Anthropic의 내부 문서, LangChain 엔지니어링 팀의 분석, 마이크로소프트의 에이전트 프레임워크, 학술 논문, 그리고 프로덕션 에이전트를 배포하는 현장 실무자들에 이르기까지, AI 하네스(Harness) 아키텍처에 관한 12편의 심층 분석 자료를 종합 검토했다. 이 모든 자료가 수렴하는 하나의 불편한 명제가 있다. 바로 **“모델은 범용화(commoditized)되었다. 이제 하네스가 곧 제품이다”**라는 사실이다.

이는 탁상공론이 아니다. LangChain은 모델 재학습 없이 오직 하네스만을 최적화하여 Terminal Bench 2.0 순위를 30위에서 상위 5위로 끌어올렸다. 동일한 모델로 14점의 성능 향상을 이뤄낸 것이다. Claude Sonnet 4.5는 오케스트레이션 스캐폴드(scaffold)를 바꾸는 것만으로 GAIA 벤치마크 점수가 44.6%에서 74.6%로 수직 상승했다. 무려 30점의 격차다. 오직 오케스트레이션만으로 말이다.

만약 아직도 “어떤 모델을 쓸 것인가”에만 매달려 있다면, 당신은 완전히 엉뚱한 계층을 최적화하고 있는 것이다.

공식: 에이전트 = 모델 + 하네스

2026년 초에 완전히 정립된 공식이다. Mitchell Hashimoto는 지난 2월 이를 이렇게 표현했다. “에이전트가 실수를 저지를 때마다, 당신은 그 에이전트가 두 번 다시 같은 실수를 반복하지 않도록 엔지니어링 솔루션을 구축하는 데 시간을 쏟아야 한다.” LangChain의 Viv Trivedy가 이를 공식화했고, 4월에 이르러 구글, Anthropic, Thoughtworks 모두가 자체 하네스 아키텍처를 발표했다.

모델은 상태가 없는(stateless) 다음 토큰 예측기에 불과하다. 모델 스스로는 코드를 실행할 수도, 어제의 일을 기억할 수도, API를 호출할 수도, 정책을 강제할 수도 없다. 하네스는 그 외의 모든 것—즉 CPU를 둘러싼 운영체제(OS)—를 의미한다.

Meng 등의 학술 서베이 논문은 이를 수식으로 정의했다: H = (E, T, C, S, L, V). 실행 루프(Execution loop), 도구 레지스트리(Tool registry), 컨텍스트 관리자(Context manager), 상태 저장소(State store), 수명 주기 훅(Lifecycle hooks), 평가 인터페이스(Evaluation interface)의 조합이다. 실제 프로덕션 환경에서 하네스는 8개에서 12개의 핵심 하중 지탱 컴포넌트로 확장된다. 그중 진짜 중요한 요소들을 짚어본다.

실질적인 하중을 견디는 핵심 컴포넌트들

교과서적인 분류는 건너뛰고, 데모에서는 그럴듯하지만 프로덕션에서 무너지는 에이전트와 실제로 작동하는 에이전트를 가르는 핵심 부품들에 집중하겠다.

실행 루프 (The Execution Loop)

모든 하네스는 while 루프를 가지고 있다. 관찰(Observe) → 사고(Think) → 행동(Act) → 반복(Repeat). 전형적인 ReAct 패턴이다. 장난감 루프와 프로덕션 루프를 가르는 차이는 그 순환 고리를 무엇이 감싸고 있는가에 있다. 스트리밍 도구 호출, 병렬 실행, 지수 백오프(exponential backoff), 토큰 예산 관리, 그리고 결정적으로 모델이 “다 끝났다”고 말하는 것에 의존하지 않는 종료 조건이다. 모델은 작업 완료 여부를 환각한다. 일이 실제로 끝났는지를 결정하는 것은 오직 하네스의 몫이어야 한다.

Anthropic의 장기 실행 에이전트 패턴은 연구해 볼 가치가 충분하다. 초기화 에이전트가 기능 목록을 생성한다. 그리고 코딩 에이전트가 루프를 돌린다: 완료되지 않은 다음 작업을 선택하고, 커밋하고, 진행 파일(progress file)을 갱신하고, 종료한다. 이때 추적 파일은 Markdown이 아닌 JSON을 사용한다. 모델이 Markdown은 은근슬쩍 수정해 버리지만, JSON은 함부로 고쳐 써서는 안 되는 구조화된 데이터로 취급하기 때문이다. 이런 디테일이 바로 하네스 엔지니어링이다.

도구 계층 (The Tool Layer)

도구는 에이전트의 손이다. 모든 도구는 이름, 매개변수, 예상 출력, 권한 수준을 정의한 JSON Schema를 가진다. 모델이 구조화된 호출을 생성하면, 하네스가 이를 검증하고 실행한 뒤 결과를 반환한다. “무엇을 호출할지 결정하는 모델”과 “이를 허용할지 결정하는 하네스” 사이의 명확한 분리가 안전성의 근간이다.

MCP(Model Context Protocol)는 이제 업계 표준 인터페이스가 되었다. JSON-RPC 기반의 타입화된 데이터 교환 규격이자 플러그인 도구 서버다. 2024년 11월 Anthropic이 처음 발표했고, 2025년 12월 구글의 A2A 프로토콜과 함께 리눅스 재단의 Agentic AI Foundation에 기증되었다. MCP는 에이전트가 도구와 소통하는 방식을 정의하고, A2A는 에이전트들이 서로 소통하는 방식을 정의한다. 이 둘이 합쳐져 프로덕션의 상호 운용성 계층을 이룬다.

아무도 말하지 않는 중요한 설계 결정이 있다: ’고정된 도구 레지스트리’를 쓸 것인가, 아니면 ’범용 bash 실행 권한’을 줄 것인가이다. 고정 레지스트리는 감사 추적이 가능하고 예측 가능하다. 반면 bash는 모델이 즉석에서 자신만의 도구를 직접 작성할 수 있게 해준다. 자유로운 코딩 작업에서는 bash가 압승이다. 그러나 규제 환경에서는 고정 레지스트리만이 유일하게 방어 가능한 선택지다. 이는 규제 준수(compliance)와 직결되는 트레이드오프이므로 아키텍처 리뷰 시 반드시 명시적으로 다루어야 한다.

컨텍스트 관리 (Context Management)

대부분의 에이전트가 죽음을 맞이하는 곳이다.

컨텍스트 부패(Context rot)는 측정 가능한 수치다. 윈도우 안에 검색된 문서가 20개만 들어가도 위치 편향 때문에 정확도가 7075%에서 5560%로 떨어진다. 100만 토큰 윈도우를 가진 모델이라 해도 다단계(multi-hop) 추론 작업에서는 10만 토큰을 넘어가면 성능이 심각하게 저하된다. 해결책은 윈도우를 키우는 것이 아니라 무자비하게 큐레이션하는 것이다.

프로덕션에서 검증된 기법들:

압축(Compaction): 이전 대화를 무작정 잘라내는 대신 요약한다. 결정 사항과 미해결 질문은 보존하고, 중복된 도구 출력은 버린다.

관찰 마스킹(Observation masking): 오래된 도구 출력 결과는 컨텍스트에서 숨기되, 도구를 호출했다는 기록 자체는 유지한다. JetBrains의 Junie가 이 방식을 사용한다.

적시 검색(Just-in-time retrieval): 파일 포인터만 저장해 두고 필요할 때만 내용을 가져온다. Claude Code는 파일 전체를 읽어 들이는 대신 grep/head를 활용해 특정 코드 세그먼트만 뽑아낸다.

점진적 도구 공개(Progressive tool disclosure): 시작할 때 수백 개의 도구 스키마를 한 번에 주입하면 모델의 추론 능력이 저하된다. 에이전트가 관련 하위 작업을 목표로 삼을 때만 해당 도구 설명을 로드해야 한다.

서브 에이전트 위임: 원시 분석 내용을 부모 에이전트의 컨텍스트에 쏟아붓는 대신, 전문 에이전트에 세부 작업을 맡기고 1~2K 토큰 수준의 요약본만 반환받는다.

모두를 긴장시켜야 할 데이터가 있다. 모델을 교체하거나 파인튜닝하지 않고 오직 하네스의 포맷만 변경했을 뿐인데, 15개 LLM의 벤치마크 점수가 5~14점 향상되었고 토큰 사용량은 20% 절감되었다. 컨텍스트 엔지니어링은 AI 시스템 설계에서 가장 레버리지가 높은 활동이다.

메모리 (Memory)

LLM은 상태가 없다. 모든 추론은 매번 백지에서 시작한다. 하네스는 세 가지 시간 축에서 영속성을 제공한다:

작업 메모리(Working memory): 현재 대화에 국한되며, 컨텍스트 내에 상주하고, 세션이 끝나면 사라진다.

에피소딕 메모리(Episodic memory): 이전 상호작용 및 중간 결과물이며, Redis나 SQLite에 저장되고 몇 시간에서 며칠간 유지된다.

시맨틱 메모리(Semantic memory): 사실적 지식, 사용자 선호도, 성공적인 패턴이며, 벡터 데이터베이스에 영구적으로 보관된다.

새롭게 등장하는 아키텍처들은 흥미롭다. MAGMA(다중 그래프 에이전트 메모리 아키텍처)는 의미론, 시간, 인과관계, 엔티티라는 4개의 직교 그래프에 메모리를 분산 표현하여 장기 추론에서 MemGPT 대비 18.5% 뛰어난 성능을 보였다. Knowledge Objects는 해시 주소 지정이 가능한 이산적 사실 튜플을 사용하여 컨텍스트 저장 대비 252배 저렴한 비용으로 100%의 정확도를 달성했다.

좋은 메모리와 나쁜 메모리를 가르는 설계 원칙은 단순하다. 에이전트는 기억을 ’절대적 진실’이 아니라 ’참고용 힌트’로 취급해야 한다. 행동하기 전에 회상된 기억을 실제 시스템의 현재 상태와 반드시 대조 검증해야 한다. 오염된 기억은 기억이 아예 없는 것보다 훨씬 위험하다.

수명 주기 훅 (Lifecycle Hooks)

프롬프트 수준의 제안을 강제 집행 가능한 보장으로 바꾸어주는 장치다. PreToolUse, PostToolUse, PreCommit, OnPermissionRequest 등 모델이 무엇을 하려 하든 상관없이 결정론적 코드가 강제로 실행되는 가로채기(interception) 지점들이다.

“절대로 rm -rf /를 실행하지 마라”는 규칙은 모델이 무시할 수도 있는 시스템 프롬프트가 아니라, 코드로 작성되어 강제되어야 한다.

Birgitta Böckeler의 프레임워크가 가장 명쾌하다. 배포되는 모든 하네스는 내부 하네스(모델 개발사가 제공하는 SDK, Cursor 등)와 외부 하네스(사용자가 직접 조립하는 AGENTS.md, MCP 서버, 스킬 등)를 가진다. 그리고 모든 컴포넌트는 행동 전에 조향하는 ’가이드(guide)’이거나, 행동 후에 감지하는 ‘센서(sensor)’ 중 하나다. 대다수 하네스는 가이드에만 치중하고 센서가 부실하다. 바로 그 지점에서 실패가 발생한다.

검증과 평가 (Verification & Evaluation)

모델은 자신이 일을 끝마쳤다고 말할 것이다. 그리고 그 말은 틀렸을 가능성이 높다. 외부 검증만이 유일하게 신뢰할 수 있는 확인 수단이다.

연산 기반 센서: 린터(linter), 테스트 스위트, 스키마 검증기. 빠르고, 결정론적이며, 모호함이 없다. 추론 기반 센서: LLM 심사위원을 통한 평가, 관련성 점수 측정. 강력하지만 편향되어 있다. 2026년 연구에 따르면 LLM 심사위원은 67~82%의 자사 모델 편향을 보인다.

핵심 패턴은 ’교정 사이클’이다. 테스트가 실패하면 하네스는 에러 로그를 묶어 에이전트의 컨텍스트로 다시 주입하여 스스로 교정하게 만든다. 외부 어서션(assertion)이 통과 신호를 보내기 전까지 에이전트는 결코 작업을 완료로 표시할 수 없다.

그리고 최전선에는 자체 개선 하네스가 있다. 자신의 실패 트레이스를 분석하고, 하네스 수정안을 제안하며, 회귀 테스트를 통해 이를 검증한다. HarnessX는 강화학습을 통해 하네스 자체를 최적화함으로써 수작업으로 구축된 정적 하네스 대비 14.5%의 성능 향상을 입증했다.

반드시 알아야 할 실패 모드

기억해야 할 두 가지 대표 패턴이 있다.

컨텍스트 부패(Context rot): 작업 컨텍스트에 낡고 모순되며 무의미한 정보가 서서히 쌓여간다. 10단계쯤 지나면 에이전트는 스스로의 발목을 잡기 시작한다. 해결책: 의도적인 프루닝(가지치기), 명시적인 상태 핸드오프, 주기적인 컨텍스트 리셋.

둠 루프(Doom loops): 에이전트가 접근 방식을 바꾸지 않은 채 실패한 동작을 끝없이 반복하는 현상이다. 해결책: 엄격한 재시도 횟수 제한. 일시적 에러는 단 한 번만 재시도하고, 그래도 안 되면 즉시 실패를 밖으로 드러내야 한다.

복리 계산의 현실은 가혹하다. 각 단계의 신뢰도가 99%인 10단계 작업의 최종 신뢰도는 90.4%다. 단계별 신뢰도가 95%라면 전체 성공률은 60%로 떨어지고, 90%라면 35%로 폭락한다. 이것이 가이드보다 센서가 더 중요한 이유다. 오류를 미리 방지하려는 시스템보다 오류를 정확히 감지하고 교정하는 시스템이 우수하다. 예방은 소리 없이 무너지지만 감지는 검증 가능하기 때문이다.

성숙도 모델 (The Maturity Model)

레벨 0: 단순 챗봇 (하네스 없음)
레벨 1: 시스템 프롬프트만 사용
레벨 2: 구조화된 도구 사용
레벨 3: 세션 간 메모리 유지
레벨 4: 작업 분해 및 계획 수립
레벨 5: 자동화된 검증 체계
레벨 6: 다중 에이전트 조율
레벨 7: 자체 개선 하네스

대부분의 프로덕션 시스템은 레벨 3~4에 머물러 있다. 레벨 6 이상에 도달한 곳은 극소수이며, 레벨 7은 거의 전무하다. 대다수 팀이 위치한 곳과 기술적 최전선 사이의 이 거대한 간극이 바로 2026년의 가장 큰 엔지니어링 기회다.

구속력 있는 제약 조건 (The Binding Constraint)

OpenAI의 Codex 팀은 3~7명의 엔지니어가 5개월간 약 100만 줄의 하네스 코드를 작성했다. 초기에 진척이 느렸던 이유는 모델의 능력이 부족해서가 아니라 환경이 불충분하게 명시되었기 때문이었다.

이것이 핵심 통찰이다. 제약 요인은 모델의 지능이 아니다. 환경에 대한 엄밀한 명세다.

이를 다루는 학문이자 실무인 ’하네스 엔지니어링’은 이제 프롬프트 엔지니어링이나 단순 모델 선택과는 완전히 구별되는 독자적인 영역으로 자리 잡았다. 자체적인 이름, 콘퍼런스, 채용 공고가 생겨났다. 중국 베이징 정부의 2026년 AI 정책 문서에는 하네스 엔지니어링이 핵심 지원 분야로 공식 명시되기까지 했다.

만약 AI 시스템을 구축하면서 여전히 대부분의 시간을 모델 비교와 프롬프트 튜닝에 쏟고 있다면, 당신은 점차 수렴하고 있는 10%의 영역에 매달리며 폭발적으로 갈라지고 있는 90%의 영역을 방치하고 있는 것이다. 진짜 일이 일어나는 곳은 하네스다. 이제 하네스가 곧 제품이다.

컴포넌트별 상세 분석, 아키텍처 다이어그램, 참고 문헌이 포함된 전체 연구 보고서는 동반 연구 문서에서 확인할 수 있습니다.