Prime Agent 기술보고서 공개, ARC-AGI-3 30%→95.5%

하네스(harness)는 언어모델을 실제 작업에 붙일 때 모델 바깥에서 돌아가는 실행 층이에요. 도구를 호출하고, 파일을 읽고 쓰고, 코드를 돌리고, 오류가 나면 되살리고, 대화 기록을 어디까지 남길지 정하는 일 전부가 여기서 벌어져요. 보고서 서론은 언어모델을 "경계가 있는 순차 처리기"로 규정해요. 가중치와 지금 열려 있는 컨텍스트에 담긴 정보만 가지고 다음 한 수를 정한다는 뜻이에요. 컴퓨터 한 대가 할 수 있는 일과 모델 한 개가 할 수 있는 일 사이의 빈칸을 하네스가 메운다는 게 이 논문의 출발점이에요.

그래서 벤치마크 점수는 늘 모델과 하네스의 합작품이었어요. 도구 호출이 한 번 어긋나서 세션이 죽으면 성적표에는 그냥 실패로 찍히죠. 보고서는 Prime Agent가 "하네스 실패가 모델 실패로 둔갑하는 것을 막는다"고 적었어요(Prime Agent 기술보고서 초록). 측정값을 모델의 진짜 최대 능력 쪽으로 밀어 올리는 게 목표라는 거예요.

8월 5일 공개, 8월 24일 개정

Prime Agent 자체는 지난 8월 5일에 나왔어요. 당시 Prime Intellect는 코딩과 장기 실행 자율 작업용 하네스라고 소개하면서 프로그래매틱 툴 호출, 변수로 다루는 컨텍스트, 멀티에이전트 메시징, 스스로 고치는 하네스 상태를 설계 축으로 내세웠는데 벤치마크 수치는 함께 나오지 않았어요. 이번 보고서가 그 자리를 채운 문서예요. 논문 표지에는 최초 공개 8월 5일, 현재 버전 8월 24일이라고 적혀 있어요.

저자는 11명이고, 논문에 적힌 소속은 프린스턴대·Prime Intellect·MIT 세 곳이에요. 교신 주소는 seth@primeintellect.ai와 altzhang@mit.edu 두 개고요. 회사 블로그 글을 확장해 하네스를 "어떻게 설계하고 어떻게 평가해야 하는가"를 논의의 중심에 놓았다는 게 게시물의 설명이에요.

네 개의 부품

초록이 설명하는 구조는 부품 네 개로 나뉘어요.

부품	하는 일
영속 IPython REPL	세션 내내 살아 있는 파이썬 실행 환경. 재귀 언어모델(RLM) 추상화를 따라 컨텍스트를 프로그램으로 다루고 테스트 시점 연산을 돌려요
Continual Harness	대화 이력·메모리·스킬·프롬프트·서브에이전트 명세를 여러 작업 궤적에 걸쳐 보존해요
재귀 서브에이전트	에이전트끼리 중개자 없이 직접 주고받으며 협업해요
Agents View	데몬으로 돌아가는 세션을 사람이 들여다보고 관리하는 화면

컨텍스트를 텍스트 덩어리가 아니라 프로그램이 다루는 변수로 취급한다는 대목이 핵심이에요. 긴 로그를 통째로 모델에 밀어 넣는 대신 REPL에서 잘라내고 요약하고 필요한 조각만 꺼내 쓰는 방식이죠. 실행·복구·검증·자원 회계는 하네스가 표준으로 처리하고, 전략을 짜는 일은 모델에 맡긴다는 게 설계 원칙이에요.

X 게시물은 혁신 지점을 네 갈래로 번호 매겨 소개했는데, 에이전틱 컨텍스트 관리와 스웜·depth-n+ RLM 두 개가 온전히 보이고 세 번째 Verifiers 지원은 문장 중간에서 끊겨 있어요. 나머지 항목은 본문에서 확인하는 편이 정확해요.

어디서 쟀나 — 게임과 커널 사이

측정 대상 목록이 특이해요. 장문맥 코딩, GPU 커널 생성, 에뮬레이터 구축, 자율 nanoGPT 스피드런. 마지막 항목은 작은 GPT를 정해진 성능까지 얼마나 빨리 학습시키는지를 겨루는 과제인데, 사람이 손대지 않고 에이전트가 알아서 돌린다는 뜻이에요. 초록은 이들 영역에서 각 모델의 네이티브 하네스나 널리 쓰이는 하네스와 대등하거나 더 나았다고 적었어요.

게임도 들어갔어요. 공장 건설 게임 Factorio에서는 반복 개선을 거치며 기술 트리를 끊기지 않고 진행할 수 있었고, 전담 서브에이전트를 붙이니 작업을 병렬로 나눌 수 있었다고 해요. 몇 시간짜리 목표를 쪼개 여러 갈래로 밀어붙이는 능력을 보려면 코딩 벤치마크보다 이쪽이 잘 드러난다는 판단으로 읽혀요.

직접 써보려면

코드는 github.com/PrimeIntellect-ai/prime-agent 저장소에 오픈소스로 올라와 있어요. 논문 초록이 코드 위치로 명시한 주소예요. 하네스는 모델을 갈아 끼워 쓰는 층이라, 쓰던 코딩 에이전트와 같은 작업을 하네스만 바꿔 돌려 보면 차이가 어디서 나는지 비교하기 쉬워요. 저장소를 받아 REPL 세션을 띄우고 익숙한 과제 하나를 던져 본 뒤 Agents View로 세션이 어디서 멈추는지 확인하는 순서가 현실적이에요.

에디터의 시선

30%에서 95.5%라는 숫자를 그대로 믿든 아니든, 이 보고서가 건드린 건 지난 1년치 에이전트 벤치마크 점수의 신뢰도예요. 어떤 모델이 SWE-bench에서 몇 퍼센트를 받았다는 발표를 우리는 모델의 능력치로 읽어 왔는데, 같은 모델을 다른 껍데기에 넣으면 점수가 크게 움직인다면 그 발표는 모델 점수가 아니라 모델+하네스 조합 점수였다는 얘기가 돼요. 그래서 논문 제목이 하네스를 평가 대상으로 못 박은 거예요. 우리 수집망에도 에이전트 코딩 평가에서 인프라 잡음을 정량화하려는 시도, 두뇌와 손을 분리해 관리형 에이전트를 확장하려는 논의가 최근 잇따라 잡혔어요. 같은 문제를 여러 팀이 동시에 파고 있다는 신호예요.

실무에서 이걸 어떻게 읽어야 하냐면, 모델 교체보다 하네스 정비가 먼저라는 쪽이에요. 코딩 에이전트를 붙여 본 팀은 대체로 같은 지점에서 막혀요. 모델이 답을 몰라서가 아니라 툴 호출이 어긋나고, 긴 로그가 컨텍스트를 잡아먹고, 중간에 죽은 세션을 되살릴 방법이 없어서 작업이 끝나지 않죠. 그 상태에서 상위 모델로 갈아타면 토큰 비용은 두세 배가 되는데 완주율은 별로 안 오르는 경험을 하게 돼요. Prime Agent가 표준화 항목으로 실행·복구·검증·자원 회계 네 가지를 꼽은 건 정확히 그 지점이에요. 특히 자원 회계 — 어느 서브에이전트가 토큰을 얼마나 태웠는지 계산해 주는 기능은 데모에서는 눈에 안 띄지만 실제 운영에서는 매달 청구서를 결정해요.

한국 팀에 당장 쓸모 있는 부분은 Continual Harness 개념이에요. 작업 하나가 끝나면 대화 기록과 함께 그 안에서 얻은 요령까지 날아가는 게 지금 대부분의 에이전트 파이프라인이 돌아가는 방식이거든요. 이력·메모리·스킬·프롬프트·서브에이전트 명세를 작업 사이에 남긴다는 설계는 사내 반복 업무에 붙일 때 효과가 크게 나요. 같은 형식의 리포트를 매주 만드는 작업이라면 두 번째 주부터 지시가 짧아지죠. 반대로 아직 이른 건 스웜이에요. 서브에이전트를 여러 개 띄워 병렬로 돌리는 구성은 Factorio처럼 목표가 명확하고 검증이 자동인 환경에서 잘 굴러가는데, 검증 기준이 사람 눈밖에 없는 업무에서는 병렬화가 곧 검수 부담 증가로 돌아와요.

앞으로 몇 주 안에 하네스를 고정한 상태로 모델을 비교하는 평가, 반대로 모델을 고정하고 하네스를 비교하는 평가가 나란히 나올 거예요. 그리고 모델 발표문에 어떤 하네스로 잰 점수인지를 적는 관행이 자리 잡을 거고요. Prime Agent가 그 표준을 가져갈지는 다른 문제지만, 점수 옆에 껍데기 이름을 병기하지 않은 발표는 이제 반쪽으로 읽히게 됐어요.