코드도 읽지 않고 프로덕션 iOS 앱을 출시했다: “Vibe Coding”의 현실

발행: (2026년 1월 8일 오후 05:03 GMT+9)
11 min read
원문: Dev.to

I’m happy to translate the article for you, but I need the actual text of the post. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown, and any technical terms.

“AI 에이전트 시대”는 지치게 한다 – dumppp라는 네이티브 iOS Notion 클라이언트를 만든 나의 여정

2025년 말, 일본 개발자 커뮤니티에서 “AI 에이전트 시대가 실제로는 지치게 한다”는 논의가 바이럴하게 퍼졌다. 나는 깊이 공감했다. 이 글의 제목이 반대 의미처럼 보일 수 있지만, 끝까지 읽으면 왜 이 새로운 시대가 이렇게 힘든지 이해하게 될 것이다.

이 글은 dumppp, 네이티브 iOS Notion 클라이언트를 코드 한 줄도 읽지 않고 AI 에이전트를 활용해 출시한 이야기를 담고 있다.

Note: 이 글에서는 깊게 읽지 않고 AI로 코딩하는 과정을 **“Vibe Coding”**이라고 부른다.

오케스트레이터가 겪는 “고통”

“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와 함께 재시도하면서 (이하 내용은 다음 파트에 이어진다)

over, only to have it repeat the same mistake because my intent didn’t land, brings a unique kind of mental fatigue—different from the fatigue of writing code.

The Solution: SDD (Specification‑Driven Development)

To survive this chaos I arrived at SDD using SpecKit:

  • AI Generates Specs – Before writing code, I had the AI write detailed Markdown specifications.
  • Human Reviews / Approves – I scrutinised the specs, discussed them with another AI, and finally gave the “OK.”
  • Implementation via Claude Code – The approved spec became the single source of truth for the AI to implement.

This almost entirely solved the problem of the AI “hallucinating” its own logic. As long as the human holds the spec, the fluctuations of Vibe Coding are drastically reduced.

Mobile‑Optimised DX

  • GitHub Issues & Actions – Creating an issue from my iPhone triggers Claude Code on GitHub Actions to automatically create PRs for both specs and code. I can develop without ever touching a terminal.
  • Development Anywhere – This environment let me refine specs and implementation during bus rides, in the bath, or in bed.
  • The Backpack Deploy Machine – For physical‑device deployment I kept a MacBook in my backpack, connected via tethering, and used Tailscale for remote access. I solved the build process with brute force using Termius.

Leveraging AI Beyond Code

I used AI for everything, including marketing. The most interesting hack was using NotebookLM to turn my specs into a podcast. By listening to an AI‑generated discussion of my own strategies while doing dishes or laundry, I could spot logic holes or flawed monetisation plans from a “third‑party” perspective. Sometimes I’d even ask it to just “praise this project to the moon” to recover my motivation (lol).

결론

Vibe Coding이라는 iOS 앱을 만들면서 AI 개발의 놀라운 잠재력을 배웠지만, 동시에 숨겨진 비용도 드러났습니다: 본래 자율적인 시스템을 혼자서 조율해야 하는 정신적 부담. Specification‑Driven Development 로 전환하면서 나는 정신적 안정을 되찾았고, 환상( hallucinations) 현상을 줄였으며, AI의 속도를 활용하면서 부작용에 휩싸이지 않는 워크플로우를 구축했습니다.

전체를 Vibe 방식으로 진행하고 싶다면 기억하세요: AI가 코드를 작성할 수는 있지만, 제품에 대한 소유권은 여전히 여러분에게 있습니다.

이는 **“삶이 쉬워진다”**는 의미가 아닙니다.

코드를 읽고 쓰는 고통이 단순히 사양을 검토하고 끊임없이 결정을 내리는 고통으로 옮겨갔을 뿐입니다.

그럼에도 생산성은 단순한 “효율성”을 넘어선 수준으로 향상되었습니다. 개발 외의 일에 더 많은 시간을 할애할 수 있게 되었죠. 엔지니어로서 코드를 직접 작성하는 즐거움을 알고 있지만, 저는 AI‑주도 개발이 새로운 시대의 즐거움이라고 믿습니다. 자신의 역할을 깨는 것에 “알레르기”를 느끼는 것은 자연스러운 일이며, 스스로 코드를 작성하고 싶었던 순간도 수없이 많았습니다.

이 경험을 통해 앞으로 나아갈 길은 AI를 단순한 도구가 아니라 “파트너” 로 대우하고, 인간은 “지휘자” 라는 규율을 유지하는 것임을 깨달았습니다.

먼저 AI‑에이전트 규칙과 사양을 신중히 작성하세요. 그 다음에는 혼자서는 도달할 수 없었던 새로운 풍경이 여러분을 기다리고 있습니다.

이 실험의 결과를 확인해 보세요:

https://dumppp.com/

Back to Blog

관련 글

더 보기 »

기술은 구원자가 아니라 촉진자다

왜 사고의 명확성이 사용하는 도구보다 더 중요한가? Technology는 종종 마법 스위치처럼 취급된다—켜기만 하면 모든 것이 개선된다. 새로운 software, ...

에이전틱 코딩에 입문하기

Copilot Agent와의 경험 나는 주로 GitHub Copilot을 사용해 인라인 편집과 PR 리뷰를 수행했으며, 대부분의 사고는 내 머리로 했습니다. 최근 나는 t...