상시 대기 중인 Claude — Anthropic의 CI/CD 장애 초기 대응을 책임지는 Claude Tag

셋업 키트로 나만의 Claude 온콜 시스템 구축하기.

몇 주 전, 제가 온콜 당번이었을 때의 일입니다. 밤 10시에 동료가 슬랙 메시지를 보내왔습니다. 새로운 서비스에서 테스트 44개가 실행되지 않는다는 내용이었습니다.

예전이라면 하던 일을 멈추고 노트북 앞에 앉아 한숨을 내쉬며 한 시간짜리 원인 파악과 수정 작업에 돌입했을 겁니다. 하지만 지금은 워크플로우가 완전히 달라졌습니다. @Claude를 멘션하고 상황을 파악해 달라고 요청하면 됩니다.

이번 경우, Claude는 그날 오전 피처 플래그(feature flag)가 켜지면서 테스트들이 사라진 사실을 발견했고, 롤백해도 안전하다는 분석도 함께 내놓았습니다. 저는 동료에게 플래그를 되돌려 달라고 요청했고, 3분 뒤 Claude가 슬랙으로 스킵 규칙이 제거되었으며 오류율이 정상 수준으로 돌아왔음을 확인해 주었습니다.

지난 몇 달간 Claude Tag는 Anthropic의 CI/CD 장애에 대한 온콜 초기 대응자 역할을 맡아왔습니다. 덕분에 팀원들의 사생활이 보호된 것은 물론, 모든 CI 장애에 즉각적인 초기 대응이 가능해졌습니다. 최근 발생한 장애 중 상황 보고서가 작성된 모든 건에서 Claude가 첫 번째 보고서를 작성했으며, 대부분 15분 이내에 첫 번째 분석 결과를 게시했습니다.

이 글에서는 저희가 구축한 시스템이 어떻게 작동하는지 단계별로 소개합니다. 온콜 당번이 돌아오는 게 더 이상 두렵지 않도록, 직접 구축하는 데 필요한 내용을 모두 담았습니다.

저희의 Claude 온콜 구성

장애 대응 프로세스의 각 단계를 살펴보기 전에, 세부 내용을 이해하는 데 도움이 될 전체 구성 개요를 먼저 소개합니다.

온콜 에이전트에는 네 가지가 필요합니다. 이전에 수행한 작업을 기억하는 메모리, 조사·파악·행동이 가능한 연결과 접근 권한, 언제 다시 작동해야 하는지 아는 스케줄, 그리고 무엇을 해야 하는지 알려주는 지침입니다.

Claude Tag는 저희 온콜 에이전트의 핵심입니다. Claude Tag는 온콜 슬랙 채널 전반에 걸쳐 메모리를 유지하고, 장애 대응 중 단계별 지침을 제공하는 인터페이스 역할을 합니다. Claude는 온콜 채널과 다른 채널에서 발생하는 이벤트에 실시간으로 반응하기도 합니다. "매주 월요일 오전 9시(EST)에 CI 인수인계를 실행해" 같은 자연어 프롬프트로 정기 루틴 스케줄을 설정하는 것도 같은 채널에서 이루어집니다.

Claude Tag는 전용 서비스 계정을 갖추고 있으며, Datadog, Grafana 등 Anthropic CI 엔지니어에게 필요한 도구에 접근할 수 있습니다. 이 설정은 채널 관리자가 한 번만 구성하면 됩니다(설정 방법 보기).

온콜 채널 외에도, Claude Tag가 멤버로 참여한 다른 관련 채널들도 Claude가 모니터링하도록 설정했습니다. 서비스 알림, 설정 변경, PR 업데이트 등 추가적인 컨텍스트를 파악하기 위해서입니다.

상시 지침은 스킬(skill) 형태의 마크다운 파일로 작성되어 GitHub 리포지토리에 커밋됩니다. 덕분에 여러 팀원이 함께 수정하고 발전시킬 수 있으며, 코드와 동일한 방식으로 변경 사항을 관리할 수 있습니다. 라우팅 지침, 정책, 자기개선 루프의 일환으로 축적된 교훈 기록 등 핵심 정보도 여기에 포함됩니다.

이 구성을 완성하는 데는 며칠이 아니라 몇 시간밖에 걸리지 않았습니다. 저희는 유사한 에이전트를 손쉽게 시작할 수 있도록 GitHub에 범용 온콜 셋업 키트를 공개했습니다. 이 키트는 팀의 장애 이력을 트리아지 플레이북으로 변환하고, 인시던트 채널에 진단·에스컬레이션·학습을 수행하는 읽기 전용 Claude를 배치해 줍니다. 가상의 팀 이력을 활용한 실행 과정을 약 10분 안에 확인할 수 있습니다.

핵심만 간추리면

• Claude Team 또는 Claude Enterprise 플랜이 필요합니다
• 조직 소유자가 Claude Tag를 통해 Claude를 온콜 슬랙 채널에 추가해야 합니다
• 조직 소유자는 온콜 슬랙 채널의 Claude를 적절한 커넥터와 GitHub 리포지토리에 연결하고, Claude Code Remote를 설정해야 합니다.
• 인시던트 채널에 Claude를 추가하고, 장애 모니터링과 즉각적인 트리아지를 수행하도록 지시합니다

이제 장애 대응의 각 단계에서 이 변화가 구체적으로 어떻게 나타나는지 살펴보겠습니다.

탐지

Claude는 장애 대응 방식만 바꾸는 게 아닙니다. 장애를 탐지하는 방식 자체를 바꿉니다. 기존에는 장애 탐지에서 두 가지 주요 실패 패턴이 반복되었습니다.

사람이 항상 완벽한 규칙과 임계값을 미리 설정해 두기란 어렵습니다. 트래픽 패턴을 분석하기에 데이터가 충분하지 않을 때는 특히 그렇습니다.

이를 해결하기 위해, 새 서비스를 처음 운영하는 며칠 동안 Claude가 데이터와 수신 알림을 분석해 추가 규칙을 제안하고, 너무 광범위하거나 좁게 설정된 규칙을 세밀하게 조정합니다.

두 번째 실패 패턴은 알림 피로(alert fatigue)였습니다. 발생하는 모든 알림을 일일이 확인하고 검토하는 작업은 무척 번거롭습니다. 하지만 Claude는 사람처럼 지치지 않습니다.

Claude는 각 알림 채널의 모든 관련 알림을 모니터링하고, 루트 oncall.md 파일의 판단 기준을 검토해 아침까지 기다려도 되는지, 아니면 온콜 담당자에게 즉시 알려야 하는지를 결정합니다. 예를 들어, 데이터 분석을 통해 조정된 규칙은 이런 형태일 수 있습니다. "오류율이 2%를 초과한 상태가 5분 이상 지속되고, 알려진 배포 시간대가 아닐 경우 온콜 담당자에게 알림을 보낼 것. 그렇지 않으면 lessons.md에 기록할 것."

Claude 온콜 알림 프로세스가 트리거되는 경로는 두 가지가 더 있습니다.

• CI 팀원이 온콜 채널에 문제를 직접 보고하는 경우입니다. 앞서 소개한 테스트 44개 누락 사례가 이에 해당합니다. 또는
• 사내 누구든 내부 페이지를 통해 인시던트를 등록할 수 있습니다. CI 인프라 인시던트로 분류되면 해당 인시던트를 위한 슬랙 채널이 자동으로 생성되고, 저희 온콜 Claude가 이를 감지해 대응을 시작합니다.

핵심은 이렇습니다. 알림 프로세스는 결정론적(deterministic)으로 작동하지만, 온콜 에스컬레이션은 결정론적 경로와 에이전틱 경로를 모두 활용합니다.

트리아지

Claude가 알림 노이즈를 걸러내는 것도 유용하지만, 진정한 시간 절약은 조사 단계에서 이루어집니다. Claude는 인시던트 발생 후 중앙값 기준 14분 이내에 근거 기반 첫 번째 분석을 게시하며, 가장 빠른 경우에는 첫 번째 보고서에서 4분 만에 근본 원인을 특정합니다.

알림이 인시던트로 에스컬레이션되면, Claude는 이미 슬랙 채널에서 검토 가능한 근거 기반 가설을 준비해 두는 경우가 많습니다. Claude Tag는 오케스트레이션 에이전트와 함께 동적 워크플로우를 시작하며, 각 의존성과 신뢰할 수 있는 정보 소스를 조사하는 실행자(executor) 서브에이전트를 생성합니다.

저희의 경우 Grafana, 로그 저장소, PagerDuty, GitHub, Kubernetes, 슬랙 인시던트 채널이 모두 MCP 커넥터를 통해 연결되어 있습니다. Claude는 여러 단서를 병렬로 추적할 수 있어 MTTR(평균 해결 시간) 단축에 도움이 됩니다.

실행자들이 조사 결과를 오케스트레이션 에이전트에 보고하면, 오케스트레이션 에이전트는 이를 종합해 체계적인 상황 보고서(SITREP)로 정리합니다.

오케스트레이터와 실행자 에이전트는 무작위로 탐색하지 않습니다. 조사 스킬과 버그 유형별 상세 참조 마크다운 파일이 이들을 안내합니다.

예를 들어, 섀도우 다이버전스(shadow divergence) 버그에 대한 617줄짜리 조사 스킬에는 일반적인 조사 과정에서 제가 수행하는 모든 단계가 담겨 있습니다. 실제 인시던트 중 Claude와 함께 단계별로 트러블슈팅하면서 구축했고, 그 경험을 바탕으로 파일을 생성하도록 했습니다.

Lessons.md 역시 Claude의 트러블슈팅을 안내합니다. 이 마크다운 파일은 저희가 해결한 모든 인시던트의 기록입니다. 무슨 일이 있었는지, 근본 원인은 무엇인지, 어떻게 수정했는지, 기억해 둘 주의 사항은 무엇인지를 담고 있습니다. Claude가 자동으로 항목을 추가하며, 새로운 조사는 항상 이 파일을 읽는 것부터 시작합니다. 그래서 Claude의 첫 번째 가설은 최근에 어떤 일이 있었는지를 출발점으로 삼습니다.

같은 패턴이 일정 횟수 이상 등장하면, 해당 내용을 조사 스킬 자체에 반영합니다. 제가 가장 좋아하는 항목은 Claude가 저에 대해 쓴 것입니다. 제가 메트릭을 확인하기 전에 설정 파일만 보고 가정을 세웠던 적이 있었는데, lessons.md에는 지금 이런 문장이 남아 있습니다. "먼저 데이터를 조회하고, 그다음에 가설을 세울 것. 설정 파일은 무엇이 잘못될 수 있는지를 알려주지만, 실제로 무엇이 잘못되었는지는 메트릭이 알려준다."

이러한 도구와 컨텍스트를 갖추고 있어도, Claude가 처음부터 정확한 답을 내놓는 건 아닙니다. 사람의 직관과 경험은 여전히 중요합니다. Claude Tag 덕분에 팀은 인시던트를 멀티플레이어 방식으로 함께 트러블슈팅할 수 있습니다. 누구든 실시간으로 조사 방향을 조정하거나 새로운 가설을 추가할 수 있습니다.

해결

Claude가 알림을 에스컬레이션하고 트러블슈팅할 수 있다면, 직접 수정까지 할 수 있을까요? 이 질문에 대한 답은 팀마다 다를 수 있지만, 저희는 이렇게 접근합니다.

저희 팀의 배포 대부분은 피처 플래그 뒤에서 이루어집니다. 저는 제 권한으로 Claude Code에 별도의 에이전트를 구성해 두었으며, 이 에이전트는 각 피처 플래그를 통해 점진적 배포를 수행할 수 있습니다.

롤아웃 프로세스의 첫 번째 단계에서는 보통 Claude가 카나리아(canary) 트래픽을 관리하고, 문제를 모니터링하며, 피처 플래그를 자동으로 조정합니다. 이 주제만으로도 별도의 글 한 편이 될 수 있어, 여기서는 더 이상 자세히 다루지 않겠습니다.

Claude Tag가 저희 팀을 돕는 다른 해결 경로들은 다음과 같습니다.

• Kubernetes 클러스터의 특정 영역을 드레인하거나 격리해야 하는지 알려주기
• 수요 급증 상황에서 인프라 규모를 확장하는 방법 안내하기 (드문 일이지만, Claude가 구체적인 완화 방안을 바로 제시해 줄 때는 매우 유용합니다). 그리고 가장 빈번하게는,
• 온콜 담당자가 검토·병합·배포하여 신속하게 문제를 해결할 수 있는 PR 형태의 수정 사항 제공하기

검증, 커뮤니케이션, 인수인계

Claude는 조사 단계에서 사용했던 MCP 커넥터와 도구 대부분을 그대로 활용해 수정 사항이 의도한 대로 작동하는지 검증합니다. oncall.md의 상시 지침에 따라, 사후 분석(post-mortem)을 lessons.md와 인수인계 상황 보고서에 기록합니다.

여러 인시던트에 걸친 전체 상황을 전달하기 위해 저희는 ci-weather라는 에이전트를 만들었습니다. 이 에이전트는 각 인시던트 슬랙 채널의 정보, 빌드 메트릭, 머지 큐 통계, 배포 지연 현황을 취합합니다. 그리고 사내 누구나 읽을 수 있는 공개 채널에 뉴스룸 형식의 보고서를 게시합니다. 이제 엔지니어들은 머지를 보류해야 할지, 또는 "CI에 무슨 문제가 있지?"라는 질문에 답하고 싶을 때 저희에게 직접 연락하는 대신 그 채널을 확인하면 됩니다.

솔직히 말하면, 보고서 형식을 완성하기까지 여러 번 수정이 필요했습니다. Claude가 상태 보고서를 생성하는 스킬을 단번에 만들어낼 수는 있지만, 실제로 읽기 좋게 만드는 것은 팀마다 다른 취향의 문제입니다. 이것은 시스템 배관이 아니라 사람을 위한 커뮤니케이션이니까요.

마지막으로, Claude가 lessons.md에 자체 기록을 남기는 것과 별개로, 매주 월요일에는 사람을 위한 인수인계 보고서도 작성합니다. Claude는 일별·주별 요약본을 생성해 팀원이 이전 담당자가 마지막으로 처리한 지점부터 원활하게 이어받을 수 있도록 합니다.

인시던트 모니터링에서 장애 대응 시스템 모니터링으로

저희 소프트웨어 엔지니어들은 2021년 대비 현재 평균적으로 분기당 8배 더 많은 코드를 출시합니다. 품질 기준은 여전히 높게 유지하고 있습니다. 모든 PR에는 담당 엔지니어가 지정되어 있고, 모든 변경 사항은 병합 승인이 필요하며, 동일한 CI 게이트를 통과해야 합니다. 하지만 에이전틱 코딩의 속도를 따라가려면, CI 역시 에이전틱해져야 합니다.

Claude는 제 업무에서 가장 번거로운 부분들, 즉 퇴근 후 장애 대응과 인시던트 커뮤니케이션을 흡수해 주었습니다. 덕분에 저는 시스템 안정성에 실질적인 영향을 미치는 중장기 아키텍처 변화에 집중할 수 있게 되었습니다.

저희가 구축한 시스템에서 가장 마음에 드는 점은, 따로따로 분산된 느낌이 없다는 것입니다. 온콜 프로세스는 여전히 슬랙에서 이루어지고, Claude가 그 채널에 합류했을 뿐입니다.

시작하는 방법:

• Claude Team 또는 Claude Enterprise 플랜이 필요합니다
• 조직 소유자가 Claude Tag를 통해 Claude를 온콜 슬랙 채널에 추가해야 합니다
• 조직 소유자는 온콜 슬랙 채널의 Claude를 적절한 커넥터와 GitHub 리포지토리에 연결하고, Claude Code Remote를 설정해야 합니다.
• 인시던트 채널에 Claude를 추가하고, 장애 모니터링과 즉각적인 트리아지를 수행하도록 지시합니다

셋업 키트로 나만의 Claude 온콜 시스템 구축하기.

이 글은 Anthropic 기술 직원 Sachin Malhotra가 작성하고, Anthropic 직원 Michael Segner가 기여했습니다.