React 기반 디자인 시스템 모노레포에서는 컴포넌트 변경이 잦습니다. 그만큼 구현보다 검수·머지·버전·npm 배포까지의 핸드오프가 배포 리드타임을 좌우했습니다. 그래서 여러 도구를 엮어 "디자이너 승인 = 배포"가 성립하는 파이프라인으로 전체 흐름을 재설계했습니다.
기능 브랜치를 main에 머지해도 배포가 끝나지 않았습니다. Changeset이 있으면 Actions가 Version Packages PR을 한 번 더 만들고, 그 PR까지 머지해야 버전 범프와 npm 배포가 완료됩니다.
flowchart TD
A[Figma 기준으로 컴포넌트 구현] --> B[PR 생성 및 코드 디자인 검수]
B --> C[Storybook 미리보기 URL을 Slack에 수동 공유]
C --> D[디자이너 검수, 피드백 왕복]
D --> E[기능 PR을 main에 머지]
E --> F[Changeset 감지, Version Packages PR 자동 생성]
F --> G[Version Packages PR을 또 머지]
G --> H[npm publish 완료]
검수 승인 후에도 개발자가 머지를 두 번 해야 했고, "기능 머지 = 배포 완료"가 아니어서 핸드오프가 끊기지 않고 계속 이어졌습니다. 디자이너는 검수만 했을 뿐, 자신이 승인한 컴포넌트가 실제로 배포됐는지는 알 방법이 없었습니다. 배포 여부를 확인하려면 다시 개발자에게 물어봐야 했고, 배포 트리거가 검수 완료 시점과 떨어져 있었던 셈입니다.
개발자: 구현·커밋까지
디자이너: Chromatic 검수 + Slack에서 승인/배포
시스템: version · merge · npm publish · 결과 알림
특히 Version Packages PR 2차 머지를 없애고, 배포를 개발자의 후속 작업이 아니라 검수 완료의 다음 동작으로 만드는 것이 목표였습니다.
단계 | 담당 | 내용 |
|---|---|---|
1 | 개발자 | Figma 링크 Agent에게 전달 |
2 | 개발자/에이전트 | feature 브랜치에서 Figma MCP로 구현, Changeset 추가, 커밋·푸시 |
3 | 개발자/에이전트 | Chromatic 실행 → Storybook URL → Slack 검수 요청(Block Kit) |
4 | 디자이너 | Chromatic 검수 후 Slack 배포 버튼 |
5 | 자동화 | Worker → GitHub Actions → feature에서 version → main 머지 → npm 배포 → Slack 알림 |
3~5단계가 핵심입니다. 미리보기 공유와 승인·배포가 Slack 메시지 하나로 묶이고, version은 main 머지 전에 feature에서 처리됩니다.
flowchart TD
A[개발자 Figma 링크 전달] --> B[개발자 에이전트 Figma MCP 구현, Changeset, 커밋 푸시]
B --> C[개발자 에이전트 Chromatic 실행, Slack 검수 요청]
C --> D{디자이너 Chromatic 검수}
D -->|승인| E[Slack 배포 버튼 클릭]
E --> F[Worker, GitHub Actions 실행]
F --> G[feature에서 version 처리]
G --> H[main 머지]
H --> I[npm publish]
I --> J[Slack 결과 알림]
1) Agent Skill로 절차 표준화 배포 Skill이 브랜치 생성, Figma MCP 구현, Changeset, Chromatic, Slack 전송 순서를 고정합니다. 배포 지식을 개인 메모나 특정 개발자의 머릿속이 아니라, 팀원 누구나 실행할 수 있는 워크플로로 만든 이유가 여기 있습니다. Skill로 만들어 두면 담당자가 바뀌거나 새로 합류한 사람도 같은 절차로 배포를 진행할 수 있고, 에이전트가 반복 실행할 수 있는 형태로 문서화되어 개인 경험에 의존하지 않습니다. Slack 전송 전 개발자 확인을 두어, 미완성 미리보기가 채널에 올라가는 실수도 막았습니다.
2) Chromatic을 검수 표면으로 빌드 대시보드가 아니라 실제 Storybook URL을 공유합니다. 디자이너는 GitHub/로컬 없이 스토리북에서 확인합니다.
3) Slack Block Kit = 검수·배포 컨트롤 플레인
디자인 검수 완료: 검수 기록(배포 없음)
배포: 확인 모달 후 배포 트리거
승인 UX를 GitHub이 아니라 디자이너가 이미 쓰는 Slack에 두었습니다.
4) Cloudflare Worker = Slack ↔ GitHub 브릿지 Slack Interactivity를 받아 서명 검증 후, GitHub workflow_dispatch로 Changesets 워크플로를 실행합니다. 버튼에 담긴 feature 브랜치명을 넘깁니다. Worker는 배포 로직 없이 이벤트 중계만 담당합니다.
5) Changesets로 version → merge → publish 일원화 승인 시점에 feature 브랜치에서 version을 먼저 수행한 뒤 main에 머지합니다. 이후 main push가 Release 잡을 트리거해 npm publish까지 이어지고, 결과는 같은 Slack 채널로 알립니다.
이로써 기존에 필요했던 Version Packages PR 2차 머지가 사라집니다. PR 연동 CI가 빠질 수 있어 승인 머지 잡에 빌드 검증을 넣었습니다.
영역 | Before | After |
|---|---|---|
배포 완료 조건 | main 머지 + Version Packages PR 재머지 | Slack 배포 버튼 1회 |
버전 범프 시점 | main 머지 이후 별도 PR | 승인 시 feature에서 version 후 main 머지 |
미리보기 공유 | URL 수동 복붙 | Chromatic → Slack 메시지 |
배포 승인 | "머지해줘" + 개발자 작업 | 디자이너 Slack 버튼 |
개발자 역할 종료 | Version Packages PR 머지·배포 확인 후 | 검수 요청 전송 후 |
디자이너 도구 | Figma + Slack + (간접) GitHub | Figma + Chromatic + Slack |
검수·배포 트리거는 디자이너, git/npm 권한은 CI·시크릿에만
Slack 전송 전 확인, 배포 confirm 모달, Worker 서명 검증
Changeset 없이는 버전/배포가 성립하지 않으므로 Skill 단계에서 강제
version을 feature에서 먼저 처리해 Version Packages PR 왕복을 제거
요청 → 승인 → 결과를 Slack 한 채널에서 추적
디자인 시스템 배포에서 가장 길었던 구간은 구현이 아니라, main 머지 후 Version Packages PR을 한 번 더 머지해야 배포가 끝나는 구조였습니다. Slack 승인 시점에 version을 앞당기고 merge·publish를 자동화해, 검수 완료를 배포 트리거로 직결했습니다.
개발자는 구현까지, 디자이너는 Slack에서 끝, 배포는 시스템이 한다.