함정

잘 하는 법의 뒷면입니다. 어떤 것이 왜 위험한지, 숫자와 함께.

주사위 굴리기

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

검증 공백

• 실무 자료 101편의 행동 단위 518개를 분류하니 QA 실천 중 "생략" 36%, "무비판적 신뢰" 18%, "AI에 QA 위임" 10%, "디버깅 대신 재요청" 5% [5]. 코드 품질 인식은 "빠르지만 결함" 68%.

  

• 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].

수업에서

그래서

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