기업 IT 에이전트는 절반을 놓친다, 검증 레이어라는 빈자리

어떤 문제인가

기업은 IT 운영을 자율 에이전트에 맡기라는 권유를 사방에서 받는다. 그런데 정작 프런티어 모델조차 SRE 장애 해결 벤치마크에서 절반을 못 넘긴다. 더 곤란한 건 패턴이다. 조사를 한 턴 더 돌릴수록 정답에 가까워지는 게 아니라 오탐이 늘어난다. 후보 원인이 쌓이기만 하고, 그중 뭘 믿어야 할지는 더 흐려진다.

운영 현장에서 이건 단순한 정확도 문제가 아니다. 에이전트에게 실행 권한을 주는 순간, 절반의 확률로 틀리는 판단이 프로덕션에 그대로 반영된다. 새벽 3시 장애 상황에서 잘못된 롤백 한 번이 어떤 결과를 내는지는 온콜을 서본 사람이 안다. 그래서 많은 팀이 “에이전트 도입”을 외치면서도 실제로는 손을 못 댄다.

왜 지금인가

에이전트가 틀린다는 사실 자체가 시장이다. 모델 성능이 1년 안에 완벽해질 거라면 이 빈자리는 임시방편에 그치겠지만, 장애 해결처럼 맥락이 길고 부작용이 큰 작업에서 50% 선을 단숨에 넘기긴 어렵다. 그사이 기업은 에이전트를 쓰고는 싶은데 실행 권한은 못 주는 어정쩡한 상태에 머문다. 바로 그 간극을 메우는 레이어에 수요가 생긴다.

어떻게 만들 수 있나

핵심은 에이전트를 “실행”이 아니라 “제안”으로 묶어두는 것이다. 에이전트가 근본 원인 후보를 내면, 검증 레이어가 그 후보를 로그·메트릭·과거 인시던트와 대조해 신뢰도를 매기고, 명백히 틀린 것을 쳐낸 뒤 사람이 결정할 수 있는 좁은 목록으로 축소한다. 휴먼인더루프는 병목이 아니라 안전장치로 설계한다, 사람이 보는 건 원시 로그가 아니라 이미 검증·축소된 후보다.

flowchart LR
  A[장애 신호] --> B[에이전트: 원인 후보 생성]
  B --> C[검증 레이어: 로그·메트릭 대조]
  C --> D[오탐 제거·신뢰도 점수]
  D --> E[좁힌 후보 목록]
  E --> F[사람: 결정·실행]

MVP는 특정 스택(예: 쿠버네티스 + 관측성 도구 한 종) 하나에 좁혀 검증 규칙과 eval 파이프라인을 붙이는 것으로 시작한다. 범용을 노리기 전에, 한 환경에서 오탐을 실제로 줄여주는 걸 증명하는 쪽이 빠르다.