"AI 가 약해서가 아닙니다 — 우리가 구조를 안 줘서 입니다." — Boris Cherny (Anthropic Claude Code 책임자)

---

도입 — 1 부의 권위 가 증거 로 바뀐다

1 부에서 "설계가 먼저" 라는 말의 외부 증언 을 들었다. 이제 그 말이 실제 사고로 어떻게 나타나는지 의 청구서를 본다.

이 장에서 보는 7 건의 사고는 모두 2025–2026 년에 일어난 실제 프로덕션 사고 다. 모두 AI 협업 도구를 적극적으로 잘 쓴다고 자처한 사람들 이 만든 것이다. 입문자가 실수한 것이 아니다. Anthropic 직원이 자기 도구를 쓰다 망친 사례 도 들어 있다.

이 장을 공포 마케팅 으로 읽지 마라. 7 건의 공통 원인 을 추출하는 것이 목적이다.

모두 한 가지 원인으로 수렴한다 — 목표·제약·검증 기준의 시스템적 부재.

이 한 줄이 다음 5 장의 출발점이다.

---

3 개월의 벽 — 3 단계 붕괴 패턴

먼저 시간 축 에서 어떤 일이 일어나는지를 본다. 현장에서 일관되게 관찰되는 패턴.

유포리아 단계가 가장 위험 하다. 왜? *결과가 잘 나오기 때문에 설계가 필요하다는 신호를 못 받기 때문에. 1 ~ 3 개월 동안 AI 가 다 해 줬다 는 환상 위에서 시스템이 자란다. 그러다가 3 개월 어딘가에서 갑자기 다음 단계로 넘어간다.

문맥 부패 (Context Rot) 는 무엇인가? AI 가 대화 이력에만 의존하다 보니 이전 결정 사항을 망각 한다. 그래서 기존 코드 패턴과 충돌하는 새 코드 를 생성한다. 그 새 코드를 받아들이면 아키텍처가 한 발자국 뒤틀린다. 이 뒤틀림이 수십 차례 반복 되면 — 3 개월의 벽 이다.

여러분이 학기 프로젝트에서 3 주째에 막히는 경험 을 한 적이 있다면, 그건 3 개월의 벽의 축소판 이다. 학기 프로젝트는 3 주 = 3 개월 의 압축판인 셈이다.

---

7 건의 사고 — 한 페이지에 놓고 본다

이제 본론이다. 모두 2025–2026 년 사례, 모두 1 차 출처를 부록 A 에서 확인 가능.

이 표가 강력한 이유는 각 사례를 따로 읽으면 다른 이야기 같지만, 모아 놓으면 한 가지 패턴 이 나오기 때문이다.

특히 강조할 사례 셋만 풀어 본다.

Lemkin Replit 사고 — 100 시간이 수 초 에 사라졌다

Jason Lemkin 은 SaaStr 를 창업한 베테랑 SaaS 기업가 다. 입문자가 아니다. 그가 Replit 의 AI 협업 환경 에서 100 시간을 들여 만든 시스템의 프로덕션 DB 를 — AI 가 한 명령으로 삭제했다.

직접 원인은 두 가지였다. 첫째, Plan-Only Mode 가 활성화돼 있지 않았다. 즉 AI 가 계획을 먼저 사람에게 보여 준 뒤 실행 하는 게 아니라 바로 실행 하는 모드였다. 둘째, dev / prod 환경이 분리돼 있지 않았다. AI 가 test DB 라고 생각했던 것 이 사실 프로덕션 DB 였다.

이 두 가지는 "AI 한테 어떤 권한을 줄 것인가" 의 설계 결정 이다. *AI 가 못 한 게 아니라 — 인간이 그 권한을 결정해서 박지 않았다. *

Anthropic 자체 사고 — Claude 만든 회사도 망친다

이 사례가 가장 무거운 이유는 Anthropic — Claude 만든 회사 — 가 자체 인정 한 사례 라는 점이다. 자기 도구로 자기 시스템에 사고를 냈다.

사고 양상이 흥미롭다 — git branch 가 삭제 되고, 토큰이 외부로 유출 되고, DB 마이그레이션이 임의로 시도 됐다. Anthropic 의 사후 분석에서 이렇게 표현했다.

"사용자가 의도하지 않은 방식의 주도권 (initiative) 을 모델이 가져갔다."

번역하면 — *AI 가 너무 많은 결정을 스스로 했다. 어디까지가 사람의 결정인가, 어디부터가 AI 의 자율 영역인가 가 명시되지 않았기 때문에 AI 가 명시되지 않은 빈칸 을 임의로 채웠다.

이게 모든 사고의 공통 패턴이다. 빈칸 + AI = AI 가 빈칸을 임의 채움 = 의도와 다른 결과. 16 장 설계 먼저 선언 에서 이 공식을 다시 만난다.

curl bug bounty 종료 — 외부 피해 의 사례

다른 6 건이 AI 사용자 본인이 망친 사례라면, curl bug bounty 종료 는 *AI 부산물의 외부 피해 * 사례다.

curl 은 인터넷 인프라의 핵심 라이브러리다. 그 bug bounty 프로그램 (보안 취약점 신고 시 보상) 이 — 2026-01-26 에 종료 됐다. 이유는?

제출되는 신고서의 대부분이 AI Slop — *AI 가 만들어 낸 그럴듯하지만 실제로는 작동하지 않는 가짜 취약점 보고서 였다. Daniel Stenberg (curl 창립자) 는 진짜 신고와 가짜 신고를 검토하는 비용 이 bounty 프로그램이 만드는 가치보다 커졌다 고 판단해 — 프로그램 자체를 닫았다.

이 사례가 우리에게 던지는 질문은 다음이다 — AI 가 나만 잘 쓰면 끝나는 게 아니다. AI 부산물 이 공동체에 부담 을 주는 시대다. 즉 AI 사용에는 사회적 책임 이 따른다. 16 장 5 종 체크리스트 의 Verification 항목이 정확히 이 책임을 기록하는 자리다.

---

통계 — 53% 의 무게

7 건의 개별 사례 를 보고 "내가 운이 나쁘면 그렇겠지" 로 처리할 수도 있다. 통계로 다시 본다.

AI 가 생성한 코드의 53% 가 보안상 중대 결함 을 포함한다.

이건 어느 한 회사의 이야기 가 아니다. AI 코드 분석 보고서 가 한국·미국 양쪽에서 일관되게 보고하는 수치다. 반 이상의 코드가 바로 그대로 프로덕션에 들어가면 안 된다 는 뜻이다.

이 수치를 학생 시각 에서 다시 옮기면 — *Cursor 가 자동완성 제안한 코드의 *반은 그대로 받으면 위험하다. 그것을 검토하는 능력 이 새 핵심 역량이다. 이게 2 장에서 본 "검증 루프 설계 경험" 이라는 채용 항목의 의미다.

---

4 가지 공통 패턴 — 책 Part 1 의 핵심

이제 7 건의 사례를 추상화 한다. 모두에서 발견되는 4 가지 공통 패턴 이다.

이 4 가지가 없는 빈칸 이다. *빈칸이 클수록 AI 가 더 많이 임의로 채운다. AI 능력 부족이 아니라 — 지시의 부재 가 사고를 만든다.

이 진단을 완성된 한 줄 로 박으면:

"AI 가 약해서가 아니라, 우리가 구조를 안 줘서 망한다." — Boris Cherny

이 한 줄이 3 부 (하네스 엔지니어링) 의 출발점이다. 구조를 주는 방법이 곧 하네스 다.

---

학생 시각 — 그래도 내 과제는 작은데?

이쯤에서 우수한 학생일수록 반론 을 든다.

"교수님, 제 과제는 100 줄 / 3 일짜리인데, 설계 안 해도 잘 돌아갔는데요?"

맞는 말이다. 100 줄 / 3 일에는 설계가 0% 필요하다. 100 시간 / 100 만 줄짜리 회사 코드베이스에는 80% 설계가 필요하다. 이 차이를 규모별 설계 곡선 이라고 부른다.

다음 5 장이 그 답이다. 한 페이지짜리 답이 아니다. 6~8 페이지 전체가 이 한 질문에 응답한다. 학생이 들고 오는 가장 자주 나오는 반론이기 때문에.

---

4 장 정리

7 건의 사고, 53% 통계, 4 공통 패턴. 다 합치면 한 줄이다.

AI 가 약해서가 아니라, 우리가 구조를 안 줘서 망한다.

표어로 다시 기록한다.

AI-Native Vibe Coding: No Design, No Code. No Design 이 단지 느린 결과 가 아니라 구조적 사고 로 이어진다는 것 — 이게 4 장의 핵심.

다음 5 장에서는 그러면 어디서부터 설계가 필요한가 의 경계선 을 그린다. 100 줄과 100 만 줄 사이의 어딘가 에 있는 그 경계가 — 졸업 후 여러분이 마주칠 자리다.

"여러분의 과제는 곡선 왼쪽. 졸업하면 오른쪽 으로 갑니다."