소개

디지털 시스템은 이상하고 불편한 방식으로 고장 납니다. 하드웨어는 죽고, 의존성은 타임아웃 나고, 네트워크는 분리되고, 사람은 잘못 클릭하고, 자격 증명은 유출되고, 백그라운드 잡은 조용히 멈춥니다. 대부분의 팀은 이런 사실을 머리로는 알고 있지만, 여전히 탄력성을 "있으면 좋은 것" 정도로 취급하며 장애가 난 뒤에야 다루곤 합니다.

카오스 엔지니어링은 여기에 의도적으로 실패를 주입함으로써 접근 방식을 뒤집습니다. 실제 운영 환경과 유사한 시스템에 실패를 인위적으로 일으켜, 사용자보다 먼저 취약점을 발견하는 것이죠. 하지만, 개별 실험만 돌리는 것만으로는 충분하지 않습니다. 진짜로 탄력성을 향상시키려면, 팀이 공유하는 맥락, 반복 가능한 학습, 그리고 신뢰성을 일급 요구사항으로 대하는 문화를 만들어야 합니다.

바로 여기서 종이 신뢰성 관측 벽(Paper Reliability Observatory Wall) 이 등장합니다.

이 글에서는 카드, 다이어그램, 실험이 빼곡히 붙어 있는 단순한 물리적 벽이 어떻게 카오스 엔지니어링을 손으로 만질 수 있는 팀 의식으로 바꾸어, 코드·시스템·사람을 연결하는지 살펴봅니다. 이를 통해 다음과 같은 것들을 어떻게 할 수 있는지 볼 수 있습니다.

• 탄력성을 눈에 보이고, 실행 가능한 형태로 만들기
• 기능/조직 간 협업을 자연스럽게 촉진하기
• 인시던트와 카오스 실험을 지속적인 학습 엔진으로 전환하기
• 순수 기술적 실패를 넘어, 인간이 만들어내는 위협 시나리오까지 사고를 확장하기

탄력성 실천으로서의 카오스 엔지니어링

카오스 엔지니어링은 단순히 재미로 시스템을 망가뜨리는 일이 아닙니다. 현실 세계의 난기류 속에서도 시스템이 버틸 수 있다는 정당화된 자신감을 구축하는 일입니다.

핵심적으로, 카오스 엔지니어링은 다음을 의미합니다.

1. “정상” 혹은 “안정 상태(steady state)”가 무엇인지 정의한다. (예: 에러율, 지연 시간, 처리량 등)
2. 특정 실패 상황에서 시스템이 어떻게 동작할지 가설을 세운다.
3. 운영 혹은 운영 유사 환경에서 통제된 실패를 주입한다.
4. 시스템이 예상한 대로 동작하는지 관찰한다.
5. 그 결과를 설계·자동화·운영 개선에 반영한다.

중요한 점은, 카오스 엔지니어링은 탄력성을 하나의 요구사항으로 간주한다는 것입니다. 부수적인 효과가 아닙니다. 기능 정확성이나 성능을 테스트하듯, 장애 상황에서도 허용 가능한 서비스 품질을 유지할 수 있는지를 테스트합니다.

그러나 많은 조직은 여전히 탄력성을 이렇게 취급합니다.

• 명확하고 검증 가능한 목표가 아닌, 모호한 성질 정도로 여기거나
• “SRE 팀”의 책임으로 돌리고, **공동 소유(shared ownership)**로 보지 않거나
• 인시던트 이후에만 반응적으로 다루고, 선제적인 학습 실천으로 만들지 못합니다.

종이 신뢰성 관측 벽은 이러한 격차를 해소하도록 설계되었습니다.

왜 신뢰성을 ‘손에 잡히게’ 그리고 ‘눈에 보이게’ 만들어야 할까?

디지털 작업은 도구 안에서 이뤄집니다. 대시보드, 위키, 런북, 티켓 시스템 등. 이 도구들은 필수적이지만, 동시에 주의를 분산시킵니다. 중요한 신뢰성 관련 지식은 종종 다음과 같이 여기저기 흩어져 있습니다.

• Grafana 대시보드
• Jira 보드
• 인시던트 후 보고서
• Slack 채널
• 어딘가 폴더에 박혀 있는 아키텍처 다이어그램

물리적인 벽은 이 모든 지식이 한데 모이는 단일의, 지속적인 표면이 될 수 있습니다. 이 벽은 다음을 만들어냅니다.

• 공유된 맥락 – 모두가 동일한 위험, 실험, 인시던트, 학습 내용의 지도를 함께 봅니다.
• 낮은 마찰의 협업 – 사람들은 자연스럽게 벽 앞에 모입니다. 질문을 유도하고, 기여를 초대합니다.
• 눈에 보이는 진행 중인 일(work-in-progress) – 신뢰성이 더 이상 추상적인 “품질”이 아니라, 지금 무엇을 탐색·테스트·수정하고 있는지가 드러납니다.
• 의식을 위한 앵커 – 벽 앞에서 정기적으로 모이는 세션이 카오스 실험과 리뷰의 리듬이 됩니다.

하이브리드나 원격 환경이라면, 디지털 화이트보드로 이 개념을 흉내 낼 수도 있습니다. 다만 초기에는 실제 종이와 마커를 사용하면, 의식 자체가 훨씬 더 ‘몸으로 느껴지고’ 참여감이 높아지는 경우가 많습니다.

종이 신뢰성 관측 벽이란 무엇인가?

이 벽을 시스템 탄력성을 위한 **살아 있는 관측소(living observatory)**라고 생각해 보세요. 최소한 다음 요소들이 시각적으로 연결되어야 합니다.

1. 시스템 맵(System Map)

   • 서비스, 데이터 저장소, 큐, 외부 의존성을 포함한 상위 수준 아키텍처 다이어그램
   • 주요 사용자 여정과 크리티컬 패스

2. 탄력성 요구사항(Resilience Requirements)

   • SLO/SLA: 지연 시간, 가용성, 에러 버짓 등
   • 명시적인 탄력성 가정 (예: “체크아웃은 하나의 리전이 장애 나도 동작해야 한다”)

3. 카오스 실험(Chaos Experiments)
   각 실험마다 다음을 적은 간단한 카드:

   • 가설: “X가 실패해도, Y는 여전히 동작할 것이다.”
   • 주입한 실패: 네트워크 파티션, 파드 종료, 의존성 성능 저하 등
   • 범위와 안전장치: 어디서·언제·어떻게 블라스트 반경(blast radius)을 제한할지
   • 결과: 통과/실패 및 핵심 관찰 사항

4. 인시던트 & 포스트모템(Incidents & Postmortems)

   • 최근 인시던트에 대한 짧은 요약: 원인, 영향, 탐지, 대응
   • 핵심 학습 내용과 개선 항목
   • 상세 보고서로 연결되는 링크(QR 코드, 단축 URL 등)

5. 위험 & 시나리오 백로그(Risk & Scenario Backlog)

   • 아직 테스트하지 못한 “만약 ~라면?” 질문 목록
   • 순수 기술적 시나리오뿐 아니라, 인간 위협(human-threat) 시나리오도 포함

6. 개선 사항 & 상태(Improvements & Status)

   • 실험이나 인시던트에서 파생된 신뢰성 개선 카드
   • 단순한 상태 표시: 탐색 예정(To Explore) → 실험 중(In Experiment) → 수정 중(Fixing) → 검증 완료(Verified)

시간이 지나면 이 벽은 하나의 시각적 스토리가 됩니다. 우리가 기대했던 것, 실제로 벌어진 일, 무엇이 깨졌고, 무엇을 고쳤으며, 아직 무엇을 이해하지 못했는지에 대한 이야기입니다.

카오스 엔지니어링을 팀 의식으로 만드는 방법

이 벽은 **반복 가능한 의식(ritual)**의 중심에 있을 때 가장 큰 힘을 발휘합니다. 바로 적용할 수 있는 구체적인 패턴을 소개합니다.

1. 주간 혹은 격주 “카오스 랩(Chaos Lab)” 세션

정기적인 60~90분짜리 세션을 잡습니다. 참여자는 다음을 포함하는 것이 좋습니다.

• 핵심 서비스를 담당하는 개발자
• SRE / 운영 엔지니어
• 보안 또는 DevSecOps 담당자
• 주요 사용자 흐름을 책임지는 일부 PO/PM

예시 아젠다는 다음과 같습니다.

1. 지난 실험 리뷰 (벽 앞에서)

   • 시스템은 예상대로 동작했는가?
   • 뜻밖의 메트릭 변화나 연쇄 효과는 없었는가?

2. 최근 인시던트 리뷰

   • 탐지·대응·보호 장치에 대해 무엇을 배웠는가?
   • 어떤 가정이 잘못되어 있었는가?

3. 다음 실험(들) 선정

   • 위험 백로그에서 뽑되, 현재 비즈니스/기술 우선순위와 정렬
   • 카드에 가설, 블라스트 반경, 성공 기준을 명시

4. 담당자와 실행 시점 지정

   • 누가 실행할 것인가? 온콜과는 어떻게 조율할 것인가?
   • 롤백 또는 중단(Abort) 플랜은 무엇인가?

5. 개선 항목 업데이트

   • 시작된/완료된 수정 사항 표시
   • 필요 시 후속 실험 카드 추가

이런 세션을 통해 카오스 엔지니어링은 부업(side project)이 아니라, 시스템을 위한 **지속적인 학습 실험실(learning lab)**로 자리 잡게 됩니다.

2. 인시던트 이후, 벽 앞에서 배우기

인시던트가 발생하면, 후속 작업에는 반드시 벽 앞에서 하는 세션이 포함되어야 합니다.

• 어떤 일이 있었는지 요약한 인시던트 카드를 추가합니다.
• 실험·서비스·이전 인시던트와 실/선, 색상 코딩 등으로 연결합니다.
• **격차(gap)**를 식별합니다: 빠졌던 알람, 잘못된 가정, 취약한 완화책 등.
• 이 격차를 기반으로 새로운 실험 카드와 개선 카드들을 만듭니다.

이렇게 하면 포스트모템 보고서가 정적인 문서로 끝나지 않습니다. 대신 그 인사이트가 곧바로 진행 중인 카오스 프로그램으로 흘러들어갑니다.

머신을 넘어서: 인간 위협(Human-Threat) 시나리오 포함하기

많은 카오스 실험은 주로 기술적 실패에 초점을 맞춥니다.

• 노드 또는 파드 장애
• 네트워크 지연 또는 파티션
• 데이터베이스 장애
• 트래픽 급증

이런 것들은 매우 중요하지만, 전체 그림은 아닙니다. 실제 인시던트에는 자주 인간 요인이 얽혀 있습니다.

• 급한 일정에 쫓겨 엔지니어가 잘못 푸시한 설정
• 과도하게 넓은 권한 설정
• 유출된 자격 증명 또는 탈취된 계정
• 특권을 가진 내부자의 악의적인 행동

카오스 실천 안에 인간 위협 시나리오를 포함하면, 신뢰성에 대한 사고 폭이 넓어집니다.

• 신뢰받는 DevOps 엔지니어의 자격 증명이 탈취된다면?
• 관리자 권한을 가진 누군가가 중요한 리소스를 삭제한다면?
• 엔지니어가 의도적으로 보안 통제를 우회하려 한다면?

실제 운영 환경에서 진짜 악의적 행위를 그대로 시뮬레이션할 필요는 없습니다. 대신, 통제된 테이블탑(tabletop) 연습이나 스테이징 환경 기반 연습을 설계할 수 있습니다.

• 스테이징/테스트 환경에서, “레드팀” 역할을 맡은 엔지니어가 권한을 악용해 보려는 롤플레이를 진행합니다.
• 로그와 알람을 활용해 비정상적인 관리자 행동을 얼마나 잘 탐지할 수 있는지 테스트합니다.
• 접근 권한 회수와 자격 증명 회전(rotate)을 얼마나 빠르게 수행할 수 있는지 연습합니다.

이런 시나리오 역시 기술적 실험과 동일하게 벽에 표현합니다.

• 가설: “관리자가 Service X에서 데이터를 유출하려는 시도가 있을 경우, Y분 이내에 탐지·차단할 수 있다.”
• 실패 모드: 인프라 오류가 아니라 비정상적인 인간 행동
• 결과 및 학습: 모니터링, 감사 로그, 접근 제어에서의 공백

인간 위협 시나리오를 1급 카오스 실험으로 다룸으로써, 보안·운영·신뢰성을 아우르는 탄력성 사고방식을 기를 수 있습니다.

신뢰성을 ‘테스트 가능한 요구사항’으로 만들기

카오스 엔지니어링이 무작위 혼란 야기 활동이 되지 않으려면, 명시적이고 테스트 가능한 탄력성 요구사항에 기반해야 합니다.

• 핵심 사용자 여정과 허용 가능한 성능 저하 수준을 정의합니다.
• 탄력성 가정을 명확히 표현합니다. 예를 들면:
  • “체크아웃은 단일 리전 장애 시에도 동작해야 한다.”
  • “백그라운드 분석 작업은 최대 1시간까지 지연될 수는 있지만, 데이터 손실은 안 된다.”
  • “관리자 작업은 실행 후 5분 내에 감사 가능해야 한다.”

벽 위에서는 각 요구사항을 다음과 연결합니다.

• 이미 수행된 관련 카오스 실험
• 아직 검증하지 못한, 앞으로 필요한 실험
• 해당 요구사항이 깨졌던 인시던트 카드

시간이 지나면, 단순히 “뭐라도 다 테스트해 보자”는 수준이 아니라, 비즈니스 기대 → 탄력성 요구사항 → 실제 실험 → 관찰된 시스템 행위로 이어지는 **추적 가능한 링크(traceability)**를 만들어 가게 됩니다.

이렇게 할 때 신뢰성은 뒷북 치는 고려사항이 아니라, 시스템의 관리되고 측정 가능한 속성이 됩니다.

장기적인 조직 탄력성 구축하기

종이 신뢰성 관측 벽의 진짜 가치는 문구류에 있지 않습니다. 이 벽이 키우는 문화에 있습니다.

• 공동 소유(Shared ownership) – 개발, 운영, 보안이 신뢰성을 서로 떠넘기지 않고, 공동 책임으로 인식합니다.
• 지속적인 학습(Continuous learning) – 인시던트와 실험이 비난의 재료가 아니라, 개선을 위한 원자재가 됩니다.
• 시스템적 사고(Systemic thinking) – 코드, 인프라, 프로세스, 사람 사이의 상호작용을 입체적으로 바라보게 됩니다.
• 예측적 사고(Predictive mindset) – “우리는 지금 무엇을 가정하고 있는가? 그것이 어떻게 깨질 수 있는가?”라는 질문을 점점 더 잘 던지게 됩니다.

의식이 자리를 잡으면, 이런 부수 효과들도 눈에 띄기 시작합니다.

• 장애 모드와 실패 시나리오를 더 잘 고려하는 설계 리뷰
• 제품 논의에서 신뢰성과 보안의 트레이드오프까지 함께 다루는 문화
• 이미 통제된 환경에서 여러 번 실패를 경험해 본 덕분에, 온콜 엔지니어가 더 준비되어 있고 덜 불안해하는 상황

맺음말

탄력성은 선한 의도나 멋진 대시보드만으로 생기지 않습니다. 의도적인 연습의 결과물입니다. 가정을 체계적으로 드러내고, 실험을 수행하고, 인시던트에서 배우고, 그 배움을 개선으로 고정시키는 과정에서 탄력성이 만들어집니다.

종이 신뢰성 관측 벽은 이러한 실천을 돕는, 놀랄 만큼 단순한 도구입니다. 카오스 엔지니어링을 손에 잡히고 눈으로 보이게 함으로써, 여러분은 다음을 이룰 수 있습니다.

• 흩어진 지식을 공유된 이해로 통합하기
• 팀 전체가 함께 참여하는 반복 가능한 신뢰성 의식을 만들기
• 기술적 실패와 인간 위협 시나리오를 하나의 학습 프레임워크 안에 통합하기
• 탄력성을 구체적이고 테스트 가능한 요구사항 수준으로 끌어올리기

작게 시작해 보세요. 벽 하나를 정하고, 시스템 개략도를 그려 붙이고, 두세 개의 카오스 실험 카드를 추가한 뒤, 첫 번째 “카오스 랩” 세션을 잡습니다. 시간이 지나면서, 그 종이 벽은 여러분의 소프트웨어가 이미 살고 있는 혼란스러운 현실을 헤쳐 나가는 데 있어 가장 강력한 도구 중 하나가 될 수 있습니다.