에이전트에서 모델이 하는 일은 생각보다 좁다. 다음에 무슨 말을 할지, 어떤 도구를 부를지 '제안'할 뿐이다. 그 제안을 실제 실행으로 옮기는 건 모델을 감싼 소프트웨어다. 이 소프트웨어가 모델에게 어떤 정보를 보여줄지, 어떤 도구를 어떤 순서로 쓰게 할지, 언제 멈출지를 정한다. 이걸 하네스(harness)라고 부른다. 모델이 똑같아도 하네스가 다르면 에이전트는 딴판으로 움직인다.
그래서 에이전트를 더 똑똑하게 만드는 길은 둘뿐이다. 모델 자체를 다시 학습시키거나, 모델을 감싼 하네스를 고치거나. 이 논문은 두 번째 길만 판다. 모델 가중치는 손도 대지 않고 프롬프트·메모리·워크플로우·실행 코드만 실행 결과를 보고 스스로 고친 뒤, 그 수정본을 다음 실행에 그대로 물려주는 과정을 정식으로 정의한다.
놀라운 건, 하네스만 잘 손봐도 작은 모델이 큰 모델을 앞서는 장면이 나온다는 점이다. 하지만 이 논문이 정작 공을 들인 곳은 그 반대편이다. 스스로 고치다 보면, 고친 게 진짜 나아진 건지 아니면 그 평가 문제에만 요령껏 맞춰진 건지 구별하기 어려워진다. 좋아 보이는 수정이 사실은 과거에 잘 되던 걸 조용히 망가뜨리고 있을 수도 있다. 이 착각을 어떻게 걸러내느냐 — 그게 이 글이 끝까지 끌고 갈 질문이다.
미리 성격을 밝혀두면, 이 논문은 새 시스템을 만들어 벤치마크를 쓸어 담는 종류가 아니다. '자가진화 하네스'라는 분야를 정의하고, 흩어진 방법들을 분류하고, 신뢰성 조건을 PAC-learning(적은 표본으로도 높은 확률로 처음 보는 데이터에서 통함을 보장하려는 통계 학습 이론)으로 유도하는 66쪽짜리 종합 논의다. 뒤에 나오는 실험 수치도 저자들이 직접 돌린 게 아니라 선행 연구에서 가져와 예시로 붙인 사례다. 숫자는 '이런 일이 관찰됐다'는 사례로 읽어야 한다. 저자들은 이 분야를 '하네스 RSI(recursive self-improvement, 재귀적 자기개선)'라 부르면서도, 이름에 '개선'이 들었다고 매 수정이 도움이 된다고 전제하지 않는다는 단서를 분명히 단다.
배포가 끝난 에이전트는 멈춰 있지 않다. 다루는 업무가 바뀌고, 환경이 바뀌고, 평가 기준도 바뀐다. 처음 설계한 프롬프트와 워크플로우가 석 달 뒤에도 최선이라는 보장은 없다. 여기서 적응의 선택지가 갈린다.
하나는 모델 가중치를 다시 건드리는 길이다. 성능은 오를 수 있지만 재학습 비용이 들고, 체크포인트가 쌓이고, 모델이 왜 달라졌는지 추적하기 어렵다. 상용 API 뒤에 있는 모델은 가중치 접근 자체가 막혀 있다. 다른 하나가 하네스를 고치는 길이다. 고정된 모델의 행동을 실제로 빚어내는 건 결국 하네스이고, 기존 배포를 그대로 재활용하니 재학습도 체크포인트도 필요 없다. 무엇보다 지시문·메모리·코드는 사람이 눈으로 열어 읽고 버전을 비교하고 변경을 추적할 수 있다. 가중치 diff와는 다르다.
이 길 자체는 새롭지 않다. 뿌리가 둘 있다. 하나는 EURISKO로, 경험에 따라 규칙을 고쳐나갔다. 다른 하나는 Gödel Machine으로, '이득이 증명될 때만' 자기 코드를 다시 쓰게 했다. 요즘 방법들(Reflexion, ExpeL, Voyager, AFlow, GEPA, Promptbreeder 같은 계열)은 대체로 전자 쪽이다. 경험 피드백으로 프롬프트를 고치고 메모리를 다지고 워크플로우를 탐색한다. 유연하다. 그런데 바로 그 유연함이 빈자리를 남긴다. 경험으로 고친 수정이 진짜 개선인지, 운 좋게 맞은 건지 보증할 방법이 없다. 매 수정을 증명하라고 요구하면(Gödel Machine 쪽) 현실의 에이전트는 한 발도 못 뗀다.
게다가 방법마다 무엇을 고치는지, 후보를 어떻게 만드는지, 어떤 기준으로 받아들이는지가 제각각이었다. 그래서 이 논문은 공통 언어부터 세우고, 비어 있던 신뢰성 보증을 '증명' 대신 '통계적 보장'으로 채우려 한다. 경험의 유연함은 살리되, 아무 수정이나 받아들이지는 않는 선을 긋는 것이다.
말보다 한 장면이 빠르다. 에이전트가 스프레드시트 과업을 돌리다 출력 점검을 건너뛰어 틀린 결과를 냈다고 하자. 그 실패가 피드백으로 남는다. 업데이트를 맡은 쪽이 원인을 진단하고("출력 점검 단계가 없다"), 수정안을 제안하고(점검 단계 추가), 새 데이터로 평가하고, 나아졌으면 채택한다. 채택된 수정은 저장돼 다음 실행에 로드된다. 받아들일 만한 수정이 없으면 기존 하네스를 그대로 둔다.
이게 한 바퀴다. 현재 하네스가 여러 번 실행(rollout)을 돌려 각각의 궤적·결과·피드백을 모으고, 업데이트 연산자가 진단·제안·평가·채택을 묶어 수행하고, 채택본이 다음 바퀴로 넘어간다. 두 조건 — 자기 실행 피드백으로 수정을 만들어 그 메커니즘을 계속 유지한다는 점, 그리고 채택본이 다음 실행으로 계승된다는 점 — 이 둘이 충족될 때만 '하네스 자가진화'라 부른다. 고정된 규칙으로 로그를 덧붙이거나 컨텍스트를 압축하는 건 여기 들지 않는다. 스스로 배우는 게 아니라 정해진 대로 돌 뿐이니까.
하네스 자체는 일곱 가지 런타임 기능으로 쪼개지는데, 외우기보다 세 묶음으로 쥐고 있으면 된다.
자가진화가 건드리는 건 결국 이 셋 어딘가다.
논문은 '무엇을 고치느냐'를 두 갈래로 가른다. 하나는 해석되는 상태(interpreted state) — 지시문, 저장된 경험, 고정된 능력들 위에서 돌아가는 과업 수준의 조정이다. 다른 하나는 실행 가능한 수정(executable revision) — 능력의 구현 자체, 레포지토리 수준의 제어 논리, 플러그인으로 묶이는 서비스 구성을 바꾸는 것이다.
비유하면 전자는 요리사에게 건네는 레시피 카드를 고쳐 쓰는 일이고, 후자는 주방의 조리 기구와 배관을 뜯어고치는 일이다. 이 비유가 말해주는 건 딱 하나다. 지시를 바꾸는가, 그 지시를 실행하는 장치를 바꾸는가. 기준은 편집한 파일이 무슨 언어로 쓰였느냐가 아니라, 그 산출물이 시스템에서 맡은 역할이다. 같은 워크플로우 수정이라도 고정된 인터페이스 위에서 순서만 바꾸면 해석되는 수정이고, 그 조정을 실제로 집행하는 런타임 메커니즘을 건드리면 실행 가능한 수정이다.
한 가지는 분명히 떼어둬야 한다. 수정의 '종류'와 '영향 범위'는 같은 말이 아니다. 레시피 한 장을 고쳐도, 그 레시피가 여러 매장에서 공유되고 있으면 영향은 매장 전체로 번진다. 영향 범위는 이 수정이 공유되는지, 어디에 적용되는지를 따로 보고 판단해야 한다. 실행 가능한 수정이 더 멀리 번지기 쉽다는 건 맞지만, 해석되는 수정이라고 좁은 데 머문다는 보장은 없다.
이 논문의 중심축은 이론이다. 그런데 이론을 이름으로 외울 필요는 없다. 원리 하나만 손에 쥐면 나머지가 따라온다.
원리는 이렇다. 같은 평가 문제를 보며 수정을 거듭하면, 그 수정은 점점 그 문제에만 맞춰진다. 시험을 미리 보고 그 시험지에만 맞춰 공부한 셈이다. 그래서 채택 판정은 수정을 만들 때 쓴 데이터가 아니라, 손대지 않은 신선하고 독립적인 검증 데이터로 해야 한다. 거기서도 높은 확률로 개선이 확인될 때만 받아들인다 — 이게 '고확률 채택 규칙'이다. 평가 데이터에서만 좋아 보이는 수정을 걸러내는 그물이다.
두 번째는 회귀(regression) 예산이다. 회귀란 과거에 되던 기능이 조용히 깨지는 것을 말한다. 수정이 하나씩 쌓이면 이 깨짐도 쌓인다. 그래서 '허용할 기존 기능의 성능 하락 한도'를 미리 정해두고, 그 한도 안에서만 수정을 받는다. 가령 새 업무의 정답률은 올라갔는데 기존 업무에서 되던 일부가 깨졌다면, 그 깨진 폭이 정해둔 한도를 넘는 순간 그 수정은 보류한다. 새 성능이 좋아졌다는 사실만으로는 채택 근거가 못 된다. 유지(retention) 바운드는 바로 이 누적 회귀가 예산 안에서 통제될 때만 의미를 갖는다. 여기에 명시된 가정 아래에서의 기대 일반화 바운드까지, 세 결과가 후보 탐색을 진화적 최적화(evolutionary optimization, 여러 후보를 만들고 좋은 것만 남겨 다음 세대로 잇는 탐색)에 대응시켜 유도된다.
마지막으로 설계 원칙 하나. 후보 하네스는 내부 비평자나 중간 점검은 고칠 수 있지만, 최종 채점·검증을 맡는 평가자 자체는 건드리지 못하게 막는다. 채점표를 쥔 손이 응시자여서는 안 되기 때문이다. 이 격리가 없으면 위의 두 그물이 통째로 무력해진다.
이제 숫자를 볼 차례인데, 앞서 말했듯 저자들의 자체 실험이 아니라 선행 연구에서 가져온 사례다. 어느 연구의 어떤 조건인지를 특히 조심해서 봐야 한다.
첫 사례는 SpreadsheetBench(스프레드시트 과업 벤치마크)에서의 HarnessOpt다. 스킬 편집에 머물던 SkillOpt-Lite를 런타임 수정으로 확장해, 스프레드시트 미리보기·출력 점검·도구 실패 후 복구를 개선한 방법이다. 선행 연구(shen2026skilloptlite)의 비율을 환산한 수치가 논문 Table 2에 있다.
| 모델 | Initial | SkillOpt | SkillOpt-Lite | HO only | HO + skill |
|---|---|---|---|---|---|
| GPT-5.4-nano | 29.89 | 51.60 | 66.19 | 76.51 | 77.58 |
| GPT-5.4-mini | 28.21 | 47.50 | 73.31 | 81.14 | 82.56 |
| GPT-5.4 | 39.86 | 61.50 | 79.36 | 83.63 | 85.05 |
| GPT-5.5 | 37.37 | 76.20 | 79.72 | 83.63 | 85.77 |
여기 글 첫머리에서 말한 장면이 있다. 가장 작은 GPT-5.4-nano에 HarnessOpt와 스킬을 붙인 조건(77.58%)이, 더 큰 GPT-5.5에 SkillOpt만 붙인 조건(76.20%)을 넘어선다. 네 모델 전체에서 HarnessOpt+스킬은 SkillOpt-Lite보다 5.69~11.39%p 높았다. 작은 모델에 좋은 하네스를 입히는 편이 큰 모델에 약한 하네스를 입히는 것보다 나을 수 있다는 것 — 모델과 하네스의 짝맞춤이 모델 크기만큼이나 결과를 가른다는 신호다.
다만 이 교차가 '같은 비용에서의 우위'를 뜻하지는 않는다. 작은 모델이 이겼다 해도, 하네스를 최적화하는 데 들어간 연산 비용까지 맞춰 비교한 결과가 아니다. 이 수치가 재는 건 특정 조건의 정확도이지, 비용 대비 효율이 아니다.
두 번째 사례는 'Everything Is a Plugin(EIP)'이다. Codex 플러그인이 실행 도중 필요한 도구를 스스로 만들어 이후 과업에 재사용한다. 모의 사무 작업에서 지역별 스프레드시트는 언어와 내용은 달라도 계산은 비슷했고, Codex는 배치 조회·요약 도구를 만들어냈다. 그 덕에 첫 과업의 도구 호출이 13회에서 3회로 줄었다. 대신 도구를 만드느라 첫 과업에서는 토큰과 시간이 더 들었다 — 초기 투자인 셈이다. 그 투자는 두 번째 과업부터 회수되고, 다섯 과업을 누적하면 토큰과 시간을 아끼는 쪽으로 넘어간다. 다만 저자들은 첫 과업 집계와 누적 집계의 숫자가 서로 어긋나, 둘을 하나의 비용 궤적으로 이어 말할 수 없다고 명시한다.[^1] 도구를 만드는 초기 비용과 이후의 재사용 이득이 핵심이고, 그 둘을 한 줄로 그릴 수는 없다는 단서까지가 이 사례에서 가져갈 전부다.
온틀은 사람을 더 못 뽑아 반복 업무가 쌓이는 소기업과 1인 창업가에게, 그 반복 업무를 AI가 대신 처리하도록 붙여주는 서비스다. 한 장면을 끝까지 따라가 보자(실제 운영이 아니라 적용 시나리오다).
온틀의 AI PM이 여러 고객사에서 '주간 진행보고 작성'을 맡고 있다. A사에서 "보고가 너무 길다"는 피드백이 돌아오면, PM은 보고 템플릿 프롬프트를 '핵심 3줄 + 리스크 섹션'으로 고친다. 논문 용어로 해석되는 상태 수정이다. 더 나아가 진행 데이터를 긁어오는 조회 도구를 새로 만들어 보고 생성 파이프라인에 끼워 넣으면, 그건 실행 가능한 수정, 그중에서도 플러그인 구성에 가깝다.
이 논문이 바꾸는 지점은 '그 수정을 언제 믿고 다른 고객사로 퍼뜨리느냐'다. A사 피드백으로 만든 수정본은 A사에서 쓴 바로 그 데이터가 아니라, 손대지 않은 다른 주간 분량으로 검증을 통과해야 채택한다. 그리고 B사로 넘기기 전에, 그 수정이 B사의 기존 보고 품질을 깎지 않는지를 회귀 예산 안에서 확인한다. A사에 맞춰 짧게 줄인 템플릿이, 규제 보고가 중요한 B사에서는 오히려 필수 항목을 누락시키는 회귀일 수 있기 때문이다.
그래서 이 사례가 남기는 건 '온틀이 잘한다'는 결론이 아니라, 당장 풀어야 할 설계 질문들이다. 고객사마다 '빠뜨리면 안 되는 필수 항목'은 누가 정하고 누가 평가하는가. 모든 고객사에 공유되는 공통 템플릿 수정과, 한 고객사에만 적용할 수정은 어디서 가르는가. 평가 기준이 고객사마다 다른데, '신선한 독립 검증 데이터'는 현장마다 어떻게 확보하는가. 이 질문에 답을 가진 조직만이 자가진화를 실제로 켤 수 있다.
이 논문의 성과는 특정 점수가 아니라 틀에 있다. 흩어져 있던 방법들을 '무엇을 고치는가(업데이트 대상)'와 '어떻게 제안·채택하는가'라는 두 축으로 분리하고, 경험적 선택만으로는 일반화도 유지도 보장되지 않는다는 점을 통계적 보장으로 받아낸 것이다.
한계도 같은 자리에 있다. 이론의 바운드는 모두 명시된 가정 아래에서만 성립하고, 실험은 선행 연구에서 빌려온 사례라 이 프레임워크가 통제된 조건에서 재현한 결과가 아니다. SpreadsheetBench 교차는 같은 비용에서의 우위가 아니고, EIP 비용 보고는 앞서 본 불일치를 안고 있다. 그리고 평가자 분포가 계속 바뀌는 환경에서 신선한 독립 검증 데이터를 꾸준히 확보하는 일 자체가 만만치 않은 숙제로 남는다. 틀을 세운 공은 크지만, 그 틀이 실제 배포에서 얼마나 예측력을 갖는지는 후속 실증의 몫이다.
실무로 가져갈 땐 이 체크리스트가 전부다.
아닙니다. 자가진화는 시스템이 자기 실행 피드백에서 스스로 수정을 만들어내고, 그 수정 메커니즘이 계속 돌면서 채택본이 다음 실행으로 넘어가는 경우를 말합니다. 사람이 직접 고치는 건 다른 작업입니다. 다만 사람이 고치더라도 신선한 검증 데이터로 채택을 판정하고 회귀 예산을 관리하라는 원칙은 똑같이 적용할 수 있습니다.
발상은 닮았습니다. 여러 후보를 만들고 평가해서 좋은 것만 남겨 다음 세대로 잇는 구조라는 점에서요. 논문은 이 구조에 안정성·집중 부등식 같은 고전적 통계 결과를 끌어와 바운드를 유도합니다. 핵심은 알고리즘 이름이 아니라, '여러 후보를 평가해 고른다'는 틀이 통계적 보장을 얹을 수 있는 형태라는 점입니다.
가중치 접근이 막혀 있다는 건 하네스를 택하는 여러 이유 중 하나일 뿐입니다. 열 수 있어도, 재학습 비용이 들지 않고 변경을 사람이 읽고 버전을 비교할 수 있다는 이점은 그대로입니다. 어디가 왜 달라졌는지 추적해야 하는 운영 환경이라면, 가중치를 열 수 있어도 하네스 쪽 수정이 더 다루기 쉬운 경우가 많습니다.
논문은 '예산으로 관리하라'는 역할만 줍니다. 허용할 하락 폭을 얼마로 잡을지는 수치로 유도되는 게 아니라, 그 기능이 깨졌을 때의 사업적 위험에 따라 조직이 정하는 정책 판단입니다. 규제 보고처럼 누락이 치명적인 영역은 한도를 빡빡하게, 내부 메모처럼 여유 있는 영역은 느슨하게 잡는 식으로 업무마다 다르게 설정하는 게 자연스럽습니다.
[^1]: 첫 과업: 도구 호출 13→3회, 토큰 41,119→47,572, 벽시계 15.49→24.00초(토큰 +15.7%, 시간 +54.9%). 다섯 과업 누적으로는 110,351 토큰·22.97초 절약으로 보고된다. 다만 첫 과업이 암시하는 증가분(6,453 토큰·8.51초)과 누적 집계 1행(4,895 토큰·6.74초)이 어긋나, 두 보고를 하나의 비용 궤적으로 합칠 수 없다.