바이브 코딩, 몇 달 써보고 느낀 현실

올해 초, 안드레이 카파시가 트위터에 올린 글이 화제였다. "There's a new kind of coding I call 'vibe coding'." AI에게 대충 말하면 코드가 나오고, 돌아가면 넘어가고, 에러가 나면 에러 메시지를 그대로 붙여넣는 방식. 그는 이걸 반쯤 농담으로 말했는데, 현실에서는 이게 진지한 개발 방법론이 되어버렸다.

나도 지난 몇 달간 바이브 코딩을 나름 진지하게 해봤다. Copilot에서 시작해서 Cursor를 거쳐 Claude Code까지. 결론부터 말하면, 생산성은 확실히 올랐다. 하지만 생각했던 것과는 다른 방식으로.

바이브 코딩이 뭔데

카파시의 원래 정의는 이렇다. "자연어로 원하는 걸 설명하면 AI가 코드를 작성하고, 결과가 동작하면 그냥 넘어가는 방식." 핵심은 코드를 직접 읽지 않아도 된다는 거다.

과격하게 들리지만, 솔직히 말하면 이미 많은 개발자가 부분적으로 이렇게 일하고 있다. Stack Overflow에서 코드 복붙하는 거랑 본질적으로 뭐가 다른가. AI가 더 정확하고 맥락을 이해한다는 차이 정도다.

다만 "코드를 읽지 않는다"는 부분이 문제가 된다. 나중에 다시 얘기하겠지만, 이 지점이 바이브 코딩의 가장 위험한 함정이다.

내가 써본 도구들

GitHub Copilot

가장 먼저 써본 AI 코딩 도구. 자동완성 수준에서는 확실히 편하다. 반복적인 보일러플레이트, getter/setter, 테스트 케이스 생성 같은 건 놀랍도록 잘한다.

하지만 프로젝트 전체 맥락을 이해하는 능력은 약하다. 파일 하나 안에서는 꽤 정확한데, 파일 간 의존성이나 프로젝트 컨벤션을 모르는 경우가 많았다. "이 프로젝트에서는 이렇게 안 쓰는데..." 하고 수정하는 일이 잦았다.

Cursor

에디터 자체에 AI가 통합된 형태. Copilot보다 컨텍스트 윈도우가 넓어서 프로젝트 구조를 더 잘 파악한다. @codebase로 프로젝트 전체를 참조할 수 있는 것도 좋았다.

Cursor에서 인상적이었던 건 "이 파일 수정해줘"라고 하면 diff를 보여주고, 수락/거절할 수 있는 UX다. 코드 리뷰하는 느낌으로 AI의 결과물을 검토할 수 있어서, 무비판적으로 코드를 받아들이는 위험이 좀 줄어든다.

Claude Code

터미널에서 작동하는 CLI 기반 에이전트. 이전에 블로그에 따로 글을 쓸 정도로 인상적이었다. 파일을 직접 읽고, 수정하고, 빌드하고, 테스트까지 돌린다. 진짜 "주니어 개발자한테 일 시키는" 느낌에 가장 가깝다.

다만 컨텍스트가 길어지면 앞에서 한 얘기를 까먹거나, 같은 실수를 반복하는 경우가 있다. 그래서 작업 단위를 작게 쪼개서 지시하는 게 중요하다. 결국 AI를 잘 쓰려면 일을 잘 쪼개는 능력이 필요하다.

실제로 생산성이 올랐나

솔직히 말하면, 올랐다. 하지만 기대했던 것과는 다른 영역에서.

확실히 빨라진 것:

• 보일러플레이트 코드 작성 (API 엔드포인트, CRUD, DTO 매핑)

• 익숙하지 않은 라이브러리 탐색 ("이 라이브러리에서 이거 어떻게 해?")

• 테스트 코드 작성 (특히 단순 단위 테스트)

• 정규식, SQL 쿼리 같은 "인간이 약한" 영역

• 문서 작성, 커밋 메시지, PR 설명

별로 안 빨라진 것:

• 아키텍처 설계 (AI는 "어떻게"에 강하지만 "왜"에 약하다)

• 복잡한 비즈니스 로직 (도메인 지식이 필요한 부분)

• 성능 최적화 (프로파일링 결과를 해석하고 판단하는 건 여전히 사람 몫)

• 디버깅 (AI가 원인을 찾는 것보다 사람이 직감으로 찾는 게 빠른 경우가 많다)

체감으로 전체 개발 시간의 30~40% 정도가 절약된 느낌이다. 하지만 이건 "코딩 시간"이 줄어든 거지, "개발 시간" 전체가 줄어든 건 아니다. 요구사항 분석, 설계, 코드 리뷰, 디버깅에 들어가는 시간은 크게 변하지 않았다.

코드 품질 문제: 여기가 핵심이다

바이브 코딩의 가장 큰 문제는 "돌아가니까 괜찮겠지"라는 마인드셋이다.

AI가 생성한 코드는 대부분 동작한다. 하지만 동작하는 것과 좋은 코드인 것은 다르다. 실제로 경험한 문제들:

• 과도한 추상화 — 3줄이면 될 걸 인터페이스, 팩토리, 전략 패턴을 동원해서 30줄로 만듦

• 에러 핸들링 부재 — Happy path만 구현하고 예외 상황을 무시

• 보안 구멍 — SQL 인젝션이나 XSS에 취약한 코드를 자연스럽게 생성

• 성능 무시 — N+1 쿼리, 불필요한 전체 스캔 등을 아무렇지 않게 작성

• 프로젝트 컨벤션 무시 — 기존 코드와 스타일이 다른 코드를 생성

이런 문제들을 잡으려면 결국 코드를 읽어야 한다. "코드를 읽지 않아도 된다"는 바이브 코딩의 전제가 깨지는 지점이다.

주니어와 시니어가 다르게 써야 하는 이유

이 부분이 가장 중요하다고 생각한다.

시니어 개발자가 바이브 코딩을 하면, AI가 생성한 코드를 보고 "이건 문제가 있다"는 걸 직감적으로 안다. 경험에서 오는 패턴 인식이 있기 때문이다. AI는 타이핑을 대신해주는 도구이고, 판단은 여전히 사람이 한다.

주니어 개발자가 바이브 코딩을 하면 위험하다. 코드가 왜 그렇게 작성되었는지 이해하지 못한 채 넘어갈 수 있다. 동작하니까 괜찮다고 생각하지만, 실은 기술 부채가 쌓이고 있는 거다. 더 심각한 건, 배움의 기회를 잃는다는 것이다.

코딩을 배우는 과정에서 가장 중요한 건 삽질이다. 에러를 만나고, 디버깅하고, 왜 이렇게 동작하는지 이해하는 과정에서 실력이 는다. AI가 이 과정을 건너뛰게 해주면 단기적으로는 편하지만, 장기적으로는 성장의 천장이 낮아진다.

그렇다고 주니어가 AI를 안 쓸 수는 없다. 현실적인 조언을 하자면:

• AI가 생성한 코드를 반드시 한 줄씩 읽고 이해하고 넘어갈 것

• "왜 이렇게 작성했어?"라고 물어보는 습관을 들일 것

• AI 없이도 같은 코드를 작성할 수 있는지 스스로 점검할 것

바이브 코딩의 미래

과대평가와 과소평가 사이 어딘가에 진실이 있다.

과대평가: "AI가 개발자를 대체한다" — 아직 멀었다. 복잡한 시스템 설계, 도메인 이해, 사용자 공감은 AI가 할 수 없다.

과소평가: "AI는 자동완성 수준" — 이건 1년 전 얘기다. 지금은 파일 간 맥락을 이해하고, 프로젝트 구조를 파악하고, 테스트까지 작성한다.

현실적으로 바이브 코딩은 "개발자의 생산성 도구"로 자리잡을 것이다. 엑셀이 회계사를 대체하지 않았듯, AI 코딩 도구도 개발자를 대체하지 않는다. 대신 AI를 잘 다루는 개발자와 그렇지 않은 개발자 사이의 생산성 격차는 벌어질 것이다.

몇 달간의 경험을 한 문장으로 요약하면 이렇다. 바이브 코딩은 "코드를 작성하는 방식"을 바꾸지만, "소프트웨어를 만드는 방식"은 바꾸지 않는다. 코딩은 소프트웨어 개발의 일부일 뿐이고, 나머지 — 설계, 판단, 커뮤니케이션, 디버깅 — 는 여전히 사람의 영역이다.

솔직히 말하면, 나도 이제 AI 없이 코딩하는 건 상상하기 어렵다. 그만큼 편하다. 하지만 AI가 작성한 코드를 읽지 않고 넘어가는 순간, 그건 개발이 아니라 도박이다.