AI 에이전트의 성능 지표를 '정답'에서 '과정'으로 전환하다

ChatGPT나 코딩 에이전트가 낡은 문서를 읽고 엉뚱한 코드를 짜면, 개발자는 수정에 시간을 쓰고 에이전트는 토큰을 낭비하게 된다. 불친절한 API와 오래된 문서는 AI 에이전트에게 비용 증가와 경로 이탈이라는 실질적인 손실을 입힌다. 이에 Hugging Face는 정답 여부뿐 아니라 토큰, 시간, 턴 수 등 에이전트가 정답에 도달하기까지 들인 작업 노력(effort)을 측정하는 벤치마크 하네스를 도입했다.

기존 벤치마크는 최종 답변의 정답 여부만 확인했다. 하지만 두 에이전트가 똑같이 정답을 맞혔더라도, 한쪽은 한 번에 성공하고 다른 쪽은 수차례 시행착오를 거치며 수천 개의 토큰을 낭비했다면 실무적 효율은 완전히 다르다. 에이전트가 도구를 효과적으로 구동할 수 있도록 설계하는 '에이전트 최적화 툴링'은 코드가 정확한 것을 넘어 에이전트가 제어하기 쉬운 구조여야 함을 강조한다.

Hugging Face는 transformers 라이브러리를 케이스 스터디로 활용해 과정 중심의 벤치마크를 구현했다. 에이전트가 라이브러리를 사용하는 환경을 기본 지식만 사용하는 `bare`, 소스 코드 전체를 제공하는 `clone`, 정제된 문서를 제공하는 `skill` 티어로 나누어 모델별 비용과 성능을 대조했다. 이를 통해 에이전트가 정답에 도달하는 경로를 정량적으로 추적하고 최적의 지원 방식을 판단하는 체계를 구축했다.

Bare부터 Skill까지, 에이전트 지원 수준을 나누는 3가지 티어(Tier)

에이전트가 라이브러리를 사용하는 환경은 정보 제공 수준에 따라 세 가지 티어로 나뉜다. 첫 번째 Bare는 추가 도움 없이 모델이 이미 학습한 기본 지식만으로 라이브러리를 사용하는 단계다. 두 번째 Clone은 라이브러리의 전체 소스 트리(Source tree)를 제공하여 에이전트가 직접 코드를 읽고 분석하게 한다. 마지막 Skill은 큐레이션된 문서(Curated docs)를 제공해 정답에 빠르게 접근하도록 돕는다. 모델 특성에 따라 소스 코드를 직접 읽는 Clone 방식이 정제된 문서를 보는 Skill 방식보다 효율적인 결과가 나오기도 한다.

성능 측정은 작업 완료까지의 턴 수(Turns), 사용 토큰(Tokens), 소요 시간(Seconds), API 호출 경로를 모두 기록한다. 턴 수는 에이전트와 환경 사이의 상호작용 횟수로 응답 지연 시간과 직결되며, 사용 토큰은 API 비용과 연결된다. 모든 측정 결과는 Overview, Coverage, Results 리포트에 저장되며, 실행 경로는 Hugging Face Hub의 agent-traces viewer를 통해 명령어 단위로 추적해 에이전트의 이탈 경로를 시각적으로 확인할 수 있다.

이 기준을 적용하면 새로운 CLI(명령줄 인터페이스) 도입 시 작업 시간은 단축되었으나 이를 학습하기 위한 입력 토큰량이 늘어났다면, 이를 '발견 비용(Discovery cost)'의 증가로 판단할 수 있다. 결국 에이전트 최적화의 핵심은 에이전트가 정보를 얼마나 쉽게 찾느냐 하는 '발견 가능성(Discoverable)'에 있으며, 이를 통해 명확한 API와 구조화된 문서의 필요성을 수치로 입증할 수 있다.

대형 모델은 '효율'을, 소형 모델은 '정확도'를 본다

인프라 담당자가 모델을 선택할 때 두 모델의 정답률이 모두 100%로 동일하다면, 실제 운영 환경의 비용과 응답 속도가 변별력이 된다. 대형 오픈 모델은 대부분의 태스크에서 결국 정답에 도달하므로 정답률만으로는 성능 차이를 구분하기 어렵다. 이때는 정답에 도달하기까지의 턴 수, 총 소모 토큰, 최종 답변까지의 소요 시간을 측정해 모델의 실제 효율성을 판단해야 한다.

반면 소형 로컬 모델은 파라미터 크기에 따라 성능 편차가 크므로 정답 일치율(Match %)이 가장 중요한 지표가 된다. 모델 체급에 따라 정답률이 어느 지점에서 계단식으로 상승하는지 확인해야 해당 모델을 특정 도구의 자동화에 투입할 수 있을지 결정할 수 있다. 즉, 소형 모델은 정확도라는 기본기에, 대형 모델은 자원 낭비를 줄이는 효율성에 집중하는 서로 다른 평가 잣대를 적용해야 한다.

이러한 체급별 지표 차이를 검증하기 위해 코딩 에이전트 pi를 사용하여 다양한 모델과 라이브러리 리비전(Revision) 간의 교차 테스트를 수행했다. 특히 테스트 신뢰도를 높이기 위해 Hugging Face Jobs를 통해 모든 실행 환경의 하드웨어를 동일하게 유지했다. 이를 통해 측정된 시간과 성능 차이가 하드웨어 성능이 아닌 모델의 능력과 라이브러리 구조의 차이에서 왔음을 보장했다.

CLI와 Skill 도입 결과: 시간은 줄었지만 토큰은 늘어난 트레이드오프

`transformers` 라이브러리에 전용 CLI, Skill, 태스크별 예제 코드를 추가해 최적화를 진행했다. 에이전트가 파이썬 코드를 직접 작성하고 실행하며 발생하는 디버깅 루프를 줄이고, 미리 정의된 인터페이스를 통해 작업 경로를 단축하기 위함이다.

대형 모델 3종을 대상으로 테스트한 결과, Skill 커밋 이후 모든 태스크에서 평균 작업 시간(Median time)이 감소했다. 에이전트가 복잡한 API 호출 구조를 분석하며 시행착오를 겪는 대신, 최적화된 인터페이스를 사용하여 정답에 도달하는 경로가 짧아졌기 때문이다.

반면 토큰 소모량에서는 비용 증가가 나타났다. 라이브러리 전체 소스 트리를 제공하는 Clone 티어에서 CLI 구현체와 예제 스크립트를 읽는 과정 때문에 입력 토큰이 약 4k에서 6.4k로 늘어났다. 실제 실행 경로를 추적하니 에이전트 작업의 약 3분의 1이 `/cli/` 트리와 `cli/agentic/*.py` 예제 파일을 읽으며 인터페이스 사용법을 익히는 데 할당되었다.

결과적으로 에이전트는 파이썬 디버깅 시간을 줄이는 대신 CLI 사용법을 학습하는 토큰 비용을 지불하는 트레이드오프를 보였다. 다만 이는 일회성 실험 환경의 결과이며, 실제 사용 환경에서는 학습 비용이 여러 번의 작업에 걸쳐 분산되어 상쇄될 가능성이 높다.

한국 AI 실무자를 위한 시사점: SDK 설계의 새로운 기준

이제 SDK 설계자는 사람 개발자뿐 아니라 AI 에이전트라는 새로운 사용자를 고려해야 한다. 에이전트가 유용한 파일과 예제에 빠르게 접근할 수 있도록 경로를 설계하는 것이 곧 성능 향상으로 이어진다. 특히 `cli/agentic/*.py`와 같이 에이전트가 읽기 좋은 예제 코드를 저장소에 직접 포함하면, 에이전트가 방대한 소스 트리를 훑는 대신 정제된 예제에서 사용법을 빠르게 학습해 시행착오를 줄일 수 있다.

단일 실행 환경에서 CLI 구현체와 예제 코드를 읽을 때 입력 토큰이 증가하더라도, 이 비용을 통해 파이썬 코드를 직접 디버깅하며 허비하는 시간이 사라지면 전체 작업 시간은 단축된다. 실제 환경에서는 한 번 학습한 인터페이스를 연속 작업에 활용하므로 초기 발견 비용이 분산(Amortized)되어 전체 효율이 높아진다. 따라서 토큰 소모량의 일시적 증가보다 작업 시간의 절대적 단축이 주는 실익을 우선 판단 기준으로 삼아야 한다.

또한 에이전트의 토큰 소모량과 수행 시간을 측정하는 프로세스를 CI/CD(지속적 통합 및 배포)에 도입해야 한다. 정답 여부만 확인하는 기존 방식으로는 라이브러리 변경이 에이전트의 작업 효율을 실제로 높였는지 알 수 없다. 작업 완료까지의 턴 수와 소요 시간을 지표로 관리함으로써, 업데이트가 에이전트의 작업 노력(Effort)을 줄였는지 확인하고 PR(풀 리퀘스트) 병합 여부를 결정하는 기준으로 활용해야 한다.

에이전트가 정답을 맞혔는가보다 정답에 도달하기까지 얼마나 많은 자원을 썼는가가 더 중요한 지표가 된다. 이제 사내 SDK나 라이브러리를 배포할 때 단순한 성공률이 아니라 시간 단축과 토큰 비용의 상관관계를 먼저 따져봐야 한다.

공개된 벤치마크 하네스를 활용해 bare, clone, skill 각 단계에서 모델이 소모하는 작업 노력을 정량적으로 측정해 보자. 정답률이 동일한 조건이라면 작업 시간이 가장 짧은 구조를 선택하는 것이 실무적으로 가장 효율적인 라이브러리 설계 방식이다.