강의보고 따라하는 데 누가 망하냐구요?? 저요!
제목부터 좋았다. “프롬프트로 완성하는 나만의 서비스.”
나는 그때 막 시작하던 때였다.
AI가 코딩도 해준다며.
그럼… 나도 되겠네?
영상은 친절했다.
친절한 건 좋은데, 문제는 친절한 게 늘 정답은 아니라는 거다.
강의는 바이브코딩을 이렇게 정리했다.
프롬프트를 구체화하라 예시와 레퍼런스를 주면 더 잘 된다.
룰(규칙)을 만들어라 Cursor Rules 같은 걸로 “항상 이렇게 하라”를 고정하라.
MCP를 붙여라 AI가 검색도 하고, 크롤링도 하고, 테스트도 하게 만들어라.
솔직히 말해서, 들을 때는 맞는 말 같다.
그리고 진짜로 도움이 된다.
문제는… 여기서 끝이 아니라는 점이다.
강의 후반부에 이런 말이 나온다.
“Say → Run → See” 반복은 빠르다.
하지만 계획이 없으면,
연결이 약해지고
순서가 꼬이고
토큰만 낭비된다
그래서 중간에 PRD(제품 요구 문서) 같은 기획 단계를 넣으라고 한다.
PRD가 어렵다면 AI로 만들고, 대화로 다듬으라고도 한다.
여기서 나는 속으로 이렇게 생각했다.
오케이.
그럼 나는 PRD까지는 나중에.
일단 “되는 것”부터 만들어보자.
그리고 그날부터, 나는 망하기 시작했다.
처음엔 된다.
정말 된다.
기능이 생기고, 화면이 뜨고, 버튼이 눌린다.
그 순간, 머릿속에 딱 그 생각이 든다.
“와… 이거 진짜네.”
그래서 욕심이 생긴다.
“조금만 손보면 완벽하겠다.”
여기서부터가 지옥의 시작이다.
프롬프트를 다시 쓴다.
그리고 다음 순간, 이상한 일이 시작된다.
이제 아예 안 된다.
고쳐달라고 한다.
다시 되긴 한다.
그런데…
내가 원했던 것에서 더 멀어졌다.
안 되냐고 물으면, 안 되는 건 아니다.
되냐고 물으면, 뭔가 제대로 되는 것 같진 않다.
이게 바이브코딩의 첫 번째 벽이다.
그때 내가 느낀 건 이런 거였다.
이게 맞는지 모르겠다
어디서부터 틀린 건지 모르겠다
고쳐달라고 하면 더 망가질까 봐 무섭다
이걸 겪어보면 알게 된다.
AI가 만드는 코드는 대부분 그럴듯하다.
그래서 더 위험하다.
완전히 깨진 건 누구나 알아본다.
하지만 “겉으로는 멀쩡한데 안에서 썩는 결과물”은
비개발자한테는 재앙이다.
Andrej Karpathy가 말했듯이,
느낌대로 영어로 뭔가를 적으면 결과가 나오는 코딩.
그게 바이브코딩의 원형이다.
맞다.
개발자 입장에서는.
나는 아니다.
나는 개발자가 아니다.
개발자가 가르치는 바이브코딩은
나에게 그대로 맞지 않았다.
왜냐면, 그들은 기본적으로
가장 중요한 걸 모른다.
비개발자가 무엇을 모르는지.
비개발자가 모르는 건 “문법”이 아니다.
진짜로 모르는 건 이거다.
지금 이 변경이
“조금 손보는 수정”인지
“아예 방향을 바꾸는 결정”인지
개발자는 그걸 구분한다.
구분할 기준이 있기 때문이다.
비개발자는 그걸 모른다.
그래서 프롬프트를 한 번 더 쓴다.
그리고 AI는 성실하게 움직인다.
문제는, 어디로 가는지 아무도 모른다는 것이다.
비개발자가 바이브코딩을 할 때 가장 중요한 건,
툴도 아니고, 룰도 아니고, MCP도 아니다.
내가 만들 “제품”의 명세다.
나는 무엇을 만들 것인가?
그건 어떤 기능을 하는가?
누가 쓸 것인가?
기능이 하나인가, 여러 개인가?
확장성이 필요한가?
이 질문에 답이 없으면,
바이브코딩은 반드시 어긋난다.
왜냐면 우리는 코딩을 모르니까.
중간에 마음먹은 대로
“야 여기서 우회전”, “다시 좌회전”을 못 한다.
우리는 지도 없는 외지인이고,
개발자들은 네비게이션 달고 다니는 동네 토박이다.
다음 글에서는 이걸 더 정확히 말해보겠다.
비개발자가 바이브코딩을 하면서 망하는 이유는,‘프롬프트’가 아니라 ‘결정’을 모르기 때문이다.
결정이 무엇인지,
결정이 언제 발생하는지,
그걸 모르고 지나가면 어떻게 망하는지.
내가 망한 순서 그대로 보여주겠다.