대부분의 에이전트 시스템은 단순한 통합 결정으로 시작합니다. 검색, 스크래핑(Scraping) 또는 브라우저 자동화를 위한 제공업체(Provider)를 선택한 다음, 에이전트가 웹이 필요할 때마다 이를 호출하는 방식입니다.

이는 프로토타입에서는 작동합니다. 하지만 "웹 액세스"는 단일 역량이 아니기 때문에 프로덕션 환경에서는 취약해집니다.

검색 요청은 관련 링크가 필요합니다. 스크래핑 요청은 알려진 URL로부터 깨끗한 콘텐츠가 필요합니다. 출처가 포함된 답변(Sourced-answer) 요청은 인용과 함께 하는 합성이 필요합니다. 브라우저 액션(Browser-action) 요청은 라이브 페이지와의 성공적인 상호작용이 필요합니다. 이러한 작업들은 서로 다른 성공 조건, 지연 시간(Latency) 프로필, 비용 및 실패 모드를 가집니다.

따라서 라우팅 단위는 벤더(Vendor)가 아니라 **역량 (Capability)**이 되어야 합니다.

이 글은 그러한 라우팅 레이어를 구축하는 실질적인 방법을 제시합니다. 목표는 보편적으로 가장 좋은 제공업체 하나를 선택하는 것이 아닙니다. 각 도구 호출(Tool call)을 측정 가능하고, 교체 가능하며, 에이전트가 실제로 필요로 하는 결과와 일치하도록 만드는 것입니다.

엔드포인트(Endpoint)가 아닌 결과(Outcome)부터 시작하세요

제공업체를 선택하기 전에, 각 역량에 대해 성공적인 결과가 무엇을 의미하는지 정의하십시오.

유용한 역량 계약(Capability contract)은 다섯 가지 부분으로 구성됩니다:

1. 입력 계약 (Input contract): 쿼리(Query), URL, 스키마(Schema), 문서 또는 자연어 목적.
2. 성공 술어 (Success predicate): 응답을 사용 가능하게 만드는 최소 조건.
3. 품질 측정 (Quality measure): 관련성, 추출 정확도, 커버리지, 콘텐츠 청결도 또는 작업 완료 여부.
4. 마감 시간 (Deadline): 에이전트가 폴백(Fallback)하거나 중단하기 전까지 사용할 수 있는 지연 시간 예산.
5. 실패 정책 (Failure policy): 어떤 오류가 재시도 가능한지, 어떤 오류가 다른 제공업체를 필요로 하는지, 그리고 어떤 오류를 에이전트에 반환해야 하는지.

웹 검색을 생각해 보십시오. 200 OK 응답만으로는 충분하지 않습니다. 결과에 관련 없는 링크가 포함되어 있거나, 요청된 시간 범위를 놓치거나, 다음 추론 단계에 충분한 문맥(Context) 없이 스니펫(Snippet)만 반환한다면 그 결과는 여전히 쓸모없을 수 있습니다.

문서 파싱 (Document parsing)의 경우, 성공을 위해서는 읽기 가능한 텍스트, 최소 페이지 커버리지 비율 (page-coverage ratio), 그리고 스캔된 페이지에 대한 OCR (광학 문자 인식)이 필요할 수 있습니다. 브라우저 액션 (Browser actions)의 경우, 성공 여부는 예외 (Exception)의 발생 여부가 아니라 요청된 상태 변화 (State change)와 연계되어야 합니다.

이러한 구분은 흔히 발생하는 관측 가능성 (Observability) 오류, 즉 전송 성공 (Transport success)을 작업 성공 (Task success)으로 간주하는 실수를 방지합니다.

역량별로 하나의 스코어카드 구축

성공의 기준이 명확해지면, 서로 관련 없는 작업들을 하나의 전역 순위 (Global ranking)로 결합하는 대신 각 역량 (Capability) 내에서 제공자 (Provider)를 평가해야 합니다.

실용적인 스코어카드에는 네 가지 차원이 필요합니다.

1. 품질 (Quality)

품질은 해당 역량과 일치해야 합니다.

• 검색 (Search): 선택된 컷오프 (Cutoff)에서의 결과 재현율 (Recall) 또는 관련성 (Relevance).
• 스크래핑 (Scraping): 콘텐츠 완전성 (Completeness), 마크다운 (Markdown)의 깔끔함, 그리고 까다로운 페이지에서의 성공 여부.
• 구조화된 추출 (Structured extraction): 알려진 스키마 (Schema)에 대한 필드 수준의 정밀도 (Precision) 및 재현율 (Recall).
• 크롤링 (Crawling): 발견된 페이지 커버리지 (Discovered-page coverage) 및 중복 제어.
• 문서 파싱 (Document parsing): 텍스트 정확도, 읽기 순서 (Reading order), 그리고 OCR 커버리지.
• 브라우저 액션 (Browser actions): 요청된 상호작용의 완료 및 결과 상태의 검증.

모든 항목에 대해 하나의 일반적인 "품질" 테스트를 적용하는 것을 피하십시오. 지표는 다운스트림 에이전트 (Downstream agent)가 안전하게 사용할 수 있는 것이 무엇인지를 설명해야 합니다.

2. 지연 시간 (Latency)

호출자 (Caller)의 관점에서 실제 경과 시간 (Wall-clock latency)을 측정하십시오. 중앙값 지연 시간 (Median latency)은 일반적인 동작을 파악하는 데 유용하지만, 운영 결정을 내릴 때 유일한 수치로 사용되어서는 안 됩니다.

라우팅 정책에는 에이전트의 전체 마감 시간 (Deadline)을 기반으로 한 타임아웃 (Timeout)도 필요합니다. 만약 워크플로 (Workflow)에 10초가 남았다면, 품질은 매우 뛰어나지만 중앙값 지연 시간이 12초인 제공자는 해당 호출에 대해 실행 가능한 기본 경로 (Primary route)가 될 수 없습니다.

호출이 체인(Chain) 형태로 연결될 때는 꼬리 지연 시간 (Tail latency)이 중요합니다. 개별적으로는 수용 가능한 수준인 여러 번의 지연이 모이면, 최종 합성 (Synthesis) 단계가 시작되기도 전에 에이전트의 전체 예산을 모두 소진할 수 있습니다.

3. 성공적인 결과당 비용 (Cost per successful result)

요청당 가격 (Price per request)은 비교하기 쉽지만 종종 오해를 불러일으킵니다.

운영 지표는 다음과 같습니다:

성공적인 결과당 비용 = 총 청구 비용 / 사용 가능한 결과의 수

한 제공업체가 요청당 $0.001를 청구하고 작업의 절반을 성공한다고 가정해 봅시다. 다른 제공업체는 $0.0015를 청구하고 90%를 성공합니다. 재시도(retries)와 2차 처리(secondary processing)를 무시할 때, 이들의 실질 비용은 다음과 같습니다:

• 제공업체 A: 성공적인 결과당 $0.002
• 제공업체 B: 성공적인 결과당 약 $0.00167

명목상 더 저렴한 제공업체가 결과물 기준으로 측정했을 때는 더 비쌉니다.

실패는 기술적으로 유효한 응답을 반환하더라도 분모 계산에 포함되어야 합니다. 에이전트가 해당 데이터를 사용할 수 없다면, 시스템은 여전히 실패한 시도에 대해 비용을 지불한 것이기 때문입니다.

4. 에러율 (Error rate)

전송 에러(transport errors), 타임아웃(timeouts), 잘못된 형식의 응답(malformed responses), 그리고 역량 수준의 실패(capability-level failures)를 별도로 추적하십시오.

이러한 분리는 다음과 같은 서로 다른 질문에 답하는 데 도움이 됩니다:

• 제공업체를 사용할 수 없는 상태인가?
• 통합(integration) 과정에서 응답을 잘못 파싱(parsing)하고 있는가?
• 제공업체가 유효하지만 품질이 낮은 데이터를 반환하고 있는가?
• 대상 사이트가 요청을 차단하고 있는가?
• 작업이 제공업체가 지원하는 형태(shape)를 벗어났는가?

단일한 에러율 수치는 해결 경로(remediation path)를 가려버립니다.

코퍼스(Corpus)를 고정하십시오

비교는 제공업체들이 동일한 작업을 수행할 때만 유용합니다.

역량(capability)별로 버전이 관리되는 작업 코퍼스(task corpus)를 사용하십시오. 특정 평가에 참여하는 모든 제공업체는 동일한 쿼리(queries), URL, 대상 스키마(target schemas), 마감 기한(deadlines), 그리고 통과 기준(pass criteria)을 받아야 합니다. 코퍼스가 변경되면 버전을 올리고 새로운 실행 날짜를 기록하십시오.

이는 미묘한 편향(bias)의 원인을 통제합니다. 예를 들어, 한 제공업체에는 쉬운 페이지를 주고 다른 제공업체에는 안티봇(anti-bot) 시스템으로 보호되는 페이지를 준 다음, 작업 부하가 동일한 것처럼 성공률을 비교하는 오류를 방지합니다.

코퍼스에는 데모용 입력값뿐만 아니라 어려운 사례들도 포함되어야 합니다. 프로덕션 환경에서의 실패는 스캔된 문서, 동적 페이지(dynamic pages), 속도 제한이 걸린 도메인(rate-limited domains), 특이한 스키마, 그리고 하나 이상의 소스에서 증거를 요구하는 쿼리에서 발생하는 경향이 있습니다.

이러한 설계의 공개적인 사례 중 하나는 NativePort에서 운영하는 역량 기반 벤치마크 방법론 (capability-based benchmark methodology)입니다. 이 방법론은 역량(capability)별로 고정된 코퍼스(corpus)를 유지하며, 실행 날짜와 함께 품질, 중앙값 지연 시간 (median latency), 성공적인 호출당 비용, 그리고 에러율을 발표합니다. 여기서 중요한 패턴은 특정 종합 점수(composite score)가 아니라, 역량의 분리 및 기초 측정값의 공개입니다.

실행으로부터의 선택 분리

에이전트(agent)는 역량을 요청해야 합니다. 라우팅 계층 (routing layer)은 어떤 제공자(provider)가 이를 실행할지 결정해야 합니다.

개념적으로 요청에는 다음 내용이 포함됩니다:

• 요구되는 역량 (required capability);
• 입력 페이로드 (input payload);
• 마감 기한 (deadline);
• 최소 품질 임계값 (minimum quality threshold);
• 지리적 위치나 출력 형식과 같은 선택적 제약 조건.

라우터는 해당 계약(contract)을 지원하는 제공자만을 평가합니다. 그런 다음 최신 적격 스코어카드 (scorecard)와 현재의 운영 상태 (operational health)를 사용하여 기본 경로를 선택합니다.

제공자별 특정 요청 필드가 실제 사용자 요구 사항을 나타내는 경우가 아니라면, 에이전트의 계획 인터페이스 (planning interface)로 유출되지 않도록 하십시오. 그렇지 않으면 모든 제공자 변경이 에이전트 프롬프트 (agent-prompt)의 변경으로 이어지게 됩니다.

동시에, 모든 업스트림 (upstream) 응답을 하나의 지나치게 일반적인 스키마 (schema)로 강제하는 것을 피해야 합니다. 정규화 (normalization)는 라우팅 경계에서 유용하지만, 에이전트가 필요할 때 역량별 특정 정보에 접근할 수 있어야 합니다.

좋은 절충안은 상태 (status), 타이밍 (timing), 비용 (cost), 출처 (provenance), 그리고 결과 분류 (outcome classification)를 포함하는 안정적인 엔벨로프 (envelope)를 구성하되, 그 내부에 역량별 응답을 보존하는 것입니다.

폴백(fallback)을 재시도가 아닌 정책으로 취급하기

재시도 (retry)와 제공자 폴백 (provider fallback)은 서로 다른 문제를 해결합니다.

재시도는 일반적으로 일시적인 실패 (transient failure) 후에 동일한 작업을 동일한 제공자에게 다시 보내는 것입니다. 폴백은 첫 번째 경로가 남은 예산 내에서 역량 계약 (capability contract)을 충족할 수 없기 때문에 다른 제공자에게 작업을 보내는 것입니다.

AWS Builders’ Library의 재시도 및 백오프(retries and backoff) 가이드는 왜 재시도에 타임아웃(timeout), 제한(limit), 백오프(backoff), 지터(jitter)가 필요한지 설명합니다. 무제한 재시도는 과부하를 증폭시키고 부분적인 장애를 더 광범위한 사고로 악화시킬 수 있습니다.

에이전트 도구(agent tools)의 경우, 폴백(fallback) 정책은 다음 사항을 고려해야 합니다:

• 장애가 일시적인지 여부;
• 호출을 반복하는 것이 안전한지 여부;
• 남은 지연 시간 예산(latency budget);
• 이미 지출된 비용;
• 다른 제공자가 진정으로 독립적인 경로를 제공하는지 여부;
• 중복 실행이 외부 부작용(side effect)을 일으킬 수 있는지 여부.

검색(search) 및 읽기 전용 스크래핑(read-only scraping)은 양식을 제출하거나 상태를 변경(mutate state)하는 브라우저 동작보다 일반적으로 재시도하기가 더 쉽습니다. 상태 유지 동작(stateful actions)의 경우, 시스템은 안전하게 다시 시도하기 전에 멱등성(idempotency) 또는 동작 후 검증(post-action verification)이 필요합니다.

유용한 규칙은 동일한 경로가 다른 결과를 생성할 가능성이 높을 때만 재시도하는 것입니다. 그렇지 않으면 경로를 전환하거나 중단하십시오.

요청뿐만 아니라 결과(outcomes)를 계측(instrument)하십시오

라우팅은 프로덕션 피드백이 스코어카드(scorecards)에 도달할 때만 개선됩니다.

최소한 다음 사항을 기록하십시오:

• 역량(capability) 및 코퍼스(corpus) 또는 작업 클래스(task class);
• 선택된 제공자 및 폴백 순서(fallback sequence);
• 시작 시간, 마감 시간(deadline) 및 지속 시간(duration);
• 사용 가능한 경우 청구된 비용;
• 전송 상태(transport status);
• 파싱 상태(parse status);
• 역량 수준의 성공 여부;
• 폴백 사유;
• 에이전트가 사용한 최종 결과.

분산 트레이싱(distributed traces)을 사용하여 에이전트의 결정, 도구 호출, 재시도, 폴백 및 최종 결과를 연결하십시오. OpenTelemetry HTTP 시맨틱 컨벤션(HTTP semantic conventions)은 HTTP 클라이언트 스팬(spans)을 위한 표준 기반을 제공하며, 역량 및 결과 필드는 애플리케이션 속성(application attributes)으로 추가할 수 있습니다.

높은 카디널리티(high-cardinality) 데이터는 주의해야 합니다. 원시 쿼리(raw queries), 전체 URL 및 추출된 콘텐츠에는 민감한 정보가 포함될 수 있으며 텔레메트리(telemetry) 비용을 높일 수 있습니다. 제한된 작업 클래스, 적절한 경우 해시된 식별자(hashed identifiers), 그리고 명시적인 보관 규칙(retention rules)을 사용하는 것이 좋습니다.

가장 중요한 것은 “요청 완료(request completed)”와 “에이전트가 사용 가능한 결과를 수신함(agent received a usable result)” 사이의 차이를 보존하는 것입니다. 라우터가 개선하고자 하는 지표는 바로 두 번째 지표입니다.

라우팅 블랙박스를 만들지 않고 배포하기

역량 라우터(capability router)는 운영자에게 설명 가능해야 합니다.

모든 결정에 대해 다음 질문에 답할 수 있을 만큼 충분한 정보를 보유해야 합니다:

• 어떤 제공자(providers)가 적격했는가?
• 왜 기본 경로(primary route)가 선택되었는가?
• 어떤 임계값(threshold)이 폴백(fallback)을 트리거했는가?
• 벤치마크 데이터가 얼마나 오래되었는가?
• 최종 결과가 성공 술어(success predicate)를 충족했는가?
• 전체 시도에 비용이 얼마나 들었는가?

섀도 모드(shadow mode)로 시작하십시오. 기존 통합 시스템이 트래픽을 계속 처리하게 두는 동안, 라우터는 자신이 내렸을 결정을 계산하도록 합니다. 자동 전환을 활성화하기 전에 이러한 결정들을 실제 결과와 비교하십시오.

그다음, 한 번에 하나의 역량씩 라우팅을 도입하십시오. 검색(Search)은 성공 술어와 재시도 동작이 더 단순하기 때문에 상태 유지 브라우저 자동화(stateful browser automation)보다 일반적으로 더 쉽습니다. 장애 발생 시를 대비한 수동 오버라이드(manual override)와 점수 데이터가 누락되었거나 오래된 경우를 위한 결정론적 기본값(deterministic default)을 유지하십시오.

라우터는 예측 가능한 방식으로 성능이 저하(degrade)되어야 합니다. 벤치마크 데이터가 누락되었다고 해서 그것이 특정 제공자가 우수하다는 증거로 암묵적으로 간주되어서는 안 됩니다.

실무적인 구현 체크리스트

역량 우선 라우팅(capability-first routing)을 활성화하기 전에 다음 사항을 확인하십시오:

• 모든 역량에 명문화된 성공 술어(success predicate)가 있는가;
• 제공자들이 동일하고 버전 관리된 작업(versioned tasks)을 기준으로 비교되는가;
• 실패 사례가 유효 비용(effective-cost) 계산에 포함되는가;
• 전송 오류(transport errors)와 사용 불가능한 응답이 별도로 분류되는가;
• 재시도(retries)에 제한, 타임아웃, 백오프(backoff), 지터(jitter)가 적용되어 있는가;
• 폴백(fallbacks)이 남은 마감 시간과 부작용 위험(side-effect risk)을 준수하는가;
• 트레이스(traces)가 제공자 시도와 최종 에이전트 결과를 연결하는가;
• 벤치마크 날짜가 운영자에게 보이는가;
• 누락되었거나 오래된 데이터에 대한 명시적인 기본 정책이 있는가;
• 라우팅 결정을 사후에 설명할 수 있는가.

핵심 아이디어는 간단합니다. 에이전트에게는 “웹 제공자 (web provider)”가 필요한 것이 아닙니다. 에이전트에게 필요한 것은 특정 예산(budget) 내에서 성공적인 검색 (search), 추출 (extraction), 크롤링 (crawl), 파싱된 문서 (parsed document), 또는 완료된 브라우저 동작 (browser action)입니다.

라우팅이 이러한 역량 계약 (capability contracts)을 따를 때, 제공자 선택은 영구적인 아키텍처적 약속이 아닌 운영 정책 (operational policy)이 됩니다. 이를 통해 에이전트는 측정하기 더 쉬워지고, 장애 조치 (fail over)가 더 안전해지며, 발전시키는 데 드는 비용이 줄어듭니다.

고지 사항: 이 기사는 NativePort에 의해 게시되었으며, 해당 회사의 공개 벤치마크 방법론이 구현 사례로 인용되었습니다. 본 기사는 특정 제품이나 제공자를 추천하지 않습니다. 초안은 AI의 도움을 받아 작성되었으며, 게시 전 인용된 출처 및 공개 방법론을 바탕으로 검토되었습니다.