프롬프트 다음, 컨텍스트 다음은 '하네스'다 — Agent Harness Engineering 서베이 정리

에이전트를 만들다 보면 같은 모델을 쓰는데도 팀마다 결과가 크게 갈린다. 이유는 대개 모델 내부보다 바깥쪽에 있다. 실행 환경, 도구 계약, 컨텍스트 관리, 검증, 관측, 권한 통제가 어떻게 짜였는지가 결과를 좌우한다.

Agent Harness Engineering: A Survey는 바로 이 지점을 정면으로 다룬다. 이 글은 2026년 5월 16일 공개된 서베이와 공식 프로젝트 페이지를 바탕으로, 왜 지금 “하네스(harness)“가 에이전트 개발의 핵심 레이어가 되었는지 정리한 것이다.

딥다이브: 왜 지금 하네스 엔지니어링인가

지난 몇 년 동안 에이전트 개발의 초점은 조금씩 위로 올라왔다.

핵심은 단순하다. 이제는 “어떤 모델을 쓸까”보다 모델 주변에 어떤 시스템을 둘까가 더 큰 변수가 되었다.

이 흐름을 뒷받침하는 사례도 있다. LangChain은 모델을 고정한 채 하네스만 바꿔 Terminal Bench 2.0 점수를 크게 끌어올렸다. 즉, 실전 성능은 모델 파라미터만으로 설명되지 않는다. 환경 설계가 성능의 상당 부분을 결정한다.

ETCLOVG — 하네스를 7계층으로 분해하기

서베이의 중심 개념은 ETCLOVG다. 이름은 낯설지만, 실무적으로는 꽤 정확한 분해다.

여기서 중요한 점은 O와 G를 독립 계층으로 승격했다는 것이다. 많은 프레임워크는 관측과 거버넌스를 보조 기능처럼 다루지만, 실제 운영에서는 이 둘이 나중에 붙을수록 비용이 크게 튄다.

분포가 말해주는 것

서베이는 170개 이상의 오픈소스 프로젝트를 ETCLOVG에 매핑한다. 결과를 보면 어디가 성숙했고 어디가 비어 있는지 바로 드러난다.

• L, V, E는 상대적으로 프로젝트 수가 많다.
• C는 중요하지만 프레임워크 안에 흡수되어 보이지 않는 경우가 많다.
• O, G는 가장 얇다. 즉, 운영과 통제 영역은 아직 빈 자리가 많다.

이건 꽤 실용적인 진단이다. 오픈소스 생태계는 대체로 “돌리기”와 “검증하기”부터 잘한다. 하지만 “안전하게 운영하기”와 “책임 있게 통제하기”는 늦게 성숙한다.

하네스의 짧은 역사

하네스의 역사는 생각보다 짧지만, 변화 속도는 빠르다.

2022–2023: ReAct era

초기의 하네스는 단순했다. while 루프와 프롬프트 템플릿, 작은 tool dispatch table이면 충분해 보였다. ReAct가 그 원형에 가깝다.

하지만 AutoGPT, BabyAGI 같은 시도가 나오면서 실패 양상도 분명해졌다.

• 실행 폭주
• 컨텍스트 폭발
• 상태 손실
• 부작용 미관측

이 시점부터 문제는 프롬프트가 아니라 인프라라는 점이 분명해졌다.

2023–2024: 도구와 멀티에이전트

이 시기에는 세 흐름이 동시에 커졌다.

• 학습된 도구 사용: Gorilla, ToolLLM, Toolformer
• 역할 기반 조직: CAMEL, ChatDev, MetaGPT, Mixture-of-Agents
• 벤치마크 확대: SWE-bench, AgentBench, WebArena, GAIA

여기서 “에이전트 = LLM + 도구”라는 패러다임이 굳어졌다.

2025–2026: Harness engineering으로 명명됨

모델이 몇 시간 단위의 자율 작업까지 시도할 수 있게 되면서 병목이 바깥으로 옮겨갔다. 그 결과, 하네스는 더 이상 부속품이 아니라 시스템의 본체가 되었다.

특히 LangChain의 하네스 실험처럼, 같은 모델에서도 실행 환경과 제어 루프만 바꿔 점수가 크게 오르는 사례가 나오면서 이 흐름은 더 분명해졌다.

한 레이어로는 풀리지 않는 세 가지 제약

서베이에서 실무적으로 가장 가치 있는 부분은, 여러 레이어가 결합될 때 생기는 제약을 따로 떼어 본다는 점이다.

1) 비용-품질-속도 삼중고

더 강한 샌드박스, 더 풍부한 컨텍스트, 더 촘촘한 검증은 품질을 올린다. 하지만 동시에 비용과 지연시간도 올린다.

그래서 프로덕션 하네스는 “어떤 위험은 런타임에서 막고, 어떤 위험은 비동기 검증으로 넘길지”를 명시적으로 정해야 한다.

2) 능력과 통제는 같은 축이다

도구를 넓히고 기억을 늘리고 권한을 풀수록 작업 범위는 커진다. 동시에 오작동의 blast radius도 커진다.

즉, tool schema, permission, audit, human approval은 서로 따로 놓을 수 없다. 능력 확대와 통제 강화는 같은 설계 축 위에 있다.

3) 하네스 결합 문제

가장 중요한 메시지는 이거다.

하네스 변경은 시스템 변경(system change)으로 테스트하라.

프롬프트, 도구, 샌드박스, 검증기, 모니터를 각각 따로 보면 좋아 보이는 변경도, 전체 제어 루프와 결합되면 롤아웃을 망칠 수 있다. 부분 최적화는 생각보다 자주 깨진다.

아직 열려 있는 5가지 문제

서베이는 마지막에 앞으로 풀어야 할 문제도 정리한다. 이 부분은 사실상 다음 1~2년의 R&D 로드맵에 가깝다.

1. 실행 환경의 hardening과 scale-out

   • prompt injection, goal misalignment, compositional amplification에 대한 보안 평가
   • container, microVM, 브라우저, desktop VM, learned surrogate 간 비용 비교
   • self-hosted / cloud / hybrid 간 의미 보존 portability

2. 장기 실행 에이전트의 상태 신뢰성

   • 컨텍스트 관리를 state estimation 문제로 보기
   • 압축, 검색, 망각의 정보 손실 특성화
   • provenance와 staleness marker의 명시화

3. Trace-native failure diagnosis

   • 트레이스를 사후 디버깅이 아니라 1급 객체로 다루기
   • outcome score, trajectory quality, failure attribution, regression test를 같은 축에서 보기

4. 에이전트·도구·사람 사이의 표준 handoff

   • 단순 요약이 아니라 intent, constraints, permissions, artifacts, provenance, budget, risk, unresolved decisions까지 넘기기

5. 모델 개선에 따른 적응적 단순화

   • 모델이 좋아질수록 일부 래퍼는 핵심이 되지만, 일부는 그냥 비용이 된다
   • 하네스도 결국 스스로를 줄이거나 다시 조합할 수 있어야 한다

이 다섯 가지는 공통적으로 같은 질문으로 모인다. 어떤 개입이 정말 필요한가?

이 서베이를 읽고 얻는 실무적 교훈

여기서 바로 적용할 수 있는 결론은 몇 가지다.

1. “모델만 바꾸자”는 대개 첫 번째 가설로 틀리다.
2. 하네스를 7계층으로 나눠 점검하라. 특히 O와 G는 프로토타입에서 잘 안 보이지만 운영에서 결정적이다.
3. 하네스 변경은 시스템 테스트로 검증하라. 단일 미들웨어 A/B만으로는 결합 문제를 놓치기 쉽다.
4. 카탈로그를 한 번 훑어라. 공식 프로젝트 페이지의 레퍼런스와 공개 카탈로그만 봐도 빈칸이 보인다.

공식 프로젝트 페이지는 이 서베이를 중심으로 PDF, GitHub 저장소, 오픈 카탈로그, 데이터셋까지 묶어 둔다. 즉, 논문 한 편이 아니라 생태계 전체의 지도를 제공한다는 점이 중요하다.

마치며

Agent Harness Engineering: A Survey는 에이전트가 더 똑똑해지는 방향보다, 에이전트를 둘러싼 환경이 더 잘 설계되는 방향이 중요하다고 말한다.

이 판단은 꽤 냉정하지만 현실적이다. 모델은 빠르게 좋아지지만, 실제 업무에서 신뢰성을 만드는 일은 여전히 실행 환경, 관측, 검증, 거버넌스의 몫이다. 결국 차이는 모델이 아니라 환경이다.

그리고 지금은 그 환경을 어떻게 만들지에 대한 공통 언어가 막 생기기 시작한 시점이다. ETCLOVG는 그 시작점을 설명하는 꽤 좋은 지도다.

참고 자료

• Project page — Agent Harness Engineering: A Survey
• OpenReview — eONq7FdiHa
• GitHub — Picrew/LLM-Harness
• GitHub — Picrew/awesome-agent-harness
• Hugging Face dataset — Agent-Harness-Engineering
• LangChain — Improving Deep Agents with Harness Engineering