RobustSGPO: 에이전트 하네스 진화에서 탐색 공간을 다스리는 법

이번에 살펴볼 연구는 RobustSGPO: Search-Space Control for Agent Harness Evolution으로, arXiv에 2609.09646 번호로 공개된 논문입니다. 원문은 제목 아래에 걸린 링크에서 바로 확인할 수 있습니다.

이 연구는 실행 피드백으로 에이전트 하네스를 개선하는 SGPO가 남긴 빈틈, 즉 무엇을 어느 범위에서 어떤 동작으로 고칠지 정해주지 않는다는 문제를, 고치고 싶은 내용을 문장으로 못 박고 패치를 직접 만들고 검사한 뒤 현행본이나 보관된 스냅샷 중 더 나은 출발점에서 탐색을 이어가는 탐색 공간 제어로 풀자고 제안합니다. 이번 글에서는 그 진단이 왜 나왔는지, 수정 명시와 패치 검사와 스냅샷 재출발이 각각 무엇을 바꾸는지, 그리고 AgentX 브레인스토밍 흐름에서 120개 과제와 95회 실행, 7,350번 후보 시도로 무엇을 확인했는지 차례로 따라가겠습니다.

에이전트가 아니라 하네스를 고친다는 발상이 눈에 밟혔습니다

안녕하세요, 패트릭입니다. 제가 이 논문에서 가장 흥미롭게 본 부분은 모델이 아니라 모델을 둘러싼 하네스를 진화 대상으로 삼았다는 점입니다. 보통 에이전트 성능이 아쉽다고 하면 모델을 바꾸거나 프롬프트 한 줄을 더 잘 쓰려고 하는데, 이 연구는 그 바깥쪽, 즉 과제를 배분하고 도구를 연결하고 권한을 정하는 하네스 자체를 고치는 쪽을 봅니다. 생각해보면 사람 조직도 비슷하게 움직입니다. 일 잘하는 사람을 뽑는 일과, 그 사람이 일하기 좋은 운영 방식을 만드는 일은 서로 다른 일이니까요. 그래서 저는 첫 장을 읽으면서부터 마음이 기울었습니다. 모델 점수를 올리는 이야기가 아니라, 모델이 일하는 판을 고치는 이야기였기 때문입니다.

그런데 판을 고친다는 말은 들을 때는 시원하지만 막상 손을 대면 막막해집니다. 어디를 고쳐야 할지, 얼마나 넓게 손대야 할지, 고친 뒤에는 어떻게 확인할지가 한꺼번에 몰려오기 때문입니다. 제가 현장에서 본 하네스 수정도 대개 이런 식이었습니다. 누군가 밤늦게 프롬프트를 조금 고치고, 다음 날 아침에는 도구 호출 순서를 바꾸고, 그 다음 주에는 권한 설정을 건드리는데, 무엇 때문에 좋아졌는지 나중에 아무도 설명하지 못합니다. 그렇다면 이런 고치기를 자동화하려면 무엇이 먼저 필요할까요. 이 질문이 바로 RobustSGPO가 출발하는 지점입니다.

실행 피드백이 있어도 막상 손댈 곳이 안 보이면요

이야기는 SGPO라는 앞선 방법에서 시작합니다. SGPO는 실행 피드백을 이용해 에이전트 하네스를 고치는 시도인데, 말하자면 시맨틱 그래디언트라는 이름으로 실패 원인을 언어로 받아 적고 그 지적을 다음 수정으로 연결합니다. 얼핏 들으면 TextGrad나 GEPA 같은 프롬프트 최적화 흐름과 닮아 있습니다. 이전 시도에서 배운 점을 다음 후보에 반영한다는 점에서는 같은 집안이라고 볼 수 있죠. 실제로 저도 처음에는 SGPO를 두고 프롬프트 자동 수정의 하네스版이라고 이해했습니다.

문제는 그다음입니다. 피드백이 있어도 무엇을 어느 범위로 고칠지, 그리고 어떤 동작으로 고칠지가 비어 있으면 탐색이 겉돌기 쉽습니다. 예컨대 실패 원인이 권한 설정에 있다고 합시다. 이때 문장 하나를 고치는 것으로 끝낼 수도 있고, 권한 스케줄 전체를 다시 짤 수도 있고, 아예 작업 분기 방식을 바꿀 수도 있습니다. 그런데 기존 SGPO의 국소 갱신 규칙은 이 선택을 정해주지 않는데, 그래서 같은 피드백을 받아도 어떤 때는 찔끔 고치고 어떤 때는 엉뚱한 곳을 건드리게 됩니다. 여러분도 코드를 고칠 때 비슷한 경험을 하셨을 겁니다. 에러 메시지는 분명한데 막상 고칠 파일이 세 군데로 흩어져 있어서 손이 망설여지는 경우 말이죠. 이럴 때 탐색은 넓어지는 것이 아니라 흐려집니다.

여기서 재미있는 질문이 생깁니다. 피드백 자체를 더 정교하게 만드는 게 먼저일까요, 아니면 피드백을 받아들이는 탐색 공간을 먼저 다듬는 게 먼저일까요. 연구팀은 후자를 택했습니다. 피드백 문장을 더 예쁘게 쓰는 대신, 수정의 범위와 동작을 어떻게 통제할지를 먼저 정한 것이죠. 저는 이 판단이 꽤 엔지니어답다고 봅니다. 숫자를 올리기 전에 실험 장치를 먼저 손보는 태도이기 때문입니다.

고치고 싶은 것을 먼저 문장으로 못 박는 이유는 뭘까

RobustSGPO의 첫 번째 장치는 요청된 수정을 명시하는 일입니다. 막연히 더 나아지게 고치라는 지시가 아니라, 무엇을 어느 범위에서 어떤 동작으로 바꿀지를 문장으로 먼저 적습니다. 이를테면 권한 일정을 손본다면 어느 단계에서 몇 단계로 늘릴지, 프롬프트를 손본다면 어느 블록을 덧붙이거나 덜어낼지를 미리 못 박는 식입니다. 이렇게 적어두면 탐색은 운이 아니라 약속을 따라 움직입니다. 나중에 왜 그 수정을 시도했는지 되짚을 수도 있고, 같은 약속을 다른 과제에도 그대로 적용할 수 있으니까요.

이 차이는 생각보다 중요합니다. 평소에 저희가 새로운 AI 구조를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데, 수정 요청이 문장으로 남아 있으면 그 추적이 훨씬 쉬워집니다. 반대로 요청이 없으면 후보는 매번 다른 방향으로 흔들리고, 좋아진 이유도 나빠진 이유도 설명하기 어렵습니다. 일종의 작업 지시서처럼요. 현장에서 구두 지시와 문서 지시가 다른 결과를 내는 것과 같은 이치입니다.

그렇다면 이런 명시가 탐색을 너무 좁히지는 않을까요. 저는 여기서 조금 의심했습니다. 미리 범위를 정하면 의외의 좋은 수정을 놓칠 수도 있으니까요. 그런데 연구의 답은 명시가 좁히는 것이 아니라 흩어짐을 막는 것이라는 쪽에 가깝습니다. 범위를 정해도 그 안에서 여러 후보를 만들 수 있고, 오히려 범위가 분명해야 실패 원인을 다음 약속에 반영하기 쉽기 때문입니다. 다음 장면에서 다룰 패치 검사가 바로 그 뒤를 받칩니다.

패치가 실제로 돌아가는지 바로 확인하는 습관이 갖는 힘

두 번째 장치는 패치를 직접 만들고 검사한다는 점입니다. 요청 문장이 있으면 그 문장을 하네스 코드나 설정에 대한 실제 패치로 옮기고, 그 패치가 실행 가능한지 바로 확인합니다. 여기서 실행 가능하다는 말은 단순히 문법이 맞다는 뜻을 넘어섭니다. 하네스가 실제로 돌아가고, 과제를 끝까지 수행할 수 있는 상태인지를 본다는 뜻에 가깝습니다. 그래서 깨진 패치는 일찍 버려지고, 살아남은 패치만 다음 평가로 넘어갑니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 하네스 진화에서는 그럴듯한 수정 제안이 실행 단계에서 무너지는 경우가 잦기 때문입니다. 권한을 넓혔다가 도구가 꼬이거나, 프롬프트를 다듬었다가 호출 순서가 어긋나는 식이죠. 이런 후보를 끝까지 평가하면 토큰과 시간이 그대로 샙니다. 반면 패치 단계에서 걸러내면 평가는 평가대로 아낄 수 있고, 탐색은 살아 있는 후보에만 집중할 수 있습니다. 밤사이 배치 실험을 돌려본 분이라면 이 감각을 바로 아실 겁니다. 아침에 로그를 열었을 때 깨진 실행이 절반이면, 그날은 점수 이전에 파이프라인부터 손봐야 하니까요.

개인적으로 인상 깊었던 점은, 이 검사가 품질 점수와 직결된다는 보고입니다. 실행 가능한 수정과 다른 출발점을 함께 썼을 때 품질이 좋아졌다는 대목인데, 이는 그럴듯한 말이 아니라 돌아가는 말이 더 좋은 점수를 받는다는 뜻입니다. 물론 검사가 모든 것을 보장하지는 않습니다. 돌아가기만 하고 내용은 밋밋한 후보가 있을 수도 있으니까요. 하지만 적어도 돌아가지도 않는 후보에 예산을 쓰는 일은 줄어듭니다. 그렇다면 남는 예산으로 무엇을 할 수 있을까요. 그 답은 탐색의 출발점을 늘리는 데 있습니다.

지금 자리에서만 출발하지 않으면 탐색은 어떻게 달라질까

세 번째 장치는 현행본 아니면 보관된 스냅샷에서 탐색을 이어간다는 점입니다. 보통 진화 탐색은 지금 가장 좋은 후보, 즉 현행본에서 다음 후보를 만듭니다. 그런데 현행본이 어느 순간 막다른 길에 들어서면 그 뒤의 시도는 죄다 그 골목 안에서 맴돕니다. RobustSGPO는 그래서 과거에 잘했던 스냅샷을 따로 보관해두고, 필요하면 그 스냅샷으로 돌아가 다시 출발합니다. 등산하다가 길을 잘못 들면 무조건 앞으로만 가지 않고, 아까 갈림길까지 내려가 다시 오르는 것과 비슷합니다.

이 장치가 좋은 이유는 실패를 버리는 대신 갈림길로 남기기 때문입니다. 현행본이 특정 과제군에 과하게 맞춰졌을 때, 보관된 스냅샷은 다른 방향의 가능성을 품고 있습니다. 그래서 연구의 표현을 빌리면, 탐색은 현행본 아니면 보관된 스냅샷 중 어느 쪽에서 이어갈지를 계속 고릅니다. 저는 이 대목을 읽으면서 오답 노트가 아니라 갈림길 지도에 가깝다고 느꼈습니다. 틀린 답을 모아두는 것이 아니라, 다시 출발할 수 있는 지점을 모아둔다는 점에서 말이죠.

여기서는 조금 조심해서 읽을 필요가 있습니다. 스냅샷을 많이 보관한다고 무조건 좋아지는 것은 아니기 때문입니다. 보관과 복원에는 비용이 들고, 너무 자주 돌아가면 탐색이 앞으로 나가지 못합니다. 실제로 연구에서도 보관에 따른 부담이 측정됐다고 보고합니다. 그럼에도 이 장치가 남기는 메시지는 분명합니다. 잘 고르는 일만큼 잘 돌아가는 일이 중요하다는 것이죠. 다음으로 볼 권한 일정 실험은 이 탐색이 구체적인 하네스 결정에서 어떻게 작동하는지 보여줍니다.

권한은 처음부터 풀어주는 게 답이 아니었습니다

이제 AgentX라는 브레인스토밍 흐름에서의 실험으로 들어가 보겠습니다. 전체 규모는 120개 과제와 95회 실행, 그리고 7,350번 후보 시도에 이릅니다. 숫자 자체도 적지 않지만, 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 단순히 점수를 한 번 잰 것이 아니라, 권한 일정과 누적 통제와 과제군 전이라는 서로 다른 층위에서 같은 장치를 시험했기 때문입니다.

그중 권한 일정 실험이 먼저 눈에 들어옵니다. 여기서 권한이란 에이전트가 한 번에 어디까지 손댈 수 있는지를 정하는 설정에 가깝습니다. 처음부터 권한을 최대로 풀어주면 편해 보이지만, 결과는 그렇지 않았습니다. 주기적으로 1에서 2, 그리고 3으로 넓혀가는 일정이 고정된 최대 권한보다 시험 점수에서 0.28점 앞섰기 때문입니다. 일반 파일에만 남겼을 때와 SOUL.md에 옮겨 적었을 때 결과가 갈렸던 앞선 멀티 에이전트 실험처럼, 어디에 무엇을 적어두는지보다 언제 무엇을 풀어주는지가 성패를 가른 셈입니다.

왜 이런 차이가 생길까요. 처음부터 많이 풀어주면 탐색은 일찍 편해지지만, 그만큼 엉뚱한 수정도 일찍 들어옵니다. 반면 단계적으로 풀어주면 초반에는 좁게 확실히 다지고, 뒤로 갈수록 넓게 시도할 수 있습니다. 아이에게 처음부터 도서관 전체를 맡기는 대신, 먼저 한 책장을 정리하게 하고 다음에 두 책장을 맡기는 것과 비슷합니다. (참고로 AgentX는 브레인스토밍 흐름을 운영하는 하네스인데, 아이디어를 내고 다듬고 추리는 과정이 권한 설정에 따라 꽤 민감하게 흔들립니다.) 저는 그래서 이 0.28이라는 숫자를 작은 차이로 보지 않았습니다. 같은 예산 안에서 일정을 바꾸는 것만으로 점수가 움직였다는 점에서, 운영의 문제이자 설계의 문제이기 때문입니다.

같은 토큰을 쓰고도 끝까지 끝내는 팀이 갈립니다

권한 일정이 하네스의 한 부속을 다룬다면, 다음 결과는 하네스 전체의 체감에 가깝습니다. 2천만 토큰이라는 같은 예산 아래에서, 따로 떼어둔 30개 과제에서의 완수율이 60.0%에서 80.0%로 올랐고, 시험 품질도 3.77에서 4.14로 함께 올랐기 때문입니다. 완수율은 끝까지 과제를 마쳤는지를 보고, 시험 품질은 그 결과가 얼마나 쓸 만한지를 봅니다. 둘 중 하나만 오르면 반쪽짜리 개선이지만, 여기서는 둘이 함께 움직였습니다. 그래서 저는 이 대목을 단순한 점수 상승이 아니라 일하는 방식의 변화로 읽었습니다.

이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 2천만 토큰이라는 예산이 함께 적혀 있다는 점이 바로 그 조건인데, 무제한으로 시도해서 얻은 결과가 아니라 같은 지갑 안에서 얻은 결과라는 뜻입니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 토큰을 어디에 썼기에 같은 돈으로 더 끝까지 가고 더 좋은 답을 냈을까요. 연구가 제시하는 답은 앞서 본 두 가지, 즉 실행 가능한 수정과 다른 출발점입니다. 깨지는 후보에 돈을 덜 쓰고, 막힌 길에서는 과거 갈림길로 돌아가 다시 쓰는 식으로 예산을 아꼈다는 것이죠.

그렇다면 이 흐름은 어디까지 일반화할 수 있을까요. 저는 여기서 마음을 조금 늦췄습니다. 30개 과제는 따로 떼어둔 평가용이지만, 과제 성격이 달라지면 완수율과 품질의 관계도 달라질 수 있기 때문입니다. 어떤 과제군에서는 완수는 쉬워도 품질이 안 오르고, 어떤 과제군에서는 그 반대가 생길 수 있습니다. 그럼에도 20%포인트라는 완수율 차이는 작지 않습니다. 특히 브레인스토밍처럼 중간에 멈추기 쉬운 흐름에서는 끝까지 간다는 것 자체가 품질의 전제 조건이 되니까요. 다음 장면인 과제군 전이는 이 개선이 이사를 간 뒤에도 이어지는지를 묻습니다.

이사 간 뒤에도 옛 동네 일을 기억해야 할까

하네스를 오래 쓰다 보면 과제군이 바뀌는 순간이 옵니다. 브레인스토밍 주제가 바뀌거나, 평가 방식이 달라지거나, 함께 쓰는 도구가 교체되는 식이죠. 이때 묻게 됩니다. 옛 과제에서 잘하던 방식을 얼마나 붙들고 있어야 할까요. 다 버리고 새 동네에 맞추면 새 일은 잘할지 몰라도 옛일은 못하게 되고, 옛 방식을 너무 붙들면 새일에 적응이 늦어집니다. 연구팀은 이 긴장을 전이 실험으로 들여다봤습니다.

결과는 한 줄로 정리하기 어렵습니다. 분야별로 스냅샷을 골라 보관하는 방식은 옮겨간 뒤에 옛 과제에서의 하락을 줄여줬지만, 무작위로 보관하는 방식은 새 도착점에서의 끝값이 더 높았기 때문입니다. 다시 말해 옛일을 덜 잊는 방법과 새일에서 더 높이 올라가는 방법이 갈라진 것이죠. 저는 이 갈라짐이 오히려 솔직해서 좋았습니다. 하나의 보관법이 모든 면에서 이겼다고 했다면 오히려 의심했을 겁니다. 현실의 이사도 마찬가지니까요. 옛 동네 친구를 자주 만나면 옛 인연은 이어지지만, 새 동네에 올인한 사람이 새 적응은 더 빠를 수 있습니다.

그렇다면 무엇을 골라야 할까요. 답은 하네스를 어디에 쓸지에 따라 달라집니다. 옛 과제와 새 과제를 함께 돌려야 하는 운영이라면 분야별 보관이 마음 편하고, 새 과제군으로 완전히 갈아타는 상황이라면 무작위 보관의 높은 끝값이 눈에 밟힐 겁니다. 여기서 중요한 것은 보관이라는 행위 자체가 공짜가 아니라는 점인데, 그 비용 이야기가 바로 다음 순서입니다.

공짜는 아니어서 오히려 믿음이 갑니다

지금까지의 이야기를 모으면 좋아 보이는 그림만 남을 수 있습니다. 수정은 분명해지고, 패치는 검사되고, 탐색은 갈림길에서 다시 출발하고, 점수는 오릅니다. 그런데 연구는 여기서 멈추지 않고 보관에 따른 부담을 함께 적었습니다. 저는 이런 대목을 보면 오히려 신뢰가 올라갑니다. 좋은 것만 골라 말하는 보고서보다, 비용까지 함께 적는 보고서가 현장에서 더 오래 살아남기 때문입니다.

부담의 내용은 어렵지 않습니다. 스냅샷을 보관하고 되돌아가려면 저장과 관리와 판단이 따라붙습니다. 언제 보관할지, 무엇을 버릴지, 어느 스냅샷에서 다시 시작할지를 정하는 일 자체가 연산과 토큰을 씁니다. 그럼에도 품질이 좋아졌다는 보고는 이 비용을 쓰고도 남는 이득이 있었다는 뜻입니다. 실행 가능한 수정으로 낭비를 줄이고, 다른 출발점으로 막힘을 풀었기에 가능한 수지 계산이죠. 저희가 새로운 AI 구조를 볼 때도 같은 잣대를 댑니다. 점수가 올랐는지만 보지 않고, 그 점수를 위해 어떤 저장과 통신과 재시작이 들었는지를 함께 묻습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 부담은 규모가 커지면 어떻게 변할까요. 과제가 120개에서 1,200개로 늘거나, 하네스가 여러 팀에서 동시에 돌아가면 보관 전략도 달라져야 할 겁니다. 어떤 스냅샷은 금방 낡고, 어떤 스냅샷은 오래 쓸모 있을 테니까요. 연구가 95회 실행과 7,350번 시도로 보여준 것은 끝이 아니라 시작점처럼 보입니다. 비용을 재면서 쓰는 탐색이야말로 운영에 올릴 수 있는 탐색이기 때문입니다.

그래서 다음에 하네스를 만진다면 저는 어디부터 볼까요

앞에서 미뤄둔 질문으로 돌아올 차례입니다. 피드백을 더 예쁘게 다듬는 일과 탐색 공간을 먼저 다스리는 일 중 무엇이 먼저일까요. 이 논문을 따라 읽은 뒤의 제 답은 후자에 가깝습니다. 무엇을 어느 범위에서 어떤 동작으로 고칠지를 먼저 정하고, 그 약속이 실제로 돌아가는지 바로 확인하고, 막히면 현행본이 아니라 보관된 갈림길에서 다시 출발하는 순서 말이죠. 이 순서는 거창하지 않지만, 밤사이 실험이 깨지는 이유를 하나씩 줄여줍니다.

제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째, 수정 명시의 언어가 더 정교해질 수 있는지입니다. 지금은 범위와 동작을 적는 수준이지만, 앞으로는 권한과 도구와 호출 순서까지 함께 적는 약속으로 넓어질 수 있을 겁니다. 둘째, 보관의 기준입니다. 분야별 보관과 무작위 보관이 갈라진 만큼, 과제군의 성격을 보고 보관법을 고르는 장치가 필요해 보입니다. 셋째, 더 큰 예산과 더 긴 전이에서의 움직임입니다. 2천만 토큰에서의 60.0%에서 80.0%로의 변화와 3.77에서 4.14로의 변화가 더 큰 규모에서도 같은 모양으로 이어지는지, 그리고 보관 부담은 어떻게 늘어나는지가 궁금합니다.

사람 조직으로 돌아가면 이야기는 더 단순해집니다. 일을 잘한다는 것은 재능의 문제이기도 하지만, 일을 맡기는 방식의 문제이기도 합니다. 언제 권한을 넓혀줄지, 실패한 시도를 어디에 적어둘지, 막힌 팀을 어느 갈림길로 되돌릴지를 정하는 일이 쌓이면 조직은 조금씩 나아집니다. 에이전트 하네스도 마찬가지라고 봅니다. 모델이 똑똑해지는 속도와 별개로, 그 모델이 일하는 판을 다스리는 기술이 따로 필요합니다. RobustSGPO는 그 판을 다스리는 한 가지 방법을 꽤 구체적인 손놀림으로 보여줬습니다. 그래서 저는 이 논문을 점수표가 아니라 작업 지침서처럼 읽었습니다. 다음에 하네스를 만질 때, 저는 먼저 물을 겁니다. 우리가 고치려는 것이 문장으로 적혀 있는지, 그 문장이 실제로 돌아가는지로 검사되는지, 그리고 돌아갈 갈림길이 어딘지에 말이죠.