시니어 iOS 개발자를 위한 바이브 코딩 (Vibe Coding) - 4개월 동안 10개의 앱을 출시하며 얻은 6가지 교훈

2026년 2월 초에 저는 App Store에 라이브된 iOS 앱을 단 하나만 가지고 있었습니다. 5월 말인 지금 이 글을 쓰는 시점에는 10개의 앱과 지속 가능한 작업 패턴을 갖게 되었습니다. 약 4개월 동안 혼자서, 제 Mac과 커피숍에 있을 때 사용하는 iPad를 활용해 10개의 앱을 구축했습니다.

이 포스트에서는 이 스프린트(Sprint)로부터 실행 가능한 통찰(Actionable insights)을 추출해보고자 합니다. 이 글은 제가 좋아하는 커피숍에서 Claude를 사용하여 iPad로 iOS 앱을 바이브 코딩(vibe coding)하는 방법에 대해 쓴 긴 포스트의 보완적인 성격으로, 더 작고 집중된 내용을 담고 있으며, 해당 포스트에서는 저의 설정과 실제 프로세스를 설명했습니다. 이번 글은 시작 단계에서는 보이지 않았지만, 동일한 일을 시작하려는 사람들에게, 특히 이미 소프트웨어를 출시하는 방법을 알고 있는 사람들에게 유용할 수 있는 내용에 관한 것입니다. 이것은 초보자나 코딩을 배우는 사람들을 위한 것이 아니라, 특히 시니어 개발자를 위한 바이브 코딩(vibe coding)에 관한 노트입니다.

대상 독자

시중에 나와 있는 대부분의 바이브 코딩(vibe coding) 콘텐츠는 코딩을 한 번도 해본 적 없는 사람들을 위해 작성되었습니다. 그것은 빠르게 성장하고 있는 정당한 타겟층이지만, 저는 여기서 그들을 대상으로 하지 않습니다. 시니어 개발자를 위한 바이브 코딩(vibe coding)은 완전히 다른 주제이며, 그것이 제가 이 글을 통해 나아가고자 하는 방향입니다. 이상적으로, 당신은 코딩을 배우기 위해 AI를 사용하는 것이 아닙니다. 당신은 이미 수년 동안 그 일을 해왔습니다. 당신은 단지 이미 할 줄 아는 일을 위임(Delegating)하고 있을 뿐이며, 그 위임 기술이 바로 새로운 부분입니다.

아래의 가이드라인은 제가 2월 초의 과거의 저에게 보내고 싶은 내용들입니다. 이 가이드라인은 당신이 언어와 코딩 플랫폼을 알고 있으며, 기본적인 프로세스에 숙달되어 있다고 가정합니다.

1. 두 개의 모델을 사용하라

제 워크플로우(Workflow)를 가장 많이 개선한 변화는 두 개의 모델을 병렬로 실행하는 것이었습니다. 주 모델로는 Claude Code를, 백업으로는 OpenRouter를 통해 접속하는 MiniMax M2.7을 사용했습니다.

역할 분담은 다음과 같습니다:

Claude Code는 아키텍처(Architecture), 에이전트 루프(Agentic loops), 사양 해석(Spec interpretation), 그리고 프로젝트 전체를 컨텍스트(Context)에 유지해야 하는 모든 작업을 처리합니다. 메모리 파일(Memory files), 제네시스 프롬프트(Genesis prompts), 테스트 및 버전 관리(Versioning) 접근 방식 등이 여기에 해당합니다.

MiniMax M2.7은 리팩터링 (refactors), 보일러플레이트 (boilerplate) 작성, 복잡한 코드베이스에 대한 제2의 의견 제시 (팀 내 코드 리뷰 담당자처럼 활용), 그리고 Claude 할당량 (quota)을 모두 소모했을 때의 백업 용도로 사용됩니다.

Claude Code Max는 월 100달러인 반면, MiniMax 2.7은 Token Plan 기준 월 20달러로, 백업 모델로 사용하기에 충분하고도 남는 가격입니다 (정말 필요하다면 메인 모델로 사용할 수도 있겠지만, 여유롭지는 않을 것입니다). 가격 외에 이 방식을 사용하는 주된 이유는 연속성 (continuity) 때문입니다. Claude Code가 쓸데없는 작업에 토큰의 절반을 써버리는 바람에, 중요한 기능 구현 도중에 토큰이 바닥나 흐름이 끊기는 상황은 매우 의욕을 저하시키는 경험이기 때문입니다.

이것은 시니어 개발자를 위한 바이브 코딩 (vibe coding) 가이드라인 중 가장 단순하면서도 제가 가장 먼저 실행에 옮길 원칙입니다. 바로 최소 두 개의 모델을 사용하되, 명확한 분리 접근 방식 (clean separation approach)을 취하는 것입니다.

2. 근본부터 최적화하기 (Optimize At the Root)

제 코딩 세션에서 발생하는 대부분의 마찰 (friction)은 결국 첫 번째 프롬프트의 불충분한 명세 (underspecification)로 거슬러 올라갑니다. 여덟 번째 턴에서 나오는 모든 "사실, 이것도 추가로..."라는 말은 대개 첫 번째 턴이 충분히 명확하지 않았다는 신호입니다.

그래서 저는 코드가 작성되기 전에 앱을 설명하는 단일 제네시스 프롬프트 (genesis prompt)를 고안했습니다. 앱 이름, 번들 ID (bundle ID), 수익 모델 (monetization model), 기술 스택 (tech stack), 아키텍처 (architecture), 파일 구조 (file structure), 컬러 팔레트 (color palette), 인앱 결제 (IAP) 제품 ID, App Store 메타데이터 등 모든 것을 하나의 문서에 담습니다. 제가 사용하는 프롬프트는 iOS App Genesis Mega Prompt로 오픈 소스로 공개되어 있습니다. 이 프롬프트는 23개의 섹션으로 구성되어 있으며, 기본적으로 범용 템플릿 역할을 합니다. 실제 앱의 기능만 정의하면 되는데, 이는 Claude 채팅이나 사용 중인 에이전트 (agent)에서 정의할 수 있습니다. 그런 다음 그 내용을 제네시스 프롬프트에 넣고, 이 혼합된 정보를 Claude Code에 입력합니다. 대부분의 경우, Claude Code는 첫 번째 패스 (first pass)에서 작업의 95%를 수행할 수 있습니다.

제네시스 프롬프트 (genesis prompt)에 소비하는 시간은 프로젝트에서 가장 높은 레버리지 (leverage)를 가집니다. 한 시간 동안 신중하게 명세 (spec)를 작성하는 것은 세션 중간에 발생하는 하루 치의 수정 작업을 방지합니다. 모델이 당신의 작업 이력, 경험, 기술을 알고 있다고 가정하지 마세요. 좋은 정보를, 초기에 제공하십시오.

3. 정신적 모드 (Mental Mode)를 가볍게 유지하라

모든 프로젝트를 머릿속에 담아두려 한다면, 이 정도 속도로 제품을 출시하는 것은 지속하기 어렵습니다. 그렇게 하기에는 정신적 용량 (mental capacity)이 턱없이 부족합니다. 저는 이를 고통스럽게 배웠습니다. 결국, 저는 제가 어느 순간에 어떤 정신적 모드에 있는지 알 수 있는 외재화된 (externalized) 방법이 필요하다고 결정했습니다.

제가 이를 위해 사용하는 프레임워크는 Assess-Decide-Do입니다. 이는 제가 15년 동안 가르쳐 온 방법론을 기반으로 구축된 메가 프롬프트 (mega prompt)입니다. 요약하자면 이렇습니다: 당신은 어느 순간이든 세 가지 모드 중 하나에 있습니다. 당신은 평가 중이거나 (assessing: 상태가 어떠한가? 선택지는 무엇인가?), 결정 중이거나 (deciding: 어떤 선택지를, 어떤 비용으로 택할 것인가?), 또는 실행 중입니다 (doing: 선택한 옵션을 실행함). 흔한 실패 사례는 이 세 가지를 동시에 하는 것입니다. 이것을 동시에 진행하는 10개의 프로젝트에 곱하면, 당신은 자유 낙하하게 됩니다.

Assess-Decide-Do 스타일의 Claude Code로 세션을 시작할 때, 저는 우리가 즉시 어떤 모드에 있는지 알 수 있으며, 특정 순간에 제가 원하는 정신적 모드로 모델을 조종할 수 있습니다. "앞으로 20분 동안은 Assess 모드입니다. 코드를 작성하지 말고, IAP (In-App Purchase) 레이어에 대한 트레이드오프 (trade-offs)만 모델링하세요." 또는, "호흡 동기화 (breath-sync) 기능에 대해 Do 모드로 들어갑니다. 명세는 확정되었으니 구현만 하세요. 완료되면 알려주세요."라고 지시할 수 있습니다. 이 프레임워크는 저에게 하는 것과 똑같은 역할을 AI에게도 수행합니다. 즉, 올바른 다음 행동을 명명해 주는 것입니다.

이것이 정신적 모드를 가볍게 유지한다는 것의 실제 의미입니다. 어떤 규칙 세트를 암기하는 것이 아니라, 당신의 프로세스 위에 견고한 인지적 프레임워크 (cognitive framework)를 덧씌워 당신과 에이전트 (agent)가 동기화되도록 하는 것입니다.

4. 구축 시간은 줄이고, 검증 시간은 늘려라

AI가 코딩을 수행함에 따라, 구축(building)에 소비되는 시간은 줄어듭니다. 그에 비례하여 검증(verifying)에 소비되는 시간은 늘어나야 하며, 이것이 바로 대부분의 시니어 개발자들이 뒤늦게 깨닫는 조정 사항입니다. 실제 작업이 이루어지는 위치가 이처럼 변화한다는 점이, 시니어 개발자들이 바이브 코딩 (vibe coding)을 실천할 때 가장 당혹감을 느끼는 부분입니다.

현재 저의 비율은 대략 30%의 명세(spec), 20%의 생성(generation), 50%의 검증(verification)입니다. 주요 기능 구축이 끝날 때마다 다음 과정을 거칩니다: diff를 주의 깊게 읽고, 빌드(build)를 실행하며, 해당 모델이 만들어낼 수 있는 특정 실패 모드(failure modes)를 스캔하고, 모든 것을 문서화한 뒤에야 다음 단계로 넘어갑니다.

검증이 예전보다 더 중요해진 이유는 컨텍스트 드리프트 (context drift) 때문이며, 이는 긴 세션(session)에서 발생하는 주요 위험 요소입니다. 한 세션 내에서 더 많은 코드가 생성될수록, 모델의 어텐션 (attention)은 이미 생성된 내용들 사이로 희석됩니다. 세션이 길어질수록 이러한 문제의 빈도와 영향력은 다음과 같이 증가합니다:

• 동일한 세션 내에서 이전에 구축된 무언가를 조용히 망가뜨림
• 초기 프롬프트 (genesis prompt)의 제약 조건을 잊어버림
• 방금 수행한 수정을 다시 퇴보시킴 (regression)
• 아무도 요청하지 않은 방향으로 작동 중인 파일을 "개선"함 (솔직히 말해서 이 부분은 정말 미칠 것 같습니다)

제 경험상, 집중적인 세션의 3~4시간 차에 접어들면 무언가를 하는 시간보다 되돌리는 데 쓰는 시간이 더 많아집니다. 컨텍스트 드리프트가 추가적인 생성 작업이 이루어질 때마다 복리로 쌓이기 때문입니다. 효과적인 방법은 다음과 같습니다: 더 짧은 세션, 공격적인 커밋 (commit), 의도적으로 시작하는 새로운 컨텍스트, 지금까지 구축된 모든 것에 대한 철저한 문서화, 그리고 모든 생성물에 대한 검토입니다.

만약 여러분이 (거의 모든 시니어 개발자가 그러하듯) 모든 코드를 직접 한 줄씩 써 내려오며 성장했다면, 이미 검증 반사 (verification reflex)를 갖추고 있을 것입니다. 여러분은 단지 그 반사 신경을 자신의 오타가 아닌 모델의 드리프트 (drift)로 향하게 하기만 하면 됩니다.

5. 자연스럽게 느껴지는 시점보다 더 일찍 마케팅으로 전환하라

구축 단계가 압축되면, 병목 현상 (bottleneck)은 앞 단계로 이동합니다. 이전에는 가장 중요한 질문이 "앱이 완성되었는가?"였다면, 이제는 "이 앱이 존재한다는 사실을 누군가 알고 있는가?"가 됩니다.

이제 저는 제네시스 프롬프트 (genesis prompt)가 확정되는 즉시, 코드를 작성하기도 전에 ASO (App Store Optimization, 앱 스토어 최적화) 스캐폴드 (scaffolds) 작업을 시작합니다. 키워드 조사를 포함한 앱 이름 후보군, 부제목 변형, 스크린샷 카피, Applyra가 A/B 테스트를 진행할 첫 세 세트의 키워드 필드, 그리고 Product Hunt를 위한 한 줄 피치 (pitch) 등이 포함됩니다. 앱 빌드와 마케팅 빌드는 거의 병렬적으로 진행됩니다.

마케팅 또한 이제 자체적인 툴링 (tooling)을 갖추고 있습니다. dragosroua.com을 WordPress에서 Astro로 마이그레이션하는 동안, 저는 콘텐츠 작업을 위한 Claude Code 기술 세트를 구축했습니다. 여기에는 SEO 메타데이터 일괄 업데이트 도구, 배치 전략을 포함한 CTA (Call To Action, 행동 유도) 주입기, 그리고 고립된 페이지 (orphan pages)를 찾아내는 링크 분석기가 포함됩니다. 이 도구들은 오픈 소스로 공개되어 있습니다.

핵심은 이러한 특정 기술들이 아닙니다. 원칙의 문제입니다. 앱을 출시하는 것과 동일한 규율과 접근 방식이 앱을 둘러싼 마케팅 인프라를 구축하는 데에도 적용되어야 한다는 것입니다. 콘텐츠, ASO, 그리고 배포를 위한 기술, 프롬프트, 스캐폴드는 제네시스 프롬프트 이후가 아니라, 그와 나란히 존재해야 합니다.

시니어 개발자의 본능은 제품을 잘 만들고 그것이 스스로를 증명하게 두는 것입니다. 하지만 빌드 시간이 압축되고 (모두에게 점근적으로 0에 수렴하고 있는 상황에서), 그러한 본능은 다운로드 수가 없는 앱을 만들어낼 뿐입니다. 이제 더 희소한 자원은 코딩이 아니라 주의력 (attention)입니다. 따라서 마케팅이 중요합니다.

6. 모든 앱을 실험으로 취급하라

이러한 포트폴리오 접근 방식 — 혹은 제가 부르는 방식대로라면 "앱 생태계 (ecosystem of apps)" — 는 앱이 의미 있는 결과를 내지 못할 때, 그것을 최종 제품이 아닌 기본적으로 하나의 실험으로 취급하며 빠르게 다음 단계로 넘어갈 수 있을 만큼 가볍게 유지한다면 효과를 발휘하는 경향이 있습니다.

제 경우에는 월간 수익이 Zen Tales, addTaskManager, MosquiGo와 같은 두세 개의 앱에 집중되어 있습니다. 나머지 앱들은 각각 한 달에 몇 달러 정도를 법니다. 만약 제가 단 하나의 앱에만 집중했다면, 그것은 정말 운에 맡기는 일이었을 것입니다. 맞히느냐 틀리느냐의 문제였겠죠. 하지만 각 앱을 하나의 실험으로 취급함으로써 매주 ASO (App Store Optimization), 수익화 (Monetization), 카테고리 역학 (Category Dynamics), 그리고 사용자들이 실제로 어떤 기능에 비용을 지불하는지에 대한 매우 유용한 데이터를 얻을 수 있습니다. 덕분에 저는 가볍게 유지할 수 있고, 더 나은 무언가로 매우 빠르게 피벗 (Pivot) 할 수 있습니다.

바이브 코딩 (Vibe Coding) 작업을 수행하는 시니어 개발자에게 적합한 대사 작용 (Metabolism)은 다음과 같습니다: 빠르게 출시하고, 정직하게 측정하며, 각 앱에 대해 독립적으로 승부수를 던지거나(Double down) 미련 없이 떠날 준비를 하는 것입니다. AI가 구축 비용을 낮추었기 때문에, 프로젝트를 포기하는 비용 또한 낮아졌습니다.

나의 10개 앱과 각 앱이 요구한 것들

다음은 이번 4개월간의 스프린트(Sprint)를 통해 나온 실제 라인업이며, 각 앱이 저에게 해결하도록 강요했던 구체적인 코딩 과제들입니다.

addTaskManager — ADD (주의력 결핍 장애) 프레임워크를 기반으로 구축된 생산성 앱. 과제: iOS, iPad, Mac 간의 CloudKit 동기화; 사용자가 어떤 모드에 있는지에 따라 UI를 제어하는 Realm 상태 머신 (State Machine); 그리고 앱 내의 실제 데이터를 통해 사용자의 정신 상태를 추론하는 Zen Status 기능. 이것은 제가 이미 가지고 있던 앱이었으며, 바이브 코딩 스프린트 과정에서는 주로 다른 앱으로부터의 가져오기(Import)와 같은 기능들을 추가하는 작업이 포함되었습니다.

MosquiGo — 초음파 모기 퇴치기. 과제: AVAudioSession 제약 조건 하에서 백그라운드에서 안정적으로 실행되는 주파수 엔진, 그리고 소리가 몇 시간 동안 효과를 유지할 수 있도록 하는 항적응 (Anti-habituation) 패턴.

AI Kiddo First Words — 8개 언어로 배우는 아이들의 첫 단어. 과제: 일본어와 한국어를 포함한 완전한 현지화 (Localization), 아동 안전을 고려한 TTS (Text-to-Speech) 라우팅, 그리고 돌쟁이 아이가 실제로 사용할 수 있을 만큼 단순한 UI.

Zen Tales — AI 성찰이 포함된 불교 이야기. 도전 과제: 앱 용량을 늘리지 않으면서 TTS (Text-to-Speech)로 이야기를 생성하고, 비용을 세심하게 관리하며 실시간 AI 성찰을 구현하는 동시에 UI를 극도로 단순하게 유지하는 것.

Just 5 Words — 5개의 단어를 선택하면 AI가 이야기와 이미지를 생성합니다. 도전 과제: Apple Intelligence의 Writing Tools 및 Image Playground를 통한 완전한 온디바이스 (on-device) 생성. 백엔드 없음, API 키 없음, 네트워크 왕복 (network round-trip) 없음.

Light Njoy — 아이폰을 분위기 있는 조명으로 활용합니다. 도전 과제: 다섯 가지의 뚜렷한 렌더링 레이아웃 (오로라 밴드, 방사형 펄스, 리퀴드 미트볼, 풀 글로우, 그리드), 자연어를 통한 AI 생성 컬러 팔레트, 호흡 동기화 햅틱 (haptics), 그리고 조명 시퀀스 공유를 위한 커스텀 .njoy 파일 형식 구현.

Hacking Habits — 나의 Gravitational Habits 전자책의 동반자 역할을 하는 금융 회복력 습관 앱. 도전 과제: 습관 그래프 (habit-graph) 데이터 모델, dragosroua.com에 있는 기존 Hacking Habits 허브와의 통합, 그리고 ADHD (Attention Deficit Hyperactivity Disorder) 중심의 사용자 흐름 (user flows) 설계.

Flight Lens — AI 기반 항공 지능 서비스. 도전 과제: 항공 API 글로벌 폴링 (polling), Pulse 이상 지수 (anomaly index) 계산, Apple Intelligence를 이용한 항공 이벤트 요약, 그리고 Travelpayouts 통합.