에이전트 평가

앞의 여섯 장에서는 단일 에이전트의 구축을 펼쳐 보였습니다. 컨텍스트, 지식, 도구, 코딩 역량, 그리고 관찰 공간과 행동 공간입니다. 하지만 구축이 끝났다고 해서 올바르게 구축된 것은 아닙니다. 결과를 안정적으로 측정할 수 있어야 이후의 모델 훈련과 시스템 진화가 신뢰할 수 있는 방향을 얻습니다.

에이전트 시스템을 구축할 때 개발자는 정답이 명확하지 않은 수많은 설계 선택에 직면합니다.

• 어떤 모델을 사용해야 할까요?
• 모델이 어떤 도구를 호출할 수 있어야 할까요?
• 지식 베이스에는 어떤 데이터를 어떤 구조로 저장해야 할까요?
• 사용자 메모리는 어떻게 구현해야 할까요?
• 모델의 프롬프트와 스킬은 어떻게 구성해야 할까요?
• 하네스(harness)에는 어떤 제약을 추가해야 할까요?
• 평가 결과를 에이전트의 지속적 진화를 위한 학습 신호로 어떻게 바꿔야 할까요?

평가는 이러한 의사결정을 과학적 토대 위에 올려놓습니다. 체계적인 비교 실험(한 번에 변수 하나만 바꾸고 효과를 관찰)과 제거 실험(한 번에 컴포넌트 하나를 비활성화하고 전체 성능 변화를 관찰)을 통해 진정한 역량 향상과 겉으로 드러난 변동을 구분하고, 작은 것을 아끼려다 큰 것을 잃는 실수를 피할 수 있습니다. 소프트웨어 엔지니어링에는 측정할 수 없는 것은 개선할 수 없다는 말이 있습니다. 반복 가능한 평가 시스템이 없다면 에이전트는 직관에 의존해 개선할 수밖에 없습니다.

1장에서 소개한 하네스 엔지니어링의 관점에서 평가는 하네스 안에서 “검증”이라는 핵심 역할을 맡습니다. 중요한 통찰은 평가 대상이 모델 하나가 아니라 모델과 하네스의 조합이어야 한다는 것입니다. 같은 모델도 하네스에 따라 성능이 크게 달라질 수 있습니다. 어떤 팀은 하네스만 최적화하여 같은 모델의 터미널 작업 성능을 크게 높였습니다(5장 참조). 따라서 에이전트의 평가 결과가 좋지 않을 때 해결책은 모델 교체가 아니라 프롬프트, 도구 설계, 피드백 루프 같은 하네스 컴포넌트의 개선일 수 있습니다. 건전한 평가 시스템은 “모델 역량 부족”과 “하네스 설계 결함”이라는 근본적으로 다른 두 문제를 구분할 수 있어야 합니다. 이를 구분하는 일반적인 방법은 모델 교체 실험입니다. 하네스를 고정한 채 더 강하거나 약한 모델로 바꾸고 점수가 얼마나 움직이는지 관찰합니다. 더 강한 모델로도 점수가 오르지 않으면 병목은 하네스입니다. 약한 모델에서 점수가 급락하고 결과가 모델 역량에 따라 크게 요동한다면, 가장 직접적인 해석은 모델 자체가 병목이고 현재 성능이 모델에 지배된다는 것입니다. 과제 자체가 본질적으로 어렵기 때문인지, 하네스가 모델의 사전 지식에 지나치게 의존하기 때문인지는 추가로 분석해야 합니다. 이는 앞의 제거 실험과 다릅니다. 제거 실험은 하네스 컴포넌트를 비활성화하고 전체 성능 변화를 살펴보지만, 모델 교체는 하네스를 고정하고 모델만 바꿉니다. 전자는 하네스 내부에서 어느 부분이 중요한지 찾고, 후자는 병목이 모델인지 하네스인지 알려 줍니다.

모델이 빠르게 발전하는 시대에는 평가 시스템의 가치가 더 커집니다. 모델은 계속 개선되지만 공개 벤치마크 점수가 더 높은 새 모델이 여러분의 작업에서도 반드시 더 잘하는 것은 아닙니다. 오히려 일부 측면에서 이전 버전보다 나빠지는 회귀가 생길 수도 있습니다. 자체 평가 데이터셋에서 전체 평가를 실행해야만 데이터에 근거해 업그레이드를 결정할 수 있습니다. 견고한 평가 시스템이 있으면 “미래의 모델을 위한 제품 구축”도 실현 가능한 전략이 됩니다. 현재 모델의 품질이 상용 배포에 충분하지 않더라도 제품과 평가 세트를 완성하고 새 모델이 나올 때마다 성능을 추적하다가 기준을 넘는 순간 출시할 수 있습니다. 평가 체계는 네 개의 단계로 나눌 수 있다. 무엇을 성공으로 볼 것인가, 과제는 어디서 오는가, 누가 검증하는가, 점수를 어떻게 의사결정으로 바꾸는가. 그림 7-1과 같다.

평가 과제 한 건의 해부: τ²-bench의 telecom 도메인

먼저 τ²-bench의 telecom 도메인에서 실제 과제 하나를 통째로 해부해 보자. τ²-bench는 Sierra의 오픈소스 프로젝트이며, chapter7/tau2-bench-eval/README.md의 명령으로 로컬에 클론한 뒤 과제 파일 data/tau2/domains/telecom/tasks_small.json을 열면 된다.

과제 정의의 네 가지 구성 요소

다음은 그 파일에 들어 있는 과제 하나이며, 읽기 편하도록 일부를 생략했다.

{
  "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off",

  // Agent에게 전달되는 티켓
  "ticket": "사용자의 휴대폰이 인터넷에 연결되지 않고 상태 표시줄에 'No Service'가
             표시된다. 고객 John Smith, 번호 555-123-2002, 현재 프랑스 체류 중.
             속도 테스트 결과가 excellent여야 해결로 인정한다. 요금제는 바꾸지 않되
             필요하면 2.0 GB 데이터 충전은 감수한다.",

  // 사용자 시뮬레이터에게 전달되는 행동 규범
  "user_scenario": { "instructions": {
      "known_info": "You are John Smith with phone number 555-123-2002.
                     You are currently abroad in France.",
      "unknown_info": null,
      "task_instructions":
        "…express mild frustration after the first unsuccessful attempt.
         You will consider the issue resolved only when speed test returns
         excellent internet speed and nothing else. If it returns poor, fair
         or good, you will not consider the issue resolved.
         Whenever the agent asks you about your device, always ground your
         responses on the results of tool calls. …
         Never make up the results of tool calls."
  }},

  // 실행 전에 양쪽 상태를 같은 출발점으로 초기화한다
  "initial_state": { "initialization_actions": [
      { "env_type": "user",      "func_name": "turn_airplane_mode_on" },
      { "env_type": "user",      "func_name": "turn_roaming_off" },
      { "env_type": "assistant", "func_name": "enable_roaming",
        "arguments": { "customer_id": "C1001", "line_id": "L1002" } }
  ]},

  // 채점 기준
  "evaluation_criteria": {
      "actions": [
        { "requestor": "user", "name": "toggle_airplane_mode" },
        { "requestor": "user", "name": "toggle_roaming" }
      ],
      "env_assertions": [
        { "func_name": "assert_mobile_data_status", "expected_status": true },
        { "func_name": "assert_internet_speed",
          "expected_speed": 200, "expected_desc": "excellent" }
      ],
      "communicate_info": null,
      "nl_assertions": null,
      "reward_basis": ["ENV_ASSERTION"]
  }
}

이 정의에서 짚고 넘어가야 할 설계가 네 군데 있다.

사용자의 인지 경계가 명시적으로 모델링되어 있다. known_info에는 이름, 번호, 체류 국가 세 가지만 들어 있다. 비행기 모드가 켜져 있다는 것과 데이터 로밍이 꺼져 있다는 것, 즉 진짜 고장 원인 두 가지는 거기에 없다. 사용자는 모르기 때문에 먼저 말할 수 없고, Agent는 질문하고 사용자에게 확인시키는 방식으로만 얻어낼 수 있다. 이것이 점진적 정보 공개(Progressive Information Disclosure) 를 과제 정의 수준에서 구현한 모습이다. “한꺼번에 다 말하지 말라”는 프롬프트로 시뮬레이터를 묶는 것이 아니라, 사용자의 지식 범위 자체를 독립된 필드로 모델링한 것이다. 대부분의 벤치마크는 과제 시작 시점에 완전한 요구사항을 제시하지만, 현실의 사용자가 처음 꺼내는 말은 대개 “인터넷이 안 된다” 정도다. 요구를 실행 가능한 수준까지 명확히 하는 일 자체가 Agent 능력의 일부다.

시뮬레이터가 받는 것은 대사가 아니라 행동 규범이다. task_instructions에는 세 종류의 제약이 섞여 있다. 감정 설정(첫 번째 복구 시도가 실패하면 가벼운 불만을 표시한다), 수용 기준(속도 테스트가 excellent일 때만 해결로 보고 poor, fair, good은 모두 거부한다), 그리고 사실 접지(Grounding) 요구, 즉 기기 상태에 관한 어떤 답변도 도구 반환값에 근거해야 한다는 것이다. “Never make up the results of tool calls.” 세 번째가 특히 중요하다. 사실 접지 제약이 없으면 시뮬레이션된 사용자는 Agent의 유도를 따라 문제가 해결되었다고 확인해 버리고, 평가는 두 모델이 서로를 추인하는 일로 전락한다.

초기 상태는 제어 주체에 따라 나뉘어 있다. env_type은 user와 assistant 두 값을 가진다. 비행기 모드와 로밍 스위치는 사용자 쪽에, 통신사 쪽의 enable_roaming은 Agent 쪽에 속한다. 이 구분이 고장의 형태를 결정한다. 통신사 쪽에서는 로밍이 개통되어 있는데 사용자 단말에서는 꺼져 있으므로, Agent가 데이터베이스를 조회해도 “설정 정상”이라는 결론밖에 얻지 못한다. 고장은 데이터베이스에서 보이지 않는 쪽에 있고, 사용자에게 확인시켜야만 드러난다.

채점 기준은 네 층으로 나뉘어 있고, 이 과제는 그중 한 층만 채택한다. env_assertions는 최종 상태를 검증하고(모바일 데이터 사용 가능, 속도 200 Mbps 이상이며 등급 excellent), actions는 핵심 동작이 발생했는지와 어느 쪽이 수행했는지를 검증하며, communicate_info와 nl_assertions는 필요한 정보를 사용자에게 전달했는지를 검증한다. 이 과제의 reward_basis는 ENV_ASSERTION만 선언하고 있고, 나머지 층은 평소대로 계산·기록되지만 최종 보상에는 반영되지 않는다. 채점 기준은 과제마다 선언되는 것이지 전역으로 고정된 것이 아니다.

실제 실행 한 건의 궤적

이제 독자가 직접 τ²-bench telecom 도메인의 평가 과제를 실행하여 과제 설계, 사용자 시뮬레이터 설계, 과정과 결과의 검증 로직을 관찰하고, Agent의 실행 궤적을 살펴 왜 실패했는지 분석해 보기를 권한다.

실험 7-1 ★: τ²-bench 실행 및 τ-bench로부터의 진화 비교

본 실험은 τ²-bench 평가 프레임워크를 실행하여 인간-컴퓨터 상호작용 평가 환경의 설계 요점을 이해한다. 먼저 이 절에서 밟은 경로대로 과제 정의 파일을 통독한다. 각 과제는 알려진 정보, 과제 지시, 초기 상태, 성공 조건의 네 부분으로 구성된다. 이어서 전체 평가 흐름을 실행하고, 사용자 시뮬레이터와 Agent의 다중 턴 대화를 관찰하며 전형적인 실패 양상(정책 위반, 정보 누락, 과도한 상담원 이관 등)을 분석한다.

부속 저장소에는 한 번의 실행 기록(chapter7/tau2-bench-eval)이 보존되어 있다. 아래에서는 그중 성공한 실행 하나를 분석한다.

앞의 십여 턴은 계정 식별 단계다. Agent는 번호로 고객 C1001을 찾아낸 뒤 L1001, L1002, L1003 세 회선의 데이터 사용량을 차례로 조회하고, 다시 사용자가 프랑스에서 실제로 쓰는 번호를 묻는다. 17번째 메시지에서 Agent는 잘못된 결론을 내린다.

Agent(17): 번호 555-123-2002는 활성 회선에 없습니다. 가장 가까운 것은 555-123-2001입니다……

이 결론은 L1001 한 회선의 조회 결과에만 근거한 것이다. 사용자가 번호가 맞다고 고집하자 Agent는 L1002를 조회하고 나서야 일치시킨다. 결정적 전환은 30번째에서 일어난다.

사용자(30) → check_network_status(), check_status_bar() 호출

도구 반환(31): Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No

사용자(33): 휴대폰이 지금 비행기 모드라서 신호가 없는 것 같습니다. 모바일 데이터는 켜져 있지만 데이터 로밍은 꺼져 있습니다. 비행기 모드를 꺼서 시도해 볼까요?

도구 호출을 발한 쪽은 Agent가 아니라 사용자다. 이것이 이중 제어(Dual-Control) 메커니즘이다. 시뮬레이션된 사용자는 check_status_bar, toggle_airplane_mode, reseat_sim_card, run_speed_test 같은 독자적인 도구 세트를 가진다.

이후의 진단은 순조롭다. Agent가 사용자에게 비행기 모드를 끄고 로밍을 켜라고 요청하고, 사용자가 실행하자(35, 37) 상태 표시줄이 5G 풀바로 바뀐다. Agent가 속도 측정을 요청하니 275 Mbps, 등급 Excellent가 반환되고(46) 사용자가 해결을 확인한다. 두 개의 env_assertions가 모두 통과하여 reward = 1.0이 된다.

이 만점 궤적에도 검증기가 잡아내지 못한 문제가 하나 들어 있다. telecom의 Agent 정책 첫 단락에는 “You should only make one tool call at a time”이라고 명시되어 있는데, 4번째 메시지에서 Agent는 get_customer_by_phone과 get_customer_by_name을 한 번에 발행했다. 검증기가 이를 오류로 판정하지 않은 이유는 이 과제의 reward_basis가 최종 상태만 고려하기 때문이다. 이는 τ²-bench의 실수가 아니라 이진 보상의 본질적 대가다. 과정의 입도를 모델 간 비교 가능한 단일 숫자와 맞바꾼 것이다. 그러나 프로덕션 환경의 평가 시스템은 대개 그 이상을 요구한다. 옳고 그름을 판정하는 데 그치지 않고 문제가 어디에 있는지를 짚어 주어야 한다.

실패한 과제도 분석할 가치가 있다. 사용자 번호는 555-123-2002인데 Agent는 L1001 회선을 선택하고 그 3.2/5 GB 사용량을 근거로 추론을 이어 갔다. 도중에 get_details_by_id(L1001)이 그 회선의 번호가 555-123-2001이라고 분명히 반환했음에도 Agent는 그 결과를 읽고도 판단을 고치지 않았고, 이후 무관한 진단에 수십 개의 메시지를 소모한 끝에 상담원으로 이관했다. 사실 과제의 절반은 해냈다. 사용자에게 데이터 절약 모드를 끄게 했고 그 사용자 쪽 동작은 실제로 발생하여 환경에서 검증되었다. 그러나 회선 선택을 잘못한 탓에 필요한 2 GB 충전이 실행되지 않았고 세 개의 최종 상태 어서션이 모두 실패했다. 이 실패의 형태는 뒤의 “실패 귀인” 절에서 다루는 AndroidWorld 사례와 매우 닮았다. 판단을 고치는 데 필요한 증거는 이미 컨텍스트에 들어와 있었는데도 Agent가 그것을 근거로 되짚지 않은 것이다.

이 과제 하나로 평가 세트가 답해야 할 질문은 이미 모두 나왔다. 무엇을 성공으로 볼 것인가, 과제는 어디서 오는가, 누가 검증하는가, 점수를 어떻게 의사결정으로 바꾸는가. 이어지는 절에서 차례로 다룬다.

평가 지표: 성공의 정의

앞 절의 평가 결과는 다섯 과제 중 네 과제 통과였다. 0.8이라는 숫자만으로는 그 시스템을 쓸 수 있는지 판단할 수 없다. 그것이 환불 상담 Agent라면 다섯 명 중 한 명이 받아야 할 환불을 받지 못한다는 뜻이고, 취약점을 찾는 보안 Agent라면 다섯 번 중 네 번 적중은 상당히 훌륭하다. 차이는 그 업무 상황이 얼마나 높은 성공률을 요구하는가에 있다.

기술적 경이: Pass@k로 보는 능력 상한

현재의 많은 모델과 Agent는 여전히 ‘기술적 경이’ 라 부를 만한 단계에 있습니다. 여기서 경이란 충분한 시도, 넉넉한 시간, 사람의 선별을 전제로 드러나는 능력의 상한을 뜻합니다. 그중 한 번만 성공해도 “원리적으로는 가능하다”를 보이기에는 충분합니다. 이것이 바로 Pass@k 의 논리입니다. 같은 작업을 $k$ 번 실행해 적어도 한 번 통과하면 통과로 치고, 출력이 연속 점수라면 가장 좋은 한 번을 취해 Best@k 라고 부릅니다.

장시간 구동 Agent에 대한 Anthropic의 논의가 이런 상한을 잘 보여 줍니다. Agent에게 일주일간 자율적으로 일하게 해 C 컴파일러를 처음부터 작성하게 하거나, 중요한 수학 추측의 반례를 찾을 때까지 탐색을 계속하게 하거나, 오픈소스 소프트웨어를 반복해서 검토하게 해 수십 년간 남아 있던 중대한 보안 취약점을 찾아내게 하는 식입니다.

이런 공학적·과학적 탐색에서 보여 주는 것은 대개 “매번 옳게 한다”가 아니라, 탐색 예산을 충분히 늘렸을 때 마침내 나타나는 한 줄기 돌파구 궤적입니다. 과학적 발견, 취약점 발굴, 열린 창작 같은 작업에서는 이 능력 상한 자체에 가치가 있습니다. 사람이 $k$ 개의 후보 궤적 중 가장 좋은 하나를 고를 수 있기 때문입니다.

기반 모델 외에 많은 응용 기업도 ‘기술적 경이’ 전략을 씁니다. Manus가 널리 주목받은 이유는 가상 컴퓨터를 제공했기 때문입니다. 그전까지 Agent에 대한 직관이 없던 사람들이, AI도 사람처럼 컴퓨터를 조작하며 30분에서 한 시간까지 계속 일하고 복잡한 작업을 단계적으로 완성해 낸다는 것을 보게 되었습니다.

OpenClaw는 많은 사람이 Agent의 ‘살아 있는 느낌’을 처음 경험하게 한 제품입니다. 사용자는 실제 사람에게 일을 맡기듯 메신저로 작업을 배정할 수 있습니다. 컴퓨터의 모든 파일과 온라인 서비스에 접근할 수 있고, 일정 단계에 이르면 먼저 보고하거나 새로운 정보를 요청하며, 스스로를 깨워 메일을 조회하고 처리하기까지 합니다.

초기의 Manus와 OpenClaw는 복잡한 작업의 성공률이 높지 않았고 token 비용도 매우 컸습니다. 그러나 이들 Agent 프레임워크는 범용적이어서, 가장 강한 모델과 함께 쓰면 복잡한 작업에서도 Pass@k가 높게 나오며 높은 기술적 상한을 보여 줍니다. 이런 ‘기술적 경이’가 소셜 네트워크에서 대량으로 공유된 것이 이 제품들의 성공에 결정적이었습니다.

비즈니스 신뢰성: Pass^k

실제 비즈니스가 더 신경 쓰는 것은 대개 그 반대입니다. 여러 번의 시도에서 단 한 번도 틀리면 안 된다는 것입니다. 이 목표를 Pass^k(Pass consecutive k 로 읽습니다)라고 부릅니다. 같은 작업을 연속으로 $k$ 번 실행해 매번 통과해야 하고, 안전·규정 준수·환각 같은 거부권 항목을 건드려서도 안 됩니다. 이는 “Agent가 안정적으로 믿을 만하게 전달할 수 있는가”에 답하는 것이지, “가끔 기적을 만들 수 있는가”에 답하는 것이 아닙니다.

각 실행이 서로 독립이고 단회 성공률이 $p$ 라면, 두 지표의 관계는 직관적입니다.

예를 들어 단회 성공률 $p=0.6$, $k=5$ 일 때 Pass@5 $=1-0.4^5\approx99.0\%$ 로, “적어도 한 번은 성공”이 거의 항상 성립하는 것처럼 보입니다. 하지만 Pass consecutive@5 $=0.6^5\approx7.8\%$ 이므로, 다섯 번 연속 실수 없이 통과하기란 여전히 어렵습니다. 앞의 수치는 탐색 단계의 능력 천장을 재는 데 적합하고, 결제·환불·권한 변경·프로덕션 배포 같은 상황이 요구하는 신뢰성에 가까운 것은 뒤의 수치입니다.

평가 보고서에는 $k$ 회 시도의 기준을 분명히 적어야 합니다. 같은 작업을 $k$ 번 독립 표집한 것인지, 프로덕션 파이프라인에서 연속된 $k$ 개 작업인지 말입니다. 부작용이 있는 조작이라면 단순히 “성공할 때까지 재시도”해서는 안 되며, 샌드박스나 롤백 가능한 환경에서 표집하고 실패 하나하나를 신뢰성 지표에 기록해야 합니다.

평가 환경

지표 기준이 정해졌다면 다음 문제는 어디서 측정할 것인가다. 평가 환경이란 반복 실행할 수 있는 장치다. 같은 초기 상태를 주면 같은 Agent는 비교 가능한 결과를 내야 한다.

다섯 가지 구성 요소

앞에서 해부한 telecom 과제로 돌아가자. 그것을 기준점으로 삼으면, 반복 실행 가능한 평가 환경에 필요한 구성 요소는 이미 다 갖춰져 있다.

데이터셋(Dataset) 은 과제 파일 그 자체다. 초기 상태, Agent용 티켓, 시뮬레이터용 행동 규범, 수용 기준이 한 레코드로 묶이고, 한 레코드가 하나의 테스트 케이스다.

환경 상태(Environment State) 는 과제 실행 중의 가변 정보다. 데이터베이스의 고객, 회선, 요금제, 청구서에 더해 단말 쪽의 비행기 모드, 로밍, 데이터 절약 스위치, 잔여 데이터가 여기 속한다. 이는 초기화 가능해야 하며 initialization_actions가 그 초기화 스크립트다. 진실성은 상태 변화가 업무 로직을 따를 것을 요구하고, 통제 가능성은 실행 전마다 같은 출발점으로 돌아올 수 있을 것을 요구한다.

도구 인터페이스(Tools) 는 양쪽에 나뉘어 속한다. Agent는 고객 조회, 사용량 조회, 데이터 충전, 상담원 이관 같은 통신사 쪽 작업을 호출할 수 있고, 사용자는 단말 쪽 스위치를 조작할 수 있다. 두 도구 세트 모두 원자적 조작이며 “사용자의 인터넷 문제를 해결한다” 같은 상위 추상은 존재하지 않는다. 추상 수준이 너무 높으면 평가는 단일 함수 호출을 검사하는 일로 퇴화하고, 계획과 추론이 도구 자체에 흡수되어 버린다.

채점 기준(Rubric) 은 evaluation_criteria의 네 층 검사에 reward_basis라는 집계 규칙을 더한 것이다.

실행 프로토콜(Interaction Protocol) 은 상호작용 순서와 종료 조건을 규정한다. 여기서 정상 종료 신호는 시뮬레이션된 사용자가 ###STOP###을 출력하는 것이다. 그 외에 턴 수 상한이 있고, 시뮬레이션된 사용자가 인내심이 바닥나 스스로 대화를 끝낼 수도 있다. 소통 효율이 지나치게 낮은 것 자체가 실패로 계산되는 것이다.

다섯 요소 중 하나만 빠져도 평가는 반복 가능한 루프를 이루지 못한다. 뒤에서 다른 벤치마크를 살필 때도 이 다섯 항목을 대조 틀로 삼는다.

인간-컴퓨터 상호작용형과 도구 호출형 평가 환경

telecom 같은 과제에는 반드시 상호작용 상대가 필요하며, 다섯 요소 중 사용자 시뮬레이션 부분이 빠질 수 없다. 반면 대화 상대가 아예 없는 과제군도 있다. 코드 생성, 데이터 분석, 수학 풀이 같은 과제에서 Agent는 처음부터 끝까지 도구하고만 상호작용하고, 정확성은 실행 검증을 통과하는지로 결정되며, 사람의 라벨링도 모델의 판정도 필요 없다. 이런 환경은 사용자 시뮬레이터를 생략하지만 나머지 네 요소는 그대로 존재하며 형태만 단순해진다. 환경 상태는 파일 시스템이나 데이터베이스이고, 채점 기준은 한 토막의 테스트 코드이며, 실행 프로토콜은 “답을 낼 때까지 혹은 턴을 다 쓸 때까지 도구를 계속 호출한다”로 퇴화한다.

Verifiers 프레임워크는 이런 환경을 두 축으로 나눈다. 과제가 턴을 넘는 상태를 유지해야 하는지, 격리가 필요한지다. SingleTurnEnv는 수학 문제를 내고 답을 바로 검증하는 경우, ToolEnv는 여러 웹페이지를 검색해 종합 답변한 뒤 최종 결과를 검증하는 경우, StatefulToolEnv는 데이터베이스 레코드를 수정하고 상태 변화를 검증하는 경우, SandboxEnv는 샌드박스에서 코드를 실행하고 출력 파일을 확인하는 경우에 적합하다. 표 7-1은 이 네 유형을 정리한 것으로, 과제 상태·도구 호출·격리 요구에 따라 고르면 된다.

표 7-1 Verifiers 환경 유형 비교

이 프레임워크는 병렬 샘플링과 궤적 캐싱을 지원하며, 매 평가의 완전한 궤적(관찰, 행동, 보상)이 저장되어 이후 분석과 재생이 쉽다. 또한 도구의 실행 효과는 현재 상태에 의존하므로, 실패 시에는 단일한 실패 플래그가 아니라 명확한 오류 정보를 반환하여 Agent가 그에 따라 전략을 조정할 수 있게 해야 한다.

도구 호출형 평가가 묻는 것은 관찰 가능한 상태 변화의 정확성이고, 인간-컴퓨터 상호작용형 평가가 묻는 것은 소통 전략의 타당성이다. 전자는 행동을 검증하고 후자는 유도를 검증한다. 두 환경의 구조 대비는 그림 7-2를 참고하라.

평가 데이터셋의 설계

평가 환경이 무대라면 데이터셋은 대본이다. 같은 다섯 요소라도 과제 종류가 바뀌면 채우는 방식은 전혀 달라질 수 있다. 과제는 어디서 오는가, 검증기는 어느 깊이까지 확인할 수 있는가, 어떻게 암기를 막는가. 이 절은 여러 공개 벤치마크의 설계 실천에서 출발해, 마지막에 더 실무적인 질문—자체 구축 평가 세트의 과제는 어디서 와야 하는가—으로 돌아온다.

벤치마크 설계의 횡적 대조

앞 절에서 구분한 상호작용 상대의 유무는 환경 층위의 첫 번째 차이일 뿐이고, 데이터셋 층위의 분기가 설계상의 절충을 더 잘 드러낸다. 표 7-2는 자주 인용되는 벤치마크들을 나란히 놓은 것이다.

표 7-2 몇몇 Agent 벤치마크의 핵심 설계 선택

검증기

Agent는 “과제를 전부 완료했다”는 장황한 보고서를 쉽게 써낼 수 있지만, 실제로는 전혀 완료하지 않았을 수 있다. 평가 프레임워크는 Agent의 자기 진술이 아니라 기계가 독립적으로 확인할 수 있는 사실을 검증해야 한다.

SWE-bench Verified는 “수정 완료”를 두 개의 독립 명제로 분해한다. 하나는 FAIL_TO_PASS로, 수정 전에는 실패하고 수정 후에는 통과함으로써 문제가 실제로 해결되었음을 증명한다. 다른 하나는 PASS_TO_PASS로, 수정 전후 모두 통과함으로써 새로운 결함을 들여오지 않았음을 증명한다. 앞의 것만 검사하면 Agent는 걸리적거리는 어서션을 지우거나 고쳐서 빠져나갈 수 있고, 뒤의 것만 검사하면 검사하지 않은 것과 같다. 둘을 함께 검사해야 “고쳤다”와 “망가뜨리지 않았다”가 각각 증명 가능한 결론이 된다. 여기에 더해 테스트 자체의 안정성도 확인하여, 통과했다 실패했다 하는 불안정 테스트(flaky test)를 배제한다.

OSWorld의 검증기는 겉으로는 완료했지만 실질적으로는 틀린 상황을 잡아낼 수 있다. 134개의 독립 평가 함수와 운영체제 전체 접근 권한을 갖추어 파일 시스템 구조, 프로세스 상태, 네트워크 연결, 애플리케이션 내부 상태를 검사할 수 있다. 데이터베이스 조작 과제에서 평가 스크립트는 보고서 파일의 존재만 확인하는 것이 아니라 데이터베이스에 접속해 SQL이 제대로 실행되었는지 확인한다. 브라우저 과제에서는 DOM 트리를 분석하고 cookie와 localStorage를 살피며 백엔드에 검증 요청을 보내 폼이 실제로 반영되었는지 확인한다.

Terminal-Bench의 과제 build-linux-kernel-qemu는 소스에서 Linux 커널 6.9를 빌드하고 start_kernel에 사용자 정의 printk를 넣고 initramfs를 생성해 QEMU에서 부팅할 것을 요구한다. 성공 기준은 부팅 로그에 그 사용자 정의 메시지가 나타나는 것이다. Agent는 출력을 위조할 수 없고 전 과정을 실제로 해내는 수밖에 없다.

과제의 난이도 구분

평가 과제 세트에는 서로 다른 난이도의 과제가 들어가야 한다. 그래야 모델 능력이 향상되어도 평가 과제 세트가 금방 낡지 않는다.

GAIA는 전체 466문항을 세 단계 난이도로 나눈다. Level 1은 도구 한둘이면 되고(사람 93.9%, GPT-4 30.3%), Level 2는 다단계 사고가 필요하며(91.8% 대 9.7%), Level 3은 복잡한 조합이 필요하다(87.3% 대 0%). 이 계층화는 난이도를 표시하는 데 그치지 않고 진단적 가치를 지닌다. Level 1의 실패는 기초적인 도구 사용을, Level 2는 다단계 계획과 정보 통합을, Level 3은 긴 시퀀스의 사고와 복잡성 관리를 가리키며 셋은 각각 다른 개선 방향에 대응한다.

Terminal-Bench는 단순한 mlflow 모델 등록부터 중간 난이도의 7z 비밀번호 크래킹, 어려운 git 서버와 webserver 다중 컴포넌트 통합, 최고 난도의 FEAL 차분 암호 분석까지를 아우른다.

τ²-bench는 여기에 더해 함정 과제를 따로 설계했다. 사용자가 “상담원이 취소를 승인했다”고 주장하지만 실제로는 정책에 맞지 않는 상황으로, Agent가 압박과 오도 속에서 올바른 판단을 유지하는지 검증한다.

데이터 유출 방지

GAIA는 답을 인터넷에서 직접 검색할 수 없게 만든다. 그 과제는 개념적으로는 단순하되 경로가 열려 있다. 예컨대 특정 날짜의 NASA 오늘의 천문 사진에서 출발해 사진 속 우주비행사를 식별하고, 그가 속한 우주비행사 그룹을 찾고, 그 그룹에서 우주 체류 시간이 가장 짧은 사람을 계산해 “성, 세미콜론 구분, 천 단위 구분자” 형식으로 엄격히 출력하게 한다. 답은 매우 구체적이고 정오는 정확한 문자열 일치로 판정된다. 유출 방지는 두 가지에 기댄다. 첫째, 문제는 여러 정보원을 조합해야 답할 수 있고 단일 웹페이지로는 답이 바로 나오지 않는다. 둘째, 일부 과제에는 전용으로 제작한 첨부 파일(인터넷에 존재하지 않는 PDF, 오디오, 이미지)이 붙어 있다.

AndroidWorld는 하나의 템플릿에서 다수의 인스턴스를 파생시킨다. 그 과제는 정적 텍스트가 아니라 동적으로 인스턴스화할 수 있는 템플릿이다. 예컨대 “연락처 [CONTACT_NAME]의 전화번호를 [NEW_PHONE]으로 바꾼다” 같은 형태로, 평가할 때마다 파라미터 값을 무작위로 생성한다. 여기에는 세 가지 이점이 있다. 파라미터가 매번 달라 고정된 조작 순서의 재생이 무력해지고, 하나의 템플릿에서 거의 무한한 인스턴스를 만들 수 있으며, 일부 파라미터를 고정하고 나머지만 바꿔 특정 요인의 영향을 정확히 측정할 수 있다.

Terminal-Bench는 문제문에 카나리아 식별자를 심는다. 각 문항은 canary GUID를 지니며, 모델이 그 GUID가 포함된 내용을 출력할 수 있다면 벤치마크 데이터가 학습 세트에 들어갔다는 뜻이다. 유출을 막지는 못하지만 유출을 탐지 가능하게 만든다.

품질 관리와 장기 유지보수

높은 품질의 평가 세트를 만드는 일은 매우 어렵다. 위 벤치마크들의 현재 형태는 대부분 초판을 운용에 투입해 문제가 드러난 뒤 여러 차례 손본 결과다. 예컨대 τ-bench에서 τ²-bench로 오면서 설계를 다시 한 곳이 다섯 군데 있다.

첫째, 과제 지시가 지나치게 두루뭉술해 답을 추측할 수 있었다. 초판의 과제 지시는 폭넓게 쓰여 있어 모델이 요구를 진짜로 명확히 할 필요 없이 상식으로 절차를 추측하는 것만으로도 통과할 수 있었다. τ²-bench는 대본을 known_info와 task_instructions 두 칸으로 나누었다. 앞은 사용자가 아는 범위를 획정하고 뒤는 공개 방식을 규정한다. 사용자가 모르는 정보는 Agent가 추측할 길이 없고 조회해서 얻는 수밖에 없다.

둘째, 성공 조건이 충분히 정밀하지 않아 검증이 오판했다. “네트워크가 복구되었다” 같은 조건에는 확인 가능한 경계가 없다. τ²-bench는 이를 “속도 테스트 결과가 excellent여야 해결로 보고 poor, fair, good은 모두 받아들이지 않는다”로 바꿨다. 이 변경이 겨냥한 것은 미봉책 수리, 즉 증상만 누르고 근본 원인은 해결하지 않는 방식이다.

셋째, 사용자 시뮬레이터의 행동이 지나치게 기계적이었다. 초판의 시뮬레이션 사용자는 수동적으로 응답할 뿐이었다. τ²-bench는 여기에 감정(첫 수리가 실패하면 불만을 드러낸다), 인내 한도(소통 효율이 너무 낮으면 대화를 끊는다), 그리고 사실 접지 요구를 더했다. 셋이 함께 작용하여 시뮬레이터는 실제 사용자에 가까워지면서도 재현 가능성을 유지한다.

넷째, 사용자는 대화만이 아니라 조작에도 참여한다. telecom 도메인은 이중 제어 환경을 도입했다. 이전 평가에서는 Agent만 환경을 바꿀 수 있었지만, 기술 지원 같은 상황에서는 상당수의 동작을 원래 사용자가 자기 기기에서 수행해야 한다. 이중 제어는 검증에도 한 차원을 더한다. 사용자가 상태를 바꾼 뒤 Agent는 도구를 다시 호출해야만 결과를 알 수 있으므로, 검증은 “Agent가 사용자 쪽 조작 결과를 실제로 읽었는가”까지 포괄하게 된다.

다섯째, 과제 인스턴스를 동적으로 생성한다. τ²-bench의 구체적 인스턴스(사용자 이름, 번호, 고장 조합)는 파라미터화하여 일괄 생성할 수 있고, 이는 커버리지와 유출 저항력을 동시에 개선한다.

SWE-bench Verified: 공개 전에 원래 과제의 71%를 탈락시켰다. OpenAI는 원래의 2294개에서 1699개를 무작위 추출해 사람 평가에 부치고, Python에 능한 개발자 93명을 모아 한 건씩 검사했다. 문제 기술이 명확한가, 테스트 케이스가 경계 조건을 포괄하는가, 테스트가 안정적인가, 참조 patch가 새 오류를 들여오지 않는가, 난이도가 타당한가. 최종적으로 통과한 것은 500개뿐이었다. 높은 탈락률이 가져다주는 것은 더 높은 신호 대 잡음비이며 평가 비용도 약 80% 내려간다. 복잡한 Agent 과제는 수 분에서 수 시간이 걸리기 일쑤이고, 프런티어 모델로 평가 데이터셋을 통째로 돌리면 수천 달러의 token 비용이 들기 때문에 평가 비용을 낮추는 일은 매우 중요하다.

OSWorld: 공개 후 15개월 동안 300여 개의 문제가 드러났다. 2024년 4월 공개 후 곧 멀티모달 Agent 평가의 중요한 벤치마크가 되었지만, 이후 널리 쓰이는 과정에서 네 종류의 문제가 드러났다. 환경 문제(사이트의 크롤링 차단, CAPTCHA, 동적 콘텐츠 변화), 과제 기술 문제(표현의 모호함), 검증 로직 문제(지나치게 엄격하거나 느슨함), 초기 상태 문제(설정 불완전)이다. 홍콩대학 팀은 약 10명 규모의 그룹을 꾸려 MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular 등과 두 달간 긴밀히 협력해 체계적으로 수리했다. 환경 문제는 버전 고정과 오프라인 백업으로, 기술 문제는 모호한 표현의 재작성으로, 검증 문제는 사람이 올바른 기준선을 세우고 조건을 조정하는 것으로, 초기 상태 문제는 완전성 검사 추가로 완화했다.

실험 7-2 ★: 벤치마크 과제를 사람이 직접 수행하기

GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench, OSWorld-Verified에서 과제를 골라 직접 완수해 보라. 데이터셋마다 쉬움·보통·어려움을 하나씩 하기를 권한다. “어려움” 수준은 사람에게도 도전적이다.

마친 뒤 두 가지 질문에 답해 보라. 그 과제의 기술에 합리적 해석이 여럿 존재하는가, 존재한다면 검증기는 어느 쪽을 인정하는가? 대충 해서 통과하려 한다면 가장 값싼 경로는 무엇이며, 검증기가 그것을 막을 수 있는가?

평가 세트의 세 가지 출처

흔한 견해로 공개 벤치마크는 모델 순위를 위한 것이고 실제 업무와는 관련이 적다는 것이 있다. 공개 벤치마크의 점수가 제품 의사결정을 직접 이끌기 어려운 것은 사실이지만, 그 설계 기법은 충분히 이식 가능하다. 앞에서 다룬 검증의 깊이, 파라미터화 생성, 유출 방지, 품질 유지야말로 자체 구축 평가 세트에서 가장 놓치기 쉬운 부분이다.

프로덕션 환경의 평가 세트에는 보통 세 가지 출처가 있다.

공개 벤치마크는 모델의 거친 선별과 설계 기법의 차용에 쓰고, 일반적으로 제품 의사결정에는 쓰지 않는다. 그 과제 분포는 실제 업무의 과제 분포와 일치하지 않으며, GAIA에서 2퍼센트포인트 오른 것과 환불 성공률 사이에 필연적 관계는 없다.

자체 구축 업무 세트는 실제 과제 분포를 포괄하며 모델 선정과 Harness 설계 결정의 근거가 될 수 있다. 예컨대 τ²-bench는 사용자 시뮬레이션이 필요한 평가 시스템의 골격으로 그대로 쓸 수 있고, 도메인 데이터와 도구 세트만 바꾸면 된다.

프로덕션 궤적 환류는 현장의 실제 실패 사례에서 온다. 사용자의 명시적 정정, 사용자의 낮은 평가, 그리고 사후에 상태 검사, 규칙 검증기, 혹은 LLM 검토로 발견된 문제 사례다. 실패 귀인을 거쳐 회귀 케이스로 축적된다. 구체적인 방법은 뒤의 “실패 귀인”과 “엔드투엔드 회귀 과제와 trajectory prefix 회귀 과제” 절을 참고하라. 이 출처는 비용이 가장 높고 정확도도 가장 높다. 사용자가 실제로 마주친 문제에서 곧바로 오기 때문이다.

시작 단계에는 보통 공개 벤치마크와 소량의 손으로 쓴 자체 업무 세트밖에 없다. 시스템이 프로덕션에서 한동안 돌아간 뒤에는 프로덕션 궤적에서 환류된 케이스가 주가 된다.

자동화 평가 방법

앞의 여러 절에서 다룬 벤치마크에는 하나의 공통점이 있다. 검증기가 거의 전부 결정적이라는 점이다. SWE-bench는 테스트 스위트를 실행하고, AndroidWorld는 최종 UI 상태를 어서트하며, GAIA는 정확한 문자열 일치를 하고, τ²-bench의 네 층 검사도 마찬가지로 전부 코드로 실행된다. 이 선택에는 충분한 이유가 있다. 결정적 검증은 추가 모델 비용을 들이지 않고, 결과가 완전히 재현 가능하며, 유닛 테스트처럼 지속적 통합에 넣을 수 있고, 모델 간 순위를 매기기에도 편하다.

그 대가는 최종 결과의 정오만 평가할 수 있을 뿐 오류의 원인은 알려 주지 못한다는 것이다. τ²-bench의 실패한 과제는 최종적으로 0점을 받았지만, 그 0점은 Agent가 회선 선택 단계에서 틀렸는지 데이터 충전 단계를 빠뜨렸는지 말해 주지 않고, 다음에 무엇을 고쳐야 하는지도 짚어 주지 않는다. 순위를 매기는 공개 벤치마크에 이는 결함이 아니지만, 지속적 개선이 필요한 프로덕션 시스템에는 바로 그것이 가장 필요한 정보다.

프로덕션 상황에는 또 하나의 어려움이 있다. 많은 판단이 애초에 코드로 검사할 수 있는 어서션으로 쓰이지 않는다. 민원 회신이 적절한지, 조사 보고서가 핵심 정보를 빠뜨렸는지, 기억 검색이 인물 관계를 잘못 짚었는지. 이런 것들에는 조회할 유일한 최종 상태도 없고 키워드 일치로 판정할 수도 없다.

따라서 공개 벤치마크에서 프로덕션 환경의 평가로 나아가려면 검증 방식을 하나의 스펙트럼을 따라 오른쪽으로 옮겨야 한다. 그 가로축은 과제의 기계적 검증 가능 정도이며, 그림 7-4와 같다.

스펙트럼 오른쪽의 두 도구가 그래서 프로덕션 평가의 주역이 된다. Rubric으로 막연한 “좋고 나쁨”을 개별 채점 가능한 여러 차원으로 쪼개고, LLM-as-a-Judge로 결정적 판정 기준이 없을 때의 채점을 수행한다. 둘이 합쳐져야 막연한 실패율을 손댈 수 있는 구체적 문제로 되돌릴 수 있다. 여기에 이 절 후반의 실패 귀인까지 더하면 프로덕션 Agent 평가의 완전한 폐루프가 구성된다.

다만 오른쪽으로 옮긴다는 것이 왼쪽을 포기한다는 뜻은 아니다. 프로그램 어서션으로 쓸 수 있는 검사는 모두 어서션으로 남겨야 하며, LLM 판정은 기계적으로 판정할 수 없는 차원에만 쓴다. 결정적 검사가 더 싸고 안정적이며, 회귀 테스트로 장기간 돌리기에도 적합하다.

LLM-as-a-Judge: 자동 평가의 핵심

LLM-as-a-Judge는 왜 필요할까요? 보고서 생성, 고객 불만 처리, 창작 콘텐츠 같은 개방형 작업에는 자동으로 비교할 표준 정답이 없고, 사람의 평가는 비용이 많이 들며 확장하기 어렵습니다. LLM-as-a-Judge는 언어 모델이 전문가가 정의한 채점 기준(루브릭)에 따라 출력을 평가하게 하여 자동화의 확장성과 사람 전문가의 판단 사이에서 균형을 맞춥니다. 하지만 이 방법에는 알려진 한계가 있습니다. 평가자 모델 자체에 편향이 있고(가장 전형적인 것은 정확성이 더 높지 않아도 길고 상세한 응답에 더 높은 점수를 주는 길이 편향), 같은 입력을 반복해서 판단해도 결과가 달라질 수 있습니다. 특히 길이 편향에는 구체적인 대응이 필요합니다. 일반적인 방어책은 세 가지입니다. 루브릭에서 장황함에 명시적으로 감점하고 작업 유형마다 응답 길이를 제한합니다. 쌍대 비교에서는 판단 전에 두 후보의 길이를 비슷하게 맞춥니다. 그리고 점수와 응답 길이의 상관관계를 정기적으로 감사합니다. 높은 점수가 거의 항상 긴 응답에 돌아간다면 평가자가 길이에 휘둘린 것이므로 루브릭을 수정해야 합니다. 이러한 문제를 체계적으로 해결하려면 루브릭 설계가 다음 원칙을 따라야 합니다.

루브릭(채점 기준): LLM 판단의 토대.

루브릭의 네 가지 원칙(Scale AI, “Rubrics as Rewards”):

(1) 전문가 지침에 기반할 것 — 루브릭은 도메인 지식을 반영하여 핵심 사실과 사고 단계를 포착해야 합니다. 예를 들어 의료 질의응답용 루브릭에는 진단 기준과 반드시 피해야 할 의료 오류가 필요합니다. 전문가의 근거가 없으면 유창함 같은 표면적인 특징만 포착할 수 있습니다.

(2) 포괄적으로 다룰 것 — 루브릭은 사실 정확성, 논리적 일관성, 완전성, 안전성을 다루어야 합니다. 긍정적인 기준만 정의하지 말고 의료 조언에서 검증되지 않은 치료법을 권하는 것처럼 위험도가 높은 흔한 오류인 **함정(Pitfalls)**도 명시해야 합니다.

(3) 중요도 가중치를 표준화할 것 — 기준을 필수(Essential), 중요(Important), 선택(Optional), 함정(Pitfall) 항목으로 분류합니다. 이 체계는 즉시 탈락 메커니즘을 지원합니다. 예를 들어 고객 서비스 시나리오에서 거짓 정보를 지어내는 환각은 전형적인 즉시 탈락 차원입니다. 다른 차원의 성능이 아무리 좋아도 거짓 정보가 나타나면 반드시 탈락시켜야 합니다. 이는 키워드 채우기로 보상을 해킹하는 문제도 방지합니다.

(4) 평가 항목이 자체 완결적일 것 — 각 평가 항목은 독립적으로 실행 가능하고 평가자의 도메인 지식에 의존하지 않아야 합니다. “응답이 깊은 이해를 보여 준다” 같은 추상적인 기준은 피하고, “권위 있는 이론을 두 개 이상 인용하고 각 이론이 결론을 어떻게 뒷받침하는지 정확히 설명한다”처럼 검증 가능한 기준으로 바꿔야 합니다.

핵심 실무는 각 차원에 객관적으로 검증할 수 있는 점수 수준을 정의하고 구체적인 예시와 모호한 상황을 해결할 경계 사례를 제공하는 것입니다. 에이전트가 작업을 실제로 완료하지 않고 높은 점수를 얻는 “지름길”을 찾는 보상 해킹을 적극적으로 막아야 합니다. 환각, 아첨, 키워드 채우기, 어려운 질문 회피에 명시적으로 감점합니다. 루브릭은 반복해서 개선하는 제품입니다. 시험 사용에서 평가자 간 의견 차이가 드러나고, 루브릭은 이 피드백을 통해 추상적인 원칙에서 상세한 사례집으로 점차 발전합니다.

다음은 네 가지 원칙을 따르는 완전한 루브릭으로, 사용자 메모리 에이전트를 예로 듭니다. 테스트 질문은 “제 딸의 소아과 주치의는 누구인가요?”입니다. 답하려면 두 대화의 정보를 연결해야 합니다. 첫 번째 대화에는 “딸의 이름은 Lily”라고 나오고, 두 번째 대화에는 “Lily를 데리고 Dr. Chen에게 진료를 받음”이라고 나옵니다.

rubric:
  dimensions:
    - name: 사실 정확성
      weight: essential        # 필수 항목
      scoring:
        4_Excellent: "Dr. Chen이라고 정확히 답하고 딸 Lily와 연결함"
        3_Good: "Dr. Chen이라고 정확히 답하지만 Dr. Chen이 Lily의 의사라고 언급하지 않음"
        2_Passable: "의사는 정확히 답하지만 확실하지 않은 정보를 덧붙임"
        1_Fail: "의사 이름을 잘못 답하거나 '모르겠습니다'라고 답함"

    - name: 정보 완전성
      weight: important        # 중요 항목
      scoring:
        4_Excellent: "관련 정보(예: 최근 진료일, 진단)를 선제적으로 보충함"
        3_Good: "빠뜨리지 않고 핵심 질문에 답함"
        2_Passable: "핵심 질문에는 답하지만 이용 가능한 관련 정보를 빠뜨림"
        1_Fail: "핵심 정보가 빠짐"

    - name: 사고 정확성
      weight: important
      scoring:
        4_Excellent: "세션을 넘나드는 두 정보인 '딸=Lily'와 'Lily의 의사=Dr. Chen'을 정확히 연결함"
        3_Good: "정확히 연결했지만 사고 경로가 충분히 명확하지 않음"
        2_Passable: "일부만 정확히 연결함"
        1_Fail: "잘못 연결함(예: 사용자 본인의 의사를 딸의 의사로 착각함)"

    - name: 환각 감지
      weight: veto             # 즉시 탈락 항목: 한 번 걸리면 총점은 0점
      scoring:
        pass: "모든 정보의 근거를 과거 대화 기록에서 찾을 수 있음"
        fail: "대화에 없는 정보를 지어냄(예: 존재하지 않는 진료일이나 진단)"

  edge_cases:
    - "사용자에게 서로 다른 의사를 만나는 딸이 여러 명이라면 어느 딸인지 물어야 함"
    - "메모리에 'Dr. Chen'과 '陈医生'(같은 이름의 중국어 표기)이 모두 있다면 같은 사람으로 인식해야 함"

좋은 루브릭과 나쁜 루브릭: 위의 각 점수 수준은 “Dr. Chen이라고 정확히 답함”처럼 검증할 수 있고 구체적인 행동을 명시합니다. “메모리를 깊이 이해함을 보여 줌”처럼 객관적으로 판단할 수 없는 설명은 사용하지 않습니다. 즉시 탈락 항목은 최저선을 정합니다. 다른 모든 차원에서 만점을 받아도 환각이 한 번이라도 있으면 자동으로 0점입니다.

루브릭과 에이전트의 실제 응답을 평가 모델에 함께 넘기면 항목별 점수와 근거가 나옵니다. 수십 개 사례를 모아 낮은 점수의 궤적을 다시 보면 막연한 성공률 하락을 구체적인 원인으로 나눌 수 있습니다. 정보를 찾지 못했는지, 사람 사이의 관계를 잘못 연결했는지, 근거 없는 내용을 덧붙였는지 구분하는 것입니다. 루브릭은 점수표이면서 다음 수정 지점을 알려 주는 진단 도구입니다.

아래에서는 사용자 메모리를 구체적인 사례로 삼아, 이 범용 방법을 실행 가능한 평가 세트와 검증기로 어떻게 옮기는지 보여 준다.

실험 7-3 ★★: 루브릭 기반 사용자 메모리 평가 시스템 구축하기

선행 조건: 3장의 사용자 메모리 실험(chapter3/user-memory-evaluation)을 완료해야 합니다.

이 실험에서는 3장의 chapter3/user-memory-evaluation 프레임워크를 수정하여 현재의 단순한 LLM-as-a-Judge 채점 메커니즘을 구조화된 다차원 루브릭 평가 시스템으로 업그레이드합니다. 기존 시스템은 한 번의 LLM 호출로 통과/실패 결과와 평가 근거를 반환하므로 구조화된 진단 기능이 부족합니다.

세 가지 작업 수준에 모두 적용할 수 있는 통합 다차원 루브릭 프레임워크를 설계하세요. 평가 차원은 다음과 같습니다. 사실 정확성(정밀도: 제공한 모든 정보 중 올바른 정보의 비율. 숫자·날짜·이름이 저장된 메모리와 일치하는지 검증), 정보 완전성(재현율: 제공해야 할 모든 정보 중 언급한 정보의 비율. 핵심 내용을 빠뜨리지 않고 관련 정보를 모두 제공하는지 검증), 사고 정확성(정보 간 관계와 암묵적 논리를 올바르게 이해했는지 확인), 사고의 선제성(적절할 때 직접적인 답을 넘어 제안이나 위험 경고를 제공하는지 평가), 환각 감지(메모리에 없는 정보를 지어내지 않는지 확인)입니다.

우수/양호/통과 가능/실패의 4단계로 채점하고, 추상적인 설명 대신 각 수준에 구체적인 판단 기준을 둡니다. 환각 차원은 즉시 탈락 항목입니다. 차원마다 예시와 경계 사례를 제공하세요.

실험 7-4 ★★: 고급 JSON 카드와 RAG 비교 평가

선행 조건: 3장의 사용자 메모리와 RAG 실험(chapter3/user-memory, chapter3/agentic-rag-for-user-memory)을 완료해야 합니다.

목표: 같은 평가 세트에서 구조화된 메모리와 비구조화 검색이 각각 어디서 강한지 공정하게 비교합니다. 3장의 두 프로젝트를 재사용하고 chapter3/user-memory-evaluation의 테스트 케이스 60개에서 고급 JSON 카드만 사용한 구성, RAG만 사용한 구성, 핵심 사실은 상주시켜 두고 원본 대화는 필요할 때 검색하는 하이브리드 구성을 비교합니다.

인수 기준: 기본 회상/여러 세션 간 모호성 해소/세션 간 숨은 연관이라는 세 복잡도 수준에서 성공률, 평균 단계 수, 도구 호출 수, 지연 시간, 비용을 기록합니다. 구조화된 메모리가 놓치는 것, 검색이 놓치는 것, 하이브리드가 실제로 시너지를 내는지 등 각 접근법의 실패 경계를 명확히 설명합니다. 설정 세부 사항과 테스트 케이스는 부속 저장소에 있습니다.

부속 실험은 같은 60개 질문을 세 가지 메모리 구성에 적용해 실제 API 실행 궤적 180개를 남겼습니다. 표 7-3의 전체 성공률에는 성공한 문제 수도 함께 적어 표본 크기를 숨기지 않았습니다.

표 7-3 세 사용자 메모리 구성의 난이도별 성공률

가장 눈여겨볼 점은 혼합 방식이 자연히 이기지는 않았다는 것이다. 3개 문항에서는 두 단일 방식 어느 쪽도 해내지 못한 일을 해냈지만, 다른 8개 문항에서는 더 나은 단일 방식에 미치지 못했다. 문항마다의 최선 단일 방식과 견주면 평균 성공률은 오히려 낮았다. 순수 RAG는 기본 회상 문항에서 구조화 카드와 큰 차이가 없었지만, 세션을 가로지르는 연관 문항에 이르자 성공률이 15%까지 떨어졌다. 또 하나 놓치기 쉬운 숫자가 있다. 180번의 판정 가운데 환각 거부가 28번 발동했다는 것이다. 단일 거부 항목의 중요성이 여기서 드러난다.

동일 계열 모델 문제와 다중 출처 평가.

에이전트와 평가 모델이 같은 계열이라면 에이전트가 평가 모델의 선호와 사각지대를 악용하는 법을 배울 수 있습니다.

이는 바로 Goodhart의 법칙이 말하는 바입니다. 지표가 최적화 목표가 되면 더 이상 좋은 지표가 아닙니다. 에이전트를 특정 채점 시스템에 맞춰 학습하거나 조정할수록 진정한 역량을 높이는 대신 그 시스템의 허점을 악용하는 경향이 강해집니다.

더 교묘하게는 에이전트가 평가 모델이 잘 감지하지 못하는 유형의 오류를 점차 피하게 되어 채점 시스템이 완벽하게 작동하는 것처럼 보일 수 있습니다.

이를 완화하는 방법은 서로 다른 모델 계열의 독립 평가자를 사용하는 다중 출처 이기종 평가입니다. 에이전트가 Claude에서 실행된다면 GPT-5와 Gemini로 평가합니다. 서로 다른 계열의 편향은 직교하는 경우가 많아 에이전트가 모든 평가자를 동시에 속이기는 어렵습니다. 모두 같은 목표를 판단하도록 동일한 루브릭을 사용하고, 가중 평균이나 일관성 검사로 결과를 통합합니다. 배포 시에는 단일 모델로 신속한 평가를 처리하고, 전체 다중 출처 설정으로 주기적인 품질 감사를 수행할 수 있습니다.

다중 출처 평가는 어떤 모델을 평가자로 삼을지에 답합니다. 다음 질문은 어떤 모달리티를 평가할 것인가입니다. LLM-as-a-Judge를 텍스트에서 음성, 이미지, 동영상으로 확장하는 것은 평가 범위를 넓히는 또 다른 축입니다.

멀티모달 LLM-as-a-Judge.

멀티모달 평가는 LLM-as-a-Judge를 음성, 이미지, 동영상 영역으로 확장합니다. 일반적인 네 가지 방향은 다음과 같습니다.

• TTS 평가(TTS는 Text-to-Speech): 정확성, 자연스러움, 음성 일관성, 감정 표현을 평가합니다. 이러한 차원으로 전통적인 WER(Word Error Rate)이 감지하기 어려운 운율 문제를 포착할 수 있습니다.
• ASR 평가(ASR은 Automatic Speech Recognition): 의미적 영향도를 평가합니다. “오늘의 날씨”를 잘못 인식하는 것은 큰 문제가 아니지만, “천 원 이체”를 “만 원 이체”로 잘못 인식하면 심각한 결과를 낳을 수 있습니다.
• UI 평가: 제안자-검토자(Proposer-Reviewer) 메커니즘을 사용해 텍스트 넘침, 색상 대비, 버튼 배치 같은 문제를 확인합니다. 여기서 제안자-검토자는 평가 방법으로 쓰이므로 5장에서 생성 시스템 컴포넌트로 사용한 것과 다르지만, 한 모델이 생성하고 다른 모델이 독립적으로 검토한다는 핵심 메커니즘은 같습니다.
• 동영상 편집 평가: 키프레임을 통해 클립의 시작점·끝점과 효과 적용의 정확성을 검증합니다.

실험 7-5 ★★: 완전히 자동화된 TTS 품질 평가 파이프라인 구축하기

이 실험에서는 완전한 멀티모달 LLM-as-a-Judge TTS 품질 평가 시스템을 처음부터 설계하고 구현해야 합니다.

다차원 TTS 루브릭을 설계하세요. 정확성 차원은 모든 텍스트를 빠뜨리거나 잘못 읽거나 추가하지 않고 정확히 읽었는지 검증합니다. 자연스러움 차원은 음성이 기계적이지 않고 자연스럽게 들리는지, 부자연스러운 멈춤은 없는지, 자연스러운 운율을 사용하는지 평가합니다. 감정 표현 차원은 억양이 텍스트의 감정적 어조와 맞는지 확인합니다(질문은 올라가는 억양, 감탄문은 강조, 슬픈 내용은 느린 속도와 낮은 음높이). 음성 일관성 차원은 참조 음성이 있을 때 화자의 유사성을 평가합니다(멀티모달 모델이 참조 음성과 합성 음성을 함께 받아 비교).

길이, 장르, 감정, 숫자·고유명사·다음자·방언 등 난도가 다양한 테스트 말뭉치를 만드세요. TTS 생성 모듈은 OpenAI, ElevenLabs, Fish Audio, Minimax, Doubao 등에 연결하고, 음성을 직접 입력받는 멀티모달 평가 모델에 합성 음성, 원문, 참조 음성, 루브릭을 함께 제공합니다. 차원별 점수 분포를 분석하는 한편 평가 모델 이름, 참조 음성 해시, 후보 음성 해시도 저장해 결과를 다시 확인할 수 있게 합니다.

부속 저장소에는 소규모 직접 청취 파일럿도 남아 있습니다. OpenAI와 Fish Audio가 숫자, 다음자, 긴 문장, 흥분한 말투를 각각 한 개씩 생성했고, Voxtral이 8개 음성을 위 네 차원으로 평가했습니다. 정확성과 자연스러움은 두 서비스 모두 5.00과 4.00이었습니다. 감정 표현과 음성 일관성은 Fish Audio가 4.00과 3.00, OpenAI가 3.75와 2.75였습니다. 글을 정확히 읽었는지만 보면 차이가 없어도 평가 축을 나누면 말투와 음색의 차이가 드러납니다.

하지만 표본 8개로 어느 TTS가 낫다고 결론 내릴 수는 없습니다. 서비스당 네 개뿐인 데다 고정 참조 음성이 Fish S1에서 만들어져 음성 유사도 비교가 애초에 Fish Audio에 유리합니다. 범용 TTS를 비교한다면 ‘Fish 참조 음성과 얼마나 비슷한가’를 총점에서 빼야 합니다. 음성 복제를 비교한다면 모든 시스템이 같은 목표 화자를 흉내 내게 하고, 사람의 블라인드 청취로 모델 점수를 보정해야 합니다. 어떤 정답·이미지·음성을 참조로 고르는지도 평가 설계의 일부이며, 실험 전에 중립적으로 끝나는 준비 작업이 아닙니다.

사람이 작성한 루브릭은 이런 진단 축을 빠르게 만드는 데 적합합니다. 규모가 커지면 전문 생성형 보상 모델로 판단을 자동화할 수 있으며 학습 방법은 8장에서 다룹니다.

판정 모델이 준 점수는 결과가 좋은지 나쁜지만 말해 줄 뿐이다. 그 결과를 고칠 수 있는 문제로 바꾸려면 실패가 도대체 어느 단계에서 시작되었는지까지 짚어 내야 한다.

실패 귀속: 전체 trajectory에서 첫 오류 위치 특정

엔드투엔드 평가는 흔히 “성공/실패”만 말합니다. 수정으로 연결하려면 실패 trajectory마다 오류 분류, 허용할 수 없는 행동이 처음 나타난 단계, 관련 도구 호출이나 모델 출력, 감사 가능한 증거를 기록해야 합니다. 사용자의 명시적 교정, 부정적 피드백, 사후 상태·규칙 검사가 주요 신호입니다. LLM은 보조할 수 있지만 실패가 제품 문제를 드러낼 수 있으므로 사람의 분석이 필요합니다.

Coding Agent의 초기 분류에는 절차·저장소 규칙 누락, 도구·형식 오류, 비정상 종료, 완료도·논리 문제가 포함됩니다. 단계 번호, 도구, 관찰, 근본 원인과 결과, 복구 가능성, 확신도를 JSON/YAML로 저장하고 환경 상태·버전·전체 trajectory도 보존합니다.

실패 귀인 체계를 만들려면 프로덕션의 문제 궤적을 개발자가 끈기 있게 읽고 분석해야 합니다. 이 과정에 LLM의 도움을 받을 수는 있지만 LLM에 전부 맡길 수는 없습니다. 실패 귀인은 기술 문제만이 아니라 제품 문제를 드러내는 경우가 많기 때문입니다.

제품이 다듬어질수록 오류 분류는 여러 대분류를 갖고, 그 아래 다시 소분류가 붙어 결국 수백 가지에 이를 수 있습니다. 이 분류와 귀인 방식은 그대로 귀인 주석 Agent의 프롬프트나 Skill이 됩니다.

Coding Agent를 예로 들면, 쓸 만한 초기 분류는 다음과 같습니다.

귀인 주석 Agent는 LLM을 활용해 대량의 프로덕션 궤적에 대한 근본 원인 분석을 규모 있게 수행할 수 있지만, “실패 원인” 한 문장만 내놓아서는 안 됩니다. 귀인 기록은 구조화되어야 합니다. JSON이나 YAML 형식으로 구체적인 단계 번호, 도구 이름, 관찰 증거를 인용하고, 근본 원인과 결과를 구분하며, 복구 가능 여부를 판단하고 신뢰도를 붙여야 합니다. 예를 들어 edit_file이 old_string 불일치를 반환하고 이후 Agent가 세 번 재시도하고도 파일을 쓰지 못했다면, 주원인은 “파일 편집·도구 호출 오류”이고 세 번의 재시도는 그 결과이지 독립된 세 개의 근본 원인이 아닙니다. 여러 분류가 동시에 나타나면 “가장 이르면서 이후 실패를 설명할 수 있는” 것을 주원인으로 고르고 나머지는 부차 원인으로 남깁니다. 위 표의 최소 세 분류는 LLM에 첫 오류 위치를 맡기기 전에 규칙으로 의심 궤적을 걸러낼 수 있습니다. 완료 선언과 실제 실행 명령의 대조, diff가 테스트 단언과 skip 표시를 건드렸는지, diff가 마이그레이션 파일 없이 공개 API나 schema를 바꿨는지입니다. 규칙으로 먼저 거르고 LLM으로 위치를 잡는 편이 모든 궤적을 LLM에 넘기는 것보다 싸고 정확합니다.

귀인 기록을 저장할 때는 LLM이 낸 기록만이 아니라 작업 목표, 환경 상태, Agent 버전, 도구 세트 버전, 그리고 전체 Agent 궤적을 함께 저장해 회귀 테스트로 전환할 수 있게 해야 합니다.

아래에서는 대표적인 세 가지 오류를 예로 들어 설명합니다.

“행동은 맞았는데 보고가 틀린” 문제

“행동은 맞았는데 보고가 틀린” 범주는 전체 성공률에 가장 잘 가려집니다. 대부분의 평가가 환경 상태만 검사하기 때문입니다. τ²-bench는 이를 따로 채점합니다. 공개된 베이스라인 중 정보 전달 요건이 있는 704회 실행에서 240회가 실패했고, 그중 162회가 정보 전달 검사에서 떨어졌으며, 80회(전체 실패의 3분의 1)는 환경 상태는 맞았지만 보고한 정보가 틀렸습니다.

부속 저장소에 대응하는 사례가 있습니다. 갤러리의 expenses.jpg에 있는 지출을 가계부 앱에 입력하는 과제에서, Agent는 권한 부여·검색·이미지 열기·행 입력·저장을 32단계로 수행하며 어느 단계도 오류를 반환하지 않은 채 완료를 선언했습니다. 그러나 검증기는 기록되었어야 할 행—Dress, ¥436.35—이 없다고 보고했고, 이는 Agent가 입력한 네 건과 아무 관련이 없습니다. 8단계의 사고에는 *“I cannot actually see the content/details of the expenses in the image”*라고 적혀 있습니다. 데이터를 얻지 못했다는 것을 스스로 알면서도 멈추지도 보고하지도 않고 계속 진행했고, 11단계에서 지어낸 지출 네 건이 기록에 등장했으며 이후의 모든 입력이 그 날조된 데이터를 충실히 실행했습니다. 첫 오류는 8단계이며, 그 단계는 오류를 내지도 않았고 도구 호출도 아닙니다. 근본 원인도 잘못 분류하기 쉽습니다. T3A는 관측 공간에 요소 트리만 있고 이미지 픽셀이 없는 텍스트 전용 Agent이므로, 원인은 “모델이 OCR을 못한다”가 아니라 관측 경로의 부재와 “정보를 얻을 수 없다”는 합법적 종료 동작의 부재입니다. 모델 능력 문제로 기록하면 모델 교체나 OCR 학습으로 가지만, 실제로 해야 할 일은 경로와 종료 동작을 더하는 것입니다.

실험 7-6 ★★: AndroidWorld 실패 궤적에 대한 실패 귀인

이 실험은 이 절의 귀인 방법을 실제 궤적으로 연습한다. 에뮬레이터도 모델 API도 필요하지 않다. 자료는 chapter7/android-world에 저장된 T3A 실행 기록이다. t3a.md에는 모든 작업의 단계별 Action/Reason/Summary가, t3a_failed.md에는 50여 개의 실패 궤적이 담겨 있으며 각 궤적 끝에는 검증기의 객관적 판정이 붙어 있다.

1단계: 표본 추출. t3a_failed.md에서 도구 오류가 전혀 없는 조용한 실패를 최소 10개 뽑는다. 실패한 도구 반환이 없어야 하고, Agent가 스스로 완료를 선언했거나 단계 상한에 도달했으며, 마지막 검증기 판정만이 실패를 가리켜야 한다.

2단계: 첫 오류 위치 확정. 각 궤적에 대해 첫 오류의 단계 번호를 기록하고, 그 단계가 도구 호출인지 assistant message인지 명시한다. 조용한 실패는 두 가지 방법으로 찾는다. 사실 앵커 대조는 Agent의 진술을 도구 반환값과 차례로 맞춰 첫 어긋남을 잡는다. trajectory prefix 이분 탐색은 궤적을 k단계에서 잘라 넘겨주고, 여전히 복구된다면 오류가 k 이후에 있다고 판단한다. 오류 키워드 검색은 대체재가 못 된다.

3단계: 구조화된 기록 작성. 궤적마다 JSON 또는 YAML 기록을 만들어 작업명, 첫 오류 단계, 오류 범주, 근본 원인의 책임 주체, 근거 인용을 담고 주원인과 결과를 구분한다.

4단계: 기존 노트와 대조. 결과를 저장소의 t3a_failed_analysis.md와 항목별로 비교하고 불일치를 기록한다. 특히 근본 원인 귀속에 주의하라. 이 노트는 이미지 전사 실패를 “비전 모델에 OCR 능력이 없다”라고 적었지만, T3A의 관측 공간에는 이미지 픽셀 자체가 없다. 진짜 근본 원인은 관측 경로의 부재다. 기존 귀인 노트는 정답이 아니다.

5단계: 회귀 작업으로 전환. 첫 오류가 assistant message에 있는 궤적 3개를 골라 그 직전까지의 prefix를 잘라내고, 허용 동작 집합과 금지 동작을 작성해 trajectory prefix 회귀 작업을 만든다.

범위에 민감한 문서 형식 오류

사용자가 “따옴표 형식이 잘못됐다”라고 말해도 이를 전역 문자 치환으로 바꾸어서는 안 됩니다. 최소한 ASCII 곧은 따옴표(", '), 중국어 굽은 따옴표(“”, ‘’), 마크다운 백틱(`)은 구분해야 합니다. 같은 문자라도 중국어 자연어, 인용된 영어 원문, 인라인 코드, 코드 블록, 코드 주석, JSON, 경로에서 맡는 문법적 역할이 다릅니다.

평가 데이터는 먼저 문서를 범위가 표시된 조각으로 파싱해야 합니다. 예를 들어 ZH_PROSE, EN_PROSE, QUOTED_SOURCE, INLINE_CODE, CODE_BLOCK, CODE_COMMENT, JSON_OR_SCHEMA 입니다. 각 조각에는 허용되는 변환 집합, 반드시 보호해야 할 문자, 수정 후 검증기 결과를 저장합니다. 아래 세 곳은 같은 치환 규칙으로 처리할 수 없습니다.

중국어 설명: `reset()` 메서드를 호출한다.
인용된 영어 원문: “Please restart the service.”
# 아래 코드 블록은 보호된 범위를 설명하기 위한 것일 뿐이다
# 중국어 주석: "현재 상태"를 표시한다
name = "status"

궤적 접두사 회귀에서는 모델에 최소 수정을 요구하는 동시에 중국어 문서 스타일, 영어 원문 보존율, 코드와 JSON 문법, 대상이 아닌 텍스트의 편집 거리를 함께 확인해야 합니다. 규칙으로 범위를 확정할 수 없을 때는 원문을 유지하고 확인을 요청하는 것이 허용된 동작이어야 하며, 추측에 의한 수정을 통과로 처리해서는 안 됩니다.

정확한 복사 오류: old_string mismatch에서 계층별 원인 규명까지

old_string 실패도 “모델이 잘못 베꼈다”로만 귀속할 수 없습니다. 같은 문자열에 대해 원본 바이트 해시, 유니코드 code point 시퀀스, tokenizer token ID 시퀀스를 저장하고 다음 연쇄를 따라 첫 번째 차이를 찾아야 합니다.

original file bytes → tool return → Harness serialization → model context
→ model token output → decoded string → JSON/tool-call parsing → tool matching

최소한의 평가 프로브는 직접 복창, 긴 컨텍스트에서의 추출, 도구 인자에 넣기, 유사 문자열 선택, 그리고 공백·줄바꿈·역슬래시·유니코드 결합 문자·저빈도 token을 포괄합니다. 지표로는 byte-exact match, code-point-exact match, token-exact match, 첫 분기 위치, 실제 도구 성공률을 사용합니다. 직접 프로브에서는 맞는데 도구 호출이 실패한다면 tokenizer·직렬화·Harness·도구 프로토콜을 고쳐야 하며, 첫 차이가 모델 자신의 출력에서 나타날 때에만 그 사례를 8장의 복사 학습 데이터로 전환합니다.

엔드투엔드 회귀 작업과 trajectory-prefix 회귀 작업

실패 귀인으로 첫 오류와 그 분류가 정해지면, 다음은 수정 목표를 반복 실행 가능한 테스트 케이스, 즉 회귀 작업(regression task)으로 옮기는 일입니다. 여기에는 서로 보완하는 두 층의 회귀 작업이 필요합니다. 엔드투엔드 회귀 작업은 변경이 전체 워크플로를 깨뜨리지 않았는지 검증하고, trajectory prefix 회귀 작업은 첫 오류 직전 상태를 잘라내어 그 결정 경계가 고쳐졌는지만 검증합니다.

엔드투엔드 회귀 작업은 초기 상태와 사용자 요청에서 출발해 Agent가 전체 작업을 끝내게 하고 최종 상태, 필요한 출력, 안전 조건을 확인합니다. 프로덕션 결과에 가장 가깝지만 어느 단계에서 실패했는지는 판단하기 어렵습니다. 일반적으로 엔드투엔드 회귀 작업은 각 영역에서 Agent의 능력이 기대에 부합하는지 검증하는 데 씁니다. 이 장에서 다룬 OSWorld, AndroidWorld, tau-bench 같은 표준 평가 세트는 모두 엔드투엔드 회귀 작업입니다.

trajectory prefix 회귀 작업은 이미 주어진 맥락, 대화, 도구 반환, 환경 상태를 얼려 두고, Agent에게는 다음 한 걸음 또는 몇 걸음의 관측 가능한 행동만 생각해 실행하게 합니다. 비용이 낮고 단일 정책이나 도구 문제를 분리해 낼 수 있습니다. 높은 신뢰성이 필요한 프로덕션급 Agent에서는 trajectory prefix 회귀 작업 집합을 만드는 일이 엔드투엔드 쪽보다 더 중요할 때가 많으며, 앞 절에서 말한 실패 분류 체계와 실패 귀인 체계를 끈기 있게 세워야 합니다.

trajectory prefix 회귀 작업의 답은 유일한 행동이나 답이 아니라 허용 가능한 행동 집합으로 정의해야 합니다. “저장소 규칙을 먼저 읽는다”, “사용자에게 먼저 묻는다”, “위험한 조작을 거부한다” 같은 것을 요구하면서 금지 행동도 함께 적습니다.

실패 귀인을 마치면 엔드투엔드와 trajectory prefix 회귀 작업을 아우르는 평가 데이터셋을 구성할 수 있습니다. Coding Agent를 예로 들면, 절차 누락에는 계획 문서와 테스트 인수 조건을 갖춘 엔드투엔드 회귀 작업을 만듭니다. 도구 호출 오류에는 실패한 앞부분을 잘라 경계 작업으로 다듬어, 모델이 형식을 고치고 특수 문자를 이스케이프하며 적절한 도구로 갈아탈 수 있는지 시험합니다. 실행 이상에는 잘림·타임아웃·도구 장애로부터의 복구 시나리오를 넣습니다. 완료도와 논리 오류에는 다목표 체크리스트, 남은 작업 알림, “아직 불가능하다고 증명되지 않았다”는 경계를 넣습니다. 요구 이해와 모호성 부류는 합리적 해석이 여럿인 작업을 프리픽스로 얼려 두고 “먼저 확인하기”를 허용 행동에 넣습니다. 증상 땜질과 검증 위조 부류는 인수 조건에 “테스트 단언을 고쳐서는 안 된다”, “완료 선언에는 실제로 실행한 명령의 출력을 첨부해야 한다”는 두 가지 강한 제약을 더합니다. 정보 보고 부류는 환경 상태만이 아니라 답변 내용 자체에 단언을 겁니다.

평가 데이터셋은 8장의 사후 학습과 9장의 Agent 자기 진화의 토대가 됩니다.

실험 7-7 ★★: 여러 표현을 이용한 trajectory-prefix 경계 평가

알려진 사용자 메모리, 현재 지시, trajectory prefix, 도구 반환, 환경 상태를 주고 다음 행동만 출력하게 합니다. 11개 사례를 JSON Cards·Markdown·Python-like로 인코딩해 결정적 규칙으로 판정했습니다. 33/33 셀이 API 오류 없이 끝났고 각 표현은 6/11을 통과했으므로, 표현만 바꿔서는 정책 문제가 해결되지 않습니다.

실제 모델을 선택할 때는 흔히 “A와 B 중 어느 것이 더 좋은가?”라는 질문을 마주합니다. 쌍대 비교는 절대 점수에 의존하지 않는 평가 방법을 제공합니다.

쌍대 비교와 모델 순위

Elo 레이팅(원래 체스를 위해 설계된 순위 시스템)은 많은 쌍대 대결을 통해 모델의 상대적 역량을 정량화합니다. 레이팅 차이가 클수록 강한 모델의 예상 승률도 높습니다. 예를 들어 모델 A의 레이팅이 1200이고 모델 B가 1000이라면 Elo 시스템은 A의 승률을 약 76%로 예측합니다. 예상과 달리 B가 이기면 B는 더 많은 점수를 얻고 A는 더 많이 잃습니다. 이변일수록 조정 폭이 커지므로 순위가 진정한 역량에 빠르게 수렴합니다. 통계적 토대는 Bradley-Terry 모델입니다. 각 모델을 잠재적인 “강도 점수”로 추상화하고, 대결에서 한 모델이 다른 모델을 이길 확률을 점수 차이로 결정합니다. Elo는 이 모델을 온라인 갱신 형태로 구현한 엔지니어링 방법입니다.

Chatbot Arena는 익명 무작위 대결을 사용합니다. 사용자는 모델의 정체를 모른 채 더 좋은 응답을 선택하고 수백만 표에서 순위를 도출합니다. “절대 기준”을 정의할 필요 없이 사람이 “A와 B 중 어느 것이 더 좋은가”만 판단하면 된다는 장점이 있습니다. 한계는 사용자가 우연히 무엇을 묻느냐에 따라 순위가 달라진다는 점입니다. 수많은 사용자가 프로그래밍 질문을 쏟아내면 프로그래밍에 강한 모델이 더 높은 순위를 차지하지만, 다른 작업에서의 수준에 대해서는 거의 알려 주지 못할 수 있습니다.

사람의 투표가 아니라 LLM으로 쌍대 평가를 수행할 때는 위치 편향도 방어해야 합니다. 평가 모델이 특정 위치(보통 첫 번째)에 나온 후보를 체계적으로 선호하고, 두 후보의 내용을 완전히 맞바꿔도 판단이 달라지지 않을 수 있습니다. 표준 완화 방법은 각 쌍의 순서를 바꾸어 두 번 평가하는 것입니다. 한 번은 A를 먼저, 한 번은 B를 먼저 놓고 두 결과의 평균을 냅니다. 더 엄격하게는 두 판단이 일치하는 경우만 집계하고, 불일치는 무승부로 처리하거나 사람의 검토로 보냅니다. Chatbot Arena의 접근법도 본질적으로 같습니다. 두 응답의 표시 위치를 무작위화하여 큰 표본에서 위치 편향이 상쇄되게 합니다.

실험 7-8 ★★: 쌍대 비교 데이터로 모델 리더보드 구축하기

이 실험은 Elo 레이팅 계산 시스템을 처음부터 구현하여 Bradley-Terry 모델이 대량의 쌍대 비교에서 상대적 역량 점수를 추출하는 방법을 깊이 이해하는 것이 목표입니다. 수백만 건의 익명 사용자 블라인드 투표가 담긴 Chatbot Arena의 실제 오픈 소스 투표 데이터셋을 사용합니다.

Elo 레이팅 반복 갱신 알고리즘을 구현하세요. 모든 모델의 초기 레이팅을 1000으로 설정합니다. 투표 기록을 시간순으로 처리합니다. 대결마다 두 모델의 현재 레이팅 차이로 예상 승률을 계산하고, 실제 결과와 예상을 비교한 뒤 고정 학습률로 레이팅을 조정합니다. 승자는 점수를 얻고 패자는 잃으며, 조정 폭은 예상에서 벗어난 정도에 비례합니다(예상 밖 패배일수록 레이팅이 더 크게 바뀝니다). 최종 레이팅의 내림차순으로 모델을 정렬하고 쌍별 승률 행렬을 계산합니다. 공식 리더보드와 비교하여 순위가 전반적으로 일치하는지 검증합니다. 점수 하나하나가 정확히 같을 필요는 없습니다. 공식 Chatbot Arena는 Bradley-Terry 최대 가능도 추정(투표 순서와 무관하게 모든 대결을 동시에 풀이)을 사용하지만, 이 구현은 온라인 증분 Elo 갱신(결과가 학습률 K-factor와 처리 순서의 영향을 받음)을 사용합니다. 두 알고리즘은 전체 순위가 일관되어야 하지만 구체적인 점수까지 정확히 같지는 않습니다.

실험의 두 번째 부분에서는 시간에 따른 순위 변화 애니메이션을 만듭니다. 투표 데이터를 주별 또는 월별로 나누고 각 시점의 Elo 레이팅 스냅샷을 계산합니다. D3.js로 막대그래프 경주 애니메이션(가로 막대 길이 = 레이팅, 세로 위치 = 순위, 시간에 따라 매끄럽게 변화)을 구현합니다. 애니메이션을 관찰하여 기술적 돌파 시점(모델의 레이팅이 갑자기 급등), 경쟁 구도의 발전, 모델 수명 주기를 파악합니다.

평가 기반 모델 선택

모델 선택은 단순히 “가장 강한 모델을 고르는” 일이 아니라 애플리케이션 시나리오에 따라 여러 차원에서 평가에 근거한 절충을 하는 과정입니다.

선택의 핵심 차원

처리량과 지연 시간은 혼동하기 쉬운 두 지표군이지만 LLM 추론이 두 단계로 실행된다는 사실 하나만 알면 구분할 수 있습니다. **프리필(Prefill)**은 전체 컨텍스트를 한 번에 읽으며 첫 토큰까지 걸리는 시간(TTFT, Time To First Token), 즉 사용자가 Enter를 누른 뒤 첫 글자가 나타날 때까지의 지연을 결정합니다. 컨텍스트가 길수록 프리필은 느려지고 TTFT가 높아집니다. 이어서 **디코드(Decode)**가 응답을 토큰 단위로 생성하며 생성 속도(토큰/초)를 결정합니다. 이 속도는 사고 시간도 좌우합니다. 초당 50토큰인 모델이 사고 토큰 2,000개를 생성하면 사고에만 40초가 걸립니다.

이 두 단계를 중심으로 한 주요 처리량·지연 시간 지표는 다음과 같습니다.

• 입력 처리량 / 출력 처리량: 각각 프리필과 디코드의 속도에 대응합니다.
• TTFT: 대기열 시간과 프리필 시간의 합이며 사용자가 체감하는 “응답성”입니다.
• 사고 지연 시간: 생성하는 사고 토큰 수는 모델에 따라 몇 배씩 다를 수 있고, 사고 길이가 작업 효과와 반드시 양의 상관관계를 갖는 것은 아닙니다. 공개 리더보드만 보고 추정하지 말고 자체 작업에서 각 모델의 사고 토큰 사용량과 그에 따른 이점을 측정해야 합니다.
• p95 꼬리 지연 시간: 요청의 95%가 넘지 않는 지연 시간입니다. 많은 빠른 요청이 평균을 낮춰 일부 사용자가 겪는 심각한 지연을 가릴 수 있으므로, 평균보다 실제 사용자 경험을 더 잘 나타냅니다.

비용: 입력·출력·캐시 토큰의 가격입니다. 비용을 따로 떼어 평가해서는 안 됩니다. 성공률이 낮은 저렴한 모델은 잦은 재시도로 실제 비용이 더 들 수 있습니다. 작업당 평균 비용과 비용 대비 성능을 계산해야 합니다.

성능: Pass@1, Pass^k, Pass@k, Best@k의 정확한 정의는 앞의 “평가 지표 체계”에서 제시했습니다. 여기서는 모델 선택 맥락에서의 사용법만 설명합니다. 일상적인 시나리오에는 Pass@1(단일 시도의 평균 성공률)을 중시합니다. 중요한 작업에는 “한 번도 실수하지 않는” 안정성에 초점을 맞춰 Pass^k를 우선합니다. 탐색적 작업에는 충분한 기회가 주어졌을 때의 역량 상한을 보는 Pass@k 또는 Best@k를 우선합니다. 개방형 작업에는 다차원 루브릭 채점을 사용합니다.

속도 제한과 신뢰성: RPM(Requests Per Minute)·TPM(Tokens Per Minute) 제한은 동시 처리 능력에 영향을 주며, 일부 API는 사용량이 많은 시간대에 할당량을 동적으로 조정합니다. 견고성 측면에서는 분포 외 데이터, 적대적 입력, 장기 실행 안정성(모드 붕괴나 어텐션 드리프트 같은 문제가 발생하는지)에 주목해야 합니다.

예산-역량 곡선: 고정된 예산에서 얻은 단일 점수만으로 에이전트가 장기 작업을 처리할 수 있는지 판단할 수 없습니다. 성공률과 함께 실제 경과 시간, 토큰, 도구 호출, 컴퓨팅 예산에 따라 성능이 어떻게 변하는지도 보고해야 합니다. RE-Bench는 이 문제를 구체적으로 보여 줍니다. 환경당 총 2시간의 예산에서는 최고 에이전트가 사람 전문가보다 약 4배 높은 점수를 얻었습니다. 하지만 사람은 시간이 늘어날 때 더 큰 이점을 얻어 8시간에서는 최고 에이전트를 근소하게 앞섰고, 여러 시도에 총 32시간을 주자 약 2배 높은 점수를 얻었습니다¹. 따라서 짧은 예산에서의 우위를 장기 실행 역량으로 곧바로 일반화할 수 없습니다. 모델 선택 시 실제 작업 시간과 가까운 여러 예산 지점을 비교해야 합니다.

실무에서는 모델을 혼합할 수 있습니다. 단순한 요청에는 경량 모델을 사용해 비용을 줄이고 복잡한 작업에는 강력한 모델을 사용해 품질을 지킬 수 있습니다. 이미지 이해나 코드 생성 같은 특정 하위 작업에는 전문 모델을 두고 하위 에이전트 메커니즘으로 협업하게 할 수도 있습니다. 이러한 이기종 조합은 추가되는 시스템 복잡성보다 전체 이점이 큰지 평가로 검증해야 합니다(예컨대 “9.9와 9.11 중 어느 쪽이 큰가”, “세차를 하려는데 집에서 세차장까지 50미터다, 걸어갈까 차를 몰까” 같은 질문을 단순한 문제로 보고 경량 모델에 맡겨 잘못된 판단에 이르는 경우다.)

모델 행동: 언제 읽기를 멈추고 편집을 시작할 것인가

모델 선택은 과제를 끝낼 수 있는지만이 아니라 기본적으로 어떻게 행동하는지도 비교해야 한다. Coding Agent에서 쉽게 관찰되는 차이 하나가 행동 임계값이다. 같은 코딩 과제를 받아도 어떤 모델은 저장소를 폭넓게 탐색하고 아키텍처, 호출부, 테스트를 확인한 뒤 편집한다. 다른 모델은 더 적은 증거로 위치를 좁히고 일찍 편집한 다음 테스트 피드백으로 이해를 보완한다. 전자는 성급한 편집의 비용을 더 높게 보고, 후자는 파일 하나를 더 읽는 기회비용을 더 높게 본다.

Agent의 이런 성향에는 두 가지 원천이 있다. 하나는 Harness 안의 시스템 프롬프트이고, 다른 하나는 모델의 행동 정책이다. 사후 학습은 모델 행동 정책의 핵심 원천이다. SFT 궤적은 “어디까지 읽고 나서 손을 대는지”를 시연하고, 과정 보상은 특정 도구 경로를 보상하거나 벌하며, 결과 보상은 끝내 성공한 전체 전략을 강화한다. 시간이 지나면서 모델이 익히는 것은 코드를 어떻게 쓰는지만이 아니라 엔지니어링 습관이기도 하다.

실험 7-9 ★★: 고정된 Coding Harness에서 모델의 행동 임계값 측정

목표: 모델 요인을 분리하고, Coding 모델이 정보 수집을 계속할지 편집을 시작할지 기본적으로 어떻게 절충하는지 정량화하며, 경로 효율과 최종 품질을 함께 평가한다.

방법: chapter6/model-action-threshold/experiment.py를 실행한다. 기본 설정은 동일한 OpenRouter OpenAI-compatible 엔드포인트로 GPT-5.6-sol과 Claude Sonnet 5를 호출하면서 시스템 프롬프트, 도구 Schema, 과제 저장소, 테스트 명령, 최대 턴 수를 고정한다. 중립 프롬프트는 최소 파일 열람 수나 빠른 편집을 지정하지 않는다. 세 과제 유형을 각각 최소 세 번 반복하고 모델 실행 순서를 번갈아 배치한다. 첫 편집 전의 도구 호출 수, 읽은 파일 수, 검색 횟수, 실제 경과 시간과 함께 처음 테스트한 패치의 통과율, 테스트 후 재작업, 최종 성공률, 변경 파일 수, Token 사용량을 기록한다.

인과 해석: 중립 캠페인은 같은 Harness 안에서 모델에 따라 행동이 변하는지를 묻는다. Harness의 조절 효과를 측정하려면 --policy explore-first로 별도 캠페인을 실행하고 두 policy를 하나의 모델 비교에 섞지 않는다. 모델 교체 때 바뀌고 같은 모델에서는 여러 Harness에 걸쳐 유지되는 행동은 모델 효과를 더 강하게 뒷받침하며, 그 반대는 Harness 효과를 더 강하게 지지한다.

수용 기준: 모든 오프라인 단위 테스트가 통과해야 한다. 각 과제 fixture가 초기 상태에서는 테스트에 실패함을 먼저 확인해야 한다. 정식 결과에는 모든 모델 × 과제 × 반복 셀, API 오류 0건, 독립적인 최종 테스트, 감사 가능한 궤적이 포함되어야 하며, manifest.json은 설정·관측·요약 파일의 해시를 검증해야 한다. 부속 디렉터리에는 18/18 셀을 완료한 실측 결과가 저장되어 있다. 독자는 이 소형 저장소의 수치를 영구적인 순위표로 간주하지 말고, 관심 있는 모델 버전과 실제 워크로드에서 다시 실행해야 한다.

에이전트 시스템의 비용 분석

앞 절에서는 비용을 핵심 선택 차원 중 하나로 나열했지만, 에이전트 비용은 단순한 토큰 가격보다 훨씬 복잡합니다. 여러 턴의 사고, 도구 호출, 컨텍스트 누적으로 비용이 비선형적으로 증가합니다. 체계적인 비용 분석은 평가 시스템에서 빼놓을 수 없으며 프로덕션 배포의 전제 조건입니다.

비용의 구성 요소.

에이전트 시스템의 비용은 세 수준으로 나눌 수 있습니다.

모델 추론 비용은 입력·출력 토큰 소비로 결정되는 가장 직접적인 구성 요소입니다. 하지만 에이전트 시나리오에는 자주 간과하는 두 가지 증폭 요인이 있습니다. 첫 번째는 컨텍스트 누적 효과입니다. 에이전트는 LLM을 호출할 때마다 모델이 컨텍스트를 이해할 수 있도록 이전의 모든 대화 기록과 도구 출력을 함께 보냅니다. KV 캐시(이미 처리한 컨텍스트를 캐시해 중복 계산을 피하는 기능)를 효과적으로 활용하지 않으면 비용이 매우 빠르게 증가합니다. 1라운드에 1,000토큰, 2라운드에 2,000토큰, 3라운드에 3,000토큰을 보내면 합계가 3×1,000=3,000이 아니라 1,000+2,000+3,000=6,000이 됩니다. 라운드가 많을수록 차이가 커집니다. 두 번째는 사고 토큰 비용입니다. 사고를 지원하는 모델은 많은 사고 토큰을 생성합니다. 이 토큰은 사용자에게 표시되지 않지만 여전히 비용이 청구됩니다.

도구 호출 비용에는 외부 API 사용료(검색 엔진은 질의마다 요금을 부과하고 데이터베이스 쿼리는 컴퓨팅 리소스를 소비), 코드 실행용 샌드박스 리소스, 그리고 쉽게 간과하는 간접 비용인 도구 출력을 컨텍스트에 주입할 때 발생하는 토큰 비용이 포함됩니다. 웹 검색 한 번이 반환하는 내용은 2,000~5,000토큰을 차지할 수 있으며, 이후 모든 추론 라운드에서 입력으로 반복 청구됩니다.

인프라 비용에는 벡터 데이터베이스(RAG 검색에 사용), 메시지 큐, 관계형 데이터베이스, 로깅·트레이싱 스토리지(관측 가능성에 사용)의 운영 오버헤드가 포함됩니다.

비용이 실제로 어디서 생기는지 보기 위해 부속 실험은 8라운드 환불 흐름을 고정했습니다. 주문, 배송, 환불 정책, 지식 베이스를 조회한 뒤 위험 확인, 환불, 알림, 종료까지 수행합니다. 실제 gpt-4o-mini 호출에서 ‘안정적인 접두사’와 ‘기록 압축’을 각각 켜고 꺼 2×2로 비교했습니다. 네 구성은 같은 업무를 완료했고 표 7-4의 비용은 저장된 token 사용량과 당시 가격으로 계산했습니다.

표 7-4 8라운드 에이전트 작업의 실제 비용

기준 구성은 라운드당 입력이 1,113 token에서 3,668 token까지 늘었습니다. 도구 반환값이 이후 요청에 반복해서 포함되며 8라운드에 9,544 입력 token을 차지했습니다. 두 최적화를 함께 켜면 5,248 token으로 줄고 총비용은 30% 낮아졌습니다.

효과는 단순히 더해지지 않습니다. 안정적인 접두사만으로 28.3%, 압축만으로 17.5%를 절감했지만 둘을 함께 써도 30.0%입니다. 기록을 압축하면 캐시가 적중할 접두사도 짧아지기 때문입니다. 여러 컨텍스트 최적화를 함께 적용할 때는 전체 작업에서 모든 조합을 측정해야 하며 개별 절감률을 더하면 안 됩니다. 모델, 가격, 작업 길이가 바뀌면 30%도 달라집니다. 재사용할 것은 네 구성의 대조 설계입니다.

비용 최적화 전략.

입력 측면에서는 세 방법을 먼저 시험할 만합니다. 접두사를 안정적으로 유지해 KV 캐시를 재사용하고, 오래된 궤적과 긴 도구 출력을 줄여 컨텍스트를 압축하며, 단순한 요청과 복잡한 추론에 서로 다른 등급의 모델을 배정합니다. 구현 방법은 2장에서 설명했습니다. 여기서 중요한 것은 기능을 각각 독립적으로 켜고 끌 수 있게 만드는 것입니다. 그래야 개별 효과뿐 아니라 함께 쓸 때 서로 상쇄되는지도 확인할 수 있습니다. 여기에 평가·운영 관점의 두 방법을 더합니다.

비동기 일괄 처리는 실시간 처리가 필요 없는 작업을 모아 API 공급자의 일괄 처리 가격 할인을 활용합니다. 자체 배포 시에는 사용량이 적은 시간대의 GPU 이용률도 높입니다.

비용 모니터링과 예산 제어.

프로덕션 환경에서는 실시간 비용 모니터링 시스템을 구축해야 합니다. 작업 유형, 모델, 사용자 등을 기준으로 토큰 소비량과 API 비용을 추적합니다. 작업마다 비용 상한도 설정하여 에이전트가 루프에 빠지거나 지나치게 깊게 탐색하면 자동으로 종료하고, 단일 작업에서 비정상적으로 높은 비용이 발생하지 않게 합니다.

실험 7-10 ★: 에이전트 작업의 엔드투엔드 비용 분석

실험 목표: 위 8라운드 작업의 전체 비용 분해를 재현하고 자신의 실제 워크로드에서 최적화 효과를 검증합니다.

기술적 접근법: 먼저 부속 저장소의 고정 작업을 재현하고, 이어서 자신의 대표 작업으로 바꿉니다. LangSmith나 자체 트레이싱 시스템으로 입출력 token, 사고 token, 도구 호출과 반환 크기, 엔드투엔드 지연 시간을 기록하고 평균 비용, p50/p95/p99, 비용 구성을 계산합니다.

인수 기준: 주요 비용 요인을 식별한 보고서를 만듭니다. 캐시와 압축의 네 조합을 모두 실행해 개별 효과와 상호작용을 확인합니다. 모델이 바뀌면 부속 궤적의 절감률을 재사용하지 말고 다시 측정합니다.

평가 기반 지속적 개선

모델 선택은 한 번으로 끝나는 결정이 아니라 모델의 발전에 따라 조정하는 지속적인 과정입니다. 이 장은 평가 시스템이 모델의 발전을 따라가게 한다는 주장으로 시작했습니다. 구체적인 모델 교체 사례를 통해 실제 의사결정에서 어떻게 작동하는지 살펴보겠습니다.

현재 에이전트 시스템이 도구 호출과 복잡한 오케스트레이션에 뛰어난 Claude를 기반으로 구축되었다고 가정합니다. 어느 날 Gemini가 새 모델을 출시했고, 공개 벤치마크에서 더 낮은 가격으로 여러 지표에서 Claude를 앞섰습니다. 이제 묻고 싶은 것은 “Gemini가 Claude보다 좋은가?”가 아니라 “내 구체적인 작업에서 Gemini가 Claude보다 좋은가? 얼마나 더 좋은가? 교체 비용은 얼마인가?”입니다.

견고한 평가 시스템을 갖춘 팀은 몇 시간 안에 답할 수 있습니다. 자체 평가 데이터셋에서 새 모델을 실행하고 작업 성공률, 도구 호출 정확도, 지연 시간, 비용을 비교합니다. 새 모델이 단순한 작업에서는 실제로 더 좋고 저렴하지만 여러 라운드의 복잡한 도구 오케스트레이션이 필요한 핵심 시나리오에서는 성공률이 5% 떨어진다는 사실을 발견할 수 있습니다. 차이가 추정한 표본 잡음을 넘는다고 확인하면(아래 “평가 결과의 통계적 유의성” 참조), 무작정 전체를 교체하지 않고 단순 작업은 새 모델로 이전해 비용을 줄이고 복잡한 작업은 기존 모델을 유지해 품질을 지키는 차등 전략을 선택할 수 있습니다. 이처럼 세밀하고 데이터에 근거한 의사결정은 평가 시스템을 미리 구축해야만 가능합니다.

실험 7-11 ★★: 다차원 모델 성능 벤치마킹

주류 LLM과 여러 API 공급자를 종합적으로 벤치마크하여 다차원 모델 선택 의사결정 데이터베이스를 구축합니다.

테스트 범위를 선택하세요. GPT 계열, Claude 계열, Gemini 계열, Doubao 계열 같은 비공개 SOTA 모델과 Qwen, Kimi, DeepSeek 같은 오픈 소스 모델을 포함합니다. 같은 모델도 서로 다른 API 공급자(예: DeepSeek 공식 대 Siliconflow)에서 테스트하여 제3자 성능 모니터링 플랫폼(예: Artificial Analysis)의 결과를 검증합니다.

표준 테스트 워크로드를 설계하세요. 입력 처리량 테스트에는 고정 길이 컨텍스트(8K/32K/128K토큰), 출력 처리량 테스트에는 고정 길이 응답(512/2,048토큰)을 사용합니다. 지연 시간 테스트에는 TTFT(Time to First Token)와 엔드투엔드 지연 시간을 포함합니다. 사고를 지원하는 모델은 사고 길이와 사고 지연 시간을 따로 측정합니다. 설정마다 최소 100회 요청하고 표준편차, p50, p95, p99를 계산합니다. 지연 시간 분산이 크면 사용자 경험이 불안정하다는 뜻입니다.

API의 가용성과 안정성을 평가하세요. 일주일 동안 매시간 한 번씩 조사하여 성공률, 오류 유형, 실패 지속 시간을 기록합니다. 실패율, MTTR(Mean Time to Recovery), 최장 연속 가동 시간을 계산합니다. 속도 제한의 실제 임계값도 테스트합니다. 동시 실행 수를 점차 높여 제한 지점을 찾고 RPM/TPM 한도를 기록합니다. 종합 비용을 계산합니다. 가격 정보(입력·출력·캐시 토큰 단가)를 수집하고 KV 캐시의 영향을 고려하여 대표적인 여러 턴 에이전트 작업의 평균 비용을 계산합니다.

실험 7-12 ★★: 사용자 메모리 시스템의 엔드투엔드 선택 평가

선행 조건: 3장의 맥락 검색 또는 에이전트형 RAG 실험을 완료해야 합니다.

목표: 사용자 메모리 검색 에이전트를 엔드투엔드로 모델 선택 평가하여 임베딩 모델, 재순위화 모델, 에이전트의 주 모델이 검색 품질·지연 시간·비용에 함께 미치는 영향을 살펴봅니다. chapter3/contextual-retrieval-for-user-memory 또는 chapter3/agentic-rag-for-user-memory를 재사용하고 테스트 케이스 60개에서 각 구성을 비교합니다.

인수 기준: 세 선택 지점을 차례로 평가합니다. 임베딩 모델(BGE-M3 / OpenAI / Doubao 등. 상위 5개 검색 정확도, 지연 시간, 비용 기록), 재순위화 모델(“재순위화 모델 없음” 기준선을 포함하고 한계 가치를 정량화), 주 모델(같은 검색 설정에서 성공률과 도구 사용 효율 비교)입니다. 핵심은 컴포넌트 간 시너지를 찾는 것입니다. 더 강한 임베딩 모델은 재순위화 모델을 불필요하게 만들 수 있고, 더 강한 주 모델은 검색의 단점을 보완할 수 있습니다. 선택은 가장 강한 컴포넌트를 따로 고르는 일이 아니라 시스템 차원의 절충입니다. 설정 세부 사항은 부속 저장소에 있습니다.

평가 결과의 통계적 유의성

평가 세트는 유한하고 모델 출력에는 무작위성이 있으므로, 점수 차이는 표본 잡음에 불과할 수도 있다. $n$ 개 사례에서 성공률 $p$ 를 측정했다면 표준오차는 대략 이렇게 추정할 수 있다.

예컨대 100개 사례에 성공률 70%라면 95% 신뢰구간은 약 $70\%\pm9$ 퍼센트포인트다. “새 모델 73% 대 옛 모델 70%“만으로는 교체를 뒷받침하기에 부족하다.

같은 과제 묶음에서 두 구성을 비교할 때는 짝지은 분석을 우선해야 한다. 문항마다 어느 쪽이 이겼는지 기록하고 McNemar 검정이나 짝지은 bootstrap으로 차이를 판정하는 것이지, 독립적인 두 성공률을 그냥 빼는 것이 아니다. Agent는 실행할 때마다 결과가 달라질 수 있으므로 각 구성을 여러 난수 시드(예컨대 35회)로 돌려 평균과 변동 폭을 함께 보고하는 편이 좋다. 한 번의 실행은 방향을 걸러 내는 데에만 쓸 수 있다. 기대 이득이 23퍼센트포인트뿐이고 평가 세트가 수십 문항밖에 없다면 먼저 표본을 늘려야 한다. 표준오차는 $1/\sqrt{n}$ 로 줄어든다.

for task in paired_tasks:
    for seed in fixed_seeds:
        a = run(config_a, task, seed)
        b = run(config_b, task, seed)
        record_paired_delta(verifier(a), verifier(b))

return paired_bootstrap_or_mcnemar(all_deltas)

짝짓는다는 것은 두 그룹이 과제와 무작위 조건을 공유한다는 뜻이지, 두 표본을 따로 뽑아 평균을 비교한다는 뜻이 아니다.

여러 가설을 병렬로 검증할 때는 다중 비교도 고려해야 한다. 유의 수준 임계값을 조이거나, 양성 결과는 독립적으로 재실행한다. 실무의 판단 기준은 간단하다. 점수 차가 잡음을 넘고, 짝지은 분석에서도 성립하며, 재현까지 된다면 그때 비로소 모델을 바꾸거나 변경을 배포할 만하다.

에이전트 관측 가능성

모델 선택이든 지속적 개선이든 평가 기반 의사결정은 고품질 운영 데이터에 의존합니다. 아래에서는 먼저 이 데이터를 체계적으로 수집하는 방법인 관측 가능성을 소개하고, 평가 결과를 시스템 개선으로 옮기는 방법을 논의합니다.

관측 가능성은 분산 시스템에서 빌려온 개념입니다. 시스템을 열어 작동하는 모습을 직접 볼 수 없으므로 시스템이 내보내는 로그, 지표, 트레이스로 내부 상황을 추론합니다. 의사가 환자의 내부를 직접 보지 못한 채 체온, 혈압, 영상으로 진단하는 것과 같습니다. 에이전트 시스템은 더 어렵습니다. 같은 입력도 서로 다른 출력을 만들 수 있고, 여러 라운드의 사고와 도구 호출 때문에 실행 경로가 매우 복잡하며, 모델의 “사고”는 외부에서 전혀 볼 수 없습니다.

관측 가능성의 첫 번째 가치는 문제 진단입니다. 완전한 트레이스가 있으면 개발자가 추측하는 대신 전체 과정을 재생할 수 있습니다. 둘째, 지속적 최적화의 토대입니다. 어떤 작업에 여러 라운드의 반복이 필요한지, 어느 도구의 성공률이 가장 낮은지, 어떤 검색 질의가 늘 빈 결과를 반환하는지 볼 수 있습니다. 비용 관리 측면에서는 에이전트 운영 비용이 작업마다 한두 자릿수 배만큼 달라질 수 있는데, 트레이싱으로 비정상적으로 비싼 사례를 드러낼 수 있습니다. 마지막으로 축적된 트레이스 데이터는 이후 시스템 최적화와 모델 개선의 토대가 됩니다.

에이전트 관측 가능성은 트레이스를 기반으로 하며, 그 데이터 구조는 분산 시스템의 스팬 트리 모델을 직접 물려받습니다. 한 번의 작업 실행이 하나의 트레이스에 대응하고, 각 LLM 호출·도구 호출·검색은 스팬입니다. 스팬은 입력·출력, 시작·종료 시각, 토큰 소비량, 오류 정보를 기록하는 실행 단위입니다. 스팬의 부모-자식 관계가 실행 트리를 만듭니다. 예를 들어 “에이전트 주 루프” 스팬 아래에 여러 “LLM 호출”과 “도구 호출” 자식 스팬이 달릴 수 있습니다. 이 계층에는 이미 표준화된 프로토콜이 있습니다. OpenTelemetry는 범용 분산 트레이싱 표준이고, OpenInference 같은 명세는 그 위에 프롬프트, 모델 매개변수, 토큰 사용량 등을 기록하는 LLM 전용 의미 규칙을 정의합니다. 표준 프로토콜을 채택하면 수집과 분석을 분리할 수 있다는 장점이 있습니다. 같은 트레이스 데이터를 서로 다른 분석 백엔드에 연결하여 공급자 종속을 피할 수 있습니다.

LangSmith는 이 분야를 대표하는 플랫폼 중 하나이며(Langfuse, Arize Phoenix 등도 비슷합니다), 관측 가능성, 평가, 최적화를 폐루프로 통합합니다. 각 실행은 트레이스 세션을 만들고, 모델 호출, 도구 사용, 지식 검색을 독립된 실행 단위로 기록한 뒤 인과관계로 연결하여 실행 트리를 구성합니다. 각 단위에는 완전한 입력·출력, 타이밍 정보, 비용 데이터, 오류 정보를 기록합니다. 플랫폼은 비동기 일괄 데이터 수집을 사용하여 트레이싱 자체가 에이전트의 응답 지연에 영향을 주지 않게 합니다.

플랫폼은 A/B 테스트(사용자 트래픽 일부를 새 버전으로 라우팅하고 지표를 자동 비교하며 신속한 롤백이나 점진적 확대를 지원), 프롬프트 버전 관리(각 버전을 런타임 성능 데이터와 연결), 협업 개발(팀 구성원이 트레이스 데이터와 문제 사례를 공유)도 지원합니다. 프로덕션 환경의 방대한 실제 데이터는 지속적 개선을 위한 금광입니다. 예상하지 못한 시나리오를 발견하고 가장 시급하게 최적화해야 할 기능을 식별할 수 있습니다.

관측 가능성 데이터의 가장 가치 있는 활용법은 이를 평가 자산으로 바꾸는 것입니다. 실용적인 루프는 다음과 같습니다. 프로덕션 트레이스에서 실패하거나 의심스러운 사례 추출 → 익명화(사용자 데이터와 키 같은 민감 필드 제거) → 새 테스트 케이스와 회귀 테스트로 정제하여 평가 세트에 추가합니다. 그러면 평가 세트는 일회성 정적 모음이 아니라 제품과 함께 발전하고 실제 사용자 분포를 계속 반영하는 살아 있는 자산이 됩니다. 오늘 프로덕션에서 드러난 실패 패턴이 내일의 기준선을 지키는 회귀 테스트가 됩니다. 이것이 관측 가능성과 이 장의 핵심 주제를 잇는 접점입니다. 관측 가능성은 현실에서 일어나는 일을 “보는” 책임을 지고, 평가는 그 관측을 반복 가능한 기준으로 확정할 책임을 집니다.

포괄적인 평가 시스템과 데이터셋을 마련한 뒤에는 평가 결과를 실질적인 시스템 개선으로 옮기는 일이 핵심입니다.

벤치마크 보고서에서 시스템 개선으로

이제 부속 저장소에 남아 있는 실제 AndroidWorld 개선 과정을 살펴보겠습니다. API 35 에뮬레이터의 Wi-Fi 설정 작업 네 개만 대상으로 삼고 작업마다 한 번씩 쌍대 실행했습니다. 116개 작업 전체 벤치마크도 아니고 API 33 표준 환경의 재검증도 아닙니다. 시스템 전체가 얼마나 좋아졌는지 증명하는 사례가 아니라 한 라운드의 결과로 다음 라운드에서 무엇 하나를 바꿀지 결정하는 사례입니다.

하네스 엔지니어링의 관점에서 이 절은 본질적으로 하네스를 반복 최적화하는 방법론을 다룹니다. 평가 데이터로 하네스의 약점(컨텍스트 부족? 제약 누락? 검증 불충분? 늦은 피드백?)을 찾아 표적 개선한 다음 다시 평가하여 하네스의 지속적 진화를 위한 폐루프를 만듭니다.

벤치마크 보고서를 분석하기 전에 쉽게 간과하는 원칙을 기억하세요. 에이전트의 성능이 떨어지면 에이전트보다 평가 시스템을 먼저 확인해야 합니다. 점수가 내려가자마자 에이전트 코드를 수정하기 시작하면서 평가 시스템이 먼저 고장 났을 가능성을 무시하는 것이 흔한 실수입니다. 왜곡된 신호를 따라가면 교정은 첫 단계부터 틀립니다. 전형적인 평가 측 실패에는 런타임 환경의 리소스 부족으로 프로세스가 종료되는 문제(무작위 실패로 나타남), 정답을 오답으로 표시하는 검증기 버그, 프로덕션 시나리오와 동기화되지 않고 드리프트한 테스트 케이스가 있습니다. 대표 수치에서는 모두 모델 성능 저하와 똑같아 보이며, 전체 트레이스를 검토해야만 구분할 수 있습니다.

벤치마크 보고서 읽기: 문제 발견의 기술

초기 보고서는 116개 작업을 한 번씩 실행해 약 88%의 전체 성공률을 기록했습니다. 그러나 실패는 흩어져 있지 않았습니다. SystemWifiTurn* 작업 네 개 중 세 개가 실패했고, 궤적에는 화면을 오가거나 최종 상태를 확인하지 못하는 행동이 반복됐습니다. 원인은 적어도 두 가지로 볼 수 있습니다. 설정 화면으로 가는 길을 모르거나, 에이전트가 받은 화면 정보가 불완전한 경우입니다.

88%라는 총점만 보면 이 작고 밀집된 실패군을 놓치기 쉽습니다. 단계 수만 늘리면 ‘화면이 보이지 않음’을 ‘시간이 부족함’으로 오진할 수도 있습니다. 먼저 실패가 집중된 작업과 역량을 찾고 궤적을 재생해 보기·생각하기·행동하기·검증하기 중 어디서 막혔는지 구분해야 합니다. Wi-Fi 작업 네 개로 범위를 좁힌 목적은 저비용으로 원인을 진단하는 것이지 전체 성능을 추정하는 것이 아닙니다.

데이터에서 가설로: 개선 로드맵 구축

첫 라운드는 가장 싼 변경부터 시험했습니다. H1은 에이전트가 길만 모른다고 보고 실험군에 Wi-Fi 설정 탐색 안내와 최종 상태 확인 지시를 추가했습니다. 성공률은 그대로였으므로 원인은 프롬프트가 아니었습니다.

두 번째 라운드는 에이전트가 실제로 무엇을 보는지 확인했습니다. H5는 API 35와 호환되지 않는 accessibility feed를 AndroidWorld가 지원하는 UIAutomator 요소 트리로 바꿨습니다. 성공률은 올랐지만 전체 트리가 길어 token 사용량이 크게 늘었습니다. H5C는 새 정보를 추가하지 않고 보이지 않으며 텍스트도 없고 조작할 수도 없는 컨테이너를 삭제해 성공률을 유지하면서 잡음을 줄일 수 있는지 시험했습니다.

세 라운드 모두 모델, 작업 매개변수, 무작위 시드, 단계 제한, 에뮬레이터를 고정하고 대조군과 실험군의 실행 순서를 번갈아 배치했습니다. 라운드마다 변수 하나만 바꾸면 이전 결과에서 드러난 문제가 다음 라운드의 유일한 검증 대상이 됩니다.

결과에서 의사결정으로: 데이터 기반 절충

세 라운드의 실측 결과는 표 7-5과 같습니다. 각 그룹에 작업이 네 개뿐이므로 이 수치로 판단할 수 있는 것은 실험을 확대할 가치가 있는지까지입니다. AndroidWorld 전체 성공률을 추정할 수는 없습니다.

표 7-5 AndroidWorld Wi-Fi 하위 집합의 세 라운드

세 결과를 이어 보면 하나의 백분율보다 유용한 결론이 나옵니다. 에이전트가 받지 못한 정보는 프롬프트를 자세히 쓴다고 생기지 않으므로 이런 실패에서는 입력부터 확인해야 합니다. 반대로 입력이 많을수록 좋은 것도 아닙니다. 전체 요소 트리는 ‘보이지 않음’을 해결했지만 잡음이 많았습니다. 의미 없는 노드를 지운 뒤에도 네 작업이 모두 성공했고 token은 약 절반으로 줄었습니다. 모델을 바꾸지 않고 Harness의 화면 표현만 조정해 먼저 실행 가능성, 다음으로 비용 문제를 해결했습니다.

지속적 개선: 첫 개선에서 시스템 진화까지

H5C가 네 작업을 통과했다는 사실은 다음 시험으로 갈 가치가 있다는 뜻이지 배포할 수 있다는 뜻이 아닙니다. 다음 단계는 타사 앱을 포함해 Pixel 6 / API 33 표준 환경에서 116개 작업을 각각 5개 시드로 실행하는 것입니다. 성공률은 비열등해야 하고 token 비율은 0.75 이하, 지연 시간 비율은 1.5 이하이어야 합니다. 이 전체 재검증 전에는 하위 집합의 4/4를 시스템 전체의 100%라고 쓸 수 없습니다.

지속적 반복은 증거의 규모에 맞는 다음 단계만 허용하는 일입니다. H1 실패로 프롬프트를 더 쌓지 않았고, H5는 올바른 방향과 함께 비용 문제를 드러냈으며, H5C가 비용을 해결한 뒤에야 시험을 확대할 자격을 얻었습니다. 좋은 벤치마크 보고서는 점수뿐 아니라 결론의 적용 범위, 통과하지 못한 가드레일, 다음에 검증할 항목까지 밝힙니다.

실험 7-13 ★★★: AndroidWorld에서 평가하고 개선하기

이 실험은 평가 보고서에서 시스템 개선까지 가는 흐름을 연습합니다. chapter6/android-world에 저장된 과거 보고서와 세 쌍의 실행 결과에서 시작합니다.

1단계: 진단. 작업별 표와 역량 태그 행렬을 교차 분석하여 표면적인 작업 실패를 근본적인 역량 결함에 매핑합니다. 성공률이 기대보다 낮은 역량 태그와 실패가 밀집한 작업 영역을 식별합니다.

2단계: 가설 수립. 표면 → 중간 → 심층의 3계층 프레임워크에 따라 개선 가설을 세웁니다. 각 가설에는 목표 성공률 개선 폭과 검증 방법을 명시해야 합니다.

3단계: 단계적 실험. H1, H5, H5C를 재현하며 라운드마다 변수 하나만 바꿉니다. 성공률뿐 아니라 token, 지연 시간, 회귀도 기록합니다.

4단계: 데이터 기반 의사결정. 효과가 있는 개선을 모두 채택하지 말고, 개선마다 적용 범위, 지연 시간 영향, 비용 오버헤드를 저울질하여 비용 대비 효과 분석에 근거한 배포 결정을 내립니다. 비용이 낮고 이점이 큰 개선은 우선 배포하며, 비용이 높은 개선은 중요한 시나리오로 제한합니다.

5단계: 반복. 소규모 시험을 통과해도 전체 재검증으로만 진행합니다. 표준 환경에서 116×5회 실행을 마치기 전에는 배포를 논하지 않습니다. 보고서에는 환경 차이, 표본 수, 아직 실행하지 않은 부분을 남깁니다.

외부 평가에서 내부 평가로: 프로덕션 수준 에이전트의 평가 인프라

지금까지 이 장에서는 평가 환경을 구축하고, 데이터셋을 설계하고, 벤치마크 보고서를 분석하는 등 외부에서 에이전트 시스템을 평가했습니다. 하지만 최고의 에이전트 제품은 외부 평가를 받는 데 그치지 않고 지속적인 자체 평가 인프라를 제품에 내장합니다. 아래에서는 5장에서 소개한 오픈 소스 범용 에이전트 OpenClaw를 예로 들고, 선도적인 코딩 에이전트 제품에 대한 공개 기술 분석과 실무자의 통찰을 바탕으로 본받을 만한 내부 평가 시스템을 제시합니다. ML 연구의 실험 방법론을 제품 엔지니어링에 체계적으로 내장하는 시스템입니다.

제거 실험 인프라: 각 기능의 실제 기여 이해하기

ML 연구자는 모델의 어느 컴포넌트가 실제로 중요한지 알아내기 위해 오래전부터 제거 실험을 사용했습니다. 제거 실험은 컴포넌트를 한 번에 하나씩 “없애고” 전체 성능이 얼마나 떨어지는지 관찰하는 방법입니다. OpenClaw는 이 방법론을 제품 엔지니어링에 도입합니다. 내장된 마스터 스위치로 사고 모드, 컨텍스트 압축, 자동 메모리, 백그라운드 작업 등 여러 주요 기능을 한꺼번에 비활성화하여 “순수 모델” 기준선을 만들 수 있습니다. 이를 통해 **기능이 실제로 사용자 경험을 개선하는가, 아니면 유용하게 느껴질 뿐인가?**라는 핵심 질문에 답할 수 있습니다.

제거 실험을 일회성 연구 활동이 아니라 일상적인 엔지니어링 실무로 만들면 몇 가지 실질적인 의미가 생깁니다. 첫째, 모듈 수준 상수가 설정 값을 포착하기 전인 시작 경로의 매우 이른 단계에 제거 실험 스위치를 주입해야 합니다. 즉 제거 실험 인프라는 나중에 덧붙이는 것이 아니라 처음부터 시스템 아키텍처에 설계해야 합니다. 둘째, 제거 실험을 정기적으로(예: 주요 릴리스 전마다) 실행하면 한때 효과가 있었지만 모델이 발전하면서 더 이상 필요하지 않게 된 기능인 “기능 부채”를 발견할 수 있습니다. 프로덕션 에이전트를 구축하는 모든 팀에 권장하는 실무는 다음과 같습니다. 모든 주요 기능은 독립적으로 비활성화할 수 있어야 하고, 팀은 각 기능의 실제 기여를 정기적으로 검증해야 합니다.

A/B 테스트 방법론: 메커니즘과 목표 구분하기

성숙한 에이전트 제품은 자체 행동에 대해 엄격한 A/B 테스트를 수행합니다. 즉 사용자를 무작위로 두 그룹에 나누어 한쪽은 이전 버전, 다른 쪽은 새 버전을 사용하게 하고 두 그룹의 실제 데이터를 비교하여 변경의 효과를 판단합니다. 잘 설계된 에이전트 A/B 테스트 사례는 몇 가지 핵심 방법론적 원칙을 보여 줍니다.

이진 비교가 아니라 여러 변형을 사용할 것. 단순히 “있음”과 “없음”을 비교하지 말고 점진적인 변형을 여러 개 설계합니다. 예를 들어 프롬프트 제약의 강도를 테스트한다면 대조군과 제약이 점차 엄격해지는 세 실험군을 구성합니다. 이 설계로 용량-반응 관계를 파악하고 최적점을 찾을 수 있습니다.

메커니즘 지표와 목표 지표를 구분할 것. 가장 쉽게 하는 실수는 바꾸려는 대상을 최적화 목표로 착각하는 것입니다. 예를 들어 “에이전트의 계획 파일 길이 줄이기”를 테스트한다면 계획 길이는 직접 바꾸는 메커니즘 지표이지만 목표는 아닙니다. 진짜 목표는 “세션 수준 비용 절감”일 수 있습니다. 계획 파일을 줄이면 비용이 낮아질 수 있지만, 계획이 충분히 상세하지 않아 편집-검사-편집 루프가 늘고 전체 출력이 증가할 수도 있습니다. 항상 **내가 바꾸는 것(메커니즘)과 진정으로 중요한 것(목표)이 같은가?**라고 물어야 합니다. 다르다면 목표를 우선하세요.

가드레일 지표를 설정할 것. 목표 지표가 좋아져도 사용자 만족도가 떨어지거나 작업 수가 늘거나 오류율이 오르면 실험을 중단해야 합니다. 가드레일 지표는 절대 후퇴해서는 안 되는 협상 불가능한 임계값입니다.

기준 통계를 기록할 것. 표본 크기, 분포 백분위수, 상관관계 분석(예: “계획 크기가 커질수록 거부율이 단조롭게 증가”)을 포함하여 실험 결과 해석에 필요한 맥락을 제공합니다. 기준선이 없으면 실험 결과가 통계적으로 유의미한지 판단할 수 없습니다.

2계층 기능 플래그 시스템

에이전트 제품에는 첫날부터 설계한 기능 플래그 인프라가 필요합니다. 기능 플래그는 코드를 다시 배포하지 않고도 사용자에게 기능을 활성화하거나 비활성화할지 원격으로 제어하는 스위치입니다. 실험, 점진적 출시, 비상 서킷 브레이커라는 세 가지 목적을 동시에 수행합니다.

컴파일 시점 플래그는 빌드 단계에서 관련 코드를 빌드 산출물에서 물리적으로 제거합니다. 내부 전용 기능은 외부 빌드에 아예 존재하지 않아 리버스 엔지니어링으로도 제거된 기능을 발견할 수 없습니다. 깔끔한 제거 메커니즘이 되기도 합니다. 기능을 비활성화하면 런타임에서 로직을 건너뛰는 것이 아니라 해당 코드가 물리적으로 없어집니다.

런타임 플래그는 서버가 설정을 전달하고 로컬 디스크에 캐시합니다. 네트워크 요청을 기다리느라 에이전트 시작을 막는 대신 약간 오래된 캐시 설정을 읽는 것을 우선하는 설계입니다. 구체적인 그룹 할당은 실험 플랫폼(예: GrowthBook)을 통해 결정하여 A/B 테스트 그룹을 배정합니다. 중요한 설계 세부 사항은 중복 기록이 실험 데이터를 오염시키지 않도록 기능별 노출 이벤트를 세션마다 최대 한 번만 기록하는 것입니다.

에이전트 개발자가 얻을 교훈은 기능 플래그가 디버깅 도구가 아니라 일급 아키텍처 컴포넌트라는 것입니다.

프롬프트 민감도 평가

시스템 프롬프트는 에이전트 행동의 핵심 “코드”지만 일반 코드에 적용하는 버전 관리와 회귀 테스트가 없는 경우가 많습니다. OpenClaw의 접근법은 지정한 Git 리비전이나 커밋에서 완전히 렌더링된 시스템 프롬프트를 추출하는 전용 도구를 제공하는 것입니다. 모든 동적 조건을 펼친 최종 텍스트까지 포함합니다. 그러면 팀은 **어느 커밋에서 프롬프트가 바뀌었는가? 평가 세트에 어떤 영향을 주었는가?**에 정확히 답할 수 있습니다.

모든 에이전트 팀에 권장하는 실무는 다음과 같습니다. (1) 시스템 프롬프트는 결정론적으로 렌더링할 수 있어야 합니다(같은 설정 입력이면 항상 같은 출력을 생성). (2) 프롬프트의 버전별 스냅샷 메커니즘을 구축합니다. (3) 코드 변경에 CI가 필요하듯 모든 프롬프트 변경에 대해 평가 세트에서 회귀 테스트를 실행합니다.

평가 기반이 되는 개인정보 보호형 분석

평가에는 좋은 데이터가 필요하지만 에이전트 제품은 민감한 사용자 콘텐츠를 다루는 경우가 많습니다. OpenClaw는 타입 시스템으로 이 모순을 해결합니다. 분석 인터페이스는 특별한 타입으로 감싼 값만 받으며, 타입 이름 자체가 “이 값이 코드나 파일 경로가 아님을 확인했다”고 명시하는 감사 추적 역할을 합니다. 이 설계는 개인정보 보호 제약을 문서에 적힌 명세에서 컴파일 시점에 강제되는 타입 검사로 바꿉니다.

핵심 원칙은 개인정보 보호 제약을 처음부터 시스템에 설계하고 나중에 덧붙이지 말라는 것입니다. 분석 시스템이 데이터를 안전하게 수집할 수 없다면 효과적으로 평가할 수도 없습니다. 개인정보 보호와 평가는 대립하지 않습니다. 개인정보 보호를 인식한 설계는 실제로 무엇을 측정해야 하는지 신중하게 생각하도록 강제하며, 이는 더 정확한 평가 지표로 이어집니다.

외부에서 내부로: 평가 사고의 전환

이 절의 핵심 메시지는 다음과 같습니다. 앞 절에서는 에이전트를 외부에서 평가하는 방법을 배웠고, 이 절에서는 최고의 에이전트 제품이 내부에서 자신을 평가하는 방법을 살펴보았습니다. 외부 평가는 “에이전트가 얼마나 좋은지” 알려 주고, 내부 평가 인프라는 “어떤 변경이 에이전트를 더 좋게 만들었는지” 알려 줍니다. 제거 실험은 실제로 중요한 기능을 찾고, A/B 테스트는 각 변경의 영향을 정량화하며, 기능 플래그는 실험과 롤백을 위한 인프라를 제공하고, 프롬프트 민감도 평가는 시스템 프롬프트를 CI 시스템에 통합하며, 개인정보 보호형 분석은 데이터 수집의 규정 준수를 보장합니다. 이 다섯 컴포넌트가 함께 평가 기반 제품 엔지니어링을 구성합니다. 가끔 평가하는 것이 아니라 모든 제품 의사결정에 평가를 내장하는 것입니다.

시뮬레이션 환경: 평가에서 사후 학습으로 가는 다리

평가의 종착점은 채점이 아니라 개선입니다. 이 장에서는 이미 하네스를 조정하는 경로(벤치마크 보고서에서 시스템 개선으로)와 평가를 제품 엔지니어링에 내장하는 경로(내부 평가 인프라)라는 두 가지 개선 방법을 보여 주었습니다. 가장 강력한 형태의 개선은 학습입니다. 목표가 “기존 역량 평가”에서 특히 8장에서 다룰 사후 학습 기법으로 “새 역량 육성”까지 확장되면 평가 환경은 에이전트가 반복해서 연습하고 자동으로 채점받는 가상 훈련장인 시뮬레이션 환경으로 발전해야 합니다. 시뮬레이션 환경과 평가 환경의 핵심 차이는 훨씬 높은 상호작용 빈도(수백만 대 수천), 암기를 방지하기 위한 무작위화, 즉각적인 피드백의 필요성입니다. 응용 관점에서 시뮬레이션 환경은 디지털 환경(정보 처리 작업)과 체화 환경(물리적 세계 인식·조작)이라는 두 범주로 나뉩니다.

다리의 양쪽 끝은 다음과 같이 연결됩니다. 평가 측에 축적한 자산은 거의 그대로 학습 신호로 전환됩니다. 잘 정의한 루브릭이나 검증기는 본질적으로 **검증 가능한 보상을 활용한 강화 학습(RLVR, Reinforcement Learning with Verifiable Rewards)**의 보상 함수입니다. 채점 스크립트가 보상 스크립트가 되고, 테스트 통과 여부나 상태가 기준을 충족하는지는 평가 기준이면서 강화 학습 보상이 됩니다. 하지만 학습에는 평가에서 고려할 필요가 없었던 요구가 생깁니다. 첫째는 신뢰할 수 있는 재설정 의미론입니다. 학습은 수백만 에피소드(초기 상태에서 작업 완료까지 이어지는 한 번의 완전한 상호작용)를 실행하며, 에피소드마다 환경을 결정론적이고 깨끗한 초기 상태로 재설정할 수 있어야 합니다. 그렇지 않으면 이전 에피소드의 잔여 상태가 그래디언트 신호를 오염시킵니다. 둘째는 평가를 훨씬 뛰어넘는 처리량입니다. 평가 몇천 회면 결론을 내리기에 충분하지만, 학습은 허용 가능한 실제 경과 시간 안에 모델에 수백만 번의 상호작용을 제공해야 합니다. 환경의 병렬화 정도와 인스턴스당 오버헤드가 학습 가능 여부를 직접 결정합니다. 검증기를 보상 함수로 전환하는 것과 학습 수준의 재설정·처리량이라는 두 사항은 8장에서 자세히 설명합니다.

디지털 환경에서는 AWorld 프레임워크가 GAIA 작업을 위한 제어 가능한 MCP 서버 샌드박스를 구축합니다. 도구 함수 126개를 포괄하는 MCP 서버 26개를 제공하여 실제 API에 직접 접근할 때의 차단과 제어할 수 없는 부작용을 피합니다. 모든 도구 호출을 재생하고 감사할 수 있습니다. AWorld의 분산 아키텍처는 기존의 직렬 실행 시간을 7,695초에서 525초로 줄였고(14.6배 향상), 환경의 무상태 설계로 각 인스턴스가 완전히 독립적이어서 효율적인 병렬 처리를 지원합니다.

체화 환경에서는 RoboTwin2가 물리 엔진을 바탕으로 양팔 조작 작업을 구축하고 물체의 위치, 방향, 외관을 무작위화하여 일반화 능력을 높입니다. 관측 공간에는 여러 카메라의 영상과 관절 상태가 포함되며, 모델이 여러 연속 행동을 한 번에 계획하는 **행동 청킹(Action Chunking)**으로 실시간 제어를 달성합니다(6장에서 자세히 설명). OSWorld는 가상 머신 스냅샷으로 재설정 기능을 제공하고, AndroidWorld는 모바일 애플리케이션 자동화에 초점을 맞춥니다. 디지털 환경이든 체화 환경이든 시뮬레이션 환경에는 4장에서 다룬 격리 실행 환경과 가상 신원 메커니즘(VM·컨테이너 격리, 레지덴셜 프록시, 휴먼 인 더 루프 인증, 공유 파일 시스템)도 필요하므로 여기서는 반복하지 않습니다.

실험 7-14 ★★: OpenVLA와 RoboTwin2의 체화 지능 환경 구성하기

로봇 조작을 위한 시뮬레이션 환경을 구성합니다. ch7/SimpleVLA-RL과 OpenVLA 문서를 읽고 Vision-Language-Action 모델의 아키텍처를 이해하세요. 시각 인코더, 언어 모델, 행동 디코더를 엔드투엔드로 통합하여 이미지와 텍스트를 공유 의미 공간에 투영합니다. RoboTwin2 환경을 구성하고 관측 공간(세 시점의 RGB + 14차원 관절 상태)과 행동 공간(14차원 제어 벡터)을 이해합니다. move_can_pot의 환경 무작위화 메커니즘과 공간 제약 로직을 연구합니다. 사전 학습된 모델을 평가하여 성공률, 완료 시간, 실패 유형을 기록하고 행동 청킹 메커니즘의 영향에 초점을 맞춥니다.

충실도의 절충과 도메인 무작위화

충실도가 높은 환경은 현실 세계로 더 잘 전이되지만 컴퓨팅 비용이 높습니다. 충실도의 또 다른 차원은 무작위화 정도입니다. 적절한 무작위화는 일반화 능력을 높이지만 지나치면 작업이 너무 어려워질 수 있습니다. **도메인 무작위화(Domain Randomization)**는 시뮬레이션과 현실의 격차(sim-to-real gap)를 줄이는 핵심 기법입니다. 물리적 매개변수, 시각적 외관, 센서 잡음 등에 폭넓은 무작위 변화를 도입합니다. 다양한 조명과 각도에서 물건 잡기를 연습해 현실에서 조명이 바뀌었다는 이유만으로 실패하지 않게 하는 것과 같습니다. 디지털 환경에서 시뮬레이션과 현실의 격차는 인터페이스 렌더링, 응답 시간 등의 차이로 나타나며 지연과 실패를 무작위화하여 완화할 수 있습니다.

장 요약

이 장은 에이전트가 실제로 좋아졌는지 어떻게 아는가라는 질문을 다뤘습니다. 이 사슬은 네 단계로 이루어집니다. 먼저 무엇을 성공으로 볼지 정리하고(Pass@k, Best@k, Pass consecutive@k의 기준 차이), 다음으로 과제가 어디서 오는지 정하고(공개 벤치마크, 자체 구축 업무 세트, 프로덕션 궤적 환류의 세 출처), 이어서 검증 방식을 고르고(결정적 검증기에서 검사 항목 목록, Rubric과 LLM 판정, 나아가 쌍대 비교까지), 마지막으로 점수를 의사결정으로 바꿉니다(통계적 유의성, 실패 귀인, 회귀 과제, 모델 선정). 어느 단계가 흔들려도 결론의 신뢰성이 떨어집니다. 실측 결과는 네 가지를 더 보여 줍니다. 구조화 메모리와 RAG를 합쳐도 시너지가 보장되지 않고, 캐시와 압축의 절감률은 더할 수 없으며, 참조 음성 선택이 멀티모달 점수의 의미를 바꾸고, 에이전트가 UI를 읽는 능력과 그 token 비용은 Harness가 입력을 표현하는 방식에 달려 있습니다. 모델 선택은 한 점의 성능이 아니라 자원 예산별 역량 곡선을 비교해야 합니다. 프로덕션 평가는 가끔 치르는 시험이 아니라 제품 결정에 내장된 지속적 검증입니다.

책 전체의 구조로 보면 이 장이 만드는 것은 1장 발견 루프의 증거 구간입니다. 실패 귀인이 뒤따르는 제안에 기댈 근거가 있는지를 결정합니다.

궤적 접두부 경계 평가는 나아가 정보를 얻는 것과 그것을 현재 결정에 올바르게 쓰는 것은 서로 다른 능력임을 보여 준다. 엔드투엔드 회귀는 기본 과제가 퇴화하지 않음을 보장하고, trajectory prefix 경계 집합은 범위 판단, 현재 지시에 의한 덮어쓰기, 명확화 요청, 위험한 동작 전 확인을 직접 점검한다. 사용자 메모리는 이 범용 방법의 한 사례일 뿐이다. 프로덕션급 Agent의 평가는 이따금 치르는 시험이 아니라, 실제 문제 사례에서 회귀 과제와 경계 과제를 끊임없이 만들어 내는 검증 시스템이다.

핵심 방법론은 관찰 → 가설 → 실험 → 검증 → 새로운 이해 → 새로운 가설이며, 에이전트 엔지니어링을 경험에 의존하는 “연금술”에서 데이터 기반 과학적 엔지니어링으로 바꿉니다.

이 장에서 소개한 평가 시스템은 완전한 폐루프를 이룹니다. 평가 환경이 자동 테스트 인프라를 제공 → 평가 데이터셋이 테스트 케이스를 정의 → 자동 평가 방법(LLM-as-a-Judge와 루브릭)이 에이전트의 성능을 채점 → 벤치마크 분석이 개선 방향을 제시 → 시스템 개선이 문제를 해결 → 평가 환경과 데이터셋을 갱신하여 새로운 반복 주기를 시작합니다.

여기서 구축한 평가 시스템은 현재 시스템의 최적화뿐 아니라 이어지는 두 장의 중요한 토대가 됩니다. 8장은 평가 환경과 데이터를 모델 사후 학습의 입력으로 전환하고 SFT와 RL로 상호작용 정책을 매개변수에 기록합니다. 9장은 프로덕션 궤적의 다차원 평가를 지식, 지침, 프로그램, 매개변수의 갱신 후보로 바꿉니다.

생각해 볼 문제

1. ★★ LLM-as-a-Judge는 언어 모델의 출력을 언어 모델로 평가합니다. 이러한 “자체 평가”에는 체계적인 사각지대가 있을까요? 예를 들어 모델이 사람의 판단과 맞지 않는 특정 스타일의 응답에 계속 높은 점수를 줄 수 있습니다. 이러한 편향을 어떻게 감지하고 교정할 수 있을까요?
2. ★★★ 평가 데이터셋의 “유출 방지” 설계는 매우 중요합니다. 하지만 오픈 소스 생태계에서는 벤치마크 데이터가 공개되면 곧 학습 데이터에 포함됩니다. 이 “고양이와 쥐의 게임”에 종착점이 있을까요? 데이터 유출에 근본적으로 견디는 평가 방법을 설계해 보세요.
3. ★★ Scale AI의 네 기준(전문가 지침, 포괄적 범위, 표준화된 중요도 가중치, 자체 완결적 평가)은 평가의 주관성을 없애려 합니다. 하지만 “답이 도움이 되는가?”, “어조가 적절한가?” 같은 일부 작업 차원은 본질적으로 주관적입니다. 이러한 주관적 차원을 위한 신뢰할 수 있는 루브릭을 어떻게 설계할 수 있을까요?
4. ★★ τ-bench는 실제 사용자 행동을 시뮬레이션하여 에이전트를 평가합니다. 하지만 시뮬레이션 사용자 자체가 LLM이므로 감정적으로 격앙되거나 의사를 명확히 표현하지 못하는 사용자 같은 일부 경계 사례를 체계적으로 과소평가할 수 있습니다. 시뮬레이션 사용자 자체의 품질을 어떻게 검증할 수 있을까요?
5. ★★ 쌍대 비교(Bradley-Terry 모델)는 선호가 추이적이라고 가정합니다(A > B이고 B > C이면 A > C). 하지만 사람의 선호는 추이성을 자주 위반합니다. 에이전트 평가에서는 어떤 시나리오에서 비추이적 선호가 나타날 수 있을까요? 이는 순위의 신뢰성에 어떤 영향을 줄까요?
6. ★★ 이 장은 능력의 상한을 나타내는 Pass@k와 업무 신뢰성을 나타내는 Pass consecutive@k를 구분했습니다. 단일 실행 성공률이 60%에 불과한 에이전트에 대해, 작업의 실패 비용·재시도 비용·부작용을 어떻게 결합해 어느 지표를 보고할지와 $k$를 얼마로 잡을지를 결정하시겠습니까?
7. ★★ 이 장에서는 “관찰 → 가설 → 실험 → 검증”이라는 과학적 방법을 제안합니다. 하지만 실제로 에이전트의 행동 공간은 방대하며 가설 하나를 검증하는 데 수백 번의 평가 실행이 필요할 수 있습니다. 제한된 컴퓨팅 예산으로 평가에서 얻는 정보를 어떻게 극대화할 수 있을까요?
8. ★ AndroidWorld 파일럿에서 전체 요소 트리는 성공률을 25%에서 100%로 높였지만 token 사용량을 대조군의 2.498배로 늘렸습니다. 축약 후 성공률은 100%로 유지됐고 token은 0.506배가 됐습니다. 접근성, 상태 검증, 이후 행동에 필요한 정보는 남기면서 의미 없는 UI 노드를 자동으로 제거하려면 어떤 규칙을 설계해야 할까요?
9. ★★ τ-bench의 사용자 시뮬레이션은 모든 정보를 한꺼번에 제공하지 않고 에이전트의 질문에 따라 점차 공개하는 “점진적 정보 공개”를 사용합니다. 이 설계는 평가 결과에 어떤 영향을 줄까요? 시뮬레이션 사용자의 정보 공개 전략이 실제 사용자와 크게 다르다면 평가 결론을 여전히 신뢰할 수 있을까요?