Read Original
#Frontend

쏘카 디자인 시스템 2.0 개발기 2편: 기술로 굴리기(웹)

쏘카 디자인 시스템 2.0 개발기 2편: 기술로 굴리기(웹)
01

Summary

쏘카는 어떻게 '동작'까지 표준화했을까? 디자인 시스템 2.0 기술 심층 분석

UI 로직 분리부터 LLM 활용까지, 쏘카가 웹 디자인 시스템을 구현하며 마주한 기술적 선택의 기록

쏘카 디자인 시스템 2.0의 웹 구현 과정을 다루며, 단순한 UI 컴포넌트 모음을 넘어 서비스 파편화를 해결하기 위한 고도화된 아키텍처를 제시합니다. 컴포넌트의 성격에 따라 Hook과 클래스 객체를 선택적으로 활용하는 설계 전략과 패키지 최적화 기법을 상세히 공유합니다.

  • 01상태 전이가 UI 애니메이션과 직결되는 경우 Hook 중심의 Orchestration 구조 채택
  • 02복잡한 정책(DatePicker 등)은 UI와 무관한 순수 로직 객체(Core)로 분리하여 테스트 용이성 확보
  • 03트리쉐이킹을 고려한 패키지 전략으로 Next.js 등 다양한 번들 환경 최적화
  • 04LLM 활용 시 단순 프롬프팅이 아닌 '지시(Instructions) 고정' 방식을 통한 코드 일관성 유지
  • 05Figma MCP와 LLM을 연동하여 디자인과 코드의 간극을 줄이는 시도

RECOMMENDATION

대규모 서비스에서 일관된 UI/UX 정책을 유지하면서도 기술적 유연성을 확보하고 싶은 프론트엔드 엔지니어 및 디자인 시스템 구축 담당자에게 강력 추천합니다.

The Problem

다양한 서비스 환경(Next.js 13~15, SSR/CSR, 각기 다른 번들러)에서 UI 정책과 비즈니스 로직이 강하게 결합되어 있어, 컴포넌트의 재사용성이 떨어지고 유지보수 비용이 증가하는 문제가 발생했습니다.

The Solution

UI 결합도에 따라 'Hook 중심(상태-애니메이션 강결합)'과 '객체 중심(복잡한 정책 로직 분리)' 구조로 이원화하고, 트리쉐이킹 최적화를 위한 패키지 전략 및 일관성 유지를 위한 AI 지시어(Instructions) 고정 방식을 도입했습니다.

The Result

UI와 로직의 명확한 분리를 통해 서비스별 커스텀 요구에 유연하게 대응할 수 있는 독립성을 확보했으며, 트리쉐이킹 최적화로 번들 사이즈 효율을 개선하고 LLM을 활용한 개발 생산성 향상 기반을 마련했습니다.

Trade-off

로직을 객체(core)와 Hook 어댑터로 분리함에 따라 초기 설계 복잡도가 증가하고 단순한 컴포넌트에도 다소 과한 아키텍처가 적용될 수 있는 오버엔지니어링의 위험이 존재합니다.

03

Key Concepts

Concept · 01

Hook 중심 아키텍처

UI의 상태 변화가 제스처나 애니메이션과 밀접하게 연동될 때, React Hook을 사용하여 상호작용 로직을 캡슐화하는 방식입니다.

  • BottomSheet와 같이 드래그, 스냅 포인트 등 UI와 상태가 강결합된 컴포넌트에 적용
  • useBottomSheet.tsx 내에서 여러 Hook을 오케스트레이션하여 복잡한 제어 수행
Concept · 02

Core-Adapter 패턴

비즈니스 로직이나 복잡한 정책을 순수 자바스크립트 객체(Core)로 구현하고, 프레임워크 종속적인 Hook이나 컴포넌트를 어댑터로 사용하는 구조입니다.

  • DatePicker의 날짜 계산, 비활성 정책 등 UI와 독립적인 로직을 DateManager 클래스로 분리
  • 프레임워크나 UI 라이브러리가 변경되어도 핵심 로직을 재사용하고 독립적으로 테스트 가능
Concept · 03

트리쉐이킹(Tree Shaking)

빌드 과정에서 사용하지 않는 코드를 제거하여 최종 번들 크기를 줄이는 최적화 기술입니다.

  • 디자인 시스템 패키지에서 필요한 컴포넌트만 포함되도록 번들 구조 설계
  • Next.js 13~15 등 다양한 SSR/CSR 환경에서의 로딩 성능 최적화