Logan.

2026-05-15

React Native Web Storybook으로 잡는 회귀와 잡는 회귀

RN 프로젝트에 Storybook을 도입할지 결정할 때 가장 중요한 표 한 장. 잡히는 회귀 7종과 못 잡는 회귀 9종을 솔직하게 정리합니다.

by Logan·8분 읽기·part 1 of 본격 Storybook 도입·#storybook #react-native #testing

안녕하세요, 로건입니다 👋

여러분, 처음 RN 프로젝트에 Storybook을 셋업하면서 동료한테 이런 질문을 받았어요.

"그거 어차피 HTML로 렌더하는 거잖아요. 앱이랑 무슨 상관이에요?"

솔직히 그 자리에서 한 줄로 반박할 자신이 없었어요. 그래서 노트북을 덮고, 몇 주에 걸쳐 우리 팀이 매일 마주치는 회귀들을 표 한 장에 정리해봤습니다. 잡히는 것안 잡히는 것을 솔직하게요. 결과는 "반은 맞고 반은 다르다"였는데, 그 반쪽을 어떻게 받아들이느냐가 도입 성패를 가른다고, 검증 단계를 마치고 도입을 막 시작하는 지금 시점에 정리해두려고 합니다.

RN-Web Storybook이 잡는 것

먼저 잡히는 회귀부터 보시죠.

회귀 종류RN-Web Storybook디바이스 QA
props 전달 누락
조건부 렌더 분기 (disabled, error)
핸들러 wire-up 끊김
콜백 인자 시그니처 변경
props → state 동기화 버그
렌더 트리 구조 변화✅ (Chromatic diff)
토큰 시스템 적용 불일치

핵심은 이거예요. JS 레이어의 로직과 시각 결과는 RN-Web에서 거의 그대로 재현됩니다. 컴포넌트가 disabled={true}일 때 회색으로 안 바뀐다? 웹에서도 똑같이 안 바뀝니다. 핸들러를 잘못 끊었다? play 함수가 click을 발사하는데 fn() spy가 호출되지 않으니 빨갛게 떨어집니다.

RN-Web Storybook이 못 잡는 것

그런데 못 잡는 것들이 분명히 있어요. 그것도 9가지나.

회귀 종류RN-Web디바이스만 잡힘
pan/pinch/long-press 같은 gesture
키보드 IME 한국어 조합
SafeAreaView의 실제 inset 값
60fps 애니메이션 jank
네이티브 모듈 (camera, biometrics, push)
Android/iOS 폰트 fallback 차이
Reanimated worklet 실행 결과
스크롤 관성·overscroll 동작
앱 콜드 스타트 시점의 race condition

여기서 분명히 해두고 싶은 게 있어요. 이 표의 오른쪽 9가지는 Storybook이 잡으려고 노력하면 안 되는 영역입니다. 무리해서 jest나 play로 잡으려고 들면 mock이 거대해지고, mock이 production과 어긋나는 순간 검수 가치는 0이 됩니다. 이게 다음 편에서 자세히 다룰 이야기예요.

보정 한 줄 — 이 표는 RN-Web 기준입니다. 도입을 시작하면서 @storybook/react-native를 DebugView 안에 같이 얹었고(8편), 그 결과 위 9가지 중 gesture · IME · SafeArea · Reanimated worklet · 폰트 fallback · 스크롤 관성 6칸은 디바이스 QA 전에 한 번 더 걸러지기 시작했어요. 콜드 스타트 race와 네이티브 모듈 권한 흐름은 여전히 디바이스 QA의 몫.

그래서 어떤 포지셔닝인가

저는 검증 단계를 거치면서, 동료에게 다음과 같이 답하기로 했어요.

"값싼 회귀 안전망이에요. 디바이스 QA는 비싸지만 본질적인 검증이고, Storybook은 PR마다 자동으로 돌아가서 JS 레이어 회귀를 1분 안에 잡아주는 그물입니다. 그 그물이 한 번 잡아주면, QA 시간을 며칠 단위로 절약합니다."

테스트 레이어를 분담해서 보면 이렇게 됩니다.

위로 올라갈수록 비싸지고, 본질에 가까워집니다. 아래로 내려갈수록 싸지고, 자주 돌릴 수 있어요. Storybook이 차지하는 칸은 그 중간 — 빠르고, 자주 돌고, 절반의 진실을 담당하는 그물입니다.

테스트 레이어 분담 다이어그램

가장 흔한 착각 세 가지

검증 단계 동안 팀원들과 부딪힌 인식 차이를 정리하면 이 세 가지였습니다.

"Storybook 통과 = 앱 OK" — 아니에요. JS 레이어만 통과한 거예요. 디바이스에선 다를 수 있어요.

"모든 화면을 Storybook으로 만들면 QA가 사라진다" — 절대 아닙니다. 시도해봤다가 화면 100개를 한 번에 지운 이야기를 3편에서 풀게요.

"Storybook이 없는 컴포넌트는 검증이 안 된 거다" — 검증 방식이 다른 거예요. Showcase grid 같은 갤러리 스토리는 인스트루먼트 없이도 가치 있고, 어떤 영역은 jest나 디바이스 QA가 더 적합합니다.

표 한 장을 동료에게 보여드리세요

만약 여러분이 RN 프로젝트에 Storybook 도입을 고민하고 있다면, 가장 먼저 할 일은 도구를 까는 게 아니에요. 잡히는 회귀와 안 잡히는 회귀를 표로 정리해서 동료에게 보여주는 것입니다. 표가 만들어지면, 그 다음에 도입 여부는 거의 자동으로 결정됩니다. "이 그물이 우리 팀에게 값어치 있는가?"라는 질문에 모두가 같은 그림을 보고 답할 수 있게 되니까요.

다음 편에서는 그렇게 결정한 다음, 검증 단계에서 200개에 가까운 스토리를 짜며 손에 굳은 한 줄짜리 규칙들에 대해 풀어볼게요. argTypes 전수 노출, 대표 스토리에만 play, showcase에는 인스트루먼트 X — 처음엔 가볍게 들리는 이 규칙들이 50번째 스토리쯤부터 왜 무거운 의미를 갖는지에 대해서요.

related — in series · 본격 Storybook 도입