하네스를 고치는 에이전트, 열린 세계에서 일하는 법

Harness^2: Recursive Agent Harnessing for an Open World라는 논문이 arXiv(2610.14224)에 공개됐습니다. 원문 링크는 제목 아래에 걸어 두었습니다.

이 연구는 에이전트의 성능이 모델뿐 아니라 실행 하네스에 달려 있다는 진단에서 출발해 정답 검증기가 없는 열린 환경에서도 쓸 수 있는 두 층의 재귀적 하네스 개선 틀을 제안하며, 이 글에서는 그 진단과 두 층의 동작 방식과 측정 결과를 차례로 따라가겠습니다.

왜 모델만 바꾸는 것으로는 부족할까

안녕하세요, 패트릭입니다. 저는 이 논문을 읽기 전까지 에이전트 성능 이야기를 들으면 자연스럽게 모델 크기와 학습 데이터를 먼저 떠올렸습니다. 그런데 저자가 던지는 첫 문장을 보고 발걸음이 멈췄습니다. 에이전트의 능력은 모델뿐 아니라 그 모델을 감싸고 움직이게 만드는 실행 하네스에도 달려 있다는 것이었기 때문입니다. 생각해보면 사람도 비슷하게 일합니다. 아무리 유능한 신입이라도, 업무 매뉴얼이 엉성하고 결재 라인이 꼬여 있으면 일을 망치기 쉽죠. 그 매뉴얼과 결재 라인이 바로 하네스에 해당합니다.

여기서 하네스란 프롬프트 템플릿과 도구 호출 순서, 재시도 규칙, 중간 점검 방식처럼 에이전트가 실제로 움직이는 틀을 말합니다. 같은 GLM-5를 쓰더라도 하네스가 다르면 결과가 달라지고, 같은 Gemini 3.5 Flash라도 하네스를 어떻게 짰느냐에 따라 엉뚱한 곳에서 헤맬 수 있습니다. 그래서 연구진은 모델 개선과는 별개로 하네스 최적화를 일류 개선 대상으로 보자고 말합니다. 저는 이 시각 전환이 마음에 들었습니다. 모델 점수 경쟁에만 시선을 두면 놓치는 부분이 분명히 있으니까요.

그렇다면 하네스를 왜 따로 떼어내서 고쳐야 할까요. 이유는 하네스가 자주 바뀌면서도 매번 처음부터 손으로 고쳐지고 있기 때문입니다. 새로운 업무가 들어올 때마다 엔지니어가 프롬프트를 조금 고치고, 도구 설명을 덧붙이고, 실패 사례를 보며 규칙을 추가합니다. 이 과정은 경험에 의존하고 반복도 많습니다. 그런데 이런 손질을 에이전트 스스로 체계적으로 하게 만들 수 있다면 어떨까요. 그 질문이 바로 이 논문의 출발점입니다.

하네스를 고친다는 것은 무엇을 뜻할까

하네스를 고친다는 말을 처음 들으면 프롬프트 한 줄을 바꾸는 정도로 생각하기 쉽습니다. 하지만 실제로 하네스는 훨씬 넓은 범위를 가집니다. 어떤 도구를 어떤 순서로 부를지, 중간 결과가 이상하면 언제 멈추고 되돌아갈지, 외부 파일과 기억을 어떻게 읽고 쓸지 같은 운영 규칙 전체가 포함됩니다. 그래서 하네스를 고친다는 것은 에이전트의 일하는 방식을 통째로 다듬는 일에 가깝습니다. 레시피의 재료 하나를 바꾸는 것이 아니라 조리 순서와 불 조절과 플레이팅까지 함께 손보는 셈이죠.

이 논문이 말하는 Harness^2는 그런 손질을 대신 해주는 꽂아 쓰기(plug-and-play) 방식의 틀입니다. 기존 에이전트 위에 얹어서 쓸 수 있고, 특정 모델이나 특정 업무에만 묶이지 않도록 설계됐습니다. 이름에 제곱 표시가 붙은 이유는 재귀가 두 층으로 연결되어 있기 때문입니다. 아래층에서는 지금 맡은 일의 하네스를 고치고, 위층에서는 그 고친 경험을 모아 다음 일을 위한 하네스를 업데이트합니다. 아래층이 오늘의 일을 잘하게 만든다면, 위층은 다음 달의 일을 미리 준비하는 셈입니다.

저는 이 나눗셈이 꽤 영리하다고 봅니다. 아래층만 있으면 매번 잘 고치면서도 다음에는 또 처음부터 헤매게 되고, 위층만 있으면 추상적인 교훈만 쌓이다가 현장의 디테일을 놓치기 쉽기 때문입니다. 두 층을 연결하면 현장의 수정이 쌓여서 운영 지침이 되고, 운영 지침은 다시 현장의 수정을 더 빠르게 만듭니다. 그렇다면 아래층의 수정은 어떻게 믿을 수 있을까요. 그 이야기는 다음으로 이어집니다.

정답지가 없는데 어떻게 고칠 수 있을까

열린 세계에서 에이전트를 돌리면 가장 곤란한 순간이 언제일까요. 저는 테스트 당일에 처음 보는 업무가 떨어졌는데 채점 기준표가 없을 때라고 봅니다. 연구실에서는 정답 검증기(ground-truth verifier)가 있어서 하네스를 고친 뒤 점수가 올랐는지 바로 확인할 수 있습니다. 하지만 실제 배포에서는 그런 검증기가 없는 새로운 일이 계속 들어옵니다. 온라인으로 하네스를 고쳐야 하는데, 고친 방향이 맞는지 알려줄 심판이 없는 것이죠. 이 빈자리가 바로 열린 세계 배포의 어려움입니다.

기존의 재귀적 자기 개선 방식도 이 빈자리를 메우지 못했습니다. 특정 업무에 대해서는 잘 고쳤지만, 조금만 조건이 바뀌면 다시 무너졌기 때문입니다. 한 업무에 과하게 맞춘 요령은 다음 업무에서는 짐이 되기 쉽습니다. 마치 한 고객사의 결재 문서 양식에 맞춰 만든 매크로가 다른 고객사에서는 오작동하는 것과 비슷합니다. 그래서 연구진이 던진 질문도 바뀌었습니다. 한 일을 잘 고치는 방법에서, 정답지 없이도 믿을 만하게 고치고 그 경험이 다음 일에도 통하게 만드는 방법으로 말이죠.

여기서 재미있는 질문이 생깁니다. 심판이 없으면 무엇을 기준으로 고쳐야 할까요. 사람의 직감일까요, 아니면 다른 신호일까요. 논문은 대비(contrast)라는 오래된 아이디어를 끌어옵니다. 하나의 안을 놓고 맞다 틀리다를 따지는 대신, 서로 다른 두 안을 나란히 놓고 어느 쪽이 더 그럴듯한지 따져보자는 것입니다. 정답은 몰라도 둘 중 나은 쪽은 고를 수 있다는 발상에 가깝습니다. 이 차이가 생각보다 중요합니다. 왜냐하면 열린 세계에서는 완벽한 점수보다 덜 헤매는 방향이 더 현실적인 목표이기 때문입니다.

나쁜 안과 좋은 안을 나란히 놓고 보면

작업층 재귀의 뼈대는 Propose-Probe-Compose라는 세 단계 대비 과정입니다. 이름이 거창하게 들리지만 하는 일은 의외로 직관적입니다. 먼저 지금 하네스의 변형 후보를 제안하고(Propose), 그 후보들을 실제 일에 찔러보며 반응을 살피고(Probe), 그 관찰을 모아 더 나은 하네스로 엮어내는(Compose) 흐름입니다. 저는 이를 장보기와 요리에 비유하고 싶습니다. 재료를 몇 가지 사 와서(Propose) 맛을 보고(Probe) 최종 메뉴로 정리하는(Compose) 과정과 닮았기 때문입니다.

이 과정에서 중요한 점은 정답 검증기에 의존하지 않는다는 것입니다. 대신 두 후보의 행동 차이를 이용합니다. 예를 들어 월요일 아침에 고객사 A의 발주 메일을 정리하는 일을 생각해보겠습니다. 하네스 후보 하나는 메일을 열자마자 바로 답장을 쓰고, 다른 후보는 첨부된 발주서를 먼저 열어 수량과 납기를 확인한 뒤 답장을 씁니다. 어느 쪽이 더 조심스러운지는 정답지가 없어도 알 수 있습니다. Probe 단계는 바로 이런 차이를 드러내는 작은 시험들을 만듭니다. 그리고 Compose 단계에서는 잘된 선택만 남기고 하네스에 반영합니다.

그런데 여기서 조금 조심해서 읽을 필요가 있습니다. 대비가 항상 옳은 방향을 가리키는 것은 아니기 때문입니다. 두 안이 모두 나쁘면 그중 나은 쪽을 골라도 여전히 나쁠 수 있습니다. 연구진이 대비를 강조하는 이유도 그것이 완벽해서가 아니라, 검증기가 없을 때 가장 덜 흔들리는 신호이기 때문이라고 저는 읽었습니다. 실제로 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 대비 과정을 한 번만 돌릴 것인가, 아니면 예산이 허락하는 대로 더 돌릴 것인가요. 그 답은 확장 방식에 있습니다.

한 번의 수정이 다음 일을 도울 수 있을까

아래층에서 오늘의 하네스를 잘 고쳤다고 해도, 그 경험이 휘발되면 조직은 매번 같은 삽질을 반복합니다. 그래서 Harness^2에는 하네싱층(harnessing-level) 재귀라는 두 번째 층이 있습니다. 하는 일은 단순합니다. 작업층에서 일어난 수정들을 모아보고, 거기서 다음 일에도 쓸 수 있는 교훈을 뽑아내어 계속 개선되는 하네스에 반영하는 것입니다. 일종의 오답 노트처럼요. 다만 개인의 노트가 아니라 팀 전체의 운영 지침에 적히는 노트에 가깝습니다.

예를 들어 이번 주에 발주서 정리 일을 고치면서 중간 점검을 한 번 더 넣었더니 실수가 줄었다고 해보겠습니다. 다음 주에는 전혀 다른 일인 회의록 정리 일이 들어옵니다. 표면적으로 보면 두 일은 다르지만, 중간에 한 번 멈춰서 빠진 정보를 확인한다는 습관은 그대로 통할 수 있습니다. 하네싱층 재귀는 바로 이런 층위의 경험을 옮깁니다. 구체적인 문구를 복사하는 것이 아니라, 어떤 종류의 점검이 어디서 효과 있었는지를 추려내는 것이죠. 그래서 특정 업무에만 달라붙는 요령과 구분됩니다.

개인적으로 인상 깊었던 점은, 이 층이 경험을 모은다는 표현을 쓴다는 것입니다. 모든 수정을 다 저장하는 것이 아니라, 다음 적응을 도와줄 만한 수정을 가려서 반영한다는 뜻으로 읽히기 때문입니다. 다 저장하면 운영 지침이 금방 비대해지고, 아무거나 버리면 배운 것이 사라집니다. 무엇을 남기고 무엇을 버릴지를 가르는 기준이 바로 이 틀의 수준을 가를 것 같습니다. 그렇다면 이런 두 층 구조는 얼마나 더 밀어붙일 수 있을까요.

넓게 시도하고 깊게 이어가면 무엇이 달라질까

작업층 재귀는 예산을 더 쓰면 더 좋아질 수 있도록 설계됐습니다. 논문이 말하는 두 가지 확장 방식은 병렬(parallel)과 순차(sequential) 재귀입니다. 병렬은 여러 후보를 동시에 넓게 시도하는 것이고, 순차는 한 번 고친 결과를 출발점으로 다시 고치는 것입니다. 등산로 찾기에 비유하면 병렬은 여러 갈래 길을 동시에 정찰조를 보내보는 것이고, 순차는 한 길을 따라가며 계속 표지판을 고쳐 세우는 것에 가깝습니다. 둘 다 비용이 들지만 기대하는 효과는 다릅니다.

병렬이 넓이를 준다면 순차는 깊이를 줍니다. 처음에는 엉성했던 하네스도 한 번 고치고 다시 찔러보면 새로운 약점이 드러나고, 그 약점을 또 고치면 처음에는 보이지 않던 문제가 보이기 시작합니다. 반면 병렬은 한 번의 시도에 운이 나쁘게 걸리는 경우를 줄여줍니다. 여러 안을 동시에 비교하면 특정 안의 우연한 성공에 속을 가능성이 낮아지기 때문입니다. 저는 이 대목에서 예산 이야기가 나온다는 점이 현실적이라고 봤습니다. 연구실에서는 무한히 시도할 수 있지만, 실제 서버에서는 토큰 비용과 지연이 바로 돈이 되니까요.

문제는 그다음입니다. 예산을 늘리면 항상 좋아질까요. 논문의 서술을 곧이곧대로 읽으면 더 돌릴수록 좋아진다고 들리지만, 여기서는 조금 멈칫할 필요가 있습니다. 대비 신호 자체가 흔들리면 더 돌린다고 항상 좋아지지는 않기 때문입니다. 넓게 시도해도 후보들이 모두 비슷하면 남는 것이 없고, 깊게 이어가도 초기 방향이 틀렸으면 그 틀린 길을 더 잘 닦게 됩니다. 그래서 확장 예산은 만능이 아니라 방향이 맞을 때 가속하는 장치에 가깝습니다. 그 방향이 실제로 맞았는지는 숫자로 확인해야 합니다.

숫자는 실제로 얼마나 움직였을까

이제 숫자를 보겠습니다. 논문은 GLM-5와 Gemini 3.5 Flash를 기본 하네스 위에서 한 단계만 고쳤을 때 WorkBuddy-Bench에서 최대 11.5점, JobBench에서 4.5점, LAB에서 11.8%포인트가 올랐다고 보고합니다. 일반 파일에 적힌 규칙을 손으로 고치는 수준이 아니라 틀 자체를 한 번 다듬었는데 두 자릿수에 가까운 움직임이 나왔다는 점에서 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 특히 모델 두 종류에서 함께 올랐다는 대목이 눈에 띕니다. 특정 모델의 버릇에 맞춘 요령이었다면 다른 모델에서는 효과가 줄었을 텐데, 그렇지 않았기 때문입니다.

숫자를 해석할 때는 조건을 함께 봐야 합니다. 여기서 말하는 한 단계(single step)란 두 층이 한 번씩 도는 짧은 개선을 뜻합니다. 길게 반복한 결과가 아니라 첫 손질에서 나온 변화라는 점에서 의미가 있습니다. 현장에서는 길게 돌릴 시간이 없을 때가 많기 때문입니다. 밤사이 들어온 장애 티켓을 아침에 처리해야 하는 운영팀을 생각해보면, 한 번의 손질로 얼마나 움직이는지가 바로 도입 여부를 가르는 기준이 됩니다. 그런 점에서 첫 단계의 상승은 실무적인 설득력을 가집니다.

다만 이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 세 벤치마크가 모두 실제 열린 세계를 온전히 대신하지는 않기 때문입니다. WorkBuddy-Bench와 JobBench는 업무형 일을, LAB는 다른 층위의 능력을 재겠지만, 어떤 벤치마크도 처음 보는 일의 무한한 변형을 다 담지는 못합니다. 그래서 저는 이 결과를 이렇게 읽었습니다. 하네스 재귀가 통한다는 신호는 분명하지만, 그 신호가 모든 열린 일에 같은 크기로 나타난다고 일반화하기에는 아직 데이터가 부족합니다. 그 경계를 가르는 것이 다음 질문입니다.

그 일만 잘하는 것과 처음 보는 일까지 해내는 것

기존 자기 개선 방식이 자주 빠지는 함정은 한 일에 너무 잘 맞는 것입니다. 연구실 벤치마크에서는 점수가 쑥 오르지만, 막상 옆 부서의 일을 맡기면 헤매는 경우가 많죠. 논문이 기존 방식을 업무 특정적(task-specific)이라고 부르며 일반화가 안 된다고 지적하는 대목도 같은 맥락입니다. 한 마디로 하면 그 일의 정답에 과하게 맞춘 하네스는 다음 일의 오답이 되기 쉽습니다. 특정 고객의 말투에 맞춘 응대 스크립트가 다른 고객에게는 실례가 되는 것과 비슷합니다.

Harness^2가 내세우는 차이는 바로 이 지점에 있습니다. 작업층의 대비 과정은 정답을 외우는 대신 더 나은 일하는 방식을 고르고, 하네싱층은 그 방식을 다음 일에 쓸 수 있는 형태로 추립니다. 그래서 한 일의 점수보다 처음 보는 일への 적응을 더 본다고 말합니다. 표현을 바꾸면 외운 답이 아니라 일하는 습관을 옮긴다는 것이죠. 저는 이 구분이 에이전트 평가의 방향과도 연결된다고 봅니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다.

그렇다면 이 일반화는 어디까지 믿을 수 있을까요. 솔직히 말해 증거에는 경계가 있습니다. 세 벤치마크에서의 상승은 고무적이지만, 열린 세계의 새로움은 벤치마크의 새로움보다 훨씬 질깁니다. 예를 들어 수요일 오후에 갑자기 바뀐 사내 보안 정책 때문에 도구 접근 순서가 통째로 바뀌는 상황을 생각해보겠습니다. 이런 일은 벤치마크에 미리 들어 있기 어렵습니다. 그래서 저는 이 논문을 특정 점수의 승리로 읽기보다, 점수보다 구조를 보게 만드는 제안으로 읽는 편이 좋다고 봅니다. 구조가 맞으면 점수는 따라올 가능성이 크기 때문입니다.

실제 서버에 올리면 무엇이 먼저 걸릴까

좋은데, 이걸 어디에 올릴까요. 연구실 그림과 운영 서버 사이에는 항상 간격이 있습니다. 하네스 재귀는 말 그대로 돌릴수록 토큰을 쓰고 시간을 씁니다. Propose에서 후보를 만들고 Probe에서 찔러보고 Compose에서 엮는 매 단계마다 모델 호출이 들어가기 때문입니다. 트래픽이 몰리는 금요일 오후를 생각해보면, 에이전트 한 건당 호출이 몇 배로 늘어나는 설계는 바로 비용과 지연으로 돌아옵니다. 그래서 도입 여부를 가르는 것은 정확도 상승 하나가 아니라 상승당 비용이 됩니다.

또 하나는 하네스가 커지면서 생기는 운영 부담입니다. 계속 개선되는 하네스라고 해서 무조건 쌓기만 하면 어느 순간부터는 하네스 자체가 무거워집니다. 규칙이 많아지면 서로 충돌하고, 도구 설명이 길어지면 컨텍스트를 잡아먹고, 중간 점검이 잦아지면 지연이 늘어납니다. 마치 매뉴얼이 두꺼워질수록 신입이 더 헤매는 것과 비슷합니다. 그래서 계속 쌓는 것만큼이나 무엇을 버릴지가 중요해집니다. 경험을 모은다고 할 때 그 가려내는 기준이 운영에서는 더 엄격해야 합니다.

여기서 재미있는 trade-off가 생깁니다. 아래층을 자주 돌리면 오늘의 일에는 강해지지만 비용이 올라가고, 위층에만 의존하면 비용은 아끼지만 현장 변화에 늦어집니다. 저는 그래서 이 틀을 쓸 때는 예산 스위치를 함께 설계해야 한다고 봅니다. 일이 급하고 처음 보는 일이라면 아래층을 짧게 돌리고, 일이 반복되고 패턴이 보이면 위층에 차곡차곡 쌓는 식입니다. 실제 시스템 관점에서 보면 이런 운영 스위치가 논문의 수식만큼이나 중요해 보입니다. 그렇다면 남은 의문은 무엇일까요.

저는 이 다음 장면이 궁금합니다

지금까지의 이야기를 정리하면 흐름은 분명합니다. 질문도 바뀌었습니다. 좋은 모델은 무엇인가에서 좋은 일하는 틀을 어떻게 자동으로 찾을 것인가로, 다시 정답지 없이도 믿을 만하게 고르고 다음 일에 전할 수 있는가로 말이죠. 저는 이 흐름의 다음을 보고 싶습니다. 특히 대비 신호가 흔들리는 상황에서도 방향을 잃지 않는 방법이 나올지가 궁금합니다. 두 안이 모두 별로일 때, 혹은 Probe 자체가 잘못된 시험을 만들 때 이 틀은 어떻게 스스로를 의심할 수 있을까요.

제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째는 실패의 기록입니다. 어디에서 대비가 틀렸고, 어떤 종류의 일에서는 위층의 교훈이 오히려 방해가 됐는지를 보고 싶습니다. 성공 숫자만 보면 다음 도입자가 같은 함정에 빠지기 쉽기 때문입니다. 둘째는 장기 운영의 모습입니다. 한 달, 석 달 동안 하네스가 계속 업데이트될 때 규칙이 비대해지는지, 아니면 스스로 다이어트하는지가 궁금합니다. 셋째는 사람과의 연결입니다. 엔지니어가 중간에 개입해서 방향을 꺾을 수 있는 자리가 어디에 있는지를 알고 싶습니다. 완전 자동보다 사람과 함께 고치는 지점이 현실에서는 더 자주 필요하기 때문입니다.

이 논문이 흥미로운 이유는 특정 점수를 올렸다는 데 있지 않습니다. 에이전트의 일하는 틀 자체를 개선 대상으로 끌어올리고, 그 개선을 오늘의 일과 다음의 일로 나눠서 설계했다는 데 있습니다. 모델이 좋아지는 속도와 별개로, 일을 시키는 방식이 좋아지는 속도가 있다는 것을 보여주기 때문입니다. 그렇다면 사람의 역할은 무엇일까요. 저는 무엇을 자동화할지보다 어떤 일을 맡길지를 정하는 일이 더 중요해질 것이라고 봅니다. 어떤 하네스를 쓸지는 결국 어떤 일을 시키고 싶은지에 달려 있으니까요.