원문: When to use which CSS methodology by simurai

해가 지날수록 점점 더 많은 CSS 방법론이 등장하고 있습니다. 그러나 불행하게도 언제나 먹히는 CSS 방법론은 존재하지 않기 때문에, 이 글에서는 프로젝트의 성격에 따라 어떤 CSS 방법론이 적합한지에 대해 살펴보겠습니다.

좋아요, 이제 그럼 CSS 방법론으로 가득 찬 캄캄한 동굴 속으로 들어가 봅시다.

저는 그냥 단일 페이지 사이트나 간단한 사이트를 만들고 싶어요. 콘텐츠는 대부분 텍스트로 이루어져 있고, 폼 요소가 한두개 정도 들어가 있어요. 같이 개발할 사람은 없고, 그냥 저 혼자 (그리고 제 고양이랑) 만듭니다.

👉 요소에 클래스를 부여하여 이를 선택자로 사용하는 대신, 그냥 HTML 요소를 선택자로 쓰세요. 그리고 케스케이드를 사용하여 상속이 일어나도록 하세요. 사이트 규모가 커진다면 OOCSS나 유틸리티 클래스(역: 자주 재사용하게 되는 보편적인 메소드를 모아놓은 클래스를 유틸리티 클래스라고 합니다)를 사용하는 것을 고려해 보세요.

우리는 중간 규모의 팀입니다. 프로젝트가 좀 복잡해지고 있어요. 많은 사람들이 동시에 같은 프로젝트 내에서 개발하고 있습니다.

👉 BEM, SUIT, SMACSS, ITCSS, Enduring CSS와 같은 방법론 도입을 고려해보세요. 모두 다른 방법론이긴 하지만 어느 정도 겹치는 부분도 있고, 몇가지 공통점도 존재합니다. 이들 방법론에서 제시하는 명명 규칙(naming convention)을 따른다면 다른 사람이 작성한 CSS를 망칠 염려를 하지 않아도 됩니다. 이들 중에서 어떤 것을 채택할지는 팀원들과 상의를 해서 정하고, 최종적으로 하나를 선택하기 전에 먼저 후보를 추려낸 후 직접 써보세요.

우리는 큰 회사에서 일하고, 팀의 성격도 다양합니다. 저희가 담당하고 있는 서비스는 규모가 크고, 복잡해요. 프로젝트 변경 사항을 따라가기가 벅찰 정도 입니다. 코드가 항상 유동적으로 변하고 있는데, 우리는 변경 사항이 엉뚱한 곳에 영향을 끼치는 것을 원하지 않아요.

👉 JSX, JSS (아니면 이와 비슷한 라이브러리)를 사용하세요. HTML/JS 코드에 CSS를 묶어두면 변경 하기가 편할 뿐더러, 다른 부분에도 부작용을 일으키지 않고 컴포넌트를 옮기거나 제거할 수 있습니다. 아, 그리고 ACSS와 같은 Atomic CSS 방법론도 한번 참고해 보세요. 앞에서 소개한 라이브러리와 비교해 보았을 때, 해결하려는 문제는 동일하지만 다른 접근 방법을 취하고 있습니다.

지금까지 소개한 케이스 3가지가 가장 흔하게 마주할 수 있는 상황이지만, 얼마든지 다른 요구사항을 만족시켜야 하는 상황도 발생할 수 있습니다.

본격적인 시작에 앞서 프로토타입을 먼저 만들어 보고 싶어요.

👉 TACHYONS, BASSCSS 같이 “단일 목적(single purpose) 클래스”를 생성할 수 있는 라이브러리를 사용해 보세요. HTML과 CSS 코드를 동시에 작성해야 하는 수고를 덜어줍니다. 파일을 이것저것 열어둘 필요도 없고, 클래스 이름을 짓느라 고민할 필요도 없이 마음 속에 있는 것을 그대로 구현할 수 있게 해줍니다.

우리가 진행하는 프로젝트는 대응해야 하는 상황이 너무 많고, 서비스 사용 도중에 수시로 바뀌어야 할 사항도 많아요.

👉 CSS-in-JS 라이브러리를 사용해보세요. 특정 프로퍼티를 수정해야 할 때, 클래스나 DOM 노드를 찾을 필요 없이 JS를 통해 바로 수정할 수 있습니다.

CSS 프레임워크를 만들어서 배포해보고 싶어요.

👉 네임스페이스를 붙인 BEM을 사용해보세요. 사용하는 데 제약사항이 조금 있긴 하지만, 사용자의 입맛 대로 어느 정도 변경이 가능합니다. 또한 변수를 사용해 프레임워크의 테마를 쉽게 바꿀 수 있게 만들면 사용자들이 좋아할 것 같네요.

(사용자가 임의대로 변경할 수 없는) 서드 파티 위젯을 만들어 보고 싶어요.

👉 CSS Module을 사용해보세요. 클래스 이름이 중복되지 않기 때문에 스타일이 원치 않는 곳으로 새나가는 것을 방지할 수 있습니다. Iframe이나 Web Component 사용 역시 고려해보세요.

CodePen에서 데모를 만들어 보고 싶어요.

👉 뭔가 새로운 것을 시도해보세요. 바로 이때가 평소에 해보지 않은 것을 시도해 볼 절호의 기회입니다.

저는 제 동료가 싫어요.

👉 아래와 같이 선택자를 줄줄이 나열해서 작성해 보세요. 충분히 동료를 고통스럽게 만들수 있기 때문에 당신의 가학성을 충족할 수 있을 것입니다.

header > ul.nav li.button {}

아, 잠시만요… 마지막 말은 취소하겠습니다. 선택자를 줄줄이 나열해서 쓰는 것은 마크업을 건드릴 수 없을 경우에만 사용하는 최후의 보루로 남겨주세요. CMS의 변경 감지 기능 때문에 도저히 손쓸 방법이 없는 경우 처럼요. 이런 경우에는 선택자 나열법이 가장 좋은 (그리고 유일한) 해결책이라고 생각합니다.

보시는 바와 같이, 매우 다양한 상황이 존재하기 때문에 서로가 처한 환경에 대한 파악 없이는 CSS 방법론에 대해 논의하는 것이 어려울 수 있습니다.

마치며: 반드시 하나의 CSS 방법론만 고수할 필요가 없습니다. 이미 존재하는 방법론에서 마음에 드는 부분을 가져와서 여러분만의 방법론을 만들어 보세요. 내 프로젝트 상황에 딱 맞는 방법론을 만드는 것입니다. 하다가 아니다 싶으면 새로운 방법론으로 바꾸는 것도 가능하고, 때로는 반드시 다른 것으로 갈아타야 하는 경우도 있습니다. 프로젝트가 처음에는 간단한 프로토타입으로 시작했으나 나중에는 여러명의 팀원이 함께 참여하는 복잡한 프로젝트로 커가는 경우처럼 말입니다. 방법론을 바꿀 때 자칫하다가는 꽤 시간 낭비를 할 수 있고 불안정한 방향으로 흘러가기 쉽습니다. 나중에 골치 아파지는 상황을 방지하기 위해 사전 계획을 세우는 것이 좋겠지요. 행복한 선택의 시간이 되기를 바랍니다!

알림 사항: 누구나 그렇듯이, 저 또한 한쪽으로 편향된 의견을 가지고 있습니다. 그리고 제가 하는 말이 무슨 말인지 명확히 파악하고 있을 정도로 모든 CSS 방법론을 충분히 사용해 보지는 않았습니다. 그렇지만 최대한 중립적인 자세를 가지고 이를 대하려고 합니다. 만약 여러분이 생각하시기에 이 글 전체가 완전히 잘못되었다고 생각하거나 뭔가 빠진게 있다고 느낀다면, 이 링크를 클릭해서 수정해 주세요.