버그 리포트가 줄었는데 왜 시스템은 더 위험해지나
테스트 커버리지 100%. 버그 리포트 감소 추세. 배포 주기 단축. 지표만 보면 완벽한 팀이다. 그런데 Vagrant와 Terraform의 공동 창업자 미첼 하시모토(Mitchell Hashimoto)는 바로 이 상황을 가리켜 "AI 집단 광기(AI Psychosis)"라고 부른다. 지표가 건강해 보일수록, 실제 시스템은 아무도 이해할 수 없는 상태로 침몰하고 있다는 경고다.
메커니즘은 단순하다. AI 에이전트가 버그를 빠르게 패치하니, 팀은 버그를 출시해도 괜찮다는 논리를 내면화한다. "MTTR이면 충분하다"—평균 복구 시간이 짧으면 평균 고장 간격은 신경 쓰지 않아도 된다는 사고방식이다. 하시모토는 이걸 클라우드 인프라 자동화 시대에 이미 한 번 실패로 검증된 논리라고 짚는다. 그때도 "자동화가 빠르게 복구하니 장애를 내도 된다"고 했고, 결과는 "매우 회복력 있는 재앙 기계"였다. 지금 AI 시대에 똑같은 실수가 소프트웨어 개발 전체 규모로 반복되고 있다.
이해 불가능성이 진짜 위험이다
문제의 핵심은 버그 수가 아니다. 이해 가능성이다. AI가 생성하고, AI가 패치하고, AI가 테스트를 추가하는 사이클이 반복될수록 코드베이스는 국지적 지표로는 정상이지만 전체 아키텍처는 아무도 파악하지 못한 상태가 된다. Hacker News 스레드에서 한 개발자는 이를 정확하게 표현했다: "순수 AI 작성 시스템은 인간이 이해할 수 없는 복잡도까지 커지고, 결함 수정률은 줄어드는 반면 결함당 토큰 소모는 늘어난다." 결국 AI가 고치는 버그보다 만드는 버그가 많아지는 임계점에 도달한다.
@adamhjk의 지적도 날카롭다: "순수 바이브 코딩이 가장 먼저 파괴하는 것은 아키텍처 자체다." 아키텍처가 없으면 부식을 감지할 기준도 없다. 버그 리포트가 줄어드는 것도 실상은 두 가지 원인이 겹친다—진짜 품질 향상이 아니라, 사용자가 고쳐질 거라는 믿음을 잃어 신고를 포기했거나, AI가 생성한 버그 리포트가 오탐을 섞어 신호 자체를 오염시키고 있기 때문이다. 지표가 좋다고 시스템이 안전한 게 아니다.
코드 전에 검증: devils-council의 접근
그렇다면 실전에서 쓸 수 있는 대응은 무엇인가. dev.to에 공개된 오픈소스 도구 devils-council은 한 가지 명확한 전제에서 출발한다: 계획의 맹점은 계획을 짠 사람이 볼 수 없다. PR 리뷰는 문법을 잡고, 프로덕션은 결함을 드러낸다. 하지만 그 사이—계획이 코드가 되기 전—에는 검증 공백이 있다.
이 도구는 Staff Engineer, SRE, Product Manager, Devil's Advocate 네 개의 AI 페르소나가 계획 문서를 병렬로 독립 분석한다. 각 페르소나는 서로 다른 실패 모드를 탐색하고, Council Chair가 페르소나 간 모순을 합성해 pass/fail 스칼라로 압축하지 않고 긴장 지점 그대로 노출한다. 평균 리뷰 시간은 48초다.
실제 사례가 이 도구의 가치를 보여준다. Terraform Cloud 부트스트랩 마이그레이션 계획에서 SRE 페르소나는 새 토큰이 Vault에 기록된 시점과 에이전트가 실제로 픽업하는 시점 사이의 검증 공백을 찾아냈다. ESO 싱크 + 파드 재시작 + 에이전트 재연결이 즉시 일어나지 않는다는 사실—이 갭을 그냥 넘겼다면 173개 워크스페이스 전체 장애였다. Devil's Advocate 페르소나는 중단 기준(abort criteria)이 없다는 점을 별도로 짚었다. 두 페르소나가 독립적으로 같은 구멍을 다른 각도에서 찾아낸 것이다.
monorepo CI 설계 사례는 더 흥미롭다. 록파일 변경을 CI 트리거 신호로 쓰는 "핵심 인사이트"를 담은 계획이었다. Devil's Advocate는 workspace:*가 심볼릭 링크로 해소되기 때문에 워크스페이스 패키지 소스를 수정해도 pnpm-lock.yaml이 바뀌지 않는다는 false negative를 찾았다. SRE는 록파일이 의존성 호이스팅 변경 같은 무관한 이유로도 바뀐다는 false positive를 찾았다. Chair의 합성: 두 실패 모드가 동시에 전제를 무효화한다. 대안은 pnpm nx show projects --affected—40줄짜리 솔루션이 작동하지 않을 3,291줄짜리 구현을 대체했다.
Agentic SRE의 실제 한계: 동사가 문제다
dev.to의 또 다른 글, agentic SRE를 다룬 분석은 다른 각도에서 같은 지점을 건드린다. 인시던트 대응은 반복적인 컨텍스트 수집 작업이 대부분이고, 에이전트가 도울 수 있는 영역이다. 하지만 위험은 에이전트가 "보는" 것에서 "하는" 것으로 전환되는 순간에 시작된다.
"로그 30분 요약"과 "서비스 재시작"은 같은 에이전트 명령처럼 보이지만 완전히 다른 범주다. 전자는 조사(investigation), 후자는 운영(operation)이다. 프로덕션에서 에이전트는 증상을 근본 원인으로 오진할 수 있고, 한 경로를 고치면서 다른 경로를 깨뜨릴 수 있다. 인간도 같은 실수를 하지만 더 느리고, 사회적으로 책임지고, 중단시키기 쉽다. 광범위한 권한을 가진 에이전트는 잘못된 판단을 매우 효율적으로 실행한다. 효율성이 항상 아군은 아니다.
이 글이 제안하는 권한 설계는 실용적이다: 평시에는 읽기 전용, 완화 단계에서는 가역적 소수 액션만, 고임팩트 운영은 반드시 인간 승인. "블라스트 반경이 승인 모델을 결정한다"—이 원칙은 성숙한 자동화의 기본이다. 그리고 에이전트가 런북을 따를 수 있으려면 런북이 명확해야 한다. "대시보드를 확인하고 멈춰 보이면 재시작" 수준의 런북은 사람도 에이전트도 따를 수 없다. 역설적으로, 에이전트 도입 압박이 런북 품질을 끌어올리는 부수 효과가 생긴다.
시사점: 속도를 늦추는 게 아니라 검증을 앞당기는 것
세 기사가 수렴하는 지점은 하나다. AI의 속도를 제한하자는 게 아니다. 검증을 코드 작성 이후가 아니라 이전으로 끌어당기자는 것이다. 하시모토의 처방은 단순하다: "생각하라. AI를 쓰되, 생각하라." Chad Fowler는 "엄격함(rigor)을 아키텍처와 평가 체계로 재배치하는 것"이라고 표현했다. devils-council은 그 재배치를 48초짜리 자동화로 구현한 시도고, agentic SRE의 권한 설계는 에이전트가 운영 단계로 진입하는 문턱을 명시적으로 설계하는 시도다.
Hacker News 스레드의 한 코멘트가 실무자 관점에서 가장 정확하게 정리한다: "진짜 결정은 미리 하고 명세에 담아야 한다. 경계, API, 핵심 자료구조, 오류 처리, 보안 제약을 정의해야 한다. 모호하면 멈추라고 에이전트에게 지시해야 한다." 이걸 잘 하는 엔지니어는 부작용 없이 2~3배 속도 향상을 얻는다. 못 하는 팀은 지표가 좋아 보이는 채로 이해 불가능한 시스템을 쌓아간다.
전망: 다음 20년의 소프트웨어 공학이 배워야 할 것
Hacker News의 한 예측은 냉소적이지만 현실적이다: "AI 아키텍처 컨설팅이 보안 침해 대응처럼 고가치 전문 영역이 될 것이다." 순수 AI 생성 시스템이 이해 불가능한 복잡도에 도달하면, 그것을 클린룸처럼 해체하고 핵심 설계 원칙을 추출한 뒤 재구축하는 특수 절차가 필요해진다는 시나리오다. 소프트웨어 공학이 안정적인 설계 원칙에 도달하는 데 수십 년이 걸렸듯, AI 시대의 교훈을 체계화하는 데도 시간이 걸릴 것이다.
그 시간을 단축하는 방법은 이미 존재한다. 계획 단계의 다중 페르소나 검증, 인시던트 대응의 단계별 권한 설계, 아키텍처 부식을 감지할 수 있는 명시적 기준—이것들은 AI 속도를 죽이는 브레이크가 아니다. AI가 빠르게 달릴 수 있는 트랙을 설계하는 일이다. 트랙 없이 속도만 올리면, 빠를수록 더 빨리 벽에 박힌다.