Unreal Labs, 툴 호출 비동기화한 에이전트 하네스 'Unreal Agent' 공개

Unreal Labs가 AI 에이전트용 실행 하네스 'Unreal Agent'를 공개했다. 핵심은 툴 호출을 완전한 비동기 방식으로 관리해, 기반 모델이 툴의 대기·폴링·하트비트를 직접 신경 쓰지 않도록 만든 것이다. 에이전트가 툴을 다루느라 쏟는 시간과 토큰을 줄이는 것이 설계 목표였다.

동작 방식은 이렇다. 에이전트가 툴 호출을 내보내면 곧바로 세션 로그에 해당 툴이 '진행 중(in-progress)' 상태로 돌아왔다는 이벤트 레코드를 덧붙이고, 실제 실행은 백그라운드에서 계속된다. 툴이 실제로 끝나면 그 결과를 세션 로그에 추가한 뒤 LLM을 호출한다. 이 흐름을 프롬프트 캐시를 깨뜨리지 않으면서 구현하는 것 자체가 만만치 않은 엔지니어링 과제였다고 팀은 설명한다.

성과는 수치로 제시됐다. 실무 워크로드와 에이전트 벤치마크에서 Codex와 비교해 최대 40%, Pi와 비교해 최대 20%의 비용 절감을 달성했다는 것이다. GPT-6 Astra xhigh로 테스트했으며, 통과율에서는 큰 차이가 나지 않았는데 이는 벤치마크 분산 때문으로 해석한다. 비교에 쓰인 Codex(lb)는 리더보드 베이스라인이고, Unreal Agent와 Pi 실행 결과는 별도로 공개됐으며 이 실행들은 Harbor 기반이 아니다.

비용 절감의 근거로 두 가지를 든다. 첫째는 하네스 자체의 최소화다. 프롬프트를 단순하게 유지하고 툴 결과를 토큰에 맞게 다듬었으며, 서브에이전트나 별도 워크플로를 두지 않았다. 둘째는 모델 턴당 더 많은 툴 작업을 몰아넣는 것이다. 비동기 툴 호출 모델을 LLM이 이해할 수 있게 명확히 설명해 두었기 때문에, 폴링이나 대기에 토큰을 낭비하지 않고 한 턴에 무거운 툴 호출을 여러 개 던질 수 있다.

이런 설계는 기존 SDK에 대한 문제의식에서 나왔다. Claude의 Agent SDK처럼 CLI 지향으로 만들어진 SDK는 로컬 세션, 서브프로세스, 자원 한계에 대한 전제를 깔고 있어 프로덕션 환경에 그대로 옮기기 어렵다. 완료·취소·백그라운드 작업을 안정적으로 처리하려면 결국 자체 라이프사이클 관리를 덧씌워야 한다. 다른 프로바이더를 지원하는 작업도 부담이다. API 모드를 바꾸면 툴이나 컴팩션이 깨질 수 있고, SDK 업그레이드가 메시지 포맷을 바꾸면서 통합 코드를 다시 짜야 하는 상황이 생긴다. 의존성 트리가 무거우면 이미 직접 이해하고 패치해야 하는 런타임에 유지보수와 공급망 리스크가 더해진다.

보안과 승인 처리에 대해서도 다른 접근을 택했다. 하네스 훅이나 특수 툴에 기대는 방식은 유지보수 부담이 크고 견고하지 않다고 본다. 대신 허용·차단 호스트 목록, 세분화된 액세스 토큰, 승인 게이트를 둔 프록시처럼 하네스 바깥의 결정적 환경·샌드박스 제약으로 통제하는 편이 낫다는 입장이다.

개발자 입장에서 가장 체감이 큰 변화는 사용자 개입 방식이다. 툴 호출이 끝나기를 기다리지 않고도 사용자가 언제든 에이전트에 방향을 제시할 수 있고, 이기종 툴 호출을 모델에 추가 인지 부담 없이 병행시킬 수 있다. 예컨대 몇 분 걸리는 개발 환경 셋업을 띄워 놓은 채로 코드베이스 탐색과 웹 검색을 동시에 돌리는 식이다. 현재 SDK는 코드베이스에 직접 통합하는 Go 라이브러리, claude -p나 codex exec에 대응하는 러너 실행 파일, Harbor와 호환되는 벤치마크 러너를 제공한다.

전제와 한계도 분명히 밝혀 두었다. 벤치마크는 Harbor에서 재현과 검증이 쉬워 대부분 코딩 중심으로 돌렸지만, 하네스 자체는 특정 도메인에 묶여 있지 않다. 또한 하나의 컨텍스트에 툴 호출 결과 항목을 두 개(진행 중, 최종) 넣는 패턴은 Responses API 문서에 명확히 규정되어 있지 않다. 테스트 과정에서 일부 추론 프로바이더(OpenAI는 아님)의 일부 모델이 이를 거부했고, function_call_output의 status 필드가 아무 영향을 주지 않는 경우도 있었다. 대화 포맷이 받아들여지기만 하면 모델이 진행 중 업데이트에서 최종 결과로 이어지는 흐름을 이해한다는 것이 팀의 관찰이며, 이 패턴이 Responses API에서 명시적으로 지원되고 추론 프로바이더 전반에서 일관되게 동작하기를 바란다고 덧붙였다. 하네스 설계 자체가 독립적인 연구 영역이라는 관점도 밝히며, 관련 연구로 HarnessTax(2026)를 인용했다.