AI 에이전트는 크게 두 부분으로 나눠 볼 수 있습니다. 하나는 두뇌 역할을 하는 모델입니다. 사람 말을 알아듣고 글을 만드는 대규모 언어 모델(LLM)이죠. 다른 하나는 이 두뇌가 실제로 일을 해내도록 돕는 손발입니다. 프롬프트를 어떻게 짜는지, 여러 단계를 어떤 순서로 밟는지, 어떤 도구를 언제 부르는지, 무엇을 기억할지. 이 손발 전부를 묶어 하네스라고 부릅니다.
여기서 흥미로운 사실 하나. 두뇌를 그대로 둔 채 손발만 잘 다듬어도 같은 모델이 눈에 띄게 똑똑해집니다. 그래서 최근에는 이 손발 다루는 법 자체를 에이전트가 스스로 고치게 만드는 시도가 나옵니다.
문제는 이렇게 풀어놓으면 에이전트가 곧잘 '똑똑한 바보'가 돼서 돌아온다는 겁니다. 연습 문제 점수는 쭉쭉 오릅니다. 그런데 연습에 없던 새 문제를 만나면 실력이 뚝 떨어집니다. 원리를 익힌 게 아니라 정답지를 통째로 외운 탓이죠. 머신러닝에서는 이걸 과적합이라 부릅니다. 구글의 RRSI 연구는 바로 이 과적합에 고삐를 채웁니다. 그 결과 처음 보는 문제에서도 성능이 유지됐고, 덤으로 쓰는 비용까지 줄었습니다.
손발을 스스로 고친다는 게 구체적으로 뭘까요. 에이전트가 자기 하네스를 조금씩 바꾼 후보를 내놓고, 그중 좋은 것을 골라 반영하기를 반복합니다. 이게 재귀적 자기개선, 줄여서 RSI입니다. 두뇌(모델)는 손대지 않습니다. 두뇌를 쓰는 요령만 스스로 자라는 거죠.
과적합은 이 자동 진화 과정에서 벌어집니다. 진화에 쓴 과제 안에서는 점수가 크게 뜁니다. 이렇게 진화에 쓴 과제와 성격이 같은 영역을 '분포 안', 성격이 다른 처음 보는 과제를 '분포 밖'이라 합니다. 분포 안에서 오른 실력이 분포 밖으로 넘어가면 쪼그라들거나 사라집니다. 어디서나 통하는 기본기가 아니라 이 시험에서만 먹히는 요령을 익힌 셈입니다.
RRSI(Regularized Recursive Self-Improvement, 규제된 재귀적 자기개선)의 핵심은 자기개선 과정 안에 '규제'를 심은 데 있습니다. 모델이 훈련 데이터를 외우지 못하도록 규제를 거는 머신러닝의 오랜 방식을, 이번엔 하네스가 진화하는 과정에 그대로 가져온 겁니다.
진화는 두 역할이 주고받으며 돌아갑니다. 새 변화를 들고 오는 제안자, 그중 무엇을 남길지 고르는 선택자. RRSI는 이 둘 모두에 규제를 겁니다.
제안자 쪽부터 보죠. 가장 중요한 장치가 시간에 따라 줄어드는 수정 예산입니다. 한 번에 바꿀 수 있는 수정 개수에 상한을 두되, 진화가 진행될수록 이 상한을 점점 조입니다. 금속을 뜨겁게 달궜다가 서서히 식혀 단단하게 굳히는 담금질(annealing)에서 따온 방식입니다. 원리는 이렇습니다. 초반에는 해법 공간을 넓게 탐색하도록 크게 바꿀 여지를 열어 둡니다(뜨거운 상태). 그러다 점차 변화의 폭을 줄여 좋은 해법 하나로 안정적으로 수렴시킵니다(서서히 식히는 상태). 처음부터 끝까지 한 번에 열 군데씩 뜯어고치면, 무엇이 효과였는지 가려낼 수 없고 우연히 연습 과제에만 맞아떨어진 변화가 섞여 들기 쉽습니다. 뒤로 갈수록 작고 신중하게 손보게 만드는 이유죠.
여기에 하나 더. 지금까지의 진화 이력을 참고해, 이미 여러 번 시도한 방향은 뒤로 미루고 아직 안 가본 변화를 앞세웁니다. 같은 방향으로만 깊이 파고들다 연습 과제에 딱 맞춰지는 걸 막는 장치입니다.
선택자는 올라온 제안을 두 개의 필터에 차례로 통과시킵니다. 첫째는 보편성 필터입니다. 이 제안이 이 시험에만 특화된 수정인지, 아니면 처음 보는 과제에서도 통할 기본기인지 따집니다. 분포 밖에서 무너질 제안을 여기서 걸러냅니다. 둘째는 효율성 필터입니다. 이미 반영된 변화 중 너무 사소하거나, 비용이 크거나, 더는 쓸모없어진 것을 잘라냅니다.
예를 들어 보죠. 제안자가 "코드 과제를 풀 때 파일 전체를 넣지 말고 관련 함수만 골라 넣자"는 수정을 내놓았습니다. 보편성 필터는 묻습니다. 이게 특정 과제에서만 통하는 요령인가, 어떤 코딩 과제에도 통하는 기본기인가. 범용이라 판단되면 채택합니다. 시간이 지나 그 수정이 비용만 키우고 효과가 흐려지면, 이번엔 효율성 필터가 걷어냅니다. 새 시도, 보편성 검사, 효율성 검사를 반복하다 보면 진화는 자연스럽게 재사용 가능한 범용 메커니즘을 시험 전용 요령보다 선호하게 됩니다. 가지치기 덕에 하네스가 가벼워져 토큰을 덜 쓰는 건 실용적인 보너스고요.
RRSI는 코딩, 에이전트형 워크스페이스, 엔지니어링 설계에 걸친 여덟 개 벤치마크에서 검증됐습니다. 각 환경에서 얻은 핵심 성과를 나눠 보면 다음과 같습니다. 표를 읽기 전에 용어 하나만. 토큰은 AI가 글을 읽고 쓸 때 다루는 최소 단위(대략 단어 조각)인데, 그중 정책 토큰은 에이전트가 실제로 '무엇을 할지' 결정하는 데 쓰는 토큰을 말합니다.
| 어디서 얻은 성과인가 | 보고된 수치 |
|---|---|
| 진화에 쓴 과제(분포 안) — 코딩 과제 계열 | 최대 14.1점 향상 |
| 분포 밖 5개 벤치마크 — 에이전트형 워크스페이스(JobBench) | 최대 4.7점 향상 |
| 토큰 효율 — 규제 없는 진화와 비교 | 정책 토큰 30% 절감 |
세 수치는 서로 다른 과제와 설정에서 나온 각각의 최고점입니다. 그래서 "이만큼 지키면서 저만큼 더 얻었다"고 한 줄에 세워 읽으면 곤란합니다. 분포 안 향상과 분포 밖 향상은 애초에 다른 과제에서 나온 값이라 나란히 비교할 대상이 아닙니다.
그래도 한데 묶으면 방향이 또렷합니다. 규제로 과적합을 줄였더니 연습 과제에서 크게 올랐고, 처음 보는 과제에서도 향상이 남았으며, 토큰은 오히려 덜 썼습니다. 점수 올리기와 새 문제로의 일반화, 비용 절감이 서로 배타적이지 않다는 것. 이것이 이 논문의 메시지입니다.
다만 분포 밖 향상이 '최대'로도 분포 안만큼은 아니라는 점은 정직하게 읽을 필요가 있습니다. 규제가 과적합을 줄이기는 해도 완전히 없애지는 못한다는 신호죠. 두 수치가 다른 과제에서 나온 만큼 단정할 일은 아니지만, '규제했으니 과적합이 사라졌다'고 과하게 기대할 근거도 아닙니다.
좋은 결과지만, 제품에 올리기 전이라면 이 아이디어가 현장에서 어떤 과제로 바뀌는지부터 봐야 합니다.
규제 강도는 결국 사람이 맞춥니다. 담금질 예산, 보편성 기준, 가지치기 임계값은 사람이 돌리는 손잡이입니다. 세게 조이면 유용한 변화까지 잘려 나가고, 느슨하면 과적합이 돌아옵니다. 백본 의존성도 남습니다. 논문은 진화에 끼지 않은 별도 백본으로도 이득이 전이되는지 확인했지만, 일부 백본 사이의 검증에 그칩니다. 더 다양한 모델에서도 같은 이득이 나올지는 열려 있죠. 한 가지 더. '범용이냐 전용이냐'를 가르는 판별 자체가 또 다른 편향이 될 수 있습니다. 비평가가 그 선을 얼마나 정확히 긋는지도 검증 대상입니다.
바로 이 한계들 때문에, 저희 온틀 같은 현장에서는 이 아이디어를 그대로 이식하기보다 길들여 씁니다. 온틀은 고객사마다 AI 프로젝트 매니저(PM) 에이전트를 둡니다. 요청을 접수해 분석, 개발, 납품까지 끌고 가는 담당 에이전트죠. 저희가 파는 건 모델 자체가 아니라, 고객사의 반복 업무를 처리하도록 잘 조립된 에이전트 하네스입니다. 그러니 '현장판 과적합'은 남의 얘기가 아닙니다.
여기서 중요한 구분이 하나 있습니다. PM 에이전트의 하네스는 두 종류의 기능으로 나뉩니다. 하나는 여러 고객이 함께 쓰는 공통 기능입니다. 요청을 접수하고 분석해 작업으로 쪼개는 흐름 같은 것이죠. 다른 하나는 특정 고객에게만 맞춘 기능입니다. 둘을 섞어 보면 판단이 흐려집니다.
구체적인 장면으로 따라가 보죠. A사가 "우리 양식에 맞춰 주간 보고서를 자동으로 써 달라"고 요청합니다. 그래서 A사 전용 보고서 작성 로직을 다듬습니다. 이건 맞춤 기능입니다. 다른 고객에게 통하지 않는다는 이유만으로 이 수정이 나쁜 건 아닙니다. 애초에 A사만을 위한 기능이니까요. 문제는 이 로직이 A사 특유의 표 서식에만 아슬아슬하게 맞아떨어질 때입니다. A사가 다음 분기에 양식을 조금 바꾸자마자 보고서가 엉킨다면, 그건 A사 안에서조차 과적합한 겁니다. 그래서 맞춤 기능은 튜닝에 쓰지 않은 A사의 다른 사례, 이를테면 다른 주차, 다른 부서의 보고에 그대로 돌려 품질과 비용이 유지되는지 봅니다. 논문이 분포 밖에서 성능을 확인한 것과 같은 발상이죠.
반대로 "보고서를 쓸 때 관련 자료만 추려 넣자" 같은 수정은 공통 기능 쪽입니다. 이건 A사 사례만으로 검증하면 안 됩니다. B사, C사의 업무에 붙여도 통하는지 봐야 비로소 공통 기능으로 승격할 자격이 생깁니다. 새 자동화를 붙일 때마다 "이게 한 고객용인가, 모두를 위한 기본기인가"를 먼저 가르고, 그에 맞는 사례로 검증하는 관문을 두는 겁니다.
마지막으로, 쌓이기만 하고 쓸모없어진 로직과 맥락은 주기적으로 쳐냅니다. 토큰이 곧 운영 원가인 파견형 서비스에서는, 이 가지치기가 품질과 마진을 함께 지키는 일입니다.
물론 이건 적용 방향이지 보장은 아닙니다. 규제 강도를 사람이 맞춰야 하고, 범용과 전용을 가르는 판별이 또 다른 편향일 수 있다는 한계는 현장에서도 고스란히 남습니다. 어디까지 자동 심사에 맡기고 어디부터 사람이 볼지는 고객마다 조율할 몫입니다.
RRSI가 던지는 함의는 한 편의 논문보다 큽니다. 벤치마크 점수 경쟁에 매몰되기 쉬운 업계에, 성장의 방향을 잡는 일이 성장의 속도만큼 중요하다고 짚어 주거든요. 더 높은 점수가 곧 더 쓸모 있는 에이전트는 아닙니다. 처음 보는 일 앞에서 무너지지 않고 쓸수록 가벼워지는 쪽으로 똑똑해질 때, 그 똑똑함이 비로소 현장에서 값을 합니다. 자기개선하는 에이전트에게 필요한 건 더 센 엔진이 아니라 제대로 된 고삐인지도 모릅니다.
아닙니다. RRSI는 두뇌(백본 모델)를 고정한 채 그 위의 하네스만 진화시키는 방식이라, 특정 모델에 묶이지 않습니다. 논문은 진화에 쓰지 않은 별도의 백본으로도 이득이 전이되는지 확인했습니다. 다만 일부 백본 사이의 검증에 그치므로, 어떤 모델에든 똑같이 통한다고 단정하기는 이릅니다.
코드와 프로젝트 페이지가 공개돼 있어 후속 검증과 재현이 가능합니다. 논문은 arXiv와 HuggingFace에서 볼 수 있습니다(아래 참고자료). 공개돼 있다는 점은 수치를 그대로 믿는 대신 확인해 볼 여지가 있다는 뜻이라 신뢰를 더합니다.
오히려 비용에 민감한 쪽에 매력이 있습니다. RRSI는 가지치기로 하네스를 가볍게 만들어 정책 토큰을 규제 없는 진화 대비 30% 줄였는데, 토큰이 곧 운영 원가인 서비스에서는 이게 바로 마진으로 돌아옵니다. 다만 규제 강도(예산, 기준, 임계값)를 사람이 맞춰야 하는 품은 들기 때문에, 그 조율에 쓸 여력은 계산에 넣어야 합니다.