AI 열광이 회사를 리스크 공장으로 만들 때

Mitchell Hashimoto는 X 게시글에서 일부 회사가 “AI psychosis” 상태에 빠졌다고 표현했다. 요지는 강하다. AI 에이전트가 버그를 빠르게 고칠 수 있으니 버그를 내도 괜찮다는 식의 사고가 퍼지면, 소프트웨어 산업 전체가 과거 클라우드 인프라 전환기 때 겪었던 MTBF와 MTTR 논쟁을 더 큰 규모로 반복할 수 있다는 것이다.

그가 끌어온 비유는 중요하다. 인프라 업계는 장애를 완전히 막는 것보다 빠르게 복구하는 능력, 즉 MTTR을 중시하게 됐다. 그러나 “복구가 빠르다”는 말이 “망가뜨려도 된다”는 허가증은 아니었다. Google SRE 책이 반복해서 강조하듯 신뢰성은 측정, 제한, 오류 예산, 사후 분석이 함께 있어야 작동한다.

빠른 복구는 좋은데, 이해 가능성은 별개의 문제

AI 코딩 도구는 변경 속도를 크게 올린다. 문제는 변경의 단위가 작아지는 동시에 전체 시스템을 설명할 수 있는 사람이 줄어드는 순간이다. 테스트 커버리지가 올라가고 버그 리포트가 줄어도, 아키텍처의 의미적 부채는 눈에 잘 보이지 않는다. Hashimoto가 말한 “로컬 지표는 건강해 보이지만 전역 시스템은 이해 불가능해진다”는 경고가 여기 있다.

최근 AI가 나를 멍청하게 만든다는 개발자의 고백에서도 비슷한 문제를 다뤘다. 코드 작성량보다 중요한 것은 사람이 시스템을 계속 배울 수 있느냐이다. 에이전트가 PR을 만들고 테스트를 고치고 릴리즈 노트를 쓰는 조직에서는 생산성 대시보드가 오히려 위험을 가릴 수 있다.

MTTR 만능론의 유혹

DORA 연구가 보여준 고성과 조직의 핵심도 단순한 배포 횟수가 아니라 변경 실패율, 복구 시간, 리드타임을 함께 보는 균형이다. AI 도입 조직은 여기에 “사람이 설명할 수 있는 설계 결정 비율” 같은 정성 지표를 추가해야 한다.

한국 개발 조직에 주는 시사점

한국 기업은 AI 코딩 도구를 도입할 때 “몇 퍼센트의 개발자가 사용하느냐”를 먼저 묻기 쉽다. 그러나 더 나은 질문은 “AI가 만든 변경을 누가 소유하느냐”다. LLM 위임 작업의 문서 손상이 보여주듯 에이전트가 산출물을 만들면 책임 경계가 흐려진다.

NIST AI Risk Management Framework는 AI 위험을 지도화하고 측정하고 관리하고 거버넌스하는 반복 과정을 제안한다. 소프트웨어 팀에 적용하면, 에이전트 사용 로그뿐 아니라 설계 리뷰, 롤백 훈련, 장애 후 학습, 권한 제한을 같은 운영 체계 안에 넣어야 한다. Statewright의 상태기계 접근처럼 에이전트 자체를 제어 가능한 시스템으로 모델링하는 방법도 참고할 만하다.

앞으로의 기준

AI 코딩의 성숙도는 “AI가 얼마나 많이 작성했나”가 아니라 “AI가 작성한 코드를 조직이 얼마나 잘 이해하고 운영하나”로 갈 것이다. 빠른 복구는 여전히 중요하다. 다만 복구 속도만 믿고 예방, 설계, 소유권을 버리면 조직은 더 빠르게 실패하는 기계를 만든다.

FAQ

AI 코딩 도구를 쓰지 말라는 뜻인가?

아니다. 도구 사용 자체가 문제가 아니라 복구 속도만 믿고 설계 검토와 학습을 줄이는 운영 방식이 문제다.

테스트 커버리지가 높으면 안전하지 않나?

도움은 되지만 충분하지 않다. 테스트가 실제 사용자 의미와 장애 경로를 반영하지 않으면 커버리지는 착시가 될 수 있다.

MTTR 중심 운영은 틀렸나?

틀리지 않다. 다만 MTBF, 변경 실패율, 아키텍처 이해도, 롤백 가능성을 함께 봐야 한다.

에이전트 PR에는 무엇을 추가로 봐야 하나?

변경 의도, 영향 범위, 롤백 경로, 실패 시 소유자, 사람이 검토한 설계 근거가 남아야 한다.

경영진은 어떤 지표를 요구해야 하나?

사용률보다 변경 실패율, 장애 원인 분석 완료율, 에이전트 변경의 재작업률, 핵심 모듈별 인간 소유권을 봐야 한다.