바이브 코딩(Vibe Coding)이라는 단어가 등장한 지 채 1년도 되지 않았지만, 이미 '실제로 써봤다'는 사람들의 경험담이 쏟아지기 시작했습니다. 그런데 대부분의 이야기는 두 극단 중 하나입니다. "AI가 다 해줬다"거나, "결국 쓰레기 코드만 남았다"거나. 실전에서 진짜 무슨 일이 일어나는지—어디까지 가능하고, 어디서 막히고, 어떤 판단이 필요한지—를 구체적으로 보여주는 이야기는 생각보다 드뭅니다.
최근 요즘IT에 올라온 '클로드 코드로 해외 송금 비교 서비스 만들어봤습니다'와 시니어 엔지니어가 이틀간 바이브 코딩을 실험한 dev.to 아티클은, 그 공백을 메워주는 드문 실전 사례입니다. 두 글은 배경도, 만든 것도, 사용한 도구도 다르지만—놀랍도록 같은 지점에서 수렴합니다.
실제로 무엇을 만들 수 있었나
송금 비교 서비스 사례부터 봅시다. 미국 거주 개발자인 필자는 Claude Code를 주 도구로, Gemini를 PRD 교차 검증에, Figma를 UI 설계에 보조로 활용해 '센드피컴페어'를 1인으로 몇 주 만에 출시했습니다. 결과물의 규모가 인상적입니다. 12개 이상 업체의 스크래퍼, 17개 서비스 모듈, 6개 자동화 워크플로우. Next.js + Supabase + GitHub Actions 조합으로 운영 비용은 도메인 제외 사실상 0원. AI 없이는 불가능했을 속도라는 데 이견이 없습니다.
시니어 엔지니어의 실험도 비슷한 결론에 도달합니다. auto-edit 모드를 켠 채 이틀 만에 드래그앤드롭, 인증, 태깅, 시각적 리디자인까지 갖춘 생산성 앱 'Dunzo'를 배포했습니다. 평소라면 각 단계에서 꼼꼼히 검토하며 몇 배 더 걸렸을 작업입니다. "속도는 real하다(The speed is real)"는 그의 표현이 압축적으로 요약합니다.
그런데, 어디서 막혔나
두 사례 모두 막히는 지점이 명확합니다. 그리고 그 지점은 코드 생성의 영역이 아니라 판단의 영역입니다.
송금 서비스 개발자는 이렇게 표현했습니다. "무지성으로 Yes를 클릭하는 시점이 오게 되는데, 이때가 가장 위험한 단계였다." AI가 제안하는 대로 승인을 반복하다 보면 프로젝트 구조의 일관성이 흔들리고, 중복 코드가 쌓이고, 디버깅 비용이 기하급수적으로 늘어납니다. 12개 업체의 서로 다른 수수료 구조(정액제, 정률제, 환율 내재형)를 하나의 비교 테이블로 정규화하는 DB 설계, 실시간 스크래핑과 정기 스크래핑 사이의 비용-유지보수 트레이드오프 결정—이런 문제들은 AI가 '이상적인 솔루션'을 제시할 수는 있어도, 실제 운영 맥락에서의 최선을 판단하지는 못했습니다.
시니어 엔지니어 쪽에서는 다른 각도의 관찰이 나왔습니다. AI는 Zustand, Zod, dnd-kit 같은 '훈련 데이터에 가장 많이 등장하는 도구'를 자연스럽게 선택했습니다. 합리적인 선택이지만, 그 선택이 현재 프로젝트의 맥락에서 최선인지는 별개의 문제입니다. Zustand 스토어는 의도적 설계 없이 점점 비대해졌고, 이를 인지하고 조율하는 것은 결국 개발자의 몫이었습니다.
프로토타이핑 → 검증 → 고도화, 이 흐름이 핵심이다
두 사례가 공통으로 보여주는 가장 중요한 패턴은 빠른 프로토타이핑이 검증의 기회를 앞당긴다는 점입니다. 송금 서비스 개발자는 출시 후 미국 한인 커뮤니티 '마일모아'에 제작기를 공유해 6,000회 이상의 조회수와 구체적인 사용자 피드백을 받았습니다. "다른 업체도 추가해달라