하네스 엔지니어링(Harness Engineering): 엔지니어링의 새로운 패러다임

1. 왜 지금 '하네스'가 필요해졌는가

AI 에이전트의 약속은 분명하다. 사람이 일일이 손대지 않아도, 사람이 시킨 일을 알아서 끝내준다. 코드를 작성하고, 테스트를 돌리고, 문서를 정리하고, PR을 열고, 리뷰까지 받아 머지하는 일들을 사람의 개입을 최소화한 채로 — 또는 거의 없이 — 자율적으로 수행하길 우리는 기대한다.

문제는 거기에 있다. 기존 소프트웨어 엔지니어링은 결정론적이었다. 같은 입력을 넣으면 같은 출력이 나오고, 코드는 작성한 그대로 동작한다. 결과가 예측 가능했기 때문에 우리는 그 위에 거대한 시스템을 쌓아 올릴 수 있었다.

그러나 LLM 기반 에이전트는 다르다. 같은 프롬프트로도 다른 결과가 나오고, 어떤 도구를 어떤 순서로 호출할지, 어디서 멈춰서 “다 됐다”고 선언할지 — 모두 확률적이다. 모델 자체의 성능은 매 세대 좋아지고 있지만, 그것만으로는 두 가지 본질적인 한계를 넘어서지 못한다.

첫 번째 한계: 장기 작업과 다중 세션에서의 일관성. Anthropic은 이 문제를 정면으로 다룬 글에서, 장기 실행 에이전트의 핵심 난제를 "각 새로운 세션이 이전 세션에 대한 기억 없이 시작된다는 점"으로 짚는다. 마치 교대 근무로 돌아가는 소프트웨어 프로젝트에 매번 새로운 엔지니어가 아무런 인수인계 없이 투입되는 상황에 가깝다는 것이다. 컨텍스트 윈도우가 유한하기 때문에 복잡한 프로젝트는 한 세션 안에 끝나지 않고, 따라서 에이전트는 세션과 세션 사이의 간극을 메울 방법이 필요하다. 압축(compaction)만으로는 부족하다는 사실이 실험으로 드러났다 — Opus 같은 최전선 모델조차 그냥 루프만 돌리면 절반쯤 구현된 기능을 남기거나, 반대로 진행 상황을 보고는 “끝났다”고 선언하며 종료해 버린다 (Anthropic, Effective harnesses for long-running agents).

두 번째 한계: 검증의 병목. OpenAI가 사내에서 다섯 달에 걸쳐 진행한 실험을 공개하면서 던진 화두가 이것이다. 약 100만 줄 규모의 베타 제품을 사람이 직접 코드를 한 줄도 쓰지 않고 Codex 에이전트만으로 출시한 이 프로젝트에서, 가장 큰 발견은 사람이 매번 검토하는 구조로는 에이전트 처리량을 따라잡을 수 없다는 사실이었다. 매주 금요일을 정리 작업에 통째로 할당해 봤지만, 엔지니어링 시간의 20%를 써도 생성 속도를 따라잡지 못했다. 해법은 사람의 리뷰를 에이전트 간 리뷰로 옮기는 것이었다 (Adithya Giridharan, OpenAI’s Harness Engineering Post Is a Blueprint for the Agent-First Era).

이 두 한계 — 세션을 가로지르는 일관성*과 *사람 검증의 병목 — 가 만나는 지점에서 새로운 공학이 필요해졌다. 그 이름이 바로 하네스 엔지니어링이다.

---

2. 하네스란 무엇인가

말의 하네스(harness)는 마구(馬具)다. 고삐, 안장, 재갈 — 강하지만 예측이 어려운 동물을 원하는 방향으로 안내하는 모든 장비. 이 비유가 그대로 소프트웨어로 옮겨 왔다.

가장 깔끔한 정의는 LangChain이 정리한 것이다:

Agent = Model + Harness

모델이 아닌 모든 것이 하네스다.

즉, 시스템 프롬프트, 도구와 그 설명, 번들된 인프라(파일시스템, 샌드박스, 브라우저), 오케스트레이션 로직(서브에이전트 분기, 핸드오프, 모델 라우팅), 결정론적 실행을 위한 훅과 미들웨어(컨텍스트 압축, 연속 실행, lint 검사) — 모델 자체가 아닌 모든 코드와 설정, 실행 로직이 하네스다 (LangChain, The Anatomy of an Agent Harness).

Anthropic도 같은 구도를 공유한다. Claude Agent SDK 자체를 “범용 에이전트 하네스”라고 부르며, 모델과 하네스를 따로 두고 그 사이의 인터페이스를 설계하는 일을 엔지니어링의 핵심으로 본다.

한 마디로 정리하면 이렇다.

하네스란, AI 모델이 구조적으로 못 하는 것을 시스템 차원에서 보완하고 강제하는 모든 것이다.

모델은 텍스트를 받아 텍스트를 내놓는 함수에 가깝다. 영속적인 상태도 없고, 코드를 실행할 수도 없고, 실시간 정보를 가져올 수도 없고, 환경을 세팅할 수도 없다. 이 모든 것이 “하네스 차원의 기능”이다. 채팅처럼 평범해 보이는 UX마저 사실은 모델을 while 루프로 감싸고 이전 메시지를 추적하는 작은 하네스다.

OpenAI는 한 발 더 나아간다. 모델의 지능이 아무리 좋아져도, 에이전트가 일할 환경이 부실하면 진전이 없다는 것이 그들의 실험에서 얻은 가장 중요한 교훈이었다. 초기에 진전이 느렸던 이유는 Codex가 못해서가 아니라, *환경이 명세가 덜 되어 있었기 때문이었다. 에이전트가 막힐 때마다 사람의 본능은 “직접 짜자”가 아니라 “환경에 *무엇이 빠져 있는가, 어떻게 읽을 수 있게 그리고 강제할 수 있게 만들 것인가”를 묻는 것이었다 (OpenAI, via InfoQ; Adithya Giridharan).

---

3. 하네스의 해부학: 무엇으로 구성되는가

LangChain이 정리한 하네스의 핵심 구성 요소를 한 번 훑어 두자. 이것이 지금까지 산업이 합의한 하네스의 기본 골격이다 (LangChain).

• 파일시스템. 컨텍스트에 다 담을 수 없는 정보를 외부로 떠넘기고, 세션을 가로질러 작업을 영속시키는 가장 근본적인 기본기. 에이전트의 작업 공간이자, 여러 에이전트가 협업하는 공유 칠판이다. Git을 얹으면 버전 관리와 롤백, 실험 분기까지 가능해진다.
• Bash + 코드 실행. 미리 만들어 둔 도구만으로는 풀 수 없는 문제를 위해, 에이전트에게 컴퓨터 자체를 쥐여주는 일반 목적 도구. 모델이 그때그때 코드를 짜서 자기 도구를 만들어 쓰게 된다.
• 샌드박스와 환경 기본기. 에이전트가 만든 코드를 로컬에서 그냥 돌리는 건 위험하고 확장성도 없다. 격리된 실행 환경, 미리 설치된 런타임과 패키지, 브라우저, 테스트 러너 — 이것들이 모두 환경 디폴트로 깔려 있어야 자가 검증 루프가 돈다.
• 메모리와 검색. 모델 가중치를 바꿀 수 없는 이상 “지식 추가”는 컨텍스트 주입으로만 가능하다. AGENTS.md 같은 메모리 파일 표준, 그리고 웹 검색·Context7 같은 MCP 도구가 학습 컷오프 이후의 세상과 모델을 연결해 준다.
• 컨텍스트 부패(Context Rot) 대응. 컨텍스트가 차면 모델 추론력이 떨어진다. 그래서 압축, 도구 호출 결과 오프로딩, Skills의 점진적 공개(progressive disclosure) 같은 기법이 하네스 레벨에서 들어간다.
• 장기 자율 실행 패턴. Ralph Loop처럼 모델이 종료를 시도할 때마다 훅으로 가로채 깨끗한 컨텍스트에 다시 투입하기, 계획 파일로 상태 추적, 자가 검증 루프 — 모두 컨텍스트 윈도우 너머로 작업을 끌고 가기 위한 장치다.
  다시 한번. 하네스 = 모델이 못하는 것 + 모델을 더 잘 쓰게 하는 모든 것.

---

4. 핵심 베스트 프랙티스 — 지금까지 합의된 것들

산업이 다양한 실험을 거치면서, “이건 다들 그렇게 하더라”라고 모일 수 있는 패턴이 몇 가지 생겼다. 출처와 함께 정리해 본다.

4-1. 마크다운 파일에 떼려 모아 놓기

가장 단순하면서도 강력한 기법. 에이전트가 시작할 때마다 자동으로 읽어 들이는 고정된 자리에 있는 파일에, 모든 규칙·맥락·진행 상황을 적어 둔다.

• Anthropic은 두 가지 파일을 핵심 아티팩트로 쓴다: 진행 로그를 누적하는 claude-progress.txt, 그리고 요구사항을 200개 이상의 기능 단위로 펼쳐 둔 feature_list.json. 기능마다 passes: false로 초기화하고, 에이전트는 이 필드의 상태만 바꿀 수 있다. 마크다운보다 JSON을 택한 이유는 모델이 JSON 파일을 함부로 덮어쓰지 않는 경향이 실험에서 더 강했기 때문이다 (Anthropic).
• OpenAI Codex 쪽에서는 Plan.md / Implement.md / Documentation.md가 비슷한 역할을 하는 재사용 가능한 하네스 아티팩트로 자리잡았다 (awesome-harness-engineering).
• LangChain은 표준화된 AGENTS.md를 언급한다. 에이전트가 시작될 때 자동으로 컨텍스트에 주입되고, 에이전트가 이 파일을 갱신하면 다음 세션이 그것을 다시 읽어 들이는 — 지속 학습(continual learning)의 가장 가벼운 형태다.

  4-2. 맵(map)으로 정리: 레포지토리가 곧 진실의 단일 소스

에이전트 관점에서 컨텍스트에 들어오지 않는 정보는 존재하지 않는 정보다. Slack 스레드, Google Docs, 누군가의 머릿속에 있는 결정 — 모두 에이전트에겐 비가시(invisible)다. 그래서 OpenAI는 모든 결정을 레포지토리 안으로 끌어들이는 일을 엔지니어링의 핵심으로 삼았다. 구조화된 docs 디렉토리에 시스템 맵, 실행 계획, 디자인 명세를 두고, 이것들이 단일 진실의 소스가 된다. 디자인 문서와 아키텍처 문서의 교차 참조는 린터와 CI 검증으로 기계적으로 강제된다 (InfoQ on OpenAI Harness Engineering).

4-3. 린터로 강제하기: 어기면 잡혀서 다시 한다

“말로 하지 말고 강제하라”가 이 분야의 격언이 되어 가고 있다.

OpenAI의 실험에서, 레이어 간 의존성은 다음과 같은 고정 방향으로만 흐르도록 못 박혔다.

Types → Config → Repo → Service → Runtime → UI

이 규칙은 권고가 아니라, Codex가 직접 생성한 커스텀 린터와 구조 테스트로 CI에서 강제된다 (InfoQ). 에이전트가 경계를 벗어나면 빌드가 깨지고, 깨진 빌드는 다시 에이전트에게 돌려보내져 자동 개선 루프가 돈다. Anthropic도 같은 원칙을 강조한다 — 자가 검증 루프는 훅에서 사전 정의된 테스트 스위트를 돌려, 실패하면 에러 메시지와 함께 모델로 돌려보내는 식으로 구성된다 (LangChain).

핵심은 invariant(불변식)는 강제하되, 구현은 마이크로매니지하지 않는다는 원칙이다. 데이터 경계에서 형 검증을 해야 한다는 건 강제하지만, 어떤 라이브러리로 할지는 모델에 맡긴다. 결과적으로 OpenAI 팀의 경우 Codex가 Zod로 자연스럽게 수렴했다 (Adithya Giridharan).

4-4. Initializer + Coding 에이전트 분리

Anthropic이 장기 실행 코딩 에이전트에서 효과를 본 두 단 구성이다 (Anthropic).

• Initializer 에이전트 — 첫 세션에서만 실행된다. init.sh(개발 서버를 띄우는 스크립트), claude-progress.txt(이후 에이전트들이 읽어 갈 진행 로그), 그리고 위에서 본 feature_list.json을 생성한다. 초기 Git 커밋도 함께.
• Coding 에이전트 — 이후 모든 세션을 담당한다. 매 세션은 정해진 부트스트랩으로 시작한다: pwd로 작업 디렉토리 확인, claude-progress.txt와 Git 로그 읽기, feature_list.json에서 우선순위 높은 미완 기능 하나 고르기, init.sh로 개발 서버 띄우고 기본 동작 확인, 그 다음에야 새 기능에 착수.
  이 구성이 풀어낸 두 가지 실패 모드가 의미심장하다.

1. 한 번에 다 해버리려는 욕심 → 기능 리스트에서 하나만 고르도록 강제.
2. “다 됐다”고 조기 선언 → 200개 넘는 기능을 미리 펼쳐 놓고, 모두 실패 상태로 시작.
   기능을 passes: true로 바꾸려면 단위 테스트뿐 아니라 브라우저 자동화로 사용자처럼 검증해야 한다. Anthropic 사례에서는 Puppeteer MCP를 통해 Claude가 직접 스크린샷을 찍어 가며 end-to-end 검증을 수행했다.

4-5. 자동 개선 루프 / 가비지 컬렉션

에이전트 생성 코드베이스는 엔트로피가 빠르게 쌓인다. 패턴이 표준에서 벗어나고, 문서와 구현이 어긋난다. 사람 중심 워크플로에서는 주기적인 클린업 스프린트로 처리하지만, 에이전트 처리량에서는 그 방식이 통하지 않는다.

OpenAI의 해법은 “골든 원칙을 레포에 인코딩하고, 백그라운드 Codex 작업을 스케줄로 돌려 이탈을 스캔하고 리팩토링 PR을 제출하게 하는 것”이다. 대부분은 1분 안에 자동 머지된다 — 주기적인 큰 정산 대신 작고 연속적인 지불이다 (Milvus, What Is Harness Engineering; Adithya Giridharan).

4-6. Ralph Loop과 장기 자율 실행

장기 작업을 위한 또 하나의 패턴. 모델이 종료를 시도하면 훅이 가로채서, 원래 프롬프트를 깨끗한 컨텍스트에 다시 주입해 완료 목표 대비 작업을 계속하게 한다. 파일시스템이 이걸 가능하게 한다 — 매 반복은 새 컨텍스트로 시작하지만, 이전 반복의 상태를 파일에서 읽어들이기 때문에 진전이 누적된다 (LangChain). OpenAI도 같은 패턴을 — 농담 섞어 “Ralph Wiggum Loop”라 부르며 — 자기들 PR 완성 루프에 쓰고 있다고 밝혔다.

4-7. 그 외 — 개인적으로 가능한 모든 방식

위에 정리한 것은 지금까지 합의된 핵심*일 뿐이다. 하네스의 정의 자체가 “모델이 아닌 모든 것”이라는 점을 다시 떠올려 보자. 즉, 모델의 부족함을 *구조적으로 메우는 일이라면 그게 무엇이든 하네스가 될 수 있다. 어떤 팀은 자체 평가 에이전트를 따로 돌리고, 어떤 팀은 도메인 특화 DSL을 만들고, 어떤 팀은 트레이스 분석 에이전트를 따로 두어 하네스 자체의 실패 모드를 자동 진단한다 (LangChain).

---

5. 초반은 무겁다, 그러나 시간이 지날수록 가벼워진다

하네스를 처음 세팅하는 일은 명백히 오버헤드다. 문서를 정리하고, 린터를 만들고, 진행 파일과 기능 리스트 포맷을 정하고, 초기 스크립트와 CI를 짜고 — 사람이 직접 코드를 짜는 편이 더 빨라 보이는 순간이 많다.

그러나 이 곡선은 비선형으로 좋아진다.

OpenAI 팀의 표현을 빌리면, 하네스에 더해지는 개선 하나하나가 이후 에이전트 실행을 더 유능하게 만든다. 더 유능해진 에이전트는 더 복잡한 작업을 위임받을 수 있고, 그 과정에서 드러나는 다음 빈틈이 다시 하네스로 인코딩된다. 복리로 누적되는 능력 향상. 다섯 달이 지난 시점에서, 그들의 레포지토리는 “Codex가 명세에서 머지된 PR까지 end-to-end로 새 기능 하나를 처리할 수 있는” 임계를 넘었다 — 코드 작성, 테스트 실행, 리뷰 피드백 응답, 업데이트 푸시, 스쿼시 머지까지 (Adithya Giridharan).

LangChain은 이 효과를 다른 각도에서도 짚는다. 같은 모델(Opus 4.6)이라도 어떤 하네스에서 돌리느냐*에 따라 Terminal Bench 2.0 같은 벤치마크에서 점수 차이가 크게 벌어진다는 것이다. 그들 스스로의 코딩 에이전트는 *하네스만 바꿔서 Top 30에서 Top 5로 올라갔다 (LangChain).

요컨대 — 모델은 사고, 하네스는 직장이다. 같은 사람도 좋은 직장에서 더 좋은 결과를 낸다.

---

6. 지금 가장 많이 쓰는 환경에서, 구체적으로 어떻게 하네스를 구축하는가

이론은 충분히 봤다. 실제 환경에서 어떻게 하는가가 중요하다. 현재 가장 활발히 쓰이는 두 환경 — Claude Code (Anthropic Claude Agent SDK 기반) 와 OpenAI Codex — 를 중심으로, 어떤 파일을 어디에 두고, 어떤 훅을 거는지 구체적으로 정리한다.

6-1. Claude Code 환경에서의 하네스 구축

Claude Code는 Anthropic이 자체적으로 Claude를 후 학습(post-train)할 때 함께 진화시킨 하네스다. 즉, 모델이 원래 이걸 잘 쓰도록 훈련되어 있다. 그 위에 우리가 추가로 쌓을 수 있는 레이어는 대략 다음과 같다.

1) CLAUDE.md / AGENTS.md를 레포 루트에 둔다.

• 에이전트가 세션 시작 시 자동으로 컨텍스트에 적재한다.
• 여기에 적는 것: 프로젝트 개요, 디렉토리 구조 지도, 코딩 컨벤션, 반드시 지켜야 할 invariant, 자주 쓰는 명령어, 흔히 빠지는 함정. 시니어 동료에게 한 페이지짜리 인수인계장을 쓴다고 생각하면 된다.
• 2) Skills 디렉토리를 만든다.*
• /skills/<task-name>/SKILL.md 형태로, 특정 작업(예: PDF 생성, 데이터 분석, Excel 자동화)별로 작업 전 반드시 읽어야 할 가이드를 둔다.
• 이것이 LangChain이 말하는 “progressive disclosure” — 도구나 MCP를 컨텍스트에 미리 다 펼치지 않고, 시작 시엔 front-matter만, 필요할 때 본문을 펼친다. 컨텍스트 부패를 방지하는 데 결정적이다.
• 3) 진행 파일과 기능 리스트를 둔다.*
• Anthropic의 권장 형태를 따라:
  • claude-progress.txt — 각 세션이 끝날 때 무엇을 했는지 누적 로그.
  • feature_list.json — 200~수백 개 단위로 펼친 기능 명세. 각 항목은 passes: false로 시작.
• 시스템 프롬프트에 “이 JSON 파일에서 passes 필드 외에는 절대 수정하지 마라. 테스트를 지우거나 수정하는 것은 허용되지 않는다”를 강한 어조로 박아 둔다.
• 4) init.sh를 둔다.*
• 개발 서버 띄우기, 마이그레이션, 시드 데이터 — 새 세션이 5초 안에 동작하는 앱 앞에 설 수 있게 한다.
• 5) MCP 서버를 붙인다.*
• 브라우저 자동화(Puppeteer MCP) — 사람이 쓰듯 클릭하고 검증하게 한다.
• Context7 같은 라이브러리 문서 MCP — 학습 컷오프 이후 라이브러리 변경에 대응.
• 자사 시스템 MCP — 내부 도구·DB 접근.
• 6) 매 세션 시작 시 부트스트랩을 강제한다.*
• 시스템 프롬프트에 “세션 시작 시 반드시: pwd → claude-progress.txt 읽기 → git log --oneline -20 → feature_list.json 검토 → init.sh로 서버 띄우고 기본 동작 검증 → 그 다음 새 기능” 의 흐름을 명시.
• 7) 매 세션 종료 시 클린 상태 강제.*
• Git 커밋(설명 풍부한 메시지) + 진행 파일 업데이트 없이는 세션을 “완료”로 표시하지 못하게 한다. 코드 변경 후 반드시 end-to-end 검증.

  6-2. OpenAI Codex 환경에서의 하네스 구축

OpenAI 사내 실험에서 사용한 패턴은 위와 결이 같지만, 기계적 강제에 좀 더 무게가 실린다 (InfoQ).

1) 구조화된 docs/ 디렉토리를 단일 진실의 소스로 만든다.

• 시스템 맵, 실행 계획(Plan.md), 디자인 명세(Documentation.md), 구현 노트(Implement.md).
• 디자인-아키텍처 문서 간 교차 링크는 린터로 검증한다 (링크가 깨지면 CI 실패).
• 2) 도메인 × 레이어 매트릭스를 정의한다.*
• 각 비즈니스 도메인을 고정된 레이어로 쪼개고, 의존성은 한 방향으로만 흐르게:
  • Types → Config → Repo → Service → Runtime → UI
• 이 규칙은 커스텀 린터와 구조 테스트로 강제. 권고 아님, 빌드 게이트.
• 3) Codex로 *린터 자체를 생성하게 한다.**
• 새 invariant가 필요해지면 “이런 규칙을 강제하는 린터를 짜라”고 Codex에 시키고, 결과 린터를 CI에 등록.
• 하네스가 하네스를 만든다.
• 4) 백그라운드 가비지 컬렉션 잡을 돌린다.*
• 골든 원칙을 레포에 인코딩.
• 스케줄된 Codex 작업이 이탈을 스캔하고 작은 리팩토링 PR을 자동 제출. 대부분 자동 머지.
• 5) 사람 리뷰를 에이전트 리뷰로 옮긴다.*
• PR을 끝까지 끌고 가기 위해 Codex가 자신의 변경을 로컬에서 직접 리뷰, 추가 에이전트 리뷰어를 로컬과 클라우드 양쪽에서 호출, 받은 피드백에 응답해 반복 — 모든 에이전트 리뷰어가 만족할 때까지 (앞서 언급한 “Ralph Wiggum Loop”).
• 사람은 원하면 리뷰할 수 있지만 필수는 아니다.
• 6) 관측 가능성(observability) 도구를 에이전트에 직접 연결한다.*
• 로그, 메트릭, 트레이스를 Codex가 직접 읽을 수 있게 해, 자가 진단과 자가 수정 루프를 닫는다.

  6-3. 어느 환경이든 통하는 원칙 다섯 가지

위 둘을 관통하는 공통 원칙을 다시 한 줄씩 정리하면 이렇다.

1. 레포지토리가 단일 진실의 소스다. 슬랙, 회의록, 머릿속에 있는 결정은 에이전트에겐 없는 결정이다.
2. Invariant는 기계적으로 강제하라. 권고문은 무력하다. 린터·테스트·CI 게이트로 잡아라.
3. 사람 리뷰가 아닌 에이전트 리뷰로 옮겨라. 검증을 에이전트 사이에서 닫는다.
4. 진행 상태와 기능 명세를 읽기 좋은 파일로 둬라. JSON/Markdown 어느 쪽이든, 시작 부트스트랩이 정해진 자리에 있을 것.
5. 막힐 때마다 환경에 인코딩하라. 사람이 직접 짜는 게 아니라, 빠진 것을 환경에 추가해서 다음번에 에이전트가 해결할 수 있게 만든다.

---

7. Harness-as-a-Service — 흐름은 거스를 수 없다

여기서 시야를 한 단계 위로 올려 보자.

지금까지 본 것은 각 팀이 자기 레포 안에서 하네스를 직접 짜는 모습이었다. 그러나 패턴이 충분히 합의되고 표준이 잡히면, 외부에서 가져다 쓰는 형태 — Harness-as-a-Service — 로 진화할 가능성은 매우 높다.

이미 그 초기 형태들이 보인다. LangChain의 deepagents 라이브러리는 하네스 구축 자체를 패키지로 제공한다. LangSmith는 에이전트가 무엇을 하는지 디버깅·평가·배포까지를 묶어 에이전트 엔지니어링 플랫폼으로 자리매김했다. Anthropic의 Claude Agent SDK도 본질은 “범용 하네스”를 SDK로 풀어놓은 것이다.

이게 서비스 영역으로 확장된다는 건 무슨 뜻일까. 가능한 그림 몇 가지를 그려 보면:

• 하네스 템플릿 마켓플레이스. “SaaS 백엔드용 하네스”, “데이터 파이프라인용 하네스”, “모바일 앱용 하네스” 같은 도메인별 사전 구축 하네스. 새 프로젝트 시작 시 가져다 쓰는 create-react-app의 에이전트 버전.
• 트레이스 분석 SaaS. 우리가 돌린 에이전트 실행을 자동 분석해 하네스의 어디가 약한지 — 어떤 도구 호출이 자주 실패하는지, 어떤 컨텍스트 주입이 비효율적인지 — 알려주는 서비스. LangChain이 “에이전트가 자기 트레이스를 분석해 하네스 수준 실패 모드를 식별·수정하는” 연구를 진행 중이라고 밝히고 있다.
• 컴플라이언스·거버넌스 레이어. 규제 산업에서 에이전트가 절대 못 하게 막아야 하는 행동들을 표준 하네스 모듈로 제공.
• 에이전트 간 협업 프로토콜. 여러 회사의 에이전트가 같은 작업을 분담하기 위한 공유 하네스 인터페이스 — MCP가 그 첫걸음이다.
  그런데 사실 이런 그림보다 더 중요한 것이 있다. 흐름의 방향이다.

물이 더 낮은 곳으로 흐르듯, 시장은 더 나은 도구로 흘러간다. 피쳐폰을 아이폰이 대체했고, SMS를 WhatsApp이 대체했다. 더 적은 사람의 더 적은 노력으로 더 좋은 결과를 내는 방식이 나타나면, 사람들은 결국 그쪽으로 흘러간다. 잠시 망설일 수는 있어도, 거스를 수는 없다.

지금 우리는 그 변곡점에 있다. 사람이 코드를 한 줄도 쓰지 않고 100만 줄 제품이 출시되는 광경을 봤다. 5개월짜리 실험이지만, 발견된 패턴은 이미 일반화되고 있다. Claude Code, Codex, Cursor, Aider — 각자 다른 이름과 다른 디자인으로 같은 방향을 가리킨다.

물론 모델이 더 좋아질수록 하네스에 있던 일부 기능은 모델 안으로 흡수된다. LangChain이 정확히 짚는다 — 계획 수립, 자가 검증, 장기 일관성 같은 능력이 모델 안에 네이티브로 들어가면, 그만큼 컨텍스트 주입은 줄어들 것이다. 그렇다면 하네스의 가치는 점점 사라질까?

프롬프트 엔지니어링이 그랬듯 사라지지 않는다. 모델이 똑똑해질수록 더 유능한 하네스 위에서 빛이 난다. 잘 구성된 환경, 알맞은 도구, 영속적인 상태, 검증 루프 — 이것들은 모델의 기본 지능과 독립적으로 모든 모델을 더 효율적으로 만든다 (LangChain).

다만 한 가지 솔직히 짚어야 할 열린 문제*가 있다. Martin Fowler가 정확히 지적한 부분이다 — *하네스는 코드가 어떻게 작성·조직되는지는 강제할 수 있지만, 그 코드가 사용자가 정말 원하는 일을 하는지는 아직 검증하지 못한다. 아키텍처 일관성과 기능적 정확성은 다른 문제이고, 후자는 에이전트·제품·실제 사용자 행동 사이의 더 깊은 피드백 루프를 요구한다 (Adithya Giridharan, citing Martin Fowler).

이게 다음의 큰 숙제다. 하네스 엔지니어링의 첫 번째 챕터 — 아키텍처 일관성을 어떻게 기계적으로 강제하는가 — 는 어느 정도 풀렸다. 두 번째 챕터 — 사용자가 진짜 원하는 것을 만들어 내는지 어떻게 자동으로 검증하는가 — 는 열려 있다.

---

마치며: 누가 다음 시대의 엔지니어가 되는가

“엔지니어 = 코드를 쓰는 사람”이라는 정의는 이미 흔들리고 있다. 새로운 정의는 환경 설계자*에 가깝다. 레포지토리를 에이전트가 추론할 수 있게 구조화하는 사람, 아키텍처 제약을 에이전트가 *실수로도 어길 수 없게 인코딩하는 사람, 시스템을 에이전트가 자기 실패를 진단할 수 있도록 계측하는 사람.

하네스 엔지니어링은 그 새로운 정의에 가장 가까이 다가간 이름이다.

모델은 지능을 담고, 하네스는 그 지능을 유용하게 만든다. (LangChain)

다음 5년의 소프트웨어 엔지니어링이 어떻게 보일지 알고 싶다면, 지금 자기 레포에 AGENTS.md를 하나 두는 것에서 시작해 보자. 처음엔 한 페이지짜리 인수인계장이지만, 다음 세션에서 에이전트가 그걸 읽고 일하는 모습을 보면, 왜 이 흐름이 거스를 수 없는지 직관적으로 느껴질 것이다.

물은 더 낮은 곳으로 흐른다. 그리고 더 나은 도구는 결국 쓰이게 된다.

---

참고 자료

• LangChain — The Anatomy of an Agent Harness (Vivek Trivedy, 2026)
• Anthropic — Effective harnesses for long-running agents (Justin Young, 2025)
• OpenAI — Harness engineering: leveraging Codex in an agent-first world
• Ryan Lopopolo (OpenAI) — Harness Engineering: How to Build Software When Humans Steer, Agents Execute (YouTube)
• InfoQ — OpenAI Introduces Harness Engineering
• Adithya Giridharan — OpenAI's Harness Engineering Post Is a Blueprint for the Agent-First Era
• Milvus — What Is Harness Engineering for AI Agents?
• awesome-harness-engineering (GitHub)