AI 에이전트의 실력은 고정된 스킬보다 학습하는 하네스에서 갈린다

에이전트에 더 좋은 모델과 스킬을 붙였는데도 같은 실패가 반복된다면, 문제는 지능이 아니라 실행 구조에 있을 수 있다. 장기 실행 에이전트의 다음 경쟁력은 고정된 프롬프트가 아니라 실패를 다음 실행에 반영하는 하네스다.

TL;DR

스킬과 메모리를 설계 시점에 고정하면 실행 중 얻은 교훈이 다음 작업으로 전달되지 않는다.
자기개선 하네스는 모델을 스스로 바꾸는 마법이 아니라, 실행 기록·실패 분류·검증된 규칙 갱신의 루프다.
장기 실행의 핵심은 무한 자율성이 아니라 중단 후에도 이어갈 수 있는 상태와 복구 증거다.
처음에는 전체 에이전트를 학습시키지 말고, 반복 오류가 있는 좁은 작업 하나부터 실험해야 한다.

왜 지금 중요한가

AI 코딩 에이전트는 코드를 생성하는 단계에서 빠르게 발전하고 있다. 하지만 실제 프로젝트에서 비용이 커지는 지점은 첫 결과를 만드는 순간보다 실패를 다시 분석하고, 같은 오류가 재발하지 않게 유지하는 과정이다.

고정된 시스템은 매번 비슷한 입력을 받아 비슷한 경로를 반복한다. 메모리를 추가해도 무엇을 남길지, 어떤 실패를 규칙으로 승격할지 정해져 있지 않으면 기록은 쌓이기만 한다. 그래서 에이전트를 오래 운영할수록 모델 호출보다 하네스의 상태 관리와 검증 설계가 중요해진다.

핵심 관점: 자기개선은 에이전트가 마음대로 자신을 다시 쓰는 기능이 아니라, 검증된 경험만 다음 실행 구조에 반영하는 운영 루프다.

핵심 흐름: 고정된 스킬에서 실행 중인 하네스로

1. 실행을 상태로 남긴다

Prime Agent는 RLM과 Continual Harness를 중심으로 컨텍스트, 스킬, 메모리, 서브에이전트를 실행 과정에서 다룰 수 있는 대상으로 설명한다. 이 방향의 핵심은 특정 구현을 그대로 복제하는 데 있지 않다. 작업이 끝난 뒤 결과만 남기는 대신, 어떤 입력과 도구와 조건으로 결과가 나왔는지를 다시 읽을 수 있게 만드는 데 있다.

최소한 다음 정보는 남겨야 한다.

원본 입력과 입력의 식별자
사용한 도구와 주요 인자
모델이 선택한 경로
결과와 검증 결과
사람이 수정하거나 거부한 부분

이 기록이 있어야 “이번에는 왜 실패했는가?”를 다음 실행의 입력으로 바꿀 수 있다.

2. 실패를 원인별로 분류한다

모든 실패를 하나의 실패 상태로 저장하면 개선 방향을 찾기 어렵다. 예를 들어 SQL을 ERD로 변환하는 작업이라면 파싱 오류, 관계 추론 오류, 출력 형식 오류, 검증 누락을 나눠야 한다.

분류의 목적은 복잡한 taxonomy를 만드는 것이 아니다. 같은 원인이 반복되는지 확인하고, 어떤 체크리스트를 먼저 바꿀지 결정하는 것이다. 빈도가 낮고 영향도 작은 실패는 기록만 남겨도 된다. 반복적이고 영향이 큰 실패만 다음 규칙 후보로 올린다.

3. 사람이 승인한 규칙만 승격한다

하네스가 자기 코드를 무제한으로 수정하게 만들면 개선과 회귀를 구분하기 어려워진다. 안전한 초기 루프는 다음과 같다.

실행 기록 → 실패 분류 → 규칙 후보 생성 → 작은 eval 통과 → 규칙 업데이트

규칙 업데이트 전후에 같은 사례와 반례를 다시 실행해야 한다. 새 규칙이 한 오류를 줄이는 대신 정상 사례를 망가뜨릴 수 있기 때문이다. 자기개선의 단위는 “더 똑똑해졌다”가 아니라 “반복 오류율이 줄고 기존 품질이 유지됐다”여야 한다.

4. 중단과 복구를 기본 상태로 취급한다

장기 실행 에이전트는 항상 한 번에 끝난다는 가정으로 설계할 수 없다. persistent REPL, append-only 로그, 세션 트리 같은 구조가 주는 교훈은 실행이 중단되어도 마지막으로 확정된 상태부터 다시 시작할 수 있어야 한다는 것이다.

복구 가능한 작업에는 적어도 다음 상태가 필요하다.

running: 현재 실행 중
waiting: 사용자 입력이나 승인을 기다림
failed: 원인과 재시도 조건이 기록됨
completed: 결과와 검증 증거가 확정됨

completed를 API 호출 성공과 동일하게 취급하면 안 된다. 결과 파일이 실제로 생성됐는지, 검증이 통과했는지, 재실행 시 중복이 없는지를 확인해야 완료라고 부를 수 있다.

실제 사례 / 신호

Prime Agent는 자기개선 코딩 하네스를 RLM과 Continual Harness라는 두 추상화로 설명한다. 공개된 소개만으로 특정 성능 수치를 모든 환경에 일반화할 수는 없지만, 제품 설계 관점에서 중요한 신호는 분명하다. 컨텍스트와 하네스 상태가 고정된 설정 파일이 아니라 실행 중 관리되는 작업 표면이 되고 있다는 점이다.

같은 시기 공개된 AI 팀원 제품들은 여러 Bot을 병렬로 배치해 프로젝트를 수행하는 흐름을 보여준다. 그러나 병렬 실행 수가 늘어날수록 승인 대기, 실패, 재시도, 완료를 구분하는 상태 표면이 더 중요해진다. 많은 에이전트를 돌리는 것과 운영 가능한 팀을 만드는 것은 같은 일이 아니다.

AI가 코드를 대량 생성하면서 리뷰와 유지보수가 새로운 병목이 된다는 논의도 같은 방향을 가리킨다. 생성량이 늘어날수록 하네스는 결과를 만드는 장치가 아니라 결과를 검증하고 다음 실행에 반영하는 장치가 되어야 한다.

실전 활용 팁: 반복 오류를 다음 실행 규칙으로 바꾸는 법

작은 AI 유틸이나 사내 에이전트를 운영한다면 다음 네 단계를 먼저 구현한다.

작업 단위를 고정한다. 입력, 결과, 검증을 하나의 실행 ID로 묶는다. 여러 작업의 로그를 섞지 않아야 원인을 추적할 수 있다.
수정 diff를 남긴다. 사용자가 결과를 고친 부분을 단순 최종본이 아니라 원래 결과와의 차이로 저장한다.
반복 오류만 후보로 올린다. 한 번의 실수는 관찰하고, 같은 오류가 반복되거나 영향이 큰 경우에만 규칙 후보를 만든다.
업데이트 전후를 비교한다. 새 규칙이 목표 오류를 줄였는지와 정상 입력을 망가뜨리지 않았는지를 작은 eval로 함께 확인한다.

이 구조는 거대한 자기개선 플랫폼이 없어도 적용할 수 있다. JSONL 실행 로그, 오류 분류 필드, 승인된 체크리스트 파일만으로도 첫 루프를 만들 수 있다.

바로 해볼 실험

1~3일짜리 실험이라면 입력과 출력이 분명하고 반복 오류가 보이는 작업을 하나 고른다. 예를 들어 SQL→ERD 변환에서 파싱 경고와 사용자의 수정 diff를 저장한다.

첫날: 실행 ID, 입력 hash, 결과, 검증 결과를 기록한다.
둘째 날: 반복되는 오류 세 종류를 분류하고 반례를 만든다.
셋째 날: 가장 빈번한 오류 하나에 대한 체크리스트를 업데이트하고 이전 사례를 재실행한다.

측정할 값은 모델 점수가 아니다. 동일 오류 반복률, 재실행 성공률, 첫 결과까지 걸린 시간, export 후 수동 수정 수를 비교한다. 개선 전후의 기록을 나란히 볼 수 있으면 실험은 이미 충분히 유용하다.

리스크 / 반론

실행 로그를 많이 남긴다고 자동으로 학습이 되는 것은 아니다. 잘못 분류된 실패를 규칙으로 승격하면 회귀가 누적될 수 있다. 그래서 규칙 변경에는 승인자, 반례, 되돌리기 방법이 필요하다.

또한 모든 작업이 자기개선 루프를 필요로 하는 것도 아니다. 단순 변환이나 일회성 질문에는 고정된 함수가 더 저렴하고 예측 가능하다. 반복성과 오류 비용이 충분히 큰 작업에만 하네스를 두껍게 만드는 편이 낫다.

성능 수치나 특정 모델의 결과도 그대로 약속해서는 안 된다. 데이터, 도구, 평가 기준이 달라지면 결과가 달라진다. 자신의 입력과 실패 조건으로 작은 검증을 먼저 돌려야 한다.

결론

AI 에이전트의 다음 단계는 더 많은 스킬을 붙이는 일이 아니다. 실행을 읽을 수 있게 만들고, 실패를 분류하고, 검증된 규칙만 다음 실행에 반영하는 일이다.

자기개선 에이전트를 만들고 있다면 먼저 다음 질문부터 던져야 한다.

어떤 실행 상태를 중단 후에도 복구할 수 있는가?
사용자의 수정과 검증 결과가 다음 작업에 연결되는가?
규칙 변경이 기존 정상 사례를 망가뜨리지 않았다는 증거가 있는가?
실패한 작업을 처음부터 다시 돌리지 않고 이어갈 수 있는가?

에이전트가 스스로 성장한다고 말하기 전에, 실패가 다음 실행을 실제로 바꾸는지부터 확인해야 한다.