소프트웨어 팀은 수십 년 동안 툴체인에 결정론을 구축해 왔습니다. 패키지 관리자를 위한 잠금 파일. 컨테이너를 위한 고정된 베이스 이미지. 컴파일된 아티팩트를 위한 재현 가능한 빌드. 원칙은 잘 알려져 있습니다: 동일한 입력은 항상, 어느 컴퓨터에서나, 언제나 동일한 출력을 생성해야 합니다.

디자인 핸드오프는 이 원칙을 적용한 적이 없습니다. 기본적으로 근본적으로 인간적이고 따라서 비결정론적인 프로세스였습니다. 디자이너가 디자인을 개발자에게 설명합니다. 개발자가 해석합니다. 해석은 사람에 따라, 날에 따라, Zeplin 댓글이 얼마나 명확하게 작성되었는지에 따라 다릅니다. 재현할 수 없습니다. 테스트할 수 없습니다. diff를 비교할 수 없습니다.

AI 코딩 에이전트의 세계에서 비결정론적 핸드오프는 이제 일급 엔지니어링 문제입니다. figmascope는 고정된 휴대용 컨텍스트 번들로 이를 해결합니다.

현재 툴링이 에이전트에게 비결정론적인 이유

Zeplin과 Avocode는 Figma에서 추출한 수치를 제공합니다 — 레이어 치수, 색상 값, 폰트 크기. 하지만 기계 판독 가능한 아티팩트가 아닌 탐색 가능한 UI로 제공합니다. Zeplin을 가리키는 에이전트는 UI를 탐색하여 값을 찾아야 합니다. 취약하고, 속도 제한이 있으며, 주석이 어떻게 작성되었는지에 의존합니다.

Figma Dev Mode는 더 나아갑니다: 디자인에서 인라인으로 생성된 코드 스니펫을 제공합니다. 하지만 스니펫은 상태가 없습니다 — 요청 시 재생성되며 버전이 없습니다. 체크인할 번들이 없습니다. diff를 비교할 파일이 없습니다. 디자이너가 디자인을 업데이트하면 Dev Mode 뷰가 조용히 업데이트됩니다. 마지막으로 내보낸 것 대비 기본 디자인이 언제 변경되었는지 알 수 없습니다.

스크린샷은 최악의 경우입니다: 순수 픽셀 데이터, 파싱하기 완전히 비결정론적이며, 매번 다른 구조 추론을 생성합니다.

라이브 MCP 연결 — 에이전트에게 Figma 파일에 대한 실시간 API 접근을 제공하는 도구 — 은 정의상 비결정론적입니다. 에이전트가 읽는 동안 파일이 변경됩니다. 오전 9시의 실행과 오후 2시의 실행은 다른 입력을 봅니다. 소스가 변경되었기 때문에 오전 9시 실행을 재현할 수 없습니다.

에이전트는 확률적 시스템입니다. 비결정론적 입력을 제공하면 단순히 분산이 생기는 것이 아니라 시스템을 테스트할 수 없게 됩니다. 잘못된 출력이 모델 때문인지, 프롬프트 때문인지, 아니면 두 실행 사이에 누군가가 레이어를 이동했기 때문인지 알 수 없습니다.

컴파일 단위로서의 번들

figmascope 내보내기를 위한 올바른 정신 모델은 컴파일 아티팩트입니다. 컴파일러가 소스 코드를 가져와 결정론적 바이너리를 생성하듯 — 동일한 소스, 동일한 플래그, 동일한 바이너리 — figmascope는 Figma 파일 상태를 가져와 결정론적 번들을 생성합니다: 동일한 파일 상태, 항상 동일한 번들.

번들은 고정된 스냅샷입니다. 특정 버전의 디자인을 캡처하고 모든 관련 속성을 직렬화합니다: 공간 레이아웃, 컴포넌트 식별, 토큰 바인딩, 문자열 내용, 계층 구조. 내보내기 후 번들은 불변입니다. Figma 파일이 변경되어도 번들은 변경되지 않습니다. 변경 사항을 통합하려면 재내보내기하여 새 번들을 얻습니다.

이것이 컴파일 단위 모델입니다. 디자인 파일이 소스입니다. 번들이 아티팩트입니다. 에이전트는 소스가 아닌 아티팩트를 소비합니다.

결정론적 핸드오프의 네 가지 속성

스냅샷 가능. 핸드오프 아티팩트는 특정 시점을 나타내야 합니다. "Figma 파일의 현재 상태"가 아니라 명명된, 버전이 있는 내보내기. figmascope 번들에는 내보내기 타임스탬프와 포함된 내용의 지문이 있는 _meta.json이 포함됩니다. 번들은 라이브 뷰가 아닌 스냅샷입니다.

휴대 가능. 아티팩트는 자급자족해야 합니다. 외부 서비스, 라이브 API, 또는 로그인된 세션에 의존성이 없어야 합니다. figmascope 번들은 일반 파일의 ZIP입니다 — JSON, Markdown, PNG. 복사하고, 이메일로 보내고, git에 체크인하고, PR에 첨부하고, 설치 없이 주니어 개발자나 코딩 에이전트에게 전달할 수 있습니다.

검사 가능. 결정론적 아티팩트는 내용을 확인할 수 없으면 쓸모가 없습니다. 번들의 모든 파일은 사람이 읽을 수 있습니다. CONTEXT.md는 Markdown입니다. tokens.json은 W3C 유사 구조입니다. 화면별 IR은 명확한 필드 이름을 가진 JSON입니다. 엔지니어가 번들을 열고 에이전트에게 정확히 무엇이 전달되었는지 감사할 수 있습니다. 이것은 "스크린샷을 붙여넣고 코드를 얻었다"와 질적으로 다릅니다.

재현 가능. 동일한 Figma 파일 상태에서 두 번의 별도 내보내기는 기능적으로 동등한 번들을 생성해야 합니다. 바이트 동일하지는 않지만(타임스탬프가 다름), 의미론적으로 동일: 동일한 노드 구조, 동일한 토큰 값, 동일한 컴포넌트 인벤토리. 변경되지 않은 파일에서 두 번 내보내 번들이 의미론적으로 다르다면 문제가 있는 것입니다. 이 속성을 통해 내보내기 파이프라인을 검증하고 추출기 자체의 회귀를 포착할 수 있습니다.

실제에서의 작동 방식

디자이너가 스프린트의 화면을 완성합니다. 번들을 내보냅니다. 번들이 티켓과 함께 레포지토리에 커밋됩니다 — 또는 Jira 이슈에 첨부되거나, 워크플로에 따라 공유 드라이브에 저장됩니다. 이 시점에서 핸드오프 아티팩트가 고정됩니다. 에이전트(또는 개발자)는 라이브 Figma 파일이 아닌 번들로 작업합니다.

구현 중 디자이너가 세 개의 화면을 업데이트합니다. 문제 없습니다: 개발자의 작업 번들은 변경되지 않습니다. 새 화면은 새 내보내기를 받습니다. 이제 두 개의 번들이 있고 diff를 비교할 수 있습니다: 개발자가 시작한 디자인과 현재 디자인 사이에 무엇이 변경되었는지. 이것이 스크린샷 기반 또는 라이브 연결 기반 워크플로에서는 불가능한 변경 가시성입니다.

멀티 에이전트 워크플로에서 — 한 에이전트가 컴포넌트 라이브러리를 구축하고, 다른 에이전트가 화면 레이아웃을 구축하고, 세 번째가 테스트를 작성 — 각 에이전트는 동일한 번들을 진실의 원천으로 받습니다. 모두 동일한 고정된 디자인 상태로 작업하고 있습니다. 출력이 구성 가능한 것은 입력이 공유되고 고정되어 있기 때문입니다. 이것이 실제로 신뢰할 수 있는 멀티 에이전트 UI 생성의 전제 조건입니다.

번들 diff 비교

번들이 일반 파일이기 때문에 코드처럼 diff를 비교합니다. 동일한 파일의 두 Figma 버전에 걸친 두 내보내기는 정확히 무엇이 변경되었는지 알려주는 JSON diff를 제공합니다:

이것은 현재의 어떤 핸드오프 툴링에도 존재하지 않는 디자인 변경 가시성입니다. Figma에는 자체 버전 히스토리가 있지만 시각적이고 디자이너 중심입니다. 번들 diff는 구조화되고 개발자 중심입니다: 자동화된 테스트를 구동하고, 변경 로그를 업데이트하거나, CI 워크플로를 트리거할 수 있는 기계 판독 가능한 변경 데이터.

디자인 핸드오프를 위한 CI/CD

핸드오프가 결정론적이면 CI/CD는 자연스럽게 따릅니다. 번들에 대해 실행하는 테스트를 작성할 수 있습니다: "이 화면은 Button/Primary 컴포넌트를 포함해야 한다," "이 토큰은 바인딩되어야 하고 하드코딩된 값이 아니어야 한다," "이 문자열은 stringRef 키를 가져야 한다." 이것은 구조화된 데이터에 대한 정적 분석 검사입니다. 밀리초 단위로 실행됩니다. 파이프라인에서 실행됩니다.

또한 번들에 대해 코드 생성 에이전트의 출력을 검증할 수 있습니다. 에이전트가 토큰을 사용했나요 아니면 리터럴을 하드코딩했나요? 반복 컴포넌트의 올바른 수의 인스턴스를 생성했나요? 올바른 간격 값을 사용했나요? 이 질문들은 진실의 원천이 PNG가 아닌 구조화된 파일일 때 답할 수 있습니다.

MCP 비교

Figma에 대한 MCP 스타일 라이브 연결이 주목받고 있습니다. 매력은 명백합니다: 에이전트가 항상 최신 디자인을 보고, 내보내기 단계 없이, 수동 번들 관리 없이. 하지만 라이브 연결은 편의를 위해 결정론을 교환합니다 — AI 에이전트에게는 나쁜 교환입니다.

라이브 연결은 에이전트의 컨텍스트가 실행 시간에 의존한다는 것을 의미합니다. 디자이너가 낮에 작업한 경우 오전 9시 실행과 오후 2시 실행은 다른 데이터를 봅니다. 이전 실행을 재현할 수 없습니다. 고정된 입력에 대해 테스트할 수 없습니다. 에이전트에게 무엇이 전달되었는지 감사할 수 없습니다. 생성된 코드가 잘못되었다면 "모델이 잘못된 추론을 했다"와 "에이전트 아래에서 디자인이 변경되었다"를 구별할 수 없습니다.

올바른 모델은: 최신성이 중요한 디자인 탐색 및 반복에는 라이브 연결을, 재현성이 중요한 핸드오프 및 생성에는 결정론적 번들을 사용하는 것입니다. 경쟁하는 것이 아닙니다 — 워크플로의 다른 지점에서 작동합니다.

주니어 개발자에게 핸드오프

번들을 AI 에이전트에게 좋게 만드는 동일한 속성이 코드베이스에 새로 온 인간 개발자에게도 좋게 만듭니다. 번들을 받은 주니어 개발자는 다음을 갖게 됩니다: CONTEXT.md의 완전한 명세, tokens.json의 모든 토큰 값, 속성이 있는 모든 컴포넌트 목록, 식별이 있는 모든 문자열. Figma 파일에 있을 필요가 없습니다. Figma 계정이 필요 없습니다. 어떤 화면이 권위있는 것인지 알 필요가 없습니다.

번들은 완전하고 자급자족하는 작업 지시입니다. 에이전트가 받는 것과 동일합니다. 유일한 차이는 인간이 읽고 에이전트가 프로그래밍 방식으로 처리한다는 것입니다 — 하지만 아티팩트는 동일합니다.

그 통합 — 동일한 아티팩트, 인간 또는 에이전트 소비자 — 이 핵심입니다. 번들이 핸드오프의 단위입니다. 그 외 모든 것은 구현 세부 사항입니다.

Claude Code, Cursor, 또는 Aider를 통해 실제 결정론적 핸드오프를 확인하세요. 모두 동일한 figmascope 내보내기에서 시작합니다.