장애가 나면 흩어진 정보부터 모은다. 경보에서 영향을 받은 서비스를 찾고 트레이스와 로그를 확인한다. 최근 배포와 코드 변경도 대조한다.
숙련된 엔지니어는 이 순서에 익숙하다. 그래도 정보를 모으는 동안 고객 영향은 계속된다.
이 시간을 줄이기 위해 팀원이 Incident Agent를 개발했다. 장애 분석에 필요한 정보를 모으는 에이전트다. 이 글에서는 그 개발·운영 사례를 바탕으로 장애 대응에서 AI에 어떤 일을 맡길 수 있는지 살펴본다.
에이전트는 사람이 판단할 수 있도록 필요한 맥락부터 모으도록 구성됐다.
에이전트가 알아서 도구를 고르는 방식에서는 실행할 때마다 순서가 달라졌다. 로그부터 볼 때도 있었고 코드부터 볼 때도 있었다. 장애와 관계없는 배포를 원인으로 고르기도 했다.
이후에는 SRE가 평소 장애를 분석하는 순서가 규칙에 반영됐다. 경보에서 시작해 트레이스와 로그를 확인하고 배포 이력과 코드를 대조하는 순서다.
AI가 같은 순서로 분석하려면 운영 절차부터 정리돼 있어야 했다. 사람도 설명하지 못하는 판단을 AI가 같은 방식으로 반복해줄 수는 없었다.
초기 버전은 요청을 식별하는 트레이스 ID(Trace ID)를 조회 결과에 없는데도 만들어 답했다. 장애가 난 뒤의 배포를 원인으로 지목하기도 했다. 문장은 자연스러워 틀린 답을 놓치기 쉬웠다.
이를 막기 위해 도구 조회 결과에 없는 식별자는 답변에 쓸 수 없도록 규칙이 추가됐다. 장애가 난 뒤의 변경도 원인 후보에서 제외됐다. 초기 지원 범위도 좁게 설정됐다.
결과에는 확인한 사실과 추측이 구분돼 있었다. 확인하지 못한 내용도 표시됐다. 답보다 근거를 먼저 볼 수 있어야 했다.
Google SRE도 장애 분석을 관찰과 가설 검증의 반복으로 설명한다. 시스템을 모른 채 일반적인 절차만 따라가면 분석이 느려진다고 말한다. Effective Troubleshooting
실제 장애에서 Incident Agent가 사람이 검토하던 원인 후보를 먼저 찾은 적이 있다. 반대로 요청을 맞는 분석 에이전트로 보내지 못한 적도 있다.
한 번 맞힌 결과만으로 분석을 맡기기는 어렵다. 호출과 데이터 조회가 늘 같은 방식으로 동작해야 한다. 실패했을 때는 사람이 이유를 확인할 수 있어야 한다.
오탐 사례는 규칙과 지식 저장소에 반영됐다. 분석 절차도 코드 수정 없이 바꿀 수 있도록 구성됐다. 시스템이 바뀌면 장애를 보는 순서도 바뀐다.
AI가 원인 후보를 내놔도 롤백이나 스케일 조정은 사람이 결정한다. 고객 영향과 변경 위험은 서비스 맥락을 알아야 판단할 수 있다.
Incident Agent는 오류가 시작된 위치를 보여주고 직전 변경과 관련 로그를 연결했다. 사람이 확인할 가설도 줄였다.
이런 도구를 평가할 때는 정답률과 함께 사람이 검토할 첫 가설이 나오기까지 걸린 시간을 봐야 한다. 가설에 붙은 근거가 조회 결과와 맞는지도 확인해야 한다. 틀린 답을 먼저 검토하면 복구 조치가 늦어질 수 있다.
이 사례에서 내가 중요하게 보는 부분은 정보를 찾는 시간을 줄여 사람이 빨리 결정할 수 있게 하는 것이다.
그러려면 장애 분석 순서와 데이터 접근 방식부터 정리해야 한다. AI의 답을 검증할 장치도 필요하다.
이 에이전트도 SRE의 장애 분석 순서가 규칙에 반영된 뒤에야 일관된 순서로 정보를 모을 수 있었다.