의존하는 API가 멈춘 날, 에이전트는 무엇을 하고 있었나
· BNV Solutions
8월 12일부터 Anthropic Claude 계열 서비스에 장애가 며칠 연속 이어졌다는 보고가 나왔습니다. 12일 여러 모델의 성능 저하로 시작해 13일에는 Mythos 5·Fable 5·Sonnet 5의 오류율이 올라갔고, 14일에는 Claude Code 웹과 API가 영향을 받았습니다. 같은 날 상태 페이지 자체가 인증서 오류로 접속되지 않았다는 점이 눈에 띕니다. 벤더를 탓할 일은 아닙니다. 그 규모의 인프라라면 어디서나 일어납니다. 정작 답할 질문은 따로 있습니다. 그때 우리 에이전트는 무엇을 하고 있었는가.
에이전트 장애는 서버가 꺼지는 모습이 아니라, 이번처럼 오류율이 오르고 응답 품질이 슬쩍 떨어지는 회색 장애로 옵니다. 까다로운 이유는 곱셈입니다. 챗봇은 실패해도 다시 물으면 그만이지만, 툴을 스무 번 호출하는 에이전트는 단계별 성공률 99%에서도 완주율이 8할 근처로 내려앉습니다. 95%면 3분의 1 수준입니다. 벤더 쪽 작은 열화가 우리 쪽에서 기능 정지로 증폭됩니다.
상태 페이지가 함께 멈춘 일은 관측성의 단일 실패점입니다. 장애 판단을 벤더 화면 하나에 맡기면, 그 화면과 서비스가 같은 인프라를 쓰는 순간 함께 사라집니다. 기준은 안에 두어야 합니다. 우리가 보낸 호출의 오류율과 지연을 우리 로그에서 재고, 임계치를 넘으면 사람을 부릅니다. 벤더 공지는 확인용이지 탐지용이 아닙니다.
흔한 처방은 다른 모델로 갈아타는 라우터인데, 스위치 하나로 끝나지 않습니다. 프롬프트는 모델마다 다르게 반응하고 툴 호출 스키마도 미묘하게 어긋나서, 평소 돌려보지 않은 폴백은 필요한 날 두 번째 장애가 됩니다. 재시도도 같아서, 지수 백오프, 즉 실패할수록 대기 간격을 늘려 물러서는 방식 없이 즉시 재시도를 걸면 우리 트래픽이 상대의 회복을 늦추고 청구서만 불어납니다. 폴백은 기능이 아니라 훈련입니다.
실행형 에이전트에는 문제가 하나 더 붙습니다. 절반쯤 끝난 작업입니다. 단비는 사내에서 회의록을 쓰고 일정을 잡는데, 요약을 만든 뒤 저장 직전에 호출이 끊기면 사용자 눈에는 아무 일도 없었던 것처럼 보입니다. 그래서 외부에 흔적을 남기는 단계는 다시 실행해도 결과가 같도록 멱등하게 짜고, 중간 상태는 큐에 남겨 복구할 수 있게 둡니다. 품질을 낮춰서라도 계속 돌릴 일과 멈추고 사람에게 넘길 일을 가르는 선은 장애 전에 그어야 합니다.
7월 7일 Forbes는 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 수 있다는 Gartner 전망을 다시 짚었습니다. 3,412명 설문에서 유의미한 투자를 했다는 응답은 19%였고, 취소 요인으로는 비용 급증과 불분명한 사업 가치, 부실한 리스크 통제가 지목됐습니다. 이번 장애는 그 마지막 항목의 실물입니다. 잘 도는 데모와 계속 도는 시스템의 거리는 모델 성능이 아니라 멈췄을 때를 미리 설계했는지에서 갈립니다.