바이브 코딩, 제대로 하려면
"The hottest new programming language is English." — Andrej Karpathy
2025년 초, Andrej Karpathy가 트위터에 올린 한마디가 개발 커뮤니티를 뜨겁게 달궜다. "바이브 코딩(Vibe Coding)" — 코드의 세부 구현에 매몰되지 않고, 자연어로 의도를 전달하며 AI와 함께 소프트웨어를 만들어가는 방식. 이 개념은 순식간에 퍼져나갔고, 수많은 개발자들이 이 새로운 패러다임에 뛰어들었다.
하지만 현실은 어떤가? 바이브 코딩을 시도한 많은 사람들이 비슷한 경험을 한다. 처음엔 마법처럼 느껴지다가, 프로젝트가 커질수록 점점 통제할 수 없는 코드 더미와 씨름하게 된다. "AI가 알아서 해줄 줄 알았는데, 왜 이렇게 엉망이 되는 거지?"
나도 비슷한 경험을 했다. 이 글에서는 바이브 코딩이라는 유행어 너머에 있는 본질적인 질문들을 다뤄보려 한다.
바이브 코딩이란 무엇인가
바이브 코딩의 핵심은 단순하다. 코드를 직접 타이핑하는 대신, AI에게 원하는 것을 자연어로 설명하고 결과물을 받는 것이다.
개발자: "사용자 로그인 API를 만들어줘. JWT 토큰 발급하고,
리프레시 토큰은 Redis에 저장해."
AI: [완성된 코드를 생성]
개발자: (코드를 대충 훑어보고) "좋아, 적용하자."Karpathy는 이를 "코드에 완전히 몸을 맡기고, 바이브를 느끼며, 코드가 작동하는지조차 거의 확인하지 않는 것"이라고 설명했다. 매력적으로 들리지만, 이 문장에는 중요한 전제가 숨어 있다. Karpathy 본인이 세계 최고 수준의 AI 연구자이자 개발자라는 사실이다.
왜 실패하는가
"동작하는 코드"의 착각
AI는 놀라울 정도로 그럴듯한 코드를 생성한다. 문법적으로 정확하고, 실행하면 당장 동작하는 것처럼 보인다. 하지만 여기에 구조적 시한폭탄이 숨어 있다.
def get_user_data(user_id):
# 매번 새로운 DB 연결 생성 (커넥션 풀 미사용)
conn = sqlite3.connect('users.db')
cursor = conn.cursor()
# SQL 인젝션 취약점
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
result = cursor.fetchone()
# 커넥션 닫기 누락 → 리소스 누수
return result이 코드는 "동작"한다. 하지만 10명이 동시 접속하면 커넥션 풀이 고갈되고, 악의적인 입력이 들어오면 데이터베이스가 통째로 노출된다. "동작하는 코드"와 "좋은 코드"는 완전히 다른 차원의 문제인데, 바이브 코딩에선 이 차이를 놓치기 쉽다.
컨텍스트의 누적 붕괴
프로젝트 초기에는 매끄럽게 진행된다. 하지만 코드베이스가 커질수록 AI는 전체 맥락을 놓치기 시작한다.
프로젝트 규모 AI 이해도 개발자 경험
─────────────────────────────────────────────
100줄 ████████████ "와, 마법 같다!"
1,000줄 ████████░░░░ "음, 좀 이상한데?"
5,000줄 █████░░░░░░░ "왜 기존 코드를 무시하지?"
10,000줄 ███░░░░░░░░░ "전부 다시 설명해야 해?"
50,000줄+ █░░░░░░░░░░░ "차라리 직접 짜는 게 빠르겠다"솔직히 이건 현재 LLM의 근본적 한계다. 아무리 컨텍스트 윈도우가 크더라도, 수만 줄에 걸친 암묵적 설계 결정이나 비즈니스 규칙 간의 의존 관계까지 이해하긴 어렵다.
속도의 역설
바이브 코딩의 가장 위험한 함정은 속도의 환상이다. 프로토타입은 30분이면 나오는데, 그 뒤에 오는 디버깅과 리팩토링이 기존 개발보다 더 오래 걸리는 경우가 많다. 초기 속도에 도취되면 기술 부채라는 더 큰 대가를 치르게 된다. 빠르게 만든 것을 느리게 고치는 것은 처음부터 제대로 만드는 것보다 항상 비용이 크다.
제대로 된 바이브 코딩의 원칙
바이브 코딩을 효과적으로 하려면, "AI에게 모든 것을 맡긴다"는 환상을 버려야 한다.
아키텍처는 내가 정한다
AI는 구현의 세부 사항에 강하지만, 시스템 전체의 설계 결정은 사람이 해야 한다.
❌ 잘못된 접근:
"채팅 앱 만들어줘"
✅ 올바른 접근:
"WebSocket 기반 실시간 채팅을 구현하려 해.
- 아키텍처: 클라이언트(React) → API Gateway → Chat Service → Redis Pub/Sub
- 메시지 저장: PostgreSQL, 최근 100개는 Redis 캐시
- 인증: 기존 JWT 미들웨어 활용
- 먼저 Chat Service의 메시지 송수신 핸들러부터 구현해줘."아키텍처를 먼저 정하고, AI에게는 잘 정의된 범위 내에서의 구현을 맡기는 것이 핵심이다.
작은 단위로 반복한다
한 번에 "전체 인증 시스템을 구현해줘"보다는, User 모델 만들기 → 회원가입 API → 로그인 & JWT 발급 같은 식으로 쪼개서 진행한다. 각 단계마다 검토, 테스트, 커밋. 소프트웨어 공학에서 오래전부터 검증된 원칙인데, AI와 작업할 때 특히 중요하다.
이해 못하는 코드는 받아들이지 않는다
바이브 코딩에서 가장 치명적인 실수는 이해하지 못하는 코드를 수용하는 거다. AI가 코드를 생성하면 읽고, 질문하고("왜 이 패턴을 선택했어?"), 테스트하고, 필요하면 수정한 뒤에 커밋한다.
"이 코드에 버그가 있다면, 나 혼자서 디버깅할 수 있는가?" 이 질문에 "아니오"라면 아직 커밋할 준비가 안 된 거다.
컨텍스트를 충분히 제공한다
AI는 마음을 읽지 못한다. 배경(왜 이 작업이 필요한지), 제약 조건(기술 스택, 건드리면 안 되는 코드), 기대 결과, 검증 기준까지 명확하게 전달해야 좋은 결과물이 나온다.
TIP
프로젝트 규칙 문서(CLAUDE.md, cursor rules 등)를 잘 작성해두면 매번 같은 설명을 반복할 필요가 없어진다. AI와의 소통 비용을 극적으로 줄여주는 방법이다.
바이브 코딩 도구의 현재
2025~2026년 현재 도구들은 빠르게 진화하고 있다. Cursor는 IDE에 AI가 깊이 통합되어 있어서 코드를 보면서 수정하기 좋고, Claude Code는 CLI 기반이라 큰 리팩토링이나 자동화에 강하다. GitHub Copilot은 인라인 자동완성에 특화되어 있고, Bolt이나 Lovable 같은 도구는 빠른 프로토타이핑용이다.
개인적으로는 Cursor로 코딩하면서 Claude Code로 큰 작업을 맡기는 조합이 꽤 잘 맞았다. 근데 이건 사람마다 다를 거다.
에이전틱 코딩도 주목할 만하다. 단순히 코드를 생성하는 걸 넘어서, AI가 스스로 코드베이스를 분석하고, 구현 계획을 세우고, 테스트까지 실행하는 방식이다. Claude Code 같은 도구가 보여주는 에이전틱 접근은 바이브 코딩의 한계를 상당 부분 극복하고 있다.
누가 바이브 코딩을 해야 하는가
솔직한 이야기를 해보자.
경험 있는 개발자에게 바이브 코딩은 생산성 증폭기다. 이미 알고 있는 패턴을 빠르게 구현하고, 보일러플레이트를 자동화하고, 새로운 프레임워크를 빠르게 탐색할 수 있다. 잘못된 코드를 알아볼 수 있는 눈이 있으니까 안전하다.
비개발자나 입문자에게는 좀 위험할 수 있다. 동작하는 코드와 올바른 코드의 차이를 구분하기 어렵고, 문제가 생겼을 때 디버깅 능력이 부족하면 막힌다. 바이브 코딩을 하지 말라는 게 아니라, 바이브 코딩만으로 충분하다고 생각하는 것이 위험하다는 뜻이다.
입문자라면 AI가 생성한 코드를 그대로 쓰기보다 "왜 이렇게 작성했어?"라고 물어보고, 한 줄씩 이해하려는 자세가 중요하다고 본다.
앞으로 어디로 가고 있나
지금은 과도기다. 검증 자동화(정적 분석, 자동 테스트, 보안 스캔)가 바이브 코딩 워크플로우에 통합될 거고, 컨텍스트 관리도 더 나아질 거다. 코드를 직접 작성하는 능력보다 문제를 정의하고, 시스템을 설계하고, 결과를 검증하는 능력이 더 중요해질 것 같은데, 이건 개발자의 역할이 축소되는 게 아니라 더 높은 수준으로 이동하는 거라고 생각한다.
바이브 코딩의 이름에 "바이브"가 들어간다고 해서 감으로 코딩하라는 뜻은 아니다. 설계를 먼저 하고, 작게 나누고, 이해한 것만 수용하고, 테스트로 검증하고, 맥락을 관리하는 것. 결국 좋은 소프트웨어 엔지니어링 원칙의 연장선에 있다.
바이브를 즐기되, 원칙을 잃지 말자.