Hugging Face가 공개한 "Is it agentic enough?"는 에이전트 시대의 라이브러리 품질을 꽤 현실적인 방식으로 묻는다. 모델이 최종 답을 맞혔는지만 보지 말고, 그 답까지 가는 동안 얼마나 많은 토큰과 시간을 썼는지, 어떤 명령을 실행했는지, 실패했을 때 어디로 돌아갔는지를 보자는 글이다. 사례는 transformers다.
글의 핵심 예시는 감성분석 태스크다. 두 에이전트가 모두 POSITIVE라는 같은 결과를 낼 수 있다. 하지만 한쪽은 AutoTokenizer와 AutoModelForSequenceClassification을 불러와 40줄 가까운 Python 코드를 쓰고, torch softmax까지 거쳐 답을 출력한다. 다른 쪽은 transformers classify --model ... --text ... 한 줄로 끝낸다. 결과 문자열만 보면 둘 다 성공이지만, 실제 운영 관점에서는 전혀 같은 성공이 아니다.
벤치마크 설계도 흥미롭다. Hugging Face 팀은 에이전트가 transformers를 만나는 조건을 bare, clone, skill 세 가지로 나눴다. bare는 pip install transformers 외에는 별다른 도움을 주지 않는 조건이고, clone은 전체 소스 트리를 작업 디렉터리에 둔다. skill은 CLI 문서와 태스크별 예제를 패키징해 컨텍스트로 제공한다. 여기서 skill이 항상 clone보다 낫다고 전제하지 않는 점이 좋다. 어떤 모델은 정리된 문서보다 소스 자체를 뒤지는 편이 더 잘 작동할 수 있다.
측정 항목은 단순 정답률을 넘어선다. match %, median time, 새 토큰과 캐시 토큰과 생성 토큰, error %, 아무 출력도 하지 않은 silent failure, 그리고 도구가 정의한 marker adoption까지 본다. 특히 trace를 남겨 명령 단위로 에이전트의 행동을 확인할 수 있게 한 부분이 중요하다. 숫자만으로는 왜 비용이 늘었는지, 왜 특정 revision에서 모델이 우회했는지 설명하기 어렵기 때문이다.
이 글의 메시지는 플러그인을 하나 더 붙이는 이야기가 아니다. 에이전트가 쓰기 좋은 소프트웨어는 CLI가 있고, 문서가 발견 가능하며, 예제가 작업 단위로 정리돼 있고, 에러가 다음 행동을 좁혀 주는 소프트웨어에 가깝다. 사람을 위한 DX가 읽기 좋은 API와 문서에서 출발했다면, 에이전트를 위한 DX는 시행착오 비용까지 포함한다.
물론 범위는 아직 제한적이다. 글은 deterministic task, 즉 기대 답을 명확히 검증할 수 있는 작업에 초점을 둔다. 생성형 작업이나 품질 판단이 필요한 작업은 model-as-a-judge 같은 다음 단계가 필요하다. 그래도 방향은 분명하다. 앞으로 라이브러리 유지보수자는 "사람이 이해하기 쉬운가"뿐 아니라 "에이전트가 덜 헤매는가"를 테스트해야 할 가능성이 크다.