Vibe 코딩 숙취는 실감 난다: 프로덕션에서 AI-Generated Code에 대해 아무도 말해주지 않는 것

Source: Dev.to

지난달, 한 스타트업 창업자가 코드베이스를 검토해 달라고 보냈습니다. “주말에 Cursor로 만들었어요,” 라고 자랑스럽게 말했습니다. “우리 시리즈 A 데모 준비 완료.”

저는 레포를 열었습니다. 30초 후, 슬랙을 닫고 술을 따랐습니다.

코드는 동작했습니다. 그게 문제가 아니었습니다. 문제는 그 코드가 당분간 동작한다는 것이었죠—덕트 테이프와 기도, 그리고 그 화요일 오후 Claude가 가진 어떤 환각에 의해 얽혀 있었습니다.

이것이 vibe‑coding hangover입니다. 그리고 올해 AI가 생성한 코드를 프로덕션에 배포했다면, 이미 그 여파를 느끼고 있을지도 모릅니다.

바이브 코딩이란 실제로 무엇인가?

용어는 2025년 초 Andrej Karpathy가 “완전히 바이브에 몸을 맡기고 코드가 존재한다는 사실을 잊는다”고 트윗하면서 폭발적으로 퍼졌다.

Collins Dictionary는 이를 2025년 올해의 단어로 선정했다.

그리고 현재 84 %의 개발자가 매일 AI 코딩 도구를 사용하고 있다.

하지만 아무도 이야기하지 않는 점이 있다: 실제로는 두 가지 정의의 바이브 코딩이 떠돌고 있으며, 이를 혼동하는 것이 혼란을 초래하고 있다.

대부분의 끔찍한 이야기는 정의 1에서 비롯된다. 대부분의 생산성 향상은 정의 2에서 비롯된다.

문제는? 모두가 정의 2를 하고 있다고 생각한다.

내가 매번 보는 Vibe‑코드 재난의 5가지 패턴

올해 15 개 이상의 vibe‑코드 프로젝트(주말 해킹부터 투자받은 스타트업까지)를 검토하면서 반복되는 악몽을 파악했습니다.

1. “내 컴퓨터에서는 잘 되는데” 환상

AI는 행복 경로를 해결하는 데는 뛰어납니다. Claude에게 로그인 폼을 만들라고 하면, 유효한 이메일과 올바른 비밀번호를 입력했을 때 완벽히 동작하는 아름다운 폼을 얻을 수 있습니다.

그런데 다음 상황은 어떨까요?

• 누군가 이메일 필드에 50 000자를 붙여넣음
• 인증 도중 데이터베이스 연결이 타임아웃됨
• 사용자가 제출 버튼을 더블클릭함
• 폼 로드와 제출 사이에 세션이 만료됨

정적

지난달에 결제 처리 흐름을 검토했습니다. AI가 만든 코드는 성공적인 결제는 문제없이 처리했습니다. 실패한 결제는? 오류 처리 코드는 문자 그대로:

} catch (error) {
  console.log("Something went wrong");
}

그게 전부였습니다. 실제 돈을 다루는 결제 시스템에서 말이죠.

2. 아키텍처 기억 상실증

숨은 비밀: AI는 당신의 아키텍처를 기억하지 못합니다.

프롬프트마다 새로 시작합니다. 그래서 월요일에 Feature A를, 화요일에 Feature B를, 수요일에 Feature C를 요청하면, 각각은 고립된 상태에서는 완벽히 이해가 되지만, 함께 합치면 완전한 혼란이 됩니다.

제가 본 사례:

• 하나의 React 앱에 서로 다른 세 가지 상태 관리 방식이 혼재
• 보안을 위해 별도로 설정한 ORM을 우회하는 데이터베이스 쿼리
• 일곱 군데에 중복된(서로 다른) 인증 로직
• 네 가지 서로 다른 형식으로 데이터를 반환하는 API 엔드포인트

AI는 각 문제를 그 문제에 최적화해서 해결합니다. “우리는 이유를 두고 이렇게 하기로 결정했다”는 개념이 전혀 없습니다.

3. 보안 시한폭탄

이것 때문에 밤에 잠을 못 잡습니다.

스웨덴의 vibe‑코딩 플랫폼 Lovable은 올해 초 보안 감사를 받았습니다. 그 도구로 만든 1 645개의 애플리케이션 중 170개가 사용자 데이터를 누구든지 볼 수 있게 하는 취약점을 가지고 있었습니다.

즉, 창업자들이 프로덕션 준비가 되었다고 생각한 앱에서 **10 %**가 치명적인 실패율을 보인 것입니다.

공통 패턴:

// AI‑generated “authentication”
const isAdmin = req.query.admin === 'true';

// AI‑generated “database query”
const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);

// AI‑generated “file upload”
const filename = req.file.originalname;
fs.writeFileSync(`./uploads/${filename}`, req.file.buffer);

각 스니펫은 교과서적인 보안 실패 사례입니다: SQL 인젝션, 경로 탐색, 쿼리 파라미터를 통한 권한 상승.

이 코드는 동작하고 수동 테스트를 통과해 데모는 멋지게 보이지만, 누군가 실제로 악용하려 하면 문제가 드러납니다.

4. 디버깅 악몽

vibe‑코드 앱을 검토한 개발자가 이렇게 말했습니다:

“AI가 만든 코드를 디버깅하는 것이 수작업으로 코드를 짜는 것보다 더 어렵다.”

왜일까요? 코드를 직접 작성하면 그 동작 방식에 대한 정신 모델을 구축합니다. tempBuffer라는 변수명을 왜 썼는지, 47번째 줄에서 어떤 엣지 케이스를 처리했는지 기억합니다.

vibe‑코드 프로젝트에서는 다른 사람의 코드를 디버깅하는데, “다른 사람” 자체가 존재하지 않습니다. 코드를 만든 AI는 대화 내용을 기억하지 못합니다.

저는 6 시간 동안 vibe‑코드 베이스에서 버그를 찾아 헤맸습니다. 문제는? 거의 동일한 이름을 가진 두 함수(processUserData와 processUserInfo)가 전혀 다른 일을 했던 것입니다. 하나는 프로덕션에서 호출됐고, 다른 하나가 실제로 올바르게 동작했습니다.

AI는 같은 문제를 서로 다른 시점에 두 가지 방식으로 해결해 코드를 생성했으며, 개발자는 이를 눈치채지 못했습니다.

5. 스파게티 눈사태

모든 AI 코딩 도구는 각각 다른 “스타일”을 가지고 있습니다. 어떤 도구는 함수형 접근을 선호하고, 어떤 도구는 클래스를 좋아합니다. 어떤 도구는 주석을 생성하고, 어떤 도구는 주석을 생략합니다. async/await을 쓰는 경우도 있고, .then() 체인을 쓰는 경우도 있습니다.

몇 주·몇 달에 걸쳐 vibe‑코딩을 하면, 마치 서로 대화조차 하지 않은 50명의 개발자가 만든 코드베이스처럼 보이게 됩니다—왜냐하면 실제로 그런 상황이기 때문입니다.

ened.

Next.js 앱을 검토했는데:

• 일부 API 라우트는 App Router 패턴을 사용하고, 다른 라우트는 Pages Router 패턴을 사용함
• 일부 라우트는 원시 Express 미들웨어를 두 라우터 모두에 삽입함
• 데이터 패칭은 SWR, React Query, and 원시 fetch를 서로 다른 컴포넌트에서 사용함

각 조각은 동작했지만, 함께 사용하면 유지보수가 어려웠다.

숫자는 거짓말을 하지 않는다

연구가 실제로 보여주는 내용을 이야기해 봅시다.

생산성 신화

맞습니다, AI는 단기적인 속도를 높일 수 있지만, 기술 부채, 보안 사고, 온보딩 마찰의 장기적인 비용이 이득을 능가하는 경우가 많습니다.

대신 해야 할 일

1. AI를 마법사가 아닌 페어 프로그래머로 다루세요.
2. 검토 체크리스트를 적용하세요 (보안, 오류 처리, 스타일).
3. 공유 디자인 문서에 아키텍처 결정을 고정하고 AI가 이를 참조하도록 하세요.
4. 린팅, 테스트, 정적 분석을 자동화하여 AI가 놓치는 저수준 문제를 잡아내세요.
5. 리팩토링 시간을 할당하세요 — 첫 번째 초안 AI 출력을 “완료”로 바로 배포하지 마세요.

TL;DR

Vibe coding은 본질적으로 악한 것이 아니지만 정의가 중요합니다. AI가 내놓는 모든 것을 그대로 받아들인다면, 깨지기 쉽고, 보안이 취약하며, 유지보수가 어려운 시스템이 됩니다. AI를 사용해 보일러플레이트를 가속화하고, 모든 것을 검토하며, 아키텍처를 일관되게 유지하세요. 그렇지 않으면 계속해서 숙취 같은 대가를 치르게 됩니다.

보조 코딩: 현실 점검

보조 코딩은 통제된 연구에서 개발 시간을 25‑50 % 단축할 수 있습니다.
하지만 Google의 DORA 연구에 따르면, 실제 기업 환경에서 AI 어시스턴트에 크게 의존하는 팀은 디버깅 및 재작업을 고려하면 배포 속도가 오히려 느려집니다.

품질 격차

• Microsoft와 IBM은 현재 ~20‑30 % 정도의 코드를 AI가 생성한 것으로 추정합니다.
• IBM CEO는 유지보수 부담 때문에 AI 코드 비중이 더 높아지는 것은 지속 가능하지 않으므로 이 비율은 그대로 유지될 것이라고 말했습니다.

1.5 조 달러 문제

산업 분석가들은 2027년까지 AI가 생성한 코드로 인해 누적 기술 부채가 1.5 조 달러에 이를 것으로 전망합니다.
오타가 아닙니다—조(trillion), T가 붙은 trillion입니다.

Source: …

실제로 효과가 있는 방법은?

저는 AI 코딩에 반대하는 입장이 아닙니다. Cursor와 Claude Code를 매일 사용하지만, “바이브 코딩” 밈이 암시하는 방식과는 매우 다르게 활용합니다.

“AI 지휘자” 접근법

자신을 오케스트라 지휘자라고 생각하세요, 승객이 아니라.

AI가 해야 할 일

• 여러분이 어차피 작성할 보일러플레이트를 생성한다.
• 평가할 수 있는 접근 방식을 제안한다.
• 여러분이 이해하고 있는 로직에 대한 테스트를 작성한다.
• 검토 중인 코드를 설명한다.
• 작동 중인 코드를 더 깔끔하게 리팩터링한다.

AI가 하지 말아야 할 일

• 아키텍처 결정을 내린다.
• 보안에 중요한 경로를 검토 없이 처리한다.
• 여러분이 설명할 수 없는 코드를 생성한다.
• 정확히 명시하지 않은 비즈니스 로직을 작성한다.

30초 규칙

AI가 생성한 코드를 받아들이기 전에 스스로에게 물어보세요:

“이 코드가 무엇을 하는지 30 초 안에 주니어 개발자에게 설명할 수 있나요?”

답이 아니오라면, 절대 머지하지 마세요. 끝.

이 단일 규칙 덕분에 제가 배포했을 경우 80 % 정도의 버그를 피할 수 있었습니다.

리뷰 의식

AI가 만든 모든 코드는 다음 과정을 거칩니다:

1. 읽어보기 – 모든 라인을 이해했는가?
2. 경계 상황 체크 – null/undefined/빈값/거대한 입력은 어떻게 처리되는가?
3. 보안 눈여겨보기 – 사용자 입력이 안전하게 다뤄지는가?
4. 아키텍처 적합성 – 현재 코드베이스의 방식과 맞는가?

이 과정은 5 분 정도 걸리며, 수백 시간에 달하는 디버깅 시간을 절약해 주었습니다.

주니어 개발자에 대한 현실적인 이야기

바이브 코딩 열풍은 주니어 개발자에게 가장 큰 타격을 줄 것입니다.

• 시니어 개발자는 AI를 타이핑을 외주 주는 도구로 사용합니다. 좋은 코드가 어떤 모습인지 이미 알고 있으며, 수년간의 패턴 인식을 통해 AI 출력물을 평가할 수 있습니다.
• 주니어 개발자는 AI를 학습을 외주 주는 도구로 사용합니다. 왜 동작하는지 이해하는 과정을 건너뛰어, 매일 커지는 스킬 격차를 만들게 됩니다.

저는 “AI만 있으면 뭐든 만들 수 있다”는 주니어 개발자를 인터뷰한 적이 있는데, for 루프가 어떻게 동작하는지 설명하지 못했습니다. 그들은 프롬프트만으로 작동하는 앱을 만들 수 있었지만, 문제가 생겼을 때 디버깅은 전혀 못했습니다.

신입 개발자에게 조언
먼저 기본기를 다지세요. AI는 도구일 뿐, 지팡이가 아닙니다. 2026년 이후에도 성공할 개발자는 AI가 틀렸을 때 이를 알아차릴 수 있는 사람들입니다.

핵심 요약

Vibe coding은 본질적으로 좋거나 나쁜 것이 아닙니다. 이것은 도구이며, 모든 도구와 마찬가지로 결과는 누가 사용하느냐에 달려 있습니다.

• 경험 많은 개발자가 AI를 사용해 깊이 이해하고 있는 작업을 가속화 → 훌륭함. 아마도 그 어느 때보다 생산성이 높아졌을 것입니다.
• 완전히 이해하지 못한 AI‑생성 코드를 배포 → 모래 위에 짓는 겁니다. 숙취가 찾아옵니다. 다음 주일 수도, 내년일 수도 있지만, 반드시 찾아옵니다.

문제는 AI가 코딩 방식을 바꾸는가가 아니라—이미 바꾸었습니다.
문제는 여러분이 이를 강력한 도구로 사용하는가, 아니면 어려운 부분을 건너뛰기 위한 변명으로 사용하는가 입니다.

현명하게 선택하세요.

---

프로덕션에서 AI‑생성 코드를 사용한 경험은 어떠셨나요?
바이브 코딩 숙취를 겪어보셨나요? 댓글에 여러분의 공포 이야기(또는 성공 사례)를 남겨 주세요.