종이부터 시작하는 카오스 회전목마: 하이 스테이크 장애를 위한 로우테크 드릴 돌리기
복잡한 카오스 엔지니어링 도구나 프로덕션 실험에 앞서, 종이와 대화만으로 하는 간단한 카오스 드릴과 테이블탑 익서사이즈로 실전 수준의 인시던트 대응 능력을 만드는 방법을 다룹니다.
종이부터 시작하는 카오스 회전목마: 하이 스테이크 장애를 위한 로우테크 드릴 돌리기
현대 시스템은 복잡하고 예측하기 어려운 방식으로 장애가 발생합니다. 그렇다고 해서, 그 장애에 대비하기 위해 반드시 복잡한 도구가 필요한 것은 아닙니다.
프로덕션 환경에 카오스 엔지니어링 도구를 바로 들이붓기 전에, 더 안전하고 저렴하며, 종종 더 효과적인 출발점이 있습니다. 바로 **종이부터 시작하는 카오스 드릴(paper-first chaos drills)**입니다.
이걸 언제든지 돌릴 수 있는 **“카오스 회전목마(Chaos Carousel)”**라고 생각해 보세요. 인프라도 필요 없고, 특별한 권한도 필요 없습니다. 사람 몇 명, 몇 가지 프롬프트, 그리고 *“좋아, 이게 고장 나면… 그다음에는?”*이라는 질문을 할 의지만 있으면 됩니다.
이 글에서는 **테이블탑 익서사이즈(tabletop exercises)**를 활용해 종이 기반 카오스 연습을 설계하고, 운영하고, 확장하는 방법과, 여기서 얻은 학습을 AWS Fault Injection Simulator, Chaos Monkey 같은 실제 카오스 도구와 어떻게 연결할지, 그리고 그 과정에서 팀이 번아웃되지 않도록 하는 방법을 다룹니다.
왜 종이부터 시작하는 카오스 드릴인가?
종이부터 시작하는 카오스 드릴은 저기술(low-tech), 저위험(low-risk) 인시던트 대응 연습 세션입니다.
- 프로덕션에는 어떤 변화도 주지 않습니다.
- 클라우드 콘솔 접근 권한이 필요 없습니다.
- 실제 장애가 발생할 위험이 없습니다.
실제 장애를 주입하는 대신, 종이(혹은 화이트보드, 공유 문서, 슬라이드)를 사용해 인시던트를 시뮬레이션합니다. 목표는 인프라 레벨에서의 현실감을 재현하는 것이 아니라, 팀의 행동, 의사결정, 커뮤니케이션에서의 현실감을 만드는 것입니다.
이 접근법이 강력한 이유는 다음과 같습니다.
- 압박 속에서 어떻게 대응하는지에 대한 **근육 기억(muscle memory)**을 만듭니다.
- 런북, 알림, 오너십, 에스컬레이션 경로의 빈틈을 드러냅니다.
- 엔지니어링, SRE, 지원(Support), 리더십 간의 기대치를 정렬합니다.
- 비용이 거의 들지 않으면서 반복 실행할 수 있습니다.
즉, 가장 안전하게 배울 수 있는 공간, 회의실에서 장애와 그에 대한 대응을 리허설하는 것입니다. 프로덕션이 아니라.
테이블탑 익서사이즈: 종이 기반 카오스의 핵심
테이블탑 익서사이즈는 보안 분야와 카오스 엔지니어링에서 모두 핵심적인 실천법입니다. 이는 그룹이 가상의 인시던트를 단계별로 따라가며 논의하는 구조화된, 토론 기반의 시나리오 연습입니다.
테이블탑 익서사이즈를 하나의 이야기라고 생각해 보세요.
“지금 새벽 2시 13분입니다. PagerDuty가 울립니다. 결제 API의 레이턴시가 세 배로 증가했습니다. 고객들은 결제를 완료하지 못하고 있습니다. 처음 5분 동안 무슨 일이 일어나나요?”
이후 퍼실리테이터가 새로운 정보를 던져줍니다.
- 새로운 알림(alert)이 발생합니다.
- 메트릭이 새로 들어옵니다.
- 의존 서비스 하나가 장애를 일으킵니다.
- 이해관계자(stakeholder)에게서 커뮤니케이션이 도착합니다.
참가자들은 실제 상황처럼 반응합니다.
- 다음으로 누구에게 페이지를 날리나요?
- 가장 먼저 어떤 대시보드를 열어 보나요?
- 지금 이 시점에서 인시던트를 공식 선언하나요? 심각도(severity)는 어느 수준인가요?
- 고객 지원팀이나 리더십에게 뭐라고 설명하나요?
초점은 시나리오를 “잘 풀어내는 것”이 아닙니다. 대신 다음을 드러내는 데 있습니다.
- 없는 런북
- 명확하지 않은 오너십
- 특정 한 사람의 지식에 과도하게 의존하는 구조
- 망가졌거나 너무 시끄러운(noisy) 알림
- 팀 간 커뮤니케이션의 단절
잘 설계된 테이블탑 익서사이즈는 카오스 엔지니어링의 핵심 관행이 됩니다. 구조화되어 있고, 반복 가능하며, 시간이 지날수록 점점 더 현실에 가까워집니다.
첫 번째 종이 기반 카오스 시나리오 설계하기
완전히 맨몸으로 시작할 필요는 없습니다. 많은 조직이 연습을 일관되고 반복 가능하게 유지하기 위해 구조화된 가이드와 템플릿을 사용합니다.
기본적인 시나리오 템플릿에는 다음과 같은 항목을 포함할 수 있습니다.
-
시나리오 이름
예: "체크아웃 경로에서 리전 단위 데이터베이스 장애" -
비즈니스 영향(Business Impact)
- 무엇이 위협받고 있는가? (매출, 브랜드 신뢰도, 안전, SLA 등)
- 어떤 메트릭이 가장 중요한가? (에러율, 레이턴시, 결제 실패 건수 등)
-
시작 조건(Starting Conditions)
- 시간대 (업무 시간/야간/주말 등)
- 누가 온콜인지
- 어떤 알림이 가장 먼저 발생하는지
-
타임라인 프롬프트(퍼실리테이터가 순차적으로 공개)
- T+5분: 다른 서비스에서 두 번째 알림 발생
- T+10분: 사내 Slack 채널이 메시지로 폭주
- T+20분: 임원이 복구 예상 시간(ETA)을 물어봄
-
참조해야 할 산출물(Artifacts)
- 존재한다면, 관련 런북
- 대시보드 및 모니터링 화면
- 온콜 절차
- 인시던트 커뮤니케이션 템플릿
-
학습 목표(Learning Goals)
예시 목표:- 모두가 인시던트를 어떻게 선언하는지 알고 있는지 검증
- 상태 페이지(status page) 업데이트 연습
- 모니터링이 잘 안 되는 의존 서비스를 식별
시나리오가 실제로 유의미하려면, 당신 조직의 ‘하이 스테이크’ 인시던트에 맞게 커스터마이징해야 합니다.
- 과거에 비즈니스에 큰 타격을 줬던 장애
- SLA나 규제 리스크와 직결된 상황
- 이미 존재한다고 의심하면서도 아직 충분히 탐구하지 못한 단일 장애 지점(Single Point of Failure)
핵심은 반복 가능성입니다. 연습 간의 개선을 비교할 수 있도록, 기본적인 구조는 유지한 채 다양한 시나리오에 반복 적용하세요.
카오스 회전목마 돌리기: 퍼실리테이션 방법
좋은 퍼실리테이터는 연습을 집중되게 유지하고, 현실감 있게 만들며, 심리적 안전(psychological safety)을 보장합니다.
역할 정의
- 퍼실리테이터(Facilitator): 시나리오를 진행하고, 새로운 정보를 제공하며, 시간을 관리합니다.
- 참가자(Participants): 온콜 엔지니어, SRE, 개발자, 지원팀, 경우에 따라 프로덕트/리더십까지 포함합니다.
- 옵저버 / 기록 담당(Observer / Note-taker): 의사결정, 질문, 후속 액션 아이템을 기록합니다.
기본 규칙
- 블레임 프리(blame-free): 이는 평가가 아니라 연습입니다.
- 선의의 가정(assume good intent): 사람들은 자신이 알고 있는 범위 내에서 최선을 다하고 있다고 가정합니다.
- 역할 유지(stay in character): 실제 인시던트 상황이라고 생각하고 행동합니다.
- 시간 제한(timebox): 보통 45–90분 안에 끝냅니다.
진행 흐름
-
컨텍스트 세팅 (5–10분)
- 목표를 명확히 말합니다. (예: “인시던트 선언 프로세스를 점검하는 것이 목표입니다.”)
- 시나리오와 제약 조건을 소개합니다.
-
인시던트 시뮬레이션 (30–60분)
- 초기 알림을 제시합니다.
- 묻습니다: “다음에 무엇을 하나요? 누구를 참여시키나요?”
- 시간이 지나면서 새로운 프롬프트를 공개합니다.
- 참가자들이 실제 도구를 떠올리며 이야기하도록 유도합니다. “어떤 대시보드를? 어떤 런북을?”
-
디브리핑(Debrief) (15–30분)
- 무엇이 잘 되었나요?
- 어디에서 헷갈리거나 막혔나요?
- 무엇이 가장 의외였나요?
- 앞으로 어떤 구체적인 액션을 취해야 할까요?
카오스 드릴의 진짜 가치는 이 디브리핑 단계에서 발생합니다. 허구의 이야기가 시스템과 프로세스를 실제로 개선하는 실행 항목으로 변환되는 지점입니다.
종이에서 프로덕션으로: 카오스 도구와 연결하기
종이 기반 연습을 몇 번 돌려 보면 반복적으로 나타나는 패턴이 보이기 시작합니다.
- 특정 의존 서비스가 지속적으로 취약하다는 사실
- 알림이 아예 없거나, 반대로 너무 시끄럽다는 문제
- 런북이 오래됐거나 존재하지 않는 구간
- 항상 핵심 경로에 끼어 있는 팀들
이 시점이 바로 실제 카오스 엔지니어링 도구와 연결할 타이밍입니다.
예시:
-
AWS Fault Injection Simulator (FIS)
종이 시나리오에서 "us-east-1 리전의 데이터베이스 레이턴시 스파이크"를 다뤘다면, 이를 자동화된 실험으로 바꿔볼 수 있습니다.- 특정 리소스에 네트워크 레이턴시를 인위적으로 주입
- 다른 리전으로 페일오버
- 에러율과 사용자 경험에 미치는 영향 관찰
-
오픈소스 도구 (예: Netflix Chaos Monkey)
종이 드릴의 핵심 질문이 “이 서비스의 노드 하나를 잃으면 어떻게 될까?”였다면, 이를 다음과 같이 포멀하게 실험할 수 있습니다.- 제어된 환경에서 인스턴스를 랜덤하게 종료
- 오토스케일링과 중복 구성이 예상대로 작동하는지 확인
처음부터 도구로 달려가지 마세요. 종이 기반 연습을 통해 무엇을 자동화할 가치가 있는지 먼저 결정해야 합니다. 이렇게 해야 리스크를 줄이고, 카오스 실험이 비즈니스의 실제 우려와 정렬되도록 보장할 수 있습니다. 단순히 ‘카오스를 위한 카오스’가 아니라.
부담 분산: 참여자 로테이션과 온콜 역량 확산
인시던트 대응에서 가장 큰 리스크 중 하나는 **지식 집중(knowledge concentration)**입니다. 소수의 전문가만이 장애 상황에서 무엇을 해야 하는지 아는 상태죠.
종이 기반 카오스 드릴은 이 지식을 조직 전체에 분산시키는 데 최적의 도구입니다.
- 참가자를 로테이션하세요: 서로 다른 엔지니어, 팀, 타임존을 순환 참여시킵니다.
- 역할을 바꾸어 보기: 어떤 때는 시니어 엔지니어가 주 대응자(primary responder)가 되고, 다른 때는 주니어나 신규 팀원이 리드를 맡게 합니다.
- 비엔지니어도 초대: 지원팀, 프로덕트, 운영팀도 인시던트가 어떻게 흘러가는지, 무엇을 도울 수 있는지 직접 체험할 수 있습니다.
이점:
- 사람 차원에서의 단일 장애 지점(SPOF)이 줄어듭니다.
- 더 많은 사람이 인시던트 상황에서 주도적으로 행동할 자신감을 갖게 됩니다.
- 온콜이 소수 전문가에게만 떨어지는 벌이 아니라, 공정하게 나누는 팀의 책임이 됩니다.
단지 기술적인 대응 능력만 연습하는 것이 아닙니다. 인시던트가 팀 스포츠라는 문화를 만드는 과정입니다.
리더십의 역할: 지속 가능한 연습으로 만들기
인시던트 대응과 온콜은 감정적으로도 상당한 부담을 줍니다. 적절한 지원 없이 계속되면 팀은 쉽게 번아웃됩니다.
강한 리더십 참여는 카오스 연습을 스트레스 증폭기가 아니라, 지속 가능한 신뢰성 엔진으로 바꾸는 열쇠입니다.
리더는 다음을 할 수 있습니다.
- 정기적인 카오스 드릴과 디브리핑을 위한 시간을 공식적으로 보장합니다.
- 가용성(uptime)만이 아닌 학습을 보상합니다. 좋은 인시던트 대응과 복기(prime postmortem)를 인정하고 축하합니다.
- 테이블탑 익서사이즈에서 나온 액션 아이템이 실제로 이행되도록 후속 조치를 보장합니다.
- 알림 노이즈와 반복 업무(toil)를 줄이기 위한 도구와 인력 투자를 합니다.
- 때때로 직접 연습에 참여하고, 인시던트 프로세스를 존중함으로써 침착한 태도를 모범으로 보여줍니다.
사람들이 리더십이 인시던트 연습을 진지하게 받아들이고, 그것을 개인을 탓하는 대신 시스템을 고치는 기회로 쓴다는 것을 보게 되면, 심리적 안전은 올라가고, 번아웃은 줄며, 전반적인 신뢰성은 향상됩니다.
시작하기: 간단한 플레이북
거창한 프로그램 없이도 시작할 수 있습니다. 작게 시작해서 반복적으로 개선하세요.
-
하나의 하이 스테이크 시나리오를 고르기
현실적이고 영향력이 큰 것을 선택합니다. (예: “블랙 프라이데이 체크아웃 장애”) -
템플릿 확보하기
시나리오, 비즈니스 영향, 타임라인 프롬프트, 역할, 목표를 포함한 간단한 가이드를 찾거나 만듭니다. -
60분짜리 세션을 잡기
퍼실리테이터 1명, 엔지니어 몇 명, 가능하다면 지원/프로덕트 담당을 포함합니다. -
연습을 돌리고 디브리핑하기
3–5개의 구체적인 개선 항목을 반드시 남깁니다.
(예: “SEV-1 인시던트 선언용 런북 작성”, “상태 페이지 업데이트 체크리스트 추가” 등) -
반복과 로테이션
다음 달에는 시나리오와 참가자를 바꾸세요. 시간이 지나면 테이블탑 익서사이즈 백로그를 만들고, 각 연습이 어떤 개선을 이끌어냈는지 추적합니다. -
자동화로의 브리지 만들기
패턴이 보이기 시작하면, 어떤 시나리오를 AWS FIS, Chaos Monkey 같은 도구를 이용한 실험으로 옮길지 결정합니다.
결론: 도구를 돌리기 전에 회전목마부터 돌려라
하이 스테이크 인시던트는 피할 수 없습니다. 하지만 준비되지 않은 상태로 맞이하는 것은 선택입니다.
종이 기반 카오스 드릴과 테이블탑 익서사이즈는 안전하고 저렴한 방식으로 장애를 리허설하고, 약한 고리를 드러내며, 팀의 공동 자신감을 쌓을 수 있게 해줍니다. 프로덕션에서 패킷을 한 번이라도 드롭하거나 인스턴스를 하나라도 날려 보기 훨씬 전 단계에서 말이죠.
먼저 종이에서 시작하세요. 시스템, 프로세스, 커뮤니케이션이 어디에서 취약한지 파악하세요. 그리고 나서야 AWS Fault Injection Simulator나 Chaos Monkey 같은 도구를 통해 자동화 단계로 나아가도 늦지 않습니다.
**종이부터 시작하는 카오스 회전목마(Paper-First Chaos Carousel)**를 정기적인 관행으로 만들고, 참가자를 순환시키며, 리더십이 눈에 보이게 지원하도록 한다면, 단지 기술적 신뢰성만 좋아지는 것이 아닙니다. 문제가 생겼을 때 모두가 무엇을 해야 하는지 알고, 그 무게를 누구 하나가 홀로 짊어지지 않아도 되는, 더 건강하고 탄탄한 인시던트 문화를 만들 수 있습니다.