카카오웹툰은 CSS를 어떻게 작성하고 있을까?

CSS-in-JS의 등장 배경과 장단점, 그리고 카카오웹툰이 실제로 CSS를 어떻게 작성하는지 방법론 선택의 이유와 함께 소개한다. 복잡한 인터랙션이 많은 서비스에서 CSS 방법론이 성능에 미치는 영향을 실증적으로 다룬다.

핵심 포인트 - CSS의 역설: 직관적이고 간단해 보이지만 복잡한 페이지에서는 디버깅과 유지보수가 극도로 어려워지는 특성 - CSS-in-JS 등장 배경: 2014년 Facebook의 Vjeux 발표. Global namespace, 의존성, Dead Code, 상태 공유 어려움 등 CSS 7가지 문제를 해결하기 위해 등장 - CSS-in-JS 해결 방식: 빌드 타임 유니크 클래스명 자동 생성, 컴포넌트 단위 스코프화, JS 상태 공유, 컴포넌트와 CSS 동일 파일 관리 - CSS-in-JS의 단점: 작업 효율(DX) 측면의 장점은 있지만 런타임에 스타일을 생성하므로 JS 번들 크기 증가, SSR 시 스타일 주입 복잡성, 성능 부담 발생 - Next.js의 CSS Module 기본 제공: v9.2부터 CSS Module을 내장 지원. 클래스명 지역화, 빌드 타임 처리로 런타임 비용 없음 - 카카오웹툰의 선택: 복잡한 인터랙션·영상·이미지가 많은 서비스 특성상 런타임 비용 없는 방식 채택

상세 정리 - Styled-Components: CSS-in-JS의 대표 라이브러리. 컴포넌트 선언과 동시에 스타일 정의, ThemeProvider로 디자인 토큰 공유 - CSS-in-JS의 SSR 복잡성: 서버 사이드에서 스타일을 추출해 HTML head에 삽입하는 별도 처리 필요. Next.js와 통합 시 주의점 증가 - CSS Module의 장점: 클래스명 충돌 없음(빌드 시 해시 접미사), 런타임 오버헤드 없음, 표준 CSS 문법 그대로 사용 - BEM, OOCSS, SMACSS: 전통적 CSS에서 Global namespace 문제를 명명 규칙으로 해결하려던 방법론들. CSS-in-JS가 이를 자동화 - 성능 고려: 많은 인터랙션이 있는 서비스에서 런타임 CSS 생성은 재렌더링마다 비용 발생 가능 - 서비스 성격과 CSS 방법론 선택의 상관관계: 복잡도·팀 규모·SSR 여부에 따라 최적 방법론이 다름

왜 읽나: CSS 방법론의 역사적 흐름과 각 방식의 실질적 트레이드오프를 이해하고, 카카오웹툰 같은 복잡한 서비스에서 어떤 기준으로 CSS 전략을 선택하는지 배울 수 있다.