Figma 퍼블리싱 파이프라인 회고 (리팩토링 → 재설계 결정)
·5 min read
1. 상황 요약
Figma → 코드 퍼블리싱 자동화 파이프라인을 만들었고, 다음 기능들이 하나의 흐름 안에 들어가 있었다.
- Figma 분석
- 자산 추출
- 섹션 분할
- JSX 생성
- 스타일 적용
- audit / text 검사
- 재퍼블리싱 (ownership, snapshot)
초기에는 잘 동작했지만, 기능이 추가될수록 구조가 빠르게 복잡해졌다.
2. 발생한 문제
2.1 책임이 한 곳에 몰림
하나의 파이프라인 안에서 아래가 동시에 처리되고 있었다.
- framework 분기 (Tailwind / Chakra)
- project별 규칙 (경로, 컴포넌트 매핑 등)
- page별 예외 처리
- 스타일 문법 처리
- 실행 흐름 관리
→ 결과: 수정 시 영향 범위 예측이 어려움
2.2 조건문 기반 확장
if (framework === "tailwind") ...
if (app === "marketer") ...
if (page.includes("members")) ...이 패턴이 늘어나면서:
- 구조가 아니라 조건으로 확장됨
- 새로운 케이스 추가할수록 복잡도 증가
2.3 phase 기준 설계의 한계
처음 설계 기준:
PHASE 0 → 1 → 2 → 3
문제:
- 단계는 나눠졌지만
- 책임은 분리되지 않음
3. 핵심 깨달음
설계 기준이 잘못됨
구조는 "단계"가 아니라 "변경되는 축" 기준으로 나눠야 한다
4. 올바른 분리 기준
4.1 Core (변하지 않아야 하는 것)
- 전체 실행 흐름
- Figma 분석
- 자산 추출
- 섹션 분할
- audit / snapshot
특징:
- 프로젝트를 몰라야 함
- framework를 몰라야 함
4.2 Framework (문법 차이)
- Tailwind vs Chakra
- 스타일 표현 방식
- interaction 처리 방식
특징:
- 같은 구조라도 코드가 달라짐
4.3 Project (정책)
- 파일 생성 위치
- design-system 매핑
- component resolve
- asset 경로
특징:
- 프로젝트마다 바뀜
5. 문제의 본질
기존 구조는 다음이 섞여 있었다.
- Core + Framework + Project + Page
→ 결과:
- 한 곳 수정하면 전체 영향
- 예외 케이스가 계속 core로 침투
6. 의사결정
리팩토링 포기
이유:
- 구조 자체가 잘못되어 있음
- 부분 수정으로 해결 불가능
- 수정할수록 복잡도 증가
재설계 선택
전략:
- 기존 파이프라인(v1)은 유지 (참조용)
- 새로운 구조(v2)를 별도로 구축
7. v2 설계 기준
7.1 IR 중심 설계
모든 단계는 다음 중 하나만 수행해야 한다.
- IR 생성
- IR 소비
- IR 검증
중간 데이터 계약을 명확히 해서 구조 안정화
7.2 Core는 정책을 몰라야 한다
금지:
if (app === ...)
if (framework === ...)
if (page === ...)7.3 Framework는 별도 레이어
- 스타일 문법
- 토큰 변환
- interaction 처리
7.4 Project는 config로 분리
코드가 아니라 설정으로 관리
8. 이번 결정의 이유
- 구조가 조건문 기반으로 확장됨
- 책임 경계가 없음
- phase 분리는 했지만 레이어 분리가 안됨
- 유지보수 비용이 계속 증가하는 상태
9. 앞으로의 방향
- 글로벌 파이프라인 ❌
- 프로젝트 단위부터 재구축 ⭕
순서:
- 단일 프로젝트에서 완성도 확보
- 구조 안정화
- 이후 글로벌로 확장
10. 기억해야 할 기준
- 설계는 "단계"가 아니라 "변경 기준"으로 나눈다
- 조건문이 늘어나면 구조가 잘못된 신호다
- Core는 최대한 아무것도 몰라야 한다
- 자동화는 결과보다 유지보수성이 더 중요하다
11. 한 줄 요약
이 파이프라인은 복잡해서 망한 게 아니라 분리 기준이 잘못돼서 무너졌다