TL;DR

  • Anthropic의 Claude는 운영 시스템을 조사하고 유효한 수정안을 제시할 수 있지만, 잘못된 설명에 대응팀을 이끌기도 해 스스로 장애를 해결할 수 있는지는 여전히 ‘어쩌면’임.
  • 세 건의 장애 사례에서 Claude는 이미지 요청 오류 너머의 악용 계정을 찾아내고, 모니터링 수치 오류의 원인을 추적했으며, 캐시 저하라는 그럴듯한 오진에도 빠짐.
  • OODA 루프 기준으로 로그·메트릭 관찰과 수정안 결정은 강점이지만, 발견한 정보의 맥락을 파악하는 능력은 들쭉날쭉하고 운영 반영에는 사람의 승인이 필요함.
  • 자율적인 장애 대응의 한계는 모델 성능뿐 아니라 계측 상태, 보안 접근 권한, 사람에게만 있는 맥락, 로그 전송 비용에도 좌우됨.
  • 온콜 엔지니어의 반복 작업을 줄일 수는 있어도, 완전 자율 운영은 아직 멀었으며 상당 기간 사람의 개입이 필요함.

장애 사례 1: 버그 너머를 살펴봄

  • Anthropic에서 Claude 운영과 장애 대응을 맡는 Alex Palcuie는 3월 발표에서 “Claude가 스스로 문제를 고칠 수 있는가?”라는 질문에 “아니오”라고 답했지만, 이달 초 Signals Berlin에서는 답을 “어쩌면”으로 바꿈.
  • Claude는 프로덕션 시스템을 조사하고 타당한 수정안을 제시하며 Alex에게 Move 37 같은 놀라움을 안기기도 하지만, 대응팀이 그럴듯하면서도 틀린 설명을 따라가게 만들기도 함.
  • 새해 전야에 Opus가 HTTP 500 오류를 더 많이 반환하자 Alex는 Claude Code에 조사를 요청함.
  • Claude는 실패 요청에 이미지가 정확히 22개 포함된다는 점을 확인하고 이미지 전처리 버그를 찾아냄. Alex는 이 시점에 API 팀에 티켓을 전달했을 것이라고 설명함.
  • Claude는 조사 범위를 넓혀 같은 시각에 비슷한 요청을 보낸 200개 계정을 찾아냈고, 이 계정들이 사흘 전에 생성된 이메일 패턴이 동일한 4,000개 계정 배치에 속한다는 점을 확인함.
  • Claude가 안전장치 팀의 참여를 권고했고, 해당 팀은 악용을 확인함. 버그 수정에 집중하는 대응자가 놓쳤을 가능성이 있는 더 큰 맥락까지 포착한 사례임.
  • Alex에게 이 일은 Move 37의 순간이었으며, 이후 장애 대응 업무가 달라질 것임을 깨달은 계기임.

장애 사례 2: 잘못된 모니터링 수치

  • 추론 라우터(inference router)가 정상 클러스터의 트래픽을 비우고, 트래픽을 넘겨받은 서버에 과부하를 일으킨 사건에서도 Claude가 Alex를 놀라게 함.
  • 대응 채널의 사람들은 데이터센터를 원인으로 지목했지만, Claude는 일부 서버의 초당 토큰 수가 물리적으로 가능한 수준을 넘어선 점을 발견함. 사람이라면 확인할 생각조차 하지 못했을 수도 있는 지표임.
  • Claude는 시스템이 아니라 측정값이 잘못됐다는 결론을 내리고, 메트릭 수집기가 재분할된 뒤 5분 동안 두 샤드가 같은 서버를 수집해 라우터가 의존하는 처리량 수치가 부풀려졌음을 추적함.
  • Claude는 수정안을 제안하고 테스트했으며, 팀은 재발 방지를 위해 수집기의 자동 확장 기능을 일시 중지함.
  • Alex에게 이 또한 Move 37의 순간임. Claude가 자신의 전문 영역인 인프라를 넘어 Alex도 전문가가 아닌 관측 가능성(Observability) 스택까지 조사한 사례임.

장애 사례 3: 그럴듯한 오답의 함정

  • Alex가 소개한 마지막 사건에서는 한 클러스터가 5분 동안 요청의 41%에 오류를 반환함.
  • Claude는 직전에 로컬 캐시 적중률이 하락한 점을 발견함. 캐시 손실이 오류를 설명하는 듯했고, 발생 시점도 설명에 설득력을 더함.
  • 한 시간 뒤 다른 엔지니어의 Claude 세션이 빠진 맥락을 찾아냄. 로컬 캐시 적중에 실패한 요청도 공유 캐시에서 데이터를 가져오고 있었으며, 전체 캐시 적중률은 거의 하락하지 않았음. 실제 문제는 과부하된 서버였음.
  • Alex는 그래프가 자신이 예상한 설명과 맞아떨어졌기 때문에 같은 실수를 할 수도 있었다고 말함. Claude가 빠진 함정은 사람도 빠지는 함정임.
  • Alex는 Google에서 첫 관리자로 일할 때 Steve McGhee가 명확한 이유 없이 그래프를 들여다보면 실제 문제가 아닌 것을 문제로 착각할 수 있다고 경고하곤 했던 일을 떠올림.
  • 에이전트는 훨씬 많은 그래프를 검색할 수 있지만, 그 능력은 오해를 부르는 패턴을 찾아낼 기회도 늘리는 양면성을 지님.

장애 대응에서 들쭉날쭉한 AI 역량

  • Alex는 Claude의 자기 문제 해결 능력을 평가하기 위해 미국 공군의 OODA 루프인 관찰(Observe), 상황 파악(Orient), 결정(Decide), 행동(Act)을 가져옴.
  • 변화하는 상황을 더 빨리 이해하는 쪽이 우위를 점한다는 원리는 조종석뿐 아니라 장애 대응 채널에도 적용된다는 관점임.
  • 관찰은 대형 언어 모델(LLM)의 강점임. 로그 검색, 메트릭 조회, 여러 경로의 병렬 조사를 인간 대응자보다 빠르게 수행함.
  • 상황 파악은 발견한 정보의 의미를 해석하는 단계로, 역량의 편차가 두드러지는 지점임.
  • 결정 역량도 양호한 편임. Claude는 수정안을 제안하고 장단점을 비교하며 과거 장애를 기준으로 테스트할 수 있음.
  • 행동에는 여전히 경계선이 필요함. Alex는 프로덕션의 모든 수정에 사람의 승인이 필요하며, 자신이 실행하는 명령을 모두 이해하고 싶다고 밝힘.
  • 더 높은 자율성을 허용하려면 일상적인 작업은 승인하고 위험도가 높은 작업은 검토 대상으로 표시하는 프로덕션 작업 분류기가 필요하다는 주장임.

모델은 활용할 증거가 필요함

  • Alex는 Google에서 8년 동안 근무하며 Staff 레벨에 오른 SRE이며, 현재 Anthropic에서 최상위 모델과 거의 무제한에 가까운 토큰에 접근할 수 있음.
  • 그가 Claude의 자기 문제 해결 가능성을 여전히 “어쩌면”이라고 본다면, 이는 AI SRE 업계 전반에 현실적인 기대 수준을 설정함.
  • AI 지원 장애 대응 도구를 만드는 Rootly의 관점에서, 대부분의 팀은 모델과 무관한 이유로 Alex보다 불리한 출발점에 있음. 에이전트의 성능은 접근 가능한 맥락의 질에 달려 있음.
  • 코드와 인프라에 계측이 부족하거나, 보안 제한이 기존 데이터 접근을 막거나, 핵심 맥락이 사람들의 머릿속에만 있을 수 있음.
  • 비용도 변수임. 애플리케이션 로그를 Datadog에 전송하는 비용이 예산을 훨씬 넘어섰다는 엔지니어들의 이야기를 반복해서 들었으며, 그 결과 장애 대응 에이전트가 필요한 맥락을 얻지 못해 쓸모없어지는 사례가 있음.
  • 이런 도구가 온콜 엔지니어의 반복 작업을 줄일 수는 있지만, 완전 자율 운영까지는 아직 거리가 있으며 상당 기간 사람의 개입이 이어질 전망임.

각주

  • Move 37은 바둑 챔피언 Lee Sedol을 상대로 AlphaGo가 둔 예상 밖의 수를 가리킴. 전문가에게 처음에는 실수처럼 보였던 수가 AI의 승리에 기여함.