디자인 시스템 사례 · · 8 min read

인프런 디자인 시스템 구축기 2편 - 만든 후가 진짜 시작이었다

디자인과 개발의 간극을 좁히기 위해 인프런이 선택한 디자인 시스템 고도화 전략, 그리고 그 운영 방식까지 자세히 살펴봅니다.

인프런 디자인 시스템 구축기 2편 - 만든 후가 진짜 시작이었다

인프런 디자인 시스템 구축기 1편에 이은 내용입니다.

인프런 디자인 시스템 구축기 1편 - 오픈소스에서 길을 찾다
인프런은 디자인 파편화와 비효율을 해결하기 위해 디자인 시스템을 구축했습니다. 어떤 고민과 선택이 담겨 있었는지 그 여정을 함께 따라가 봅니다.

디자인 시스템, 만들긴 만들었는데…그다음은요?

많은 팀이 “디자인 시스템 도입기”까진 블로그에 자주 올리지만, 정작 그걸 어떻게 운영하고 있는지에 대한 이야기는 보기 어렵습니다. 인프런은 달랐습니다.

2022년부터 Mantine 기반 오픈소스로 시작한 디자인 시스템, 그걸 두 해 동안 직접 운영하며 겪은 현실적인 이야기를 낱낱이 공개해 주었거든요. 하나하나 공개한 내용을 살펴보겠습니다.

단일 패키지로? 음… 인프런은 쪼갰습니다

보통 디자인 시스템은 @ds/core 같은 통합 패키지 하나로 관리되곤 하죠. 근데 인프런은 역시 조금 달랐습니다.

각 컴포넌트를 개별 패키지로 분리해서 운영하고 있었거든요. 왜 이렇게 귀찮은 선택을 했을까요?

“그냥 하나로 만들지 말고, 컴포넌트 단위로 나눠서 배포하자.”
— 홍시, 프론트엔드 개발자

그 덕분에 이런 상황에선 꽤 유리했다고 합니다:

  • 특정 컴포넌트만 롤백하고 싶을 때
  • 서비스마다 필요한 것만 골라 쓰고 싶을 때
  • 커스터마이징 범위를 최소화하고 싶을 때

물론 현실에선 다들 통합 패키지로 설치해서 씁니다 😅
하지만 운영자 입장에선 쪼개놓은 덕분에 숨통 트인 순간이 많았다고 하네요.

커스터마이징, 어디까지 해봤니?

Mantine의 커스터마이징 API는 정말 괜찮습니다. ThemeProvider로 전역 스타일 조정하고, variant, size 같은 prop에 따라 조건부 스타일도 설정 가능하죠.

그런데 API로 다 되는 건 아니잖아요. 그래서 인프런은 이렇게 했습니다:

  • ThemeProvider로 되는 건 거기서 처리
  • 그걸로 안 되는 건 컴포넌트 자체를 래핑해서 커스터마이징

예컨대 Notification 컴포넌트에서 message는 무조건 title과 함께 써야 한다는 규칙이 있다면? 그 정책을 타입 레벨에서 명확하게 정의해버립니다.

“디자인 시스템은 단순히 스타일만 정리하는 게 아니라, 사용 방식을 정의하는 도구예요.”
— 비케이, 프로덕트 디자이너

디자이너도 직접 보고, 직접 확인할 수 있어야죠

디자인 시스템, 개발자만 쓰는 거 아니잖아요. 그래서 인프런은 Storybook을 거의 운영 매뉴얼처럼 활용하고 있었습니다.

  • Prop을 Control 패널에서 바로 조절 가능
  • 커스터마이징된 컴포넌트엔 README, Changelog도 포함
  • 디자이너가 개발자 없이도 확인 가능하게 HTML 프리뷰 Storybook 자동 배포
“문서는 개발자만 보는 게 아니라, 디자이너도 함께 보는 거예요.”
— 레슬리, 프로덕트 디자이너

공식 문서로 커버되지 않는 컴포넌트일수록, 내부용 Storybook이 실질적인 의사소통 도구로 작동하고 있었습니다.

한 명이 아니라, 모두가 만드는 시스템

한 명이 아니라, 모두가 만드는 시스템

플랫폼팀이 없다는 건, 디자인 시스템도 누구든 기여할 수 있어야 한다는 뜻입니다. 그래서 인프런은 시스템 기여의 진입장벽을 아주 낮췄습니다.

  • Contribution Guide 문서화
  • Jira로 히스토리 정리
  • PR 작성 시 Changelog, SemVer, 이슈 연결 필수
  • 코드엔 정책이 잘 드러나도록 테스트코드와 타입 정의 적극 활용
“우리는 UI를 정리한 게 아니라, 협업을 정리하고 있었던 거예요.”
— 홍시, 프론트엔드 개발자

자인 시스템도 누구든 기여할 수 있어야 한다는 뜻입니다. 그래서 인프런은 시스템 기여의 진입장벽을 아주 낮췄습니다.

오픈소스 업데이트? 생각보다 빡셉니다

Mantine은 꾸준히, 그리고 과감하게 업데이트됩니다. 2년 동안 무려 3개의 메이저 릴리즈가 나왔고요. 그래서 인프런은 이걸 루틴처럼 운영하고 있었습니다:

  • 프론트엔드 개발자가 먼저 PoC 및 영향도 분석
  • 디자이너에게 “이건 꼭 아셔야 해요” 버전 요약 전달
  • Storybook, Zeroheight 등 문서도 함께 업데이트
“디자이너가 이해할 수 있는 언어로 기술적 변화를 설명하는 것, 그것도 디자인 시스템 운영 능력이더라고요.”
— 엠제이, 프로덕트 디자이너

운영하면서 깨달은 건 하나였다고 합니다. “오픈소스를 쓰더라도, 우리의 기준을 세워야 한다”는 것.

지금은, 고도화 중입니다

시스템은 이제 안정적으로 돌아가고 있지만 팀은 거기서 멈추지 않았습니다. 현재 인프런이 준비 중인 고도화 항목은 다음과 같습니다:

  • Emotion 제거 → SSR 대응 + 렌더링 비용 감소
  • 디자인 토큰 기반 구조 → 스타일 일관성과 다크모드 대응
  • Mantine v7 도입 → Chakra처럼 breakpoints 기반 prop 지원
“인프런만의 스타일을 더 잘 담아내는 시스템으로 확장하는 게 목표예요.”
— 비케이, 프로덕트 디자이너

이제는 어떻게 만들까를 넘어서 ‘어떻게 우리답게 운영할까’를 고민하는 단계에 들어섰다고 합니다.

디자인 시스템은 "사람을 위한 도구"

디자인 시스템은 "사람을 위한 도구"

인프런의 이야기를 보면 디자인 시스템이란 결국 “사람을 위한 도구”라는 걸 다시 한 번 느끼게 됩니다. 단순한 UI 정리에서 시작했지만 이제는 팀 전체의 협업을 돕는 문화로 확장되었고, 스타 없이도 시스템이 유지되는 구조가 만들어졌습니다.

“디자인 시스템, 그건 결국 협업의 도구였습니다.”
— 엠제이, 프로덕트 디자이너

인프런이 블로그에서 공유해주신 것처럼 지금도 잘 운영하고 계실지 궁금해지네요.
읽어주셔서 감사합니다 😄
디자인 시스템 관련해서 궁금한 점이 있으시면 언제든 펑션투웰브에 문의 주세요!

Read next