스타일링
✅ 요구사항
우테코 스타일링 요구사항이다.
- 다양한 스타일링 방법의 특징과 차이를 이해한다.
- 직접 스타일링 할 수 있는 방법 중 한 가지를 팀 내에서 자율적으로 결정하고 도입한다.
- 프로젝트 상황에 적합한 방법이다.
- 결정한 이유가 문서화한다.
- 기술적 선택의 이유를 설명할 수 있다.
✅ 사용 가능한 도구는?
Bootstrap, MUI, Ant Design, Chakra UI, Tailwind CSS 등은 금지된다. 실제 프로덕트의 기획과 디자인은 이런 틀만으로 만족시킬 수 없는 경우가 많기 때문이다. 사용하더라도 서비스의 필요에 맞춰 커스텀이 필요한 일이 잦다고 한다. 그래서 이번 미션에서는 직접 마크업하고 스타일링 하는 기본기를 쌓아두는 것을 목표로 한다.
- CSS
- CSS Modules
- CSS-in-JS (Emotion 등)
- Zero Runtime CSS-in-JS (Vanilla extract 등)
- CSS Preprocessor (SASS 등)
🤔 경험을 바탕으로 비교해보면...
일단 경험을 바탕으로 CSS, CSS Modules, Emotion을 비교해보면...
- CSS
- 👍 설치 필요 없음
- ❌ 글로벌 범위라 클래스명 충돌 관리해야 함
- CSS Modules
- 👍 클래스명 충돌 해결 (자동으로 해시 처리함)
- ❌ props 기반 동적 스타일링이 불편함 (조건부 스타일링은 가능하지만, css Modules는 정적 클래스 기반이라 props를 스타일 쪽에서 직접 받아서 처리하는 건 어려움)
- Emotion/styled
- 🤔 스타일과 컴포넌트가 완전히 묶임
- 👍 props를 바로 받아서 조건부 처리가 가능
- ❌ 스타일 재사용이 어려움
- Emotion/react
- 🤔 스타일과 컴포넌트가 묶여 있지 않음
- 👍 여러 컴포넌트가 하나의 스타일 재사용 가능
- ❌ props 값을 스타일 함수 파아미터로 전달해서 조건부 처리(props를 스타일 함수로 일일이 전달해야 해서 귀찮음)
🤔 런타임 시간을 생각해보면...
- CSS, CSS Modules
- ✅ 런타임 비용 없음
- 스타일을 빌드 타임에 미리 계산해서 .css 파일로 만들어 브라우저에 전달함
- 앱 실행 시점에는 브라우저가 CSS 파일만 읽고 바로 스타일 적용함
- JS 코드와 CSS가 완전히 분리됨
- 처리 흐름:
[개발] → CSS 파일 생성 → 브라우저가 파일을 읽음
→ 빠르고 가볍다. 앱 규모가 커져도 스타일링 성능 이슈 거의 없다.
- Emotion
- ⚠️ 런타임 비용 있음
- CSS-in-JS 방식 → CSS를 JS 코드 안에서 작성함
- props/state 값에 따라 JS 코드 실행 시점에 스타일 계산함
- 계산된 CSS를 기반으로 고유한 클래스명 생성함 (ex: css-abc123)
- DOM에
<style>태그를 동적으로 삽입함 - 처리 흐름:
[앱 실행 시] → JS 코드 실행 → props 값 기반으로 CSS 계산 → <style> 태그 생성 → DOM에 삽입
→ 동적 스타일링은 강력하지만,
→ 스타일 계산 및 삽입 때문에 초기 렌더링에서 비용 발생 할 수 있다.
→ 다만@emotion/babel-plugin등으로 최적화 가능하다.
라이브러리에 따라 런타임 시간 유무가 있다. 하지만 런타임 시간은 충분히 줄일 수 있어서 크게 단점이 되는 것 같지 않다.
🤔 사용자 스토리 작성으로 비교하기?
Spotify 팀은 스타일링 도구를 선정할 때 사용자 스토리와 기능을 정의하고, 각 항목별로 객관적인 점수를 매겨 결정하는 POS 과정을 거친다고 한다. (링크)
그래서 나도 이전 미션에서의 경험을 가지고 스타일링 도구를 비교해보았다.
기능이 존재하지 않으면 0점, 기술 부채를 유발하는 경우에는 1점, 완벽하게 제공되면 2점이다.
- 사용자 스토리 (기능)
- HTML 코드를 보면 대략 어떤 스타일인지 알 수 있기를 바란다. (직관적 이해)
- 클래스명을 정하는 데 너무 많은 시간 쓰지 않길 바란다. (CSS 네이밍 부담 최소화)
- CSS를 보기 위해 파일 위아래를 왔다갔다 하지 않도록 하고 싶다. (CSS 위치 접근성)
- HTML 용량을 줄이기 위해 클래스명을 난독화하고 싶다. (production에서 클래스명 난독화)
- 타입스크립트로 값을 올바르게 사용하는 데 자신감을 갖고 싶다. (타입스크립트 지원)
- 자세하고 최신화된 공식 문서를 원한다. (문서화)
- 다양한 조직에서 검증된 프레임워크를 사용하고 싶다. (커뮤니티 해결 사례)
- 디자인 시스템 값에 대한 자동완성이 있으면 좋겠다. (VSC 자동완성)
- 색상 미리 보기 등 VSCode에서 추가 도구를 사용할 수 있으면 좋겠다. (도구 확장성)
- 배운 기술이 다른 사이드 프로젝트나 직장에서 그대로 쓸 수 있으면 좋겠다. (기술 이전 가능성)
🤔 사용자 스토리 작성으로 비교하기!
1️⃣ 사용자 스토리: HTML 코드를 보면 스타일 직관적 이해
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 2 | ✅ 클래스명 그대로 보여서 구조 파악 쉬움 |
| CSS Modules | 2 | ✅ 해시 클래스지만 JS import로 추적 가능 |
| Emotion/css | 1 | ⚠️ 클래스명이 난독화(css-abc123) → 직관성 조금 떨어짐 |
| Emotion/styled | 0 | ❌ DOM에 StyledComponent로 표시 → HTML에서 스타일 추적 어려움 |
2️⃣ 사용자 스토리: CSS 네이밍 부담 최소화
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 0 | ❌ 글로벌 스코프라 네이밍 전략(BEM 등) 필요 |
| CSS Modules | 2 | ✅ 자동 해시 처리 → 네이밍 충돌 완벽 방지 |
| Emotion/css | 2 | ✅ 해시 클래스 생성으로 네이밍 부담 없음 |
| Emotion/styled | 2 | ✅ 해시 클래스 생성으로 네이밍 부담 없음 |
3️⃣ 사용자 스토리: CSS 위치 접근성 (파일 위아래 이동 필요)
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 0 | ❌ CSS 파일과 JS가 분리돼있어 코드 확인 시 파일 이동 필요 |
| CSS Modules | 1 | ⚠️ 컴포넌트 단위로 관리 가능하지만 여전히 CSS 파일 따로 관리 |
| Emotion/css | 2 | ✅ 스타일을 JS 코드와 같이 작성 → 파일 이동 불필요 |
| Emotion/styled | 2 | ✅ 스타일과 컴포넌트 완전 결합 → 한곳에서 관리 가능 |
4️⃣ 사용자 스토리: 프로덕션 클래스명 난독화
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 0 | ❌ 빌드 시 클래스명이 그대로 노출 |
| CSS Modules | 2 | ✅ 클래스명이 해시 처리(Button_button__abc123)로 난독화됨 |
| Emotion/css | 2 | ✅ 클래스명이 해시 처리(css-xyz456)로 난독화됨 |
| Emotion/styled | 2 | ✅ 클래스명이 해시 처리(css-xyz456)로 난독화됨 |
5️⃣ 사용자 스토리: 타입스크립트 지원
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 0 | ❌ TS와 연계된 기능 없음 |
| CSS Modules | 1 | ⚠️ 클래스명 타입 추론 가능하지만 CSS 속성 자동완성 불가 |
| Emotion/css | 2 | ✅ props 타입 추론과 자동완성 지원 |
| Emotion/styled | 2 | ✅ props 타입 추론과 자동완성 지원 |
6️⃣ 사용자 스토리: 디자인 시스템 자동완성
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 0 | ❌ props 기반 스타일링 불가, 자동완성 미지원 |
| CSS Modules | 1 | ⚠️ 제한적 지원 (조건부 클래스 처리만 가능) |
| Emotion/css | 2 | ✅ props 기반 동적 스타일링 지원 → 디자인 시스템에 최적화 |
| Emotion/styled | 2 | ✅ props 기반 스타일링 자연스럽게 지원 |
7️⃣ 사용자 스토리: 기술 이전 가능성 (다른 프로젝트 적용)
| 기술 | 점수 | 이유 |
|---|---|---|
| CSS | 2 | ✅ CSS는 모든 프로젝트 기본 포함 → 이전 용이 |
| CSS Modules | 2 | ✅ React 생태계에서 많이 사용 → 다른 프로젝트 적용 용이 |
| Emotion/css | 2 | ✅ CSS-in-JS 지원하는 프로젝트로 이전 가능 |
| Emotion/styled | 2 | ✅ CSS-in-JS 지원하는 프로젝트로 이전 가능 |
✅ 최종 점수
| 기술 | 점수 | 총평 |
|---|---|---|
| CSS | 10 | 기본적인 스타일링에 적합. 글로벌 충돌 관리 필요 |
| CSS Modules | 17 | 클래스 충돌 방지 및 정적 스타일링 강점. props 기반 동적 스타일은 불편 |
| Emotion/css | 21 | 디자인 시스템 구축에 최적. props 기반 동적 스타일링 자연스럽고 재사용성 높음 |
| Emotion/styled | 20 | 빠른 개발에 적합. 스타일과 컴포넌트 결합 → 재사용 설계 시 주의 필요 |
Spotify가 중요하게 생각하는 사용자 스토리 중 나에게 필요한 항목만 뽑아 점수를 매겨보니, Emotion이 가장 높은 점수를 기록했다. 특히 props 기반 조건부 스타일링, 타입스크립트 지원, 디자인 시스템 자동완성 등에서 CSS와 CSS Modules와 차이를 보였다. 런타임 비용이라는 단점이 있긴 하지만, 이는 최적화로 해결할 수 있는 부분이고 개발 생산성 측면에서는 Emotion이 가장 적합하다고 판단했다.
☀️ emotion/styled VS emotion/react 최종 선택은?
이전 미션까지는 컴포넌트 중심으로 빠르게 작업하기 위해 emotion/styled를 주로 사용했다. 하지만 공통된 스타일을 여러 컴포넌트에서 재사용하는 것이 쉽지 않아 점점 불편함을 느꼈다.
그래서 이번에는 Emotion/react를 선택했다. Bootstrap이나 Tailwind CSS처럼 아주 작은 스타일 단위로 그룹을 만들어 클래스로 지정하고, 이를 조합하여 재사용하는 방식에 도전해보려 한다. 이 방식은 유지보수성과 확장성이 높아져, 디자인 시스템을 따라갈 때도 도움이 될 것이라 기대한다.
🍵 마무리
우리가 사용할 디자인 도구를 신중하게 선택했다. 앞으로도 프로젝트를 진행하면서 계속 선택의 순간들을 마주하게 될 것이다. 그 과정에서 더 나은 판단을 내릴 수 있는 선택의 감각을 기르기 위해 여러 방법을 시도하며 경험을 쌓아갈 계획이다 :)
