환경으로서의 하네스

하네스 설계가 에이전트의 실제 적응 여부를 결정하는 이유

#AI #Agent #Harness #Memory #Adaptation #RAG #Skills #LLM

에이전트 메모리 시스템이 semantic, episodic, procedural로 분화하는 이유를 이전 글에서 다뤘는데, 메모리 레이어를 아무리 정교하게 쌓아도 시스템이 실제로 적응하지 않는 경우가 여전히 많다. 벡터 DB에 경험을 수천 건 채워도 에이전트 동작이 달라지지 않는 건, 기록을 적응으로 전환하는 구조적 장치가 빠져 있기 때문이다. 에이전트가 무엇을 수정할 수 있는지, 변경의 성공 여부를 어떻게 판별하는지, 실패 시 어디까지 되돌리는지를 규정하는 환경이 그 장치인데, 이걸 **하네스(harness)**라 부른다. 하네스는 test runner나 CI pipeline이 아니라, 메모리의 각 층위가 적응의 기반으로 작동하기 위해 그 아래 깔려야 하는 실행 환경이다.

카파시의 autoresearch가 하네스의 최소 형태를 보여준다. prepare.py는 잠그고 train.py만 수정 가능하게 열어두고, 5분 wall-clock budget으로 비용 상한을 강제하며, val_bpb 단일 메트릭으로 변경의 생존 여부를 결정한다. 수정 가능한 범위, 성공 여부를 보는 지표, 실패 시 되돌릴 단위 — 고작 세 가지지만 이것 없이는 모델이 아무리 유능해도 시스템 수준의 적응은 일어나지 않는다. Arize의 RAG 사례에서도 같은 구조가 작동했다. Recall@5 39%에서 출발한 Claude 기반 루프가 8시간 동안 17회 실험을 돌리며 chunking strategy, BM25/RRF 가중치, HyDE, multi-query expansion, reranker를 순서대로 시도해 75%까지 끌어올렸는데, 종료 조건이 "작업 완료"가 아니라 "Recall@5 ≥ 80%"였기 때문에 evaluation function이 견고하고 modification boundary가 명확한 환경에서 루프가 알아서 목표를 향해 달린 것이다. 하네스가 모델을 더 똑똑하게 만든 게 아니라, 변경을 추적 가능하게 하고 실패를 되돌릴 수 있게 판을 깔아준 것뿐이다.

DeepMind의 최근 결과도 같은 구조다. AlphaProof 같은 전용 증명 시스템을 따로 만드는 대신, Gemini에 Lean 컴파일러 피드백만 붙인 단순한 루프가 오래 미해결이던 Erdős 문제 9건과 OEIS 추측 44개를 실제로 풀어냈다. 수정 대상이 Python 코드가 아니라 형식 증명(formal proof)이고 피드백을 주는 건 메트릭이 아니라 컴파일러지만, 하네스의 뼈대는 동일하다 — 모델이 산출물을 만들고, 즉각적이고 정확한 판별이 돌아오고, 루프가 돈다. 전용 시스템을 짜는 대신 범용 모델에 단순한 루프만 걸어 미해결 난제를 풀어낸 건 거의 bitter lesson급이다. 모델이 똑똑해지면서 마이크로매니징 스타일의 정교한 제약은 오히려 도움이 안 된다는 의견이 늘고 있고 실제로 그런 방향의 가이드도 나오고 있는데, 문제는 모델의 행동 특성에 의존하는 하네스는 모델이 바뀔 때마다 같이 흔들린다는 것이다. 반면 피드백의 품질 자체는 모델 버전을 가리지 않는다. Lean 컴파일러가 그렇고, val_bpb가 그렇고, Recall@5가 그렇다. 하네스의 두께는 제약의 두께가 아니라 피드백의 두께다.

장기 실행 에이전트에서 Brain/Hands/Session 분리가 등장한 것도 하네스의 연장선이다. Hands — 실행 환경 — 는 소모품으로 설계하고, Session은 thoughts, tool calls, observations, results를 append-only log로 쌓아 끝까지 살아남게 만드는 구조인데, 컨테이너가 뻗거나 도구 호출이 타임아웃돼도 새 실행 환경이 session log에서 상태를 재구성하므로 에이전트가 궤적을 잃지 않는다. Ralph 루프가 파일시스템 수준에서 이 패턴을 구현한다 — prd.json에 계획, progress.txt에 작업 노트, AGENTS.md에 실행 중 축적된 규칙. 모델 자체는 stateless여도 하네스가 상태를 쥐고 있으니 세션을 넘어서는 적응이 가능해진다.

스킬을 "능력을 설명하는 프롬프트" 정도로 보면 왜 세션을 넘어 재사용 가능한지 설명하기 어려운데, 실제로 일반화하는 스킬은 하네스의 검증을 통과해 살아남은 절차에 가깝다. DSPy에서 프롬프트는 작성하는 게 아니라 evaluation function 아래에서 optimizer가 컴파일하고, MACLA는 2,851개 ALFWorld 궤적을 Bayesian confidence estimation으로 평가해 187개 hierarchical procedure로 압축했으며, SkillOpt는 스킬 문서를 text-space parameter로 놓고 rollout, reflection, held-out validation을 돌렸다. DSPy에서 SkillOpt로의 흐름은 하네스가 자동화하는 범위가 넓어지는 과정이고, 모델 가중치는 한 톨도 건드리지 않으면서 외부 상태에 대한 evaluation-edit-promotion 루프만으로 시스템이 개선된다. AGENTS.md든 Claude Code 스킬이든 SkillOpt의 best_skill.md든, 검증을 사람이 했느냐 하네스가 했느냐의 차이일 뿐 같은 계열이다. 스킬과 하네스가 개념상 구분되면서도 구현에서 겹치는 양상은 스킬과 하네스에서 따로 다뤘다.

Omni-SimpleMem은 이 논리를 메모리 아키텍처 설계 자체에 적용한 사례다. AutoResearchClaw 파이프라인이 약 50회 실험만으로 메모리 벤치마크 성능을 몇 배씩 끌어올렸는데, 하이퍼파라미터를 튜닝한 게 아니라 데이터 파이프라인 구조와 아키텍처 자체를 바꿔서 나온 결과다. 고정된 파이프라인 안에서 정답을 찾은 게 아니라 파이프라인 설계 자체를 발견한 것이고, 조건은 동일했다 — 즉각적인 scalar metric, 모듈식 구조, 빠른 실험 사이클, 버전 관리. 다만 하네스가 있다고 해서 무조건 좋은 적응이 일어나는 건 아니다. 평가 함수가 보상하는 방향으로만 수렴하기 때문에, 무엇을 점수로 삼느냐가 좁으면 그 좁은 점수에 맞춰 똑똑하게 망가진다. 평가셋을 어떻게 깎느냐, 되돌릴 수 있는 범위를 어디까지 잡느냐 — 이 환경의 두께가 적응이 약이 될지 독이 될지를 가른다.

기능을 코드로 구현하고, 그 코드를 정밀 세공해서 shipping하는 모델은 끝이다. 코드나 프롬프트 자체는 덜 중요해진다. 더 중요한 건 환경과 데이터, 평가기준이다. 공급자가 자기 개발환경에서 소프트웨어를 완성해 고객에게 넘기는 그림 대신, 고객 환경을 에이전트가 적응할 수 있는 곳으로 세팅해두고 맞춤형 소프트웨어(스킬≈하네스)가 바로 그 자리에서 만들어져 감사를 거쳐 배포되게 하는 그림이다. 가볍고 얇은 에이전트라도 고객 환경에서 자동으로 최적화될 수 있다면 성능과 비용을 모두 월등히 만족시킨다. Claude Code가 lovable한 이유도, 에이전트 런타임을 서버에서 로컬로 내리면서 바로 이런 적응성을 발휘하기 좋은 환경(권한 포함)을 만들어낼 수 있었기 때문이다.

가령 기존에 RAG를 솔루션으로 제공하면, 엄청 좋은 엔진을 만들어서 SaaS로 공개하거나 SI로 고객 상황에 맞춘 엔진을 개발했을 것이다. 그런데 이제는 범용적이고 잘 적응하는 씨앗을 만들어서, 고객 환경에서 잘 키울 수 있게만 하면, 그리고 그렇게 할 수 있는 가이드만 잘 잡아주면 훨씬 기간도 단축하고 성능도 좋은 제품을 전달할 수 있게 되는 것이다. 기존에도 AutoML, AutoRAG 같은 게 있었지만 탐색 과정이 번거롭고 적응 가능한 상태가 되기 위해 굉장히 뚱뚱해졌다. 그런데 이제는 슬림하면서도 쉽게 적응 가능하면서, 탐색 공간 자체를 탐색할 수 있게 된 것이다.

이제 중요한 건 "모델이 얼마나 유능한가"가 아니라 "환경이 얼마나 하네스 준비가 되어 있는가"다. observable state — 로그, 메트릭, evaluation set, diff history — 가 갖춰져 있는지, 비교 가능한 지표로 실험 간 개선을 일관되게 판별할 수 있는지, rollback unit이 충분히 작아 실패 비용이 낮은지, 반복된 성공이 스킬로 승격되고 폐기된 절차가 정리되는 promotion policy가 있는지. 이게 없으면 시스템은 시간이 지나도 학습이 아니라 잡음만 쌓인다.

게다가 이건 한 번 세팅하고 끝나는 게 아니다. 배포 뒤에도 지속적인 성능평가와 드리프트 감지가 돌아야 하고, 롤백과 버전관리, 권한관리, 보안, 가시성이 모두 받쳐줘야 한다. 역설적이게도 바로 여기서 코드가 다시 중요해진다. 기능을 구현하는 코드는 덜 중요해져도, 이 모든 틀의 견고함을 방어하는 코드는 매우 중요하다. 인프라 쪽에서도 에이전트가 안전하게 작업할 도구와 작업공간, 실행을 누적하는 메모리(시맨틱·작업·에피소드·절차)의 무게가 커진다. 잘 짜인 하네스 안의 얇은 에이전트가 하네스 없는 유능한 에이전트를 성능과 비용 모두에서 앞선다. 결국 해자는 모델의 유능함이 아니라, 그 모델이 현장에서 계속 적응할 수 있게 만드는 환경의 두께에 있다.

참고

Karpathy, Andrej. "autoresearch." GitHub, 2026.

"How Arize Skills Improved RAG Recall from 39% to 75% in 8 Hours." Arize Blog, 2026.

Addy Osmani. "Building Reliable Long-Running AI Agents." Addyo Substack, 2026.

Khattab, Omar, et al. 2023. "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines." arXiv 2310.03714.

"MACLA: Multi-Agent Collaboration via Layered Abstraction." arXiv 2512.18950.

"SkillOpt: Optimizing Natural Language Skill Descriptions for AI Agents." arXiv 2605.23904.

"Omni-SimpleMem: Autonomous Discovery of Multimodal Lifetime Memory Systems." arXiv 2604.01007.

DeepMind. "Advancing Mathematics Research with AI-Driven Formal Proof Search." arXiv 2605.22763, 2026.