Figma 퍼블리싱 파이프라인 10. IR 비교 엔진과 세션 인프라 통합

정확한 비교 엔진과 안정적인 실행 인프라가 서로 다른 갈래에 나뉘어 있었다. 하나를 쓰면 다른 하나를 포기해야 하는 상태라 v7에서 둘을 합쳤다.

비교는 정밀한 쪽, 실행은 안정적인 쪽

데이터 수집과 세션 관리, 스코프 강제는 나중 갈래의 방식을 그대로 쓰고, IR 기반 비교 엔진은 앞선 갈래에서 되살렸다. LLM은 코드 생성 한 단계에만 남겼다.

셋을 하나로 줄인 방법은 단순하다. 예전에는 diff 리포트를 LLM이 쓰고, 설계서를 LLM이 쓰고, 코드를 LLM이 고쳤다. v7은 Python이 diff.json까지 완전히 만들어두고 LLM은 그걸 읽고 코드만 고친다. 설계서는 아예 안 쓴다. diff에 무엇을 고쳐야 하는지가 이미 다 적혀 있어서, 그걸 다시 문장으로 풀어 쓰는 단계가 중복이었다.

재사용하려다 구조를 왜곡하고 있었다

가장 오래 고민한 게 재사용 판단이었다.

기존 코드에 비슷한 컴포넌트가 있으면 가져다 쓰는 게 낫다. 그런데 해보니 이미 있는 컴포넌트를 억지로 끼워 맞추느라 Figma 구조를 비트는 경우가 생겼다. Figma에는 테이블이 있는데 기존 코드의 Tabs 컴포넌트가 비슷한 점수로 매칭되는 식이었다.

순서를 못 박아서 해결했다. 먼저 Figma 구조를 그대로 복원하고, 재사용 판단은 그다음에 한다. 후보 점수가 0.80 미만이면 재사용하지 않고 기본 요소로 내려간다.

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

reconstruct로 판정된 블록에서 재사용을 막는 게 핵심이다. 구조가 바뀌어야 하는 자리인데 기존 컴포넌트를 쓰면 결국 원래 모양으로 되돌아간다.

코드보다 그림을 먼저 만들어뒀다

사용자가 섹션을 고른 직후, 코드를 만들기 훨씬 전 단계에서 Figma 스크린샷과 초기 시각 뼈대를 먼저 뽑아둔다. P8이 코드를 만들 때 이걸 시각 기준점으로 쓴다.

최종적으로 만들어야 할 게 어떻게 생겼는지를 미리 확보해두는 것이라, 중간 단계에서 판단이 흔들려도 돌아올 지점이 있다.

있을 법한 컴포넌트를 추측하지 않게 했다

퍼블리싱을 시작하기 전에 현재 앱에 어떤 공용 컴포넌트와 recipe, slot-recipe가 있는지 파일 시스템을 스캔해서 목록을 만들어둔다. P8이 재사용을 판단할 때 이 목록을 본다.

전에는 LLM이 이런 게 있을 것 같은데 하고 추측했다. 이제는 Python이 실제로 훑어서 확실한 목록을 건넨다. 앞서 매핑 표를 만들었을 때와 같은 방식이다. 추측이 들어갈 자리를 조회로 바꾼다.

세션 인프라는 그대로 이어받았다. 중간에 끊겨도 --session으로 재개하고, --skip-llm으로 P8 직전까지만 돌려서 diff.json만 확인할 수도 있다.

여기까지 온 경로

v7은 아직 실험 단계다. 실제 퍼블리싱에는 diff를 쓰지 않고 매번 새로 구현하는 publish 스킬을 기본으로 쓰고 있다. 비교 정확도를 끌어올리는 방향으로 여기까지 왔는데, 정작 손에 익은 건 비교를 안 하는 쪽이라는 게 지금 상태다.