서론: 대시보드보다 더 크게 자라는 신뢰성의 문제

요즘 시스템은 ‘문서상으로는’ 어느 때보다도 더 안정적입니다.

하드웨어 MTBF는 꾸준히 좋아지고, 클라우드 플랫폼은 자동 복구를 지원하며, 개별 서비스의 업타임 지표도 인상적입니다. 그런데도 큰 장애는 계속 뉴스 헤드라인을 장식합니다. 역설은 단순합니다. 개별 컴포넌트의 신뢰성은 올라가는데, 시스템 전체의 신뢰성은 그만큼 따라오지 못하고 있다는 것입니다.

이유는, 현대 시스템이 더 이상 전구처럼 고장 나지 않고 생태계처럼 실패하기 때문입니다. 인시던트는 망가진 부품 하나가 아니라, 상호작용에서 만들어집니다. 서비스 간 전제의 불일치, 재시도 폭주가 만드는 연쇄 장애, 잘못된 타이밍에 잘못 설정된 서킷 브레이커 같은 것들이죠.

이를 다루기 위해 고급 SRE와 회복탄력성(resilience) 엔지니어링에서는 카오스 테스트, 게임데이, 장애 주입(failure injection)을 도입합니다. 하지만 자주 간과되는 강력한 저기술 보완책이 하나 있습니다.

“종이 인시던트 스토리 풍동(Paper Incident Story Wind Tunnel)” — 프로덕션에 장애가 일어나기 전에, 아날로그 방식으로 장애와 스트레스 시나리오를 모델링해 손으로 테스트하는 방법입니다.

이 접근법은 시스템 사고, 정성적 성숙도 프레임워크, 의도적인 장애 주입을 결합합니다. 별도의 거창한 툴링이 필요하지 않습니다. 종이, 마커, 그리고 진지한 사고만 있으면 됩니다.

왜 더 나은 컴포넌트만으로는 시스템 장애를 막을 수 없을까

우리는 수년간 개별 컴포넌트 최적화에 매달려 왔습니다. 더 낮은 하드웨어 고장률, 더 견고한 스토리지, 더 신뢰할 수 있는 클라우드 기본 요소들. 그럼에도 조직들은 여전히 다음과 같은 일을 겪습니다.

• 단 한 번의 설정 변경으로 촉발된 리전 전체 장애
• 재시도 폭주(retry storm)로 인한 연쇄 실패
• 피크 트래픽 상황에서만 드러나는 미묘한 의존성 문제들

핵심 문제는 다음과 같습니다.

1. 실패는 상호작용에서 비롯되는 경우가 지배적이다.
   현대 장애의 상당수는 ‘창발적(emergent)’입니다. 서비스와 사람의 상호작용에서 나타나지, 부품 하나가 깨져서 생기는 문제가 아닙니다.

2. 복잡성이 실패 모드를 숨긴다.
   마이크로서비스, 분산 데이터, 서드파티 의존성은 머릿속으로는 도저히 나열하거나 시뮬레이션할 수 없는 수많은 상태를 만들어냅니다.

3. 현실 세계의 대형 인시던트만으로는 학습 속도가 너무 느리다.
   치명적인 장애는 몇 년에 한 번 일어날 수도 있습니다. 그런 사건만으로 배우고 있다면, 피드백 루프는 위험할 정도로 느린 셈입니다.

그래서 시스템 사고(systems thinking) 가 필수입니다. 개별 컴포넌트의 SLA를 넘어, 시스템 끝에서 끝까지의 동작, 피드백 루프, 상호작용 자체에 초점을 맞춰야 합니다.

메트릭을 넘어서: CMM 같은 정성적 프레임워크 활용하기

MTTR 차트만 바라본다고 해서 신뢰성 엔지니어링 문제가 해결되지는 않습니다. 조직이 신뢰성을 어떻게 생각하고, 어떻게 행동하는지를 말할 수 있는 언어가 필요합니다.

여기서 CMM(Capability Maturity Model, 역량 성숙도 모델) 같은 정성적 프레임워크가 등장합니다. 단순히 숫자만 추적하는 대신, 다음과 같은 단계를 묘사합니다.

• 초기(Initial): 완전 반응적. 장애가 터지면 그때그때 땜질식으로 대응.
• 반복 가능(Repeatable): 기본적인 런북과 인시던트 프로세스가 존재.
• 정의됨(Defined): 설계와 개발 프로세스에 신뢰성이 사전에 녹아들어 있음.
• 관리됨(Managed): 메트릭과 피드백 루프를 기반으로 체계적인 개선이 이루어짐.
• 최적화됨(Optimizing): 지속적인 실험, 카오스 테스트, 학습이 이뤄짐.

그렇다면 종이 인시던트 스토리 풍동은 어디에 위치할까요?

• Defined 단계에서는, 팀이 장애를 구조적으로 사고할 수 있는 틀을 제공합니다.
• Managed 단계에서는, 실제로 찾아낸 이슈를 메트릭과 운영 개선으로 연결합니다.
• Optimizing 단계에서는, 자동화된 카오스 툴과 짝을 이뤄 풍부하고 지속적인 학습 루프를 만듭니다.

즉, 이건 하나의 기술이 아니라 실천(practice) 입니다. 조직을 성숙도 사다리 위로 한 단계 끌어올리는 간단한 행동 양식입니다.

의도적인 장애 주입: 재난을 기다리지 말 것

현대 신뢰성 실천에는 하나의 핵심 원칙이 깔려 있습니다.

실제 인시던트에서만 배운다면, 학습 속도는 심각하게 느리다.

의도적인 장애 주입(fault injection)은 필수입니다. 예를 들어 프로덕션에서 서버를 무작위로 죽여보는 Chaos Monkey 같은 도구로 잘 알려져 있죠. 이런 접근은 다음을 가능하게 합니다.

• 숨겨진 전제와 위험한 결합(coupling)을 드러냄
• 팀이 중복(redundancy), 자동화, 우아한 성능 저하(graceful degradation) 를 설계에 반영하도록 강제
• 실패를 ‘뜻밖의 사고’가 아니라 ‘설계 파라미터’로 다루는 문화를 만듦

하지만 모든 조직이 당장 프로덕션 인스턴스를 죽여볼 준비가 되어 있는 것은 아닙니다. 그래서 아날로그 모델링이 매우 유용해집니다.

종이 인시던트 스토리 풍동은 본질적으로 수동형 카오스 엔지니어링입니다. 사람이 손으로 만든 가상 시나리오를, 저기술 환경에서 안전하게 “시뮬레이션”해보는 것입니다. 그다음 단계로 실제 환경에서의 실사 격리(live fire)에 나아갈 수 있도록 말이죠.

종이 인시던트 스토리 풍동이란 무엇인가?

항공우주 엔지니어들이 새 비행기를 어떻게 테스트하는지 떠올려보십시오. 축소 모형을 풍동에 넣고, 강한 바람·난류·받음각 변화를 인가해 어떻게 반응하는지 봅니다.

우리는 종이와 대화만으로 비슷한 일을 시스템에 해볼 수 있습니다.

종이 인시던트 스토리 풍동은 다음과 같은 활동입니다.

**구조화된 아날로그 연습으로서,

• 시스템을 종이에 그려두고,
• 가상의 장애를 주입하고,
• 인시던트 스토리를 한 걸음씩 따라가며,
• 시스템·사람·프로세스가 어떻게 반응하는지 관찰하는 방법입니다.**

코드는 필요 없습니다. 대시보드도 필요 없습니다. 화이트보드나 포스트잇, 그리고 다양한 역할의 엔지니어와 운영 인력이 모이면 충분합니다.

목표는 다음을 표면 위로 끌어올리는 것입니다.

• 숨겨진 단일 고장점(SPOF, Single Point of Failure)
• 취약한 의존성과 과도한 결합
• 탐지·알림·런북의 빈틈
• 사람 사이의 조정 실패, 모호한 소유권

Chaos Monkey를 적용하거나 풀 스케일 게임데이를 열기 전에, 이 아날로그 풍동에서 먼저 ‘스토리 테스트’를 해보는 셈입니다.

종이 인시던트 스토리 풍동 세션 운영 방법

다음과 같은 간단한 포맷으로 시작할 수 있습니다.

1. 시나리오 선택

하나의 구체적이고 현실적인 시나리오를 고릅니다. 예를 들면 다음과 같습니다.

• 기본(Primary) 데이터베이스가 30분 동안 read-only 상태가 됨
• 하나의 가용 영역(Availability Zone)에 접근할 수 없음
• 인증(provider) 응답 지연이 5초까지 치솟음
• 핵심 내부 API가 요청의 10%에 대해 HTTP 500을 반환

네트워크 회복탄력성과 스트레스 관점에서도 각도(angle)를 잡아보세요.

• 서비스 간 부분적인 패킷 손실
• 갑작스러운 트래픽 급증(블랙 프라이데이, 대형 마케팅 캠페인)
• 사이버 공격을 흉내 낸 악성 트래픽 패턴
• 점진적인 설정 롤링 변경 과정에서 호환성 문제가 생기는 경우

2. 시스템 그리기

화이트보드나 큰 종이에 다음을 그립니다.

• 서비스, 데이터 저장소, 외부 의존성들을 스케치
• 네트워크 호출과 데이터 흐름을 화살표로 표시
• 알고 있는 경우, 타임아웃, 재시도, 레이트 리밋, 폴백(fallback) 을 주석으로 달기

이것이 풍동 안에 들어간 “모델”입니다. 완벽할 필요는 없고, 솔직하기만 하면 됩니다.

3. 인시던트 스토리 말해보기

이제 내레이션을 시작합니다.

1. 0–5분: 장애가 주입됩니다. 실제로 가장 먼저 어떤 것이 깨질까요? 누가(혹은 아무도) 이를 알아차릴까요?
2. 5–15분: 어떤 알람이 울립니까? 시끄럽기만 한가요, 아니면 명확한가요, 혹은 아예 없나요?
3. 15–60분: 시스템은 어떻게 반응합니까? 재시도, 큐 길이 증가, 연쇄적인 지연, 열화된 UX?
4. 1시간–N시간: 누가 온콜입니까? 어떻게 공조합니까? 머릿속 시스템 모델은 어떻게 생겼나요?

시나리오를 마치 시나리오 대본처럼 따라갑니다.

• “사용자가 체크아웃 버튼을 누른다…”
• “프론트엔드가 서비스 A를 호출하고, A는 B와 C를 호출한다…”
• “B와 데이터베이스 사이 네트워크 지연이 급증한다…”
• “재시도가 시작되고… 부하가 더 늘고… 레이트 리밋이 걸린다…”

각 단계마다 다음을 스스로에게 물어보십시오.

• 시스템에서 실제로 무슨 일이 일어나는가?
• 알람, 대시보드, 로그는 도움이 되는가, 방해가 되는가?
• 사람들은 무슨 일이 일어나고 있다고 믿는가? 그 믿음은 맞는가?

4. 실패 모드와 갭 메모하기

내레이션을 진행하면서 다음을 적어 둡니다.

• 기술적 위험: 이중화되지 않은 서비스, 백프레셔(backpressure) 부재, 무제한 큐 등
• 인적 위험: 소유권이 모호함, 런북 부재, 느린 에스컬레이션
• 가시성 갭: 핵심 증상을 감지하는 알람이 없거나, 너무 늦게 발생하는 경우

간단한 카테고리로 분류해도 좋습니다.

• 반드시 수정 (명백한 장애 위험)
• 수정 권장 (의미 있는 성능 저하 위험)
• 있으면 좋음 (관측 가능성·운영 품질 개선)

5. 발견 내용을 구체적인 실험으로 전환하기

아날로그 풍동은 변화로 이어질 때만 가치가 있습니다.

• 우아한 성능 저하(graceful degradation) 구현
  예: 추천 엔진이 다운되면 추천 기능은 끄더라도, 결제는 계속 가능하도록.
• 연쇄 실패를 막기 위한 레이트 리밋과 백프레셔 추가
• 런북과 온콜 프로세스 개선
• 이 시나리오를 기반으로 한 자동화 스트레스 테스트와 카오스 실험 계획 수립

이 단계에서 우리는 “아마 이렇게 망가질 것이다” 라고 추측하던 상태에서, **“테스트를 해봤기 때문에 실제로 어떻게 동작하는지 알고 있다”**는 상태로 옮겨갑니다.

왜 아날로그 모델링이 의외로 강력한가

겉보기에 단순하지만, 손으로 장애 시나리오를 테스트하는 방식은 여러 이유로 강력합니다.

1. 시스템 사고를 강제한다.
   화살표를 그리며 타임라인을 말로 풀다 보면, 자연스럽게 개별 서비스가 아닌 전체 시스템의 거동을 생각하게 됩니다.

2. 공유된 멘탈 모델을 만든다.
   엔지니어, SRE, PM, 인시던트 커맨더가 모두 같은 그림을 머릿속에 품게 됩니다. 시스템이 어떻게 실패하는지 공동의 이해를 갖게 되는 것이죠.

3. 싸고 빠르다.
   별도 환경을 만들 필요도, 크고 복잡한 승인 절차도 없습니다. 한 시간만 투자해도, 실제 장애가 몇 달 뒤에나 드러냈을 문제를 미리 발견할 수 있습니다.

4. 팀을 회복탄력성에 정렬시킨다.
   사람들이 정기적으로 장애 스토리를 다루기 시작하면, 기본적으로 중복·자동화·우아한 성능 저하를 염두에 두고 설계하게 됩니다.

5. 더 깊은 테스트를 준비시킨다.
   여기서 나온 결과는 자연스럽게 다음 활동으로 이어집니다.

   • 네트워크 스트레스 테스트
   • DDoS 시뮬레이션
   • 부하·내구(soak) 테스트
   • 스테이징 혹은 프로덕션에서의 카오스 실험

대비에서 ‘입증된’ 회복탄력성으로

많은 조직이 “대비” 수준에서 멈춥니다.

• 런북은 있습니다.
• 탁상훈련(tabletop exercise)도 가끔 합니다.
• 백업·페일오버·이중화 링크가 잘 작동할 것이라고 믿습니다.

하지만 신뢰성은 직접 회복탄력성을 검증할 때에만 진짜가 됩니다.

• 한 리전으로 가는 트래픽을 실제로 잘라보고, 무엇이 깨지는지 확인해보십시오.
• 설정 미롤(mis‑roll) 시나리오를 시뮬레이션해, 블라스트 레이디우스(blast radius)를 검증해보십시오.
• DDoS와 유사한 부하 패턴을 가해보고, 시스템이 어떻게 방어하고 복구하는지 관찰해보십시오.

종이 인시던트 스토리 풍동은 다음 둘 사이를 잇는 다리입니다.

• 이론적 대비(우리는 준비됐다고 ‘생각한다’)
• 경험적으로 입증된 회복탄력성(통제된 학대에도 이 시스템이 버티는 것을 ‘직접 보았다’)

이 방식은 더 나은 실험을 설계하고, 더 안전한 장애 주입을 하도록 도와줍니다. 어디가 약한지 분명히 이해한 상태에서 말이죠.

결론: 종이에서 시작해, 확신으로 끝내기

시스템 복잡성이 증가하는 시대에는, 부품 고장률을 개선하는 것만으로는 부족합니다. 다음이 필요합니다.

• 전체 시스템 수준에서 실패가 어떻게 등장하는지 이해하는 시스템 사고
• 조직의 행동 양식을 이끄는 정성적 성숙도 프레임워크 (단순 숫자 지표를 넘어서)
• 학습을 가속하는 의도적인 장애 주입
• 모두가 회복탄력성에 정렬되도록 만드는 정기적이고 의도적인 장애 실험 — 실제이든 시뮬레이션이든

종이 인시던트 스토리 풍동은 이 모든 것을 하나로 묶는, 놀라울 정도로 단순한 실천입니다. 다음과 같은 특징을 갖습니다.

• 저기술이지만 고임팩트
• 도입이 빠르고 쉽다
• 카오스 엔지니어링과 네트워크 스트레스 테스트로 가는 자연스러운 전 단계

새로운 도구가 필요하지 않습니다. 화이트보드를 잡고, 하나의 실패 시나리오를 고르고, 인시던트 스토리를 말로 풀어보십시오.

그러면 실제 바람이 시스템을 강타하는 순간 — 사이버 공격이든, 트래픽 폭증이든, 설정 실수든 — “부디 잘 버텨라” 하고 바라기만 하지는 않을 것입니다.

이미 그 시스템이 어떻게 행동할지 알고 있을 테니까요. 종이 위에서 그 영화를 먼저 봤기 때문입니다.