우리 인턴이 AI로 2개월짜리 백엔드 작업을 오후 한나절 만에 '바이브 코딩'으로 대체함. 데모는 쉬운 부분이었을 뿐.
our intern vibe coded a replacement for a 2-month backend in an afternoon. the demo was the easy part
핵심 요약
AI 생성 코드의 결과물만 중시하고 내부 로직을 이해하지 못하는 인턴 때문에 코드 리뷰 부담이 두 배로 늘어난 개발자의 고충.
- AI 의존성 문제 — 인턴이 생성된 코드를 이해하지 못한 채 제출하여 리뷰어의 업무 부하가 가중됨
- 생산성 착시 — 데모는 화려하지만 보안, 예외 처리, 데이터 흐름 등 실무적 완성도가 결여됨
- 코드 리뷰 정책 — AI 활용 PR에 대해 로직 설명 및 테스트 케이스 검증을 의무화하는 새로운 규칙 도입
- 소유권의 부재 — AI가 생성한 결과물과 개발자가 직접 책임지는 코드 사이의 간극이 발생함
이번 주는 우리 팀이 AI 보조 작업을 어떻게 검토해야 할지 다시 생각하게 만든 한 주였다.
상황을 좀 설명하자면, 우리 팀은 지난 두 달 동안 새로운 내부 환불 승인 엔진을 천천히 만들고 있었다. 실제 Stripe 웹훅이랑 고객 개인정보(PII)를 다루는 거라, 속도 조절하면서 제대로 된 테스트 코드까지 짜는 중이다.
나 AI 반대하는 꼰대 아니다. Codex, Claude Code, Enter Code 같은 거 쓰는 사람이 자기 작업 내용을 제대로 이해하고 있으면 진짜 유용하거든. 우리 엔지니어링 팀도 이런 툴을 밥 먹듯이 쓰고, 프로덕트 팀 절반은 아예 Codex랑 한 몸이 됐고, 나도 매일 Claude로 보일러플레이트 짜고 디버깅한다.
문제는 우리 인턴 녀석이 자기가 뽑아낸 결과물을 제대로 읽지도 않고 자기 걸로 만들 생각도 안 한다는 거다.
처음엔 사소했다. DB에서 특정 환불 상태를 어떻게 처리할지 간단하게 물어봤는데, 한 문장으로 답하는 대신 환불 매트릭스에 관한 4페이지짜리 생성형 메모를 보내더라.
4페이지인데 정작 답은 없음. 결국 내가 직접 알아냈다.
그게 패턴이 돼버렸다. 아무도 읽을 리 없는 몇 페이지짜리 글을 잔뜩 뽑아놓고, 나는 그 속에 답이 있는지 없는지 찾으려고 그 긴 걸 다 뒤져야 한다.
그러다 스크립트 수정 좀 해달라고 했더니, 우리 환경에선 일어날 수도 없는 네트워크 에러 방어 로직까지 넣어서 300줄짜리 중첩 코드를 짜왔더라. 특정 조건을 왜 넣었냐고 물어보니까 설명도 못 함. 내 질문을 그대로 LLM에 복붙해서 나온 답을 확인도 안 하고 나한테 다시 보내더라.
어제는 정점을 찍었다. 우리 속도가 너무 느리다고 답답해하더니, 환불 스펙을 AI 앱 빌더에 다 집어넣고는 오후 내내 뚝딱거려서 번지르르한 풀스택 대체 데모를 들고 왔다.
솔직히 겉보기엔 깔끔하긴 했다. UI도 매끄럽고 버튼도 잘 작동함. AI 잘 다룬다고 입 털어서 뽑았던 우리 비기술직 매니저는 그거 보고 감탄하더라.
심지어 매니저가 그 데모를 새 베이스로 삼아서 프로덕션에 연결하면 속도 좀 나지 않겠냐고 제안까지 함.
내가 바로 반박했다. 세션 인증은 어디 있는지, PII가 로그에 안 남게 어떻게 처리했는지, 환불 도중에 결제 웹훅 끊기면 어떻게 되는지 물어봤다.
그 녀석, 모델한테 다시 물어보지 않고는 질문 하나도 제대로 대답 못 하더라. 데이터 흐름을 전혀 이해 못 하고 있었음. 겉만 번지르르하지, 실제 프로덕션에서 돌아갈 수준은 전혀 아니었다.
더 짜증 나는 건, 얘가 기본 업무를 못 하는 게 아니라는 거다. 그냥 모든 걸 에이전트에 돌리기 전에 잠깐 멈춰서 스스로 생각하면 훨씬 간단해질 일들을 굳이 그렇게 안 하려고 함.
결국 모든 지름길이 내가 읽어야 할 문서, 내가 풀어야 할 꼬인 코드, 내가 잡아야 할 보안 이슈로 돌아온다. 걔가 '완성'이라고 생각하는 게 그냥 모델에서 뽑아낸 결과물일 뿐이라, 내 검토 업무만 두 배로 늘었다.
분명히 말하는데, '바이브 코딩(vibe coding)'을 금지하거나 다 같이 손으로 보일러플레이트나 짜자는 소리가 아니다. 그 데모를 보면서 AI가 아이디어를 얼마나 빨리 실체화할 수 있는지 확실히 체감했으니까.
문제는 '생성'과 '자기 것으로 만드는 것(ownership)'을 똑같다고 착각하는 거다.
우리 팀에서 AI는 작성자가 결과물을 이해하지 못하면 업무를 줄여주는 게 아니다. 해석, 테스트, 보안, 예외 케이스 처리를 전부 검토하는 사람한테 떠넘기는 꼴이다.
그래서 월요일부터 새 규칙을 시행하기로 했다. 툴은 뭘 쓰든 상관없는데, AI가 짠 PR은 검토 가능할 정도로 작아야 하고, 제출하는 사람이 핵심 로직, 데이터 흐름, 테스트, 실패 케이스를 직접 설명해야 한다.
에이전트한테 다시 물어보지 않고는 설명 못 한다? 그럼 그 PR은 통과 안 시켜줄 거다.
이미 이런 문제 겪고 있는 팀들은 어떤 검토 규칙이 효과가 있었냐? 주니어들한테 diff를 한 줄씩 설명하게 시키냐, PR 사이즈를 제한하냐, 아니면 특정 테스트를 강제하냐? 다들 어떻게 처리하고 있는지 궁금하다.


