디자인 도구와 개발자 핸드오프

디자인 핸드오프란

디자인 핸드오프(design handoff)는 디자이너가 만든 화면을 개발자가 구현할 수 있게 치수·색·글꼴·애셋·동작 정보를 넘기는 과정이다. 핸드오프의 품질이 낮으면 개발자는 추측으로 구현하고, 디자이너는 QA에서 같은 지적을 반복한다.

시기	방식	문제
과거	이미지 시안, 잘라 낸 애셋, 워드 명세서를 메일로 전달. 디자인 원본은 비싼 설치형 도구라 개발자가 못 연다	최신본이 어디 있는지 모르고, 피드백이 메일·회의록에 흩어진다
과도기	Sketch 같은 설치형 도구 + Zeplin 같은 별도 핸드오프 도구	디자이너가 핸드오프 도구로 따로 업로드해야 한다
지금	브라우저 기반 공유 파일(Figma). 개발자도 같은 파일을 열고 Dev Mode로 구현 정보를 본다	파일 정리 상태가 곧 핸드오프 품질이다

개발자가 Figma 파일에서 보는 것

하고 싶은 일	방법
파일 구조 파악	파일은 여러 페이지로, 페이지마다 캔버스 하나. 디자인 시스템·아이콘·화면을 페이지로 나눠 두는 경우가 많다
전체 스타일 확인	아무것도 선택하지 않으면 오른쪽 패널에 색·글꼴·효과 스타일과 변수(variables) 가 보인다. 이 값이 CSS 변수와 디자인 토큰의 출처다
중첩 레이어 선택	클릭은 최상위만 선택한다. Cmd/Ctrl+클릭으로 깊은 레이어를 바로 고르거나, 더블클릭으로 한 단계씩 들어간다
거리 측정	요소를 선택하고 Alt/Option을 누른 채 다른 요소에 올리면 간격이 빨간 선과 px로 나온다
CSS 확인	Dev Mode의 Inspect 패널에서 CSS·iOS·Android 코드 스니펫을 본다. 위치값은 자동 생성이라 그대로 복사하지 말고 참고만 한다(아래 「Figma 디자인을 코드로 옮길 때」)
애셋 추출	Export 설정에서 배율(1x·2x·3x)과 형식(PNG·JPG·SVG·PDF)을 고른다. 레이어 이름에 /를 쓰면 폴더로 묶여 나온다
동작 확인	Prototype 탭의 파란 화살표가 화면 흐름이다. 각 연결은 트리거·액션·전환(예: 탭 → 스마트 애니메이트, 300ms ease-out)으로 구성되고, 이 정보는 Inspect 코드에 나오지 않으니 따로 확인한다
구현 상태	"개발 준비 완료(Ready for dev)" 표시와 변경 비교로 무엇이 바뀌었는지 본다
질문	C로 댓글을 달고 @멘션해야 알림이 간다. 댓글은 파일에 접근하는 모두에게 보인다

자주 쓰는 단축키: Shift+1(전체 보기), Shift+2(선택 확대), Space+드래그(이동), Ctrl+Shift+?(단축키 목록).

컴포넌트를 코드와 직접 잇는 Code Connect, AI 에이전트가 디자인 정보를 읽는 MCP 서버처럼 디자인과 코드 사이의 거리를 줄이는 기능이 계속 늘고 있다. 디자인 토큰을 코드 패키지로 배포하는 구조는 디자인 시스템: 구성, 도입, 구축과 배포에 있다.

Figma 디자인을 코드로 옮길 때

Inspect의 CSS를 붙여 넣기만 하면 시안과 똑같아질 것 같지만, 실제로는 부모와 자식의 관계를 정하는 position과 display 를 거의 매번 고쳐야 한다.

위치: absolute를 흐름으로 바꾼다

Auto Layout이 없는 프레임은 Inspect에서 프레임이 position: relative, 그 안의 요소가 모두 position: absolute와 좌표로 나온다. 캔버스에서는 요소끼리 영향을 주지 않으니 문제없지만, 브라우저에서는 글이 길어지거나 화면이 좁아지면 겹치고 깨진다. 코드로 옮길 때는 겹쳐 놓는 요소(배지, 닫기 버튼)만 absolute로 남기고 나머지는 문서 흐름과 Flexbox·Grid로 다시 배치한다(position).

Auto Layout은 Flexbox다

Auto Layout	CSS
방향: 세로 / 가로 / 줄바꿈	flex-direction: column / row / flex-wrap: wrap
정렬(9칸 격자)	주축은 justify-content, 교차축은 align-items
간격: 고정값 / Auto	gap / justify-content: space-between
패딩	padding
크기: Hug / Fill / Fixed	내용 크기(fit-content) / flex: 1·align-self: stretch / 고정 width·height
Grid 흐름	CSS Grid

방향이 바뀌면 같은 "가운데 정렬"이 다른 속성이 된다. 가로 방향에서 세로 위치는 align-items가 맡지만, 세로 방향에서는 justify-content가 맡는다. 캔버스에서는 직관적이지만 코드에서 가장 헷갈리는 지점이다(Float와 Flexbox).

디자이너가 Auto Layout으로 시안을 만들면 개발자는 구조를 그대로 옮기면 되고, 반응형 동작에 대한 대화도 줄어든다. 코드를 직접 만져 보고 싶은 디자이너는 설치 없이 브라우저에서 돌려 보는 온라인 편집기로 시작할 수 있다(디자이너는 어떻게 코드를 배우나).

디자인 시스템을 도구에 담는 원칙

원칙	내용
라이브러리를 나눈다	모두가 쓰는 핵심(브랜드·아이콘·기본 컴포넌트)과 제품·도메인별 라이브러리를 분리한다
스타일·변수에 묶는다	색·글꼴·효과를 값으로 직접 넣지 말고 스타일·변수로 연결하고, 각 값을 문서화한다. 변수의 모드로 라이트·다크 테마를 바꾼다
컴포넌트는 적게, 확장은 명확히	채운 버튼·외곽선 버튼을 따로 만들지 않고 하나의 컴포넌트를 variants와 속성으로 바꾼다. 대신 어떻게 바꿔 쓰는지 예시를 함께 둔다
이름이 구조다	페이지(폼) → 프레임(인풋) → 컴포넌트 순으로 찾을 수 있게 이름 짓는다

도구를 바꿀 때

도구 이전(예: Sketch → Figma)의 원칙은 어느 도구에나 통한다.

• 이전 자체가 비용이다. 라이브러리 재구축, 문서 갱신, 팀 교육이 실무와 동시에 든다.
• 가져오기(import)는 아이콘 같은 단순 요소에 쓰고, 복잡한 컴포넌트는 새 도구의 방식으로 다시 만든다. 옛 도구의 한계를 우회하던 복잡성까지 옮겨 오지 않기 위해서다.
• 핵심 라이브러리부터 옮기고, 짧은 데모 영상으로 팀을 온보딩한다.
• 두 도구를 병행하지 않는다. 새 프로젝트는 새 도구, 진행 중인 프로젝트만 옛 도구로 끝낸다는 식으로 경계를 분명히 한다.

실제 조건으로 디자인한다

• 여러 화면 크기를 한 캔버스에서. 모바일·태블릿·데스크톱 프레임을 나란히 두고 같은 컴포넌트를 쓰면 한 번 고친 것이 모든 크기에 반영된다. 각 크기를 따로 그리는 대신 Auto Layout과 제약 조건(constraints)으로 늘고 줄어드는 규칙을 디자인한다.
• 실제 데이터로 채운다. "Lorem ipsum"과 같은 길이의 이름만 넣으면 긴 제목, 빈 값, 큰 숫자 같은 극단 상황을 놓친다. JSON이나 스프레드시트 데이터를 레이어에 채우는 플러그인으로 실제에 가까운 콘텐츠를 넣는다.
• 기기에서 미리 본다. Figma 모바일 앱의 미러링으로 실제 화면 크기와 밀도에서 확인한다.

고해상도 화면 대응

픽셀 밀도가 높은 화면(과거 애플이 "레티나"라 부른 것)이 기본이 되면서 원칙이 정해졌다.

• 아이콘·로고·UI 도형은 벡터(SVG)로 만들고 내보낸다. 해상도와 무관하게 선명하다.
• 비트맵이 필요하면 1x·2x·3x로 내보내고, 웹에서는 srcset으로 화면 밀도에 맞게 고르게 한다.
• 2x로 키울 때 그림자·테두리 값을 기계적으로 두 배로 하지 말고 결과를 눈으로 확인한다. 1x 기준에서 홀수 픽셀은 반 픽셀 번짐을 만들 수 있다.

정리

• 핸드오프는 파일 하나를 함께 보는 일이 됐다. 파일 정리가 곧 명세다.
• 개발자는 스타일·변수, 측정, 애셋, 프로토타입 흐름, 댓글 다섯 가지만 익히면 된다. 자동 생성 CSS는 참고용이다.
• 디자인 시스템은 라이브러리 분리, 변수, 적은 컴포넌트와 명확한 확장 예시로 담는다.
• 도구 이전은 비용을 계산하고, 다시 만들고, 한 번에 옮긴다.
• 시안은 실제 데이터와 여러 화면 크기로 검증한다. 와이어프레임을 클릭되게 만드는 기준은 와이어프레임, 목업, 프로토타입에 있다.

관련 노트: 디자인 시스템: 구성, 도입, 구축과 배포, 디자이너는 어떻게 코드를 배우나, 반응형 디자인과 다국어 타이포그래피, 새 서비스 개발 프로젝트 진행 순서, 디자인 단계의 접근성, 와이어프레임, 목업, 프로토타입