바이브 코딩, 마법 같은 단어입니다.

작년 11월, Windsurf를 켜고 Claude Sonnet 3.5에게 이렇게 말했어요.

Windsurf에서 시작해 Cursor를 거쳐

Cline, RooCode로 Claude API도 연결했습니다.

출시도 못 하고 접은 첫 프로젝트에만 30만 원이 나갔죠.

지금은 더 큰 비용을 들여 굴러가는 제품을 만들고 있지만,

그때의 실패 덕분에 배운 게 분명히 있어요.

예전에는 파이썬으로 크롤링 같은 걸 구현할 때,

스택오버플로우·구글 검색·깃허브 레포를 뒤져가며 해결했어요.

막히면 키워드를 바꿔가며 답을 찾아 붙였죠.

그런데 지금은 패턴이 달라졌어요.

검색 대신 ChatGPT와 AI IDE(Windsurf, Cursor 등)에 먼저 묻고,

나온 코드를 바로 돌려본 뒤 프롬프트로 수정·재시도를 반복하는 대화 중심 방식이 기본이 됐어요.

‘검색 중심 → 대화 중심’ 전환은, 생각했던 것보다 더 ‘지식 노가다’ 입니다.

올해 초 안드레이 카파시가 언급하며 ‘바이브 코딩’이라는 단어가 등장했습니다.

그리고 AI 모델 성능과 에이전트 도구의 기술이 발달하면서

“이제 누구나 개발할 수 있다.”는 분위기가 팽배해졌죠.

게다가 최근 Claude Code와 Claude 4 Family의 등장은

‘수익화’라는 마법의 단어와 결합해, 바이브 코딩을 호그와트행 급행 열차로 만들었습니다.

하지만 현실은 달라요.

AI는 마법사의 돌이 아니고, 우리는 해리포터가 아니죠.

바이브 코딩은 마법이 아니라 정말로 사람의 손이 많이 가는 ‘일’이 거든요.

이번 에피소드에서는 AI가 모든 걸 해줄 거라는 환상에 빠져,

30만원과 한 달을 날린 제 이야기를 들려드릴게요.

그리고 어떻게 문제가 되는 부분을 극복했는지도 설명해드리려고 합니다.

시간은 돈보다 소중합니다.

이 글을 읽으시는 분들이, 저와 같은 실수를 반복하지 않으셨으면 해요.

바이브 아티클,

시작합니다.

1. AI는 기억하지 못한다.

AI를 처음 쓰는 분들이 좋은 프롬프트를 쉽게 찾을 수 있게 하고 싶었어요.

인터넷에 흩어져 있는 프롬프트들을

카테고리별로 정리해서, 마케팅용, 글쓰기용, 분석용으로 나누고

사용자가 즐겨찾기도 할 수 있는 그런 서비스를 만들고 싶었거든요.

처음에는 정말 잘 되는 것 같았어요.

"간단한 웹 애플리케이션 만들어줘"라고 하니까

Claude가 HTML, CSS, JavaScript를 뚝딱 만들어주더라고요.

"프롬프트 입력 폼 만들어줘"라고 하니까 그것도 금방 나왔고요.

그런데 프로젝트가 복잡해지면서 문제가 발생했어요.

아직까지 AI 모델은 Context Window 제한이 너무 뚜렷해요.

즉, 아무리 올바른 대답을 내놓는 것 같아도

한 번에 기억할 수 있는 정보량이 정해져 있다는 뜻이죠.

당시 제가 쓰던 Claude Sonnet 3.5는 200K 토큰 정도였는데,

대화가 길어질수록 처음에 한 말들을 까먹기 시작한 거였어요.

가장 황당했던 건 "사용자 로그인 기능 추가해줘"라고 했더니

기존 데이터베이스 구조를 완전히 바꿔버린 일이에요.

그러면서 이전에 만든 프롬프트 저장 기능이 다 깨져버렸죠.

복구하려고 하니까 "어떤 이전 버전을 말씀하시는 건가요?"라고 되묻더라고요.

그제야 깨달았어요. AI는 제 머릿속 전체 그림을 모른다는 걸.

특히나 디자인 작업을 할 때가 가장 말썽인데요.

아무리 다른 파일에서 동일한 색상을 사용하더라도

새롭게 디자인을 추가하면, 맥락을 전혀 감지하지 못합니다.

그래서 지금은 몇 가지 방법으로 이러한 문제를 해소하려고 노력중입니다.

하나의 Task가 끝나면

md 문서에 기록하거나 노션에 내용을 정리해두고,

CursorRules에도 Brand Identity 내용을 명시해뒀어요.

그리고 제 제품에 브랜드 컬러를 자동으로 맞춰주는 기능까지 넣어서,

색상 구현이 필요할 때 마다 직접 HEX 코드를 전달해주고 있어요.

그럼에도 불구하고 매번 귀찮게 넣다보니

너가 알아서 찾아봐. 라고 말하게 되요.

그래도 다행히 최근에는 상황이 많이 나아지고 있어요.

Cursor에서 Claude-4-Sonnet 모델의

Context Window가 600K 토큰으로 늘어났고,

Claude Code에서는 1M 토큰까지 지원할 예정이라는 소식도 들려오고 있거든요.

하지만 도구가 좋아져도 결국 사람이 제대로 관리해야 한다는 걸 배웠어요.

그래도 Context 관리만 잘한다고 해서 모든 문제가 해결되는 건 아니더라고요.

더 근본적인 문제가 남아있었거든요.

바로 전체 구조를 미리 생각하지 않고 덤벼들었다는 점이었어요.

설계, 아키텍쳐 구조를 만들지 않고 코드부터 짰더니 프로젝트가 산으로 가더라구요.

2. 설계 없는 코딩은 모래성이다

처음에는 금방 제품이 나올 줄 알았어요.

하지만 기능을 하나씩 붙일 때마다, 상황이 급격히 복잡해졌죠.

“업종별로 다른 프롬프트가 필요하니까 업종 분류가 있어야겠네.”

“직무에 따라서도 달라져야 하고, 목적도 더 세분화해야겠지.”

그렇게,

업종 드롭다운 → 직무 선택 → 목적 분류 → 톤앤매너 옵션 → 키워드 입력

까지 줄줄이 붙였습니다.

구조가 매번 바뀌기 시작했어요.

각 기능을 추가할 때마다, AI가 기존 구조를 마음대로 수정하고 있었죠.

업종 분류를 넣으려다 보니 프롬프트 생성 로직이 달라지고,

톤앤매너 기능을 추가하려다 보니 데이터베이스 구조를 또 변경하고.

처음엔 문제가 없었어요.

단순히 "마케팅 프롬프트 하나 생성해줘"였는데,

나중에는 "20-30대 직장인 B2B 기업 마케터가 효율적인 톤앤매너로 비즈니스 제안서를 쓸 수 있는 프롬프트를 생성해줘"처럼 요구하는 기능이 복잡해지자, 마구잡이로 코드가 엉키기 시작했습니다.

혼돈 그 자체였죠.

더 황당한 건 파일 관리였어요.

AI가 갑자기 "components 폴더를 만들어서 정리하겠습니다"라고

하면서 기존 파일들을 이곳저곳 옮겨버리는 거예요.

그러면 import 경로가 다 깨지고, 어떤 파일이 어디에 있는지도 모르게 되더라고요.

그러다 운명의 날이 찾아왔어요.

톤앤매너 선택 기능을 추가하려는데, 기존 코드와 완전히 충돌하는 거예요.

AI는 이렇게 가볍게 말했죠.

한 달간의 작업이 물거품이 되는 순간이었습니다.

그제야 확실히 알았어요.

이건 AI의 문제가 아니라 제가 설계를 안 한 문제였다는 걸요.

기준이 없었어요.

규칙을 정하지 않았기 때문이었죠.

프레임워크를 바꿀 수 있는지 없는지,

데이터베이스 스키마를 언제 바꿔도 되는지,

폴더 구조와 네이밍을 어떻게 유지할지…

이런 기본적인 원칙을 제가 제시하지 않으니,

AI는 그때그때 “최적화”라는 이름으로 전체를 갈아엎은 겁니다.

비슷한 문제는 다른 곳에서도 나타나요.

Y Combinator 2025년 겨울 배치 기업 중 25%가 95% 이상을 AI 코드로 만들었는데,

그들 역시 기술적 부채가 쌓여 나중에 전체를 다시 만드는 상황을 맞고 있다고 해요.

설계 없는 시작이 결국 빚이 되어 돌아온 거죠.

결국 저는 첫 프로젝트를 포기했습니다.

너무 꼬여서 차라리 새로 시작하는 게 낫겠다고 판단했죠.

대신 새로운 프로젝트인 sangse.page를 시작할 때는 완전히 다르게 접근했어요.

(이 이야기는 다음 에피소드에서 더 디테일하게 다뤄보겠습니다.)

여전히 개발 지식은 부족합니다. 코드를 직접 짤 줄도 몰라요.

하지만 이제는 Claude Code와 긴 대화를 먼저 합니다.

“어떤 컴포넌트가 필요한지, 데이터는 어떻게 흘러가는지, 폴더 구조는 어떻게 가져갈지”

아키텍처 설계를 문서로 먼저 정리하고 시작했죠.

그랬더니 결과는 달라졌어요.

components, hooks, services, types, utils처럼 구조가 체계적으로 나뉘니까,

새로운 기능을 붙여도 기존 코드가 깨지지 않았습니다.

AI도 명확한 가이드라인 안에서 일관성 있게 응답했어요.

결국 깨달았습니다.

설계 없이는 바이브 코딩도 한계가 있다는 것.

AI는 아무리 똑똑해도 제 머릿속 전체 그림은 모릅니다.

그래서 지금은 무조건 문서화를 해요.

간단히라도 기준을 남겨두면, 그게 훗날 프로젝트를 지탱하는 안전망이 되거든요.

사실 기록이 너무 많아져서 가끔은 헷갈리기도 해요. 😅

그래도 설계와 문서화만 해도 프로젝트는 훨씬 안정적으로 굴러가요.

다만, 설계만 잘한다고 끝은 아니었습니다.

다음에는 더 근본적인 문제, 제 자신의 지식 부족과 마주해야 했습니다.

3. 가장 비싼 도구는 '기초 지식'이다

30만 원이 사라진 이유는 단순했어요.

제가 기본 지식이 없어서, 스스로 판단하지 못하고 AI에만 의존했기 때문이었죠.

모델에 묻고 답을 받아 쓰는 데는 문제가 없었지만,

토큰이 소진되면 더 이상 앞으로 나아갈 수가 없었어요.

결국 “AI 없이는 아무것도 못 하는” 상태가 되어버린 겁니다.

그래서 IDE나 에이전트 기능에 의존하며 버티려 했죠.

하지만 그건 지식의 성장이 아니라, 단순히 다른 도구로 갈아탄 것뿐이었어요.

제가 모르는 게 너무 많았어요.

AI에게 “이 라이브러리로 만들어줘”라고 하면 결과물은 척척 나오는데,

 왜 그 라이브러리를 선택했는지, 장단점이 뭔지는 이해하지 못했어요.

폴더와 파일이 어떤 역할을 하는지는 대략 알았지만,

충돌이 나면 늘 “왜 안 되나요?”라고 물었고,

AI가 알려주면 그대로 따라하기만 했습니다.

코드가 쌓이기는 하는데,

판단 기준이 생기지 않았습니다.

비슷한 문제가 반복되면서,

어느 순간부터 질문을 바꾸기 시작했어요.

이런 질문을 던지자,

AI는 단순히 코드를 주는 대신 맥락과 이유를 설명해주기 시작했습니다.

저는 그 과정을 통해 조금씩 배경 지식을 채워 나갔습니다.

최근 연구를 보니,

개발자들이 AI 도구를 쓰면서 20% 빨라졌다고 느끼지만,

실제로는 19% 느려졌다는 결과도 있더군요.

특히 저 같은 기본 지식이 부족한 사람일수록 더 많은 시간을 잃는다는 겁니다.

정말 제 얘기였어요.

반대로 경험이 많은 사람들은,

불필요한 걸 과감히 걷어내고 단순하게 갑니다.

Pieter Levels처럼요.

그는 프레임워크나 라이브러리조차 최소화해서 심플하게 개발한다고 합니다.

저는 그와 정반대였어요.

부족한 경험을 레퍼런스로, AI 제안으로, 잡을 수 있는 모든 걸로 메꾸려 했습니다.

AI는 정말 훌륭한 도구예요.

하지만 도구가 아무리 좋아도,

기본 지식과 경험이 없다면 아무 판단도 못 한다는 걸 뼈저리게 느꼈습니다.

결국, 사람이 주도해야 합니다

30만 원을 들여 첫 제품 개발에 실패했습니다.

한 달 동안 밤낮으로 AI와 씨름했지만, 그 비용이 아깝지 않았어요. 바이브 코딩을 제대로 하려면 어떻게 접근해야 하는지 몸으로 배웠고, 그 덕분에 두 번째 시도에서는 100일 만에 새로운 제품을 완성할 수 있었거든요.

이 경험을 통해 확실히 말할 수 있어요.

바이브 코딩은 수익화를 보장하는 호그와트행 열차가 아닙니다. SNS에서 보이는 ‘AI로 하루 만에 월 천만 원’ 같은 광고는 현실과 거리가 있어요. 그렇다고 가능성이 없다는 뜻은 아니에요. 올바르게 접근하면 강력한 도구가 될 수 있습니다.

그래서 시작하려는 분들께 몇 가지를 권합니다.

1. 간단한 설계도부터 그리세요. 
   A4 한 장이라도 기능과 데이터 흐름을 먼저 정리하면 맥락을 유지하는 데 도움이 됩니다.

2. 맥락을 충분히 제공해줘야 해요.
   “뭐든 만들어줘” 대신 목표·제약·배경을 구체적으로 전달해 주세요. 그러면 결과물의 완성도가 높아져요.

3. 항상 이유를 확인하세요.
   AI의 제안에 “왜 이 선택을 했나요?”라고 묻고 가정을 검증해 주세요. 그렇게 하면 의미없이 과도한 기능 개발은 피할 수 있어요.

결국 주도권은 사람이 가져야 해요.

바이브 코딩은 마법이 아니라 손이 많이 가는 일이지만, 방향만 제대로 잡으면 분명 힘이 됩니다.

다음 에피소드에서는

sangse.page를 어떻게 키웠는지,

첫 고객을 어떻게 유치했는지 들려드릴게요.

긴 글 읽어주셔서 감사해요. 다음 에피소드에서 뵙겠습니다!

엉클잡스 올림

📚 Prompt Master Class