카오스 엔지니어링은 "파괴"가 아닌 "검증"이다
- 년대에 Netflix가 Chaos Monkey를 공개했을 때, 카오스 엔지니어링은 "프로덕션 환경을 무작위로 파괴하는 과격한 프랙티스"로 받아들여졌습니다. 그 문화적 임팩트는 컸지만, 동시에 오해도 낳았습니다——프로덕션에서 폭탄을 투척하기 위해서는 조직적 성숙이 필요하며, 대부분의 기업에게는 허들이 너무 높았습니다.
- 년의 도달점은 명확합니다. 카오스 엔지니어링은 "파괴하는 기술"이 아니라 "레질리언스를 검증하는 규율"이며, 그 본질은 "장애를 상정한 설계가 실제로 상정대로 동작하는지를 과학 실험으로 확인한다"는 것입니다. 가설을 세우고, 작게 시험하고, 관측하고, 개선합니다. 이 PDCA를 돌리는 활동 전체가 chaos engineering입니다. 일본 기업에서 널리 참조되어 온 TPM(전원 참가의 예방 보전)이나 FMEA(고장 모드 영향 해석)의 연장선상에 있다고 파악하면 도입 설명이 쉬워집니다.
툴 선정: Gremlin / LitmusChaos / Chaos Mesh
- 년 시점의 주요 툴은 세 가지로 나뉩니다. Gremlin은 상용 SaaS의 강자로, SRE 팀이 없는 조직에서도 안전하게 도입할 수 있는 "Blast Radius(영향 범위) 제어"와 "Halt 조건"이 세일즈 포인트입니다. 네트워크 지연, CPU 과부하, 디스크 I/O 고갈, 존 장애 등 표준 공격이 수십 종류 준비되어 있으며, Web UI에서 몇 번의 클릭으로 실험을 시작할 수 있습니다. 금융이나 통신처럼 "규제 대응으로서 chaos engineering 프로그램이 필요한" 경우에 강합니다.
LitmusChaos는 CNCF Graduated 프로젝트로, Kubernetes 네이티브의 OSS입니다. Chaos Experiment를 CRD로 정의하고, ChaosHub에서 커뮤니티 실험을 가져올 수 있습니다. GitOps 연계가 탁월하여 Argo CD와 조합하여 "실험을 Git에서 선언하고, Argo Workflows로 실행하며, Prometheus로 메트릭을 검증하고, 실패 시에는 자동 rollback"이라는 완결된 파이프라인을 구성할 수 있습니다. SRE 팀의 규율이 정비된 조직에 적합합니다.
Chaos Mesh는 PingCAP 발의 CNCF Incubating 프로젝트로, Kubernetes 위에서의 세밀한 장애 주입에 특화됩니다. PodChaos, NetworkChaos, IOChaos, TimeChaos, DNSChaos 등의 CRD가 충실하며, 특히 NTP 어긋남이나 DNS 오염 같은 "다른 툴로는 어려운 저수준 장애"를 재현할 수 있습니다. Chaos Dashboard의 UX도 뛰어나 LitmusChaos보다 학습 비용이 낮습니다.
Kubernetes에서의 실시: 실험의 3계층 모델
Kubernetes 환경에서는 실험을 3계층으로 나누어 운용하는 것이 표준 패턴이 되었습니다. 제1계층은 "Pod 레벨". PodChaos로 특정 Deployment의 Pod를 하나 kill하여, HPA나 서비스 메시의 재시도·서킷 브레이커가 상정대로 동작하는지 확인합니다. 영향 범위가 최소이며 매일 자동 실행할 수 있습니다.
제2계층은 "Node 레벨". NodeChaos로 AZ 내의 한 노드를 drain하여, Pod Disruption Budget과 재배치가 기능하는지 확인합니다. 주별 실행이 목표입니다. 제3계층은 "리전/AZ 레벨"로, NetworkChaos로 존 간 통신을 차단하여, 멀티 AZ 구성의 페일오버를 검증합니다. 분기의 game day에서 실시하는 규모입니다.
- 년의 현장에서는 제1·제2계층은 완전 자동화(CI 파이프라인에 편입)하고, 제3계층만 사람이 개재하는 game day로 남기는 설계가 주류입니다. 자동화 부분은 GitHub Actions나 Tekton에서 LitmusChaos를 호출하고, SLO 대시보드와 연동하여 "SLO 위반이 감지되면 실험을 자동 정지"하는 halt 조건을 반드시 붙입니다.
Multi-Region Failover의 검증
복수 리전 구성을 가진 서비스에서는 연 1~2회의 "리전 전환 game day"가 사실상의 필수 프랙티스가 되었습니다. 방법은 세 단계입니다. 우선 현재 리전에서 DNS 트래픽을 단계적으로 부 리전으로 전환합니다(10% → 50% → 100%). 각 단계에서 SLI가 저하되지 않았는지 확인하고, 저하되면 rollback. 100% 이행 후, 현재 리전을 의도적으로 네트워크 차단(NetworkChaos의 partition)하여, 부 리전이 단독으로 버틸 수 있는지를 수 시간 관찰합니다.
이 game day에서 자주 발견되는 것은 (1) 부 리전의 용량 부족(평상시에는 저트래픽으로 다루고 있기 때문에 HPA 상한이 부족하다), (2) 데이터베이스 레플리카 지연 스파이크(쓰기 집중으로 레플리카가 뒤처진다), (3) 서드파티 API의 리전 제약(특정 리전에서 호출할 수 없거나, 레이트 제한이 엄격하다)의 세 가지입니다. 사전에 상정하기 어려운 문제뿐이며, game day에서 실증하지 않으면 실제 재해에서 처음으로 표면화됩니다.
일본 기업의 문화적 과제: "계획 정전" vs "프로덕션 카오스"
카오스 엔지니어링 도입에서 가장 심각한 장벽은 기술이 아니라 문화입니다. 일본 기업에는 "계획 정전(사전 고지 후 단시간 서비스 정지)"의 문화는 있지만, "프로덕션에서 가동 중인 시스템에 의도적으로 장애를 주입한다"는 것에 대한 저항이 강합니다. "프로덕션을 망가뜨리다니 무슨 짓인가"라는 임원의 반응은 드물지 않습니다.
이 장벽을 넘기 위한 실무적 전술은 세 가지입니다. 첫 번째로, 처음에는 "비프로덕션 환경에서의 chaos"부터 시작합니다. Staging 환경에서 매일 PodChaos를 돌려, 릴리스 전에 SLO를 검증하는 문화를 만듭니다. "프로덕션에서는 하지 않습니다"라고 설명할 수 있는 상태에서 반년~1년의 실적을 쌓습니다.
두 번째로, 프로덕션 도입 시에는 "기존의 계획 정전 구역"을 활용합니다. 월별 유지보수 윈도우에서 소규모 chaos를 실시하고, "계획 정전의 일환"으로 위치시킵니다. 이로써 임원 레벨의 승인 프로세스를 새로 만들 필요가 없어집니다.
세 번째로, game day를 "훈련"으로 브랜딩합니다. "장애 대응 훈련" "BCP 연습"이라고 부르면, 품질 관리 부서나 내부 감사 부서에서 오히려 평가받습니다. 실제로 game day는 ISO 22301(사업 계속성)이나 FISC 안전 대책 기준의 연습 요건을 충족하는 근거로 사용할 수 있습니다.
성숙도와 다음 단계
Chaos Engineering Maturity Model(Casey Rosenthal 제창, 2026년 개정판)에서는 성숙도가 Level 1(ad hoc 실험)부터 Level 5(프로덕션 완전 자동·지속 실행)까지 정의되어 있습니다. 일본 기업의 대부분은 Level 2(staging에서 정기 실험)에서 Level 3(프로덕션에서 game day)으로의 이행 단계에 있습니다. Level 4(프로덕션 자동 실험)로의 이행에는 SLO·Error Budget·observability 3종 세트가 완비되어 있을 것이 전제이며, 이전 글에서 언급한 multi-window multi-burn-rate가 기능하고 있는 것이 사실상의 필요 조건입니다.
KGA IT에서는 고객의 SRE 성숙도 진단 안에서 "chaos engineering 도입 로드맵"을 6~18개월 단위로 설계하고 있습니다. 문화적 장벽을 넘는 순서가 기술 선정보다 중요하며, Gremlin이냐 LitmusChaos냐의 선택은 실은 후반의 논점입니다.