하네스 엔지니어링
2026년 하네스 엔지니어링 논의 정리
2026년 들어 OpenAI, LangChain, Anthropic은 에이전트 관련 글에서 공통적으로 harness를 전면에 두고 있다. 표현은 조금씩 다르지만, 프롬프트만으로 설명하기 어려운 실행 구조, 평가 구조, 정리 루프를 함께 다룬다는 점은 비슷하다.
이 글은 각 회사가 하네스를 어떻게 설명하는지, 그 설명을 어떤 층위로 읽을 수 있는지 정리한 메모다.
하네스를 어떻게 정의하는가
LangChain은 2026년 3월 10일 글에서 하네스를 "모델이 아닌 모든 코드, 설정, 실행 로직"으로 정의했다. 이 정의를 따르면 하네스에는 시스템 프롬프트만이 아니라 도구 설명, 샌드박스, 브라우저, 파일시스템, 상태 저장, 오케스트레이션, 컨텍스트 관리, 재시도 로직, 린트, 후처리까지 함께 들어간다.
이 정의는 프롬프트를 하네스 안에 포함시키면서도, 동시에 프롬프트 바깥의 실행 구조를 같이 보게 만든다. 최근 논의에서 하네스가 반복해서 등장하는 이유도 이 범위 설정과 연결된다.
하네스를 몇 가지 층으로 나눠서 볼 수 있다
자료를 읽을 때는 몇 층으로 나눠 보는 편이 더 선명하다.
1. Agent harness
모델이 실제로 일을 하도록 만드는 실행 층이다. 프롬프트, 툴, 샌드박스, 상태 저장, 오케스트레이션, 컨텍스트 관리가 여기에 들어간다.
2. Eval harness
에이전트가 여전히 원하는 행동을 하는지 확인하는 평가 층이다. capability eval, regression eval, holdout, grader, 집계 로직이 여기에 속한다.
3. Repo GC harness
리포지토리에 쌓이는 엔트로피를 수거하는 정리 층이다. 규칙 위반 스캔, 품질 등급 갱신, 작은 cleanup PR, 중복 패턴 제거, 죽은 코드 탐지, 위생 점검 루프를 이 범주로 묶어볼 수 있다.
4. Meta-harness
모델이 바뀌어도 버틸 수 있도록 세션, 샌드박스, 툴 인터페이스를 안정적으로 잡는 층이다. 특정 구현보다 추상화와 교체 가능성을 먼저 보는 관점이라고 할 수 있다.
이렇게 나누면 각 회사가 어디에 더 무게를 두는지도 비교하기 쉬워진다.
OpenAI는 엔트로피와 정리 루프를 전면에 둔다
OpenAI의 2026년 2월 11일 글은 Entropy and garbage collection을 별도 섹션으로 둔다. 여기서는 Codex가 만든 코드베이스에 시간이 지나며 엔트로피가 쌓이고, 이를 사람이 주기적으로 청소하는 방식은 스케일하지 않는다고 설명한다.
그래서 규칙 위반을 스캔하고 품질 등급을 갱신하며 작은 정리 PR을 계속 올리는 배경 작업을 둔다. OpenAI는 하네스를 단순한 실행 장치보다, 코드베이스 위생을 유지하는 운영 루프까지 포함한 개념으로 다룬다고 읽힌다.
특히 이 부분은 repo GC harness라는 층을 따로 떼어 보는 데 좋은 근거가 된다.
LangChain은 하네스의 경계를 가장 넓게 정의한다
LangChain의 2026년 3월 10일 글은 하네스를 "모델이 아닌 모든 것"으로 정리한다. 덕분에 프롬프트, 툴, 실행 로직, 설정, 상태 관리까지 하나의 범주 안에서 볼 수 있다.
이어 2026년 4월 8일 글에서는 eval을 이용해 하네스를 계속 hill-climb하는 루프를 설명한다. 운영 중 수집한 예시를 eval로 만들고, optimization/holdout으로 나눠 하네스를 개선하는 방식이다.
이 두 글을 함께 보면 LangChain은 하네스를 넓게 정의한 뒤, 이를 평가를 통해 계속 조정하는 대상으로 본다고 정리할 수 있다. 즉 agent harness와 eval harness를 같이 설계하고 갱신하는 관점이 강하다.
Anthropic은 하네스를 층으로 분리해서 본다
Anthropic의 2026년 1월 9일 글은 evaluation harness와 agent harness를 명시적으로 구분한다. capability eval과 regression eval을 함께 돌려 드리프트를 막아야 한다는 점도 이 글에서 분명하게 나온다.
이후 2026년 3월 24일 글과 2026년 4월 초 Managed Agents 글에서는 하네스가 담고 있는 가정이 모델 향상에 따라 금방 stale해질 수 있다고 설명한다. 모델이 더 좋아지면 예전에 필요했던 보조 구조가 오히려 불필요한 오버헤드가 될 수 있다는 의미다.
그래서 Anthropic 글들은 특정 구현을 세밀하게 고정하기보다, 세션, 하네스, 샌드박스 같은 인터페이스를 안정적으로 잡는 편이 낫다는 쪽으로 읽힌다. 이 부분은 meta-harness라는 층으로 요약할 수 있다.
프롬프트 엔지니어링과는 어디가 다른가
이 자료들을 같이 읽으면, 최근의 하네스 논의가 프롬프트 엔지니어링과는 다른 층을 다룬다는 점이 보인다.
프롬프트 엔지니어링은 주로 턴 단위 응답 품질을 높이는 문제에 가깝다. 반면 하네스 엔지니어링은 상태를 어떻게 남길지, 평가를 어떻게 돌릴지, 리포지토리 엔트로피를 어떻게 수거할지, 모델이 바뀌었을 때 무엇을 유지하고 무엇을 버릴지 같은 문제를 포함한다.
특히 아래 세 지점은 프롬프트만으로 설명하기 어렵다.
- eval harness: 지금 좋아진 것이 실제 개선인지, 다른 부분을 망가뜨린 대가인지를 평가해야 한다.
- repo GC harness: 나쁜 패턴, 중복 유틸, 위생 붕괴는 실행 후에 계속 누적된다.
- stale assumption: 이전 모델 기준의 실행 구조가 새 모델에서는 불필요해질 수 있다.
그래서 최근 글들에서는 프롬프트를 잘 쓰는 문제보다, 프롬프트를 포함한 전체 실행 구조를 어떻게 설계하고 유지할지가 더 자주 전면에 나온다.
정리
세 회사의 표현은 다르지만, 최근 하네스 논의는 대체로 네 가지 층으로 읽을 수 있다.
- agent harness: 모델이 실제로 일하도록 만드는 실행 구조
- eval harness: 그 행동을 계속 평가하는 구조
- repo GC harness: 리포지토리 엔트로피를 수거하는 정리 구조
- meta-harness: 모델 변화에도 버티도록 인터페이스를 잡는 구조
이 정리는 "하네스"라는 말이 최근 왜 자주 등장하는지 이해할 때 기준점이 된다. 이후에는 이 층위를 실제 프로젝트에 어떻게 적용할지 따로 이어서 볼 수 있다.
참고
- OpenAI, Harness engineering: leveraging Codex in an agent-first world
https://openai.com/index/harness-engineering/ - LangChain, The Anatomy of an Agent Harness
https://blog.langchain.com/the-anatomy-of-an-agent-harness/ - LangChain, Better Harness: A Recipe for Harness Hill-Climbing with Evals
https://blog.langchain.com/better-harness-a-recipe-for-harness-hill-climbing-with-evals/ - Anthropic, Demystifying evals for AI agents
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents - Anthropic, Harness design for long-running application development
https://www.anthropic.com/engineering/harness-design-long-running-apps - Anthropic, Scaling Managed Agents: Decoupling the brain from the hands
https://www.anthropic.com/engineering/managed-agents
'AI코딩' 카테고리의 다른 글
| Matt Pocock 신규 스킬 4종 (0) | 2026.05.12 |
|---|---|
| 결국 기초가 중요하다 - Matt Pocock 강의 (0) | 2026.05.06 |
| 2026 에이전틱 코딩 트랜드 리포트 by Anthropic (0) | 2026.03.04 |
| 스펙 주도 개발 (Spec Driven Development, SDD) (1) | 2026.03.02 |