Kiwi.com이 Figma에서 프로젝트

Kiwi.com은 여러 도구를 조합한 Sketch 중심 workflow에서 발생하는 동기화 문제를 해결하기 위해 모바일 디자인 시스템을 Figma로 옮기기 시작했다. 소규모 디자인팀과 약 20명의 협업자가 함께 작업하는 환경에서는 디자인, 프로토타입, 개발 전달, 버전 관리가 하나의 협업 공간에서 연결되는 것이 중요하다고 판단했다. 이 글은 Figma 도입 배경과 디자인 라이브러리·컴포넌트·프로젝트 구조를 정리하는 방식을 소개한다.

Kiwi.com의 디자인 환경과 과제

• 모바일 디자인팀은 디자이너 2명으로 구성되어 있지만, 약 20명이 다양한 방식으로 디자인에 참여한다.
  • 디자인 시안에 댓글을 남기는 사람
  • 카피를 수정하는 사람
  • 여러 플랫폼을 아우르는 기능을 설계하는 사람
• 기존 프런트엔드 디자인과 디자인 시스템인 Orbit는 Sketch를 기반으로 운영되고 있었다.
• 그러나 Orbit의 모바일 버전은 시각적으로 차이가 커서, 별도의 모바일 디자인 시스템을 Figma에서 시험하게 되었다.

Sketch 기반 도구 조합의 동기화 문제

• 기존 workflow에서는 목적별로 여러 도구를 사용했다.
  • Sketch: 디자인 제작
  • Zeplin: 개발자 핸드오프
  • Abstract: 버전 관리
  • Marvel: 정적 프로토타입 제작
  • Dropbox Paper: 디자인 이미지 공유
• 도구가 분리되어 있어 최신 상태가 서로 달라질 수 있었다.
  • 프로토타입이 최신 테스트 버전을 반영하지 못함
  • 작업자가 Abstract에 커밋하는 것을 잊음
  • 승인된 최종 시안이 Zeplin에 업데이트되지 않음
  • 문서에 첨부된 PNG가 몇 주 전 버전으로 남아 있음
• 각 도구는 독립적으로 작동하기 때문에, 팀이 수동으로 상태를 맞추지 않으면 디자인 산출물이 쉽게 불일치한다.

Figma를 선택한 이유

• Figma 도입의 핵심 기대 효과는 디자인 파일, 협업, 프로토타입, 버전 이력을 한 환경에서 연결하는 것이었다.
• 여러 도구 사이에서 최신 파일을 확인하고 전달하는 관리 비용을 줄일 수 있다.
• 다수의 참여자가 디자인 과정에 관여하는 Kiwi.com의 환경에서는 중앙화된 협업 방식이 특히 유용하다.
• 저자는 초기에는 브라우저 기반 도구인 Figma의 가치에 회의적이었지만, 실제 팀의 협업 문제를 경험하면서 Figma 도입의 필요성을 재평가하게 되었다.

글에서 다루는 디자인 시스템 운영 범위

• 글은 단순한 Figma 사용 후기가 아니라 다음 운영 주제를 함께 다룬다.
  • 모바일 디자인 시스템을 Figma로 구축한 이유
  • Figma 업데이트 이후 달라진 작업 방식
  • 디자인 라이브러리 컴포넌트의 설계 원칙
  • 컴포넌트와 프로젝트 파일의 구조화
  • 버전 이력 관리와 파일 정리
• 특히 여러 사람이 컴포넌트를 재사용하는 환경에서 일관성을 유지하고, 최신 디자인 자산을 쉽게 찾도록 구성하는 방법에 초점을 둔다.

여러 협업자가 디자인에 참여하고 도구별 최신 상태를 수동으로 맞추고 있다면, Figma처럼 디자인·프로토타입·협업을 한 공간에 통합하는 방식을 검토할 만하다. 다만 도구를 바꾸는 것만으로 문제가 해결되지는 않으므로, 컴포넌트 명명 규칙과 파일 구조, 버전 관리 원칙을 함께 정립하는 것이 중요하다.