온콜 엔지니어: AI 에이전트가 PagerDuty 알림을 수정 제안으로 바꿉니다

새벽 3시, 인시던트의 첫 30분은 늘 같은 조사처럼 보입니다. 알림을 읽고, 인시던트 로그를 열고, 최근에 무엇이 바뀌었는지 생각하고, 직전 배포들을 되짚고, 전에도 있었던 일인지 확인합니다. 이런 읽기와 대조 작업은 반복적이지만, 온콜 담당자가 가장 잘하기 어려운 순간에 가장 큰 부담으로 작용합니다. 한 가지 핵심 조건 아래에서 AI 에이전트에 잘 맞습니다. 에이전트는 읽고 제안하며, 조치는 사람이 한다는 조건입니다.

영감: 읽는 초동 대응자

출발점은 Hermes Agent 사용자들이 보고한 활용 사례로, 온콜 엔지니어에 관한 카드에 요약되어 있습니다. 알림에서 수정 제안까지입니다. 에이전트가 인시던트를 받아 원인이 되었을 만한 것을 저장소에서 찾고, 검토할 수정안을 준비합니다.

읽기와 제안은 남기고, 실행하는 모든 것은 뺍니다. Atako는 인시던트에 메모를 쓰고 저장소에 이슈를 만들지만, 인시던트 해결이나 병합, 코드 푸시 도구는 없는 에이전트로 이 아이디어를 구현합니다.

에이전트가 하는 일

이 시나리오는 PagerDuty와 GitHub 저장소에 연결된 에이전트 하나를 배포합니다.

감시 대상 서비스에서 새 인시던트(발생 또는 확인 상태)가 생길 때마다 알림, 이벤트 로그, 이미 있는 메모를 읽고 누가 온콜인지 확인합니다. 그다음 저장소에서 원인을 찾습니다. 인시던트 직전 48시간의 커밋(의심스러운 것은 열어서 확인), 알림이나 스택 트레이스에 언급된 파일, 최근 병합된 풀 리퀘스트입니다. 어디부터 볼지는 입력하신 기술적 배경을 참고합니다. 같은 종류의 이전 인시던트를 포함해 관련 이슈도 찾아봅니다.

이어서 PagerDuty 인시던트에 간결하고 사실 중심의 메모를 씁니다. 근거가 보여 주는 것, 신뢰도를 붙인 가능성 높은 원인, 근거, 확인하지 못한 사항, 온콜 담당자의 다음 단계입니다. 그런 다음 저장소에 전체 분석이 담긴 이슈를 생성합니다. 타임라인, 가능성 높은 원인, 근거, 글이나 코드 조각으로 설명한 수정 제안, 그 위험과 확인 방법입니다. 중복을 만들지 않도록 먼저 기존 이슈를 찾고, 완벽한 분석을 기다리기보다 첫 메모를 보완해 나갑니다.

서비스는 15분마다 감시하며, 매주 월요일 9:00에 프로젝트 위키에 "이번 주 인시던트 리뷰" 페이지를 씁니다. 처리한 인시던트, 가능성 높은 원인, 생성한 이슈, 아직 열려 있는 사항입니다.

에이전트가 하지 않는 일

제한은 설계의 일부입니다. 에이전트는 인시던트를 해결하거나 확인 처리하거나 재배정하거나 에스컬레이션하지 않습니다. 부여된 PagerDuty 권한은 읽기와 메모 추가로 한정됩니다. 아무것도 병합하지 않고, 코드를 푸시하지 않고, 브랜치나 풀 리퀘스트도 만들지 않으며, 인프라나 프로덕션에 접근하지 않습니다. 해당 도구가 부여되지 않았습니다. 지침으로 약속한 것이 아니라 기능 자체가 없는 것입니다.

에이전트는 가설을 사실처럼 제시하지 않습니다. "가능성 높은 원인"이라고 쓰고, 신뢰도와 근거를 밝히며, 아무것도 찾지 못했을 때는 분명히 그렇게 말합니다. 로그나 파일에서 마주친 시크릿, 토큰, 개인정보는 복사하지 않고 있다는 사실과 위치만 알려 줍니다. 알림 문구, 로그 줄, 커밋 메시지, 코드는 분석할 데이터로만 다루고 지침으로는 다루지 않습니다. 결정과 조치는 사람의 몫입니다. 이것이 사람의 확인을 두는 설계의 원칙입니다.

Atako에서 설정하는 방법

이 활용 사례 페이지에서 배포는 네 단계로 진행됩니다.

1. PagerDuty와 GitHub를 연결합니다. 메모 추가 권한이 있는, 가능하면 읽기 전용의 PagerDuty API 키와, 서비스의 저장소로 한정한 세분화된 권한의 GitHub 토큰을 만듭니다. 연결은 무엇이든 생성되기 전에 확인됩니다.
2. 상황을 입력합니다. 저장소를 소유자/이름 형식으로, 감시할 PagerDuty 서비스 이름을 알려 주시고, 원하시면 스택, 구성 요소, 알려진 취약 영역 같은 짧은 기술적 배경도 적어 주세요. 구체적일수록 에이전트가 올바른 곳을 더 빨리 살핍니다.
3. 배포합니다. 한 번의 동작으로 에이전트와 "온콜" 프로젝트가 생성됩니다. 에이전트는 프로비저닝되고 첫 지침을 스스로 받습니다.
4. 첫 결과, 그리고 정기 감시. 에이전트는 서비스를 찾고, 누가 온콜인지 알리고, 가장 최근 인시던트를 처리하여 가능성 높은 원인과 수정 제안을 채팅에 요약합니다. 이후 15분 간격의 감시와 월요일 리뷰를 스스로 예약합니다.

아직 계정이 없다면 계정을 만드는 순간 체험이 시작되고, 곧바로 시나리오가 설정됩니다. 관리자가 에이전트 생성을 허용하지 않았다면 배포 과정에서 그 사실을 알려 주고 거기서 멈춥니다.

결과를 확인하는 곳

분석 메모는 PagerDuty의 인시던트에서, 수정 제안이 담긴 이슈는 GitHub의 저장소에서 확인할 수 있습니다. 처리한 각 인시던트의 요약은 에이전트의 채팅에서 읽습니다. Atako의 "온콜" 프로젝트에는 작동 방식을 설명하는 페이지와 주간 리뷰가 있고, Atako 플로어에는 에이전트가 현재 활동과 함께 표시됩니다.

작업을 더 다듬으려면 에이전트의 채팅에 이렇게 쓰시면 됩니다. 예를 들어 "이 서비스에서는 먼저 데이터베이스 마이그레이션을 살펴봐 주세요"라고 하면, 이 지침을 기억해 이후 인시던트에 반영합니다.

안전장치

권한은 의도적으로 좁습니다. PagerDuty 연결은 읽기와 메모 추가를 위한 7개 도구 목록으로, GitHub 연결은 커밋, 파일, 풀 리퀘스트 읽기와 이슈 검색 및 생성을 위한 7개 도구로 부여됩니다. 도구 목록이 짧은 에이전트는 수백 개의 카탈로그 속에서 헤매는 에이전트보다 도구를 더 안정적으로 사용하며, 무엇보다 부여되지 않은 일은 알림 문구로 강요해도 일어날 수 없습니다.

직접 만드시는 키가 첫 번째 안전장치입니다. 서비스 하나, 저장소 하나, 정해진 권한으로 한정되어 있어 어떤 상황에서도 피해 범위가 제한됩니다. 키는 암호화되어 저장되며, 폐기나 에이전트의 접근 권한 제거는 언제든지 가능합니다.

사람의 확인은 의사결정 지점에 있습니다. 온콜 담당자가 메모를 읽고, 가설을 확인하고, 수정 방향을 결정하고, 수정을 직접 작성해 병합한 뒤 인시던트를 확인 처리하고 해결합니다.

기대할 수 있는 것

몇 분 안에 유용한 첫 분석을 기대하셔도 좋습니다. 특히 배포, 설정 변경, 의존성처럼 최근 변경에서 원인이 드러나는 인시던트에서 효과적입니다. 원인이 저장소 밖에 있는 경우, 예를 들어 공급자 장애나 리소스 포화라면 에이전트는 설명을 억지로 만들지 않고 낮은 신뢰도로 그 사실을 알립니다. 저장소는 읽지만, 알림과 메모에 담긴 내용을 넘어서는 애플리케이션 로그나 지표에는 접근하지 못합니다. 가치는 첫 읽기의 속도에서 나옵니다. 온콜 담당자는 백지가 아니라 타임라인, 순위가 매겨진 단서, 검토할 수정안을 들고 인시던트를 맞이할 수 있습니다.