아날로그 인시던트 스토리 등대 정원: 가장 위험한 기능 주변에 종이 경고 비콘 심기

모던 시스템은 모던한 방식으로 망가집니다. 구조는 복잡하고, 분산되어 있고, 노이즈는 많고, 종종 새벽 3시에 캐시, 피처 플래그, 결제 API가 왜 한꺼번에 파업했는지 아무도 이해하지 못하는 상태에서 터집니다.

우리는 대시보드, 알림, 자동 분석으로 대응합니다. 그런데도 팀은 제대로만 공유되었다면 충분히 예측할 수 있었던 인시던트에 계속해서 놀랍니다. 그때 그 사람이, 그때 그 이야기를, 그때 그 자리에만 있었다면 말이죠.

여기서 아날로그 인시던트 스토리 등대 정원(Analog Incident Story Lighthouse Garden) 이 등장합니다.

의도적으로 로우테크이고, 눈에 잘 띄는 방법으로:

가장 위험한 기능과 컴포넌트를 드러내고
실제 인시던트 스토리를 사람의 언어로 기록하며
그 스토리를 팀이 매일 지나가며 보게 되는 “종이 경고 비콘”으로 바꾸고
느낌(hunch)이 아니라 위험도(risk) 를 기준으로 신뢰성 작업을 이끌어냅니다.

신뢰성을 위한 정원을 가꾸는 것이라고 생각해도 좋습니다. 위험한 곳에는 경고 표지판을 심고, 그 표지판을 계속 가꾸다 보면 시스템은 점점 더 안전하게 탐험할 수 있는 공간이 됩니다.

왜 신뢰성 리스크에는 더 나은 스토리텔링이 필요한가

복잡성이 직관을 앞질렀다

오늘날 시스템은:

고도로 분산되어 있고 (마이크로서비스, 함수형 서비스, 큐, 서드파티 API)
동적으로 스케일링되고 (오토스케일링, 서버리스, 멀티 리전)
항상 변화합니다 (잦은 배포, 설정 변경, 피처 플래그)

그래서 신뢰성 리스크는 더 이상 눈에 띄지 않습니다. 장애는 종종 이런 식으로 나타납니다.

평범해 보이는 코드 변경이 obscure한 설정과 이상하게 상호작용할 때
서드파티 의존성이 이상한 부분 장애(partial failure) 상태로 망가질 때
아무도 예상하지 못한 엣지 케이스 워크로드가 시스템을 치고 지나갈 때

“여기가 왠지 위험해 보인다”는 전통적인 직관만으로는 부족합니다. 팀은 숨겨진 리스크를 눈에 보이게 만들고, 오래 남게 하는 방법이 필요합니다.

SRE: 신뢰성을 전체 시스템의 속성으로 보기

Site Reliability Engineering(SRE)은 신뢰성을 단순한 업타임 이상의 것으로 재정의합니다.

고객 경험: 사용자가 깨진 페이지, 느린 응답, 일관성 없는 동작을 보게 되는가?
만족도와 신뢰: 사용자가 필요할 때 우리 제품이 “당연히 잘 동작할 것”이라 믿는가?
스트레스 상황에서의 유지보수성: 배포 직후, 트래픽 피크 때, 클라우드 일부 장애 상황에서 팀이 시스템을 이해하고, 디버그하고, 복구할 수 있는가?

신뢰성은 Ops 팀만의 문제가 아닙니다. 제품과 엔지니어링 전반의 품질 문제입니다. 그리고 어떤 품질 문제든, 팀이 무엇을 볼 수 있고, 기억하고, 우선순위에 올려두는가에 달려 있습니다.

인시던트에서 등대로: 핵심 아이디어

등대(lighthouse) 는 배가 위험한 해안을 피하도록 경고합니다. 인시던트 스토리 등대는 엔지니어가 위험한 변경이나 블라인드 스팟을 피하도록 경고합니다.

아날로그 인시던트 스토리 등대 정원이란:

가장 위험한 기능과 실제 인시던트를 종이에 한눈에 보이게 기록해, 팀이 물리적으로 외면할 수 없도록 작업 공간 곳곳에 붙여 놓은 “경고 비콘” 모음입니다.

이 비콘들은:

관련 시스템을 소유한 팀 근처에 붙어 있고
과거 실패를 단순 숫자가 아닌 이야기(story) 형태로 담고 있으며
리스크 카테고리(발생 가능성 × 영향도)를 강조하고
구체적인 액션과 오너십을 제안합니다.

일부러 아날로그로 만드는 데에는 이유가 있습니다. 디지털 도구는 강력하지만 동시에:

탭, 필터, 권한 뒤에 숨기 쉽고
배포에 쫓길 때는 쉽게 잊히고
“누군가의 문제겠지”라고 치부하기 쉽습니다.

반면 벽에 붙은 종이는, 시야 안에 있으면 무시하기 어렵습니다.

1단계: 신뢰성 리스크 지형도 그리기

등대를 심기 전에, 먼저 어디에 암초가 있는지 알아야 합니다.

간단한 리스크 매트릭스: 가능성 × 영향도

주요 기능과 컴포넌트에 대해 다음 두 가지 관점으로 점수를 매깁니다.

발생 가능성(Likelihood): 이 영역에서 문제가 얼마나 자주 발생하는가?
영향도(Impact): 문제가 났을 때 사용자와 비즈니스에 어떤 일이 벌어지는가?

각 항목을 1~5 점으로 매긴 뒤, 이렇게 분류할 수 있습니다.

크리티컬 리스크: 발생 가능성 높음, 영향도 높음
잠자는 거인(Sleeping giant): 발생 가능성 낮음, 영향도 높음
귀찮은 영역(Annoyance): 발생 가능성 높음, 영향도 낮음
백그라운드 노이즈: 발생 가능성 낮음, 영향도 낮음

우선 크리티컬 리스크와 잠자는 거인에 집중합니다. 여기가 바로 첫 등대를 심을 자리입니다.

신뢰성 메트릭 데이터 끌어오기

신뢰성 메트릭은 시스템 건강 상태를 보는 현미경입니다. 다음을 포함해야 합니다.

장애 및 서비스 중단
가용성 & 업타임
에러율 (4xx, 5xx, 타임아웃)
응답 시간 & 꼬리 지연(tail latency)
포화 상태(saturation: CPU, 메모리, 동시성, 큐 길이 등)

전체 IT 영역(IT estate) 을 폭넓게 봅니다. 인프라 와 애플리케이션 모두 포함하고, 다양한 기간을 살펴보세요.

지난 1주일 (단기적인 불안정성)
지난 분기 (추세와 패턴)
지난 1년 (드물지만 치명적인 사건)

이 데이터로 팀의 감을 교차 검증합니다. 어디가 자주 고장 나고, 어디가 드물지만 터지면 재앙이고, 어디가 상대적으로 안전한지 분명해질 것입니다.

2단계: 가장 위험한 기능 주변에 “종이 경고 비콘” 심기

이제 리스크를 눈에 보이는 사람의 이야기로 바꿉니다.

비콘에 무엇을 넣을 것인가?

각 위험한 기능이나 컴포넌트마다 1페이지짜리 인시던트 스토리를 종이로 만듭니다. 다음 내용을 포함하세요.

기능/컴포넌트 이름
예: “Checkout Payment Orchestrator”, “Notification Fanout Service”
리스크 카테고리
예: “Critical Risk: 발생 가능성 높음, 영향도 높음”
최근 또는 대표적인 인시던트 스토리
- 언제 발생했는지
- 사용자가 무엇을 봤는지
- 기술적 근본 원인(쉽게 풀어쓴 언어로)
- 어떻게 탐지되었는지(혹은 탐지되지 않았는지)
임팩트 스냅샷
- 영향을 받은 사용자 비율 또는 세그먼트
- 지속 시간
- 비즈니스 영향(매출 손실, SLA 위반, 평판 손상 등)
시그널 및 메트릭
- 관련 SLO/SLI (예: p99 latency < 500ms)
- 변동이 컸던 주요 메트릭 (에러율, 지연, 포화 등)
알려진 트리거 & 취약 지점
- “캐시 워밍 없이 배포하면 5xx가 스파이크로 튄다”
- “서드파티 장애 시 우회(graceful degradation) 경로가 실제로는 미검증 상태”
오너 & 다음 스텝
- 담당 팀/스쿼드 이름
- 계획 중이거나 필요한 구체적인 신뢰성 개선 한 가지 이상

이 내용을 보기 쉽게 정리해서 출력한 뒤, 일이 실제로 벌어지는 곳에 붙입니다.

해당 팀의 벽이나 화이트보드
배포 화면이나 칸반 보드 근처
여러 팀이 교차하는 공용 공간

사람이 이해할 수 있는 이야기로 만들기

짧은 내러티브 요소를 꼭 포함하세요.

“11월 세일 기간 동안 약 13분간 전체 사용자 중 18%가 결제 실패를 경험했습니다. 고객센터는 문의로 포화되었고, 엔지니어들은 오케스트레이터와 결제 프로바이더 사이 로그 상관관계를 잡는 데 큰 어려움을 겪었습니다. 근본 원인: 잘못 설정된 서킷 브레이커로 인한 재시도 폭풍(retry storm).”

이야기는 기억에 남습니다. 단순 그래프보다 훨씬 강하게 미래의 의사결정을 바꿔 줍니다.

3단계: 카오스와 Failure-as-a-Service로 정원을 키우기

등대 정원이 계속 유용하려면, 과거에만 반응해서는 안 됩니다. 새로운 위험을 발견해야 합니다.

카오스 엔지니어링을 탐사 도구로 쓰기

카오스 엔지니어링과 “failure-as-a-service” 플랫폼은 다음을 가능하게 합니다.

인프라와 애플리케이션에 의도적으로 장애를 주입하고
스트레스 상황에서 실제 시스템 동작을 관찰하며
우리가 믿고 있는 탄력성 가정(resilience assumptions) 을 검증합니다.

예시 실험:

정상 트래픽 중 핵심 서비스 인스턴스를 강제로 종료하기
주요 데이터베이스에 인위적인 지연(latency) 추가
서드파티 서비스 장애를 시뮬레이션하기
핵심 컴포넌트 사이 네트워크 트래픽 드랍하기

놀랍거나 우려스러운 결과가 나오면, 바로 새 비콘을 추가하거나 기존 비콘을 업데이트합니다.

우리는 무엇이 일어날 것이라 예상했는가?
실제로는 무엇이 일어났는가?
모니터링과 알림은 어디에서 우리를 배신했는가?
이 상황이 사용자 혹은 고객 입장에서는 어떻게 느껴졌을까?

이렇게 하면 등대 정원은 실험을 거듭할수록 진화하며, 이미 실패한 곳뿐 아니라, “크게 망가질 수도 있었던” 지점까지 드러나게 됩니다.

4단계: 메트릭을 장식이 아니라 행동으로 연결하기

아무도 보지 않고 쓰지 않는 등대는 그냥 해안가 인테리어에 불과합니다.

비콘을 구체적인 신뢰성 작업에 연결하기

각 비콘에 대해 최소 한 개 이상의 실행 가능한 액션 아이템을 정의합니다.

SLO와 알림을 추가하거나 강화하기
런북이나 온콜(On-call) 문서 개선하기
서킷 브레이커, 백프레셔, 더 나은 타임아웃 추가하기
우아한 장애 허용(graceful degradation) 또는 피처 킬 스위치 구현하기
취약한 상호작용/의존성 단순화하기

그리고 이것을 팀의 기존 플래닝 리추얼에 자연스럽게 녹입니다.

스프린트 플래닝 시, 비콘에서 바로 신뢰성 작업을 끌어와 티켓으로 만들기
인시던트 리뷰 후, 비콘을 업데이트하거나 새 비콘 심기
분기 계획 때, “이번 분기에 반드시 없애고 싶은(=해결하고 싶은) 등대” 상위 3~5개 고르기

행동 편향을 가진 메트릭 사용하기

메트릭은 보기 위한 것이 아니라, 결정하고 행동하기 위한 것이어야 합니다. 주요 기능/서비스마다 이렇게 물어보세요.

명확한 SLI와 SLO가 있는가?
알림은 사용자가 고통받기 전에 충분히 일찍 울리는가?
에러 버짓(error budget)을 정기적으로 리뷰하고, 소진 시 실제로 행동하는가?

어떤 메트릭이 있어도, 그것이 아무 결정도 바꾸지 못한다면 그 가치를 의심해야 합니다. 등대 정원에는 각 위험 영역마다 정말 중요한 소수의 메트릭만 강조해서 두어야 합니다.

5단계: 신뢰성을 개발자·팀 퍼포먼스와 정렬시키기

신뢰성은 엔지니어링 팀에게 점점 더 중요한 핵심 퍼포먼스 시그널이 되고 있습니다. 채찍이 아니라, 방향을 맞추기 위한 기준으로서 말이죠.

빠르게 배포하면서도 안정적인 기능을 내는가
실제 운영 환경을 고려해 유지보수성을 설계하는가
일관된 동작으로 고객의 신뢰를 쌓고 있는가

아날로그 등대는 여기에 기여합니다.

트레이드오프를 명시적으로 드러냅니다: “여기서는 속도를 택했고, 그 대가로 이 리스크를 안고 간다.”
높은 리스크 비콘을 줄이거나 없애는 팀을 인정하고 보상할 수 있게 합니다.
인시던트를 숨기기보다는 내부 투명성을 장려합니다.

다음과 같은 항목을 측정하고 축하하는 것을 고려해 보세요.

사전에 예방한 크리티컬 인시던트 (메트릭이나 카오스 테스트로 발견·차단한 사례)
“지루해진” 고위험 컴포넌트 (단순화 또는 하드닝으로 더 이상 뉴스거리가 안 되는 수준이 된 영역)
더 나은 스토리와 문서 덕분에 인시던트를 이해하는 데 걸리는 시간(time-to-understand) 이 개선된 정도

목표는 팀이 자신의 신뢰성 스토리를 스스로 소유하고, 데이터와 내러티브를 함께 들고 나올 수 있는 문화를 만드는 것입니다.

결론: 무덤이 아니라 정원을 가꾸자

모던 시스템의 신뢰성은 더 이상 직관만으로 관리할 수 없습니다. 복잡한 분산 아키텍처, 동적인 워크로드, 예측하기 어려운 상호작용 속에서는:

인시던트는 반드시 발생하고
우리는 거기서 반드시 배울 수 있으며
그 학습을 눈에 보이고, 행동으로 이어지게 만들어야 합니다.

아날로그 인시던트 스토리 등대 정원은 다음을 가능하게 하는, 놀랍도록 단순하지만 강력한 방법입니다.

보이지 않던 리스크를 물리적인 공유 지식으로 바꾸고
메트릭과 사람의 이야기를 결합하며
발생 가능성과 영향도를 기준으로 신뢰성 작업을 이끌고
엔지니어링 행동을 고객 경험과 비즈니스 연속성에 맞춰 정렬시킵니다.

작게 시작하세요.

당장 봐도 위험해 보이는 기능/서비스 3~5개를 고릅니다.
각각에 대해 1페이지짜리 인시던트 또는 리스크 스토리를 작성합니다.
그 팀이 일하는 공간의 벽에 붙입니다.
인시던트가 발생할 때마다, 혹은 카오스 실험을 한 뒤마다 업데이트합니다.

시간이 지날수록 이런 변화를 보게 될 것입니다.

예상치 못한 인시던트가 줄어들고
팀은 더 잘 준비된 상태로 장애를 맞이하며
신뢰성이 “나중에 생각할 것”이 아니라, 시스템을 설계하고, 만들고, 이야기하는 매 순간의 일부가 됩니다.