에이전트의 실력은 모델 무게가 아니라 모델을 둘러싼 구조에서 갈린다. 우리는 이번 주에 그걸 숫자로 확인했다. 똑같은 모델로 글을 쓰게 했는데, 구조를 바꾸기 전에는 발행글 50편 중 40편에서 세부 왜곡이 나왔고, 바꾼 뒤에는 첫 발행부터 오류가 걸러졌다. 모델은 한 글자도 안 바뀌었다. 바뀐 건 하네스다.
이 글은 그 과정을 그대로 옮긴 기록이다. 하네스 엔지니어링(harness engineering)과 루프 엔지니어링(loop engineering)이 뭔지, 왜 지금 이 분야 논문이 쏟아지는지, 그리고 작은 팀이 실무에서 어떻게 써먹을 수 있는지를 우리 사례와 논문 세 편으로 풀었다.
하네스는 모델 바깥의 전부다. 구글 클라우드 AI 리서치가 올해 낸 RRSI 논문은 하네스를 이렇게 정의한다. "LLM 에이전트의 능력은 하네스에 의해 크게 증폭된다 — 즉 고정된 백본 모델을 둘러싼 프롬프트, 제어 흐름, 도구, 메모리, 컨텍스트 관리"(arXiv:2609.24972). 같은 모델이라도 무엇을 보여주고, 어떤 순서로 일을 시키고, 결과를 어떻게 검사하고, 실패하면 어디로 보내는지에 따라 결과물이 완전히 달라진다는 얘기다.
자동차에 비유하면 모델은 엔진이고 하네스는 나머지 전부다. 변속기, 브레이크, 계기판, 안전벨트. 엔진 출력이 같아도 변속기가 엉망이면 차는 느리고, 브레이크가 없으면 사고가 난다. 지난 몇 년은 다들 엔진 마력 경쟁을 했는데, 올해 나온 논문들을 보면 무게중심이 눈에 띄게 하네스 쪽으로 넘어오고 있다.
세 편만 짚어보자.
| 논문 | 핵심 주장 | 우리가 주목한 지점 |
|---|---|---|
| NeoHorse-1 (arXiv:2609.08183) | 운영 중인 라우팅 하네스가 남기는 실행 기록 자체가 다음 학습의 재료다 | 하네스는 실행 장치이면서 동시에 관측 장치다 |
| SoL-Pi (arXiv:2609.20519) | 하네스 개선을 자동 연구 루프로 돌려, 점수 하락을 몇 % 이내로 억제하면서 토큰 사용량을 44.7~49.0% 줄였다 | 하네스 개선 자체를 루프로 만들 수 있다 |
| RRSI (arXiv:2609.24972) | 하네스 자기개선은 과적합한다. 정규화 원리가 필요하다 | 루프에는 브레이크가 필요하다 |
NeoHorse-1 팀의 관찰이 특히 흥미롭다. 배포된 하네스는 매 턴마다 어떤 능력이 요구됐는지, 어떤 모델 등급이 선택됐는지, 그 뒤에 무슨 상호작용이 일어났는지를 기록으로 남긴다. 이 기록이 곧 "모델이 지금 무엇을 할 수 있고 무엇을 못 하는지"의 증거이고, 그 증거를 다음 라운드 학습으로 되먹이는 게 재귀적 자기개선(RSI)의 출발점이라는 것이다. 하네스를 잘 만들면 실행만 좋아지는 게 아니라, 시스템이 스스로를 관찰하는 눈까지 생긴다.
SoL-Pi는 한 발 더 나간다. NVIDIA와 NTU, MIT 연구진은 하네스 개선 작업 자체를 AI에게 맡겼다. 기본 하네스로 과제를 돌리고, 연구 AI가 실행 기록을 들여다보며 개선 후보를 내고, 능력과 효율 게이트로 후보를 걸러낸다. 이 루프에서 살아남은 메커니즘 네 개(액션 융합, 온라인 컨텍스트 압축, 관측 패킹, 증거 보존 축약)를 합친 하네스가 SoL-Pi인데, 51개 과제 벤치마크에서 기존 하네스 점수의 94% 안팎을 유지하면서 기록된 토큰 트래픽을 절반 가까이(44.7~49.0%) 줄였다. 약간의 점수를 내주고 비용을 크게 아낀 교환이고, 모델은 전혀 건드리지 않았다.
그런데 RRSI가 여기에 찬물을 끼얹는다. 하네스를 반복 수정하며 좋아지는 것처럼 보이는 시스템이, 실은 훈련 과제를 외워버린 경우가 많다는 것이다. 학습 분포 안에서는 점수가 크게 오르는데 분포 밖 벤치마크로 가져가면 이득이 쪼그라들거나 사라진다. 그래서 이 논문은 하네스 진화에 정규화를 건다. 수정을 한 번에 조금씩만 허용하고, 근거 없는 수정은 기각하고, 복잡도가 늘어나는 수정에는 페널티를 준다. 사람으로 치면 "시험 문제 풀이만 외우지 말고, 원리를 이해했는지 딴 문제로 확인하라"는 얘기다.
이론은 이 정도로 하고, 우리 얘기를 하겠다.
이 블로그는 매일 최신 논문을 골라 해설 글을 자동 발행한다. 논문 선정부터 집필, 발행까지 사람 손 없이 돌아간 지 한 달쯤 됐을 때, 발행된 50편 전체를 서로 다른 벤더의 모델 두 개로 소급 팩트체크해 봤다. 집필한 모델이 자기 글을 검사하면 제 눈의 들보를 못 보니, 검사관은 반드시 다른 회사 모델로 세웠다.
결과가 아팠다. 50편 중 40편에서 지적이 나왔다. 치명적 날조는 아니었지만 세부가 어긋나 있었다. 벤치마크 개수를 11개라고 썼는데 논문 본문 표를 세어보면 10개인 글. 논문이 계산·저장·대역폭 세 가지를 병목으로 지목했는데 "진짜 비용은 메모리"라고 단정해버린 글. 서로 다른 실험에서 나온 점수 세 개를 한 실험의 성과처럼 묶어버린 글.
원인을 파보니 하네스 문제였다. 집필 프롬프트가 논문 초록만 넣어주고 있었다. 초록은 논문의 예고편이다. 예고편만 보고 영화 리뷰를 쓰면 큰 줄거리는 맞아도 장면 묘사에서 틀리기 시작한다. 모델이 멍청해서가 아니라, 우리가 재료를 부족하게 준 것이다.
그래서 하네스를 세 군데 고쳤다.
첫째, 집필 단계에 논문 HTML 전문 발췌를 주입했다. 예고편이 아니라 본편을 읽고 쓰게 한 것이다.
둘째, 발행 직전에 이중 독립검증 게이트를 세웠다. 집필 모델과 다른 두 벤더의 모델이 각자 원문을 대조해 판정하고, 둘 다 통과해야 발행된다. 하나라도 걸리면 지적 사항을 반영해 수정하고 다시 검증한다.
셋째, 수정해도 통과 못 하면 발행을 보류하고 관리 채널로 보고한다. 어중간한 글을 내보내느니 그 회차를 건너뛰는 쪽을 택했다.
고친 하네스로 돌린 첫 발행에서 바로 효과가 나왔다. 새 논문 해설 초안에서 검증 게이트가 "실측 범위 과장"을 잡아냈다. 초안은 두 실험 트랙 모두 다섯 단계까지 측정됐다고 썼는데, 원문을 대조하니 트랙마다 측정 범위가 달랐다. 게이트가 이 지적을 수정 단계로 넘겼고, 고쳐진 원고가 재검증을 통과한 뒤에야 발행됐다. 사람은 한 번도 개입하지 않았다.
기존 40편도 같은 루프에 태웠다. 지적을 반영해 수정하고, 재검증을 통과한 글만 다시 실었다. 두 번 고쳐도 통과 못 한 글은 내렸다. 독자 입장에서 달라진 건 없어 보이겠지만, 지금 이 블로그의 글은 전부 두 명의 외부 검사관을 통과한 원고다.
위 이야기에서 하네스만큼 중요한 게 루프다. 검증 게이트는 한 번 판정하고 끝나는 문이 아니라, 실패를 되먹여 다시 시도하는 순환 구조로 짜야 작동한다.
우리가 루프를 짤 때 반드시 넣는 요소가 네 가지 있다.
종료 조건. 루프는 반드시 끝나야 한다. 우리 수정 루프는 두 바퀴까지만 돈다. 두 번 고쳐도 검증을 통과하지 못하면 그 글은 보류다. 종료 조건 없는 루프는 개선이 아니라 배회다. RRSI가 하네스 진화에 수정 횟수 제한과 채택 기준을 거는 것도 같은 원리다.
폴백 경로. 주력 수단이 막혔을 때 갈 곳을 미리 정해둔다. 우리 집필 단계는 주력 모델이 한도에 걸리면 예비 모델로 자동 전환된다. 이걸 안 만들어두면 어떻게 되는지도 겪어봤다. 예전 파이프라인은 모델이 한도 안내문을 뱉으면 그걸 본문으로 알고 발행을 시도하다가 사흘 연속 빈손으로 끝난 적이 있다. 폴백은 사치가 아니라 기본 배관이다.
재개 가능성. 긴 배치 작업은 반드시 중간부터 다시 시작할 수 있어야 한다. 50편 소급 감사는 편당 몇 분씩 걸리는 작업이라, 처리한 글의 번호를 파일로 남기고 재실행하면 남은 것만 이어서 돌게 만들었다. 40편째에서 네트워크가 끊겼다고 처음부터 다시 도는 구조라면 그 루프는 실전용이 아니다.
실패의 기록과 원상복구. 실패한 회차는 흔적을 지우는 게 아니라 기록을 남기고 상태를 되돌린다. 우리 발행 워커는 논문을 선점해두고 시작하는데, 발행에 실패하면 선점을 해제해서 다음 회차가 같은 논문을 다시 시도할 수 있게 한다. 실패가 시스템을 잠그면 안 된다.
약한 루프와 강한 루프의 차이를 한 줄씩 대조하면 이렇다.
문장은 길어졌지만, 새로 들어간 단어 하나하나가 실제 장애 상황 하나씩을 막고 있다.
거창한 프레임워크가 필요한 게 아니다. 우리 게이트도 핵심은 "다른 모델에게 판정 형식을 정해 물어보고, 답을 파싱해서 분기하는" 몇십 줄짜리 코드다. 시작할 때 순서는 이렇게 잡으면 된다.
한 가지 경고. RRSI의 교훈대로, 게이트 통과율이 올라간다고 무조건 좋아하면 안 된다. 검사관에게 잘 보이는 요령만 학습된 것일 수도 있다. 우리가 검사관을 두 벤더로 나누고 원문 대조를 시키는 것도, 한 검사관의 취향에 과적합하는 걸 막기 위해서다.
온틀은 AI 프로젝트 매니저를 파견하는 서비스라, 위 원리들이 곧 제품이다. 고객 요청을 접수하고, 처리하고, 산출물을 만들고, 보고하는 전 과정이 하네스와 루프로 짜여 있다. 요청이 막히면 감시 루프가 정체를 알아채고, 산출물은 검증을 거쳐 나가고, 실패한 작업은 기록과 함께 재시도 경로로 돌아간다. 이 블로그의 발행 파이프라인은 그 구조의 축소판이자, 새 메커니즘을 먼저 실험해보는 시험대이기도 하다.
모델은 계속 좋아질 것이다. 하지만 어떤 모델이 오든, 그 모델로 무엇을 안정적으로 만들어낼 수 있느냐는 결국 하네스와 루프를 설계하는 쪽의 몫으로 남는다. 우리가 이번에 40편을 고치며 배운 게 그거다.
프롬프트는 하네스의 부품 하나다. 하네스 엔지니어링은 프롬프트에 더해 제어 흐름, 도구 연결, 메모리, 컨텍스트 관리, 검증 게이트, 실패 경로까지 시스템 전체를 설계한다. 우리 사례에서도 문제 해결의 핵심은 프롬프트 문구가 아니라 입력 재료(논문 전문)와 검증 구조였다.
같은 모델 계열로 검증하면 같은 맹점을 공유할 위험이 있다. 또 한 검사관에게만 맞추다 보면 그 검사관의 성향에 과적합한다는 게 RRSI가 지적하는 위험이다. 우리는 서로 다른 두 벤더 모델의 판정을 모두 통과해야 발행하는 규칙을 쓴다.
가능하다. 핵심 게이트는 "판정 형식을 고정해 다른 모델에 묻고, 응답을 파싱해 분기"하는 수준의 코드다. 처음부터 자동 수정 루프까지 갈 필요도 없다. 발행 전 판정 하나만 세워도 우리 기준 80%였던 세부 왜곡이 걸러지기 시작한다.
SoL-Pi는 하네스 개선을 자동 연구 루프로 돌려, 점수를 94% 안팎으로 유지하는 대신 토큰 트래픽을 44.7~49.0% 줄이는 메커니즘을 찾아냈고, NeoHorse-1은 하네스 실행 기록을 다음 학습의 재료로 쓰는 경로를 제시했다. 다만 RRSI가 보여주듯 무제한 자기개선은 과적합하므로, 실무에서는 채택 기준과 수정 제한 같은 브레이크를 함께 설계해야 한다.