AI 에이전트가 특정 작업에서 반복적으로 실패할 때, 기본적으로 취하는 반응은 더 나은 모델을 사용하거나 현재 모델을 파인튜닝(Fine-Tuning)하는 것입니다.

그것은 잘못된 첫 번째 선택일 수 있습니다.

모델은 에이전트의 일부일 뿐입니다. 에이전트의 하네스(Harness)는 모델이 받는 컨텍스트(Context), 사용할 수 있는 도구(Tools), 조사할 수 있는 환경(Environment), 받는 피드백(Feedback), 그리고 한 번의 실패가 지속적인 개선으로 이어질지 여부를 제어합니다.

저는 이러한 개선 프로세스를 구조화되고 검증 가능하게 만들기 위해 Harneloop을 구축했습니다.

루프 (The loop)

Harneloop은 운영 중인 에이전트에게 다음과 같은 작업을 요청합니다:

1. 실제 작업을 시도합니다.
2. 결과물인 아티팩트(Artifacts), 상태(State), 로그(Logs), 트레이스(Traces)를 조사합니다.
3. 기록된 실행 과정을 통해 발생 가능한 실패의 원인을 추적합니다.
4. 하네스에 대한 격리된 후보 변경 사항(Candidate change)을 생성합니다.
5. 후보 사항과 관련 회귀 테스트(Regressions)를 재테스트합니다.
6. 개선을 뒷받침하는 증거가 있을 때만 변경 사항을 반영합니다.

후보 사항은 시스템 프롬프트(System prompt) 이상의 것을 변경할 수 있습니다. 도구(Tools), 검색(Retrieval), 예시(Examples), 검증기(Validators), 환경 자동화(Environment automation), 기술(Skills) 또는 기타 작업별 인프라를 추가할 수 있습니다.

후보가 테스트되는 동안 작동 중인 하네스는 변경되지 않은 상태로 유지됩니다. 실패한 실험이 조용히 프로덕션 상태(Production state)로 전환되지 않습니다.

아티팩트(Artifacts)가 중요한 이유

명령은 성공할 수 있지만 결과는 틀릴 수 있습니다.

인터페이스는 컴파일될 수 있지만 시각적으로 실패할 수 있습니다. 장면(Scene)은 렌더링될 수 있지만 요청된 공간 관계를 위반할 수 있습니다. 문서는 유효할 수 있지만 잘못된 내용을 전달할 수 있습니다. 브라우저 워크플로우(Browser workflow)는 잘못된 상태로 종료될 수 있습니다.

이러한 작업에서 아티팩트(Artifact)는 증거의 일부입니다.

Harneloop은 아티팩트와 관찰 사항(Observations)을 그것들을 생성한 정확한 실행(Run)에 연결합니다. 이를 통해 에이전트는 "이것은 잘못된 것 같다"라는 단계에서 하네스의 무엇을 변경해야 하는지에 대한 트레이스 기반의 가설(Trace-backed hypothesis) 단계로 나아갈 수 있습니다.

휴대 가능한 하네스 유닛 (Portable harness units)

각 작업별 개발 환경은 **하네스 유닛(Harness unit)**으로 저장됩니다.

하네스 유닛 (Harness unit)은 타겟 정의(target definition), 운영 맵(operational map), 재사용 가능한 하네스 재료(reusable harness material), 후보군(candidates), 증거 참조(evidence references), 회귀 케이스(regression cases), 그리고 승격된 버전(promoted versions)을 포함합니다. 에이전트(agent)는 필요에 따라 커스텀 스크립트, 연구, 검색 데이터(retrieval data), 인프라 또는 완전히 새로운 디렉토리를 추가할 수 있습니다.

Harneloop은 에이전트를 경직된 템플릿에 가두는 대신 라이프사이클(lifecycle)을 보호합니다.

성공적인 유닛은 일시 중지, 복구, 이동, 패키징하거나 다른 에이전트 또는 애플리케이션으로 내보낼 수 있습니다.

왜 하네스 우선(harness-first)인가?

연구에 따르면 추론 시간 시스템(inference-time systems)이 모델 가중치(model weights)를 변경하지 않고도 에이전트의 성능을 변화시킬 수 있음이 반복적으로 증명되었습니다.

SWE-agent는 목적에 맞게 구축된 에이전트-컴퓨터 인터페이스(agent-computer interface)의 영향력을 입증했습니다. Reflexion과 Self-Refine은 추가 학습 없이도 피드백과 반복적인 정제(iterative refinement)를 통해 성능 향상을 보여주었습니다. 2026년 Self-Harness 논문은 에이전트가 트레이스(traces)에서 약점을 찾아내고, 하네스 변경을 제안하며, 회귀 테스트(regression tests)로 이를 검증하는 과정을 직접적으로 보여주었습니다.

이것이 하네스가 항상 파인튜닝(fine-tuning)보다 낫다는 의미는 아닙니다. 파인튜닝은 추론 시간(inference time)에 효과적으로 제공될 수 없는 행동, 스타일, 지연 시간(latency) 또는 능력(capabilities)을 위해 여전히 유용할 수 있습니다.

실질적인 규칙은 더 좁습니다:

병목 현상(bottleneck)이 컨텍스트(context), 도구(tools), 검색(retrieval), 피드백(feedback), 검증(validation), 메모리(memory) 또는 환경 상호작용(environment interaction)인 경우, 가중치를 변경하기 전에 하네스를 먼저 테스트하십시오.

초기 증거

Harneloop은 공간 추론 및 장면 생성을 위한 Blender 하네스인 ViperMesh를 개발하는 데 처음 사용되었습니다.

벤치마크에서는 실행 모델을 OpenAI GPT 5.5 High로 고정하고, ViperMesh를 Anthropic x Blender MCP 서버 베이스라인과 비교했습니다.

7개의 유사한 라이브 작업 전반에 걸쳐 ViperMesh는 다음과 같은 결과를 보였습니다:

• 7개 중 6개 작업에서 더 빨랐습니다.
• 평균 2.534배의 속도 향상을 달성했습니다.
• 예비 중립 LLM 시각적 평가(neutral LLM visual evaluation)를 8.19포인트 개선했습니다.

Harneloop은 장면(scenes)을 생성하지 않았습니다. 대신 실패를 조사하고, 하네스(harness)를 개선하며, 증거를 보존하고, 변경 사항이 도움이 되었는지 검증하는 데 사용되는 프로세스를 구조화했습니다.

ViperMesh 사례 연구 전문에는 방법론과 한계점이 포함되어 있습니다. 이는 하나의 작업군(task family)에서 얻은 증거이며, 하네스 대 파인튜닝(fine-tuning)을 비교하는 보편적인 벤치마크는 아닙니다.

실제 작업에서 시도해 보세요

Harneloop은 에이전트 주도 설정(agent-led setup)에 최적화되어 있습니다. 저장소(repository)를 유능한 코딩 에이전트에게 전달하고 하네스가 개선하기를 원하는 내용을 설명하세요. 에이전트는 프레임워크를 설치하고, 환경을 매핑하며, 첫 번째 하네스 유닛을 생성하고, 필요한 경우 누락된 정보를 요청할 수 있습니다.

저는 실패한 사례를 포함하여 독립적인 사용 사례(use cases)를 찾고 있습니다. 가장 유용한 피드백은 온보딩(onboarding), 환경 매핑(environment mapping), 증거 품질(evidence quality), 런타임 비용(runtime cost), 후보 결정(candidate decisions), 그리고 하네스가 한계에 도달하는 작업에 관한 것입니다.

Repository: https://github.com/Ker102/Harneloop

Case study: https://www.kristoferjussmann.me/case-studies/vipermesh