프롬프트에서 컨텍스트에서 하네스로 — AI 엔지니어링 3단 진화의 전체 그림

# 프롬프트에서 컨텍스트에서 하네스로 — AI 엔지니어링 3단 진화의 전체 그림

2026년 초, Mitchell Hashimoto(HashiCorp 공동 창업자)가 블로그에 짧은 글을 올렸다. AI 에이전트가 실수할 때마다 환경에 영구적인 수정을 넣는 작업을 “하네스 엔지니어링”이라 불렀다. 수주 뒤 OpenAI가, 그리고 Anthropic이 같은 단어를 썼다. Martin Fowler의 블로그에 올라왔고, AWS의 시니어 사이언티스트가 “2026년은 하네스 엔지니어링의 시대”라고 선언했다. 두 달 만에 업계 전체의 공식 언어가 됐다.

## TL;DR

• AI 엔지니어링이 3단계로 진화했다: 프롬프트 엔지니어링(지시문 품질) → 컨텍스트 엔지니어링(정보 제공 방식) → 하네스 엔지니어링(시스템 구축)

• OpenAI, Anthropic, Meta, Martin Fowler가 동시에 “하네스”를 말하기 시작했다

• SWE-bench의 몰락이 “하네스 > 모델”을 증명했다 — 같은 모델이 프레임워크에 따라 17문제 차이

• 하네스의 핵심 구성요소 6가지가 표준화되고 있다: CLAUDE.md, MCP, 라이프사이클 훅, 권한 모델, 피드백 루프, 서브에이전트 관리

• 하네스 엔지니어링은 실무자에게 이미 현실이다 — .claude/ 디렉토리 안에서 매일 일어나는 일

— -

## 1. Mitchell Hashimoto의 한 마디에서 시작된 물결

2026년 초, Mitchell Hashimoto가 자신의 블로그에 짧은 글을 올렸다. Vagrant와 Terraform, 그리고 HashiCorp을 만든 사람이다. 인프라 자동화의 선구자가 이번에는 AI 에이전트와 씨름하고 있었다.

### 말의 성격은 바꿀 수 없지만, 고삐는 바꿀 수 있다

그의 관찰은 단순했다. AI 코딩 에이전트를 쓰다 보면 같은 실수가 반복된다. 에이전트 자체를 고치는 건 불가능하다 — 모델은 블랙박스니까. 대신 에이전트가 작동하는 환경을 고칠 수 있다. 시스템 프롬프트에 규칙을 추가하고, 도구 호출에 제약을 걸고, 출력을 검증하는 센서를 다는 것이다.

이 작업을 그는 “에이전트의 하네스를 엔지니어링한다”고 표현했다. 하네스(harness)는 원래 말을 제어하기 위한 고삐와 안장을 뜻한다.

수주 뒤, OpenAI가 공식 블로그에서 “하네스 엔지니어링”이라는 기술 보고서를 발표했다. Anthropic이 장기 실행 에이전트의 하네스 설계에 관한 블로그 2편을 연속 게시했다. Martin Fowler의 블로그에 기사가 올라왔고, GitHub에는 awesome-harness-engineering 리포지토리가 등장했다.

한 사람의 블로그 포스트가 두 달 만에 업계의 공식 용어가 된 건, 모두가 같은 고통을 느끼고 있었기 때문이다. 모델은 충분히 똑똑해졌는데, 실전에서 쓸 만한 시스템을 만드는 건 여전히 어렵다는 고통.

— -

## 2. 3단 진화 — 프롬프트에서 컨텍스트에서 하네스로

4월 13일, aitimes는 AWS 한국 지사의 김영민 시니어 데이터 사이언티스트 인터뷰를 실었다. 그는 AI 엔지니어링의 진화를 세 단계로 정리했다.

### 1단계: 프롬프트 엔지니어링 (2022–2024)

ChatGPT가 등장하고, 사람들은 “어떻게 물어보면 더 좋은 답이 나오는지”에 집중했다. “너는 시니어 파이썬 개발자야”라는 역할 부여, 단계별 사고(chain-of-thought), 예시 제공(few-shot) — 이런 기법들이 쏟아졌다. 핵심은 지시문의 품질이었다. 같은 모델이라도 프롬프트를 어떻게 쓰느냐에 따라 결과가 크게 달라졌다.

### 2단계: 컨텍스트 엔지니어링 (2025)

모델이 더 똑똑해지면서 프롬프트의 영향력이 줄었다. 대신 어떤 정보를 얼마나 효율적으로 제공하느냐가 결정적이 됐다. RAG(검색 증강 생성), 벡터 데이터베이스, 컨텍스트 윈도우 관리 — 이런 것들이 핵심 역량이 됐다. 모델이 아는 것보다 모델에게 뭘 보여주느냐가 중요해진 것이다.

### 3단계: 하네스 엔지니어링 (2026)

에이전트 시대가 열리면서 컨텍스트만으로는 부족해졌다. 에이전트는 단순히 질문에 답하는 게 아니라 행동한다 — 코드를 쓰고, 파일을 만들고, API를 호출하고, 다른 에이전트를 실행한다. 이 행동을 제어하고, 모니터링하고, 실패 시 복구하는 시스템 전체를 설계하는 것이 하네스 엔지니어링이다.

비유하면 이렇다. 프롬프트 엔지니어링은 요리사에게 레시피를 잘 설명하는 것이다. 컨텍스트 엔지니어링은 좋은 재료를 제때 가져다주는 것이다. 하네스 엔지니어링은 주방 자체를 설계하는 것이다 — 동선, 도구 배치, 위생 규정, 화재 경보기까지 포함해서.

— -

## 3. OpenAI — “코더에서 하네스 설계자로”

2026년 2월, OpenAI는 하네스 엔지니어링 기술 보고서를 공식 블로그에 발표했다. 3명의 엔지니어가 코덱스(Codex) 에이전트를 활용해 대규모 코드베이스를 관리한 사례다.

### 더 많은 컨텍스트가 아니라, 더 나은 구조

이들은 코드를 직접 쓰는 시간보다 에이전트의 하네스를 설계하는 시간이 더 길었다. AGENTS.md 파일을 작성하고, 도구 호출 규칙을 정의하고, 테스트 자동화 훅을 걸고, 실패 시 복구 전략을 세우는 것이 주 업무가 된 것이다.

“1,000페이지짜리 문서를 에이전트에게 먹이는 것보다, 간단한 인덱스(AGENTS.md)와 구조적 맵을 제공하는 것이 훨씬 효율적이었다.”

이 관찰은 프롬프트 엔지니어링 시대의 상식을 뒤집는다. “더 많은 컨텍스트 = 더 좋은 결과”가 아니었다. 잘 구조화된 최소한의 컨텍스트와 적절한 실행 환경이 더 나은 결과를 만들었다. 이것이 바로 컨텍스트 엔지니어링에서 하네스 엔지니어링으로 넘어가는 전환점이다.

OpenAI는 이 보고서에서 엔지니어의 역할을 공식적으로 재정의했다 — 코더(coder)에서 하네스 설계자(harness designer)로. 코드를 쓰는 사람이 아니라, 코드를 쓰는 AI가 일하는 환경을 설계하는 사람. 이건 추상적인 비전이 아니라, 3명이 실제로 경험한 현실이었다.

— -

## 4. Anthropic — 가이드와 센서, 이중 제어의 하네스

Anthropic은 4월에 장기 실행 에이전트의 하네스 설계에 관한 블로그를 2편 연속 게시했다. 하네스의 내부 구조를 제어 이론(control theory)의 언어로 정리했다는 점에서 특히 가치가 있다.

### 피드포워드와 피드백

가이드(Guide) = 피드포워드 제어. 에이전트가 행동하기 전에 방향을 잡아주는 것이다. CLAUDE.md 파일에 프로젝트의 규칙과 컨벤션을 적는 것, 시스템 프롬프트에 역할과 제약 조건을 거는 것, 도구 접근 권한을 설정하는 것 — 이 모든 것이 가이드다. 에이전트가 잘못된 방향으로 가기 전에 미리 울타리를 치는 것이다.

센서(Sensor) = 피드백 제어. 에이전트가 행동한 후에 문제를 잡는 것이다. 가이드가 아무리 잘 설계돼 있어도 에이전트는 실수한다. 센서는 그 실수를 감지하고, 자동으로 수정하거나, 인간에게 알리는 역할을 한다. 테스트 실행, 로그 분석, 출력 검증, lint 검사가 센서에 해당한다.

Anthropic의 통찰은 가이드만으로는 불충분하고 센서만으로도 불충분하다는 것이다. 둘의 조합이 하네스의 본질이다. 자동차의 차선 이탈 경고(가이드)와 자동 긴급 제동(센서)이 함께 작동하는 것과 같다.

장기 실행 에이전트(수시간~수일)가 여러 컨텍스트 윈도우를 넘나들 때, 이전 윈도우의 계획과 교훈을 다음으로 어떻게 전달할 것인가. 이것이 2026년 에이전트 하네스의 가장 어려운 열린 문제 중 하나다.

— -

## 5. Martin Fowler — 소프트웨어 공학의 주류로 편입

Martin Fowler의 블로그에 “코딩 에이전트 사용자를 위한 하네스 엔지니어링” 기사가 올라왔다. 이 사실 자체가 중요한 신호다.

### AI 트렌드가 아니라 소프트웨어 공학의 표준 패턴

리팩터링, 마이크로서비스, CI/CD, 이벤트 소싱 — 지난 20년간 소프트웨어 엔지니어링의 핵심 패턴들이 그의 블로그를 거쳐갔다. 거기에 “하네스 엔지니어링”이 올라왔다는 건, 이 개념이 AI 전용 트렌드가 아니라 소프트웨어 공학 전체의 표준 패턴으로 인정받기 시작했다는 의미다.

Martin Fowler가 관심을 가진다는 건, 곧 시니어 엔지니어와 아키텍트들의 의사결정에 영향을 준다는 뜻이다. “우리 팀에 하네스 엔지니어를 채용해야 하나?” 같은 질문이 CTO 레벨에서 나오기 시작할 것이다. 아마 이미 나오고 있을 것이다.

하네스 엔지니어링이 Martin Fowler의 블로그에 올라왔다는 건, AI 전용 트렌드의 시대가 끝나고 소프트웨어 공학 전체의 표준 패턴으로 편입되는 시작점이다.

— -

## 6. SWE-bench의 몰락 — “하네스 > 모델”을 증명한 숫자

하네스 엔지니어링이 왜 중요한지를 가장 명쾌하게 보여주는 증거가 있다.

### 4배 성능 향상이 아니라 게이밍이었다

SWE-bench는 AI 코딩 에이전트의 실력을 측정하는 대표 벤치마크였다. 실제 GitHub 이슈를 해결하는 능력을 테스트한다. 2024년 8월 최고 점수는 약 20%였는데, 2026년 초 여러 시스템이 80%를 넘겼다. 4배 성능 향상처럼 보이지만, 실상은 달랐다. TianPan.co의 4월 9일 분석에 따르면, 이 성능 향상은 모델이 벤치마크에 훈련 시점에 노출된 결과라는 의혹이 지속적으로 제기됐다.

OpenAI는 결국 SWE-bench Verified를 공식 폐기하며 이렇게 밝혔다.

“개선 사항이 모델의 실제 소프트웨어 개발 능력의 의미 있는 향상을 반영하는 것이 아니라, 모델이 벤치마크에 얼마나 노출됐는지를 점점 더 반영하고 있다.”

### 17문제의 차이가 말해주는 것

더 흥미로운 데이터가 있다. 2026년 2월의 한 테스트에서, 같은 모델을 세 가지 다른 에이전트 프레임워크로 실행했더니 731문제 중 17문제의 차이가 났다. 모델은 동일하다. 바뀐 건 하네스(프레임워크, 오케스트레이션, 컨텍스트 검색, 파일 인덱싱)뿐이다. 이 17문제 차이가 의미하는 건 명확하다.

모델을 바꾸는 것보다 하네스를 바꾸는 것이 성능에 더 큰 영향을 줄 수 있다. 모델 전쟁이 아니라 하네스 전쟁이 시작된 것이다.

— -

## 7. 하네스의 해부학 — 6가지 핵심 구성요소

그렇다면 하네스란 구체적으로 무엇으로 이루어져 있는가? philschmid(Hugging Face), Milvus 등 여러 기술 블로그의 분석을 종합하면 6가지 핵심 구성요소가 반복적으로 등장한다.

### 프롬프트 프리셋과 도구 호출

1. 프롬프트 프리셋 (CLAUDE.md, AGENTS.md). 에이전트가 프로젝트를 이해하는 기반 문서다. 디렉토리 구조, 코딩 컨벤션, 테스트 명령어, 아키텍처 규칙을 담는다. CLAUDE.md(Anthropic), AGENTS.md(OpenAI), .cursorrules(Cursor) — 이름은 다르지만 역할은 같다. 에이전트에게 프로젝트의 “성격”을 알려주는 것이다.

2. 도구 호출 핸들링 (MCP). 에이전트가 외부 도구(파일 시스템, API, 데이터베이스 등)와 상호작용하는 방식을 제어한다. Anthropic의 MCP(Model Context Protocol)가 9,700만 설치를 돌파하며 사실상 표준이 됐다. 어떤 도구를 쓸 수 있는지, 어떤 파라미터로 호출하는지, 결과를 어떻게 검증하는지를 정의한다.

### 실행 제어와 안전장치

3. 라이프사이클 훅. 에이전트의 실행 전(pre)과 후(post)에 자동으로 실행되는 스크립트다. 코드를 작성하기 전에 lint를 돌리고, 코드를 작성한 후에 테스트를 실행하는 식이다. Claude Code의 hooks 시스템이 대표적 구현이다.

4. 권한 모델. 에이전트가 할 수 있는 것과 할 수 없는 것의 경계를 정의한다. 파일 읽기는 허용하지만 삭제는 금지, 특정 디렉토리만 접근 가능, 외부 API 호출은 승인 필요 — 이런 세분화된 권한 제어. 에이전트가 강력해질수록 권한 모델의 중요성도 커진다.

### 피드백과 오케스트레이션

5. 피드백 루프. Anthropic이 말한 “센서”에 해당한다. 에이전트의 출력을 자동으로 검증하고, 문제가 있으면 수정하거나 인간에게 알리는 메커니즘이다. 테스트 실패 시 자동 재시도, 코드 리뷰 자동화, 에이전트 행동 로그 분석이 포함된다.

6. 서브에이전트 관리. 복잡한 작업을 위해 메인 에이전트가 하위 에이전트를 실행하는 패턴이다. 각 서브에이전트의 역할, 입력, 출력, 실패 처리를 정의한다. 마이크로서비스 아키텍처에서 서비스 간 계약(contract)을 정의하는 것과 비슷하다.

이 6가지가 모여서 하나의 하네스를 구성한다. 그리고 이 하네스와 프레임워크의 차이를 이해하는 것이 중요하다.

프레임워크(LangChain, CrewAI)는 에이전트를 조립할 부품을 제공하는 설계도다. 하네스는 그 에이전트가 실제로 실행되는 공장 현장이다.

— -

## 8. 저커버그의 한 마디 — “모델은 범용, 하네스는 맞춤”

Meta의 마크 저커버그도 같은 흐름에 합류했다.

“기업별 맞춤 운영 레이어가 경쟁력이다.”

저커버그는 aitimes 인터뷰에서 이렇게 설명했다(간접 인용). 모델은 점점 범용화되고 있다. GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro — 이들의 성능 차이는 점점 줄어들고 있다. 어떤 모델을 쓰느냐보다, 그 모델 위에 어떤 운영 레이어를 쌓느냐가 기업의 경쟁력을 결정한다는 것이다.

자체 데이터를 어떻게 보호하면서 모델에 제공할 것인가. 업무 로직을 어떻게 에이전트의 실행 흐름에 녹여낼 것인가. 보안 규정을 어떻게 에이전트의 권한 모델에 반영할 것인가. 이것이 바로 각 기업이 자기만의 방식으로 설계해야 하는 맞춤형 하네스다.

### 제조업에서도 이미 일어나고 있다

PLM 전문가 Oleg Shilovitsky는 하네스를 3단계로 구분했다.

• 1단계: 도구 중심 — 에이전트가 파일 단위로 접근하는 수준

• 2단계: 워크플로우 중심 — 에이전트가 업무 흐름을 이해하는 수준

• 3단계: 제품 메모리 중심 — 에이전트가 제품의 복잡성 자체를 이해하는 수준

1단계에서 3단계로 갈수록 비즈니스 가치가 기하급수적으로 커진다. 그리고 3단계의 하네스는 절대로 범용적일 수 없다. 자동차 제조사의 하네스와 반도체 설계사의 하네스는 완전히 다른 모양이어야 한다. 이것이 저커버그가 말한 “맞춤 운영 레이어”의 실체다.

— -

## 9. 나의 하네스 — .claude/ 디렉토리 안에서 일어나는 일

여기서 개인적인 이야기를 하겠다. 나는 매일 하네스 안에서 일한다. 이론이 아니라 실전이다.

### 실전 하네스의 구조

내 프로젝트의 .claude/ 디렉토리에는 이런 것들이 들어 있다.

• CLAUDE.md: 프로젝트의 아키텍처, 파일 구조, 품질 기준, 워크플로우 규칙. 에이전트가 프로젝트를 이해하는 첫 번째 문서다.

• agents/: 역할 기반 서브에이전트 정의. researcher, writer, reviewer, adapter, editor — 각 에이전트의 역할, 도구, 품질 기준이 적혀 있다.

• skills/: 도메인 특화 지식. 플랫폼별 변환 규칙, 포맷 규칙, 스타일 가이드가 참조 문서로 정리돼 있다.

• commands/: 슬래시 명령 워크플로우. /blog-scout, /blog-write, /blog-adapt 같은 명령이 어떤 단계를 거치는지 정의돼 있다.

이 구조가 바로 하네스다. 에이전트 자체를 바꾸는 것이 아니라, 에이전트가 일하는 환경을 설계한 것이다. 에이전트가 실수하면 CLAUDE.md에 규칙을 추가한다. 새로운 도메인이 생기면 skills/에 참조 문서를 넣는다. 워크플로우가 복잡해지면 agents/에 새 역할을 정의한다.

Mitchell Hashimoto가 말한 “에이전트가 실수할 때마다 환경에 영구적 수정을 넣는 것”을 나는 매일 하고 있다. 이건 이론이 아니다. CLAUDE.md 파일을 열고 규칙을 한 줄 추가하는 것이 일상이다.

그리고 경험에서 말하건대, 하네스의 품질이 결과의 품질을 직접적으로 결정한다.

같은 Claude Opus 4.6 모델이 하네스가 빈약한 프로젝트에서는 엉뚱한 결과를 내놓고, 하네스가 잘 갖춰진 프로젝트에서는 놀라울 정도로 정확한 결과를 낸다. SWE-bench에서 같은 모델이 프레임워크에 따라 17문제 차이가 난 것과 정확히 같은 현상이다.

— -

## 마무리 — 하네스가 곧 경쟁력이다

첫째, AI 엔지니어링의 무게중심이 모델에서 시스템으로 이동했다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링이라는 3단 진화는 단순한 유행어 교체가 아니다. “AI에게 뭘 물어보는가”에서 “AI가 어떤 환경에서 일하는가”로 본질이 바뀐 것이다. OpenAI, Anthropic, Meta, Martin Fowler가 동시에 같은 말을 하기 시작한 건, 이 전환이 더 이상 선택이 아니라 필수가 됐다는 뜻이다.

둘째, SWE-bench의 몰락은 경고이자 기회다. 벤치마크 점수를 올리는 것이 실력이 아니라 게이밍이었다는 사실은, 모델 성능 경쟁에 올인하는 것이 위험하다는 경고다. 하지만 동시에, 같은 모델이 하네스에 따라 17문제 차이가 난다는 건 기회이기도 하다. 최고 모델을 살 돈이 없어도, 하네스를 잘 설계하면 경쟁할 수 있다.

셋째, 하네스 엔지니어링은 새로운 직무다. OpenAI가 “코더에서 하네스 설계자로” 역할을 재정의한 건 레토릭이 아니다. 지금 이 순간에도 CLAUDE.md를 편집하고, MCP 서버를 연결하고, 라이프사이클 훅을 거는 사람들이 있다. 이 사람들이 하는 일에 이름이 붙은 것이다. 프롬프트 엔지니어링이 한때 “새로운 직무”였던 것처럼, 하네스 엔지니어링이 그 자리를 차지하고 있다.

2026년은 하네스의 해다. 모델은 충분히 똑똑해졌다. 이제 문제는 그 모델이 일하는 환경이 충분히 똑똑한가이다. 하네스가 곧 경쟁력이다. 그리고 그 경쟁력은 모델을 바꾸는 것이 아니라, .claude/ 디렉토리 안의 CLAUDE.md 파일을 한 줄 고치는 것에서 시작된다.

— -

## Sources

1. aitimes — AI 엔지니어링의 새로운 기준 ‘하네스’

2. OpenAI — Harness engineering: leveraging Codex in an agent-first world

3. Anthropic — Harness design for long-running application development

4. Anthropic — Effective harnesses for long-running agents

5. Martin Fowler — Harness engineering for coding agent users

6. philschmid / Hugging Face — The importance of Agent Harness in 2026

7. Milvus — What Is Harness Engineering for AI Agents?

8. Shulex VOC Blog — Harness Engineering: Why Your AI Agents Keep Failing

9. TianPan.co — Agentic Coding in Production: What SWE-bench Scores Don’t Tell You

10. Simranjeet Singh / Medium — Agent Harness: 12 Agentic Harness Patterns from Claude Code

11. Steven Cen / Medium — From Prompt Engineering to Harness Engineering

12. NxCode — Harness Engineering: The Complete Guide

13. AI Code Invest — Harness Engineering Explained

14. HumanLayer — Skill Issue: Harness Engineering for Coding Agents

15. Louis Bouchard — Harness Engineering: The Missing Layer Behind AI Agents

16. GitHub — awesome-harness-engineering

17. harness-engineering.ai — The Complete Guide to Agent Harness