본문으로 건너뛰기

Figma → 코드 자동 퍼블리싱 파이프라인 설계 정리 (Pipeline 중심)

·7 min read
DevToolsfigmaautomationpublishing-pipelinearchitecturerefactoringllm

Figma 시안을 기반으로 퍼블리싱 자동화 파이프라인을 설계하면서 겪은 문제와 구조 개선 과정을 정리한 학습용 기록

1. 목표 — 어떤 UX를 만들고 싶었는가

이 파이프라인의 목표는 단순했다.

피그마 링크 → 퍼블리싱해줘

또는 조금 더 구체적으로:

/publish https://figma.com/... → 코드 생성

핵심은:

  • 빠르게
  • 최소 입력으로
  • 예측 가능하게

동작하는 퍼블리싱 흐름이었다.

2. 초기 상태 — 왜 문제였는가

초기 파이프라인은 기능적으로는 꽤 잘 동작했다.

  • 코드 생성 가능
  • 자동화 흐름 존재
  • 기본적인 품질 확보

하지만 시간이 지나면서 문제가 발생했다.

주요 증상

  • 퍼블리싱 1건에 10~30분 소요
  • 토큰 사용량 증가
  • 결과 일관성 부족
  • 기존 코드 수정 시 특히 느림

3. 문제의 본질

문제는 모델 성능이 아니었다. 파이프라인 구조 문제였다.

3.1 작업 범위가 너무 넓었다

요청은 단순했다.

특정 화면 퍼블리싱

하지만 실제 내부 동작은:

페이지 전체 탐색
→ 구조 이해
→ 파일 탐색
→ 수정 위치 판단
→ 생성 + 수정 + 비교

결과: 코드 생성보다 "탐색"이 더 무거워짐.

3.2 생성과 수정이 섞여 있었다

  • 생성: 단순
  • 수정: 복잡

하지만 구조는:

생성 + 수정 + 비교 → 동시에 처리

결과:

  • 반복 작업 증가
  • 판단 복잡도 증가
  • 실패 확률 증가

3.3 파이프라인이 너무 많은 일을 했다

한 요청에서 처리한 것:

  • 신규 퍼블리싱
  • 기존 코드 수정
  • 구조 분석
  • 스타일 적용
  • 검증
  • 재수정

결과: 하나의 작업으로 보기엔 너무 무거운 구조.

4. 핵심 깨달음

❌ 잘못된 방향: 더 똑똑하게 만들기

✅ 올바른 방향: 덜 하게 만들기

5. 파이프라인 재설계

5.1 목표 변경

기존: 페이지 전체 퍼블리싱

변경: Figma 화면 하나 → 컴포넌트 하나 생성

5.2 구조 단순화

기존:

Figma → 분석 → 분할 → 생성 → 스타일 → 수정 → 반복

변경:

Figma → 최소 데이터 → 코드 생성 → 끝

6. 제거한 것 vs 유지한 것

제거한 것

  • 페이지 전체 탐색
  • 기존 코드 수정 (patch)
  • 자동 수정 루프
  • 복잡한 검증 단계
  • 다단계 생성 구조

유지한 것

  • Figma 데이터 읽기
  • 기본 구조 생성
  • 코드 생성

"할 수 있는 것"이 아니라 "이번 작업에 필요한 것만 남긴다"

7. 구조 개선 전략

7.1 파일 위치를 미리 정함

기존: 파일 찾기 → 수정

변경: 파일 위치 고정 → 생성

탐색 비용 제거.

7.2 항상 새로 생성 (Replace 전략)

기존 코드 수정 ❌
새로 생성 후 교체 ⭕

수정 복잡도 제거.

7.3 한 번만 생성

  • 여러 단계 생성 ❌
  • 한 번에 생성 ⭕

반복 제거.

8. 성능 문제 — 왜 느렸는가

핵심 병목

Phase 2A + 2B — Layout 생성과 Styling 처리가 전체 토큰의 70~80%를 차지했다.

구조적 원인

1. 섹션 수 증가

  • 섹션 = LLM 호출 횟수
  • 페이지 복잡도 → 비용 증가

2. 반복 LLM 호출

생성 → 스타일 → 검증 → 수정 → 반복

3. 컨텍스트 누적

  • MCP 방식 → 컨텍스트 계속 증가
  • 세션 후반 → 토큰 폭발

9. 해결 방향

9.1 경량 vs 풀 파이프라인 분리

경량 모드: 단순 페이지, 1회 생성

풀 모드: 복잡한 페이지, 기존 구조 유지

9.2 IR(중간 표현) 강화

Figma → IR → LLM

LLM 입력 최소화.

9.3 LLM 사용 최소화

  • 레이아웃 → 룰 기반
  • 스타일 → 토큰 매핑
  • LLM → 예외 처리만

10. 구조 방향 — 플러그인 아키텍처

기존: 글로벌 + 프로젝트 분리

문제: 중복, 유지보수 비용 증가

변경: Core + Plugin

Core 역할

  • Figma 분석
  • 섹션 분할
  • 토큰 매핑
  • 기본 흐름

Plugin 역할

  • framework 대응
  • 스타일 처리
  • 프로젝트 규칙

공통은 하나로 유지하고 차이만 주입한다

11. 핵심 설계 원칙

  • 단순함 우선
  • 생성과 수정 분리
  • 탐색 제거
  • 반복 제거
  • LLM 최소 사용
  • 구조 기반 설계

12. 최종 한 줄 정리

이 파이프라인의 문제는 기능 부족이 아니라 너무 많은 일을 한 번에 하도록 만든 구조였다

13. 복습 포인트

  • 생성과 수정은 완전히 다른 문제다
  • 파이프라인은 똑똑해질수록 좋아지는 게 아니다
  • 탐색 비용이 코드 생성보다 더 클 수 있다
  • 섹션 수 = 비용이다
  • LLM은 최소한으로 써야 한다

마무리

이 파이프라인은 아직 완성된 상태는 아니다. 하지만 방향은 명확해졌다.

퍼블리싱 자동화는 기능 문제가 아니라 구조와 범위를 어떻게 제한하느냐의 문제였다