“Vibe Coding”이라는 말은 2025년 말 개발자 커뮤니티에서 갑자기 널리 쓰이기 시작했다. 간단히 말하면 만들고 싶은 것을 자연어로 설명하고, AI가 코드를 작성하게 하는 방식이다.
핵심 개념
더 이상 모든 줄을 직접 입력하는 방식만 고집하지 않는다. 사용자가 요구사항을 설명하면 AI가 이해한 뒤 코드를 생성한다. 결과가 맞지 않으면 자연어로 다시 고친다. 전체 과정은 코드를 직접 “작성”한다기보다 코드가 어떤 방향으로 움직여야 하는지 “연출”하는 느낌에 가깝다.
Cursor의 Composer 모드, Claude Code의 에이전트 모드, GitHub Copilot의 코딩 에이전트가 모두 이 흐름을 밀고 있다.
정말 쓸 만한가
잘 맞는 용도는 분명하다.
- 아이디어를 실행 가능한 데모로 빠르게 바꾸는 프로토타입 개발.
- 반복적인 CRUD 코드.
- 낯선 프레임워크나 언어를 처음 탐색하는 작업.
- 테스트 케이스와 문서 작성.
반대로 피해야 할 영역도 있다.
- 성능이 중요한 저수준 코드.
- 보안에 민감한 모듈.
- 모든 로직을 정확히 통제해야 하는 상황.
- 복잡한 맥락이 쌓인 대형 레거시 코드베이스.
논쟁의 지점
지지자들은 바이브 코딩이 프로그래밍의 문턱을 낮춰 더 많은 사람이 코드로 아이디어를 구현하게 만든다고 본다. 비판하는 쪽은 자신이 만든 코드를 이해하지 못하는 사람이 유지보수와 디버깅에서 큰 문제를 만날 수 있다고 경고한다. AI가 쓴 코드를 읽지 못한다면, 버그가 났을 때 어떻게 고칠 것인가?
이 논쟁은 한때 로우코드 플랫폼을 둘러싼 논쟁과 거의 같다. 답도 비슷할 가능성이 크다. 바이브 코딩은 효과적인 도구가 될 수 있지만, 시스템의 기초 원리를 이해해야 한다는 요구를 없애지는 않는다.
누가 쓰고 있나
흥미로운 점은 헤비 유저가 초보자만은 아니라는 것이다. 경험 많은 개발자도 많이 쓴다. 다만 목적이 다르다. 초보자는 “돌아가는 코드”를 얻기 위해 쓰고, 숙련자는 “지루한 부분을 빨리 건너뛰기” 위해 쓴다.
METR의 연구는 한 가지 경고도 덧붙인다. 경험 많은 개발자가 AI 도구를 쓰면 오히려 더 느려질 수 있으며, 해당 연구에서는 19%라는 수치도 제시됐다. 바이브 코딩은 만능 해법이 아니다. 제대로 쓰려면 언제 써야 하고 언제 멈춰야 하는지를 알아야 한다.
출처: 개발자 커뮤니티 논의, CocoLoop, METR 연구.