저는 백서(whitepaper)를 통해 이 의견을 얻은 것이 아닙니다.

이 문제를 중심으로 오픈 소스(open-source) 프로젝트를 구축하는 과정에서, 빌드(build) 과정이 계속해서 반론을 제기했기 때문에 이 결론에 도달했습니다.

저는 현재 에이전트를 위한 오픈 소스(OSS) 평가 실험실인 AgentEval Forge를 작업하고 있습니다. 원래 아이디어는 꽤 간단해 보였습니다. 시나리오 팩(scenario packs), 적대적 사례(adversarial cases), 궤적 점수 산정(trajectory scoring), 회귀 추적(regression tracking), 비용 및 지연 시간(latency) 분석 같은 것들이었죠. 제 머릿속에서는 제가 이미 다른 곳에서 수행했던 평가 작업보다 더 진지하고 더 구조화된 버전이 될 것이라고 생각했습니다.

그것이 첫 번째 실수였습니다.

저는 이미 모델 평가(model-eval) 및 워크로드 평가(workload-eval) 스타일의 시스템을 구축하는 데 시간을 보낸 적이 있습니다. 실제 작업을 위해 모델을 비교하는 것이 무엇을 의미하는지, 루브릭(rubric)을 어떻게 설계하는지, 속도 대 비용을 어떻게 생각해야 하는지, 그리고 테스트 환경(harness)이 취약할 때 깔끔한 점수가 얼마나 빨리 오해를 불러일으킬 수 있는지 알고 있었습니다. 저는 에이전트 평가가 그 세계의 연장선일 것이라고 가정했습니다.

AgentEval Forge에 깊이 파고들수록, 그 가정이 사실이 아니라는 느낌이 강해졌습니다.

모델 평가는 답변이 좋은지를 묻습니다.

에이전트 평가는 시스템이 신뢰할 수 있을 만큼 충분히 잘 행동했는지를 물어야 합니다.

이 둘은 같은 질문이 아닙니다.

깨달음을 준 비교

깔끔한 모델 평가(model-eval) 설정은 제가 논리적으로 추론할 수 있는 영역입니다. 입력(input)이 있고, 출력(output)이 있으며, 품질을 점수화하는 어떤 방법이 있습니다. 때로는 정확한 일치(exact match)일 수도 있고, 때로는 루브릭(rubric)일 수도 있습니다. 때로는 LLM 판사(LLM judge)일 수도 있고, 때로는 벤치마크 테스트 환경(benchmark harness)일 수도 있습니다. 설정이 아무리 화려해지더라도 무게 중심은 여전히 꽤 안정적입니다. 즉, '모델이 이 작업에 대해 좋은 답변을 생성했는가?'입니다.

그것만으로도 이미 충분히 어렵습니다. 저는 모델 평가조차 과학적으로 보이는 방식으로 잘못될 수 있다는 것을 알 만큼, 취약한 점수 산정 방식과 잘못된 확신을 충분히 목격해 왔습니다. 루브릭은 잘못된 것에 보상을 줄 수 있습니다. 이진 체크(binary check)는 분명히 유용한 것을 놓칠 수 있습니다. 벤치마크는 객관적으로 느껴지면서도 여전히 당신을 잘못된 최적화 목표로 끌어들일 수 있습니다. 따라서 저는 모델 평가가 해결되었다고 주장하는 것이 아닙니다.

하지만 에이전트의 경우, 문제의 형태 자체가 변합니다.

평가 대상이 더 이상 단순한 답변이 아닙니다. 그것은 워크플로 (workflow)입니다. 일련의 결정 과정입니다. 도구 선택 (tool choice), 재시도 (retries), 중간 상태 (intermediate state), 비용 (cost), 복구 동작 (recovery behavior), 그리고 때로는 정책 준수 (policy adherence)입니다. 시스템이 단 한 번의 응답 이상을 수행하도록 허용하는 순간, 최종 출력물은 전체 이야기를 대변하지 못하게 됩니다.

이를 솔직하게 말하면 당연하게 들릴 것입니다. 하지만 실제로 많은 팀이 이미 그 범주를 넘어선 시스템에 대해 여전히 답변 점수 산정 (answer-scoring) 습관을 사용하고 있다고 생각합니다.

AgentEval Forge를 구축하며 제가 경험한 변화

진정한 변화는 AgentEval Forge가 실제로 무엇을 점수화해야 하는지 정의하려고 시도했을 때 일어났습니다.

처음에는 답이 간단할 것이라고 생각했습니다. 시나리오 팩 (scenario packs)을 실행하고, 출력을 점수화하고, 버전을 비교하면 끝이라고 말이죠.

하지만 실제 에이전트의 동작을 더 자세히 들여다볼수록, 그것이 얼마나 순진한 생각이었는지 느껴지기 시작했습니다. 에이전트는 도달하는 과정에서 많은 일을 잘못 수행하면서도 괜찮은 최종 답변을 만들어낼 수 있습니다. 처음에 잘못된 도구를 선택했다가 운 좋게 복구할 수도 있습니다. 필요 이상으로 루프 (loop)를 돌 수도 있습니다. 더 나은 경로를 사용했을 때보다 5배나 많은 토큰 (tokens)을 소비할 수도 있습니다. 인간 검토자라면 절대 승인하지 않을 위험한 단계를 밟은 뒤, 결과적으로는 수용 가능한 것처럼 보이는 무언가로 되돌아올 수도 있습니다.

만약 제가 최종 답변에만 점수를 매긴다면, 저는 그 실행을 성공으로 표시할지도 모릅니다.

그것이 함정입니다.

경로가 중요합니다.

이것은 제가 이것을 구축하는 동안 계속해서 되새기는 문장입니다. 경로는 종착점만큼이나 중요하며, 때로는 그보다 더 중요합니다. 왜냐하면 경로야말로 비용 (cost), 안전성 (safety), 그리고 신뢰 (trust)가 실제로 존재하는 곳이기 때문입니다.

그러한 도전 과제는 매우 실질적인 방식으로 나타납니다. 저는 단순히 에이전트가 정답을 맞혔는지 점수를 매기려는 것이 아닙니다. 저는 에이전트가 처음에 잘못된 도구 (tool)를 선택했거나, 뒤늦게 복구했기 때문에 겨우 과업을 완수했거나, 넘지 말아야 할 경계를 넘었거나, 단순한 작업에 너무 많은 단계 (steps)를 소비했거나, 혹은 평균 점수는 여전히 괜찮아 보임에도 불구하고 특정 좁은 시나리오 군 (scenario family) 내에서만 퇴보한 경우들을 고민하고 있습니다. 이것이 바로 에이전트 평가를 정답 채점보다는 시스템 작업 (systems work)에 훨씬 더 가깝게 느껴지게 만드는 혼란스러운 지점입니다.

이전 작업에서 이미 이러한 징후들을 보았습니다

이것이 제가 이 문제의 경계를 느낀 첫 번째 사례는 아니었습니다.

이전의 하네스 (harness) 및 현장 연구 (field-study) 작업, 특히 장난감 예제 (toy examples) 대신 실제 워크로드 (workloads)를 대상으로 시스템을 실행할 때, 저는 깔끔한 프롬프트 평가 (prompt-eval) 설정에서는 절대 나타나지 않았을 실패 사례들을 계속해서 발견했습니다. 그 경험은 제가 데모 경로 (demo-path)의 자신감에 대해 훨씬 덜 감명받게 만들었습니다.

시스템은 통제된 평가 (controlled evaluation)에서는 강력해 보일 수 있지만, 환경이 불규칙해지는 즉시 변덕스럽게 변할 수 있습니다. 실제 저장소 (repos). 실제 로그 (logs). 실제 커밋 히스토리 (commit histories). 실제 명명 규칙의 혼란 (naming mess). 실제 모호함 (ambiguity).

그곳이 바로 엣지 케이스 (edge cases)가 나타나는 곳입니다. 그곳이 바로 도구 오용 (tool misuse)이 나타나는 곳입니다. 그곳이 바로 "기술적으로는 정답"인 것과 "배포하기에 안전한" 것이 서로 멀어지기 시작하는 곳입니다.

저는 이러한 경험이 AgentEval Forge가 제 머릿속에서 지금과 같은 형태를 갖추게 된 이유 중 일부라고 생각합니다. 저는 리더보드 생성기 (leaderboard generator)를 만들려고 했던 것이 아닙니다. 저는 에이전트를 위한 출시 규율 (release discipline)에 더 가까운 무언가를 만들려고 노력하고 있었습니다.

둘째, 궤적 품질 (trajectory quality)이 필요합니다. 어떻게 그 결과에 도달했나요? 의사결정의 시퀀스 (sequence of decisions)가 합리적이고, 효율적이며, 안정적이었나요? 아니면 실제 운영 환경 (production)에서 결코 반복되기를 원치 않을 방식으로 성공한 것인가요?

셋째, 도구 동작 (tool behavior)을 평가해야 합니다. 올바른 도구를 선택했나요? 도구를 과도하게 사용했나요? 불필요하게 비용이 많이 들거나 위험한 행동을 취했나요? 혹은 우연한 회복 (accidental recovery)에 의존했나요?

넷째, 안전성 (safety) 및 정책 준수 (policy adherence)가 필요합니다. 안전하지 않은 경로를 통해 도달한 성공적인 출력은 깨끗한 승리로 간주해서는 안 됩니다.

다섯째, 비용 (cost), 지연 시간 (latency), 그리고 회귀 (regressions)를 고려해야 합니다. 새로운 버전이 더 느려졌나요? 더 비싸졌나요? 더 불안정해졌나요? 운영 동작을 악화시키면서 정확도만 개선했나요? 아니면 단순히 스타일만 바뀌었는데도 발전을 했다며 축하받고 있지는 않나요?

마지막 항목은 저에게 매우 중요한데, 왜냐하면 팀들이 가장 쉽게 스스로를 속이는 지점이 바로 여기라고 생각하기 때문입니다. 그들은 차이점 (difference)을 보고 개선 (improvement)이라고 부릅니다. 이 둘은 같은 것이 아닙니다.

현재의 평가 (eval) 생태계가 충분하지 않다고 생각하는 이유

저는 현재의 평가 생태계가 쓸모없다고 주장하는 것이 아닙니다. 결코 그렇지 않습니다.

평가 주도 개발 (evaluation-driven development)에 관한 LangChain의 글은 핵심적인 부분을 정확히 짚고 있습니다. 일단 운영 환경에서 실패를 목격하면, 그 실패 사례들은 오프라인 평가 (offline evals)에 반영되어야 하며, 모든 변경 사항은 그 사례들을 바탕으로 테스트되어야 합니다. 이러한 루프 (loop)는 건강합니다. 이것이 바로 제가 더 많은 팀이 채택하기를 바라는 규율 (discipline)입니다.

그리고 다른 관점에서, 에이전트 기반 코딩 (agentic coding)에 관한 Birgitta Böckeler의 글은 제가 중요하다고 생각하는 또 다른 측면을 포착합니다. 가장 위험한 실패는 종종 더 긴 피드백 루프 (feedback loops) 속에 존재합니다. 유지보수성 (maintainability). 팀 내 마찰 (team friction). 무차별적인 수정 (brute-force fixes). 오진 (misdiagnosis). 과하게 설계된 솔루션 (overbuilt solutions). 이러한 비용은 즉각적인 출력물에는 항상 나타나지 않지만, 나중에는 반드시 나타납니다.

그렇기 때문에 저는 기존 도구들이 나쁘다는 것이 문제가 아니라고 생각합니다. 문제는 우리의 많은 평가 습관이 '프롬프트와 답변 (prompt-and-answer)'의 세계에서 형성되었다는 점입니다. 에이전트 시스템은 훨씬 더 복잡합니다. 이들은 고립된 텍스트 생성 (text generation)이라기보다 오케스트레이션된 소프트웨어 (orchestrated software)처럼 동작합니다. 일단 그 점을 받아들이고 나면, 여러분의 평가 시스템 또한 성숙해져야 합니다.

평가조차 여러분을 속일 수 있습니다

이 부분은 제가 지나치게 깔끔하게 정리하고 싶지 않은 대목입니다.

여러분의 평가 설정은 매우 엄격해 보임에도 불구하고 잘못될 수 있습니다.

저는 모델 평가 (model-eval) 및 하네스 (harness) 작업에서 이미 그런 사례를 충분히 보았기에, 실제보다 더 확신에 차 있는 것처럼 들리는 그 어떤 시스템도 경계하게 되었습니다. 유용한 동작을 과소 집계할 수도 있습니다. 이진 체크 (binary checks)를 너무 취약하게 만들 수도 있습니다. 실제로 중요한 것이 아니라 점수를 매기기 쉬운 것에 최적화할 수도 있습니다.

따라서 이제 과제는 두 가지 층위로 나뉩니다. 에이전트는 평가하기 어렵고, 평가 시스템 그 자체 또한 신중하게 설계하고, 정직하게 보정하며, 약간은 불신해야 하는 또 다른 시스템이 됩니다.

그것이 진지한 평가를 피해야 할 이유는 아닙니다. 오히려 그 반대입니다. 이는 평가를 단순한 보고 (reporting)가 아니라, 제품 및 엔지니어링 작업처럼 다루어야 함을 의미합니다.

그럼에도 제가 이것을 구축하는 것에 대해 낙관적인 이유

이 모든 상황에도 불구하고, 저는 이 문제에 대해 냉소적으로 느끼지 않습니다.

오히려 AgentEval Forge를 구축하면서 이것을 제대로 해낼 가치가 있다는 확신이 더 강해졌습니다. 저는 시나리오 팩 (scenario packs)을 원합니다. 적대적 사례 (adversarial cases)를 원합니다. 궤적 점수 매기기 (trajectory scoring)를 원합니다. 어떤 변화가 시스템을 더 유용하게 만들었는지, 그리고 어떤 변화가 단지 데모에서만 더 깔끔해 보이게 만들었는지를 알려줄 수 있는 회귀 추적 (regression tracking)을 원합니다.

저는 단순히 연구 질문 (research question)에 답하는 것이 아니라, 출시 질문 (release question)에 답하는 데 도움이 되는 평가 시스템을 원합니다.

이 버전이 더 좋아졌는가?

어떻게 더 좋아졌는가?

어떤 대가를 치렀는가?

그리고 헤드라인 점수(headline score)가 올라갔음에도 불구하고 무엇이 더 위험해졌는가?

이것이 바로 제가 툴링 (tooling)을 통해 도움을 받고 싶은 질문의 종류입니다.

팀들이 곧 배우게 될 더 큰 사실

저는 많은 팀이 AI 보조 코딩 (AI-assisted coding) 분야에서 많은 팀이 했던 방식과 똑같이, 에이전트 평가 (agent evaluation)에서도 이전 문제의 습관을 빌려와 그것이 확장 가능하기를 바라고 있다고 의심합니다.

때로는 그 방식이 통하기도 합니다.

하지만 대개는 그렇지 않습니다.

그러면 나중에 회귀 (regressions), 이상한 프로덕션 동작, 비용이 많이 드는 경로, 안전하지 않은 툴 사용 (tool use), 또는 시스템이 실제로 개선되었는지 여부를 결코 말할 수 없는 채로 계속해서 시스템을 변경하기만 하는 팀의 모습으로 청구서가 날아옵니다.

이것이 제가 이 주제를 위한 오픈 소스 (OSS)를 구축하는 도중에 이 글을 쓸 가치가 있다고 느끼는 이유입니다. 구축 과정 자체가 저에게 논거를 더 날카롭게 만들어주고 있습니다. 모든 설계 결정은 저를 동일한 결론으로 몰아가고 있습니다: 모델 평가 (model evaluation)가 정답이 좋은지를 묻는 것이라면, 에이전트 평가 (agent evaluation)는 시스템이 신뢰할 수 있을 만큼 충분히 잘 작동했는지를 물어야 합니다.

그것은 더 어려운 문제입니다. 저는 이것이 진지한 에이전트 작업의 결정적인 엔지니어링 문제 중 하나가 될 것이라고 생각합니다.

OSS가 공개되면 이에 대해 더 자세히 쓰겠습니다. 이러한 도전 과제 중 일부는 이미 AgentEval Forge에서 구체적인 설계 결정으로 바뀌고 있으며, 앞으로 몇 주 안에 저희가 어떤 부분을 깔끔하게 해결했는지, 어떤 부분이 여전히 복잡하게 남아 있는지, 그리고 코드가 아이디어가 아닌 실제 시스템으로서 작동해야 할 때 트레이드오프 (tradeoffs)가 어떻게 변했는지를 공유하고 싶습니다. 준비가 되면 GitHub 리포지토리 (repo)를 공개적으로 공유하겠습니다.

토론을 위하여

이것은 여전히 저에게 활발히 구축 중인 작업이자 활발히 진행 중인 사고의 흐름이므로, 진심으로 반론을 환영합니다.

• 에이전트 작업에서 정답 점수 매기기 (answer scoring)가 충분하지 않게 된 지점은 어디인가요?
• 현재 경로 (path)를 평가하고 계신가요, 아니면 여전히 주로 최종 출력물 (final output)을 평가하고 계신가요?
• 점수를 잘 매기기 가장 어려웠던 것은 무엇인가요: 툴 사용 (tool use), 회귀 (regressions), 안전성 (safety), 비용 (cost), 아니면 다른 무엇인가요?
• 그리고 가장 중요한 질문: 우리는 출시 신뢰도 (release confidence)를 높이는 평가 시스템을 구축하고 있나요, 아니면 그저 엄격함을 느끼기 위한 더 나은 방법을 만들고 있나요?