바이브 코딩이란 무엇인가
바이브 코딩과 Agentic AI: 구현은 AI가, 판단은 인간이
바이브코딩 106
바이브 코딩이란 무엇인가
바이브 코딩과 Agentic AI: 구현은 AI가, 판단은 인간이
인스타를 켠다.
광고다.
누가 또 바이브코딩으로 몇만 불을 벌었단다.
유튜브를 켠다.
바이브코딩으로 1시간 만에 웹 SaaS를 만드는 방법을 가르쳐주신다.
아주 좋은 세상이다.
그래서 나도 했다.
그리고 망했다.
한 번이 아니고 수십 번.
그 과정을 앞선 다섯 편에 걸쳐 썼다.
이 글은 그 다섯 편을 거치면서 내가 내린 결론을 하나로 정리한 글이다.
안 읽었어도 상관없다.
"그래서 바이브 코딩이 뭔데?"
이 질문 하나에 답하는 게 이 글의 전부다.
바이브 코딩이란 무엇인가?
바이브 코딩은 AI가 대신 코딩해주는 방식이 아니다.
바이브 코딩은 agentic AI와 함께(with) 소프트웨어를 만드는 개발 방식이다.
여기서 중요한 단어는 AI도 아니고 코딩도 아니다.
with, 즉 함께다.
AI가 전부 해주고 인간은 결과만 받는 구조?
그건 바이브 코딩이 아니라 외주다.
인스타 광고에서 말하는 그거.
왜 'with'인가?
요즘 AI는 코드 한 줄 추천해주는 수준이 아니다.
직접 파일을 만든다.
수정한다.
실행한다.
테스트를 돌린다.
그리고 인간은 그 행동을 승인하거나 거절한다.
AI는 도구가 아니라 작업자.
인간은 관객이 아니라 결정자.
구현은 AI가 한다.
판단은 인간이 한다.
이게 바이브 코딩의 구조다.
이 구조가 유지될 때만 바이브 코딩은 힘을 가진다.
'with'가 빠지면 어떻게 되는가?
내가 다섯 편에 걸쳐서 쓴 게 딱 이거다.
인간이 결정을 안 하면 AI는 성실하게 달린다.
어디로 가는지 아무도 모른 채.
왜 이렇게 만들었는지 모르고,
어디까지 바꿔도 되는지 모르고,
고칠수록 더 망가진다.
결국 이 한마디가 나온다.
"아예 다시 만들어주세요."
인스타가 안 알려주는 것
인스타 광고는 이런 걸 말한다.
프롬프트만 잘 쓰면 된다.
코딩 몰라도 앱을 만들 수 있다.
빠르게 결과를 뽑는 요령이다.
전부 맞는 말이다.
첫날까지는.
둘째 날부터는 다른 게 필요하다.
결정이다.
무엇을 만들지.
이건 어떤 상황을 위한 건지.
지금 이 변경이 "살짝 손보는 수정"인지 "아예 방향을 바꾸는 결정"인지.
이걸 구분하는 기준.
이걸 고정하는 구조.
이걸 반복하는 습관.
인스타에서는 이 얘기를 안 한다.
1시간 만에 만드는 강의가 더 잘 팔리니까.
결정을 고정하는 장치
개발자들은 이 문제를 수십 년 전에 겪었다.
사람끼리 해도 이렇게 되니까.
그래서 만든 게 있다.
이름이 무섭게 생겼는데,
하는 일은 전부 같다.
"지금 뭘 만들고 있는지"를 글로 박아놓는 것.
TDD — Test-Driven Development.
시험 문제를 먼저 만든다.
"로그인 버튼을 누르면 메인 화면이 뜬다."
이걸 먼저 적는다.
그다음에 이 시험을 통과하는 코드를 만든다.
시험이 있으니까 "됐는지 안 됐는지"가 명확하다.
AI한테도 마찬가지다.
"이거 만들어줘"가 아니라 "이 시험을 통과하게 만들어줘."
기준이 있으면 AI가 딴소리를 할 수가 없다.
DDD — Domain-Driven Design.
문제에 정확한 이름을 붙이는 거다.
"좀 이상해요"가 아니라 "결제 완료 후에도 장바구니가 안 비워지는 문제."
이름이 정확하면 AI도 정확해진다.
이름이 애매하면 AI도 애매해진다.
당연한 거 아닌가 싶겠지만,
실제로 해보면 대부분 "좀 이상해요" 쪽에서 시작한다.
나도 그랬다.
Spec-driven — 스펙 먼저 쓰기.
만들기 전에 "우리는 이걸 만든다"를 문서로 적는 거다.
말로 하면 휘발된다.
머릿속에만 있으면 AI는 모른다.
글로 써놓으면 남는다.
"이 스펙 기준으로 만들어줘."
이 한마디면 AI가 딴 데로 새는 일이 확 줄어든다.
왜 이게 결정을 고정하는가?
셋 다 하는 일이 같다.
만들기 전에, 뭘 만들지를 먼저 고정하는 거다.
TDD는 "성공 조건"으로 고정한다.
DDD는 "정확한 이름"으로 고정한다.
Spec-driven은 "문서"로 고정한다.
고정되면 뭐가 달라지냐고?
AI한테 "이것만 해"라고 말할 수 있다.
고정이 안 되면?
AI한테 매번 "알아서 해줘"라고 말하게 된다.
"알아서 해줘"를 세 번 하면 왼팔이 28개 달린 괴물이 나온다.
경험담이다.
왜 여기에 에너지를 쏟아야 하는가?
바이브 코딩에서 구현은 공짜다. (에너지가 말이다. 구독료 말고)
AI가 해주니까.
파일 만드는 것. 공짜.
코드 짜는 것. 공짜.
테스트 돌리는 것. 공짜.
공짜가 아닌 게 딱 하나 있다.
"뭘 만들 건지 정하는 것."
이건 인간만 할 수 있다.
그리고 이걸 글로 고정하는 것.
이것도 인간만 할 수 있다.
구현은 AI한테 무한정 시킬 수 있지만,
결정이 틀리면 구현을 백 번 해도 쓰레기다.
그래서 에너지를 쏟아야 할 곳은 코드가 아니라 스펙이다.
프롬프트가 아니라 기준이다.
AI가 빠르게 달릴 수 있는 이유는 AI가 똑똑해서가 아니다.
인간이 길을 깔아놨기 때문이다.
그 길을 까는 게 TDD고, DDD고, Spec-driven이다.
바이브 코딩에서 인간의 진짜 일은 코딩이 아니라 길 까는 것이다.
그래서 내가 정의하는 바이브 코딩
다섯 편을 쓰고,
직접 게임을 만들고,
AI 에이전트 시스템을 구축하고,
수십 번 망하고 다시 시작하면서
겨우 겨우 런칭 직전의 서비스 3개를 MVP까지 완성해냈다.
내가 내린 결론은 하나다.
바이브 코딩은 AI와 함께(with) 결정을 계속 교환하며 소프트웨어를 만들어가는 개발 방식이다.
구현은 AI가 한다.
판단은 인간이 한다.
이 분리가 무너지면 인스타 광고처럼 시작해서 "아예 다시 만들어주세요"로 끝난다.
시작하기 전에 반드시 답해야 할 4가지
어떤 도구를 쓰든, 어떤 방법론을 쓰든, 이 네 가지에 먼저 답해야 한다.
내가 무엇을 만들고 있는가.
이건 어떤 상황을 위한 것인가.
지금 겪는 문제는 무엇인가.
그 문제를 왜 고치려는가.
이 답이 있으면 AI는 정확하게 움직인다.
이 답이 없으면 AI는 그럴듯하게 헤맨다.
그리고 나는 그 헤매는 걸 구경하다가 셋째 날쯤에 이렇게 말하게 된다.
"아예 다시 만들어주세요."
벌써 세 번째다.
FAQ
Q. 바이브 코딩과 일반 AI 코딩은 뭐가 다른가?
일반 AI 코딩은 AI한테 코드 달라고 해서 복붙하는 거다. 바이브 코딩은 AI가 직접 파일을 만들고 고치고 실행까지 한다. 차이? 복붙이냐, 같이 일하냐.
Q. 코딩을 전혀 모르는 사람도 할 수 있는가?
할 수 있다. 다만 "코딩 실력" 대신 "결정 능력"이 필요하다. 무엇을 만들지, 이 기능이 지금 필요한지, 이 변경이 수정인지 방향 전환인지. 코딩 문법은 AI가 대신하지만, 이 판단은 인간만 할 수 있다. 이 판단을 연습하는 과정이 바이브 코딩이다.
Q. 가장 좋은 AI 도구가 뭔가?
도구 싸움이 아니다. Claude Code든 Cursor든 GPT든, 결정을 고정하는 구조 없이 쓰면 결과는 다 비슷하다. 스펙 문서 먼저 만들고, 단계 쪼개서 하나씩 진행하고, 결과 검증하는 흐름. 이게 도구 선택보다 열 배는 중요하다.
Q. 프롬프트 엔지니어링이랑 같은 말 아닌가?
다르다. 프롬프트 엔지니어링은 말을 잘하는 기술이다. 바이브 코딩은 AI와 함께 일하는 방식 전체를 가리킨다. 프롬프트는 그 안의 한 조각이고, 실제로는 환경 설계가 프롬프트보다 더 먹힌다. 말 이쁘게 아무리 잘해봐야, 일 잘할 상황을 하나 만들어주는 것만 못하다.
Q. Karpathy가 말한 바이브 코딩이랑 다른 건가?
Karpathy가 말한 원형은 "느낌대로 영어로 뭔가 적으면 결과가 나오는 코딩"이다. 맞다. 개발자 입장에서는. 근데 비개발자한테는 그 "느낌"이 작동을 안 한다. 결정을 구분할 기준이 없으니까. 이 글의 정의는 Karpathy 원형에 "결정 구조"를 더한 거다. 개발자가 아닌 사람도 쓸 수 있는 바이브 코딩.
아니 저 사람은 원래 저 결정 구조를 가지고 있던 사람인거고, 나는 아니었기에 나중에 깨달은 거겠지.
그래 류현진이 공 던지는 법 원포인트 레슨 해줘봐야, 야구 선수나 알아 듣는거다.
이 글은 바이브코딩 101~105 시리즈를 거치며 정리한 정의 편이다.
각 편에서 다룬 구체적인 방법론이 궁금하면 시리즈를 이어서 읽어도 좋다.
곧 런칭할 내 서비스도 궁금하다면 (제발 궁금해라) 다음 편도 기대해주시라