09:17:49 UTC에, 제공업체 의존성(provider dependency)이 구현 세부 사항에서 가용성 경계(availability boundary)로 변했습니다. 만약 애플리케이션이 단 하나의 원격 모델 엔드포인트(remote model endpoint)를 신뢰해야만 계속 작동할 수 있다면, 해당 엔드포인트는 이미 애플리케이션의 진행 여부를 제어하고 있는 것입니다.

OpenAI의 첫 번째 장애는 2026년 7월 25일 10:02:52에 완화 모니터링(mitigation monitoring) 단계에 진입하여 11:08:36 UTC에 해결되었습니다. 두 번째 장애는 11:35:24에 시작되었습니다. 조사 당시에는 장애가 식별되었고, 에러 발생률 상승이 보고되었으며, 완화 작업이 진행 중이었습니다. 이후 공식 상태 페이지에는 '부분적 시스템 저하(Partial System Degradation)'가 표시되었습니다. 해당 기록들은 시점과 상태를 확립할 뿐, 이후 발생한 장애의 근본 원인(root cause), 전 세계적 영향, 영향을 받은 사용자 수 또는 최종 복구에 대해서는 나타내지 않습니다.

재시도(retries) 로직을 작성하기 전에 경계를 설정하라

프롬프트(prompts), 도구 권한(tool permissions), 대화 상태(conversation state), 그리고 수락된 출력(accepted output)을 별개의 자산으로 취급하십시오. 폴백 제공업체(fallback provider)는 최소한의 이식 가능한 요청(portable request)만을 전달받아야 하며, 기본 제공업체에 할당된 자격 증명(credentials)이나 권한(authority)을 암묵적으로 상속받아서는 안 됩니다.

user -> policy gate -> durable request -> provider adapter
                    |                  -> circuit state
                    +-> output validator -> application action

보안 불변성(security invariant)은 다음과 같습니다: 제공업체를 변경하더라도 데이터 접근 권한, 도구 범위(tool scope), 또는 출력 권한(output authority)이 확장되어서는 안 됩니다. 가용성(Availability)은 이러한 불변성이 유지되는 동안에만 유용합니다.

실행되지 않은 브레이커(breaker) 정책

다음 YAML은 설계 예시이며, 테스트된 설정이 아닙니다:

breaker:
  window_seconds: 60
  minimum_requests: 20
...

타임아웃 (Timeout)은 가용성 신호를 증가시키지만, 장애 (Outage)를 증명하는 것은 아닙니다. 서킷 브레이커 (Breaker)는 이러한 증거 유형들을 별도로 유지하면서, 제한된 로컬 관측값 (Local observations)과 공식 상태 기록 (Official status record)을 결합해야 합니다. 상태 정보는 증상보다 늦게 나타날 수 있으며, 로컬 오류는 사용자의 네트워크, 자격 증명 (Credentials), 또는 배포 (Deployment) 환경에서 발생할 수도 있습니다.

세 가지 상태를 사용하십시오. closed는 정상적인 트래픽을 전송합니다. open은 새로운 원격 시도를 중단하고 안전한 저하된 경로 (Degraded path)를 제공합니다. half_open은 합성 (Synthetic) 또는 민감하지 않은 카나리 (Canaries)를 전송하며, 대기열에 있는 프로덕션 작업은 절대 전송하지 않습니다. 단순히 회로가 닫혔다고 해서 요청을 재시도하지 마십시오. 이전 시도가 클라이언트 타임아웃 이후에 완료되었을 수도 있습니다.

멀티 제공자 폴백 (Multi-provider fallback)은 의미론적 위험 (Semantic risk)을 수반합니다. 모델들은 지침 (Instructions), 도구 (Tools), 스키마 (Schemas), 그리고 안전 경계 (Safety boundaries)를 서로 다르게 해석할 수 있습니다. 유효한 JSON 응답이 곧 동일한 의미를 보장하는 것은 아닙니다. 제공자별 픽스처 (Fixtures)가 중요한 불변량 (Invariants)을 입증하기 전까지는 권한이 높은 작업들을 일시 중단 상태로 유지하십시오.

장애 방지(Outage-proof)라고 부르지 않고 탈출 전략 평가하기

제공자 관련 이벤트 이후 개발 환경을 검토하는 팀들을 위해, MonkeyCode는 두 가지 별도의 옵션을 제공합니다. 해외 Try Online 페이지에는 현재 “Start free”라고 표시되어 있습니다. 공식 README에는 빌드, 테스트, 미리보기 및 통합된 모델을 갖춘 관리형 서버 측 클라우드 환경(Managed server-side cloud environment)으로 설명되어 있습니다. 시작은 무료이지만, 모델 및 서버 할당량 (Quotas), 리전 (Regions), 가동 시간 (Uptime) 또는 SLA 조건은 변경될 수 있으므로 콘솔에서 확인해야 합니다.

공식 MonkeyCode 리포지토리는 AGPL-3.0 오픈 소스입니다. 검토된 메인 커밋 18baaf54937a65a7d47f1f9d83dd808777aa6cea에서, README는 내장된 개발 환경 (development-environment), 모델 (model), 작업 (task) 및 요구 사항 (requirement) 관리를 설명하고 있습니다. 소스 코드 접근은 검사 및 셀프 호스팅 (self-hosting) 탈출 옵션으로서 유용하지만, 모델 제공자 (model-provider) 또는 인프라 (infrastructure) 장애로부터의 면역을 보장하지는 않습니다. 저는 호스팅된 MonkeyCode의 신뢰성을 테스트하지 않았습니다.

이러한 보안 프레임워크 (security framing)를 위해, 저는 권한이 낮은 작업을 해외에서 시도하기 전에 리포지토리 내의 어댑터 권한 (adapter permissions)과 지속성 경계 (persistence boundaries)를 검사할 것입니다. 결정적인 증거는 폴백 (fallback)이 텍스트를 반환하는지 여부가 아니라, 제공자 변경 시 동일한 권한 범위 (authority envelope)가 유지되는지 여부입니다.

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와 관련이 없습니다.

AI 지원 공개: 이 기사는 AI의 도움을 받아 초안이 작성되었으며, 인용된 1차 자료를 바탕으로 검토되었습니다.