Anthropic이 사내 CI/CD 파이프라인의 1차 온콜 대응을 Claude에게 넘겼다. 사내에서는 이를 Claude Tag라고 부른다. 8월 18일 공개된 발표에서 가장 눈에 띄는 수치는 두 가지다. 장애 티켓이 열린 뒤 Claude가 증거를 갖춘 첫 분석을 내놓기까지 걸리는 시간은 중앙값 14분. 운이 좋으면 최초 보고서에서 4분 만에 근본 원인을 짚어내기도 한다.
배경 설명은 상당히 솔직하다. 엔지니어 1인당 분기 코드 생산량이 기존의 8배로 늘었다는 것이다. 생산량이 늘어난 만큼 빌드 실패, 테스트 불안정, 배포 롤백 같은 사건의 절대량도 함께 늘었고, 한 건을 조사하는 데 한 시간 넘게 걸리는 경우가 많으며 근무 시간 외에 발생하는 일도 잦다.
Claude가 쥐고 있는 권한
이 시스템을 움직이는 건 모델 자체의 성능이 아니라 접근 권한 설계다. Claude는 MCP 커넥터를 통해 정해진 도구 세트에 연결된다. 지표와 스택 트레이스를 보는 Grafana와 로그 저장소, 모니터링을 보완하는 Datadog, 커밋과 diff를 읽고 풀 리퀘스트를 올리는 GitHub, 클러스터 단위 조치안을 내는 Kubernetes, 그리고 알림 수신과 결론 게시에 쓰는 PagerDuty와 여러 개의 Slack 채널이다. 전용 서비스 계정으로 동작하며 행동 내역은 감사가 가능하다.
알림이 사람을 깨워야 하는지 여부는 자연어로 적힌 규칙이 판단한다. 기사에 나온 예시는 이렇다. 오류율이 2%를 넘는 상태가 5분 넘게 지속되고, 알려진 배포 시간대가 아니면 온콜을 호출한다. 이런 임계값은 예전에는 모니터링 시스템 설정 파일 안에 있어 바꾸려면 릴리스 절차를 거쳐야 했다. Claude가 읽을 수 있는 규칙으로 옮기면서, 값을 조정하는 비용은 문장 한 줄을 고치는 수준으로 떨어졌다. 자동 알림 외에 팀원이나 사내 장애 페이지에서 수동으로 트리거할 수도 있다.
트리아지는 병렬로 진행된다
장애가 접수되면 Claude는 오케스트레이터 에이전트를 띄우고, 이 에이전트가 여러 서브 에이전트를 병렬로 보내 서로 다른 의존성을 동시에 확인한다. 하나는 로그를 읽고, 하나는 최근 커밋을 비교하고, 다른 하나는 지표 그래프를 본다. 이 '동적 워크플로'가 바로 14분짜리 분석을 만들어낸다.
판단을 뒷받침하는 건 두 종류의 파일이다. 하나는 장애 유형별 조사 매뉴얼 격인 스킬 파일로, 그중 특히 까다로운 버그 한 종류를 다룬 파일은 617줄에 달한다. 다른 하나는 lessons.md로, 사건이 종결될 때마다 Claude 스스로 내용을 추가하고 다음에 비슷한 패턴을 만나면 가장 먼저 참조한다. 두 파일 모두 GitHub에 저장되며 코드와 동일한 리뷰 절차를 거친다.
수정은 여전히 사람 몫
수정 단계에는 사람의 자리가 남아 있다. 가장 흔한 산출물은 풀 리퀘스트로, 엔지니어가 검토한 뒤 배포 여부를 결정한다. 배포는 피처 플래그로 통제된다. 클러스터와 관련된 문제라면 Claude가 드레이닝, 격리, 스케일링 같은 조치안을 제시하지만 실행 여부는 사람이 판단한다. 수정이 반영된 뒤에는 같은 도구 세트로 다시 검증한다.
Anthropic은 몇 가지를 명확히 사람 몫으로 남겨두었다. 중장기 아키텍처 개선, 공유 모드에서 Claude와 함께 가설을 보완하는 작업(Claude가 처음부터 늘 옳은 것은 아니라 사람의 직관으로 방향을 바로잡아야 하기 때문이다), 풀 리퀘스트 승인 게이트, 그리고 커뮤니케이션의 어조다. 상태 보고서 형식은 팀이 원하는 방식에 맞을 때까지 여러 차례 조정을 거쳐야 했고, 이 부분은 자동화로 흡수되지 않았다고 한다.
인계 과정도 제품화됐다. 주간 종합 보고서와 일일 요약이 있고, ci-weather라는 별도 에이전트가 여러 사건을 모아 외부에 공개할 수 있는 상태 설명으로 정리한다.
놓치기 쉬운 8배라는 숫자
이 8배라는 숫자는 '왜 이 일을 하는가'와 '해보니 어땠는가' 두 지점에서 의미가 조금 다르다. 한쪽에서는 이것이 압박의 원인이다. 팀 규모는 그대로인데 배포량이 8배로 늘면 장애 티켓 수도 그대로 머물 수 없다. 다른 쪽에서는 이것이 이 온콜 체계가 성립하기 위한 전제조건이기도 하다. 만약 코드가 여전히 사람 손으로 한 줄씩 작성되고 있었다면, 장애의 형태와 빈도, 해석 가능성은 엔지니어의 직관에 훨씬 가까웠을 것이고 AI 트리아지의 한계 효익은 이렇게 뚜렷하지 않았을 것이다. AI가 코드 작성의 상당 부분을 담당하게 된 이상, 첫 단계 분류를 AI에 맡기는 것은 이 흐름의 연장선에 있다.
도입 조건도 분명히 적혀 있다. Claude Team 또는 Enterprise 플랜이 필요하고, 도구 연결과 권한 설정에는 처음에 몇 시간이 걸린다. 대부분의 팀에게 어려운 부분은 연결 작업 자체보다, 풀 리퀘스트를 올리고 클러스터를 조작할 수 있는 서비스 계정을 내줄 배짱이 있는가일 것이다.
참고 출처: Anthropic 공식 블로그, CocoLoop. 중앙값 14분의 트리아지 시간, 최단 4분의 근본 원인 파악, 분기 코드 생산량 8배 증가, 스킬 파일 617줄은 모두 회사의 공개 발표를 따른 것이다.