코드를 읽지 않고 프로덕션 iOS 앱을 출시했다: “Vibe Coding”의 현실
I’m happy to translate the article for you, but I’ll need the full text of the post (the body of the article) in order to do so. Could you please paste the article’s content here? Once I have it, I’ll provide a Korean translation while keeping the source link and all formatting exactly as you requested.
“AI 에이전트 시대”는 지치게 한다 – 네이티브 iOS Notion 클라이언트 dumppp를 만들며 겪은 여정
2025년 말, 일본 개발자 커뮤니티에서 “AI 에이전트 시대가 실제로는 지치게 한다”는 논의가 바이럴하게 퍼졌습니다. 저는 그 의견에 깊이 공감했습니다. 이 글의 제목이 반대 의미처럼 보일 수 있지만, 끝까지 읽으시면 제가 왜 이 새로운 시대를 이렇게 힘들게 느끼는지 이해하게 될 것입니다.
오케스트레이터가 겪는 “고통”
“AI가 앱을 대신 만들어 줄 거야.”
몇 년 전만 해도 우리는 그런 SF 세계를 꿈꾸며 기뻐했었습니다. 이제 그 세계가 현실이 되었는데—어떤 느낌일까요?
솔직히 말해서: 정말 지칩니다.
AI 에이전트가 “개발자” 역할을 하며 번개처럼 코드를 뽑아낼 때, 인간은 오케스트레이터라는 역할에 100 % 책임을 떠안게 됩니다. “AI가 만들었으니 나는 모른다”는 변명이 통하지 않죠. 코드를 읽지 않더라도 동작, 사양 간 모순, 사용자 경험 품질에 대한 책임은 전부 여러분에게 돌아옵니다. “결정의 순수성”을 유지하려면 생각보다 훨씬 더 큰 정신적 체력이 필요합니다.
“스스로 부과한 제약” – 실험을 밀어붙이다
SF 꿈을 포기하고 싶지 않았습니다. 고난이도 프로젝트—iOS 앱 출시—를 완수하면 이 피로감의 본질을 파악하고 그 너머를 볼 수 있을 거라 믿었습니다. 그래서 dumppp에 다음과 같은 거대한 제약을 걸었습니다:
“코드를 읽지 않는다.”
빌드 오류는 한 번쯤 살펴볼 수는 있지만, 구현 세부 사항을 이해하려는 시도 자체를 근본적으로 포기했습니다. 왜냐하면 AI를 **“자율 구현자”**로서 얼마나 활용할 수 있는지 실험해보고 싶었기 때문입니다.
“Vibe Coding”을 진행하면서 저는 모든 자원을 다음에 집중했습니다:
- 요구사항 정의 – 어떤 문제를 해결하는가?
- 마케팅 – 어떻게 알릴 것인가?
- 수익 모델 – 어떻게 지속 가능하게 만들 것인가?
- UX 검증 – 실제 사용감은 좋은가?
또한 Swift를 사용한 네이티브 iOS 앱으로 만들기로 했습니다. 크로스‑플랫폼 프레임워크를 선택할 수도 있었지만, UX를 극대화하기 위해 네이티브 API를 고수했습니다. 네이티브 개발의 난이도가 높아지는 것이 바로 재미의 일부였습니다.
전체 Vibe Coding의 장점
제가 발견한 장점은 압도적입니다:
- 1인 “팀” – 저는 제품 소유자/오케스트레이터 역할을, AI는 개발팀 역할을 했습니다. 명확한 역할 분담 덕분에 대규모 병렬 처리가 가능했습니다.
- 미지의 기술 다루기 – OAuth, Notion API, StoreKit 2(구독), AppIntents, SwiftUI 등을 레퍼런스 매뉴얼을 열지 않고도 AI와의 대화만으로 구현했습니다.
- 초고속 글로벌화 – 6개 언어(JP, EN, CN, FR, DE)를 지원했습니다. 번역부터 구현까지 AI에게 맡기니 몇 분 안에 끝났습니다. 제가 목욕 중일 때 세 번째 언어를 추가한 것도 마법 같은 경험이었습니다.
단점: 피로감의 핵심
진짜 “고통”은 여기서부터 시작됩니다:
- “충분히 좋음”을 넘어선 지옥 – AI는 놀라운 속도로 약 60 % 수준까지 끌어올려 줍니다. 80 % 이상의 “프로덕션 준비” 품질—특정 조건에서만 나타나는 UI 미세 결함이나 오프라인 동기화 불일치 해결—에 도달하려면 코드를 읽지 않은 대가가 돌아옵니다.
- 4,000줄 “두꺼운 파일” 문제 – 엄격한 규칙이 없으면 AI가 모든 것을 처리하면서 파일 구분이 엉망이 됩니다. 최대 4 000줄에 달하는 거대한 파일이 생겼고, AI 자체도 큰 그림을 놓치기 시작했으며, 하나의 수정이 연쇄적인 회귀 버그를 일으켰습니다.
- 품질 보증의 함정 – “동작한다!”는 곧 다양한 엣지 케이스 버그의 연속이 됩니다. AI와 반복해서 수정 작업을 진행하지만 의도가 제대로 전달되지 않아 같은 실수를 반복하게 되면, 코드 작성 피로와는 다른 독특한 정신적 피로가 찾아옵니다.
해결책: Specification‑Driven Development (SDD)
이 혼란을 견디기 위해 저는 SpecKit을 활용한 SDD에 도달했습니다:
- AI
Source: …
Generates Specs** – 코드가 작성되기 전에 AI가 상세한 Markdown 사양을 생성합니다.
2. Human Reviews / Approves – 나는 사양을 면밀히 검토하고 다른 AI와 논의한 뒤 최종적으로 “OK”를 줍니다.
3. Implementation via Claude Code – 승인된 사양이 AI가 구현할 단일 진실 소스가 됩니다.
이렇게 하면 AI가 자체 논리를 “환각”하는 문제를 거의 완전히 해결할 수 있었습니다. 인간이 사양을 유지하는 한 Vibe Coding의 변동성이 크게 줄어듭니다.
Mobile‑Optimised DX
- GitHub Issues & Actions – iPhone에서 이슈를 만들면 GitHub Actions의 Claude Code가 자동으로 사양과 코드를 위한 PR을 생성합니다. 터미널을 전혀 건드리지 않고도 개발할 수 있습니다.
- Development Anywhere – 이 환경 덕분에 버스 안, 목욕 중, 침대에서도 사양과 구현을 다듬을 수 있었습니다.
- The Backpack Deploy Machine – 물리 디바이스 배포를 위해 백팩에 MacBook을 넣고 테더링으로 연결했으며, Tailscale을 사용해 원격 접근했습니다. 빌드 과정은 Termius를 이용해 무차별적으로 해결했습니다.
Leveraging AI Beyond Code
나는 마케팅을 포함한 모든 작업에 AI를 활용했습니다. 가장 흥미로운 해킹은 NotebookLM을 사용해 사양을 팟캐스트로 바꾸는 것이었습니다. 설거지나 빨래를 하면서 AI가 만든 내 전략에 대한 토론을 듣다 보면 “제3자” 시각에서 논리적 구멍이나 잘못된 수익 모델을 발견할 수 있었습니다. 때때로는 동기 부여를 회복하기 위해 AI에게 “이 프로젝트를 달까지 올려 칭찬해 줘”라고 요청하기도 했습니다 (ㅋㅋ).
Conclusion
Vibe Coding an iOS app taught me about the incredible potential of AI‑driven development—but it also revealed a hidden cost: the mental exhaustion of orchestrating an autonomous code‑generating partner. By anchoring the process in well‑crafted specifications (SDD) and building a mobile‑first development workflow, the fatigue becomes manageable, and the promise of the AI Agent era feels a little less exhausting.
“It won’t mean ‘life gets easy.’”
The pain of reading and writing code has simply shifted to the pain of scrutinizing specifications and making constant decisions.
Productivity, however, has risen beyond mere efficiency. I can now spend more time on things outside of development. While I still enjoy writing code, I believe AI‑driven development heralds a new kind of joy. It’s natural to feel “allergic” to breaking one’s own role, and there were countless moments when I wanted to write the code myself.
Through this experience, I’ve realized that the path forward is to treat AI not just as a tool, but as a “partner,” with the human maintaining the discipline of a “Conductor.”
- Start by writing your AI agent rules and specifications with care.
- Beyond that, a landscape you could never have reached alone is waiting for you.
Check out the result of this experiment here: