디스커버리 단계는 소스 도구, 정의된 추론 프로필, 그리고 발견한 증거를 보존하는 방법이 필요합니다. 이 단계의 최종 산출물은 명시적인 주장 경계를 가진 소스 패킷일 수 있습니다.

이제 주 공급자가 시간 초과(timeout)되었다고 상상해 보세요. 오케스트레이터는 일반적인 폴백 목록에 있는 다음 모델로 이동하지만, 그 경로에서는 필수 소스 도구를 사용할 수 없습니다. 이 설정은 무시되거나 워크플로우가 조용히 텍스트 전용 생성으로 전환됩니다. 세련된 패킷이 나타나고 실행은 녹색으로 바뀝니다.

워크플로우는 작업을 변경함으로써 계속 이용 가능하게 유지됩니다. 유창한 산문(fluent prose)은 실패를 발견하기 어렵게 만드는데, 왜냐하면 모든 후속 단계가 디스커버리 계약 외부에서 생성되었지만 유효해 보이는 산출물을 받기 때문입니다. 대시보드가 단지 '완료됨'만 기록한다면, 그 불일치는 최종 출력까지 살아남을 수 있습니다.

이것이 발생하기 위해 모델이 나쁠 필요는 없습니다. 라우팅 정책(routing policy)이 서로 다른 작업을 상호 교환 가능하게 취급하기만 하면 됩니다. 신뢰할 수 있는 라우터는 각 단계의 계약을 정의하고, 그것을 충족시킬 수 있는 경로를 선택하며, 비호환적인 대체품은 거부하고, 실제로 실행된 것을 기록합니다. 가용성 폴백(Availability fallback)은 그 정책 안에 속하며, 이를 무효화할 수는 없습니다.

하나의 워크플로우는 여러 다른 작업을 포함합니다

'최고의 모델을 사용하라'는 결정적으로 들리지만, 파이프라인에 여러 단계가 있는 경우 그렇지 않습니다. 무엇에서 가장 좋을까요? 디스커버리는 브라우징 또는 검색 도구, 증거 세트를 위한 충분한 컨텍스트, 그리고 증거 캡처를 필요로 할 수 있습니다. 계획(Planning)은 제한된 패킷으로 작동하여 그것을 주장으로 바꿉니다. 초안 작성(Drafting)은 플랫폼, 목소리, 길이 및 파일 제약 조건을 가지며, 평가(Evaluation)는 간결한 내용과 소스에 연결된 명시적인 확인이 필요합니다.

추론 노력(Reasoning effort) 또한 경로 정의에 속해야 합니다. 이는 전역적인 품질 스위치가 아니라 특정 작업을 위한 예산이자 행동 설정입니다.

현재의 SDK들은 이러한 선택을 명시적으로 만들 수 있는 이음새(seams)를 노출하고 있습니다. OpenAI Agents SDK는 에이전트별 모델 및 프로바이더(provider) 선택, 구성 가능한 추론 노력(reasoning effort), 그리고 지원되지 않는 기능에 대한 엄격한 검증(validation)을 문서화합니다. Vercel의 AI SDK는 모델 선택을 포함하여 런타임 컨텍스트(runtime context)를 사용한 단계 준비(step preparation), 추론 제어 및 텔레메트리(telemetry)를 문서화합니다. Vercel의 라우팅 가이드는 작업 지향적 라우팅(task-oriented routing)을 비용, 지연 시간(latency), 폴백(fallback), 부하 분산(load balancing) 및 예산 정책과 분리합니다.

이러한 제어 장치들이 모든 파이프라인에 여러 모델이 필요하다는 것을 증명하는 것은 아닙니다. 종종 전체 워크플로에 하나의 경로만으로도 충분합니다. 유용한 변화는 재사용이 상속된 기본값이 아니라 검증된 결정이 된다는 점입니다. 즉, 동일한 경로가 네 가지 계약(contracts)을 모두 충족한다면, 이를 네 번 할당하고 그 선택을 기록하면 됩니다. 설계의 목적은 모델 이름을 수집하는 것이 아니라 각 작업을 보존하는 것입니다.

4단계 계약으로 시작하기

모델 이름을 추가하기 전에 작업(jobs)으로부터 라우팅 테이블을 구축하십시오. 다음은 소스 제한적(source-bounded) 퍼블리싱 워크플로를 위한 실질적인 4단계 설계입니다. 이는 구현 예시이며, 어떤 종류의 모델이 가장 성능이 좋은지에 대한 벤치마크 주장(benchmark claim)이 아닙니다.

첫 두 행 사이에는 유용한 경계가 존재합니다. Discovery는 승인된 소스 도구로 증거를 수집하고, 자료가 관련성이 있고 읽기 가능한지 확인하며, 각 소스가 무엇을 지원할 수 있는지 기록합니다. Planning은 해당 제한된 증거 패킷을 전달받아 기사의 논거, 순서 및 개요를 결정합니다. Planning은 더 많은 자료가 필요할 때마다 광범위한 Discovery를 다시 열어서는 안 됩니다. 만약 패킷에 실제 공백(gap)이 있다면, Planner는 자신의 작업을 조용히 확장하는 대신 의도적인 Discovery 단계를 위해 해당 공백을 반환할 수 있습니다.

압축된 계약(compact contract)은 프롬프트 문장(prompt prose) 대신 설정(configuration) 내에 존재할 수 있습니다:

version: 3
stage: discovery
task_class: source_bounded_research
...

프로필 별칭(profile aliases)은 다른 곳에 정의된 구체적인 제공자(provider), 모델(model), 추론(reasoning), 그리고 도구(tool) 설정으로 해석됩니다. 이를 통해 프롬프트는 작업(work)을 설명하는 동안, 인프라 정책은 런타임(runtime)이 검사할 수 있는 오케스트레이션 상태(orchestration state)에 유지됩니다. 실제 계약에는 예산(budget)이나 지연 시간(latency) 경계가 필요할 수도 있습니다. 필드는 라우터(router)가 이를 검증할 수 있거나 평가자(evaluator)가 이를 확인할 수 있을 때만 그 자리를 얻게 됩니다. 그 외의 모든 것은 장식에 불과합니다.

단계별 라우팅 루프 (The stage-routing loop)

이 메커니즘은 내부 라우팅 제품을 별도로 구축하지 않고도 구현할 수 있을 만큼 작습니다.

1. 모델을 선택하기 전에 계약을 선언합니다. 작업 클래스(task class), 필요한 도구 및 기능, 컨텍스트 요구사항, 추론 프로필(reasoning profile), 예산 경계, 예상 결과물(artifact), 그리고 승인된 대체 수단(approved substitutes)을 기록합니다.

2. 계약과 현재 런타임 컨텍스트(runtime context)로부터 경로(route)를 결정합니다. 애플리케이션 전반의 기본값(default)에 의해 실수로 결정되지 않도록, 선택 사항을 코드나 버전 관리된 설정에 반영합니다.

3. 실행 전에 호환성을 검증합니다. 도구, 스키마 동작, 컨텍스트, 설정, 그리고 출력 지원 여부를 확인합니다. OpenAI의 strict_feature_validation=True가 하나의 구체적인 예시입니다. 이를 통해 지원되지 않는 설정이 무시되는 대신 명시적인 에러로 나타날 수 있습니다. 다른 스택들은 서로 다른 검증 방식을 노출할 것이므로, 일반적인 규칙은 의존하고 있는 요구사항을 테스트하는 것입니다.

4. 복구(recovery) 방법을 선택하기 전에 실패 원인을 분류합니다. 타임아웃(timeout), 기능 누락, 그리고 반복되는 제공자 불안정성은 각각 다른 대응을 필요로 합니다.

5. 실행된 경로에 대한 영수증(receipt)을 발행합니다. 설정(configuration)은 의도(intent)를 보여주고, 영수증은 실행(execution)을 보여줍니다.

순서가 중요합니다. 호환성 검증 전에 폴백(fallback) 선택이 일어나면, 일반적인 목록이 계약을 조용히 약화시킬 수 있습니다.

기능에 대해서는 폐쇄형 실패(fail closed), 가용성에 대해서는 장애 조치(fail over)

계속 작동하도록 설계된 시스템에서 "폐쇄형 실패 (Fail closed)"라는 용어는 경직되게 들릴 수 있습니다. 유용한 질문은 "무엇이 실패했는가"입니다.

재시도 (Retries)는 일시적인 시도를 처리하고, 폴백 (fallbacks)은 대체 실행 경로를 선택하며, 서킷 브레이커 (circuit breakers)는 반복되는 실패로 트래픽을 보내는 것을 중단합니다. 기능 거부 (Capability rejection)는 더 이른 단계에서 발생합니다. 이는 특정 경로가 이 작업을 아예 수행할 수 없음을 의미합니다. 이러한 메커니즘들을 하나의 체인으로 평탄화(Flattening)하면, 녹색 실행(green runs)은 늘어나지만 무엇이 "완료"되었는지에 대한 확실성은 줄어들어 기만적인 가동 시간 (uptime)을 만들어냅니다.

실질적인 결과는 간단합니다. 범용 텍스트 모델은 비상 상황에서 도구 기반의 탐색 (tool-backed discovery)을 수행할 수 없으며, 서로 다른 스키마 (schema) 동작을 가진 평가 경로 (evaluation route)는 대체하기 전에 반드시 검증이 필요합니다. 경로가 필수적인 도구를 잃어버린다면 컨텍스트 윈도우 (context window)가 더 커지는 것도 무의미합니다. 모든 대체 수단은 단순히 답변을 생성하는 것이 아니라, 현재의 계약 (contract)을 통과해야 합니다.

이 '폐쇄형 실패 (fail-closed)' 규칙은 소스에 명시된 라우팅 및 검증 제어에서 도출된 이 글의 운영 권장 사항입니다. 어떤 벤더도 정확히 이 문구의 정책을 강제하지는 않습니다.

설정을 검증하지 말고, 런타임을 검증하라

훌륭한 경로 테이블 (route table)이라 할지라도 재시도, 런타임 오버라이드 (runtime override), 또는 제공자 실패 이후에 무슨 일이 일어났는지는 알려줄 수 없습니다. 실행(run)에서 얻은 증거만이 그 간극을 메울 수 있습니다.

OpenAI Agents SDK는 실행 (runs), 에이전트 (agents), 모델 생성 (model generations), 도구 (tools), 가드레일 (guardrails), 그리고 핸드오프 (handoffs)에 걸친 중첩된 트레이싱 (nested tracing)을 문서화합니다. Vercel은 루트 생성 (root generation), 모델 호출 (model calls), 단계 (steps), 도구 (tools), 사용량 (usage), 오류 (errors), 그리고 선택된 컨텍스트 (selected context)를 아우르는 텔레메트리 (telemetry)를 설명합니다. 이러한 인터페이스들은 간결한 라우팅 영수증 (routing receipt)을 실용적으로 만들어 줍니다.

유용한 영수증에는 다음과 같은 내용이 포함될 수 있습니다:

stage: discovery
contract_version: 3
selected_route: research-primary
...

이 스키마는 권장 사항일 뿐, 어느 SDK에서 제공하는 표준은 아닙니다. 이 스키마의 역할은 명확합니다. 선택된 경로와 실제 경로를 보여주고, 변경 사항을 설명하며, 대체 수단이 계약을 통과했는지 기록하고, 최종 결과물 (terminal artifact)을 가리키는 것입니다.

영수증(receipt)이 초안이 정확하거나 훌륭하다는 것을 증명할 수는 없습니다. 영수증은 운영자가 라우팅 실패(routing failures), 도구 실패(tool failures), 그리고 출력 품질 문제(output-quality problems)를 분리하는 데 도움을 줍니다. 평가는 여전히 자체적인 역할을 수행해야 합니다.

추적(Tracing)은 생성(generation) 및 함수 스팬(function spans)에 민감한 입력 또는 출력이 포함될 수 있기 때문에 데이터 처리 문제를 야기합니다. 진단에 필요한 것만 캡처하고, 의도적으로 비식별화(redact)하며, 액세스를 제한하고, 보존 규칙(retention rules)을 설정하십시오. 기본적으로 모든 것을 기록하는 것은 관측성(observability) 전략이 아니라 부채(liability)입니다.

비용과 복잡성에 대한 반론은 타당합니다

라우터(router)는 코드, 설정, 테스트, 그리고 또 다른 실패 지점을 추가합니다. 그 비용은 실재하므로, 역량 차이가 가장 명확한 두 단계부터 시작하십시오. 해당 단계들의 계약(contracts)을 정의하고, 아주 작은 승인된 라우트 테이블(route table)을 유지하며, 폴백(fallback) 과정에서 사라질 가능성이 가장 높은 요구사항에 대해 하나의 사전 점검(preflight check)을 추가하십시오. 비식별화된 영수증을 기록한 다음, 의도적으로 하나의 제공자(provider) 실패를 유도하여 대체 수단이 계약을 준수하는지 또는 중단되는지 확인하십시오.

역량, 리스크, 또는 결과물(artifact)의 의미론(semantics)이 실질적으로 변하는 경우에만 라우팅하십시오. 첫 번째 경로가 이미 네 가지 단계의 계약을 모두 통과한다면 두 번째 모델을 추가하는 것은 가치가 없습니다. 그런 경우에는 네 개의 명시적인 할당을 가진 하나의 모델이 포함된 가장 단순하고 정확한 테이블이 정답입니다.

비용 제어 또한 여기에 해당하지만, 라우팅이 자동으로 돈을 절약해 줄 것이라는 약속을 전제로 해서는 안 됩니다. 추론 노력(reasoning effort), 모델 계층(model tier), 재시도(retries), 그리고 예산 상한선(budget ceilings)은 단계별로 할당하고 측정할 수 있는 정책 차원(policy dimensions)입니다. 추가적인 추론이 항상 더 나은 것은 아니며, 더 저렴한 경로는 이후의 모든 단계에서 소비되는 결과물(artifact)을 손상시킨다면 나쁜 거래입니다.

복잡성은 눈에 보이는 속성을 얻어야 합니다: 즉, 워크플로가 선언된 작업을 수행하거나 수행할 수 없음을 보고해야 합니다. 그러한 속성이 없다면 라우터는 단지 더 정교해진 폴백 체인일 뿐입니다.

신뢰성이란 작업을 보존하는 것을 의미합니다

AI 단계의 출력이 잘 읽힌다는 이유만으로, 해당 단계가 제대로 작동했다는 증거로 오해하기 쉽습니다. 더 안전한 시퀀스는 계약 (contract)을 선언하고, 승인된 경로를 해결 및 검증하며, 실패 클래스 (failure class)에 따라 복구하고, 해당 결과물 (artifact)을 생성한 런타임 (runtime)을 기록하는 것입니다.

그런 다음 일반적인 폴백 체인 (fallback chains)이 회피하는 질문을 던져보십시오. 만약 오늘 기본 제공자 (primary provider)가 실패했다면, 폴백이 동일한 작업을 수행했다는 것을 증명할 수 있습니까? 아니면 단지 그 결과물이 그럴듯한 텍스트를 생성했다는 사실만 알게 될 뿐입니까?

Source notes

• Models - OpenAI Agents SDK
• Tracing - OpenAI Agents SDK
• AI SDK 7 is now available - Vercel
• 6 LLM routing strategies for teams running multi-model production traffic - Vercel