Figma 퍼블리싱 파이프라인 10. v6 → v7: IR 엔진과 인프라의 통합

2026년 4월 12일·7 min read·10 / 12

figma pipeline v7 ir diff-engine llm-reduction

v7 — 두 파이프라인의 통합 (2026-04-12)

"v5의 뇌 + v6의 몸"

v7의 핵심 아이디어는 단순하다.

데이터 수집/세션 관리/스코프 강제: v6 방식 유지
비교 엔진(IR + 8-type diff + 6-tier 매칭): v5 방식 복원
LLM은 딱 1개 Phase만: 코드 생성(P8)에만 집중

데이터 수집 (v6)          IR 비교 엔진 (v5)         생성 + 검증
P0 → P0.5 → P1 → P2  →  P3 → P4 → P5 → P6 → P7  →  P8 → P9
collect  scope  assets    d-ir  c-ir  norm  map  diff   generate  validate

토큰 비교

버전	LLM Phase 수	예상 토큰
v5	3개 (9, 10, 11)	~3,500
v6	2개 (2, 3)	~2,200
v7	1개 (P8)	~1,500

어떻게 3개를 1개로 줄였을까? v5에서는 "diff 리포트 작성(LLM)", "설계서 작성(LLM)", "코드 수정(LLM)" 순서였다. v7에서는 Python이 diff.json까지 완전히 만들어두고, LLM은 그 결과를 읽고 코드만 수정한다. 설계서도 따로 안 쓴다. diff에 있는 내용이 이미 "무엇을 고쳐야 하는가"를 설명하고 있으니까.

P8 구조 복원 우선 원칙

v7에서 가장 고민한 부분이 재사용 판단이었다.

기존 코드에 비슷한 컴포넌트가 있으면 재사용하는 게 좋다. 하지만 막상 해보면 "이미 있는 컴포넌트를 억지로 재사용하느라 Figma 구조를 왜곡"하는 경우가 생겼다. 예를 들어 Figma에는 테이블이 있는데, 기존 코드에 Tabs 컴포넌트가 비슷한 점수로 매칭되는 식으로.

v7의 해결책은 순서를 명확히 하는 것이다.

먼저 Figma skeleton을 복원한다 (구조 우선)
그 다음에 재사용 여부를 판단한다 (재사용은 나중)
candidate score가 0.80 미만이면 무조건 primitive fallback

P8 실행 순서:
1. diff.json에서 missing_node/structure_mismatch 확인
2. Figma skeleton 먼저 복원
3. p8_structure_plan.json에서 stable/reconstruct 판단
4. reconstruct block은 재사용 금지
5. 그 다음에 component → recipe → slot-recipe → primitive 순서로 재사용 검토

Early Visual Artifacts

사용자가 섹션을 선택하면(P0.5), 코드가 생성되기 훨씬 전인 P0a에서 Figma screenshot과 초기 visual skeleton을 먼저 만들어둔다. P8에서 코드를 생성할 때 "시각 기준점"으로 활용한다. "코드가 아직 없어도, 내가 최종적으로 만들어야 할 게 이렇게 생긴 거구나"를 미리 확보해두는 것.

Project Probe — 컴포넌트 인벤토리

v7에서 새로 추가된 개념이다. 퍼블리싱 시작 전에 현재 앱에 어떤 shared component, recipe, slot-recipe가 있는지 스캔해서 인벤토리를 만들어둔다. P8이 재사용 판단을 할 때 이 인벤토리를 참고한다.

기존엔 LLM이 "이런 게 있을 것 같은데..."라고 추측했다면, v7에서는 Python이 미리 파일 시스템을 스캔해서 확실한 목록을 건네준다.

세션 재개 (v6에서 이어받음)

v6에서 만든 세션 인프라를 그대로 쓴다. Phase 중간에 끊겨도 --session 옵션으로 재개. --skip-llm으로 P8까지만 돌려서 diff.json만 확인할 수도 있다.

버전 계보 정리

v4.0  단일 API 호출, LLM이 직접 비교 (부정확)
  │
v4.1  API 2단계 분리 (경량 목록 → 선택 후 풀다운)
  │
v4.1  패턴 하드코딩 제거 (TABLE/CARD/FORM → LLM 판단)
refactor
  │
v4.2  재귀 탐색 + 설계-코드 검증 단계 추가
  │
v5    IR 기반 비교 엔진 (Design IR + Code IR + Diff Engine)
  ├──────────────────────────┐
v5.4                        v6  세션 + 스코프 + 안정성
diff 폭증 해결              │   (비교 엔진은 단순화)
(6440→939)                  │
                            v7  v5 IR 엔진 + v6 인프라 통합
                                LLM 1개 Phase (~1,500 토큰)
 
publish  Fresh Publish (diff 포기, 항상 처음부터 새로 구현)

느낀 것들

파이프라인을 만들면서 반복적으로 느낀 게 있다.

"LLM에게 판단을 맡기면 맡길수록 결과가 불안정해진다."

v4 때는 Figma JSON과 코드를 통째로 LLM에게 던지면서 "비교해줘"라고 했다. 틀렸다. v5에서 비교는 Python이 하고 LLM은 설명과 생성만 하도록 바꿨더니 정확도가 올라갔다. v7에서 LLM Phase를 3개→1개로 줄이면서 또 한 번 안정성이 올라갔다.

결국 좋은 파이프라인은 LLM이 최대한 좁은 역할만 하도록 만드는 것 같다. "LLM이 할 일은 이 diff.json을 읽고 코드를 수정하는 것뿐" — 이게 v7이 도달한 결론이다.

그리고 세션 재개는 생각보다 훨씬 중요했다. 파이프라인이 길수록 중간에 뭔가 하나 잘못되는 게 당연하다. 처음부터 다시 시작해야 한다면 개발 속도가 크게 느려진다. v6에서 세션 인프라를 만든 게 v7 개발을 수월하게 했다.

v7은 현재 실험적 상태(experimental)이다. 실제 퍼블리싱에는 publish 스킬(Fresh Publish 방식)을 기본으로 쓰고 있다.