'AI로 만들었다'는 말이 더 이상 놀랍지 않은 시대가 됐다. 그런데 흥미로운 건, 같은 Claude를 쓰면서도 결과물의 품질이 극단적으로 갈린다는 점이다. 최근 공개된 세 가지 실전 사례—2일 만에 풀스택 제품을 출시한 Factcovery 개발기, 극한 제약 환경에서 ShellSignal을 배포한 솔로 개발자의 기록, 그리고 'AI 의존 역설'을 직접 경험한 iOS 앱 제작기—는 그 차이가 어디서 오는지 꽤 선명하게 보여준다.
핵심 이슈: '바이브 코딩'과 '에이전트 코딩'은 다르다
dev.to에 올라온 Factcovery 개발기의 저자는 서두에서 이 구분을 명확히 짚는다. "ChatGPT에 '투두 앱 만들어줘' 입력하고, 오류 나면 오류 붙여넣고, 반복"—이게 바이브 코딩이다. 간단한 실험엔 괜찮지만, 웹 앱·REST API·모바일·CI/CD가 맞물리는 실제 제품에선 금방 무너진다.
그가 택한 방식은 달랐다. Claude를 코드 생성기가 아니라 설계 파트너로 사용한 것이다. 핵심 규칙은 단순하다: 영어로 계획한다 → 검토한다 → 그 다음에 만든다. 코드 한 줄 생성 전에 화면 목록, 사용자 흐름, 폴더 구조를 먼저 대화로 확정했다. 이 '5분짜리 계획'이 수 시간의 디버깅을 막았다고 그는 회고한다.
맥락 해석: 세 사례가 공통으로 가리키는 것
첫째, 계획 단계를 코드보다 먼저 확보한다. Factcovery 개발자는 모든 파트—NuxtJS 프론트, Django 백엔드, Flutter 앱, GitHub Actions CI/CD—를 시작하기 전에 반드시 텍스트 형태의 아키텍처를 먼저 받았다. "코드 아직 쓰지 마, 구조만 설명해줘"라는 프롬프트가 반복해서 등장한다. i18n, Lighthouse 최적화, 푸시 알림 시스템 모두 구현 전에 전략을 문서화했다.
둘째, 스택 선택 자체가 '1인 세금'을 결정한다. dev.to의 ShellSignal 개발기는 더 직접적이다. 나이지리아 호스텔, JUPEB 시험 기간, 제한된 데이터 요금제—이 극한 환경에서 Next.js + Supabase + Vercel을 선택한 이유는 명확하다. 인프라 설정, 인증 토큰 관리, 배포 파이프라인이라는 '세금'을 스택 차원에서 없애버리기 위해서다. Supabase의 Row Level Security는 라우트 핸들러 곳곳에 흩어질 인가 로직을 DB 레벨로 끌어내렸고, Vercel의 cron job은 별도 스케줄러 없이 JSON 설정 하나로 해결됐다. "결국 당신이 해결하려는 문제에 시간을 써야지, 그걸 담는 인프라에 시간을 써선 안 된다"는 그의 결론은 1인 개발자라면 뼈에 새길 만하다.
셋째, AI 의존의 역설을 의식적으로 설계한다. 브런치에 올라온 iOS 앱 개발기는 가장 솔직하다. 'AI에 대한 사고 의존'을 경계하기 위해 사고 연습 앱을 만들기로 했는데, 정작 그 앱을 Claude Code에 의존해서 만들고 있다는 아이러니를 저자 스스로 인정한다. 그가 택한 해법은 제약의 명문화였다. Claude.md로 iOS 개발 환경 제약을 설정하고, 세션당 태스크를 최소화하며, handoff 기반으로 학습을 누적했다. 디자인 판단력이 부족하다고 느낀 부분은 Mobbin 레퍼런스와 오픈소스 UI 컴포넌트로 여러 프로토타입을 만들어 가이드를 잡았다. AI를 쓰되, AI가 대신 판단하지 못하도록 경계를 설계한 것이다.
시사점: '출력 단위'가 아니라 '판단 구조'를 설계하라
세 사례를 관통하는 패턴은 하나다. AI의 출력 품질은 입력 설계가 결정한다. Factcovery 개발자가 "한 번에 다 만들어줘" 대신 "모델 먼저, 시리얼라이저 다음, URL 마지막" 순서를 지정한 것처럼, ShellSignal 개발자가 Supabase RLS로 인가 판단을 DB에 위임한 것처럼, iOS 앱 개발자가 Claude.md로 컨텍스트 경계를 설정한 것처럼—AI가 잘 작동하도록 구조를 먼저 설계하는 것이 개발자의 핵심 역할이 되고 있다.
또 하나 눈에 띄는 건 '피벗 판단'이다. Factcovery 개발자는 React Native로 시작했다가 애니메이션 성능이 기대에 못 미치자 Flutter로 전환했다. AI는 이 판단을 대신해줄 수 없었다. "AI가 느낌을 감지할 수 없다"는 그의 표현처럼, 제품이 충분히 좋은지 아닌지를 감각하는 것—이건 여전히 인간의 몫이다.
전망: 프로토타입 속도보다 '검증 루프'가 경쟁력이 된다
AI 도구가 보편화될수록 프로토타입을 빠르게 만드는 능력은 점점 평준화된다. 2일 만에 풀스택 제품을 만드는 것이 뉴스가 되는 지금은 과도기일 뿐이다. 다음 단계의 경쟁력은 얼마나 빨리 만드느냐가 아니라 만든 것을 얼마나 빨리 검증하고 고도화하느냐에서 갈릴 것이다.
세 개발자 모두 배포를 끝으로 이야기를 마치지 않는다. Factcovery는 App Store 심사 중이고, ShellSignal은 실제 사용자(저자 본인)의 문제를 해결하고 있으며, iOS 사고 연습 앱은 앱스토어 릴리즈를 향해 달리고 있다. 배포는 시작점이다. 그리고 그 시작점까지의 시간을 AI가 줄여주는 지금, 진짜 싸움은 그 이후에 있다.
1인 개발자에게 AI는 더 이상 '있으면 좋은 도구'가 아니다. 설계 파트너로 쓸 것인가, 단순 코드 자판기로 쓸 것인가—이 선택이 제품의 완성도를 가르는 시대가 이미 왔다.