2025년이 AI 에이전트의 해였다면, 2026년은 하네스(Harness)의 해입니다. 모델은 이미 충분히 강력해졌고, 이제 경쟁력은 모델 자체가 아니라 모델을 감싸는 시스템에서 갈립니다.

이 글에서는 하네스 엔지니어링의 개념부터 필요한 도구, 실전 적용법, 그리고 현재 트렌드까지 슬라이드 형식으로 정리합니다.


Slide 1. 하네스 엔지니어링이란?

한 줄 정의

AI 에이전트가 무엇을 보고, 무엇을 할 수 있고, 언제 멈추고, 실패하면 어떻게 되는지를 설계하는 엔지니어링 규율

비유: 말과 마구(馬具)

LLM은 강력하지만 방향 감각이 없는 말입니다. 하네스는 그 힘을 통제 가능한 작업으로 전환하는 고삐, 안장, 재갈 역할을 합니다.

개념 초점
프롬프트 엔지니어링 단일 모델 호출의 품질 개선
컨텍스트 엔지니어링 컨텍스트 윈도우에 무엇을 넣을지 결정
하네스 엔지니어링 컨텍스트 윈도우 바깥의 모든 것 — 도구, 상태, 검증, 생명주기

하네스 엔지니어링은 프롬프트 엔지니어링의 상위 개념입니다. 프롬프트가 “한 번의 대화를 잘하는 법”이라면, 하네스는 “100번의 세션을 걸쳐 일관되게 잘하는 법”입니다.


Slide 2. 왜 하네스가 필요한가?

LLM의 근본적 한계

LLM은 기본적으로 무상태(stateless)입니다. 매 세션은 이전 작업에 대한 기억 없이 시작됩니다.

문제 설명
컨텍스트 붕괴 도구 결과와 이력으로 윈도우가 채워지면 원래 지시를 놓침
환각적 도구 호출 존재하지 않는 API를 참조하거나 잘못된 매개변수 사용
실패 시 상태 손실 네트워크 오류 시 진행 상황이 완전히 소실
조기 완료 선언 검증 없이 “완료”를 선언하는 경향

모델은 상품화되었다

Claude, GPT, Gemini, 오픈소스 모델들의 성능 차이는 좁아지고 있습니다. 동일한 모델을 사용해도 하네스 품질에 따라 작업 완료율이 40%p 차이가 납니다.

모델은 교체 가능한 부품이고, 하네스가 곧 제품이다.


Slide 3. 하네스의 6대 핵심 구성요소

graph TB subgraph Harness["Agent Harness"] CE["1. Context Engineering
컨텍스트 엔지니어링"] VL["2. Verification Loops
검증 루프"] SM["3. State Management
상태 관리"] TO["4. Tool Orchestration
도구 오케스트레이션"] HL["5. Human-in-the-Loop
인간 개입"] LM["6. Lifecycle Management
생명주기 관리"] LLM["LLM"] end CE --> LLM VL --> LLM SM --> LLM TO --> LLM HL --> LLM LM --> LLM

1. 컨텍스트 엔지니어링

에이전트가 무엇을 볼 수 있는지 결정합니다.

  • 코드베이스 내 지속적으로 개선되는 지식 기반 (AGENTS.md, CLAUDE.md 등)
  • 관찰 가능성 데이터, 브라우저 네비게이션 같은 동적 컨텍스트
  • “Lost in the Middle” 문제 대응 — 가장 중요한 정보를 프롬프트의 시작과 끝에 배치
  • 3종 메모리 운영: 작업 컨텍스트(임시), 세션 상태(중기), 장기 메모리(영구)

2. 검증 루프

에이전트가 제대로 했는지 확인합니다.

  • 코딩 에이전트: 테스트 스위트 통과 후에만 기능 완료 표시
  • 기능 목록을 JSON으로 관리 → 각 기능의 pass/fail 상태를 기계적으로 추적
  • 결정론적 린터 + 구조 테스트로 아키텍처 제약 위반 감지

3. 상태 관리

에이전트가 어디까지 했는지 기억합니다.

  • claude-progress.txt 같은 진행 로그
  • Git 커밋으로 각 단계의 진행 상황 문서화
  • JSON 형식 선호 (모델이 마크다운보다 JSON을 덜 임의로 수정함)

4. 도구 오케스트레이션

에이전트가 무엇을 할 수 있는지 제어합니다.

  • 파일 시스템 접근, 코드 실행, API 호출, 웹 검색 등
  • 사전 승인된 도구만 접근 가능하도록 제한
  • MCP(Model Context Protocol) 서버를 통한 도구 연결

5. 휴먼-인-더-루프

에이전트가 언제 사람에게 물어봐야 하는지 결정합니다.

  • 파괴적 작업(삭제, 배포 등)에 대한 인간 승인 요구
  • 완전 자율은 드물게 적절 — 대부분의 시나리오에서 인간 개입 지점 설계 필수
  • 민감한 결정에 대한 에스컬레이션 경로

6. 생명주기 관리

에이전트의 시작과 끝, 그리고 세션 간 전환을 관리합니다.

  • 초기화 에이전트 → 코딩 에이전트 분리 패턴
  • 각 세션 시작 시 표준 절차: pwd 확인 → git 로그 읽기 → 기능 목록 확인 → 다음 작업 선택
  • 실패 시 안전한 롤백 경로

Slide 4. 하네스 엔지니어링에 필요한 도구들

코드 품질 & 제약 도구

도구 역할
Pre-commit hooks 커밋 전 코드 품질 자동 검증
Custom linters 조직 고유 규칙 강제 적용
ArchUnit / 구조 테스트 코드 아키텍처 제약을 테스트로 검증
CI/CD 파이프라인 에이전트 생성 코드의 자동 빌드/테스트/배포

컨텍스트 & 메모리 도구

도구 역할
AGENTS.md / CLAUDE.md 코드베이스 내 에이전트 지시사항 문서
벡터 스토어 장기 메모리 저장 및 시맨틱 검색
진행 로그 (JSON) 세션 간 상태 유지
Git 진행 상황 문서화 & 롤백 지점

도구 연결 & 오케스트레이션

도구 역할
MCP 서버 표준화된 도구 인터페이스 제공
Puppeteer / Playwright 브라우저 자동화를 통한 E2E 검증
Firecrawl 웹 검색/스크래핑 — 에이전트의 웹 접근 계층
컨테이너/샌드박스 에이전트 실행 환경 격리

검증 & 안전 도구

도구 역할
테스트 프레임워크 기능 완료 여부 기계적 검증
레드팀 도구 에이전트 취약점 사전 탐지
모니터링/알림 에이전트 행동 이상 감지
감사 로그 에이전트 행동의 추적 가능성 보장

Slide 5. 실전: 하네스 엔지니어링은 어떻게 하는가?

아키텍처 패턴 선택

패턴 A: 단일 에이전트 + 감독자 루프

  • 하나의 모델이 도구·메모리·검증과 함께 루프
  • 적합: 고객 지원, 단순 자동화

패턴 B: 초기화-실행자 분할 (Anthropic 추천)

  • 초기화 에이전트가 환경 세팅 후, 코딩 에이전트가 증분 진행
  • 적합: 장기 실행 코딩 작업

패턴 C: 멀티 에이전트 조율

  • 연구자·작가·검토자 등 전문가 에이전트 간 작업 위임
  • 적합: 복잡한 프로젝트, 다단계 파이프라인

실전 체크리스트

Step 1: 기능 목록 정의

[
  {
    "category": "functional",
    "description": "사용자가 새 대화를 생성할 수 있다",
    "passes": false
  },
  {
    "category": "functional",
    "description": "메시지 전송 시 실시간 응답이 표시된다",
    "passes": false
  }
]

모든 기능을 false로 시작하여 완료 기준을 명확히 합니다.

Step 2: 초기화 스크립트 작성

#!/bin/bash
# init.sh — 에이전트가 매 세션 시작 시 실행
npm install
npm run dev &
echo "Development server started"

Step 3: 에이전트 지시사항 문서 작성

# AGENTS.md

## 작업 규칙
- 한 번에 하나의 기능만 작업할 것
- 기능 완료 전 반드시 E2E 테스트를 실행할 것
- 테스트를 삭제하거나 수정하는 것은 금지
- 작업 완료 후 git commit으로 진행 상황을 기록할 것

## 세션 시작 절차
1. pwd로 현재 디렉토리 확인
2. git log로 최근 진행 상황 확인
3. features.json에서 다음 미완료 기능 선택
4. init.sh로 개발 서버 시작

Step 4: 검증 자동화 구축

# .github/workflows/agent-verify.yml
on: [push]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint        # 커스텀 린터
      - run: npm run test:arch   # 구조 테스트
      - run: npm run test:e2e    # E2E 테스트

Step 5: 엔트로피 관리 (가비지 컬렉션)

주기적으로 별도 에이전트가 코드베이스를 스캔합니다:

  • 문서화 불일치 감지 및 수정
  • 아키텍처 제약 위반 탐지
  • 코드 부패(code rot) 식별

OpenAI 팀의 핵심 통찰: 에이전트가 어려움을 겪을 때, 그것을 신호로 해석하라. 부족한 도구, 가드레일, 문서를 식별하고 저장소에 피드백하는 것이 하네스 엔지니어링의 핵심 루프다.


Slide 6. 하네스 엔지니어링을 위한 SDK & 개발 킷

하네스를 직접 처음부터 만들 필요는 없습니다. 주요 벤더와 오픈소스 커뮤니티가 에이전트 하네스 구축을 위한 SDK와 프레임워크를 제공합니다.

코딩 에이전트 하네스 (완성형)

이미 하네스가 내장된 에이전트 환경으로, 즉시 사용 가능합니다.

제품 제공사 핵심 하네스 기능
Claude Code Anthropic 5계층 권한 모델, 18+ 훅 이벤트, CLAUDE.md 컨텍스트, 자동 스냅샷/롤백, 서브에이전트 스포닝, 워크트리 격리
Codex CLI OpenAI 샌드박스 실행, AGENTS.md 지시사항, 파일 접근 제어, 도구 정의, 자동 검증 루프
Cursor Cursor Inc. .cursor/rules 기반 하네스, IDE 통합, 루프 탐지, 모델별 프롬프트 적응
Windsurf Codeium Cascade 에이전트, 컨텍스트 인식 코드 생성, 멀티파일 편집, 터미널 통합

Claude Code 하네스 아키텍처 상세

Claude Code는 가장 정교한 하네스 시스템 중 하나입니다:

graph LR CC["Claude Code Harness"] CC --> PM["Permission Model
5계층"] PM --> PM1["Mode
plan/autoEdit/fullAuto"] PM --> PM2["Allowlist"] PM --> PM3["MCP Permissions"] PM --> PM4["Bash Rules"] PM --> PM5["User Prompt"] CC --> HK["Hooks System
18+ 이벤트"] HK --> HK1["PreToolUse / PostToolUse"] HK --> HK2["SessionStart / SessionEnd"] HK --> HK3["Notification / Stop"] CC --> CTX["Context Engineering"] CTX --> CTX1["CLAUDE.md"] CTX --> CTX2["자동 컨텍스트 압축"] CTX --> CTX3["3종 메모리"] CC --> EX["Execution"] EX --> EX1["서브에이전트 스포닝"] EX --> EX2["워크트리 격리"] EX --> EX3["태스크 의존성 그래프"] CC --> SF["Safety"] SF --> SF1["자동 스냅샷 & 롤백"] SF --> SF2["읽기 전용 기본값"] SF --> SF3["파괴적 작업 승인 요구"]

에이전트 개발 SDK (프레임워크)

에이전트를 직접 구축할 때 하네스 기능을 제공하는 SDK입니다.

Claude Agent SDK (Anthropic)

  • 접근 방식: Tool-use-first — 에이전트 = Claude 모델 + 도구
  • 하네스 기능: 훅 시스템, 권한 모델, 다른 에이전트를 도구로 호출
  • 아키텍처: 프롬프트 수신 → 필요시 도구 호출 → 구조화된 응답 반환
  • 강점: 의도적으로 단순한 설계, Anthropic 플랫폼 네이티브 통합
from claude_agent_sdk import Agent, Tool

agent = Agent(
    model="claude-sonnet-4-6",
    tools=[filesystem, code_runner, browser],
    hooks={"pre_tool_use": lint_check, "post_tool_use": test_runner},
    permissions={"file_write": "ask", "bash": "restricted"}
)

OpenAI Agents SDK

  • 접근 방식: 최소주의 — 핵심 추상화는 “Handoff”
  • 하네스 기능: 입력/출력 가드레일, 낙관적 실행 + 롤백, 추적/평가
  • 아키텍처: 에이전트 간 명시적 제어 전환 (Handoff 메커니즘)
  • 강점: 가장 낮은 학습 곡선, 빠른 프로토타이핑
from agents import Agent, Runner, InputGuardrail

agent = Agent(
    name="code_agent",
    instructions="...",
    tools=[file_tool, shell_tool],
    input_guardrails=[safety_check],
    output_guardrails=[quality_check]
)
result = Runner.run(agent, "Fix the login bug")

Google ADK (Agent Development Kit)

  • 접근 방식: 명시적 워크플로우 타입 (Sequential, Parallel, Loop)
  • 하네스 기능: 에이전트를 도구로 사용하는 계층 구조, Vertex AI 통합, Developer UI
  • 아키텍처: 결정론적 + 동적 흐름 혼합, OpenAPI 자동 변환
  • 강점: GCP 생태계 네이티브, 풍부한 내장 도구, 평가 도구 내장
from google.adk import Agent, SequentialAgent, ParallelAgent

researcher = Agent(name="researcher", tools=[search, scrape])
writer = Agent(name="writer", tools=[file_write])
pipeline = SequentialAgent(
    agents=[researcher, writer],
    guardrails=safety_filter
)

AWS Strands Agents SDK

  • 접근 방식: 모델 주도(model-driven) — Model + Tools + Prompt
  • 하네스 기능: 내장 도구 20+, MCP 서버 연결, @tool 데코레이터
  • 아키텍처: 모델이 계획·도구 선택·결과 반영을 모두 주도
  • 강점: AWS Bedrock 네이티브, 복잡한 오케스트레이션 불필요
from strands import Agent
from strands.tools import tool

@tool
def deploy(service: str) -> str:
    """Deploy a service to production"""
    return run_deploy(service)

agent = Agent(tools=[deploy])
result = agent("Deploy the user service")

오케스트레이션 프레임워크

에이전트 간 조율과 복잡한 워크플로우를 위한 프레임워크입니다.

프레임워크 핵심 특징 하네스 관련 기능
LangGraph 그래프 기반 상태 관리, 노드/엣지 명시적 정의 체크포인트 복구, HITL 내장, LangSmith 가드레일
CrewAI 역할 기반 멀티 에이전트 협업 Flows 이벤트 파이프라인, 에이전트 간 위임
MS AutoGen 대화 기반 멀티 에이전트 (Microsoft) 그룹 채팅 패턴, 코드 실행 샌드박스, 비동기 메시징
AWS Bedrock Agents 완전 관리형 서비스 사전 구축 가드레일, IAM 통합, Knowledge Base RAG

Microsoft AutoGen

  • 접근 방식: 대화 기반 멀티 에이전트 — 에이전트들이 그룹 채팅처럼 대화
  • 하네스 기능: 코드 실행 샌드박스, 비동기 메시징, 그룹 채팅 관리자
  • 아키텍처: AssistantAgent, UserProxyAgent 등 역할별 에이전트가 대화로 협업
  • 강점: Microsoft 생태계 통합, 인간 참여가 자연스러운 대화 흐름에 녹아듦
from autogen import AssistantAgent, UserProxyAgent, GroupChat

coder = AssistantAgent("coder", llm_config=llm_config)
reviewer = AssistantAgent("reviewer", llm_config=llm_config)
executor = UserProxyAgent("executor", code_execution_config={"work_dir": "workspace"})

group_chat = GroupChat(agents=[coder, reviewer, executor], messages=[])

도구 연결 표준: MCP (Model Context Protocol)

모든 SDK를 관통하는 핵심 표준이 MCP입니다.

graph TB Agent["AI Agent
(SDK 무관)"] <-->|"MCP
표준 프로토콜"| Server["MCP Server
(도구 제공)"] Server --> FS["파일시스템"] Server --> DB["데이터베이스"] Server --> API["외부 API"]
  • 어떤 SDK를 사용하든 동일한 도구 인터페이스 제공
  • Claude Code, Cursor, Codex 모두 MCP 지원
  • 한 번 만든 MCP 서버를 여러 에이전트에서 재사용

SDK 선택 가이드

시나리오 추천 SDK 이유
즉시 코딩 에이전트 사용 Claude Code / Codex CLI 하네스 내장, 설정만으로 시작
커스텀 에이전트 구축 (Anthropic) Claude Agent SDK 단순한 설계, 강력한 훅/권한
커스텀 에이전트 구축 (OpenAI) OpenAI Agents SDK 최소 학습 곡선, Handoff 패턴
GCP 생태계 활용 Google ADK Vertex AI 네이티브, 평가 도구
AWS 생태계 활용 Strands Agents Bedrock 네이티브, 모델 주도
복잡한 멀티 에이전트 파이프라인 LangGraph 그래프 기반 상태, 벤더 중립
역할 기반 에이전트 팀 CrewAI 직관적 역할 정의, Flows
관리형 서비스 선호 AWS Bedrock Agents 코드 최소, 가드레일 내장

비교 요약

항목 Claude Agent SDK OpenAI Agents SDK Google ADK Strands LangGraph
학습 곡선 낮음 가장 낮음 높음 낮음 중간
모델 유연성 Anthropic 중심 OpenAI 중심 멀티모델 Bedrock 중심 벤더 중립
가드레일 훅 기반 입출력 객체 콜백 + 필터 도구 제한 LangSmith
HITL 권한 모델 내장 코드 구현 콜백 지원 코드 구현 내장 지원
배포 자유 자유 GCP 최적 AWS 최적 자유
멀티 에이전트 서브에이전트 Handoff 계층 구조 멀티에이전트 그래프 노드

Slide 7. 실제 사례: OpenAI Codex

OpenAI의 Codex 팀은 하네스 엔지니어링의 가장 대표적인 사례입니다.

프로젝트 개요

  • 5개월 동안 프로덕션 애플리케이션 개발
  • 100만 줄 이상의 코드, 전부 AI가 생성
  • 인간 엔지니어는 코드를 한 줄도 직접 작성하지 않음
  • 엔지니어의 역할: AI가 코드를 안정적으로 작성할 수 있는 시스템을 설계

3가지 핵심 하네스 전략

1. 컨텍스트 엔지니어링

  • 코드베이스 내 지속적으로 개선되는 지식 기반
  • 관찰 가능성 데이터와 동적 컨텍스트 제공

2. 아키텍처 제약

  • 결정론적 커스텀 린터와 구조 테스트
  • LLM 기반 방식과 결정론적 방식의 혼합
  • 에이전트의 “해결 공간”을 좁혀서 신뢰성 확보

3. 가비지 컬렉션 에이전트

  • 주기적으로 코드베이스 엔트로피를 감지·수정
  • 문서 불일치, 아키텍처 위반, 코드 부패 자동 탐지

핵심 교훈

“제약이 클수록 신뢰성이 높다” — 무제한 유연성보다 제약된 해결 공간이 더 나은 결과를 만든다


Slide 8. 실제 사례: Anthropic의 장기 실행 에이전트 하네스

Anthropic은 장기 실행 코딩 에이전트를 위한 초기화-실행자 분할 패턴을 권장합니다.

2단계 아키텍처

graph LR subgraph S0["Session 0 — 초기화"] Init["초기화 에이전트"] Init --> I1["init.sh 작성"] Init --> I2["features.json 생성"] Init --> I3["초기 커밋"] Init --> I4["환경 검증"] end subgraph SN["Session 1..N — 실행"] Code["코딩 에이전트"] Code --> C1["진행 로그 읽기"] Code --> C2["다음 기능 선택"] Code --> C3["구현 & 테스트"] Code --> C4["커밋 & 업데이트"] end S0 -->|"환경 준비 완료"| SN

주요 실패 패턴과 해결책

문제 원인 해결책
조기 완료 선언 검증 없이 “done” 기능 목록 + E2E 테스트 강제
문서화 부족 세션 간 정보 손실 Git 커밋 + 진행 로그 의무화
앱 실행에 시간 낭비 매번 환경 셋업 init.sh로 표준화
기존 코드 파괴 컨텍스트 부족 이전 커밋 로그 참조 의무화

베스트 프랙티스

  • JSON > Markdown: 모델이 JSON 파일은 임의로 수정하는 경향이 적음
  • 강력한 금지 지시: “테스트를 삭제하거나 수정하는 것은 허용되지 않음”
  • E2E 검증 우선: 단위 테스트보다 실제 사용자 관점의 E2E 테스트

Slide 9. 현재 트렌드와 미래 방향

트렌드 1: 하네스 = 새로운 경쟁 우위

모델 성능이 수렴하면서, 하네스 품질이 곧 제품 품질이 되었습니다. 동일 모델에서 하네스 유무에 따라 2~5배의 신뢰성 차이가 발생합니다.

트렌드 2: 하네스 엔지니어, 새로운 직군의 탄생

에이전트 기반 제품을 만드는 회사에서 “Harness Engineer”가 독립적인 역할로 등장하고 있습니다. 기존 소프트웨어 엔지니어링 + AI 시스템 설계 + 안전성 엔지니어링의 교차점입니다.

트렌드 3: Meta-Harness — 하네스를 최적화하는 AI

최신 연구에서는 하네스 코드 자체를 AI가 최적화하는 메타 하네스 개념이 등장했습니다. 소스 코드, 점수, 실행 트레이스를 분석하여 더 나은 하네스를 자동으로 제안합니다.

트렌드 4: 기술 스택의 수렴

개발자의 프레임워크/언어 취향보다 AI 친화적 구조가 우선시되는 경향입니다. 하네스가 유지보수하기 좋은 코드 구조가 사실상의 표준으로 자리잡고 있습니다.

트렌드 5: 모델 드리프트 감지

하네스가 모델이 100번째 스텝 이후 지시를 따르지 않거나 추론 오류를 범하는 시점을 정확히 감지하는 도구로 진화하고 있습니다.

트렌드 6: 신규 vs 기존 코드베이스 분화

  • 신규 프로젝트: 처음부터 하네스를 고려하여 설계
  • 기존 프로젝트: 하네스 레트로핏이 항상 가치 있지는 않음 — 엔트로피가 높은 레거시 코드는 비용 대비 효과가 낮을 수 있음

Slide 10. 핵심 요약

“더 나은 모델”이 아니라 “더 나은 제어 환경”이 장기적 코드 품질과 에이전트 신뢰성을 결정한다

원칙 설명
모델은 부품, 하네스가 제품 모델은 교체 가능하지만 하네스는 경쟁 우위
제약이 신뢰를 만든다 해결 공간을 좁힐수록 결과가 안정적
실패를 신호로 에이전트 실패 → 하네스 개선 기회
검증은 자동으로 수동 검토 대신 E2E 테스트와 구조 테스트
점진적 진행 한 번에 하나의 기능, 매번 커밋

참고 자료