안녕하세요, 로건입니다 👋
긴 시리즈도 이제 마지막 편입니다. 여기까지 오신 분들 정말 감사해요.
검증 단계를 마치고 본격 도입을 시작하는 지금, 몇 달간 만들어 본 결정들을 한 자리에 모아두려고 합니다. 1년치 운영 회고는 아니에요. 출발선의 풍경이고, 앞으로 어떻게 활용하면서 어떤 가설을 측정해볼지에 대한 그림입니다. 시리즈에서 한 번씩 나왔던 결정들을 한 페이지에 압축해두면, 비슷한 길을 시작하시는 분께 한 번에 펼쳐볼 지도가 되지 않을까 했어요.
안전망의 출발선 — 6개 레이어
먼저 우리 팀의 테스트 레이어 분담을 한 번에 보여드릴게요.
위로 갈수록 비싸지고, 본질에 가까워져요. 아래로 갈수록 싸고, 자주 돕니다. Storybook은 Layer 2~5를 차지하는 그물입니다 (web과 on-device, 두 결로). 모든 칸을 채우는 것이 목표가 아니라, 각 칸의 주인이 누구인지 분명히 하는 것이 안전망 운영의 본질이에요.
play 함수의 Tier 분류 — 모든 곳에 달지 않는다
이게 검증 단계에서 가장 늦게 안정화된 부분이에요. 처음엔 모든 컴포넌트에 play 함수를 달려고 했는데, 작성 비용이 도입 자체를 좌초시킬 뻔했거든요. Tier로 나눈 다음에 합리적이 됐어요.
| Tier | 정의 | play 적용 | 예시 |
|---|---|---|---|
| Tier 1 | 핵심 사용자 경로 | ✅ 필수 | Button, FormField, BottomSheet |
| Tier 2 | 자주 회귀 발생 영역 | ✅ 권장 | ToggleSwitch, Tabs, Stepper |
| Tier 3 | 보조 UI, 표시 전용 | ❌ 안 함 | Badge, Divider, Spinner |
| Showcase | 갤러리 grid | ❌ 안 함 (마찰) | AllTones, AllSizes |
모든 컴포넌트에 play를 달았다면 작성 시간도 유지보수 부담도 무거웠을 거예요. 안전망의 그물눈을 조밀하게가 아니라 적절하게 짜는 것이 핵심이었습니다.
검증 단계에서 만들어진 산출물
숫자로 정리하면 이래요.
| 항목 | 수치 |
|---|---|
| 컴포넌트 스토리 | 200개 근방 |
| play 인터랙션 테스트 | 60개 근방 |
| Figma 자동 변환 스토리 | 80개 근방 |
| 일괄 삭제한 페이지 스토리 (3편) | -106 |
| Chromatic baseline | 200+ 스냅샷 |
| 자체 도구 (Visual Builder) | S3 정적 런타임으로 정착 |
| in-app Storybook (on-device) | DebugView 안 토글로 도입 (8편) |
이 표는 지금까지 만든 것의 사진이지, 측정된 효과는 아니에요. 효과는 본격 도입 이후 측정할 예정입니다. PR당 평균 회귀 발견 건수, 디자인 검수 시간, 머지 속도 — 이런 지표를 도입 전후로 비교해보고 싶어요. 그게 다음 회고의 재료가 되겠죠.
아직 못 채운 칸들
이게 가장 정직하게 적어두고 싶은 부분이에요. 의도적으로 미뤄둔, 또는 다음 분기로 넘긴 영역들입니다.
| 영역 | 상태 | 이유 |
|---|---|---|
addon-a11y 자동 audit | ⏳ 미시작 | 우선순위 낮음. 디바이스 QA에서 함께 검수 예정. |
test-runner CI 통합 (Tier 2까지) | 🔄 일부만 | Tier 1만 자동, Tier 2는 수동 트리거. |
| Living Style Guide (MDX 문서) | ⏳ 미시작 | argTypes 콘트롤로 충분하다는 판단. |
| Visual Builder 디자이너 베타 배포 | 🔄 시작 직전 | 베타 user 2~3명 발급 예정. (7편) |
| in-app Storybook ROI 측정 | 🔄 도입 직후 | 디자이너 검수 사이클 / 디바이스 QA 회귀 감소량 (8편) |
| Detox e2e와의 dual 라벨링 | ⏳ 미시작 | mock 무한 회귀 위험. 페이지 스토리 폐기와 같은 이유. |
| iOS vs Android 별도 베이스라인 | ⏳ 미시작 | 우리 케이스에서는 차이가 작아 무료 플랜 비용 우선 |
빈 칸을 모두 채우는 게 목표가 아니에요. 각 칸이 누구의 책임인지 명시하는 것이 안전망 운영의 본질이라고 1편부터 7편까지 반복해서 말씀드렸어요. 이 표가 그 메시지의 가장 정직한 증거입니다.
도입 직후, 측정하고 싶은 가설들
본격 도입을 시작하면서 측정해보고 싶은 가설 몇 개를 미리 적어둘게요. 6개월 뒤에 다시 적을 글의 재료가 될 거예요.
가설 1. PR 리뷰에서 "이건 토큰이 다른데요" 라는 디자이너 코멘트가 절반 이하로 줄어든다 (Visual Builder + Figma 변환 워크플로 효과).
가설 2. 디바이스 QA 단계에서 발견되는 컴포넌트 단위 회귀가 분기당 한 자릿수로 떨어진다 (Storybook play + Chromatic + in-app Storybook 안전망 효과).
가설 3. 신규 컴포넌트 한 개를 카탈로그에 추가하고 시각 검수까지 받는 시간이 평균 30분 이하로 들어온다 (작성 표준 + 자동 변환 효과).
가설 4. 디자이너가 Visual Builder를 Figma 다음 단계로 받아들인다 — 즉, 디자인 → 빌더 → 명세 → 코드라는 새 흐름이 정착한다.
가설 1~3은 정량으로 측정할 수 있어요. 가설 4는 정성에 가깝지만, 빌더 사용량 (월 PUT 횟수, 활성 user 수)으로 proxy 측정 가능합니다.
다시 시작한다면 이렇게 했을 것
검증 단계에서 가장 늦게 깨달은 결정 세 가지를 정리해두려고 해요. 이미 시작하신 분도, 지금 도입을 시작하시는 분도 똑같이 한 번씩 부딪힐 갈림길이거든요.
결정 1 — 페이지 스토리는 처음부터 시작하지 않는다
3편에서 한 번에 지운 그 106개 페이지 스토리. 다시 시작한다면 그 시간 전체를 절약하고 컴포넌트 스토리에 집중하겠어요. 처음엔 "1:1 매칭이 가능하지 않을까?" 하는 환상이 있었는데, mock 무한 회귀의 함정이 너무 명백했어요. 어떤 영역은 처음부터 디바이스 QA에 맡기는 게 답이라는 걸 가장 빨리 인정하는 게 검증 단계의 최선이었을 거예요.
결정 2 — Chromatic은 1주차에 Pilot으로 켠다
6편에서 단계적으로 풀었던 Pilot 단계를 몇 주 뒤에야 시작했어요. 다시 시작한다면 첫 PR 머지하기 전에 Pilot을 켜겠어요. 빠르면 빠를수록 false positive 패턴을 빨리 발견하고, 도입 자체의 ROI를 한 자릿수 PR 만에 증명할 수 있어요. 그게 팀의 신뢰를 끌어올리는 가장 빠른 방법이에요.
결정 3 — 스토리 작성 표준을 공유 문서로 만든다
2편에서 정리한 한 줄 규칙들 — argTypes 전수 노출, 대표 스토리만 play, StyleSheet.create만, shim은 고치지 말기 등 — 이게 사실 내 머릿속에만 있었어요. 새로 합류한 분이 똑같은 실수를 다시 하시더라고요. 다시 시작한다면 첫 컴포넌트 스토리를 짤 때 이 규칙들을 사내 위키에 박아두는 것부터 하겠어요. 도구가 자동으로 강제할 수 있는 규칙은 ESLint 룰로, 사람만 결정할 수 있는 규칙은 PR 리뷰 체크리스트로요.
그리고 한 줄
검증부터 도입까지 짧지 않은 시간이 걸렸어요. 처음엔 "Storybook 도입"이라는 한 줄짜리 OKR이었는데, 끝나고 보니 팀이 디자인을 검수하는 방식, PR이 머지되기 전에 거치는 단계, 디자이너와 개발자가 의사소통하는 도구가 다 같이 바뀌어 있더라고요. 그리고 어쩌면 가장 의외였던 건 — 안전망을 짜다가 우리만의 도구 한 칸(7편) 과, 디바이스 위 한 겹(8편) 까지 더 얹게 됐다는 것.
만약 여러분이 비슷한 갈림길에 서 계신다면, 마지막으로 한 줄 드리고 싶어요.
도구가 아니라 정책이 안전망을 만듭니다.
Storybook을 깔고, Chromatic을 붙이고, play 함수를 짜는 건 1주일이면 됩니다. 그런데 어떤 회귀를 잡을지, 어떤 회귀를 안 잡을지, 합격 받은 스토리를 어떻게 보호할지, false positive를 어떻게 줄일지 — 이런 정책들이 정착하는 데 몇 달이 걸렸어요. 그 정책들이 모여서 지금의 그물이 됐고, 이제 그 그물 위에서 실제로 안전망이 어떻게 작동하는지 측정해볼 차례입니다.
만약 여러분도 RN 프로젝트에 Storybook 도입을 고민 중이시라면, 도구 자체보다 정책 한 묶음을 같이 설계하시는 걸 추천드려요. 시리즈에서 풀었던 한 줄 규칙들이 그 시작점이 될 수 있을 거예요. 그리고 안 짤 영역을 처음부터 정직하게 비워두세요. 그게 1주일 뒤에 후회를 가장 적게 남기는 결정이더라고요.
긴 시리즈 읽어주셔서 다시 한 번 감사합니다. 안전망이라는 단어가 처음보다 조금 더 손에 잡히는 모양으로 다가왔으면 좋겠어요. 도입을 시작한 다음의 풍경은, 몇 달 뒤에 다시 글로 인사드릴게요.
