Claude Code 서브에이전트와 병렬 워크트리를 사용하여 완전한 AI 모바일 앱을 출시한 경험

QA 에이전트가 가장 먼저 찾아낸 것은 제가 사용자들에게 그대로 출시했을 법한 P0 버그였습니다.

출생 차트(Natal chart)가 인증(Authentication) 전에 계산되고 있었습니다. 401 에러가 조용히 반환되었습니다. 결과 화면에는 실제 차트 대신 가짜(Mock) 차트가 표시되었고, 에러도, 무언가 잘못되었다는 표시도 없었습니다. TypeScript도 이를 잡아내지 못했습니다. 유닛 테스트(Unit tests)도 잡아내지 못했습니다. 하지만 앱을 실제로 렌더링(Rendering)해 본 QA 서브에이전트(QA subagent)는 약 90초 만에 이를 잡아냈습니다.

이것이 바로 하나의 버그로 보여주는 에이전트 기반 개발(Agentic development)의 사례입니다.

이것은 Raedus Labs 산하에서 AI 점성술 및 타로 동반자 앱인 Origo를 구축한 이야기입니다. AI 동반자의 이름은 Vega입니다. 기술 스택(Stack)은 Expo SDK 56, Supabase edge functions, 그리고 RevenueCat입니다. 빌드 과정 전반에 걸쳐 Claude Code 서브에이전트(Subagents)와 동적 워크플로우(Dynamic workflows)를 사용했습니다. 무엇이 효과적이었는지, 무엇이 실패했는지, 그리고 훔쳐올 가치가 있는 구체적인 패턴은 무엇인지 소개합니다.

코드 작성 전의 리서치

구현 코드를 한 줄이라도 쓰기 전에, 저는 6개의 에이전트가 분산되어 수행하는 팬아웃(Fan-out) 리서치 워크플로우를 실행했습니다. 6개의 서브에이전트(Subagents)가 병렬로 실행되었으며, 각 에이전트는 경쟁사 환경, 수익화 패턴, 리텐션(Retention) 메커니즘, 기술 스택 검증, 콘텐츠 깊이 요구사항, 사용자 페르소나 신호라는 각각의 별도 리서치 질문에 집중했습니다.

합성 에이전트(Synthesis agent)는 6개의 출력물을 모두 읽고 빌드 준비가 된 PRD(제품 요구사항 문서)를 생성했습니다.

이 모든 과정은 백그라운드에서 실행되었습니다. 메인 세션의 컨텍스트 비대화(Context bloat)도 없었습니다. 제가 코드를 쓰기 위해 앉았을 때, 제품 결정은 이미 내려져 있었고 추측이 아닌 근거에 기반하고 있었습니다.

이것이 첫 번째 패턴입니다: 리서치는 팬아웃(Fan-out) 문제입니다. 하나의 에이전트가 순차적으로 리서치를 수행하는 것은 느리고 얕습니다. 6개의 에이전트가 병렬로 실행되어 각 질문을 깊게 파고든 후, 합성(Synthesis) 단계를 거치는 것이 더 빠르고 더 나은 신호를 만들어냅니다.

병렬로 구축된 6개의 화면

기반이 마련된 후, 저는 기능 화면을 구축하기 위해 6개의 서브에이전트(Subagents)를 파견했습니다. 각 에이전트는 자신만의 git 워크트리(Worktree)와 브랜치(Branch)를 할당받았습니다.

# 각 화면을 위한 격리된 워크트리(worktree) 설정
for screen in onboarding chart-reveal daily-reading tarot-draw chat settings; do
  git worktree add ".claude/worktrees/$screen" -b "build/$screen" origin/main
...

모든 것을 main 브랜치로 다시 병합(merge)하기 전의 관문: tsc --noEmit을 통과해야 했고, 테스트를 통과해야 했으며, 해당 화면이 충돌 없이 렌더링(render)되어야 했습니다. 각 병합은 순차적으로 진행되었습니다. 워크트리(Worktree)는 격리되어 있지만, 통합(integration) 문제는 병합 시점에 드러나기 때문에 병합 자체를 병렬로 처리하지는 않았습니다.

이것이 두 번째 패턴입니다: 생성을 위한 병렬성(parallelism), 통합을 위한 순차성(sequentialism). 6개의 에이전트가 동시에 빌드하는 것은 괜찮습니다. 하지만 통합 확인 없이 병합을 진행하는 것은 연쇄적인 충돌(cascading conflicts)을 일으키는 지름길입니다.

콘텐츠 데이터도 동일한 방식을 적용했습니다. 팬아웃(fan-out) 워크플로우를 통해 5개의 병렬 라이터(writer) 에이전트가 각각의 하위 집합을 담당하여 78장의 타로 데이터셋을 생성한 후, 일관성을 위한 병합 단계(merge pass)를 거쳤습니다.

비용 차익 거래로서의 모델 라우팅 (Model Routing as Cost Arbitrage)

모든 작업에 Opus 토큰을 사용할 필요는 없습니다. 저는 작업 유형에 따라 라우팅(routing)했습니다:

• Opus: 아키텍처(architecture) 결정, 보안이 중요한 Supabase 엣지 함수(edge function) 로직
• Sonnet: 기계적인 화면 빌드, 라우팅 로직, 데이터 포매팅(data formatting)
• Codex (OpenAI 토큰 사용, 완전히 별도의 예산): 단순 작업(grunt work), 보일러플레이트(boilerplate), 패키지 설치, 간단한 수정

Opus와 Sonnet의 구분은 보안에 민감한 백엔드(backend) 코드에서 가장 중요합니다. Vega의 응답을 처리하는 엣지 함수는 코드 기반의 안전 필터(safety filter)를 사용합니다. 해당 아키텍처를 제대로 구축하는 것은 Opus를 호출할 가치가 있었습니다. 하지만 설정(settings) 화면의 스캐폴딩(scaffolding)은 그럴 가치가 없었습니다.

기계적인 작업을 위해 OpenAI 토큰으로 Codex를 실행하는 것은 진정한 비용 차익 거래(cost arbitrage)입니다. 이는 다른 예산을 사용하는 주니어 개발자가 지루한 부분들을 처리하는 것과 같습니다.

검증(Verification)이 핵심 열쇠였다

TypeScript와 단위 테스트(unit tests)는 특정 수준의 보증을 제공합니다. 타입(type)이 일관되고 순수 함수(pure functions)가 올바르게 작동한다는 것을 알려줍니다. 하지만 사용자 흐름(user flow)이 엔드 투 엔드(end to end)로 작동하는지는 알려주지 않습니다.

QA 에이전트(QA agent)는 실제 앱을 렌더링하고 실제 온보딩 흐름(onboarding flow)을 따라 수행했습니다. 바로 이 과정을 통해 네이탈 차트(natal chart) 버그를 잡아낼 수 있었습니다.

원인을 파악한 후 수정은 간단했습니다. 콜드 오픈(cold open) 시점에 익명 Supabase 인증(anonymous Supabase auth)을 적용하고, 회원가입 시 linkEmail을 호출하여 인증 전환 과정 중에도 실제 차트 데이터가 유지되도록 했습니다. 커밋(Commit) 31fdf4e. 하지만 실제로 버튼을 눌러본 에이전트가 없었다면, 우리는 이 코드를 작성해야 한다는 사실조차 몰랐을 것입니다.

테스트가 놓친, 검증(verification)을 통해 발견된 실제 버그들:

• P0 온보딩 흐름 (인증 전 네이탈 차트가 계산됨, 조용한 401 에러 발생, 모의 차트(mock chart)가 표시됨)
• 에지 함수(edge function) 응답 형태와 클라이언트의 예상 타입 간의 클라이언트/서버 계약 드리프트(Client/server contract drift) (tsc로 강제된 단일 공유 계약 파일로 수정 완료)

규칙: 서브에이전트(subagent)가 "tsc clean, 테스트 통과"라고 말하는 것은 하나의 주장일 뿐입니다. 그것을 믿기 전에 게이트(gate)를 직접 다시 실행하십시오.

알아둘 가치가 있는 세 가지 운영 실패 사례

이것들은 제가 누군가에게 첫 멀티 에이전트 빌드(multi-agent build)를 시작하기 전에 말해줄 법한 내용들입니다.

고립된 워크트리(Orphaned worktrees)가 jest 실행을 오염시켰습니다. 화면 빌드 워크플로(screen-build workflow)가 완료된 후, .claude/worktrees/ 디렉토리에 잔여 브랜치들이 남았습니다. Jest가 이를 스캔하면서 중복된 테스트 트리(test trees)를 발견했습니다. 그 결과 약 8개의 "suite failed to run" 에러가 발생했고 실행 시간은 579초가 걸렸습니다. 해결책: jest의 testPathIgnorePatterns와 modulePathIgnorePatterns에 .claude/를 추가하십시오. 수정 후 깨끗하게 실행했을 때: 255개의 테스트, 약 70초 소요.

// jest.config.js
{
  "testPathIgnorePatterns": ["/node_modules/", "/.claude/"],
...

로컬 스택(local stack)이 구동 중일 때는 절대 테스트 게이트를 실행하지 마십시오. Supabase 컨테이너, functions serve, 그리고 expo start --web이 jest와 동시에 실행되면 메모리 압박(memory pressure)이 발생하여 SIGTERM으로 jest 워커(workers)가 종료됩니다. 이로 인해 약 10개의 잘못된 스위트 실패(false suite failures)가 발생합니다. 동일한 조건에서 증분 tsc 실행(incremental tsc run) 또한 가짜 타입 에러(spurious type errors)를 생성할 수 있습니다. 게이트를 실행하기 전에 개발 서버를 종료하십시오. 예외는 없습니다.

빌드 중간에 발생한 세션 종료 상황에서 살아남기. 화면 빌드 워크플로우 (screen-build workflow)가 도중에 중단되었습니다. 상태 (state)가 디스크에 저장되어 있었기 때문에 복구가 가능했습니다: 연속성 노트 (continuity notes), Git 히스토리, 커밋된 워크트리 (worktrees). 하나의 워크트리는 작업 내용을 커밋한 상태였습니다. 그것은 복구할 수 있었습니다. 나머지 다섯 개는 파일이 부분적으로만 작성되었고 커밋이 없었습니다. 그것들은 정리된 후 다시 배정되었습니다. 교훈은 이것입니다: 작업이 미완성이라 할지라도 워크트리에서 일찍, 그리고 자주 커밋하십시오. 부분적인 커밋은 복구 가능합니다. 고립된 워크트리 (orphaned worktree) 내의 커밋되지 않은 작업은 복구할 수 없습니다.

출시 제품 (What's Shipping)

Origo는 Raedus Labs의 앱입니다. Vega는 차트 인식 컨텍스트 시스템 (chart-aware context system)과 코드 강제 안전 필터 (code-enforced safety filter)를 갖춘 서버 측 Supabase 엣지 함수 (edge functions)에서 실행됩니다. RevenueCat이 구독을 처리합니다. 에이전트 기반 빌드 (agentic build) 방식은 몇 번의 집중적인 세션을 통해 제로 상태에서 완전하고 테스트 가능한 앱으로 만들어냈습니다.

만약 Claude Code 서브에이전트 (subagents) + 동적 워크플로우 (dynamic workflows)가 운영 오버헤드 (operational overhead)를 감수할 가치가 있는지 평가하고 있다면: 가치가 있습니다. 하지만 이득은 생성 계층 (generation layer)이 아니라 검증 계층 (verification layer)에서 발생합니다. 코드를 빠르게 생성하는 것은 기본 중의 기본입니다. 첫 사용자가 마주치기 전에 P0(최우선 순위) 버그를 잡아내는 것이 에이전트 기반 개발 (agentic development)이 실제로 제값을 하는 지점입니다.

출생 차트 (natal chart) 버그를 찾아낸 QA 에이전트의 비용은 커피 한 잔 값보다 적게 들었습니다. 그 대안은 실제 사용자에게 가짜 차트를 출시하고 왜 리텐션 (retention)이 깨졌는지 의아해하는 것이었습니다.

Origo는 아직 공개 베타 단계가 아닙니다. 저는 raeduslabs.com과 Dev.to에 제품이 출시됨에 따라 빌드 로그를 게시하고 있습니다. 만약 에이전트 기반 워크플로우 (agentic workflows)로 개발하다가 흥미로운 점을 발견하신다면 여기에 답글을 달아주세요. 제가 아직 발견하지 못한 실패 유형이 무엇인지 항상 궁금합니다.