하네스 엔지니어링 | AI 에이전트 시대의 새로운 핵심 역량 2026

2024년에는 프롬프트를 잘 쓰는 사람이 AI를 잘 쓰는 사람이었다. 2025년에는 맥락(Context)을 잘 설계하는 사람이 차별화되었다. 그렇다면 2026년, AI를 가장 잘 다루는 사람은 누구인가? 바로 하네스(Harness)를 설계하는 사람이다.

AI 모델은 이미 충분히 똑똑해졌다. 코드를 생성하고, 문서를 작성하며, 복잡한 추론도 해낸다. 그런데 왜 여전히 AI 에이전트가 장시간 작업에서 엉뚱한 방향으로 달리거나, 같은 실수를 반복하거나, 자기가 만든 결과물을 스스로 검증하지 못하는 일이 벌어지는가? 문제는 모델의 지능이 아니다. 모델을 둘러싼 시스템이 문제다.

하네스 엔지니어링은 이 정확한 지점을 공략한다. AI 모델이 안정적으로 작동할 수 있는 환경 자체를 설계하는 기술이다. 이 글에서는 하네스 엔지니어링이 무엇인지, 왜 지금 이 개념이 폭발적으로 부상했는지, 그리고 실무에서 어떤 형태로 적용되는지를 구체적 사례와 데이터를 기반으로 분석한다.

1

하네스 엔지니어링의 정체: 모델이 아니라 마구(馬具)가 핵심이다

'하네스(Harness)'는 원래 말을 제어하기 위해 장착하는 고삐, 안장, 줄 등의 장비를 뜻한다. AI 맥락에서 하네스란 AI 모델을 감싸고 있는 모든 인프라, 제약 조건, 피드백 루프, 도구, 권한 체계를 가리킨다. AI 모델이 두뇌(엔진)라면, 하네스는 그 두뇌가 실제로 유용한 작업을 수행할 수 있게 만드는 나머지 모든 것이다.

LangChain은 이를 명쾌하게 정의했다. "하네스란 모델 자체가 아닌 모든 코드, 설정, 실행 로직이다. 순수한 모델은 에이전트가 아니다. 하네스를 입혀야 비로소 에이전트가 된다." 이 공식은 업계 전반에서 통용되고 있다.

Agent = Model + Harness

이 등식이 2026년 AI 개발의 핵심 패러다임이다. 모델 성능이 아무리 뛰어나도, 하네스 없이는 장시간 작업에서 맥락을 잃고, 아키텍처 경계를 무시하며, 자기 생성물의 품질을 과대평가하는 문제가 반복된다.

하네스 엔지니어링이 프롬프트 엔지니어링이나 컨텍스트 엔지니어링과 근본적으로 다른 지점은 범위에 있다. 프롬프트 엔지니어링은 모델에게 무엇을 물을지를 다루고, 컨텍스트 엔지니어링은 모델이 추론 시점에 무엇을 볼지를 최적화한다. 반면 하네스 엔지니어링은 컨텍스트가 언제 로드되는지, 어떤 도구가 활성화되는지, 어떤 행동이 허용되는지, 실패 시 어떻게 처리하는지, 그리고 어떤 조건을 충족해야 작업이 "완료"로 인정되는지까지 아우른다.

핵심은 이 세 가지가 교체 관계가 아니라 누적 관계라는 사실이다. 하네스 엔지니어링은 프롬프트 엔지니어링과 컨텍스트 엔지니어링을 모두 포함한다. 이전 시대의 기술이 쓸모없어지는 게 아니라, 더 큰 프레임워크 안에 흡수되는 것이다.

2

왜 지금인가: 하네스 엔지니어링이 2026년 화두가 된 배경

2025년 말부터 AI 에이전트는 단순한 텍스트 생성을 넘어 실제 코드를 작성하고, 도구를 호출하며, 장시간에 걸친 복잡한 작업을 수행하기 시작했다. 유용할 만큼 능력이 올라갔지만, 동시에 신뢰하기엔 아직 불안정한 단계에 진입한 것이다.

Andrej Karpathy(전 OpenAI, 테슬라 AI 리더)가 2025년 12월에 공유한 관찰이 상징적이다. 그의 작업 방식이 "대부분 수동 코딩 + 약간의 AI 도움"에서 "대부분 에이전트 기반 코딩 + 약간의 수동 편집"으로 역전(inversion)되었다는 내용이었다. 모델이 승리한 것처럼 들리지만, 실상은 달랐다. 에이전트가 충분히 일관성을 갖추게 된 바로 그 순간, 실제 환경에서 얼마나 취약한지가 동시에 드러났다. 테스트를 실행하지 않고 기능 완료를 선언하거나, 장시간 작업에서 목표를 잃거나, 전체 아키텍처를 무시하는 국소적 수정을 반복하는 문제가 속출했다.

이런 고통 속에서 Mitchell Hashimoto(HashiCorp 창업자, Terraform, Vagrant 등의 제작자)가 2026년 2월 초 자신의 블로그에서 핵심 원칙을 정립했다. "에이전트가 실수할 때마다, 다음번에 잘하길 바라지 마라. 그 특정 실수를 같은 방식으로 반복할 수 없도록 환경 자체를 엔지니어링하라." AGENTS.md를 실제 실패 사례 기반으로 개선하고, 스크립트와 린터와 검증 도구를 추가해서 에이전트가 스스로 작업을 검증하고 수정할 수 있게 만들라는 제안이었다.

그리고 2026년 2월 11일, OpenAI Codex 팀이 결정적인 사례를 공개했다. 엔지니어 3명이 5개월간 단 한 줄의 코드도 직접 타이핑하지 않고 약 100만 줄 규모의 소프트웨어 제품을 구축한 실험이었다. 1,500개 이상의 PR(풀 리퀘스트)이 열리고 병합되었으며, 엔지니어 1인당 하루 평균 3.5개의 PR을 처리했다. 이 숫자는 팀이 7명으로 늘어난 후에도 오히려 증가했다.

같은 시기 Anthropic도 장기 실행 에이전트를 위한 하네스 설계 연구를 잇달아 발표했다. 2025년 11월에 공개된 첫 번째 연구에서는 초기화 에이전트와 코딩 에이전트를 분리하고, 세션 간 구조화된 아티팩트로 맥락을 전달하는 패턴을 제시했다. 2026년 3월에 발표된 후속 연구에서는 GAN(생성적 적대 신경망)에서 영감을 받은 생성기-평가기 구조의 멀티 에이전트 아키텍처를 선보였다. 플래너, 제너레이터, 이벨류에이터 3개 에이전트가 협업하는 이 구조로 복잡한 풀스택 애플리케이션을 수 시간에 걸쳐 자율적으로 생성하는 데 성공했다.

3

실전 사례로 본 하네스의 위력: 모델을 바꾸지 않고 성능을 바꾸다

하네스 엔지니어링의 위력을 가장 극적으로 보여준 사례는 LangChain의 실험이다. LangChain은 자사의 코딩 에이전트(Deep Agents)를 Terminal Bench 2.0 벤치마크에서 테스트했다. 모델은 전혀 바꾸지 않고 하네스만 개선한 결과, 점수가 52.8%에서 66.5%로 13.7포인트 상승했다. 순위로 환산하면 30위권 밖에서 상위 5위로 도약한 것이다. 같은 두뇌에 더 나은 작업 환경을 제공했을 뿐인데, 전혀 다른 수준의 성과가 나온 셈이다.

기업 수준에서의 적용 사례도 속속 등장하고 있다. Stripe는 내부 AI 에이전트 시스템 'Minions'를 통해 매주 1,300건 이상의 PR을 병합하고 있다. 인간이 작성한 코드는 한 줄도 포함되지 않는다. 이 규모가 가능한 이유는 격리된 실행 환경, 엄격한 CI(지속적 통합) 제한, 에스컬레이션 규칙 등 하네스 인프라 덕분이다.

토스(Toss)의 기술 블로그에서는 같은 AI를 사용하더라도 엔지니어 간 생산성 격차가 10배 이상 벌어지는 현상을 분석했다. 핵심 차이는 작업 전에 컨텍스트를 먼저 세팅하느냐, 아니면 바로 작업을 시키느냐에 있었다. 레포의 코딩 가이드라인, 린트 규칙, 기존 코드 패턴을 에이전트에게 사전 주입하는 엔지니어의 결과물이 월등했다. 개인의 '슈퍼 파워'를 넘어 팀의 '표준'으로 이를 확산하는 방법론이 곧 하네스 엔지니어링이라는 분석이었다.

Anthropic의 실험도 인상적이다. 단일 에이전트(솔로)로 "2D 레트로 게임 메이커"를 만들게 했을 때는 20분 만에 9달러의 비용으로 결과물이 나왔지만, 게임의 핵심 기능인 플레이 모드가 작동하지 않았다. 반면 플래너-제너레이터-이벨류에이터 구조의 하네스를 적용한 결과, 6시간과 200달러의 비용이 들었으나 16개 기능이 구현된 완성도 높은 애플리케이션이 만들어졌다. 비용은 20배 이상이었지만, 실제로 작동하는 제품과 작동하지 않는 데모의 차이는 비교 자체가 무의미하다.

4

하네스 설계의 핵심 원칙: 백과사전이 아닌 지도를 만들어라

OpenAI Codex 팀이 100만 줄의 코드를 에이전트로 유지보수하면서 얻은 가장 중요한 교훈은 "지도를 줘라, 1,000페이지짜리 매뉴얼을 주지 마라"는 것이었다.

거대한 지시 파일은 실제 작업과 코드, 관련 문서를 밀어내며 에이전트가 핵심 제약 조건을 놓치거나 잘못된 방향으로 최적화하게 만든다. 모든 것이 중요하면 아무것도 중요하지 않다. 에이전트는 의도적으로 탐색하는 대신 국소적 패턴 매칭에 빠진다.

이 문제의 해법이 점진적 공개(Progressive Disclosure)이다. AGENTS.md(또는 Claude 환경에서는 CLAUDE.md)를 약 100줄 수준의 간결한 "목차"로 유지하고, 심층적인 지식은 구조화된 docs/ 디렉터리에 배치한다. 에이전트는 작고 안정적인 진입점에서 시작해서 필요할 때 더 깊은 정보원을 참조하는 방식으로 작동한다.

구체적으로 OpenAI 팀의 저장소 지식 체계는 다음과 같은 층위로 구성되었다.

첫째, 설계 문서(Design Documentation)가 카탈로그화되고 인덱싱된다. 검증 상태와 에이전트 우선 운영 원칙을 정의하는 핵심 신념(core beliefs) 세트가 포함된다.

둘째, 아키텍처 문서(Architecture Documentation)가 도메인과 패키지 레이어링의 최상위 지도를 제공한다. 각 비즈니스 도메인은 고정된 레이어 세트(Types → Config → Repo → Service → Runtime → UI)로 분할되며, 의존성 방향이 엄격하게 검증된다.

셋째, 품질 문서(Quality Document)가 각 제품 도메인과 아키텍처 레이어의 등급을 매기고, 시간 경과에 따른 격차를 추적한다.

넷째, 실행 계획(Execution Plans)이 일급 아티팩트로 취급된다. 진행 상황과 결정 로그가 저장소에 직접 체크인되며, 활성 계획, 완료된 계획, 알려진 기술 부채가 모두 버전 관리된다.

OpenAI 팀은 이런 제약 조건 강제를 "마이크로매니징이 아닌 인베리언트(불변 조건) 강제"라고 표현했다. 예를 들어 데이터 경계에서 반드시 파싱을 수행하도록 요구하지만, 특정 라이브러리(Zod 등)를 지정하지는 않는다. 큰 틀의 경계를 엄격히 유지하되, 그 안에서의 구현은 에이전트(또는 팀)에게 자유를 부여하는 방식이다. 대규모 엔지니어링 플랫폼 조직을 운영하는 것과 동일한 철학이다.

커스텀 린터가 이 시스템에서 핵심적 역할을 한다. 구조화된 로깅, 스키마 및 타입의 명명 규칙, 파일 크기 제한, 플랫폼별 신뢰성 요구사항을 정적으로 강제한다. 린터가 커스텀이기 때문에 오류 메시지에 수정 방법을 포함시켜 에이전트의 컨텍스트에 자동 주입할 수 있다. 인간 중심 워크플로에서는 이런 규칙이 지나치게 까다롭게 느껴질 수 있지만, 에이전트 환경에서는 한 번 인코딩하면 모든 코드에 동시에 적용되는 증폭기(multiplier)가 된다.

5

OpenAI와 Anthropic의 하네스 전략 비교: 두 거인의 접근법

하네스 엔지니어링에 대한 OpenAI와 Anthropic의 접근법은 철학적 차이를 보인다.

OpenAI는 인프라 중심 접근을 취한다. Codex 에이전트가 저장소 전체를 관리하며, 제품 코드, 테스트, CI 설정, 릴리스 도구, 내부 개발자 도구, 문서, 평가 하네스, 리뷰 코멘트, 저장소 관리 스크립트까지 모든 것을 에이전트가 생산한다. 인간은 우선순위를 결정하고, 사용자 피드백을 수용 기준으로 전환하며, 결과를 검증하는 역할에 집중한다. 에이전트가 어려움을 겪으면 "더 잘해봐"가 아니라 "무엇이 빠져있는가"를 진단하고, 그 수정 자체도 Codex에게 맡긴다. 핵심 키워드는 환경 설계와 레버리지(leverage)이다.

Anthropic은 에이전트 분리와 전문화 중심 접근을 취한다. 단일 에이전트의 한계를 인정하고, 역할별로 특화된 에이전트를 조합하는 데 주력한다. 플래너가 사양서를 작성하고, 제너레이터가 구현하며, 이벨류에이터가 Playwright를 활용해 실제 애플리케이션을 클릭하며 테스트한다. 스프린트 계약(Sprint Contract)이라는 메커니즘으로 구현 전에 "완료"의 기준을 합의하는 과정이 독특하다. 핵심 키워드는 역할 분리와 피드백 품질이다.

두 접근법은 배타적이지 않다. 실무에서는 상황에 따라 혼합하여 적용하는 것이 현실적이다. 중요한 것은 모델에만 의존하지 않고, 모델 주위의 시스템을 의식적으로 설계한다는 공통 철학이다.

6

개발자 역할의 재정의: 코드 타이피스트에서 환경 설계자로

하네스 엔지니어링이 부상하면서 소프트웨어 엔지니어의 역할이 근본적으로 변하고 있다. 사라지는 것이 아니라, 이동(shift)하는 것이다.

매 줄의 코드를 직접 타이핑하는 시간은 줄어든다. 대신 에이전트가 유용한 작업을 수행하면서도 주변의 모든 것을 망가뜨리지 않는 "서식지(habitat)"를 설계하는 시간이 늘어난다. 기계가 읽을 수 있는 문서를 작성하고, 평가 체계(evals)를 설계하고, 샌드박스와 권한 경계를 구축하고, 구조적 테스트와 로그, 트레이스, 재생 가능성(replayability)을 구현하는 데 더 많은 역량이 필요해진다.

OpenAI 팀의 표현이 이를 정확히 포착한다. "우리의 가장 어려운 과제는 이제 환경, 피드백 루프, 제어 시스템을 설계하는 것이다. 에이전트가 대규모에서 복잡하고 신뢰성 있는 소프트웨어를 구축하고 유지보수하도록 돕는 시스템 말이다."

이 변화는 비개발자에게도 시사점이 크다. 하네스 엔지니어링의 원리는 코딩 에이전트에만 국한되지 않는다. 고객 서비스 챗봇에 가드레일을 설정하고, 데이터 분석 에이전트의 출력을 검증하는 파이프라인을 구축하며, 콘텐츠 생성 에이전트의 톤과 범위를 제어하는 것 모두 하네스 엔지니어링의 영역이다. AI를 단순히 사용하는 것과 AI가 작동하는 환경을 설계하는 것 사이의 격차가, 2026년 이후 AI 활용 능력의 핵심 분기점이 될 가능성이 높다.

모델이 계속 발전하면 하네스의 일부 구성 요소는 불필요해질 수 있다. 하지만 Anthropic의 연구자가 도달한 결론이 설득력 있다. "모델이 향상될수록 흥미로운 하네스 조합의 공간이 줄어드는 것이 아니라 이동한다. AI 엔지니어의 흥미로운 작업은 그 다음의 새로운 조합을 찾는 것이다." 더 강력한 모델은 더 야심 찬 작업을 가능하게 하고, 그 야심 찬 작업은 또 다른 수준의 하네스를 요구한다. 이 순환이 당분간 계속될 것이다.

하네스 엔지니어링은 프롬프트 한 줄을 잘 쓰는 기술의 연장선이 아니다. AI의 지능을 시연(demo)하는 단계에서 실제로 출하(ship)하는 단계로 넘어가면서 필연적으로 부상한 시스템 설계 역량이다.

지금 할 수 있는 가장 구체적인 첫 걸음은 이것이다. 현재 사용하고 있는 AI 에이전트의 로그를 열어서 어디서 실패하는지 관찰하라. 그 실패 패턴을 방지하는 규칙 하나를 AGENTS.md(또는 CLAUDE.md)에 추가하라. 이것이 하네스 엔지니어링의 시작이다.

2026년은 AI가 충분히 똑똑해진 해가 아니라, AI를 둘러싼 시스템이 충분히 정교해져야 하는 해이다. 모델은 이미 준비되었다. 이제 하네스를 준비할 차례다.