Sentry 장애를 AI에게 고치게 해도 될까? 병합 전 6칸 증거 카드

읽는 시간 약 8분 · 운영 판단 가이드

먼저 답하면: Sentry 이벤트를 바탕으로 AI가 만든 수정 PR은, 원인을 확인했다는 증거가 아니라 조사를 시작할 수 있는 가설입니다. 사건 범위부터 수정 후 관찰 조건까지 여섯 칸을 분리해 채워야 병합·보류·롤백 준비를 같은 기준으로 결정할 수 있습니다.

온콜 중에 오류 보고서와 스택 트레이스를 AI 코딩 에이전트에 전달했더니 그럴듯한 수정 PR이 나왔습니다. 이때 팀의 질문은 “코드가 맞아 보이나?”만이 아닙니다. 이 PR이 지금 보고 있는 사건을 실제로 줄일 근거가 있는가?를 확인해야 합니다. 이 글은 그 판단을 한 장의 6칸 인시던트 증거 카드로 남기는 방법을 정리합니다.

핵심 요약

Sentry의 이벤트, 스택 트레이스, breadcrumbs, 태그는 사건을 좁히는 조사 단서이지 단독 원인 판정은 아닙니다.
suspect commit도 연관된 변경 후보입니다. 한 커밋이나 AI 설명만으로 원인을 확정하지 않습니다.
병합 전에는 사건 범위·원본 이벤트·릴리스/변경점·가설·격리 재현·수정 검증을 따로 기록합니다.
재현이 비어 있거나 PR 범위가 사건보다 넓거나, 관찰·되돌리기 조건이 없으면 긴급 병합 대신 보류가 안전합니다.

운영 장애 이벤트에서 AI 수정 PR 검증까지의 단계 흐름 — AI의 가설 생성과 수정 효과 검증은 서로 다른 단계입니다.

사건 단서는 무엇을 말해 주고, 무엇을 말해 주지 않을까요?

Sentry의 이슈 상세 화면에서는 개별 이벤트의 스택 트레이스, breadcrumbs, 태그와 관련 맥락을 검토할 수 있습니다. 이는 “어느 사용자 흐름, 어느 릴리스, 어느 환경에서 문제가 보였는가”를 좁히는 데 유용합니다. 다만 한 번의 오류와 한 줄의 스택 트레이스만으로 코드 변경의 인과관계가 확정되지는 않습니다.

GitHub는 Copilot 환경에서 Sentry의 crash report, errors, stack traces 및 관련 맥락을 검토해 조사와 수정 검증, PR 준비를 지원한다고 안내합니다. 여기서 중요한 운영 원칙은 간단합니다. AI가 요약한 설명은 카드의 ‘원인 가설’ 칸에만 둡니다. 원본 이벤트와 재현 결과를 대신할 수는 없습니다.

수정 PR을 위한 6칸 인시던트 증거 카드

카드는 길고 복잡한 사후 보고서를 만들기 위한 양식이 아닙니다. 교대 중인 담당자도 “무엇이 확인됐고 무엇이 비어 있는지”를 바로 읽게 하는 최소 기록입니다. 각 칸에는 링크, 시간·환경, 담당자, 보류 조건을 함께 남겨 주세요.

1. 사건 범위
영향을 받은 기능, 시작 시각, 환경, 사용자 영향의 관찰 범위를 적습니다. “결제 API 500”처럼 증상을 쓰되, 아직 원인을 적지 않습니다.
2. 원본 이벤트
해당 이벤트 링크와 스택 트레이스·breadcrumbs·태그를 연결합니다. 민감 값은 링크 권한으로 보호하고, 카드에는 마스킹된 요약만 둡니다.
3. 릴리스·변경점
발생 구간의 배포 버전과 관련 변경 후보를 기록합니다. suspect commit은 후보임을 명시합니다.
4. 원인 가설
AI의 설명, 담당자의 추정, 아직 확인하지 못한 반례를 구분합니다. “확정”이라는 표현을 쓰지 않습니다.
5. 격리 재현
운영과 분리된 환경에서 입력·전제조건·관찰 결과를 남깁니다. 재현이 안 되면 그 상태도 명시합니다.
6. 수정 검증
PR이 바꾼 범위, 회귀 확인, 배포 뒤 살필 신호와 되돌리기 조건을 적습니다.

가상의 예시: 결제 API 500 오류

예를 들어 새 릴리스 뒤 결제 API에서 500 오류가 늘었다고 가정해 보겠습니다. AI가 null 처리 한 줄을 추가한 PR을 제안할 수 있습니다. 하지만 이벤트 태그가 특정 리전에만 몰렸거나, 격리 환경에서 같은 요청이 재현되지 않았다면 그 한 줄은 아직 수정 근거가 아닙니다. 카드에는 “특정 릴리스 이후·특정 리전·원본 이벤트 링크”와 “격리 재현 미완료”를 함께 적고, PR은 조사 상태로 둡니다. 실제 고객 데이터, 토큰, 내부 주소는 예시와 카드에 넣지 않습니다.

세 가지 보류 신호와 다음 행동

격리 재현이 비어 있습니다. 같은 조건과 결과를 확인하지 못했다면 긴급 병합이 아니라 관찰·조사 상태로 둡니다.
수정 diff가 사건 범위를 넘습니다. 오류 한 건을 고친다는 명목으로 넓은 리팩터링이 섞였다면 변경을 분리합니다.
사후 관찰과 되돌리기 조건이 없습니다. 배포 뒤 무엇을 볼지, 어떤 신호에서 되돌릴지 없으면 해결 완료로 단정하지 않습니다.

판단	필요한 카드 상태	변경 범위	다음 행동
병합	사건·원본·가설·격리 재현·수정 검증이 연결됨	사건을 겨냥한 최소 변경	관찰 신호와 되돌리기 조건을 붙여 배포합니다.
보류	재현 또는 반례 검토가 비어 있음	효과가 불명확하거나 범위가 넓음	추가 이벤트·테스트를 수집하고 PR을 분리합니다.
롤백 준비	영향 범위가 확대되거나 관찰 신호가 악화됨	수정 후 회귀 가능성이 남음	되돌리기 절차와 담당자를 확인한 뒤 배포를 중지합니다.

표는 옆으로 밀어 볼 수 있습니다.

권한과 민감 데이터는 별도 경계로 다루세요

Sentry와 코딩 도구를 연결할 수 있다는 사실이 모든 데이터와 쓰기 권한을 한 번에 맡겨도 된다는 뜻은 아닙니다. GitHub 문서는 Sentry MCP 서버가 인증된 예외 데이터 접근을 제공할 수 있는 통합 맥락을 설명하지만, 실제 조직에서는 프로젝트 범위와 노출 필드를 따로 확인해야 합니다.

Sentry 데이터와 AI 코딩 에이전트 권한 분리 및 마스킹 경계 — 관측 데이터 접근, AI 조사, 저장소 쓰기 권한은 같은 권한이 아닙니다.

권한 원칙: 이벤트를 읽는 권한, 민감 필드를 마스킹하는 과정, 저장소에 PR을 만드는 권한을 분리하세요. breadcrumbs나 첨부물에 개인정보·토큰·내부 URL이 있다면 입력 전 최소화와 마스킹이 먼저입니다.

운영 신호 자체를 설계하는 방법은 AI 에이전트 운영 관측 카드에서 이어서 볼 수 있습니다. 수정 PR의 증거를 검토하는 관점은 AI 보안 수정 PR 확인 글, 최종 병합 판단을 기록하는 방법은 AI 코드 리뷰 결정 기록과 함께 보면 더 선명해집니다.

자주 묻는 질문

suspect commit이 보이면 바로 되돌려야 하나요?

아닙니다. suspect commit은 스택과 릴리스 맥락에서 연결된 변경 후보입니다. 원본 이벤트, 영향 범위, 격리 재현으로 가설을 확인한 뒤 결정하는 편이 안전합니다.

재현이 안 되면 AI PR은 버려야 하나요?

바로 버리기보다 조사 상태로 두는 편이 좋습니다. 어떤 환경과 입력을 시도했는지, 아직 확인하지 못한 조건은 무엇인지 카드에 남기고 변경 범위를 최소화하세요.

긴급 상황에서도 여섯 칸을 모두 써야 하나요?

길게 쓰기보다 빈칸을 드러내는 것이 목적입니다. 시간이 부족하면 각 칸에 링크·한 줄 판단·담당자·보류 조건만 남겨도 교대와 되돌리기 판단이 쉬워집니다.

배포 뒤에는 무엇을 확인해야 하나요?

같은 사건 범위의 오류 신호가 줄었는지, 새 회귀 신호는 없는지, 정한 되돌리기 조건이 충족되지 않는지를 관찰합니다. 관찰 전에는 해결 완료라고 단정하지 않는 편이 좋습니다.

참고 자료

GitHub Copilot weekly releases — September 14 — Sentry canvas가 오류·스택·관련 맥락을 검토해 조사와 수정 검증을 지원한다는 공식 변경 이력입니다.
Sentry Issue Details — 개별 이벤트에서 스택 트레이스, breadcrumbs, 태그와 관련 맥락을 검토하는 방법을 설명합니다.
Sentry Suspect Commits — 릴리스와 연결된 변경을 조사 단서로 다루는 공식 문서입니다.
GitHub Copilot MCP server configuration — Copilot과 Sentry 예외 데이터의 인증된 연결 맥락을 설명합니다.