소개: 당신의 ‘작은’ 장애는 사실 작지 않다

대부분의 조직은 SLA를 깨고, 매출에 영향을 주고, 임원을 깨우는 큰 장애만 깊이 분석합니다. 하지만 실제 신뢰성의 이야기는 작은 사고들에 숨어 있습니다. 5분짜리 API 오류, 잘못 설정된 feature flag, 특정 리전만 느려진 부분 장애 같은 것들 말입니다.

각각은 별거 아닌 것처럼 보이지만, 모이면 보물 창고가 됩니다.

이런 ‘작은’ 장애 하나하나는 시스템과 조직 안에서 특정한 경로를 따라 이동합니다. 알람이 울리고, 온콜이 호출되고, Slack 채널이 열리고, 대시보드가 갱신되고, 사람들이 결정을 내리고, 일이 다른 팀으로 넘어갑니다. 그 보이지 않는 흔적 속에서 우리는 다음을 발견할 수 있습니다.

• 감춰져 있던 의존성
• 팀 간 인계 과정의 취약함
• 커뮤니케이션의 빈틈
• 툴이 보지 못하는 블라인드 스팟

연필로 그리는 장애 아틀라스(Pencil-Drawn Outage Atlas) 는 간단한 실천입니다. 종이와 연필 수준의 낮은 진입장벽으로, 실제로 사고가 서비스·팀·툴·이해관계자 사이를 어떻게 이동하는지 지도로 그려내고, 그걸 기반으로 진짜 신뢰성 시스템을 바라보고 개선하는 방법입니다.

새로운 플랫폼이 필요하지 않습니다. 필요한 건 연필 하나, 간단한 템플릿 하나, 그리고 모든 장애를 학습 가능한 지도 하나로 바꾸겠다는 약속뿐입니다.

1. 가능한 한 가장 작은 사고부터 지도 그리기

대형 장애를 기다릴 필요가 없습니다. 다음에 발생하는 작은 사고부터 시작하세요.

• 결국은 별일 아니었던 noisy alert
• 자동 복구된 짧은 502 에러 스파이크
• 빠른 롤백으로 처리된 배포 문제

각 사고마다 Before–During–After(전–중–후) 지도를 그립니다.

1. Before (전) – 사고 이전의 시스템·조직 컨텍스트는 어떠했는가?

   • 어떤 서비스들이 관련되어 있었는가?
   • 누가 온콜이었는가?
   • 어떤 내부·외부 의존성이 있었는가?

2. During (중) – 사고는 어떤 경로로 흘러갔는가?

   • 증상은 처음 어디에 나타났는가? (로그, 메트릭, 사용자 제보 등)
   • 어떤 알람이 떴고, 누가, 어떤 툴에서 그것을 보았는가?
   • 어떤 결정이, 누가, 어떤 정보를 바탕으로 내렸는가?

3. After (후) – 어떻게 마무리되었는가?

   • 무엇이 바뀌었는가? (설정 변경, 롤백, 페일오버 등)
   • 모두가 이 사고가 “끝났다”고 인식한 시점은 언제인가?
   • 어떤 후속 작업이 생성되었는가?

이걸 장애 지하철 노선도를 그린다고 생각해도 좋습니다. 사고가 A역(예: 메트릭 스파이크)에서 시작해 B, C, D역(페이지, Slack 채널, 팀 간 인계, 대시보드)들을 지나 최종적으로 Z역(해결 + 사후 회고 메모)에 도달하는 식입니다.

목표는 예쁜 그림이 아니라 구조가 한눈에 보이는 것입니다.

2. 의도적으로 연필과 종이만큼 단순하게 만들기

지도를 그리는데 특별한 툴이나 완벽한 다이어그램이 필요해지는 순간, 사람들은 그 작업을 더 이상 하지 않게 됩니다.

누구나, 빨리 스케치할 수 있도록 장애 아틀라스 프로세스를 설계하세요.

• 아주 기본적인 도형만 사용합니다.

  • 네모(□) = 시스템 / 서비스
  • 동그라미(○) = 사람 / 역할
  • 화살표(→) = 정보 또는 작업의 흐름
  • 번개(⚡) = 장애 지점 / 혼란이 있었던 순간

• 라벨은 표준화하고 최소한으로

  • "Alert fired" (알람 발생)
  • "On-call acknowledged" (온콜이 확인)
  • "Escalated to X" (X로 에스컬레이션)
  • "Waited for Y approval" (Y 승인 대기)
  • "Customer updated" (고객 공지 발송)

• 툴에 중립적으로: 종이 노트, 화이트보드, 간단한 드로잉 앱 등 무엇을 쓰든, 표현 언어는 동일하게 유지합니다.

저해상도(low fidelity)는 단점이 아니라 장점입니다. 다이어그램이 빠르고 비공식적일수록 사람들은:

• 사고가 아직 생생할 때 바로 기록하고
• ‘완벽하게 해야 한다’는 압박을 덜 느끼고
• 본인이 헷갈렸던 지점이나 모호했던 부분에 대해 더 솔직해집니다.

단 하나의 기준만 두세요: 사고에 관여했다면, 10–15분 안에 그 사고의 경로를 스케치할 수 있어야 한다.

3. 장애를 ‘범인 찾기’가 아닌 ‘종이 흔적’ 만들기로 보기

전통적인 postmortem(사후 분석)은 종종 수사처럼 느껴집니다. 누가 무엇을 했는지, 누가 무엇을 놓쳤는지, 누구의 잘못인지 따지는 식이죠.

연필로 그리는 장애 아틀라스에서는 관점을 바꿉니다. 모든 장애는 풍부한 종이 흔적(paper trail)을 남길 기회라고 보는 것입니다. 그 흔적에는 다음이 포함됩니다.

• 인계 과정: 누가, 언제, 누구에게 일을 넘겼는가
• 의사결정: 무엇을 선택했고, 무엇을 포기했는가
• 컨텍스트: 당시 사람들이 무엇을 믿고 있었는가

"누가 이걸 망쳤나?" 대신 이렇게 물어보세요.

• "이 사고는 다음에 어디로 이동했는가?"
• "각 단계에서 사람들은 무엇을 보고 있었나?"
• "그들이 가지고 있다고 믿은 옵션은 무엇이었나?"

지도에는 다음이 드러나야 합니다.

• 의사결정 지점 – 다이아몬드 모양이나 메모로 표시 (예: "롤백 vs 대기?", "DB 팀 호출할까?")
• 지식의 공백 – 누군가가 가시성이나 이해가 부족했던 지점 (예: "서비스 A가 서비스 B에 의존하는 줄 몰랐음")
• 헛돌았던 루프 – "X를 시도했지만 효과 없어 되돌리고, Y를 시도함" 같은 재작업 구간

이건 책임 추궁이 아니라, 사고가 당신의 사회-기술(socio-technical) 시스템을 어떻게 통과했는지를 재구성하는 작업입니다.

4. 숫자 신호와 사람 이야기를 함께 얹기

데이터만으로 구성된 타임라인은 실제 사고가 어떻게 전개되는지를 충분히 담지 못합니다.

장애 아틀라스에는 반드시 다음 두 가지를 섞어서 담아야 합니다.

정량 데이터(Quantitative data)

• 로그
• 메트릭(지연 시간, 에러율, 리소스 사용률 등)
• 트레이스(분산 트레이싱 정보)
• 알람 발생·승인 타임라인

정성 입력(Qualitative input)

• 온콜 담당자의 내러티브: "제가 본 건 이렇습니다", "그래서 이런 액션을 택했습니다"
• Slack/Teams 대화 중 혼란이나 정렬이 드러나는 부분
• 전문가의 직관: "지난 분기 장애 때문에 로드 밸런서를 먼저 의심했습니다"

지도 위의 노드와 화살표에 둘 다를 주석으로 다는 식입니다.

• "14:05 – Error rate > 5%" (메트릭)
• "Ops 엔지니어: ‘지난주 캐시 이슈 같아 보임’" (사람의 해석)

이 이중 시점이 강력한 이유는:

• 메트릭은 무엇이, 언제 일어났는지를 보여주고
• 이야기는 사람들이 왜 그런 행동을 했는지를 알려주기 때문입니다.

아틀라스의 역할은 이 두 관점을 서로 맞춰보는 것입니다.

5. 사후 문서를 ‘지도 중심’으로 표준화하기

대부분의 조직은 이미 어떤 형태로든 incident postmortem 문서를 가지고 있습니다. 아틀라스는 그것을 대체하는 게 아니라, 그 문서의 중심(anchor) 역할을 합니다.

항상 다음을 포함하는 가볍고 표준화된 템플릿을 만드세요.

1. 지도(Map)

   • 손으로 그린 흐름도를 사진·이미지로 캡처하거나, 디지털 스케치라면 그 스냅샷.

2. 복수의 Root Cause(근본 원인들)

   • 기술적 기여 요인 (예: 설정 드리프트, 처리하지 않은 엣지 케이스)
   • 조직적 기여 요인 (예: 불명확한 오너십, 느린 에스컬레이션 경로)

3. 핵심 인사이트(Key Lessons)

   • 무엇이 가장 의외였는가?
   • 시스템에 대해 가지고 있던 정신 모델 중 무엇을 업데이트해야 하는가?

4. 예방·개선 액션

   • 단기적인 조치
   • 장기적인 투자 항목

5. 커뮤니케이션 리뷰

   • 누가 언제 무엇을 알았어야 했는지, 실제로 그렇게 되었는지

기준은 간단합니다. 누군가 이 지도의 이미지와 한 페이지짜리 요약만 읽어도, 무슨 일이 있었고 무엇을 배웠으며 앞으로 무엇을 할지 이해할 수 있어야 한다는 것입니다.

이 문서들을 Confluence, Notion, Git 저장소 등 검색 가능한 공용 공간에 저장하고, 서비스·팀·주제(예: "alerting", "deploy", "dependencies") 기준으로 태깅하세요.

시간이 지나면 이것이 바로 당신만의 Outage Atlas 라이브러리가 됩니다.

6. 사람 네트워크 그리기: 이해관계자와 커뮤니케이션 흐름

기술적 사고는 곧 커뮤니케이션 사고이기도 합니다.

장애 지도에는 다음을 명시적으로 포함해야 합니다.

• 누가 통보를 받았는지 – 온콜만? 팀 리드? 고객지원? 경영진?
• 어떻게 통보되었는지 – Slack 채널, 이메일, 상태 페이지, incident 관리 툴 등
• 언제 통보되었는지 – 초기에? 너무 늦게? 아예 안 되었는지?

이해관계자는 동그라미나 그룹 단위로 표현하고, 정보 흐름을 화살표로 연결합니다.

• Engineering ↔ SRE
• Engineering → Customer Support
• SRE → Status Page
• Engineering → 외부 벤더

그리고 깨졌던 지점을 표시합니다.

• 점선 화살표: "원래는 알려야 했지만 실제로는 전달되지 않음"
• 번개(⚡): "혼란스럽거나 상충된 업데이트가 있었던 부분"

이렇게 하면 다음과 같은 패턴이 드러납니다.

• 고객지원팀이 고객 문의를 통해서야 장애를 처음 알게 되는 경우
• 프로덕트 매니저가 너무 늦게 참여해 고객 기대치를 조정하지 못하는 상황
• 여러 팀이 서로 다른 메시지를 경영진에게 보내는 상황

이제 이게 보이기 시작하면, 더 나은 커뮤니케이션 플레이북을 설계할 수 있습니다. 예를 들어:

• 외부 공지의 명확한 오너십 정의
• 예상되는 업데이트 타임라인
• 경영진 브리핑에 사용할 템플릿 등

7. 아틀라스를 온보딩·트레이닝의 비밀 병기로 만들기

대부분의 온보딩은 시스템이 어떻게 동작할 ‘예정’인지에 대해 설명합니다.

반면, 장애 아틀라스 라이브러리는 시스템이 스트레스 상황에서 실제로 어떻게 행동하는지를 보여줍니다.

이걸 적극적으로 활용하세요.

• 새로 합류한 사람에게: "당신이 속한 영역에서 실제로 있었던 장애 3건의 지도를 함께 훑어봅시다."
• 온콜 교육에서: "당신이 온콜이라고 가정합시다. 이 지도에서 첫 알람이 터진 시점부터 시작해보죠. 무엇을 확인하겠습니까? 무엇을 다르게 해볼 수 있겠습니까?"
• 팀 간 세션에서: "이 장애가 우리 팀들 사이를 몇 번씩 튕기고 있나요? 이 경로를 어떻게 단순화할 수 있을까요?"

그러다 보면 이런 패턴들이 보이기 시작합니다.

• 여러 번 장애를 일으킨 동일한 의존성
• 역할이 달라도 반복해서 등장하는 동일한 오해
• 다른 사고 지도에서도 반복되는 커뮤니케이션 병목

아틀라스는 사고가 조직을 처음부터 끝까지 어떻게 관통하는지를 보여주는 살아 있는 커리큘럼이 됩니다. 정적인 아키텍처 다이어그램보다 훨씬 구체적입니다.

8. 문화로 안착시키는 가벼운 의식 만들기

연필로 그리는 장애 아틀라스를 조직 문화에 녹이려면, 작고 반복 가능하게 만들어야 합니다.

• 트리거: 최소 기준 이상인 모든 사고에 대해 지도를 그립니다. (예: 누군가를 실제로 깨운 페이지, 혹은 사용자 체감 영향이 있었던 경우)
• 오너: 1차 대응 담당자가 24시간 이내에 러프 스케치를 시작합니다.
• 정교화: post-incident 리뷰에서 모두 함께 지도를 보며 수정·보완합니다.
• 보관: 최종 지도와 짧은 요약을 라이브러리에 저장합니다.

이 과정을 반복하면:

• 시스템·팀 간 숨겨진 의존성이 드러나고
• 조직도에서는 보이지 않던 프로세스 마찰이 보이기 시작하며
• 기술 설계뿐 아니라 사람 사이의 협업 방식도 개선됩니다.

그것도 새로운 툴 하나 사지 않고 말이죠.

결론: 최적화보다 먼저, 일단 ‘그려라’

장애는 코드나 인프라의 실패만이 아닙니다. 당신 조직 전체를 통과하는 하나의 여정입니다. 작은 사고가 조직을 어떻게 이동하는지 손으로 지도화하면 다음을 얻을 수 있습니다.

• 눈에 보이지 않던 의존성을 시각화하고
• 스트레스 상황을 장기적인 학습 자산으로 바꾸고
• 단순히 uptime만이 아니라, 협업·커뮤니케이션·온보딩까지 함께 개선할 수 있습니다.

연필로 그리는 장애 아틀라스는 의도적으로 로우테크입니다. 단순한 도형, 빠른 스케치, 사람의 이야기와 하드 데이터의 결합. 이게 힘을 가지는 이유는 폼(finish)이 아니라, 솔직함과 반복입니다.

다음 장애가 발생하면—크든 작든—고치고 바로 잊지 마세요. 연필을 집어 들고, 그 사고가 어디를 어떻게 지나갔는지 그려보세요. 그 지도야말로, 위기 상황에서 당신 조직이 실제로 어떻게 작동하는지 보여주는 가장 정확한 그림입니다.