왜 디자인시스템이 필요했나
회사의 B2B 서비스를 Next.js로 마이그레이션하기로 결정했습니다. 기존 서비스는 Gulp + AngularJS 기반의 레거시 코드베이스였고, 마이그레이션 과정에서 UI 컴포넌트를 처음부터 다시 만들어야 하는 상황이었습니다.
그 시점에 한 가지 선택지가 생겼습니다.
"마이그레이션할 때마다 그냥 컴포넌트를 새로 만들 건가, 아니면 한 번 제대로 만들어둘 건가?"
서비스가 B2B 하나가 아니었습니다. B2C, CMS, OCMS까지 여러 서비스가 있었고, 각자 비슷한 UI를 따로따로 만들어 쓰고 있었습니다. 토글을 어떤 서비스에서는 "스위치"라고 부르고, 어떤 서비스에서는 "토글"이라고 부르는 일도 있었습니다.
공통 디자인시스템이 없다면 마이그레이션을 할 때마다 같은 컴포넌트를 반복해서 만드는 일이 반복될 게 분명했습니다.
그래서 마이그레이션의 선행 작업으로 디자인시스템을 구축하기로 결정했습니다.
혼자였다
문제는 저 혼자였다는 겁니다.
- 디자이너: 없음
- QA: 없음
- 함께 설계를 검토해줄 FE 동료: 없음
처음엔 막막했습니다. 디자인시스템은 보통 여러 명이 만드는 거 아닌가? 하는 생각이 들었습니다.
그런데 반대로 생각하면, 혼자이기 때문에 의사결정이 빨랐습니다. 컴포넌트 하나를 설계할 때 여러 사람의 의견을 조율할 필요가 없었습니다. 방향을 정하면 바로 코드로 옮길 수 있었습니다.
컴포넌트 설계 방향
컴포넌트를 두 가지로 나눴습니다.
1. 기반 컴포넌트 (36개) Button, Input, Modal, Select, Checkbox, Tooltip 같은 범용 UI 컴포넌트들입니다. Radix UI를 기반으로 설계했습니다.
Radix를 선택한 이유는 하나였습니다. **접근성(a11y)**을 직접 구현하면 WAI-ARIA 스펙을 모두 커버하기 어렵습니다. Radix는 스타일이 없는(unstyled) 컴포넌트를 제공하면서 접근성은 보장해줍니다. 디자인 자유도를 유지하면서 접근성을 공짜로 가져갈 수 있었습니다.
2. 도메인 특화 컴포넌트 (31개) CameraPlayer, MotionZoneEditor, EventTimeline처럼 우리 서비스 도메인에 특화된 복합 컴포넌트들입니다. 기반 컴포넌트를 조합해서 만들었습니다.
Figma가 없다면 직접 만든다
디자이너가 없으니 Figma 파일도 없었습니다.
그렇다고 개발자가 UI를 감으로 만들면 나중에 기획자와 싱크를 맞추기 어렵습니다. 그래서 제가 직접 Figma를 배워서 UI 초안을 설계했습니다.
완벽한 디자인 시스템 수준은 아니었지만, 컴포넌트의 상태(default, hover, disabled, error)와 변형(variant)을 정리해두는 것만으로도 개발할 때 기준점이 생겼습니다.
Storybook으로 해결한 의외의 문제
Storybook을 도입한 이유는 컴포넌트 문서화였습니다. 그런데 예상치 못한 부분에서 더 큰 효과가 있었습니다.
기획자·개발자 간 UI 명칭 혼선 해소
같은 UI 요소를 기획자는 "토글", 개발자는 "스위치"라고 부르는 상황이 꽤 있었습니다. 이런 혼선이 쌓이면 커뮤니케이션 비용이 높아집니다.
Storybook에 컴포넌트를 올려두고 "이게 공식 명칭입니다"라고 공유했습니다. 이후로 명칭 혼선으로 인한 재확인 커뮤니케이션이 확연히 줄었습니다.
alpha 배포 없이 동작 확인 가능
예전에는 "이 컴포넌트가 이렇게 동작하나요?" 하는 질문에 "alpha에 배포해볼게요"라는 답이 나왔습니다. 이제는 Storybook 링크를 공유하면 됩니다. 배포 없이도 기획자가 직접 동작을 확인할 수 있게 됐습니다.
배포 파이프라인 자동화
컴포넌트를 만드는 것만큼 배포 관리도 중요합니다. 디자인시스템은 여러 서비스가 의존하는 공통 패키지이기 때문에 버전 관리가 엉키면 큰일이 납니다.
GitHub Actions의 label을 기반으로 자동 버전 관리와 배포를 구성했습니다.
PR에 "patch" / "minor" / "major" 라벨 부착
↓
머지 시 자동으로 버전 bump
↓
사내 Nexus 패키지 레지스트리에 자동 배포
수동으로 버전을 올리고 배포하는 실수를 없앴습니다.
현재와 앞으로
현재 67개 컴포넌트가 구현됐고, B2B Next.js 마이그레이션에 먼저 적용될 예정입니다. 이후 B2C → CMS → OCMS 순서로 전사에 적용해 나갈 계획입니다.
디자인시스템 하나가 모든 서비스의 UI 일관성 기반이 되는 구조를 만들어가고 있습니다.
회고
"FE 혼자 디자인시스템을 만든다"는 게 처음엔 무모하게 느껴졌습니다. 실제로 힘든 순간도 많았습니다. 컴포넌트 하나를 설계할 때 "이게 맞나?" 싶어서 오픈소스 코드와 문서를 몇 시간씩 파고든 날도 있었습니다.
하지만 돌아보면 이 경험이 가장 많이 배운 시간이기도 합니다. 접근성이 왜 중요한지, 컴포넌트 API를 어떻게 설계해야 사용하기 편한지, 패키지 버전 관리는 어떻게 해야 하는지를 직접 부딪혀가며 배웠습니다.
혼자 한다는 건 힘들지만, 그만큼 설계의 처음부터 끝까지 내 손을 거친다는 뜻이기도 합니다. 그 과정에서 얻은 깊이가 코드에 녹아 있다고 생각합니다.