벤치마크는 에이전트 하나가 작업 하나를 해냈는지까지만 말해줘
회사에서 에이전트를 굴리는 일은 사업 부서와 애플리케이션 팀, 테스트, 플랫폼 엔지니어링, 인프라, 보안, 운영, 데이터 거버넌스가 한꺼번에 맞물리는 조정 문제야. 8월 27일 arXiv에 올라온 원고는 여기서 지금 쓰는 벤치마크가 못 답하는 지점을 짚어. 능력과 모델, 런타임 장치, 용량, 사내 데이터가 바뀔 때 누가 소유하고 어떻게 승인하고 무엇으로 증명하는지는 점수로 안 나오거든.
책임을 세 계약으로 자르고 데이터는 밖으로 뺐어
- Skill: 재사용할 수 있고 버전이 매겨진 능력·워크플로 자산이야. 에이전트 스킬이라는 말과 겹쳐 보이지만, 여기선 제품 기능이 아니라 소유 단위를 뜻해.
- Harness: 런타임 컴파일러이자 관리자야. 무엇을 켜고 어떤 통제를 걸지 여기서 정해.
- Scaffold: 실행과 통제의 경계이고, 성능·보안 같은 비기능 요구사항의 주인이야.
- 데이터 기반: 이 셋 밖에 둬. CIO가 따로 관리하는 의미 체계와 계측 아래에 둔다고 적혀 있어.
검증하겠다는 가설은 딱 하나야
원고가 세운 중심 주장은 P1 하나야. 정해진 운영 구간 안에서 켜는 능력을 바꿔도 용량과 응답의 관계가 미리 정한 동등성 범위 안에 남고, 호환되는 Scaffold 용량을 바꿔도 능력의 의미가 열등하지 않은 범위에 남으며, 그때 필요한 통제 비용이 선언한 예산을 안 넘는다는 거야.
이걸 재려고 클러스터 기간 무작위 교차 설계를 제안해. 판정은 지지, 반증, 조건부 엔지니어링, 판단 불가 네 가지로 갈려. 여섯 개 설계 조건이 측정 의무가 되고, 그게 안 채워지면 P1은 판정 자체가 안 돼.
저자들이 마지막 문장에 결과가 없다고 적어 뒀어
48페이지짜리 원고인데 초록 마지막 줄은 완료된 구현도, 실험도, 데이터셋도, 측정 결과도 없다고 밝혀. 정확도나 지연시간, 비용 수치가 한 개도 안 나온다는 뜻이야. 숨긴 게 아니라 저자들이 직접 적어 뒀어.
이 원고를 어디에 쓰면 되나
에이전트 플랫폼을 고르는 중이라면 이건 비교표에 넣을 자료가 아니야. 대신 벤더 자료를 받았을 때 던질 질문지로는 써볼 만해. 능력을 바꿀 때 용량 계획을 다시 짜야 하는지, 그 통제 비용을 누가 대는지, 무엇을 증거로 남기는지를 물어보면 돼. 다만 이 글의 근거는 arXiv 원고 한 편이 전부야. 공개된 코드 저장소도, 공식 프로젝트 페이지도, 이 원고를 다룬 다른 출처도 찾지 못했어.