서비스가 멀쩡한 날에는 누구나 복구 계획을 믿어. 다중 가용 영역, 자동 장애 조치, 재시도 로직, 이중화 저장소까지 갖췄다면 더 그렇지.
그런데 Microsoft가 Azure Chaos Studio Workspaces에 넣은 첫 장면은 정상 작동이 아니야. DNS를 끊고, 가용 영역의 가상 머신을 멈추고, 데이터베이스 장애 조치를 강제로 일으킨다. 설계도가 아니라 실제 서비스가 그 상황에서 무엇을 하는지 보자는 거야.1
장애는 한 겹으로 오지 않아
이 접근이 겨냥하는 건 서버 한 대가 꺼지는 단순한 시험이 아니야. 실제 장애에서는 플랫폼과 애플리케이션이 함께 시험대에 올라. 데이터베이스는 다른 곳으로 넘어갔는데 코드가 예전 지역의 주소만 보고 있거나, 캐시가 비자 데이터베이스가 한꺼번에 몰리는 요청을 버티지 못할 수 있어. 이중화가 있어도 건강 확인 설정 하나가 오래전에 잘못돼 있었다면 복구 경로는 멈춰.1
그래서 이 기능은 “장애를 막아 준다”고 말하기보다, 장애가 났을 때 이미 넣어 둔 장치가 정말 움직이는지 확인하게 해 주는 도구에 가까워. 복구 목표 시간 안에 트래픽이 돌아오는지, 진행 중이던 거래가 망가지지 않는지, 재시도가 더 큰 부하를 만들지는 않는지를 한 번에 봐야 해.
조립 대신 시나리오
Chaos Studio Workspaces는 구독이나 리소스 그룹을 범위로 정하면 그 안의 자원을 살피고, 적용할 만한 장애 시나리오를 추천한다고 설명해. Zone Down, DNS Outage, Microsoft Entra ID Outage, Cache Stampede, 이벤트 기반 메시징 중단이 그 출발점이야.1
예를 들어 Cache Stampede는 Redis를 비우고 데이터베이스를 다시 시작하며 App Service 프로세스까지 멈추는 조합이야. 캐시가 비었을 때 많은 요청이 원본 데이터베이스로 몰리는 상황을 흉내 낸다. 장애 하나를 따로 따로 고르는 대신, 실제로 같이 일어날 수 있는 실패 묶음을 먼저 꺼내는 방식이지.
여기서 중요한 건 추천 시나리오가 답안지는 아니라는 점이야. Microsoft는 일반적인 장애 패턴을 바탕으로 했다고 설명하지만, 어떤 서비스가 어느 시간 안에 복구되는지는 각자의 구성과 코드에 달려 있어. Workspaces가 확인해 주는 것은 복구력이 있다는 선언이 아니라, 그 선언을 시험해 볼 수 있는 절차와 결과 보고서야.1
AI도 예외가 아니야
AI 서비스는 모델 호출만 떠올리기 쉽지만, 실제 배포는 검색 인덱스, 데이터베이스, 캐시, 인증, 메시지, 네트워크와 얽혀 있어. 그래서 Microsoft는 Copilot·에이전트·검색 증강 생성 파이프라인도 기존 분산 시스템의 장애 시나리오로 먼저 시험할 수 있다고 설명해.1
다만 여기에는 선이 있어. 검색 결과가 엉뚱해지는 현상이나 토큰 제한, 부하 아래에서 모델 행동이 달라지는 문제는 앞으로 더 다루겠다는 계획이지, 지금 제공되는 검증 항목은 아니야. AI 서비스에 “장애 훈련을 붙였다”는 말이 모델 품질이나 에이전트의 판단까지 보증한다는 뜻은 아니지.
그 구분은 agentic workflow를 읽을 때도 유용해. 에이전트가 MCP 서버나 다른 도구를 통해 더 많은 일을 맡더라도, 그 밑의 인증·저장소·네트워크가 실패할 때 어떤 행동을 하는지는 별도의 질문이야. Microsoft는 GitHub Copilot용 대화형 기능과 MCP 서버도 함께 내놨지만, 둘 다 같은 Chaos Studio API와 사용자의 Azure 로그인 권한 위에서 동작한다고 설명한다.1
다음에 볼 것
이 발표는 공개 미리보기 단계야. 정식 출시는 2026년 말이 목표지만 바뀔 수 있다고 적혀 있어.1
그러니 다음 신호는 기능 목록이 더 길어지는지가 아니야. 실제 팀이 이 훈련 결과를 배포 승인, 변경 기록, 감사 자료에 반복해서 붙이는지 봐야 해. 또 AI 서비스에서 검색·모델·도구 호출의 실패를 어느 범위까지 같은 보고서 안에서 다루게 되는지도 확인할 지점이야.
장애 대응의 실력은 복구 절차를 써 둔 날이 아니라, DNS가 끊기고 캐시가 비었을 때 그 절차가 실제로 움직인 날에 드러나.
댓글