Figma → 코드 자동 퍼블리싱 파이프라인 구축기 (아키텍처 중심 회고)

Figma 시안을 기반으로 "링크 하나로 퍼블리싱"되는 시스템을 만들면서 겪은 설계 고민과 실패, 그리고 구조를 다시 정의한 과정 기록

1. 시작 — 내가 만들고 싶었던 것

처음 목표는 단순했다.

피그마 링크 하나 넣고 "이 시안으로 퍼블리싱 해줘" 라고 하면 코드가 생성되는 시스템

하지만 초반 접근은 완전히 다른 방향이었다.

• 디자인 토큰 자동 적용
• 글로벌 스킬 설계
• 범용 자동화 시스템

지금 보면 이건 전부 수단이었다.

실제 목표

피그마 노드 URL + 페이지 경로
→ 로컬 프로젝트에 바로 코드 생성

핵심은 기능이 아니라 UX였다.

2. 첫 번째 설계 — 글로벌 스킬 (실패)

처음에는 이렇게 생각했다.

• 하나의 글로벌 퍼블리싱 스킬
• 모든 프로젝트에서 동작

결과는 실패였다.

왜 실패했나

프로젝트마다 전부 달랐다.

• framework
• styling
• 구조
• 규칙

결국 이런 코드가 생기기 시작했다.

if (framework === "tailwind") ...
if (app === "marketer") ...

3. 문제의 본질 — 구조가 아니라 조건으로 확장됨

이 시점에서 중요한 걸 놓쳤다. 이건 단순한 코드 문제가 아니라 구조 붕괴 신호였다.

실제로 벌어진 일

• Core가 framework를 앎
• Core가 project를 앎
• Core가 page까지 앎

결과:

• 영향 범위 예측 불가
• 유지보수 불가능
• 확장할수록 복잡도 증가

4. 파이프라인이 망가진 이유

문제는 기능이 많아서가 아니었다.

너무 많은 일을 한 번에 처리한 구조

한 요청에서 처리한 것:

• Figma 분석
• 자산 추출
• 섹션 분할
• 코드 생성
• 스타일 적용
• 기존 코드 수정
• 검증
• 재수정

결과:

• 20~30분 소요
• 토큰 증가
• 결과 불안정

5. 가장 중요한 전환점 — "덜 하게 만들기"

처음 생각:

더 똑똑하게 만들면 해결된다

실제 결론:

덜 하게 만들어야 한다

구조 변경

❌ 기존: 생성 + 수정 + 검증 + 비교

✅ 변경: 생성만 한다. 수정은 분리한다.

추가 변화

• 페이지 전체 → 컴포넌트 단위
• 탐색 제거
• 자동 수정 루프 제거

핵심 깨달음

자동화에서 어려운 건 "생성"이 아니라 "수정"이다

6. 아키텍처 재정의

이 시점에서 설계 기준을 완전히 바꿨다.

❌ 기존 기준: Phase 중심 설계 → 실행 흐름 기준

✅ 새로운 기준: Core / Framework / Project → 변경 기준

6.1 Core

• 실행 흐름
• Figma 분석
• 섹션 분할

Core가 몰라야 하는 것:

• framework
• project
• page

6.2 Framework

• Tailwind / Chakra
• 스타일 문법

6.3 Project

• 파일 위치
• 컴포넌트 매핑
• 규칙 → config로 분리

핵심

구조는 "단계"가 아니라 "변경되는 축" 기준으로 나눠야 한다

7. 리팩토링 vs 재설계

결론: 리팩토링 ❌ 재설계 ⭕

이유:

• 구조 자체 문제
• 조건문 기반 확장
• 책임 경계 없음
• 수정할수록 복잡도 증가

구조가 틀리면 리팩토링은 의미 없다

8. 최종 구조

~/.claude/
├── CLAUDE.md
├── commands/
│   ├── publish-init.md
│   └── publish.md
└── tools/
    └── figma-extract.js

9. 핵심 설계 전략

9.1 컨텍스트 캐싱

/publish-init → 1회
/publish → 반복

반복 작업 제거.

9.2 IR 중심 설계

모든 단계는:

• IR 생성
• IR 소비
• IR 검증

구조 안정화.

9.3 조건문 제거

분기로 해결하지 말고, 레이어로 분리.

10. 지금 기준 결론

하지 말아야 할 것

• 글로벌부터 만들기
• 한 번에 다 처리하려 하기
• 조건문으로 확장하기

해야 할 것

• 프로젝트 단위부터 완성
• 구조 분리 (Core / Framework / Project)
• 단순화
• 캐싱

11. 한 줄 정리

이건 자동화 문제가 아니라 구조 설계 문제였다

12. 복습 포인트

• 조건문이 늘어나면 구조를 의심할 것
• 생성과 수정은 분리할 것
• phase 분리는 해결책이 아니다
• Core는 아무것도 몰라야 한다
• 더 잘 만들기보다 덜 하게 만들기

마무리

이 시스템은 아직 완성된 게 아니다. 하지만 하나는 확실하다.

문제를 해결하는 방향은 기능 추가가 아니라 구조 재정의였다