같은 Opus인데 왜 결과가 다를까 — 하네스 엔지니어링이라는 답 | 김성박의 즐거운 에이전틱 코딩

올해 3월, Anthropic 엔지니어링 블로그에 눈에 띄는 실험 결과가 올라왔습니다. 같은 Opus 4.5에게 같은 프롬프트를 줬거든요. "2D 레트로 게임 메이커를 만들어라." 한쪽은 고장난 UI만 나왔고, 다른 한쪽은 레벨 에디터, 스프라이트 에디터, 플레이 테스트까지 갖춘 게임이 실제로 돌아갔습니다. 16개 기능, 10개 스프린트를 거쳐서요.

같은 모델, 같은 프롬프트. 차이는 모델 바깥에 있었습니다.

고장난 쪽은 모델에게 그냥 시켰고, 돌아가는 쪽은 모델을 둘러싼 환경을 설계했습니다. 이 환경을 요즘 "하네스(harness)"라고 부르고, 이걸 설계하는 행위를 "하네스 엔지니어링"이라고 합니다.

저도 Claude Code를 꽤 오래 써왔는데, 이 실험을 보고 나서야 왜 어떤 날은 괜찮은 결과를 얻고 어떤 날은 시간만 날렸는지 이해가 됐습니다. 모델 탓이 아니라 제가 만든 환경의 차이였던 겁니다.

하네스가 뭔데, 그게 그렇게 중요한가

OpenAI가 2026년 2월에 낸 블로그에서 이 용어를 처음 꺼냈습니다. 내부에서 5개월간 실험한 결과인데, 빈 레포지토리에서 시작해서 약 100만 줄의 프로덕션 코드를 사람 손으로 한 줄도 쓰지 않고 베타 제품을 출시한 이야기였습니다.

블로그에서 OpenAI가 한 말이 인상적이었는데요.

"엔지니어의 주요 업무가 코드 로직 작성에서 환경, 의도, 피드백을 루프형으로 설계하는 역할로 넘어갔다."

하네스란 결국 모델을 둘러싼 모든 것입니다. 어떤 정보를 주는지(컨텍스트), 어떤 도구를 쥐어주는지(MCP, 스킬), 어떻게 반복시키는지(실행 루프), 어떻게 검증하는지(테스트, 평가), 언제 사람이 끼어드는지(감독). 이 다섯 가지가 모델의 성능을 좌우합니다. 모델 자체가 아니라요.

다음 그림은 하네스를 구성하는 5가지 핵심 요소를 보여줍니다.

하네스 구성 요소

AI 모델을 중심에 두고, 컨텍스트·도구·실행 루프·검증·사람이 모델을 둘러싸고 있습니다. 이 중 하나라도 빠지면 에이전트가 제대로 동작하기 어렵습니다.

Anthropic의 실험에서 돌아가는 쪽이 한 일도 여기 있습니다. 모델을 세 개로 분리했거든요. Planner가 한 문장짜리 프롬프트를 16개 기능의 제품 명세로 확장하고, Generator가 스프린트 방식으로 하나씩 구현하고, Evaluator가 Playwright로 실제로 앱을 클릭하면서 테스트했습니다. 고장난 쪽은 이 과정 없이 모델 하나가 다 하려고 했고요.

컨텍스트는 많을수록 좋을까요? 연구 결과는 반대였습니다

하네스에서 가장 먼저 부딪히는 문제가 컨텍스트입니다. 모델에 정보를 얼마나, 어떻게 넣어줄 것인가.

직감적으로는 많이 넣을수록 좋을 것 같죠. Opus가 1M 토큰까지 처리하고, GPT도 수십만 토큰을 지원하니까요. 근데 Chroma Research에서 18개 모델(GPT-4.1, Claude Opus 4, Gemini 2.5 Pro 포함)을 테스트한 결과는 달랐습니다.

모든 모델이 컨텍스트가 늘어나면 성능이 떨어졌습니다. 예외 없이요.

200K 모델 기준으로 약 130K 토큰부터 품질이 눈에 띄게 떨어지기 시작합니다. Stanford와 UC Berkeley의 "Lost in the Middle" 연구에서는 더 구체적인 수치가 나왔는데, 컨텍스트 시작과 끝에 있는 정보는 잘 활용하지만 중간에 있는 정보의 정확도가 30% 이상 떨어집니다.

트랜스포머가 자기회귀적(autoregressive)으로 돌아가기 때문입니다. 토큰이 늘어나면 연산량이 같이 늘고, 그만큼 틀릴 확률도 올라갑니다. 100K 토큰이면 100억 개의 쌍별 관계를 처리해야 하거든요.

제 경험으로도 300K를 넘기면 결과물이 쓸 만하지 않았습니다. Claude Code와 Codex가 컨텍스트가 95%쯤 차면 자동 압축을 하는 것도 이런 이유겠죠.

결국 컨텍스트는 예산입니다. 한정된 예산에서 가치 높은 것만 골라야 합니다. 저는 이렇게 나눕니다.

세션 시작 시 바로 넣는 것:

작업 목표와 제약 사항
코딩 컨벤션, 아키텍처 변경 이력
절대 하면 안 되는 행동 (보안 규칙, 접근 금지 폴더)

필요할 때 도구로 가져오는 것:

세부 코드 내용 (수정 시점에 읽으면 됨)
대용량 로그, 외부 API 문서
테스트 실행 결과 (성공 로그가 대부분이라 쓸데없이 컨텍스트만 차지함)

OpenAI도 100만 줄 실험에서 같은 원칙을 적용했습니다. 그들의 표현을 빌리면 "문서를 백과사전이 아닌 목차로 취급한다." 에이전트가 먼저 목차를 읽고, 필요한 세부 문서로 들어가서 읽는 구조입니다.

자동 루프 없이 에이전트를 쓴다면 그건 채팅일 뿐이다

Anthropic 실험에서 고장난 쪽이 실패한 건 모델이 나빠서가 아닙니다. 검증 루프가 없었기 때문입니다.

기존에 IDE 채팅으로 코딩하던 방식을 떠올려보면 이해가 빠릅니다.

다음 그림은 두 방식의 차이를 보여줍니다.

수동 루프 vs 자동화된 하네스 루프

왼쪽은 사람이 매번 직접 확인하고 설명해야 하는 수동 루프이고, 오른쪽은 목표와 검증 기준만 설정하면 에이전트가 알아서 반복하는 자동화된 루프입니다.

수동 루프에서는 사람이 요청하고, 결과를 확인하고, 문제를 찾아서 다시 설명합니다. 한두 번은 괜찮은데 이게 반복되면 지칩니다. 그리고 피곤해지면 검토를 대충 하게 되죠.

하네스 기반 루프에서는 목표와 검증 기준을 미리 설정합니다. 에이전트가 코드를 짜고, 테스트를 돌리고, 실패하면 알아서 수정하고, 통과하면 사람에게 보고합니다. 사람은 방향만 잡아주면 됩니다.

Anthropic 실험에서 돌아가는 쪽의 Evaluator 에이전트가 한 일이 정확히 이겁니다. 매 스프린트가 끝날 때마다 Playwright로 앱을 실제로 클릭하면서 기준에 미달하면 스프린트를 실패 처리하고 피드백을 줬습니다. Sprint 3 하나에만 레벨 에디터 관련 27개 검증 기준이 있었다고 합니다.

실무에서 이걸 가장 쉽게 구현하는 방법은 **훅(hook)**입니다. Claude Code 기준으로 세션 시작 시 컨벤션을 강제로 주입하고, 작업 완료 시 테스트를 자동 실행하고, 커밋 전에 린트를 체크하는 식으로요. 문서에 "이렇게 해주세요"라고 써놓는 것과 코드로 강제하는 것은 완전히 다릅니다. 문서만 있으면 에이전트가 안 읽을 수 있지만, 훅은 무조건 실행되니까요.

OpenAI도 비슷하게 접근했습니다. 코드가 특정 레이어 순서(Types → Config → Repo → Service → Runtime → UI)로만 의존할 수 있도록 했는데, 이걸 문서가 아니라 구조 테스트로 기계적으로 차단했습니다.

같은 모델이 자기 작업을 평가하면 안 되는 이유

하네스에서 가장 간과하기 쉽지만 위험한 함정이 자기 평가 편향(self-evaluation bias)입니다.

Anthropic 실험에서 나온 건데, 에이전트가 자기 작업을 평가하면 품질이 떨어져도 자신있게 칭찬합니다. 디자인 같은 주관적 과제에서 특히 심하고요. 문제를 발견하고도 "별거 아니네"라고 넘어가는 행동까지 관찰됐습니다.

그냥 관찰 수준이 아니라 연구로 검증된 현상이기도 합니다. LLM 평가자의 에러율이 50%를 넘는 경우가 확인됐고, 위치 편향(먼저 나온 답을 선호), 길이 편향(긴 출력을 선호), 동의 편향(비판 없이 수용) 같은 게 체계적으로 나타납니다.

Anthropic이 찾은 해결책은 단순했습니다. 생성과 평가를 분리하는 거죠. Generator와 Evaluator를 나누고, Evaluator를 회의적으로 튜닝하는 게 Generator를 자기 비판적으로 만드는 것보다 훨씬 쉽고 잘 먹혔다고 합니다. GAN에서 영감을 받은 아키텍처입니다.

이 원칙을 제 작업에 적용하면서 Claude Code와 Codex를 같이 쓰게 됐습니다.

다음 그림이 이 흐름을 잘 보여줍니다.

교차 검증 워크플로우

Claude(보라색)와 Codex(파란색)가 번갈아가며 작성과 검증을 수행하고, 최종 머지는 사람(초록색)이 결정합니다. 핵심 규칙은 오른쪽에 써있는 그대로입니다.

Claude Code는 코드를 짜는 데 강합니다. 파일 여러 개를 동시에 건드리는 리팩토링이나 탐색적 디버깅에서 특히요. Codex는 계획을 세우고 검증하는 데 더 강점이 있습니다. Terminal-Bench 2.0에서 GPT-5.3-Codex가 77.3%로 1위고, 테스트 실행 → 실패 → 자체 수정 → 재실행하는 내장 루프가 강력하거든요.

아키텍처도 다릅니다. Claude Code는 로컬에서 내 파일시스템을 직접 읽고 터미널 명령을 실행하고, Codex는 클라우드 샌드박스에서 돌아가서 내 환경에 영향 없이 빌드와 테스트를 수행합니다.

학습 데이터가 다르니까 같은 코드를 봐도 다른 관점이 나옵니다. Claude가 짠 코드를 Codex가 검증하고, Codex가 수정한 걸 다시 Claude가 보는 교차 방식이 자기 평가보다 훨씬 믿을 만합니다.

하네스도 유통기한이 있다

Anthropic 블로그에서 자꾸 머릿속을 맴도는 문장이 하나 있습니다.

"하네스 조합의 흥미로운 공간은 모델이 개선된다고 줄어들지 않는다. 대신 이동한다."

Opus 4.5에서 4.6으로 올라가면서 실제로 많은 게 바뀌었습니다. 스프린트 구조를 빼도 됐고(모델이 알아서 쪼개니까), 2시간 넘게 일관되게 작업하고, 평가도 마지막에 한 번만 돌리면 충분해졌습니다. Anthropic조차 "이건 이제 필요 없다"면서 없앤 게 꽤 됩니다.

그런데 동시에, 이전에는 불가능했던 더 복잡한 작업에 하네스를 적용할 수 있게 됐습니다. Opus 4.6으로 DAW(디지털 오디오 워크스테이션)를 약 4시간, $124에 만든 사례도 있고요.

오늘 잘 돌아가는 하네스가 다음 모델 업데이트에서도 최적이라는 보장은 없습니다. 그래서 측정이 중요합니다.

측정 안 하면 개선도 없다

Red Hat의 Eval-Driven Development 연구 결과가 있는데, 기능 구현 전에 평가부터 만드는 팀이 프로덕션 전에 이슈를 60% 더 많이 잡아냈고, 반복 속도가 3배 빨랐습니다.

근데 현실에서는 대부분 에이전트 세션을 전혀 추적하지 않습니다. 어떤 대화에서 잘못됐는지, 프롬프트가 문제인지 도구가 문제인지 기록이 없으면 평가를 할 수가 없죠.

저는 LangFuse라는 오픈소스 LLM 옵스 플랫폼으로 팀 내 에이전트 세션을 한곳에 모으고 있습니다. 세션 트래킹, 워크플로우 시각화, LLM-as-Judge 평가까지 돼요. 이걸로 주기적으로 "여기선 프롬프트를 다시 썼어야 했다", "이 상황에 스킬을 썼으면 나았겠다" 같은 이야기를 팀원들과 나눕니다.

측정하고, 평가하고, 고치고. 이 사이클이 하네스를 살아있게 만듭니다.

그래도 조심해야 할 것들

하네스를 잘 만들어도 빠지기 쉬운 구멍들이 있습니다.

아키텍처 드리프트. 에이전트한테 작업을 쌓다 보면 원래 설계에서 점점 벗어납니다. 가장 흔한 건 코드가 동작은 하는데 확인해 보면 하드코딩이거나 더미 코드인 경우입니다. 테스트로 잡아내야 합니다.

컨텍스트 불안(Context Anxiety). Anthropic이 발견한 건데, 모델이 컨텍스트 한계에 가까워졌다고 판단하면 작업을 조기 종료하려 합니다. Sonnet 4.5에서 특히 강하게 나타났고, 해결책은 컨텍스트를 통째로 리셋하고 핸드오프 아티팩트로 이어받는 겁니다.

승인 피로. Anthropic이 쓴 표현인데, "승인 기반 루프에서 열 번째 승인 후에는 더 이상 검토도 하지 않는다. 그냥 클릭할 뿐이다." 이건 보안 사고로 직결됩니다.

출처 불명 도구. MCP 도구를 아무거나 가져다 쓰면 안 됩니다. 도구를 통한 공격은 지금도 계속 일어나고 있습니다.

결국 환경을 설계하는 사람이 이긴다

Anthropic의 실험 결과를 다시 떠올려 봅니다.

조건	결과
같은 모델 + 하네스 없음	UI만 있고 게임 실행 불가
같은 모델 + 하네스 설계	16개 기능, 플레이 가능한 게임

같은 모델, 같은 프롬프트. 차이는 모델 바깥에 있었습니다.

거창하게 시작할 필요 없습니다. 지금 하는 작업에서 가장 반복적인 걸 하나 골라서, 에이전트에게 넘길 수 있는 형태로 정리해보는 것부터가 시작입니다. 처음부터 완벽할 필요 없고요. 모델이 바뀌면 하네스도 바뀌어야 하니까, 어차피 계속 고쳐나가는 거예요.

한 가지만 확실합니다. 같은 모델을 돌려도, 환경을 설계한 사람과 그냥 채팅만 한 사람의 결과물은 비교가 안 됩니다.

참고 자료

같은 Opus인데 왜 결과가 다를까 — 하네스 엔지니어링이라는 답

하네스가 뭔데, 그게 그렇게 중요한가

컨텍스트는 많을수록 좋을까요? 연구 결과는 반대였습니다

자동 루프 없이 에이전트를 쓴다면 그건 채팅일 뿐이다

같은 모델이 자기 작업을 평가하면 안 되는 이유

하네스도 유통기한이 있다

측정 안 하면 개선도 없다

그래도 조심해야 할 것들

결국 환경을 설계하는 사람이 이긴다

댓글

김성박의 다른 글

니콜이 거짓말 안 하게 만드는 법 — 문맥 판단, 대화 합성, 도구 호출 검증

AI 기억 시스템 개선기 — 벡터 검색 + 태그 확장으로 "저번에 뭐 들었더라?"를 찾는 법

AI가 대화를 기억하는 법 — 세션 태그와 토픽 기반 맥락 유지 알고리즘

폼 전송의 세 가지 방식: urlencoded, multipart, JSON의 차이와 선택 기준

HTTP 메서드 완벽 가이드: PUT과 PATCH의 차이, DELETE body의 함정