연필로 그리는 인시던트 온실 트램: 한 장짜리 종이 지도로 장애 전 과정을 움직이기

프로덕션에서 뭔가가 깨지는 순간, 가장 먼저 성능이 떨어지는 시스템은 사람의 뇌다.

알림, 로그, Slack 스레드, ETA를 묻는 임원, 어렴풋이 기억나는 런북, 심지어 다급한 고객까지 동시에 상대하고 있을 수 있다. 이런 스트레스 상황에서 뇌는 아직 명확하게 추론할 재료가 없다. 이미 트램을 몰고 있는 와중에, 지금 무슨 일이 벌어지고 있는지에 대한 머릿속 지도를 만들려고 애쓰는 중이기 때문이다.

이 글은 그 지도를 의도적으로 만드는 방법에 대한 이야기다. 나는 이것을 “연필로 그리는 인시던트 온실 트램(pencil‑drawn incident greenhouse tram)”이라고 부른다. 장애의 각 단계마다 업데이트되며 함께 움직이는, 단순하고 공유되고 진화하는 다이어그램이다. 모두가 한 장의 종이(또는 화이트보드, 혹은 그에 상응하는 디지털 보드)를 바라보며 다음을 이해할 수 있다고 생각해 보자.

지금 우리가 알고 있는 것
지금 우리가 시도하고 있는 것
누가 무엇을 맡고 있는지
AI가 어디에 들어올 수 있는지 (그리고 절대 들어오면 안 되는 곳은 어디인지)

그리고 나중에는, 같은 지도를 기반으로 인시던트를 재구성해 명확하고 유용한 포스트모템을 만들 수 있다.

시계가 아니라 독자의 뇌에서 시작하라

대부분의 인시던트 리뷰 문서는 이렇게 쓰인다. "09:13에 알람이 발생했다. 09:16에는…"

연대기(타임라인)를 기록하는 것은 쉽지만, 읽기에는 어렵다. 대시보드든, 런북이든, 포스트모템이든, 장애를 이해하려고 할 때 내가 먼저 필요한 것은 타임라인이 아니라 지도다.

인지 부하를 기준으로 스토리 순서를 다시 짜라

분 단위 재생 대신, 인시던트 산출물을 다음과 같이 구조화하라.

고수준 지도(빅 픽처)
- 무엇이 깨졌는가? (증상)
- 무엇이 영향을 받았는가? (사용자, 시스템)
- 어떤 유형의 장애였는가? (성능, 데이터 손상, 가용성 등)
- 무엇이 그것을 고쳤는가? (고수준 요약)
시스템 개요(어떻게 연결되어 있는가)
- 관련된 주요 컴포넌트들의 단순한 다이어그램
- 데이터/트래픽 흐름을 보여주는 화살표
핵심 의사결정 지점
- 그 시점에 우리가 사실이라고 생각했던 것
- 그에 따라 무엇을 하기로 결정했는지
- 그 결과 무엇을 발견했는지
상세 타임라인
- 이벤트, 로그, 메트릭, 변경 사항, 채팅 기록 등

사람은 시간을 따라 왼쪽에서 오른쪽으로 읽기보다, 위에서 아래로 읽는다. 이 점을 활용하라. 인시던트 문서는 뇌가 혼란을 이해해 가는 방식에 맞춰 설계해야 한다.

인시던트를 위한 ‘한 장짜리 종이 지도’

중요한 장애가 발생할 때마다 모두가 볼 수 있는 한 장짜리 종이가 따라다닌다고 상상해 보자. 실제로 벽에 붙인 종이일 수도 있고, 화이트보드일 수도 있고, Miro 같은 온라인 화이트보드일 수도 있다.

그 종이 위에 온실 트램(greenhouse tram) 다이어그램을 그린다. 핵심 컴포넌트마다 박스를 하나씩 그리고, 그 사이의 트래픽 흐름을 선으로 표시한다. 인시던트가 전개되면서 여기에 다음을 계속 추가한다.

빨간 X 표시: 의심되거나 실제로 고장 난 컴포넌트 위에 표시
스티키 노트나 콜아웃: 가설과 테스트를 적는다. ("X를 하면 Y가 보일 것으로 기대")
이름 또는 역할: 진행 중인 액션 옆에 책임자를 적는다. ("API 롤백 – 온콜 A 담당")

이 지도는 곧 **시각적인 인시던트 신경 중심(nerve center)**이 된다.

지도에는 무엇을 적을까?

최소한 다음은 있어야 한다.

사용자 진입 지점: 트래픽이 들어오는 곳 (브라우저, 모바일 앱, 외부 API 소비자 등)
크리티컬 패스: 로드 밸런서 → API 게이트웨이 → 서비스 → 데이터베이스 → 큐 등
현재 증상: 문제가 보이는 지점 (예: "결제 지연 > 5초", "/login에서 500 에러")
마지막으로 건강했던 지점: 그 경로 중 마지막으로 정상임이 확인된 지점
알려진 변경 사항: 해당 경로에 영향을 줄 수 있는 배포, 설정 변경, 인프라 업데이트

그리고 장애 대응 중에 다음과 함께 지도를 실시간으로 업데이트한다.

데이터 수집 (메트릭, 로그, 트레이스 등)
가설 변경 ("DB 문제일지도… 아니다, 캐시 계층 같다")
실행한 액션 (페일오버, 롤백, 기능 플래그 전환 등)

이 한 장짜리 지도는, 장애 동안 팀 전체가 함께 타고 가는 트램 노선이 된다.

스트레스받은 뇌를 기준으로 설계하라

인시던트 중에는 누구도 전체 그림을 가지고 있지 않다. 사람들은 다음과 같은 상태에 있다.

정보가 부분적으로만 주어져 있고
아드레날린이 치솟아 있으며
계속 컨텍스트 스위칭 중이다

이건 팀의 버그가 아니라, 인간이 원래 그렇게 동작하기 때문이다.

그래서 인시던트 프로세스와 문서는 인지 부하를 낮추도록 설계해야 한다.

1. 런북은 시각적이고 한눈에 들어오게 만들 것

각 런북의 시작은 다음으로 시작하라.
- "당신이 이 런북을 보게 되는 상황은…" (증상 기준 설명)
- 관련 시스템의 단순한 다이어그램
- 세부 단계에 들어가기 전에 3–5개의 상위 단계 요약
불릿 포인트와 명시적인 체크 항목을 사용하라.
- "X 메트릭이 Y 이상인 상태가 Z분 이상 지속되는지 확인하라. 아니라면, 멈추고 다시 평가하라."

2. 역할을 완전히 명확하게 할 것

종이 지도 위에는 항상 다음을 명시하라.

인시던트 커맨더(IC, Incident Commander)
커뮤니케이션 담당(Comms lead)
각 서브시스템별 주 책임 응답자(Primary responder)

소유권이 명확해지면, 사람들은 "이건 누가 하는 거지?", "이거 내가 해야 하나?" 같은 생각에 뇌 용량을 쓰지 않아도 된다.

3. 동시에 진행되는 스레드를 제한할 것

응답자들에게 다음을 권장하라.

중요도가 낮은 아이디어나 논의는 지도의 한 켠에 "나중에" 섹션을 만들어 눈에 띄게 적어 두기
한 번에 하나의 가설에 집중하기
가설을 명시적으로 종료하기 ("기각: 네트워크 경로 A 문제 아님")

목표는 조사의 현재 상태를 가시화하는 것이다. 그래야 뇌가 모든 것을 기억하려 애쓸 필요가 없다.

AI의 위치: 권위가 아니라 조수

AI 도구는 인시던트 대응에서 엄청나게 도움이 될 수 있다. 하지만 AI는 신뢰할 수 있는 추론 엔진이 아니며, **진실의 원천(ground truth)**도 아니다.

AI는 반드시 **조수(assistant)**로 취급해야 한다. **권위(authority)**로 두어서는 안 된다.

인시던트에서 AI의 알려진 약점

논리적 추론: 그럴듯하지만 틀린 인과관계를 만들어낼 때가 많다.
환각(hallucination): 존재하지 않는 API, 플래그, 설정 등을 지어낼 수 있다.
맥락 부족: 실시간 시스템 신호를 포함해, 여러분이 보고 있는 모든 것을 자동으로 알지 못한다. 맥락을 세심하게 제공해 주지 않으면 특히 그렇다.

장애 중 AI를 안전하게 쓰는 방법

종이 지도 위에 AI가 만든 아이디어나 코드 옆에 **"AI 보조(AI-assisted)"**라고 적어 둘 수도 있다.

AI가 가장 효과적인 영역은 다음과 같다.

붙여 넣은 로그나 에러 메시지 요약
로그/메트릭을 위한 검색 쿼리 제안
헬스 체크 엔드포인트를 반복 호출하는 스크립트 같은, 보일러플레이트 진단 스크립트 생성
사고가 끝난 뒤 런북 업데이트 초안이나 인시던트 요약 초안 작성

이 모든 것은 여전히 사람의 검증이 필요하다.

가드레일 없이 위험한 AI 사용법

"이 장애의 원인이 뭐야?"라고 묻고, 그 답을 곧바로 실행하는 것
AI가 프로덕션 설정이나 인프라 정의를 직접 수정하게 두는 것
실제 사용자 데이터를 건드리는 쿼리나 마이그레이션을, 테스트 없이 AI가 만들어 준 그대로 실행하는 것

코드/설정/데이터를 변경하는 모든 AI 제안은 다음과 같이 취급해야 한다.

실력이 어떤지 모르는 신입 엔지니어가 쓴 코드
매우 뛰어날 수도 있지만
그럴수록 더더욱 철저한 리뷰와 테스트가 필요하다.

지도 위에 이를 다음처럼 기록할 수 있다. "AI 가설: X. 사람 Y가 리뷰. 상태: 승인/기각." 이렇게 하면 추론의 주도권은 항상 사람에게 남는다.

AI 보조 변경 사항: 매번 리뷰하고 테스트하라

위기 상황에서는 이런 유혹이 크다. "AI가 이 쿼리가 문제를 해결할 거랬어. 그냥 돌리자."

그 유혹을 이겨내야 한다. 다음과 같은 명시적인 규칙을 만들어라.

AI가 생성한 모든 변경 사항은 리뷰 필수
- 지정된 사람이 diff, 스크립트, 명령을 리뷰한다.
- 리뷰어 이름을 인시던트 지도에 기록한다.
가능한 가장 안전한 환경에서 먼저 테스트
- 스테이징, 섀도 트래픽, 또는 한 샤드/한 테넌트 같은 제한된 폭(blast radius)에서 먼저 검증한다.
실행 전에 롤백 단계부터 적어둘 것
- "이게 잘못되면 X, Y, Z를 실행해 되돌린다."

그 순간에는 느리게 느껴질 수 있다. 하지만 AI가 만든 변경으로 2차 장애를 한 번만 겪어 보면, 왜 이런 절차가 필요한지 금방 이해하게 된다.

포스트모템은 48시간 안에 진행하라

그래프가 다시 녹색으로 돌아갔다고 해서 인시던트가 끝나는 것이 아니다.

포스트모템을 미룰수록, 팀이 공유하고 있던 공동 지도는 빠르게 휘발된다. 사람들은 다음을 잊어버린다.

당시 실제로 무엇을 믿고 있었는지
어떤 경로를 탐색했다가 버렸는지
어느 순간에 얼마나 스트레스받고 혼란스러웠는지

재구성된 지도를 정확하게 유지하려면, 단순한 규칙을 하나 두어라.

인시던트 해결 후 48시간 이내에 포스트모템을 실행한다.

아직 인시던트 채널에 있을 때 바로 일정을 잡아라.

이 짧은 시간 창은 다음을 보장해 준다.

더 생생한 기억
더 신뢰할 수 있는 정성적 데이터
실제 스트레스 상황에서 프로세스가 어떻게 작동했는지에 대한 더 나은 인사이트
(사후적으로 미화된 모습이 아니라 실제 모습)

정성적 데이터로 전체 그림을 채워 넣기

메트릭과 로그는 무엇이 일어났는지를 보여 준다. 하지만 어떤 느낌이었는지, 왜 그런 결정을 내렸는지는 거의 보여 주지 못한다.

좋은 포스트모템은 인시던트를 시스템 + 인간 이벤트로 다룬다. 인간 측면을 포착하려면 정성적 데이터를 수집해야 한다.

1. 짧은 설문

인시던트가 해결된 직후, 관련된 모든 사람에게 간단한 폼을 보내라.

가장 헷갈렸던 지점은 무엇인가요?
언제 가장 막힌 느낌이 들었나요?
어떤 도구나 문서가 도움이 되었나요? 혹은 방해가 되었나요?
그때 화면에 있었으면 좋았을 것 같은 정보나 도구가 있었나요?

2. 짧은 인터뷰

핵심 참여자(IC, 주요 응답자, 온콜 개발자 등)에게는 다음을 진행하라.

10–15분 정도의 짧은 대화
핵심 의사결정 시점을 중심으로: "10:27에 왜 경로 A 대신 B를 선택했나요?"

3. 1인칭 메모

응답자들이 인시던트 중에 타임스탬프가 찍힌 메모(거친 불릿이라도 좋다)를 남기도록 장려하라. 이것은 다음을 재구성하는 데 큰 도움이 된다.

실제 가설 vs. 사후에 정리된 미화된 스토리
감정적 부하 ("이때 나는 정말 확신이 없었다")

작성하는 포스트모템 문서 안에서, 이런 관점들을 데이터와 함께 엮어라. 그래야 진짜 지도를 얻을 수 있다. 단순히 정제된 기술적 버전만 남는 것이 아니라.

모두 한데 모으기

“연필로 그리는 인시던트 온실 트램”은, 흩어진 머릿속 모델과 끝없이 올라가는 채팅 스크롤 대신, 하나의 살아 있는 공유 지도를 중심에 두고 장애를 설계하자는 메타포다.

정리하면 다음과 같다.

인지 부하에 맞춰 문서를 구조화하라: 먼저 고수준 지도, 그다음 타임라인.
하나의 시각적 지도로 시스템, 가설, 소유권, 액션을 추적하라.
스트레스받은 뇌를 기준으로 설계하라: 역할을 명확히 하고, 시각적인 런북을 쓰고, 동시에 진행되는 스레드를 제한하라.
AI는 조수로 대하라: 빠르고 유용하지만 가끔 틀리는 존재로, 절대 최종 권위로 두지 말 것.
AI가 만든 모든 변경 사항은 신뢰할 수 없는 코드처럼 리뷰하고 테스트하라.
포스트모템은 48시간 안에 진행해 기억이 생생할 때 함께 되짚어라.
정성적 데이터까지 수집해, 무엇이 깨졌는지뿐만 아니라 사람이 그 혼란을 어떻게 헤쳐 나갔는지까지 이해하라.

당신이 장애를 한 장짜리 지도에 그릴 수 있고, 그 그림을 인시던트 전 과정을 통해 계속 살아 있게 유지하며, 이틀 안에 모두 함께 다시 재생해 볼 수 있다면, 시스템은 더 탄탄해지고, 그 시스템을 운영하는 사람들은 더 자신감 있게 움직일 수 있게 될 것이다.