MVP → RN Expo + 백엔드 전환에 Ralph Loop를 쓸 수 있는가
54_claude_code_ralph_loop 후속 문서. winemine-keyscreen 같은 기존 MVP를 React Native Expo 앱 + 백엔드로 전환하는 작업에 Ralph Loop를 적용할 수 있는지에 대한 명확한 답과, 가능하게 만들기 위한 사전 조건·실행 패턴을 정리한다. harness 스킬과 subagent를 활용한 조합 패턴도 포함.
1. 결론 (TL;DR)
섹션 제목: “1. 결론 (TL;DR)”가능합니다. 단 “MVP를 RN+백엔드로 전환해줘” 를 통째로 던지면 100% 실패합니다.
정확히는:
- ❌ 불가능: 한 번의 Ralph Loop로 전체 전환을 끝내려는 시도
- ✅ 가능: 사람이 사전에 아키텍처/스펙/API 컨트랙트를 확정하고, 작업을 기계 검증 가능한 phase로 쪼갠 뒤 phase 단위로 Ralph를 돌리는 것
검증된 사례
섹션 제목: “검증된 사례”| 사례 | 규모 | 시간 | 출처 |
|---|---|---|---|
| React v16 → v19 마이그레이션 | 1개 코드베이스 | 14시간 무인 실행 | ynkzlk (커뮤니티) |
| 3년 된 코드베이스 마이그레이션 | 236 files / 271 commits | 3일 | Dan Malone |
두 사례 모두 통째가 아니라 phase 분할 + git worktree 병렬 패턴이었다.
2. 왜 통째로는 불가능한가
섹션 제목: “2. 왜 통째로는 불가능한가”| 이유 | 설명 |
|---|---|
| 컨텍스트 누적 | 54번 7.1 에 정리한 대로 공식 플러그인은 fresh session이 아니라 같은 윈도우에 누적 → ~150k에서 auto-compact. RN+백엔드 전체 컨텍스트는 이 한도 밖. |
| 아키텍처 결정은 LLM이 못함 | ”Zustand냐 Jotai냐”, “Expo Router냐 React Navigation이냐”, “Supabase냐 자체 API냐” 같은 디자인 판단. Ralph는 객관 검증이 가능할 때만 작동. |
| objective exit criteria 부재 | ”앱이 잘 만들어졌는가” 는 기계가 못 판단함. 반면 “이 컴포넌트의 jest 테스트가 그린인가” 는 판단 가능. |
| Huntley 본인의 경고 | ”There’s no way in heck would I use Ralph in an existing code base.” — 단, 이건 “monolithic하게는 안 쓴다”는 뜻이지 “절대 안 쓴다”는 아님. 커뮤니티는 phase 분할로 우회. |
3. Ralph 가능해지기 위한 4가지 기준
섹션 제목: “3. Ralph 가능해지기 위한 4가지 기준”작업이 다음 4개 조건을 모두 만족해야 Ralph 적합:
3.1 기계 검증 가능한 종료 조건 (Machine-verifiable Exit Criteria)
섹션 제목: “3.1 기계 검증 가능한 종료 조건 (Machine-verifiable Exit Criteria)”- ✅
jest --bail그린,tsc --noEmit0 errors,eas build성공,supabase db push --dry-run클린 - ❌ “이 UI가 예쁜가”, “코드 품질이 좋은가”, “사용성이 어떤가”
3.2 Bounded Scope Per Iteration
섹션 제목: “3.2 Bounded Scope Per Iteration”한 iteration이 처리하는 단위:
- ≤ 1개 컴포넌트
- ≤ 1개 API 엔드포인트
- ≤ 1개 마이그레이션 스크립트
큰 작업은 여러 phase로 분할. 큰 작업을 한 iteration에 욱여넣지 말 것.
3.3 아키텍처는 사람이 먼저 확정
섹션 제목: “3.3 아키텍처는 사람이 먼저 확정”Ralph는 결정 실행자지 결정자가 아님. 아키텍처를 Ralph 안에서 결정하려 하면 무한 루프 또는 LLM이 임의로 정한 (보통 나쁜) 선택지가 박힌다.
3.4 외부 상태 머신
섹션 제목: “3.4 외부 상태 머신”PRD 체크박스([ ] / [x]) 또는 progress.md로 진행 상황을 파일로 영속화.
이유: context compaction 후에도 다음 iteration이 어디까지 했는지 알 수 있어야 함.
4. 실전 패턴: Phase + Wave + Worktree (Dan Malone 패턴)
섹션 제목: “4. 실전 패턴: Phase + Wave + Worktree (Dan Malone 패턴)”검증된 패턴. harness 스킬 + subagent와 정확히 결합 가능.
4.1 디렉토리 구조
섹션 제목: “4.1 디렉토리 구조”winemine-app/├── ralph/│ ├── prd/│ │ ├── phase-01-supabase-schema.md [ ] tables [ ] RLS [ ] migration test│ │ ├── phase-02-auth-api.md [ ] login [ ] signup [ ] e2e test│ │ ├── phase-03-expo-shell.md [ ] init [ ] tsconfig [ ] eas build│ │ ├── phase-04-navigation.md [ ] tabs [ ] stacks [ ] type-safe routes│ │ ├── phase-05a-screen-home.md [ ] UI [ ] data fetch [ ] snapshot test│ │ ├── phase-05b-screen-wine-detail.md [ ] ...│ │ └── phase-05c-screen-tasting-note.md [ ] ...│ ├── progress.md│ └── AGENT.md ← build/test 실행 방법, 환경 변수, 검증 명령어└── specs/ ├── api-contract.openapi.yaml ├── design-system.md └── auth-flow.mmd4.2 Wave 단위 병렬 실행
섹션 제목: “4.2 Wave 단위 병렬 실행”Wave 1 — 의존성 없는 phase 동시 실행:
git worktree add ../wm-phase-01 phase-01-supabasegit worktree add ../wm-phase-03 phase-03-expo-shell# 각 worktree에서 별도 Claude Code 세션 띄워 /ralph-loopWave 2 — 의존성 있는 phase (이전 wave 머지 후):
git worktree add ../wm-phase-02 phase-02-auth-api # schema 의존git worktree add ../wm-phase-04 phase-04-navigation # expo shell 의존Wave 3+ — 화면별 phase (UI는 거의 다 독립이라 대량 병렬 가능):
git worktree add ../wm-phase-05a phase-05a-homegit worktree add ../wm-phase-05b phase-05b-wine-detailgit worktree add ../wm-phase-05c phase-05c-tasting-note# ...4.3 단일 phase Ralph 호출 예시
섹션 제목: “4.3 단일 phase Ralph 호출 예시”/ralph-loop "phase-05a-screen-home.md의 모든 체크박스를 순서대로 처리:- 첫 번째 미체크 [ ] 항목 찾기- 구현 (specs/design-system.md 준수, specs/api-contract.openapi.yaml 준수)- yarn test:home --bail 통과 확인- [x]로 마크하고 commit (메시지: 'feat(home): <체크박스 내용>')- 다음 [ ] 항목으로 진행
모든 [ ]가 [x]가 되고 yarn build && yarn typecheck && yarn test:home 모두 그린이면<promise>PHASE_05A_DONE</promise>" \ --completion-promise "PHASE_05A_DONE" \ --max-iterations 30핵심 패턴:
- 단일 task per iteration (“ONLY WORK ON A SINGLE TASK AT A TIME”)
- 체크박스 = 상태 머신
- 매 iteration commit으로 진행상황 영속화
- promise는 모든 검증이 그린일 때만 출력
5. harness 스킬과의 연결점
섹션 제목: “5. harness 스킬과의 연결점”harness 스킬은 phase별 specialized agent / skill을 정의하는 데 정확히 맞다. 권장 agent 목록:
| Agent | 책임 | 검증 명령 |
|---|---|---|
supabase-schema-agent | RLS·migration·시드 데이터 | supabase db push --dry-run, supabase db lint |
expo-shell-agent | Expo 부트스트랩·tsconfig·eslint·EAS 설정 | eas build --local --profile development |
rn-screen-converter | 웹 컴포넌트 → RN 컴포넌트 (화면 단위) | yarn test:<screen>, yarn typecheck |
api-route-builder | OpenAPI spec → 백엔드 라우트 + integration test | vitest run api/<route> |
migration-verifier | 각 wave 종료 시 회귀 테스트 | yarn test:e2e --grep <wave> |
핵심 규칙: 각 agent는 자기 phase 안에서만 Ralph 루프를 돈다. 전체를 도는 메가 루프는 만들지 않는다.
6. Ralph 시작 전 사람이 반드시 해야 할 일
섹션 제목: “6. Ralph 시작 전 사람이 반드시 해야 할 일”이걸 skip하면 반드시 실패한다. 검증 사례 공통점은 전부 사전 PRD가 정밀했다는 것.
| # | 결정 사항 | 산출물 |
|---|---|---|
| 1 | 백엔드 스택 (Supabase / Next.js API / 다른 거) | ADR 1줄 |
| 2 | API 컨트랙트 | OpenAPI 또는 tRPC schema |
| 3 | 상태관리·라우팅·데이터페칭 라이브러리 | package.json deps 결정 |
| 4 | 디자인 시스템 (Tamagui / NativeWind / Paper) | 컴포넌트 베이스 결정 |
| 5 | 인증 플로우 | 시퀀스 다이어그램 (mermaid) |
| 6 | DB 스키마 | SQL 또는 Prisma schema |
| 7 | 화면별 와이어프레임/스펙 | _workspace/에 phase별 .md |
| 8 | 테스트 전략 (Detox? Maestro? unit only?) | AGENT.md에 명시 |
이 8개를 Ralph 안에서 결정하려 하면 무한 루프 또는 LLM이 임의로 정한 (보통 나쁜) 선택지가 박힌다.
7. 공식 플러그인 vs 직접 구현
섹션 제목: “7. 공식 플러그인 vs 직접 구현”| 케이스 | 권장 도구 |
|---|---|
| Phase가 작음 (≤30 iter, 단일 컴포넌트·엔드포인트) | 공식 /ralph-loop 그대로 |
| Phase가 큼 (≥50 iter, 다중 파일 마이그레이션) | bash while + Claude Code SDK + worktree로 진짜 fresh session 패턴 — Dan Malone 방식 |
| 야간 무인 실행 | 직접 구현 + 비용 알림 + max-iterations 강제 |
54번 7.1의 컨텍스트 누적 함정 때문에, 대형 phase는 공식 플러그인 대신 직접 구현이 훨씬 안전.
Dan Malone 패턴의 핵심 명령어
섹션 제목: “Dan Malone 패턴의 핵심 명령어”claude --permission-mode acceptEdits "@PRD.md @progress.txt" \ --output-format stream-json | grep '^{' | tee tmpfile | jq@문법: 파일을 컨텍스트로 임베드--permission-mode acceptEdits: 편집 자동 승인--output-format stream-json: 실시간 진행상황 스트리밍 → 외부 모니터링·promise 감지 가능
8. 안티-패턴 체크리스트
섹션 제목: “8. 안티-패턴 체크리스트”다음 중 하나라도 해당되면 그 phase는 Ralph로 돌리지 말 것:
- 성공 기준이 “느낌”·“품질”·“좋아 보임” 같은 주관적 표현
- 컴포넌트 라이브러리·상태관리·라우팅 같은 선택이 아직 안 됨
- 화면 와이어/스펙이 없음
- 테스트 인프라(jest/detox 등)가 아직 부팅 안 됨
- 1개 phase 안에 여러 화면·여러 도메인이 섞여 있음
-
max-iterations안 걸려 있음 - promise 문구가 검증 가능한 상태와 분리됨 (단순 “DONE” 만 출력시키는 케이스)
9. 권장 시작 순서
섹션 제목: “9. 권장 시작 순서”- 지금 (사람 영역): winemine-keyscreen 레포 구조 파악 → 6장의 8개 결정 사항을
_workspace/에 정리. 이건 Ralph 아님. - 그 다음:
ralph/prd/phase-XX-*.md분할. 각 phase에 체크박스 + machine-verifiable exit criteria 명시. - 그 다음: harness 스킬로 phase별 specialized agent 정의.
- 마지막: Wave 1의 phase 1~2개부터 작게 Ralph 돌려 확신 얻고 → 점진 확장.
이 순서를 뒤집으면 (= 계획 없이 Ralph부터) 토큰만 태우고 결과물은 못 쓰는 코드가 된다.
10. 한 줄 요약 표
섹션 제목: “10. 한 줄 요약 표”| 질문 | 답 |
|---|---|
| MVP → RN+백엔드 전환을 Ralph로 한 번에 끝낼 수 있나? | ❌ 절대 안 됨 |
| Phase 분할 + 사전 스펙이 있으면 Ralph로 자동화 가능한가? | ✅ 가능 (검증 사례 있음) |
| harness + subagent와 같이 쓸 수 있나? | ✅ 정확히 맞는 패턴 (Dan Malone 방식이 동일 철학) |
| 공식 플러그인 그대로 써도 되나? | 작은 phase는 ✅ / 큰 phase는 직접 구현이 안전 |
| 사람이 먼저 해야 할 일이 있나? | ✅ 6장의 8개 사전 결정사항. 이거 없으면 실패 |
11. 레퍼런스
섹션 제목: “11. 레퍼런스”- 54_claude_code_ralph_loop — 플러그인 전체 정리 (선행 문서)
- Ralph Wiggum: Orchestrating AI Agents to Migrate a 3-Year-Old Codebase — Dan Malone — Phase + Wave + Worktree 패턴의 출처
- Ralph Wiggum Loop — January 2026 Snapshot — 마이그레이션은 “best fit” 카테고리라는 공식적 확인
- From Meme to Night Shift Coder — techbuddies.io — React 16→19 무인 마이그레이션 사례
- The Ralph Wiggum Technique — ghuntley.com — 원조 글 (그리고 “existing codebase는 안 씀” 발언의 출처)
조사 일자: 2026-05-19. 대상 작업: winemine-keyscreen MVP → React Native Expo + 백엔드 전환.