하네스는 어떻게 만들어야 하나 — 권위 있는 소스들의 권고

한눈에 보기

• 하네스(harness)란 에이전트에서 모델을 뺀 나머지 전부를 말한다. 루프, 도구, 컨텍스트·기억 관리, 검증, 권한·안전장치가 여기에 든다. Martin Fowler 사이트의 Böckeler는 이를 "Agent = Model + Harness"로 정리했다.
• 모델 제작사(Anthropic·OpenAI)와 실제로 하네스를 운영하는 팀(Cognition·Manus·LangChain), 공인 실무 저자(Martin Fowler 사이트)의 1차 원문 12편을 직접 열어 읽었다. 2024년 12월부터 2026년 4월까지의 글이다.
• 넓게 합의된 점: ① 가장 단순한 구조에서 시작한다. ② 컨텍스트는 한정된 자원이다. ③ 도구 설계에 프롬프트만큼 공을 들인다. ④ 에이전트가 스스로 검증할 수단을 준다. ⑤ 사람은 판단이 필요한 지점에 배치한다.
• 의견이 갈리는 점: 다중 에이전트를 언제 쓸지, 압축을 얼마나 적극적으로 할지, 리뷰어에게 컨텍스트를 공유할지.
• "모델이 강해지면 하네스는 얇아진다" vs "하네스가 성능을 가른다": 원문을 대조해 보면 두 주장은 하네스의 서로 다른 층을 가리킨다. 모델의 약점을 메우는 장치는 얇아지는 쪽이고, 환경·검증·지식을 공급하는 장치는 오히려 두꺼워지는 쪽이다. 따라서 결론은 "합의된 원칙 목록"이 아니라 "무엇을 보완하는 장치인지에 따른 조건부 선택"이다. 이 구분은 여러 원문을 엮은 이 보고서의 해석이며, 어느 한 소스가 이렇게 정리한 것은 아니다.

읽은 소스와 시점

권고가 바뀐 것인지, 다루는 작업이 다른 것인지를 가리려면 발행 시점이 중요하다. 그래서 소스마다 발행일과 당시 거론된 모델 세대를 함께 적었다. 근거의 성격은 세 가지로 나눴다. 실측은 수치로 낸 평가 결과, 사례는 자기 제품을 운영하며 얻은 경험, 의견은 원칙이나 제안이다.

O2와 M1은 각 회사가 공식 사이트에 올린 한국어판으로 읽었다. 이 두 글의 인용문은 공식 한국어판 문구다.

1. 단순하게 시작하고, 필요할 때만 자율성을 올린다

합의. 2024년부터 2026년까지 모든 소스가 같은 출발점을 권한다.

• Anthropic A1 (2024-12): "find the simplest solution possible, and only increasing complexity when needed". 흐름이 미리 정해진 작업에는 워크플로가, 유연성이 필요한 작업에는 에이전트가 맞다고 구분한다. 프레임워크를 쓸 때는 "ensure you understand the underlying code"라고 당부하고, 운영 단계에서는 추상화 층을 줄이라고 한다. 근거는 고객 사례다.
• Anthropic A4 (2025-09): 그사이 에이전트의 정의가 "LLMs autonomously using tools in a loop"로 단순해졌다고 밝힌다. 그러면서도 "do the simplest thing that works" will likely remain our best advice라고 다시 강조한다.
• OpenAI O1 (2025): "maximize a single agent's capabilities first". 결론부도 "Start small, validate with real users, and grow capabilities over time"이다.
• OpenAI O2 (2026-02): 더 높은 자율성은 하네스에 투자한 결과로 왔다고 본다. 테스트·검증·리뷰·복구가 시스템에 인코딩된 뒤에야 Codex가 기능을 처음부터 끝까지 맡을 수 있었다. 다만 "유사한 투자 없이 일반화할 수 있다고 가정해서는 안 됩니다"라고 단서를 단다.

시점에 따른 변화. 2024년의 질문은 "에이전트를 쓸지 말지"였다. 2026년의 질문은 "에이전트가 끝까지 일하게 하려면 환경에 무엇을 갖춰야 하나"로 바뀌었다. 권고가 뒤집힌 것은 아니다. 다루는 작업의 길이와 자율성 수준이 달라진 것이다.

2. 컨텍스트 엔지니어링 — 압축, 외부 기억, 격리

합의: 컨텍스트는 유한한 자원이다.

• Anthropic A4: 토큰이 늘수록 기억해 내는 능력이 떨어지는 "context rot"이 모든 모델에서 나타난다고 지적한다. 목표는 "the smallest possible set of high-signal tokens"다. 시스템 프롬프트는 "right altitude"로 쓰라고 한다. 깨지기 쉬운 if-else 규칙과 막연한 지침 사이의 높이라는 뜻이다. 예외 사례를 길게 나열하지 말고 대표 예시를 고르라고 권한다.
• OpenAI O2: 하나의 거대한 AGENTS.md는 실패했다고 보고한다. 대신 "1,000페이지의 설명서가 아닌 맵을 제공해야 한다"고 정리한다. 약 100줄짜리 AGENTS.md를 목차로 두고, 실제 지식은 버전 관리되는 docs/에 둔다. 린터와 문서 정리(doc-gardening) 에이전트가 그 신선도를 지킨다. 근거는 사례다.
• Cognition C1: 신뢰성의 핵심이 컨텍스트 엔지니어링이라고 본다. 단일 스레드 선형 에이전트가 "will get you very far"라고 하고, 아주 긴 작업에는 이력을 핵심 결정으로 압축하는 전용 모델을 둔다고 한다.

기법별 권고.

이견. Anthropic(A4)은 압축을 첫 수단으로 권한다. Manus(M1)는 비가역 압축의 위험을 강조하며 복원 가능한 압축을 원칙으로 둔다. Cognition(C1)은 압축이 "hard to get right"하다며 전용 모델에 투자했다. 셋 다 압축은 필요하다고 본다. 다만 무엇을 버려도 되는지에 대한 신뢰 수준이 서로 다르다.

3. 도구 설계 — 에이전트-컴퓨터 인터페이스(ACI)

합의: 도구는 프롬프트만큼, 혹은 그보다 더 중요하다.

• Anthropic A1: 사람-컴퓨터 인터페이스에 들이는 만큼의 노력을 ACI에도 들이라고 한다. SWE-bench용 에이전트를 만들 때 "spent more time optimizing our tools than the overall prompt"였다고 밝힌다. 상대 경로 대신 절대 경로를 받도록 고친 것처럼, 실수하기 어렵게 만드는 poka-yoke 설계를 권한다.
• Anthropic A3: 도구를 "결정론적 시스템과 비결정론적 에이전트 사이의 계약"으로 본다. 순서는 프로토타입 → 실사용에 가까운 평가 → 에이전트가 기록(transcript)을 분석해 개선하는 루프다. 권고 항목은 이름공간 나누기, 의미 있는 컨텍스트 반환, 토큰 효율이다. held-out 평가셋에서 사람이 쓴 도구보다 더 나은 결과를 얻었다고 보고한다(실측).
• Anthropic A4: "If a human engineer can't definitively say which tool should be used..., an AI agent can't be expected to do better." 기능이 겹치는 도구를 잔뜩 둔 상태가 흔한 실패라고 짚는다.
• Anthropic A2: 외부 MCP 도구는 설명의 품질이 들쭉날쭉하다고 지적한다. 실제 운영에서는 출처 품질 휴리스틱 같은 지침을 따로 넣어야 했다.
• Manus M1: 도구가 늘면 "무장한 에이전트가 더 멍청해집니다". browser_, shell_처럼 일관된 접두사를 붙이면 상태에 따라 도구 묶음을 제한하기 쉽다.
• OpenAI O2: 에이전트가 직접 읽을 수 있게 해야 할 대상이 도구만이 아니라 앱의 UI, 로그, 메트릭까지라고 넓힌다. "지루한" 기술이 에이전트가 모델링하기 쉽다고 하고, 필요하면 의존 라이브러리 일부를 직접 다시 만들기도 했다.

이견. 도구를 동적으로 불러오는 방식(RAG로 도구 선택)에 대해 Manus는 캐시와 일관성 문제 때문에 "절대적으로 필요한 경우가 아니라면" 피하라고 한다. 다른 소스들은 이 문제를 직접 다루지 않았다. 따라서 이 부분은 합의가 아니라 Manus 한 팀의 경험이다.

4. 장기 작업 — 진행 파일, 초기화 단계, 점진적 커밋

이 축은 주로 2025년 말 이후 글에서 다뤄진다. 몇 시간에서 며칠씩 이어지는 작업이 등장하면서 생긴 주제다.

• Anthropic A5 (2025-11): Opus 4.5를 써도 "compaction isn't sufficient"라고 한다. 실패는 두 가지였다. 앱을 한 번에 다 만들려다 컨텍스트가 바닥나는 것, 그리고 진행된 흔적만 보고 일찍 끝났다고 선언하는 것이다. 처방은 다음과 같다.
• 초기화 에이전트: 첫 세션에서 init.sh, claude-progress.txt, 첫 git 커밋, JSON 기능 목록을 만든다. 기능 목록은 200개가 넘었고 처음에는 모두 "failing"으로 표시했다. Markdown보다 JSON을 모델이 덜 망가뜨렸다고 한다.
• 코딩 에이전트: 한 번에 기능 하나만 맡는다. 세션을 시작할 때 진행 파일과 git 로그를 읽고 기본 E2E 테스트를 돌린다. 세션이 끝나면 커밋하고 진행 상황을 기록한다. 이렇게 "clean state"를 남긴다.
• 단서: 웹앱 개발에 최적화된 데모다. 단일 에이전트와 다중 에이전트 중 무엇이 나은지는 "still unclear"라고 적었다.
• OpenAI O2 (2026-02): 실행 계획을 "일급 아티팩트"로 다룬다. 진행 중인 계획, 끝난 계획, 기술 부채를 저장소 안에서 버전 관리한다. Codex 한 번 실행이 "6시간 이상" 이어지는 일이 흔하다고 한다. 에이전트가 쌓는 엔트로피는 정기적인 "가비지 컬렉션" 작업으로 갚는다.
• Anthropic A2: 리드 에이전트가 컨텍스트 한도에서 잘릴 것에 대비해 계획을 메모리에 미리 저장한다.
• Manus M1: 작업 하나에 평균 약 50번의 도구 호출이 든다. 그래서 todo.md를 계속 고쳐 쓰며 목표가 흐려지는 것을 막는다.

합의: 세션 사이에 상태를 넘기는 수단은 모델의 기억이 아니라 파일과 git이다. 진행 파일, 계획 파일, 커밋 이력이 그 역할을 한다. 이 보고서가 읽은 원문 범위에서는 이 점에 반대하는 소스를 찾지 못했다.

5. 검증·평가 루프와 사람의 자리

합의: 에이전트는 스스로 검증하는 습관이 없으니, 하네스가 검증을 강제해야 한다.

• Anthropic A1: 매 단계마다 환경에서 "ground truth"를 얻으라고 한다. 반복 횟수 상한 같은 정지 조건을 두고, 샌드박스에서 충분히 테스트하라고 권한다.
• Anthropic A5: 브라우저 자동화로 "as a human user would" 테스트하게 하자 성능이 "dramatically" 좋아졌다고 한다.
• LangChain L1 (실측): 모델(gpt-5.2-codex)은 고정하고 하네스만 바꿔 Terminal Bench 2.0 점수를 52.8에서 66.5로 올렸다(Top 30권에서 Top 5로). 효과가 컸던 것은 다음과 같다.
• 계획 → 구현 → 검증 → 수정 순서를 시스템 프롬프트에 넣었다.
• 종료 직전에 검증을 강제하는 미들웨어(PreCompletionChecklist)를 두었다.
• 같은 파일을 반복해서 고치는 "doom loop"를 감지했다.
• 시간 예산 경고를 주입했다.
• 추론을 "xhigh-high-xhigh"로 배분했다. 계획과 검증에 추론을 더 쓰는 방식이다.
• trace 분석으로 개선을 반복했다.
• Anthropic A2 (실측): 초기에는 약 20개 쿼리로 바로 평가를 시작하라고 한다. 프롬프트를 조금만 고쳐도 30%가 80%로 뛸 만큼 효과가 크기 때문이다. 루브릭 기반의 LLM-as-judge를 쓰되, 사람의 평가가 자동 평가가 놓친 편향을 잡아냈다고 한다.
• Martin Fowler F1: 하네스를 가이드(feedforward)와 센서(feedback)로 나누고, 각각을 계산적(computational)인 것과 추론적(inferential)인 것으로 나눈다. 테스트·린터·타입 검사가 계산적이고, AI 리뷰가 추론적이다. 둘 중 하나만 있으면 "keeps repeating the same mistakes"이거나 규칙이 효과가 있었는지 끝내 모르게 된다. 검사는 가능한 한 앞쪽에 둔다(keep quality left). 다만 기능 동작을 검증하는 하네스(behaviour harness)는 아직 풀리지 않은 문제이고, AI가 만든 테스트를 믿는 것은 "not good enough yet"라고 본다.
• OpenAI O2: 커스텀 린터의 오류 메시지에 수정 지침을 넣어 에이전트 컨텍스트로 들어가게 한다. 사람의 취향은 리뷰 코멘트에서 문서로, 다시 코드화된 규칙으로 승격된다.

사람의 자리.

• OpenAI O1: 실패 횟수가 임계치를 넘을 때, 그리고 되돌릴 수 없거나 위험이 큰 행동(결제, 환불 등)을 할 때 사람에게 넘기라고 한다. 가드레일은 "layered defense"로 쌓는다.
• OpenAI O2: 사람은 "다른 추상화 레이어"에서 일한다. 우선순위를 정하고, 수용 기준을 만들고, 결과를 검증한다. 에이전트가 막히면 그것을 "신호"로 보고 빠진 도구나 문서를 채운다.
• Martin Fowler F1: "A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important."

이견. 병합 게이트의 엄격함에서 갈린다. OpenAI O2는 처리량이 매우 큰 환경이라 "최소한의 차단 병합 게이트"로 운영하면서도 "처리량이 적은 환경에서는 적합하지 않습니다"라고 덧붙인다. Fowler F1은 검사를 앞당겨 품질을 지키는 쪽을 강조한다. 둘은 서로 다른 처리량 조건을 전제로 한다.

6. 단일 에이전트 vs 다중 에이전트

이 축에서 의견이 가장 크게 갈렸고, 시간이 지나며 수렴하고 있다.

수렴점. 2025년 6월 Cognition과 Anthropic의 글은 결론이 정반대로 보였다. 하지만 원문을 함께 보면 둘 다 같은 경계를 가리킨다. Cognition C2의 각주도 같은 결론에 이르렀다고 적는다. 그 경계는 다음과 같다. 읽기 전용 작업(검색·탐색·리뷰)은 병렬화하고, 쓰기 결정은 한 곳에 모은다. Anthropic은 성과를 낸 분야가 리서치였고 코딩은 아직 이르다고 했다. Cognition은 코딩에서 쓰기 병렬화가 실패하는 것을 보았다. 둘은 서로 다른 작업을 본 것이다.

여전히 갈리는 점. 리뷰어에게 컨텍스트를 줄지에서 의견이 엇갈린다. Cognition C1(2025)은 "share full agent traces"를 원칙으로 세웠다. 그런데 C2(2026)에서는 코드 리뷰 루프가 "coding and review agents do not share any context beforehand"일 때 가장 잘 작동했다고 보고한다. 같은 저자가 생성자-검증자 루프라는 특정 구조에서 원칙의 예외를 실측으로 찾은 셈이다. 컨텍스트를 공유하라는 원칙은 쓰기 결정이 충돌하는 경우에 적용되고, 독립적으로 검증하는 경우에는 오히려 격리가 유리하다.

핵심 쟁점: 하네스는 얇아져야 하나, 두꺼워져야 하나

"모델이 강해지면 하네스는 얇아진다"는 쪽의 원문 근거

• Anthropic A4: "smarter models require less prescriptive engineering". 에이전트 설계는 "letting intelligent models act intelligently, with progressively less human curation" 방향으로 간다고 예상한다. 프롬프트 형식의 중요도도 "becoming less important"라고 본다.
• LangChain L1: 루프 감지 같은 장치는 "today's perceived model issues"를 우회하는 휴리스틱이다. "These guardrails will almost surely dissolve over time."
• Anthropic A1: 2024년 글 머리에 이후 도구 환경이 크게 바뀌었다는 주석이 붙었다.
• Cognition C2: 모델이 더 "agentic"해지면서 1년 전에는 실패하던 다중 에이전트 패턴 일부가 작동하게 됐다.

"하네스 엔지니어링이 성능을 가른다"는 쪽의 원문 근거

• LangChain L1 (실측): 같은 모델로 하네스만 바꿔 13.7점이 올랐다.
• Anthropic A5: Opus 4.5조차 기본 하네스로는 운영 수준의 앱을 만들지 못했다.
• OpenAI O2: 초기 진행이 더뎠던 이유는 "Codex의 역량이 부족해서가 아니라 환경이 제대로 갖춰지지 않았기 때문"이었다. 규율은 "코드보다는 스캐폴딩에서 더 많이 드러난다"고 한다.
• Anthropic A4: 컨텍스트 창이 커져도 "context pollution" 문제는 "for the foreseeable future" 남는다고 본다.
• Manus M1: 모델 발전이 밀물이라면 Manus는 "기둥이 아닌 배"가 되겠다고 한다. 하네스(컨텍스트 엔지니어링)를 모델 발전과 직교하는 투자로 본다.

판별. 두 진영은 서로 반박하는 관계가 아니다. 하네스 안의 다른 장치를 가리키고 있다. 같은 글 안에 두 주장이 함께 들어 있는 경우도 많다(A4, L1).

따라서 실무 권고는 다음처럼 조건부가 된다. 이 역시 이 보고서의 종합이다.

1. 새 장치를 넣을 때 "이 장치는 모델의 결함을 메우는가, 모델에게 없는 정보와 신호를 주는가"를 먼저 묻는다.
2. 결함을 메우는 장치는 걷어낼 수 있게 만든다. 모델을 교체할 때마다 평가로 계속 필요한지 확인한다. LangChain과 Anthropic은 모두 평가셋과 trace를 개선 루프의 중심에 둔다.
3. 정보와 신호를 주는 장치(검증 센서, 저장소 지식, 진행 상태)는 자산으로 쌓는다. 가능하면 결정론적(계산적) 형태로 만든다(O2, F1).

미확인·누락과 한계

• Google의 1차 원문은 이번에 읽지 않았다. Google DeepMind나 Google Cloud의 에이전트 설계 글(예: Agent Development Kit 문서, 에이전트 백서)은 이번 범위에 넣지 못했다.
• Cursor의 1차 글도 읽지 않았다. 하네스를 운영하는 주요 팀이지만 이번 조사에 포함하지 못했다.
• 그 밖에 Stripe "minions"(Fowler 글에서 언급), OpenAI "Unlocking the Codex harness", Anthropic "Building agents with the Claude Agent SDK", Fowler 사이트의 후속 글(센서 실험)도 확인하지 않았다.
• "하네스를 얇게 하라"를 정면 주장으로 내세운 권위 있는 1차 원문은 이번에 찾지 못했다. 위 쟁점 정리는 각 소스 안의 진술을 대조한 것이다. 이를 근거로 그런 주장을 하는 원문이 없다고 단정할 수는 없다.
• 실측 수치는 각 회사의 내부 평가나 자사 벤치마크 결과다(A2 90.2%, L1 52.8→66.5, C2 버그 2건·58%). 외부에서 재현을 확인한 것은 아니다. A5와 O2는 수치 비교 없는 사례 보고다.
• OpenAI의 PDF 가이드(O1)는 본문에 발행일이 없어 날짜를 "2025년"으로만 적었다.
• 인용은 각 원문의 짧은 구절이다. 문맥은 링크된 원문에서 확인하길 권한다.

조사일: 2026-10-21. 12개 원문 전문을 직접 수집해 읽었다(검색 요약만으로 인용한 소스는 없음).