소개

대부분의 팀은 시스템의 가장 약한 고리를 실제 프로덕션 장애가 터져야만 알게 됩니다.

장애가 발생하고, (제대로 되어 있다면) 알람이 울리고, 모두가 워룸으로 뛰어들어가 압박 속에서 다음과 같은 사실을 뒤늦게 발견합니다.

• 폴백(fallback) 로직이 실제로는 동작하지 않는다.
• 있다고 믿었던 대시보드에 핵심 지표가 빠져 있다.
• 런북(runbook)이 오래됐거나, 아예 없다.

이런 약점을 사용자에게 피해가 가기 전에, 의도적으로 그리고 안전하게 찾을 수 있다면 어떨까요?

여기서 등장하는 것이 바로 실패 샌드박스 캘린더(Failure Sandbox Calendar) 입니다.

카오스 엔지니어링을 대기업만 할 수 있는 일회성 쇼처럼 보지 말고, 작은 팀도 아주 작은 실패 실험을 정기적으로 안전한 환경에서 수행할 수 있습니다. 시간이 지나면서 이 실험들은 프로덕션 시스템을 점점 더 단단하게 만들고, 런북을 개선하며, 회복 탄력성이 일상적인 루틴이 되는 문화를 만듭니다.

이 글에서는 실패 샌드박스 캘린더를 어떻게 설계하는지, 어떤 종류의 실험을 하면 좋은지, 그리고 이 실천을 팀이 신뢰할 수 있는 살아있는 지식 베이스로 어떻게 발전시킬 수 있는지 설명합니다.

실패 샌드박스 캘린더란 무엇인가?

실패 샌드박스 캘린더(Failure Sandbox Calendar) 의 핵심 아이디어는 간단하지만 강력합니다.

격리된 환경에서 수행하는 작고 통제된 실패 실험을 정기적으로 스케줄링하고, 각 실험을 꼼꼼히 기록해 프로덕션 시스템 개선에 직접 활용하는 것.

세 가지 핵심 요소가 있습니다.

1. 샌드박스(Sandbox) – 다음 조건을 만족하는 환경

   • 실제 사용자와 완전히 격리되어 있고
   • 프로덕션과 최대한 유사한 설정(구성, 서비스, 데이터 형태)을 가지며
   • 망가뜨리고, 재시작하고, 일부러 깨트려도 되는 안전한 환경

2. 실패 실험(Failure Experiments) – 의도적이고 범위가 제한된 테스트 예시:

   • 데이터베이스 장애를 시뮬레이션
   • 핵심 API에 인위적인 지연(latency) 추가
   • 특정 의존성 서비스를 꺼보기
   • 리소스(CPU, 메모리, 디스크, 네트워크) 스로틀링

3. 캘린더(Calendar) – 반복되는 시간 슬롯(예: 매주 화요일 60분)으로, 이 시간 동안 팀은

   • 하나의 작은 실험을 수행하고
   • 관찰하고 측정하며
   • 발견 사항과 후속 작업을 문서화합니다.

거대한 카오스 플랫폼도, 전담 SRE 팀도 필요 없습니다. 필요한 것은 작지만 꾸준한 연습뿐입니다.

작은 팀일수록 카오스 엔지니어링이 더 필요하다

카오스 엔지니어링은 흔히 FAANG급 대기업만 할 수 있는 럭셔리처럼 들립니다. 하지만 현실에서는 작은 팀이 훨씬 더 큰 이득을 볼 수 있습니다. 이유는 다음과 같습니다.

• 모든 장애가 훨씬 더 아프게 다가옵니다. 한 번의 장애가, 제한된 개발 리소스와 신뢰를 크게 소모합니다.
• 싱글 포인트 오브 페일러(Single Point of Failure)가 흔합니다. 중요한 지식과 결정 권한이 소수 인원에게 몰려 있습니다.
• 낭비할 여유가 없습니다. 예방 가능했던 프로덕션 이슈를 쫓느라 쓰는 한 시간이 곧 기능 개발을 못 하는 한 시간입니다.

작은 규모라도 카오스 엔지니어링을 정기적인 워크플로우에 녹여 넣으면:

• 고객보다 먼저 실패 모드를 발견해 안정성(stability) 이 개선되고,
• 통제된 방식으로 실패 대응을 연습해 안전성(safety) 이 높아지고,
• 알람과 런북을 다듬어 장애 대응 시간을 줄이니 효율성(efficiency) 도 좋아집니다.

핵심은 스코프(scope) 입니다. 데이터센터 절반의 전원을 뽑는 것이 아니라, 아주 작은, 점진적인 테스트를 통해 약점을 드러내고 바로 개선으로 이어지게 만드는 것입니다.

효과적인 샌드박스 실험의 원칙

실제로 도움이 되면서도 불필요한 위험을 피하려면, 다음 원칙을 기반으로 실험을 설계해야 합니다.

1. 작고, 잘 통제된 범위

각 실험은 좁고 명확하게 정의되어야 합니다. 예를 들어:

• 좋은 예: “사용자 서비스가 2분 동안 다운되면 어떻게 될까? 우아하게 강등(degrade)되는가?”
• 나쁜 예: “그냥 랜덤하게 여기저기 죽여 보면서 무슨 일이 일어나는지 보자.”

반드시 정의해야 할 것들:

• 목표로 하는 컴포넌트 (예: auth 서비스, 주문 API 등)
• 실패의 타입 (지연, 완전 장애, 리소스 고갈, 잘못된 데이터 등)
• 시간 제한 (예: 5–10분)
• 성공 기준 (어떤 상태를 ‘탄탄하다/회복력 있다’라고 볼 것인지)

2. 점진적이고 반복 가능할 것

실험을 테스트 스위트의 버전 업처럼 바라보세요.

• 먼저 영향이 적은 실패(예: 지연 증가)부터 시작합니다.
• 자신감이 붙을수록 강도와 범위를 조금씩 늘립니다.
• 동일한 실험을 나중에 다시 수행해, 실제로 수정이 효과가 있었는지 검증합니다.

3. 설계 단계에서부터 안전할 것

샌드박스라고 해도 무작정 해서는 안 됩니다. 의도적으로 설계해야 합니다.

• 비프로덕션 데이터를 사용하거나, 실제 데이터는 적절히 마스킹/비식별 처리합니다.
• 파괴적인 도구에는 제한된 접근 권한과 퍼미션을 적용합니다.
• 명확한 중단 조건(abort condition) 을 정의합니다. 예: “X 현상이 보이면 실험을 즉시 중단한다.”

4. 반드시 관찰하고 측정할 것

관찰 없이 하는 실패 실험은 그저 재미로 부수는 것과 다를 바 없습니다.

다음 질문에 답할 수 있어야 합니다.

• 메트릭, 로그, 트레이스에는 무엇이 보였는가?
• 알람은 울렸는가? 유용했는가, 아니면 노이즈였는가?
• 장애를 탐지하는 데 걸린 시간, 상황을 이해하는 데 걸린 시간, 복구하는 데 걸린 시간은 얼마나 됐는가?

실패 샌드박스 설계하기

프로덕션을 완벽하게 복제할 필요는 없지만, 믿을 수 있는(credible) 환경은 필요합니다.

1. 환경 구성(Environment Setup)

   • 전용 환경을 사용합니다. 예: sandbox, staging-chaos 등.
   • 가능한 한 프로덕션과 유사한 아키텍처(서비스, 메시지 큐, 스토리지, 설정)를 구성합니다.
   • 현실적인 데이터 볼륨과 데이터 형태를 시드합니다.

2. 접근 권한과 도구(Access and Tooling)

   • 엔지니어가 안전하게 다음을 할 수 있도록 합니다.
     • 서비스 kill / restart
     • 지연(latency)과 에러 주입
     • CPU/메모리/디스크 스로틀링
   • 처음에는 단순한 도구로 시작해도 충분합니다: 셸 스크립트, 피처 플래그, 로드 제너레이터 등.
   • 필요성이 명확해지면 상용/전문 카오스 툴을 도입해도 됩니다.

3. 가드레일(Guardrails)

   • 무엇은 허용되고, 무엇은 금지인지(예: 실제 결제 프로세서는 절대 건드리지 않기)를 명확히 정합니다.
   • 첫날부터 로깅과 모니터링을 반드시 켜 둡니다.

샌드박스는 팀이 안전하게 망가뜨리는 법을 배우는 곳입니다. 그리고 실제 사용자가 알아차리기 전에 그 문제를 고치는 곳이기도 합니다.

카오스를 ‘캘린더 습관’으로 만들기

이 실천이 진짜로 자리 잡는 지점은 바로 “캘린더” 입니다.

1단계: 반복 시간 슬롯 정하기

작지만 고정된 타임박스를 잡습니다. 예를 들어:

• 매주(Weekly): 30–60분
• 격주(Bi-weekly): 60–90분

캘린더에 반복 미팅으로 등록하세요: “Failure Sandbox Session(실패 샌드박스 세션)”. 그리고 다음과 같이 취급합니다.

• 스프린트 세리머니나 계획 회의와 동급으로
• 웬만해서는 취소하지 않는 약속으로

2단계: 단순한 세션 구조 정의하기

전형적인 60분 세션 예시는 다음과 같습니다.

1. (10분) 실험 계획 수립

   • 어떤 실패를 시뮬레이션할 것인가?
   • 우리가 기대하는 시스템의 반응은 무엇인가?
   • 무엇을 측정할 것인가?

2. (20–30분) 실험 실행

   • 샌드박스에 실패를 유도합니다.
   • 메트릭, 로그, 사용자 관점의 동작을 관찰합니다.
   • 실제 프로덕션 장애 시처럼 대응해 봅니다.

3. (15–20분) 회고 및 문서화

   • 실제로 일어난 일 vs 우리가 예상했던 일
   • 잘 동작한 것, 깨진 것, 헷갈렸던 것
   • 구체적인 후속 조치(티켓, 개선 작업) 도출

3단계: 책임 순환(rotating ownership)

카오스 엔지니어링이 특정 사람의 “남의 일”이 되지 않도록, 역할을 돌려 가며 맡깁니다.

• Experiment Owner(실험 오너): 해당 주 실험을 설계하고 실행 주도
• Observer(옵저버): 실험 중 일어나는 일들을 집중해서 기록
• Facilitator(퍼실리테이터): 시간 관리와 회고 진행

이렇게 하면 지식이 분산되고, 더 많은 사람이 시스템이 스트레스를 받을 때 어떻게 동작하는지 직관을 쌓게 됩니다.

첫 한 달을 위한 예시 실험들

여기서는 일반적인 웹/서비스 기반 제품을 가정하고, 4주짜리 스타터 프로그램을 제안합니다.

1주차: 서비스 장애(Service Outage)

• 시나리오: 인증(auth) 서비스를 5분간 종료시킵니다.
• 질문:
  • 이미 로그인한 사용자에게는 어떤 일이 벌어지는가?
  • 신규 사용자는 무엇을 보게 되는가?
  • 인증 실패에 대한 알람은 발동하는가?
• 발견할 수 있는 개선 포인트 예시:
  • “로그인에 문제가 있습니다.” 같은 UX 메시지 부재
  • 인증 에러율을 한눈에 볼 수 있는 대시보드 부재

2주차: 느린 의존성(Slow Dependency)

• 시나리오: 주요 데이터베이스나 외부 API에 2초의 지연을 인위적으로 추가합니다.
• 질문:
  • 타임아웃이 적절히 동작하는가?
  • UI는 우아하게 강등되나, 아니면 그냥 로딩 스피너만 계속 도는가?
  • 폴백(캐시된 데이터, 리드 레플리카 등)이 실제로 트리거되는가?

3주차: 잘못된 설정(Broken Configuration)

• 시나리오: 잘못된 설정(예: 오배선된(feature flag miswired) 피처 플래그)을 샌드박스에 배포합니다.
• 질문:
  • 미묘한(바로 티 나지 않는) 문제를 얼마나 빨리 감지할 수 있는가?
  • CI/CD 단계에서 잡았어야 할 설정 검증(Validation)이 빠져 있지는 않은가?

4주차: 부분 데이터 손실 시뮬레이션(Partial Data Loss)

• 시나리오: 작지만 비핵심적인 데이터셋 일부를 삭제하거나 손상시킵니다.
• 질문:
  • 서비스들은 누락된 데이터를 안전하게 처리하는가?
  • 에러 메시지와 로그는 도움이 되는가?
  • 복구 경로와 런북이 명확하게 존재하는가?

한 달이 지나면 팀은 다음과 같은 상태가 됩니다.

• 실제 약점을 몇 가지 찾아서 수정했을 것입니다.
• 비슷한 유형의 프로덕션 이슈를 다루는 데 자신감이 커졌을 것입니다.
• 작은 규모지만 점점 쌓여 가는 문서와 런북의 기반이 생겼을 것입니다.

실험을 살아있는 지식 베이스로 만들기

실험을 수행하는 것만이 전부는 아닙니다. 나머지 절반은 문서화입니다.

각 실험마다 최소한 다음을 기록하세요.

1. 실험 메타데이터(Experiment Metadata)

   • 날짜, 참여자, 사용한 환경
   • 시나리오 설명과 가설(우리가 기대한 동작)

2. 실행 세부 정보(Execution Details)

   • 실제로 수행한 단계(명령어, 사용한 도구, 변경한 설정 등)
   • 실험의 시간과 범위

3. 관찰 내용(Observations)

   • 메트릭, 로그, 사용자 관점 증상
   • 알람은 울렸는가? 유용했는가?
   • 탐지까지 걸린 시간, 이해하는 데 걸린 시간, 샌드박스 기준 ‘해결’까지 걸린 시간

4. 결과와 후속 조치(Outcomes and Follow-ups)

   • 잘 된 점
   • 깨졌거나, 예상 밖이었던 부분
   • 후속 액션 아이템: 알람 개선, 코드 변경, 문서 업데이트 등 티켓화

이 모든 것을 중앙에 모아둡니다.

• 위키에 “Failure Sandbox” 전용 섹션을 만들거나
• 실험당 문서 하나씩 두는 공유 폴더를 만들거나
• 실험과 결과를 정리한 가벼운 내부 사이트를 만들어도 좋습니다.

시간이 지나면 이것은 시스템이 스트레스를 받을 때 실제로 어떻게 동작하는지에 대한 살아있는 지식 베이스가 됩니다. 이건 종이에 그려 넣은 이론적인 아키텍처 다이어그램보다 훨씬 가치 있습니다.

문화적 효과: 소방 훈련에서 회복 탄력성 연습으로

실패 테스트를 정기적인 캘린더 이벤트로 다루면 팀 문화가 바뀝니다.

• 두려움에서 친숙함으로. 엔지니어들이 ‘실패’를 안전한 맥락에서 자주 보게 되면서, 장애에 대한 막연한 두려움이 줄어듭니다.
• 영웅담에서 시스템 사고로. 밤샘 복구보다, 위험을 줄이고 시스템을 튼튼하게 만든 사람을 더 높이 평가하게 됩니다.
• 일회성 훈련에서 지속적인 연습으로. 회복 탄력성이 개발 라이프사이클의 평범한 일부가 됩니다.

또한 팀 안에 공유 언어가 생깁니다.

• “이거 2주 차 레이턴시 이슈랑 비슷한데?”
• “저 경로는 지난달 샌드박스 세션에서 검증했어.”

이런 공유 컨텍스트는 실제 장애 대응 상황에서 엄청난 자산이 됩니다.

결론

카오스 엔지니어링을 실천하는 데 거대한 SRE 조직이나 복잡한 툴링은 필수 조건이 아닙니다.

실패 샌드박스 캘린더(Failure Sandbox Calendar) 를 도입하면, 작은 팀도 다음을 할 수 있습니다.

• 작고 통제된 주간 실패 실험을 꾸준히 수행하고
• 격리된 샌드박스에서 안전하게 ‘망가뜨려’ 보며
• 매번의 실험으로 가정(assumption)을 검증하고, 알람을 다듬고, 런북을 개선하며
• 시간이 지날수록 코드베이스를 단단하게 만드는 살아있는 지식 베이스를 쌓을 수 있습니다.

아주 작게 시작하세요. 주간 슬롯 하나를 정하고, 하나의 좁은 실패 시나리오를 골라, 배운 점을 문서화합니다. 다음 주에 또 반복합니다. 그다음 주에도요.

생각보다 빠르게, 이 작은 정기 실험들이 더 잔잔한 온콜, 더 적은 프로덕션 깜짝 이슈, 그리고 회복 탄력성을 ‘기대’가 아니라 ‘습관’으로 대하는 팀 문화를 만들어 줄 것입니다.