하네스 엔지니어링이란? 모델보다 환경이 AI 성능을 가르는 이유

같은 프롬프트를 던졌어요. "레트로 게임 메이커 앱을 만들어줘." 한쪽 에이전트는 20분 만에 9달러를 쓰고 멈췄어요. 결과물은 핵심 기능조차 돌아가지 않았죠. 다른 쪽은 6시간 동안 200달러를 쓰더니, 기능 16개를 전부 작동시켰어요.

같은 모델, 같은 지시. 차이는 단 하나였어요. 두 번째 에이전트에게는 하네스가 있었거든요.

2026년 초, 이 차이에 이름이 붙었어요. 바로 하네스 엔지니어링(Harness Engineering)이에요. 모델을 더 똑똑하게 만드는 게 아니라, 모델이 잘못된 행동을 할 수 없는 환경을 설계하는 기술이죠. 이번 글에서는 하네스 엔지니어링이 정확히 무엇인지, 왜 2026년의 핵심 키워드가 됐는지, 어떻게 하는지, 그리고 OpenAI·Stripe·Anthropic 같은 회사들이 실제로 어떻게 적용하고 있는지를 한 번에 정리해드릴게요.

하네스 엔지니어링이란 무엇인가요?

하네스 엔지니어링은 AI 에이전트가 올바르게 행동할 수밖에 없는 외부 환경 전체를 설계하는 방법론이에요. 프롬프트를 잘 쓰는 게 아니라, 에이전트를 감싸는 구조·제약·피드백 루프를 설계해서, AI가 사람 감독 없이 자율적으로 일해도 일관되고 안전하게 동작하게 만드는 거죠.

말(馬)과 마구(馬具)의 비유

'하네스(harness)'는 원래 말에 채우는 마구를 뜻해요. 안장, 고삐, 굴레 같은 장치죠. 아무리 힘센 말이라도 마구가 없으면 제멋대로 달리지만, 마구를 채우면 그 힘을 원하는 방향으로 끌어낼 수 있어요.

AI도 똑같아요. GPT든 Claude든 이미 충분히 강력한 모델이에요. 문제는 이 힘을 어떻게 통제하느냐죠. 하네스 엔지니어링의 핵심 공식은 이렇게 정리돼요.

Agent = Model + Harness. 에이전트는 모델 하나가 아니라, 모델과 그것을 감싸는 환경의 합이에요.

OpenAI는 하네스를 "에이전트가 안정적으로 작업을 수행하도록 감싸는 스캐폴딩(scaffolding)이자 피드백 루프가 구축된 전체 환경"으로 정의해요. 저장소 구조, CI 설정, 포맷 규칙, 패키지 관리자, 프로젝트 지시 사항, 외부 도구 연결, 린터까지 — 에이전트 바깥에서 동작하는 시스템 전체가 하네스예요. 자세한 정의는 OpenAI의 공식 아티클에서 확인할 수 있어요.

프롬프트도 컨텍스트도 아닌, 환경을 설계한다

여기서 헷갈리기 쉬운 지점이 있어요. "그거 그냥 프롬프트 잘 쓰는 거 아냐?" 아니에요. 작동하는 위치가 완전히 달라요.

프롬프트 엔지니어링이 모델에게 "오른쪽으로 돌아"라고 말하는 음성 명령이라면, 하네스 엔지니어링은 고삐와 안장을 채우고, 울타리를 세우고, 도로까지 정비해서 말 열 마리가 동시에 안전하게 달리게 만드는 전체 설계예요. 전자는 한 번의 지시고, 후자는 시스템이죠.

왜 2026년에 갑자기 이 단어가 등장했나요?

하네스 엔지니어링은 AI 활용 패러다임이 세 번째 단계로 넘어갔다는 신호예요. 모델이 충분히 똑똑해지면서, 병목이 모델 자체가 아니라 모델을 둘러싼 환경으로 옮겨갔거든요.

프롬프트 → 컨텍스트 → 하네스, 3단계 진화

지난 3년 동안 우리가 AI에게 던진 질문은 계속 바뀌어 왔어요.

프롬프트 엔지니어링은 "무엇을 물어볼까", 컨텍스트 엔지니어링은 "무엇을 보여줄까"에 답해요. 하네스 엔지니어링은 질문 자체가 달라요. "에이전트 바깥의 제약, 피드백, 운영 시스템 전체를 어떻게 설계할까"를 묻죠.

이 개념이 표면으로 떠오른 건 2026년 2월이에요. HashiCorp 공동 창업자 미첼 하시모토(Mitchell Hashimoto)가 자신의 블로그에서 "Engineer the Harness"라는 표현을 처음 썼고, 며칠 뒤 OpenAI가 공식 아티클을 발표했어요. 이후 한 달 만에 Martin Fowler, Anthropic, Stripe, LangChain이 잇따라 정리하면서 업계 표준 어휘로 자리 잡았죠.

모델은 상향 평준화되고, 하네스는 자산으로 남아요

왜 이게 중요할까요? 답은 경쟁력의 위치가 바뀌었기 때문이에요.

모델 성능은 빠르게 평준화되고 있어요. GPT가 앞서면 Claude가 따라오고, Gemini도 금세 올라와요. 어떤 회사도 모델 성능만으로 오래 앞서기 어렵죠. 반면 하네스는 팀이 직접 쌓아야 하는 자산이에요. 우리 코드베이스에 맞는 규칙, 반복된 실패에서 뽑아낸 검증 게이트, 도메인 특화 스킬 — 이건 돈 주고 살 수 없어요.

모델은 누구나 같은 걸 쓰지만, 하네스는 아무도 똑같이 가질 수 없어요. 그래서 하네스가 진짜 해자(moat)가 돼요.

실제로 측정된 사례도 있어요. revfactory의 통제 실험에서는 모델을 고정한 채 구조화된 사전 설정(하네스)만 추가했더니 코드 출력 품질이 평균 49.5점에서 79.3점으로, 약 60% 올랐어요. 흥미로운 건 과제가 어려울수록 개선 폭이 커졌다는 점이에요(Basic +23.8, Expert +36.2). 다만 이 수치는 저자의 자체 A/B 측정값이고 제3자 재현이 진행 중이라는 점은 감안해서 봐야 해요.

하네스는 어떻게 생겼나요? 입력·출력·실행을 통제한다

하네스를 한 문장으로 요약하면 '통제하는 껍데기'예요. 그런데 무엇을 통제할까요? 크게 세 가지 길목을 통제해요.

식당으로 보는 입력·출력·실행 제어

에이전트를 식당이라고 생각해볼게요. 손님 주문이 들어오고, 주방에서 요리하고, 음식이 나가요. 하네스는 이 세 길목마다 검문소를 세워요.

입력 제어는 문지기예요. AI에 전달되기 전에 부적절한 입력, 개인정보, 악의적 명령을 걸러내죠. "이상한 손님은 들이지 않는다"는 규칙이에요. 출력 제어는 서빙 전 검수예요. AI가 만든 답변의 형식·정확성·안전성을 내보내기 전에 검증해요. 실행 제어는 주방 규칙이에요. 에이전트가 할 수 있는 작업 범위를 명시적으로 제한하죠. 예를 들어 "조회는 되지만 삭제는 안 된다"처럼요.

[이미지: 사용자 입력 → 입력 제어(문지기) → AI 에이전트 → 출력 제어(검수) → 실행 제어(주방 규칙) → 응답으로 이어지는 흐름도]

이 세 검문소가 있으면, 에이전트가 아무리 자율적으로 움직여도 위험한 행동이 사용자나 시스템에 도달하기 전에 걸러져요. 자율성과 안전성을 동시에 잡는 구조죠.

하네스를 이루는 다섯 가지 부품

실제 하네스는 다섯 가지 구성요소로 조립돼요. 하나씩 볼게요.

첫째, 컨텍스트 레이어(AGENTS.md / CLAUDE.md)예요. 에이전트가 작업을 시작할 때 가장 먼저 읽는 프로젝트 지시 파일이에요. 프로젝트 목적, 디렉터리 구조, 코딩 컨벤션, 커밋 규칙, 그리고 "절대 하면 안 되는 행동"이 담겨요. 주의할 점은, 하나의 거대한 매뉴얼을 만들면 오히려 역효과라는 거예요. OpenAI는 이걸 "낡은 규칙들의 무덤"이라고 표현했어요. 그래서 AGENTS.md는 100줄짜리 목차처럼 짧게 유지하고, 실제 지식은 docs 디렉터리에 구조화하는 방식을 권해요.

둘째, 스킬 파일(SKILL.md)이에요. 에이전트가 반복적으로 수행하는 작업의 베스트 프랙티스를 캡슐화한 문서죠. git 커밋 방식, PR 생성 절차, 코드 리뷰 체크리스트 같은 팀 고유의 노하우를 담아요. 에이전트는 특정 작업을 시작하기 전에 해당 스킬 문서를 먼저 읽고 그 절차를 따르고요.

셋째, 규칙과 권한(Rules / Permissions)이에요. AGENTS.md가 "이렇게 일하라"는 가이드라인이라면, 규칙은 "무슨 일이 있어도 이것만은 지켜라"는 절대 원칙이에요. 예를 들어 git 명령은 허용하되, 위험한 삭제 명령이나 환경 변수 파일 수정은 차단하는 식이죠. 특정 디렉터리에서만 특정 규칙이 활성화되도록 경로별로 설정할 수도 있어요.

넷째, 피드백 루프예요. 잠시 뒤에 따로 자세히 다룰 만큼 중요한 부품이에요. 에이전트가 올바른 방향으로 가도록 안내하고, 잘못된 결과를 감지하는 장치들이죠.

다섯째, 기계적 강제와 코드 정리예요. 에이전트가 코드를 대량 생성하면 아키텍처 일관성이 무너지기 쉬워요. 이걸 막으려고 아키텍처 의존성 방향을 린터와 구조 테스트로 강제하고, 백그라운드 에이전트가 지속적으로 코드와 문서의 편차를 스캔해서 리팩토링을 제안해요. "한 번에 크게 청산하지 말고, 매일 조금씩 정산한다"는 원칙이죠.

여기에 외부 도구 연결을 위한 MCP(Model Context Protocol)도 빼놓을 수 없어요. 에이전트가 이슈 트래커, 위키, 모니터링 같은 외부 시스템에 접근하게 해주는 프로토콜이에요. 다만 도구 정의 자체가 토큰을 소비하기 때문에, 도구가 100개를 넘어가면 에이전트 성능이 급락한다는 보고가 있어요. 그래서 필요한 것만 선별적으로 연결하는 게 핵심이에요.

에이전트를 길들이는 법, 피드백 루프 설계

하네스의 심장은 피드백 루프예요. 에이전트가 실수했을 때 그 실수를 어떻게 감지하고, 어떻게 다시 바로잡게 만드느냐가 전부거든요. Martin Fowler는 이 피드백을 두 종류로 나눠 정리했어요.

가이드와 센서, 두 방향의 피드백

가이드(Guide)는 올바른 방향을 미리 안내하는 피드포워드예요. 작업 전이나 작업 중에 작동하죠. AGENTS.md의 예시 코드, 미리 준비한 테스트 케이스가 여기 해당해요. 센서(Sensor)는 잘못된 결과를 나중에 감지하는 피드백이에요. 작업 후에 작동하죠. CI 실패, 린터 경고, 테스트 실패가 대표적이에요.

핵심 원칙은 하나예요. 피드백은 빠를수록 좋다. 에이전트가 잘못된 방향으로 100줄을 쓴 뒤에 오류를 아는 것보다, 10줄 시점에 아는 게 훨씬 나아요. 그래서 좋은 하네스는 pre-commit 린터로 형식 오류를 즉시 차단하고, CI 테스트로 로직 오류를 감지하고, 실패하면 에이전트가 오류 메시지를 읽고 스스로 수정하게 만들어요. Fowler의 센서 분류는 Martin Fowler 아티클에 자세히 정리돼 있어요.

계획-실행-검증(PEV) 루프

최근 학계는 이 피드백 과정을 하나의 통제 루프로 묶어서 부르기 시작했어요. 바로 PEV(Plan-Execute-Verify) 루프예요.

동작은 이래요. 먼저 에이전트가 바꾸려는 내용과 검증 기준을 명시적으로 꺼내놓아요(계획). 그다음 격리된 샌드박스 환경 안에서 그 변경을 실행해요(실행). 마지막으로 린터·테스트 같은 결정론적 센서와 사람 검토 게이트로 결과 상태를 검증하죠(검증). 검증을 통과하면 수용하고, 실패하면 수정·재시도하거나 사람에게 에스컬레이션해요.

이 루프가 중요한 이유는, 에이전트의 자율성을 '되돌릴 수 있고, 관찰할 수 있고, 수정할 수 있는' 상태 전환으로 바꿔주기 때문이에요. 특히 금융·배포처럼 위험한 작업은 사람 승인(HITL) 게이트를 의무로 두고, 안전한 조회 작업은 자율로 풀어주는 식으로 권한을 계층화해요. 자율성과 책임성을 동시에 설계하는 거죠.

그래서 다들 어떻게 하고 있나요?

개념은 이쯤이면 충분해요. 진짜 궁금한 건 "실제로 효과가 있냐"겠죠. 2026년 상반기에 공개된 다섯 회사의 사례를 수치와 함께 볼게요.

OpenAI — 수동 코드 0줄로 100만 줄을 만들다

가장 강력한 원조 사례예요. OpenAI는 2025년 8월부터 2026년 1월까지 5개월간, 엔지니어 3명에서 7명으로 시작한 팀이 약 100만 줄의 프로덕션 코드를 만들었어요. 그중 사람이 손으로 작성한 코드는 0줄이에요. 약 1,500개의 PR이 머지됐고, 엔지니어 1인당 하루 3.5개 PR을 처리했죠. 일반 개발 대비 약 10배 속도예요.

비결은 하네스 설계였어요. AGENTS.md를 100줄짜리 목차로 두고 상세 규칙은 docs로 분산했어요. 그리고 아키텍처 의존성 방향(Types → Config → Repo → Service → Runtime → UI)을 린터로 강제해서, 이 방향을 위반하는 코드가 생성되면 즉시 차단하고 수정 방법을 에이전트에게 주입했죠. 백그라운드에서는 코드 정리 에이전트가 계속 돌면서 리팩토링 PR을 자동 제출했고요.

에이전트가 실수하면 에이전트 문제가 아니라 환경 문제예요. 부족한 도구·가드레일·문서를 찾아 고치고, 그 수정조차 에이전트에게 쓰게 해서 다시 반영하는 반복이 본질이에요.

Stripe — Slack 이모지 하나로 주 1,300개 PR

결제 회사 Stripe는 'Minions'라는 내부 에이전트 군단을 운영해요. 매주 1,300개 이상의 PR을 사람이 코드 한 줄 쓰지 않고 자동으로 머지하죠. 트리거는 놀랍게도 Slack 이슈 스레드에 다는 이모지 반응 하나예요. 엔지니어가 이모지를 달고 자리를 비우면, 돌아왔을 때 테스트를 통과한 완성된 PR이 기다리고 있어요.

Stripe 엔지니어 Steve Kaliski에 따르면, 이게 가능한 건 수년간 쌓은 6계층 하네스 덕분이에요. 격리된 VM에서 시작해, 로컬 린터, 선택적 CI, 비용 폭주를 막는 타임아웃, 사람이 중간 지시를 넣는 하이브리드 단계, 마지막 인간 코드 리뷰까지 여섯 겹으로 감싸요. 내부 도구 400개 이상을 MCP로 연결하되 필요한 것만 선별 제공하고요.

여기서 중요한 구분이 나와요. Cursor나 Claude Code 같은 도구는 사람이 옆에서 지켜보며 단계마다 승인하는 '감독형(attended)' 에이전트예요. 반면 Minions는 아무도 지켜보지 않는 '무감독(unattended)' 에이전트죠. 이 차이가 하네스 설계 요구사항을 완전히 바꿔요. 수억 줄 규모의 Ruby 코드베이스에서 무감독 에이전트가 안정적으로 돌려면, 잘 정제된 컨텍스트와 빠른 피드백이 필수거든요. 자세한 워크플로는 How I AI 분석에서 볼 수 있어요.

Anthropic — 9달러의 실패, 200달러의 완성

글 맨 처음 소개한 그 실험이 바로 Anthropic 사례예요. 동일한 "레트로 게임 메이커 앱" 프롬프트로, 하네스 없는 솔로 에이전트는 9달러·20분 만에 핵심 기능도 못 만들고 멈췄고, 하네스를 갖춘 에이전트는 200달러·6시간으로 기능 16개를 전부 완성했어요.

솔로 에이전트가 실패한 원인은 두 가지였어요. 하나는 컨텍스트 불안이에요. 컨텍스트 창이 길어질수록 초반 합의를 잊고 엉뚱한 방향으로 새는 거죠. 다른 하나는 자기평가 편향이에요. 자기가 만든 코드를 자기가 검토하면 늘 "잘 됐다"고 판단해서 테스트를 생략하거든요.

Anthropic은 GAN에서 영감받은 3-에이전트 구조로 이걸 풀었어요. 플래너가 짧은 프롬프트를 상세 스펙으로 확장하고, 생성기가 코드를 구현하되 컨텍스트가 리셋되면 진행 상태 파일을 다시 읽어요. 그리고 생성기와 완전히 분리된 평가기가 Playwright로 실제 페이지를 직접 탐색하며 채점하죠. 디자인·기능·코드 품질·요구사항 충족을 주관적 판단이 아니라 수치화된 루브릭으로 강제 채점하고요. 설계 원칙은 Anthropic 엔지니어링 블로그에 공개돼 있어요.

LangChain — 모델은 그대로, 순위만 25계단

하네스의 위력을 가장 깔끔하게 증명한 사례예요. LangChain은 Terminal Bench 2.0 벤치마크에서 모델을 전혀 바꾸지 않고 하네스만 개선했어요. 결과는 점수 52.8%에서 66.5%로 13.7%포인트 상승, 순위는 Top 30 밖에서 Top 5로 도약이었죠.

바꾼 건 세 가지였어요. 첫째, 에이전트가 종료 직전에 "코드 다시 읽고 OK"라고 자기 판단하는 나쁜 패턴을 가로채서, 계획-구축-검증-수정 루프를 다시 강제하는 미들웨어를 넣었어요. 둘째, 시작할 때 현재 디렉터리 구조와 사용 가능한 도구를 자동으로 파악해 주입해서, 에이전트가 환경 탐색에 낭비하는 비용을 없앴고요. 셋째, 추론 예산을 '계획 단계 최고 집중 → 구현 단계 보통 → 최종 검증 다시 최고 집중'으로 배분하는 구조를 적용했죠. 모델은 손대지 않고 환경만 바꿨는데 결과가 이만큼 달라진 거예요.

Hashimoto — 1인 개발자의 하네스

하네스는 거대 조직만의 이야기가 아니에요. 터미널 앱 Ghostty를 만드는 미첼 하시모토는 혼자서도 하네스를 써요. 저녁에 리서치 에이전트를 돌려놓고 다음 날 아침 결과물로 업무를 시작하거나(Warm-Start), 명확한 단순 작업은 에이전트에 완전히 위임하거나(Slam Dunk), 작업 완료를 알림 훅으로 자동 통보받는 식이죠.

하시모토의 통찰이 하네스 엔지니어링의 정수를 보여줘요.

에이전트가 실수했을 때, 나는 실수를 고치는 데서 멈추지 않아요. 그 실수가 구조적으로 재발 불가능하도록 환경을 바꿔요.

다섯 사례를 한 표로 정리하면 이래요.

하네스 엔지니어링은 개발 영역에만 머물지 않아요. 에이전트를 관측하고 평가하는 도구를 붙인 엔터프라이즈 사례도 빠르게 늘고 있죠. 결제 기업 Klarna는 AI 어시스턴트에 피드백 루프를 붙여 고객 케이스 해결 시간을 약 80% 단축했고, 물류 기업 C.H. Robinson은 하루 5,500건의 주문을 자동 처리해 약 600시간을 아꼈어요. Podium은 엔지니어링 에스컬레이션을 90% 줄였고요. 공통점은 분명해요. 모델을 바꾼 게 아니라, 에이전트를 감싸는 검증·관측·피드백 환경을 설계했다는 거예요. 코드를 쓰는 에이전트든 고객 문의를 처리하는 에이전트든, 하네스의 원리는 똑같이 작동해요.

한 걸음 더, "코드가 곧 하네스"라는 학술적 관점

여기까지가 실무 현장의 이야기라면, 학계는 이 흐름을 더 근본적인 틀로 정리하고 있어요. 2026년 일리노이대(UIUC)·메타·스탠퍼드 연구진이 발표한 서베이 논문 Code as Agent Harness가 대표적이에요.

이 논문의 핵심 주장은 흥미로워요. 코드는 더 이상 에이전트가 만들어내는 결과물이 아니라, 에이전트가 추론하고 행동하고 환경을 표현하는 실행 매개체라는 거예요. 코드는 실행 가능하고(executable), 들여다볼 수 있고(inspectable), 상태를 유지(stateful)하기 때문에, 자연어보다 하네스 인터페이스로 훨씬 적합하다는 논리죠. 실행 가능하니 의도를 검증할 수 있고, 들여다볼 수 있으니 실패를 진단해 피드백할 수 있고, 상태를 유지하니 단계 사이에 맥락이 사라지지 않아요.

논문은 하네스를 세 계층으로 분류해요. 첫째 하네스 인터페이스는 코드가 추론·행동·환경 모델링을 연결하는 층이에요. 둘째 하네스 메커니즘은 계획·메모리·도구 사용·검증을 장기 실행 동안 지탱하는 층이고요. 셋째 하네스 스케일링은 단일 에이전트를 넘어 여러 에이전트가 공유 코드 위에서 협업·검증하는 층이에요. 이 분류는 앞서 본 OpenAI·Stripe 사례가 왜 작동하는지를 이론적으로 설명해줘요.

흥미로운 건, 이 관점이 코딩에만 국한되지 않는다는 점이에요. 논문은 코드가 공통 매개체로 작동하는 다섯 개 응용 도메인을 짚어요. 저장소에서 패치를 만드는 코딩 어시스턴트, 화면과 운영체제를 조작하는 GUI/OS 자동화, 가설을 코드로 검증하는 과학 연구 에이전트, 사용자 선호를 편집 가능한 상태로 다루는 개인화 추천, 그리고 물리 제약 아래 동작하는 로봇 에이전트까지요. 영역은 달라도 코드가 실행·검증·상태 유지의 매개체가 된다는 원리는 같아요.

동시에 논문은 아직 풀리지 않은 숙제도 짚어요. 최종 작업 성공만으로는 하네스를 평가할 수 없다는 점, 불완전한 피드백 아래서 어떻게 검증할 것인가, 하네스가 스스로 진화하되 기존 성능을 후퇴시키지 않게 하는 법, 여러 에이전트 사이 상태를 일관되게 유지하는 법 같은 것들이죠. 하네스 엔지니어링이 이제 막 '과학'으로 정립되기 시작한 분야라는 신호예요.

우리 팀은 어떻게 시작하면 될까요?

거창하게 들리지만, 시작은 작아도 돼요. 세 단계면 충분해요.

1단계, AGENTS.md부터 짧게 써보세요. 프로젝트 구조, 빌드 명령, 코딩 규칙을 짧게 적는 것부터 시작해요. 그리고 에이전트가 반복적으로 틀리는 부분이 생기면, 그때그때 해당 규칙을 추가하는 거예요. 처음부터 완벽한 매뉴얼을 만들 필요는 없어요. 오히려 거대한 문서는 역효과라고 했죠.

2단계, MCP로 자주 쓰는 외부 시스템을 연결하세요. 에이전트가 자주 참조하는 이슈 트래커, 위키, 모니터링 도구를 선별해서 붙여요. 단, 욕심내서 다 붙이면 안 돼요. 도구가 너무 많으면 성능이 떨어지니까, 정말 필요한 것만 골라요.

3단계, 린터와 CI로 피드백 루프를 만드세요. 에이전트가 CI 실패 로그를 읽고 스스로 수정하는 구조를 만들어요. 이게 가이드와 센서가 함께 도는 가장 기본적인 피드백 루프예요. 여기까지만 해도 에이전트의 안정성이 눈에 띄게 달라져요.

중요한 건 마음가짐이에요. 에이전트가 실수할 때마다 "이 모델은 왜 이래"라고 탓하는 대신, "이 실수가 다시 일어나지 않게 환경의 무엇을 바꿔야 할까"를 물으세요. 그 질문을 반복하는 것, 그게 하네스 엔지니어링의 전부예요.

정리하자면

하네스 엔지니어링은 모델을 더 똑똑하게 만드는 기술이 아니에요. 모델이 잘못된 행동을 할 수 없는 환경을 설계하는 기술이죠. 프롬프트가 한 번의 지시, 컨텍스트가 한 화면의 구성이라면, 하네스는 에이전트가 사람 없이도 신뢰 가능하게 일하는 세계 전체예요.

OpenAI의 100만 줄, Stripe의 주 1,300 PR, Anthropic의 9달러와 200달러, LangChain의 25계단 도약. 이 사례들이 공통으로 말하는 건 하나예요. 모델은 누구나 같은 걸 쓰지만, 결과를 가르는 건 그 모델을 어떻게 감싸느냐라는 거예요.

모델 성능은 계속 상향 평준화될 거예요. 그래서 진짜 경쟁력은 점점 더 모델 바깥으로, 팀이 직접 쌓아 올린 하네스로 옮겨가고 있어요. AI를 쓰는 시대가 아니라, AI가 일할 환경을 설계하는 시대로 넘어가는 중이에요.

출처 — 이 글은 OpenAI의 하네스 엔지니어링 공식 아티클, Anthropic의 장기 실행 앱 하네스 설계 블로그, Martin Fowler의 하네스·센서 아티클, Stripe Minions를 다룬 How I AI 분석, 미첼 하시모토의 AI 도입 여정 블로그, 그리고 UIUC·메타·스탠퍼드 공동 서베이 논문 'Code as Agent Harness'를 종합해 작성했어요. 일부 성과 수치(revfactory, Anthropic 비용 실험 등)는 각 주체의 자체 측정값으로, 제3자 재현 결과는 다를 수 있어요.