Angular에서 모듈 형태로 라이브러리 직접 주입하기

메가박스 클론 프로젝트를 할 때의 일이다.
당시 나는 메인 페이지를 맡고 있었는데 코린-코린이였던 당시의 나(지금은 아마도 코린이)에게 캐러셀은 너무 큰 장벽 중에 하나였다. 모르면 용감하다고, 프로젝트를 시작하던 당시의 나는 '캐러셀을 만들어보고 싶다'는 생각을 했었다. 프로젝트의 목적은 학습이라고, 비슷하게 의견을 모은 팀원들과 나는 라이브러리를 배제하고 작업한 후 나중에 정 필요하면 추가하자고 합의했다.

코린-코린이였던 당시의 나에게 3주의 시간은 너무 짧았고, 결국 별점을 구현하는 데 너무 많은 시간을 쏟은 나는 결국 캐러셀은 부트스트랩을 사용하기로 결정한다.

라이브러리를 사용하자

바로 이것. 사실 나는 부트스트랩을 포함한 스타일 라이브러리 사용하는 것을 좋아하지 않는다. 스타일 라이브러리를 자제하려는 사람들은 대부분 커스텀이 어려운 것을 이유로 꼽는데, 나 역시도 마찬가지였다. 개인적으로 CSS 작업하는 걸 좋아하기도 한다.

하여간 당시의 나는 '일단 구현'이라는 목적이 있었고 보험처럼 마음 한구석에 쟁여놓고 있던 ngx-bootstrap(bootstrap Angular 버전)을 사용하기로 마음 먹었다.

라이브러리를 사용하는 것은 사실 너무 쉽다.

이렇게 인스톨을 해주고,

캐러셀 모듈을 찾아 추가한 뒤 부트스트랩에서 제공하는 코드를 CNP 하면 된다.

있었는데요 없었습니다

너무 쉽게 캐러셀을 적용하고 직접 만들지 못한 건 아쉽지만 잘 돌아가니 되었다고 안심하려는 찰나, 프로젝트의 모든 스타일이 망가진 것을 발견하게 됐다. 당시에 너무 당황해서 캡쳐를 남기지 못했는데 폰트부터 사이즈와 같은 거의 모든 스타일이 틀어져있는 것이었다.

처음에는 부트스트랩 때문에 벌어진 일이 아닌 줄 알았다. 캐러셀만 적용했을 뿐인데 모든 페이지의 스타일이 틀어진다는 게 이해가 잘 안 되었기 때문이었다. 특히, 상술했던 것처럼 부트스트랩이 제공하는 스타일 중에서 캐러셀만 모듈로 가져온 상황이었기 때문에 전체 스타일이 영향을 받는다는 게 더 말이 안 되는 것처럼 느껴졌다.

그런데 설치되어 있는 부트스트랩을 제거하자 기존에 작업하던 스타일대로 돌아오는 것을 발견한 뒤, 이것은 부트스트랩의 문제라는 것을 알게 되었다. 즉, angular.json 파일에 추가한 부트스트랩 모듈이 전역에 영향을 주고 있었던 것이다.

클래스명 중복 문제

angular.json 파일에 모듈을 추가했다고 해도 직접 가지고 온 요소에만 영향을 줘야 하는 것 아닌가? 라고 생각했었다. 라이브러리를 가지고 올 때마다 전체 요소에 영향을 준다면 그 라이브러리를 사용하는 의미가 없는 것 아닌가, 싶기도 했다. 그런데 당시 스타일이 더 크게 틀어졌던 원인은 프로젝트 내부에 더 있었다.

부트스트랩이 글로벌로 제공하는 스타일의 클래스명과 프로젝트를 하면서 정했던 클래스명이 겹치는 경우가 많았던 것이다. 예를 들면 button 같은 클래스명이 부트스트랩과 겹치면서 전체 스타일이 아예 다 틀어지는 문제를 낳게 되었다.

내가 생각했던 구조

부트스트랩을 적용할 때 내가 생각했던 그림은 위와 같은 것이었는데, 실제로는 아래처럼 동작했다. 왜죠

실제로 적용된 구조

angular.json에 추가한 모듈은 직접 app 내부의 특정 파일에 영향을 주는 것이 아니라 angular.json을 거치면서 전역 스타일에 영향을 미치게 되었고, 이 과정에서 클래스명이 중복되자 기존에 입힌 스타일에 부트스트랩의 스타일을 뒤집어쓰는 결과가 발생하게 되었다.

그래서 우선 커스텀 스타일이 가장 마지막에 적용될 수 있도록 위 코드와 같이 import 시점을 부트스트랩이 먼저 렌더링 된 후에 커스텀 스타일이 렌더링 되도록 변경했다. 하지만 이것만으로는 전역 스타일로 영향을 주는 것을 완전히 막을 수가 없어서 다른 대안이 필요했다.

캐러셀을 모듈로 만들어 직접 주입하자

시간이 촉박해 캐러셀에 대한 다른 대안도 없었고, 그렇다고 부트스트랩의 영향을 받은 스타일을 일일이 수정하는 것도 말이 되지 않았다. 내가 맡은 페이지는 캐러셀을 사용한 책임감으로 일일이 수정할 수도 있겠지만 그걸 팀원들에게도 함께 감당해달라고 말할 수는 없었다.

그래서 여기저기 도움을 요청하고 다녔는데, 캐러셀을 모듈로 만들어 직접 주입하면 되지 않겠냐는 조언을 듣게 됐다. ㄴㅇㄱ

모듈로 만드는 방법은 여러 가지가 있을 수 있다. 내 경우는 부트스트랩이 제공하는 캐러셀 코드가 가진 전역 속성이 아무 데나 영향을 미치지 못하도록 유니크한 클래스명을 적용하고 이 클래스에 해당할 경우에만 부트스트랩이 동작하도록 하는 방법을 선택했다.

위와 같이 유니크한 클래스명 carousel-wrap을 만들어 캐러셀을 적용해야 하는 파일에만 직접 주입하면 다른 페이지에 영향을 주지 않으면서 필요한 곳에서만 동작하게 할 수 있다.

기획은 정말로 중요하다

이 경험을 통해 내가 깨달은 것은 처음에 어떤 방향으로 갈 것인지를 기획 단계에서 명확하게 만들어야 한다는 것이었다. '일단 이렇게 하고 나중에 다른 이슈가 생기면 저렇게 하자' 하는 것은 사실 기획이 아니라 회피에 가깝다는 것을 몸소 느꼈다.

내가 겪은 캐러셀 문제는, 처음 맞닥뜨렸을 때의 당혹스러움에 비하면 구조를 아예 뜯어고치지 않고 다소 간단한 방법으로 해결할 수 있었지만 기획을 잘못해서 구조 자체를 뜯어고쳐야 하는 경우도 심심찮게 접한다. 나는 그걸 아주 적은 비용을 치루며 배웠다고 생각한다.

특정 라이브러리를 사용했을 때 이슈가 생긴다면 그 라이브러리를 채택하지 않는 방법 외에도 다양한 방법으로 문제를 해결할 수 있다는 사실을 알게 된 점 또한 작은 소득이다. '쓴다' 혹은 '쓰지 않는다' 라는 선택지만 존재한다고 생각했던 내 시야가 조금 넓어지는 계기가 되었다고 생각한다.