0.25에서 0.61로, 스스로 코드를 고친 에이전트 MOSS

AI 요약

• 무슨 일: arXiv에 공개된 MOSS 논문이 에이전트의 소스 레벨 자기수정 루프를 제안했습니다.
  • 저자들은 OpenClaw 실험에서 네 과제 평균 grader score가 한 번의 사이클 후 0.25에서 0.61로 올랐다고 보고했습니다.
• 핵심 전환: 프롬프트, 스킬, 메모리 파일을 고치는 수준을 넘어 라우팅과 훅 순서가 들어 있는 하네스 코드를 고칩니다.
• 운영 조건: 실패 증거 배치, trial worker replay, 사용자 동의, container swap, health-probe rollback이 안전장치로 제시됐습니다.
  • 공개 GitHub 링크는 2026년 5월 22일 확인 시 404였으므로, 재현성 평가는 아직 보류해야 합니다.
• 주의점: 자기진화라는 표현보다 중요한 것은 수정 권한을 어디까지 열고, 어떤 검증으로 배포를 막을지입니다.

2026년 5월 21일 arXiv에 올라온 논문 MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems는 에이전트 자기개선 논의의 초점을 조금 더 위험하고 실무적인 층으로 옮깁니다. 지금까지 self-evolving agent라는 말은 대체로 프롬프트를 고치거나, 스킬 파일을 추가하거나, 메모리 스키마를 바꾸거나, 워크플로 그래프를 조정하는 방식으로 쓰였습니다. MOSS가 던지는 질문은 다릅니다. 반복되는 실패의 원인이 지시문이 아니라 에이전트 하네스의 코드에 있다면 어떻게 해야 하는가입니다.

논문의 답은 꽤 직접적입니다. 에이전트가 실패 증거를 모으고, 그 증거를 바탕으로 소스 코드 수정 후보를 만들고, 격리된 trial worker에서 실패 배치를 다시 실행해 검증한 뒤, 사용자의 동의를 받아 컨테이너를 갈아끼우는 구조입니다. 저자들은 OpenClaw 위에서 네 개 과제 평균 grader score가 한 번의 진화 사이클 후 0.25에서 0.61로 올랐다고 보고했습니다. 수치만 보면 작지 않은 개선입니다. 하지만 이 뉴스의 진짜 쟁점은 점수보다 경계입니다. AI 에이전트가 자기 프롬프트를 고치는 것과 자기 실행 코드를 고치는 것은 같은 이야기가 아닙니다.

왜 프롬프트 밖으로 나가려 하는가

현재 많은 에이전트 시스템은 모델과 프롬프트만으로 움직이지 않습니다. 파일을 읽고, 명령어를 실행하고, 브라우저를 열고, 외부 도구를 호출하고, 실패를 기록하고, 작업을 재시도하는 하네스가 있습니다. 이 하네스에는 라우팅, hook ordering, 상태 불변식, 권한 검사, dispatch 규칙, 재시도 정책, 로그 저장 방식이 들어갑니다. 사용자가 보는 것은 "에이전트가 답한다"는 경험이지만, 실제 동작은 모델 호출과 주변 런타임의 조합입니다.

MOSS 논문은 기존 자기진화 방식이 이 주변 런타임을 충분히 건드리지 못한다고 봅니다. 프롬프트와 스킬 파일은 텍스트로 바꿀 수 있습니다. 메모리 스키마와 워크플로 그래프도 어느 정도 수정 가능합니다. 그러나 코드에 박힌 구조적 실패는 그런 텍스트 계층에서 닿지 않을 수 있습니다. 예를 들어 특정 실패가 "도구 호출 전에 승인 훅이 먼저 실행돼야 하는데 순서가 뒤집혀 있다"는 문제라면, 모델에게 "승인을 잘 확인하라"고 말하는 것만으로는 안정적 해결이 어렵습니다. 하네스 코드 자체의 순서가 바뀌어야 합니다.

논문은 source-level adaptation을 더 일반적인 매체로 설명합니다. 소스 코드는 튜링 완전하고, 텍스트로 바꿀 수 있는 설정의 상위 집합이며, 모델이 매번 지시를 잘 따르는지에 덜 의존하고, 긴 컨텍스트에서 지시가 희석되는 문제에도 상대적으로 덜 취약하다는 주장입니다. 표현은 연구 논문답게 단정적이지만, 문제의식은 현장적입니다. 에이전트의 실패가 점점 "모델이 몰랐다"보다 "하네스가 잘못 설계됐다"에 가까워질수록, 자기개선의 대상도 프롬프트 밖으로 밀려납니다.

MOSS가 제안한 루프

MOSS의 루프는 낭만적인 "AI가 스스로 진화한다"보다 CI/CD 파이프라인에 가깝습니다. 먼저 생산 환경에서 실패 증거를 모읍니다. 논문은 이것을 automatically curated batch of production-failure evidence라고 부릅니다. 중요한 점은 개선 목표가 막연한 자기평가가 아니라 실제 실패 묶음에 묶인다는 것입니다. 에이전트가 어디서 실패했는지, 어떤 입력과 상태에서 실패했는지, 어떤 평가자가 낮은 점수를 줬는지를 고정해야 후보 패치가 평가 가능합니다.

그다음 코드 수정은 외부 coding-agent CLI에 위임됩니다. 여기서 MOSS가 직접 모델이 되는 것은 아닙니다. MOSS는 수정 후보를 만드는 행위를 pluggable external coding-agent CLI에 맡기고, 자신은 단계 순서와 verdict를 통제합니다. 이 구분이 중요합니다. 자기진화 시스템에서 가장 위험한 구조는 수정하는 주체와 승인하는 주체, 배포하는 주체가 모두 흐릿해지는 것입니다. MOSS는 적어도 논문 설계상으로는 "코드는 외부 코딩 에이전트가 고치되, MOSS는 검증과 승격 프로토콜을 유지한다"는 분리를 둡니다.

후보 패치는 바로 운영 환경에 들어가지 않습니다. MOSS는 candidate image를 만들고 ephemeral trial worker에서 실패 배치를 replay합니다. 기존 실패가 다시 발생하는지, 점수가 좋아지는지, 시스템이 깨지지 않는지를 시험하는 단계입니다. 이 부분은 에이전트 자기개선 논의에서 특히 중요합니다. 자기수정은 쉽게 그럴듯한 패치와 과적합된 패치를 만들어냅니다. 특정 실패 로그 하나를 통과하려고 다른 경로를 망가뜨릴 수 있고, 평가자가 보지 못하는 권한 경계나 데이터 경계를 건드릴 수 있습니다. 격리된 재실행은 최소한의 방화벽입니다.

승격 단계도 완전 자동 배포가 아닙니다. 논문은 user-consent-gated in-place container swap을 말합니다. 즉 후보가 검증을 통과해도 사용자 동의가 있어야 실제 컨테이너 교체가 일어납니다. 이후 health probe가 실패하면 rollback합니다. 이것은 에이전트 연구와 운영 시스템의 언어가 만나는 지점입니다. 자기진화가 실험실 데모를 넘어 운영 이야기로 가려면, 성능 개선보다 먼저 승격과 되돌리기 조건이 명확해야 합니다.

0.25에서 0.61이라는 숫자가 말하는 것

논문 초록에서 가장 눈에 띄는 숫자는 OpenClaw 실험 결과입니다. MOSS가 한 번의 사이클로 네 과제 평균 grader score를 0.25에서 0.61로 올렸다는 주장입니다. 이것은 "자기수정이 가능하다"는 데모로는 충분히 강합니다. 특히 개선 대상이 프롬프트가 아니라 production agentic substrate의 source-level rewriting이라는 점 때문에 더 그렇습니다.

하지만 이 숫자를 읽을 때는 조심해야 합니다. 첫째, arXiv preprint입니다. 둘째, 공개 페이지에는 코드 링크가 적혀 있지만 2026년 5월 22일 확인 시 GitHub 저장소는 404를 반환했습니다. 셋째, 네 개 과제 평균이라는 실험 범위는 아직 좁습니다. 넷째, grader score 상승이 일반적인 운영 안정성, 보안성, 권한 보존, 회귀 방지까지 입증하는 것은 아닙니다.

그럼에도 숫자의 의미가 사라지는 것은 아닙니다. 기존 에이전트 개선은 흔히 "더 좋은 모델을 붙인다" 또는 "프롬프트를 다듬는다"로 설명됐습니다. MOSS는 같은 모델 계층 위에서도 하네스 코드가 성능과 실패 양상을 크게 바꿀 수 있음을 보여주는 사례입니다. 코딩 에이전트 시대의 성능은 모델 가중치만의 함수가 아닙니다. 어떤 실패를 저장하고, 어떤 증거를 재생하고, 어떤 코드를 고칠 수 있게 허용하고, 어떤 검증을 통과해야 배포되는지가 함께 성능을 만듭니다.

텍스트 아티팩트 자기진화와 소스 레벨 자기진화

기존 self-evolving agent 연구가 의미 없다는 뜻은 아닙니다. 스킬 파일, 프롬프트, 메모리, 워크플로는 실제로 중요합니다. 이 계층은 수정 비용이 낮고, 사람이 검토하기 쉽고, 위험 반경이 상대적으로 작습니다. 문제는 모든 실패가 그 층에 있지 않다는 점입니다.

소스 레벨 진화는 더 강력하지만 더 위험합니다. 프롬프트 하나가 잘못되면 대개 답변 품질이 나빠집니다. 런타임 코드가 잘못되면 로그가 사라지고, 승인 절차가 우회되고, 재시도 루프가 폭주하고, 비용 제한이 깨질 수 있습니다. 그래서 MOSS에서 흥미로운 부분은 "AI가 코드를 고쳤다"는 문장보다 "어떤 검증과 승격 장치를 붙였는가"입니다.

이 관점은 최근 코딩 에이전트 경쟁과도 맞닿아 있습니다. Claude Code, Codex, Cursor, OpenClaw 같은 도구는 점점 더 큰 작업 단위를 맡고 있습니다. 그러나 큰 작업 단위를 맡길수록 에이전트 주변의 하네스가 중요해집니다. 좋은 컨텍스트를 넣고, 잘못된 도구 호출을 막고, 실행 결과를 관측하고, 실패를 재현하고, 비용을 제한하는 주변 시스템이 약하면 모델 성능만으로는 안정적인 자동화가 어렵습니다.

자기수정의 진짜 쟁점은 권한입니다

MOSS 같은 구조를 실제로 운영한다고 생각하면 첫 번째 질문은 성능이 아닙니다. "어떤 파일을 고칠 수 있는가"입니다. 에이전트가 자기 하네스 전체를 수정할 수 있다면, 승인 정책과 로그 정책, 네트워크 접근, 비용 제한, 평가 로직까지 모두 수정 대상이 될 수 있습니다. 그러면 자기개선 시스템이 자신의 안전장치를 약화시키는 패치를 만들 가능성도 열립니다.

따라서 수정 가능 영역을 나누는 정책이 필요합니다. 예를 들어 라우팅 정책 일부는 수정할 수 있지만 인증과 비밀 관리 코드는 수정할 수 없게 할 수 있습니다. 로그 포맷은 바꿀 수 있지만 감사 로그 전송 경로는 바꿀 수 없게 할 수 있습니다. 평가용 replay harness는 수정 대상에서 제외해야 할 수도 있습니다. 자기수정 시스템에서 평가자와 피평가자가 같은 권한을 갖는 순간, 점수 상승은 신뢰하기 어려워집니다.

두 번째 질문은 데이터 경계입니다. 실패 증거 배치는 실제 사용자 입력, 내부 문서, 코드, API 응답, 오류 로그를 포함할 수 있습니다. 이 데이터를 외부 coding-agent CLI로 넘기는 순간 조직의 데이터 처리 경로가 바뀝니다. MOSS가 특정 CLI에 종속되지 않는 pluggable 구조를 택했다는 점은 유연하지만, 운영자는 어떤 CLI가 어떤 데이터를 받는지 명확히 알아야 합니다. 특히 기업 코드베이스와 고객 데이터가 섞인 에이전트에서는 실패 로그 자체가 민감 정보가 됩니다.

세 번째 질문은 비용과 폭주입니다. 자기진화 루프는 실패 배치를 만들고, 후보 패치를 생성하고, 이미지를 빌드하고, replay를 돌리고, 승격과 rollback을 관리합니다. 이것은 단순 모델 호출보다 무겁습니다. 실패가 많을수록 개선 루프가 자주 돌 수 있고, 개선 루프가 잘못 설계되면 비용과 컴퓨트가 새 병목이 됩니다. "에이전트가 스스로 고친다"는 문장은 매력적이지만, 실제로는 또 하나의 배포 파이프라인과 비용 센터를 만든다는 뜻입니다.

개발팀에 주는 실무 신호

지금 당장 모든 팀이 자기수정 에이전트를 도입해야 한다는 뜻은 아닙니다. 오히려 반대에 가깝습니다. MOSS는 아직 preprint이고, 공개 코드도 확인되지 않았습니다. 다만 개발팀이 준비해야 할 방향은 분명합니다. 에이전트 운영에서 실패를 재현 가능한 증거로 남기는 능력이 더 중요해지고 있습니다.

코딩 에이전트를 쓰는 팀이라면 "실패했다"는 감상보다 "어떤 입력, 어떤 파일 상태, 어떤 도구 호출, 어떤 출력, 어떤 평가 기준에서 실패했는가"를 남겨야 합니다. 그래야 사람이 고치든 에이전트가 고치든 검증할 수 있습니다. 실패 증거가 없으면 자기개선은 학습이 아니라 추측입니다.

또한 에이전트 하네스는 테스트 가능한 구조여야 합니다. 도구 호출 순서, 권한 체크, 상태 전이, 비용 제한, 파일 접근 정책이 테스트로 표현돼 있어야 합니다. MOSS의 trial replay가 의미를 가지려면 replay할 수 있는 환경과 판정 기준이 있어야 합니다. 에이전트가 점점 더 많은 일을 할수록, "에이전트에게 맡겼다"가 아니라 "에이전트가 고칠 수 없는 불변 조건을 테스트로 묶었다"가 운영 역량이 됩니다.

마지막으로 인간 승인 지점은 사라지지 않습니다. MOSS가 user-consent-gated 승격을 넣은 것은 현실적인 선택입니다. 자기수정 시스템이 매번 사람을 기다리면 자동화 효과가 줄어들지만, 사람의 승인 없이 런타임 코드가 바뀌면 위험이 너무 큽니다. 실제 제품에서는 변경 범위별 승인 정책이 필요할 가능성이 큽니다. 낮은 위험의 로깅 개선은 자동 승격할 수 있어도, 권한 검사나 네트워크 호출 경로 변경은 사람이 봐야 합니다.

에이전트 진화의 다음 경계

MOSS 논문은 자기개선 에이전트가 더 똑똑해졌다는 단순한 이야기가 아닙니다. 에이전트가 실패를 고치는 공간이 프롬프트와 스킬에서 소스 코드와 컨테이너 배포로 확장될 수 있다는 신호입니다. 이 확장은 흥미롭지만, 동시에 에이전트 운영을 소프트웨어 배포 문제로 되돌립니다. 패치 후보가 있고, 검증 환경이 있고, 승격 조건이 있고, rollback이 있고, 감사 가능한 로그가 있어야 합니다.

그 점에서 MOSS가 보여주는 미래는 완전 자율적이고 마법 같은 에이전트가 아닙니다. 오히려 더 강한 자동화일수록 더 단단한 운영 경계가 필요하다는 쪽에 가깝습니다. 에이전트가 자기 코드를 고칠 수 있다면, 인간은 더 이상 모든 패치를 직접 쓰지 않을 수 있습니다. 대신 어떤 코드를 고칠 수 있는지, 어떤 증거로 고쳤다고 판단할지, 어떤 테스트를 통과해야 승격할지, 어떤 순간에 즉시 되돌릴지를 설계해야 합니다.

이번 논문은 아직 시작점입니다. 코드 공개 상태와 실험 재현성, 더 큰 과제 집합에서의 회귀, 보안 경계, 비용 모델은 계속 확인해야 합니다. 그래도 한 가지는 분명합니다. AI 에이전트의 경쟁은 모델 성능만이 아니라 하네스와 운영 루프의 경쟁으로 이동하고 있습니다. MOSS는 그 흐름을 가장 노골적인 방식으로 보여줍니다. 에이전트가 더 잘 일하게 만들려면, 언젠가는 에이전트 자신을 둘러싼 코드까지 개선 대상으로 올려야 할 수 있습니다. 그 순간부터 핵심 질문은 "스스로 고칠 수 있는가"가 아니라 "고친 것을 믿을 수 있는가"가 됩니다.

출처

• arXiv: MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems
• MOSS PDF
• arXiv DOI