# [[Phase 3- Harness Engineering]]

## 📌 Brief Summary
'Phase 3: Harness Engineering'은 AI 에이전트 발전의 세 번째 단계로, 모델의 크기(Phase 1)나 프롬프트 및 컨텍스트(Phase 2)를 개선하는 것을 넘어 모델이 작동하는 '환경'을 설계하는 단계를 의미한다 [1, 2]. 이는 에이전트의 성공 여부를 결정짓는 컨텍스트 전달, 도구 인터페이스, 계획 아티팩트, 검증 루프, 메모리 시스템 및 샌드박스 등 스캐폴딩(Scaffolding)을 설계하는 공학적 규율이다 [3]. 이 단계에서는 "모델에게 무엇을 말할 것인가"가 아니라 "모델을 어떤 환경에서 작동시킬 것인가"에 집중하여 에이전트의 신뢰성과 성능을 극대화한다 [2].

## 📖 Core Content
* **에이전트 발전의 3단계 진화:** AI 에이전트 개발은 더 큰 모델과 데이터를 학습시키는 '가중치 단계(Phase 1)', 프롬프트 엔지니어링이나 RAG 등을 통해 모델이 보는 것을 변경하는 '컨텍스트 단계(Phase 2)'를 거쳐, 현재 런타임과 인프라를 최적화하는 '하네스 엔지니어링 단계(Phase 3)'로 진화했다 [1].
* **환경 및 스캐폴딩 중심 설계:** 모델 자체는 고정된 텍스트 생성기로 유지되지만, 영구적인 메모리, 스킬 파일, 작업 순서를 제어하는 런타임 등의 하네스 환경을 제공함으로써 에이전트의 신뢰성과 작업 해결 능력을 근본적으로 변화시킨다 [2, 4].
* **제어 루프 (피드포워드와 피드백):** 하네스 엔지니어링은 에이전트가 오류를 범하기 전에 올바른 방향으로 안내하는 '피드포워드 가이드(Feedforward Guides)'와, 행동 완료 후 결과를 관찰하여 스스로 수정할 수 있게 돕는 '피드백 센서(Feedback Sensors)'라는 두 가지 핵심 제어 루프를 통해 에이전트를 조향(Steering)한다 [5-8].
* **컴퓨테이셔널(Computational) 및 인퍼렌셜(Inferential) 제어:** 하네스의 제어 장치는 린터나 정적 분석, 테스트처럼 빠르고 결정론적인 '컴퓨테이셔널 제어'와, LLM 심사관(LLM-as-judge)처럼 느리고 확률적이지만 의미론적 판단이 가능한 '인퍼렌셜 제어'로 나뉘어 구성된다 [9, 10].
* **메타 하네스(Meta-Harness) 최적화:** 최근 연구에서는 시스템 프롬프트, 도구 구성, 오케스트레이션 코드 등 하네스 전체를 최적화 대상으로 간주하여, 에이전트가 자체 실행 트레이스와 실패 신호를 바탕으로 스스로 하네스 구조를 반복적으로 진화시키는 메타 하네스 패턴으로 발전하고 있다 [11, 12].

## ⚖️ Trade-offs & Caveats
* **데이터 품질 보증의 구조적 공백:** 현존하는 대부분의 하네스 오케스트레이션 프레임워크는 에이전트가 읽는 데이터가 신뢰할 수 있다고 가정할 뿐 이를 자체적으로 인증하거나 검증하지 않는다 [13-15]. 통제되지 않은 환경에서 스키마가 변경되거나 오래된 데이터가 유입되면 하네스의 오케스트레이션이 아무리 정교하더라도 '메모리 오염'이나 '연쇄 실패'와 같은 치명적인 오류가 발생할 수 있다 [16, 17].
* **특정 하네스 구조에 대한 과적합(Overfitting):** 특정 하네스 환경 내에서 훈련(Post-trained)된 모델은 해당 하네스 설계에 과적합되는 부작용을 겪을 수 있다 [18, 19]. 이로 인해 도구의 논리나 런타임 지속성(Persistence) 모드가 조금만 변경되어도 일반화 능력을 상실하고 심각한 성능 저하나 토큰 낭비가 발생할 수 있다 [19, 20].
* **인퍼렌셜 센서의 높은 비용과 비결정성:** 의미론적 판단이나 AI 코드 리뷰를 수행하는 인퍼렌셜 센서(Inferential Sensors)는 유용하지만 실행 속도가 느리고 비용이 많이 들며 결과가 비결정론적이다 [9, 10]. 이로 인해 모든 변경 사항에 대해 상시 실행하기 어렵고, 사람의 의도 오해나 과도한 엔지니어링과 같은 고영향 문제를 완벽히 포착하기에는 여전히 한계가 있다 [21].
* **멀티 에이전트 조율의 복잡도 증가:** 여러 에이전트가 협업하는 하네스 아키텍처는 본질적으로 분산 시스템처럼 동작하게 된다 [22, 23]. 따라서 각 에이전트 간의 핸드오프(Handoff) 과정에서 명시적인 경계 검증과 엄격한 스키마가 강제되지 않으면 조율 실패가 발생하여 막대한 아키텍처 관리 오버헤드를 초래한다 [22, 23].

---
*Last updated: 2026-05-05*