개발자는 왜 AI가 작성한 코드를 다시 읽지 않는가: 바이브 코딩의 숨겨진 함정

개발자는 왜 AI가 작성한 코드를 다시 읽지 않는가: 바이브 코딩의 숨겨진 함정

 

 

출처: siliconrepublic.com

 

최근 코드 리뷰 도중 "AI가 작성해 주었습니다"라는 말을 듣고 당황한 경험이 있을 것이다. 본인이 올린 PR인데도 정작 본인이 그 코드의 의미를 설명하지 못하는 상황이다. Cursor, Claude Code, GitHub Copilot 덕분에 생산성이 10배가 되었다고들 하지만, 정작 그 코드를 작성한 당사자조차 자신이 무엇을 만들었는지 모르는 경우가 적지 않다. 이것이 최근 개발 씬에서 가장 자주 회자되는 바이브 코딩(vibe coding) 현상이다. 이 글에서는 바이브 코딩이 무엇인지, 왜 개발자가 자신이 머지한 코드를 더 이상 읽지 않게 되었는지, 그리고 그것이 3개월 뒤 어떻게 터지는지를 팩트 중심으로 정리한다.

 

바이브 코딩이란 무엇인가

 

바이브 코딩(vibe coding)은 개발자가 AI에게 코드 생성을 지시하고, 그 코드를 직접 읽거나 검토하지 않은 채 "일단 돌아가면 OK"라는 기준으로 merge하는 개발 방식이다. Andrej Karpathy(전 OpenAI, 전 테슬라 AI 헤드)가 2025년 2월 트윗에서 처음 이름을 붙였다. 원문 표현은 "fully give in to the vibes, embrace exponentials, and forget that the code even exists"이다. 한국어 커뮤니티에서는 "감코딩", "분위기 코딩", "느낌 코딩" 정도로 번역되고 있다.

 

바이브 코딩과 일반 AI 보조 코딩의 차이

 

둘 다 AI를 활용하지만 결정적으로 다르다.

 

• AI 보조 코딩: 코드 제안을 받고 → 읽어본 뒤 → 판단하여 반영한다
• 바이브 코딩: 코드 요청 → 생성된 결과 붙여넣기 → 실행 → 에러 발생 시 에러 메시지를 다시 AI에게 전달 → 반복

 

후자는 개발자가 "검증 주체"의 자리에서 이탈하는 구조다. 개발자의 역할은 사실상 QA 대행으로 축소되고, 그마저도 "작동 여부"만 체크하는 수준에 머무른다.

 

왜 2024~2025년에 이 용어가 부상했는가

 

2022~2023년 Copilot 시절의 AI는 "자동완성" 수준에 불과했다. 그러나 2024년 말 Cursor Composer가 등장하고, 2025년 초 Claude Code Agent가 터미널에서 수십 개의 파일을 동시에 생성하면서 판도가 바뀌었다. 이제는 프롬프트 한 번에 프로젝트 하나가 뚝딱 완성된다. 사람이 읽을 시간도 없이 코드가 쏟아지다 보니 "어차피 다 읽지 못할 바에는 읽지 않는다"가 자연스러운 귀결이 된 것이다.

 

 

출처: geuni.tech

 

개발자가 AI 코드를 읽지 않게 된 5가지 구조적 이유

 

이것은 "개발자가 게을러서"와 같은 개인의 문제가 아니다. 구조적으로 읽지 않게 만들어져 있다.

 

1. 인지 과부하 회피 — 읽는 비용이 작성하는 비용보다 커졌다

 

작성은 AI가 하지만 이해는 사람이 해야 한다. 이 비용 구조가 역전되었다. 50줄짜리 함수를 작성하는 데 3초가 걸리는 반면, 그것을 꼼꼼히 읽고 로직을 따라가는 데는 5~10분이 걸린다. 뇌가 "이것은 손해다"라고 판단한다. 인지 외주화(cognitive offloading)의 전형적인 패턴이다.

 

2. 시간 압박과 "일단 돌아가면 OK" 문화

 

특히 한국 SI/스타트업 환경에서 바이브 코딩이 더 강하게 나타나는 이유가 있다. 원래부터 "일단 돌아가게 만들어라, 리팩터는 나중에"라는 문화가 자리 잡고 있었는데, AI가 이를 증폭시켰다. 스프린트에 쫓기는 상황에서 AI 코드를 읽고 앉아 있을 여유가 없다.

 

3. 블랙박스 신뢰 형성 — 100번 중 95번이 맞으면 검증을 포기한다

 

사람은 경험적으로 신뢰 구간을 형성한다. Claude나 GPT가 3개월간 매번 그럴듯한 코드를 뽑아내면, 뇌가 "이것은 그냥 믿어도 된다"라고 세팅된다. 다만 문제는 나머지 5%가 hallucination(환각) — 존재하지 않는 API, 잘못된 시그니처, 보안 취약 구조 — 라는 사실이다. 95%의 신뢰가 5%의 재앙을 가린다.

 

4. 맥락 전환 비용 — 다시 프롬프트를 치는 편이 더 싸다

 

AI 코드에 이상한 부분이 보이더라도, 그것을 파악하여 수정하는 것보다 "이 부분을 다시 작성해 달라"라는 프롬프트를 치는 편이 더 빠르다. 그래서 개발자는 코드 이해 대신 프롬프트 반복으로 문제를 해결하려 한다. 이해는 영영 이루어지지 않는다.

 

5. PR 리뷰 문화의 붕괴

 

"AI가 작성했다"라는 말이 설명 책임을 회피하는 카드가 된다. 리뷰어가 "여기는 왜 이렇게 했느냐"라고 물으면 "Cursor가 그렇게 작성했다"로 대화가 종료된다. 작성자도 모르고, 리뷰어도 그대로 넘긴다. 양쪽 모두 설명 책임에서 해방되는 공범 관계가 형성된다.

 

데이터로 본 현실 — GitClear 2024 리포트

 

GitClear가 2020~2024년에 걸쳐 1억 5천만 줄의 코드를 분석한 리포트에 따르면, AI 코딩 도입 이후 코드 중복률이 2021년 대비 2024년에 8배 이상 증가했다. 동시에 옮겨 쓰인 코드(moved code)의 비율은 25% 이상 하락했다. 이를 해석하면 "리팩터를 하지 않고 복붙으로 쌓는 경향"이 심화되었다는 의미다. Stack Overflow Developer Survey 2024에서도 AI 도구 사용률은 76%에 달하지만, "AI 출력의 정확성을 신뢰한다"는 응답 비율은 43%에 불과하다. 사용은 하지만 믿지는 않는 셈이다. 그럼에도 읽지 않는다. 이것이 바이브 코딩의 정체다.

 

 

바이브 코딩의 기술 부채가 터지는 순간

 

"일단 돌아간다"라는 상태가 얼마나 지속 가능한지는 현장 사례를 보면 답이 나온다.

 

파산 패턴 A: hallucinated API 호출로 인한 런타임 에러

 

Cursor가 존재하지 않는 라이브러리 메서드를 사용해 코드를 뽑아내는 경우가 흔하다. 로컬에서는 mock으로 돌아가니 모르고 넘어간다. 그러나 프로덕션에서 실제 호출이 이루어지면 AttributeError 혹은 TypeError로 터진다. 이때 당사자조차 코드의 의미를 모르니 디버깅도 불가능하다.

 

파산 패턴 B: 3개월 뒤 본인도 읽지 못하는 코드

 

가장 흔한 참사다. 급한 이슈를 AI에게 맡겨 해결한 뒤 머지했는데, 3개월 뒤 관련 버그 리포트가 들어온다. 본인이 작성한 코드지만 아무리 들여다봐도 어떤 로직인지 알 수 없다. git blame을 찍으면 본인의 이름이 찍혀 있다. 결국 그 코드를 갈아엎고 다시 작성하게 된다. 시간으로 따지면 처음부터 제대로 작성했을 때보다 오히려 더 많이 걸린다.

 

파산 패턴 C: 보안 취약점 — 하드코딩 시크릿, 검증 없는 입력

 

Simon Willison이 블로그에서 여러 차례 경고한 지점이다. AI는 "돌아가는 코드"는 잘 작성하지만 "안전한 코드"는 잘 작성하지 못한다. API 키를 그대로 박아두거나, 사용자 입력에 대한 sanitize를 생략하거나, SQL injection 구멍을 남겨두는 경우가 실제로 많다. 2024년 Hacker News 토론 스레드에서도 어느 스타트업이 Cursor로 작성한 코드에서 Stripe 시크릿 키가 public repo에 노출된 사례가 공유된 바 있다.

 

Simon Willison의 "safe vibe coding" 원칙

 

Simon Willison은 자신의 블로그 "Here's how I use LLMs to help me write code"에서 바이브 코딩을 전면 부정하지 않고 대신 경계선을 긋는다. 핵심은 "개인 장난감 프로젝트, 일회용 스크립트는 바이브로 가도 된다. 다만 배포되는 것, 남이 사용하는 것, 돈이나 개인정보가 오가는 것에는 바이브를 금지한다"이다. 이것이 정답에 가깝다.

 

주니어 개발자 실력 저하 논쟁

 

최근 시니어들 사이에서 "AI 때문에 주니어 실력이 늘지 않는다"라는 이야기가 많이 돈다. 다만 이것은 절반만 맞다. 정확히 말하면 "바이브 코딩에만 익숙한 주니어"의 실력이 늘지 않는다. 왜일까? 코드를 읽지 않기 때문이다. 읽지 않으면 패턴을 배울 수 없다. 패턴을 배우지 못하면 AI 없이는 아무것도 하지 못하는 상태가 된다. 이것은 연차가 쌓인 뒤 본인이 가장 크게 손해를 보는 구조다.

 

시니어가 바이브 코딩을 덜 위험하게 쓸 수 있는 이유

 

시니어가 Cursor를 써도 덜 위험한 이유가 있다. 이미 수많은 코드를 읽은 경험이 축적되어 있어 3초만 훑어도 "이것은 이상하다"라는 감지가 작동한다. 이것이 바로 주니어가 갖지 못한 자산이다. AI 생성 코드 검토에서 가장 중요한 것은 "의심할 줄 아는 눈"이며, 이는 결국 과거에 코드를 많이 읽어본 경험에서 비롯된다.

 

안전하게 바이브 코딩하는 개발자는 무엇이 다른가

 

바이브 코딩 자체가 악은 아니다. 선을 어디에 긋느냐가 전부다.

 

프로젝트 등급에 따른 분리

 

프로젝트 성격	바이브 코딩 허용 수준
토이/사이드 프로젝트	풀 바이브 OK
팀 내부 툴	기능 단위 리뷰 필수
외부 고객 프로덕션	줄 단위 풀 리뷰 필수
결제/인증/개인정보	AI 생성 후 시니어 재작성
보안 크리티컬	AI 사용 금지 또는 엄격한 샌드박스

 

이 표를 팀 컨벤션으로 문서화해 두는 회사가 최근 늘고 있다.

 

"샘플링 리뷰" — 100% 읽지 못해도 20~30%는 본다

 

모든 코드를 전부 읽을 시간이 없다면, 무작위로 20~30%를 골라 깊게 읽는 방식이 현실적이다. 사람이 "지켜보고 있다"라는 전제가 들어가야 AI 코드의 퀄리티도 관리된다.

 

테스트 선작성 → AI에게 통과 코드 요구 (TDD + AI)

 

이것은 최근 유명해진 기법이다. 각설하고, 개발자가 테스트부터 작성한다. 그다음 AI에게 "이 테스트를 통과하는 구현을 작성해 달라"라고 지시한다. 이렇게 하면 AI가 뻘짓을 해도 테스트가 막아준다. 동시에 개발자는 "의도"를 여전히 자신이 쥐고 있다. 바이브 코딩의 속도를 누리면서 검증은 놓치지 않는 절충안이다.

 

타입 시스템으로 AI 실수 차단

 

TypeScript, Rust, Kotlin과 같은 정적 타입 언어를 사용하면, AI가 존재하지 않는 메서드를 호출하거나 잘못된 시그니처를 쓰는 것을 컴파일 단계에서 잡아낸다. Python을 사용한다면 type hint + mypy 강제가 최소한의 방어선이다. 동적 타입 언어에서의 바이브 코딩은 가장 위험한 조합이다.

 

git diff 확인 + checkpoint 습관

 

Cursor Composer나 Claude Code로 여러 파일을 수정했을 때, 반드시 git diff로 실제 변경 내용을 확인하고 commit을 여러 개로 쪼개는 습관이 필수다. 이렇게 해 두면 이후에 어디서 터졌는지를 추적할 수 있다. 바이브 코딩으로 한 번에 10개 파일을 건드리고 한 커밋에 몰아넣으면, 나중에는 본인도 찾지 못한다.

 

"이 코드를 왜 이렇게 작성했는지 설명해 달라"는 2차 프롬프트

 

AI에게 코드를 작성하게 한 뒤, 그 자리에서 "이 코드의 시간복잡도는 무엇인가? 엣지 케이스는 무엇인가? 왜 이 라이브러리를 골랐는가?"와 같은 2차 프롬프트를 던지는 방식이다. 이렇게 하면 AI가 자신이 작성한 코드를 해설해 주므로 개발자의 이해 비용이 크게 낮아진다. 바이브 코딩을 "학습 모드"로 전환시키는 트릭이다.

 

 

출처: Geeky Gadgets

 

그래서 바이브 코딩, 해야 하는가 하지 말아야 하는가

 

결론부터 말하면 해야 한다. 다만 "언제, 어디까지"가 핵심이다. 사용하지 않으면 생산성 차이를 따라잡지 못하고, 무분별하게 사용하면 3개월 뒤 본인의 발목을 잡는다.

 

팀 단위 가드레일이 필요하다

 

개인이 "나는 그러지 말아야지"라고 다짐하는 것만으로는 부족하다. 팀 차원의 합의가 있어야 한다. 실제로 도입되는 룰은 다음과 같다.

 

• PR 템플릿에 "AI 사용 여부" 체크박스 삽입 — 본인이 AI를 사용했다고 밝히면, 리뷰어가 더 꼼꼼히 살펴본다
• 자동 시큐리티 스캐너 (gitleaks, Semgrep, CodeQL)를 CI에 필수 탑재 — AI가 흘린 시크릿/취약점을 걸러낸다
• 의무 테스트 커버리지 하한선 — AI가 작성한 코드라도 테스트가 없으면 머지 불가
• 중요 디렉토리는 시니어 리뷰 필수 (결제, 인증, DB 스키마) — 자동 머지 금지

 

회사/팀 문화 차원의 변화

 

"이것은 AI가 작성했다"라는 대답을 그대로 넘기지 않는 문화가 필요하다. "그래서 이 코드를 설명할 수 있느냐"까지 물어봐야 한다. 작성자에게 설명 책임을 다시 얹는 것이다. 이 한 가지만 바꾸어도 바이브 코딩의 절반은 막을 수 있다.

 

진짜 문제는 AI 의존성이 아니다

 

다들 "AI 의존성"이 문제라고 말하지만, 사실 그것이 진짜 문제는 아니다. 진짜 문제는 검증 없는 의존성이다. 계산기를 쓴다고 산수 실력이 늘지 않는 것은 아니다. 다만 계산기 결과를 검산 한 번 없이 그대로 제출하면, 그것은 사고다. 바이브 코딩도 동일한 구조다. AI에 의존하는 것 자체는 괜찮다. 검증 과정이 없는 의존이 위험한 것이다.

 

요약하면 이렇다

 

• 바이브 코딩은 Karpathy가 2025년 2월에 이름을 붙인 개념이다. AI가 작성한 코드를 읽지 않고 머지하는 방식이다
• 개발자가 읽지 않게 된 것은 게으름이 아니라 구조적 이유 5가지 때문이다. 인지 비용 역전, 시간 압박, 블랙박스 신뢰, 맥락 전환 비용, PR 리뷰 붕괴가 그것이다
• 기술 부채는 3개월 뒤 반드시 터진다. hallucination 런타임 에러, 본인도 읽지 못하는 코드, 보안 취약점의 3가지 패턴이 대표적이다
• 안전한 바이브 코딩은 존재한다. 프로젝트 등급 분리, TDD + AI, 타입 시스템 강제, git diff 습관, 2차 프롬프트가 그 방법이다
• 개인의 다짐이 아니라 팀 가드레일이 답이다. PR 템플릿, CI 시큐리티 스캐너, 커버리지 하한선, 시니어 리뷰 의무화가 필요하다

 

오늘 Cursor로 작성해 push한 코드 중, 한 줄이라도 읽고 올린 것이 맞는가? 그렇지 않다면 지금이라도 git diff를 한 번 돌려보는 편이 좋다. 3개월 뒤 본인을 살리는 길이다. 다음 글에서는 Cursor를 프로덕션에서 안전하게 쓰는 구체적 워크플로우를 정리할 예정이다.