AI 집단 광기(AI Psychosis) — MIT가 경고하는 소프트웨어 산업의 현주소

AI 집단 광기(AI Psychosis) — MIT가 경고하는 소프트웨어 산업의 현주소

Mitchell Hashimoto가 트위터에 올린 한 줄이 소프트웨어 업계에 파문을 일으켰다. "지금 많은 기업이 심각한 AI 집단 광기에 빠져 있으며, 그들과 이성적인 대화를 나누는 것은 불가능하다." 이 한마디에는 수십 년간 인프라 자동화 시대를 살아온 개발자의 깊은 우려가 담겨 있다.

AI 정신증이란 무엇인가

Hashimoto가 말하는 AI 정신증(AI Psychosis)은 단순한 AI 거품이나 과대광고와는 다르다. 기업이 AI 에이전트의 능력에 깊이 맹신하여, "에이전트가 빠르게 버그를 고칠 테니 버그를 출시해도 괜찮다"는 논리가 조직 전체를 지배하는 상태를 말한다.

이 상태에 놓인기업여합리적인대화 자체가 차단된다. 버그 리포트 감소, 테스트 커버리지 100퍼센트 달성, 배포 속도 비약적 향상 — 이 수치들은 모두 건강해 보인다. 하지만 시스템의 국소 지표가 좋아 보여도, 전체적으로는 이해 불가능한 상태로 변질되어 가고 있다는 사실을 아무도 인지하지 못하고 있다.

클라우드 시대의 교훈이 다시 반복된다

Hashimoto가 보는 이 문제는 완전히 새로운 것이 아니다. 클라우드 전환 시절, 인프라 업계는 이미 한 번 같은 실수를 반복했다. MTTR(평균 복구 시간) 만능주의가 그 시절의 산물이다.

"버그가 발생하면 에이전트가 금방 고쳐줄 테니,출료문제후재수야불지(나중에 고치면 되지 않나)"

이 사고방식이 인프라 영역에만 머물렀다면행이다ㅉ타。 그러나 지금은 소프트웨어 개발 산업 전체, 나아가 전 세계로 확산되고 있다.

왜 대화가 차단되는가

이 문제를 주변 동료에게 직접 제기하면, 돌아오는 대답은 언제나 같다.

> "아니야, 우리 테스트 커버리지가 완벽해."

> "버그 리포트가 계속 줄어들고 있어."

이 즉각적인 반박이 보여주지 않는 것이 있다. 전체 그림이다. 버그 리포트가 줄어드는 것은 사용자들이 더 이상 버그를 보고하지 않기 때문일 수 있다. 테스트 커버리지가 올라가는 것은, 의미론적 이해가 아닌 라인 카운트만 증가하기 때문일 수 있다.

기술 리더십이 "이걸 멈추려면 무엇이 사실이어야 하는가"라는 반사실적 질문에 답하지 못하고 침묵할 때, 그것이 바로증상이다.

자동화된 재앙 기계

Hashimoto는 이것을 "회복력 있는 재앙 기계"라고 불렀다. 인프라 시대에 이미 한 번 겪은 현상이다.

자동화를 통해 시스템이 매우 회복력 있어 보여도, 실제로는 이해 불가능한 상태가 된다. 국소적으로는 모든 지표가 건강해 보인다. 그러나 전체 그림은 그렇지 않다. 버그 리포트는 줄어들지만 잠재적 위험은 폭증한다. 테스트 커버리지는 올라가지만 의미론적 이해는 하락한다.

순수하게 AI가 작성한 시스템은 인간이 이해할 수 없는 복잡도까지 커진다. 결함 수정률은 줄어들지만, 결함당 토큰 소비는 늘어난다. 결국 AI가 고치는 결함보다 더 많은 결함을 만들어 내면서 전체가 불안정해진다.

에이전트 시대의 LGTM 문제

POC에서 가장 주목받은 논점 중 하나는 LGTM(Looks Good To Me) 문제다.

현재 에이전트 사용자 경험은 LGTM을 가장 저항이 적은 경로로 만들고 있다. 에이전트가 생성하는 그럴듯해 보이는 코드의 속도가, 코드 리뷰의 검증 문제를 즉각적 위협으로 격상시키고 있다. AI가 말한 것이 완전히 잘못된 정보인지 판별하는 데 10초가 아닌 20분이 걸리는 시대에 진입한 것이다.

조직이 현실과의 접점을 유지하지 못하면, 결국 에이전트 속도로 일이 움직이고, 종종 말도 없이 결정을 내린 뒤 "계획은 이렇다"는 최종 출력만 주게 된다. 이를 제대로 검토하려면 문제를 깊이 이해해야 하기 때문에, 다시 인간 속도로 돌아가야 한다. 결국 대충 훑고 승인하는 루프에 빠진다.

사고를 AI에 외주 주는 것의 대가

Hashimoto가 제시한핵심 메시지는 이렇다. "생각하라. AI를 사용하되, 생각하라."

모든 것을 AI에 맡기면 마법 같은 속도 향상이 생긴다. 그러나 그 대가는인지 부채의 폭증이다. 더 이상 문제를 깊이 이해하는 사람이 조직에 남지 않기 때문이다.

반면, 의식적으로 결정하여 AI에 외주 주는 것의 범위를 제한하면, 속도는 늦춰지지만 더 많이 개입하게 되고,인지 부채도 덜 쌓인다.

Hashimoto가 제안하는실전적 구분은 이렇다.

AI에게 맡겨도 좋은 것	AI에게 맡기면 안 되는 것
배열을 어떻게 순회할지	시스템의 경계와 책임 범위
한 호출의 출력을 다른 호출의 입력에 맞추는 지루한 결정	핵심 자료구조 설계
테스트 코드 보충	API 설계와 오류 처리 정책
라이브러리 탐색	보안과 개인정보의 강한 제약 조건

모호한 상황에서는 에이전트에게 "멈추라"고 지시해야 한다. 이것이 좋은 엔지니어와 무분별한 AI 의존자의 차이다.

소프트웨어 공학의 전환점

Hashimoto는 이렇게 말했다. "어쩌면 이 일이 소프트웨어 공학을 진짜 공학 분야로 바꿀지도 모른다."

지금까지 소프트웨어 공학은 형식화되지 않은 학문이라는 비판을 받아왔다. 그러나 AI가 코드를 더 빨리 작성할 수 있게 되면서, 체계적 사고와 문제 정의의 가치가 오히려 높아지고 있다. 엔지니어가 에이전트를 올바르게지인하려면, 먼저 문제가 무엇인지 정확히 정의해야 하기 때문이다.

흥미로운 반전이다. AI가 코딩 속도를 비약적으로 높여주는 듯하지만, 실제로 가치를 높이는 것은 AI가 할 수 없는 일 — 문제 정의, 아키텍처 설계, 의사결정 — 에 집중할 때이다.

독일에서 보내온 한 통의 이메일

Hacker News 토론에서 가장 인상적이었던 답변 중 하나는 독일에서 보내온 것이었다.

> "여기서는 이런 식으로 일하라고 강요받는 사람을 진짜 한 명도 모른다. 이런 열풍이 없는 문화권에서 일하는 것이 이렇게 다행일 줄 몰랐다."

모든 회사가 AI 광기에 빠져 있는 것은 아니다. 그러나 업계적주류는 분명히 속도 경쟁에 몰두하고 있다. 이런 환경에서 조급함을 거부할 수 있는 용기가 엔지니어가 가져야 할 덕목이 되고 있다.

결론: 현명한 AI 사용을 위한 체크리스트

AI 정신증에 빠지지 않으려면, 다음 질문들에 먼저 답할 수 있어야 한다.

배포 전에 확인해야 할 것

• 이 코드가 운영에서 터지면, 내가 직접 고칠 수 있는가?

• 에이전트가 생성한 코드를 아가 실제로 이해하고 있는가?

• 새로운 라이브러리를 도입할 때, 그 복잡도가 정말 필요한 것인가?

AI에임세루 결정 전에 확인해야 할 것

• 이 결정의후과오수적가승담스루카(누가 이 결정의 결과를 부담하는가)?

• 만약 에이전트가 틀린 결정을 내리면, 우리 조직이 알아챌 수 있는가?

• 이 결정은 reversible한가, 그렇지 않은가?

Hashimoto의 경고는 AI를 쓰지 말라는 것이 아니다. AI를 쓰되, 생각하라는 것이다. 에이전트가 대신 결정을 내리는 것이 편하고 빠르더라도, 그결정의 무게를 인식하는 것은 여전히 엔지니어의 몫이다.

---

핵심 요약

• AI 정신증: 버그 출시는 에이전트가 고쳐줄 것이라는 맹신

• 국소적 지표 건강과 전체적 이해 불가능성이 공존

• AI에 사고를 외주 주면 속도는 오르지만인지 부채가 폭증

• 좋은 엔지니어는 모호한 상황에서 에이전트에게 "멈추라"고 지시한다

• AI는 사고를 대체하는 도구가 아니라, 사고를가속하는 도구여야 한다

📚 출처

• Mitchell Hashimoto — Twitter/X

• GeekNews: 지금 많은 기업이 AI 집단 광기에 빠져 있다고 믿는다

---

📚 출처

• https://news.hada.io/topic?id=29549