안드레 카파시 바이브 코딩은 2025년 2월 2일 그가 X에 올린 한 문장에서 시작됐다. 흐름에 몸을 맡기고 코드가 존재한다는 사실조차 잊는 방식이지만, 그는 버려도 되는 주말 프로젝트로 선을 그었다. 원문 다섯 가지 행동, AI 보조 코딩과의 구분, 유지보수와 보안 한계, 한국 1인 개발자가 diff를 읽고 안 읽는 자리를 나누는 법까지. 바이브 코딩, LLM, 커서, 클로드 코드, 개발자 기준. 2026년 8월 공식 자료.
바이브 코딩이라는 말을 검색하셨다면 대개 두 가지가 궁금하실 겁니다. 누가 만든 말인지, 그리고 실제로 뭘 하라는 건지요.
이 말은 2025년 2월 안드레 카파시가 트위터에 올린 한 문장에서 시작됐습니다. 그 뒤로 뜻이 부풀려지고 오해도 많아졌죠. AI에게 다 맡기고 코드는 안 본다는 이미지만 남아서, 정작 카파시가 어떤 상황을 두고 한 말인지는 흐려졌습니다. 그래서 실무에 그대로 가져다 쓰다가 낭패를 보는 분도 적지 않습니다.
여기서는 원문이 실제로 무슨 말을 했는지, 어디까지가 바이브 코딩이고 어디부터는 아닌지, 그리고 한국에서 혼자 서비스를 만드는 분이 이걸 어떻게 선을 그어 쓰면 좋은지 차분히 풀어 봅니다. 같은 단어를 두고 헷갈리셨다면 도움이 되실 거예요. 근거는 카파시 원문과 마틴 파울러, MIT 테크놀로지 리뷰 정리에 뒀습니다.
바이브 코딩이라는 말은 어디서 나왔나
바이브 코딩은 2025년 2월 2일 안드레 카파시가 X(옛 트위터)에 올린 게시물에서 처음 나온 말입니다. 그는 오픈AI 공동 창업자이자 테슬라 AI 총괄을 지낸 사람이라, 초보가 아니라 최상위 개발자가 던진 표현이라는 점이 먼저 중요합니다.
원문 첫 문장은 이렇게 시작합니다. 코드를 직접 쓰지 않고 흐름에 몸을 맡긴다는 뜻이죠.
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
새로운 코딩 방식이 있는데 나는 이걸 바이브 코딩이라 부른다. 흐름에 완전히 몸을 맡기고, 지수적 발전을 받아들이고, 코드가 존재한다는 사실조차 잊는 것이다.
이 글은 조회 450만 회를 넘겼고, 콜린스 사전은 2025년 올해의 단어로 바이브 코딩을 뽑았습니다. 한 사람의 농담 섞인 메모가 업계 전체를 설명하는 단어가 된 셈입니다. 카파시 본인이 원문 게시물에서 밝힌 도구는 커서 컴포저와 소넷, 그리고 음성 입력 도구였습니다.
먼저 짚을 것 | 이 말을 만든 사람은 코딩을 못 해서 AI에 기댄 게 아닙니다. 이미 다 아는 사람이 재미로 힘을 뺀 상태를 부른 이름입니다. 이 전제가 뒤에 나오는 한계선의 근거가 됩니다.
바이브 코딩은 2025년 2월 카파시의 짧은 게시물 한 편에서 시작됐다
카파시가 원문에서 실제로 한 말
원문 뒷부분은 정의보다 행동 묘사에 가깝습니다. 카파시가 그날 실제로 한 다섯 가지를 그대로 옮기면 바이브 코딩의 온도가 정확히 잡힙니다.
원문 행동
무슨 뜻인가
음성으로 지시
키보드를 거의 안 만지고 말로 요청
항상 전체 수락
제안을 그대로 받고 diff를 안 읽음
에러는 그냥 붙여넣기
설명 없이 오류 메시지만 복사해 다시 요청
이해 범위를 넘는 코드
읽으면 알겠지만 굳이 안 읽는 상태
안 고쳐지면 우회
버그가 안 잡히면 다른 요청으로 돌아감
그리고 카파시는 스스로 못을 박습니다. "버려도 되는 주말 프로젝트에는 나쁘지 않다"고요. 원문 마지막 문장은 이렇게 끝납니다. 만들기는 하는데 진짜 코딩은 아니라는 겁니다.
It's not too bad for throwaway weekend projects. I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
버려도 되는 주말 프로젝트엔 나쁘지 않다. 그냥 보고, 말하고, 실행하고, 복사해 붙이면 대체로 돌아간다.
오해와 진짜 정의를 가른다
가장 흔한 오해는 AI로 코딩하면 다 바이브 코딩이라는 생각입니다. 그렇지 않습니다. 개발자 사이먼 윌리슨은 이 둘을 명확히 나눴습니다. 그는 바이브 코딩을 "AI가 쓴 코드를 검토하지 않고 소프트웨어를 만드는 것"이라고 정리했죠. 다시 말해 코드를 읽고 고치면서 AI를 쓰는 건 그냥 AI 보조 코딩이지 바이브 코딩이 아닙니다.
마틴 파울러도 같은 자리를 짚습니다. 그는 바이브 코딩의 핵심을 "코드가 존재한다는 사실조차 잊는 것"이라고 봤고, 바로 그 지점이 쓸모이자 한계라고 적었습니다. 코드를 안 보니 빠르지만, 코드를 안 보니 유지보수와 정확성과 보안에서 문제가 남는다는 뜻입니다.
그래서 선은 하나로 정리됩니다. diff를 읽느냐 안 읽느냐입니다. 읽고 판단하면 AI 협업, 안 읽고 수락하면 바이브 코딩이죠. 이 구분을 흐리면 실무 코드에 바이브 코딩을 밀어 넣고 사고가 났을 때 원인을 못 찾습니다.
구분
바이브 코딩
AI 보조 코딩
코드 검토
거의 안 읽음
읽고 판단함
제안 수락
대체로 전체 수락
선택 수락, 수정
맞는 자리
프로토타입, 습작
운영 서비스, 협업 코드
책임 소재
흐릿함
사람이 최종 확인
diff를 읽느냐 안 읽느냐가 두 방식을 가르는 한 줄이다
어디까지 써도 되나
카파시가 직접 그은 선이 그대로 실무 기준이 됩니다. 버려도 되는 것에는 흐름에 맡기고, 남을 것에는 코드를 읽습니다. 사이가 애매한 자리는 오래 두지 말고 한쪽으로 옮기는 게 안전합니다.
구체적으로 나누면 이렇습니다. 하루 만에 확인하고 버릴 아이디어 검증, 개인용 스크립트, 사내 데모, 발표용 목업은 바이브 코딩과 잘 맞습니다. 반대로 결제가 붙는 화면, 개인정보를 다루는 로직, 여러 명이 오래 고칠 코드베이스는 diff를 읽어야 합니다. 이유는 단순합니다. 안 읽은 코드는 남에게 넘길 수 없고, 사고가 나면 어디서 터졌는지 아무도 모르기 때문이죠.
상황
권장
이유
주말 아이디어 검증
바이브 코딩 OK
버릴 코드라 속도가 이득
개인 스크립트, 자동화
대체로 OK
혼자 쓰고 위험이 작음
결제, 로그인 로직
diff 필독
보안, 정확성이 걸림
여러 명이 고칠 코드
diff 필독
유지보수가 안 되면 부채
바이브 코딩으로 시작한 프로토타입이 반응이 좋아 운영으로 넘어갈 때가 진짜 갈림길입니다. 이때는 코드를 처음부터 읽으면서 다시 짜는 단계를 한 번 거쳐야 합니다. 도구별 판단은 바이브코딩 툴 가이드에, 클로드 코드 흐름은 실전 워크플로우에 정리해 뒀습니다.
[ ] 지금 만드는 게 버릴 코드인지 남을 코드인지 정했다
[ ] 남을 코드면 diff를 읽기로 규칙을 세웠다
[ ] 결제, 로그인, 개인정보 로직은 바이브 코딩에서 뺐다
[ ] 프로토타입이 운영으로 갈 때 다시 짜는 단계를 넣었다
[ ] AI가 만든 코드를 그대로 배포하기 전 한 번은 읽었다
운영 코드에 그대로 밀면 위험 | 안 읽은 코드는 보안 구멍과 잘못된 처리를 그대로 안고 배포됩니다. 남을 코드라면 속도를 조금 내주고 diff를 읽는 편이 결국 빠릅니다.
한국 1인 개발자가 선을 긋고 쓰는 법
저는 사이트 여러 개를 혼자 운영하면서 바이브 코딩을 자주 씁니다. 다만 자리를 나눠서 씁니다. 새 기능을 붙여 볼지 감을 잡는 단계에서는 흐름에 맡기고, 그 기능이 실제 화면에 남기로 하면 그때부터 코드를 읽습니다.
한국에서 혼자 만들 때 현실적인 위험이 하나 더 있습니다. 나중에 코드를 물어볼 동료가 없다는 점이죠. 회사라면 옆자리에 물어보겠지만 1인 개발은 안 읽은 코드가 곧 나만 모르는 코드가 됩니다. 그래서 저는 배포 브랜치에 올라가는 코드는 아무리 급해도 한 번은 훑고, 결제나 로그인처럼 돈과 계정이 걸린 부분은 줄 단위로 읽습니다.
비용도 선 긋기의 이유가 됩니다. 전체 수락을 반복하면 AI가 큰 파일을 통째로 다시 쓰면서 사용량이 빨리 찹니다. 구독 한도와 실비용을 관리하는 감은 결제 직후 첫 주 체크리스트와 월 실비용 글에 적어 뒀습니다. 바이브 코딩은 공짜 속도가 아니라, 읽지 않는 대가를 나중에 치르는 방식이라는 점만 기억하면 충분합니다.
안드레 카파시가 2025년 2월 2일 X에 올린 게시물에서 처음 썼습니다. 그는 오픈AI 공동 창업자이자 테슬라 AI를 이끌었던 사람입니다. 조회 450만 회를 넘겼고 콜린스 사전 2025년 올해의 단어로 뽑혔습니다.
AI로 코딩하면 전부 바이브 코딩인가요?
아닙니다. 사이먼 윌리슨은 AI가 쓴 코드를 검토하지 않고 만드는 것만 바이브 코딩이라고 정리했습니다. 코드를 읽고 고치며 AI를 쓰는 건 AI 보조 코딩이죠. 갈림선은 diff를 읽느냐 안 읽느냐입니다.
카파시는 실무 코드에 쓰라고 했나요?
그렇지 않습니다. 원문에서 버려도 되는 주말 프로젝트에는 나쁘지 않다고 선을 그었습니다. 코드가 이해 범위를 넘어가고 diff를 안 읽는 상태를 재미로 즐긴 것이라, 남을 코드에 그대로 쓰라는 뜻은 아니었습니다.
한계나 위험은 무엇인가요?
마틴 파울러는 코드를 안 보기 때문에 유지보수, 정확성, 보안에서 문제가 남는다고 봤습니다. 읽지 않은 코드는 사고가 났을 때 원인을 찾기 어렵고, 남에게 넘기기도 힘듭니다. 그래서 오래 남을 소프트웨어에는 맞지 않습니다.
1인 개발자는 어떻게 선을 그으면 되나요?
감을 잡는 단계는 흐름에 맡기고, 화면에 남기기로 하면 그때부터 코드를 읽으면 됩니다. 배포 브랜치는 최소 한 번 훑고, 결제나 로그인처럼 돈과 계정이 걸린 부분은 줄 단위로 읽는 편이 안전합니다.
프로토타입이 잘되면 그대로 운영하면 되나요?
그대로 넘기지 않는 편이 좋습니다. 반응이 좋아 운영으로 가면 코드를 처음부터 읽으며 다시 짜는 단계를 한 번 거치는 게 안전합니다. 재작성 예산을 미리 잡아 두면 바이브 코딩의 속도를 살리면서 부채를 줄일 수 있습니다.
바이브 코딩은 코드를 안 보는 무책임이 아니라, 어디까지 흐름에 맡기고 어디부터 코드를 읽을지 선을 긋는 판단입니다. 카파시는 버릴 것에만 맡기라고 선을 그었고, 남을 코드에는 diff를 읽는 손이 여전히 필요합니다. 관련 글: 바이브코딩 툴 가이드, 실전 워크플로우, 결제 직후 첫 주.
안드레 카파시바이브 코딩바이브코딩vibe codingAI 코딩커서클로드 코드LLM개발자프로토타입diffAI 보조 코딩
