AI 핸드오프의 핵심은 스펙 자동 생성이 아니라 변경을 추적하는 일입니다

핸드오프 문서가 반복되는 이유는 디자이너가 설명을 못해서가 아닙니다. 시안이 바뀔 때마다 레이어, 간격, 상태, 반응형 동작을 다시 확인해야 하기 때문입니다. Figma MCP처럼 에이전트가 디자인 파일의 정보를 도구를 통해 읽을 수 있는 환경은 이 반복을 줄일 가능성이 있습니다.

하지만 “Figma를 읽었으니 개발 스펙이 완성됐다”고 말하면 위험합니다. MCP가 제공하는 것은 파일과 도구에 접근하는 통로이지, 제품의 모든 요구사항을 자동으로 아는 능력이 아닙니다. 데이터 상태, 권한, 오류, 네트워크, 성능, 정책은 화면만 읽어서 복원할 수 없습니다.

1. 먼저 읽을 범위를 고정합니다

에이전트에게 파일 전체를 던지는 대신 대상 프레임과 목적을 고정해야 합니다. 어떤 화면을 구현할지, 사용자가 어느 상태에 있는지, 이번 변경에서 포함하지 않는 범위가 무엇인지 먼저 적습니다.

“이 화면의 스펙을 만들어줘”보다 다음 요청이 낫습니다.

이 프레임의 결제 완료 상태를 기준으로,
기존 Button과 Modal 컴포넌트만 사용해
레이어 구조·간격 토큰·상태·모바일 차이를 표로 정리해줘.
Figma에서 확인할 수 없는 데이터·권한·오류 조건은 추측하지 말고 질문으로 분리해줘.

좋은 프롬프트는 결과물을 길게 만드는 것이 아니라, 에이전트가 추측하면 안 되는 영역을 표시합니다.

2. 추출보다 먼저 상태를 묻습니다

핸드오프에서 가장 자주 빠지는 것은 정상 화면이 아니라 상태입니다. hover·active·disabled뿐 아니라 빈 상태, 로딩, 실패, 권한 없음, 긴 텍스트, 작은 화면을 확인해야 합니다.

Figma 파일에 상태가 정리돼 있지 않다면 에이전트는 가장 그럴듯한 상태를 채웁니다. 이때 자동 생성된 문서는 깔끔하지만 제품에는 없는 가정을 포함할 수 있습니다. 따라서 문서에는 confirmed, inferred, missing 같은 상태를 붙이는 편이 안전합니다.

3. 문서는 diff로 갱신합니다

시안 버전이 올라갈 때마다 전체 스펙을 새로 만들면 변경의 의미가 사라집니다. 이전 버전과 비교해 컴포넌트, 토큰, 콘텐츠, 상태, 반응형 동작 중 무엇이 달라졌는지를 먼저 보여줘야 합니다.

변경 문서는 최소한 다음을 포함할 수 있습니다.

• 변경된 프레임과 컴포넌트
• 추가·삭제·변경된 상태
• 개발자가 확인해야 할 질문
• 디자인 파일에서 확인하지 못한 가정
• 접근성·콘텐츠·성능 검수 항목

이렇게 하면 AI는 문서 작성기가 아니라 변경을 발견하는 보조자가 됩니다.

좋은 점

반복적인 값 추출과 변경 요약을 줄이고, 디자이너와 개발자가 같은 파일을 보며 이야기할 수 있습니다. 특히 큰 파일에서 특정 프레임의 구조를 빠르게 설명하는 데 유용합니다.

한계

시각 파일에는 비즈니스 규칙과 런타임 상태가 모두 들어 있지 않습니다. MCP 연결이 안정적이어도 접근 권한, 파일 위생, 컴포넌트 이름, 문서의 최신성이 나쁘면 결과도 불안정합니다.

남는 긴장

핸드오프를 자동화할수록 문서는 빨리 생기지만, 팀이 문서를 읽고 판단하는 시간은 별도로 필요합니다. 속도가 빨라진 것이 검수 비용까지 줄었다는 뜻은 아닙니다. AI가 만든 설명이 늘어날수록 무엇을 읽지 않아도 되는지 정하는 편집이 중요해집니다.

질문

• 이번 변경에서 Figma가 실제로 알고 있는 것과 모르는 것은 무엇인가요?
• 정상 상태 외에 어떤 실패·권한·접근성 상태가 필요한가요?
• 자동 생성 문서에 추측과 확인된 사실이 구분돼 있나요?
• 변경 diff를 제품·코드·정책의 변경과 연결할 수 있나요?

AI 핸드오프의 목표는 문서를 한 줄도 쓰지 않는 것이 아닙니다. 반복해서 옮겨 적는 시간을 줄이고, 사람은 더 중요한 미확정 상태와 제품 판단에 집중하는 것입니다.