소개: 비행기처럼 장애를 테스트할 수 있다면?

새 비행기가 승객을 태우기 전에 반드시 거치는 곳이 있습니다. 바로 풍동(wind tunnel)입니다. 엔지니어들은 난기류, 스트레스, 에지 케이스 상황에서 비행기가 어떻게 반응하는지 안전하고, 예측 가능하며, 저렴하게 검증합니다.

소프트웨어 시스템도 마찬가지 대접을 받아야 합니다.

카오스 엔지니어링은 우리에게 이런 사고방식을 줬습니다. 실제 장애를 버텨낼 수 있다는 자신감을 얻기 위해, 시스템에 의도적으로 실험을 가하라. 하지만 현실에서는 많은 팀이 이 사고방식과 실제 실행 사이의 간극을 건너뛰어 버립니다. 연습된 플레이북도, 명확한 역할 정의도, 검증된 UI도 없이 곧장 스테이징이나 심지어 프로덕션에 카오스 실험을 돌리기 시작하곤 합니다.

_“우리도 좀 더 레질리언트(탄탄한)해야 해.”_라는 선언과 “그럼 프로덕션에 장애를 주입해 보자.” 사이에는 사실 하나의 중요한 층이 빠져 있습니다. 그게 바로 아날로그 인시던트 스토리 풍동(analog incident story wind tunnel) 입니다. 즉, 실제 사용자가 난기류를 느끼기 전에, 종이 기반의 로우테크 시뮬레이션으로 장애를 미리 프로토타이핑하는 방법입니다.

카오스 엔지니어링에서 아날로그 풍동으로

카오스 엔지니어링의 핵심 목표는 다음과 같습니다.

• 재난이 되기 전에, 약점을 미리 드러낸다
• 현실적인 조건 아래에서 대응을 연습한다
• 시스템이 장애를 견뎌낼 수 있다는 신뢰와 자신감을 쌓는다

아날로그 인시던트 풍동은 이 목표를 한 단계 더 앞당겨 수행합니다. 코드가 배포되기 전, 대시보드가 만들어지기 전, 온콜 로테이션이 돌아가기 전 단계에서 말이죠.

라이브 시스템부터 시작하는 대신, 이렇게 시작합니다.

• 손으로 그린 화면들: 모니터링 대시보드, 운영 도구 UI
• 종이로 그린 워크플로: 에스컬레이션, 커뮤니케이션 절차
• 스토리 기반 장애 시나리오: 인덱스 카드나 포스트잇에 적은 사건 카드들

아날로그이자 저충실도 상태를 유지하면 다음이 가능합니다.

• “인시던트가 이렇게 흘러가면 좋겠다”는 이상적인 그림을 빠르게 그려볼 수 있고
• 도구와 프로세스 설계 상의 결함을 조기에 드러낼 수 있으며
• 매우 저렴하고 빠르게 반복(iteration)할 수 있습니다.

그리고 나서야 비로소 자동화하고, 코드화하고, 운영에 반영합니다.

“아날로그 인시던트 스토리 풍동”이란 정확히 무엇인가?

테이블탑(tabletop) 연습과 UX 페이퍼 프로토타이핑을 합쳐, 장애와 인시던트 대응에만 초점을 맞춘 워크숍이라고 생각하면 됩니다.

탐지부터 복구까지의 장애 시나리오를 오직 종이 아티팩트만으로 시뮬레이션합니다.

• 거칠게 그린 모니터링 대시보드
• 가짜 채팅 창과 티켓팅 시스템 화면
• 종이로 된 런북(runbook)과 플레이북(playbook)
• 알림, 고객 제보, 시스템 상태를 나타내는 인덱스 카드들

팀은 이 장애를 처음부터 끝까지 “플레이”합니다. 테이블 위에서 종이를 이리저리 옮기는 모습은, 마치 모델 비행기 위로 바람을 불어 넣는 것과 비슷합니다.

여기서의 목적은 기술 그 자체를 테스트하는 것이 아닙니다. 대신 다음을 검증합니다.

• 인터페이스 – 사람들이 처음에 무엇을 보고, 어디를 클릭하는가?
• 워크플로 – 누가 누구와, 어떤 순서로 소통하는가?
• 의사결정 방식 – 불확실한 상황에서 다음 행동을 어떻게 고르는가?
• 커뮤니케이션 – 고객에게 무엇을, 언제, 어떻게 말하는가?

종이를 모델링 클레이처럼 사용해, 인시던트의 스토리를 한 단계씩, 상호작용 단위로 쌓아 가는 것입니다.

왜 종이인가? 저충실도 시뮬레이션의 힘

분산 트레이싱과 실시간 옵저버빌리티가 넘쳐나는 시대에, 종이는 너무 단순해 보일 수 있습니다. 하지만 바로 그 단순함이 이 접근법의 강점입니다.

1. 믿을 수 없을 만큼 빠르고 싸다
손으로 그린 디자인만 있으면, 다음이 가능합니다.

• 새로운 대시보드 레이아웃을 몇 분 만에 스케치
• 에스컬레이션 플로우를 화살표 하나 바꾸며 재설계
• 마음껏 버리고 다시 그리기 (매몰비용에 대한 부담 거의 없음)

백엔드 변경도, 티켓 발행도, 배포 윈도우도 필요 없습니다.

2. 심리적 부담을 크게 낮춘다
난잡하게 그려진 스케치는 반듯한 UI보다 훨씬 비판하기 쉽습니다. 덕분에 다음이 쉬워집니다.

• 가정에 질문하기: “왜 이 알림은 여기 있어야 하죠?”
• 플로우를 갈아엎기: “이 단계에서 더 일찍 페이지 받아야 해요.”
• 대안을 탐색하기: “여기서는 페이지 대신 런북 링크로 가면 어떨까요?”

3. ‘인간이 포함된 시스템’을 제대로 들여다보게 한다
대부분의 인시던트는 순수 기술 문제가 아니라, 사회기술적(socio-technical) 문제입니다. 시스템은 다음을 모두 포함합니다.

• 코드와 인프라스트럭처
• 대응에 참여하는 사람들
• 이들이 사용하는 도구들
• 이들 사이에서 오가는 커뮤니케이션 패턴

종이 프로토타입은 기계가 아니라 사람과 워크플로를 중심에 두도록 만들어 줍니다.

나만의 인시던트 스토리 풍동 만들기

시작에 필요한 것은 그리 많지 않습니다.

• A4 용지나 포스트잇
• 마커와 펜
• 인덱스 카드
• 화이트보드나 넓은 책상

준비가 되었다면, 아래 구조를 따라가면 됩니다.

1. 시나리오 정의하기

현실적으로 일어날 법한 장애나, 최근의 니어미스(아슬아슬하게 피해간 사고)를 하나 고릅니다.

• “메인 데이터베이스 성능이 서서히 악화되다가 결국 사용 불가 상태가 된다.”
• “인증 서비스 지연이 급증해, 사용자들이 간헐적으로 로그인에 실패한다.”
• “잘못된 설정 롤아웃으로 API 일부가 다운된다.”

시나리오를 카드에 한 줄로 적고, 몇 개의 비트(beat)—시간 흐름에 따른 사건—를 추가합니다.

• T+0: 조용한(silent) 실패 시작
• T+5: 에러율 증가
• T+10: 사용자들이 소셜 미디어에서 불만을 올리기 시작
• T+15: 온콜에 알림 도착

이 비트들이 풍동 속의 “바람 한 줄기” 역할을 합니다.

2. 인터페이스와 아티팩트 스케치하기

각각의 종이에 손으로 다음을 그립니다.

• 모니터링 대시보드 화면
• 알림(Notification) 수신 화면
• 티켓/인시던트 관리 도구
• 시스템 다이어그램
• 런북 페이지

예쁘게 그릴 필요는 없습니다. 중요한 것은 명확성입니다. 누가 봐도 이 정도는 말할 수 있을 정도의 충실도만 확보하면 됩니다.

“이 시점이라면, 저는 여기 클릭해서 이 그래프를 볼 거예요.”

3. 역할(Role) 배정하기

작지만 기능이 다른 사람들로 구성된 그룹을 모읍니다.

• 온콜 엔지니어
• 인시던트 커맨더(또는 평소 인시던트를 리드하는 역할)
• 관련 프로덕트/피처 오너
• 가능하다면 고객지원 또는 커뮤니케이션 담당자

각자 실제 조직에서 맡고 있는 역할을 그대로 배정합니다. 그리고 한 명은 퍼실리테이터로 세워, 다음 역할을 맡깁니다.

• “시스템” 역할: 새로운 이벤트를 공개하는 사람
• 내레이터: 시간의 흐름을 관리하는 사람
• 서기(scribe): 통찰과 인사이트를 기록하는 사람

4. 시뮬레이션 실행하기

시나리오를 실제 시간 흐름에 맞추거나, 약간 빠르게 돌려 봅니다.

퍼실리테이터는 다음과 같은 이벤트 카드를 순서대로 공개합니다.

• 새로운 알림 카드: “/checkout 경로에서 에러율 급증”
• 사용자 제보 카드: “주문이 안 돼요, 페이지가 계속 로딩만 해요.”
• 모니터링 카드: “CPU는 정상, DB 커넥션 사용률 90%”

참여자들은 오직 종이로만 제공된 도구를 사용해 대응해야 합니다.

• 대시보드를 “연다”: 해당 화면이 그려진 종이를 집어 듭니다.
• 누군가를 “페이지” 한다: 에스컬레이션 카드를 옮겨 놓습니다.
• 고객 공지 초안을 작성한다: 포스트잇에 문구를 적습니다.

그룹의 목표는 종이가 실제 시스템이라 가정하고 어디에서 이 종이 시스템이 여러분을 배신하는지 찾아내는 것입니다.

5. 갭과 마찰 지점 포착하기

누군가 이런 말을 할 때마다:

• “여기서 X도 같이 보였으면 좋겠어요.”
• “이 서비스 오너가 누군지 어디서 찾아야 하죠?”
• “아마 Y를 먼저 확인하느라 시간 좀 날릴 것 같네요.”

…그 순간을 멈춥니다. 적어 두세요. 그게 바로 난기류(turbulence)입니다.

예를 들어 이런 문제들이 드러날 수 있습니다.

• 중요한 의존성의 오너가 불분명함
• 장애 트리아지보다는 평시 운영에 맞춰 설계된 대시보드
• 엔지니어링팀과 지원팀 간의 애매한 핸드오프 구간
• 빠진 의사결정 지점: “에러율이 어느 수준이면 피처 플래그를 끄지?”

이런 약점들을 실제 장애를 주입하기 전에 발견하는 것이 목표입니다.

도구만으로는 보이지 않는 것들을 종이가 드러내는 이유

페이퍼 인시던트 풍동은 특히 다음 세 영역에서의 갭을 찾아내는 데 탁월합니다.

1. 모니터링: 우리는 정말 ‘봐야 할 것’을 보고 있는가?

시뮬레이션을 돌리다 보면 자연스럽게 이런 질문이 나옵니다.

• 이 장애를 충분히 일찍 감지할 수 있었을까?
• 트리아지 초기에 가장 먼저 봐야 하는 메트릭은 무엇인가?
• 사용자 임팩트의 “스토리”를 한눈에 보여주는 단일 화면이 있는가?

손으로 그린 대시보드 위에 낙서와 메모를 한가득 더해야 겨우 쓸 만해진다면, 그건 분명한 디자인 시그널입니다. 평시 운영용이 아니라, 인시던트 트리아지용 옵저버빌리티를 새로 설계할 필요가 있다는 뜻입니다.

2. 커뮤니케이션: 누가, 언제, 무엇을 알고 있는가?

커뮤니케이션 패턴이 탄탄한지 금방 드러납니다.

• 지원팀은 언제쯤 인시던트 발생 사실을 알게 되는가?
• 고객에게는 어떤 채널로 공지하는가? 상태 페이지, 이메일, 인앱 배너?
• 외부 커뮤니케이션을 누가, 어떤 트리거에 따라 담당하는가?

이걸 종이 위에서 직접 플레이해 보면, 그간 “대충 이렇게 되겠지”라고 가정만 하고 있던 부분이 매우 불편할 정도로 선명히 드러납니다.

3. 의사결정: 압박 속에서도 좋은 결정을 내릴 수 있는가?

실제 인시던트 상황에서 머뭇거림과 혼란은 분 단위의 손실로 이어집니다. 종이 시뮬레이션은 다음을 검증할 기회를 줍니다.

• 롤백 vs 롤포워드를 선택하는 분명한 기준이 있는가?
• 런북에 단순 명령어 나열이 아니라, 실제 의사결정 포인트가 포함돼 있는가?
• 엔지니어들 의견이 갈릴 때, 최종 판단 권한은 누구에게 있는가?

여기서는 실제 서비스가 걸려 있지 않으니, 사람들도 더 적극적으로 모호한 의사결정 경계를 문제 삼고 개선을 제안할 수 있습니다.

종이에서 푸시 버튼까지: 반복 가능한 인시던트 대응으로 가는 길

성숙한 인시던트 매니지먼트의 핵심 목표 중 하나는, 대응 과정을 이렇게 만드는 것입니다.

가능한 한 반복 가능하며, 버튼 한 번으로 시작할 수 있는(workflow) 상태에 가깝게.

기계적으로 똑같이만 하자는 뜻이 아니라, 중요한 부분은 예측 가능하고 코드화되어 있도록 하자는 것입니다.

아날로그 풍동은 이 목표를 향해 안전하게 반복할 수 있는 실험장입니다.

1. 스토리부터 시작한다
   인시던트의 첫 증상부터 최종 해결까지, 장애의 스토리를 이야기로 풀어냅니다.

2. 워크플로를 종이로 프로토타이핑한다
   화면, 알림, 의사결정, 커뮤니케이션까지 모두 그려 봅니다.

3. 여러 번 반복하며 다듬는다
   한 번 돌릴 때마다 마찰이 발견되고, 그때마다 조금씩 매끄럽게 만듭니다.

4. 안정된 부분을 자동화한다
   종이 위에서 “이제 이 정도면 괜찮다” 싶을 때, 그 경로를 코드로 옮깁니다.

   • 알림 라우팅 규칙
   • 기본 제공 대시보드
   • 챗옵스(ChatOps) 명령어
   • 상태 페이지 기본 템플릿

지금 있는 것을 그저 자동화하는 대신, 의도적으로 설계하고, 테스트를 거친 인시던트 경험을 자동화하는 셈입니다.

시작을 위한 간단한 연습

이 모든 게 조금 뜬구름 같게 느껴진다면, 다음의 가벼운 연습부터 시도해 보세요.

1. 최근 인시던트에 참여했던 사람 3–5명과 90분을 확보합니다.
2. 기억에 남는 인시던트 하나를 골라 다음을 재구성합니다.
   • 타임라인: 주요 이벤트를 포스트잇으로 시간 순서대로 붙이기
   • 핵심 결정: 각 결정을 인덱스 카드에 한 줄씩 적기
   • 당시 사용한 인터페이스: 기억나는 대로 화면을 스케치
3. 그리고 이렇게 질문합니다. “이게 내일 다시 일어난다면, 우리는 어떻게 흘러가길 원할까?”
4. 이상적인 버전을 종이 위에 다시 그립니다.
   • 더 적은 단계
   • 더 명확한 알림
   • 더 깔끔한 커뮤니케이션 플로우
5. 실제 vs 이상 버전을 나란히 놓고 비교합니다. 이 차이가 곧 여러분의 개선 로드맵입니다.

이 과정을 몇 번만 반복해도, 사실상 작은 규모의 아날로그 풍동 실험실을 만든 셈이 됩니다.

결론: 종이 위 난기류를 통한 더 안전한 하늘길

탄탄한 시스템은 더 좋은 코드나 더 많은 메트릭만으로 완성되지 않습니다. 그런 시스템 뒤에는 항상 다음을 실천하는 팀이 있습니다.

• 장애를 미리 예상하고
• 대응을 반복해서 연습하며
• 압박 속에서 일하는 방식을 계속해서 다듬는 팀

아날로그 인시던트 스토리 풍동은, 이를 실천하는 매우 저비용·고레버리지 수단입니다. 프로덕션에서 카오스 실험을 돌리기 전에, 고객이 화가 나기 전에, 팀이 새벽 3시에 비몽사몽한 상태로 대응하기 전에 미리 해 볼 수 있는 연습장이죠.

손으로 그린 저충실도 시뮬레이션을 받아들이면, 다음을 이룰 수 있습니다.

• 새로운 인시던트 프로세스와 도구의 리스크를 낮춘다
• 모니터링, 커뮤니케이션, 의사결정의 공백을 드러낸다
• 점진적으로 반복 가능하고 푸시 버튼에 가까운 인시던트 대응으로 나아간다

복잡한 시스템을 운영하는 한, 난기류는 언제나 존재합니다. 중요한 건 나와 사용자가 그 난기류를 **야생(the wild)**에서 처음 맞닥뜨릴지, 아니면 내가 만든 종이 풍동 안에서 먼저 경험해 볼지의 차이입니다.

당신의 팀이 온콜, 인시던트, 혹은 신뢰성(reliability)을 책임지고 있다면, 지금 바로 마커를 집어 드세요. 그리고 종이 위에 풍동을 하나 지어 보세요. 원 없이 추락해도 되는 실험실에서, 마음껏 수십 번이고 충돌해 보면서요.