AI 에이전트를 실제 서비스에 올려본 팀이라면 한 번쯤 마주치는 문제가 있다. 모델 자체의 추론 능력보다, 그 모델을 감싸는 '하네스(harness)'가 비용과 응답 속도를 좌우한다는 사실이다. Unreal Labs가 공개한 Unreal Agent는 바로 이 지점을 파고든 에이전트 하네스로, 실제 프로덕션 워크로드와 코딩·과학 벤치마크에서 코덱스(Codex) 대비 최대 40%, Pi 대비 최대 20%의 비용 절감을 성능 저하 없이 달성했다고 주장한다.
문제는 모델이 아니라 툴 호출 관리였다
Unreal Labs가 지목한 핵심 낭비는 '툴 호출을 관리하는 데 드는 토큰'이다. 에이전트는 외부 도구를 호출한 뒤 그 작업이 끝나기를 기다리고, 상태를 폴링(poll)하고, 하트비트를 확인하는 데 상당한 시간과 토큰을 쓴다. 모델 입장에서 이 대기 관리는 실질적인 작업이 아니면서도 매 턴마다 컨텍스트를 갉아먹는 비용이다. Unreal Agent는 이 툴 호출을 완전히 비동기(asynchronous) 방식으로 처리해, 모델이 대기·폴링·하트비트를 직접 신경 쓰지 않도록 설계했다.
동작 방식은 이렇다. 에이전트가 툴을 호출하면 하네스는 즉시 '진행 중(in-progress)' 상태로 반환됐다는 이벤트 로그를 기록하고, 실제 실행은 백그라운드에서 계속한다. 툴이 진짜로 끝나면 그 결과를 세션 로그에 덧붙이고 그때 LLM을 호출한다. 이렇게 하면 두 가지 이점이 생긴다. 첫째, 사용자는 진행 중인 툴 호출이 끝날 때까지 기다리지 않고도 언제든 에이전트에 방향을 지시(steering)할 수 있다. 둘째, 에이전트는 모델 호출 사이사이에 더 많은 유의미한 툴 작업을 예약할 수 있어, 폴링이나 대기에 토큰을 낭비하지 않고 한 번의 모델 턴에 무거운 작업을 여러 개 굴릴 수 있다. 예컨대 몇 분씩 걸리는 개발 환경 세팅을 걸어두고, 동시에 코드베이스를 탐색하고 웹을 검색하는 식의 이질적인 작업을 추가 토큰 부담 없이 병렬로 진행할 수 있다.
기존 SDK에 대한 불만에서 출발했다
Unreal Labs가 자체 하네스를 만든 배경에는 상용 에이전트 SDK들에 대한 실전 경험이 깔려 있다. 이들은 클로드의 Agent SDK처럼 CLI 지향적인 SDK가 로컬 세션, 서브프로세스, 리소스 제한 같은 가정을 담고 있어 프로덕션 환경으로 그대로 옮기기 어렵다고 지적한다. 완료·취소·백그라운드 작업을 안정적으로 다루려면 결국 자체 생명주기 관리를 얹어야 한다는 것이다. 여러 공급자를 지원하려면 호환성 작업도 늘어난다. API 모드를 바꾸면 툴이나 컴팩션이 깨지고, SDK 업그레이드가 메시지 포맷을 바꿔 통합 코드를 다시 짜게 만들기도 한다. 무거운 의존성 트리는 직접 이해하고 패치해야 하는 런타임에 유지보수 부담과 공급망 리스크를 더한다.
보안과 승인 처리에 대한 관점도 눈여겨볼 만하다. Unreal Labs는 하네스 훅(hook)과 전용 툴에 의존하는 방식보다, 하네스 바깥의 결정론적 환경·샌드박스 제약이 더 견고하다고 본다. 허용/차단 호스트 목록, 세분화된 액세스 토큰, 승인 게이트를 둔 프록시처럼 하네스와 무관하게 작동하는 제약이 유지보수도 덜 들고 더 안정적이라는 것이다. 에이전트의 권한 통제를 어디에 둘 것인가라는 질문에 대해, 모델의 행동 규칙보다 인프라 수준의 경계를 신뢰한다는 설계 철학이 읽힌다.
절감의 근거와 남은 물음
비용 절감은 크게 두 축에서 나온다. 하나는 최소한의 하네스 풋프린트다. Unreal Agent는 단순한 프롬프트, 토큰 최적화된 툴 결과를 쓰며, 서브 에이전트나 워크플로를 두지 않는다. 다른 하나는 앞서 설명한 비동기 툴 호출 모델로, 모델 턴당 더 많은 툴 작업을 처리하면서 대기 토큰을 없앤 것이다. 결과적으로 같은 성과를 더 적은 모델 턴과 더 적은 입력 토큰으로 달성한다는 설명이다. 벤치마크는 GPT-6 Astra의 xhigh 설정으로 코덱스, Pi와 비교해 수행했고, 통과율(pass rate)에서는 미세한 차이만 있었는데 이는 벤치마크 편차로 돌렸다. 재현과 검증이 쉬운 Harbor에 코딩 벤치마크가 올라와 있어 주로 코딩 과제로 측정했지만, 하네스 자체는 도메인에 종속되지 않는다고 덧붙였다.
다만 실무자가 함께 짚어야 할 한계도 있다. Unreal Labs 스스로 밝힌 대로, 하나의 컨텍스트에 '진행 중'과 '최종'이라는 두 개의 툴 호출 결과 항목을 넣는 패턴은 Responses API 문서상 명확히 규정돼 있지 않다. 실제 테스트에서 OpenAI가 아닌 일부 추론 공급자·모델 조합에서는 거부가 발생했고, function_call_output의 상태 필드가 아무 영향을 주지 못하는 경우도 있었다고 한다. 캐시를 깨뜨리지 않으면서 이 구조를 구현하는 것 자체가 별도의 엔지니어링 난제였다는 언급도 있다. 요컨대 이 접근의 이점은 특정 API 동작에 대한 가정 위에 서 있고, 공급자 간 지원이 일관되지 않으면 재현이 흔들릴 수 있다는 뜻이다. 40%라는 숫자를 그대로 자사 워크로드에 대입하기보다, 자신이 쓰는 모델과 추론 공급자에서 이 비동기 패턴이 받아들여지는지부터 확인하는 편이 현실적이다.
Unreal Agent가 던지는 더 큰 메시지는 하네스 설계가 그 자체로 하나의 연구 영역이라는 관점이다. 모델 성능이 상향 평준화될수록, 같은 모델을 얼마나 적은 토큰으로 굴리느냐가 제품의 경쟁력을 가른다. 대기와 폴링이라는, 그동안 당연시돼 온 오버헤드를 걷어낸 이 시도는 에이전트 코드를 직접 운영하는 팀에게 '무엇을 모델에게 맡기고 무엇을 인프라로 밀어낼 것인가'를 다시 묻게 한다.