AI에게 코딩이나 터미널 작업을 맡겨 보면 묘한 일이 벌어진다. 같은 AI인데 어떤 날은 척척 해내고, 어떤 날은 같은 자리에서 맴돈다. 성능을 끌어올리려 손을 대도 늘 같은 벽 앞에 선다. 방금 고친 게 진짜 실력을 키운 걸까, 아니면 이 문제에만 통하는 요령 하나를 외운 걸까.
ModularRSI는 이 질문을 피하지 않는다. 핵심 발상은 이렇다. AI가 스스로 고친 실력이 진짜인지 알고 싶다면, 두뇌 역할을 하는 AI 모델을 통째로 바꿔 끼워 보라. 요령이라면 모델과 함께 증발하고, 실력이라면 남는다. 이 "옮겨 붙는 성질"(모델이나 과제를 바꿔도 성능이 유지되는 일반화 가능성)이 이 논문의 중심이다. 거기까지 어떻게 갔는지 따라가 보자.
먼저 용어 하나. 에이전트 하네스(harness)는 AI의 핵심 엔진인 LLM(사람 말로 묻고 답하는 AI 모델) 그 자체가 아니다. 그 엔진을 감싸서 실제로 일을 시키는 '실행 장치'다. 어떤 순서로 생각하고 움직일지, 어떤 도구를 언제 꺼낼지, 관찰한 결과에서 뭘 추릴지, 일이 끝났는지 어떻게 판단할지 — 이 '일하는 방식의 뼈대'가 전부 하네스다.
주방에 빗대면 쉽다. LLM은 요리사, 하네스는 주방의 동선과 도구 배치다. 요리사가 아무리 뛰어나도 동선이 꼬이고 칼이 엉뚱한 서랍에 있으면 요리는 느려진다. 에이전트의 실질 성능은 요리사만큼이나 주방 설계에 달려 있다.
재귀적 자기개선(RSI)은 바로 이 주방을 에이전트가 스스로 손보는 것이다. 자기 실행 기록에서 실패를 추려 '이 방식이 문제였다'를 찾아내고, 다음번 동선을 스스로 바꾼다. 사람이 아니라 에이전트가 한다는 게 핵심이다. 최근 연구들이 긴 호흡의 코딩·터미널 작업에서 이걸 실제로 시도하기 시작했다.
문제는 이 자기개선이 엉뚱한 자리를 고치기 쉽다는 것이다. 논문은 함정 세 개를 짚는다.
| 기존 방식의 함정 | 왜 '진짜 개선'과 헷갈리나 |
|---|---|
| 시험 문제(벤치마크)로 하네스를 고치면 | 그 시험 점수만 오르고 처음 보는 일엔 안 통하는 '요령'일 수 있다 |
| 한 번의 시도만 보고 고치면 | 뼈대 자체의 결함인지, 그 일 하나의 특수한 사정인지 뒤섞인다 |
| 뭉쳐 있는 하네스를 통째로 고치면 | 어느 변경이 효과였는지 짚을 수 없고, 상관없는 기능끼리 엉킨다 |
세 함정은 결국 하나로 모인다. 고칠 자리와 근거를 흐릿하게 만든다는 것. 과녁이 안 보이면 명중했는지도 알 수 없다.
ModularRSI는 함정 하나에 처방 하나씩을 붙인다.
첫째, 연습 문제와 시험지의 출처를 아예 갈라놓는다. 외부에서 실행 가능한 연습용 작업 2,000개를 모으되, 나중에 성능을 잴 벤치마크와는 겹치지 않게 했다. 연습장과 실전 시험지가 같은 출처라면 점수가 올라도 그게 실력인지 유출된 답을 외운 건지 가릴 수 없다. 출처를 떼어 놓아야 그 구분이 선다.
또한 성공한 시도와 실패한 시도를 나란히 놓고 비교하는 방식을 통해, 어쩌다 한 번의 실수가 아니라 몸에 밴 '나쁜 버릇'을 가려낸다. 두 기록의 차이를 보면 '이 작업에만 있던 사정'은 걸러지고 '일하는 방식 자체의 결함'이 도드라진다. 성공한 짝이 없는 실패는 단독으로도 진단하고, 모두 성공한 작업이라도 더 빠르게 끝낼 여지가 있으면 효율을 손본다. 그리고 어느 수정을 받아들일지 고를 때는, 여러 작업에서 함께 지지되는 수정안을 우선한다. 한 작업에만 들어맞는 수정보다 여러 곳에서 통하는 수정이 '요령'보다 '실력'일 공산이 크기 때문이다.
그리고 뼈대를 다섯 부품으로 쪼개 따로 고친다는 점이 가장 큰 특징이다. 통째로 고치면 무엇이 효과였는지 알 수 없으니, 하네스를 다섯 모듈로 나눈다.
각 모듈은 정해진 범위 안에서만 독립적으로 손본다. 고칠 부품을 격리하니 어떤 변경이 무슨 효과를 냈는지 추적되고, 상관없는 기능이 덩달아 엉키는 일이 준다. 따로 다듬은 모듈은 마지막에 하나의 하네스로 합치는 통합 단계에서 서로의 충돌을 조율한다.
실험은 두 시험대에서 돌아갔다. SWE-Bench Verified는 실제 소프트웨어의 버그를 찾아 고치는 코딩 능력을, TB2.0은 터미널에서 명령을 짜 일을 끝내는 능력을 재는 표준 벤치마크다.
개선된 하네스는 세 방향 모두에서 이득이 남았다. 무엇을 바꿔 보았고 그게 무엇을 증명하는지 표로 정리하면 이렇다.
| 바꿔 본 것 | 무엇을 시험하나 | 결과가 말해주는 것 |
|---|---|---|
| 같은 분야의 처음 보는 작업 | 외운 답이 아닌가 | 연습에 없던 문제에도 통함 |
| 다른 분야의 처음 보는 작업 | 한 분야에 갇힌 요령 아닌가 | 분야를 넘어 옮겨짐 |
| 기반 모델(요리사)을 교체 | 특정 모델 버릇에 맞춘 것 아닌가 | 모델이 바뀌어도 이득이 남음 |
마지막 줄이 이 논문의 심장이다. 어떤 개선이 특정 모델의 버릇에만 맞춰진 것이라면, 요리사를 갈아 끼우는 순간 함께 사라진다. 그런데 ModularRSI가 다듬은 주방은 다른 요리사를 세워도 더 잘 돌아갔다. 고쳐 놓은 게 '이 모델, 이 시험용 요령'이 아니라 '일하는 방식 그 자체'였다는 뜻이다.
솔직히 짚을 것도 있다. 이 결과는 '얼마나' 좋아졌는지가 아니라 '어디까지 옮겨지는지'를 말한다. 향상 폭이 몇 점인지는 원문의 수치표를 들여다봐야 하고, 이 글만으로는 판단할 수 없다. 그래도 자기개선 연구가 오래 증명하고 싶어 한 건 애초에 폭이 아니라 이 일반성이었다. 폭이 크더라도 한 모델·한 시험에 갇히면 '요령'이고, 폭이 작더라도 모델과 분야를 넘어 남으면 '실력'이다. ModularRSI가 보여준 쪽은 후자다.
이 고민은 우리 온틀(ONTLE)이 만드는 'AI 프로젝트 매니저'의 일상과 거의 포갠다. AI PM은 전형적인 긴 호흡·다단계 에이전트다. 여러 도구를 부르고, 관찰한 걸 추리고, 좁은 문맥 안에서 상태를 쥐고, '이 일이 끝났나'를 스스로 판단한다. 논문이 쪼갠 다섯 모듈이 그대로 우리 고민 목록이기도 하다.
한 장면을 끝까지 따라가 보자(아직 설계 단계의 가정이다). 고객이 작업 도중 납기를 앞당겨 달라고 한다. AI PM이 이 변경을 일정에만 반영하고, 이미 진행 중이던 산출물 범위는 손대지 않은 채 '반영 완료'를 선언했다고 하자. 바뀐 납기에 맞추려면 범위도 다시 조율했어야 하는데 거기까지 못 간 것이다.
프롬프트를 통째로 갈아엎고 싶은 충동부터 누른다. 먼저 과녁을 좁힌다. 이 실수는 '작업 완료 판단' 모듈의 문제로 보인다 — 바뀐 조건을 다 반영하기 전에 끝을 선언하는 버릇. 하지만 한 건으로 단정하지 않는다. 논문의 결을 따라, 여러 고객·여러 세션 로그를 뒤져 같은 '성급한 종료'가 다른 곳에서도 나타나는지부터 본다. 한 번이면 그 고객만의 사정일 수 있고, 여러 곳에서 겹치면 그 모듈을 손볼 근거가 더 단단해진다. 고친 뒤에는 이번에 건드리지 않은 다른 고객 업무에서 같은 실수가 줄었는지로 효과를 가늠한다. 우리 시험으로 우리 주방을 다듬으면 늘 잘 되는 것처럼 보이니, 검증은 손대지 않은 일에서 해야 한다.
다만 논문을 그대로 베끼지는 않는다. 다섯 모듈은 코딩 에이전트에 맞춰 나뉜 것이고, AI PM에는 결이 다른 부품이 필요할 수 있다. 이를테면 '고객 의도 파악'(말 뒤의 진짜 요구를 읽어내는 단계)이나 '중간 보고 생성'(진행 상황을 고객 언어로 정리해 내보내는 단계) 같은 모듈은 코딩 벤치마크엔 없지만 우리 현장엔 있다.
논문이 준 건 코딩용 망치다. 우리는 그 쥐는 법 — 모듈로 쪼개고, 여러 곳에서 겹치는 수정을 우선하고, 손대지 않은 일로 검증하는 결 — 을 가져와 PM 업무용 스패너를 따로 벼릴 차례다.
논문이 연습용 작업을 '실행 가능한' 것으로 고른 이유가 여기 있습니다. 코드가 돌아가고 테스트가 통과하는지, 터미널 명령이 원하는 결과를 냈는지는 기계가 객관적으로 가립니다. 사람이 일일이 채점하지 않아도 성공과 실패가 또렷이 갈리니, 그 차이에서 '나쁜 버릇'을 자동으로 뽑아낼 수 있습니다.
그 위험을 줄이려고 설계 자체가 보수적입니다. 고칠 수정을 고를 때 여러 작업에서 함께 지지되는 쪽을 우선하고, 성능은 연습과 겹치지 않는 시험지로 재니, 한 번의 운에 휘둘려 엉뚱한 곳을 건드릴 여지가 작습니다. 다만 모든 퇴행을 막아준다고 논문이 보장한 것은 아닙니다 — 그래서 손대지 않은 일로 다시 확인하는 검증 단계가 끝에 남습니다.
그건 아닙니다. 더 좋은 요리사를 세우면 같은 주방에서도 요리는 더 잘 나옵니다. 이 논문이 말하는 건 '모델이 다 똑같다'가 아니라, 주방을 잘 고쳐 놓으면 그 개선분이 요리사를 바꿔도 얹혀 간다는 겁니다. 좋은 모델과 좋은 하네스는 둘 중 하나를 고르는 문제가 아니라 더하기입니다.