하네스 엔지니어링? 요즘 AI 업계에 화두가 되고 있는 말이다. 과연 하네스 엔지니어링이 뭔지 기본부터 파악해보고자 한다.
LangChain이 모델을 한 번도 바꾸지 않고 벤치마크 순위를 25단계 끌어올렸다. Terminal Bench 2.0에서 52.8%였던 점수가 66.5%로 뛰었고, Top 30에서 Top 5에 진입했다. 바뀐 건 모델을 감싸는 시스템뿐이었다.
핵심 요약
- 하네스 엔지니어링은 AI 에이전트를 프로덕션에서 안정적으로 굴리기 위한 제어 인프라 설계 분야다
- 프롬프트 엔지니어링(말하기) -> 컨텍스트 엔지니어링(먹이기) -> 하네스 엔지니어링(수용하기)으로 진화했다
- Meta가 Manus를 약 2조 원에 인수한 이유도 모델이 아닌 하네스의 가치 때문이다
에이전트 = 모델 + 하네스
모델이 아무리 뛰어나도 하네스 없이는 프로덕션에서 쓸 수 없다. 이게 2026년 들어 확실해진 사실이다.
하네스(Harness)는 원래 말의 마구를 뜻한다. 말의 힘을 안전하게 제어하고 원하는 방향으로 이끄는 도구다. AI 에이전트에서도 같은 역할을 한다. 모델이 지능을 제공하면, 하네스가 그 지능을 쓸 만하게 만든다. 도구 호출 처리, 메모리 관리, 권한 제어, 검증, 로깅 — 모델을 제외한 거의 모든 것이 하네스에 해당한다.
Philipp Schmid는 이걸 컴퓨터에 비유했다. 모델은 CPU, 컨텍스트 윈도우는 RAM, 하네스는 OS다. CPU가 아무리 빠르다 한들 OS 없이 애플리케이션을 돌릴 수는 없다.
이 용어가 공식적으로 등장한 건 2026년 2월이다. HashiCorp 공동 창업자 Mitchell Hashimoto가 블로그에서 이름을 붙였고, 며칠 뒤 OpenAI가 “Harness Engineering“이라는 제목의 공식 포스트를 발표하면서 빠르게 퍼졌다. Martin Fowler의 기술 블로그에서 Birgitta Böckeler가 체계적인 프레임워크를 정리한 것도 개념 정립에 크게 기여했다.
By Ryan Lopopolo, Member of the Technical Staff
출처: Harness engineering: leveraging Codex in an agent-first world
지금은 LangChain의 State of Agent Engineering 조사 기준으로 57.3%의 조직이 에이전트를 프로덕션에서 운영 중이다. “에이전트를 도입할까”가 아니라 “어떻게 안정적으로 돌릴까”가 핵심 질문이 된 셈이다.
프롬프트에서 하네스까지, 3단계 진화
하네스 엔지니어링이 갑자기 하늘에서 떨어진 개념은 아니다. 프롬프트 엔지니어링에서 출발해 단계적으로 확장된 결과다.
| 시기 | 접근법 | 비유 | 핵심 |
|---|---|---|---|
| 2024 | 프롬프트 엔지니어링 | AI에게 “말하기” | CoT, few-shot, role 지정 |
| 2025 | 컨텍스트 엔지니어링 | AI에게 “먹이기” | RAG, 메모리, 도구 통합 |
| 2026 | 하네스 엔지니어링 | AI를 “수용하기” | 가드레일, 샌드박스, 피드백 루프 |
세 계층은 대체가 아니라 중첩 관계다. 하네스가 컨텍스트를 포함하고, 컨텍스트가 프롬프트를 포함한다. 복잡도에 따라 필요한 계층이 달라진다. 이메일 주소 검증은 프롬프트만으로 충분하다. 기존 코드베이스 안에서 검증하려면 컨텍스트가 필요하다. 전체 검증 시스템을 구축하고 유지하려면 하네스가 요구된다.
프롬프트 엔지니어링이 “오른쪽으로 돌아”라는 명령이라면, 하네스 엔지니어링은 도로와 가드레일, 신호 체계 전체를 설계해서 10대의 차량이 동시에 안전하게 달리게 하는 것이다.
그런데 하네스는 구체적으로 어떻게 작동할까.
Guides와 Sensors, 이중 제어 구조
Martin Fowler 블로그에서 Böckeler가 정리한 핵심 구조는 두 축으로 나뉜다.
Guides(피드포워드 제어)는 에이전트가 행동하기 전에 방향을 잡아준다. 아키텍처 문서, 코딩 관례, 부트스트랩 지침 같은 것이다. 첫 시도에서 괜찮은 결과를 얻을 확률을 높이는 역할이다.
Sensors(피드백 제어)는 에이전트가 행동한 뒤 출력을 관찰하고 자기 수정을 가능하게 한다. 테스트 실행 결과, 린터 출력, 코드 리뷰가 여기에 해당한다.
피드백에만 의존하면 같은 실수를 반복한다. 피드포워드에만 의존하면 규칙이 실제로 작동하는지 알 수 없다. 둘 다 필요하다.
출처: Martin Fowler – Harness engineering for coding agent users
각 제어는 다시 Computational(결정론적)과 Inferential(추론적)으로 나뉜다. 린터나 타입 체커처럼 빠르고 안정적인 계산적 검증과, LLM as Judge 같은 느리지만 의미론적 판단이 가능한 추론적 검증을 조합하는 것이 실무적으로 효과적이다.
실제로 뭐가 달라지는가 — 3가지 사례
이론은 이 정도면 충분하다. 실제로 하네스가 어떤 차이를 만드는지가 더 중요하다.
OpenAI Codex: 코드 한 줄 안 치고 100만 줄
OpenAI 내부 실험이 가장 극적인 사례다. 엔지니어 3명이 코드를 직접 타이핑하지 않는다는 제약 아래 약 100만 줄 규모의 프로덕션 애플리케이션을 만들었다. 1,500개 PR을 머지했고, 1인당 하루 평균 3.5개 PR을 처리했다.
이걸 가능하게 한 건 하네스의 네 가지 원칙이다.
- Progressive Disclosure: 에이전트에게 1,000페이지 매뉴얼이 아니라 지도를 준다
- Repository as System of Record: 컨텍스트에 없는 지식은 행동에 영향을 줄 수 없다
- Enforce Invariants, Not Implementations: 경계를 정의하되 솔루션은 정의하지 않는다
- Agent Legibility: 에이전트가 추론하기 좋은 구조로 코드를 최적화한다
엔지니어의 역할이 코드 작성에서 제약 설계로 완전히 바뀐 것이다. 직접 코딩하는 대신, 에이전트가 잘 작동할 수 있는 환경을 만드는 데 집중한다.
LangChain: 모델 그대로, 순위만 25단계 상승
앞서 언급한 LangChain Deep Agents 사례를 좀 더 들여다보면 흥미롭다. 이들은 모델을 고정한 채 시스템 프롬프트, 도구, 미들웨어 훅 세 가지만 조정했다. 그중 가장 효과가 컸던 건 PreCompletionChecklistMiddleware — 에이전트가 종료하기 전 검증 패스를 강제하는 단일 훅이었다.
출처: LangChain Blog – Improving Deep Agents with harness engineering
13.7%p 향상의 상당 부분이 이 검증 훅 하나에서 나왔다는 점이 시사하는 바가 크다. 복잡한 기법이 아니라 “끝내기 전에 한 번 더 확인해”라는 단순한 제어가 가장 큰 효과를 낸 셈이다.
Claude Code: 단일 에이전트의 반격
Anthropic의 Claude Code는 CLAUDE.md 프로젝트 컨텍스트와 JIT 검색을 통해 95%의 컨텍스트 감소를 달성했다. 더 주목할 점은, 잘 하네스된 단일 에이전트가 5개 전문 에이전트를 능가한 사례가 나왔다는 것이다. 멀티 에이전트 복잡성에 뛰어들기 전에 하나의 에이전트를 제대로 하네스하는 것이 먼저라는 실무적 교훈이다.
Meta가 2조 원을 쓴 이유
Meta가 Manus를 약 $2B(약 2조 원)에 인수한 건 2025년 12월이다. Manus가 사용하는 모델은 Anthropic이나 OpenAI의 파운데이션 모델이다. 자체 모델이 아니다. Meta가 산 건 6개월간 5번 재구축한 하네스 아키텍처였다. 매번 재구축할 때마다 안정성과 태스크 완료율이 올라갔다.
같은 맥락에서 Vercel의 사례도 흥미롭다. 에이전트 도구의 80%를 제거했더니 오히려 성능이 좋아졌다. 선택지가 줄어드니 혼란이 줄고, 토큰 사용이 줄고, 성공률이 올라갔다. “더 많은 기능”이 아니라 “더 나은 설계”가 답이었다.
이 사례들이 공통적으로 말하는 것은 명확하다. 모델은 상품(commodity)이 됐고, 하네스가 해자(moat)가 됐다.
아직 풀리지 않은 문제들
솔직히 하네스 엔지니어링이 만능은 아니다.
하네스 자체가 복잡해지면 그것 자체로 버그와 유지보수 부담이 생긴다. “하네스가 제품이 되는 순간 자체적인 드리프트가 시작된다”는 지적은 유효하다. 장기 실행 세션에서 에이전트 메모리가 끊기는 문제도 여전히 미해결이다.
에이전트가 생성한 코드의 저작권 문제도 법적으로 불확실한 상태다. 100만 줄의 에이전트 생성 코드를 누가 소유하는가? 에이전트가 프로덕션에서 일으킨 오류의 책임은 누구에게 있는가? 아직 답이 없다.
그리고 더 근본적인 질문이 있다. 미래 모델이 현재 하네스가 담당하는 기능을 네이티브로 흡수하면 어떻게 될까. 이 가능성 때문에 하네스를 모듈화하고, 필요 없어진 부분은 과감히 걷어내는 “Build to Delete” 전략이 필요하다.
인사이트
하네스 엔지니어링은 엔지니어의 역할 자체를 바꾸고 있다. 코드 작성자에서 제약 설계자, 피드백 루프 빌더, 품질 큐레이터로의 전환이다. OpenAI 사례처럼 코드를 직접 치지 않으면서도 프로덕션 수준의 소프트웨어를 만들어내는 방식이 점점 현실이 되고 있다.
당장 할 수 있는 가장 작은 단위는 AGENTS.md(또는 CLAUDE.md) 파일 하나를 만드는 것이다. 프로젝트의 구조, 관례, 불변량을 100줄 정도로 정리해서 리포지토리 루트에 두는 것만으로 에이전트 행동의 일관성이 확 달라진다. 프롬프트 10개 짜는 것보다 이 파일 하나가 낫다.
마무리
결론부터 말하면, 더 좋은 모델을 기다리는 것은 전략이 아니다. 지금 쓸 수 있는 모델로 하네스를 잘 설계하는 것이 프로덕션 성공의 핵심이다. LangChain이 모델 안 바꾸고 순위를 25단계 올린 것처럼, 차이는 모델이 아니라 모델을 감싸는 시스템에서 나온다.
개발자라면 CLAUDE.md 파일 하나부터 시작해보면 좋다. 거창한 프레임워크가 아니라, 에이전트가 읽을 수 있는 지도 한 장이 모든 것의 출발점이다.
참고 자료
- OpenAI – Harness engineering: leveraging Codex in an agent-first world
- LangChain Blog – Improving Deep Agents with harness engineering
- Martin Fowler – Harness engineering for coding agent users
- Aakash Gupta – 2025 Was Agents. 2026 Is Agent Harnesses.
- Philipp Schmid – The importance of Agent Harness in 2026
- MorphLLM – Agent Engineering: Harness Patterns, IMPACT Framework
- DecodingAI – Agentic Harness Engineering
- Channel.io – 하네스 엔지니어링이란?
