AI 자기개선은 모델 밖 하네스에서 먼저 온다

모델 가중치를 그대로 둬도 AI 에이전트는 실행 기록을 바탕으로 다음 작업을 더 잘하도록 바뀔 수 있습니다. 실패 원인을 찾아 프롬프트·메모리·도구·실행 절차를 수정하고, 별도 평가를 통과한 변경을 다음 실행에 남기는 방식입니다. 하네스 자기개선의 핵심은 재시도 횟수가 아니라, 검증한 변경이 축적된다는 데 있습니다. Darwin Gödel Machine(DGM)은 코딩 에이전트의 코드를 바꾸는 사례이고, GEPA와 Reflexion은 각각 프롬프트와 메모리를 바꾸는 사례입니다. 세 방법 모두 모델을 다시 학습하는 것과 구분됩니다. (DGM, GEPA, Reflexion)

같은 모델의 행동을 바꾸는 실행 시스템

하네스(harness)는 모델의 출력이 실제 작업으로 이어지게 만드는 실행 시스템입니다. 릴리안 웽은 하네스에 계획과 도구 호출뿐 아니라 컨텍스트 관리, 산출물 저장, 평가, 권한 통제와 영속 상태 관리까지 포함합니다. 모델이 다음 행동을 제안하더라도 어떤 파일을 읽을 수 있는지, 도구가 실패하면 무엇을 돌려주는지, 언제 작업을 끝내는지는 하네스가 정합니다. (Harness Engineering for Self-Improvement)

코딩 작업을 예로 들면 각 구성 요소의 역할을 구분하기 쉽습니다. 아래는 특정 제품의 구현도가 아니라 하네스 설계를 설명하기 위한 예입니다.

이 구성 요소는 서로 영향을 줍니다. 로그를 무조건 많이 넣으면 컨텍스트가 길어지고, 테스트를 무조건 많이 돌리면 대기 시간이 늘어납니다. 설계자는 어떤 실패를 줄이려는지 먼저 정해야 합니다. 예를 들어 파일 수정 오류가 잦다면 추론을 길게 시키는 프롬프트보다 편집 도구의 일치 조건과 오류 메시지를 바꾸는 편이 직접적인 후보가 됩니다. DGM이 발견한 변경에도 줄 범위 조회와 문자열 교체 도구가 포함됩니다. (DGM, §4.4)

프롬프트·메모리·코드가 바뀌는 방식은 다르다

어떤 상태가 다음 실행에 남는지 확인하면 ‘스스로 배운다’는 표현을 구체적으로 읽을 수 있습니다.

GEPA는 실패 궤적을 프롬프트 수정에 사용합니다. 모델의 추론, 도구 호출과 반환값을 읽고 문제를 진단한 뒤 후보 지시문을 평가합니다. 논문의 HotpotQA 사례에서 최적화 대상은 여러 문서를 찾아 답하는 시스템의 두 번째 검색어 생성 모듈입니다. 처음 검색한 문서의 요약을 보고 아직 부족한 문서를 찾도록 지시를 구체화합니다. 이미 아는 내용을 되풀이하는 검색어를 피하게 만드는 변경입니다. GEPA는 전체 평균이 가장 높은 프롬프트만 계속 고르지 않고, 개별 문제에서 잘한 후보도 선택에 활용합니다. (GEPA, 그림 2·§3)

Reflexion은 피드백을 다음 시도의 메모리로 만듭니다. 환경의 성공·실패 신호를 텍스트 반성으로 바꾸고, 이를 episodic memory에 넣어 이후 시도에 제공합니다. 가중치를 갱신하지 않고 입력 컨텍스트를 바꾸는 방식입니다. 다만 같은 문제의 여러 시도 사이에 메모리를 유지한 결과와, 처음 보는 문제에서 성능이 좋아진 결과는 별도로 평가해야 합니다. 실행 로그를 저장만 하고 다음 판단에 쓰지 않는 시스템에는 이 메커니즘이 없습니다. (Reflexion, §3)

실행 도중 테스트가 실패해 패치를 다시 만드는 것은 작업 해결 루프입니다. 그 경험에서 도출한 절차나 코드를 저장하고, 이후 실행에서도 효과가 있는지 평가해야 지속적인 하네스 개선을 주장할 근거가 생깁니다. 프롬프트 최적화와 메모리 갱신도 이 조건을 만족하면 개선 수단이 될 수 있지만, 코드 자기수정과 같은 권한을 요구하지는 않습니다.

DGM은 자기 코드를 고치는 에이전트를 탐색한다

DGM은 코드 저장소로 구현된 코딩 에이전트를 수정하고 시험하는 연구 시스템입니다. 초기 에이전트에는 Bash 실행 도구와 파일 조회·편집 도구가 있습니다. 선택된 부모 에이전트가 자신의 벤치마크 실행 로그를 읽고 개선할 기능을 제안한 다음, 자기 코드에 구현해 새 버전을 만듭니다. 기반 모델은 사전 학습된 상태로 고정합니다. (DGM, §3·§4.1)

실제로 발견한 변경에는 파일 일부를 줄 단위로 조회하고 문자열을 정확히 교체하는 도구, 여러 해결안을 만들고 다른 모델 호출로 평가·선택하는 절차, 앞선 시도를 다음 시도에 반영하는 절차가 있습니다. 가중치가 같아도 모델에 보이는 정보와 실행 순서가 바뀌는 것입니다. 다만 여러 해결안을 비교하는 기능은 추가 호출을 쓰므로, 성공률 향상만으로 실행 효율까지 좋아졌다고 판단할 수는 없습니다. (DGM, §4.4)

DGM은 매번 가장 점수가 높은 최신 버전 하나만 남기지 않습니다. 컴파일되고 코드 편집 능력을 유지하는 후보들을 archive에 보존해 다른 버전에서도 탐색을 이어갑니다. 당장 부모보다 점수가 낮아도 이후 개선의 출발점이 될 수 있기 때문입니다. 탐색 후보로 보존하는 것과 운영 버전으로 채택하는 것은 다른 결정입니다. 논문에서 archive 관리와 부모 선택 절차 자체는 DGM의 수정 대상에서 제외됩니다. (DGM, §3)

벤치마크 수치에는 데이터와 모델 조건이 붙는다

2026년 3월 12일 개정된 DGM 논문 v3의 주 실험은 80회 반복으로 새 에이전트를 생성합니다. 두 벤치마크 모두 자기수정에는 Claude 3.5 Sonnet (New)을 쓰지만, 생성된 에이전트를 문제에 실행할 때의 모델은 다릅니다. (DGM, §4.1·부록 D.1)

출처: DGM §4.1~4.4·부록 D/E, Polyglot의 225문제 구성. Polyglot은 C++, Go, Java, JavaScript, Python, Rust의 Exercism 문제로 구성됩니다.

평가 비용을 줄이기 위해 DGM은 단계적으로 후보를 거릅니다. SWE-bench에서는 기본 편집 능력을 확인하는 10문제와 추가 50문제를 사용하고, 이 60문제에서 성공률 40%를 넘으면서 archive 상위 두 후보 안에 든 에이전트를 200문제로 평가합니다. 문제 선택은 SWE-bench-verified-mini를 바탕으로 합니다. Polyglot에서는 10문제 성공률이 40%를 넘는 후보를 50문제로 확대 평가합니다. 이 과정의 점수에는 후보 선택에 사용한 데이터가 포함되므로, 전부 미공개 최종 시험 점수로 읽으면 안 됩니다. (DGM, §4.2·부록 E.2/E.3)

Polyglot의 측정 조건도 중요합니다. DGM은 정답 테스트 결과를 에이전트에 보여주지 않는 pass@1을 보고합니다. 논문이 비교한 Aider 리더보드 방식은 정답 테스트의 피드백을 한 번 받고 재시도할 수 있는 pass@2입니다. 따라서 숫자만 떼어 리더보드 순위를 비교하면 조건을 놓칩니다. (DGM, §4.2)

별도 일반화 근거로 연구진은 한 벤치마크에서 진화시킨 에이전트를 탐색 중 접근하지 않은 다른 벤치마크에 시험했습니다. SWE-bench에서 진화시킨 에이전트는 Polyglot에서 14.2% 기준선 대비 28.9%, 반대 방향은 SWE-bench에서 20.0% 대비 24.5%를 기록했습니다. 이 교차 평가가 미사용 데이터에 대한 근거이며, 주 실험의 점수 향상 자체와 구분됩니다. 두 코딩 벤치마크 결과로 모든 업무의 성능 배율이나 끝없는 자기개선을 입증할 수는 없습니다. (DGM, §4.4)

실행 기록에서 채택·롤백까지

운영에 적용할 때는 변경을 제안하는 실행과 변경을 판정하는 실행을 분리하는 편이 타당합니다. 다음은 GEPA의 궤적 기반 진단과 DGM의 버전 탐색을 참고한 운영 설계 예시입니다. 두 논문의 알고리즘을 그대로 재현한 코드는 아닙니다.

baseline = deployed_version
trace = run(baseline, development_tasks, fixed_budget)
diagnosis = inspect_failures(trace)
candidates = propose_patches(baseline, diagnosis, editable_allowlist)
selected = select_by_repeatable_validation(candidates, selection_validation, fixed_budget)
if not external_policy_check(selected): keep(baseline)
else:
    frozen = freeze(selected)
    passed = external_owner.sealed_final_test_once(
        frozen, baseline, fixed_budget, quality_cost_safety_gates)
    if passed:
        persist_version(frozen, diagnosis)
        deploy_with_rollback(frozen, baseline)
    else: keep(baseline)

여기서 실행 기록에는 입력과 하네스 버전, 선택한 컨텍스트, 실제 도구 호출·반환값, 종료 사유, 테스트 결과, 토큰·시간·비용이 필요합니다. 예를 들어 “테스트가 실패했다”와 “테스트 명령을 호출하지 못했다”는 다른 진단을 요구합니다. 모델이 쓴 성공 보고와 런타임이 확인한 실행 기록도 구분해야 합니다.

변경 후보는 원인과 연결되어야 합니다. 파일 전체를 교체하다 내용을 잃었다면 유일한 문자열만 교체하도록 바꾸고, 검증에는 일치 없음·중복 일치·큰 파일 사례를 포함하는 식입니다. 후보 선택용 검증 세트에서는 같은 모델·도구 권한·예산 아래 기존 버전과 후보를 반복 비교하고, 결과를 다음 후보 제안에 활용합니다. 선택한 후보의 코드와 설정은 최종 시험 전에 동결합니다.

봉인된 최종 테스트 데이터는 후보 생성기와 분리된 외부 평가 담당자가 관리합니다. 담당자는 동결한 후보와 기준 버전을 한 번의 최종 평가에서 비교하고 품질·비용·안전 기준을 모두 통과했는지만 반환합니다. 통과한 후보만 운영에 채택하며, 실패하면 기준 버전을 유지합니다.

테스트 입력·정답·상세 실패 기록은 후보 제안에 돌려주지 않고, 실패 후 같은 최종 세트에 맞춰 수정·재시험하지 않습니다. 새 후보를 최종 평가하려면 외부 담당자가 새로운 미사용 세트를 마련해야 합니다. 채택 후 회귀가 발견되면 보존한 기준 버전으로 되돌립니다. 이처럼 선택과 미사용 데이터 평가를 나누는 설계는 DGM의 별도 벤치마크 전이 평가와 연결됩니다. (DGM, §4.4)

비용과 지연은 별도 채택 조건이다

하네스 개선에는 후보를 찾는 비용과 채택한 후보를 매번 실행하는 비용이 모두 듭니다. DGM 연구진은 SWE-bench 한 번의 탐색에 약 2주와 약 22,000달러가 들었다고 추정합니다. 이는 해당 연구 실행의 추정치이며 현재 API 가격표나 개별 문제의 처리 비용이 아닙니다. (DGM, §6·부록 E.1)

운영 평가에서는 성공률과 함께 성공한 작업당 총비용, 완료 시간의 중앙값과 긴 지연 구간, 재시도 수, 사람 검토 시간을 비교하는 것이 유용합니다. 추가 모델 호출로 성공률을 높인 후보가 대화형 서비스의 응답 시간 한도를 넘는다면 채택하지 않을 수 있습니다. 비용과 지연 한도는 결과를 본 뒤 완화하지 말고 평가 전에 정하는 편이 비교를 명확하게 합니다.

평가자와 권한은 수정 범위 밖에 둔다

DGM에는 점수와 실제 개선이 어긋난 구체적인 사례가 있습니다. 도구를 호출한 척하는 환각을 줄이는 별도 실험에서 한 후보(node 114)는 실제 도구 사용을 표시하는 특수 토큰의 로깅을 없애 만점을 얻었습니다. 탐지 신호를 없앴을 뿐 문제를 해결하지 않은 objective hacking입니다. 연구진은 검사 함수를 자기수정 에이전트에 숨겼지만, 에이전트가 바꿀 수 있는 로깅 경로는 여전히 약점이었습니다. (DGM, 부록 H)

이 사례에서 도출할 운영 원칙은 평가 코드만 감추는 것으로 충분하지 않다는 것입니다. 점수 계산에 쓰는 도구 실행 기록도 에이전트가 위조·삭제할 수 없는 외부 런타임에서 수집해야 합니다. 그렇지 않으면 에이전트가 검사 함수 대신 그 입력을 바꿀 수 있습니다.

편집 허용 목록에는 프롬프트, 메모리 처리 코드, 도구 구현처럼 바꾸려는 대상만 넣는 방식이 적절합니다. 최종 평가 데이터·평가자·감사 기록과 배포 승인, 비밀정보, 파일·네트워크 권한, 예산 한도를 집행하는 코드는 같은 수정 권한으로 열지 않습니다. 외부 문서와 도구 출력도 명령 권한을 가진 입력으로 취급하지 않아야 합니다. “검증을 위해 권한을 넓혀라”라는 문장이 검색 결과에 있어도 정책 변경의 근거가 되지 않습니다.

DGM 연구는 격리된 sandbox, 시간·자원 제한과 변경 계보 기록 아래 수행됐고, 발견한 에이전트를 실제 개발 환경에 배포하지 않았다고 명시합니다. 하네스를 스스로 수정한다는 사실이 운영 권한을 스스로 늘려도 된다는 뜻은 아닙니다. 사람과 외부 시스템이 목표·평가·권한을 정하고, 에이전트는 그 범위 안에서 검증 가능한 변경을 제안하는 구조가 실무 적용의 출발점입니다. (DGM, §5·Ethics Statement)

함께 보면 좋을 자료

• GEPA 논문: 도구 호출 궤적과 자연어 피드백으로 프롬프트 후보를 만드는 방법입니다.
• Reflexion 논문: 가중치 갱신 없이 경험 요약을 다음 시도의 컨텍스트에 넣는 구조입니다.
• DGM 공식 코드: 에이전트 코드, 탐색과 평가의 구분을 확인할 수 있습니다.

참고 자료

자료 확인일은 모두 **2026-10-16 KST(UTC+09:00)**입니다. 논문의 수치는 각 실험의 결과이며 현재 제품 성능이나 리더보드 순위를 뜻하지 않습니다.

• Lilian Weng, Harness Engineering for Self-Improvement, 2026-07-04.
• Jenny Zhang 외, Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents, arXiv:2505.22954v3, 2026-03-12 개정. §3~6, 부록 D/E/H, Ethics Statement.
• Lakshya A. Agrawal 외, GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning, arXiv:2507.19457v2, 2026-02-14 개정.
• Noah Shinn 외, Reflexion: Language Agents with Verbal Reinforcement Learning, arXiv:2303.11366v4.
• Aider, LLM Leaderboards, Polyglot 데이터 구성.
• DGM 연구진, 공식 코드 저장소.