# 함정

> [!NOTE]
> **한 장 요약.** 위험은 생성이 아니라 **평가**에 있다. 결과를 안 보고 에러만 다시 붙여 넣는 것(주사위 굴리기), 다 했다는 보고를 믿는 것, 첫 결과와 기본값에 고착되는 것(동질화), 남에게 보이는 순간 필요해지는 보안. 로컬에서 도는 작품은 대부분 안전하지만 폼·DB·API 키·로그인이 붙는 순간 숫자가 바뀐다.

[잘 하는 법](https://opencircuit.club/wiki/vibe/practice)의 뒷면입니다. 어떤 것이 왜 위험한지, 숫자와 함께.

## 주사위 굴리기

유튜브 라이브 세션 7편(16시간, 프롬프트 254개)을 분석한 FSE 2026 논문 [13]. 코드를 한 번도 열지 않은 V5는 한 시간 동안 **에러 메시지만 담은 프롬프트를 31번** 보냈고, 결국 "YOLO 모드"를 켰습니다. 코드를 본 적 없는 두 사람은 프롬프트의 40%가 새 정보 없는 재요청이었고, 코드를 보거나 배경지식이 있는 사람은 20% 미만이었어요. 세션의 20% 이상(V5는 50% 이상)이 **생성을 기다리는 시간**이었습니다. 한 논평자의 반론이 정확합니다: "이미지는 다시 굴리면 되지만, **프로그래밍에서는 픽셀 하나 어긋나면 버그다**."

![스트리머 V1~V7의 프롬프트 구성. 주황 빗금이 "같은 방법을 새 정보 없이 반복"(주사위 굴리기). 코드를 본 적 없는 V4·V5가 가장 크다. 출처: Chou 외 (2025) Fig. 6 [13], CC BY-NC-ND 4.0](/wiki/vibe/fig-2512.22418-1.png)

## 검증 공백

- 실무 자료 101편의 행동 단위 518개를 분류하니 QA 실천 중 **"생략" 36%**, "무비판적 신뢰" 18%, "AI에 QA 위임" 10%, "디버깅 대신 재요청" 5% [5]. 코드 품질 인식은 "빠르지만 결함" 68%.
![실무 자료 101편에서 세어 본 주제 빈도 — 동기(빨강)는 속도가 압도적이고, 경험(파랑)은 "즉각적 성공과 몰입", 품질 인식(보라)은 "빠르지만 결함", QA 실천(청록)은 "생략"이 가장 많다. 출처: Fawzy 외 (2025) Fig. 2 [5], CC BY 4.0](/wiki/vibe/fig-2510.00328-1.png)

- 162명 설문에서 비개발자는 "생성 코드를 확인하지 않는다"고 답한 유일한 집단이었고, 이해가 안 돼 디버깅을 포기하는 비율이 가장 높았습니다 [6].
- 리뷰 47편의 결론: "이 분야는 **무엇을 권할지**에는 수렴하지만 **무엇이 효과가 있는지**에는 아직 아니다" [4].

이 공백에 빠지는 사람을 한 논문은 "**만들 수는 있지만 고칠 수는 없는** 새로운 취약 개발자 집단"이라 부릅니다 [5]. 위험한 순간은 실패할 때가 아니라 "**작동하는 것처럼 보이면서** 미묘한 취약점과 기술 부채를 품을 때"입니다.

## 다 했다는 거짓말

에이전트는 진행 상황을 부풀립니다. 세 세션 사례 연구 [11]에서 Claude Code는 "SYSTEM OPERATIONAL & VALIDATED", "혁명적 성과 문서화"를 선언하다가, 추궁받자 "135개 중 97개 테스트 실패"를 인정하고 "나는 정직보다 유능해 보이는 것을 우선하도록 설계된 것 같다"고 말했습니다. 저자들은 이것을 무작위 환각이 아니라 "사용자 신뢰를 이용하도록 조율된 맥락 민감 연기"로 읽고, **바이브 코딩의 비공식적 분위기가 "흐름을 유지하려고 검증을 건너뛰는" 경향을 키운다**고 봅니다. 표본이 작고 해석이 강한 논문이니 사례로만 인용하세요. 그러나 시각화 연구 16명에서도 같은 것이 관찰됐습니다: "일부만 하고 요약에는 전부 했다고 보고" [29]. 보안 연구에서는 취약점을 재도입한 실행의 32%에서 에이전트가 위험을 **알면서도** 주석으로 옮기고 배포했습니다 [30].

## 문맥의 관성

Sarkar와 Drosos가 "context momentum"이라 부른 것 [2]: 앞선 상호작용과 출력이 이후 방향을 강하게 규정하는 경로 의존. 초기에 받아들인 해석에서 나중에 벗어나기 어렵고, **"프로토타입과 프로덕션의 경계가 흐려져" 첫 '바이브'가 프로젝트 전체의 궤적을 정합니다**. 실무자들의 "프롬프트 소용돌이", "30개 파일이 커밋 없이 바뀐 대참사" [12], 긴 세션에서 모델이 "멍청해지는" 느낌 [13]이 같은 현상의 다른 얼굴입니다.

## 동질화와 고착

- 통제 실험: LLM이 있으면 정답들이 서로 더 비슷해지고, 아이디어 생성이 짧아지고, '아하'가 줄어듭니다 — **자유도가 큰 과제일수록** [25].
- 해커톤: 27명 중 23명이 아이디어 5개 이하, 모든 앱 UI가 비슷 [14]. 워크숍 예시를 그대로 닮은 결과물이 낮은 독창성 점수를 받았고, 저자들은 "발판을 점차 걷어 내야" 한다고 [16].
- 디자이너들: "쉬운 답에서 멈추기 쉽다 … 진짜 창의적 돌파가 일어나는 어렵고 지저분한 탐색을 건너뛰게 된다"; "조심하지 않으면 모든 것이 같아 보이고 같이 작동할 것" [19]. "거의 완성된 초안을 받으면 **남의 작업처럼 느껴진다**"는 소유감 문제도.
- 거시적으로는 되먹임: 인터넷의 통계적 평균으로 훈련된 모델이 "보편적 동질화기"가 되고, 그 결과물이 다시 훈련 데이터가 되는 "디지털 유산의 항구적 평탄화" [28]. 컴프턴이 2015년에 "오트밀 천 그릇"이라 부른 것 [38].

## 이해의 상실

- "그림 그리듯 코딩"의 대가는 "코드의 물질적 저항과 씨름하며 생기는 깊은 체화적 이해와 기술 형성"의 상실 [2].
- 예술가: "무슨 일이 일어나는지 붙잡고 있다는 느낌이 덜하다" [21]; 11명 중 7명이 코드를 안 봄 [24].
- 교육 연구는 "역량의 착각"을 경고합니다: AI와 함께일 때 자신 있던 학생이 혼자서는 못 했고, "이해했다고 생각했는데 직접 만들어 보니 아니었다" [18]. 같은 논문은 완전 초보에게는 바이브 코딩을 "엄격히 제한"하라고 하는데, 이는 **소프트웨어 엔지니어가 되려는 사람** 기준입니다. 작품을 만들려는 사람에게 그 기준을 그대로 적용할 이유는 없지만, "설명해 봐"와 "AI 없이 다시 만들어 봐"라는 두 연습은 가져올 만합니다.
- 초보의 함정은 반대 방향에도 있습니다: "질문을 하려면 무엇을 모르는지 알 만큼은 알아야 한다" [13]. 3D 게임을 만들던 스트리머: "3D 엔진을 몰라서 뭘 시켜야 할지 모르겠다."

## 보안

깃허브에서 AI가 85% 이상 작성한 앱 10,517개를 찾고 배포된 200개를 감사한 연구 [30]: **90%에 취약점**, 그중 77%가 심각·높음. 접근 제어 실패가 36%, 취약점의 63%가 백엔드. 작은 앱일수록 밀도가 높았고("작다고 안전하지 않다"), 중간 개발 기간은 9.8일이었습니다. 실패 유형 셋 — **기억 결함**(새 라우터엔 인증을 붙이고 옛 핸들러 11개엔 안 붙임; `// TODO` 그대로 출시), **목표 결함**("Supabase 인증이 깨져서" 우회 로그인 추가; "데모용" base64 암호화), **지식 결함**(존재하지 않는 API 환각; `CLAUDE.md`에 적힌 "시저 암호로 키를 보호하라").

로컬에서 도는 작품은 대부분 해당이 없습니다. **폼, 데이터베이스, API 키, 로그인이 붙는 순간** 이 숫자가 여러분 것이 됩니다.

## 비용과 종속

- "API 크레딧과 강력한 기계에 대한 의존 — 배제와 기술 엘리트주의 우려" [9].
- 통제는 사라지지 않고 모델·프로토콜 제공자에게 집중됩니다 [10]. 가격 변경, 서비스 중단 [3].
- 창작 코드의 5.5%가 이미 사라졌고, 생성 예술은 자산·API·기기 프로토콜이라는 "취약한 공급망"에 의존합니다 [36]. 아무도 이해하지 못하는 생성 코드는 보존이 더 어렵습니다.
- 그리고 중독: "나는 말 그대로 중독됐다 … 사람들이 나를 대단한 코더로 생각할 때 거짓 속에 사는 기분" [12]; "거의 중독처럼" [19].

## 수업에서

> [!TIP]
> - 체크인(15:50 · 16:40) 때 손을 든 사람에게 첫 질문은 "마지막 세 프롬프트에 **새 정보**가 있었나요?"입니다. 없었다면 주사위를 굴리고 있는 것입니다.
> - 에이전트가 "완료"라고 하면 옆 사람이 **한 번 눌러 보는 것**을 규칙으로. 두 번째 눈이 가장 싼 검증입니다.
> - GitHub Pages로 공개하기 직전, `.env`가 `.gitignore`에 있는지 짝이 확인해 줍니다.

## 그래서

이 목록이 말리는 것은 바이브 코딩이 아니라 **"결과를 안 보는 바이브 코딩"** 입니다. 리뷰 47편의 마지막 문장: "바이브 코딩은 속도 위주의 지름길로 취급되어서는 안 된다" [4]. 같은 문헌이 가장 강하게 지지하는 용도가 "프로토타이핑과 UI"라는 것도 기억하세요 — 우리가 첫날 하는 일이 정확히 그것입니다.