상태 목업이 먼저다 — 피그마가 바이브 프로토타입을 치운 이유

피그마가 직접 말했다. 바이브로 돌린 프로토타입은 개발·PM 정렬에 안 쓰였다. 상태 목업이 먼저다.

2026년 9월 1일, 피그마 프로덕트 디자이너 로기 킹이 Behind the build: Generative plugins and shaders at Figma에 그렇게 적었습니다. 바이브로 짠 프로토는 디자이너가 자기 가정을 검증하고 뒤집는 데 훌륭했어요. 개발자·PM·이해관계자에게 넘기는 참조로는 도움이 되지 않았습니다. 그래서 순서를 바꿨습니다. 피그마에 정적 목업을 올려 가능한 상태를 전부 펼친 뒤, 그다음 돌아가는 코드 프로토로 옮겼어요.

같은 날부터 생성형 플러그인과 셰이더를 다루는 폭이 늘었고, 만든 것을 커뮤니티에 올리거나 Org·Enterprise면 조직 안에만 둘 수 있다고 했습니다. 피그마 MCP 서버는 디자인 결정을 코드를 짜는 도구로 가져간다고 했고, 엔지니어는 get_design_context를 기대한다고 적었어요. 이 글은 그 기능을 안내하지 않습니다. 움직이는 화면부터 붙이다가 미팅이 멈추는 일, 그 순서를 고치는 정찰 기록입니다. 시점은 2026년 9월입니다.

움직이는 화면과 상태 목업은 하는 일이 다릅니다

같은 「프로토」라는 말을 써도, 남는 게 다릅니다. 표로 접으면 이렇습니다.

로기 킹은 성공 화면 한 장이 아니라, 터질 수 있는 상태를 한눈에 보이게 하라고 했습니다. 미팅은 그 펼침에서 갑니다. 채팅으로 돌린 화면은 만든 사람 머릿속에만 상태가 있어요. 목업은 그 상태를 밖에 꺼내, 팀이 같은 실패를 보게 합니다. 잘 되는 한 경로만 움직이면, 옆자리는 아직 같은 서비스를 본 게 아닙니다.

실사용 — 상태를 먼저 펼치는 법

갈림은 도구 취향이 아닙니다. 다음에 그 화면을 누가 보느냐입니다.

디자이너에게만 통했던 프로토

바이브로 돌린 화면은 눌러 보면 그럴듯합니다. 만든 사람은 「이 버튼 다음은 이거」를 이미 알고 있어요. 옆자리 PM은 모릅니다. 빈 목록을 어디로 보냈는지, 결제가 실패하면 어디를 보여 주는지를 프로토가 숨깁니다. 피그마 팀이 겪은 일과 같은 구조입니다. 검증은 됐고, 참조는 안 됐습니다.

상태를 펼쳐야 미팅이 간다

정적 목업은 느리게 보이지만, 질문이 바뀝니다. 「예쁜가요」가 「빈 화면은 어디로 가나요」로 바뀌어요. 로딩, 권한 없음, 만료, 재시도. 이 네 장이 없으면 개발은 성공 경로만 짭니다. 정렬은 그 네 장에서 납니다. 움직이는 홈보다, 멈춘 네 장이 미팅을 끝까지 데려갑니다.

셀프는 HTML, 의뢰는 피그마

바이브 코더에게 정적 상태의 자리는 클라비 HTML 화면설계입니다. 화면 한 장이 HTML 한 장이고, 빈 목록과 에러를 화면으로 남길 수 있어요. 브랜드 라이브러리와 하이파이 시안은 그다음입니다. 그 갈림은 HTML 다음에 Figma에 있습니다. 클라비는 피그마를 대체하지 않습니다. 밸류랩스 의뢰의 산출 중심은 피그마예요. 셀프 HTML과 의뢰 피그마를 같은 산출로 부르면 미팅이 어긋납니다.

그다음이 돌아가는 코드

상태를 맞춘 뒤에야 코드 프로토가 일을 합니다. 피그마는 그 순서로 엔지니어 시간을 아꼈다고 적었어요. 구현을 기다렸다가 디자인으로 되돌리고, 다시 구현하는 왕복을 줄인 겁니다. 코드는 맞춰진 목업을 검증하는 자리입니다. 목업을 대체하는 자리가 아니에요. MCP로 get_design_context를 읽는 일도, 맞춰진 상태가 있어야 의미가 있습니다. 상태 없이 에이전트만 열면 성공 화면만 코드가 됩니다.

고르는 기준 세 가지

기준은 세 개면 충분합니다. 순서대로 물어 보세요.

1. 지금 보여 줄 사람이 나인가, 팀인가 — 나 혼자 가정을 깨면 바이브 프로토입니다. 개발·PM이 보면 상태 목업이에요.
2. 성공 경로만 있나, 빈칸·에러가 있나 — 한 경로만 움직이면 아직 참조가 아닙니다. 터질 화면이 펼쳐져 있어야 해요.
3. 다음에 붙일 것이 코드인가, 브랜드인가 — 구현이면 상태 HTML 또는 피그마 목업 다음이 코드입니다. 하이파이·라이브러리면 의뢰 피그마로 이어 가세요.

앞의 두 개가 「팀」과 「펼침」이면, 움직이는 프로토는 미뤄도 됩니다. 세 번째가 브랜드면 HTML만으로 끝내지 마세요.

되는 것 vs 안 되는 것

• 되는 것. 상태를 정적 목업으로 먼저 펼친다. 셀프는 클라비 HTML로 빈칸·에러를 남긴다. 의뢰는 피그마로 받는다. 정렬이 끝난 뒤에 돌아가는 코드를 붙인다.
• 안 되는 것. 바이브 프로토를 개발 참조라고 가정한다. 클라비가 피그마를 대체한다고 가정한다. 성공 화면만 돌리고 상태를 채팅에 맡긴다. 셀프 HTML과 의뢰 피그마를 같은 산출로 부른다.

실패는 보통 순서를 뒤집는 쪽에서 납니다. 움직이는 홈만 있고 빈 목록이 없으면, 미팅은 다시 처음으로 돌아가요.

자주 묻는 질문

바이브 프로토를 팀에 보여 주면 안 되나요

보여 줄 수는 있습니다. 다만 피그마가 겪은 대로, 그건 디자이너의 검증 도구에 가깝습니다. 개발·PM이 「이 화면이 전부인가」를 물을 때 답이 되어 주지 않아요. 팀에 넘길 때는 상태를 펼친 목업이 먼저입니다.

상태 목업이면 클라비 HTML만으로 끝나나요

흐름과 상태를 고정하는 자리라면 HTML이면 됩니다. 브랜드·하이파이·팀 라이브러리면 피그마가 필요합니다. 클라비는 그 자리를 대체하지 않아요. 셀프는 HTML이 상태의 자리이고, 의뢰는 피그마가 산출의 자리입니다.

지금 상태부터 펼치려면 기획 인터뷰로 가면 됩니다. HTML과 피그마의 순서는 HTML 다음에 Figma에 있습니다. 이야기는 상담으로 이어집니다. 이 글은 성공담 모음이 아니라 정찰 기록입니다. 아이디어 한 줄이면 시작됩니다.