12장. 핸드오프 번들이란 무엇인가

디자인 파일 하나로는 왜 늘 부족했을까

디자인이 끝났다고 해서 개발이 바로 시작되지는 않는다. 오히려 진짜 어려움은 그다음에 나타난다. 화면은 예쁘게 나왔는데, 엔지니어는 묻는다. 이 버튼은 기존 컴포넌트를 쓰는 걸까, 새로 만드는 걸까? 이 간격은 16일까 20일까? 로딩 상태는 어디 있지? 빈 화면은? 에러 메시지는? 문구는 최종안이 맞나?

바로 이 지점에서 디자인과 개발 사이의 '번역 손실'이 생긴다. 디자이너나 PM의 머릿속에는 분명한 의도가 있었는데, 그 의도가 개발 단계로 넘어가면서 조금씩 사라지거나 바뀌는 것이다. 화면 캡처, 피그마 링크, 슬랙 메시지, 회의 메모, 노션 문서가 이리저리 흩어져 있으면 더 심해진다.

Claude Design이 말하는 핸드오프 번들은 이 문제를 줄이기 위한 묶음이다. 단순히 "여기 시안입니다"라고 넘기는 것이 아니라, 이 화면을 어떻게 이해하고 어떻게 구현해야 하는지까지 함께 포장해 Claude Code로 전달하는 패키지라고 생각하면 된다.

핸드오프 번들은 디자인 결과물을 개발 친화적인 형태로 정리한 꾸러미다. 화면 모양만 전달하는 것이 아니라, 화면을 구성하는 부품과 규칙, 문구와 동작 원리까지 한 번에 묶는다. 그래서 Claude Code는 단순히 예쁜 이미지를 보고 추측하는 대신, 비교적 분명한 맥락을 가진 상태에서 코드를 만들 수 있다.

핸드오프 번들의 핵심 개념

핸드오프 번들의 중심 아이디어는 간단하다. "보이는 것"만 넘기지 말고, "왜 이렇게 만들었는지"와 "어떻게 구현해야 하는지"까지 함께 넘기자는 것이다.

전통적인 핸드오프에서는 보통 시각 결과물이 중심이었다. 예를 들어 메인 화면 한 장, 상세 화면 한 장, 간단한 주석 몇 개가 전부인 경우가 많았다. 하지만 실제 제품은 정지된 이미지가 아니라 상태를 바꾸고, 데이터를 받고, 예외 상황을 처리하고, 브랜드 규칙을 지키며 움직이는 시스템이다.

핸드오프 번들은 이 시스템적 성격을 드러내기 위해 다음 요소들을 함께 묶는다.

• 컴포넌트

• 디자인 토큰

• 카피

• 인터랙션 노트

이 네 가지는 각각 따로 보면 익숙하지만, 한 번에 묶일 때 비로소 힘을 발휘한다. 화면은 컴포넌트로 분해되고, 컴포넌트는 토큰 규칙을 따르며, 문구는 확정된 카피를 사용하고, 동작은 인터랙션 노트에 따라 구현된다. 즉, 모양·규칙·의미·행동이 하나의 묶음으로 정렬되는 것이다.

번들 안에는 무엇이 들어 있을까

컴포넌트: 화면을 부품 단위로 쪼개는 지도

컴포넌트는 화면을 이루는 재사용 가능한 조각이다. 버튼, 카드, 탭, 모달, 입력창 같은 것들이 대표적이다. 핸드오프 번들에서 컴포넌트 정보가 중요한 이유는, 개발이 화면 전체를 한 번에 만드는 일이 아니라 부품을 조립하는 일이기 때문이다.

예를 들어 결제 페이지가 있다고 해보자. 겉으로 보면 하나의 페이지지만 실제로는 상단 요약 카드, 결제 수단 선택 리스트, 쿠폰 입력 폼, 약관 체크박스, 결제 버튼, 에러 배너 같은 여러 블록으로 나뉜다. 핸드오프 번들은 이 블록들 중 무엇이 기존 디자인 시스템의 컴포넌트인지, 무엇이 이번 기능을 위해 새로 정의된 패턴인지 구분해준다.

이 차이는 엔지니어에게 아주 중요하다. 기존 컴포넌트라면 빠르게 조립할 수 있고, 새 패턴이라면 어느 수준까지 범용화할지 먼저 판단해야 한다. 이 정보가 없으면 개발자는 화면을 보고 추측으로 구조를 짜게 된다. 그러면 겉보기는 비슷해도 내부 구현은 제각각이 되기 쉽다.

핸드오프 번들에서의 컴포넌트 정보는 보통 이런 질문에 답한다.

• 이 요소는 어떤 컴포넌트인가?

• 기존 컴포넌트를 재사용하는가, 새로 만드는가?

• 어떤 variants, 즉 상태별 변형이 필요한가?

• 어떤 props, 즉 설정값이 필요한가?

• 반응형 화면에서 어떻게 변하는가?

쉽게 말해, "이 화면을 어떤 레고 블록으로 조립해야 하는가"를 알려주는 설명서다.

디자인 토큰: 보기 좋음을 규칙으로 바꾸는 언어

디자인 토큰은 색상, 간격, 글꼴 크기, 모서리 반경, 그림자 같은 시각 규칙을 이름 붙여 관리하는 단위다. 예를 들어 primary-blue, spacing-16, radius-medium 같은 식이다.

디자인만 볼 때는 이 값들이 그냥 스타일처럼 보일 수 있다. 하지만 개발 단계에서는 토큰이 있어야 일관성이 생긴다. 버튼마다 파란색이 조금씩 다르고, 카드마다 여백이 어긋나고, 제목마다 폰트 크기가 미묘하게 달라지는 문제를 막아주기 때문이다.

핸드오프 번들에 토큰이 포함되면 Claude Code는 단순히 "비슷한 파란색"을 만드는 대신, 팀이 이미 쓰는 색상 규칙과 간격 규칙을 따라가려 한다. 이것이 중요한 이유는 결과물이 화면 한 장에서 끝나지 않기 때문이다. 나중에 같은 제품 안에서 다른 기능을 붙일 때도 같은 언어를 쓰게 된다.

토큰은 디자인의 취향을 코드의 규칙으로 바꾸는 번역기다. 디자이너가 느끼는 "이 브랜드다운 느낌"을 엔지니어가 재현 가능한 값으로 옮겨 주는 셈이다.

카피: 문구도 구현 사양이다

많은 팀이 카피를 마지막에 바꾸는 장식처럼 취급한다. 하지만 실제 제품에서는 문구가 레이아웃, 상태 처리, 심지어 사용자 행동까지 바꾼다. 버튼 라벨 하나가 길어지면 너비가 달라지고, 빈 상태 문구가 바뀌면 정보 구조가 달라질 수 있다.

핸드오프 번들에 카피가 포함된다는 것은, 화면에 들어갈 문장을 임시 텍스트가 아니라 구현 기준으로 다룬다는 뜻이다. 제목, 본문, 버튼 라벨, 오류 메시지, 토스트 알림, 빈 상태 안내문까지 확정 또는 후보 상태로 정리해 넘길 수 있다.

이렇게 하면 개발자가 더미 텍스트를 넣고 나중에 다시 바꾸는 일을 줄일 수 있다. 무엇보다 문구가 인터랙션과 연결된다. 예를 들어 버튼이 비활성화될 때 어떤 설명을 보여줄지, 업로드 실패 시 어떤 톤으로 안내할지 같은 문제는 UI와 카피가 함께 결정해야 자연스럽다.

즉, 카피는 "나중에 붙이는 문장"이 아니라 사용 경험을 구성하는 부품이다.

인터랙션 노트: 정지 화면에 움직임을 부여하는 지시서

정적인 시안은 한 순간만 보여준다. 하지만 실제 제품은 계속 상태를 바꾼다. 클릭 전과 후, 로딩 중, 성공, 실패, 빈 상태, 권한 없음, 모바일 접힘 상태까지 모두 설계해야 한다.

인터랙션 노트는 이런 동작 규칙을 적어 둔 기록이다. 사용자가 버튼을 누르면 무엇이 열리는지, 몇 초 동안 로딩 스켈레톤을 보여주는지, 입력 오류가 나면 어떤 메시지를 어디에 띄우는지, 저장 후 어떤 화면으로 이동하는지 같은 내용이 들어간다.

이 정보가 빠지면 엔지니어는 정지 화면 사이를 자기 판단으로 연결해야 한다. 물론 경험 많은 개발자는 꽤 잘 추측할 수 있다. 하지만 추측이 늘 디자이너의 의도와 같지는 않다. 핸드오프 번들은 바로 이 추측의 영역을 줄여 준다.

한마디로 말하면, 인터랙션 노트는 "이 디자인이 어떻게 살아 움직여야 하는가"를 설명하는 부분이다.

왜 '묶음'이 중요한가

여기서 중요한 것은 각각의 자료가 존재하느냐가 아니라, 그것들이 하나의 번들로 연결되어 있느냐이다.

컴포넌트 문서는 따로 있고, 카피는 스프레드시트에 있고, 인터랙션은 회의 녹음에 있고, 토큰은 개발 저장소 어딘가에 있다면 이론상 정보는 다 있는 셈이다. 그런데도 프로젝트는 자주 꼬인다. 왜냐하면 사람과 AI 모두 흩어진 정보를 모아 해석하는 과정에서 실수하기 때문이다.

핸드오프 번들은 흩어진 조각들을 한 덩어리로 묶어 "이번 작업의 기준은 이것"이라고 정해 준다. 그러면 Claude Code는 디자인을 보고 짐작하는 것이 아니라, 패키지화된 맥락을 읽고 구현 방향을 잡을 수 있다.

이때 번들은 일종의 압축 파일처럼 작동한다. 화면의 표면 아래 숨어 있던 의사결정이 함께 들어 있기 때문이다. 겉모습, 구조, 규칙, 상태 변화가 분리되지 않고 같은 문맥 안에 있으니, 개발 단계에서 빠지는 정보가 줄어든다.

번역 손실이 줄어드는 메커니즘

핸드오프 번들의 가장 큰 가치는 "좋은 정리"가 아니다. 더 정확히 말하면, 의도가 사라지지 않게 만드는 전달 방식이다.

전통적인 협업에서 번역 손실은 보통 세 군데에서 발생한다.

첫째, 추측이 개입할 때다. 정적 화면만 있으면 개발자는 보이지 않는 상태를 상상해야 한다.

둘째, 기준이 여러 개일 때다. 피그마와 문서와 슬랙 대화가 서로 조금씩 다르면 무엇이 최신인지 모호해진다.

셋째, 표현 언어가 다를 때다. 디자이너는 시각적 패턴으로 생각하고, 엔지니어는 컴포넌트 구조와 상태 기계처럼 생각한다. 같은 의도도 서로 다른 언어로 말하면 어긋나기 쉽다.

핸드오프 번들은 이 세 문제를 동시에 다룬다.

우선, 추측의 범위를 줄인다. 컴포넌트 정의와 상태 설명이 있으니 빈칸이 적어진다. 다음으로, 기준을 하나로 묶는다. 작업 단위마다 "이번 구현의 공식 패키지"가 생기니 최신본이 무엇인지 덜 헷갈린다. 마지막으로, 디자인 언어를 구현 언어에 가깝게 바꿔 준다. 버튼의 모양만 보는 것이 아니라 버튼 컴포넌트의 variant와 토큰, 카피와 상태를 함께 전달하니 엔지니어의 사고 방식과 더 잘 맞는다.

Claude Code가 이 번들을 받으면 단순히 시각적 유사성을 흉내 내는 수준을 넘어서게 된다. 어떤 컴포넌트를 재사용해야 하는지, 어떤 토큰을 우선 써야 하는지, 어떤 카피가 확정 문안인지, 어떤 상호작용을 구현해야 하는지 판단 재료가 더 많아진다. 즉, 출력물의 품질이 올라가는 이유는 모델이 갑자기 마법처럼 똑똑해져서가 아니라, 들어오는 입력의 구조와 밀도가 좋아지기 때문이다.

핸드오프 번들은 어떤 흐름으로 만들어질까

실무에서는 보통 다음과 같은 흐름으로 생각하면 이해하기 쉽다.

1단계: 디자인 결과물을 화면이 아니라 시스템으로 본다

먼저 Claude Design에서 만든 결과물을 단순한 목업으로 보지 않는다. 이 화면이 어떤 컴포넌트 조합으로 이루어졌는지, 브랜드 규칙은 무엇인지, 어떤 상태 전환이 필요한지를 함께 파악한다.

이 관점 전환이 중요하다. 그래야 "예쁜 시안"이 "구현 가능한 설계"로 바뀐다.

2단계: 구현에 필요한 정보만 골라 구조화한다

모든 메모를 다 넘기는 것은 오히려 방해가 된다. 핸드오프 번들은 구현과 직접 연결되는 정보 위주로 정리된다. 예를 들어 시안 A와 B를 비교하던 초기 아이디어보다, 최종안에서 실제로 채택된 컴포넌트와 토큰, 카피, 상태 규칙이 더 중요하다.

즉, 번들은 회의록이 아니라 실행 패키지다.

3단계: Claude Code가 읽기 좋은 형태로 넘긴다

핸드오프 번들의 목적은 사람이 보기 좋게 정리하는 데서 끝나지 않는다. Claude Code가 바로 이어받아 구현 흐름을 시작할 수 있어야 한다. 그래서 정보는 가급적 명확한 이름과 관계를 가진다. 어떤 요소가 어떤 컴포넌트인지, 어디서 재사용되는지, 어떤 상태가 있는지가 드러나야 한다.

이때 중요한 것은 완벽한 형식미가 아니라 해석 가능성이다. 모호한 미사여구보다 분명한 연결이 더 도움이 된다.

예시로 보는 핸드오프 번들

가상의 예시를 하나 보자. 팀이 "AI 회의 요약" 기능의 결과 화면을 만들었다고 해보자.

디자인 시안만 넘기면 개발자는 대략 이런 것만 본다. 상단에 제목, 오른쪽에 공유 버튼, 아래에 요약 카드, 액션 버튼, 타임라인이 있네. 여기서부터는 대부분 추측이다.

하지만 핸드오프 번들로 넘기면 상황이 달라진다.

상단 제목 영역은 기존 페이지 헤더 컴포넌트를 사용한다. 공유 버튼은 secondary button variant다. 요약 카드는 새 컴포넌트이지만 내부의 태그와 아이콘 배지는 기존 시스템 컴포넌트를 조합한다. 액션 버튼 영역은 데스크톱에서는 가로 정렬, 모바일에서는 세로 스택으로 전환한다. 타임라인의 시간 라벨은 text-secondary 토큰을 사용하고, 현재 재생 중인 구간은 accent 색으로 강조한다. "다시 생성" 버튼을 누르면 로딩 상태가 2단계로 보이는데, 첫 단계는 스피너, 두 번째는 부분 결과 스트리밍이다. 실패 시에는 카드 상단에 인라인 에러를 띄우고, 기존 생성 결과는 유지한다.

이제 Claude Code는 단순히 모양을 흉내 내는 것이 아니라 구조를 가진 구현 계획을 세울 수 있다. 페이지를 어떤 컴포넌트 트리로 나눌지, 어떤 토큰을 불러올지, 상태 관리를 어디에 둘지 더 선명해진다.

핸드오프 번들의 진짜 효용은 바로 여기 있다. 화면을 '보는' 데서 끝나는 것이 아니라, 화면을 '만드는 방식'까지 함께 전달한다.

엔지니어에게 좋은 번들과 나쁜 번들

좋은 핸드오프 번들은 정보가 많기만 한 번들이 아니다. 필요한 정보를 바로 꺼내 쓸 수 있는 번들이다.

좋은 번들은 구현 우선순위가 드러난다. 어디까지가 MVP인지, 어떤 부분은 추후 개선인지 구분되어 있다. 또한 재사용과 신규 개발의 경계가 보인다. 기존 컴포넌트를 건드리지 않고 조합만 하면 되는지, 아예 새 패턴을 추가해야 하는지 알 수 있다. 상태도 빠지지 않는다. 정상 화면만 있고 에러나 로딩이 없으면 번들은 반쪽짜리다.

반대로 나쁜 번들은 화려하지만 모호하다. 화면은 멋진데 이름이 없고, 규칙은 있는데 적용 범위가 불분명하고, 카피는 있는데 확정본인지 아닌지 알 수 없다. 인터랙션 설명도 "부드럽게 전환" 같은 말로 끝나면 구현자는 결국 다시 묻게 된다. 그 순간 핸드오프 번들의 가치가 줄어든다.

핵심은 예술 작품처럼 감탄하게 만드는 문서가 아니라, 질문을 줄여 주는 패키지라는 점이다.

핸드오프 번들이 팀 문화를 바꾸는 이유

핸드오프 번들은 단지 산출물 포맷의 변화가 아니다. 팀이 디자인과 개발의 관계를 보는 방식 자체를 바꾼다.

예전에는 디자인이 먼저 끝나고, 개발이 그다음에 받아 구현하는 일방향 흐름이 강했다. 그래서 핸드오프는 '인수인계'에 가까웠다. 하지만 Claude Design과 Claude Code를 함께 쓰는 흐름에서는 설계와 구현이 더 촘촘히 연결된다. 디자인은 이미 구현을 염두에 두고 구조화되고, 구현은 단순 복제가 아니라 설계 의도를 이어받는 작업이 된다.

이런 환경에서는 디자이너, PM, 엔지니어가 서로의 언어를 조금 더 이해하게 된다. 디자이너는 컴포넌트와 상태를 더 명확히 정의하게 되고, 엔지니어는 시각적 의도가 왜 중요한지 더 구체적으로 파악한다. PM은 기능 범위를 문구와 상태 수준까지 관리할 수 있다. 결국 핸드오프 번들은 파일이 아니라 공통 언어에 가깝다.

이 장의 핵심 정리

핸드오프 번들은 디자인 결과물을 Claude Code가 바로 이어받을 수 있도록 정리한 구현 패키지다. 여기에는 보통 컴포넌트, 디자인 토큰, 카피, 인터랙션 노트가 함께 들어간다.

이 묶음이 중요한 이유는 디자인과 개발 사이에서 자주 생기는 맥락 손실을 줄여 주기 때문이다. 화면만 넘기면 생길 수밖에 없는 추측을 줄이고, 흩어진 기준을 하나로 모으며, 시각 언어를 구현 언어에 더 가깝게 바꿔 준다.

결국 핸드오프 번들의 목표는 단순하다. "이 화면처럼 만들어 주세요"에서 멈추지 않고, "이 의도와 이 규칙대로 구현해 주세요"까지 한 번에 전달하는 것. 바로 그 차이가, 아이디어가 실제 제품이 되는 과정의 마찰을 크게 줄여 준다.

다음 장에서는 이 개념이 실제 기업 사례에서 어떻게 효과를 냈는지 살펴볼 것이다. 좋은 번들이 실전에서 어떤 속도 차이와 품질 차이를 만드는지 보면, 왜 이 방식이 단순한 유행어가 아닌지 더 분명해질 것이다.