최근 1년 정도는 인시던트 대응을 하지 않았기 때문에, 잊어버리기 전에 자신의 지식과 경험을 정리해 두어야겠다고 생각하여 이 글을 쓰게 되었습니다.

다만, 이왕이면 AI를 활용한 인시던트 대응 프레임워크를 생각해보고 싶다는 느낌입니다.

앞서 말씀드린 대로 인시던트 대응에서 약간 벗어나 있기 때문에, 약간의 망상이 포함될 수도 있지만 너그럽게 이해해 주시기 바랍니다~

다양한 프레임워크가 있겠지만, 현장에서 적용했을 때 가장 잘 맞았던 것은 PagerDuty의 인시던트 대응 프로세스였습니다. 저에게 레거시(Legacy)한 프레임워크는 이 PagerDuty가 제시하는 프로세스의 형태이므로, 이를 전제로 하여 후술할 AI 에이전트를 활용한 인시던트 관리 (Incident Management) 개념을 작성하고 있습니다.

전부 읽으면 꽤 분량이 많지만, 사전 조치, 인시던트 진행 중, 사후 조치. 거기에 더해 인시던트 발생 시의 체제 등이 우선 중요하므로, 우선 그 부분에 관해 레거시 프레임워크를 제 방식대로 풀어서 설명해 드리겠습니다. 더 자세히 알고 싶은 분은 PagerDuty의 트레이닝 자료를 참조하시는 것이 좋을 것 같습니다.

주의할 점을 1부터 10까지 말하자면 엄청나게 많지만, 개인적으로 특히 중요하다고 생각한 **인시던트 대응 중의 마인드셋 (Mindset)**을 아래에 뽑아보았습니다.

• 우선은 서비스 복구를 제일로 생각할 것
• 에스컬레이션 (Escalation)을 주저하지 말 것
• 눈치 보지 말고 의견은 계속해서 낼 것
• 비난하지 말 것
• Incident Commander가 책임자이며, 평상시의 직급과 관계없이 Incident Commander가 회의에서 가장 높은 직급이다 (CEO보다 상위의 결정 권한을 가진다는 정도의 인식이어야 함)

제가 원래 인지하고 있는 프레임워크의 체제는 위와 같은 형태이며, 포인트를 요약하자면 다음과 같은 내용이 개인적으로 중요합니다.

또한 프레임워크상에는 여러 역할이 있지만, 실제로 모든 역할을 부여하는 것이 어려울 수도 있으므로 팀의 실정에 맞춰 커스텀(Custom)해도 괜찮습니다.

참고로 누가 어떤 역할을 맡을지는 사전에 정해져 있는 것이 아니라, 그 자리에서 배정합니다. (실제 상황에서는 실무 역할이 있으므로 그에 끌려 필연적으로 결정되겠지만, 처음에는 그래도 괜찮습니다)

Incident Commander (IC)- 중대 인시던트 발생 시, 현재 무엇이 일어나고 있는지, 그리고 앞으로 무엇이 일어날지에 관한 유일한 정보원이자 의사 결정자로서 기능한다.

• 절대로 흔들려서는 안 되는 점은,
  복구 작업이나 로그 조사는 수행해서는 안 된다는 것이다. - 만약 반드시 Incident Commander (IC)가 조사를 해야만 하는 상황이라면, 그 사람은 IC의 역할을 다른 사람에게 위임한다.

Deputy- IC를 직접 보좌하는 역할로, 단계(Step)를 기록하는 것에 주의를 기울이거나 타이머를 모니터링하는 것보다, 눈앞의 문제에 집중할 수 있도록 IC를 지원한다.

• Deputy는 IC가 될 가능성이 있는 역할이므로, 필요에 따라 IC의 역할을 인계받을 가능성이 있다.

• 또한, IC가 될 가능성이 있는 만큼, IC와 마찬가지로
  복구 작업이나 로그 조사는 수행해서는 안 된다는 점은 공통사항이다.

Scribe- 인시던트 진행에 따라 타임라인 (Timeline)을 문서화하여, 모든 중요한 결정이나 데이터가 사후 리뷰를 위해 남겨지도록 한다.

• IC, Deputy와 마찬가지로
  복구 작업이나 로그 조사는 수행해서는 안 된다. - IC는 인시던트 대응의 컨트롤(Control)에, SME (Subject Matter Expert)는 인시던트 해결에 집중하도록 하지만, 현상 확인이나 사후 포스트모템 (Post-mortem)을 위해 타임라인을 기록해 두는 것은 회고에도 활용할 수 있고, 나아가 당시에는 깨닫지 못했던 영향 범위에 대해 알 수 있는 재료가 될 수 있으므로 Scribe의 역할도 매우 중요하다.

• Liaison (연락 담당자) - 스테이크홀더(Stakeholder)와의 상호작용 및 커뮤니케이션 책임을 지는 역할.

• 세부적으로는 다음과 같이 나뉩니다.

  • 사내용 Internal Liaison, 사외용 External Liaison

• Internal Liaison의 역할 이미지는 각 프로덕트 팀이나 고객 지원(Customer Support) 팀 등의 팀 창구 역할을 하는 사람들입니다. "A가 발생했으므로, 아마도 K 프로덕트에서 B의 영향이 있을 수 있습니다. 조사를 부탁드려도 될까요?"와 같은 상호작용을 하는 사람들입니다.

• External Liaison의 역할 이미지는 고객 지원 팀으로부터 인시던트 발생과 관련된 문의를 취합하거나 고객 대응을 하고, 영업 팀의 고객 대응, SNS를 통한 공지, 또는 Internal Liaison으로부터 받은 인시던트 정보를 외부에 공개하는 등의 역할을 하는 사람들입니다.

• 당연하게도, 조사 요원이 아니기 때문에 복구 작업이나 로그 조사는 수행해서는 안 된다는 점은 공통사항입니다.

• Subject Matter Expert (SME, 주제 전문가) - 대상 분야의 전문가(이하 SME)는 때때로 해결자(Resolver)라고도 불리며, 도메인 전문가(Domain Expert)나 서비스 오너(Service Owner) 등이 담당합니다.

• 문제의 진단, 조사, 수정 등 실제로 직접 작업을 수행합니다.

• 기본적으로 독단적으로 행동하지 않으며, 반드시 결정권자인 IC(Incident Commander)에게 의견을 묻습니다. (물론 제안은 괜찮지만, 독단적으로 행동하지 말라는 의미입니다.)

PagerDuty의 트레이닝 자료 전체를 발췌한 것이 아니라, 제가 실무 중에서 필요하다고 느낀 것들을 발췌하거나 커스텀하여 아래에 나열합니다.

• 포스트모템(Post-mortem) 템플릿 작성 - 사건 내용, 대응 기록 등의 보고서 문서.

• 앞서 언급한 Scribe가 작성하는 대응 기록과는 별개로, 내용을 깔끔하게 정리하기 위한 용도의 위치를 가집니다.

• 인시던트 대응 문서 작성 - 사건 발생 시 범용적으로 사용하는 문서.

• Scribe가 타임라인을 기록하거나, SME가 조사 내용 및 대응한 작업 로그를 남기기 위해 사용합니다.

• 중요도(Severity) 정의 - 보안 사고나 데이터 불일치처럼 사용자가 이용하지 못하는 것을 넘어 비즈니스에 막대한 영향을 미치는 수준인지, 서비스가 완전히 다운되는 수준인지, 일부 서비스는 계속 이용할 수 있는 수준인지 등을 정의합니다.

• 각 중요도에 따라 참여시킬 스테이크홀더나 대응 방침 등을 미리 결정해 둡니다. (예: 보안 사고나 데이터 결손 등이라면 특정 정부 부처에 보고한다거나, 일부 서비스 다운이라면 프로덕트의 인시던트 정보 페이지에 게시하는 정도로 제한하는 등)

• 사전 트레이닝 (대피 훈련) - 실제로 인시던트가 발생하면 상당히 당황하게 되므로, 실제로 스테이징(Staging)이나 개발 환경에서 의도적으로 인시던트를 발생시켜 연습해 보는 것이 좋습니다. 실제로 제가 담당했던 팀도 처음에는 아무도 IC를 하거나 SME 역할을 하지 못했지만, 실제로 트레이닝을 진행하니 특정 개인에게 의존하는 현상(Bus Factor)이 제거되었습니다.

• 실무에서 사용했던 사례를 소개하자면, 제 프로덕트는 k8s(Kubernetes) 기반이었기에 Chaos Mesh를 사용하여 포드(Pod)를 떨어뜨리거나 통신을 차단하는 방식으로 의도적인 인시던트를 일으켜 정기적인 트레이닝을 실시했습니다.

이 부분은 정해진 템플릿이 있는 것은 아니지만, 기본적으로 인시던트 해결을 향해 액션을 취한다는 것이 핵심 줄기입니다.

다만, 개인적으로 팀과 약속(Commit)했던 사항은 다음과 같습니다.

• 즉시 단독 행동을 하지 말고, 우선 역할 분담을 한다. - 단독 행동으로 해결하는 경우도 있지만, 그것은 성공한 경험이 있었기 때문입니다.

• 실패하거나 잘못된 방향으로 돌진할 수도 있으므로, 독단적으로 돌진하지 않도록 주의해야 합니다.

• 단기적인 목표와 장기적인 목표를 정한다. - 단기적인 목표: 1차 해결, 사용자가 기본 기능을 이용할 수 있게 하는 것 등의 목표.

• 장기적인 목표: 영구적인 해결, 문제의 근본 원인(Root Cause) 조사 및 대응 방침 결정 등.

• 다만, 우선은 서비스 복구를 우선시하는 것이 좋으므로, 장기적인 목표의 상세 내용은 현장에서 논의하기보다 큰 틀만 정해두면 충분합니다.

• 역할 분담이 끝나면 방침과 액션을 결정하고 해결을 향해 행동을 시작한다. - 여기서 중요한 것은 마일스톤(Milestone)을 설정하면서 동시에 업데이트해 나가는 것입니다. 이 부분은 IC가 확실하게 판단해야 합니다.

• 팀은 IC를 따르기만 하는 것이 아니라, 필요하다면 의견을 제시하며 팀으로서 함께 해결을 향해 나아가야 합니다.

여러분도 알고 계시다시피, 사후에는 **포스트모템 (Post-mortem)**을 실시해야 합니다. PagerDuty의 포스트모템 관련 페이지가 상세하므로, 자세한 내용은 그쪽을 참조하시는 것이 좋습니다.

다만, 핵심 포인트만 요약하자면 다음과 같은 액션을 취하는 것이 좋다고 생각합니다.

• 인시던트의 내용을 되돌아봅시다. 언제, 무엇이, 왜 발생했는지를 명확히 해 나갑니다.

• 전항의 '장기적인 목표'에 대한 세부 사항을 확정합니다.

• 영구적인 해결을 어떻게 수행할 것인지 고민합니다.

• 결과적으로 영구적인 해결책이 되지 않더라도 개의치 마세요. 비용 대비 편익 (Cost-benefit)과 저울질하여 결정합시다.

• 무엇을 할지 결정했다면 영구 대책을 향해 액션을 취해 나갑시다.

여기까지는 자신의 인시던트 대응을 포함한 지금까지의 인시던트 대응 포인트였습니다.

여기까지 꽤 긴 이야기였지만, 지금부터는 망상을 포함하여 앞으로의 인시던트 대응에 관한 저의 생각입니다.

기본적으로는 지금까지의 체제와 크게 변하지 않을 것이라고 생각합니다.

다만, 각 역할에서 AI 에이전트 (AI Agent)를 활용할 수 있다고 생각합니다. 솔직히 여러분의 상상 범위를 전혀 벗어나지 않는다고 생각합니다만, 적용할 수 있을 법한 곳은 다음과 같습니다.

• Deputy Agent: IC를 지원하며, 판단이나 정보 정리 등을 수행
• Scribe Agent: 채팅, 온라인 미팅 내에서의 의사록, 대응 타임라인을 기록
• SME Agent: 제품별, 서비스별 조사 및 수정을 수행

체제 이야기만 하면 그림의 떡이므로, 실제로 어떻게 도구를 조합할 것인지 생각해 보겠습니다.

여기서는 제가 실무에서 사용해 본 적이 있거나, 현재 사용하고 있는 도구를 전제로 구성해 보겠습니다.

Slack: 인시던트의 주 전장. 채널 (War Room) 기반의 정보 집약과 속보의 장. -
Zoom: SME나 IC가 실제로 목소리로 대화하는 장. 텍스트만으로는 절대 따라잡을 수 없는 장면이 있으므로, 음성을 남기는 것을 전제로 함. -
Notion: 타임라인, 판단 로그, 포스트모템의 1차 소스. -
Claude: 정보의 요약·정리·기록의 오케스트레이션 역할. Deputy Agent / Scribe Agent의 실체. -
Devin: 코드베이스를 수정하는 조사·수정 실행 역할. SME Agent의 실체. -

포인트는, 인간 (IC / SME)은 Zoom과 Slack만 보고 있으면 되는 상태로 만드는 것입니다.

Notion에 대한 기록은 에이전트 측의 업무로 맡기고, 인간은 '복구'와 '의사결정'에만 집중하도록 한다는 사상입니다.

인시던트 중에 자주 발생하는 문제 중 하나는, Zoom에 참여하고 있는 사람과 참여하지 않고 있는 사람 사이의 정보 격차입니다.

Zoom에서 SME가 "Redis의 커넥션 풀 (Connection Pool) 고갈이네요"라고 말하는 순간, 그 정보는 Zoom에 접속해 있는 몇 명에게만 전달됩니다. 반면 Slack에는 "상황이 어떤가요?"라는 스테이크홀더 (Stakeholder)의 문의가 쌓여갑니다.

그리고 IC나 Deputy가 Slack에 글을 쓰러 가는 시간 손실이 발생하는 경우도 많을 것이라 생각합니다.

이 부분을 Scribe Agent와 Deputy Agent로 메웁니다.

Zoom의 텍스트 변환 (라이브 트랜스크립트)을 지속적으로 가져오기 - Zoom의 Transcript를 순차적으로 추출하여 Scribe Agent (Claude)에 흘려보냅니다.

일정한 입도로 청크 (Chunk)를 나누어 요약시키기 - 전문을 그대로 Slack에 흘려보내면 아무도 읽지 않으므로, "1~2분 단위" 혹은 "화제가 전환되는 타이밍"으로 나누어 요약하게 합니다.

"속보로서 가치가 있는지"를 판정하게 하기 - 이 부분이 중요합니다. 모든 요약을 Slack에 던지면 노이즈가 되어 인시던트 대응을 방해합니다. 다음과 같은 것들만 속보 대상으로 삼습니다.

• 영향 범위에 관한 새로운 사실 ("결제 API도 다운되었습니다")

• 원인에 관한 가설의 확정·기각

• IC의 의사결정 ("일단 롤백하겠습니다")

• 단기 목표의 달성 ("1차 복구되었습니다")

• 반대로, 잡담·확인 중인 중간 과정·"잠시만 기다려 주세요" 계열의 발화는 버립니다.

• 이 부분이 중요합니다. 모든 요약을 Slack에 던지면 노이즈가 되어 인시던트 대응을 방해합니다. 다음과 같은 것들만 속보 대상으로 삼습니다.

Slack의 인시던트 채널에 스레드로 속보를 남기기 -
🔴 속보 / 14:32

와 같은 접두사(Prefix)를 붙여서, 인간의 작성 글과 시각적으로 구분할 수 있도록 해두면 혼란이 줄어들 것으로 기대합니다. - 누구의 발화에서 유래했는지(SME의 보고인지, IC의 판단인지)를 라벨(Label)로 덧붙입니다. 이것이 없으면 "AI가 말하는 것뿐"인지 "IC가 결정한 것"인지 구분할 수 없어 2차 피해의 원인이 되기 때문입니다.

이로써 Zoom에 접속하지 않은 Internal Liaison이나 External Liaison이 Slack을 보는 것만으로도 실시간으로 상황을 추적할 수 있는 상태가 됩니다.

구현 방식으로는, Claude의 Slack 연동(Claude in Slack)을 사용하여 채널에 상주시키거나, Agent SDK로 워커(Worker)를 작성하여 Slack Bot으로 구동하는 방식 중 하나가 될 것이라고 생각합니다.

전반부에서 "Scribe의 역할은 매우 중요하다"라고 썼지만, 솔직히 말해서 Scribe는 인간이 수행할 때 가장 힘든 역할입니다.

말하는 속도를 손이 따라가지 못하고, 기록에 집중하면 논의를 따라갈 수 없게 됩니다. 그렇다고 기록이 없으면 사후 분석 (Post-mortem)의 질이 단번에 떨어집니다. 이 부분은 솔직히 AI에게 맡기고 싶은 부분입니다.

타임라인 자동 생성- Zoom의 전사 데이터(Notion AI나 Zoom의 요약 기능으로 취득)와 Slack의 발언을 대조하여, 시각이 포함된 타임라인을 Notion의 인시던트 페이지에 추가해 나갑니다.

• 사전 액션으로 만든 "인시던트 대응 문서" 템플릿을 Notion의 데이터베이스 템플릿으로 설정해 두어, 인시던트 발생 시 에이전트가 페이지를 신규 생성하는 단계까지 자동화할 수 있다면 이상적입니다.

판단 로그를 독립적으로 남기기- 타임라인과는 별개로,
"IC가 무엇을, 왜, 언제 결정했는가"만을 추출한 테이블을 가지고 있으면 사후 분석 (Post-mortem)의 질이 극적으로 향상됩니다. -
시각 / 결정 내용 / 근거가 된 정보 / 결정자 / 결과

정도의 컬럼(Column)만 있으면 충분합니다. - "왜 그런 판단을 했는가"는 나중에 절대 떠올릴 수 없으므로, 그 현장의 발화에서 근거를 찾아주는 것만으로도 가치가 있습니다.

• 타임라인과는 별개로,

SME의 보고를 구조화하여 남기기- "누가", "어떤 컴포넌트를", "어떻게 조사하여", "무엇을 알아냈는가"를 Zoom의 발화로부터 추출하여 기록합니다.

• 이것이 남아 있으면, 다음에 동일한 증상이 나타났을 때 조사 속도가 완전히 달라집니다.

단기 목표 / 장기 목표 및 액션 아이템(Action Item) 기입- Zoom에서 "이것은 영구 대응으로 봅시다"라고 흘러간 이야기는 대부분 잊혀집니다.

• 대화 속에서 장기 목표 후보를 포착하여 Notion의 태스크(Task)로 초안을 작성해 두고, 사후 분석 (Post-mortem) 자리에서 채택 여부를 결정하는 흐름으로 가져가면 누락을 줄일 수 있습니다.

인간 SME가 움직이고 있는 이면에, Devin도 병행하여 조사를 수행하게 합니다.

조사의 병렬화- IC가 "Redis 가설"과 "배포 원인 가설"이라는 두 가지 가설을 가지고 있을 때, 인간 SME에게 한쪽을, Devin에게 다른 한쪽을 할당하는 방식으로 사용할 수 있습니다.

• 인간의 손길이 부족한 인시던트 상황에서 효과적입니다.

최근 배포 차이점 파악- "최근 3시간 동안 머지(Merge)된 PR 중, 결제 계통을 건드린 것을 나열해 줘"와 같은 요청은 궁합이 상당히 좋을 것으로 기대합니다.

수정 PR 작성까지 맡기기- 단,
머지(Merge)와 운영 반영은 반드시 인간(IC의 승인)을 거쳐야 합니다. 여러분도 잘 아시겠지만, 인시던트 대응 중에 AI에게 PR을 작성하게 하면 파괴적인 문제를 일으킬 수 있으므로 리뷰는 반드시 수행해야 한다고 생각합니다.

• 단,

조사 결과도 Slack과 Notion에 흘려보내기- Devin의 작업 결과를 Deputy Agent를 통해 요약하여 Slack에 속보로 흘려보내고, 동시에 Notion의 타임라인에도 기록합니다.

Deputy Agent는 Slack과 Notion에 쌓인 정보를 횡단적으로 살펴 IC를 지원합니다. 인간 Deputy를 대체한다기보다, 인간 Deputy의 보조 역할을 수행하는 이미지입니다.

IC의 "지금 어떻게 되어가고 있어?"라는 질문에 즉각 답변하기- Slack에서 멘션하면, 현시점의 상황, 확정된 사실, 미확정 가설, 진행 중인 액션을 정리하여 답변합니다.

누락 사항 지적

• "단기 목표가 설정된 지 30분이 경과했으나, 진행 상황 공유가 없습니다."

• "영향 범위에 대해 B 프로덕트로의 파급 효과가 확인되지 않은 상태입니다."

• 이러한
  타이머와 체크리스트의 역할은 사실 AI가 가장 잘하는 분야입니다. 인간 Deputy(부관)가 수행하던 "타이머 모니터링"은 통째로 맡길 수 있습니다.

스테이크홀더(Stakeholder)용 문구 초안 작성

• Liaison(연락 담당자)을 위해, 사내용 및 사외용 각각의 톤으로 상황 설명을 위한 초안을 작성합니다.
• 당연하게도,
  외부로 나가는 문장은 반드시 인간이 리뷰해야 합니다. 이 점 또한 타협할 수 없는 핵심 포인트입니다.

지금까지 의욕적으로 작성했지만, AI를 도입함으로써 새롭게 발생하는 리스크도 있으므로 그 부분도 적어두겠습니다.

AI의 출력과 인간의 결정을 반드시 구분할 것

• 가장 무서운 것은 AI가 제시한 가설이 어느샌가 "확정된 사실"로서 타임라인에 올라가고, 그것을 전제로 의사결정이 진행되어 버리는 것입니다.

• Slack에서도 Notion에서도,
  발신처(인간 / 에이전트)와 확도(확정 / 가설)를 반드시 라벨링(Labeling)하는 운영 방식을 갖추어야 한다고 생각합니다.

속보 빈도 조절

• AI는 무한히 말할 수 있기 때문에, 방치하면 인시던트 채널이 AI의 독백으로 가득 차게 됩니다. 인간의 대화를 방해하는 순간, 이 아키텍처는 해악이 됩니다.

의사결정은 IC(Incident Commander)가 주도할 것

• 전반부에서 "IC가 유일한 의사결정자"라고 썼지만, 이는 AI가 도입되어도 변하지 않습니다. 오히려 AI가 제안하는 내용이 늘어나는 만큼,
  AI의 제안을 채택할지 여부를 IC가 명시적으로 결정하는 프로세스가 중요해질 것이라고 생각합니다.

장애 시에는 함께 대응할 것

• Slack이나 Zoom, 혹은 AI 서비스 자체가 다운되는 케이스의 인시던트도 발생할 수 있습니다.
  AI 없이 운영하는 절차를 버리지 않는 것은 대전제입니다. 사전 트레이닝(대피 훈련)도 AI가 있는 패턴과 AI가 없는 패턴 모두를 수행해 두는 것이 좋습니다.

기록에 무엇을 남길지는 사전에 결정해 둘 것

• 인시던트 내용에 따라 개인정보나 인증 정보가 대화에 등장할 수 있습니다. 녹취록을 그대로 외부 서비스에 전송하는 구성으로 할 경우에는, 이 부분에 대한 정리를 사전에 완료해 두어야 합니다.

결국 AI에게 시키고 있는 것은 "기록", "요약", "전달", "감시"와 같이, 인간이 하면 지치지만 소홀히 하면 나중에 문제가 되는 업무입니다.

반대로 "결정한다", "책임을 진다"라는 부분은 인간에게 남습니다. 전반부에 쓴 레거시(Legacy) 프레임워크의 사상은 AI가 도입되어도 본질적으로는 아무것도 변하지 않는다는 것이 현재 저의 생각입니다.