에이전트 하네스 엔지니어링: 2025년은 에이전트, 2026년은 하네스의 해

핵심 요약

• 같은 모델을 사용해도 하네스 설계에 따라 작업 완료율이 40%p 차이가 난다.
• 하네스는 시스템 프롬프트, 도구 정의, 샌드박스, 피드백 루프, 메모리 관리 등 모델 외의 모든 것이다.
• Anthropic은 **"더 똑똑한 모델이 더 나은 결과를 의미하지 않는다"**고 공식 발표했다.
• 하네스 설계의 3원칙: 최소 개입, 단계적 권한 공개, 빠른 실패와 복구.
• 2026년 하반기, 하네스 엔지니어링은 독립적인 엔지니어링 분야로 정착할 전망이다.

하네스란 무엇인가

AI 에이전트의 맥락에서 하네스(Harness)란 에이전트를 안전하고 안정적으로 운용하기 위한 설계 구조 전체를 말한다. 원래 "마구(馬具)"라는 뜻으로, 말의 힘을 제어하고 방향을 잡아주는 도구에서 유래했다. AI에서는 모델의 능력을 제어하고, 올바른 방향으로 인도하는 시스템이다.

구체적으로 하네스에 포함되는 요소는 다음과 같다:

• 시스템 프롬프트: 에이전트의 역할, 제약 조건, 행동 규칙 정의
• 도구 정의: 에이전트가 사용할 수 있는 함수와 API의 범위
• 샌드박스 환경: 에이전트의 실행을 격리하는 보안 경계
• 오케스트레이션 로직: 작업 분배, 순서 제어, 분기 처리
• 피드백 루프: 실행 결과를 검증하고 재시도하는 메커니즘
• 메모리 관리: 컨텍스트 윈도우를 넘어서는 장기 기억 체계
• 미들웨어 훅: 실행 전후에 개입하는 검증/변환 로직

한마디로, 모델이 아닌 모든 것이 하네스다.

왜 지금 하네스인가

모델 격차는 줄고, 하네스 격차는 벌어진다

2025년은 에이전트의 해였다. OpenAI의 Codex, Anthropic의 Claude Code, Google의 Jules, 그리고 OpenClaw까지 — 수많은 AI 에이전트가 등장했다. 그러나 2026년에 접어들면서 업계의 관심은 "어떤 모델을 쓰느냐"에서 **"어떻게 운용하느냐"**로 급격히 이동하고 있다.

그 이유는 명확하다. 같은 Claude 또는 GPT 모델을 사용하는 두 엔지니어링 팀이 작업 완료율에서 40%p 차이를 보이는 현상이 반복적으로 관찰되었기 때문이다. 차이를 만든 것은 모델이 아니라 하네스였다.

구분	모델 중심 접근	하네스 중심 접근
핵심 질문	"어떤 모델이 가장 똑똑한가?"	"어떻게 하면 안정적으로 작동하게 할까?"
최적화 대상	모델 파라미터, 프롬프트	환경 설계, 검증 루프, 권한 체계
실패 시 대응	모델 교체 또는 프롬프트 수정	하네스 구조 개선, 가드레일 추가
확장성	모델 비용에 비례	하네스 재사용으로 효율 증가

Anthropic의 공식 입장

Anthropic은 2026년 공식 엔지니어링 블로그에서 이렇게 밝혔다:

"더 똑똑한 모델이 더 나은 코드를 의미하지는 않으며, 하네스가 결과를 결정한다."

이것은 AI 업계 최전선에 있는 기업이 모델보다 하네스가 중요하다고 공식적으로 인정한 것이다.

하네스 설계의 세 가지 방식

현재 업계에서 사용되는 하네스 설계 방식은 크게 세 가지로 나뉜다.

1. 마크다운 프롬프트 방식

오케스트레이션 지침을 시스템 프롬프트나 마크다운 파일에 임베딩하는 방식이다.

대표 사례: Anthropic의 CLAUDE.md, OpenAI Codex의 AGENTS.md

# CLAUDE.md 예시
## 코딩 규칙
- TypeScript strict 모드 필수
- 테스트 없이 커밋하지 않는다
- PR 크기는 300줄 이하로 유지한다

## 작업 흐름
1. 이슈를 분석하고 계획을 세운다
2. 브랜치를 생성한다
3. 구현하고 테스트한다
4. PR을 생성한다

장점: 설정이 간단하고, 코드베이스와 함께 버전 관리 가능 한계: 복잡한 조건 분기나 동적 제어가 어렵다

2. 코드 기반 방식

LangGraph, CrewAI 등의 프레임워크를 활용하여 오케스트레이션 로직을 코드로 구현하는 방식이다.

장점: 복잡한 워크플로우, 조건 분기, 상태 관리가 가능 한계: 학습 곡선이 높고, 프레임워크 종속성이 생긴다

3. 하이브리드 방식

결정론적 검증(린터, 타입 체크)과 LLM 기반 에이전트 리뷰를 혼합하는 방식이다.

장점: 기계적 검증과 맥락 이해를 모두 활용 활용 예: CI/CD에서 린터로 기본 규칙을 검증하고, 에이전트가 아키텍처 일관성을 리뷰

Anthropic의 장기 실행 에이전트 하네스

Anthropic은 엔지니어링 블로그에서 **장기 실행 에이전트(long-running agent)**를 위한 하네스 설계를 상세히 공개했다. 이 접근법의 핵심 통찰은 매우 현실적이다.

핵심 문제: 컨텍스트 윈도우의 단절

AI 에이전트가 수 시간에서 수 일에 걸친 복잡한 작업을 수행할 때, 가장 큰 문제는 컨텍스트 윈도우 간의 단절이다. 각 새로운 세션은 이전 작업에 대한 기억 없이 시작된다. 복잡한 프로젝트는 단일 컨텍스트 윈도우 내에서 완료할 수 없기 때문에, 세션 간의 간극을 메우는 방법이 필요하다.

해결책: 진행 상황 파일 + Git 히스토리

Anthropic의 해법은 인간 엔지니어에서 영감을 받았다. 새로운 개발자가 프로젝트에 투입될 때 가장 먼저 하는 것은 문서를 읽고, Git 히스토리를 확인하는 것이다. 에이전트도 마찬가지다.

claude-progress.txt 파일과 Git 히스토리를 결합하여, 새로운 컨텍스트 윈도우가 시작될 때 에이전트가 현재 작업 상태를 빠르게 파악할 수 있게 한다.

멀티 컨텍스트 윈도우 워크플로우

Anthropic은 첫 번째 컨텍스트 윈도우에는 다른 프롬프트를 사용하는 것을 권장한다. 첫 세션에서는 프로젝트 이해와 계획 수립에 집중하고, 후속 세션에서는 실행에 집중하는 구조다.

[1차 컨텍스트 윈도우]
→ 프로젝트 분석, 계획 수립, progress.txt 생성

[2차+ 컨텍스트 윈도우]
→ progress.txt 읽기 → Git diff 확인 → 이어서 실행

OpenAI Codex의 하네스 접근법

OpenAI의 Codex 팀은 다른 각도에서 하네스를 설계했다.

AGENTS.md: 기계가 읽을 수 있는 지침

프로젝트 루트에 AGENTS.md 파일을 배치하여 에이전트가 코드베이스의 규칙과 구조를 이해할 수 있게 한다. 이 파일은 인간 개발자의 온보딩 문서이자, 에이전트의 행동 가이드라인이다.

재현 가능한 개발 환경

"하나의 명령으로 부팅되는 개발 환경"을 핵심 원칙으로 삼았다. 에이전트가 환경 설정에 시간을 낭비하지 않도록, 모든 의존성과 설정이 사전에 준비되어야 한다.

CI의 기계적 불변식(Invariant)

아키텍처 경계를 CI에서 강제한다. 에이전트가 생성한 코드가 아키텍처 규칙을 위반하면, 자동으로 거부되고 피드백이 제공된다. 이는 에이전트의 자율성을 유지하면서도 품질을 보장하는 핵심 메커니즘이다.

하네스의 6가지 핵심 구성 요소

하네스 엔지니어링의 6가지 핵심 구성 요소는, 에이전트가 "인상적인 데모"가 아닌 **"신뢰할 수 있는 프로덕션 시스템"**이 되는지를 결정한다.

1. 컨텍스트 엔지니어링

에이전트에게 제공하는 정보의 품질과 구조를 설계한다. 너무 많은 정보는 혼란을, 너무 적은 정보는 환각을 유발한다. Enterprise RAG 시스템은 이 문제에 대한 직접적인 해결책이다 — 에이전트가 필요한 순간에 정확한 정보를 검색할 수 있게 한다.

2. 검증 루프(Verification Loop)

에이전트의 출력을 자동으로 검증하고, 기준에 미달하면 재시도하는 메커니즘이다. 린터, 타입 체커, 테스트 스위트 등 결정론적 도구와 LLM 기반 리뷰를 조합한다.

3. 상태 관리(State Management)

작업 진행 상황, 완료된 단계, 남은 작업을 추적하는 체계다. 특히 장기 실행 작업에서 컨텍스트 윈도우 간 상태를 전달하는 메커니즘이 핵심이다.

4. 도구 오케스트레이션(Tool Orchestration)

에이전트가 사용할 수 있는 도구의 범위, 호출 순서, 병렬 실행 여부를 제어한다. MCP(Model Context Protocol)가 이 영역의 표준으로 부상하고 있다.

5. 인간 개입 지점(Human-in-the-Loop)

에이전트가 자율적으로 진행하되, 위험한 결정이나 불확실한 상황에서 인간에게 판단을 위임하는 지점을 설계한다. "항상 확인"과 "완전 자율" 사이의 적절한 균형점을 찾는 것이 관건이다.

6. 라이프사이클 관리(Lifecycle Management)

에이전트의 시작, 실행, 일시정지, 재개, 종료에 걸친 전체 수명주기를 관리한다. 에러 발생 시 정상적인 복구(graceful recovery)가 특히 중요하다.

하네스 설계 3원칙

실무에서 검증된 하네스 설계의 3가지 핵심 원칙은 다음과 같다.

원칙 1: 최소 개입

모델이 스스로 수정할 수 없는 임계점에서만 시스템이 개입한다. 과도한 개입은 에이전트의 자율성을 해치고, 부족한 개입은 오류를 방치한다.

원칙 2: 단계적 권한 공개

작업 진행 정도에 따라 최소한의 권한만 부여한다. 처음에는 읽기만 허용하고, 검증이 완료되면 쓰기 권한을, 최종 단계에서만 배포 권한을 부여하는 식이다.

원칙 3: 빠른 실패와 복구

오류를 즉각 감지하여 재시도하거나, 인간에게 이관한다. 에이전트가 같은 실수를 반복하지 않도록 실패 패턴을 기록하고 학습하는 메커니즘을 포함한다.

멀티 에이전트 vs 싱글 에이전트

하네스 설계에서 중요한 아키텍처 결정 중 하나는 에이전트 수다.

Anthropic의 교훈: 단순함의 승리

Anthropic은 흥미로운 진화를 거쳤다. 초기에는 멀티 에이전트 아키텍처를 실험했지만, 결국 단일 에이전트에 강력한 하네스를 적용하는 방식이 더 안정적이라는 결론에 도달했다.

멀티 에이전트의 문제점은 에이전트 간 통신 오버헤드, 상태 동기화의 복잡성, 디버깅의 어려움이었다. 단일 에이전트에 잘 설계된 도구와 검증 루프를 제공하는 것이 더 예측 가능하고 디버깅하기 쉬웠다.

그러나 이것이 항상 정답은 아니다. 도메인이 명확히 분리되고, 병렬 처리가 필요한 경우에는 멀티 에이전트가 적합할 수 있다. 핵심은 복잡성을 정당화할 수 있는 근거가 있어야 한다는 것이다.

기업이 지금 시작해야 할 것

1. AGENTS.md 또는 CLAUDE.md 작성

코드베이스의 규칙, 아키텍처 원칙, 작업 흐름을 문서화한다. 이것은 에이전트뿐 아니라 신규 개발자 온보딩에도 도움이 된다. 투자 대비 효과가 가장 높은 첫 번째 단계다.

2. CI/CD에 에이전트 가드레일 추가

아키텍처 규칙을 CI에서 자동 검증하도록 설정한다. 에이전트가 생성한 코드도 동일한 품질 기준을 통과해야 한다.

3. RAG 기반 컨텍스트 인프라 구축

에이전트가 기업의 내부 지식에 정확하게 접근할 수 있는 인프라를 구축한다. 하네스의 컨텍스트 엔지니어링은 RAG 시스템의 품질에 직접적으로 의존한다.

4. 점진적 권한 모델 설계

에이전트의 접근 권한을 단계별로 정의하고, RBAC(역할 기반 접근 제어)을 적용한다. 처음부터 모든 권한을 부여하는 것은 보안 리스크다.

---

브랜즈모어의 하네스 접근

브랜즈모어는 Enterprise RAG 솔루션을 에이전트 하네스의 컨텍스트 엔진으로 포지셔닝하고 있다. 에이전트가 아무리 정교해도, 기업의 내부 문서와 지식에 정확하게 접근하지 못하면 실질적인 업무 자동화는 불가능하다.

브랜즈모어의 RAG 시스템은 95% 이상의 검색 정확도로 에이전트가 필요한 정보를 실시간으로 제공하며, RBAC 기반 접근 제어로 에이전트의 정보 접근 범위를 정밀하게 관리한다. 이것이 바로 하네스의 "컨텍스트 엔지니어링" 구성 요소다.

에이전트 시대의 경쟁력은 모델이 아니라 하네스에서 나온다. 그리고 하네스의 핵심은 정확한 지식 인프라다.

---

참고 자료: Anthropic Engineering Blog "Effective harnesses for long-running agents", NxCode "What Is Harness Engineering", Medium "2025 Was Agents. 2026 Is Agent Harnesses."