6개월 운영 끝에 스펙 누락 컴플레인이 주 8건에서 0건이 됐습니다. Zeplin 하나가 바꾼 결과였습니다. 그런데 Figma Dev Mode가 나오면서 저는 이 도구를 새 프로젝트에 더 이상 기본 추천하지 않게 됐습니다. 팀 규모와 디자인 시스템 성숙도에 따라 선택이 달라지기 때문입니다.
라이선스 ROI, 직접 계산해봤습니다
Zeplin은 디자이너와 개발자 양쪽에 라이선스 비용이 부과됩니다. 팀 규모가 커질수록 월정액이 선형으로 늘어나는 구조입니다. 처음 이 비용 구조를 접했을 때 솔직히 이건 예상 밖이었습니다. 개발자 좌석 비용까지 붙는 협업 도구가 생각보다 많지 않거든요.
ROI란 Return on Investment, 즉 투자 대비 회수율을 의미합니다. 저는 외주 7건에서 팀 규모별 BEP(손익분기점, Break-Even Point)를 계산했습니다. BEP란 라이선스 비용이 도구를 쓰지 않았을 때 발생하는 커뮤니케이션 낭비 비용과 같아지는 시점입니다. 쉽게 말해 "이 시점부터 본전"인 지점입니다.
결론부터 말씀드리면, 디자이너 6명·개발자 15명 이하 팀은 Figma Dev Mode로 완전 대체 가능하다는 게 데이터로 나왔습니다. 이 수치를 임원 보고서에 제시했을 때 반응이 꽤 달랐습니다. 숫자가 있으니 설득이 됐습니다. 이 보고서 템플릿은 이후 외주 5건에서 재사용 중입니다.
Zeplin의 라이선스 비용이 부담이 되는 팀이라면, 먼저 현재 팀의 스펙 누락 건수와 커뮤니케이션 비용을 측정해보시길 권합니다. 감으로 판단하는 것보다 훨씬 설득력 있는 의사결정이 가능합니다.
버전관리, 디자인 파일과 무엇이 다른가
Figma나 Sketch 같은 디자인 파일에도 버전 히스토리는 있습니다. 그런데 제가 직접 써봤는데, 이건 Google Docs의 자동 저장 히스토리와 본질적으로 같습니다. 언제 뭘 바꿨는지 알기 어렵고, 변경 맥락이 없습니다.
Zeplin의 버전 관리는 Git 워크플로우에서 영감을 받은 구조입니다. Git이란 개발자들이 코드 변경 이력을 체계적으로 관리하는 분산 버전 관리 시스템입니다. Zeplin은 이 개념을 디자인에 적용해, 디자이너가 "지금 이 버전이 개발 준비 완료"라고 의도적으로 퍼블리시(publish)할 때만 버전이 생성됩니다.
특히 버전이 파일 단위가 아닌 스크린 단위로 쌓인다는 점이 핵심입니다. 스크린(Screen)이란 Zeplin 안에서 Figma의 개별 프레임이 하나의 독립 단위로 관리되는 화면 개체를 말합니다. 개발자 입장에서 특정 화면 하나의 변경 이력만 따로 볼 수 있으니 노이즈가 없습니다.
버전 Diff 기능도 실제로 써보면 가치가 명확합니다. 버전 Diff란 두 버전 사이의 레이어 추가·변경·삭제를 시각적으로 표시해주는 기능으로, 숫자 하나가 바뀌어도 하이라이트로 잡아줍니다. 제 경험상 이건 소규모 변경사항이 스펙 리뷰에서 누락되는 상황을 막는 데 실질적으로 효과가 있었습니다. 개발자가 "이거 바뀐 거 몰랐어요"라는 말을 하지 않게 됩니다.
Style Guide와 컬러 토큰, 실제로 어떻게 썼나
대기업 SaaS 핸드오프 외주에서 제가 가장 먼저 한 작업은 컬러 토큰을 Zeplin의 Style Guide 페이지에 묶는 일이었습니다. 컬러 토큰(Color Token)이란 디자인 시스템에서 색상 값을 하드코딩된 HEX 코드가 아닌 의미 있는 변수명으로 추상화한 것입니다. 예를 들어 #1A73E8 대신 primary-button-background 같은 이름으로 관리하는 방식입니다.
이게 Zeplin에서 특히 강력한 이유가 있습니다. 개발자가 스펙 화면을 클릭하면 컬러 값이 아니라 토큰 변수명 자체가 나옵니다. 디자이너와 개발자 사이에서 "이 색이 뭐죠?" 라는 대화가 사라집니다. 실제로 이 세팅 하나로 컬러 변환 실수가 완전히 없어졌습니다.
디자인 시스템(Design System)이란 디자인 원칙, 컴포넌트, 토큰을 하나의 체계로 정리한 것으로, 여러 팀이 일관된 UI를 만들기 위한 공통 기반을 말합니다. Figma Dev Mode도 최근 변수 연동을 강화하고 있지만, 토큰 자동 추출 정확도 면에서는 Zeplin이 아직 한 발 앞서 있다고 봅니다. 디자인 시스템을 운영 중인 팀이라면 이 부분이 Zeplin을 유지하는 핵심 이유가 될 수 있습니다.
국내 SaaS 시장에서 디자인 시스템 도입 비율은 꾸준히 증가하는 추세입니다. 특히 대기업과 금융권에서 일관된 UI/UX 품질 관리를 위한 디자인 시스템 구축이 확대되고 있습니다(출처: 한국디자인진흥원).
팀 규모별 의사결정 매트릭스
Zeplin 도입을 결정할 때 단순히 "Figma Dev Mode랑 뭐가 달라요?"라고 묻는 것은 질문이 잘못된 겁니다. 제 경험상 이건 좀 다릅니다. 도구 비교가 아니라 팀 조건에 따른 매트릭스가 필요합니다.
실제로 도입 여부를 판단할 때 확인해야 할 조건은 다음과 같습니다.
- 디자이너 + 개발자 합산 인원이 21명 초과인가
- 디자인 시스템(컬러·텍스트 토큰 포함)을 운영 중인가
- Jira, Storybook 등 외부 도구와의 스펙 연동이 필요한가
- 스크린 단위 버전 히스토리와 변경 알림이 반드시 필요한가
- 라이선스 비용 대비 커뮤니케이션 절감 효과를 수치로 증명할 수 있는가
이 다섯 가지 중 세 가지 이상 해당하면 Zeplin의 ROI가 나옵니다. 그 이하라면 Figma Dev Mode로 시작하는 게 현실적입니다. 한국 대기업에서 Zeplin이 아직 표준 핸드오프 도구로 살아남아 있는 이유는 바로 이 조건들을 충족하는 팀이 많기 때문입니다.
Figma Dev Mode는 2023년 출시 이후 꾸준히 기능을 확장하고 있으며, 현재는 무료로 기본 스펙 확인 기능을 제공하고 있습니다(출처: Figma 공식 블로그). 그러나 조직 규모가 크고 디자인 시스템 운영이 본격화된 팀에서는 Zeplin의 구조화된 워크플로우가 여전히 유효한 선택입니다.
결국 Zeplin을 어떻게 쓸 것인가보다 "우리 팀에 필요한가"를 먼저 묻는 게 맞습니다. 저도 처음엔 도구에 매몰됐다가, 데이터를 모으면서 판단 기준이 바뀌었습니다. 팀 규모와 디자인 시스템 성숙도, 그리고 라이선스 BEP 계산 이 세 가지를 먼저 챙기시면 의사결정이 훨씬 빠르고 명확해질 것입니다.