디자인 외주가 끝나고 나서 개발이 시작되면, 거의 항상 같은 일이 벌어집니다. 화면은 시안대로 나왔는데 어딘가 다릅니다. 간격이 미묘하게 어긋나고, 같은 회색이 화면마다 다른 값으로 들어가 있습니다.
디자이너를 탓할 일도, 개발자를 탓할 일도 아닙니다. 넘긴 것이 시안뿐이었기 때문입니다.
30초 요약
- •시안은 결과물이지 규칙이 아닙니다. 규칙을 넘겨야 구현이 흔들리지 않습니다.
- •디자인 토큰은 색과 간격에 이름을 붙이는 일입니다. 값이 아니라 이름으로 주고받습니다.
- •Figma Variables 와 Dev Mode가 그 이름을 개발까지 그대로 가져갑니다.
- •상태 정의가 빠지면 개발자가 임의로 만듭니다. 비어 있을 때, 로딩, 오류, 권한 없음.
- •계약 전에 산출물 목록을 문장으로 합의하세요. 끝나고 요구하면 받을 수 없습니다.
시안만 받으면 왜 흔들리는가
시안은 특정 화면의 특정 순간을 그린 그림입니다. 거기에는 이런 정보가 없습니다.
- •이 회색이 다른 화면에서도 같은 회색이어야 하는가
- •이 간격이 우연인가 규칙인가
- •버튼이 눌린 동안, 비활성일 때는 어떻게 되는가
- •데이터가 없을 때 이 자리에 무엇이 오는가
개발자는 이 빈칸을 채워야 화면을 만들 수 있습니다. 물어볼 사람이 없으면 각자 합리적인 판단을 내리고, 그 판단이 화면마다 달라집니다.
시안은 결과물이고, 넘겨야 할 것은 그 결과를 만든 규칙입니다.
디자인 토큰이란 무엇인가
어렵게 들리지만 하는 일은 단순합니다. 값에 이름을 붙이는 것입니다.
#6B7280 → color.text.secondary
16px → space.4
8px → radius.md
이름으로 주고받으면 두 가지가 달라집니다.
일관성이 자동으로 지켜집니다
개발자가 회색을 고를 때 스포이트로 찍지 않습니다. 이름을 부르면 항상 같은 값이 나옵니다. 비슷한 회색 일곱 개가 생기는 일이 사라집니다.
바꿀 때 한 번만 바꿉니다
브랜드 색이 바뀌면 토큰 하나를 고칩니다. 시안으로 넘겼다면 화면 수만큼 찾아다녀야 합니다. 다크 모드를 나중에 붙일 수 있느냐도 여기서 갈립니다.
Figma 에서 실제로 무엇을 받아야 하나
Variables 로 정리된 토큰
Figma Variables 는 색, 숫자, 문자열을 이름으로 관리하는 기능입니다. 여기에 정리되어 있어야 개발이 그대로 가져갈 수 있습니다. 스타일(Styles)만 쓰고 있다면 색은 되지만 간격과 반경은 빠집니다.
최소한 이 네 묶음은 있어야 합니다.
- •색 배경, 텍스트, 테두리, 상태(성공·경고·오류)
- •간격 4 또는 8의 배수로 정리된 단계
- •타이포 크기, 굵기, 행간의 조합에 이름을 붙인 것
- •반경과 그림자 카드, 버튼, 모달에 쓰는 값
Dev Mode 접근 권한
Dev Mode 는 개발자가 시안에서 값과 토큰 이름을 바로 확인하는 화면입니다. 링크만 받고 권한이 없으면 소용이 없습니다. 계약할 때 개발자 좌석을 누가 부담하는지도 함께 정해두세요.
컴포넌트와 상태
버튼 하나에도 기본, 마우스 오버, 눌림, 비활성, 로딩 다섯 가지가 있습니다. 시안에 기본 상태만 그려져 있으면 나머지 넷은 개발자가 만듭니다.
Figma 의 Variants 로 상태를 묶어 두었는지 확인하세요. 화면 한쪽에 상태별 예시를 늘어놓은 것만으로도 충분합니다.
자주 빠지는 것 네 가지
저희가 인수받아 보면 이 넷이 거의 언제나 비어 있습니다.
- •빈 상태 목록에 데이터가 하나도 없을 때 무엇을 보여주는가
- •로딩 스켈레톤인가 스피너인가, 어느 범위에 거는가
- •오류 문구는 어디에 뜨고, 사용자는 무엇을 하면 되는가
- •권한 없음 아예 안 보이는가, 보이되 막히는가
정상 화면만 그려두면 실제 서비스에서 마주치는 화면의 상당수가 설계 없이 만들어집니다. 그리고 그 화면들이 제품의 인상을 결정합니다.
Code Connect 는 언제 필요한가
Figma 컴포넌트와 코드의 컴포넌트를 연결해, Dev Mode 에서 실제 코드 조각을 보여주는 기능입니다.
좋은 기능이지만 모든 프로젝트에 필요하지는 않습니다. 코드 컴포넌트가 이미 정리되어 있고, 디자인과 개발이 계속 같이 굴러가는 조직에서 값어치가 납니다.
첫 구축 단계라면 토큰과 상태 정의가 먼저입니다. 연결할 코드가 아직 없는데 연결부터 만들 수는 없습니다.
계약 전에 문장으로 합의하세요
가장 실질적인 조언입니다. 산출물을 말로 합의하면 끝나고 나서 해석이 갈립니다. 목록으로 적어 계약서에 넣으세요.
Figma Variables 로 정리된 토큰 4종
Dev Mode 접근 권한과 기간
주요 컴포넌트의 상태별 정의
빈 상태, 로딩, 오류, 권한 없음 화면
반응형 기준점과 각 지점의 동작
한 줄씩 읽어보면 어렵지 않은 요구입니다. 다만 적어두지 않으면 대개 포함되지 않습니다. 무엇을 남길지에 대한 판단은 B2B SaaS UI/UX 외주 편에서 더 다뤘습니다.
자주 묻는 질문
디자이너가 토큰 작업을 추가 비용으로 청구하는데 정당한가요?
정당합니다. 시안을 그리는 것과 규칙을 세우는 것은 다른 일이고 시간이 더 듭니다. 다만 그 비용은 구현 단계에서 회수됩니다. 개발자가 값을 찾아다니고 되묻는 시간이 사라지기 때문입니다.
우리는 개발자가 한 명인데도 필요한가요?
한 명이어도 필요합니다. 토큰이 없으면 그 한 명의 머릿속에만 규칙이 남습니다. 그 사람이 떠나면 규칙도 함께 사라집니다.
이미 시안만 받고 개발이 끝났습니다
지금이라도 값을 모아 이름을 붙일 수 있습니다. 코드에서 쓰이는 색과 간격을 뽑아 정리하는 편이, 다음 기능을 추가할 때마다 같은 고민을 반복하는 것보다 빠릅니다.
정리하면
디자인 외주에서 받아야 할 것은 시안이 아니라 시안을 만든 규칙입니다.
Figma Variables 로 정리된 토큰, Dev Mode 접근 권한, 컴포넌트의 상태 정의, 그리고 빈 상태와 오류 화면. 이 넷을 계약서에 적어두면 구현 단계에서 겪는 일의 절반이 사라집니다.
함께 읽으면 좋은 글
제품 구조부터 점검이 필요하시면 상담 신청을 남겨주세요. 범위와 예상 기간을 먼저 정리해 드립니다. 진행 방식과 포함 범위는 요금제 페이지에서 확인하실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 제품 단계와 조직 구성에 따라 다를 수 있어 결과를 보장하지 않습니다. 우리 제품에 맞는 개선 방향이 궁금하시다면 편하게 상담 신청해주세요.
