하네스 엔지니어링 시대: Agent = Model + Harness가 바꾸는 AI 개발의 무게중심

더 크고 강력한 모델을 만드는 것이 AI 경쟁의 전부라고 믿었던 시대는 조용히 막을 내리고 있다. 이제 에이전트의 성패는 모델 자체가 아니라, 그것을 감싸는 ‘하네스(harness)‘를 얼마나 정교하게 설계했느냐에서 갈린다.

핵심 요약 AI 개발의 무게중심은 사전학습 스케일링에서 추론-시간 스케일링과 에이전틱 AI로 이동하고 있다. “Agent = Model + Harness"가 업계 표준 프레임으로 자리잡았으며, 에이전트 성능의 결정 변수는 모델 교체가 아닌 하네스 설계다. 실수를 반복하지 못하도록 루프를 설계하는 자가 다음 시대의 주도권을 쥔다.

1. 패러다임의 전환: 사전학습 스케일링에서 하네스 엔지니어링으로

AI 개발의 역사는 지금까지 하나의 공식에 지배돼 왔다. 더 많은 데이터, 더 많은 파라미터, 더 많은 컴퓨팅 — 이른바 **사전학습 스케일링 법칙(pre-training scaling law)**이다. 모델이 커질수록 성능이 향상된다는 믿음은 수년간 업계의 투자 논리를 지탱해왔다.

그러나 이 공식에 균열이 생기기 시작했다.

Andrej Karpathy는 2025년 중반 “컨텍스트 엔지니어링(context engineering)”이라는 표현을 지지하며, 모델에게 무엇을 어떻게 제공하느냐가 모델 자체의 크기만큼 중요하다는 관점을 공론화했다. 컨텍스트 엔지니어링이란 AI 모델이 주어진 맥락(context window) 안에서 최적의 판단을 내릴 수 있도록 입력 구조, 도구 정의, 메모리 설계 등을 체계적으로 구성하는 실천이다.

이 흐름은 Ghostty 창업자이자 HashiCorp 공동창업자인 Mitchell Hashimoto가 자신의 AI 도입기에서 에이전트 루프 설계의 구체적 방법론을 공개하며 실무적 깊이를 얻었다. 그리고 2026년 2월, OpenAI가 ‘Harness Engineering’을 정식 엔지니어링 분과로 공식화하면서 이 흐름은 산업 표준의 지위를 획득했다.

이 계보는 단순한 명칭의 변화가 아니다. AI 개발의 무게중심이 **모델을 만드는 곳(사전학습)**에서 **모델을 운용하는 방식(추론-시간 스케일링과 에이전틱 설계)**으로 이동하고 있음을 알리는 구조적 선언이다.

더 큰 모델을 만드는 군비경쟁은 이제 다른 경쟁으로 진화했다. 모델이 ‘생각하는 시간(추론 연산)‘을 늘리고, 도구를 활용하며, 장기 과제를 자율적으로 수행하는 에이전트를 누가 더 잘 설계하느냐의 경쟁이다.

2. 업계 표준 프레임: Agent = Model + Harness

하네스(Harness)란 모델을 둘러싼 실행 환경 전체 — 도구 정의, 메모리 관리, 루프 제어, 오류 처리, 평가 체계 — 를 총칭하는 개념이다. 오늘날 AI 에이전트 개발의 공통 언어가 된 등식이 있다.

Agent = Model + Harness

이 프레임이 의미하는 바는 명확하다. 동일한 프론티어 모델을 사용하더라도, 하네스를 얼마나 정교하게 설계했느냐에 따라 에이전트의 성능은 근본적으로 달라진다. 모델은 더 이상 차별화의 유일한 축이 아니다. 실제로 Claude Code, Pi, Letta처럼 독립적으로 개발된 하네스들이 대형 툴 결과의 디스크 영속화, 컴팩션 경계 안전성 같은 동일한 설계로 수렴하고 있다는 분석은, 이것이 유행이 아니라 검증된 공학 패턴임을 보여준다. 미니멀리즘도 검증됐다 — Vercel은 에이전트의 툴 80%를 삭제해 오히려 성능을 개선했다. 적을수록 낫다.

에이전트 작동의 기본 루프

에이전트는 단선적으로 실행되지 않는다. 다음과 같은 순환 구조 안에서 작동한다.

flowchart LR
    A([목표 수신]) --> B[계획 Plan]
    B --> C[도구 사용 Tool Use]
    C --> D[관찰 Observe]
    D --> E{충분한가?}
    E -- 아니오 --> F[반성 Reflect]
    F --> G[개선 Improve]
    G --> B
    E -- 예 --> H([결과 출력])

    style A fill:#4F46E5,color:#fff
    style H fill:#059669,color:#fff
    style E fill:#D97706,color:#fff

**계획(Plan) → 도구 사용(Tool Use) → 관찰(Observe) → 반성(Reflect) → 개선(Improve)**의 루프는 에이전트가 단일 응답 생성기를 넘어 자율적 작업 수행자로 기능하게 하는 핵심 구조다.

이 루프를 조향하는 방법은 두 갈래로 정리된다. Martin Fowler 사이트에 실린 Birgitta Böckeler의 프레임워크를 빌리면 — 규칙과 컨텍스트를 사전에 주입하는 feedforward(가이드), 그리고 린터·테스트·훅으로 사후 관찰하는 **feedback(센서)**이다. 좋은 하네스는 이 두 축을 함께 설계한다.

3. 루프 엔지니어링의 실천: 실수를 시스템으로 봉인하라

하네스 엔지니어링의 핵심 실천 원리는 Hashimoto의 말 한마디로 압축된다.

“에이전트가 실수할 때마다, 다시는 그 실수를 못 하도록 시스템을 엔지니어링하라.”

이는 에이전트를 더 똑똑하게 만드는 접근이 아니다. 실수가 반복될 수 없는 구조적 제약을 시스템 안에 내장하는 접근이다. 버그를 발견하면 테스트를 추가하는 소프트웨어 공학의 원칙이, AI 에이전트 운용의 영역으로 확장된 것이다.

Loop Engineering의 3대 구현체

실무에서 루프 엔지니어링은 세 가지 표준 구현체로 수렴하고 있다.

구현체핵심 아이디어성립 조건
Ralph Wiggum Loop (Geoffrey Huntley)while 루프로 매 이터레이션 fresh context 실행. git과 progress 파일이 메모리 레이어상세한 스펙 + 명확한 종료 기준(exit criteria)
Initializer-Executor (Anthropic)초기화 에이전트가 durable environment(초기화 스크립트·진행 파일)를 1회 구축, 이후 executor 세션들이 세션 간 공유 메모리로 사용디스크에 영속화된 상태 설계
Dynamic Workflows계획 자체가 오케스트레이션 코드로 이동 — 중단 후 재개 가능한 결정론적 제어 흐름관측 가능한 단계 분해

셋의 공통분모는 분명하다. 장기 실행의 핵심은 컨텍스트 윈도우가 아니라 디스크에 영속화된 상태이며, 루프의 성패는 모델 성능이 아니라 종료 기준 설계에 달렸다. 하네스를 편집 가능한 파일 컴포넌트로 분해하고 관측 데이터로 하네스 자체를 자동 진화시키는 연구까지 나온 상태다.

Spec-Driven 개발의 부상

이 흐름이 개인 방법론을 넘어 표준 도구로 정착하는 과정을 보여주는 상징적 사례가 GitHub Spec-Kit이다.

Spec-driven 개발이란 에이전트에게 직접 작업을 지시하는 대신, 먼저 사양(spec)을 작성하고 → 계획(plan)으로 분해하고 → 실행 가능한 태스크(tasks)로 구체화한 뒤 에이전트를 투입하는 방식이다. 이 체인이 에이전트-애그노스틱 마크다운으로 표준화됐다는 것은, 어떤 모델을 쓰든 동일한 워크플로를 재사용할 수 있음을 의미한다.

반면 역할(페르소나)별로 파일을 주고받는 무거운 핸드오프 구조는 오버헤드 때문에 실패 사례로 언급된다 — 위임 구조는 플랫할수록 좋다는 교훈이다.

4. 검증과 병렬화: 생성이 아니라 검토가 병목이다

에이전트가 코드를 쏟아내는 시대에 합의된 검증 원칙은 세 가지다.

  1. Definition-of-Done은 기계가 체크 가능한 계약이어야 한다 — 모든 완료 조건이 관측 가능해야 한다.
  2. 작성자 에이전트는 오염돼 있다(compromised) — 자기 작업의 검증은 반드시 세션을 분리한 별도 에이전트가 수행해야 한다(adversarial review).
  3. 검증자는 크지 않아도 되지만, 달라야 한다 — 같은 모델이 자기 출력을 평가하면 self-evaluation bias에 빠진다.

병렬화 쪽의 수렴도 뚜렷하다. 병렬 에이전트 도구들은 전부 worktree(또는 컨테이너) 격리 + 태스크별 브랜치 + 리뷰 후 병합이라는 같은 설계에 도달했다. 그리고 업계의 실전 합의 — 1인 개발자가 감당 가능한 동시 작업은 4~8 worktree. 그 이상에서는 에이전트가 아니라 사람의 리뷰가 병목이 된다.

스케일의 제약이 연산에서 인간 검토 대역폭으로 이동했다. “AI가 똑똑해졌다"보다 “AI가 검증 가능한 루프 안에 들어갔다"가 가치 창출을 더 정확히 설명한다.

하네스 생태계가 커지면서 보안도 새 전선이 됐다. 인기 메모리 플러그인이 무인증 로컬 HTTP API를 0.0.0.0에 바인딩해 보안 감사에서 HIGH 판정을 받은 사례가 있다. 서드파티 플러그인이 늘수록 하네스의 공격 표면도 커진다 — 하네스 엔지니어링에는 처음부터 보안 감사가 포함돼야 한다.

5. 에이전트 경제학: 비즈니스 현장의 실증

하네스 엔지니어링은 학문적 개념에 머물지 않는다. 실물 경제의 가장 민감한 영역 — 자본 배분과 기업 경쟁 — 에서 이미 그 효과가 검증되고 있다.

자동화 패러다임의 세대 교체

구분과거의 자동화현재의 AI 자동화
자동화 대상논리적 절차로 설명 가능한 일충분한 데이터로 검증 가능한 일
설계 방식규칙 기반 프로그래밍루프 안에서의 학습·평가·반복
한계 요인예외 케이스, 규칙의 불완전성검증 루프의 정밀도, 평가 기준의 명확성
성능 향상 방법규칙 추가·수정하네스 재설계, 평가 데이터 확충

과거의 자동화 시스템은 인간이 ‘어떻게 하는지’를 명시적으로 코드화할 수 있는 영역에서만 작동했다. 지금의 AI는 ‘무엇이 좋은 결과인지’를 데이터로 검증할 수 있다면 자동화할 수 있다. 이 차이가 AI 자동화의 적용 범위를 기하급수적으로 확장한다.

재무·반도체 — 에이전트 적용의 최적 지형

법인카드·지출관리 시장에서 경쟁을 돌파한 Ramp가 재무용 AI 에이전트 기업으로의 전환을 선언하며 대형 밸류에이션 투자 유치에 성공한 것은, 에이전트가 특정 산업의 핵심 인프라로 자리잡을 수 있다는 투자자의 집합적 판단이다. 재무 데이터는 검증 기준이 명확하고 반복 실행 가능한 루프를 설계하기 용이하다 — 에이전트 적용의 최적 영역이다.

반도체 설계 자동화(EDA) 역시 같은 조건을 갖췄다. 복잡성과 비용이 극단적으로 높고, 검증 기준(시뮬레이션·테스트)이 명확하며, 반복 실행 가능한 루프가 이미 존재한다. 두 영역의 공통점은 우연이 아니다 — 검증 가능한 루프가 이미 있는 곳에서 에이전트의 가치가 가장 먼저 실현된다.

“미래에는 PC를 직접 조작하는 에이전트를 두게 될 것이다. 그 수를 선택하고 운용하는 것이 새로운 노동 패러다임이다.”

기업의 소프트웨어 구독 항목에 ‘에이전트 수’가 포함되는 시대가 오면, 몇 개의 에이전트를 어떤 루프로 운용할지를 결정하는 능력이 핵심 경영 역량이 된다.

FAQ: 하네스 엔지니어링에 대해 가장 많이 묻는 질문

Q. 하네스 엔지니어링과 프롬프트 엔지니어링은 어떻게 다른가?

프롬프트 엔지니어링이 모델에게 보내는 단일 입력(프롬프트)의 품질을 최적화하는 것이라면, 하네스 엔지니어링은 에이전트가 반복 실행하는 루프 전체 — 도구 설계, 메모리 관리, 오류 처리, 평가 체계, 서브에이전트 조율 — 를 시스템으로 설계하는 것이다. 프롬프트 엔지니어링이 단발 최적화라면, 하네스 엔지니어링은 지속적 시스템 설계다.

Q. 어떤 모델을 써도 하네스가 더 중요하다는 주장의 근거는?

동일한 기반 모델에서 하네스 설계만으로 성능이 유의미하게 달라진다는 사례가 산업 현장에서 반복 보고되고 있다. 평가 기준(eval) 설계, 컨텍스트 구성, 도구 호출 체계가 달라지면 모델 교체 없이도 결과가 개선된다. 반대로, 하네스 없이 모델만 업그레이드해도 같은 실수가 반복되는 경우가 다수다.

결론: 루프를 설계하는 자가 다음 시대를 이끈다

하네스 엔지니어링은 단순한 기술 트렌드가 아니다. AI 개발의 책임 소재를 모델 제조사에서 시스템 설계자로 이전시키는 구조적 전환이다.

더 강한 모델이 나오기를 기다리는 수동적 자세로는 이 시대를 앞서갈 수 없다. 지금 가진 모델이 동일한 실수를 반복하지 못하도록, 루프를 설계하고, 검증하고, 정교화하는 능력 — 이것이 다음 시대의 핵심 역량이다.

Karpathy의 컨텍스트 엔지니어링에서 출발해 Hashimoto의 루프 엔지니어링을 거쳐 OpenAI의 하네스 엔지니어링으로 이어지는 계보는, AI 지능화의 다음 단계가 파라미터 수가 아님을 분명히 한다. 얼마나 정밀하게 검증된 루프 위에서 에이전트를 작동시키느냐 — 그것이 AI 시대의 새로운 경쟁 축이다.

모델은 평준화된다. 하네스는 차별화된다.

참고 자료