Unreal Agent는 왜 도구 호출 방식을 바꿔서 비용을 줄이려는 걸까요?

요약 보기

이 글에서 Unreal Labs가 내세우는 핵심은 새 모델을 만들었다는 이야기가 아니에요. 글쓴이는 Unreal Agent를 에이전트용 하네스라고 소개하면서, 실제 업무와 코딩·과학 벤치마크에서 Codex보다 최대 40%, Pi보다 최대 20%까지 비용을 줄였고 성능에 부정적 영향은 없었다고 주장해요. 그래서 읽는 포인트는 모델 자체의 능력보다, 모델이 도구를 부르고 기다리고 다시 이어 가는 바깥 운영 구조를 어떻게 짰는지에 있어요.

여기서 하네스라는 말이 조금 낯설 수 있어요. 원문의 맥락에서는 모델 바깥에서 도구 호출을 관리하는 실행 틀 정도로 이해하면 돼요. 글쓴이는 실제 배포 환경에서 에이전트가 도구 호출을 관리하느라 시간과 토큰을 많이 쓰는 모습을 봤다고 말해요. 그래서 waits, polls, heartbeats 같은 관리 일을 하네스가 비동기적으로 맡고, 모델은 그 부담을 덜게 하려는 거죠. 가상의 비유로 보면, 상담원이 직접 택배 기사 위치를 몇 초마다 확인하는 대신 접수 시스템이 알아서 상태를 갱신해 주는 모습에 가까워요. 상담원은 확인 업무보다 다음 판단에 집중할 수 있게 되는 거예요.

왜 굳이 자체 하네스를 만들었는지도 중요해요. 글쓴이는 에이전트 중심 제품을 만들다 보면 정답처럼 따라갈 길이 없고, 큰 업체들의 SDK도 저마다 다른 타협을 안고 있다고 봐요. 예를 들어 CLI 중심 SDK는 로컬 세션, 서브프로세스, 자원 제한 같은 가정을 품고 있어서 운영 환경에 그대로 맞지 않을 수 있다고 해요. 완료 처리나 취소, 백그라운드 작업을 안정적으로 다루려면 결국 별도 수명주기 관리를 덧대야 하고, 다른 제공자를 붙이려면 API 모드 차이 때문에 도구나 메시지 형식이 깨질 수도 있다고 말하죠. 의존성이 무거우면 유지보수 부담과 공급망 위험도 커진다고 보고요. 보안 역시 하네스 안의 특수 훅보다, 허용·차단 호스트나 세분화된 토큰, 승인 게이트가 있는 프록시처럼 하네스 바깥의 결정론적 제약이 더 견고했다고 글쓴이는 평가해요.

작동 방식은 생각보다 구체적으로 설명돼 있어요. Unreal Agent가 도구를 호출하면, 하네스는 도구가 아직 끝나지 않았더라도 세션 로그에 먼저 진행 중이라는 기록을 남기고 실제 실행은 백그라운드에서 계속 돌려요. 그리고 도구가 끝났을 때 결과를 로그에 붙인 뒤 LLM을 다시 호출해요. 이 구조 덕분에 글쓴이가 특히 원했던 두 가지가 가능해진다고 해요. 하나는 사용자가 도구 종료를 기다리지 않고 중간에 계속 방향을 바꿔 지시할 수 있다는 점, 다른 하나는 오래 걸리는 개발 환경 설정이 도는 동안 코드베이스 탐색이나 웹 검색 같은 다른 도구 작업을 병렬로 진행할 수 있다는 점이에요. 원문은 이 과정이 모델에 추가적인 인지 부담이나 토큰 세금을 덜 주도록 설계됐다고 설명해요.

그렇다면 비용이 왜 줄어든다고 보는 걸까요. 글쓴이는 겉으로 보면 더 적은 모델 턴과 더 적은 입력 토큰으로 같은 결과를 낸다고 요약해요. 원인으로는 두 가지를 들어요. 첫째, 하네스 자체의 발자국을 작게 만든 것. 둘째, 도구 출력 사용을 세심하게 다듬은 것이에요. 그래서 프롬프트를 단순하게 하고, 도구 결과를 토큰 친화적으로 만들고, 서브에이전트나 복잡한 워크플로는 두지 않았다고 해요. 여기에 비동기 도구 호출 방식이 더해지면, 모델 한 번 부를 때마다 무거운 도구 작업을 더 많이 배치할 수 있고, 그 사이에 폴링이나 대기 때문에 토큰을 낭비하지 않게 된다는 논리예요.

벤치마크는 이 설명이 실제 수치로도 맞는지 보여 주려는 부분이에요. 테스트는 GPT-6 Astra xhigh로 했고 비교 대상은 Codex와 Pi였다고 해요. Terminal-Bench에서는 Unreal Agent와 Codex의 통과율이 같게 제시되면서 총비용은 Unreal Agent가 더 낮아요. SWE-Atlas와 DeepSWE 표에서도 Unreal Agent가 표에 제시된 범위에서는 더 낮은 총비용을 보이고, 통과율도 높게 나와 있어요. ALE-CLI에서도 전체 통과율과 평균 점수는 비슷한 수준으로 보이는데 총비용은 더 낮게 적혀 있고요. 다만 이 부분에서 글쓴이도 조심스러운 표현을 써요. 통과율 차이는 미세하고, 자신들은 그것을 벤치마크 변동성 때문이라고 본다고 밝혀요. 그러니 이 숫자는 무조건 성능 우위라고 단정하기보다, 적어도 그들이 제시한 실험에서는 비용 효율이 좋았다는 근거로 읽는 편이 맞아요.

한계와 조건도 분명히 있어요. 먼저 이 설계는 도구 결과를 한 번은 진행 중, 나중에 최종 결과로 같은 대화 문맥 안에 넣는 방식을 쓰는데, 글쓴이는 이 패턴이 API 문서에서 충분히 규정돼 있지 않다고 말해요. 실제 테스트에서도 일부 추론 제공자와 일부 모델에서는 거부가 있었다고 적어요. 즉, 아이디어 자체와 별개로 제공자 호환성은 아직 흔들릴 수 있다는 뜻이에요. 또 공개한 평가는 대부분 코딩 벤치마크인데, 그 이유는 Harbor에서 재현과 검증이 쉬워서라고 설명해요. 글쓴이는 하네스가 분야에 구애받지 않는다고 보지만, 이 글만으로 다른 분야에서도 같은 폭의 절감이 난다고 확정할 수는 없어요. 하네스 설계 자체가 아직 더 연구되고 구현될 여지가 많은 영역이라는 자기 평가도 그래서 함께 읽어야 해요.