완성된 화면을 처음 받아 든 날, 시안과 나란히 놓고 보면 어딘가 미묘하게 어긋나 있습니다. 버튼을 감싼 여백이 두 픽셀쯤 좁고, 로딩이 도는 동안 화면은 텅 비어버리고, 에러가 났을 때 무슨 일이 일어나는지는 아무도 정해두지 않았습니다. 분명 시안은 완성되어 있었는데, 구현된 제품은 그 시안이 아닙니다.
이 어긋남은 디자이너의 실력이나 개발자의 성의 문제가 아닙니다. 디자인 핸드오프를 전달로 이해하는 순간 생기는 필연적인 균열입니다. 결론부터 말씀드리면, 핸드오프는 파일을 넘기는 행위가 아니라 서로 다른 두 직군이 같은 의도를 공유하는 과정입니다. 던지고 끝내는 순간, 의도는 번역 과정에서 새어 나가고 제품은 조금씩 갈라집니다. 오늘은 왜 핸드오프라는 순간이 품질을 깎는지, 그리고 그것을 어떻게 다시 설계할 수 있는지 이야기해보려 합니다.
핸드오프가 전달이 되는 순간 제품이 갈라진다
디자인 핸드오프가 무너지는 자리는 늘 비슷합니다. 시안은 모든 것이 잘 풀린 화면, 이른바 해피 패스 한 장만 보여줍니다. 그런데 실제 제품은 한 장의 그림이 아니라 시간 속에서 움직이는 동사입니다. 데이터를 기다리는 순간, 입력이 비어 있는 순간, 네트워크가 끊긴 순간이 모두 화면을 갖습니다. 이 상태들이 시안에 없으면, 개발자는 빈칸을 자기 판단으로 채울 수밖에 없습니다.
피그마가 정리한 개발자 핸드오프 가이드는 가장 흔히 누락되는 요소로 바로 이 상태 문서화를 꼽습니다. 명세는 치수와 색과 간격을 전달하지만, 인터랙션의 동작과 상태의 전환, 그리고 그 디자인이 왜 그렇게 결정되었는지는 좀처럼 함께 건너가지 않습니다. 빠진 정보가 많을수록 구현은 시안에서 멀어지고, 그 거리를 메우려 재작업 사이클이 늘어납니다.
| 핸드오프에서 보통 전달되는 것 | 거의 빠지는 것 |
|---|---|
| 치수, 색상, 간격, 폰트 | 로딩·에러·빈 화면·비활성·포커스 상태 |
| 화면 한 장의 최종 모습 | 상태와 상태 사이의 전환과 동작 |
| 무엇을 그렸는가 | 왜 그렇게 결정했는가 |
| 정적인 레이아웃 | 화면 크기와 입력에 따른 반응 |
여기서 놓치기 쉬운 포인트가 있습니다. 시안은 명사의 목록이고, 제품은 그 명사들이 움직이는 문장입니다. 명사만 건네고 문법을 건네지 않으면, 같은 단어로도 전혀 다른 문장이 만들어집니다.
좋은 핸드오프는 번역이 아니라 공유다
그렇다면 핸드오프의 목표를 다시 물어야 합니다. 디자이너의 머릿속을 개발자에게 그대로 복사하는 것일까요. 그것은 불가능합니다. 두 직군은 세상을 다른 언어로 봅니다. 디자이너는 비례와 흐름으로, 개발자는 구조와 상태로 화면을 읽습니다.
과학기술학자 수전 리 스타와 제임스 그리스머는 1989년 서로 다른 전문 집단이 어떻게 협력하는가를 연구하며 경계 객체라는 개념을 제시했습니다. 경계 객체는 각 집단의 필요에 맞게 유연하게 해석되면서도, 집단을 가로질러 공통의 정체성을 유지하는 대상입니다. 핵심은 이것입니다. 협력에 반드시 완전한 합의가 필요한 것은 아니며, 모두가 같은 객체를 가리킬 수 있으면 서로 다르게 이해하면서도 함께 일할 수 있다는 것입니다. 디자인 파일과 토큰, 동작하는 프로토타입은 모두 디자이너와 개발자 사이의 경계 객체입니다. 좋은 핸드오프는 의도를 완벽히 번역하는 일이 아니라, 두 직군이 함께 가리킬 수 있는 객체를 잘 만드는 일입니다.
심리언어학은 이 통찰에 다른 결을 더해줍니다. 허버트 클라크는 소통이 공통 기반 위에서만 성립한다고 설명합니다. 대화하는 사람들이 공유한다고 서로 믿는 지식의 토대가 있어야 말이 통한다는 것이지요. 핸드오프가 어긋나는 이유가 여기 있습니다. 디자이너는 이 버튼이 눌리면 0.2초간 부드럽게 눌리는 느낌이 당연하다고 여기지만, 그 당연함은 개발자와 공유된 적이 없습니다. 명시되지 않은 의도는 공통 기반에 오르지 못하고, 전달의 마지막 단계에서 조용히 사라집니다.
같은 도면을 세 사람이 다르게 읽었다
에이전시에서 한 공간 프로젝트를 맡았던 시절의 일입니다. 도면대로 진행했는데 현장에 가보니 실제 치수가 도면과 맞지 않았습니다. 더 곤란했던 것은 그다음이었습니다. 디자이너인 저와 기획 담당자, 그리고 시공팀이 같은 도면을 펴놓고도 서로 다른 그림을 머릿속에 그리고 있었던 것입니다. 말로는 분명 합의된 듯했지만, 각자가 가리키는 곳이 미묘하게 달랐습니다. 공통 기반이 있다고 믿었을 뿐, 실제로는 없었던 것이지요.
문제를 푼 것은 더 자세한 도면이 아니었습니다. 저는 공간을 3D 모델로 세워, 모두가 같은 입체를 보면서 같은 지점을 손가락으로 가리킬 수 있게 했습니다. 시공팀은 시공의 관점에서, 기획자는 동선의 관점에서, 저는 비례의 관점에서 그 모델을 각자 다르게 읽었지만, 가리키는 대상은 하나였습니다. 그 3D 모델이 바로 경계 객체였습니다. 세 직군의 서로 다른 언어를 하나의 대상 위에서 만나게 한 것입니다.
디지털 제품에서 이 객체의 역할을 하는 것이 디자인 토큰과 Dev Mode 명세, 그리고 동작하는 프로토타입입니다. 특히 토큰은 강력합니다. 색상이나 간격 같은 결정에 이름을 붙여, 디자인 도구와 코드가 동일한 이름을 부르게 만들기 때문입니다. 개발자가 화면에서 hex 값 대신 의미가 담긴 토큰 이름을 본다면, 옮겨 적는 과정에서 생기던 오류가 사라집니다. 이것은 디자인 시스템이 컴포넌트의 모음이 아니라 공유된 언어라는 사실의 가장 실용적인 증거이기도 합니다.
토큰과 조기 참여로 핸드오프를 다시 설계하라
핸드오프를 전달이 아니라 공유로 바꾸기 위해, 내일부터 점검할 수 있는 것들을 정리해보겠습니다.
- 해피 패스 말고 모든 상태를 그립니다. 로딩, 에러, 빈 화면, 비활성, 포커스까지 그려야 개발자가 빈칸을 추측하지 않습니다. 포커스와 상태 명세는 접근성이 배려가 아니라 설계인 이유와 정확히 같은 자리에 있습니다.
- 무엇이 아니라 왜를 함께 남깁니다. 결정의 이유와 제약을 적어두면, 구현 중 변수가 생겼을 때 개발자가 같은 의도 위에서 판단할 수 있습니다.
- 토큰으로 같은 이름을 공유합니다. 원시 토큰에서 의미 토큰, 컴포넌트 토큰으로 이어지는 구조를 디자인과 코드가 함께 쓰면, 디자인이 바뀌어도 이름이 어긋나지 않습니다.
- 개발자를 와이어프레임 단계부터 부릅니다. 가장 비싼 재작업은 시안을 다 그린 뒤 구현이 어렵다는 말을 듣는 순간 발생합니다. 아이디어가 말랑할 때 기술적 제약을 미리 듣는 편이 훨씬 쌉니다.
| 핸드오프를 순간으로 다룰 때 | 과정으로 다룰 때 |
|---|---|
| 시안 완성 후 한 번에 전달 | 와이어프레임부터 함께 검토 |
| 디자이너가 그리고 개발자가 받는다 | 같은 객체를 함께 들여다본다 |
| 어긋나면 구현 단계에서 발견 | 어긋남을 미리 좁혀둔다 |
이렇게 보면 디자이너의 일은 화면을 그려 넘기는 데서 끝나지 않습니다. 오히려 디자이너가 화면을 그리지 않는다고 말할 만큼, 협업의 구조를 설계하는 일이 점점 더 큰 비중을 차지합니다.
결론
핸드오프는 파일을 던지고 돌아서는 선이 아니라, 두 직군이 같은 객체 앞에 나란히 서는 다리입니다. 의도는 전달되는 순간 일부가 사라지지만, 공유되는 객체 위에서는 함께 다듬어질 수 있습니다. 그래서 좋은 디자인은 넘겨지는 것이 아니라 공유되는 것입니다.
그러니 다음에 시안을 넘기기 전에, 우리가 진짜로 건네야 하는 것이 무엇인지 한 번 더 물어보면 좋겠습니다. 개발자에게 필요한 것은 더 정교한 그림 한 장이 아니라, 함께 가리킬 수 있는 하나의 대상일지도 모릅니다. 여러분의 팀은 지금, 같은 것을 보고 있나요?
참고 자료
- Susan Leigh Star & James R. Griesemer, “Institutional Ecology, ‘Translations’ and Boundary Objects,” Social Studies of Science, 19(3), 1989
- Herbert H. Clark & Susan E. Brennan, “Grounding in Communication,” in Perspectives on Socially Shared Cognition, APA, 1991
- Figma, “Guide to Developer Handoff” (Figma Best Practices)
- Figma, “The Designer’s Handbook for Developer Handoff” (Figma Blog)
- W3C Design Tokens Community Group, “Design Tokens Format Module”
