아날로그 인시던트 지도 제작자의 책상: 다음 페이저 폭풍 전에 손으로 그리는 신뢰성 지도

모든 큰 장애에는 공통된 ‘특별한 순간’이 있습니다. 바로 모든 페이저가 한꺼번에 울리고 난 직후의 짧은 정적입니다.

그 순간에는 모두가 떠들고, 메트릭은 비명을 지르고, 대시보드는 새빨개진 상태에서, 누군가가 운영에서 가장 답하기 어려운 질문을 던집니다.

“대체 뭐가 뭐에 의존하고 있는 거죠?”

이 질문에 몇 분 안에 답하지 못한다면, 그건 인시던트 대응 문제라기보다 의존성 매핑 문제입니다.

이 지점에서 바로 아날로그 인시던트 카토그래피(incident cartography)—말 그대로 손으로 그리는 신뢰성 지도—와 체계적인 테이블탑(tabletop) 연습이 등장합니다. 이 둘을 잘 활용하면 인시던트 대응은 막판 소방전이 아니라, 계속해서 개선되는 의도적인 역량으로 변합니다.

페이저 폭풍 전에 테이블탑 연습이 중요한 이유

인시던트 대응은 프로덕션이 무너지는 순간에 시작되지 않습니다. 그보다 훨씬 전에, **회의실(또는 Zoom)**에서 시작됩니다. 그 도구가 바로 테이블탑 연습입니다.

테이블탑은 말 그대로 시뮬레이션 인시던트입니다. 실제 인시던트에 투입될 사람들과 함께, 현실적인 장애 시나리오를 실시간으로 따라가며 조직이 어떻게 행동하는지 관찰합니다.

잘 설계된 테이블탑은 다음을 도와줍니다.

플레이북 검증: 런북(runbook)이 존재하는가? 쉽게 찾을 수 있는가? 실제로 쓸 만한가?
프로세스 빈틈 발견: 외부 커뮤니케이션은 누가 담당하는가? 고객에게 영향이 가는 완화 조치를 누가 결정하는가?
툴링 한계 노출: 적절한 Observability, 로깅, 접근 권한이 있는가? 모든 게 다섯 사람의 개인 SSH 설정 뒤에 숨어 있지는 않은가?
커뮤니케이션 경로 스트레스 테스트: 엔지니어링, 지원, 보안, 리더십 사이의 협업은 어떻게 이뤄지는가?

이 모든 실험이 고객 신뢰나 매출을 태우지 않고 이뤄집니다.

핵심은 하나입니다. 교과서적인 장애가 아니라, 실제로 일어날 법한 인시던트를 시뮬레이션하라는 것입니다. 예를 들어:

리전 일부 장애로 인한 부분적인 서비스 손실
서서히 나빠지는 서드파티 API
실제일 수도 있고 아닐 수도 있는 보안 경보
느리게 진행되는 데이터 손상
특정 샤드에만 잘못 적용된 피처 플래그

이런 시나리오를 돌리면, 평소에는 드러나지 않다가 압박이 걸려야만 튀어나오는 문제들이 꾸준히 발견됩니다.

“온콜이 DB 접근 권한이 있다고 생각했는데, 없네요.”
“이 내부 API에 뭐가 의존하는지 전혀 모르겠습니다.”
“법무팀에 알릴 필요는 있는데, 인시던트 채널에 초대되어 있지 않네요.”

실제 페이저 폭풍이 몰아칠 때 이 사실들을 처음으로 알게 되는 상황은 피해야 합니다.

의존성 매핑: 단순 자산 목록 그 이상

대부분의 조직에는 이런 목록이 있습니다.

서비스
데이터베이스
큐(Queue)
서드파티 프로바이더
팀

하지만 인시던트 상황에서, 목록은 거의 쓸모가 없습니다. 대응자가 필요한 것은 구조입니다.

**의존성 지도(dependency map)**는 자산 목록으로는 대답할 수 없는 질문에 답해 줍니다.

무엇이 무엇을 호출하는가?
어떤 서비스들이 이 데이터베이스에 의존하는가?
이 서드파티가 다운되면, 어떤 고객 플로우가 깨지는가?
이 팀이 비가용 상태라면, 누가 어떤 변경을 할 수 있는가?

자산 인벤토리가 *“우리는 40개의 마이크로서비스를 가지고 있다”*라고 말한다면, 의존성 지도는 이렇게 말합니다.

“서비스 A는 B와 C에 의존하고, B는 데이터베이스 X를 사용하며, C는 서드파티 Y에 의존한다. A와 C는 둘 다 엔터프라이즈 고객의 체크아웃 경험을 제공한다.”

이 차이는 곧 다음의 차이입니다.

기술적 블라스트 레디우스(Blast Radius): 어떤 시스템들이 연쇄적으로 실패하는가
비즈니스 블라스트 레디우스: 어떤 고객, 기능, 매출 흐름이 영향을 받는가

그리고 결정적으로, 지도는 **숨겨진 단일 장애점(SPOF, Single Point of Failure)**을 드러냅니다.

“작은” 내부 인증 서비스인데, 모든 프로덕트가 이걸 쓴다든가
레거시 배치 잡을 재시작할 줄 아는 사람이 딱 한 명뿐이라든가
모든 팀이 긴급 패치를 배포할 때 거쳐야 하는 공유 CI/CD 파이프라인이라든가

지도가 없다면, 이런 것들은 고장 나기 전까지는 계속 보이지 않습니다.

왜 아날로그인가: 손으로 그리는 지도는 생각보다 훨씬 잘 통한다

아마 이미 다이어그램은 있을 겁니다.

자동 생성한 아키텍처 그래프
APM 도구에 있는 서비스 맵
CMDB(Configuration Management Database)

이런 것들은 분명 유용하지만, 충분하지는 않습니다.

심각한 인시던트 한가운데 놓였을 때, 이런 지도들은 종종 우리를 배신합니다. 이유는 대개 이렇습니다.

너무 밀도가 높다: 엣지가 수백 개라 한눈에 읽을 수 없다.
너무 추상적이다: 기술적인 연결만 보이고, 비즈니스 임팩트나 팀 오너십은 안 보인다.
너무 멀리 있다: 예전에 한 번 만들고는 업데이트하지 않아, 아무도 신뢰하지 않는다.

여기에서 등장하는 것이 바로 아날로그 인시던트 카토그래퍼의 책상입니다.

화이트보드를 떠올려 보세요. 포스트잇, 굵은 마커, 인덱스 카드 한 묶음. 목표는 예쁜 다이어그램이 아니라 공유된 이해입니다.

수작업으로 신뢰성 지도를 그리는 데는 분명한 장점이 있습니다.

의도적인 사고를 강제한다
시스템 두 개 사이에 선을 그릴 때마다 이런 질문을 하게 됩니다.
“이게 정말 이걸 의존하나? 방향은 맞나? 항상 그런가, 특정 조건에서만 그런가?”
복잡성을 손으로 느끼게 만든다
화이트보드에 선과 상자가 늘어날수록, 사람들은 그 화살표 덩어리의 ‘무게’를 체감합니다. 많은 경우 처음으로 시각적으로 “이 경로가 이렇게 취약했구나”를 이해하게 됩니다.
압박 상황에서 기억에 더 잘 남는다
직접 그려보고, 화살표 방향을 두고 설전도 벌이고, 포스트잇을 이리저리 옮기는 그 물리적 행위가 머릿속 모델을 굳힙니다. 나중에 프로덕션이 불타오르면, “그때 빨간색으로 동그라미 쳤던 그 취약한 경로”가 떠오릅니다.
크로스펑셔널 협업을 촉진한다
인프라, 애플리케이션 팀, 데이터, SRE, 보안, 고객 지원까지 모두가 같은 보드를 보며 손가락으로 가리킬 수 있습니다. 이견이 바로 수면 위로 올라오고, 실시간으로 정리됩니다.
비기술적 의존성도 드러난다
사람과 프로세스도 같이 그릴 수 있습니다. 누가 페일오버를 승인할 수 있는지, 누가 프로덕션 접근 권한을 갖고 있는지, 어떤 서드파티가 어떤 핵심 플로우를 가로막는지까지요.

이걸 단순한 아키텍처 다이어그램이 아니라, 인시던트 지도라고 생각하세요. 도로, 다리, 병목, 그리고 당신의 디지털 도시를 떠받치는 핵심 인프라를 그리는 일입니다.

아날로그 매핑 + 테이블탑을 함께 돌리는 방법

아날로그 지도와 테이블탑 연습은 함께 쓸 때 효과가 가장 큽니다.

아래는 가볍지만 유용한 접근 방식입니다.

1. 진짜로 걱정되는 시나리오를 고른다

듣기만 해도 불편해지는, 현실적인 시나리오부터 시작하세요.

주요 데이터베이스 리전의 성능 저하 또는 부분 장애
결제, 인증, DNS, 이메일 같은 핵심 서드파티의 대규모 장애
네트워크 파티션으로 인한 전반적인 레이턴시 증가
핵심 시스템에서 수상한 데이터 유출 징후가 보이는 보안 인시던트

한 단락 정도로, 충분히 그럴듯하지만, 탐색의 여지가 남아 있는 시나리오를 작성합니다.

2. 모두 함께 1차 버전 지도를 그린다

회의실(또는 가상 화이트보드)에 모여서 묻습니다.

이 시나리오에 직접적으로 관련된 건 무엇인가?
(서비스, 데이터 저장소, 서드파티)
그 구성 요소들은 무엇에 의존하는가?
어떤 고객 플로우가 이 구성 요소들에 의존하는가?

그리고 다음을 그립니다.

서비스와 데이터 저장소는 박스(Box)로
서드파티는 다른 모양이나 색으로
의존성 방향은 화살표가 있는 선으로
추가 주석:
- 비즈니스 중요도(예: 매출 직결, SLA 관련 여부)
- 팀 오너십
- 알려진 리스크 영역(예: “Single AZ”, “No Failover”, “유일한 담당자 1명”)

목표는 완벽한 그림이 아니라 공유된 가시성입니다.
“잠깐, 저게 진짜 저걸 의존하나요?”, “이건 나중에 확인해 봐야겠다” 같은 말이 많이 나오는 게 정상입니다. 이런 것들은 꼭 별도로 메모해 두세요.

3. 지도를 보면서 테이블탑을 돌린다

이제 인시던트가 실제로 발생한 것처럼 과정을 밟아 봅니다.

모니터링 알람이 뜨는 상황을 가정합니다.
“가장 먼저 어디를 보겠는가?”라고 묻습니다.
지도를 보며 잠재적 블라스트 레디우스를 추적합니다.
- “이 데이터베이스가 느려지면, 어떤 서비스들이 시끄러워질까?”
- “인시던트 채널에 누구를 불러야 할까?”
- “어떤 고객 여정이 위험해질까?”

진행하면서 지도에 마킹합니다.

취약한 의존성에는 빨간 선
동작이 확실하지 않은 곳에는 물음표
완화 지점(피처 플래그, 페일오버, 점진적 기능 저하 등)에는 별표

곧 이런 것들이 눈에 들어오기 시작합니다.

프로세스의 빈틈: 누가 고객 공지 수준의 인시던트를 선언할 수 있는지 아무도 모른다.
툴링의 빈틈: 대시보드가 없거나, Synthetic 체크가 없거나, 로그 위치를 모른다.
조직의 빈틈: 핵심 팀이나 서드파티와의 연락 경로가 정리되어 있지 않다.

4. 발견사항을 구체적인 개선 과제로 전환한다

세션 마지막에는 반드시 실행 가능한 작업으로 정리해야 합니다.

모니터링과 알람 추가 또는 수정
런북 생성 또는 업데이트
인시던트 역할과 에스컬레이션 경로 명확화
단일 장애점(SPOF) 줄이기 – 기술적이든 사람에 의한 것이든

그리고 나서, 이 지도를 디지털 형태로 정리해 두세요.
사진을 찍어 위키에 올리거나, 간단한 다이어그램 도구로 다시 그리는 것도 좋습니다. 다만, 이건 살아 있는 도구이지, 박제된 산출물이 아니라는 점을 잊지 마세요.

업데이트 지옥에 빠지지 않고 지도를 유지하는 법

모든 것을 완벽하게, 실시간으로 반영한 지도가 필요하지는 않습니다. 필요한 것은 정말 중요한 것들에 대해, 충분히 정확하고 최신에 가까운 지도입니다.

실용적인 원칙 몇 가지를 권합니다.

크리티컬 패스에 집중하라: 고객 가입, 체크아웃, 인증, SLA가 걸린 데이터 파이프라인 등
주기적으로 리뷰하라: 분기별로, 혹은 큰 아키텍처 변경 후에
인시던트 후에 반드시 업데이트하라: 현실이 당신을 놀라게 했다면, 지도에 틀린 부분이 있다는 뜻입니다. 바로 수정하세요.
오너십을 지도에 명시하라: 각 컴포넌트를 어떤 팀이 소유하는지 지도만 봐도 알 수 있어야 합니다.

이렇게 하면, 시간이 지나면서 핵심 플로우와 플랫폼에 대한, 신뢰할 수 있고 사람이 이해할 수 있는 지도들이 조금씩 쌓입니다. 완전하지 않을 수는 있어도, 믿고 쓸 수 있는 수준이 됩니다.

소방전에서 ‘훈련된 역량’으로

매핑과 테이블탑을 건너뛰는 조직에서 인시던트는 대개 이렇게 보입니다.

난장판이 된 Slack 채널
끝없는 ‘찍어보기’식 변경
무엇이 영향 받는지 매번 새로 놀람
포스트모템에서 “몰랐다”, “그럴 줄 알았다” 같은 말이 반복됨

반대로, 테이블탑을 꾸준히 돌리고 의존성 지도를 잘 유지하는 조직의 인시던트는 이렇게 바뀝니다.

더 빠른 트리아지: 어디를 봐야 하고, 누구를 불러야 하는지 안다.
더 나은 우선순위 판단: 가장 시끄러운 알람이 아니라, 비즈니스 임팩트가 가장 큰 것부터 처리한다.
더 조율된 대응: 역할이 명확하고, 핸드오프가 매끄럽고, 커뮤니케이션이 정제되어 있다.
지속적인 개선: 모든 연습과 실제 인시던트가 지도, 플레이북, 아키텍처 개선으로 되돌아간다.

결국 이게 진짜 보상입니다. 인시던트 대응이 겨우 수습하는 소방전이 아니라, 조직이 의도적으로 연습하고 연마하는 하나의 전문 역량으로 자리 잡는 것입니다.

결론: 폭풍이 오기 전에, 지도 제작자의 책상을 차려라

인시던트를 잘 대응하기 위해 꼭 새 도구가 필요한 것은 아닙니다. 필요한 것은 마커 한 자루, 화이트보드 한 개, 그리고 올바른 사람들이 모인 한 시간입니다.

다음 페이저 폭풍이 오기 전에, 이렇게 해 보세요.

현실적이고, 생각만 해도 부담스러운 시나리오 하나를 고른다.
실제로 대응에 투입될 팀들을 한데 모은다.
시스템, 서비스, 사람, 서드파티를 포함해 손으로 의존성 지도를 그린다.
그 지도를 보며 인시던트가 실제인 것처럼 전체 과정을 걸어본다.
배운 모든 것을 지도로, 플레이북으로, 모니터링으로, 오너십 정리로 반영한다.

아날로그 인시던트 카토그래피를 일회성 이벤트가 아닌 습관으로 만드세요. 실제 알람이 울리기 시작했을 때, 대응자들은 단지 도구와 대시보드만 가진 것이 아니라, 머릿속에 지형을 그릴 수 있는 지도를 가지고 있게 될 것입니다.

그리고 그 차이가, 폭풍 속에서 길을 잃는 것과, 그 한가운데서 다른 사람들을 이끌 수 있는 것을 가릅니다.