쏘카 디자인 시스템 2.0 개발기 1편: 시스템으로 운영하기(웹)

쏘카프레임 2.0의 핵심은 UI 라이브러리를 넘어, 정책, 연동, 운영까지 포함한 시스템으로 재정의한 데 있다. 디자인 토큰, 컴포넌트, 문서, 연동 규칙을 공통 기반으로 두되, 서비스별 UI 정책과 화면 구성은 각 서비스 책임으로 분리해 역할 경계를 분명히 했다.

설계 목표는 두 가지였다. 하나는 변화에 대응하고 확장 가능한 UI 라이브러리를 포함한 시스템을 만드는 것이고, 다른 하나는 Figma를 중심으로 한 기존 업무 흐름을 효율화하는 것이었다.

연동 체계는 두 방향으로 강화됐다.

• 디자이너 → 개발자(라이브러리): Figma Plugin으로 아이콘과 스페이싱 토큰 같은 정적 에셋을 디자이너가 직접 PR 생성까지 이어가도록 바꿨다. 기존의 슬랙 전달, 수동 PR, 검증, 배포 과정을 줄여 리드타임을 낮췄다.
• 개발자(라이브러리) → 개발자(서비스): 기존 Storybook 중심 확인 흐름을 보완하기 위해 Figma Code Connect를 적용했다. 디자이너가 선택한 노드에 대응하는 라이브러리 코드를 바로 보여줘 사용 흐름을 단축했다.

특히 상태와 변형이 많은 DatePicker 같은 컴포넌트는 단순 매핑이 어려웠고, 디자인과 개발의 작업 방식 차이도 컸다. 디자인 쪽은 Figma Variant 중심 사고가 익숙한 반면, 개발 쪽은 합성 컴포넌트 구조의 유연성이 중요했기 때문에, 결국 Slot 개념을 채택해 Code Connect와 설계 정합성을 맞췄다.

운영은 장기 프로젝트에 맞게 정기 회의 → UI/UX 정책 합의 → 구현 → 검증의 흐름으로 유지했다. 우선순위에 따라 마일스톤을 나누고, 완료된 컴포넌트는 가능한 빨리 서비스에 반영했으며, 일부는 부분 적용 → 피드백 → 수정 방식으로 운영했다.

과정에서 OS별 구현 차이, 슬롯 구조와 상태 정의를 둘러싼 직군 간 합의, QC를 통한 품질 관리가 중요한 과제로 드러났다. 결국 디자인 시스템은 단순한 컴포넌트 묶음이 아니라, 설계 방식과 운영 규칙까지 합의한 뒤에야 반복 가능한 생산 체계가 된다는 점을 강조한다.