하네스 엔지니어링(Harness Engineering) 자료

1. Mitchell Hashimoto

URL: https://mitchellh.com/writing/my-ai-adoption-journey

저자: Mitchell Hashimoto (HashiCorp 공동창업자, Ghostty 개발자)

추가 자료: https://zed.dev/blog/agentic-engineering-with-mitchell-hashimoto

핵심 인사이트

Mitchell Hashimoto는 AI 도입 과정을 6단계 여정으로 정리하며, 5단계를 "Engineer the Harness(하네스를 설계하라)"로 명명했습니다. 이것이 "하네스 엔지니어링"이라는 용어의 기원 중 하나입니다.

6단계 여정:

Drop the Chatbot - 채팅 인터페이스 버리고 에이전트 사용
Reproduce Your Own Work - 수동 작업 후 에이전트로 재현하며 전문성 축적
End-of-Day Agents - 퇴근 시간에 에이전트 실행(리서치, 병렬 탐색, 트리아지)
Outsource the Slam Dunks - 확실한 작업 위임, 의미 있는 작업에 집중
Engineer the Harness - 에이전트 실패를 시스템적으로 방지
Always Have an Agent Running - 항상 백그라운드 에이전트 실행(목표: 업무 시간의 10-20%)

하네스 엔지니어링의 정의

"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again." (에이전트가 실수할 때마다, 그 실수를 다시는 반복하지 않도록 해결책을 엔지니어링하는 것)

실전 패턴

1) AGENTS.md를 통한 암시적 프롬프팅(Better Implicit Prompting)

Ghostty 프로젝트의 AGENTS.md 파일에서 각 줄이 과거 에이전트 실패 사례에 대한 교정 규칙
예: "이 프로젝트에서는 이 명령을 사용하라", "이 API는 쓰지 마라", "이 절차로 검증하라"
결과: "each line is based on a bad agent behavior, and it almost completely resolved them all"

2) 프로그래밍된 도구(Programmed Tools)

스크린샷 캡처, 필터링된 테스트 실행, 검증 메커니즘 스크립트 작성
업데이트된 문서와 도구를 쌍으로 결합

Zed 블로그에서의 추가 인사이트

아키텍처 통제 유지: 본인이 코드 구조, 데이터 흐름, 상태 위치를 설계 -> 에이전트는 구현만 담당
"볼링장 범퍼" 비유: 주니어 개발자에게 업무를 맡기듯, 명확한 경계를 설정하고 범위가 좁은 문제를 위임
리팩토링이 최강 영역: 이름 변경, 구조 재편, 코드 이동 등 구조적 개선 작업에서 에이전트가 "almost perfect"
언어별 한계: Zig 코드는 "hopeless" -> C/Rust/Python으로 재작성 후 수동 변환
Claude가 "the most success"를 제공 - 동일 작업을 여러 모델 인스턴스(ghostty, ghostty2, ghostty3, ghostty4)에서 경쟁 평가

4대 소스에 없는 고유 인사이트

"하네스 엔지니어링"을 명시적 단계(Stage 5)로 분류한 최초의 프레임워크
AGENTS.md 파일이 사후적(reactive) 학습 문서라는 관점 - 매 실패 후 업데이트되는 살아있는 문서
병렬 에이전트 세션을 통한 모델 경쟁 평가(competitive evaluation) 패턴

2. SmartScope Blog

URL: https://smartscope.blog/en/blog/harness-engineering-overview/

제목: "What Is Harness Engineering: Defining the 'Outside' of Context Engineering"

핵심 인사이트

하네스 엔지니어링을 **컨텍스트 엔지니어링의 '바깥'**으로 정의하는 체계적 프레임워크를 제시합니다.

말(Horse) 은유

"Horses can run faster than humans, but left unattended, they veer off course." (말은 사람보다 빨리 달릴 수 있지만, 방치하면 경로를 이탈한다)

하네스(고삐, 안장, 울타리)가 힘을 안전하게 유도합니다.

3계층 관계 (Harness >= Context >= Prompt)

계층	은유	설명
Prompt Engineering	음성 명령	지시 텍스트 최적화
Context Engineering	지도와 이정표	LLM이 "보는" 모든 것 (RAG, 도구, 스키마, 메모리)
Harness Engineering	고삐와 울타리	"시스템이 방지하고, 측정하고, 수정하는 것"

하네스 엔지니어링의 4사분면(Four Quadrants)

아키텍처 제약(Architecture Constraints): 린터, 구조적 테스트, 의존성 규칙으로 기계적 강제
피드백 루프(Feedback Loops): CI/CD 통합, 관측 가능성(Observability), 메트릭/로그 검증
워크플로 제어(Workflow Control): 태스크 분할, 병렬화, 권한 관리
개선 사이클(Improvement Cycles): 엔트로피 관리, 자동 정리, 문서 신선도 유지

핵심 은유

"The model is the CPU, the harness is the OS. No matter how powerful the CPU, performance suffers if the OS is poor." (모델은 CPU이고, 하네스는 OS다. CPU가 아무리 강력해도 OS가 나쁘면 성능이 떨어진다)

성능 영향 데이터

Can.ac 실험: 편집 인터페이스만 변경해도 모델 성능이 6.7%에서 68.3%로 급상승
LangChain 벤치마크: 하네스 개선만으로 30위 -> 5위 (13.7포인트 상승)

4대 소스에 없는 고유 인사이트

3계층 관계 모델(Prompt < Context < Harness)의 체계적 정리
4사분면 프레임워크
CPU/OS 은유로 하네스의 본질 설명
2026년 2월 기준으로 용어 자체가 아직 "주 단위(weeks old)"로 매우 초기 단계라는 점 인정

3. Evangelos Pappas

URL: https://dev.to/epappas/the-agent-harness-is-the-architecture-and-your-model-is-not-the-bottleneck-3bjd

제목: "The Agent Harness Is the Architecture (and Your Model Is Not the Bottleneck)"

The Agent Harness Is the Architecture (and Your Model Is Not the Bottleneck)

I've been experimenting with agentic systems for a while now and I keep seeing the same pattern: the focus is on which model to use, run benchmarks -- and none of it fixes why their agents still suck on production.

dev.to

핵심 인사이트

모델이 아니라 모델을 감싸는 인프라(하네스)가 프로덕션 에이전트의 성패를 결정한다는 주장을 데이터로 뒷받침합니다.

에이전트 하네스의 5대 구성요소

컨텍스트 관리(Context Management): 컨텍스트 윈도우 진입/퇴출 정책
도구 선택(Tool Selection): 가용 기능과 인터페이스 설계
오류 복구(Error Recovery): 실패한 호출, 추론 막다른 길, 재시도 로직
상태 관리(State Management): 턴과 세션 간 진행 상황 유지
외부 메모리(External Memory): 컨텍스트 윈도우 너머 정보 저장/검색

APEX-Agents 벤치마크 결과

프론티어 모델도 실제 전문 업무(은행, 컨설팅, 법률)에서 pass@1 **24%**에 불과
8회 시도해도 ~40%만 성공
실패 원인은 대부분 조율(orchestration) 문제, 지식 격차가 아님

Vercel의 도구 축소 실험

15개 -> 2개 도구로 축소한 결과:

정확도: 80% -> 100%
속도: 3.5배 향상
토큰: 37% 감소
단계: 42% 감소

"Specialized tools become bottlenecks when the model is already capable enough." (모델이 충분히 유능하면 전문 도구가 오히려 병목이 된다)

Manus의 4차 재구축에서 배운 것

파일시스템을 메모리로 활용(Filesystem-as-memory)
To-do 리스트로 "lost-in-the-middle" 주의력 저하 방지
컨텍스트 압축 계층: raw -> compressed -> summarized
KV-cache 최적화로 10배 비용 절감(안정적 접두사 활용)

비용 경제학

Claude Sonnet 기준: 비캐시 $3/MTok vs 캐시 $0.30/MTok
50회 도구 호출 작업: 순진한 관리 $0.60 vs 최적화 $0.06
컨텍스트 관리 아키텍처가 비용 지속 가능성을 직접 결정

스마트폰 비유

프로세서가 충분히 좋아진 후, 가치는 하드웨어에서 OS와 생태계로 이동했다. 마찬가지로 파운데이션 모델이 성숙하면, 경쟁 우위는 모델 선택에서 하네스 엔지니어링 - 에이전트의 '운영체제' - 으로 이동한다.

산업 수렴(Industry Convergence)

OpenAI(Codex), Anthropic(Claude Code), Manus가 독립적으로 동일한 원칙에 수렴:

전문 도구보다 범용 도구 선호
외부 상태 관리(git, 파일시스템, 진행 파일)
오류 추적 보존 및 접근법 블랙리스팅
계층화/세그멘테이션을 통한 컨텍스트 규율

실전 권장사항

Vercel 실험 재현: bash + 파일 접근만으로 줄여서 성능 개선 여부 측정
영속 진행 파일 추가: 에이전트가 세션 경계에서 to-do 리스트를 읽고 쓰기
컨텍스트 예산 계측: 작업당 토큰 추적, 초과를 아키텍처 문제로 취급
삭제를 위해 구축(Build for deletion): 모든 하네스 구성요소에 만료일 설정
Model Context Protocol 채택: 표준화된 도구 인터페이스로 유지보수 부담 감소

4대 소스에 없는 고유 인사이트

APEX-Agents 벤치마크를 통한 "실제 업무에서의 실패는 조율 문제" 입증
비용 경제학 분석($3 vs $0.30 per MTok)
"능력 하한선(capability floor)" 개념 - GPT-4 수준 이하에서는 하네스가 보상 불가
스마트폰 산업과의 비유를 통한 가치 이동 설명

4. Ignorance.ai

URL: https://www.ignorance.ai/p/the-emerging-harness-engineering

제목: "The Emerging 'Harness Engineering' Playbook"

핵심 인사이트

여러 조직의 사례를 종합한 실전 플레이북을 제시합니다.

기업별 사례

OpenAI:

3명의 엔지니어가 5개월간 100만 줄 제품 구축, 수작업 코드 0줄
엔지니어 1인당 하루 평균 3.5 PR, 팀 규모 증가에 따라 처리량 증가

Stripe Minions:

주당 1,000건 이상 병합 PR
Slack에 작업 게시 -> 에이전트가 코드 작성, CI 통과, PR 오픈까지 자동
400개 이상의 내부 도구를 MCP 서버로 접근 가능

Peter Steinberger (OpenClaw):

코드를 줄 단위로 읽지 않고 배포
월 6,600+ 커밋, 동시에 5-10개 에이전트 실행
아키텍처 게이트키퍼 역할 유지

4대 핵심 실천법

1) 아키텍처를 가드레일로 활용(Architecture as Guardrails)

"Agents are most effective in environments with strict boundaries and predictable structure." (에이전트는 엄격한 경계와 예측 가능한 구조가 있는 환경에서 가장 효과적이다)

커스텀 린터와 구조적 테스트로 아키텍처 규칙 자동 적용

2) 도구를 기반이자 피드백으로(Tools as Foundation and Feedback)

내부 도구를 CLI 또는 MCP 서버로 접근 가능하게
린터 에러 메시지가 수정 지침 역할 -> 에이전트가 일하면서 동시에 학습

3) 문서를 시스템 기록(System of Record)으로(Documentation)

AGENTS.md가 사실상의 표준으로 부상
에이전트 실패 시마다 업데이트 -> 지속적 개선 피드백 루프
Anthropic는 JSON 기반 기능 추적 + 구조화된 진행 파일 사용 (Markdown보다 손상에 강함)

4) 검증과 피드백 루프(Verification and Feedback Loops)

백그라운드 에이전트가 리포지토리 스캔 -> 오래된 문서 발견 -> 정리 PR 오픈
과제: "기능적으로 올바르지만 유지보수성 나쁜 코드" 축적 방지

엔지니어 역할의 분할

환경 구축(Building the Environment):

구조, 도구, 피드백 메커니즘 설계
병목은 에이전트 능력이 아닌 환경 설계

작업 관리(Managing the Work):

실행 전 광범위한 사전 계획 -> 전략적 방향 설정
아키텍처 게이트키핑
병렬 에이전트 세션 조율

병렬화 모델

Attended(참석): 엔지니어가 3-4개 동시 에이전트 세션 적극 관리
Unattended(무인): 작업 게시 후 떠남, 에이전트가 CI까지 처리, 리뷰 시에만 복귀 (성숙한 하네스 필요)

미해결 과제

엔트로피 관리: 성숙한 코드베이스에서 저품질 코드 축적 방지
대규모 검증: 명시적 프롬프팅 없이 적절한 E2E 테스트 보장
브라운필드 적용: 아키텍처 구조가 부족한 레거시 코드베이스에 하네스 패턴 적용
문화적 채택: 의도적 투자 필요, 복리 효과가 있지만 초기 비용이 큼

"맛(Taste)"이 핵심 성공 요인

출력 볼륨이 증가할수록 코드 품질 기준 유지가 더 중요해진다. 엔지니어의 역할은 "bullshit detection(헛소리 감지)"와 아키텍처 일관성 보장에 집중.

4대 소스에 없는 고유 인사이트

Stripe와 Peter Steinberger의 구체적 수치(1,000 PR/주, 6,600 커밋/월)
Attended vs Unattended 병렬화 모델 분류
Boris Tane의 "코드 쓰기 전 계획 승인" 원칙
엔지니어 역할의 이분법(환경 구축 vs 작업 관리)

5. Philipp Schmid

URL: https://www.philschmid.de/agent-harness-2026

저자: Philipp Schmid (Hugging Face -> AWS)

제목: "The importance of Agent Harness in 2026"

핵심 인사이트

내구성 문제(Durability Problem): 벤치마크에서 잘 작동하는 모델도 장기 실행 시 실패합니다.

1% 벤치마크 향상이 50회 이상 도구 호출 후의 신뢰성 문제를 가림
며칠에 걸친 워크플로에서 일관된 지시 따르기가 진짜 격차

하네스가 필요한 3가지 이유

실세계 검증(Real-World Validation): 리더보드가 아닌 실제 사용 사례로 최신 모델 테스트
표준화된 경험(Standardized Experience): 검증된 패턴 위에 구축, 일관된 시스템 성능 보장
피드백 루프 생성(Feedback Loop Creation): 사용자 채택 데이터 기반 반복 개선

Bitter Lesson 적용

"Over time models get better and you're having to strip away structure, remove assumptions." (시간이 지나면 모델이 좋아지고, 구조를 벗기고 가정을 제거해야 한다)

Manus: 6개월간 5번 재설계
LangChain Deep Research: 1년 내 3번 재구축
Vercel: 에이전트 도구 80% 제거

실전 가이드

단순하게 시작(Start Simple): 거대한 제어 흐름 피하기, 원자적 도구 제공하고 모델이 계획하게 하기
삭제를 위해 구축(Build to Delete): 새 모델 등장 시 코드 제거 준비가 된 모듈식 아키텍처
하네스를 데이터셋으로(Harness as Dataset): 경쟁 우위가 프롬프트에서 **캡처된 궤적(trajectories)**으로 이동 - 모든 지시 따르기 실패가 훈련 데이터로 변환

새로운 방향

장기 실행 시 모델 드리프트(drift) 감지가 향후 훈련에 반영
수많은 단계 후 모델이 지시 준수를 상실하는 시점("fatigue") 정확히 식별

4대 소스에 없는 고유 인사이트

"Harness as Dataset" 개념 - 하네스에서 캡처된 궤적이 미래 훈련 데이터
Bitter Lesson의 AI 애플리케이션 레이어 적용
모델 "피로(fatigue)" 감지라는 새로운 연구 방향
"Build to Delete" 원칙의 명시적 강조

6. HTekDev

URL: https://dev.to/htekdev/agent-harnesses-why-2026-isnt-about-more-agents-its-about-controlling-them-1f24

제목: "Agent Harnesses: Why 2026 Isn't About More Agents -- It's About Controlling Them"

핵심 인사이트

기업 환경에서의 에이전트 거버넌스(governance) 관점의 하네스를 다룹니다.

충격적 데이터

기업 평균 12개의 AI 에이전트 배포
그 중 27%만 광범위 시스템에 연결
나머지 73%는 "그림자 에이전트(Shadow Agents)" - 모니터링 없이 기술 부채 축적
10년 전 마이크로서비스 카오스의 재현 -> "Agent Sprawl(에이전트 난립)"

CNCF 플랫폼 제어 프레임워크 적용 - 4기둥

Golden Paths(황금 경로): 사전 승인된 구성, 검증된 모델/프로바이더 조합
Guardrails(가드레일): 비용 상한, 기간 제한, 차단된 출력 패턴 등 협상 불가능한 정책 강제
Safety Nets(안전망): 재시도 로직, 서킷 브레이커 등 자동 복구 메커니즘
Manual Review(수동 검토): 고위험 결정을 위한 Human-in-the-loop 게이트

고유 기술 인사이트

루프 소유권 원칙(Loop Ownership Principle):

초기 프로토타입은 함수 호출에 전/후 가드레일만 감쌈 -> 중간 통제를 놓침
진정한 하네스는 에이전틱 루프 자체를 소유 -> 매 반복마다 예산과 정책을 검증 후 도구 실행

반복 수준 관측 가능성(Iteration-Level Observability):

최종 출력만이 아니라 각 에이전트 단계(도구 호출, 차단된 액션, 반복당 토큰 소비)를 개별 추적

도구 차단 패턴(Tool Blocking Pattern):

LLM이 금지된 도구를 요청하면, 하네스가 [BLOCKED] 메시지를 대화에 삽입
에이전트가 인간 개입 없이 적응 가능

@htekdev/agent-harness 라이브러리

6개 소스에서 제로 설정 자격 증명 검색을 통한 멀티 프로바이더 지원
LLM 응답과 도구 출력 양쪽의 출력 패턴 차단
"행동 검증(behavior verification)" vs "실행 테스트"의 테스트 구분

전략적 관점

"The companies winning with AI in 2027 won't be the ones with the most agents. They'll be the ones with the best harnesses." (2027년 AI로 승리하는 기업은 가장 많은 에이전트를 가진 기업이 아닌, 최고의 하네스를 가진 기업이다)

4대 소스에 없는 고유 인사이트

"Shadow Agent" 문제와 73% 미연결 통계
CNCF 플랫폼 제어 프레임워크의 에이전트 적용
Loop Ownership Principle
[BLOCKED] 메시지 삽입 패턴
구체적인 오픈소스 하네스 라이브러리 예시

7. Can.ac

URL: https://blog.can.ac/2026/02/12/the-harness-problem/

저자: Can Boluk (보안 및 리버스 엔지니어링 전문가)

제목: "I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed."

핵심 인사이트

하나의 변수(편집 인터페이스)만 바꿔서 15개 LLM의 코딩 성능을 개선한 실험. 하네스가 모델보다 중요하다는 것을 실증적으로 증명합니다.

Hashline 포맷

기존 diff/문자열 치환 대신, 각 줄에 2-3 글자 해시 태그를 부여:

11:a3|function hello() {
22:f1|  return "world";
33:0e|}

모델이 정확한 텍스트 재현이나 diff 문법 대신 태그를 참조하여 편집
공백 재현 제거, 검증 가능한 앵커 제공

벤치마크 결과

설정: 180개 태스크/런, 3회 반복, 변형된 React 파일의 기계적 버그

모델	기존 포멧	Hashline	변화
Grok Code Fast 1	6.7%	68.3%	+917%
MiniMax	-	2배 이상	-
Grok 4	50.7% 패치 실패율	크게 감소	-
Gemini 3 Flash	-	78.3% 성공	-

전체적으로 출력 토큰 ~20% 감소
Patch 포맷이 거의 모든 모델에서 성능 최하위

핵심 인용

"The model isn't flaky at understanding the task. It's flaky at expressing itself. You're blaming the pilot for the landing gear." (모델은 작업 이해에서 불안정한 게 아니다. 자기 표현에서 불안정한 것이다. 착륙 장치 문제를 조종사 탓으로 돌리고 있다.)

실전 시사점

하네스 최적화가 주요 모델 업그레이드에 필적하는 성능 향상을 훈련 비용 없이 제공
벤더 종속(API 제한)이 교차 모델 최적화를 방해
오픈소스 하네스가 독점 도구에 불가능한 커뮤니티 차원의 개선을 가능하게 함

4대 소스에 없는 고유 인사이트

편집 인터페이스라는 단일 변수의 극적 영향에 대한 정량적 증거
Hashline 포맷이라는 구체적 기술 혁신
"조종사 vs 착륙 장치" 비유
16개 모델에 걸친 교차 모델 하네스 최적화 데이터

8. Vercel

8a. 도구 80% 제거 실험

URL: https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools

제목: "We removed 80% of our agent's tools"

결과

내부 데이터 에이전트 d0에서 도구를 15개에서 2개로 축소:

정확도: 80% -> 100%
토큰: 37% 감소
속도: 3.5배 향상
단계: 42% 감소

배경

원래 다수의 전문 도구(스키마 조회, 쿼리 검증, 에러 복구 등) 구축
매 엣지 케이스마다 패치 추가 -> 에이전트 개선보다 스캐폴딩 유지보수에 시간 소모

해결책

"bash is all you need" - 모델이 점점 똑똑해지고 컨텍스트 윈도우가 커지니, 최고의 에이전트 아키텍처는 거의 아키텍처가 없는 것

파일시스템 에이전트가 grep, cat, find, ls 등 표준 Unix 도구로 시맨틱 레이어를 탐색
인간 분석가가 하듯 파일 읽기, 패턴 검색, 멘탈 모델 구축, SQL 작성

8b. AGENTS.md가 Skills를 능가한다

URL: https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals

제목: "AGENTS.md outperforms skills in our agent evals"

벤치마크 결과

설정	Build	Lint	Test	최종 Pass
베이스라인 (문서 없음)	84%	95%	63%	53%
Skills (기본)	84%	89%	58%	53% (+0pp)
Skills + 명시적 지시	95%	100%	84%	79% (+26pp)
AGENTS.md	100%	100%	100%	100% (+47pp)

왜 수동 컨텍스트(Passive Context)가 승리하는가

문서 참조 시점에 대한 에이전트 판단 불필요
모든 상호작용 턴에서 일관되게 이용 가능
순서 결정 복잡성 제거

Skills의 문제

"In 56% of eval cases, the skill was never invoked." (평가 사례의 56%에서 skill이 호출되지 않았다)

Skill은 명시적 지시가 있어야 의미 있는 개선
지시 문구에 따라 결과가 극적으로 달라지는 취약성

컨텍스트 효율

40KB 문서를 8KB로 80% 압축 후에도 100% pass 유지
파이프 구분 인덱스 구조로 검색 가능한 파일을 가리킴

핵심 인용

"The 'dumb' approach (a static markdown file) outperformed the more sophisticated skill-based retrieval." ('멍청한' 접근법(정적 마크다운 파일)이 더 정교한 skill 기반 검색을 능가했다)

4대 소스에 없는 고유 인사이트

"bash is all you need" 가설의 정량적 검증
AGENTS.md vs Skills의 직접 비교 벤치마크
40KB -> 8KB 컨텍스트 압축 기법
"전문 도구가 오히려 병목"이라는 반직관적 발견

9. Stripe Minions

URL: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

추가: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

핵심 인사이트

Stripe의 자체 구축 코딩 에이전트 Minions가 주당 1,000건 이상의 PR을 병합합니다.

6계층 엔지니어링 하네스

"The secret isn't a better AI model -- it's the brilliant six-layer engineering harness they built around it." (비밀은 더 나은 AI 모델이 아니다. 그것을 감싸는 뛰어난 6계층 엔지니어링 하네스다.)

MCP와 내부 도구

MCP(Model Context Protocol)를 통한 400개 이상의 내부 도구 접근
하지만 400개 전부 제공하면 "토큰 마비(token paralysis)" 발생
오케스트레이터가 관련 도구 ~15개만 선별 제공 -> 집중된 컨텍스트

격리된 실행 환경

모든 Minion에 자체 격리 가상 머신(devbox) 할당
인간 엔지니어와 동일한 개발 환경
~10초 내 pre-warmed 상태로 기동

하이브리드 워크플로 (창의적 + 결정론적)

1. 에이전트가 코드 작성 (창의적 단계)
2. 하드코딩된 스크립트가 항상 린터 실행 (결정론적 게이트)
3. 린터 실패 시 에이전트가 수정 (창의적 단계)
4. 하드코딩된 스크립트가 git 커밋 (결정론적 게이트)

창의적 LLM 단계와 결정론적 게이트를 교차 배치

4대 소스에 없는 고유 인사이트

구체적인 6계층 하네스 아키텍처
MCP를 통한 400+ 도구 접근이지만 15개만 선별하는 "도구 큐레이션" 패턴
"토큰 마비" 개념 - 너무 많은 도구 제공의 역효과
하이브리드 워크플로(창의적/결정론적 교차) 패턴
10초 내 격리 환경 기동의 실전 운영

10. Meta의 Manus 인수

URL: https://natesnewsletter.substack.com/p/meta-bought-manus-for-2b-to-acquire

제목: "Meta bought Manus for $2B to acquire an 'agentic harness'"

핵심 인사이트

Meta가 Manus를 **$2B(약 2조 8천억 원)**에 인수한 것은 모델이 아닌 하네스 엔지니어링 역량 때문입니다.

핵심 비유

"An AI agent is the engine. A harness is the car. You don't get your V12 engine very far down the road without a car!" (AI 에이전트는 엔진이다. 하네스는 자동차다. V12 엔진만으로는 도로를 멀리 갈 수 없다!)

$2B 가치의 근거

다단계 신뢰성의 복합적 도전: 작은 단계별 오류가 50+ 도구 호출 시 극적으로 확대
동일 모델을 사용하는 팀들이 종종 실패하는 반면 다른 팀은 신뢰할 수 있는 워크플로 출하
차이는 하네스 엔지니어링, 모델 품질이 아님

Manus의 반복 설계

6개월간 5번 재설계 - 경직된 가정을 매번 제거
사용자 대면 복잡성 제거 + 타겟 내부 인프라(compaction, caching, logit masking) 투자
결과: 파일시스템 기반 메모리, To-do 메커니즘, 컨텍스트 압축 계층

Meta의 인수 이유

독점 기술이 아닌 팀의 프로덕션 전문성 확보
"standalone plus integrate" 접근 -> 운영 경험에서 나온 패턴 지식 가치
데모와 프로덕션을 분리하는 엔지니어링 패턴의 가치 인정

4대 소스에 없는 고유 인사이트

하네스 엔지니어링에 대한 $2B 밸류에이션이라는 시장 검증
"데모 vs 프로덕션" 격차를 하네스가 해결한다는 관점
5번 재설계를 통해 얻은 교훈: 매번 복잡성 제거 방향
V12 엔진/자동차 비유

11. Salesforce

URL: https://www.salesforce.com/agentforce/ai-agents/agent-harness/

제목: "What is an Agent Harness?"

핵심 인사이트

Salesforce는 에이전트 하네스를 **"AI의 도구, 메모리, 안전을 관리하여 신뢰할 수 있는 자율 작업 실행을 보장하는 운영 소프트웨어 레이어"**로 정의합니다.

4대 핵심 하위 시스템

컨텍스트 엔지니어링(Context Engineering):
- 압축(compression): 오래된 도구 호출을 요약으로 압축
- 주입(injection): RAG 기술로 관련 정보 동적 제공
도구 조율(Tool Orchestration): 5단계 검증 프로세스
- 요청 가로채기 -> 권한 검증 -> 격리 환경 실행 -> 출력 정제(sanitize) -> 정제된 결과 반환
Human-in-the-Loop 제어:
- 민감한 작업(고객 데이터 삭제, 대규모 금융 거래 승인) 시 일시 중지
생명주기 관리(Lifecycle Management):
- 에이전트 상태를 DB에 저장 -> 실패 시 진행 상실 없이 복구
- "AI amnesia(AI 기억상실)" 해결

2가지 운영 아키텍처

단일 스레드 감독자(Single-Threaded Supervisor): 고객 지원 등 단순 작업, 대화 턴 모니터링
다중 에이전트 조정(Multi-Agent Coordination): 허브앤스포크 모델 - 전문 에이전트(연구, 작성, 컴플라이언스) 디스패치 및 핸드오프 관리

경쟁 우위

모델 불가지론(Model Agnosticism): 비즈니스 로직 재작성 없이 LLM 교체 가능
비용 통제: 지능형 캐싱
인프라 수준 보안: 프롬프트 기반이 아닌 인프라 수준의 보안

4대 소스에 없는 고유 인사이트

5단계 도구 조율 프로세스 (intercept -> verify -> execute -> sanitize -> return)
"AI amnesia" 개념과 생명주기 관리로의 해결
단일 스레드 vs 다중 에이전트 아키텍처 분류
엔터프라이즈 관점의 모델 불가지론 전략

12. Parallel.ai

URL: https://parallel.ai/articles/what-is-an-agent-harness

제목: "What is an agent harness in the context of large-language models?"

핵심 인사이트

에이전트 하네스의 가장 포괄적인 정의와 구성요소를 제공합니다.

"The complete architectural system surrounding an LLM that manages the lifecycle of context from intent capture through execution and persistence." (의도 포착부터 실행과 영속까지 컨텍스트의 생명주기를 관리하는, LLM을 둘러싼 완전한 아키텍처 시스템)

하네스 작동 5단계

의도 포착(Intent Capture): 사용자 목표를 하위 작업으로 분해
도구 호출 실행(Tool Call Execution): 모델 출력에서 도구 호출 토큰 감시, 실행, 결과 피드백
컨텍스트 관리(Context Management): 각 모델 호출 전 작업 컨텍스트 큐레이션, 요약으로 토큰 한도 유지
검증 및 반복(Verification & Iteration): 형식 검사, 로직 검증, 테스트 실행 -> "코드 작성 -> 테스트 -> 수정" 사이클
완료 및 핸드오프(Completion & Handoff): 세션 산출물(파일, 로그, 진행 요약) 저장

메모리의 3계층 분리

작업 컨텍스트(Working Context): 임시 프롬프트
세션 상태(Session State): 현재 작업 로그
장기 메모리(Long-term Memory): 영속 지식 기반

하네스 vs 관련 개념

개념	역할
에이전트 프레임워크 (LangChain, LlamaIndex)	빌딩 블록 제공
하네스	프레임워크를 조립하여 작동하는 시스템으로 완성
오케스트레이터	로직/결정 흐름 제어 (언제/어떻게 모델 호출)
하네스	기능과 부작용 제공 (도구, 컨텍스트, 환경)
테스트 하네스	테스팅 프레임워크 (소프트웨어 테스팅 용어)

하네스의 이점

높은 성공률: 영속성, 외부 지식 접근, 오류 수정 없이 실패할 문제 해결
장기 작업 일관성: 컨텍스트 단절 간 상태 저장과 점진적 진행 강제
자원 효율: 구조화된 도구 호출로 토큰 낭비 10-100배 감소
재훈련 없는 능력 확장: 범용 모델이 하네스 통합 도구로 전문 능력 획득
신뢰성 향상: 하네스가 절차, 필터, 검증 단계를 "거버너"로 강제

4대 소스에 없는 고유 인사이트

메모리의 3계층 분리 모델 (Working / Session / Long-term)
하네스 vs 오케스트레이터 vs 프레임워크의 명확한 구분
하네스 작동의 5단계 프로세스
토큰 효율 10-100배 감소라는 정량적 이점

13. MT Rajan

URL: https://mtrajan.substack.com/p/harness-engineering-is-not-context

제목: "Harness Engineering Is Not Context Engineering"

핵심 인사이트

컨텍스트 엔지니어링과 하네스 엔지니어링의 차이를 명확히 구분합니다.

핵심 구분

Context Engineering: "에이전트가 무엇을 보아야 하는가?"
Harness Engineering: "시스템이 무엇을 방지, 측정, 교정해야 하는가?"

"Context engineering only addresses what the agent knows. It says nothing about what the agent can do, or what happens when it does the wrong thing." (컨텍스트 엔지니어링은 에이전트가 아는 것만 다룬다. 에이전트가 할 수 있는 것이나, 잘못된 것을 했을 때 무슨 일이 일어나는지는 다루지 않는다.)

신입사원 비유

완벽한 온보딩 문서를 주는 것(컨텍스트) ≠ 적절한 구조, 도구, 안전장치를 제공하는 것(하네스)

진단 프레임워크

"Wrong output once? Probably context. Slow degradation over weeks? That's a harness problem." (한 번 잘못된 출력? 아마 컨텍스트 문제. 몇 주에 걸친 느린 저하? 그것이 하네스 문제다.)

구체적 하네스 패턴

관측 가능성 & 측정 가능성:

Chrome DevTools 통합 -> 에이전트가 UI를 보고 버그 재현 가능
작업별 격리된 관측 가능성 스택(로그, 메트릭, 트레이스)
"시작이 800ms 이내 완료되어야 한다"가 열망에서 강제 가능한 것으로 전환

교육적 강제(Educational Enforcement):

린터 에러가 후속 시도의 학습 컨텍스트로도 기능
실수를 차단하면서 동시에 에이전트를 훈련

자동 표준 관리:

골든 룰과 품질 등급을 리포지토리에 직접 인코딩
백그라운드 에이전트가 이탈 감지 -> 소규모 리팩토링 PR 오픈
"코드 품질을 위한 가비지 컬렉션" - 인간의 취향을 한 번 포착, 지속 강제

지식 아키텍처:

거대 지시 파일 대신, 버전이 붙은 AGENTS.md가 더 깊은 소스(디자인 문서, 아키텍처 맵, 실행 계획)를 가리킴
백그라운드 에이전트가 자동 정리 PR로 문서 신선도 유지

핵심 결론

"Context helps the model think. Harness is what keeps the system from drifting." (컨텍스트는 모델이 생각하는 것을 돕는다. 하네스는 시스템이 표류하지 않게 유지하는 것이다.)

4대 소스에 없는 고유 인사이트

"한 번 오류 vs 점진적 저하" 진단 프레임워크
"교육적 강제" 개념 - 린터가 차단과 학습을 동시에 수행
"코드 품질을 위한 가비지 컬렉션" 은유
신입사원 비유를 통한 직관적 설명

14. Future of Being Human

URL: https://www.futureofbeinghuman.com/p/what-we-miss-when-we-talk-about-ai-harnesses

저자: (철학/기술 윤리 블로그) 제목: "What we miss when we talk about 'AI Harnesses'"

핵심 인사이트

하네스 은유에 대한 비판적 관점을 제시합니다. 대부분의 소스가 하네스를 긍정적으로 다루는 것과 대비됩니다.

하네스 은유의 3가지 문제적 전제

1. 깨끗한 통제자-피통제자 분리(Clean Controller-Controlled Separation)

인간이 지시하고 AI가 실행한다는 이분법 전제
"중요한 지능 - 무엇을 왜 할지에 대한 판단"이 전적으로 인간에게 있다고 가정
프론티어 AI 시스템의 점증하는 이해력이 이 이분법을 복잡하게 만듦

2. 변화 없는 능력 활용(Capability Without Transformation)

하네스가 사용자를 "과제 완료 후 변하지 않은 채로" 남겨준다고 가정
실제로는 고급 AI와의 상호작용이 양측을 본질적으로 변화시킴 - 이는 버그가 아닌 기능

3. 도구적 환원(Instrumental Reduction)

"그냥 도구일 뿐" 내러티브 강화
Tobias Rees의 표현: "인간 예외주의에 대한 향수(a nostalgia for human exceptionalism)"
Verbeek의 매개 이론(Mediation Theory), Clark-Chalmers의 확장 마음 가설(Extended Mind Thesis) -> 기술이 인지 풍경을 능동적으로 재형성

적절한 프레이밍이 수용해야 할 것

양방향성(Bidirectionality): 사용자도 변한다
내재적 변환(Transformation as intrinsic): 최소화할 부작용이 아님
보이지 않는 효과(Invisible effects): 가장 중대한 영향이 과제 수행 패러다임 내에서 감지 불가능
관계적 역동(Relational dynamics): AI를 "명령"하는 것이 아닌 AI와 "함께 일하는 것"

4대 소스에 없는 고유 인사이트

하네스 은유 자체에 대한 유일한 비판적 분석
철학적 프레임워크(매개 이론, 확장 마음 가설) 적용
AI-인간 상호작용의 양방향 변환 효과
"인간 예외주의에 대한 향수"라는 비판적 시각
워크숍 M1(개념과 필요성) 모듈에서 균형 잡힌 시각 제공에 활용 가능

15. Boris Tane (Cloudflare)

URL: https://boristane.com/blog/how-i-use-claude-code/

저자: Boris Tane (Cloudflare 엔지니어링 매니저, Baselime 창업자)

핵심 원칙

"Never let Claude write code until you've reviewed and approved a written plan." (계획을 검토하고 승인하기 전까지 절대 Claude가 코드를 쓰게 하지 마라.)

3단계 파이프라인

1) 연구(Research) 단계:

관련 코드베이스를 깊이 연구 -> research.md 생성
"deeply", "intricacies", "go through everything" 같은 언어로 피상적 스캔 방지

2) 계획(Planning) 단계:

설명, 코드 스니펫, 파일 경로가 포함된 상세 plan.md 생성

3) 주석 사이클(Annotation Cycle) - 가장 독특한 단계:

마크다운 계획에 인라인 노트를 직접 추가
1-6회 반복, "don't implement yet" 가드 포함
주석 유형:
- 도메인 지식: "마이그레이션에 raw SQL이 아닌 drizzle:generate 사용"
- 아키텍처 교정: "이것은 PUT이 아닌 PATCH여야 한다"
- 범위 축소: "이 섹션은 완전히 제거하라"

구현 시

하나의 프롬프트로 실행 개시:

"implement it all...mark completed tasks in the plan, run typecheck continuously, do not stop until finished"

4가지 계획 지도 방법

Pick and Choose: 가치 있는 부분만 선택, 과도한 엔지니어링 폐기
Trim Scope: "nice-to-have" 기능 명시적 제거
Protect Interfaces: 함수 시그니처와 공개 API에 하드 제약 설정
단일 긴 세션: 연구, 계획, 주석, 구현을 하나의 연속 대화에서 수행

4대 소스에 없는 고유 인사이트

주석 사이클(Annotation Cycle) 패턴 - 가장 독창적인 하네스 기법
research.md -> plan.md -> annotation -> implement의 구체적 워크플로
"구현은 기계적이고 지루해야 한다"는 원칙
Pick and Choose / Trim Scope / Protect Interfaces 전략

16. Peter Steinberger (OpenClaw)

참조: https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code

인물: Peter Steinberger (PSPDFKit 창업자, OpenClaw 개발자, 현 OpenAI)

핵심 인사이트

"I ship code I don't read." (읽지 않은 코드를 출하한다.)

규모

2026년 1월 한 달 동안 6,600+ 커밋
동시에 5-10개 에이전트 실행
GitHub 역사상 가장 빠르게 성장한 리포(OpenClaw, 180,000+ 스타)
OpenAI가 영입(2026년 2월)

"에이전틱 엔지니어링(Agentic Engineering)" 접근

Andrej Karpathy의 용어를 차용, "바이브 코딩(vibe coding)"과 명확히 구분
아키텍처 게이트키퍼 역할 유지에도 불구하고 높은 속도
PSPDFKit 13년간 부트스트랩 경험에서 나온 엔지니어링 규율

4대 소스에 없는 고유 인사이트

"읽지 않은 코드 출하"의 실전 사례와 그것이 가능한 조건(성숙한 하네스)
$2B 가치 인정 -> OpenAI 영입으로 이어진 커리어 궤적
"바이브 코딩"과 "에이전틱 엔지니어링"의 구분

17. Hugo Bowne-Anderson

URL: https://hugobowne.substack.com/p/ai-agent-harness-3-principles-for

제목: "AI Agent Harness, 3 Principles for Context Engineering, and the Bitter Lesson Revisited"

Lance Martin의 컨텍스트 엔지니어링 3원칙

에이전틱 시스템에서 토큰 효율을 관리하는 실전 프레임워크:

1. 축소(Reduce)

오래된 도구 호출을 요약으로 압축
히스토리가 임계 크기에 도달하면 궤적 요약(trajectory summarization) 적용

2. 위임(Offload)

복잡성을 프롬프트 밖으로 이동
전체 결과를 외부 스토리지에 저장
bash 터미널 같은 원자적 도구 제공 -> 컨텍스트 혼잡 없이 훨씬 많은 작업 수행

3. 격리(Isolate)

다중 에이전트 아키텍처에서 전문 하위 에이전트가 토큰 집약적 작업을 독립적으로 처리
메인 에이전트에는 간결한 요약만 반환

Bitter Lesson의 애플리케이션 레이어 적용

"Over time models get better and you're having to strip away structure, remove assumptions."

에이전트 하네스(실행과 컨텍스트를 관리하는 스캐폴딩)는 끊임없이 진화해야 함
Manus: 2024년 3월 이후 5번 재설계
LangChain Deep Research: 1년 내 반복적 재구축

4대 소스에 없는 고유 인사이트

Reduce / Offload / Isolate의 3원칙 프레임워크
Bitter Lesson을 하네스 설계에 구체적으로 적용
"궤적 요약(trajectory summarization)" 기법

18. Nahornyi AI LAB

URL: https://nahornyi.ai/en/news/openai-harness-engineering-agentic-reliability-mlops

제목: "Harness Engineering: Reliable AI Agents"

MLOps 관점의 핵심 패턴

1. 의도 버저닝(Intent Versioning):

계획, 결정, 실행 결과를 리포지토리의 일부로 버전 관리
이것 없이는 에이전트 반복이 비결정론적 스트림으로 전락

2. 제약 아키텍처(Constraint Architecture):

에이전트 환경에서 규칙이 형식화되고 자동 검증되지 않으면, 그 규칙은 존재하지 않는 것
에이전트가 규칙의 저자가 될 수 있지만, 규칙은 독립적 심판이어야 함

3. 결정론적 + LLM 하이브리드:

컨텍스트 엔지니어링, 아키텍처 제약, "가비지 컬렉션" 에이전트를 결정론적/LLM 기반 접근의 혼합으로 구성
주기적으로 문서 불일치나 아키텍처 제약 위반을 찾는 에이전트 실행

법적/운영적 관점

"Any 'smartness' must be framed by observability, quality evaluation, and manageable interfaces." (모든 '똑똑함'은 관측 가능성, 품질 평가, 관리 가능한 인터페이스로 프레임화되어야 한다)

법적/운영적으로 명확한 제어점(승인 게이트) 필요
그렇지 않으면 가속이 위험 증가로 전환

4대 소스에 없는 고유 인사이트

"의도 버저닝(Intent Versioning)" 개념
"규칙이 자동 검증되지 않으면 존재하지 않는다" 원칙
법적/운영적 리스크 관점의 하네스 필요성
"에이전트가 규칙의 저자이되, 규칙은 독립적 심판" 패턴

19. Vercel - AGENTS.md vs Skills

(8b 섹션과 동일 - 8번 항목 참조)

20. 용어 비교 정리: Prompt / Context / Harness Engineering

계층 구조

┌─────────────────────────────────────────────┐
│          Harness Engineering                │
│  "시스템이 방지하고, 측정하고, 수정하는 것"     │
│                                             │
│  ┌─────────────────────────────────────┐    │
│  │      Context Engineering            │    │
│  │  "LLM이 보는 모든 것"                │    │
│  │                                     │    │
│  │  ┌─────────────────────────────┐    │    │
│  │  │   Prompt Engineering        │    │    │
│  │  │  "지시 텍스트 최적화"         │    │    │
│  │  └─────────────────────────────┘    │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

상세 비교표

측면Prompt EngineeringContext EngineeringHarness Engineering

은유	음성 명령	지도와 이정표	고삐, 안장, 울타리
핵심 질문	"무엇을 말할까?"	"무엇을 보여줄까?"	"무엇을 방지/측정/제어할까?"
실패 패턴	단일 부정확 출력	단일 부정확 출력	시간에 따른 품질 저하
구현	프롬프트 텍스트	RAG, 메모리, 스키마	린터, CI, 작업 분할, 정리
시간 범위	단일 호출	단일 세션	지속적/장기
진단	즉시 평가 가능	한 번 잘못된 출력? 아마 이것	몇 주간 서서히 저하? 이것

핵심 인용

"Context helps the model think. Harness is what keeps the system from drifting." (MT Rajan)

"Prompt engineering is a subset of context engineering, which is a subset of harness engineering." (SmartScope Blog)

21. 전통적 Test Harness vs Agent Harness

전통적 테스트 하네스(Test Harness)

소프트웨어 테스트를 위한 프레임워크
입력 제공 -> 출력 자동 확인
구성: 실행 엔진 + 스크립트 저장소 + 스텁/드라이버
목적: 테스트의 원활, 반복 가능, 효율적 수행

에이전트 하네스(Agent Harness)

AI 모델을 감싸는 운영 인프라
모델에 도구를 제공하고 입출력을 관리
구성: 워크플로, 가드레일, 배포 통합, 생명주기 관리
목적: 모델 운영 전반의 신뢰성과 통제

관계와 차이

측면Test HarnessAgent Harness

범위	테스트 코드 실행/검증	에이전트 전체 생명주기 관리
대상	소프트웨어 코드	AI 모델/에이전트
역할	통제된 조건에서 실행	도구/메모리/안전/워크플로 관리
겹치는 부분	입출력 검증	코드 출력 테스트 포함 가능
핵심 차이	검증 도구	운영 시스템 + 검증 도구

"While test harness (an older term from software engineering) shouldn't be confused with an AI or agent harness, there is overlap—some AI harnesses include testing capabilities, but the agent harness is much broader." (Parallel.ai)

EleutherAI의 lm-evaluation-harness

LLM 출력 품질(요약/답변/정책 준수/정확성) 회귀 관리를 위한 표준 평가 프레임워크
URL: https://github.com/EleutherAI/lm-evaluation-harness
에이전트 하네스의 "평가(Eval)" 구성요소와 관련

22. 에이전트 프레임워크(CrewAI, AutoGen, LangGraph)와의 관계

프레임워크 vs 하네스

개념역할비유

에이전트 프레임워크 (CrewAI, LangGraph 등)	빌딩 블록/라이브러리	벽돌, 시멘트, 파이프
에이전트 하네스	완성된 운영 시스템	완성된 건물 + 관리 시스템

"A harness wraps both the framework and runtime and adds workflows, guardrails, and deployment integrations." (하네스는 프레임워크와 런타임을 감싸고, 워크플로, 가드레일, 배포 통합을 추가한다)

각 프레임워크의 하네스 접근 방식

CrewAI:

역할 기반(role-based) 모델 - 현실 조직 구조에서 영감
에이전트에 특정 역할 할당 -> 구조화된 작업 실행
하네스 관점: 역할 정의 자체가 일종의 행동 제약

LangGraph:

그래프 기반(graph-based) 워크플로 - 상태 있는 다단계 프로세스
하네스 관점: 그래프 구조가 워크플로 제어를 명시적으로 정의

AutoGen:

대화적 협업(conversational collaboration) 패턴
하네스 관점: 에이전트 간 대화 프로토콜이 암시적 가드레일

프레임워크 합성(Composition) 패턴

LangGraph 에이전트 (복잡 로직)
├── 도구 1: LlamaIndex 쿼리 엔진 (전문 RAG)
├── 도구 2: CrewAI 크루 (하위 작업: "블로그 글 작성")
└── 하네스: 워크플로 + 가드레일 + 관측 가능성

프레임워크는 모놀리스가 아닌 합성 가능한 라이브러리
하네스가 이들을 하나의 작동 시스템으로 묶는 역할

OpenAI Agents SDK의 위치

OpenAI는 자체 Agents SDK를 프레임워크로 제공
하지만 프로덕션 수준의 하네스(Codex 시스템)는 이 위에 별도로 구축
프레임워크 ≠ 하네스임을 자사 사례로 입증

부록: 모든 소스 목록

기존

OpenAI: https://openai.com/index/harness-engineering/
Anthropic: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
LangChain: https://blog.langchain.com/improving-deep-agents-with-harness-engineering/
Martin Fowler: https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

추가 소스 (본 리서치)

Mitchell Hashimoto: https://mitchellh.com/writing/my-ai-adoption-journey
SmartScope Blog: https://smartscope.blog/en/blog/harness-engineering-overview/
Evangelos Pappas: https://dev.to/epappas/the-agent-harness-is-the-architecture-and-your-model-is-not-the-bottleneck-3bjd
Ignorance.ai: https://www.ignorance.ai/p/the-emerging-harness-engineering
Philipp Schmid: https://www.philschmid.de/agent-harness-2026
HTekDev: https://dev.to/htekdev/agent-harnesses-why-2026-isnt-about-more-agents-its-about-controlling-them-1f24
Can Boluk (Can.ac): https://blog.can.ac/2026/02/12/the-harness-problem/
Vercel (도구 축소): https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools
Vercel (AGENTS.md): https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals
Stripe Minions: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
Meta/Manus: https://natesnewsletter.substack.com/p/meta-bought-manus-for-2b-to-acquire
Salesforce: https://www.salesforce.com/agentforce/ai-agents/agent-harness/
Parallel.ai: https://parallel.ai/articles/what-is-an-agent-harness
MT Rajan: https://mtrajan.substack.com/p/harness-engineering-is-not-context
Future of Being Human: https://www.futureofbeinghuman.com/p/what-we-miss-when-we-talk-about-ai-harnesses
Boris Tane: https://boristane.com/blog/how-i-use-claude-code/
Peter Steinberger: https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code
Hugo Bowne-Anderson: https://hugobowne.substack.com/p/ai-agent-harness-3-principles-for
Nahornyi AI LAB: https://nahornyi.ai/en/news/openai-harness-engineering-agentic-reliability-mlops
Zed Blog: https://zed.dev/blog/agentic-engineering-with-mitchell-hashimoto
InfoQ: https://www.infoq.com/news/2026/02/openai-harness-engineering-codex/
Aakash Gupta: https://aakashgupta.medium.com/2025-was-agents-2026-is-agent-harnesses-heres-why-that-changes-everything-073e9877655e
EleutherAI lm-evaluation-harness: https://github.com/EleutherAI/lm-evaluation-harness

'AI > AI 동향' 카테고리의 다른 글

하네스 엔지니어링 (0)	2026.03.02
Claude Code to Figma (0)	2026.02.18
OpenAI, 'Codex' 출시 : 웹-클라우드 환경에서 사용하는 코딩 에이전트 (0)	2025.05.17

하네스 엔지니어링(Harness Engineering) 자료

목차

1. Mitchell Hashimoto

핵심 인사이트

하네스 엔지니어링의 정의

실전 패턴

Zed 블로그에서의 추가 인사이트

4대 소스에 없는 고유 인사이트

2. SmartScope Blog

핵심 인사이트

말(Horse) 은유

3계층 관계 (Harness >= Context >= Prompt)

하네스 엔지니어링의 4사분면(Four Quadrants)

핵심 은유

성능 영향 데이터

4대 소스에 없는 고유 인사이트

3. Evangelos Pappas

핵심 인사이트

에이전트 하네스의 5대 구성요소

APEX-Agents 벤치마크 결과

Vercel의 도구 축소 실험

Manus의 4차 재구축에서 배운 것

비용 경제학

스마트폰 비유

산업 수렴(Industry Convergence)

실전 권장사항

4대 소스에 없는 고유 인사이트

4. Ignorance.ai

핵심 인사이트

기업별 사례

4대 핵심 실천법

엔지니어 역할의 분할

병렬화 모델

미해결 과제

"맛(Taste)"이 핵심 성공 요인

4대 소스에 없는 고유 인사이트

5. Philipp Schmid

핵심 인사이트

하네스가 필요한 3가지 이유

Bitter Lesson 적용

실전 가이드

새로운 방향

4대 소스에 없는 고유 인사이트

6. HTekDev

핵심 인사이트

충격적 데이터

CNCF 플랫폼 제어 프레임워크 적용 - 4기둥

고유 기술 인사이트

@htekdev/agent-harness 라이브러리

전략적 관점

4대 소스에 없는 고유 인사이트

7. Can.ac

핵심 인사이트

Hashline 포맷

벤치마크 결과

핵심 인용

실전 시사점

4대 소스에 없는 고유 인사이트

8. Vercel

8a. 도구 80% 제거 실험

결과

배경

해결책

8b. AGENTS.md가 Skills를 능가한다

벤치마크 결과

왜 수동 컨텍스트(Passive Context)가 승리하는가

Skills의 문제

컨텍스트 효율

핵심 인용

4대 소스에 없는 고유 인사이트

9. Stripe Minions

핵심 인사이트

6계층 엔지니어링 하네스

MCP와 내부 도구

격리된 실행 환경

하이브리드 워크플로 (창의적 + 결정론적)

4대 소스에 없는 고유 인사이트

10. Meta의 Manus 인수

핵심 인사이트

핵심 비유