바이브코딩, 만들 수 있다고 끝이 아닙니다
바이브코딩 현실은 신기함에서 시작합니다. 말 몇 마디에 화면이 생기고, 버튼이 동작하고, 뭔가 돌아가는 걸 보면 “나도 개발자인가?” 싶은 순간이 오죠. 바이브 코딩의 구조적 한계(지시가 모호하면 AI가 엉뚱한 방향으로 가는 문제, 프로젝트가 커지면 유지보수가 어려워지는 문제)를 어떻게든 넘겼다고 해봅시다.
그다음에 만나는 벽은 기술이 아닙니다.
바이브코딩 현실: 기술을 더 쌓으면 될 줄 알았습니다
바이브코딩으로 이것저것 만들다 보면, 자연스럽게 이런 생각이 듭니다. 기능을 더 넣으면 되겠지. 코드를 더 깔끔하게 짜면 사람들이 쓰겠지. UI를 더 예쁘게 하면 반응이 오겠지.
제가 그랬습니다. 뭔가 안 되면 기술 쪽에서 답을 찾으려고 했어요. 새로운 기능을 붙이고, 구조를 바꿔보고, 더 나은 모델을 써보고. 돌이켜보면 이건 일종의 도피였습니다. 진짜 해야 하는 일(이 서비스를 누가 왜 쓸 건지 생각하는 일)은 코딩보다 막막하거든요. 코딩은 적어도 뭔가 움직이니까 “나 지금 일하고 있다”는 착각을 주는데, 수요를 찾는 건 그런 피드백이 없습니다.
바이브코딩 현실에서 빠지기 쉬운 함정이 정확히 여기예요. 기술 자체를 개선하는 게 목적이라면 전혀 문제없습니다. 하지만 그걸로 돈을 벌고 싶다, 실제 사용자를 만들고 싶다. 그러면 오히려 코딩 비율을 줄여야 합니다.
스냅밈, 3개월 동안 1,900원
제가 직접 만들어서 출시한 서비스가 있었습니다. 스냅밈(SnapMeme)이라는 건데, 사람 사진을 올리면 배경을 자동으로 따고 밈 템플릿에 합성해서 움직이는 GIF로 만들어주는 서비스였어요.
만드는 과정도 재밌었고, 결과물도 꽤 괜찮았습니다. 무료로 밈을 만들어본 횟수가 130건이 넘게 쌓였으니까요. 사람들이 써보기는 했다는 뜻이에요.
문제는 유료 전환이었습니다. 계좌이체로 한 번에 1,900원을 받는 구조였는데, 3개월 운영하는 동안 결제는 딱 1건. 총수익 1,900원으로 끝났습니다.
130번 넘게 만들어봤는데 1명만 돈을 냈다는 건, 기술의 문제가 아닙니다. 기능이 모자라서가 아니에요.
있으면 좋은 것 vs 없으면 안 되는 것
사람들이 돈을 내는 건 재미있어서가 아닙니다. 자기 문제가 해결되기 때문이에요. 진짜 아프고, 불편하고, 시간을 잡아먹는 문제. 그걸 해결해주면 돈을 냅니다.
스냅밈은 장난감에 가까웠습니다. 한 번 써보고 웃고 끝나는 거죠. 공유할 때 재밌긴 한데, 그걸 위해 돈을 낼 사람은 거의 없어요. 제가 아무리 GIF 퀄리티를 올리고, 템플릿을 늘리고, 처리 속도를 빠르게 해봤자, 수요 구조 자체가 “있으면 좋은 것”이었으니까 기술로 뒤집을 수 있는 문제가 아니었습니다.
바이브코딩을 하든, 직접 코딩을 하든 이건 마찬가지예요. 수요가 없는 곳에 기술을 아무리 쌓아도 결과는 비슷합니다. 오히려 기술이 쉬워진 지금이야말로, 뭘 만들지를 고르는 눈이 더 중요해진 거죠.
본질이 먼저, 기술은 그다음입니다
돌이켜보면 스냅밈을 만들 때 저는 구조 없이 움직였습니다. 재밌는 기능이 떠오르면 그때그때 추가하고, 방향은 만들면서 정했어요. 기술적으로는 성장했지만, 서비스로서는 1,900원이 전부였죠.
이런 바이브코딩 현실을 겪고 나니 접근이 달라졌습니다. 이걸 왜 만드는지, 누가 쓰는지, 어떤 문제를 푸는지를 먼저 잡고, 기술은 그 본질을 실현하기 위해 붙여요. 순서가 바뀐 겁니다.
바이브코딩 현실에서 마주치는 진짜 한계는 코드를 잘 못 짜는 게 아닙니다. 코딩이 쉬워진 만큼, 뭘 만들지 고르는 일, 수요를 읽는 일, 자기 도메인을 깊게 파는 일. 이런 것들이 차이를 만듭니다. 코딩에만 매달리면 가장 중요한 질문을 건너뛰게 돼요. “이걸 누가 왜 쓰지?”
한 줄로 정리하면
바이브코딩으로 만들 수 있다는 건 시작이지, 끝이 아닙니다. 기술에 매달릴수록 정작 중요한 질문(수요, 본질, 방향)을 놓치게 됩니다. 도구가 좋아졌으니, 이제는 도구로 뭘 할지 생각할 차례예요.