요즘 코딩 에이전트를 쓰다 보면 이상한 위화감이 든다. 모델은 계속 좋아지는데, 정작 그 모델을 감싸고 있는 껍데기(하네스)는 몇 세대 전 모델을 기준으로 만들어진 그대로라는 느낌. Prime Intellect가 공개한 Prime Agent 소개 글을 읽으면서, 내가 막연히 느끼던 그 답답함에 이름이 붙는 기분이었다.
하네스가 모델의 발목을 잡는다
글의 문제의식은 명확하다. 고정된 도구 호출 스키마와 컨텍스트 압축이 모델로 하여금 자기를 돕는 구조를 오히려 우회하게 만든다는 것이다. 또 하나는 정적(static)이라는 점이다. 서브에이전트, 프롬프트, 스킬, 메모리가 설계 시점에 한 번 정해지고 나면, 에이전트가 실행 중에 무엇을 배우든 그 배움이 구조에 반영되지 않는다.
하네스는 오히려 현재 모델의 능력을 다음 세대의 추론 패턴 쪽으로 외삽(extrapolate)해야 한다.
이 문장이 이 글 전체의 태도를 요약한다고 본다. 하네스를 모델의 한계를 메우는 보조 장치가 아니라, 모델이 아직 도달하지 않은 사용법을 미리 열어두는 장치로 보겠다는 것이다.
두 개의 추상화 요약
Prime Agent는 두 축으로 설계됐다고 소개된다.
- RLM(Recursive Language Model): 컨텍스트를 변수로, 서브에이전트 위임을 REPL 안의 함수 호출로 취급한다. 지속되는 IPython 커널이 사실상 유일한 도구이고, 다른 기능들은 그 안에서 함수로 불린다.
- Continual Harness: 프롬프트·스킬·메모리·서브에이전트로 추상화된 하네스 자신의 상태를, 에이전트가 자기 트라젝토리로부터 CRUD 할 수 있게 한다.
여기에 A2A(에이전트 간) 메시징이 얹히면서, 서브에이전트를 띄우고 나중에 다시 말을 걸고 다른 Prime Agent 세션과 직접 대화하는 오케스트레이션이 가능해진다. 다만 통신 범위는 부모·형제·자식이라는 nuclear family로 제한된다고 한다.
도구를 ‘읽는’ 대신 ‘실행한다’
벤치마크 숫자보다 더 오래 곱씹게 된 건 이 설명이었다.
Prime Agent는 도구로 데이터를 읽으며 토큰을 쓰는 대신, 데이터 위에서 함수를 프로그램적으로 실행함으로써 토큰을 아낀다.
기존 에이전트가 파일을 읽고 그 내용을 컨텍스트에 밀어 넣고 그걸 다시 요약하는 방식으로 돈과 토큰을 태웠다면, 여기서는 데이터를 변수에 두고 코드로 다룬다. 성능이 올라가면서 토큰이 줄었다는 결과는 이 설계에서 자연스럽게 따라오는 것처럼 보인다. 개인적으로는 이게 RLM의 진짜 실용적 가치가 아닐까 싶다. 재귀라는 단어의 화려함보다, 컨텍스트를 읽을거리가 아니라 조작 가능한 상태로 본다는 관점의 전환이 핵심이다.
자기개선을 작은 편집으로 정의한 점
/refine 설명도 좋았다. 자기개선이라고 하면 보통 하네스를 통째로 다시 쓰는 그림을 상상하게 되는데, 이 글은 정반대로 간다. 트라젝토리를 읽고 가장 작은 관련 CRUD 편집을 적용한다. 프롬프트 노트 하나, 메모리 하나, 스킬 하나를 고치는 식이다. 게다가 각 개선은 트리거와 결과를 함께 기록하므로 임의적이지 않고 근거를 남긴다. 기본 시스템 프롬프트는 불변으로 두고 그 주변 레이어만 편집한다. 잘못된 업데이트는 ID로 롤백할 수 있다.
이 설계가 마음에 드는 이유는, 자기개선 시스템에서 가장 무서운 게 ‘조용한 퇴행’이기 때문이다. 무엇이 언제 왜 바뀌었는지 추적할 수 없으면 개선인지 손상인지 판단할 방법이 없다. 작은 단위 + 기록 + 롤백은 이 문제에 대한 상당히 보수적이고 현실적인 답이다.
숫자를 어떻게 읽을 것인가
결과 중 눈에 띄는 건 ARC-AGI-3에서 Opus 5 기반으로 RHAE Best@1 95.5%를 기록해, 보고된 인간 전문가 기준선 95.4%를 넘었다는 부분이다. 3회 실행이 [95.0, 95.2, 95.5]로 일관됐고 Best@3는 99.97%, 183개 레벨 전부 완료였다고 한다. 롱컨텍스트 벤치마크 모음에서는 오픈웨이트 모델(GLM-5.2)로도 여러 항목에서 경쟁력 있는 수치를 보였다.
다만 글 스스로가 붙여둔 단서를 같이 읽어야 공정하다고 생각한다.
현재 어떤 모델도 Prime Agent나 그 핵심 기능들을 중심으로 학습되지 않았다.
이건 양날의 문장이다. 한편으로는 ‘학습되지 않았는데도 이 정도’라는 강력한 주장이고 다른 한편으로는 비교 대상인 Claude Code나 Codex는 각자의 모델과 함께 튜닝된 홈그라운드에서 뛰고 있다는 뜻이기도 하다. 실제로 저자들도 Opus 5와 Claude Code, GPT-5.6 Sol과 Codex 조합에서 공식 보고치보다 낮은 결과가 나와 공식 수치를 쓰겠다고 밝혔다. EmulatorBench에서는 Opus 실행이 도구 호출은 정상인데도 과제를 풀지 못했다고 적었다. 이런 항목을 숨기지 않고 각주로 남긴 태도는 신뢰가 간다.
남는 질문들
- IPython 커널이 유일한 도구라는 설계는 강력하지만 그만큼 실행 환경의 안전성과 상태 관리 부담을 키운다. 실제로 글에서도 커널 메모리 정리를 위해 별도 에이전트를 가비지 컬렉터처럼 띄운다고 했다. 이 복잡도가 장기적으로 감당 가능한 수준인지.
- Continual Harness가 쌓아 올린 메모리와 스킬이 시간이 지나며 서로 충돌하거나 낡을 때, 무엇을 지워야 하는지는 누가 판단하는가. CRUD의 D는 C만큼 어렵다.
- 세션 간 통신을 nuclear family로 제한한 결정은 안전하지만 대규모 스웜 오케스트레이션에서는 제약으로 작용할 수 있다. 이 경계를 어디까지 넓힐지가 다음 설계 과제로 보인다.
정리하며
Prime Agent에서 내가 가져가고 싶은 건 특정 기능이 아니라 관점이다. 하네스는 모델의 부족함을 메우는 반창고가 아니라, 모델이 아직 쓰지 않는 능력을 미리 열어두는 인터페이스여야 한다. 컨텍스트를 변수로 보고 하네스 자신을 편집 가능한 데이터로 보는 이 두 발상은, 설령 Prime Agent라는 구현체가 아니더라도 앞으로의 에이전트 설계에 계속 남을 것 같다.
오픈소스로 공개되어 있으니 직접 돌려보고 특히 /refine이 며칠에 걸쳐 무엇을 축적하는지 관찰해볼 생각이다. 자기개선의 진짜 증거는 벤치마크 점수가 아니라 그 축적된 로그에 있을 테니까. 원문은 Prime Intellect 블로그에서 볼 수 있다.