아날로그 인시던트 과수원 맵: 시스템의 모든 장애 패턴에 종이 나무 심기

현대 시스템은 보통 전혀 새로운 방식으로 망가지지 않습니다. 대부분은 어딘가 익숙하고, 반복되는 패턴으로 실패합니다. 문제는, 많은 팀이 그 패턴을 사건이 모두 끝난 뒤에야, 그것도 아픈 인시던트를 겪고 나서야 뒤늦게 알아챈다는 점입니다.

아날로그 인시던트 과수원 맵(Analog Incident Orchard Map) 은 이 상황을 바꾸기 위한 방법입니다. 시스템에서 반복해서 나타나는 장애 패턴을 지속적인 시각적 라이브러리로 만들어 두는 것입니다. 각 패턴은 과수원 안에 서 있는 하나의 “종이 나무(paper tree)” 가 되고, 여러분은 인시던트 전·중·후에 이 과수원을 걸어 다니며 참고할 수 있습니다.

이 글에서는 다음 내용을 다룹니다.

• 반복되는 장애 양상을 시스템 아키타입(Donella Meadows의 시스템 사고 개념)과 연결하는 법
• 그 아키타입을 여러분 스택의 구체적인 엔지니어링 사례와 엮는 법
• 각 “나무”를 실제 신뢰성 데이터(예: Analog Devices의 IC 고장률 등)로 뒷받침하는 법
• 이 과수원을 활용해 선제적인 회복탄력성(Resilience) 작업을 이끄는 법
• 인시던트 문서화를 이 패턴들 중심으로 표준화하는 법
• 인시던트가 발생할 때마다 과수원을 지속적으로 업데이트하고 가지치기(Pruning) 하는 법

러너북만으로는 부족한 이유: 인시던트 과수원이 필요한 이유

러너북(runbook)은 이런 질문에 답합니다.

“지금 당장 무엇을 해야 하지?”

인시던트 과수원은 한 단계 더 깊은 질문에 답합니다.

“이건 어떤 종류의 일이고, 우리가 예전에 어디서 본 적이 있는가?”

복잡한 시스템에서 발생하는 고심각도(Sev-High) 인시던트 대부분은 고유(unique)하지 않습니다. 대개는 소수의 구조적 패턴이 재조합(recombination) 되어 나타납니다.

• 과부하된 의존 서비스
• 걷잡을 수 없이 증폭되는 피드백 루프
• 눈에 띄지 않게 서서히 진행되는 드리프트
• 추상화 뒤에 숨은 단일 장애점(SPOF)

이런 것들을 이름이 붙은, 문서화된 패턴으로 잡아내고, 시각적으로 정리해 두면 다음과 같은 효과가 있습니다.

• 인시던트를 더 빨리 인지합니다.
  “이건 우리가 말하던 ‘Retry Storm(재시도 폭풍)’ 나무랑 비슷하다.”
• 매번 처음부터 해결책을 발명하지 않고, 이미 검증된 완화책과 해결책을 재사용합니다.
• 팀 간 커뮤니케이션이 빨라집니다.
  “지금은 ‘Shifting the Burden(부담 전가)’ 시나리오에 있어요.”
• 이미 알려진 함정에 대해 아키텍처를 체계적으로 단단히 만들 수 있습니다.

과수원은 과거 사고의 단순한 기록이 아니라, 이미 알려진 함정에 대한 지도입니다.

1단계: 반복되는 장애를 시스템 아키타입에 매핑하기

Donella Meadows를 비롯한 시스템 사고가들은 시스템 아키타입(system archetypes) 을 정리해 두었습니다. 이는 시스템이 왜 특정한 방식으로 반복적으로 행동하는지를 설명하는 구조적 패턴입니다. 대표적인 것들을 몇 가지 보겠습니다.

• “성장의 한계(Limits to Growth)” – 어떤 것이 개선되다가, 보이지 않던 제약에 부딪혀 더 이상 나아가지 못하는 패턴
• “부담 전가(Shifting the Burden)” – 근본 원인을 해결하는 대신 임시방편에 의존하면서, 오히려 근본 문제가 악화되는 패턴
• “성공에의 성공(Success to the Successful)” – 한 번 이긴 쪽이 더 많은 자원을 받아, 격차가 계속 벌어지는 패턴
• “공유지의 비극(Tragedy of the Commons)” – 여러 주체가 공유 자원을 과도하게 사용해 결국 모두에게 피해가 되는 패턴

이런 아키타입은 엔지니어링 시스템 안에서도 끊임없이 등장합니다.

예시 매핑

• Retry Storm → “에스컬레이션 / 강화 피드백(Escalation / Reinforcing Feedback)”
  다운스트림 서비스가 느려지면, 콜러들이 공격적으로 재시도합니다. 부하가 더 늘면서 서비스는 더 느려지고, 결국 완전히 무너집니다.

• Alert Fatigue(알림 피로) → “부담 전가(Shifting the Burden)”
  노이즈가 많은 시스템을 고치는 대신 알림을 더 추가하고, 온콜 인원만 늘립니다. 사람들은 번아웃 되고, 진짜 중요한 이슈를 놓치게 됩니다.

• Database Hotspot(데이터베이스 핫스팟) → “성장의 한계(Limits to Growth)”
  성능이 선형적으로 잘 스케일되는 것처럼 보이다가, 어느 순간 특정 파티션·인덱스·커넥션 풀의 한계에 도달하면서 전체가 느려집니다.

여러분이 할 일: 과거 인시던트를 돌아보며, 각 인시던트에 대해 겉으로 드러난 증상이 아니라 구조적인 특성을 가장 잘 설명하는 시스템 아키타입을 태깅해 보십시오.

시간이 지나면, 전체 인시던트의 70–80%가 소수의 아키타입 조합으로 반복되고 있다는 사실을 보게 될 것입니다. 이 반복 패턴들이 과수원의 첫 번째 나무들입니다.

2단계: 각 패턴을 “종이 나무(Paper Tree)”로 만들기

종이 나무는 여러분 시스템에서 특정 장애 패턴을 표현하는 구조화된 시각 카드입니다. 과수원 안에 존재하는 하나의 지속적인 “인시던트 종(species)”라고 생각하면 됩니다.

각 나무에는 다음 요소들이 포함되어야 합니다.

1. 이름과 아키타입

   • 예: “Northstar API Retry Storm (Reinforcing Feedback)”

2. 시스템 다이어그램(최소하지만 구체적으로)

   • 핵심 컴포넌트, 호출 관계, 큐, 피드백 루프 등이 들어간 작은 다이어그램

3. 전형적인 트리거 조건

   • “다운스트림 p95 레이턴시 2분 동안 700ms 초과”
   • “서비스 X의 커넥션 풀 포화 상태”

4. 관측 가능한 시그널

   • 이 패턴이 발생할 때 튀어 오르는 메트릭, 로그, 트레이스

5. 관련 인시던트 목록

   • 이 패턴이 나타났던 포스트모템 2–5건 링크

6. 사전 예방 통제 및 설계 전략

   • 서킷 브레이커, 백오프 전략, 용량 계획(capacity planning) 등

7. 테스트 및 시뮬레이션

   • 카오스 실험, 부하 테스트, 이 패턴을 직접 겨냥한 유닛/통합 테스트

8. 신뢰성 데이터 및 위험 수준

   • 발생 가능성과 영향도에 영향을 주는 실제 고장률(하드웨어, 소프트웨어, 네트워크 등)

이 나무들을 가볍지만 구조화된 형식으로 유지하면, 엔지니어들이 설계 리뷰 중이든, 실제 인시던트 대응 중이든 빠르게 훑어볼 수 있습니다.

3단계: 각 나무를 실제 신뢰성 데이터로 뒷받침하기

데이터가 없으면 위험은 추상적으로 느껴집니다. 각 나무 안에 신뢰성 예측 데이터(reliability prediction data) 를 녹여 넣으면 과수원은 훨씬 더 실행 가능해집니다.

활용할 수 있는 데이터 출처는 다음과 같습니다.

• IC 및 전자 부품 고장 데이터 (예: Analog Devices의 안전·신뢰성 노트 등)
• 자체 인프라에서 수집한 네트워크·하드웨어 인시던트 통계
• 클라우드 제공업체의 SLA 및 과거 장애 이력
• 릴리즈/버그 트래커에서 추출한 소프트웨어 결함률

예시: 전력 민감 서브시스템의 IC 고장률

특정 ADC(아날로그-디지털 컨버터)에 의존하는 엣지 디바이스를 운영하고 있다고 가정해 보겠습니다. 이 ADC의 신뢰성 데이터에 다음 정보가 적혀 있다고 합시다.

• 고장률: FIT = 50 (10억 디바이스-시간당 50건 고장)
• 주요 고장 모드: 고온에서의 래치업(latch-up), ESD(정전기 방전) 손상

여러분의 “Analog Input Drift & Dropout(아날로그 입력 드리프트 및 드롭아웃)” 나무에는 다음과 같은 내용이 들어갈 수 있습니다.

• 발생 가능성: 고온 환경 배포에서는 중간(Medium), 그 외 환경에서는 낮음(Low)
• 영향도: 센서 데이터 손실 → 제어 루프 불안정 → 비상 셧다운
• 통제 수단: 온도 디레이팅(derating), 측정값에 대한 워치독 체크, 이중화 센싱

정밀한 수치를 맞힐 필요는 없습니다. 중요한 것은 자릿수 수준(order-of-magnitude) 의 현실감을 제공하는 것입니다. 각 나무마다 다음 두 가지가 들어 있으면 충분합니다.

• 대략적인 발생 빈도 (주간 / 월간 / 연간 / 매우 희귀)
• 블라스트 반경(blast radius) 추정 (로컬 / 단일 서비스 / 리전 전체)

이렇게 되면 과수원은 과거 실패 사례 모음이 아니라 실질적인 리스크 레지스터(risk register) 로 기능하게 됩니다.

4단계: 과수원을 선제적 회복탄력성 작업의 나침반으로 쓰기

일단 첫 번째 나무들을 몇 그루 심었다면, 이 과수원을 구조적 회복탄력성 작업을 위한 백로그처럼 다루면 됩니다.

각 나무마다 다음 항목을 관리합니다.

• 사전 예방 통제(Preventive controls):

  • 예: Retry Storm에 대해: 지터를 섞은 지수 백오프, 서킷 브레이커, 동시성 제한, 부하 차단(load shedding).

• 탐지 향상(Detection improvements):

  • 해당 패턴을 겨냥한 새로운 SLO, 더 나은 알림, 헬스 체크

• 설계 가이드라인(Design guidelines):

  • “핫 패스에서는 시스템 X에 동기 호출 금지”
  • “리전 간 쓰기 연산은 모두 멱등(idempotent)해야 한다” 등

• 테스트 카탈로그(Test catalog):

  • 이 패턴을 의도적으로 유도하는 카오스 실험

이제 신뢰성 로드맵은 이런 식으로 표현할 수 있습니다.
“이번 분기에는 어떤 나무들을 단단하게 만들 것인가?”

예를 들면:

• 2분기(Q2): “성장의 한계(Limits to Growth)” 나무들(용량, 핫스팟)에 집중
• 3분기(Q3): “부담 전가(Shifting the Burden)” 나무들(알림, 수작업 운영, 기술 부채)에 집중

이렇게 하면 신뢰성 업무는 더 이상 “우연한 불 끄기(Fire‑fighting)”가 아니라, 체계적인 정원 가꾸기(Gardening) 로 바뀝니다.

5단계: 인시던트 문서를 과수원 패턴 중심으로 표준화하기

실제 인시던트 중에는, 대응자들이 가능한 한 빨리 이런 질문에 답할 수 있어야 합니다.

“지금 우리는 어느 나무 아래에 있는가?”

이를 가능하게 만들려면, 인시던트 및 포스트모템 템플릿을 과수원을 기준으로 표준화해야 합니다.

1. 패턴 분류 필드

   • 필수 항목으로, 인시던트마다 하나의 아키타입과 기존 나무를 선택하게 하거나, “새로운 후보 나무(candidate new tree)”임을 표시하게 합니다.

2. 나무별 체크리스트(Tree checklist)

   • 특정 나무를 선택하면 자동으로 다음을 끌어옵니다.
     • 알려진 완화책
     • 관련 러너북
     • 관련 대시보드

3. 편차 기록(Deviation notes)

   • 이번 발생이 과거와 어떻게 달랐는지(새로운 트리거, 새로운 컴포넌트, 더 넓어진 블라스트 반경 등)를 적는 필드

4. 업데이트 훅(Update hook)

   • 인시던트가 해결된 뒤 포스트모템 과정에서 반드시 수행해야 할 일로,
     “나무 X를 새롭게 배운 점으로 업데이트하거나, 나무 Y를 새로 생성하라”는 단계를 넣습니다.

이렇게 하면 인시던트 커맨더는 보통 15분 이내에 이렇게 말할 수 있습니다.

• “이건 ‘Payment Gateway Cascading Timeout(결제 게이트웨이 연쇄 타임아웃)’ 나무랑 일치합니다. 우선 거기에 정리된 완화책부터 적용합시다.”

이는 트리아지 속도를 높이고, 커뮤니케이션을 집중시키며, 팀원들이 현재 상황에 대한 공유된 멘탈 모델을 갖도록 도와줍니다.

6단계: 과수원을 지속적으로 업데이트하고 가지치기하기

과수원은 살아 있는 생태계입니다. 여러분의 시스템도 마찬가지입니다. 따라서 정기적인 정원 가꾸기 사이클이 필요합니다.

1. 각 인시던트 이후

   • 어느 나무에 해당하는지 확인하거나, 새로운 나무를 만듭니다.
   • 새로 발견된 시그널, 완화책, 고장 모드를 기록합니다.

2. 분기별 과수원 리뷰

   • 더 이상 적용되지 않는 나무(예: 완전히 제거된 컴포넌트)는 제거합니다.
   • 지나치게 포괄적인 나무는 더 명확한 하위 패턴으로 쪼갭니다.
   • 서로 거의 동일한 나무는 병합합니다.

3. 설계 리뷰에 통합하기

   • 주요 설계를 리뷰할 때마다, 반드시 다음 질문을 던집니다.
     • “이번 설계로 어떤 나무를 건드리는가?”
     • “이번 설계로 새로운 나무를 의도치 않게 만들고 있지는 않은가?”

4. 교육 및 온보딩

   • 과수원을 교육에 활용합니다. 신규 엔지니어는 주요 나무들과 그 뒤에 있는 시스템 아키타입을 차근차근 살펴보며 온보딩합니다.

시간이 지나면 과수원은, 시스템이 어떻게 망가졌고(실패) 또 어떻게 예방하고 회복하는 법을 배워 왔는지에 대한 조직의 집단 기억이 됩니다.

어떻게 시작할까 (1주 안에 만들기)

처음부터 거창한 프로그램이 필요하지 않습니다. 단 1주일 안에 다음을 해볼 수 있습니다.

1. 지난 1년간 가장 임팩트가 컸던 인시던트 5–10건을 고릅니다.
2. 각 인시던트에 대해 시스템 아키타입 하나를 정합니다.
3. 간단한 종이 나무를 초안으로 만듭니다(실제 종이나 화이트보드 사진이어도 좋습니다).
   • 이름, 다이어그램, 트리거, 시그널, 완화책 정도만 적습니다.
4. 각 나무마다 실제 신뢰성 데이터 최소 1개를 끌어옵니다.
5. 인시던트 템플릿을 업데이트하여 “Tree / Archetype” 필드와 과수원 링크를 추가합니다.

그 다음에는 반복입니다. 새 인시던트가 생길 때마다, 그 인시던트는 다음 둘 중 하나를 하게 됩니다.

• 기존 나무를 더 풍부하게 만들거나,
• 새로운 패턴을 드러내며, 과수원 안에 새 나무로 자리 잡습니다.

결론: 개별 사고에서 패턴으로, 패턴에서 회복탄력성으로

각각의 인시던트는 시끄럽고, 아프고, 종종 혼란스럽습니다. 하지만 여러 인시던트를 함께 놓고 보면, 놀라울 정도로 소수의 반복 가능한 구조 패턴이 드러납니다.

아날로그 인시던트 과수원 맵은 다음을 가능하게 해 줍니다.

• 추상적인 시스템 아키타입을 구체적인 서비스 장애 모드로 번역하고,
• 그 패턴을 현실 세계의 신뢰성 데이터로 뒷받침하며,
• 이를 선제적인 회복탄력성 투자의 나침반으로 사용하고,
• 인시던트 대응과 사후 학습을 공유된 시각적 맵을 중심으로 표준화하는 것.

이제 각 장애를 고립된 사고로 취급하는 대신, 이미 알고 있는 과수원 안의 익숙한 나무로 보기 시작하게 됩니다. 그리고 나무를 계속 심고, 가지치기하고, 배우는 과정을 거치면서, 시스템과 팀은 조금씩 그러나 꾸준히 더 탄탄해집니다.

일단 몇 그루의 종이 나무부터 시작하십시오. 과수원은 생각보다 훨씬 빨리 자라날 것입니다.