랭체인(LangChain)은 단일 코딩 모델을 대상으로 모델 자체는 전혀 손대지 않고 주변의 스캐폴딩(scaffolding)만을 바꿨습니다. 그 결과 Terminal Bench 2.0 점수가 약 30위 수준이었던 52.8%에서 순식간에 톱 5위권으로 껑충 뛰어올랐습니다. 모델 가중치(weights)는 완전히 동일했습니다. 유일하게 바뀐 변수는 바로 ’하네스(harness)’였습니다.

구글의 아디 오스마니(Addy Osmani) 역시 다른 각도에서 동일한 결과를 보고했습니다. 하네스 설계만으로도 동일한 모델에서 최대 6배의 성능 차이가 발생한다는 것입니다. 모델도, 프롬프트도 아니었습니다. 바로 하네스였습니다.

이것이 바로 2026년 AI 엔지니어링에서 일어난 가장 중요한 패러다임 전환입니다. 불과 1년 전만 해도 업계에서는 어떤 모델을 써야 할지를 논쟁했습니다. 하지만 오늘날 레버리지의 중심은 스택의 더 위쪽으로 이동했습니다. 모델은 가공되지 않은 지능(raw intelligence)을 제공할 뿐입니다. 반면 하네스는 그 지능을 신뢰할 수 있는 실질적 작업으로 전환하는 루프, 도구, 메모리, 검증 메커니즘, 그리고 가드레일을 제공합니다. 프론티어 모델들은 점점 더 범용화(commoditized)되고 있습니다. 지속 가능한 경쟁 우위(durable advantage)는 바로 하네스에 존재합니다.

코딩이든, 품질 시스템이든, 규제 대상 워크플로든, 그 어떤 목적으로든 에이전트를 구축하고 있다면 엔지니어링의 모든 역량을 집중해야 할 곳은 바로 하네스입니다.

하네스의 본질 (What a harness actually is)

간단히 정리하면 다음과 같습니다:

에이전트(Agent) = 모델(Model) + 하네스(Harness)

모델은 다음 토큰을 예측하는 기계(next-token predictor)입니다. 상태를 저장하지 않는 스테이트리스(stateless) 구조이며, 텍스트만을 생성하고, 외부 세계에 직접 접근할 수 없으며, 호출 간 정보를 유지하거나 자체 출력을 스스로 검증할 수도 없습니다. 하네스는 이러한 모든 결손을 메워줍니다.

에이전트 하네스는 하나 이상의 언어 모델을 감싸 외부 환경에 실질적인 행동을 취할 수 있는 에이전트로 탈바꿈시키는 런타임 엔지니어링 계층입니다. 즉, 모델을 제외한 시스템의 모든 요소가 곧 하네스입니다.

이 용어는 오랜 은유를 담고 있습니다. 고대 프랑스어 harneis는 장비, 갑옷, 그리고 짐말을 마차에 연결하는 마구(馬具)를 의미했습니다. 한편에는 방향성 없는 힘이 있고, 다른 한편에는 그 힘을 안전하게 전달하고 이끄는 인프라가 존재합니다. 소프트웨어 공학에서는 이를 차용하여 테스트 하네스(test harness)라 불렀고, 머신러닝에서는 평가 하네스(evaluation harness)로 확장했습니다. 에이전트 하네스는 이 이름을 계승하면서 제어의 시간적 범위를 획기적으로 넓혔습니다. 사후에 결과를 관찰하기만 하는 평가 하네스와 달리, 에이전트 하네스는 실행이 진행되는 바로 그 순간에 실행을 제어하고, 제한하며, 검증하고, 교정합니다.

4가지 필수 조건 (The four necessary conditions)

2026년 6월 발표된 한 논문은 포함 및 배제 테스트를 바탕으로 한 구조적 정의를 제안했습니다. 어떤 시스템이 하네스로 인정받으려면 다음 4가지 조건을 ‘모두’ 충족해야 합니다:

조건 필수 요구사항 테스트 탈락 기준
에이전트 루프 (Agent loop) 런타임에 추론, 행동, 관찰을 교차 실행 단일 패스 생성기 (Single-pass generator)
도구 인터페이스 (Tool interface) 모델이 외부 환경을 변경할 수 있도록 지원 (파일 편집, 명령어 실행 등) 변경 권한 없는 단순 읽기
컨텍스트 관리 (Context management) 컨텍스트에 진입하고 퇴장하는 정보를 작업 인식 기반으로 능동적 선택 단순 크기 기준의 기계적 절삭(truncation)
제어 메커니즘 (Control mechanisms) 모델의 협조에 의존하지 않는 최소 하나 이상의 검증, 제한 또는 결정론적 조치 단순 로깅에 불과한 경우

4가지 모두 필수 조건(necessary)이며, 4가지가 모두 모였을 때 비로소 충분 조건(sufficient)이 됩니다. 메모리, 검증, 관측 가능성(observability), 가드레일은 별도의 추가 조건이 아니라 이 4가지 조건의 특화된 파생 요소들입니다.

테스트 스위트를 재실행하고 해당 스위트가 통과했을 때만 성공을 선언하는 최소한의 루프조차도 이미 초기 형태의 하네스 요건을 충족합니다. 기준 자체는 이토록 명확합니다. 그럼에도 시중에 나와 있는 대부분의 “에이전트 프레임워크”는 이 기본 기준조차 만족하지 못하고 있습니다.

하네스의 아키텍처 해부 (The anatomy)

프로덕션 하네스는 모델을 엔진으로 삼아 다음과 같은 반복적인 아키텍처로 수렴하고 있습니다:

                    User

                      │

              Task Manager

                      │

            Context Builder

                      │

                Planner

                      │

               Agent Loop

                      │

        ┌─────────────┴─────────────┐

     Tool Router              Memory

        │                         │

Terminal   Git   Browser   RAG   Vector DB

        │                         │

        └─────────────┬─────────────┘

                 Verification

                      │

                 Safety Layer

                      │

              Human Approval

                      │

                 Final Answer

핵심 루프 자체는 간단합니다:

while not done:
    build_context()
    ask_model()
    if tool_requested:
        execute_tool()
        validate()
        update_memory()
    else:
        return_answer()

겉보기에는 지극히 단순해 보이는 루프이지만, 실제 프로덕션 환경에서는 수천 줄에 달하는 견고한 코드로 구현됩니다.

컨텍스트 빌더 (Context builder)

가장 방대한 핵심 컴포넌트입니다. 모든 정보를 프롬프트에 무작정 쏟아붓는 대신, “모델이 지금 이 순간 무엇을 보아야 하는가?“를 지능적으로 결정합니다.

현재 수행 중인 작업, 관련 SOP, 진행 중인 CAPA, 최근 발생한 일탈, 사내 규정, 현재 Git 브랜치, 사용자 선호도, 미해결 티켓, 사용 가능한 도구, 메모리, 최근 실패 이력 등이 이에 해당합니다. 회사 전체의 데이터를 몽땅 넣는 것이 아닙니다.

컨텍스트 엔지니어링(Context engineering)은 하네스 엔지니어링 내에서 독자적인 전문 분야로 부상했습니다. 앤트로픽(Anthropic)은 컨텍스트를 유한한 자원으로 규정합니다. 최근 실무에서는 파일시스템 기반의 컨텍스트 관리를 선호하는 추세입니다. 방대한 출력 결과는 파일(research.md, app.py, 계획 파일 등)에 기록해 두고 필요할 때만 다시 읽어 들임으로써 컨텍스트 오염을 방지합니다. 마이크로소프트의 Azure SRE Agent는 100개 이상의 맞춤형 도구를 일일이 제공하던 방식에서 벗어나 소스 코드, 런북, 쿼리 스키마를 파일 형태로 노출하고 read_file, grep, find, 쉘(shell) 도구만 제공하는 방식으로 전환했습니다. 그 결과 새로운 인시던트에 대한 의도 충족(intent-met) 점수가 45%에서 75%로 대폭 상승했습니다.

도구 관리 (Tool management)

LLM은 결코 명령어를 직접 실행하지 않습니다. 모델은 단지 도구 사용을 “요청”할 뿐입니다. 하네스가 이 요청의 유효성을 검증하고, 도구를 실행하며, 출력을 캡처하여 모델에게 다시 반환합니다. 이 구조를 통해 환각에 의한 오작동(hallucinated execution)을 원천 차단합니다.

MCP(Model Context Protocol)는 도구 연결을 위한 사실상의 표준 인터페이스로 자리 잡았습니다. 수많은 하네스가 도구별 맞춤 통합 코드를 작성하지 않고도 MCP를 활용해 외부 도구 서버에 연결하고 있습니다. 이는 tools/list를 통한 도구 탐색과 tools/call을 통한 도구 실행을 지원하는 JSON-RPC 클라이언트-서버 모델입니다.

메모리 (Memory)

메모리는 다층적 구조를 지닙니다. 현재 작업을 위한 작업 메모리(working memory), 과거 상호작용을 기억하는 에피소드 메모리(episodic memory), 검색 가능한 지식을 담은 시맨틱 메모리(semantic memory), 학습된 워크플로를 다루는 절차적 메모리(procedural memory) 등이 있습니다. 하네스는 무엇을 언제 검색해 주입할지 결정합니다.

랭체인은 메모리를 하네스의 본질적인 책임으로 정의하며 다음과 같이 비유했습니다: “에이전트 하네스에 메모리를 플러그인하겠다는 것은 자동차에 운전 기능을 플러그인하겠다는 말과 같습니다.”

검증 (Verification)

에이전트 품질에서 가장 비약적인 도약을 이끌어낸 영역입니다. 단순히 “답변 생성 후 종료”하는 대신 “생성, 검증, 수정, 재검증, 승인”의 패턴을 거칩니다. 단위 테스트, JSON 유효성 검사, 스키마 검증, 정책 준수 여부 검사, 출처 인용 확인, 환각 감지 등이 수행됩니다. 이러한 검증을 실행하는 주체는 모델이 아니라 바로 하네스입니다.

안전 및 가드레일 (Safety and guardrails)

하네스는 권한을 통제합니다. 모델이 rm -rf /를 실행하려 할 때 단호히 거부하는 것이 하네스의 역할입니다. 샌드박스, 승인 게이트, 권한 범위(permission scope), 네트워크 정책, 파일시스템 정책이 여기에 포함됩니다. 2026년 OWASP 에이전틱 애플리케이션 10대 보안 위협(OWASP Top 10 for Agentic Applications 2026)에서는 데모 수준의 프로토타입을 실제 운영 가능한 시스템으로 변환하는 핵심 원칙으로 ’최소 에이전시(Least-Agency)’와 ’강력한 관측 가능성(Strong Observability)’을 꼽았습니다.

진화의 궤적: 프롬프트 → 컨텍스트 → 하네스 (The evolution: prompt → context → harness)

이 발전 과정은 레버리지가 실제로 어디에 존재하는지에 대한 업계의 통찰이 깊어지는 흐름과 정확히 일치합니다:

1단계 — 프롬프트 엔지니어링 (Prompt engineering). 단일 상호작용의 최적화. 하나의 프롬프트, 하나의 응답.

2단계 — 컨텍스트 엔지니어링 (Context engineering). 여러 단계에 걸쳐 모델이 보게 될 정보를 통제. 작업 상태에 따른 관련 컨텍스트의 동적 조립.

3단계 — 하네스 엔지니어링 (Harness engineering). 전체 운영 환경 자체를 설계. 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 도구 관리, 검증 루프, 상태 지속성, 오류 복구, 비용 예산 제어, 인간 참여(Human-in-the-loop) 게이트까지 아우르는 거대한 시스템 속의 하위 컴포넌트가 됩니다.

하네스 엔지니어링은 프롬프트 엔지니어링이나 컨텍스트 엔지니어링보다 훨씬 넓은 범위를 다룹니다. 결정적인 차별점은 비결정론적(non-deterministic)으로 동작하는 컴포넌트를 감싸도록 설계된다는 점입니다. 즉, 모델이 행동을 꾸며내거나 작업이 끝나지 않았는데도 완료되었다고 거짓 보고할 때, 하네스는 이를 우아하게 복구해 냅니다.

하네스 vs. 프레임워크 vs. 런타임 (Harness vs. framework vs. runtime)

이 용어들은 종종 혼용되곤 합니다. 현재 널리 인정받고 있는 3계층 분류법은 다음과 같습니다:

차원 (Dimension) 에이전트 프레임워크 (Agent Framework) 에이전트 런타임 (Agent Runtime) 에이전트 하네스 (Agent Harness)
역할 (What it does) 추론, 라우팅, 도구 로직 정의 시간에 걸쳐 에이전트를 안정적으로 실행 도구, 메모리, 상태, 가드레일을 갖춘 프로덕션 래퍼
대표 사례 (Examples) LangChain, CrewAI, AutoGen LangGraph, Temporal, Inngest Claude Code, Codex CLI, Deep Agents
실패 양상 (Failure mode) 잘못된 도구 선택, 잘못된 라우팅 상태 유실, 재시도 불가 컨텍스트 표류(drift), 가드레일 오설정
답변하는 질문 (Question answered) 에이전트가 무엇을 해야 하는가? 중단 후 재개할 수 있는가? 안전하고, 관측 가능하며, 신뢰할 수 있는가?

해리슨 체이스(Harrison Chase)는 이를 명쾌하게 요약했습니다: “LangGraph는 런타임이고, LangChain은 추상화이며, Deep Agents는 하네스입니다.” 프레임워크가 레고 블록을 제공한다면, 하네스는 이미 수많은 의사결정이 완료된 완제품의 형태로 제공됩니다.

2026년 중반의 하네스 생태계 지형도 (The landscape in mid-2026)

하네스 생태계는 폭발적으로 성장했습니다. 한 큐레이션 트래커에 따르면 141개의 하네스 관련 프로젝트가 등재되어 있으며, 그중 111개는 완전한 오픈소스 프로젝트입니다.

코딩 에이전트 (가장 큰 카테고리)

시스템 Star 수 제어 중점 영역
OpenCode 187k MCP를 지원하는 멀티 프로바이더 도구 호출 루프
Gemini CLI 106k 구글의 퍼스트 파티 터미널 에이전트
Codex 99.6k OpenAI의 샌드박스 기반 레퍼런스 구현체
OpenHands 81.3k Docker 기반 소프트웨어 엔지니어링 에이전트
Cline 64.8k 단계별 인간 승인을 지원하는 VS Code 확장 프로그램
Goose 51.3k 리눅스 재단 지원, MCP/ACP 모델

프레임워크 네이티브 하네스

시스템 Star 수 핵심 기능
LangChain Deep Agents 24.9k LangGraph 기반 구축, 모델 불가지론(agnostic), 계획 수립 및 서브에이전트 생성
Anthropic Agent SDK — Claude Code에서 추출, Claude 전용, 네이티브 MCP 지원
OpenAI Agents SDK — 에이전트 + 핸드오프 + 가드레일, OpenAI 우선
Google ADK — 멀티 에이전트 오케스트레이션, 4개 프로그래밍 언어 지원
Microsoft Agent Framework 1.0 GA AutoGen과 Semantic Kernel의 통합
Databricks Omnigent — 오픈소스 메타 하네스, Apache 2.0 라이선스
Mastra 25.3k TypeScript 네이티브, 시각적 개발을 위한 Studio UI 제공

점진적 공개(Progressive disclosure) 하네스

컨텍스트 윈도우 효율성에 초점을 맞춘 최신 카테고리입니다:

시스템 동작 메커니즘
Headroom (60k stars) 콘텐츠 인식 압축 — 코딩 토큰 20% 절감, JSON 토큰 60~95% 절감
context-mode (19.1k stars) 모델에 전달되기 전 도구 출력을 샌드박스 처리 — 98% 토큰 절감 주장

메타 하네스 (Meta-harnesses)

하네스 자체를 생성하거나 진화시키는 시스템입니다. MemoHarness는 하네스를 6개의 편집 가능한 제어 차원으로 분해하며, AHE(Agentic Harness Engineering)는 ‘평가-분석-개선’ 루프를 자동화합니다. 이는 모델 성능이 향상됨에 따라 특정 컴포넌트가 불필요해질 수 있음을 미리 인지하고 설계해야 한다는 통찰을 반영하고 있습니다.

성능 실증 데이터 (The performance data)

수치는 명백한 사실을 보여줍니다.

성능 레버로서의 하네스. 랭체인은 모델별 맞춤 하네스 프로파일을 추가한 것만으로 tau2-bench 하위 평가 세트에서 10~20점의 상승을 기록했다고 발표했습니다. Artificial Analysis의 코딩 에이전트 인덱스(Coding Agent Index)에 따르면, 작업당 소요 비용, 토큰 사용량, 소요 시간이 모델과 하네스의 조합에 따라 현격하게 달라지는 것으로 나타났습니다.

자동화된 하네스 진화. 10회의 반복(iteration)을 거치는 동안, AHE는 GPT-5.4 기반 Terminal-Bench 2의 pass@1 성능을 69.7%에서 77.0%로 끌어올렸으며, 이는 사람이 직접 작성한 Codex의 71.9%를 넘어선 결과였습니다. 이렇게 고정(frozen)된 하네스는 재진화 과정 없이도 SWE-bench-verified에 전이되어 12% 적은 토큰으로 실행되었고, 3개의 다른 모델 패밀리 전반에서 5.1~10.1점의 교차 성능 향상을 기록했습니다. 2026년 5월에는 NexAU-AHE가 GPT-5.5를 활용하여 Terminal-Bench 2에서 84.7%에 도달했습니다.

수학적 확률의 문제. 에이전트가 단계당 99%의 정확도로 100개의 순차적 단계를 실행한다면, 최종적인 엔드투엔드 작업 완수율은 단 36.6%에 불과합니다. 단계당 정확도가 99.9%로 올라가야만 100단계 성공률이 90.5%에 이릅니다. 오류를 처리하고, 상태를 보존하며, 컨텍스트를 관리하고, 모든 단계에 걸쳐 신뢰성을 보장하는 시스템이 바로 하네스입니다.

Harness-Bench. 하네스를 독립 변수로 격리하여 평가하기 위해 2026년 5월 고안된 벤치마크입니다. 핵심 발견 사항: 동일한 기반 LLM이라도 실행되는 하네스에 따라 완전히 다른 성능을 발휘한다는 점입니다.

하네스 엔지니어링의 6대 기본 원칙 (The six foundational principles)

OpenAI의 2026 하네스 엔지니어링 프레임워크는 타협할 수 없는 6가지 원칙을 정의합니다:

  1. 단일 진실 공급원으로서의 저장소 (Repo as system of record). 모든 사양, 규칙, 의사결정은 버전 관리되는 아티팩트로 저장되어야 합니다. 문서화되지 않은 지식은 에이전트에게 보이지 않는 존재와 같습니다.

  2. 점진적 공개 (Progressive disclosure). 에이전트의 진입점(예: AGENTS.md)은 방대한 단일 지침서가 아니라, 더 깊이 있는 문서를 가리키는 약 100줄 내외의 간결한 목차여야 합니다.

  3. 수동 규칙보다 기계적 강제 (Mechanical enforcement over manual rules). 문서는 시간이 지나면 낡고 부패합니다. 반면 자동화된 린터, 구조적 테스트, 불변성 검증(invariant checks)은 그렇지 않습니다. 경계는 반드시 코드로 강제해야 합니다.

  4. 에이전트 중심의 가독성 (Agent-centric readability). 사람의 가독성뿐만 아니라 에이전트가 정보를 처리하는 방식에 최적화하여 작성해야 합니다.

  5. 처리량 우선 운영 (Throughput-first operations). 에이전트의 처리량은 인간의 집중력 용량을 훨씬 능가합니다. 빠른 반복 실행을 최우선으로 삼아야 합니다.

  6. 엔트로피 관리 (Entropy management). 에이전트는 코드베이스에 존재하는 좋은 패턴뿐만 아니라 나쁜 패턴까지 그대로 학습하고 재현합니다. 핵심 모범 규칙(golden rules)을 성문화하고, 주기적인 드리프트 스캔을 실행해야 합니다.

규제 환경에서 이것이 결정적인 이유 (Why this matters for regulated environments)

생명과학 분야에서 하네스는 단순한 성능 향상의 수단이 아닙니다. 바로 규제 준수(compliance)를 강제하는 집행 계층입니다.

GxP 준수 하네스는 범용 코딩 에이전트를 뛰어넘는 역량을 필요로 합니다:

컴포넌트 중요한 이유
문서 버전 관리 (Document version control) 유효한 최신 SOP만 사용되도록 보장
전자 서명 (Electronic signatures) 검토 및 승인 워크플로 지원
21 CFR Part 11 제어 규제 준수 및 감사 가능성 확보
감사 추적 (Audit trail) 모델의 모든 의사결정과 도구 호출 기록
인용 출처 강제 (Citation enforcement) 모든 결론을 원천 문서에 연결
사람 QA 체크포인트 (Human QA checkpoints) 규제 대상 의사결정에 필수 요구
역할 기반 접근 제어 (Role-based access) 무단 및 비인가 작업 방지
불변 로그 (Immutable logs) 실사(inspection) 및 조사 지원

대부분의 벤더는 비슷한 수준의 프론티어 모델에 접근할 수 있습니다. 하지만 SOP, 일탈(deviations), CAPA, 변경 관리(change controls), 제조기록서(batch records), 작업 지침서 간의 유기적 관계를 안정적으로 이해하고, 올바른 최신 문서 버전만을 검색하며, 모든 결론에서 원천 증거까지의 추적성을 유지하고, GxP 가드레일을 강제하며, 필수적인 인간 승인을 위해 적절히 멈춰 서고, 감사를 위해 모든 행동을 기록하는 하네스를 구축할 수 있는 곳은 극히 드뭅니다.

하네스는 조직의 도메인 전문성, 거버넌스, 컴플라이언스 요구사항을 집약한 산물입니다. 방어 가능한 지속적 우위는 바로 여기에 존재합니다.

상호운용성 표준 계층 (Standards: the interoperability layer)

두 가지 오픈 표준이 하네스 통합 구조를 형성하고 있습니다:

앤트로픽의 MCP (Model Context Protocol) — 에이전트와 도구 간의 연결을 관장합니다. “기업 데이터 접근을 위한 USB-C”로 알려지며 수백 개 기업에 도입되었습니다.

구글의 A2A (Agent-to-Agent Protocol) — 에이전트 간의 협업을 관장합니다. 훨씬 더 야심 찬 목표를 지니고 있으나, 상대적으로 초기 단계에 있습니다.

두 프로토콜은 상호 보완적입니다. 멀티 에이전트 시스템은 에이전트 간 조율을 위해 A2A를 활용하고, 각 에이전트는 공유 컨텍스트와 도구에 연결하기 위해 MCP를 사용합니다.

아직 해결되지 않은 난제들 (The hard unsolved problems)

  1. 컨텍스트 윈도우 관리는 본질적으로 하네스의 문제입니다. 무엇을 포함하고, 압축하며, 폐기할지 결정해야 합니다. 여기서 실패하면 에이전트는 환각에 빠지거나 작업 목표를 상실하게 됩니다.

  2. 비용 대비 성능의 트레이드오프입니다. 이번 단계에는 저렴한 모델을 쓰고 다음 단계에는 고가의 모델을 써야 할까요? 토큰 예산은 기하급수적으로 불어납니다.

  3. 프로덕션 환경에서의 신뢰성입니다. 에이전트는 결정론적 인프라와 상호작용하는 확률론적 시스템입니다. 그로 인해 발생하는 실패 유형(failure modes)은 이전에는 볼 수 없었던 완전히 새로운 형태입니다.

  4. 평가 방식은 여전히 수공업적 수준에 머물러 있습니다. 대부분의 팀이 여전히 수동 검토로 평가를 진행합니다. 자동화된 평가도 가능하지만 정교한 캘리브레이션이 요구됩니다.

  5. 하네스 실패와 모델 실패의 명확한 구분 문제입니다. 대규모 리더보드 분석에 따르면, 단순 에이전트 실패로 기록된 상당수의 오류가 실제로는 하네스의 결함 때문이었던 것으로 밝혀졌습니다.

향후 전개 방향 (The trajectory)

세 가지 거대한 트렌드가 하나로 수렴하고 있습니다:

하네스가 배포의 기본 단위가 되고 있습니다. 순수 모델만 배포하는 것이 아니라 도구, 메모리, 가드레일이 완벽히 구성된 하네스 패키지를 배포합니다.

이기종 환경을 관리하기 위한 메타 하네스가 부상하고 있습니다. 모든 작업을 완벽히 해결하는 단일 하네스는 존재하지 않기 때문입니다.

모델뿐만 아니라 하네스를 일급 변수(first-class variable)로 다루는 진단 체계와 함께 벤치마크가 성숙해지고 있습니다.

이러한 흐름은 에이전트 하네스가 차세대 ’애플리케이션 서버’로 자리 잡고 있음을 시사합니다. 과거 Rails가 HTTP를 추상화하고 Kubernetes가 인프라를 추상화했듯이, 개발자들은 하네스라는 런타임 계층 위에서 애플리케이션을 구축하게 됩니다. 모델이 CPU라면, 하네스는 곧 운영체제(OS)입니다.

일부 실무자들은 이제 이를 “하네스가 새로운 데이터셋이다(Harness is the new Dataset)“라고 표현합니다. 탁월한 하네스 시스템을 구축하는 것이야말로 모델 지능을 극대화하기 위한 차세대 프론티어입니다. NVIDIA는 이 개념을 OpenShell과 NeMo Agent Toolkit으로 구체화했습니다. DeepSeek는 2026년 초 전담 하네스 엔지니어링 팀을 신설했습니다. 베이징시는 공식 AI 에이전트 정책에서 하네스 엔지니어링을 핵심 지원 R&D 분야로 지정했습니다.

결론: 요약 (The bottom line)

이제 질문은 “어떤 모델을 쓸 것인가”가 아닙니다. “어떤 하네스를 구축할 것인가”입니다.

형편없는 차체에 페라리 엔진을 얹는다고 해서 레이스에서 이길 수는 없습니다. 조악한 하네스에 탑재된 GPT-5.5는 훌륭한 하네스에서 구동되는 중급 모델보다도 못한 성능을 냅니다. 모델은 추론 능력을 제공할 뿐입니다. 루프, 도구, 메모리, 검증, 가드레일, 관측 가능성, 오류 복구 등 그 밖의 모든 것을 제공하는 주체는 바로 하네스입니다.

코딩을 위해서든, 품질 시스템을 위해서든, 규제 대상 워크플로를 위해서든 에이전트를 개발하고 있다면, 엔지니어링 투자의 복리 효과가 누적되는 곳은 오직 하네스뿐입니다. 모델 간의 개발 경쟁은 끝없이 이어지겠지만, 신뢰성과 비용, 그리고 사용자 경험을 궁극적으로 결정짓는 곳은 바로 하네스입니다.

하네스가 곧 해자(Moat)입니다.