코드를 읽지 않고 프로그래밍한다는 것
AI 코딩 도구를 쓰다 보면 묘한 순간이 찾아온다. 코드를 한 줄씩 짜는 대신 “이런 기능을 만들어 줘”라고 말하고, AI가 생성한 결과물을 실행해 보고, 안 되면 다시 말로 수정을 요청한다. 어느 순간 코드를 직접 읽지 않고도 프로그램이 돌아가고 있다. 이 방식을 하나의 프로그래밍 스타일로 이름 붙인 사람이 있다.
2025년 2월, 전 OpenAI 연구원이자 테슬라 AI 총괄이었던 안드레이 카르파티(Andrej Karpathy)가 X(트위터)에 이런 글을 남겼다.
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.
“분위기에 완전히 몸을 맡기고, 코드가 존재한다는 사실 자체를 잊어버리는” 프로그래밍. 카르파티는 이 방식을 바이브 코딩(Vibe Coding)이라 불렀다. 이름이 재밌어서인지, 아니면 많은 사람이 이미 비슷한 경험을 하고 있었기 때문인지, 이 트윗은 개발자 커뮤니티에서 빠르게 퍼졌다.
바이브 코딩은 어떻게 작동하는가
바이브 코딩의 작업 흐름은 단순하다. 개발자가 자연어로 원하는 것을 설명하면, AI가 코드를 생성한다. 개발자는 생성된 코드를 실행해 보고, 결과가 의도와 다르면 다시 자연어로 피드백을 준다. 이 과정을 반복하면서 프로그램이 만들어진다.
핵심은 개발자가 코드의 세부 구현을 직접 다루지 않는다는 점이다. 전통적인 프로그래밍에서 개발자는 변수 이름을 짓고, 조건문을 구성하고, 함수 시그니처를 설계한다. 바이브 코딩에서는 이런 작업을 AI에게 위임하고, 개발자는 “무엇을 만들고 싶은지”를 설명하는 역할에 집중한다.
이런 작업 방식을 가능하게 하는 도구들이 이미 존재한다. Cursor, GitHub Copilot, Claude Code 같은 AI 코딩 도구가 대표적이다. 이 도구들은 자연어 입력을 받아 코드를 생성하고, 프로젝트 맥락을 이해하며, 여러 파일에 걸친 수정까지 수행할 수 있다.
기존 자동 완성과 무엇이 다른가
“AI가 코드를 써 준다”는 점에서 기존 코드 자동 완성과 비슷해 보이지만, 주도권의 위치가 다르다.
코드 자동 완성은 개발자가 코드를 작성하는 흐름 안에서 작동한다. 개발자가 함수를 쓰기 시작하면 AI가 나머지를 제안하고, 개발자가 한 줄씩 수락하거나 거부한다. 주도권은 개발자에게 있고, AI는 보조 역할을 한다.
바이브 코딩은 이 관계를 뒤집는다. 개발자가 “사용자 로그인 기능을 만들어 줘”라고 말하면 AI가 전체 코드를 생성하고, 개발자는 결과물을 확인한다. 주도권이 AI 쪽으로 넘어가고, 개발자는 방향을 잡아주는 역할에 가까워진다.
자율성의 스펙트럼으로 보면, 코드 자동 완성 → AI 페어 프로그래밍 → 바이브 코딩 순서로 AI의 자율성이 높아진다.
어디에서 잘 통하고, 어디에서 한계가 있는가
바이브 코딩이 모든 상황에 적합한 것은 아니다. 잘 맞는 영역과 그렇지 않은 영역이 비교적 뚜렷하다.
빠르게 아이디어를 검증하는 프로토타이핑에서 바이브 코딩은 효과적이다. 주말에 간단한 웹 앱을 하나 만들어 보고 싶을 때, 일회성 데이터 처리 스크립트가 필요할 때, 혹은 새로운 기술을 학습하면서 예제 코드를 빠르게 생성하고 싶을 때 유용하다. 코드의 품질보다 속도가 중요한 상황, 그러니까 “일단 돌아가면 된다”는 맥락에서 강점을 발휘한다.
반면, 대규모 코드베이스를 다루는 팀 프로젝트에서는 사정이 다르다. 여러 사람이 같은 코드를 유지보수하는 환경에서는 코드의 의도와 구조를 팀원 모두가 이해하고 있어야 한다. AI가 생성한 코드를 아무도 제대로 읽지 않은 채 머지하면 디버깅이 어려워지고, 기술 부채가 빠르게 쌓인다. 보안이 중요한 시스템에서는 더 조심해야 한다. AI가 생성한 코드에 취약점이 숨어 있어도 리뷰 없이는 발견하기 어렵다.
바이브 코딩의 핵심 트레이드오프는 속도와 이해도 사이에 있다. 빠르게 결과를 얻을 수 있지만, 그 과정에서 코드에 대한 깊은 이해를 놓칠 수 있다. 카르파티 본인도 트윗에서 이 방식이 “주말 프로젝트처럼 코드 품질이 크게 중요하지 않은 곳”에서 쓴다고 밝혔다. 바이브 코딩을 프로토타이핑 단계의 도구로 보고, 이후에 코드를 직접 검토하고 다듬는 과정을 거친다면 트레이드오프를 줄일 수 있다.
다만, 코드를 직접 작성하지 않는다고 해서 아무 말이나 던져도 되는 것은 아니다. 막연히 “로그인 기능 만들어 줘”라고 말하는 것과, 입력 검증 조건과 에러 처리 방식까지 구체적으로 설명하는 것은 전혀 다른 결과를 낳는다. 프롬프트를 어떻게 구성하느냐가 곧 결과물의 품질을 좌우하고, 프롬프팅 기법을 익혀 두면 바이브 코딩에서도 실질적인 차이를 만들 수 있다.
바이브 코딩이 던지는 질문
코드를 모르는 사람이 AI로 동작하는 앱을 만들고, 코드를 아는 사람은 자연어로 지시하는 비중을 늘려 가고 있다. 개발자의 역할이 “코드를 짜는 사람”에서 “무엇을 만들지 정의하고 검증하는 사람”으로 조금씩 옮겨가는 중이고, 바이브 코딩은 그 이동의 한 단면이다.
“코드를 짠다”는 말 대신, AI가 내놓은 결과를 골라내는 코드 피커(Code Picker)가 될 수도 있고, 각 파트에 지시를 내려 곡을 완성하는 지휘자처럼 코드를 오케스트레이션(Code Orchestration)하는 쪽이 될 수도 있다. 어느 쪽이든, “개발자”라는 단어가 가리키는 모습은 지금과 꽤 달라져 있지 않을까 싶다.