본문으로 건너뛰기

Figma 퍼블리싱 파이프라인 성능 & 토큰 최적화 정리

·8 min read
DevToolsfigmapublishing-pipelinetoken-optimizationllmperformancearchitecture

퍼블리싱 자동화 파이프라인을 운영하면서 겪은 토큰 문제, 성능 병목, 구조적 한계를 정리한 학습용 기록

1. 시작 — 왜 성능 문제가 생겼는가

처음에는 단순한 문제처럼 보였다.

  • 퍼블리싱이 느림
  • 토큰이 많이 듦
  • 비용이 커짐

하지만 실제로는 이런 문제가 아니었다.

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

2. 토큰 이해 — 가장 먼저 깨달은 것

터미널에서 보던 이 숫자부터 이해가 필요했다.

tokens: 1.2k in / 0.8k out

핵심 개념

  • in → 모델에게 보내는 전체 컨텍스트
  • out → 모델이 생성한 결과

👉 중요한 건 in

왜 문제인가

대화가 길어질수록 in 토큰이 계속 누적된다. 턴마다 이전 대화 전체가 컨텍스트에 포함되기 때문이다.

턴 1: 3k
턴 2: 8k
턴 3: 15k

👉 대화가 길어질수록 계속 누적됨

결론

토큰은 "요청 크기" 문제가 아니라 세션 구조 문제다

3. 진짜 병목 — 어디서 토큰이 터지는가

파이프라인 전체를 보면:

  • 일부 단계 → 토큰 0 (Python 처리)
  • 일부 단계 → 토큰 폭발

가장 무거운 구간

Phase 2A (Layout 생성)

Phase 2B (Styling)

👉 전체 토큰의 70~80%

왜 무거운가

  • 2A → 구조 전체 입력
  • 2B → 2A 결과 + 스타일 다시 입력

👉 같은 데이터를 여러 번 태움

4. 핵심 변수 — 섹션 수

중요한 포인트:

비용은 페이지 크기보다 섹션 수에 더 크게 영향 받는다

이유

  • 섹션 = LLM 호출 횟수
  • 섹션 많을수록 반복 실행

결과

섹션 2개 → 2회 호출
섹션 8개 → 8회 호출

👉 비용 선형 증가

5. 72K 노드 문제 — 구조적 한계

Figma 페이지 하나:

  • 노드 72,000개
  • JSON 수십~수백 MB
  • 토큰 수천만

결론

전체 데이터를 그대로 LLM에 넣는다 ❌

해결 방향

전체 JSON을 LLM에 그대로 넘기는 대신, Python/CLI 레이어에서 먼저 필요한 부분만 추려낸다.

Python / CLI → 데이터 슬리밍
→ 필요한 부분만 LLM에 전달

핵심

LLM은 데이터 처리 도구가 아니라 판단 도구다

6. MCP vs API — 왜 성능 차이가 나는가

MCP 방식

MCP(Model Context Protocol)는 외부 데이터를 모델 컨텍스트에 직접 연결하는 방식이다.

큰 데이터 → 컨텍스트에 그대로 상주
→ 모든 턴에 누적

👉 문제:

  • 토큰 계속 증가
  • 대형 페이지에 취약

API 방식

전체 JSON → 로컬 처리 → 분할 → LLM 투입

👉 장점:

  • 토큰 제어 가능
  • 필요한 것만 사용

결론

MCP는 편하지만 대형 퍼블리싱 파이프라인에는 구조적으로 불리하다

7. 왜 퍼블리싱이 20~30분 걸렸는가

단순히 느린 게 아니라 구조 문제였다.

주요 원인

1. 병렬화 실패

설계상으로는 병렬이었지만 실제로는 직렬로 실행되고 있었다.

설계: 병렬
실제: 직렬

👉 4배 느려짐

2. API 호출 비효율

노드마다 개별 fetch를 반복하면 네트워크 왕복 횟수가 폭발적으로 늘어난다.

for node in nodes:
    fetch(node)

👉 네트워크 폭발

3. 수정 루프 반복

검증 → 실패 → 수정 → 다시 검증

👉 무한 루프에 가까움

4. 컨텍스트 누적

  • 같은 작업인데 토큰 3~4배 증가

8. 상용 툴이 빠른 이유

Anima / Locofy 같은 상용 툴의 특징:

레이아웃 → 룰 기반 처리
스타일 → 매핑 처리
LLM → 거의 안 씀

현재 구조

레이아웃 → LLM
스타일 → LLM
검증 → LLM

차이

LLM을 많이 쓴다고 좋은 게 아니라 덜 쓰는 구조가 더 좋다

9. 해결 전략

9.1 경량 vs 풀 모드 분리

경량

  • 단순 페이지
  • 한 번에 생성

풀

  • 복잡 페이지
  • 기존 파이프라인 유지

9.2 IR 강화

IR(Intermediate Representation)은 Figma 원본 JSON을 LLM이 이해하기 쉬운 중간 표현으로 변환한 구조다. IR을 강화하면 LLM에 넘기는 입력 자체를 줄일 수 있다.

Figma → IR → LLM

👉 입력 최소화

9.3 룰 기반 전환

  • 레이아웃 → 룰
  • 스타일 → 매핑
  • LLM → 예외 처리

9.4 플러그인 아키텍처

기존

글로벌 + 프로젝트 분리

변경

Core + Plugin

구조

Core

  • 분석
  • 분할
  • 기본 흐름

Plugin

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

핵심

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

10. 개선 우선순위

중요한 건 순서였다.

추천 순서

  1. 병렬화 확인
  2. 섹션 분할 조정
  3. 반복 루프 제거
  4. 룰 기반 전환

이유

병렬화가 깨져 있으면 다른 최적화 효과를 측정할 수 없다

11. 핵심 설계 원칙

  • 토큰은 구조 문제다
  • 섹션 수 = 비용
  • 반복 호출 제거
  • LLM 최소화
  • 데이터 먼저 줄이고 LLM 사용
  • 구조 기반 최적화

12. 한 줄 정리

성능 문제는 모델 문제가 아니라 컨텍스트를 어떻게 쪼개고 몇 번 다시 태우는가의 문제였다

13. 복습 체크리스트

  • in / out 토큰 개념 이해
  • 섹션 수가 비용에 미치는 영향 설명 가능
  • MCP vs API 차이 설명 가능
  • 병렬화 실패가 왜 치명적인지 이해
  • LLM을 줄이는 방향이 왜 중요한지 설명 가능

마무리

이 파이프라인을 보면서 가장 크게 바뀐 생각은 이거다.

자동화는 "더 똑똑하게 만드는 문제"가 아니라 "얼마나 불필요한 작업을 제거할 수 있는가"의 문제다