📖 지난 편 요약
Next.js + Vercel + Supabase 조합으로 10일 만에 첫 배포. Gemini CLI를 주력으로 바이브코딩을 진행했고, 디자인은 네 번 바꿨다. 보안 점검은 Claude Code, Codex, Gemini 세 곳에 동시에 돌렸고, 취약점 수정만큼은 Claude Code에게 맡겼다.
📋 이 글의 목차
바이브코딩, 4번 해보니 보이는 것들
FeeDraft가 처음 바이브코딩 프로젝트는 아니다. 이전에 세 개를 더 시도했다.
🗂️ 바이브코딩 프로젝트 이력
1번째 — 로또 번호 생성기
만들다 말고 폐기. 주니어 시절에 이미 손코딩으로 만들어본 적 있는 로직이라 흥미가 사라졌다.
2번째 — 할 일 목록 Task Manager
기획 단계에서 초안 작성 후 멈춰있음. 어떤 방향으로 가야 할지 아직 감이 안 잡힌다.
3번째 — 우리 가족 위치 공유 앱
기획 이상 구현됐으나 FeeDraft로 인해 잠시 중단. FeeDraft 마무리 후 재개 예정.
4번째 — FeeDraft
구상했던 기능들은 대부분 구현됨. 최종 보안 점검 및 미비점 처리 후 마무리 단계.
네 번 모두 공통점이 하나 있었다. 첫날에 첫 화면과 대략적인 기능들을 어느 정도 완성할 수 있었다. 이 부분만큼은 바이브코딩이 정말 놀랍도록 빠르다. 문제는 그 다음부터다.
프로그램을 확장하는 과정에서 시간이 계속 필요해진다. 정교하게 다듬는 시간, 오류를 잡는 시간, 검증하는 시간. 이 과정들이 만만치 않다. 딸깍 한 번으로 끝나는 게 아니라는 걸 직접 겪어봐야 안다.
자연어로 개발이 된다는 현실이 놀랍다
20년 가까이 개발을 해오면서, 아무리 작은 프로젝트라도 이렇게 빨리 끝나도 되나 싶은 불안함이 있다. 그게 이상한 게 아니다. 뭔가 빠뜨린 게 있는 거 아닐까 하는 직업적 본능이랄까.
그런데 막상 해보면, 머릿속에 있는 로직을 개발 언어 문법으로 작성하는 대신 그냥 말로 설명하면 된다는 현실이 아직도 놀랍다.
💬 실제로 이런 식으로 프롬프트를 쓴다
"이렇게 저렇게 구현해봐"
"나는 이런 기능이 필요한데, 어떤 식으로 진행하면 좋을지 제안해봐"
"오류 났어. 어디서 나는지 모르겠으니까 이 부분에 디버깅 코드 붙여줘"
[오류 메시지 전체 복붙] "이런 오류 나니까 수정해"
AI가 제안하는 방식에 1~10까지의 절차가 있다면, 내가 필요한 부분은 그대로 진행하고 원치 않는 부분은 다른 방식으로 수정을 요청하거나 직접 지시하면 된다. 이 과정이 쉽게 1번에 끝날 수도 있지만, 여러 번의 디버깅을 거쳐야 하는 경우도 많다.
개발자라면 이런 과정이 늘상 겪는 일이라 익숙하다. 문제는 이걸 처음 겪는 사람들이다.
"딸깍"이라는 말에 대하여
요즘 바이브코딩 관련 글을 보면 딸깍 한 번으로 서비스를 만들어 배포했다는 이야기들이 많다. 3시간 만에 앱 완성해서 배포했다는 글도 봤다. 솔직히 말하면 크게 믿음이 가지는 않는다.
🎵 문득 떠오른 비유
TV에서 작곡가들이 메가 히트곡은 5~10분 안에 작곡한다고 말하는 걸 본 적 있다. 그 5분이 작사·작곡·편곡·연주 모두를 포함한 시간일까? 아니면 메인 테마 멜로디 하나를 잡는 시간일까. 나는 전자라고 생각한다.
바이브코딩도 마찬가지다. 초안 프롬프트만 잘 작성하면 십여 분 안에 꽤 그럴싸한 첫 화면을 만들어 배포할 수 있다. 이건 사실이다. 그런데 그 프로그램이 오류 없이 동작하고, 필요한 모든 기능을 갖추고, 엣지 케이스까지 검증된 상태가 되려면 며칠이 걸려도 모자랄 수 있다.
✅ 딸깍으로 되는 것
· 첫 화면 구성
· 기본 기능 동작 확인
· 첫 배포 URL 생성
· 그럴싸한 외형
⏳ 시간이 필요한 것
· 오류 없는 안정적 동작
· 기능 확장과 연동
· 보안 점검 및 수정
· 엣지 케이스 검증
그리고 바이브코딩에는 또 하나의 특성이 있다. 초반에는 금방 되는 것 같다가, 어느 시점을 넘어가면 오류가 한 번 발생하면 해당 부분이 계속 꼬이는 경우가 생긴다. 기능 확장 요청이 아주 단순한 말 한마디처럼 보여도, 백단의 프로세스나 설계가 틀어지는 경우가 현실 개발에서도 비일비재하다. 확장성을 고려하지 않고 시킨 것만 처리하는 AI에게는 더욱 그렇다.
누가 딸깍 소리를 내었는가.
딸깍은 시작 소리다. 끝나는 소리가 아니다. 첫 화면을 띄우는 데 걸리는 시간이 짧아진 것이지, 제대로 된 서비스를 만드는 데 걸리는 시간이 사라진 건 아니다.
비개발자 바이브코더, 그들은 어떻게 헤쳐나가고 있을까
개발자인 나도 오류 하나를 잡는 데 디버깅을 여러 번 돌리고, 꼬인 로직을 푸는 데 예상보다 훨씬 긴 시간을 쓴다. 그리고 이런 과정들이 개발자에게는 익숙한 일상이다. 오류 메시지를 보고 어느 방향으로 접근해야 할지 감이 온다.
그런데 비개발자가 바이브코딩을 할 때 이런 상황을 만나면 어떻게 될까. 오류 메시지를 보고 어디서부터 실마리를 찾아야 할지 알 수 있을까. 이 부분이 아직도 진심으로 궁금하다.
🤔 비개발자 바이브코더에게 궁금한 것들
오류가 나서 멈췄을 때, 어떤 방식으로 문제를 파악하나?
기능 확장 요청 후 기존 기능이 망가졌을 때, 어디서부터 추적하나?
AI가 제안한 방향이 좋은 방향인지 나쁜 방향인지, 어떻게 판단하나?
물론 이런 단계들을 스스로 겪고 성장하는 비개발자 바이브코더도 있을 것이다. 그런 사람은 그냥 잘하는 사람이다. 배경이 개발자냐 아니냐를 떠나서. 다만 그게 일반적인 경우라고 보기는 어렵다고 생각한다. 바이브코딩이 진입 장벽을 낮춘 건 분명하지만, 그 장벽이 완전히 사라진 건 아니다.
FeeDraft, 지금 어디까지 왔나
구상했던 기능들은 대부분 구현이 됐다. 최종 보안 점검, 미비점 처리를 마치면 배포 완료라고 볼 수 있는 단계다. 그런데 한 가지 아직 해결 못 한 숙제가 남아있다.
✅ 구현 완료
· RSS 피드 수집 및 관리
· 키워드 / 카테고리 관리
· 핀 고정 / 읽음 처리
· AI 초안 작성 기능
· 회원가입 후 찍먹 체험
· 데이터 자동 삭제 처리
· 보안 점검 및 취약점 수정
🚧 미구현 / 예정
· 키워드 기사 자동 AI 초안 작성
· 노션 / 슬랙 / 텔레그램 내보내기
· 홍보 채널 확보
· 추가 보안 점검 1회 예정
💬 그래서, 어디에 홍보를 해야 하지?
배포 준비는 거의 다 됐는데 정작 이걸 어디에 알려야 할지가 아직 숙제다. 아무에게도 알려지지 않은 서비스. 기능을 만드는 것과 사람을 모으는 건 완전히 다른 게임이라는 걸 새삼 실감하고 있다.
4편의 연재를 쓰면서 이 프로젝트를 처음부터 다시 돌아봤다. 블로그 포스팅이 귀찮아서 시작한 일이 어쩌다 서비스가 됐고, 서비스를 만들다 보니 또 다른 고민이 생겼다. 바이브코딩이라는 도구 덕분에 이 모든 과정이 가능했다는 건 부정할 수 없다. 다만 그 도구가 마법은 아니라는 것도 분명히 말할 수 있다. 꾸준히 진행해야 한다. 그게 전부다.
🎉 SERIES COMPLETE
FeeDraft 개발일지 완결
4편 · "딸깍"으로 서비스 만든다는 말, 20년 개발자가 직접 해봤습니다 ← 현재 글
읽어주셔서 감사합니다. FeeDraft의 다음 소식도 이 블로그에서 계속됩니다.
CoLife
개발자 · code & life 블로그 운영
20년 가까이 개발자로 일하면서, 요즘은 AI 도구가 개발 방식을 어떻게 바꾸는지에 관심이 많습니다. 직접 바이브코딩 사이드 프로젝트를 진행하며 느낀 것들을 솔직하게 기록합니다.
📌 구독 & 공감
FeeDraft의 다음 소식과 새로운 개발 이야기는 계속됩니다.
블로그 구독을 누르시면 새 글 업로드 시 알림을 받을 수 있습니다. 공감 ❤️ 한 번이 큰 힘이 됩니다 🙏
'Vibe Coding devlog > FeeDraft' 카테고리의 다른 글
| Gemini CLI로 10일 만에 배포까지, 바이브코딩 실전기 — FeeDraft 개발일지 3편 (0) | 2026.04.30 |
|---|---|
| RSS 피드 수집기가 AI 초안 작성툴이 된 사연 — FeeDraft 개발일지 2편 (0) | 2026.04.29 |
| 블로그 쓰기 귀찮아서 앱을 만들었습니다 — FeeDraft 개발일지 1편 (0) | 2026.04.28 |
