--- type: WebPage title: 자기 개선을 위한 하네스 엔지니어링 | GeekNews description: "" resource: https://news.hada.io/topic?id=32179 tags: [] timestamp: 2026-08-06T07:53:33.607848Z --- [GeekNews](/) [최신글최신](/new) [예전글예전](/past) [쓰레드](/threads) [댓글](/comments) [포럼↗](https://beebs.hada.io/b/geeknews) [Ask](/ask) [Show](/show) [GN⁺](/plus) [Weekly](/weekly) [GeekBotsBots](/geekbots) [GeekBadgeBadge](/geekbadge) [후원](/support) | [글등록등록](/write) 검색 [로그인](/login) ▲ [# 자기 개선을 위한 하네스 엔지니어링](https://lilianweng.github.io/posts/2026-07-04-harness/) (lilianweng.github.io) 11P by [GN⁺](/%40neo) 17시간전 | ★ favorite | [댓글 2개](topic?id=32179) * 재귀적 자기 개선(RSI)의 단기 경로는 모델이 직접 가중치를 고치는 것보다, 사고·도구·맥락·기억·평가를 조율하는 **하네스 자체를 개선**해 더 나은 연구·배포 시스템을 만드는 방식에 가까움 * 하네스는 단순 프롬프트를 넘어 **워크플로 자동화**, 파일 기반 영속 메모리, 병렬 서브에이전트, 권한 제어, 평가와 상태 관리를 아우르는 런타임·소프트웨어 시스템임 * ACE·MCE·Meta-Harness는 최적화 대상을 구조화된 맥락에서 맥락 관리 기술과 **하네스 코드**까지 넓히며, ADAS·AFlow·STOP·Self-Harness·AHE는 실행 결과를 바탕으로 워크플로와 구성 요소를 반복 개선함 * 진화적 탐색은 평가 가능한 코드와 하네스를 폭넓게 탐색하며, DGM은 `Claude 3.5 Sonnet` 기반 에이전트의 SWE-bench Verified 성능을 **20%에서 50%**, Polyglot을 14.2%에서 30.7%로 높였지만 느리거나 모호한 평가에는 적용하기 어려움 * 완전한 자기 개선에는 모델 지능과 신뢰할 수 있는 평가가 필수이며, **보상 해킹**, 맥락 수명주기, 다양성 붕괴, 장기 유지보수, 부정적 결과 보존 문제 때문에 평가기·권한·보안과 중요한 인간 감독은 개선 루프 외부에 둬야 함 --- ## 재귀적 자기 개선과 하네스 * [I. J. Good의 1965년 개념](https://philpapers.org/rec/GOOSCT)은 인간의 모든 지적 활동을 능가하고 더 나은 기계를 설계할 수 있는 “초지능 기계”를 정의함 * [Yudkowsky의 2008년 정의](https://www.lesswrong.com/posts/JBadX7rwdcRFzGuju/recursive-self-improvement)는 AI가 현재 지능으로 자신의 지능을 생산하는 인지 장치를 개선하는 **재귀적 피드백 루프**를 가리킴 * 현대 AI의 RSI는 모델이 가중치를 직접 다시 쓰는 방식뿐 아니라, 훈련 파이프라인과 배포 시스템을 개선해 경제적으로 가치 있는 작업에서 더 나은 후속 모델을 만드는 방식까지 포함함 * **하네스(harness)** 는 기반 모델을 둘러싸고 실행을 조율하는 시스템임 + 모델이 사고하고 계획하는 방식 + 도구 호출과 행동 + 맥락 인식과 관리 + 산출물 저장 + 결과 평가를 결정함 * Claude Code와 Codex 같은 코딩 에이전트는 원시 모델 성능뿐 아니라 현실 맥락과 연결되는 **배포 계층**의 중요성을 보여줌 * 모델 자기대전, 합성 데이터, 테스트 시점 훈련, 지속 학습도 RSI와 관련되지만 하네스 엔지니어링의 직접 범위에서는 제외됨 ## 하네스 설계 원칙 * 초기 에이전트 공식인 `LLM + memory + tools + planning + action`에서 더 나아가 **워크플로 설계**, 평가, 권한 제어, 영속 상태 관리를 포함함 * 프롬프트 템플릿보다 런타임과 소프트웨어 시스템 설계에 가까우며, 모델이 관찰·행동·기억·검사·개선하는 방식을 규정함 * 일반화와 사전학습 지식 활용을 위해 의도적으로 단순하고 범용적으로 설계해야 함 * 운영체제처럼 복잡한 내부 로직을 캡슐화하면서 인터페이스는 단순하게 유지해야 하며, 설정·도구 인터페이스·프로토콜은 산업 전반에서 표준화될 수 있음 * ### 목표 지향 워크플로 + [Karpathy의 autoresearch](https://github.com/karpathy/autoresearch)는 모델이 운영·시험·반복할 수 있는 자동화 워크플로 사례임 + 일반적인 루프는 **계획 → 실행 → 관찰·시험 → 개선 → 재실행**을 목표 달성까지 반복함 + 작업 명세나 실행 선호가 불명확하면 사용자에게 먼저 확인을 요청할 수 있음 + 정적 프롬프트 대신 에이전트 런타임에서 자체 실행 궤적과 실패 사례를 분석하고 진행 방식을 수정함 * ### 파일 시스템 기반 영속 메모리 + 전체 워크플로와 로그를 맥락 창에 넣지 않고 **파일에 내구성 있는 상태**를 저장함 + 실험 로그, 코드 diff, 논문 요약, 오류 추적, 과거 실행 궤적은 장기 작업에서 훈련 당시 맥락 창보다 훨씬 커질 수 있음 + `bash` 등을 통한 파일 읽기·쓰기·편집은 LLM의 기반 능력이므로, 모델 자체가 좋아질수록 파일 기반 메모리 관리도 자연스럽게 개선됨 * ### 서브에이전트와 백엔드 작업 + 여러 가설을 탐색하거나 실험을 동시에 실행하고 독립 하위 작업을 위임할 때 **서브에이전트 병렬화**를 활용함 + 부모 에이전트는 작업 시작, 로그 검사, 실패 실행 취소, 결과 병합을 담당하는 작은 프로세스 관리자가 필요함 + 병렬 실행은 명시적이고 검사 가능해야 함 + 결과를 일시적 채팅 맥락에만 두면 빠르게 낡고 감춰짐 + 파일·로그·상태 레코드로 남기면 중단 후 복구하고 실행 이력을 추론할 수 있음 ## 코딩 에이전트 하네스의 공통 인터페이스 * Claude Code, Codex, OpenCode, Cursor 계열 에이전트는 저장소에서 인간 개발자가 IDE를 쓰듯 도구를 호출하며 개발·디버깅하는 공통 루프로 수렴함 * 주요 도구 그룹은 다음과 같음 + **파일 시스템**: `glob`, `grep`, `ls`, `read`, `read_many`, `write`, `edit`, `multi_edit`, `apply_patch` + **셸 실행**: `bash`, `PowerShell` + **입출력·버전 관리**: `lsp`, `git_status`, `git_diff`, `git_commit` + **외부 맥락**: MCP 도구, Skills + **웹 접근**: `web_search`, `web_fetch`, 브라우저 도구 + **산출물**: 문서·이미지 읽기, HTML·이미지 생성 + **백엔드 프로세스**: `CronCreate`, `CronDelete`, `CronList` + **에이전트 위임**: `spawn_agent`, `resume_agent`, `wait_agent`, `list_agents`, `close_agent`, `interrupt_agent` ## 하네스와 모델 지능의 관계 * 가까운 시기의 RSI는 모델이 직접 가중치를 다시 쓰는 데서 시작하기보다 **더 좋은 답을 얻는 장치 자체를 개선**하는 메타 방법론으로 발전할 가능성이 큼 * 하네스도 최적화 대상이 되면서 휴리스틱 규칙은 줄고 일반적인 메커니즘은 늘어남 * 성숙한 하네스는 모델 자기 개선용 자동 연구를 가능하게 하고, 더 똑똑한 모델은 하네스의 과도한 복잡화를 막아 시스템을 지속 가능하게 함 * 일부 하네스 기능이 모델 내부 행동으로 흡수될 수 있지만 외부 맥락·도구 인터페이스는 남아야 함 * 프롬프트 요령이 지시 튜닝과 추론 향상으로 덜 중요해졌어도 **목표·제약·맥락·평가 지정**은 사라지지 않은 것과 같은 구조임 * 최적화 대상은 대략 `지시 프롬프트 → 구조화된 맥락 → 워크플로 → 하네스 코드 → 최적화기 코드`로 확장됨 ## 맥락 엔지니어링의 진화 * ### ACE: 누적 프롬프트 대신 진화하는 플레이북 + [Agentic Context Engineering(ACE)](https://arxiv.org/abs/2510.04618)는 모든 도구 응답과 생성을 계속 붙이지 않고, 맥락을 식별자와 설명을 가진 불릿형 **플레이북**으로 관리함 + 세 구성 요소가 하나의 플레이북을 유지함 1. **Generator**: 불릿을 참고해 작업 궤적을 생성함 2. **Reflector**: 성공·실패 궤적에서 통찰을 추출함 3. **Curator**: 항목별 증분 기록으로 구조화된 맥락을 갱신함 + Curator는 전체 프롬프트를 다시 쓰지 않고 `(identifier, description)` 항목을 출력하며, 결정론적 로직이 이를 로그북에 병합함 + 반복 재작성에 따른 맥락 붕괴와 과도한 축약을 막고, 항목은 주기적으로 정제·중복 제거됨 + 실행에서 통찰을 학습하지만 갱신 규칙과 전체 워크플로는 여전히 수작업임 * ### MCE: 맥락 관리 방법까지 진화 + [Meta Context Engineering(MCE)](https://arxiv.org/abs/2601.21557)는 **관리 메커니즘**과 맥락에 담긴 산출물을 분리함 + 메타 수준에서는 기술(skill)을 진화시키고, 기본 수준에서는 해당 기술에 따라 작업 맥락을 최적화함 + 기술은 입력을 맥락으로 매핑하는 맥락 함수를 정의함 - 정적 구성 요소: 프롬프트, 지식 베이스, 코드 라이브러리 - 동적 연산자: 검색, 선택, 필터링, 형식화 + 기술 데이터베이스는 과거 기술, 맥락 함수, 평가 지표 이력을 저장함 + 메타 에이전트는 이전 기술을 **교차(crossover)** 해 새 기술을 만들고, 기본 수준의 맥락 엔지니어는 실행 피드백으로 맥락 함수를 학습함 + ACE처럼 구조화 규칙을 강제하지 않고 자유 형식 기술과 기술 조건부 맥락을 함께 반복 진화시킴 + 구현은 전용 디렉터리의 `skill.md`, 맥락, 데이터 실행 기록 등 파일 모음이며, 두 수준 모두 표준 도구를 갖춘 코딩 환경에서 실행됨 * ### Meta-Harness: 하네스를 최적화하는 하네스 + [Meta-Harness](https://arxiv.org/abs/2603.28052)는 저장·검색·제시할 정보를 결정하는 **코드 자체**를 최적화함 + 제안자는 코딩 에이전트이며 최종 결과는 파레토 전선의 하네스 후보 집합임 + 전체 실행 이력은 파일 시스템에서 `grep`, `cat` 등으로 읽고 단일 프롬프트에 모두 넣지 않음 + 각 후보는 소스 코드, 점수, 실행 궤적, 상태 갱신을 담은 디렉터리임 + 반복적으로 후보를 만들고 자격을 충족한 하네스만 유지함 + TerminalBench-2 탐색은 강한 하네스인 Terminus-KIRA와 Terminus-2에서 시작했지만, 하네스 설계가 실행 가능한 탐색 공간이 되면 강한 코딩 에이전트도 인간 엔지니어와 같은 공간을 활용할 수 있음을 보여줌 ## 자동 연구와 워크플로 탐색 * ### 전문가가 설계한 연구 파이프라인 + [AI Scientist](https://www.nature.com/articles/s41586-026-10265-5)는 연구 아이디어 제안, 코드 작성, 실험, 결과 분석, 논문 작성, 동료 평가를 하나의 파이프라인으로 구성함 + [ScientistOne](https://arxiv.org/abs/2605.26340)은 검증 가능성을 중심 제약으로 삼아 인용·수치·방법·결론을 증거 출처에 연결하고 **Chain-of-Evidence**로 감사함 + [Autodata](https://arxiv.org/abs/2606.25996)는 훈련·평가 데이터를 만드는 데이터 과학자 에이전트임 - 주 에이전트가 문제를 내는 challenger, weak solver, strong solver, verifier/judge를 관리함 - 강한 solver는 성공하고 약한 solver는 실패하는 “적절한” 난도의 데이터를 목표로 함 - solver와 verifier 피드백으로 challenger 프롬프트를 반복 갱신함 - 합성 작업은 약한 solver 미세조정에만 쓰이고 강한 solver는 개선하지 않아, 완전한 RSI보다 생성된 프롬프트 분포를 이용한 **간접 증류**에 가까운 한계가 있음 * ### ADAS와 AFlow + [Automated Design of Agentic Systems(ADAS)](https://arxiv.org/abs/2408.08435)는 에이전트 설계를 최적화 문제인 **메타 에이전트 탐색**으로 정의함 1. CoT와 self-refine 같은 단순 에이전트로 아카이브를 초기화함 2. 메타 에이전트가 기존 해법을 참고해 새 워크플로의 설명과 코드를 작성함 3. 두 차례 self-refine으로 피드백과 수정을 수행하고 새로움을 검사함 4. 후보를 평가해 성공한 것을 아카이브에 추가하고 최대 반복 횟수까지 계속함 + [AFlow](https://arxiv.org/abs/2410.10762)는 LLM 호출 행동을 노드로, 코드상의 논리 연산을 간선으로 표현하는 그래프 워크플로를 사용함 + **MCTS**로 템플릿 워크플로를 초기화하고 점수와 균등 탐색을 혼합해 노드를 선택함 + LLM이 평가 성능을 조건으로 수정안을 만들고, 실행·평가 후 예산 안에서 개선된 후보를 트리에 추가함 + 상위 평균 점수가 정체되거나 예산을 소진하면 중단하며, QA·코드·수학 실험에서 수작업 워크플로와 ADAS보다 개선됨 ## 하네스 전체를 자기 개선하기 * 맥락이나 워크플로만 따로 최적화하지 않고 맥락 관리, 권한, 프롬프트, 도구 호출, 서브에이전트, 제어 흐름, 메모리를 함께 탐색해야 함 * **코드**는 이 모든 요소의 결합 방식을 표현하는 범용 언어이며, 에이전트 실행 코드를 최적화하면 수작업 프롬프트보다 훨씬 큰 설계 공간에 접근할 수 있음 * ### STOP과 기반 모델의 한계 + [Self-Taught Optimizer(STOP)](https://arxiv.org/abs/2310.02304)은 초기 해법·효용 함수·블랙박스 언어 모델을 받아 해법을 개선하는 improver를 만들고, 다시 **improver 자체를 개선**함 + 여러 하위 작업에서 improver가 얻은 평균 효용을 메타 효용으로 사용해 재귀적으로 다음 버전을 생성함 + 실험에서 유전 알고리듬, 부분 분해와 개선, 다중 슬롯머신 프롬프트, 모의 담금질, 온도 변화, 빔·트리 탐색을 발견함 + GPT-4에서는 반복할수록 평균 성능이 올랐지만 GPT-3.5와 Mixtral에서는 저하됨 + 재귀 구조만으로는 충분하지 않고 기반 모델이 개선 메커니즘을 다룰 만큼 강해야 함 * ### 하네스 수정 능력과 활용 능력 + [Lin et al.](https://arxiv.org/abs/2605.30621)은 두 능력을 분리함 - **harness-updating**: 유용한 하네스 편집을 만드는 능력 - **harness-benefit**: 수정된 하네스를 활용해 작업 성능을 높이는 능력 + Qwen3.5-9B부터 Claude Opus 4.6까지 하네스 편집 능력은 비슷했고, 9B 제안자도 Opus와 절차적으로 동형인 기술을 작성할 수 있었음 + 하네스를 잘 활용하려면 기술과 도구를 정확한 시점에 호출하고 장기 지시를 잘 따라야 함 + 활용 이득은 모델 크기에 따라 단조롭게 증가하지 않았으며 **중간급 모델**이 가장 큰 이득을 얻음 * ### Self-Harness + [Self-Harness](https://arxiv.org/abs/2606.09498)는 제안·평가·수용 루프로 자체 하네스를 개선함 + **약점 채굴** 단계는 현재 하네스의 작업 실행과 추적을 모아 verifier에 근거한 실패 패턴으로 군집화함 - timeout이나 산출물 누락처럼 표면 결과가 같아도 원인이 다를 수 있음 - verifier 수준 원인, 관련 행동의 인과적 상태, 추적에서 드러난 추상적 에이전트 메커니즘을 함께 기록함 + **하네스 제안** 단계는 동일 모델에 편집 가능 영역, 실패 패턴, 보존할 성공 행동, 과거 편집 요약을 제공함 - 작업 고유 난도보다 반복적이고 수정 가능한 오류를 우선함 - 좁은 변경으로 해결하며 후보는 서로 구별되고 다양해야 함 + **검증** 단계는 held-in 데이터로 약점 해결 여부를, held-out 데이터로 새 회귀 발생 여부를 검사함 - 두 분할 모두에서 회귀가 없는 후보만 병합함 - 거절된 후보는 기록하되 활성 하네스를 바꾸지 않음 + Terminal-Bench-2에서 `MiniMax M2.5`, `Qwen3.5-35B-A3B`, `GLM-5`별 약점에 맞는 지시를 학습해 held-out 통과율을 높임 + 프로그램이 운영체제 계층을 편집하면 추상화 경계가 깨질 수 있으므로 **편집 가능 표면**, 권한 제어, 보안 계층은 루프 밖에 있어야 하며 보상 해킹 문제도 남음 * ### AHE와 관찰 가능성 + [Agentic Harness Engineering(AHE)](https://arxiv.org/abs/2604.25850)는 실패 책임 소재와 편집 근거를 밝히는 **관찰 가능성**을 중심에 둠 + 세 가지 관찰 가능성으로 폐쇄 루프를 구성함 1. **구성 요소 관찰 가능성** - 시스템 프롬프트, 도구 설명, 도구 구현, 미들웨어, 기술, 서브에이전트 설정, 장기 메모리의 7개 구성 요소를 파일 시스템에 표현함 - 실패 패턴을 하나의 구성 요소와 연결해 편집 범위를 좁힘 2. **경험 관찰 가능성** - 각 작업 궤적을 파일로 저장하고 Agent debugger가 성공·실패의 근본 원인을 분석함 - 작업별 보고서를 벤치마크 개요로 집계하되 필요하면 원시 추적까지 내려갈 수 있어 토큰 효율을 높임 3. **결정 관찰 가능성** - Evolve agent가 저장소를 읽고 수정할 구성 요소와 근거를 정함 - 모든 편집은 다음 라운드에서 검증 가능한 파일 단위 주장임 + 편집은 하네스 작업 공간에만 허용되고 실행 디렉터리, 추적기, verifier, LLM 설정은 읽기 전용임 + verifier 비활성화, 모델 교체, 추론 예산 확대 같은 보상 해킹을 차단함 + 각 성능 향상을 하네스 편집에 귀속할 수 있음 + 각 편집 기록은 실패 증거 이름, 추정 원인, 수정 대상, 예상 개선과 회귀 위험을 포함함 + Terminal-Bench-2에서 Hard tier를 제외하면 OpenCode·Terminus-2·Codex 같은 인간 설계 하네스보다 우수했고 일부 자기 진화 기준선인 ACE·TF-GRPO도 앞섬 + 추가 진화 없이 고정한 하네스가 SWE-bench Verified로 전이되어 벤치마크별 최적화가 아니라 **엔지니어링 경험**을 구성 요소에 인코딩했음을 보여줌 ## 진화적 프로그램·하네스 탐색 * 진화적 탐색은 후보 집단을 변이시키고 높은 적합도의 후보만 보존함 * 탐색 공간이 크거나 불규칙하고 기울기로 직접 최적화하기 어렵지만 후보 평가는 쉬울 때 적합함 * [Promptbreeder](https://arxiv.org/abs/2309.16797)는 작업 프롬프트와 이를 변이시키는 **변이 프롬프트**를 함께 진화시킴 * [GEPA](https://arxiv.org/abs/2507.19457)는 시행착오 궤적에 대한 자연어 성찰과 진화적 탐색을 결합해 프롬프트 갱신을 제안함 * ### AlphaEvolve 계열 + [AlphaEvolve](https://arxiv.org/abs/2506.13131)는 후보 프로그램 풀을 유지하며 고정된 LLM이 개선 diff를 만들고 성공한 자식 프로그램을 보존함 + 프롬프트에는 부모 프로그램, 결과, 지시와 필요시 메타 정보가 들어감 + 에이전트는 전체 저장소에 접근하지만 수정 영역은 `# EVOLVE-BLOCK-START`와 `# EVOLVE-BLOCK-END`로 제한됨 + 메타 프롬프트도 해법 프로그램과 함께 진화함 + 제거 실험은 진화 절차, 프롬프트 맥락, 메타 프롬프트, 전체 파일 진화, 강한 LLM의 가치를 확인함 + [ThetaEvolve](https://arxiv.org/abs/2511.23473)는 진화 탐색에 강화학습과 맥락 내 학습을 결합함 + [DemoEvolve](https://arxiv.org/abs/2605.24539)는 인간 전문가 시연을 자기 실행 아카이브에 추가해 하네스 진단과 편집의 참고 경험으로 사용함 + [ShinkaEvolve](https://arxiv.org/abs/2509.19349)는 표본 효율을 높이는 세 요소를 도입함 - 성능 순위와 자식 수의 균형을 맞추는 부모 표본 추출 - 임베딩 코사인 유사도로 기존 집단과 너무 비슷한 코드를 거절하는 참신성 표본 추출 - 성공 해법의 좋은 패턴을 메타 스크래치패드에 기록해 이후 변이를 안내함 * ### Darwin Gödel Machine + [Darwin Gödel Machine(DGM)](https://arxiv.org/abs/2505.22954)은 해법뿐 아니라 LLM 코딩 에이전트가 사용하는 **편집 가능한 하네스 저장소**를 진화시킴 + [Hyperagents](https://arxiv.org/abs/2603.19461)는 기존 작업 에이전트를 수정해 새 에이전트를 만드는 방식을 제어하는 메타 에이전트를 추가함 + DGM의 반복 과정은 다음과 같음 1. 코딩 에이전트 하나로 풀을 시작함 2. 성능에는 비례하고 자식 수에는 반비례하는 확률로 부모를 선택함 3. 부모가 자체 평가 로그를 살펴보고 `bash`와 `view/create/edit` 편집기로 하네스를 수정함 4. 새 에이전트를 평가해 충분히 우수한 후보만 풀에 추가함 5. 중단 조건까지 반복함 + 고정된 `Claude 3.5 Sonnet`과 단순한 초기 하네스에서 발견한 에이전트는 SWE-bench Verified를 20%에서 50%, Polyglot을 14.2%에서 30.7%로 높여 수작업 에이전트와 대등하거나 앞섬 + 자동 평가와 적합도 수치화가 쉬운 행렬 곱셈, GPU 커널, 알고리듬 대회, 데이터센터 스케줄링에 잘 맞음 + 평가가 느리거나 모호하고 휴리스틱 중심인 영역에서는 어려우며 **연산 효율과 진화 효과**도 과제로 남음 ## 하네스와 모델 가중치의 공동 최적화 * 하네스 진화는 모델 주변의 비매개변수 시스템을 바꾸지만, 완전한 자기 개선은 훈련 파이프라인 개선이나 테스트 시점 지속 학습으로 **가중치도 함께 갱신**할 수 있음 * [SIA](https://arxiv.org/abs/2605.27276)는 세 구성 요소를 같은 루프에 결합함 + Meta-Agent가 초기 하네스를 제안함 + Task-Specific Agent가 작업을 실행함 + Feedback-Agent가 최근 궤적을 보고 하네스와 모델 가중치 중 무엇을 갱신할지 선택함 * 실험에서는 작업 에이전트 `gpt-oss-120b`가 Meta-Agent와 Feedback-Agent의 `Claude Sonnet 4.6`보다 훨씬 약하고 기준선도 약해 결과 해석이 어려움 * 방향은 흥미롭지만 증거는 잠정적이며 **훈련 안정성과 Goodhart 효과**가 해결되지 않음 * [Continual Harness](https://arxiv.org/abs/2605.09998)는 장기 게임 환경에서 하네스를 갱신하면서, 저보상 궤적에 대한 강한 교사 모델의 레이블을 증류해 정책 모델도 함께 학습함 ## 자동 과학 연구가 드러낸 실패 * AI Scientist 계열은 전문가 설계 하네스가 논문 작성 형태의 자동 연구 상당 부분을 조율할 수 있음을 보여주지만, **논문 생산은 과학적 발견과 동일하지 않음** * 그럴듯한 원고를 작성해도 조작된 인용, 구현 이탈, 약한 실험 결과가 남을 수 있음 * [Trehan & Chopra](https://arxiv.org/abs/2601.03315)는 `read_file`, `write_file`, `llm_search`, `list_files`와 최소한의 비계만 제공해 연구 아이디어부터 논문까지 실행함 + 월드 모델, 다중 에이전트 강화학습, AI 안전·정렬의 3개 분야를 사용함 + 분야마다 새 아이디어에 참고할 고품질 문서 45~50개를 제공함 + 인간 전문가가 4개 아이디어만 전체 파이프라인 대상으로 선택했고, 논문까지 완전히 실행된 것은 1개였음 * 반복된 여섯 실패 유형은 다음과 같음 1. **훈련 데이터 기본값 편향**: 오래된 라이브러리·명령·형식이나 실제 저장소와 데이터에 근거하지 않은 가정을 사용함 2. **실행 압박에 따른 구현 이탈**: 기술적으로 복잡해지면 제안한 방법 대신 흔하고 단순한 해법으로 이동함 3. **메모리·맥락 저하**: 로그를 영속 산출물로 쓰지 않으면 장기 프로젝트의 핵심 세부 사항을 잃음 4. **과도한 낙관**: 실패하거나 잡음뿐인 실험도 성공으로 선언하며, 수치를 임시로 덧대고 승리를 선언하는 “p-hacking and eureka-ing”이 나타남 5. **도메인 지능 부족**: 구현 난도 예측, 결과의 개연성 판단, 중요한 기준선 선택 같은 암묵적 숙련이 부족함 6. **약한 과학적 안목**: 실행 가능한 실험을 만들더라도 올바른 질문에 답하지 못함 ## 완전한 RSI를 가로막는 과제 * ### 1. 약하고 모호한 평가기 + 많은 연구와 현실 작업에는 빠르고 정확한 verifier가 없으며, 현재 자기 개선 루프는 강화학습처럼 **객관적으로 측정 가능한 지표**가 있을 때 가장 잘 작동함 + 연구 안목, 참신성, 장기 과학 가치는 문제 구성·실험 설계·놀라운 결과와 재시도할 실패를 고르는 판단이 섞여 측정하기 어려움 * ### 2. 맥락과 메모리의 수명주기 + 에이전트가 자율화될수록 메모리가 커지므로, 장기 맥락 생성의 한계를 보완하면서 장기 작업 성공률을 높여야 함 + 인간이 평생 기억을 유지하듯 **맥락 엔지니어링**은 소프트웨어 계층에만 머물지 않고 지능의 핵심 부분이 되어야 함 * ### 3. 부정적 결과 보존 + 연구 문헌은 성공에 편향되어 있고, 주로 인간 데이터로 학습한 LLM도 가설을 포기하거나 부정적 결과와 실패를 인정하는 데 약할 수 있음 + 실패에서 학습하면 작업 탐색 공간을 줄일 수 있으므로 연구 하네스는 **실패한 시도도 쉽게 보존**해야 함 * ### 4. 다양성 붕괴 + 진화와 강화학습 루프는 이미 알려진 고보상 패턴을 과도하게 활용하기 쉬움 + 후보 집단이 같은 해법의 변형으로 수렴하지 않도록 탐색 메커니즘이 필요하며, 현재 평가기에서 처음에는 나빠 보일 수 있는 개방형 연구에 특히 중요함 * ### 5. 보상 해킹 + 단위 테스트를 보상으로 쓰면 테스트에 과적합하고, judge 모델을 쓰면 해당 judge에 특화된 수법을 배우며, 벤치마크 점수는 벤치마크의 인공적 특성을 악용할 수 있음 + **평가기와 권한 제어**는 하네스 진화 루프 밖에 두고 held-out 시험, 실행 추적 감사, 중요한 결정 지점의 인간 검토를 적용해야 함 + 감독을 얼마나 확장·자동화할 수 있는지는 열린 연구 문제임 * ### 6. 장기 성공 기준 + 샌드박스 훈련에서 다루는 외재적 보상은 개별 실행 밖에서 계산되지만 목표가 대체로 단기적임 + 코딩 에이전트는 당장의 작업을 완료할 수 있어도 수백·수천 명이 유지하는 저장소의 장기 건강을 보호하는 방법은 불분명함 + 표준 샌드박스 기반 RLVR 훈련은 **유지보수성**, 소유권 경계, 마이그레이션 비용, 하위 호환성, 미래 디버깅 부담을 제대로 반영하지 못함 * ### 7. 인간의 역할 + 인간을 루프에서 제거하기보다 올바른 시점과 추상화 수준에서 감독하도록 **상위 계층으로 이동**시켜야 함 + 하네스 설계는 인간 피드백과 조정이 필요한 접점을 언제, 어떻게 둘지도 포함해야 함 ## 관련 평가 벤치마크 * [PaperBench](https://arxiv.org/abs/2504.01848): ICML 2024 Spotlight·Oral 논문 20편을 처음부터 재현함 + 논문 기여 이해, 코드베이스 개발, 실험 실행을 개별 채점 가능한 작업으로 분해함 + 논문 저자들과 함께 만든 평가 기준이 총 **8,316개**임 + 당시 최고인 `Claude 3.5 Sonnet`은 약 21%로 ML 박사보다 낮았음 + PaperBench, 경량판 PaperBench Code-Dev, JudgeEval을 포함함 * [CORE-Bench](https://arxiv.org/abs/2409.11363): 컴퓨터과학·사회과학·의학 논문 90편에서 만든 **270개 작업**으로 계산 재현성을 평가함 + 제공된 코드와 데이터로 결과를 재현하며 여러 난도와 언어·비전언어 작업을 포함함 + 가장 어려운 작업에서 `GPT-4o`와 `GPT-4o-mini` 기반 최고 에이전트의 정확도는 21%였음 * [ScienceAgentBench](https://arxiv.org/abs/2410.05080): 수학·화학·생물학·지리학의 동료평가 논문 44편에서 추출한 **102개 작업**으로 데이터 기반 과학 발견을 평가함 + 데이터 처리, 모델 개발, 데이터 분석, 정보 시각화를 다룸 * [RE-Bench](https://arxiv.org/abs/2411.15114): 현실적인 ML 연구 엔지니어링 환경 7개에서 최전선 에이전트와 인간 전문가를 비교함 + 각 환경은 점수 함수, 시작 해법, 참조 해법으로 구성되며 H100 GPU 8개 이하로 실행 가능함 + 커널 최적화, 스케일링 법칙 실험, 임베딩 수정, QA용 GPT-2 미세조정 등을 포함함 + 서로 다른 인간 전문가 61명의 8시간 시도 71건에서 82%가 0점보다 높았고 24%가 강한 참조 해법과 같거나 앞섬 + 최고 AI는 2시간 예산에서 인간보다 4배 높은 점수를 냈지만, 인간은 시간이 늘수록 더 개선돼 8시간과 32시간 설정에서 에이전트를 앞섬 * [MLE-bench](https://arxiv.org/abs/2410.07095): Kaggle에서 고른 오프라인 ML 엔지니어링 대회 **75개**로 모델 훈련, 데이터 준비, 실험, 예측 제출을 평가함 + Kaggle 공개 리더보드를 인간 기준선으로 사용함 + `o1-preview`와 AIDE 비계 조합은 대회의 16.9%에서 최소 동메달 수준에 도달함 + 자원 확장과 데이터 오염 분석도 포함함 * [KernelBench](https://arxiv.org/abs/2502.10517): **250개 PyTorch 작업**으로 생성된 GPU 커널의 정확성과 속도를 평가함 + `fast_p`는 정확하면서 기준선보다 빠른 생성 커널의 비율임 ## 함께 보면 좋은 글 β * [하네스 엔지니어링: 모델보다 중요한 작업 환경 설계의 시대](/topic?id=28966) * [소프트웨어 팩토리가 실패하는 이유: 하네스 엔지니어링만으로는 부족함](/topic?id=31776) * [[2026/06/08 ~ 14] 이번 주에 살펴볼 만한 AI/ML 논문 모음](/topic?id=30531) * [장기 실행 애플리케이션 개발을 위한 하네스 설계](/topic?id=27863) * [AI가 스스로를 만들 때: 재귀적 자기 개선을 향한 우리의 진전](/topic?id=30189) **GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다.** Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. [Weekly 구독](/weekly?utm_source=referrer_banner&utm_medium=site&utm_campaign=topic_footer) [GeekBots로 받기](/geekbots?utm_source=referrer_banner&utm_medium=site&utm_campaign=topic_footer) [GeekNews 소개](/start?utm_source=referrer_banner&utm_medium=site&utm_campaign=topic_footer) 숨기기 ## 댓글과 토론 인증 이메일 클릭후 다시 체크박스를 눌러주세요 ▲ [souljung](/%40souljung) [5시간전](/topic?id=32179#cid62962)  [-] 에이전트 세션 후 회고를 도입해 다음 작업의 가이드라인을 만드는 방식이 인상적이네요. 저도 비슷한 자동화 도구를 쓸 때 에이전트가 문맥을 놓치고 엉뚱한 결정을 내리는 경우가 잦았는데, 정기적인 회고 프로세스로 실패한 도구 호출이나 프롬프트를 보완하면 장기적으로 모델의 동작 안정성을 크게 높일 수 있을 것 같습니다. 답변달기 ▲ [GN⁺](/%40neo) [17시간전](/topic?id=32179#cid62929)  [-] ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49164896) * 대규모 코드베이스에서 이를 조직 차원으로 구현할 방법을 고민 중임. **AGENTS.md·스킬·도구**를 최적화하면 에이전트의 성능·품질·비용 효율을 높일 여지가 분명하지만, 품질을 정의하고 에이전트가 그 기준으로 하네스를 최적화하게 만드는 일이 어려움 첫 단계는 PR을 에이전트가 풀고 개선할 수 있는 채점 가능한 과제로 바꾸는, 범용적이고 신뢰도 높은 코드베이스 **적합도 함수**를 만드는 것이라 봄. 우리 회사도 현재 거의 감에 의존하고 있어 다른 곳의 최적화 방식이 궁금함 + 세션이 끝나면 에이전트와 실제로 **회고**를 진행함. 실패한 도구 호출, 혼란스러운 문서나 프롬프트, 이해하기 까다로웠던 표현, 다음 에이전트가 작업하기 쉽게 바꿀 부분을 모두 물어봄 그러면 코드 변경 아이디어, 사소한 버그, 지켜야 할 불변 조건과 원칙, 린트 규칙, 도구 개선, 스킬 파일 갱신, 후속 작업 등을 제안함. 에이전트의 불평을 귀담아들을 만함 + 약 1년간 AI 음성 에이전트 하네스를 직접 만들었는데, 좋은 소프트웨어 아키텍처 원칙을 따르고 이를 `agents.md`에 명시하는 것이 좋은 출발점이었음. 최종 목표와 중요 가치를 대략 설명하는 **비전·프로젝트 정신** 섹션도 에이전트가 경직되고 단선적으로 행동하지 않게 해줌 가장 큰 속도 향상은 출시 직전까지 프런트엔드 디자인을 완전히 미루면서 얻었음. UI 문제는 추진력을 죽이고 최적화 고민에 빠뜨리므로, 백엔드 반복 개선과 불필요한 부분 제거에 집중하면 아이디어를 빠르게 검증하거나 폐기할 수 있음. 이제 개발 전체를 자동화하려 하지만 예외 상황까지 사람 개입 없이 처리할 지침을 설계하려면 세심한 계획이 필요함 + 개인 프로젝트 기준이지만 비용 절감 효과가 가장 컸던 두 가지는 모든 터미널 명령을 **조용한 모드**로 실행하는 것과, 코드베이스 이해를 빠르게 하고 파일 전체 읽기를 줄이는 **코드베이스 인덱스 MCP**를 사용하는 것이었음. 후자는 결과물 품질도 크게 높여줬음 + 에서 이 접근을 재사용 가능한 형태로 시도 중이지만, 현재는 코드 결과물의 **품질**만 다룸 실제 평가에는 코딩 에이전트 세션에 관한 휴리스틱이 필요하지만 입력 과제가 매번 달라 KPI를 비교하기 어려움. 큰 작업에서 피드백을 세 번 받은 에이전트와 작은 변경을 피드백 없이 끝낸 에이전트 중 누가 더 나빴는지 판단하기 어려움 + 이것은 AI 업계에서 **평가(evals)** 라 부르며, 그 모음이 벤치마크를 이룸. 공개 벤치마크는 이미 포화됐거나 현실 성능을 잘 예측하지 못하는 경우가 많으므로 자체 평가를 정의하는 편이 좋음 평가 데이터가 학습 데이터에 들어갔을 가능성도 있으며, 신뢰할 만한 벤치마크가 이를 피하려 해도 얼마나 성공적인지는 확실하지 않음 * 가중치 학습은 정점에 도달했고 이제 **프롬프트와 코드의 학습 패러다임**이 필요하다고 봄. 여기에는 경사 하강법이 없지만, 단순 상관관계보다 인과 이론을 활용하면 표본 효율이 더 높을 수 있음 에서 통합 이론을 만들고 있음. 전부 에이전트가 편집해 읽기 어려울 수 있지만 논리 오류는 대부분 잡으려 하고 있음. 양의 피드백 순환에 필요한 초기 이론도 [https://zby.github.io/commonplace/articles/reflective-self-i...](https://zby.github.io/commonplace/articles/reflective-self-improvement/)에 있으며 아직 안정적이지 않지만 에이전트에게 읽혀볼 수 있음 + 가중치 학습이 정점에 도달했다기보다 **가속 중**이라고 볼 근거가 더 있지 않은지 궁금함. 이제 모델로 자기 자신을 개선하고 최적화를 시험하면서 손쉬운 성과를 더 많이 얻는 듯함 + 정점이 정확히 언제였는지 궁금함. 오늘이라면 알 수 없으니, 수개월 전에 이미 정점을 지났다고 보는 듯함 * **Torment Nexus**를 향한 탐구가 계속됨 + 우리가 먼저 만들지 않으면 훨씬 무책임한 누군가가 만들 것임. Torment Nexus IPO에 먼저 도달하려면 안전 우려까지 포기하고 선두에 서야 한다는 풍자임 + **TormentBench**를 손꼽아 기다리는 중임 * 하네스를 진화시키는 순환 밖에 평가기를 두는 데 동의함. 비슷한 에이전트 하네스 작업에서 겪은 실질적 실패는 **불완전한 검사 모음**이 전체 성공으로 보고하는 경우였으며, 약한 평가기보다 오히려 더 위험했음 시행착오 끝에 각 작업의 고정 검사가 모두 갖춰지지 않으면 아무것도 배포하거나 전송하지 않는 **실패 폐쇄(fail-closed) 방식**이 효과적이었음. 그렇지 않으면 실패했어야 할 테스트를 실행하지 않고도 통과할 수 있음 * 처음에는 autoresearch에서 영감을 받은 자기 개선 에이전트 프로젝트였지만, 이후 머신러닝 학습의 관점을 빌려 **하네스 학습**, 즉 이산 프로그램 탐색으로 재정의했음 로컬 `Qwen3.6-35B A3B`는 고정한 채 Terminal-Bench 2.0 일부 과제로 하네스를 학습했으며, 정확한 기여도 배분을 위해 LLM 추론과 과제 환경을 완전히 결정적으로 만드는 일이 필수였음. 초기 한 달을 실험 잡음에 허비하고 나서야 이를 깨달았음 전체 89개 과제에서 학습 중 접하지 않은 네 LLM에 대해 공식 Terminus 2 하네스와 같거나 더 나은 결과를 냈음. `GPT-OSS-120B`는 입력 토큰을 55% 적게 쓰면서 점수가 18.7%에서 36%로 상승했고, SWE-bench만으로 학습한 하네스도 Terminal-Bench 점수를 높였음. 자세한 내용은 에 있으며, 학습 순환은 PyTorch 스타일 프레임워크 으로 공개했음 * 지식 노동자를 위한 Cursor식 IDE인 에서 **언덕 오르기 실험**으로 버그 탐지뿐 아니라 하네스도 개선하고 있음. Codex의 AI 하네스 엔지니어링 스킬을 활용해 앱을 다듬고 있으며, 이 글 덕분에 해당 스킬도 개선할 수 있었음 * 두 번째 하네스를 작성 중임. 첫 번째는 Emacs를 UI로 사용한 Emacs Lisp 구현이었고, 두 번째는 Common Lisp로 만든 **명령줄 코딩 에이전트**임 자체 AI 코딩 하네스를 만드는 일이 비효율적이라는 데는 동의하지만, 직접 만든 도구로 긴 코딩 세션을 수행하는 만족감이 큼 + 에이전트와 **REPL**을 사용해 본 과정과 배운 점, 실제로 즐거웠는지 더 알고 싶음 + **AI Lisp 머신**의 꿈에 가까움. 에이전트가 실행 중 자기 하네스 코드를 직접 다시 작성하는 기능도 넣었는지 궁금함 * 하네스에 autoresearch를 적용하고 있는데 놀라울 정도로 강력함. 실행 추적만 살펴봐도 쉽게 발견하고 고칠 수 있는 문제가 많음 제대로 작동하려면 실제 문제를 찾도록 대량의 운영 환경 추적을 읽히고, 자체 도구를 작성하게 해야 함. 예를 들어 컨텍스트 불러오기를 도구 호출 15회와 2만 토큰에서 `session_context` 호출 1회와 800토큰으로 줄일 수 있음 또한 보상 해킹을 막을 평가와 검증·테스트 분할, 12시간 동안 자동 실행할 합성 사용자·합성 도구가 필요함. 최적화 대상도 100만 줄 코드베이스가 아니라 pi 하네스, 스킬 전용 구성, Kiln 하네스처럼 **합리적인 크기**여야 함 + 사용한 **적합도 함수와 평가 방식**이 궁금함 * 하네스가 최첨단 모델 기업이 가치를 확보하고 **진입 장벽**을 만드는 지점일 수 있는지 궁금함. 재미로 직접 만들어보고 싶지만, 공개 가중치 모델을 자체 호스팅할 때 더 흥미로울 듯함 ChatGPT나 Claude용 하네스를 직접 만드는 동기와, 최첨단 모델이 빠르게 발전하는 상황에서 이를 계속 조정하는 방법도 궁금함 + pi.dev 제작자의 영상 이 이 주제를 잘 다룸 연구소들은 Claude Code나 Codex의 시스템 프롬프트를 계속 갱신하는데, 프롬프트가 지나치게 비대하고 갱신 때마다 기반 자체가 바뀜. 생태계의 최신 변화를 따라갈 수 있다면 자체 하네스로 LLM 개발에서 잃기 쉬운 **통제권**을 상당 부분 되찾을 수 있음 일관성이 목표일 때는 pi.dev의 맞춤형 하네스를 배포하지만, PR의 절대적 품질이 가장 중요할 때는 여전히 Claude Code를 대안으로 사용함 + 최첨단 모델 기업들이 하네스로 진입 장벽을 만들려는 경로는 네 가지로 보임 첫째, 모델을 자사 하네스에 맞춰 최고 성능을 내려면 해당 하네스를 쓰게 만들 수 있으나, 비슷하거나 충분히 좋은 대안 모델이 있으면 무너짐. 둘째, 암호화된 추론 토큰과 비밀 프롬프트를 통해 사용자가 어떤 파일과 데이터가 처리되는지조차 모르게 하고 이식성을 없앨 수 있으나, 기업을 전적으로 신뢰하고 대안도 없어야 성립함 셋째, 구독 가격을 자사 하네스 사용과 묶어 타사 하네스 이용에 금전적 불이익을 주는 Anthropic식 전략이 있음. 넷째는 Claude Code 광고처럼 마케팅에 집중하는 방식이지만, **베블런재 AI**가 조 단위 사업이 될지는 의문임 공개 소스 모델과 도구의 혁신 압력 때문에 성공하기 쉽지 않을 것으로 보며, 개인적으로는 Openthropic의 몰락을 바라고 있어 편향된 판단일 수 있음 + 소비자용 기본 하네스는 한 하네스에게 다른 하네스를 작성시킬 수 있을 만큼 **범용재**라 진입 장벽이 거의 없음. 최신 모델은 작업 흐름 감각을 자체적으로 더 많이 내장해 하네스의 도움도 덜 필요함 하네스의 가치가 가장 큰 곳은 단순 프롬프트 입력창이 아닌, 개인의 개발 방식 전체를 반영한 맞춤형 작업 흐름임. 이 경우 폐쇄적이고 경직된 제품보다 직접 만든 것이 나음 작은 모델, 특히 로컬 실행 모델에는 세세하게 이끄는 하네스가 매우 유용하지만, 가장 큰 모델의 사용료를 피하게 해준다는 점에서 최첨단 모델 기업의 사업 목표와는 반대 방향임 답변달기 GeekNews를 계속 받아보려면 Weekly 뉴스레터나 GeekBots를 이용해보세요. [Weekly 구독](/weekly?utm_source=referrer_banner&utm_medium=site&utm_campaign=topic_footer_reminder) · [GeekBots](/geekbots?utm_source=referrer_banner&utm_medium=site&utm_campaign=topic_footer_reminder) · [GeekNews 소개](/start?utm_source=referrer_banner&utm_medium=site&utm_campaign=topic_footer_reminder) [처음 오셨나요](/start) [사이트 이용법](/guidelines) [FAQ](/faq) [About](/about) [후원하기](/support) [이용약관](/terms) [개인정보 처리방침](/privacy)   | [Blog](/blog) [Lists](/lists) [RSS](https://news.hada.io/rss/news)   | [Bookmarklet](/bookmarklet) [X (Twitter)](https://x.com/GeekNewsHada) [Facebook](https://facebook.com/GeekNewsHada)   |   [긱뉴스봇](/geekbots) : [Slack](/slack) [잔디](/jandibot) [Discord](/discordbot) [Teams](/teamsbot) [Dooray!](/dooraybot) [Google Chat](/googlechatbot) [Mattermost](/mattermostbot) [Swit](/switbot) [시작하기](/start) [이용법](/guidelines) [FAQ](/faq) [About](/about) [후원](/support) [약관](/terms) [개인정보](/privacy) [Lists](/lists) [Blog](/blog) [RSS](https://news.hada.io/rss/news) [X](https://x.com/GeekNewsHada) [긱뉴스봇](/geekbots) 검색 언어 선택: 한국어 * 한국어 ✓ * [Indonesia](https://id.news.hada.io/topic?id=32179) * [Tiếng Việt](https://vi.news.hada.io/topic?id=32179) * [Português](https://pt.news.hada.io/topic?id=32179) * [Español](https://es.news.hada.io/topic?id=32179) * [ไทย](https://th.news.hada.io/topic?id=32179) * [日本語](https://ja.news.hada.io/topic?id=32179) * [Türkçe](https://tr.news.hada.io/topic?id=32179) * [Deutsch](https://de.news.hada.io/topic?id=32179) * [Français](https://fr.news.hada.io/topic?id=32179) * [हिन्दी](https://hi.news.hada.io/topic?id=32179) ![]()