카오스 엔지니어링: 고의로 부수지 않으면 진짜 강해질 수 없다

카오스 엔지니어링: 고의로 부수지 않으면 진짜 강해질 수 없다

새벽 3시, 문자 알림 하나가 울렸다. "결제 서비스 응답 지연 발생." 반쯤 잠이 깬 상태로 노트북을 열었고, 그림자처럼 늘어선 에러 로그를 보며 한숨을 내쉬었다. 원인은 단순했다. 장애 조치(failover)가 자동으로 일어나지 않았다. 우리는 그걸 "설계엔 있었지만 실제론 안 된다"고 표현했다. 문서상으로는 완벽한 이중화였지만, 한 번도 실제로 검증해 본 적이 없었기 때문이다. 그날 이후 저는 "장애는 예방하는 게 아니라 예행연습으로 겪어보는 것"이라는 확신을 갖게 됐다. 그리고 그 확신의 끝에 카오스 엔지니어링이 있었다.

카오스 엔지니어링이란 무엇인가

카오스 엔지니어링은 시스템에 고의로 장애를 주입해 복원력을 검증하는 실험적 방법론이다. 넷플릭스가 2010년대 초반 자체 개발한 도구 "카오스 몽키(Chaos Monkey)"에서 시작됐다. 카오스 몽키는 무작위로 프로덕션 서버를 종료시키는 스크립트였다. 처음 들으면 미친 짓 같다. 왜 돌아가는 서비스를 일부러 끄나? 하지만 넷플릭스의 논리는 명확했다. "평소에 서버가 죽는 경험을 하면, 진짜 장애가 왔을 때 겁먹지 않는다." 이 철학이 저에게 와닿은 건, 앞서 말한 새벽 3시의 경험 때문이었다. 예상치 못한 장애가 가장 무서운 게 아니라, 대비하지 못한 장애가 가장 치명적이다.

장애는 언제 오는가

장애는 절대 편안한 시간에 오지 않는다. 트래픽이 가장 몰리는 시간, 인프라 업데이트 직후, 의존하는 외부 서비스가 멈추는 순간. 실제로 겪은 장애의 80%는 "이런 일은 일어나지 않을 거야"라고 생각했던 시나리오였다. 한 번은 DNS 설정이 꼬여서 전체 서비스가 40분간 다운됐고, 또 한 번은 클라우드 공급자의 가용 영역(AZ) 장애로 인해 장애 조치가 제대로 작동하지 않았다. 이런 일들은 테스트 환경에서는 절대 발견할 수 없다. 프로덕션 환경의 복잡성과 실제 트래픽 패턴은 로컬이나 스테이징에서 재현할 수 없기 때문이다. 그래서 카오스 엔지니어링은 프로덕션 환경에서, 실제 조건 속에서 수행될 때 진짜 의미를 갖는다.

작게 시작하는 게 핵심이다

카오스 엔지니어링을 도입할 때 가장 흔한 실수는 "처음부터 크게 부수겠다"는 것이다. 저도 처음엔 프로덕션에서 대규모 장애를 주입하려다가 팀원들의 강력한 반대에 부딪혔다. 당연한 반대였다. 카오스 엔지니어링은 점진적으로 시작해야 한다. 먼저 스테이징 환경에서 단일 인스턴스를 종료하는 실험부터 시작했다. 그 다음엔 네트워크 지연을 주입하고, 이어서 의존 서비스의 응답을 느리게 만들었다. 이 과정에서 발견한 문제가 열두 개가 넘었는데, 하나같이 "이거 진짜 장애였으면 큰일 날 뻔했다"는 것들이었다. 작은 실험이 모여 시스템 전체의 신뢰성을 만든다는 걸 몸으로 깨달은 순간이었다. 카오스 엔지니어링의 핵심은 "얼마나 크게 부수느냐"가 아니라 "얼마나 작게, 얼마나 자주, 얼마나 안전하게 부수느냐"에 있다.

게임 데이, 그리고 문화의 전환

카오스 엔지니어링에서 기술만큼 중요한 것이 "게임 데이(Game Day)"라는 문화다. 정기적으로 모여서 장애 시나리오를 실제로 실행해보는 날이다. 단순히 "이런 장애가 나면 이렇게 대처한다"는 문서를 읽는 게 아니라, 실제로 버튼을 누르고 시스템이 어떻게 반응하는지 지켜본다. 처음 게임 데이를 했을 때 가장 놀라운 건 "문서에 쓴 대로 작동하는 게 하나도 없다"는 사실이었다. 알림이 울리지 않고, 자동 복구가 작동하지 않고, 장애 조치가 수동 개입 없이는 일어나지 않았다. 그날 이후 우리는 문서를 고치는 게 아니라 시스템을 고치기 시작했다. 이것이 카오스 엔지니어링의 진짜 힘이다. "안다"는 것과 "검증됐다"는 것은 전혀 다르다. 게임 데이는 그 차이를 가장 뼈저리게 체감하게 해주는 시간이다.

자동화 없는 카오스는 의미 없다

카오스 엔지니어링은 한 번 하는 것으로 끝나지 않는다. 시스템은 계속 변하고, 새로운 의존성이 추가되고, 코드는 매일 바뀐다. 그래서 카오스 실험은 자동화되어야 한다. 저는 매주 자동으로 실행되는 카오스 테스트를 파이프라인에 넣었다. 매주 금요일 새벽, 무작위 인스턴스가 종료되고 시스템이 복구되는지 검증한다. 처음 몇 주는 실패가 이어졌지만, 점차 자동 복구 로직이 개선됐고, 3개월 후에는 장애가 나도 사용자가 느끼지 못하는 수준에 도달했다. "장애가 안 나는 시스템"은 환상이다. "장애가 나도 견디는 시스템"이 현실이고, 그 현실은 자동화된 카오스 실험이 만든다. 핵심은 실험을 CI/CD 파이프라인에 통합해, 사람이 개입하지 않아도 시스템이 스스로를 검증하게 만드는 것이다.

측정하지 않으면 실험이 아니다

카오스 엔지니어링에서 빠뜨리기 쉬운 부분이 "측정"이다. 장애를 주입하고 "됐다, 끝났다"가 아니라, 시스템의 핵심 메트릭이 어떻게 변하는지 정량적으로 측정해야 한다. 우리가 정한 "안정 상태(Steady State)" 메트릭은 세 가지였다. 응답 시간의 99퍼센타일, 에러율, 그리고 처리량이다. 장애를 주입했을 때 이 세 가지가 일정 범위 안에 머물면 "견뎠다"고 판정하고, 벗어나면 "취약하다"고 기록한다. 처음엔 "서버 하나 죽였더니 응답 시간이 3배 늘어났다"는 결과가 나왔고, 이를 통해 커넥션 풀 설정이 너무 작다는 걸 발견했다. 측정이 없으면 카오스 엔지니어링은 그냥 "부수는 장난"에 불과하다. 측정이 있어야 비로소 "배우는 실험"이 된다.

부수는 용기가 만드는 신뢰

카오스 엔지니어링을 도입하면서 가장 크게 변한 건 기술이 아니라 마인드셋이었다. "장애를 두려워하지 않기"에서 "장애를 미리 겪어두기"로의 전환이었다. 전자는 막상 장애가 오면 패닉에 빠지고, 후자는 차분하게 대처한다. 물론 카오스 엔지니어링이 만병통치약은 아니다. 실험 자체가 위험할 수 있고, 준비 없이 시작하면 오히려 장애를 키울 수 있다. 폭발 반경(blast radius)을 최소화하는 가드레일을 먼저 세우고, 롤백 계획을 명확히 한 뒤에 실험해야 한다. 하지만 점진적으로, 측정 가능하게, 자동화하면서 시작하면 시스템의 신뢰성은 확실히 올라간다. 새벽 3시의 악몽을 겪은 후, 저는 하나를 확신하게 됐다. 진짜 강한 시스템은 부서지지 않는 시스템이 아니라, 부서지고도 다시 일어서는 시스템이다. 그리고 그 회복력은 고의로 부수는 용기에서 나온다.