Figma 퍼블리싱 자동화 회고 (구조 중심 정리)

퍼블리싱 자동화 파이프라인을 만들면서 겪은 시행착오와 설계 기준이 어떻게 바뀌었는지를 정리한 복습용 기록

0. 이 문서를 쓰는 이유

이 문서는 결과 정리가 아니라 판단 과정 복기용이다.

• 왜 돌아갔는지
• 어디서 틀렸는지
• 무엇을 다시 보게 됐는지

👉 이걸 기억하기 위해 작성했다

1. 문제 정의부터 틀렸었다

처음 목표:

디자인 토큰 자동 적용

하지만 실제로 원했던 건:

피그마 링크 → 퍼블리싱

문제

• 수단을 목표로 착각
• 구현 관점으로 사고
• UX 기준이 없음

깨달음

문제는 기능이 아니라 사용자 경험 기준으로 정의해야 한다

2. 글로벌 스킬 집착 — 첫 번째 큰 실수

초기 생각:

• 하나의 글로벌 스킬
• 모든 프로젝트 대응

결과

실패

이유

• 프로젝트마다 다름
• 공통화 시도 → 조건문 증가
• 구조가 아니라 예외 집합이 됨

깨달음

기반 없이 일반화하면 구조가 아니라 예외 덩어리가 된다

3. 파이프라인 폭주 — 모든 걸 한 번에 처리

초기 구조:

• 생성
• 수정
• 비교
• 검증
• 자동 수정
• audit

👉 전부 한 번에 처리

결과

• 20~30분 소요
• 토큰 폭발
• 결과 불안정

당시 착각

기능이 부족해서 문제라고 생각함

실제 원인

한 작업에 너무 많은 책임을 넣은 것

4. 가장 큰 전환점 — "덜 하게 만들기"

기존 생각:

더 똑똑하게 만들기

변경:

덜 하게 만들기

변경 내용

• 페이지 → 컴포넌트 단위
• 수정 → 생성
• 검증 축소
• 자동 수정 제거

결과

• 속도 개선
• 토큰 감소
• 안정성 증가

핵심 깨달음

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

5. 구조 붕괴 신호 — 조건문

코드가 점점 아래처럼 변해갔다.

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

의미

• Core가 너무 많은 걸 앎
• 구조가 아니라 조건으로 확장됨

깨달음

조건문이 늘어나면 구조가 잘못된 것이다

6. 리팩토링 포기 → 재설계

결정:

리팩토링 ❌ 재설계 ⭕

이유

• 구조 자체 문제
• 수정할수록 복잡해짐
• 책임 분리 실패

감정

• 아까움
• 미련
• "조금만 더 고치면 될 것 같은 느낌"

👉 전부 착각

깨달음

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

7. 설계 기준 변화

기존

• Phase 기준

변경

• Core
• Framework
• Project

핵심

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

8. 토큰 문제 재정의

초기 생각:

• 프롬프트 문제

실제:

• 구조 문제

깨달음

토큰은 비용 문제가 아니라 설계 문제다

9. 기술 선택 기준 변화

초기

• MCP → 편함

후기

• MCP → 비효율
• Plugin → 현실적

깨달음

편한 게 아니라 구조적으로 맞는 걸 선택해야 한다

10. Claude Code에 대한 이해 변화

초기:

프롬프트 잘 쓰면 된다

결론:

시스템 설계가 전부다

11. 최종 결론

하지 말아야 할 것

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

해야 할 것

• 프로젝트 단위 시작
• 구조 분리
• 단순화
• 반복 제거

12. 핵심 한 줄

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

13. 복습 포인트

• 생성과 수정은 다른 문제다
• 조건문 증가 = 구조 문제
• phase 분리는 해결책이 아니다
• Core는 아무것도 몰라야 한다
• 더 잘보다 덜 하게

14. 현재 상태

완성 ❌ 방향 ⭕

마지막 한 줄

지금은 아직 완성은 아니지만 제대로 된 출발점에 와 있다