Unreal Agent — 비동기 도구 호출로 에이전트 비용을 줄이는 하네스

AI 요약

Unreal Labs는 에이전트가 도구 실행을 기다리거나 완료 여부를 확인하는 데 모델 호출과 토큰을 낭비한다고 보고, 도구 호출을 비동기로 관리하는 Unreal Agent를 만들었습니다. 도구를 실행하면 이벤트 로그에 먼저 ‘진행 중’ 상태를 기록하고 작업은 백그라운드에서 계속합니다. 도구가 끝나면 결과를 세션 로그에 추가한 뒤 모델을 다시 호출합니다. 사용자는 도구 작업이 끝날 때까지 기다리지 않고 에이전트에 새 지시를 보낼 수 있습니다.

하네스가 맡는 일

기존 방식에서는 모델이 도구 실행, 대기, 상태 확인을 직접 조율하는 경우가 많습니다. Unreal Agent는 이 관리 작업을 하네스가 맡습니다. 긴 개발 환경 설정을 시작한 뒤 코드베이스를 살피거나 웹을 검색하는 식으로 서로 다른 도구 작업을 한 번에 진행합니다. 회사는 이런 구조가 모델이 기다리는 동안 반복하는 polling을 줄이고, 모델 호출 한 번 사이에 더 많은 도구 작업을 처리한다고 설명합니다.

비용 절감에는 두 가지 이유가 있다고 봅니다. 첫째, 프롬프트를 단순하게 유지하고 도구 결과를 토큰 효율적으로 다룹니다. 서브에이전트나 워크플로는 쓰지 않습니다. 둘째, 도구 작업을 모델 호출 사이에 더 많이 배치해 대기나 polling에 쓰는 토큰을 줄입니다. 회사는 도구 호출 결과를 ‘진행 중’ 상태와 최종 결과, 두 항목으로 기록하는 과정에서 캐시를 깨뜨리지 않는 일이 엔지니어링 과제였다고 덧붙입니다. Responses API 문서에는 이 형식이 충분히 명세되지 않았으며, 일부 모델과 추론 제공자에서 요청 거부도 관찰했다고 합니다.

SDK 선택과 운영상의 고려

Unreal Labs는 Claude Agent SDK 같은 CLI 중심 SDK가 로컬 세션, 하위 프로세스, 자원 한도 등을 전제로 해 프로덕션 환경에 그대로 맞지 않을 수 있다고 지적합니다. 완료·취소·백그라운드 작업의 수명주기를 안정적으로 관리하려면 별도 로직이 필요하다는 설명입니다. 제공자를 바꾸면 API 모드 차이로 도구나 대화 압축 기능이 달라질 수 있고, SDK 업데이트가 메시지 형식을 바꾸면 통합 코드를 다시 손봐야 합니다. 의존성이 많은 런타임은 유지보수 부담과 공급망 위험도 키운다고 봅니다.

보안과 승인은 하네스 내부의 훅이나 전용 도구에 맡기기보다, 허용·차단 호스트 설정, 세분화된 접근 토큰, 승인 게이트가 있는 프록시처럼 환경과 샌드박스 수준에서 결정적으로 제한하는 편이 낫다고 설명합니다. Unreal Agent SDK는 Go 라이브러리, CLI 실행기, Harbor와 호환되는 벤치마크 실행기를 제공합니다.

벤치마크와 수치

회사는 GPT-6 Astra xhigh로 코딩 에이전트 벤치마크를 실행했습니다. Harbor 기반 표에서 Unreal Agent의 비용은 Codex 대비 최대 40%, Pi 대비 최대 20% 낮았다고 보고합니다. 예를 들어 첫 번째 표에서 성공률은 Unreal Agent와 Codex가 각각 57.9%였지만 총비용은 1,428달러와 2,350달러였습니다. 다른 표에서는 Unreal Agent가 성공률 65.8%, 비용 936달러를 기록했고 Codex는 63.3%, 1,303달러였습니다. Harbor 외 평가에서는 전체 통과율이 Unreal Agent 30%, Codex와 Pi가 각각 29%였으며, 평균 점수는 각각 59.7, 58.1, 59.2였습니다.

회사는 성공률 차이가 크지 않아 벤치마크 변동의 영향으로 봤습니다. 코딩 벤치마크를 주로 선택한 이유는 Harbor에서 재현과 검증이 쉽기 때문이며, 하네스 자체는 특정 분야에 한정되지 않는다고 밝혔습니다. 다만 Hacker News에서는 비교 그래프에 Codex의 Astra max 결과가 섞여 xhigh 기준 비교처럼 보이지 않는다는 지적이 나왔습니다. 작성자는 개별 벤치마크의 비교는 xhigh끼리 했지만, 종합 그래프가 Codex max를 기본값으로 포함해 혼란을 줬다고 답했습니다.

Hacker News 반응

• @nylonstrung — 비동기 도구 호출이 토큰 절감으로 어떻게 이어지는지 잘 모르겠습니다. 모델이 동기식 도구 호출을 기다리는 동안 낭비하는 토큰을 없앤다고 하는데, Pi는 기다리는 동안 대체 어떤 토큰을 쓰나요?
  • @dumberquestions — 실행 중인 에이전트가 자신이 시작한 프로세스가 끝났는지 주기적으로 확인하는 것 같습니다.
  • @332451b — “모델 호출 한 번당 더 많은 도구 작업”을 하면 캐시 읽기 횟수나 캐시 미스, 그에 따른 비용도 줄어들 수 있지 않을까요?
• @tekacs — 대표 그래프가 좀 이상합니다. 어떤 이유에서인지 Astra xhigh로 실행한 하네스를 Astra max로 실행한 Codex와 비교합니다. OpenAI도 최근 자체 하네스에 비동기 도구 호출을 추가했습니다. 완전히 같은 접근은 아니지만 비슷한 기능을 조금씩 제공하고 있습니다. Codex가 토큰을 많이 쓰는 이유 중 하나는 시작한 작업을 불필요하게 계속 polling하기 때문입니다. 저도 1~2월에 Codex 포크에서 이 문제를 고쳤고, 여기 나온 Unreal의 절감과 비슷한 규모의 토큰을 아꼈습니다.
  • @discobot2 — 지적해 주셔서 감사합니다. 그래프는 저희가 제대로 만들지 못했습니다. 각 개별 벤치마크는 UA, Codex, Pi 모두 xhigh로 비교했고 종합 개선 수치도 xhigh 기준으로 계산했습니다. 다만 기본 설정에서 Codex max를 포함하는 그래프를 사용해 혼란이 생겼습니다.
• @rafaelmn — 에이전트 하네스를 채팅처럼 모델링하고 셸 세션에 끼워 넣는 대신, 비동기 액터 시스템과 샌드박스된 OS 기능 접근을 기반으로 만들면 훨씬 나을 텐데 아직도 그렇게 한다는 게 이해되지 않습니다. 올바른 추상화만 써도 쉽게 개선할 여지가 많습니다.
  • @dirtbag__dad — 그런 접근의 사례가 있나요?
  • @rafaelmn — 아직 세부 설계를 다듬는 개인 프로젝트 단계입니다. 이 프로젝트에서 보이는 점은 비동기성을 활용하면 에이전트 효율을 높일 수 있다는 것입니다. 에이전트를 메시지를 주고받는 액터로 모델링하면 이런 특성을 자연스럽게 얻습니다. 파일을 읽을 때 파일시스템 액터에 메시지를 보내고, 작업이 끝나면 응답 메시지를 받는 식입니다. 액터마다 역할과 권한을 두고, 에이전트 간 통신도 메시지를 보내는 방식으로 처리할 수 있습니다.
• @lelandbatey — 비동기 방식 자체는 흥미롭지만, 에이전트는 다음 행동을 결정할 때 실행 중인 명령의 결과에 의존하는 경우가 많습니다. 결과를 기다리는 동안에는 어떻게 행동하나요? 또 에이전트는 이미 nohup 같은 CLI 도구, 병렬 도구 호출, 병렬 서브에이전트로 비동기 작업을 실행합니다. 이 방식이 실제 속도를 얼마나 높이는지, 아니면 더 많은 일을 하는 듯한 인상만 주는지 궁금합니다.
• @faangguyindia — 이건 경우에 따라 유용하지만 항상 그렇지는 않은 programmatic tool calling과 같은 것 아닌가요? 도구 호출을 순서대로 반환하는 대신 모델이 도구를 실행하는 프로그램을 생성하면, 독립적인 도구를 비동기로 호출하고 결과를 모아 다음 모델 호출에 전달할 수 있습니다. Claude와 Codex도 이 방식을 추가했지만, 일부 연구에서는 모든 작업에 효과적이지 않고 모델도 이 기법에 맞게 훈련해야 한다고 합니다.
• @ironqcold — CLI 중심 SDK에 대한 비판은 타당합니다. 다만 서브에이전트가 없다는 제약이 장기 작업에서 어떤 결과를 내는지 보고 싶습니다.
• @vblanco — 제 프로젝트에서는 Unreal Editor의 Python 스크립팅을 노출하고, 블루프린트와 에셋 데이터를 텍스트로 내보내 봇이 검색하게 했습니다. MCP를 복잡하게 붙이지 않은 이 방식이 에이전트가 게임 코드와 작업을 다루는 데 가장 좋은 결과를 냈습니다.
• @tontinton — 비용 절감을 목표로 하는 하네스 maki.sh와도 비교해 주면 좋겠습니다.
  • @solarkraft — 두 접근의 기법은 서로 독립적으로 보입니다. 함께 쓸 수도 있을 것 같습니다.

원문: Unreal Labs / 번역·요약: Trawling