2025년 한해 동안 바이브 코딩으로 50 여개의 서비스를 만들어 봤습니다. 첫번째 바이브 코딩을 했던 프로젝트부터 가장 최근에 만든 프로젝트까지의 이야기를 시간 순서대로 정리해본 글 입니다.
1/50
50개의 프로젝트 중 첫번째 프로젝트를 언제 시작했는지, 정확히 말할 수 있다. 바로 올 설날 연휴에 시작을 했기 때문에 언제 시작을 했었는지 까먹을 수가 없다.
이번 설 연휴는 길었고 그 기간 동안 구글 디자인 스프린트 프로세스를 진행해 보고 싶었다. 그래서 아내를 꼬셨고, 설 연휴 중 남는 4일 동안 집에서 디자인 스프린트를 진행 했다. 4일 뒤에 Prototype 버전까지 잘 완성이 되었고, 이제는 Prototype을 바탕으로 실제 Product를 만들어야 했다. 모든 직장인이 그렇듯이, 출근 → 일 → 퇴근 → 저녁 → 집안일을 하면 사실상 남는 시간은 1~2시간 남짓이었고, 할 수 있는 건 바이브 코딩 밖에 없었다. 그래서 그 때부터 한달동안 매일 1시간씩 Cursor랑 바이브 코딩을 시작했다.
그 때는 Agent Mode까지는 쓰지 않았던 것 같다(아마 없었던 듯?). 요소요소 하나하나씩 Cursor의 도움을 받아가며 만들었고, 매일 1시간 x 30일은 원하던 것을 완성하기 턱 없이 부족한 시간이었다.
그리고 그 때 처음으로 느겼다. 이 프로젝트의 bottleneck이 나라고. 회사에서 일하고 돌아온 나는 매번 Context switching에 시달렸고, 어제까지 뭘 작업 했었는지 파악하는데 한참이 걸렸다. 그렇게 파악하고 나서는 cursor에게 몇번의 prompt를 던지고 나면 1시간이 다 지나있었다.
결국 Product 출시까지는 못하고 테스트만 하다 끝나버렸다. 그래도 Google 계정 연동 기능을 Prompt 1~2번에 끝내고, 네이버 지도에서 Pin을 찍으면 그 지점의 위도, 경도 좌표를 가져오는 기능도 생각보다 쉽게 만든걸 보고는 조금만 더 좋아지면, 더 좋겠는데 라는 생각이 들었다.
바이브 비스타 코딩 클럽
“빨리 가려면 혼자 가고 멀리 가려면 함께 가라” 라는 명언처럼, 혼자 한달동안 하다보니 약간의 외로움을 느꼈고 지쳤다. 그리고 어차피 바이브 코딩을 하면, AI에게 Prompt를 던져놓고 결과가 나올 때까지 딴짓을 하는 시간이 많다. 그럴바에 같이 온라인으로 모여서 바이브 코딩을 하면 어떨까 하는 생각이 들었다. 예전에 모각코도 하고, 코로나 때는 온라인 모각코를 했던 것처럼 말이다.
그래서 매일 밤마다 Vibe Coding 하는 모임을 만들었다. 이름하여, Vibe Vista Coding Club. 모임의 규칙은 단순했다.
- 매일밤 10시에 모여서 30분 만에 각자 서비스 하나 만들고 공유하기
- 그렇게 주중에 만들어진 5개를 모아서, 주말에 MVP 제품까지 만들어서 출시하기
세상 모든 일은 보통 계획한대로 안된다. 그러나 “계획대로 안된다”라는게 모두 안 좋은 결과를 말하는 것은 아니다. 이 모임에서도 그랬다. 아무리 바이브 코딩이라도 30분 만에 뭐 하나 만들기 쉽지 않았고, 이걸 몇번하다보니 일단 아이디어를 짜는 것도 30분이 넘게 걸리는 일이 종종 있었다. 그러나 이 모임을 하면서 얻은 가장 소중한 교훈은 속도가 압도적으로 빠르니 정말 빠르게 많은 걸 해보고 테스트 할 수 있다는 것이었다.
새벽에 쓴 감성적인 글을 다음 날 아침에 읽었을 때 당황했던 적이 다들 있었을 것이다. 마찬가지로 엄청나게 좋은 아이디어라고 생각했던 것들을 시간 들여서 만들고 보니, 전날 새벽에 보낸 고백 문자마냥 나를 당황하게 하는 결과물이 나오는 경우가 꽤나 있다. 그러니까, 다 만들고 보니 “이게 아닌가벼…” 하는 경험 말이다. 그런 관점에서 바이브 코딩은 이런 문제를 꽤나 잘 해결했다. 월,화,수,목,금에 만든 것들 중에 이게 뭐지 하는 것들도 많았지만, 그 중 괜찮은 것들도 종종 있었다. 그리고 들인 시간이 적었기 때문에 10개 중 하나만 걸려도 크게 손해 볼 일은 아니었다.
Firebase Studio & Jules
바이브 코딩을 모임을 할 때 즈음에 Cursor에서 Firebase Studio로 옮겨 갔었다. Firebase Studio는 Prompt를 넣어서 프로젝트를 세팅하는 것부터 시작했고, 지금으로 치면 SPEC.md 혹은 RESEARCH.md 파일을 만드는 단계부터 시작해서 그 내용을 다듬고 확정한 다음에 개발을 시작 할 수 있었다. 폰에서도 어느 정도 만들 수 있어서, 점심시간, 시청역 근처 횡단보도 건너가는 1분 만에 탑글스라는 서비스의 MVP 버전도 만들었었다. 그리고 이 때부터 Agent Mode로 개발을 했기에, 사실상 나도 “해줘” 모드로 개발을 하기 시작했다.
그리고 비슷한 시기에 나온 Jules도 가끔씩 같이 썼다. 원격 VM에서 작업해 놓고는 ‘어떻게 보이는지 들어가서 확인해주세요’라고 하거나, Github에 PR을 안 보내놓고는 ‘만들어진 코드를 테스트해보고 결과를 알려주세요’라던가 하는 이상한 이야기를 하긴 했지만, 그래도 내 컴퓨터 건드릴까봐 걱정 없이, 원격에서 병렬로 개발을 시켜놓을 수 있으니 나쁘진 않았다. 둘 다 무료 이기도 하고.
그러다가, Claude Code가 나오면서 위에 언급했던 것들 전부 다 안 쓰게 되는데.
Claude Code
위에서 언급한 것처럼 바이브 코딩을 할 때, 실질적으로 겪는 가장 큰 문제는 Context Switching이다. 강의시간에 몰래 게임하는 대학생 마냥 강의가 잘 머리 속에 들어오지 않는다. 그리고 이건 우리가 똑똑해져서 해결 할 수 있는 문제가 아니다. AI가 더 똑똑해져야 하는 문제다.
이걸 해결해 준게 Claude Code 였다.
회사에서 혼자 개발해야 하는 프로젝트가 있었다. 이걸 하긴 해야 하는데, 다른 개발일들과 회의 등등의 인터럽트들이 많아서 온전히 개발에만 집중할 시간을 마련하기 어려웠다. 그 때 즈음에 Claude Code에 대한 찬사가 들려왔고 혹시나 하는 마음 반, 이것 말고는 방법이 없다는 마음 반으로, 그 프로젝트 개발을 Claude Code에게 맡겼다. 나는 얘가 만든 결과물만 보고 그 다음 지침을 내려줄 뿐, 내가 코드를 직접 안 짜는 방식으로. 그렇게 첫번째 MVP 버전까지 만들었고, 그 버전으로 무사히 Closed-beta 테스트까지 끝낼 수 있었다.
그렇게 Claude Code를 쓰면서 코딩 에이전트에 대한 놀라움을 느꼈다. 그리고 다른 한편으로는, Claude Code를 썼던 사람들이라면 모두 느꼈을,
“이제 개발자는 X 되었구나” 라는 양가적 감정을 느꼈다.지금도 이 정도로 잘하는데, 시간이 한달, 두달, 1년, 2년 지나면 얼마나 더 잘할까? 내가 과연 코드를 직접 손으로 짜는게 의미가 있을까? 그게 의미가 없다면, 나는 앞으로 무엇을 해야 할까? 남은 개발자의 일은 무엇일까? 그런 것이 남기라도 한걸까?
바칼라우
10년 전, 병특이 끝나자마자 대기업을 퇴사하고 스타트업 공동 창업을 했었다. 시드 투자를 받고 혼자 여행을 간 곳이 스페인과 포르투갈 이었다. 유럽대륙의 서쪽 끝인 호카 곶이, 콜럼버스 이후로는 새로운 대륙의 시작처럼 보이듯이, 나에게도 그 곳은 스타트업이라는 새로운 시작의 장소로 기억에 남아 있었다. 그리고 10년 만에, 이번에는 혼자가 아닌 아내와 둘이서 이곳에 다시 갔다.
다니던 회사는 퇴사를 하였다. 불안함이 가득했지만, 반년동안 AI를 써보면서 느낀 미래에 대한 불안함이 백수가 되는 불안함보다 훨씬 더 컸다. 불과 작년 연말까지만 해도 개발할 때, ChatGPT나 Copilot을 쓰면서 좋다고 느꼈다. 그 때는 코드 Snippet을 복붙하거나 보고 있는 Code block에 대한 코딩만 도와줬을 뿐인데도 말이다.
그런데 불과 몇달 만에 그 방식은 오래된 미래처럼 느껴졌다. 그리고 다가올 미래가 너무 자명해 보였다.
바칼라우는 소금에 절여 건조한 대구로 포르투갈의 국민 음식이다. 대항해시대에 멀리까지 항해하는 동안 먹을 수 있는 보존성이 좋으면서도 영양도 풍부한 음식이 필요했고, 그 때부터 바칼라우는 포르투갈의 국민 음식이 되었다.
신기하게도 바칼라우의 원재료인 대구는 포르투갈 바다에서 잡히지 않는다고 한다. 먼 바다인 북해까지 가야만 대구를 잡을 수 있고, 그 대구를 소금에 염장해서 가져온다. 포르투갈에는 없는 생선이지만, 포르투갈의 대항해시대를 만든 것이다.
어차피 미국이나 중국처럼 Foundation model을 만들 수 없다. 그러면, 그걸 수입해서 앞으로 뭘 할지는 고민하는게 더 좋을 것 같다. 시간이 지나서 바칼라우를 기억 하는 건, 위에 있는 저 사진 속 어부 정도 뿐 아닌가.
“바이브 코딩을 폰으로도 할 수 있을까?” 하는 마음에 여행을 떠나기 전에, 현지에서 바이브 코딩을 하기 위한 준비를 했었다. 첫번째로 홈페이지를 바이브 코딩으로 만들었다. 바이브 코딩으로 만든 서비스들 중에 기억에 남는 것들을 장소에 매칭 시켜서 표시하는 MapLog를 만들었다. 그리고 여행와서 만든 것들을 등록하기는 어려울테니, Admin 페이지도 오기 전에 만들어 놓았다.
그렇게 스페인과 포르투갈을 여행하며, 영감을 받을 때마다 폰으로 바이브 코딩을 했다.
물론 결과는 좋지 않았다. 아무리 바이브 코딩이라고 해도, 폰으로 할 수 있는 정도는 아니었다.
그러고보니, 이거랑 비슷한걸 했다가 실패를 했었는데 완전히 까먹고 있었다. 6월에 입코딩 대회 가서 옆사람이 말하는 내용이 내 Prompt에 들어가고 난리 법석이었는데, 폰으로 하는게 ‘입’만으로 하던 입코딩과 별반 다르지 않았다.
모나리자
파리에 있는 루브르 박물관에 간 사람들 중에 모나리자를 안 보고 온 사람은 없을 것이다. 루브르에는 커다란 대작들이 많은데, 그에 비해 유난히 작은 모나리자를 보려고 모인 사람들을 보면 그냥 구글 검색으로 보는게 더 좋겠다는 생각까지 든다.
그런데 레오나르도 다빈치는 저 작은 모나리자를 그리는데 얼마나 걸렸을까? 무려 14년 동안 그렸다. 1503년부터 그리기 시작해서, 1517년까지 무려 14년 동안 모나리자를 그렸다고 한다. 아니 저 작은 걸 14년이나 그렸으면, 우리가 아는 나머지 작품들은 14년을 뺀 나머지 기간 동안 그린 것일까? 모나리자만 아니었으면, 다빈치가 14년 동안 더 많은 작품들을 세상에 남길 수 있었을까?
모나리자가 걸린 총 기간만 14년 일뿐, 다빈치는 그 14년 사이에 다른 작품들과 연구들을 병행했다. 그러니까, 14년 동안 모나리자만 그리고 있던게 아니라, 모나리자는 다빈치가 동시에 작업하고 있던 여러 작품들 중 하나였을 뿐이다.
한발자국 떨어져서 그 동안 바이브 코딩을 하던 나를 바라보면, 저런 식으로 작업을 하고 있다는 것을 깨달았다.
메모, 습작, 단편, 장편
소설가들을 보면, 예전에 썼던 습작들이 나중에 단편 소설로 나오고, 또 단편 소설의 내용이 길어지고 풍성해져 장편 소설로 나오는 경우가 꽤 많다. 무라카미 하루키를 보면, 우리가 아는 <노르웨이의 숲>도 예전에 썼던 단편 <반딧불이>를 기반으로 써졌고, <해변의 카프카>도 몇몇 아이디어들이 예전에 썼던 단편들에서 이어져 있다.
예전에 썼던 메모가 습작이 되고, 습작이 단편이 되고, 단편이 나중에 장편 소설이 되는 것이다. 그렇게 보면, 메모부터 시작해서 장편 소설까지 완성 되는 기간을 모두 작품을 만드는데 걸린 시간이라고 말할 수 있지 않을까?
내가 바이브 코딩으로 만들고 있는 것들도 분류해보면, 메모에 가까운 15분짜리 바이브 코딩부터, 올 4월부터 만들기 시작해서 아직까지도 만들고 있는 중인 장편까지 다양하게 있다. 그리고 그렇게 여러가지 작업을 할 수 있다는게 바이브 코딩의 매력이 아닌가 싶다.
만든 결과물이 만족스러워서 GeekNews에도 올리고 커뮤니티에도 공개했던 대부분의 것들이 엄청 가볍게 아이디어를 내고 만든 것들이었다. 어떤 것은 심지어 자기 전에 샤워하다가 아이디어가 생각나서, 머리 말리고 잘 준비 하는 1시간 동안 다 만든 적도 있다.
50/50
내 홈페이지에 가보니, Marker가 20개 있었다. 그리고 바이브 비스타 코딩 클럽을 하면서 Prototype에서 끝난 프로젝트 20여개 정도 있다. 마지막으로 아직 개발 중 상태인 프로젝트까지 다 합치면 대략 50개 정도의 서비스를 만들었다.
첫번째 만들었던 프로젝트부터, 최근에 출시한 프로젝트를 보면 격세지감이 느껴진다.
- ViewingPub - 롤드컵 보다가 아이디어 생각나서 5일 개발하고 출시
- PickleClub - 하루 개발하고 출시
- GemBack v0.1.0 버전 - 1시간 개발하고 출시
- MyGeekNews - 5월 초에 하루 이틀 하다가 안되어서 묵혀두다가, 최근에 Antigravity로 하루 개발하고 출시
- 방송대 기출문제 - 3일 만에 만들고 출시. 시험지 업로드 하면, AI가 문제, 정답, 정답 해설을 추출해서 문제 등록하는 백오피스 기능까지 다 만듬
처음 바이브 코딩 할 때는 한달 내내 해도 출시까지 못 가던 것들이 이제는 아주 짧게는 1시간, 길면 일주일 내로 출시 할만한 퀄리티의 제품이 만들어 진다. 심지어 저렇게 짧은 시간동안 만든 프로젝트들도 admin 기능, dashboard 페이지, SEO 설정, GA 이벤트 등이 다 작업이 되어 있다. 예전이라면, 제품을 만드는데 진을 다 빼서 못했을 것 같은 기능들이, 이제는 AI 덕분에 오히려 더 놓치지 않고 넣을 수 있게 되었다.
우리는 무엇을 해야 할까? 그리고 무엇을 해야 하지 않아야 할까?
최근에 바이브 코딩을 하다가 막혔다며, 나에게 도움을 청해온 분이 있었다.
그 분에게는 팀프로젝트 과제가 있었고, 과제의 주제는 AI를 이용해서 교육적으로 도움이 되는 AI 서비스를 만드는 것이었다. 팀원들과 바이브 코딩으로 만든 결과물이라며 나에게 zip 파일 하나를 보내주셨다. 400kb 정도 되었을까. 거기에는 팀원 두 분이 각각 만든 프로젝트 2개가 있었다. 첫번째 프로젝트는 requirements.txt 파일도 없이 python 파일 3개가 달랑 있었고, 다른 프로젝트에는 frontend, backend, ai, ml, models 라는 하위 폴더가 있었다. 이 폴더들을 다 합쳐서 300kb가 안 넘었고, 그 중에서 가장 큰 파일은 “실행방법”이라는 폴더에 있던 ChatGPT 캡쳐 파일들이었다.
코드를 만든 건 ChatGPT였다. ChatGPT 채팅 창에서 바이브 코딩(?)을 진행 하셨고, ChatGPT는 그 코드를 “완벽한 계획이자, 완벽한 코드”라고 그 분들에게 이야기 했다. 그러니 그 완벽한 계획과 코드에서 발생하는 약간의 에러만 고쳐주실 수 없냐고, 그거 살짝만 도와주시면 안되냐고 이야기 하셨다.
도무지 이걸 어디서부터 말씀을 드려야 할지 어려웠다. 그러면서도 “ChatGPT가 이거 된다는데요”라고 하실 때마다, 스트레스를 받았다. 환자들이 자꾸 ChatGPT가 말해준 내용을 캡쳐해서 들고 와서 스트레스 받는다는 의사들의 마음이 이러할까?
그러나 한편으로는 “우리가 무엇을 해야 할까?”라는 질문에 한가지 힌트를 더 수집했다는 생각이 들었다. 아직 우리가 해야 할일이 남아있었다. 그리고 그 일에 집중하기 위해 앞으로는 해야 하지 않아야 할일이 무엇인지도.
그렇게 2025년을 지나가고 있다. 2026년 이맘 때 즈음엔, 또 다시 이 글을 보며 격세지감을 느끼겠지.
—
ps. 바이브 코딩 방식이 잘하는 것, 잘하지 못하는 것, 그리고 Tip에 대한 내용도 같이 담으려고 했는데 글이 너무 길어져서 잘랐습니다. 해당 글은 조만간 정리해서 다시 올릴 예정입니다.