Harness vs 관련 개념

개념의 진화

AI 에이전트 분야는 짧은 시간 안에 여러 “Engineering” 개념을 만들어냈습니다. 각 개념은 이전 개념의 한계를 보완하며 등장했습니다. 이 진화 흐름을 이해하면 왜 Harness Engineering이 현재 시점에 중요한지 명확해집니다.

2020 → Prompt Engineering   : 모델에게 어떻게 물어볼 것인가
2023 → Context Engineering  : 모델에게 무엇을 보여줄 것인가
2024 → Agent Engineering    : 에이전트를 어떻게 설계할 것인가
2025 → Harness Engineering  : 에이전트 환경을 어떻게 구성할 것인가

2020 – Prompt Engineering: GPT-3 공개 이후, 동일한 모델에서 프롬프트 하나로 결과가 극명하게 달라진다는 사실이 알려졌습니다. Few-shot 예시, Chain-of-Thought 지시어, 역할 부여(system prompt) 같은 기법이 체계화됐습니다. 단점은 단일 호출에서만 유효하다는 것이었습니다.

2023 – Context Engineering: RAG(Retrieval-Augmented Generation)와 긴 컨텍스트 윈도우가 등장하면서 “무엇을 모델에게 보여줄 것인가”가 새로운 문제로 부상했습니다. 검색 결과를 어떻게 압축하고, 대화 기록을 어떻게 요약하며, 어떤 메모리를 언제 주입할지가 핵심 과제가 됐습니다.

2024 – Agent Engineering: 도구 호출, ReAct 루프, 멀티에이전트 협업이 실용화됐습니다. 단일 모델 호출이 아닌, 여러 에이전트가 협력하는 복잡한 아키텍처를 어떻게 설계하느냐가 중심 주제였습니다.

2025 – Harness Engineering: 에이전트가 프로덕션에 투입되면서 새로운 문제가 드러났습니다. 잘 설계된 에이전트도 잘못된 환경에서는 실패합니다. 검증 레이어 없이 외부 API를 그대로 에이전트에 노출하거나, 실행 결과를 피드백하지 않는 시스템은 엔트로피가 누적되어 무너집니다.

개념별 비교표

| 개념 | 범위 | 핵심 질문 | 주요 도구/기법 | |---|---|---|---| | Prompt Engineering | 단일 LLM 호출 | 어떻게 좋은 응답을 이끌어내는가? | Few-shot, Chain-of-Thought, System prompt | | Context Engineering | 모델의 컨텍스트 윈도우 | 어떤 정보를 언제 모델에게 보여주는가? | RAG, 메모리 압축, 동적 컨텍스트 | | Agent Engineering | 에이전트 내부 아키텍처 | 에이전트를 어떻게 설계하는가? | ReAct, 도구 설계, 상태 관리 | | Harness Engineering | 에이전트 주변 시스템 전체 | 에이전트가 올바르게 작동하도록 환경을 어떻게 구성하는가? | 제약, 검증, 피드백 루프, 엔트로피 관리 | | Platform Engineering | 개발 인프라 전체 | 개발팀이 효율적으로 일하도록 환경을 어떻게 만드는가? | CI/CD, IDP, 셀프서비스 플랫폼 |

개념 간 경계 — 벤 다이어그램으로 보기

각 Engineering 개념은 완전히 분리된 영역이 아닙니다. 겹치는 부분이 있고, Harness Engineering은 그 교차점을 포괄합니다.

| 영역 | Prompt Eng | Context Eng | Agent Eng | Harness Eng | |---|:---:|:---:|:---:|:---:| | 프롬프트 작성 및 최적화 | ✓ | | | ✓ | | 컨텍스트 윈도우 관리 | | ✓ | | ✓ | | 메모리 전략 (단기/장기) | | ✓ | ✓ | ✓ | | 에이전트 루프 설계 | | | ✓ | ✓ | | 도구(Tool) 인터페이스 설계 | | | ✓ | ✓ | | 출력 검증 및 가드레일 | | | | ✓ | | 샌드박스 실행 환경 | | | | ✓ | | 피드백 루프 및 관측 가능성 | | | | ✓ | | 에이전트 간 신뢰 경계 | | | | ✓ |

Prompt Engineering의 한계

Prompt Engineering은 단일 상호작용에 최적화되어 있습니다. “더 나은 프롬프트를 작성하면 더 나은 결과를 얻는다”는 전제입니다.

하지만 멀티스텝 에이전트 시스템에서는 이 전제가 무너집니다.

에이전트가 10번의 도구 호출을 거치면서 컨텍스트가 오염됩니다
첫 번째 단계의 오류가 이후 단계 전체를 오염시킵니다
좋은 프롬프트도 잘못된 도구 결과를 받으면 실패합니다

레스토랑을 예로 들어봅시다. Prompt Engineering은 웨이터가 손님의 주문을 정확히 받도록 훈련하는 것입니다. 훌륭한 웨이터라도 주방이 혼란스럽거나, 재료가 오염됐거나, 주문이 주방에 전달되지 않으면 음식은 나오지 않습니다.

Context Engineering은 주방이 필요한 레시피와 재료 정보를 제때 받도록 보장하는 것입니다. Agent Engineering은 주방 워크플로우 자체 — 어떤 셰프가 어떤 요리를 담당하는지 — 를 설계합니다.

Harness Engineering은 이 모든 것을 아우르는 레스토랑 운영 시스템입니다: 위생 점검 체계, 주문 추적 대시보드, 불량 재료 반송 프로세스, 피크타임 부하 분산, 손님 불만 피드백 루프까지 포함합니다. 웨이터 교육만 잘한다고 레스토랑이 잘 돌아가지 않습니다.

Context Engineering과의 관계

Context Engineering은 Harness Engineering의 핵심 구성 요소이지만, 하네스보다 좁은 개념입니다.

Context Engineering이 다루는 것:

어떤 정보를 컨텍스트에 포함할 것인가
오래된 정보를 어떻게 압축할 것인가
다양한 메모리 유형(단기/장기/에피소딕)을 어떻게 관리할 것인가

구체적인 도구와 기법: LangChain의 ConversationSummaryMemory, OpenAI의 함수 호출 스키마 압축, Pinecone/Weaviate 기반 벡터 검색, sliding window 방식의 대화 히스토리 관리가 여기에 해당합니다.

Harness Engineering이 추가로 다루는 것:

에이전트 행동에 대한 구조적 제약
실행 환경의 안전성
에이전트 출력 검증
시스템 수준의 엔트로피 관리

Agent Engineering과의 관계

Agent Engineering과 Harness Engineering은 상호 보완적입니다. 혼동하기 쉽지만 관점이 다릅니다.

| 구분 | Agent Engineering | Harness Engineering | |---|---|---| | 관점 | 에이전트 내부 | 에이전트 외부 | | 관심사 | 어떻게 추론하는가 | 어떻게 제어되는가 | | 결과물 | 에이전트 아키텍처 | 에이전트 인프라 | | 예시 (구체) | LangGraph 노드 설계, ReAct 루프 구현, 도구 선택 로직 | 출력 스키마 검증, E2B 샌드박스, 실행 타임아웃, 감사 로그 |

좋은 에이전트를 만들려면 둘 다 필요합니다. 하지만 실패 원인의 대부분은 에이전트 내부가 아닌 하네스 부재에서 옵니다.

Platform Engineering과의 관계

Platform Engineering은 DevOps의 진화로, 개발팀 전체가 효율적으로 일할 수 있는 **내부 개발자 플랫폼(IDP)**을 만드는 것입니다. Backstage, Crossplane, ArgoCD 같은 도구로 셀프서비스 인프라를 제공합니다.

Harness Engineering은 이 아이디어를 AI 에이전트 영역에 적용한 것입니다.

| 관점 | Platform Engineering | Harness Engineering | |---|---|---| | 대상 | 개발자 팀 | AI 에이전트 | | 핵심 산출물 | 내부 개발자 플랫폼(IDP) | 에이전트 실행 하네스 | | 거버넌스 방식 | 정책(Policy), RBAC, 감사 로그 | 제약, 가드레일, 검증 레이어 | | 자율성 조절 | 셀프서비스 + 가이드레일 | 에이전트 자율성 + 안전망 |

실습: 현재 시스템 진단

이론을 내 시스템에 적용해봅시다. 현재 운영 중이거나 계획 중인 에이전트 시스템을 떠올리며 아래 질문에 답해보세요.

Prompt Engineering 측면

[ ] 에이전트의 시스템 프롬프트가 명확한 역할과 제약을 포함하는가?
[ ] Few-shot 예시가 실제 실패 케이스를 반영하는가?

Context Engineering 측면

[ ] 컨텍스트 윈도우가 가득 찼을 때 어떻게 처리하는가?
[ ] 에이전트가 장기 실행될 때 이전 대화를 어떻게 요약하는가?

Agent Engineering 측면

[ ] 에이전트의 루프 종료 조건이 명확하게 정의되어 있는가?
[ ] 도구 호출 실패 시 재시도 로직이 있는가?

Harness Engineering 측면

[ ] 에이전트 출력이 스키마 검증을 거치는가?
[ ] 코드 실행이 격리된 환경(샌드박스)에서 이루어지는가?
[ ] 에이전트 실행 이력이 기록되고 검토 가능한가?
[ ] 비용이나 실행 시간에 상한선이 설정되어 있는가?
[ ] 에이전트가 예상치 못한 행동을 했을 때 알림이 오는가?
[ ] 실패한 실행을 재현하고 디버깅할 수 있는가?

체크리스트를 채우는 데 정답은 없습니다. 중요한 것은 현재 시스템의 어느 레이어가 취약한지 인식하는 것입니다. Prompt Engineering만 잘 되어 있고 Harness가 없는 시스템은 개발 환경에서는 잘 작동하지만 프로덕션에서 쉽게 무너집니다.

요약

Harness Engineering은 기존 개념들을 대체하지 않습니다. Prompt, Context, Agent Engineering의 성과물을 시스템 수준에서 통합하고 안전하게 운영하는 더 상위 개념입니다.

각 개념의 역할을 한 문장으로 정리하면:

Prompt Engineering: 모델에게 올바른 질문을 던진다
Context Engineering: 모델에게 올바른 정보를 제공한다
Agent Engineering: 모델이 올바른 방식으로 행동하도록 설계한다
Harness Engineering: 이 모든 것이 올바르게 작동하는 환경을 만든다

이 과정에서 배우는 모든 내용은 결국 하나의 질문으로 수렴합니다: “에이전트가 올바르게 작동하도록 환경을 어떻게 설계할 것인가?”

다음 챕터부터는 이 질문에 답하는 구체적인 구성 요소들을 하나씩 살펴봅니다.