"하네스 엔지니어링" - AI 에이전트 시대, 코드보다 중요한 것 : OpenAI vs Anthropic 하네스 전략 비교

안녕하세요! 갓대희 입니다.

 

2026년 2월, OpenAI 엔지니어링 블로그에 "Harness Engineering"이라는 글이 올라왔다 (2026-02-11).

한 달 뒤인 2026-03-24, Anthropic도 "Harness Design for Long-Running Apps"를 발표했다. AI 에이전트 시대의 양대 빅테크가 한 달 간격으로 같은 키워드의 공식 엔지니어링 블로그를 쓴 것이다.

우연이 아니다. 두 회사 모두 같은 문제에 부딪혔기 때문이다 — 모델이 아무리 좋아져도, 모델을 감싸는 "하네스"가 나쁘면 결과물이 나쁘다.

이 글에서는 두 원문을 깊이 분석하고, 공통점과 차이점을 비교한 뒤, 실무에서 바로 적용할 수 있는 하네스 설계 원칙을 정리한다.

목차

1. 왜 "하네스"가 2026년의 화두인가
2. 하네스(Harness)란 무엇인가
3. OpenAI의 접근: 하네스 엔지니어링
   • 0줄 수동 코드, 100만 줄 제품
   • 리포지토리 = 에이전트의 세계
   • 아키텍처 강제와 엔트로피 관리
4. Anthropic의 접근: 하네스 디자인
   • GAN에서 영감받은 3-에이전트 구조
   • 주관적 품질을 점수화하기
   • 모델이 좋아지면 하네스도 바뀐다
5. 두 접근법 비교 분석
6. 실무 적용: 하네스 설계 7원칙
7. 제한사항 및 열린 질문
8. 결론

하네스 엔지니어링 — 핵심 요약
AI 코딩 에이전트의 성능은 모델 자체보다 모델을 감싸는 환경(하네스)에 더 크게 좌우된다. OpenAI는 "리포지토리 전체를 에이전트가 읽고 쓸 수 있는 세계로 설계하라"고 말하고, Anthropic은 "생성기와 평가기를 분리하여 품질 피드백 루프를 만들라"고 말한다. 접근 방식은 다르지만 결론은 같다: "코드를 짜는 게 아니라 환경을 설계하는 것"이 엔지니어의 새 역할이다.

 

1. 왜 "하네스"가 2026년의 화두인가

2025년까지 AI 코딩 도구의 논의는 주로 모델 성능에 집중되어 있었다. "GPT-5가 나오면 코딩 에이전트가 완성될 것이다", "Opus 4.5가 긴 작업을 해결할 것이다" — 이런 식이었다.

하지만 2026년 초, 양대 빅테크가 연달아 발표한 엔지니어링 블로그는 다른 메시지를 전달한다.

회사	글 제목	저자	핵심 메시지
OpenAI	Harness Engineering	Ryan Lopopolo	"Humans steer. Agents execute."
Anthropic	Harness Design for Long-Running Apps	Prithvi Rajasekaran	"하네스의 흥미로운 조합 공간은 모델이 좋아져도 줄어들지 않는다. 이동할 뿐이다."

 

두 글의 공통된 발견: 모델의 원시 능력(raw capability)이 올라가도, 하네스 없이는 복잡한 실세계 작업을 안정적으로 수행할 수 없다. 모델이 좋아질수록 하네스가 불필요해지는 게 아니라, 하네스가 해결할 수 있는 문제의 복잡도가 함께 올라간다.

 

업계의 반응도 뜨겁다. Aaron Levie(Box CEO)는 X에서 "에이전트 하네스의 힘 배수(force multiplier)가 미친 수준이다"라고 평가했고, Martin Fowler(Thoughtworks)는 Birgitta Bockeler의 분석을 공유하며 "하네스가 서비스 템플릿의 새로운 형태가 될 수 있다"고 전망했다 (출처, 2026-02-17).

 

LangChain은 모델(gpt-5.2-codex)을 고정하고 하네스만 변경하여 Terminal Bench 2.0 점수를 52.8→66.5로 13.7점 올린 실험 결과를 공개했다 (출처, 2026-02-17). 한국의 GeekNews에서도 82포인트를 기록하며 화제가 되었다.

 

이 반응들이 보여주는 것은 하나다: 하네스는 더 이상 "있으면 좋은 것"이 아니라, 에이전트 코딩의 성능을 결정하는 핵심 변수로 인식되고 있다는 점이다.

 

2. 하네스(Harness)란 무엇인가

하네스(harness)는 원래 마구(馬具)를 뜻한다. 말의 힘을 제어하고 방향을 잡아주는 장치다. AI 맥락에서의 하네스도 같은 역할이다 — LLM의 능력을 특정 작업에 맞게 제어하고, 방향을 잡아주고, 결과를 검증하는 모든 것을 말한다.

하네스 ≠ 프롬프트

프롬프트는 하네스의 일부일 뿐이다. 하네스에는 리포지토리 구조, 문서 체계, 린터/CI, 피드백 루프, 에이전트 간 통신 프로토콜, 컨텍스트 관리 전략이 모두 포함된다. OpenAI의 표현을 빌리면 "에이전트가 유용한 일을 할 수 있게 해주는 도구, 추상화, 내부 구조의 총체"이다.

 

Phil Schmid(Hugging Face)가 제안한 비유가 직관적이다:

모델 = CPU, 컨텍스트 윈도우 = RAM, 에이전트 하네스 = 운영체제, 에이전트 = 애플리케이션.

CPU가 아무리 빨라도 좋은 OS 없이는 유용한 소프트웨어를 돌릴 수 없듯이, 모델이 아무리 좋아도 좋은 하네스 없이는 복잡한 작업을 안정적으로 수행할 수 없다.

 

LangChain은 이를 공식 분류 체계로 정리했다:

Agent Framework(LangChain) → Agent Runtime(LangGraph) → Agent Harness(DeepAgents).

"에이전트 = 모델 + 하네스. 모델이 아니라면, 당신은 하네스를 만들고 있는 것이다."

 

구체적으로 하네스는 다음을 포함한다.

• 환경 설계: 에이전트가 작업할 리포지토리 구조, 문서 체계, 도구 접근성
• 작업 분해: 큰 목표를 에이전트가 처리할 수 있는 단위로 나누는 전략
• 품질 검증: 린터, 테스트, 평가 에이전트 등 결과물의 정확성을 보장하는 메커니즘
• 컨텍스트 관리: 긴 작업에서 컨텍스트 윈도우를 효율적으로 사용하는 전략
• 피드백 루프: 결과를 평가하고 개선을 반복하는 구조
• 엔트로피 관리: 시간이 지남에 따라 코드베이스가 썩지 않게 유지하는 프로세스

프롬프트 엔지니어링 vs 하네스 엔지니어링

구분	프롬프트 엔지니어링	하네스 엔지니어링
초점	입력 텍스트 최적화	모델이 작동하는 환경 설계
범위	단일 요청 수준	시스템 전체 수준
방법	지시 문구 작성/개선	도구, 피드백 루프, 구조 설계
재현성	낮음 (동일 프롬프트도 결과 상이)	높음 (구조적 제약으로 일관성 확보)
확장성	모델 교체 시 재작성 필요	하네스가 모델 변화를 흡수

 

3. OpenAI의 접근: 하네스 엔지니어링

OpenAI의 글은 5개월간 수동 코드 0줄로 내부 제품을 만든 실험에서 나왔다. (출처: OpenAI Engineering Blog, 2026-02-11)

 

0줄 수동 코드, 100만 줄 제품

지표	수치
기간	5개월 (2025년 8월~)
수동 작성 코드	0줄
총 코드량	~100만 줄
PR 수	~1,500개
엔지니어 수	3명 → 7명
처리량	엔지니어당 3.5 PR/일
속도 추정	수작업 대비 ~1/10 시간 [ESTIMATE - 원문에서 직접 인용되지 않음]

핵심 원칙은 "Humans steer. Agents execute." — 인간은 방향을 잡고, 에이전트가 실행한다. 인간은 코드를 쓰는 것이 아니라 환경을 설계하고, 의도를 명세하고, 피드백 루프를 만드는 것이 주 업무가 된다.

 

리포지토리 = 에이전트의 세계

OpenAI가 가장 강조하는 개념: "에이전트가 접근할 수 없는 것은 존재하지 않는 것과 같다."

Google Docs에 있는 설계 문서, Slack에서 합의한 아키텍처 결정, 사람의 머릿속에 있는 암묵지 — 이런 것들은 에이전트에게 보이지 않는다. 따라서 모든 지식을 리포지토리 안에 버전 관리되는 형태로 넣어야 한다.

# OpenAI가 제안하는 리포지토리 지식 구조

AGENTS.md              # 약 100줄의 "목차" — 지도 역할
ARCHITECTURE.md        # 최상위 도메인/패키지 맵
docs/
├── design-docs/       # 설계 문서 (검증 상태 포함)
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/        # 실행 계획 (활성/완료/기술부채)
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/         # 자동 생성 문서 (DB 스키마 등)
├── product-specs/     # 제품 스펙
├── references/        # 외부 참조 (llms.txt 등)
├── DESIGN.md
├── FRONTEND.md
├── QUALITY_SCORE.md   # 각 도메인/레이어별 품질 등급
├── RELIABILITY.md
└── SECURITY.md

 

 

AGENTS.md를 "1,000페이지 매뉴얼"이 아닌 "목차"로 쓰라는 것이 핵심이다. OpenAI는 초기에 거대한 AGENTS.md를 시도했지만 실패했다. 이유 4가지:

1. 컨텍스트는 희소 자원: 거대한 지시 파일이 실제 작업 컨텍스트를 밀어낸다
2. 모든 게 중요하면 아무것도 중요하지 않다: 에이전트가 의도적 탐색 대신 패턴 매칭에 빠진다
3. 즉시 썩는다: 단일체 매뉴얼은 유지보수가 안 된다
4. 검증이 어렵다: 하나의 파일로는 커버리지, 신선도, 교차 링크를 기계적으로 확인할 수 없다

대신 Progressive Disclosure(점진적 공개)를 사용한다. 에이전트는 작고 안정적인 진입점(AGENTS.md)에서 시작해서, 필요에 따라 더 깊은 문서를 탐색한다.

 

아키텍처 강제와 엔트로피 관리

에이전트가 100만 줄의 코드를 생성하면 엔트로피(코드 품질 저하)가 불가피하다. OpenAI는 이를 두 가지로 해결한다.

 

1) 아키텍처 불변량(Invariant) 강제

각 비즈니스 도메인을 고정된 레이어(Types → Config → Repo → Service → Runtime → UI)로 나누고, 의존성 방향을 린터로 강제한다. "구현 방법은 자유롭게, 경계는 엄격하게"가 원칙이다. 이 린터도 Codex가 작성했다.

 

2) "가비지 컬렉션" — 정기적 정리

초기에는 매주 금요일(주당 20%)을 "AI 슬롭(slop) 청소"에 썼는데 확장이 안 됐다. 대신 "golden principles"를 리포지토리에 코드화하고, 백그라운드 Codex 태스크가 정기적으로 위반을 스캔하여 리팩토링 PR을 열도록 자동화했다. 기술 부채를 "고이자 대출"에 비유하며, 소량씩 지속적으로 갚는 것이 폭발적으로 쌓이는 것보다 낫다고 말한다.

OpenAI의 핵심 통찰

"에이전트가 생성한 코드가 인간의 스타일 선호와 항상 일치하지는 않는다. 그래도 괜찮다. 코드가 정확하고, 유지보수 가능하고, 미래 에이전트 실행에 읽기 쉬우면 기준을 충족한다."

 

4. Anthropic의 접근: 하네스 디자인

Anthropic의 글은 다른 각도에서 출발한다. 장시간(수 시간) 자율 코딩에서 품질을 어떻게 보장하는가?

(출처: Anthropic Engineering Blog)

 

나이브한 구현이 실패하는 이유

Anthropic은 두 가지 근본적인 실패 모드를 식별한다.

1. 컨텍스트 불안(Context Anxiety): 컨텍스트 윈도우가 차면서 모델이 일관성을 잃거나, 아직 할 일이 남았는데 일찍 마무리하려 한다. Sonnet 4.5에서 특히 심했으며, 컴팩션(요약)만으로는 해결되지 않았다.
2. 자기 평가의 편향: 에이전트에게 자기 작업을 평가하라고 하면 "자신감 있게 칭찬한다" — 인간이 보기에 품질이 떨어져도. 특히 디자인 같은 주관적 영역에서 심하지만, 검증 가능한 코딩 작업에서도 발생한다.

 

GAN에서 영감받은 3-에이전트 구조

이 문제를 해결하기 위해, Anthropic은 GAN(Generative Adversarial Network)에서 영감을 받은 3-에이전트 아키텍처를 설계했다.

에이전트	역할	세부 사항
Planner	1~4문장 프롬프트를 풀 스펙으로 확장	기술 세부사항보다 제품 맥락과 고수준 설계에 집중. AI 기능 통합 기회 탐색
Generator	실제 코드 생성 및 구현	스프린트 단위로 작업. React + Vite + FastAPI + SQLite/PostgreSQL 스택
Evaluator	Playwright MCP로 실제 앱을 조작하며 QA	기능별 점수 + 상세 비평. 기준 미달 시 Generator에 피드백

Generator와 Evaluator 사이에는 스프린트 계약(Sprint Contract)이 있다. 코드를 작성하기 전에 "이 스프린트에서 '완료'가 뭔지"를 양쪽이 합의한다. Evaluator는 이 계약을 기준으로 평가한다.

 

주관적 품질을 점수화하기 — 프론트엔드 디자인 실험

Anthropic은 프론트엔드 디자인에서 먼저 이 패턴을 실험했다. "이 디자인이 아름다운가?"는 일관되게 답하기 어렵지만, "이 디자인이 우리 원칙을 따르는가?"는 구체적으로 평가할 수 있다. 4가지 평가 기준을 만들었다.

기준	설명	가중치
Design Quality	색, 타이포그래피, 레이아웃이 하나의 분위기를 형성하는가	높음
Originality	의도적인 창의적 선택이 있는가, 아니면 AI 슬롭 패턴인가	높음
Craft	기술적 실행 품질 (타이포 계층, 간격 일관성, 대비)	보통
Functionality	미학과 무관한 사용성 — 사용자가 작업을 완료할 수 있는가	보통

반복 5~15회, 최대 4시간이 걸렸다. 주목할 점은, Evaluator가 Playwright MCP로 실제 페이지를 탐색하고 스크린샷을 찍으면서 평가한다는 것이다. 정적 스크린샷이 아니라 실제 인터랙션이다.

"박물관 수준의" 디자인 도약

네덜란드 미술관 웹사이트를 생성할 때, 9번째 반복까지는 깔끔한 다크 테마 랜딩 페이지였다. 그런데 10번째 반복에서 기존 접근을 완전히 버리고, CSS perspective로 렌더링된 3D 갤러리 — 체크무늬 바닥, 벽에 걸린 작품, 문 기반 내비게이션 — 로 재구상했다. 이전의 단일 패스 생성에서는 한 번도 본 적 없는 창의적 도약이었다.

 

모델이 좋아지면 하네스도 바뀐다

Anthropic이 가장 강조하는 교훈이다. 하네스의 모든 구성 요소는 "모델이 혼자 못하는 것"에 대한 가정을 인코딩한다. 모델이 좋아지면 가정을 재검증해야 한다.

하네스 구성	Opus 4.5에서	Opus 4.6에서
스프린트 분해	필수 — Sonnet 4.5가 긴 작업 일관성 유지 불가	Opus 4.5부터 불필요 — Opus 4.5에서 컨텍스트 불안 해소, Opus 4.6에서도 불필요. 2시간+ 일관 작업 가능
컨텍스트 리셋	필수 — Sonnet 4.5의 컨텍스트 불안 대응	불필요 — Opus 4.5부터 해소되어 4.6에서도 불필요, 자동 컴팩션 사용
Evaluator (QA)	매 스프린트마다 실행	전체 빌드 후 1회 (여전히 가치 있음)
Planner	필수	여전히 필수 (없으면 스코프 부족)

 

실전 비용 비교 (2D 레트로 게임 메이커 예시):

하네스	시간	비용	결과
단일 에이전트 (Solo)	20분	$9	핵심 기능(게임 플레이) 작동하지 않음
전체 하네스	6시간	$200	16개 기능, 게임 플레이 가능, AI 통합

20배 비싸지만, 단일 에이전트에서는 핵심 기능이 아예 작동하지 않았다. 비용이 아니라 "결과물이 쓸 수 있느냐 없느냐"가 진짜 차이다.

 

5. 두 접근법 비교 분석

관점	OpenAI (하네스 엔지니어링)	Anthropic (하네스 디자인)
핵심 은유	에이전트의 "세계" 구축	GAN 영감의 "적대적 피드백 루프"
주요 관심사	환경 설계 + 대규모 코드베이스 일관성	장시간 자율 코딩 + 품질 보장
에이전트 수	Codex 단일 에이전트 (+ 리뷰 에이전트)	명시적 3-에이전트 (Planner/Generator/Evaluator)
품질 보장 방법	린터 + CI + 구조적 테스트 + 정기 가비지 컬렉션	독립 Evaluator 에이전트 + Playwright 기반 실제 앱 QA
컨텍스트 관리	Progressive Disclosure (AGENTS.md → docs/)	컨텍스트 리셋 vs 자동 컴팩션 (모델에 따라)
규모	100만 줄, 1,500 PR, 5개월	풀스택 앱 1개, 4~6시간, $124.70~$200
엔트로피 대응	Golden Principles + 백그라운드 정리 에이전트	Evaluator가 스프린트마다 품질 게이트
인간의 역할	"환경 설계자" — 코드 0줄 작성	"하네스 튜너" — 평가 기준과 프롬프트 조정
모델 진화 시	명시적으로 다루지 않음	구성요소를 하나씩 제거하며 재검증

한 줄로 요약하면: OpenAI식 하네스는 리포지토리 규모의 일관성을 최적화하고, Anthropic식 하네스는 장시간 실행의 품질 보장을 최적화한다. 둘은 상호 배타적이지 않으며, 실무에서는 두 관점을 결합하는 것이 가장 효과적이다.

(위 비교는 양쪽 원문에서 직접 인용한 사실 기반이다. 아래 공통 원칙은 필자가 두 글을 종합하여 도출한 해석이다.)

 

접근 방식은 다르지만, 두 글에서 공통으로 나타나는 원칙이 있다.

• 에이전트의 작업 결과를 자동으로 검증하는 메커니즘이 필수이다
• 에이전트가 접근할 수 없는 지식은 존재하지 않는 것과 같다
• 하네스 설계는 일회성이 아니라 지속적인 튜닝이다
• 인간의 역할이 "코드 작성"에서 "환경/기준 설계"로 이동했다

 

6. 실무 적용: 하네스 설계 7원칙

두 글에서 추출한 실무 원칙을 정리한다.

원칙 1: 지도를 주지, 백과사전을 주지 마라

AGENTS.md / CLAUDE.md는 100줄 이내의 "목차"로 유지하고, 상세 내용은 docs/ 하위에 구조화한다. Progressive Disclosure로 에이전트가 필요할 때 깊이 탐색하게 한다. (OpenAI)

▶ 시작점 AGENTS.md 파일을 열고 100줄 넘는 부분을 확인한다. 넘는다면 해당 내용을 docs/ 디렉토리로 분리하고, AGENTS.md에는 해당 파일로의 링크만 남긴다.

원칙 2: 불변량은 코드로 강제하라

아키텍처 경계, 의존성 방향, 네이밍 규칙은 문서가 아닌 린터와 CI로 강제한다. 린터 에러 메시지에 수정 방법을 포함시켜 에이전트가 바로 고칠 수 있게 한다. (OpenAI)

▶ 시작점 레이어 경계 위반을 감지하는 린터 규칙 1개만 추가한다. (예: UI 컴포넌트에서 직접 DB 접근 금지). CI에 연결해서 에이전트가 생성한 코드에도 즉시 적용되게 한다.

원칙 3: 생성과 평가를 분리하라

에이전트에게 자기 작업을 평가하라고 하면 편향이 생긴다. 독립된 Evaluator를 두고, 그 Evaluator를 "회의적(skeptical)"으로 튜닝하는 것이 Generator를 자기 비판적으로 만드는 것보다 훨씬 쉽다. (Anthropic)

▶ 시작점 다음 PR 리뷰를 에이전트에게 맡길 때, 코드를 작성한 인스턴스와 다른 독립 인스턴스에 "이 PR의 문제점만 찾아라. 좋은 점은 생략해도 좋다"는 회의적 프롬프트로 리뷰를 요청해본다.

원칙 4: 에이전트에게 앱을 "보여줘라"

Chrome DevTools Protocol, Playwright MCP, 로컬 관측성 스택(로그/메트릭/트레이스)을 에이전트에 연결하여, 에이전트가 실행 중인 앱을 직접 구동하고 검증할 수 있게 한다. (OpenAI + Anthropic 공통)

▶ 시작점 에이전트에게 새 기능을 구현하게 하기 전에, 먼저 "로컬에서 앱을 실행하고 현재 동작을 스크린샷으로 캡처한 뒤 알려달라"고 요청해본다.

원칙 5: 모델이 바뀌면 하네스를 재검증하라

하네스의 모든 구성 요소는 "모델이 못하는 것"에 대한 가정이다. 새 모델이 나오면 한 번에 하나씩 제거하며 여전히 필요한지 검증한다. 필요 없는 구성은 제거하고, 새로 가능해진 영역에 하네스를 확장한다. (Anthropic)

▶ 시작점 모델 버전이 올라갈 때마다 주요 에이전트 작업 3개를 선정해 이전/이후 결과를 비교한다. 예상보다 더 잘 되거나 더 안 되는 태스크가 있으면 하네스 조정 신호다.

원칙 6: 엔트로피를 가비지 컬렉션하라

에이전트 생성 코드는 시간이 지나면 반드시 드리프트한다. "golden principles"를 정의하고, 정기적으로 스캔 → 리팩토링 PR을 여는 백그라운드 프로세스를 만든다. 기술 부채는 소량씩 계속 갚는 것이 한꺼번에 처리하는 것보다 낫다. (OpenAI)

▶ 시작점 월 1회 에이전트에게 "이 리포지토리에서 더 이상 참조되지 않는 파일, 죽은 코드, 미사용 의존성 목록을 작성해달라"고 요청한다. 가비지 컬렉션의 시작점이다.

원칙 7: "지루한" 기술을 선택하라

"Boring" 기술(안정적 API, 높은 조합성, 훈련 데이터에 풍부)이 에이전트에게 더 쉽다. 때로는 외부 라이브러리를 쓰는 것보다 에이전트가 하위 기능을 직접 구현하게 하는 것이 더 낫다 — 100% 테스트 커버리지와 런타임 기대에 정확히 맞출 수 있으므로. (OpenAI)

▶ 시작점 다음 아키텍처 결정 시 새로운 프레임워크 대신 에이전트가 학습 데이터로 가장 많이 봤을 기술(PostgreSQL, FastAPI, React, Spring Boot 등)을 먼저 검토한다. 혁신은 비즈니스 로직에서 하고, 인프라는 boring하게 유지한다.

 

7. 제한사항 및 열린 질문

두 글 모두 인정하는 한계

• 장기 일관성 미검증: OpenAI는 "완전 에이전트 생성 시스템의 아키텍처 일관성이 수년에 걸쳐 어떻게 진화하는지 아직 모른다"고 인정한다.
• 비용: Anthropic 하네스의 풀스택 앱 하나가 $124.70~$200. 개인 개발자에게는 부담스러울 수 있다.
• 재현성: OpenAI는 "이 동작은 이 리포지토리의 특정 구조와 도구에 크게 의존하며, 유사한 투자 없이 일반화될 것으로 가정해서는 안 된다"고 명시한다.
• Evaluator의 한계: Anthropic의 Evaluator도 "깊이 중첩된 기능의 미발견 버그, 비직관적 인터랙션, 작은 레이아웃 이슈"를 놓친다.
• 맛(Taste)의 인코딩: OpenAI는 "인간의 판단이 가장 큰 레버리지를 제공하는 곳이 어디인지, 그 판단을 어떻게 인코딩해서 복리로 쌓이게 하는지" 아직 배우고 있다고 말한다.

ETH 취리히 연구의 반론
2026년 ETH 취리히 연구팀이 138개 에이전트 설정 파일을 분석한 결과, LLM이 자동 생성한 설정 파일은 오히려 성능을 저하시켰으며, 인간이 정성껏 작성한 파일도 평균 4% 미만의 성능 기여에 그쳤다. 이 연구는 "AGENTS.md를 잘 쓰면 에이전트가 좋아진다"는 전제를 재검토하게 만든다. 물론 단일 연구의 독립 검증이 필요하지만, 설정 파일이 만능 해법은 아니며 하네스의 다른 요소(도구 설계, 피드백 루프)가 더 중요할 수 있다는 점을 시사한다.
(참고: HumanLayer - Skill Issue 분석, 독립 검증 필요)

 

Bitter Lesson 논쟁: 하네스는 결국 불필요해지는가?

Richard Sutton의 Bitter Lesson은 "일반적인 방법(더 큰 컴퓨팅)이 결국 도메인 특화 방법을 이긴다"고 말한다. 이 관점에서 보면, 하네스는 모델이 아직 못하는 것을 메꾸는 임시방편일 수 있다.

 

OpenAI의 Noam Brown도 "사람들이 추론 모델 위에 스캐폴딩을 만들고 있지만, 그 스캐폴드도 결국 더 능력 있는 모델로 대체될 것"이라고 말했다 (참고: Latent Space, 2026-03-05). 반면 Hugo Bowne-Anderson은 "좋은 하네스는 그 자체가 일반적 방법이다 — 컨텍스트를 관리하고, 에러에서 복구하고, 상태를 유지하는 방식이 모델 능력과 함께 확장된다"며, 핵심 원칙으로 "삭제를 위해 만들어라(Build for deletion)"를 제안한다.

 

Anthropic의 답이 여기에 있다: 모델이 좋아지면 하네스 구성을 하나씩 제거하며 재검증한다. Opus 4.5에서 4.6으로 올라갔을 때 스프린트 분해와 컨텍스트 리셋을 제거한 것이 정확히 이 원칙의 실천이다.

 

"Nothing New" 비판

비판도 있다. X의 @GenAI_is_real은 "이 사람들은 오래된 개념에 새 이름을 붙이는 것 외에 아이디어가 있는 건가?"라고 썼다 (출처). 하네스 엔지니어링이 결국 관심사 분리(Separation of Concerns), docs-as-code, CI/CD의 리브랜딩이라는 것이다.

 

이에 대해 Martin Fowler / Birgitta Bockeler는 "이 분야에서 처음으로 마음에 드는 용어다"라며, 프레이밍 자체가 실무적 가치를 가진다고 반론했다. 실제로 "에이전트를 위한 환경 설계"라는 프레임은 기존 소프트웨어 엔지니어링 원칙을 에이전트 시대에 맞게 재조직하는 데 유용하다.

 

양쪽 모두 솔직하게 인정하는 점이 있다: 이 분야는 아직 초기이다. 하네스 엔지니어링은 2026년에 막 이름을 얻은 개념이며, "정답"은 아직 없다.

 

한계가 분명히 존재한다. 그럼에도 방향은 명확하다. 에이전트가 생성한 코드 100만 줄이 이미 프로덕션에서 작동하고 있다는 사실, GAN 구조로 주관적 품질을 점수화할 수 있다는 발견, 그리고 모델이 좋아질수록 하네스가 단순해진다는 경험적 증거 — 이것들이 "하네스 엔지니어링"이 단순한 유행어가 아님을 보여준다.

 

8. 결론

OpenAI와 Anthropic이 한 달 간격으로 같은 키워드의 엔지니어링 블로그를 발표한 것은, "코드를 짜는 것이 아니라 환경을 설계하는 것"이 AI 시대 엔지니어링의 핵심이 되었다는 신호이다.

 

당신의 프로젝트에서 시작하기

단계	행동
오늘	AGENTS.md / CLAUDE.md를 "목차"로 재구성한다. 100줄 이내로.
이번 주	Slack/Notion에 있는 핵심 설계 결정을 리포지토리 docs/로 옮긴다. 에이전트가 볼 수 있게.
2주 안에	가장 중요한 아키텍처 불변량 1~2개를 린터로 강제한다.
한 달 후	코드 리뷰에 독립 평가 에이전트를 도입하고, 주기적 "가비지 컬렉션" 프로세스를 만든다.

 

Anthropic의 Prithvi Rajasekaran이 쓴 문장으로 마무리한다:

"하네스의 흥미로운 조합 공간은 모델이 좋아져도 줄어들지 않는다. 이동할 뿐이다. AI 엔지니어의 일은 다음의 새로운 조합을 계속 찾는 것이다."

참고 자료

• OpenAI: Harness Engineering: Leveraging Codex in an Agent-First World (2026-02-11)
• Anthropic: Harness Design for Long-Running Application Development
• Anthropic (선행 연구): Effective Harnesses for Long-Running Agents
• Anthropic: Building Effective Agents
• Anthropic: Effective Context Engineering for AI Agents
• OpenAI (선행 연구): Unlocking the Codex Harness (2026-02-04)
• Ralph Wiggum Loop: ghuntley.com/loop