선생 없이 스스로 나아지는 에이전트, ClawLoop가 던진 질문

arXiv에 공개된 ClawLoop: Self-Improving Agents via Harness-Native Training Loop(arXiv 2610.14118)는 외부 선생 모델 없이 에이전트가 하네스 안에서 스스로 과제를 만들고 배우고 진단하는 순환 구조를 제안합니다. 이 글에서는 그 루프가 왜 기존의 한 번짜리 증류와 다른지, 그리고 진단이 다음 커리큘럼을 어떻게 바꾸는지를 차례로 따라가 보겠습니다. 원문 논문으로 이어지는 링크는 제목 아래에 걸어 두었습니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 사실 성능표가 아니라 전제였습니다. 요즘 에이전트 학습 이야기를 들으면 대개 더 강한 모델이 문제를 내고 궤적을 모은 뒤 작은 모델을 한 번 가르치는 그림이 떠오르지 않나요. 그런데 ClawLoop는 그 강한 바깥 선생을 치워버린 채로 시작하는데, 하네스라는 일터 안에 에이전트를 남겨두고 여기서 네가 할 일을 직접 만들라고 말합니다. 처음에는 조금 무모해 보이지만 곰곰이 생각하면 질문 자체는 꽤 정직합니다. 에이전트가 실제로 일하는 곳이 파일 시스템과 셸이라면, 배우는 일도 그곳에서 일어나야 하지 않을까요.

왜 선생 없는 에이전트가 먼저 눈에 들어왔을까요

여러 사람이 함께 일하다 보면, 누군가의 말 한마디가 팀 전체의 분위기를 바꾸기도 합니다. 그렇다면 여러 에이전트 학습 방법 중에서도 누군가의 개입 하나가 전체 구조를 바꾸는 지점이 있을까요. 저는 ClawLoop에서 그 지점이 바로 선생 모델의 유무라고 봅니다. 외부 선생이 있으면 과제 품질은 안정되지만, 그 선생의 관점과 비용에 계속 묶이게 되니까요. 선생이 바뀌면 데이터가 바뀌고, 선생이 비싸지면 루프를 자주 돌리기도 어렵습니다. 그래서 선생을 없앤다는 말은 단순히 비용을 아낀다는 뜻이 아니라 의존을 끊는다는 뜻에 가깝습니다.

물론 선생이 없다고 해서 배우는 일이 저절로 쉬워지지는 않습니다. 오히려 처음에는 더 막막해지는데, 누가 좋은 문제를 내주고 누가 잘했는지 판단해줄지가 비어 있기 때문입니다. ClawLoop의 답은 그 빈자리를 루프 안으로 가져오는 것으로, 과제를 합성하는 장치가 문제를 만들고 그 문제로 학습하는 단계가 이어지며 롤아웃을 돌아보고 다음 과제를 조정하는 진단이 뒤를 받칩니다. 세 부분이 서로를 먹여 살리면서 바퀴처럼 돌기 때문에 어느 하나만 떼어내서는 설명이 안 됩니다. 저는 이 구조를 보고 학원 대신 도제식을 떠올렸습니다. 일터에서 일을 만들고, 일을 해보고, 저녁에 오늘의 실수를 정리해서 내일의 일을 바꾸는 방식이니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 선생이 없다는 말이 지도가 전혀 없다는 뜻은 아니기 때문입니다. 하네스 자체가 일종의 지도인데, 파일이 있고 셸이 있으며 실행 결과와 실패 로그가 남기 때문입니다. 바깥에서 정답을 알려주는 대신 안에서 부딪히며 배우는 것인데, 이 차이가 생각보다 중요합니다. 논문이 하네스 네이티브라는 표현을 굳이 제목에 넣은 이유도 여기에 있다고 봅니다.

하네스 안에서 일한다는 것은 무슨 뜻일까요

하네스라는 말을 들으면 거창한 인프라를 떠올리기 쉽지만, 실제로는 에이전트의 일터에 가깝습니다. 샌드박스 작업 공간이 주어지면 에이전트는 그 안에서 파일을 읽고 쓰며 셸 명령을 실행하면서 일을 처리하는데, 브라우저 속 챗봇과 달리 손이 달린 셈이라 손이 닿는 곳마다 부작용이 생깁니다. 파일을 지우면 사라지고, 명령을 잘못 치면 에러가 나며, 테스트를 돌리면 통과와 실패가 갈립니다. 생각해보면 사람도 비슷하게 배우는데, 책으로만 배운 운전과 실제 도로에서 핸들을 잡아본 운전은 다르잖아요.

그렇다면 학습도 그 일터에 붙어 있어야 하지 않을까요. 기존 방식 중에는 강한 외부 모델이 과제를 합성하고 궤적을 모은 뒤 대상 에이전트를 한 번 학습시키는 흐름이 있습니다. 이 방식은 분명 실용적이지만 배우는 장소와 일하는 장소가 살짝 어긋나는데, 바깥에서 만들어진 과제가 안에서의 실패를 온전히 담지 못할 수 있기 때문입니다. 제가 이 논문에서 자꾸 하네스라는 단어를 곱씹은 이유도 그 어긋남 때문인데, 같은 셸 에러라도 하네스 안에서는 맥락이 있고 그 맥락이 다음 학습의 재료가 되기 때문입니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 하네스 네이티브라는 주장은 바로 그 비용 구조에 대한 주장처럼 들리는데, 바깥 선생을 부르는 API 비용과 대기 시간을 줄이는 대신 안에서 실행하고 검증하는 계산을 늘리는 선택이기 때문입니다. 어느 쪽이 더 쌀지는 환경마다 다르겠지만, 적어도 루프를 자주 돌리고 싶다면 안에서 도는 편이 마음이 편합니다. 실패해도 바깥에 묻지 않고 안에서 다시 해보면 되니까요.

매번 처음부터 헤매는 에이전트가 문제인 이유

에이전트를 써본 분들은 비슷한 경험을 해보셨을 겁니다. 어제는 곧잘 하던 파일 정리를 오늘은 왜 이렇게 헤매는지, 분명히 배운 것 같은데 다음날 아침이면 다시 신입처럼 행동하는 모습 말입니다. 일회성 학습에서는 이런 일이 자주 생기는데, 한 번 가르치고 끝내면 에이전트는 그 순간의 분포에만 맞춰지고 환경이 조금만 바뀌어도 다시 헤매기 때문입니다. 아침마다 같은 출근길에서 내비게이션을 켜는 것과 비슷합니다. 길은 아는데 매번 처음 가는 길처럼 느껴지는 것입니다.

문제는 그다음입니다. 에이전트의 일터는 계속 바뀌는데 학습은 한 번으로 끝나니, 간격이 벌어질수록 실수가 쌓입니다. 새로운 도구가 들어오고 레포 구조가 바뀌며 셸 환경이 달라지면 예전에 맞던 행동이 틀어지는데, 이때마다 바깥 선생에게 새 교재를 받아오기는 부담스럽습니다. 그래서 자연스럽게 다음 질문이 생깁니다. 에이전트가 일하면서 스스로 교재를 업데이트할 수는 없을까요. 제가 보기에는 ClawLoop가 바로 이 질문에서 출발합니다.

여기서 재미있는 질문이 생깁니다. 스스로 교재를 만들면 질이 떨어지지 않을까요. 당연한 걱정이지만, 그래서 ClawLoop는 만들기를 하나의 장치가 아니라 검증과 진단이 딸린 순환으로 설계합니다. 무작정 문제를 많이 만드는 것이 아니라 풀어보고 돌아보면서 다음 문제를 고르기 때문에, 일종의 오답 노트처럼 작동합니다. 틀린 문제를 그냥 넘기지 않고 모아서 다음 주 공부 계획을 바꾸는 감각에 가깝습니다.

스스로 문제를 내고 스스로 풀면 어디까지 갈 수 있을까

ClawLoop의 뼈대는 Task Synthesis와 Training, 그리고 Diagnosis and Feedback이라는 세 단계가 맞물려 도는 구조입니다. 합성이 문제를 만들면 학습이 그 문제로 에이전트를 업데이트하고, 진단이 롤아웃 행동을 분석해서 다음 합성에 피드백을 주는데, 한 바퀴 돌 때마다 에이전트는 조금 달라지고 달라진 에이전트에 맞춰 다음 문제도 달라집니다. 그래서 일회성 증류와 달리 시간이 지날수록 분포가 함께 움직입니다.

제가 이 구조에서 인상 깊게 본 점은 진단이 장식이 아니라 운전대라는 것입니다. 많은 자기 개선 이야기가 생성과 학습만 강조하고 평가는 점수로 끝내는데, 여기서는 롤아웃을 뜯어보고 능력 분석 리포트라는 형태로 정리합니다. 어디서 자주 막히는지, 어떤 유형이 쉬워졌는지, 다음에는 무엇을 어렵게 내야 하는지를 글로 남기는 셈인데, (참고로 사람 팀의 회고와 닮았는데요. 잘한 일보다 막힌 일을 적어야 다음 스프린트가 좋아지잖아요.) 그 리포트가 다음 합성의 조건으로 들어가니 루프는 같은 자리를 맴돌지 않고 조금씩 앞으로 나아갑니다.

그렇다면 이 순환은 정말 스스로 돌 수 있을까요. 논문이 말하는 최소한의 바깥 의존이라는 표현을 저는 이렇게 이해했습니다. 처음에는 빈손으로 시작할 수 없으니 약간의 씨앗은 필요하지만, 한 번 돌기 시작하면 바깥 선생을 계속 부르지 않아도 된다는 것입니다. 물론 씨앗의 질이 중요하겠지만, 루프가 스스로 교정할 수 있다면 시작점의 부담은 훨씬 가벼워집니다. 작은 팀이 큰 교재 없이 일터에서 사람을 키우는 모습과 겹쳐 보였습니다.

어려운 일을 조금씩 어렵게 만드는 감각이 필요한 이유

과제를 합성한다고 할 때 가장 어려운 점은 난이도 조절입니다. 너무 쉬우면 배울 것이 없고, 너무 어려우면 계속 실패만 하면서 시간을 쓰니까요. ClawLoop의 Task Synthesis는 서로 보완하는 두 가지 구성 방식을 쓰고 진단에 따라 난이도를 키우는데, 한마디로 지금 에이전트가 할 만한 것보다 살짝 어려운 일을 내는 방식입니다. 운동할 때 매번 같은 무게만 들지 않고 조금씩 증량하는 것과 비슷합니다.

이 차이는 생각보다 중요합니다. 고정된 문제집은 에이전트가 외우기 쉽지만, 진단에 맞춰 자라는 문제집은 외우기 어렵습니다. 지난주에 헤맸던 파일 권한 문제를 이번 주에는 변형해서 내고, 셸 파이프라인에서 자주 끊기면 그 부분을 조금 더 꼬아서 내는 식이니까요. 표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 무엇을 어렵게 할지를 정하려면 어디에서 막혔는지를 알아야 하고, 그러려면 롤아웃을 그냥 점수로 보지 않고 행동으로 봐야 하기 때문입니다.

저는 여기서 조금 의심했습니다. 난이도를 올린다는 말이 혹시 문제를 꼬아서 실패만 늘리는 것은 아닐까 하고요. 그런데 논문의 흐름을 따라가면 그 걱정은 조금 줄어드는데, 진단이 행동을 분석해서 보고서를 만들고 그 보고서가 다음 합성의 조건이 되니 어려워지는 방향이 막무가내가 아니라 약점을 향하기 때문입니다. 물론 보고서가 틀리면 방향도 틀어지겠지만, 그래서 다음에 살펴볼 검증 단계가 함께 필요합니다. 문제를 내는 손과 문제를 걸러내는 손이 따로 있어야 루프가 헛돌지 않으니까요.

버리기 전에 두 번 걸러내는 일이 왜 필요할까

스스로 만든 문제는 옥석이 섞이기 마련입니다. 풀 수 없는 문제도 있고 너무 사소한 문제도 있으며, 하네스에서 실행조차 안 되는 문제도 섞여 있기 때문입니다. 그래서 ClawLoop는 학습에 쓰기 전에 에이전트 없이 검증하는 단계와 에이전트로 검증하는 단계를 함께 두는데, 말하자면 서류 심사와 실기 시험을 둘 다 보는 셈이라 이 이중 장치가 저는 꽤 마음에 들었습니다. 한쪽만 있으면 놓치는 것이 생기기 때문입니다.

에이전트 없이 검증하는 단계는 문제 자체의 결함을 봅니다. 실행이 가능한지, 조건이 모순되지 않는지, 채점이 가능한지 같은 것들을 확인하는데, 반면 에이전트로 검증하는 단계는 실제로 풀어보면서 살핍니다. 너무 쉬워서 배울 게 없는지, 너무 어려워서 신호가 안 나오는지, 아니면 적당히 도전적인지를 확인하는 과정인데, 같은 모델에 같은 질문을 던져도 결과가 크게 달라질 수 있다는 것을 경험으로 알고 있으니 한 번 풀어본 것만으로 판단하지 않고 여러 행동을 보면서 거르는 과정이 필요합니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 검증에 드는 계산은 누가 감당하나요. 바깥 선생을 안 부르는 대신 안에서 실행하고 풀어보는 비용이 늘어나니, 그 교환이 남는지를 따져야 합니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 검증 비용은 하네스 안에서 병렬로 돌리거나 캐싱으로 다스릴 여지가 있지만, 바깥 의존은 구조적으로 줄이기 어렵기 때문입니다. 자주 돌릴수록 안에서 걸러내는 편이 체질에 맞는 팀이 있을 겁니다. 특히 샌드박스를 이미 갖추고 매일 에이전트를 돌리는 팀이라면요.

배우는 방식은 하나로 정해져 있지 않다

문제가 준비되면 이제 배우는 차례입니다. ClawLoop의 학습 단계는 SFT와 RL 중 하나 또는 둘을 함께 쓰는 형태로 설명됩니다. 지도 미세조정으로 좋은 행동을 따라 하게 하고, 강화학습으로 시행착오 속에서 더 나은 행동을 찾게 하는데, 처음에는 따라 외우다가 나중에는 스스로 요령을 터득하는 순서와 비슷합니다. 둘 중 하나가 정답이라기보다 루프의 상태에 따라 섞어 쓸 수 있다는 점이 현실적입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. SFT와 RL을 함께 쓴다는 말이 항상 좋다는 뜻은 아니기 때문입니다. SFT는 좋은 궤적이 있을 때 빠르고 안정적이지만, 궤적이 편향되면 편향을 그대로 외웁니다. RL은 탐색을 통해 편향을 깰 수 있지만, 보상이 허술하면 엉뚱한 요령을 배울 수 있습니다. 그래서 어떤 궤적으로 SFT를 하고 어떤 보상으로 RL을 돌리는지가 실제 성능을 가릅니다. 논문이 둘을 옵션으로 열어둔 것도 그 때문이라고 봅니다. 합성된 과제의 성격에 맞춰 학습 방식을 고르라는 신호처럼 들리니까요.

그렇다면 합성 과제로 학습한다는 것은 결국 자기 궤적으로 학습한다는 뜻일까요. 크게 보면 그렇습니다. 바깥에서 가져온 모범 답안이 아니라 안에서 만들고 걸러낸 과제의 궤적으로 배우기 때문입니다. 이 방식은 분포가 안에서 닫힌다는 장점이 있지만 동시에 우물에 갇힐 위험도 있습니다. 그래서 진단과 난이도 조절이 함께 있어야 합니다. 같은 우물이라도 물이 계속 갈아엎어지면 고이지 않으니까요. 저는 학습 방식을 볼 때 항상 그 짝을 함께 봅니다. 무엇을 배우는지와 무엇을 다음에 배울지가 따로 놀면 루프가 오래가기 어렵기 때문입니다.

오답 노트가 다음 커리큘럼을 정한다는 말의 의미

루프의 마지막 조각인 Diagnosis and Feedback은 어떻게 보면 가장 사람다운 부분입니다. 롤아웃 행동을 분석해서 능력 분석 리포트를 만들고, 그 리포트를 다음 반복의 피드백으로 쓰는데, 점수만 매기고 끝내는 것이 아니라 어디서 왜 막혔는지를 언어로 정리한다는 점이 다릅니다. 점수는 등수를 알려주지만 리포트는 처방을 알려주니까요. 병원으로 치면 체온만 재는 것이 아니라 문진을 하고 차트를 남기는 일에 가깝습니다.

이 리포트가 다음 합성의 조건으로 들어간다는 점이 전체 루프를 이해하는 열쇠입니다. 예를 들어 파일 탐색에서는 안정적인데 셸 에러 복구에서 자주 멈춘다면, 다음 합성은 에러 복구 유형을 더 많이, 조금 더 어렵게 내게 됩니다. 반대로 이미 잘하는 유형은 비중을 줄이거나 변형을 달리하겠죠. 이렇게 되면 커리큘럼은 고정된 교과서가 아니라 매주 바뀌는 시간표가 됩니다. 담임 선생님이 반 아이들의 오답을 보고 다음 주 수업을 바꾸는 것과 비슷합니다.

개인적으로 인상 깊었던 점은, 이 진단이 루프를 멈추지 않게 한다는 것입니다. 자기 개선 루프의 흔한 실패는 같은 문제를 반복하거나 점점 쉬운 문제만 남기는 일인데, 행동을 보고 난이도를 조건화하면 그 함정을 피하기 쉬워집니다. 물론 진단이 틀리면 커리큘럼도 틀어지겠지만, 적어도 틀린 이유를 글로 남기니 고칠 단서가 생깁니다. 실제 운영 관점에서 보면 이 기록 자체가 자산인데, 밤사이 어떤 유형이 늘었고 어떤 실수가 줄었는지를 보여주면 아침에 에이전트를 돌리는 마음이 훨씬 가벼워지기 때문입니다.

큰 모델의 숙제가 작은 모델에서도 통할 때가 있다

결과를 보면 논문은 Qwen3.6-27B를 루프 모델로 돌렸을 때 SkillsBench와 Claw-Eval-Live, ClawGym-Bench에서 일관된 향상이 있었다고 전합니다. 세 벤치마크는 각기 다른 각도에서 하네스 안의 일을 보는데, 한쪽만 오르고 다른 쪽이 내려갔다면 루프가 편향됐을 수 있습니다. 그런데 세 곳에서 함께 좋아졌다는 점이 눈에 들어옵니다. 적어도 특정 과제 암기가 아니라 일하는 방식 자체가 나아졌다는 신호처럼 읽히니까요.

그런데 여기서 더 재미있는 대목은 다음입니다. 루프에서 다듬어진 과제들이 더 작은 Qwen3.5-4B와 9B 모델로 옮겨가서도 모든 벤치마크에서 향상을 냈다는 점입니다. 이게 왜 중요할까요. 과제 자체의 질이 루프 모델에만 붙어 있는 것이 아니라 따로 떼어내도 쓸모가 있다는 뜻이기 때문입니다. 큰 모델이 하네스에서 땀 흘리며 만든 문제집이 작은 모델의 교재로도 통한다는 것인데, 저는 이 전이를 보고 데이터가 아니라 커리큘럼이 자산이라는 생각이 들었습니다. 모델은 바뀌어도 좋은 문제집은 남으니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 작은 모델에서의 향상이 곧 모든 환경에서의 일반화를 뜻하지는 않기 때문입니다. 하네스 구성이나 도구, 평가 방식이 달라지면 결과가 달라질 수 있습니다. 그럼에도 전이가 되었다는 사실은 루프가 자기 모델의 버릇만 외운 것이 아니라는 점을 보여줍니다. 저희가 새로운 AI 아키텍처를 볼 때도 이런 전이 여부를 함께 봅니다. 한 모델 안에서만 도는 개선인지, 아니면 재료 자체가 좋아서 다른 그릇에 담아도 맛있는지를 구분해야 다음 투자를 정할 수 있기 때문입니다.

그렇다면 다음 루프에서는 무엇을 지켜봐야 할까

지금까지 따라온 그림을 정리하면 이렇습니다. 하네스라는 일터 안에서 문제를 합성하고, 두 단계로 걸러내고, SFT나 RL로 배우고, 행동을 진단해서 다음 문제를 바꾸는 바퀴가 돕니다. 바깥 선생 없이도 바퀴가 멈추지 않는다는 점이 제안의 뼈대이고, 세 벤치마크에서의 일관된 향상과 작은 모델로의 전이가 그 뼈대를 받치고 있습니다. 그런데 생각해보면, 루프가 돈다는 것과 루프가 오래 돈다는 것은 다른 문제입니다. 한두 바퀴의 개선과 열 바퀴의 개선은 다른 질문을 요구하니까요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 루프를 오래 돌리면 무엇이 먼저 닳을까요. 합성의 다양성이 먼저 떨어질 수도 있고, 검증 비용이 먼저 무거워질 수도 있으며, 진단 리포트가 점점 관성적으로 써질 수도 있습니다. 특히 난이도를 계속 올리면 언젠가는 하네스가 감당할 수 있는 범위를 넘어설 텐데, 그때 루프는 어떻게 멈추거나 쉬어야 할까요. 저는 이 지점이 다음 연구에서 가장 보고 싶은 부분입니다. 잘 도는 바퀴보다 잘 쉬는 바퀴가 더 오래가기 때문입니다.

그렇다면 사람의 역할은 무엇일까요. 선생을 없앴다고 해서 사람이 사라지는 것은 아닙니다. 오히려 사람이 할 일이 더 분명해지는데, 무엇을 잘했다고 정의할지, 어떤 실패를 용납하지 않을지, 하네스에 어떤 도구와 가드레일을 둘지를 정하는 일이기 때문입니다. 에이전트가 스스로 문제를 내는 시대일수록 무엇을 공부시킬지가 더 중요해집니다. 이 논문을 덮으며 저는 그 질문을 다시 적었습니다. 우리 일터의 하네스는 에이전트가 넘어지고 배우기에 좋은 모양인가요. 그 모양을 다듬는 일이야말로 지금 팀이 할 수 있는 가장 직접적인 투자일지 모릅니다.