하네스 엔지니어링 — 에이전트는 쉽다, 하네스가 어렵다

88%가 프로덕션에 닿지 못하는 이유

2026년, AI 에이전트 프로젝트의 88%가 프로덕션에 도달하지 못한다는 현실은 모델 성능 부족 때문이 아니다. SWE-bench Verified에서 최전선 코딩 모델이 60%를 넘어선 지금, 병목은 모델 바깥에 있다. Martin Fowler와 Thoughtworks가 정의한 공식 "Agent = Model + Harness"가 2026년 AI 실무의 핵심으로 자리잡은 이유가 바로 여기에 있다. 하네스 엔지니어링은 모델이 아닌 모델을 둘러싼 모든 것을 설계하는 새로운 AI 실무 패러다임이다.

거듭 바뀐 핵심 질문

프롬프트 엔지니어링이 "무슨 말을 할까?"를 물었고, 컨텍스트 엔지니어링이 "어떤 정보를 제공할까?"를 물었다면, 하네스 엔지니어링은 "어떤 시스템을 구축할까?"를 묻는다. 이 세 단계는 AI 엔지니어링의 추상화 수준이 한 단계씩 높아진 진화 과정이다.

2022년 ChatGPT 출시 이후 엔지니어들은 단일 지시문의 예술을 탐구했다. 퓨샷 러닝, 체인-오브-소트 프롬프팅, 역할 기반 프롬프트 등 기법이 쏟아졌다. 목표는 단 한 번의 완벽한 입력으로 최선의 출력을 이끌어내는 것이었다. 단일 요청-응답 사이클에 최적화된 이 접근법은 멀티스텝 에이전트 환경에서 한계를 드러냈다. 2025년 중반, Andrej Karpathy와 Shopify CEO Tobi Lütke가 "컨텍스트 엔지니어링"이라는 개념을 공개적으로 지지하면서 패러다임이 이동했다 — 단일 프롬프트만으로는 부족하다는 인식이 확산됐고, 모델이 합리적인 결정을 내리려면 관련 문서, 대화 이력, 툴 정의, RAG 결과로 동적으로 구성된 컨텍스트 윈도우가 필요했다.

하네스 엔지니어링은 앞선 두 단계를 포함하되 더 높은 추상화 수준에서 작동한다. 프롬프트와 컨텍스트는 하네스의 구성 요소일 뿐이다. 핵심 명제는 "에이전트는 어렵지 않다. 하네스가 어렵다(Agents aren't hard; the Harness is hard)"로 요약된다. 에이전트의 솔루션 공간을 규칙, 피드백 루프, 검증기로 제약하면 역설적으로 생산성과 신뢰성이 높아진다는 사실이 OpenAI와 Anthropic의 현장 검증을 통해 확인됐다.

⤢✕

에이전트에서 모델을 뺀 나머지 전부

Martin Fowler와 Thoughtworks 엔지니어 Birgitta Böckeler가 2026년 4월 martinfowler.com에 발표한 글에서 하네스는 AI 에이전트에서 모델을 제외한 모든 것으로 정의된다. 구체적으로는 시스템 프롬프트와 AGENTS.md 파일, 제약 문서와 가이드라인, 실행 환경과 샌드박스, 에이전트가 사용하는 툴과 API, 출력 검증 루프와 에발(evals), 오케스트레이션 로직, 관찰 계층과 감사 로그를 포함한다.

모델은 에이전트의 잠재력 상한선을 정의하지만, 하네스는 그 잠재력이 실제로 얼마나 실현되는지를 결정한다. 동일한 모델에서 하네스를 바꾸는 것만으로 에이전트의 성능을 평균 수준에서 최상위로 끌어올릴 수 있다는 점이 2026년 현장 사례를 통해 반복적으로 확인됐다.

LangChain이 2026년 초 공식화한 하네스 해부학은 두 가지 제어 유형을 구분한다. Guides(가이드)는 전방향(feedforward) 제어다 — 에이전트가 행동하기 전에 방향을 제약하고 지시한다. 시스템 프롬프트, AGENTS.md 파일, 제약 문서가 모두 가이드이며, 에이전트에게 무엇을 해야 하는지, 작업 범위는 어디까지인지, "완료"가 어떤 상태인지를 알려준다. Sensors(센서)는 피드백(feedback) 제어다 — 에이전트가 행동한 후 동작을 관찰하고 검증한다. 에발, 검증 루프, 출력 파서가 센서에 해당하며, 에이전트가 실제로 올바른 일을 하고 있는지 측정하고 이탈 시 수정 신호를 보낸다.

하네스를 이루는 구성요소

태스크 스코핑은 에이전트에게 무엇을 해야 하는지, 얼마나 해야 하는지, 무엇을 하지 말아야 하는지를 명확히 정의하는 구조화된 스펙이다. 스코프가 불명확한 에이전트는 컨텍스트 확장과 비용 폭증의 주원인이 된다. 효과적인 태스크 스코핑은 결과물의 구체적 정의인 목표 명세, 수정 가능한 파일·호출 가능한 서비스·변경 불가 영역을 명시하는 범위 경계, 성공 상태를 검증 가능한 형태로 기술하는 완료 기준(Definition of Done), 어떤 상황에서 인간 검토를 요청해야 하는지 규정하는 에스컬레이션 조건, 최대 이터레이션 수·토큰 예산·실행 시간 한도를 정하는 시간·비용 제약을 요소로 갖는다.

샌드박스 런타임은 에이전트가 실수하더라도 프로덕션 환경에 영향을 주지 않는 격리된 실행 공간이다. 2026년 OpenAI Codex의 샌드박스 에이전트는 파일시스템, Git 저장소, 스냅샷에 접근하는 영속적 격리 작업공간 안에서 동작하며, 이를 통해 에이전트는 중단 후 재개(checkpoint-resume)가 가능하다. 설계의 핵심 원칙은 태스크 완수에 필요한 최소한의 권한만 부여하는 최소 권한 원칙, 불필요한 외부 통신을 차단하는 네트워크 격리, 보호 대상 데이터를 읽기 전용으로만 접근하도록 하는 읽기 전용 마운트, 오작동 시 이전 상태로 즉시 복원하는 스냅샷 복원이다.

프로덕션 팀이 2026년 현장에서 강하게 권장하는 패턴은 명시적 인간 검토 체크포인트를 가진 단일하고 명확하게 스코핑된 에이전트다. 복잡한 멀티에이전트 파이프라인보다 리뷰 게이트가 내장된 단순한 구조가 신뢰성 측면에서 우월하다는 사실이 반복적으로 확인됐다. 리뷰 게이트는 Plan-Execute-Verify 루프로 형식화된다 — Plan 단계에서 에이전트가 실행 계획을 제안하면 인간이 승인 또는 수정하고, Execute 단계에서는 승인된 범위 내에서만 에이전트가 자율 실행하며, Verify 단계에서는 실행 결과를 자동 에발과 인간 검토가 함께 검증한다.

체크포인트는 에이전트 실행을 안전하게 일시 중지하고 재개할 수 있게 하는 상태 저장 메커니즘이다. 장시간 실행되는 에이전트 태스크에서 체크포인트가 없으면 실패 시 처음부터 다시 시작해야 하는 비용이 발생한다. 핵심 요소는 에이전트의 현재 실행 상태를 저장 가능한 형태로 직렬화하는 상태 직렬화, 동일 체크포인트에서 재실행해도 동일한 결과를 보장하는 멱등성 설계, 검토 게이트 실패 시 안전하게 되돌릴 수 있는 롤백 포인트, 태스크 일부가 완료된 상태에서 재개 시 중복 실행을 방지하는 부분 완료 처리다.

⤢✕

격리·승인·복구·감사로 안전을 설계한다

에이전트 격리는 단순히 컨테이너 수준을 넘어선다. 2026년 하네스 엔지니어링의 격리는 네 차원에서 이뤄진다. 컴퓨팅 격리는 에이전트를 호스트 시스템과 분리된 가상화 환경에서 실행해, 에이전트의 실수나 악의적 코드 실행이 호스트에 영향을 미치지 않게 한다. 네트워크 격리는 에이전트가 접근 가능한 엔드포인트를 화이트리스트로 제한해 인가되지 않은 외부 서비스로의 데이터 전송을 원천 차단한다. 데이터 격리는 민감한 데이터를 에이전트가 직접 접근하지 못하도록 레퍼런스 토큰이나 가상화된 뷰를 통해서만 제공한다. 시간적 격리는 에이전트의 실행 시간을 제한하고 한도 초과 시 자동으로 중단해 리소스 남용을 방지한다.

사람 승인 게이트(Human Approval Gate)는 특정 임계값을 초과하는 작업에 대해 자동으로 인간 검토를 요청하는 메커니즘이다 — 변경 파일 수가 N개를 초과할 때, 외부 서비스에 쓰기 작업을 수행하기 전, 불가역적 작업(데이터 삭제, 배포 등) 실행 전, 에발 점수가 기준치 이하로 떨어질 때, 에이전트가 불확실성을 감지했을 때가 대표적 임계값이다.

하네스는 에이전트의 실패를 예외가 아닌 정상 상태로 간주하고 설계한다. 재시도 로직(지수 백오프), 대안 경로(fallback tools), 부분 완료 상태 보존, 인간 에스컬레이션이 주요 복구 전략이며, 특히 에이전트가 자신의 오류를 인식하고 스스로 복구를 시도하는 자기수정 루프(self-correction loop)가 2026년 고급 하네스 설계의 핵심 요소로 자리잡았다.

모든 에이전트 실행은 완전히 추적 가능해야 한다. 감사 추적의 필수 요소는 에이전트가 수행한 모든 툴 호출과 결과를 순서대로 기록하는 실행 로그, 에이전트가 특정 행동을 선택한 이유를 기록하는 의사결정 추적(체인-오브-소트 저장), 에이전트가 수정한 파일·생성한 리소스의 before/after 스냅샷을 담는 변경 이력, 토큰 사용량·API 호출 횟수·실행 시간을 태스크별로 집계하는 비용 추적이다.

OpenAI와 Stripe가 증명한 제약의 역설

OpenAI의 코드베이스 자동화 사례에서는, 2026년 초 OpenAI가 "수동 코드 금지" 제약을 핵심 가이드로 둔 하네스 아래에서 Codex 에이전트를 운용해 100만 줄 이상의 코드를 인간 작성 없이 출시했다. 이 제약이 역설적으로 견고한 하네스 개발을 강제했고, 결과적으로 엔지니어링 속도가 수십 배 향상됐다고 보고됐다. Stripe의 AI PR 자동화 사례에서는, Stripe가 2026년 기준 주당 1,300개 이상의 AI 생성 풀리퀘스트를 처리한다. 이를 가능하게 한 핵심은 PR 생성 전 자동 에발, 코드 리뷰 게이트, 회귀 테스트 샌드박스로 구성된 하네스였다 — 에이전트가 단순히 코드를 생성하는 것이 아니라 하네스가 생성된 코드의 품질을 실시간으로 검증하고 피드백을 제공한다.

이 두 사례는 공통적으로 하네스의 제약이 에이전트의 능력을 제한하는 것이 아니라 오히려 확장한다는 점을 보여준다. 2026년 현장 데이터에 따르면 체계적인 하네스를 갖춘 팀은 에이전틱 워크플로우에서 2~5배의 신뢰성 향상을 경험했다.

⤢✕

하네스 성숙도는 다섯 단계로 구분할 수 있다. 하네스 없이 모델을 직접 호출하는 수동 프롬프팅, 시스템 프롬프트와 몇 가지 툴을 갖췄지만 검증 루프가 없는 기본 에이전트, 에발과 기본 피드백 메커니즘이 도입된 검증 루프 포함 에이전트, 태스크 스코핑·샌드박스·리뷰 게이트·체크포인트·감사 추적이 모두 갖춰진 프로덕션 수준의 완전한 하네스, 여러 에이전트가 협력하는 구조에서도 안전성을 유지하는 최고 수준의 멀티에이전트 오케스트레이션 순으로 성숙도가 올라간다.

하네스 엔지니어링은 프롬프트와 컨텍스트를 포함하는 더 넓은 시스템 설계 사고로의 전환을 의미한다. 모델의 성능이 평준화되는 2026년, 에이전트를 프로덕션에서 작동하게 만드는 진짜 역량은 하네스를 얼마나 잘 설계하느냐에 달려 있다. 태스크 스코핑, 샌드박스 런타임, 리뷰 게이트, 체크포인트 아키텍처라는 네 축을 중심으로 안전하고 신뢰할 수 있는 에이전트 시스템을 구축하는 것이 AI 엔지니어의 핵심 역량이 됐다. 하네스가 없는 에이전트는 잠재력만 있고 신뢰성이 없는 시스템이며, 하네스가 있는 에이전트는 그 잠재력을 실제 프로덕션 가치로 전환하는 시스템이다.