[AI] 하네스 엔지니어링이 비효율이 되는 이유와 아키텍처 대안 (Harness의 비효율)
초기 에이전트 시스템에서 필수적이었던 하네스가 왜 최근 프로덕션 환경에서 기술 부채와 비효율의 원인이 되고 있는지 핵심 문제점과 최신 아키텍처 방향 정리
하네스 엔지니어링(Harness Engineering)이란?
- 하네스(Harness)는 마차의 말을 통제하는 '말굴레'에서 유래한 용어로, AI 에이전트 시스템에서는 LLM의 출력을 제어하고 정해진 궤도 내에서 안전하게 작동하도록 감싸는 외부 통제 프레임워크/래퍼(Wrapper)를 의미
초기 에이전트 시스템에서 하네스가 담당했던 역할
하네스(Harness)는 마차의 말을 통제하는 '말굴레'에서 유래한 용어로, AI 에이전트 시스템에서는 LLM의 출력을 제어하고 정해진 궤도 내에서 안전하게 작동하도록 감싸는 외부 통제 프레임워크/래퍼(Wrapper)를 의미
초기 에이전트 시스템에서 하네스는 모델의 부족한 안정성을 보완하기 위한 외부 통제 계층으로 기능
- 상태 머신(State Machine) 기반 강제 제어: Planning → Action → Validation과 같은 단계별 실행 흐름을 외부 코드에서 정의하고 강제
- 엄격한 가드레일 및 검증: 시스템 프롬프트와 출력 스키마를 검증해 비정상적인 모델 출력을 사전에 차단
- 자동 에러 복구 루프: 작업 실패 시 이전 상태로 롤백하거나 동일 작업을 재시도하는 외부 감시 로직을 추가
- 도메인 룰 강제: 팀 내 코딩 컨벤션이나 아키텍처 규칙 등을 프레임워크 레벨에서 주입
GPT-3.5와 초기 GPT-4 시절에는 모델의 추론 능력과 도구 사용 안정성이 충분하지 않았기 때문에 이러한 '두꺼운 하네스(Thick Harness)'가 사실상 필수적인 안전장치로 기능
문제는 모델의 성능이 빠르게 향상되면서 시작
왜 하네스 엔지니어링이 비효율적인 구조가 되고 있는가?
최신 프론티어 모델은 과거 모델과 비교해 추론 능력과 자율적인 도구 활용 능력이 크게 향상
이 과정에서 과거 모델의 부족한 능력을 보완하기 위해 구축했던 하네스가 오히려 모델의 자율적인 판단을 제한하는 병목 계층으로 작용하기 시작
1. 모델 업그레이드와 함께 발생하는 '즉각적인 레거시화'
bits-bytes-nn의 From Prompts to Harnesses 분석에서 지적하듯, 과거에는 프롬프트 엔지니어링을 통해 모델의 행동을 통제했다면 점차 이러한 통제 로직이 하네스 아키텍처와 외부 코드로 이동. 문제는 하네스에 하드코딩된 제어 규칙과 예외 처리 역시 모델의 성능 향상과 함께 빠르게 가치가 떨어진다는 점.
과거에는 필요했던
- 특정 단계에서 반드시 검증하도록 만드는 규칙
- 특정 형태의 출력만 허용하는 로직
- 실패 시 강제로 재시도하는 로직
- 특정 상황에 대한 예외 처리
등이 모델 자체의 추론 능력이 향상되면서 불필요한 레거시 코드로 전환
특히 모델 스스로 오류를 인식하고 수정할 수 있는 수준에 도달하면, 외부 하네스가 모델보다 더 단순한 규칙을 강제하는 역전 현상 발생
결과적으로 하네스가 안정성을 높이는 안전장치가 아니라 모델이 선택할 수 있는 최적의 추론 경로를 제한하는 장애물로 작용
2. 토큰 비용과 레이턴시(Latency) 폭증
하네스가 복잡해질수록 하나의 작업을 수행하기 위해 거쳐야 하는 중간 단계도 증가
예를 들어 단순한 코드 수정 작업 하나를 수행하더라도
Planning → Action → Validation → Review → Retry → Validation
과 같은 다단계 검증 루프를 거치는 구조라면 실제 문제 해결에 필요한 추론보다 하네스를 통과하기 위한 추론에 더 많은 토큰이 소비
이러한 구조에서는
- 단일 작업 처리 시간이 수 분에서 수 시간까지 증가
- 중간 상태 검증을 위한 불필요한 토큰 지속 발생
- 반복적인 에이전트 호출로 실행 비용 급증
- 빠른 피드백이 중요한 개발 및 CI/CD 환경에서 생산성 저하
와 같은 문제가 발생
Anthropic과 PyTorch 커뮤니티의 에이전트 관련 논의에서도 지나치게 복잡한 오케스트레이션과 검증 계층이 빠른 반복 개발 환경에서는 오히려 비효율적인 구조가 될 수 있다는 지적
즉, 안정성을 높이기 위한 검증 계층 자체가 비용과 레이턴시의 주요 원인으로 전환되는 현상
3. 에이전트 간 조율 오버헤드(Coordination Overhead)
다중 에이전트 구조에서는 하네스가 단순한 실행 제어를 넘어 에이전트 사이의 통신과 승인 과정까지 관리
예를 들어
Agent A → Agent B 검증 → Agent C 승인 → Agent D 실행
과 같은 계층적 구조를 구성하면 각각의 에이전트 호출 사이에 추가적인 컨텍스트 전달과 검증 과정 발생
에이전트 A가 생성한 결과를 B가 검증하고, B의 결과를 C가 다시 승인하는 방식에서는 실제 작업보다 에이전트 간 조율 자체에 더 많은 리소스가 사용되는 상황 발생
Claude Code의 에이전트 팀 관련 문서에서도 복잡한 멀티 에이전트 오케스트레이션에서는 에이전트 간 통신과 조율 비용을 고려할 필요가 있다는 점을 강조
특히 단일 고성능 모델 세션에 충분한 컨텍스트를 제공하면 해결할 수 있는 작업까지 여러 에이전트로 분리하면 수익 체감(Diminishing Returns)이 빠르게 발생
결국 에이전트를 많이 추가한다고 해서 항상 더 높은 생산성이 나오는 것은 아닌 구조
4. 유지보수 한계와 '철회 현상(Retrenching)'
하네스의 또 다른 문제는 시간이 지날수록 외부 제어 로직이 빠르게 복잡해진다는 점
처음에는 단순한 재시도 로직 하나로 시작했던 하네스가 점차
상태 관리 → 예외 처리 → 검증 → 재시도 → 롤백 → 에이전트 간 조율
과 같은 여러 계층으로 확장
이렇게 복잡해진 시스템은 모델의 동작 자체보다 모델을 통제하기 위한 코드를 디버깅하는 데 더 많은 엔지니어링 비용을 요구
McKinsey QuantumBlack의 실무 보고서에서 언급되는 '철회(Retrenching)' 현상 역시 이러한 문제와 연결
복잡한 에이전트 시스템을 도입한 이후 디버깅 난이도와 유지보수 비용이 지나치게 높아지면서, 일부 조직이 다시 단순 자동화 구조나 얇은 에이전트 구조로 돌아가는 흐름
즉, 더 많은 에이전트와 더 복잡한 하네스가 반드시 더 좋은 시스템을 의미하지 않는다는 것
핵심 비교: 두꺼운 하네스 vs 얇은 컨텍스트 중심 설계
구분무거운 하네스(Thick Harness)얇은 컨텍스트 계층(Thin Context Wrapper)
| 제어 방식 | 외부 코드와 상태 머신을 통한 강제 통제 | 고품질 컨텍스트와 표준 프로토콜(MCP) 제공 |
| 모델 업그레이드 | 프레임워크 전면 수정 필요 | 모델 교체만으로 성능 향상 흡수 |
| 비용 & 레이턴시 | 다단계 검증 루프로 비용과 지연 증가 | 최소한의 도구 호출로 비용과 지연 최적화 |
| 에러 핸들링 | 외부 규칙에 따른 강제 롤백/재시도 | 모델 자체의 오류 인지와 자율 수정 활용 |
| 엔지니어링 방향 | 모델의 행동을 통제하는 코드 증가 | 모델이 잘 판단할 수 있는 컨텍스트 제공에 집중 |
핵심적인 차이는 '모델을 어떻게 통제할 것인가'에서 '모델이 스스로 잘 판단할 수 있는 환경을 어떻게 만들 것인가'로 관심사가 이동한다는 점
엔지니어링 방향: "하네스를 얇게 깎아내기"
최신 에이전트 아키텍처의 방향은 "스마트한 모델에게 멍청한 규칙을 강제하지 않는 것"
과거에는 모델이 스스로 수행하기 어려운 작업을 외부 코드로 강제했다면, 이제는 모델의 판단 능력을 최대한 활용하면서 시스템은 필요한 최소한의 제약만 제공하는 방식으로 변화
Simple Composable Patterns
Anthropic이 Building Effective Agents에서 제안하는 방향 역시 복잡한 프레임워크보다 단순하고 조합 가능한 패턴에 가까움
체이닝(Chaining), 라우팅(Routing)과 같이 목적이 명확한 패턴을 사용하고, 별도의 복잡한 오케스트레이션 계층은 최소화
핵심은 하네스를 계속 추가하는 것이 아니라 문제가 발생했을 때 정말 필요한 제어 계층만 남기는 것
Context Engineering & MCP
무거운 오케스트레이터를 구축하기보다는 Context Engineering을 통해 모델이 작업에 필요한 정보를 정확하게 제공
여기에 Model Context Protocol(MCP)을 활용해 도구와 데이터에 대한 표준화된 인터페이스를 제공
즉,
복잡한 하네스 → 컨텍스트 + 표준화된 도구
라는 방향으로 시스템의 중심축이 이동
모델이 어떤 도구를 어떤 순서로 사용할지 외부에서 지나치게 통제하기보다, 모델이 올바른 판단을 내릴 수 있도록 충분한 컨텍스트와 명확한 도구 인터페이스를 제공하는 방식
제거 가능성을 고려한 설계
하네스 자체를 없애는 것보다 중요한 것은 언제든 제거할 수 있도록 만드는 것
모델의 성능이 향상됐을 때 더 이상 필요하지 않은 제약 로직을 쉽게 제거할 수 있도록 외부 제어 계층의 결합도를 낮추고 기능을 모듈화
결국 좋은 하네스는 많은 기능을 가진 하네스가 아니라 필요 없어졌을 때 쉽게 사라질 수 있는 하네스
요약 및 결론
- 하네스 엔지니어링은 초기 LLM의 부족한 추론 능력과 불안정한 도구 사용을 보완하기 위한 과도기적 엔지니어링 패턴
- 당시에는 모델이 스스로 오류를 판단하거나 복구하기 어려웠기 때문에 상태 머신, 검증 로직, 재시도 루프와 같은 외부 제어 계층이 필수적인 역할
- 하지만 모델의 추론 능력과 도구 활용 능력이 빠르게 발전하면서 상황이 변화
- 과거 모델을 기준으로 만들어진 하네스는 모델의 발전과 함께 레거시 코드로 전환될 가능성이 높고, 복잡한 검증 루프는 토큰 비용과 레이턴시를 증가시키며, 다중 에이전트 오케스트레이션은 조율 오버헤드를 발생
- 따라서 최신 에이전트 시스템의 핵심은 더 많은 하네스를 만드는 것이 아니라 하네스를 얼마나 얇게 만들 수 있는가에 가까움
- 복잡한 상태 머신과 강제적인 제어 로직을 계속 추가하기보다, 정제된 컨텍스트를 제공하고 MCP와 같은 표준화된 인터페이스를 활용해 모델이 스스로 판단할 수 있는 환경을 구성
- 결국 에이전트 엔지니어링의 방향은 "모델을 통제하는 시스템"에서 "모델이 잘 판단할 수 있도록 환경을 설계하는 시스템"으로의 전환
참고 출처
- From Prompts to Harnesses — Four Years of AI Agentic Patterns — bits-bytes-nn
- Building Effective Agents — Anthropic Research
- Orchestrate Agent Teams — Claude Code Docs
- One year of agentic AI: Six lessons from the people doing the work — McKinsey QuantumBlack
- 장시간 자율 코딩을 위한 에이전트 하네스 설계 — PyTorch Discuss