소개: 프로덕션이 한밤중 폭풍우 치는 바다처럼 느껴질 때

새벽 3시에 인시던트 콜을 받아본 적 있다면 그 느낌을 알 것이다. 대시는 환하게 빛나고, 슬랙 알림은 끊이질 않고, 사람들은 서로 말이 엇갈리며, 논리적 추론보다는 ‘찍는’ 느낌이 점점 커진다. 시스템이 겨우 안정되고 나면 모두 녹초가 되고, 사후 리뷰는—한다면야 하겠지만—대충, 즉흥적으로, 그리고 금방 잊혀지곤 한다.

아날로그 인시던트 스토리 라이트하우스 맵(Analog Incident Story Lighthouse Map) 은 이 이야기를 바꾸기 위한 시도다.

이것은 인시던트 분석을 위한 의도적으로 아날로그이고 시각적인 프레임워크다. 팀이 혼란스러운 프로덕션의 밤을 지나갈 때, 손으로 그리는 ‘지도’ 형태로 안전한 경로를 함께 그려 나가도록 돕는다. 인시던트 원형 패턴(archetype)과 위협/취약점 추적 매트릭스를 활용해 실패 모드를 체계적으로 예상하고 이해하게 만들고, 기술적 시그널과 사람의 의사결정을 연결해 준다. 시간이 지나면, 이 맵은 조직이 문제로부터 어떻게 학습하는지를 공유된 정신 모델로 만들어 준다.

이 글에서는 라이트하우스 맵이 무엇인지, 어떻게 작동하는지, 그리고 어떻게 사람을 태우지 않으면서 지속 가능한 온콜을 뒷받침할 수 있는지 살펴본다.

단발성 소방 훈련에서 규율 있는 실천으로

대부분의 팀은 인시던트 리뷰를 단기적인 속죄 의식처럼 대한다. 큰 장애가 난 다음 이해관계자를 달래기 위해 ‘한 번 하는’ 행사에 가깝다. 결과는 대개 비슷하다.

• 리뷰마다 형식과 내용이 제각각이다.
• 배운 교훈은 축적되지 않고 증발한다.
• 암묵지(implicit knowledge)는 소수의 머릿속에만 남는다.
• 온콜은 설계된 운영이 아니라, 영웅적인 희생으로 느껴진다.

라이트하우스 맵은 인시던트 리뷰를 규율 있고 반복 가능한 실천(practice) 으로 재구성한다. 매번 즉흥적으로 하지 않고, 다음과 같은 요소가 담긴 시각적 템플릿에 기반해 진행한다.

• 리뷰 원칙 정의: 비난 금지, 호기심, 시스템적 관점 등
• 평가 기준 정리: 시그널 품질, 의사결정 맥락, 취약점 노출, 대응 조율 수준 등
• 모든 리뷰가 반드시 거치는 학습 체크포인트 내장

과정을 눈에 보이게 하고 예측 가능하게 만들면, 스트레스 높은 상황에서의 인지 부담이 줄어든다. 동시에, 리뷰가 매번 ‘초기화’되는 것이 아니라 계속해서 개선되는 방향으로 진화하게 된다.

‘라이트하우스 맵’이란 무엇인가?

라이트하우스 맵은 인시던트 중이거나 이후에 채워 가는 커다란 아날로그 캔버스라고 생각하면 된다. 새로운 도구라기보다, 대화와 주의를 구조화하는 새로운 방식에 가깝다.

일반적인 맵에는 다음과 같은 영역이 포함된다.

1. 인시던트 스토리라인(Incident Storyline)
   어떤 일이 벌어졌는지 시간 순으로 정리한다. 알림(alert), 관찰(observation), 의사결정, 액션, 그리고 그 결과까지. 이 타임라인이 전체 서사의 척추 역할을 한다.

2. 인시던트 아키타입 패널(Incident Archetype Panel)
   자주 반복되는 인시던트 패턴의 작은 라이브러리를 둔다. 예를 들면:

   • 설정(config) 드리프트
   • 용량(capacity) 고갈
   • 의존성(dependency) 장애
   • 잘못된 롤아웃 / 변경 실패
   • 드물게 나타나는 조건에 의해 활성화된 잠복 버그

   스토리를 이 아키타입 중 하나 이상과 연결해 태깅한다. 시간이 지날수록, 반복 패턴을 더 이르게 인지할 수 있게 된다.

3. 위협/취약점 추적 매트릭스(Threat/Vulnerability Traceability Matrix)
   다음을 서로 연결하는 구조화된 그리드다.

   • 위협(Threats): 무엇이 잘못될(또는 실제 잘못된) 수 있었는가
   • 취약점(Vulnerabilities): 시스템이나 프로세스가 어디에 노출되어 있었는가
   • 통제/완화책(Controls / Mitigations): 현재 존재하는 것, 부족한 것, 계획 중인 것

   예를 들면:

   • 위협: 캐시 클러스터 노드 손실
   • 취약점: 자동 페일오버 테스트 부재; 수동 복구 절차 문서화 안 됨
   • 통제: 분기별 페일오버 게임데이 추가; 런북(runbook) 작성; 알림 강화

4. 휴먼 팩터 & 코디네이션 영역(Human Factors & Coordination Area)
   다음 내용을 기록하는 공간이다.

   • 누가 언제 페이지를 받았는가
   • 정보가 어떻게 (혹은 어떻게 제대로) 흐르지 않았는가
   • 사람·팀 간 핸드오프(handoff)는 어떻게 이루어졌는가
   • 주요 의사결정 지점과, 그때 사람들이 갖고 있던 맥락은 무엇이었는가

5. 학습 체크포인트(Learning Checkpoints)
   반드시 짚고 넘어가는 핵심 질문들이다.

   • 우리를 가장 놀라게 한 것은 무엇이었는가?
   • 어디에서 눈이 멀어 있었는가? 무엇을 당연하게 가정했는가?
   • 언제 막혔고, 왜 그랬는가?
   • 어떤 것이 혼란이나 압박을 줄이는 데 도움이 되었는가?

세션이 끝나면 이 맵은 기술적 조건과 인간 경험이 긴밀히 연결된, 하나의 인시던트를 담은 밀도 높은 시각적 스토리로 남는다.

암묵지를 눈에 보이는 공유 지식으로 만들기

숙련된 온콜 엔지니어들은 엄청난 양의 암묵지(tacit knowledge) 를 축적한다.

• “이 알림은 시끄럽긴 한데, 정말 크리티컬한 경우는 거의 없어.”
• “이 서비스가 느려지면, 저 의존성부터 먼저 봐야 해.”
• “알리스가 온콜이면, 숨겨진 디버그 플래그를 어느 시점에 뒤집어야 할지 알고 있어.”

이 지식은 보물과 같다. 동시에 매우 깨지기 쉬운 자산이기도 하다. 팀을 옮기거나, 회사를 떠나거나, 단순히 번아웃이 오면 쉽게 사라진다.

라이트하우스 맵의 아날로그·협업적 특성은 이런 지식을 머릿속에서 꺼내 종이 위로 옮겨 적도록 설계되어 있다.

• 매핑 세션 동안 퍼실리테이터는 적극적으로 묻는다. “어떻게 그걸 해야겠다고 알았나요?”, “무엇이 이 알림을 중요해 보이게 했나요?”
• 그 대답을 타임라인과 매트릭스 옆에 바로 적어 넣는다.
• 시간이 지나면, 공통된 휴리스틱, 요령, 정신 모델이 명시적인 아티팩트로 드러난다.

그 결과는 하나의 공유 항해 지도다. 새 팀원들은 어떤 버튼을 눌렀는지만 보는 것이 아니라, 숙련된 대응자가 어떻게 생각하는지까지 볼 수 있다. 인시던트 대응은 더 이상 ‘신비한 내공’이 아니라 가르칠 수 있는 기술이 된다.

기술적 시그널과 인간 요소를 연결하기

전통적인 포스트모템(post‑mortem)은 종종 가장 좁은 의미의 ‘루트코즈(root cause)’에 집착한다. 특정 버그, 잘못된 배포, 빠진 인덱스 같은 것들이다. 라이트하우스 맵은 기술적 조건과 인간 요소를 모두 포함하는 전체론적(hollistic) 관점을 요구함으로써 이 한계를 보완한다.

• 기술적 조건: 어떤 알림이 발동(또는 발동하지) 되었는지, 시스템 상태, 인프라 헬스, 존재하던 취약점 등
• 인간 요소: 압박 속에서의 의사결정, 커뮤니케이션 패턴, 역할의 명확성, 피로도, 모호성 등

이 두 가지 차원을 나란히 둠으로써, 다음과 같은 질문을 자연스럽게 던지게 된다.

• 왜 이 알림은 무시되었는가? 단순 노이즈 피로(noise fatigue)였는가, 심각도가 애매했는가, 모니터링 시스템에 대한 신뢰 문제였는가?
• 왜 온콜 엔지니어는 페일오버 대신 롤백을 택했는가? 그 순간 그들이 가진 정보는 무엇이었는가?
• 타임존이나 팀 간 핸드오프는 진행을 도왔는가, 방해했는가?

이렇게 하면 비난을 피하고 상황 이해(situational understanding) 로 나아가게 된다. 목표는 누가 “실수했는지”를 찾는 것이 아니라, 합리적인 사람들이 합리적인 결정을 내렸음에도 불구하고 어떻게 문제가 발생했는지를 이해하는 것이다.

아키타입과 추적성을 활용해 실패 모드 예측하기

라이트하우스 맵의 강력한 점 중 하나는 인시던트 아키타입과 위협/취약점 추적 매트릭스를 활용해 떠오르고 있는 리스크를 눈에 보이게 만든다는 것이다.

인시던트 아키타입(Incident Archetypes)

각 인시던트를 하나 이상의 아키타입으로 태깅하면 다음과 같은 일을 할 수 있다.

• 우리 조직에서 어떤 카테고리가 특히 많이 발생하는지 파악한다. (예: ‘변경 관리(Change Management)’ vs ‘용량(Capacity)’ vs ‘의존성(Dependencies)’)
• 조기 경고를 포착한다. “이 알림 시퀀스는 전형적인 우리 ‘의존성 장애 패턴’이랑 똑같은데?”
• 가장 흔한 아키타입을 대상으로 하는 사전 예방적 실험을 설계한다.

위협/취약점 추적 매트릭스(Threat/Vulnerability Traceability Matrix)

이 매트릭스는 모든 인시던트를 동일한 규율 있는 렌즈로 바라보게 해 준다.

• 발생한 각 위협에 대해 묻는다. 이 위협을 가능하게 만든 취약점은 무엇이었나?
• 각 취약점에 대해 묻는다. 이미 존재하는 통제는 무엇이며, 그 효과는 어느 정도인가?
• 이를 시간에 따라 추적해, 실제로 완화 조치가 노출도를 줄이고 있는지 볼 수 있다.

이 과정을 통해 단순히 사건이 터질 때마다 땜질하는 수준에서 벗어나, 체계적인 리스크 감소로 이동한다. 이 맵은 조직이 알고 있는 ‘용(dragon)’ 목록과, 그 용을 어떻게 길들이고 있는지를 보여 주는 살아 있는 인벤토리가 된다.

라이트하우스 맵으로 지속 가능한 온콜 설계하기

사람들이 만성적으로 과부하 상태라면, 안정적인 시스템 운영은 불가능하다. 라이트하우스 맵은 인시던트 학습을 지속 가능한 온콜 설계와 명시적으로 연결한다.

각 리뷰 세션은 다음을 반드시 묻는다.

• 알림(Alerts)

  • 알림은 적시에, 행동 가능하게, 그리고 명확하게 전달되었는가?
  • 어떤 알림이 노이즈나 혼란을 만들었는가?
  • 피로도를 줄이기 위해(집계, 억제, 라우팅 개선 등) 무엇을 바꾸어야 하는가?

• 로테이션(Rotations)

  • 로테이션의 깊이와 커버리지는 적절했는가?
  • 타임존이나 핸드오프 패턴은 대응에 도움이 되었는가, 해가 되었는가?
  • 소수의 사람에게 과도한 인지 부담이 집중되어 있지는 않은가?

• 런북 & 플레이북(Runbooks & Playbooks)

  • 문서가 없거나 신뢰받지 못해, 어디에서 대응자가 즉흥적으로 대응했는가?
  • 어떤 런북은 실제로 도움이 되었으며, 그 이유는 무엇인가?
  • 이 밤을 훨씬 덜 스트레스풀하게 만들 수 있었던, 작지만 중요했던 문서 업데이트는 무엇이었는가?

이 질문들이 템플릿 안에 이미 내장되어 있기 때문에, 빼먹을 수가 없다. 그 결과는 더 탄탄한 시스템뿐 아니라, 영웅적인 희생에 의존하지 않아도 되는, 보다 인간적인 온콜 환경이다.

지속적인 학습 문화를 만드는 법

라이트하우스 맵을 한 번 쓰는 것만으로도 도움은 된다. 하지만 지속적으로 사용할 때 비로소 변혁적 효과가 나타난다.

인시던트 하나하나가 맵으로 기록되면:

• 시스템과 팀이 어떻게 진화해 왔는지 보여주는 맵 라이브러리가 쌓인다.
• 반복되는 취약점, 커뮤니케이션 상의 단골 문제 지점, 가장 많은 고통을 야기하는 아키타입들이 눈에 띄게 드러난다.
• 실제 인시던트 중에 초기 시그널을 인지하는 능력이 향상된다. 벽에 걸린 과거 맵에서 비슷한 이야기가 어떻게 전개되었는지 이미 여러 번 봤기 때문이다.

시간이 지나면 라이트하우스 맵은 단순한 도구를 넘어 하나의 의식(ritual) 이 된다.

• 구성원들은 의미 있는 인시던트라면 반드시 맵으로 그려질 것이라고 기대한다.
• 엔지니어들은 자신의 경험이 단순한 ‘무용담’으로 끝나지 않고, 조직의 지식으로 축적된다는 것을 안다.
• 리더들은 인시던트가 기술 로드맵과 팀의 운영 방식에 어떤 영향을 주는지 추적할 수 있는 명확한 수단을 얻는다.

이것이 바로 지속적인 학습 문화(continuous‑learning culture) 가 실제로 구현된 모습이다. 각 인시던트가 시스템뿐 아니라, 사람들의 사고, 의사결정, 협업 방식을 함께 강화한다.

나만의 라이트하우스 맵 시작하기

거창한 도구가 필요 없다. 아날로그로, 작게 시작하자.

1. 큰 종이 한 장 또는 화이트보드를 준비한다.
   위에서 설명한 섹션들—스토리라인, 아키타입, 위협/취약점 매트릭스, 휴먼 팩터, 학습 체크포인트—으로 나누어 그려 둔다.

2. 최근에 있었던 의미 있는 인시던트를 하나 고른다.
   대응에 참여했던 모든 사람을 초대한다. 고객 지원, 프로덕트, 운영 등도 포함한다.

3. 함께 이야기를 처음부터 끝까지 짚어 나간다.
   타임라인을 그리고, 의사결정 지점을 표시하고, 아키타입을 태깅하고, 매트릭스를 채운다.

4. 각 학습 체크포인트에서 잠시 멈춘다.
   놀랐던 점, 확신이 없었던 부분, 정서적 부담까지도 명시적으로 적어 둔다.

5. 통찰을 실행으로 옮긴다.
   세 가지 축—시스템, 온콜 설계, 커뮤니케이션 방식—에서의 개선 항목을 짧은 리스트로 뽑는다.

몇 번 반복하다 보면, 이 아날로그 실천은 단순한 회의가 아닌 집단 항해처럼 느껴질 것이다. 팀이 등대 지도(lighthouse chart) 주변에 모여, 새로운 지식을 업데이트하고, 다음 번 거친 바다 항해가 조금이라도 더 안전해지도록 준비하는 시간 말이다.

결론: 혼돈 속에서 안전한 항로를 그리기

혼란스러운 프로덕션의 밤은 사라지지 않을 것이다. 시스템은 더 복잡해지고, 의존성은 더 얽히며, 기대치는 더 높아진다. 우리가 바꿀 수 있는 것은 조직이 어떻게 대응하고, 어떻게 학습하는가다.

아날로그 인시던트 스토리 라이트하우스 맵은 다음을 가능하게 한다.

• 실패 모드를 체계적으로 예상하고 이해하기
• 인시던트에서 나온 암묵지를 명시적으로 만들고, 공유 가능하게 만들기
• 기술적 조건과 인간 요소를 하나의 이야기로 연결하기
• 시스템과 사람을 동시에 보호하는, 지속 가능한 온콜을 설계하기
• 각 인시던트를 ‘그냥 버텨야 하는 위기’가 아니라 ‘학습의 기회’로 만드는 문화 만들기

대시보드와 자동화가 넘쳐나는 세상에서, 마커를 집어 들고 인시던트 스토리를 손으로 그려 보는 일은 의외로 큰 안정감을 준다. 이 맵이 폭풍을 없애 주지는 못한다. 하지만, 팀이 함께 볼 수 있는 공통의 차트와 등대를 제공해 준다. 그렇게 해서 우리는 오늘 밤의 혼란뿐 아니라, 그 다음 밤의 혼란까지도 조금씩 더 안전하게 항해해 나갈 수 있다.