에이전트 프레임워크 파편화와 평가 파이프라인의 한계

AI 개발 팀들은 에이전트 프레임워크의 다양성이 급증하는 반면 평가 도구의 발전은 이를 따라가지 못하는 비대칭적 상황에 직면했다. 기존의 평가 시스템은 특정 SDK, 특정 LLM 클라이언트, 혹은 특정 트레이싱 패턴에 의존하여 구축되었기에 호환 범위를 벗어나는 순간 평가 파이프라인이 즉시 중단되는 구조적 한계를 가진다. 실무자들은 워크플로 오케스트레이션 모델을 위해 LangGraph를 선택하거나, 검색 파이프라인 통합을 위해 LlamaIndex를 사용하며, 조직의 GPT 표준화를 위해 OpenAI Agents SDK를 도입하는 등 목적에 따라 도구를 선택한다. 또한 멀티 에이전트 협업에는 Google ADK를, 앤스로픽의 네이티브 기능 활용에는 Claude Agent SDK를, 모델 중심 루프를 통한 빠른 구축에는 Strands Agents를 활용해 Amazon Bedrock AgentCore에 배포한다.

이러한 프레임워크의 다양성은 평가 단계에서 심각한 파편화 문제를 야기한다. 개발 팀이 성능 최적화를 위해 LlamaIndex에서 LangGraph로 전환하거나 여러 도구를 혼용할 경우, 기존 평가 시스템은 변경된 SDK의 함수 호출 방식이나 응답 구조를 인식하지 못해 작동 불능 상태가 된다. 결국 실무자는 프레임워크를 바꿀 때마다 평가 지표 수집 코드를 처음부터 다시 설계해야 하며, 이는 도구의 유연함이 오히려 전체적인 평가 체계 구축 비용을 상승시키는 결과로 이어진다. 이러한 환경에서 개발자는 특정 프레임워크에 종속되지 않고 성능을 객관적으로 측정할 수 있는 표준화된 평가 계층의 필요성을 느끼게 된다.

Amazon Bedrock AgentCore Evaluations의 디커플링 전략

Amazon Bedrock AgentCore Evaluations는 평가 로직을 프레임워크 선택으로부터 완전히 분리(Decoupling)함으로써 파편화 문제를 해결한다. 이 서비스는 어떤 SDK를 사용하여 에이전트를 구현했는지와 관계없이 동일한 평가 체계를 적용할 수 있도록 설계되었으며, 이를 위해 Amazon Bedrock AgentCore runtime이 호스팅, 확장, 메모리 관리 및 관찰성 인프라를 통합 제공한다. 개발 팀은 프로젝트마다 관찰성 인프라를 개별적으로 구축할 필요 없이, 런타임 환경에서 에이전트를 실행하고 결과물을 표준화된 방식으로 평가 서비스에 전달하여 성능 측정의 일관성을 확보한다.

이 시스템의 핵심은 모든 주요 프레임워크가 네이티브하게 혹은 커뮤니티 라이브러리를 통해 지원하는 OpenTelemetry를 활용한다는 점이다. 에이전트의 텔레메트리 데이터가 OpenTelemetry를 통해 흐르기만 하면, 하단에 어떤 SDK가 위치하든 평가 서비스가 이를 읽어 점수를 산출할 수 있다. 결과적으로 개발자는 특정 벤더의 도구에 얽매이지 않고 최적의 프레임워크를 선택할 수 있는 자유를 얻게 되며, 인프라 수준에서 제공되는 관찰성 도구를 통해 평가 파이프라인의 유지보수 공수를 획기적으로 줄일 수 있다.

OpenTelemetry 기반의 세션 재구성과 3가지 핵심 스팬 역할

OpenTelemetry는 분산 시스템의 트레이스, 메트릭, 로그를 표준화하는 벤더 중립적 프레임워크로서 에이전트의 실행 기록을 체계적으로 관리한다. 트레이스는 스팬(Span)이라는 단위가 트리 구조로 연결된 형태이며, 각 스팬은 작업 이름, 타임스탬프, 타입 지정 속성 및 이벤트 정보를 포함하는 단일 작업 단위를 나타낸다. AgentCore runtime 환경에서는 AWS Distro for OpenTelemetry(ADOT)가 수집 백엔드 역할을 수행하여, OTLP(OpenTelemetry Protocol)를 통해 전송된 스팬과 이벤트 레코드를 Amazon CloudWatch로 라우팅한다.

평가 서비스는 수집된 수많은 스팬 중 세션을 재구성하고 점수를 매기기 위해 정확히 세 가지의 스팬 역할(Span Role)만을 식별하여 사용한다. 첫째는 사용자의 요청 정보가 담긴 Input 스팬, 둘째는 에이전트가 외부 기능을 수행한 Tool Call 스팬, 셋째는 최종 응답을 생성한 Output 스팬이다. 서비스는 수신된 모든 스팬을 분류하여 이 세 가지 역할에서 필요한 값을 추출하고, 나머지 검색(Retrieval), 리랭킹(Reranking), 가드레일(Guardrail), 메모리 관련 스팬들은 추가 컨텍스트로 처리하여 무시하거나 참고 정보로만 활용한다. 이러한 방식은 향후 새로운 스팬 종류가 추가되더라도 서비스가 오류를 일으키지 않고 무시할 수 있게 하여 전방 호환성을 유지한다.

스키마 통합과 scope.name 기반의 자동 인식 메커니즘

AgentCore Evaluations는 OpenTelemetry GenAI semantic conventions와 OpenInference 사양이라는 두 가지 서로 다른 스키마를 하나의 결과로 통합하여 처리한다. OpenTelemetry GenAI는 chat, embeddings, execute_tool, plan 등의 운영 단위를 정의하며, OpenInference는 LLM, TOOL, RETRIEVER, GUARDRAIL 등의 스팬 종류로 데이터를 분류한다. 실제 운영 환경에서는 이 두 표준의 명명 규칙이 혼재되어 나타나지만, 평가 서비스는 이를 브릿징하여 프레임워크에 관계없이 동일한 데이터 구조로 변환해 평가자(Evaluator)에게 전달한다.

시스템은 각 스팬과 이벤트 레코드에 찍힌 `scope.name` 속성을 통해 어떤 instrumentation 라이브러리가 사용되었는지 자동으로 식별한다. `opentelemetry.instrumentation.*` 또는 `openinference.instrumentation.*` 접두사로 시작하는 라이브러리는 제네릭 경로를 통해 자동으로 인식되어 처리된다. 반면 `mycompany.agent.tracing`과 같이 표준 접두사를 따르지 않는 사용자 정의 scope 이름은 스팬 내부 구조가 표준을 따르더라도 인식 대상에서 제외된다. 이는 라이브러리 제작자가 명시적으로 표준 스키마 준수를 선언한 경우에만 데이터를 수집함으로써 분석 과정의 데이터 오염을 방지하기 위한 제약 조건이다.

평가 실행 전제 조건과 실무적 검증 기준

에이전트 평가를 성공적으로 수행하기 위해서는 두 가지 필수 전제 조건이 충족되어야 한다. 첫째는 그룹화 조건으로, 에이전트의 스팬이 호출 시 사용된 `runtimeSessionId`와 일치하는 `session.id` 속성을 반드시 보유해야 한다. AgentCore 런타임에서는 ADOT가 이 속성을 자동으로 주입하므로 별도의 코드 수정이 필요 없으나, 커스텀 환경에서는 해당 속성의 일치 여부를 반드시 확인해야 한다. 둘째는 데이터 소스에 스팬뿐만 아니라 실제 메시지 콘텐츠가 포함되어야 한다는 점이다. 통합 관찰성 설정이 된 에이전트는 자동으로 처리되지만, 그렇지 않은 경우 `aws/spans` 로그그룹 외에 개별 에이전트 로그그룹이 정상적으로 설정되었는지 점검해야 한다.

세션 재구성이 완료되면 GoalSuccessRate(작업 완수율), Correctness(정확성), Helpfulness(유용성) 및 커스텀 LLM-as-a-judge 지표를 통해 모든 프레임워크의 성능을 동일한 기준으로 측정한다. 현재 이 체계가 지원하는 프레임워크는 Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK, Claude Agent SDK이며, 상세 내용은 Supported agent frameworks documentation에서 확인할 수 있다. 실무자는 도입하려는 라이브러리의 `scope.name` 접두사 준수 여부를 확인하여 평가 체계 편입 가능성을 검증해야 한다. 결국 특정 SDK에 종속되지 않은 평가 체계를 구축하여 성능 최적화를 위한 프레임워크 교체 비용을 낮추는 것이 실무적인 핵심이다.