Code Orange: Fail Small이 완료되었습니다. 그 결과 Cloudflare 네트워크는 더욱 강력해졌습니다.

지난 두 분기 반 동안, 우리는 내부 코드명 “Code Orange: Fail Small”로 불린 집중적인 엔지니어링 작업을 진행해왔습니다. 이 작업은 모든 고객을 위해 Cloudflare 인프라를 더 높은 수준의 복원력, 보안성, 안정성을 갖추도록 만드는 데 초점을 맞췄습니다.

이달 초, Cloudflare 팀은 이 작업을 완료했습니다.

복원력 향상은 결코 “완료된 일”이 될 수 없으며 앞으로도 개발 라이프사이클 전반에서 최우선 과제로 남겠지만, 이제 우리는 2025년 11월 18일과 2025년 12월 5일의 글로벌 장애를 방지할 수 있었을 작업을 완료했습니다.

이번 작업은 더 안전한 구성 변경, 장애 영향 범위 축소, 그리고 “긴급 조치” 절차 및 인시던트 관리 개편 등 몇 가지 핵심 영역에 집중되었습니다. 또한 시간 경과에 따른 드리프트와 회귀를 방지하기 위한 조치도 도입했으며, 장애 발생 중 고객과 소통하는 방식도 강화했습니다.

여기에서는 우리가 배포한 내용과 그것이 여러분에게 의미하는 바를 자세히 설명합니다.

여러분에게 의미하는 바: 대부분의 경우 Cloudflare 내부 구성 변경은 더 이상 즉시 네트워크 전체에 반영되지 않으며, 대신 실시간 상태 모니터링과 함께 점진적으로 롤아웃됩니다. 이를 통해 관찰 가능성 도구가 문제를 감지하고, 고객 트래픽에 영향을 주기 전에 문제를 되돌릴 수 있습니다.

위험한 배포가 프로덕션에 도달하기 전에 감지할 수 있도록 우리는 고위험 구성 파이프라인을 식별하고 구성 변경을 더 잘 관리하기 위한 새로운 도구를 구축했습니다.

고객 트래픽을 처리하는 네트워크에서 실행되며 구성 변경을 수신하는 제품의 경우, 더 이상 이러한 변경을 네트워크 전체에 즉시 배포하지 않습니다. 대신 관련 팀들은 소프트웨어 릴리스에 사용하는 것과 동일한 “상태 기반 배포” 방법론을 모든 구성 배포에 도입했습니다. 여기에는 인시던트의 직접적인 영향을 받은 제품 팀뿐 아니라 그 외 팀들도 포함됩니다.

이 작업의 핵심에는 Snapstone이라는 새로운 내부 컴포넌트가 있습니다. 우리는 구성 변경에도 상태 기반 배포를 적용하기 위해 Snapstone을 구축했습니다. Snapstone은 구성 변경을 패키지로 묶고, 상태 기반 제어 원칙에 따라 점진적으로 릴리스할 수 있도록 하는 시스템입니다. Snapstone 이전에도 이 방법론을 구성에 적용하는 것은 가능했지만 어려웠습니다. 팀별로 상당한 노력이 필요했고, 네트워크 전체에서 일관되게 적용되지 않았습니다. Snapstone은 점진적 롤아웃, 실시간 상태 모니터링, 자동 롤백을 기본값으로 제공함으로써 이 격차를 해소합니다.

Snapstone이 특히 강력한 이유는 유연성에 있습니다. Snapstone은 특정 과거 장애를 해결하기 위한 단순한 수정책이 아닙니다. 팀은 상태 기반 제어가 필요한 모든 구성 단위를 동적으로 정의할 수 있습니다. 예를 들어 11월 18일 장애를 유발한 데이터 파일이나, 12월 5일 장애와 관련된 글로벌 구성 시스템의 제어 플래그도 포함됩니다. 팀은 필요에 따라 이러한 구성 단위를 생성하고, Snapstone은 그것들이 사용되는 모든 위치에서 안전하게 배포되도록 보장합니다.

이를 통해 우리는 이전에 없던 능력을 갖추게 되었습니다. 위험 검토나 운영 경험을 통해 위험한 구성 패턴이 식별되면, 해결 방법은 단순합니다. Snapstone에 포함시키면 해당 구성 패턴은 즉시 안전한 배포 메커니즘을 상속받는 것입니다. 

여러분에게 의미하는 바: 네트워크에서 문제가 발생하더라도 이제 시스템은 더 우아하게 실패합니다. 이를 통해 잠재적인 영향 범위를 크게 줄여, 최악의 상황에서도 여러분의 트래픽이 계속 전달되도록 보장합니다.

제품 팀은 고객 트래픽 제공에 중요한 제품들의 잠재적 장애 모드를 수동 및 프로그래밍 방식으로 면밀히 검토했습니다. 팀들은 비필수 런타임 종속성을 제거하고 더 나은 장애 처리 모드를 구현했습니다. 이제 가능한 경우 마지막으로 정상 동작했던 구성을 사용하는 방식(“fail stale”)을 사용하며, 이것이 불가능한 경우에는 각 장애 사례를 검토해 기능 일부를 축소하더라도 트래픽 제공을 유지하는 것이 더 나은지 여부에 따라 “fail open” 또는 “fail close”를 구현했습니다.

이것이 어떻게 작동하는지 예를 들어보겠습니다. 2025년 11월 장애는 Bot Management 탐지 머신러닝 분류기의 실패한 롤아웃으로 인해 발생했습니다. 새로운 절차에서는 시스템이 읽을 수 없는 데이터가 다시 생성되더라도, 시스템은 업데이트된 구성을 사용하지 않고 기존 구성을 계속 사용합니다. 만약 기존 구성도 어떤 이유로 사용할 수 없다면, 고객 프로덕션 트래픽 제공이 계속되도록 fail open 방식으로 동작합니다. 이는 다운타임보다 훨씬 나은 결과입니다.

결과적으로, 11월 장애를 유발했던 동일한 Bot Management 변경이 지금 롤아웃된다면, 시스템은 초기 배포 단계에서 장애를 감지하고 극히 일부 트래픽에만 영향을 준 상태에서 자동으로 롤백합니다.

또한 우리는 서로 다른 트래픽 코호트별로 독립적인 서비스 복사본이 실행되도록 시스템 세분화를 추가로 진행하고 있습니다. Cloudflare는 이미 트래픽 관리 기법을 통해 고객 코호트를 활용한 피해 범위 완화를 수행하고 있으며, 이번 추가 프로세스 세분화 작업은 앞으로 강력한 안정성 기능이 될 것입니다.  

예를 들어 Workers 런타임 시스템은 여러 개의 독립 서비스로 세분화되어 있으며, 그중 하나는 무료 고객 트래픽만 처리합니다. 변경 사항은 고객 코호트 기반으로 배포되며, 무료 고객부터 시작됩니다. 또한 덜 중요한 세그먼트에는 업데이트를 더 빠르고 자주 배포하고, 가장 중요한 세그먼트에는 더 느린 속도로 배포하고 있습니다.

결과적으로, Workers 런타임 시스템에 변경이 배포되어 트래픽 장애를 유발하더라도 이제는 무료 고객의 극히 일부에만 영향을 미친 뒤 자동 감지 및 롤백됩니다.

Workers 런타임 시스템을 예로 계속 들면, 이달 초 7일 동안 배포 프로세스는 50회 이상 실행되었습니다. 각 배포가 “웨이브” 형태로 에지 전체에 전파되며, 종종 이전 및 다음 릴리스와 병렬로 진행되는 모습을 볼 수 있습니다.

우리는 앞으로 더 많은 시스템에 이 배포 패턴을 확장하기 위해 작업하고 있습니다.

여러분에게 의미하는 바: 인시던트가 발생하더라도, 우리는 더 명확하게 소통하고 더 빠르게 문제를 해결할 수 있는 도구와 팀을 갖추게 되었고, 이를 통해 다운타임을 최소화할 수 있습니다.

Cloudflare는 Cloudflare 위에서 운영됩니다. 우리는 자체 Zero Trust 제품으로 인프라를 보호하지만, 이는 의존성을 만들어냅니다. 즉, 네트워크 전체 장애가 이러한 도구에 영향을 미치면, 우리는 그것들을 복구하기 위한 경로 자체를 잃게 됩니다. Code Orange 이전에는 우리의 “긴급 조치” 경로는 극소수 인원만 사용할 수 있었고, 제한된 도구 접근만 제공했습니다. 우리는 장애 상황에서 이러한 도구와 경로를 더 넓게 사용할 수 있어야 했습니다.

이를 해결하기 위해 시스템 가시성, 디버깅, 프로덕션 변경에 필수적인 도구들에 대한 포괄적인 감사를 수행했습니다. 최종적으로 우리는 18개의 핵심 서비스에 대한 백업 인증 경로를 구축했고, 새로운 긴급 스크립트와 프록시를 지원 체계로 마련했습니다.

Code Orange 프로그램 전반에 걸쳐 우리는 이론에서 실전으로 이동했습니다. 소규모 팀 훈련 이후, 2026년 4월 7일에는 200명 이상의 팀원이 참여하는 전사적 엔지니어링 훈련을 진행했습니다. 자동화가 이러한 경로를 항상 동작 가능한 상태로 유지하더라도, 이런 훈련은 실제 압박 상황에서 엔지니어들이 이를 자연스럽게 사용할 수 있도록 해줍니다.

이번 작업은 정보 흐름에도 집중했습니다. 내부 가시성이 손상되면 인시던트 대응 속도가 느려지고 외부와의 소통 능력도 저하됩니다. 과거에는 긴박한 상황 속 기술적 관찰이 고객을 위한 명확한 업데이트로 항상 이어지지는 않았습니다.

이 간극을 메우기 위해, 우리는 주요 인시던트 발생 시 대응 엔지니어와 긴밀히 협업하는 전담 커뮤니케이션 팀을 구성했습니다. 엔지니어들이 “긴급 조치” 절차를 훈련했던 것처럼, 이 팀도 Code Orange 프로그램을 통해 고객 업데이트의 주기와 명확성을 개선하는 훈련을 진행했습니다. 즉, 상황을 파악할 수 있는 도구와 소통할 수 있는 구조를 모두 갖춤으로써 더 빠르게 인시던트를 해결하고 고객에게 더 나은 정보를 제공할 수 있게 되었습니다.

여러분에게 의미하는 바: 우리는 인시던트에서 얻은 교훈을 기억하고 해결책을 체계화했습니다. 우리의 네트워크는 앞으로도 계속 더 높은 복원력을 갖추게 될 것입니다.

시간이 지나면서 Code Orange 작업의 결과가 드리프트되거나 회귀되지 않도록, 팀은 모든 가이드라인을 명확하고 간결한 규칙으로 정리한 내부 Codex를 구축했습니다.

Codex는 이제 모든 엔지니어링 및 제품 팀에 필수 적용되며, Cloudflare 내부 절차의 핵심 요소가 되었습니다. 규칙은 AI 코드 리뷰를 통해 강제 적용되며, 가이드라인에서 벗어날 가능성이 있는 사례를 자동으로 표시해 추가 수동 리뷰를 요구합니다. 이는 전체 코드베이스에 예외 없이 적용됩니다. 목표는 단순합니다. 바로 스스로 강제되는 조직적 기억을 구축하는 것입니다.

11월과 12월 장애는 공통된 장애 패턴을 공유했는데, 입력값이 항상 유효하다고 가정하는 코드와, 그 가정이 깨졌을 때 우아하게 실패하지 못하는 구조였습니다. Rust 서비스는 에러를 처리하는 대신 .unwrap()을 호출했고, Lua 코드는 존재하지 않는 객체를 인덱싱했습니다. 두 패턴 모두 교훈이 체계화되고 강제되었다면 예방 가능했습니다.

Codex는 우리가 제시하는 해답의 일부입니다. 이는 RFC(Request For Comments) 프로세스를 통해 도메인 전문가들이 작성한 엔지니어링 표준을 모아 실행 가능한 규칙으로 정리한 살아 있는 저장소입니다. 과거에는 시니어 엔지니어의 머릿속에만 존재하거나, 인시던트 이후에야 발견되던 모범 사례가 이제는 모두가 접근 가능한 공유 지식이 됩니다. 각 규칙은 “X가 필요하다면 Y를 사용하라”는 단순한 형식을 따릅니다. 그리고 그 이유를 설명하는 RFC 링크가 포함됩니다.

예를 들어 한 RFC는 이제 “.unwrap()을 테스트와 build.rs 외부에서는 사용하지 마라“고 명시합니다. 또 다른 RFC는 “서비스는 처리 전에 업스트림 종속성이 예상된 상태인지 반드시 검증해야 한다”는 더 넓은 원칙을 담고 있습니다.

이 규칙들이 더 일찍 강제되었다면, 11월과 12월 장애는 글로벌 인시던트가 아니라 머지 요청 거부로 끝났을 것입니다.

강제되지 않는 규칙은 단지 제안일 뿐입니다. Codex는 설계 검토부터 배포, 인시던트 분석까지 소프트웨어 개발 라이프사이클 전반의 AI 기반 에이전트와 통합됩니다. 이를 통해 강제 시점이 “글로벌 장애”에서 “거부된 머지 요청”으로 앞당겨집니다. 위반의 피해 범위는 수백만 건의 요청 영향에서, 프로덕션에 도달하기 전에 개발자 한 명에게 제공되는 실행 가능한 피드백 수준으로 축소됩니다.

Codex는 살아 있는 문서이며 앞으로도 지속적으로 개선될 것입니다. 도메인 전문가들은 RFC를 작성해 모범 사례를 체계화합니다. 인시던트는 새로운 RFC로 이어질 공백을 드러냅니다. 승인된 모든 RFC는 Codex 규칙을 생성합니다. 그 규칙은 다음 머지 요청을 검토하는 에이전트에 반영됩니다. 이것은 곧 플라이휠입니다. 전문성은 표준이 되고, 표준은 강제가 되며, 강제는 모두의 기준선을 끌어올립니다.

여러분에게 의미하는 바: 투명성은 우리에게 중요합니다. 문제가 발생하면, 여러분이 중요한 일에 집중할 수 있도록 모든 단계에서 지속적으로 업데이트를 제공하는 데 전념하고 있습니다.

글로벌 장애는 엔지니어링과 제품 개발을 넘어 핵심 프로세스와 문화적 접근 방식까지 재검토하게 만들었습니다. 광범위한 Code Orange 이니셔티브의 일환으로, 우리는 모든 서비스에 추가적인 서비스 수준 목표(SLO)를 도입했고, 글로벌 changelog를 강제 적용했으며, 모든 팀을 유지보수 조정 시스템에 온보딩했고, 인시던트 “prevents” 티켓 백로그에 대한 회사 전체 투명성도 개선했습니다. 

또한 장애 발생 중 고객과 소통하는 방식도 강화했습니다. 우리의 목표는 여러분이 문제를 인지하기 전에, 우리가 문제를 확인하는 즉시 이를 알려드리는 것입니다. 여러분이 지연이나 오류를 체감할 시점에는 이미 알림에 업데이트가 도착해 있도록 하는 것이 목표입니다.

활성 인시던트 중에는 이제 예측 가능한 간격(예: 30분 또는 60분마다)으로 업데이트를 제공합니다. 업데이트 내용이 단순히 “수정 사항을 계속 테스트 중이며 아직 새로운 변경 사항은 없습니다”인 경우라도 마찬가지입니다. 이를 통해 여러분은 상태 페이지를 계속 새로고침하는 대신 하루 일정을 계획할 수 있습니다.

우리의 역할은 상태가 정상으로 돌아왔다고 끝나지 않습니다. 우리는 무엇이 발생했는지, 왜 발생했는지, 그리고 다시 발생하지 않도록 어떤 구조적 변화를 적용하고 있는지를 설명하는 상세한 사후 분석 보고서를 제공합니다.

우리는 이번 인시던트를 매우 심각하게 받아들였으며, Cloudflare 전체 조직에 공동 책임 의식을 도입하면서 모든 팀에 이렇게 질문했습니다. 무엇을 더 잘할 수 있었는가? 이것이 지난 두 분기 동안 우리가 수행한 작업의 방향이 되었습니다.

이 작업은 결코 완전히 끝나는 일은 아니지만, 우리는 지금 훨씬 더 나은 위치에 있으며, 그 결과 Cloudflare는 훨씬 더 강해졌다고 확신합니다.