AI 에이전트 장애 대응 원리 — 로그를 통째로 넣으면 왜 환각이 나오고 MTTR은 어떻게 줄이나

핵심 메시지

• 잠에서 깨어 실제로 판단할 수 있는 상태가 되기까지 평균 22분이 걸리고, 그 사이 다운타임 비용은 분당 수천 달러에 이를 수 있다.
• 로그와 추적 데이터를 통째로 언어 모델에 밀어 넣는 방식은 정답이 아니라 그럴듯한 허구의 인과 서사를 만들어낸다.
• 핵심은 데이터 양이 아니라 컨텍스트 큐레이션 — 의존 관계 지도를 이용해 사건과 실제로 관련 있는 신호만 골라 넣는 것이다.
• 에이전트는 가설을 세우고 추가 증거를 요청하는 과정을 반복해 유력한 근본 원인에 도달하고, 그 사고 과정을 사람에게 공개한다.
• AI는 담당자를 대체하는 것이 아니라 검증 절차·런북·자동화 스크립트·사후 문서를 준비해 평균 복구 시간을 줄이는 역할을 한다.

쉽게 이해하기

IBM 기술 채널의 마틴 킨은 새벽 2시에 울리는 장애 알림에서 이야기를 시작한다. 사람이 잠에서 깨어 실제로 생산적인 인지 상태에 도달하기까지는 평균 22분 정도가 걸리고, 다운타임 1분마다 수천 달러가 사라질 수 있는 상황에서 이 수면 관성은 그 자체로 비싼 비용이다. 인증 서비스가 로그인의 90퍼센트를 거부하거나 결제 게이트웨이가 심하게 느려지는 상황을 떠올려 보면 된다.

당직 신뢰성 엔지니어는 문제를 특정하고, 원인을 찾고, 해결까지 가야 한다. IT 환경은 로그와 추적 같은 텔레메트리를 엄청나게 쏟아내기 때문에 얼핏 AI가 잘할 법한 일로 보인다. 그러나 발표자는 여기서 흔한 함정을 지적한다. 언어 모델의 컨텍스트 창이 아무리 커도 바닥 없는 구덩이는 아니고, 단일 노드 클러스터 하나만으로도 시간당 기가바이트 단위의 로그가 쌓이기 때문이다.

관련 없는 잡음까지 과하게 먹이면 모델은 사실을 검증하는 대신 그럴듯한 단어를 예측한다. 그 결과 순간적인 CPU 스파이크, 정상적인 재시작, 오래된 경고 로그를 엮어 깔끔하지만 실제로는 존재하지 않는 인과관계를 자신 있게 지어낸다. 그래서 무작정 밀어 넣는 방식 대신 필요한 것이 컨텍스트 큐레이션이다.

구체적으로는 지표·이벤트·로그·추적을 모아 두고, 모델에 바로 붓는 대신 중간 단계를 하나 넣는다. 관측 플랫폼이 유지하는 실시간 서비스 의존 관계 지도를 이용해 이번 사건과 실제로 관련된 구성 요소의 데이터만 끌어오는 방식이다. 인증 서비스가 문제라면 그것이 의존하는 사용자 데이터베이스, 세션에 쓰는 캐시, 해당 서비스의 최근 배포를 살피고, 같은 클러스터에서 돌지만 무관한 리포팅 마이크로서비스의 로그는 건드리지 않는다.

조사 에이전트는 지각·추론·행동·관찰의 순환 안에서 가설을 세우고 검증에 필요한 증거를 스스로 더 요청한다. 웹 서비스가 느리면 관련 로그를 가져오고, 데이터베이스 연결 오류를 발견하면 데이터베이스 지표를 조회하고, 최근 업데이트가 보이면 설정 변경을 확인하는 식이다. 그렇게 도출한 유력한 근본 원인은 사고 연쇄와 근거 자료가 함께 제시되어, 담당 엔지니어가 판단을 감독하고 검증할 수 있다.

주요 인사이트

• 발표자는 이것이 사고 예측이 아니라 사고 발생 이후의 진단임을 분명히 한다. 무엇이 잘못될지 미리 맞히는 것이 아니라, 이미 일어난 일을 빠르게 해석해 고치는 것이 목표다.
• 토폴로지 인식 상관관계는 결국 '어디를 보지 않을 것인가'를 정하는 기술이다. 무관한 데이터를 걸러내는 것만으로도 환각의 여지가 크게 줄어든다.
• 에이전트가 내놓은 근본 원인을 그대로 받아들이지 않고, 그 원인이 맞는지 확인할 검증 단계를 먼저 생성하게 하는 설계는 프로덕션 시스템에서 특히 중요하다.
• 런북은 담당자가 해당 구성 요소에 익숙하지 않아도 따라갈 수 있는 순서 있는 조치 목록이며, 각 단계를 배시 스크립트나 앤서블 플레이북 조각으로 바꿔 자동화까지 이어질 수 있다.
• 사고가 진행되는 동안 요약 문서를 계속 갱신해 두면 뒤늦게 투입된 사람도 빠르게 상황을 따라잡을 수 있고, 종료 후에는 사후 검토 보고서가 자동으로 남는다.

자주 묻는 질문

관련 AI 소식