OpenAI 모델 제공업체 간 장애 조치 설계

기업 업무가 AI 워크플로우에 의존하면 제공업체에 잠깐만 장애가 생겨도 의사 결정이 늦어지거나 서비스가 중단될 수 있습니다. OpenAI는 금융 서비스 고객들과 함께 OpenAI 모델을 활용한 에이전트 기반 애플리케이션과 사이버 보안 워크플로우를 구축해 왔습니다. 이 글에서는 결제 워크플로우의 읽기 전용 사기 위험 평가를 예로 들어 핵심 워크로드의 프로덕션 라우팅과 복구를 어떻게 설계하는지 설명합니다.

이 글에서 퍼스트 파티 (1P) 경로는 OpenAI API에 직접 연결하는 경로입니다. 서드 파티 (3P) 경로는 애플리케이션이 어디에서 실행되든 클라우드 제공업체를 통해 OpenAI 모델을 사용하는 경로입니다. 먼저 프리뷰 모델과 기능을 평가할 때 직접 연결이 어떤 이점을 주는지, 워크로드 요구 사항과 프라이빗 연결이 경로 선택에 어떤 영향을 미치는지, 어떤 작업을 다른 경로로 안전하게 전환할 수 있는지 살펴봅니다. 이어서 기존 게이트웨이에 장애 조치 정책을 구현하는 데 쓸 Codex 프롬프트를 제시하고, 장애 조치를 활성화하기 전에 검증할 사항을 설명합니다.

두 경로를 모두 사용하는 이유

프로덕션에서 클라우드 제공업체를 사용하더라도 OpenAI API에 직접 연결할 수 있으면 이점이 있습니다. 대표적인 예가 프리뷰 모델과 기능입니다. OpenAI API에서 프리뷰 모델이나 기능을 제공하면, 이용 자격을 갖춘 팀은 선택한 클라우드 제공업체가 이를 지원하기 전에도 자체 워크플로우에서 평가할 수 있습니다.

프로덕션 경로를 선택할 때는 워크플로우가 실행되는 환경이 중요한 기준이 됩니다. 어떤 애플리케이션에는 기존 인프라와 운영 통제에 맞는 서드 파티 클라우드 서비스가 적합하고, 다른 워크플로우에는 OpenAI API 직접 연결이 더 적합할 수 있습니다. 선택한 경로에서 필요한 모델과 기능이 지원되고 기대한 대로 동작하는지 검증하세요. 새로운 모델과 기능을 계속 실험할 때는 OpenAI API에 직접 연결하세요. 이용 가능한 모델과 기능은 제공업체, 엔드포인트, 리전, 계정에 따라 다릅니다.

핵심 워크로드의 경우 1P와 3P 간 장애 조치도 검증을 거쳐 도입할 수 있습니다. 제공업체 간 장애 조치란 기본 제공업체가 요청을 처리하지 못할 때 승인된 다른 제공업체를 통해 같은 요청을 재시도하는 것입니다. 요청을 안전하게 반복할 수 있고 대체 경로가 워크플로우 요구 사항을 충족할 때만 효과가 있습니다.

예를 들어 글로벌 결제 서비스 업체는 Responses API로 독립적으로 실행할 수 있는 읽기 전용 사기 위험 평가를 수행할 수 있습니다. 결과를 사용하기 전에 호출 시간이 초과되면 애플리케이션은 거래 처리 기한 내에 검증된 보조 경로로 재시도할 수 있습니다.

진행 중인 Agents API 세션에는 다른 복구 방식이 필요합니다. 제공업체를 전환하는 것만으로는 대화나 저장된 작업을 이어가거나 이전 작업의 실행 결과를 확인해 상태에 반영할 수 없습니다. 이런 세션의 복구는 훨씬 복잡하므로 이 글에서는 다루지 않습니다.

이러한 차이 때문에 여러 제공업체를 지원하는 기능은 플랫폼에서 제공하되, 실제로 장애 조치를 적용할지는 워크플로우별로 결정합니다.

계획된 라우팅과 장애 조치

프로덕션 경로를 선택하는 일과 장애 조치를 승인하는 일은 별개의 결정입니다. 계획된 라우팅에는 여러 제공업체에 트래픽을 분산하거나 한 경로의 처리 용량을 초과하는 요청을 다른 경로로 보내는 방식이 있습니다. 각 방식에 맞춰 용량, 비용, 품질, 복구를 따로 테스트해야 합니다.

일부 고객은 라우팅을 결정할 때 Decisions API의 결과를 선택적으로 활용합니다. 이 서비스가 중단되어도 워크플로우가 계속 동작할 수 있도록, 서비스를 이용할 수 없을 때의 라우팅 방식을 정해 두세요.

아래 그림에서는 1P를 기본 경로로, 승인된 3P 경로를 보조 경로로 사용합니다. 워크로드에 따라 어느 쪽이든 기본 경로가 될 수 있습니다.

라우터의 위치와 역할

그림 1. 기본 경로는 OpenAI API이고 보조 경로는 승인된 서드 파티 제공업체입니다. 플랫폼이 라우터를 운영하고 애플리케이션이 정책을 정의합니다. 경로마다 모델, 기능, 용량, 통제 수단, 가용성이 다를 수 있습니다.

기존 모델 라우터나 LLM 게이트웨이에서 경로별로 규칙을 적용할 수 있다면 그대로 사용하세요. 일반 트래픽은 기본 경로로 보내고, 장애 조치 조건을 충족할 때만 테스트를 마친 보조 경로를 사용하세요.

각 경로를 누가 어느 리전에서 어떤 모델 및 API와 함께 사용할 수 있는지 정의하세요. 승인된 법인, 팀, 제공업체 계정 또는 프로젝트와 데이터 처리 규칙을 기록하세요. 승인은 합의한 워크로드와 리전에만 적용됩니다.

프라이빗 연결과 경로 선택

규제 산업의 많은 고객은 보안 통제의 일부로 프라이빗 연결을 요구합니다. 이런 고객은 경로를 선택할 때 애플리케이션이 실행되는 클라우드에서 각 제공업체까지 프라이빗 연결을 어떻게 구성할 수 있는지도 확인해야 합니다. 아래 그림에서는 고객의 프라이빗 네트워크에 애플리케이션과 게이트웨이가 있고, 각 제공업체로 연결되는 프라이빗 경로가 따로 있습니다.

그림 2. 기본 경로는 OpenAI API(1P)이고 보조 경로는 Amazon Bedrock이나 Azure OpenAI와 같은 승인된 제공업체(3P)입니다. 복구 트래픽 중 조건을 충족하는 요청만 보조 경로를 사용합니다.

이 글을 발행하는 시점에 1P와 3P에서 제공하는 프라이빗 연결 방식은 서로 다릅니다. OpenAI API에 직접 연결하는 1P 경로에서 OpenAI Private Link는 Azure 프라이빗 엔드포인트를 사용합니다. AWS 또는 Google Cloud에서 실행되는 워크로드가 이 프라이빗 경로로 OpenAI API에 직접 접근하려면 고객이 Azure로 연결되는 네트워크를 구성하고 관리해야 합니다.

서드 파티를 이용하는 3P 경로에서 Amazon Bedrock은 AWS PrivateLink를 통해 API별 인터페이스 VPC 엔드포인트를 사용하고, Azure OpenAI는 Azure 프라이빗 엔드포인트를 사용합니다. 장애 조치를 활성화하기 전에 두 경로 모두에서 DNS, 접근 권한, 리전별 모델 및 API 지원 여부를 확인하세요. OpenAI Private Link는 리전별 엔드포인트 간에 자동으로 전환하지 않으므로 리전 간 복구를 별도로 구성하고 테스트해야 합니다. 복구 시 퍼블릭 HTTPS로 전환하려면 명시적인 승인도 필요합니다.

제공업체의 지원 범위는 달라질 수 있습니다. 경로를 선택하거나 활성화하기 전에 공식 문서를 확인하세요.

어떤 작업에 장애 조치를 적용할 수 있나요?

모든 작업에 적합한 보조 경로가 있는 것은 아닙니다. 다음과 같은 경우를 고려하세요.

• 기능 미지원: 워크플로우가 최신 정보를 확인하기 위해 OpenAI API에 직접 연결해 웹 검색을 사용할 수 있습니다. 보조 경로가 이 기능을 지원하지 않는다면 아무런 표시 없이 검색을 건너뛰지 마세요. 대체 구현을 검증하거나 해당 작업의 장애 조치를 비활성화해 두세요.
• 동작 미검증: 모델 이름이 같거나 API가 호환되는 것만으로는 충분하지 않습니다. 보조 경로를 활성화하기 전에 워크플로우의 기존 하네스와 평가를 해당 경로에서 실행하세요.
• 데이터 위치 또는 상태 제약: 승인된 데이터 위치 요건을 위반하거나 작업을 안전하게 완료하는 데 필요한 상태에 접근할 수 없는 대상으로 전환하지 마세요.

조건을 충족하는 보조 경로가 없으면 합의한 기한을 넘기지 않는 범위에서 작업을 대기열에 두거나, 승인된 기능 축소 경로나 수동 처리 경로를 사용하거나, 작업을 안전하게 중단하세요. 워크플로우 전체를 전환할 수 없더라도 재시도가 가능한 추론 단계는 전환할 수 있습니다.

읽기 전용 사기 위험 평가에서 시간이 초과된 경우, 결과가 아직 사용되지 않았고 시간이 충분히 남았다면 재시도할 수 있습니다. 출력이 다른 시스템에 전달된 뒤에는 테스트를 마친 재시작 경로가 있어야 복구할 수 있습니다. 작업이 이미 완료됐을 가능성이 있다면 재시작하기 전에 실행 결과를 확인하고 중복 실행을 방지하세요.

장애 조치 시점과 방법

결제 예시에서 모델이 과부하 상태이거나 이용 불가능하다면 승인된 다른 모델로 대체할 수 있습니다. 이를 모델 폴백이라고 합니다. 다른 제공업체를 통해 평가를 재시도하는 것은 제공업체 간 장애 조치입니다. 모델과 제공업체가 모두 바뀌는 경우도 있습니다.

먼저 제공업체를 바꾸면 문제가 해결될지 판단합니다. 공유 게이트웨이, 검색 서비스 또는 인증 시스템의 문제는 두 경로에 모두 영향을 줄 수 있습니다. 보조 경로의 연결, 접근 권한, 용량을 테스트하고, 사용하는 모델과 호스팅 도구, 데이터 위치 요건을 고려해 리전 간 복구가 지원되는지 확인하세요.

오류나 응답 지연이 지속되면 서킷 브레이커를 사용해 문제가 발생한 경로로 새 요청을 보내는 것을 일시 중지할 수 있습니다. 제공업체, 모델, 리전, 워크플로우별로 오류 및 응답 시간 임계값을 설정하세요. 이때도 각 요청이 장애 조치 조건을 충족해야 합니다.

요청을 재시도하기 전에 안전하게 반복할 수 있는지, 워크플로우 기한 내에 완료할 수 있는지 확인하세요. 보조 경로는 승인을 받아 활성화된 상태여야 하며 정상 동작해야 합니다. 추가 부하를 처리할 수 있는지 테스트를 마쳤고 예산도 남아 있어야 합니다. OpenAI의 오류 코드 문서와 요청 한도 문서를 참고하고, 다른 제공업체의 오류, 재시도, 할당량, 과금 규칙도 확인하세요.

아래 표는 자동 장애 조치를 처음 설계할 때 적용할 수 있는 보수적인 기준입니다. HTTP 상태 코드만 보지 말고 각 제공업체가 반환한 오류 세부 정보를 확인하세요.

애플리케이션, SDK, 게이트웨이에서 각각 재시도해 호출 횟수가 불어나지 않도록 한 계층에서 재시도를 제어하세요. 재시도 예산을 공유하고 유효한 Retry-After 지침을 따르세요. 유효한 지침이 없으면 지터를 적용하고 상한을 둔 지수 백오프를 사용하세요. 재시도 간 대기 시간을 늘리되 무작위 변동을 주고 시도 횟수를 제한하는 방식입니다. 안전하게 반복할 수 있는 추론 호출만 재시도하고, 요청 기한과 워크플로우 기한을 모두 지키세요.

보조 경로에 과부하가 걸리지 않도록 장애 조치 트래픽을 제한하세요. 대표 요청을 기본 경로에서 처리했을 때 오류와 응답 시간이 정해진 기간 동안 임계값 이내로 유지되면 기본 경로의 트래픽을 점진적으로 복원하세요. 임계값을 초과하면 트래픽 증가를 일시 중지하세요. 두 경로 모두 제약을 받는다면 해당 워크플로우에 대해 합의한 복구 정책을 따르세요.

Codex로 장애 조치 정책 구현하기

이제 Codex를 사용해 기존 LLM 게이트웨이에 위 복구 규칙을 구현할 수 있습니다. 결제 예시에서는 독립적으로 실행할 수 있는 읽기 전용 사기 위험 평가 단계로 범위를 한정합니다. 기본 경로는 유지하고 보조 경로의 승인과 검증이 끝날 때까지 장애 조치를 비활성화해 둡니다.

Codex에서 게이트웨이 구성이나 애플리케이션 라우팅을 관리하는 리포지터리를 열고, 아래 프롬프트를 워크플로우와 사용할 경로에 맞게 수정하세요.

[repository/gateway]에서 [workflow’s self-contained, read-only inference step]에 제공업체 간 장애 조치를 추가하고 기본값은 비활성화로 설정하세요. 기본 경로를 유지하고 기존 게이트웨이, 승인된 플랫폼 경로, 워크플로우 정책을 재사용하세요.

게이트웨이, SDK, 어댑터의 버전과 배포 구성, API, 최신 공식 문서를 확인하세요. 담당 주체와 필요한 검토 절차에 따라 앱 변경 사항과 게이트웨이 변경 사항을 구분하세요. 다른 주체가 관리하는 종속성에 대해서는 구성과 통합 테스트를 제공하세요. 지원되지 않는 통제 수단을 명시하세요. 승인 여부나 한도를 추정하지 마세요. 확인이 끝날 때까지 해당 승인이나 한도에 의존하는 장애 조치 경로를 비활성화해 두세요.

테스트를 마친 제공업체별 오류 매핑을 사용하세요. 장애 조치 대상은 일시적인 서비스 또는 네트워크 장애와 일시적인 것으로 확인된 요청 제한으로 한정하세요. 이 경우에도 요청을 안전하게 다시 실행할 수 있고 보조 경로가 다음 조건을 모두 충족할 때만 전환하세요. 보조 경로는 승인을 받아 활성화된 상태에서 정상 동작해야 하며, 필요한 기능과 데이터 통제 수단을 갖추고 용량 검증을 마쳐야 합니다. 예산과 요청을 완료할 시간도 남아 있어야 합니다. 잘못된 요청, 접근 실패, 응답 거부, 할당량·크레딧·예산 소진, 알 수 없는 오류, 원인이 불분명한 429 오류는 장애 조치 대상에서 제외하세요.

클라이언트, 게이트웨이, SDK 전체에서 재시도를 제어하는 주체를 하나만 두세요. 서로 충돌하는 재시도 및 장애 조치 체인을 비활성화하세요. 전체 시도 횟수에 하나의 상한을 적용하고 요청 기한과 워크플로우 기한을 모두 지키세요. 전체 기한 내에서 시도별로 설정된 제한 시간을 적용하세요. 논리적 요청 하나당 결과를 하나만 수락하고 이전 시도에서 늦게 도착한 응답은 무시하세요. Retry-After가 유효하면 따르고, 그렇지 않으면 지터를 적용하고 상한을 둔 지수 백오프를 사용하세요. 출력이 일부만 전달됐거나 작업의 실행 여부가 불분명할 때는 무작정 다시 실행하지 마세요. 제공업체 간에 상태가 이전된다고 가정하지 마세요. 대기열에 넣거나 축소된 결과를 반환하거나 처리를 중단하는 정책 중 승인된 정책을 적용하세요. 장애 조치 수동 비활성화, 서킷 브레이커, 기본 경로로의 점진적 복귀를 구현하세요.

외부 네트워크를 차단한 상태에서 로컬 HTTP 스텁으로 실제 요청 경로를 테스트하세요. 성공, 장애 조치가 허용되는 실패, 차단 대상인 각 오류 유형, 전환 조건 미충족, 부분 출력, 실행 여부가 불분명한 작업, 예산 소진, 두 경로 모두 실패, 복구 제어 기능 작동을 각각 테스트하세요. 각 경우에 경로 호출 순서, 호출 횟수, 경과 시간이 기대값에 맞는지 검증하세요. 장애 조치가 차단된 경우에는 보조 경로 호출 횟수가 0이어야 합니다. 테스트용으로 설정한 한도는 테스트 픽스처에만 두고 비밀 정보를 보호하세요. 승인 없이 실제 서비스를 호출하거나 배포하지 마세요.

변경 범위를 최소화한 패치, 각 요구 사항에 대응하는 테스트, 테스트 결과, 롤백 절차, 실제 환경에서 추가로 확인할 항목을 제공하세요. 검증되지 않은 모든 장애 조치 경로는 비활성화해 두세요.

이 프롬프트는 Codex에 해당 작업에 필요한 게이트웨이 변경 사항, 보조 경로를 호출해야 하는 경우와 호출하면 안 되는 경우를 확인하는 테스트, 실제 경로에서 추가로 확인할 항목을 요청합니다. 먼저 패치와 로컬 테스트 결과를 검토하세요. 그런 다음 부하가 걸린 상태에서 모델 동작, 데이터 통제, 용량, 복구를 검증한 뒤 장애 조치를 활성화하세요.

경로와 복구 검증하기

결제 예시의 검증 항목은 다른 핵심 워크로드에도 적용됩니다. 품질, 안전성, 출력 형식, 도구 사용, 컨텍스트 한도에 관한 워크플로우의 수용 기준에 따라 두 경로를 모두 테스트하세요. 처리 등급과 호스팅 기능을 포함해 테스트한 구성, 가용성, 접근 요건을 기록하고 언제 다시 테스트할지 정하세요.

프롬프트와 출력의 로깅 제한을 포함해 평가에 적용되는 데이터 제한은 정상 운영 중에도 복구 중에도 유효합니다. 어느 경로든 활성화하기 전에 법무, 개인정보 보호, 보안, 데이터 거버넌스 담당자와 함께 자격 증명, 네트워크 경로, 검색, 도구, 저장된 상태, 로그를 검토하세요.

이때 서비스 문서와 계약을 확인해 데이터를 어디에서 처리하고 저장하는지, 얼마나 오래 보관하는지, 어떤 방식으로 암호화하는지, 누가 키와 접근 권한을 관리하는지 파악해야 합니다. 엔드포인트의 위치나 프라이빗 연결 여부만으로는 충분하지 않습니다. 통제 수단, 이용 자격, 책임 범위는 엔드포인트마다 다릅니다. OpenAI의 데이터 통제 문서를 참고하세요.

요건에 맞는 경로라도 복구 트래픽을 처리할 여유 용량이 있어야 합니다. 제공업체 전체를 집계한 대시보드에서는 사기 위험 평가 모델에 걸린 요청 제한이 드러나지 않을 수 있습니다. 각 경로에서 모델, 계정 또는 프로젝트, 리전별로 단위 시간당 요청 수와 토큰 수, 동시 요청 수, 요청 제한, 응답 시간, 승인된 예산 잔액을 추적하세요.

보조 경로의 처리 능력을 확인하려면 기존 워크로드에 예상 사기 위험 평가 트래픽과 재시도를 더해 부하 테스트를 수행하세요. 결과를 바탕으로 장애 조치 트래픽의 상한을 정하고 어떤 요청을 대기시키거나 축소된 기능으로 처리하거나 중단할지 결정하세요. 할당량만으로는 기한 내 완료를 보장할 수 없습니다.

평가를 다른 경로로 옮기면 비용과 응답 시간도 달라질 수 있습니다. 캐시 미스에 따른 비용, 데이터 전송 요금, 연결 비용을 포함해 성공한 평가 한 건당 비용을 비교하세요. 캐시 미스나 클라우드 간 요청 전송으로 발생하는 추가 지연도 측정하세요.

마지막으로 부하가 걸린 상태에서 표에 나온 장애 시나리오를 테스트하세요. 필요한 기능이 없거나 보조 경로가 과부하 상태이거나 이용 불가능한 경우도 테스트하세요. 트래픽 제한, 수동 중지, 기본 경로로의 점진적 복귀를 포함해 복구 정책이 의도대로 동작하는지 확인하세요.

서비스 복구에 걸린 시간, 기한 내에 완료된 평가 건수, 결과 품질, 비용, 중복 실행 여부를 기준으로 복구 성과를 평가하세요. 자격 증명 만료, 구성 변경, 용량 변동이 생겨도 검증 결과가 현재 환경을 반영하도록 정기적으로 복구 훈련을 실시하세요.

복구 책임 분담

실무에서 사용할 수 있는 한 가지 방식은 라우팅 서비스와 애플리케이션의 운영 책임을 나누는 것입니다. 예를 들어 플랫폼 팀은 제공업체 연동, 라우터, 모니터링, 감사 로그를 운영할 수 있습니다. 이 팀은 라우팅 서비스의 프로덕션 운영 준비를 책임지고, 라우팅 대상, ID, 데이터, 트래픽, 지출에 관한 통제를 적용합니다. 경로를 비활성화하고 기본 경로로의 복귀를 관리할 온콜 담당자도 지정합니다.

이 방식에서 애플리케이션 담당자는 장애 조치를 허용할 작업, 서비스 및 품질 목표, 허용 가능한 기능 축소 범위를 정의합니다. 또한 비즈니스 결과, 저장된 복구 컨텍스트, 도구 권한, 응답 검증, 중복 실행 방지를 책임집니다. 상태나 도구를 공유하는 경우에도 이 책임은 애플리케이션 담당자에게 있습니다.

팀 사정에 맞게 역할을 통합하거나 다르게 나눌 수 있습니다. 장애 조치를 활성화하기 전에 누가 통제 수단을 승인하고, 경로 테스트와 운영 절차서를 관리하며, 장애 발생 시 조치를 취할 권한을 갖는지 합의하세요.

결론

프로덕션에서 클라우드 제공업체를 사용하더라도 OpenAI API에 직접 연결하는 경로를 함께 고려하세요. 이용 자격을 갖춘 팀은 이 경로에서 프리뷰 모델과 기능을 평가할 수 있고, 핵심 워크로드의 복구 경로로도 활용할 수 있습니다. 프로덕션에서 1P와 3P 중 어느 경로를 사용할지는 워크플로우에 필요한 기능, 호스팅 환경, 통제 요건을 기준으로 결정하세요. 프라이빗 연결이 필요하다면 그 요건도 고려하세요.

핵심 워크로드에서는 독립적으로 실행할 수 있는 읽기 전용 추론 단계 하나부터 시작하세요. Codex로 해당 단계의 게이트웨이 정책과 로컬 테스트를 구현하고, 실제 경로에서 검증해 보조 경로가 워크플로우 요구 사항을 충족하는지 확인할 수 있습니다. 이렇게 하면 언제 경로를 전환하고 언제 작업을 중단할지, 누가 그 결정을 책임질지 명확히 정한 복구 계획을 세울 수 있습니다.