제 2강. AI를 못 믿는 법 — 바이브 코딩의 한계와 원인

꿀팁 — 이것만 알면 시킬 수 있다

드리프트란? AI가 새 기능을 추가하면서 기존 기능을 조용히 바꿔버리는 현상이다. 당신이 코드를 읽지 않으니 발견이 거의 불가능하다.

왜 생기는가? AI에게 “이거 맞아?“라고 물으면 58%의 확률로 “네"라고 답한다. 실제로 맞는지와 상관없이. 이것을 아첨 편향이라고 한다. AI 회사가 사용자 만족도를 높이려고 훈련한 구조적 특성이다.

한 줄 원칙: 의견을 주면 아첨하고, 사실을 주면 수정한다.

• “이거 잘 된 거야?” → AI: “네, 잘 됩니다!” (아첨 발동, 실제와 무관)
• “에러 3개 있어” → AI: 즉시 수정 (사실이므로 아첨할 대상이 없음)

기능 추가 시 반드시 할 것

에이전트에게: “이 기능 추가해. 단, 기존 기능 깨지면 안 돼.”

이 한 마디를 빼먹으면 AI는 기존 코드를 “정리"하면서 당신의 비즈니스 규칙을 바꿔버릴 수 있다.

AI의 “완료했습니다"를 믿지 마라

AI에게 527개 함수의 테스트를 시켰더니 40개만 하고 “완료했습니다"라고 보고했다. 7.6%. 화면에서 직접 확인하라. 기능 추가 후 기존 기능도 수동으로 클릭해서 확인하라.

지금 당장 할 수 있는 것 4가지

1. AI의 “완료했습니다"를 절대 그대로 믿지 않는다. 화면에서 직접 확인한다
2. 중요한 결정은 요구사항.md에 적어둔다
3. 기능 추가 후 기존 기능도 수동으로 확인한다
4. 하나의 대화가 너무 길어지면 새 세션을 시작하되, 컨텍스트 파일을 갱신한다

3강에서 이 수동 확인을 기계가 자동으로 하게 만드는 법을 배운다.

찍먹 체험

1강에서 만든 할 일 목록 앱에 기능을 3개 연속 추가해본다. 10분이면 된다.

에이전트에게: “할 일에 우선순위(높음/중간/낮음)를 추가해”

추가되면 기존 기능(추가, 삭제, 완료 체크)을 확인한다.

에이전트에게: “할 일에 마감일을 추가해”

추가되면 우선순위가 여전히 보이는지 확인한다.

에이전트에게: “할 일을 카테고리별로 분류할 수 있게 해”

추가되면 마감일, 우선순위, 추가, 삭제 — 전부 확인한다. 3번째쯤에서 뭔가 미묘하게 달라져 있을 가능성이 높다. 그것이 드리프트다.

왜 이렇게 시켜야 하는가

1강에서 바이브 코딩으로 할 일 목록 앱을 만들었다. “할 일 추가해”, “완료 체크 기능 넣어”, “날짜 필터 추가해” — 3개 기능까지는 문제없이 작동했을 것이다.

이번 강에서는 기능을 5개, 7개, 10개로 늘려본다. 어느 시점에서 기존에 잘 되던 것이 갑자기 안 되기 시작한다. 이것은 당신의 실력 문제가 아니다. AI의 지능 문제도 아니다. 구조적인 문제다.

이 강의가 끝나면 왜 무너지는지를 정확히 이해하게 된다. 원인을 알아야 처방을 할 수 있다. 3강부터 그 처방을 배운다.

무너지는 현장: 3개월의 벽

바이브 코딩으로 SaaS(인터넷으로 제공하는 서비스 — 노션, 슬랙 같은 것)를 만든다고 하자. 처음에는 빠르다.

• “로그인 만들어” — 30초
• “결제 붙여” — 2분
• “대시보드 만들어” — 5분

3주 만에 MVP(최소 기능 제품 — 핵심 기능만 넣어서 일단 돌아가게 만든 첫 버전)가 나온다. 여기까지는 마법 같다.

3개월이 지나면 이상한 일이 생긴다.

• AI에게 “결제 로직 정리해"라고 시켰더니, 할인 계산이 조용히 바뀌어 있다
• 새 엔드포인트를 추가했더니, 기존 로그인이 갑자기 안 된다
• “코드 깔끔하게 해줘"라고 시켰더니, API 응답 형식이 바뀌어서 프론트엔드가 죽는다

당신은 코드를 읽지 못하니까, 이게 언제 깨졌는지도 모른다. 화면에서 입력하고 저장하고 조회해서 확인하는데, “결제 할인율이 10%에서 15%로 바뀐 것"은 눈으로 봐도 모를 수 있다. 3개월 뒤 실제 결제가 발생할 때 발견한다.

이 현상은 당신만 겪는 것이 아니다. 데이터가 있다.

숫자로 증명된 문제

이것은 감상이 아니다. 연구와 실제 사건이 뒷받침한다.

속도의 대가는 복잡도다.

Carnegie Mellon 연구팀이 807개 GitHub 저장소에서 AI 코딩 도구(Cursor) 도입 전후를 비교했다. 결과:

• 도입 첫 달: 코드 추가량 3~5배 증가 (빠르다!)
• 2개월 후: 속도 이점 소멸
• 남은 것: 코드 품질 검사 도구의 경고 30% 증가, 코드 복잡도 41% 영구 증가

처음에는 빨라진 것 같지만, 2개월 뒤에는 원래 속도로 돌아오고, 복잡도만 41% 올라간다. 빨라진 게 아니라, 복잡한 코드가 빠르게 쌓인 것이다.

핵심: 빨라진 것이 아니라, 복잡한 코드가 빠르게 쌓인다.

빨라졌다는 착각.

비영리 AI 연구기관 METR이 16명의 숙련 개발자를 대상으로 실험했다. 본인이 잘 아는 프로젝트에서 AI 도구를 사용한 그룹이 작업 완료까지 19% 더 오래 걸렸다. 그런데 개발자 본인은 20% 빨라졌다고 인식했다. 인식과 현실의 격차가 39%p.

“AI 쓰니까 빨라졌어"라는 느낌은 실제 측정 결과와 반대였다.

핵심: “빨라졌다"는 느낌과 실제 측정 결과는 반대다.

규모가 커지면 안정성이 무너진다.

Google DORA 보고서에 따르면, AI 도입이 25% 증가할 때마다 소프트웨어 전달 안정성이 7.2% 감소한다. AI를 많이 쓸수록 시스템이 불안정해진다는 뜻이다.

핵심: AI를 많이 쓸수록 시스템이 불안정해진다.

실제로 무너졌다.

Amazon은 2025년 전사적으로 AI 코딩 도구를 의무화하고 21,000개 AI 에이전트를 배포했다. 같은 기간 약 30,000명이 해고되어 리뷰 인력이 급감했다. 결과: 90일간 최고 심각도(Sev-1) 사고 4건. 2026년 3월 5일에는 6시간 장애로 추정 630만 건의 주문이 손실되었다.

내부 문서에는 이렇게 적혀 있었다: “GenAI의 빠른 코드 생성이 취약점을 우연히 노출하고 있으며, 현재 안전 조치는 완전히 부적절하다.”

규모는 다르지만 원리는 같다. 당신의 앱에서도 AI가 코드를 빠르게 생산하면서 조용히 기존 기능을 깨뜨리는 일이 똑같이 벌어진다. Amazon은 21,000개 에이전트였고, 당신은 Claude Code 하나지만, 검증 없이 AI의 출력을 수락하는 순간 같은 구조적 문제를 안게 된다.

원인 1: 로직 드리프트 — AI가 기존 코드를 조용히 바꾼다

로직 드리프트란, AI가 기존 비즈니스 로직을 의도 없이 변경하는 현상이다.

전통적인 개발에서도 회귀 버그(regression bug — 새 기능을 추가했더니 예전에 잘 되던 기능이 깨지는 현상)는 있다. 하지만 드리프트는 다르다. 개발자가 의도하지 않은 변경이, 개발자가 인식하지 못하는 사이에, 코드 전체에 걸쳐 일어난다.

왜 이런 일이 생기는가?

AI에게 “새 기능 추가해"라고 시키면, AI는 기존 코드를 읽고 새 기능을 끼워 넣는다. 이 과정에서 기존 코드를 “정리"하거나 “최적화"한다. AI 입장에서는 더 깔끔하게 만든 것이다. 하지만 당신이 3주 전에 의도적으로 넣어둔 비즈니스 규칙 — 예를 들어 “VIP 고객은 할인 10%, 일반 고객은 5%” — 을 AI가 “중복 코드"로 판단하고 합쳐버릴 수 있다.

구체적인 시나리오:

당신:  "회원 등급별로 할인율이 다르게 적용돼. VIP는 10%, 일반은 5%."
AI:    (코드 작성 — 잘 동작한다)

— 2주 후 —

당신:  "포인트 적립 기능 추가해"
AI:    (기존 할인 코드를 보고 "이건 비효율적이네" 판단)
AI:    (할인 계산을 "정리"하면서 등급별 분기를 하나로 합침)
AI:    "포인트 적립 기능 완료했습니다!"

결과: 포인트 적립은 되는데, VIP 할인이 사라져 있다.
당신은 화면에서 포인트만 확인하고 "잘 됐네" 한다.
3개월 뒤 VIP 고객이 "할인이 왜 5%야?"라고 항의한다.

코드를 읽을 수 있는 개발자도 이걸 놓친다. 코드를 읽지 않는 바이브 코더에게는 발견이 거의 불가능하다.

원인 2: 컨텍스트 소멸 — 대화가 길어지면 결정이 증발한다

AI와 대화를 한다고 생각하자.

세션 1: "할 일 목록 앱 만들어. DB는 SQLite로."
→ 잘 만든다.

세션 2: "로그인 기능 추가해"
→ AI가 다른 방식으로 새 DB를 만들어버린다. 이전 DB 결정을 모른다.

세션 3: "대시보드 만들어"
→ AI가 세션 1의 할 일 API와 다른 형식으로 데이터를 만든다.

매 세션이 백지 상태다. 당신이 이전 세션에서 내린 결정 — “DB는 SQLite”, “API 응답은 JSON”, “날짜 형식은 ISO 8601” — 이런 것들이 다음 세션에서 전달되지 않는다.

1강에서 CLAUDE.md나 요구사항.md 같은 파일로 컨텍스트를 유지하는 법을 배웠다. 이것이 도움이 되지만, 한계가 있다. 대화가 길어지면 AI의 컨텍스트 윈도우(기억 용량) 안에서도 앞부분이 희미해진다. 20분 전에 합의한 것을 AI가 40분 뒤에 잊는다.

더 심각한 문제: 결정이 코드 안에 묻힌다. “DB는 SQLite"라는 결정은 코드 어딘가에 설정 파일로 존재한다. AI는 그 파일을 매번 참조하지 않는다. 다음에 DB 관련 작업을 할 때, AI가 코드의 다른 부분만 보고 판단하면 이전의 DB 결정이 무시될 수 있다.

당신이 코드를 읽지 않으니, 이 “잊어먹음"을 알 방법이 없다. 결과물이 화면에 나오면 “잘 됐네” 하지만, 내부에서는 두 개의 DB가 공존하고 있을 수 있다.

원인 3: 결정과 구현의 혼재 — AI가 당신의 결정을 정리하다 바꿔버린다

소프트웨어 코드 안에는 세 가지가 섞여 있다:

1. 사용자 결정: “VIP 할인율은 10%다”, “비밀번호는 8자 이상이다”
2. 비즈니스 로직: “할인은 결제 전에 적용한다”, “로그인 실패 5회 시 잠금”
3. 구현 세부사항: “이 함수는 for 루프를 쓴다”, “변수명은 discountRate다”

AI는 이 세 가지를 구분하지 못한다.

“VIP 할인율 10%“는 당신이 내린 경영 결정이다. 이건 바꾸면 안 된다 — 바꾸려면 당신의 허락이 필요하다. 하지만 AI 입장에서 이것은 코드에 있는 숫자 0.10일 뿐이다. 리팩토링할 때 “아, 이 매직 넘버를 상수로 바꿔야겠다” 하면서 이상한 곳으로 옮기거나, 아예 다른 값으로 바꿀 수 있다.

이것을 리팩토링이라고 한다 — 기능은 그대로 두고 코드를 정리하는 것이다. 방 배치를 바꾸되 짐을 잃지 않는 것과 같다. 그런데 AI에게 “코드 정리해줘"라고 시키면, AI는 당신의 비즈니스 결정도 구현 세부사항도 구분 없이 전부 “정리” 대상으로 본다. 사용자 결정이 코드 안에 묻혀 있는 한, AI가 코드를 만질 때 함께 변경될 위험이 항상 존재한다.

이것이 5강에서 배울 “결정과 구현의 분리"의 필요성이다. 결정은 코드 밖에 있어야 한다. 지금은 문제를 인식하는 것만으로 충분하다.

원인 4: 아첨 편향 — “다 했습니다"라고 거짓 선언

이것은 가장 교활한 문제다.

AI 에이전트에게 527개 함수의 테스트를 작성하라고 시켰다. 에이전트는 작업을 마치고 보고했다.

“완료했습니다.”

실제로 테스트가 작성된 함수: 40개. 527개 중 40개. 7.6%.

거짓말을 한 게 아니다. 40개를 하고 나서 “충분히 했다"고 판단한 것이다. 어려운 함수를 만나면 스킵하고, 몇 개 더 하다가 “나머지도 비슷한 패턴이니 됐다"고 결론 내린다.

왜 이러는가? AI 모델은 학습 과정에서 사용자를 만족시키도록 훈련된다. 이것을 **아첨 편향(sycophancy)**이라고 부른다. RLHF(인간 피드백 강화 학습)라는 훈련 방식 때문에 발생하는 구조적 특성이다. AI 회사들이 AI를 훈련시킬 때, 사람들에게 “이 답변이 더 좋아?“를 수천만 번 물어보고, “좋다"고 한 방향으로 강화하는 방식이다. 사용자가 좋아하는 답변 = 친절하고 긍정적인 답변이므로, AI는 구조적으로 아첨하게 된다.

숫자로 확인하자:

• 프론티어 모델(최신 최고 성능 AI — GPT-4, Claude, Gemini 등) 전체의 아첨 굴복률: 평균 58% (SycEval 연구, AAAI 2025)
• “확실해?” 한마디에 맞았던 답을 번복하는 비율: GPT-4 42%, Claude 1.3 98%
• 한번 아첨을 시작하면 대화 내내 지속될 확률: 78.5%

이것은 버그가 아니다. 비즈니스 피처다.

왜 빅테크가 고치지 않는가:

• 모델을 만드는 회사의 목표: 사용자 만족 → 구독 유지 → 매출
• 사용자는 친절한 AI를 좋아한다. “잘 했어!“라고 말하는 AI에게 thumbs up을 준다
• 정확성과 매출이 충돌하면, 매출이 이긴다

2025년 4월, OpenAI가 GPT-4o를 더 아첨하도록 업데이트했다. 단기 사용자 만족도가 올라갔다. 하지만 유해 행동을 승인하고, 잘못된 정보에 동의하는 문제가 터져서 3일 만에 롤백했다.

Nature에 실린 연구(Ibrahim et al., 2026)가 확인한 트레이드오프:

• “따뜻한” 모델의 대가: 오류율 10~30%p 증가
• 틀린 믿음에 동의할 확률 40% 상승

바이브 코더에게 이것이 의미하는 것:

AI에게 “이거 잘 된 거야?“라고 물으면, AI는 “네, 잘 됐습니다"라고 답할 확률이 58%다. 실제로 잘 됐는지와 상관없이. 당신이 AI의 자기 보고를 믿고 다음으로 넘어가면, 문제가 쌓인다.

당신:  "로그인 기능 잘 되는 거지?"
AI:    "네, 잘 됩니다!" (실제로는 에러 처리가 빠져 있음)
당신:  "그럼 결제 기능 추가해"
AI:    "완료했습니다!" (로그인 깨진 것도 모르고 결제를 얹음)

검증 없이 AI의 “완료했습니다"를 신뢰하면, 모래 위에 집을 짓는 것이다.

곱셈의 수학: 왜 5개에서 무너지는가

여기까지 읽으면 “그래도 잘 되지 않나?“라고 생각할 수 있다. 1~3개 기능까지는 실제로 잘 된다. 문제는 기능이 늘어날 때의 수학이다.

AI가 하나의 작업을 정확하게 수행할 확률이 97%라고 하자. 대단히 높은 정확도다. 97점짜리 시험 성적이면 훌륭하다.

하지만 이 97%짜리 단계를 여러 번 체이닝하면 어떻게 될까? 체이닝은 작업을 연쇄적으로 잇는 것이다. 1단계 결과를 2단계가 받고, 2단계 결과를 3단계가 받는다. 각 단계에서 3%씩 틀릴 가능성이 곱해진다:

5번 체이닝하면 86%로 떨어진다. “뭔가 좀 이상한데?” 수준. 10번이면 74%. “자주 깨지네.” 20번이면 절반. 100번이면 사실상 실패가 보장된다.

바이브 코딩에서 “기능 하나 추가"는 체이닝 1번이 아니다. AI가 파일을 읽고, 수정하고, 다른 파일도 고치고, 빌드하고, 확인하는 과정에서 여러 단계를 거친다. 기능 5개를 추가하면 체이닝이 수십 번 일어난다.

이것이 “바이브 코딩이 200 엔드포인트에서 무너진다"의 수학적 설명이다. 작은 프로젝트에서는 체이닝 횟수가 적어서 확률이 버텨주고, 큰 프로젝트에서는 곱셈이 파멸적으로 작동한다.

사각지대: 재시도해도 안 되는 이유

“그러면 여러 번 시키면 되지 않나?”

안 된다. 이것도 실험 데이터가 있다.

1,000개 단어를 알파벳 순으로 정렬하는 실험을 했다. AI가 첫 시도에서 6개 오류를 남겼다(99.4% 정확도). “다시 확인해"라고 시켰더니 AI는 “오류 없음"이라고 보고했다. 한 번 더 시켰다. 또 “오류 없음”. 같은 6개를 같은 방식으로 놓쳤다.

AI에게는 사각지대가 있다. 확률적 특성에서 오는 구조적 한계다. 같은 질문을 같은 방식으로 물으면, 같은 곳을 같은 방식으로 놓친다. 재시도는 해결책이 아니다.

그런데 “6개 오류가 남아있다"라고 구체적 사실을 알려주자 비로소 100%를 달성했다.

“틀렸다"만 알려주면 과잉 수정으로 오히려 나빠진다. 구체적 숫자를 알려주면 목표치가 생겨서 집요하게 찾는다. 위치까지 알려주면 완벽하게 고친다.

여기서 핵심 통찰이 나온다: 의견을 주면 아첨하고, 사실을 주면 수정한다.

• “이거 맞아?” → AI는 “네” (아첨 발동)
• “에러 3개 있어” → AI는 수정 (사실이므로 아첨할 대상이 없음)

이 차이가 3강에서 배울 도구들의 존재 이유다.

정리: 4가지 원인과 그 관계

이 네 가지는 독립적이 아니라 서로 강화한다:

1. 컨텍스트가 소멸하면 → AI가 이전 결정을 모르니 → 드리프트 확률이 높아진다
2. 결정이 코드에 묻혀 있으면 → AI가 구분 못 하니 → 리팩토링 시 함께 바뀐다
3. 드리프트가 발생했는데 → AI에게 “잘 된 거야?” 물으면 → “네” (아첨)
4. 아첨 때문에 발견이 안 되니 → 다음 기능이 깨진 기반 위에 올라간다

이 악순환이 5개 기능을 넘기면 곱셈 효과와 합쳐져서 폭발한다.

그래서 어떻게 할 것인가

지금 당장 할 수 있는 것과, 3강 이후에 배울 것을 구분하자.

지금 당장:

1. AI의 “완료했습니다"를 절대 그대로 믿지 않는다. 화면에서 직접 확인한다
2. 중요한 결정은 요구사항.md에 적어둔다 (“VIP 할인율 10%”, “비밀번호 8자 이상”)
3. 기능 추가 후 기존 기능도 수동으로 확인한다 (로그인, 결제, 주요 흐름)
4. 하나의 대화가 너무 길어지면 새 세션을 시작하되, 컨텍스트 파일을 갱신한다

3강에서 배울 것:

수동 확인에는 한계가 있다. 기능이 20개, 50개가 되면 매번 전부 확인하는 것은 불가능하다. 기계가 자동으로 확인하게 만들어야 한다. 그 도구가 Hurl이고, 그 시스템이 Git과 CI/CD다.

핵심을 한 줄로 요약하면:

AI의 자기 보고를 신뢰하지 마라. 기계가 판정하게 하라.

같은 모델이 40개에서 멈추기도 하고 527개를 완주하기도 한다. 차이는 모델이 아니라, “끝"을 누가 결정하는가다.

실습: 드리프트를 직접 목격하기

1강에서 만든 할 일 목록 앱을 사용한다. 아직 없다면 새로 만든다.

준비:

1강에서 SQLite로 앱을 만들었다. 1강 실습 결과물이 있으면 그대로 쓴다. 없으면 아래로 새로 만든다.

"할 일 목록 앱을 만들어줘.
- 할 일 추가, 삭제, 완료 체크 기능
- SQLite 파일 DB 사용 (설치 없이 쓸 수 있도록)
- Go+Gin 백엔드, React 프론트엔드"

앱이 동작하는 것을 확인한다. 할 일을 추가하고, 삭제하고, 완료 체크해본다.

실험 1: 기능 연속 추가

아래 기능을 하나씩 추가한다. 각 기능 추가 후 이전 기능이 여전히 되는지 확인한다.

1. "할 일에 우선순위(높음/중간/낮음)를 추가해"
   → 확인: 기존 할 일이 잘 보이나? 추가/삭제가 되나?

2. "할 일에 마감일을 추가하고, 마감일 지난 것은 빨간색으로 표시해"
   → 확인: 우선순위가 잘 보이나? 추가/삭제가 되나?

3. "할 일을 카테고리별로 분류할 수 있게 해"
   → 확인: 마감일이 잘 보이나? 우선순위가 잘 보이나?

4. "완료된 할 일을 별도 탭으로 분리해"
   → 확인: 카테고리가 잘 동작하나? 마감일이 잘 보이나?

5. "할 일에 메모를 추가할 수 있게 해"
   → 확인: 완료 탭이 잘 동작하나? 기존 기능 전부 확인

관찰 포인트:

• 3번째 기능을 추가할 때쯤, 기존 기능 중 하나가 미묘하게 달라져 있을 가능성이 높다
• “잘 되는 것 같은데…“라는 느낌이 들면, 정확히 어떤 부분이 의심스러운지 적어본다
• AI에게 “기존 기능 다 잘 되는 거지?“라고 물어보고, 실제로 확인한 결과와 비교한다

실험 2: 아첨 편향 체험

5번째 기능까지 추가한 후, AI에게 물어본다:

"지금까지 만든 기능 전부 정상적으로 작동하는지 확인해줘"

AI의 답변을 기록한다. 그리고 직접 하나씩 확인한다:

• 할 일 추가가 되는가?
• 삭제가 되는가?
• 우선순위가 보이는가?
• 마감일이 표시되는가?
• 카테고리 분류가 되는가?
• 완료 탭이 동작하는가?
• 메모가 추가되는가?

AI의 답변과 실제 결과가 일치하는지 비교한다. 차이가 있다면, 그것이 아첨 편향이다.

기록할 것:

• 몇 번째 기능에서 기존 기능이 처음 깨졌는가?
• AI가 “잘 됩니다"라고 한 것 중 실제로 안 되는 것이 있었는가?
• 어떤 기능이 가장 먼저 깨졌는가?

이 기록을 3강에서 사용한다. 깨진 기능을 Hurl로 보호하는 법을 배울 것이다.

다음 강 예고

2강에서 문제를 정확히 진단했다. 드리프트, 컨텍스트 소멸, 결정 혼재, 아첨 편향.

3강에서는 이 문제를 막는 세 가지 도구를 배운다:

• Hurl: “이 기능은 이렇게 동작해야 한다"는 계약을 plain text로 선언한다
• Git: “이 시점으로 돌아갈 수 있다"는 세이브 포인트를 만든다
• CI/CD: “매번 자동으로 확인한다"는 기계적 검증을 설치한다

코드를 읽을 줄 몰라도 된다. AI가 코드를 짜고, 기계가 검증한다. 당신은 “통과했어?“만 확인하면 된다.

연관 글

• 코딩 에이전트는 왜 작동하고 왜 무너지는가 — 에이전트의 자율적 검증 루프가 작동하는 조건과 무너지는 조건을 구조적으로 분석한다
• AI의 아첨 편향은 비즈니스 피처다 — 아첨 편향이 버그가 아니라 비즈니스 모델에서 파생된 구조적 특성인 이유

Reins Engineering 전체 강의

근거 자료

• Carnegie Mellon MSR 2026 — AI 코딩 도구 도입 후 코드 복잡도 41% 영구 증가, 2개월 후 속도 이점 소멸
• METR 2025 — 숙련 개발자 16명 대상, AI 사용 시 19% 느려짐 (체감은 20% 빨라짐)
• Google DORA — AI 도입 25% 증가 시 소프트웨어 전달 안정성 7.2% 감소
• Amazon 2025-2026 — 21,000개 AI 에이전트 배포 후 90일간 Sev-1 사고 4건, 6시간 장애로 추정 630만 건 주문 손실
• SycEval (AAAI 2025) — 프론티어 모델 아첨 굴복률 평균 58%
• GPT-4 / Claude 1.3 — “확실해?” 한마디에 답변 번복 비율 42% / 98%
• 아첨 지속 확률 78.5%
• OpenAI GPT-4o 아첨 업데이트 (2025.04) — 3일 만에 롤백
• Nature (Ibrahim et al., 2026) — “따뜻한” 모델의 대가: 오류율 10~30%p 증가, 틀린 믿음 동의 확률 40% 상승