Part I · CHAPTER 05

하네스가 체급을 이긴다

같은 모델, 다른 체급

"더 큰 모델 = 더 나은 에이전트"는 틀린 공식이에요. 그리고 이 한 문장이, 2026년 현재 에이전트 설계의 가장 반직관적인 진실 중 하나예요.

모델 크기보다 하네스 품질

Big Brain + Weak BodySharp Brain + Strong Body
모델 크기 예GLM-5.1급 (744B MoE)Gemma4:31b급 (30B dense)
하네스 품질기본 설정, 지침 빈약정교한 지침 주입, 자동화된 오류 감지, 절차 안내
메모리 부담동일 컨텍스트에서 수 배 더 큼가볍고 빠름
반복 작업 정확도지침을 간혹 무시하네스가 강제, 일관성 높음
비용높음낮음
결과느리고 비싸고 불안정빠르고 저렴하고 일관적

표에서 보듯, 큰 모델은 KV 캐시가 더 무겁고 비용도 높지만 하네스가 빈약하면 일관성이 떨어져요. 작은 모델이라도 하네스가 잘 설계되어 있으면 반복 작업에서 더 안정적인 결과를 내요.

왜 이것이 가능한가요

같은 컨텍스트를 채우면 GLM-5.1(744B MoE)의 단기 기억은 Gemma4 31B의 수 배예요. 메모리가 더 무겁고, 처리 속도도 느려요. 반면 Gemma4 31B에 완벽히 설계된 하네스는

  • 반복 지침을 매 호출마다 빠짐없이 주입하고
  • 오류를 즉시 감지해 루프를 끊거나 재시도하고
  • 복잡한 절차를 단계별로 안내해요.

모델 업그레이드보다 하네스 정교화가 먼저예요.

비유를 하나 더 빌려 와볼게요. 두 변호사를 떠올려 보세요. 한쪽은 천재적인 머리를 가졌지만 사무실이 어지럽고 비서가 없어요. 다른 한쪽은 평범한 두뇌지만, 정돈된 사무실에 능숙한 비서와 검토 절차가 있어요. 의뢰인이 여러 건을 일관된 품질로 처리받고 싶다면 누구를 택할까요. 답은 거의 항상 후자예요. 에이전트도 마찬가지예요.

깜짝 사실 — 작은 모델이 어제의 거인을 이겨요

최근 경향은 이 비대칭을 더 뒤집고 있어요. 2026년의 경량 모델(Qwen3.6 27B, Gemma4 26B-A4B, Nemotron Cascade 2 등)이 1-2년 전 400B급 모델의 reasoning 수준을 따라잡고 있어요. 작은 모델 + 좋은 하네스 조합이 현실적인 선택지가 되고 있다는 뜻이에요. "397B를 이긴 27B"라는 부록 제목이 과장이 아니에요. 상세한 벤치마크와 원인 분석은 397B를 이긴 27B에서 다뤄요.

하네스 확장 — 외부망이라면

하네스의 확장은 여기서 끝나지 않아요. 외부망 환경에서는 웹 검색과 MCP 서버(Model Context Protocol — 외부 시스템을 에이전트의 도구로 연결하는 프로토콜)를 통해 GitHub, Slack, Linear, DB, 브라우저 등 어떤 외부 시스템이든 에이전트의 네이티브 도구로 편입할 수 있어요. 코드 작업 중에 이슈를 열고, 결과를 Slack에 보내고, DB를 직접 조회하는 일이 하나의 대화 흐름 안에서 이뤄져요. 폐쇄망 환경에서 웹 검색·MCP가 차단되는 게 아쉬운 이유가 여기 있어요. (Claude Code 기준 MCP 서버 상세는 Claude Code 3대 설정 축, Codex 기준은 Codex 사용 가이드)

한 단계 더: 에이전트 네트워크를 직접 설계하라

서브에이전트는 코딩 에이전트가 내부에서 처리해주는 방식이에요. 여기서 한 단계 더 나아가면 에이전트를 오케스트레이터(orchestrator — 여러 에이전트 노드를 지휘하는 중앙 에이전트)로 삼아 여러 LLM 노드를 직접 설계하고 연결할 수 있어요.

각 노드는 독립된 시스템 프롬프트와 하네스를 가져요. 오케스트레이터가 입력을 중계하고, 조건에 따라 분기하거나 루프를 돌려요.

flowchart TD Orch["오케스트레이터(Orchestrator)<br/>코딩 에이전트(Coding Agent)"] Writer["작성자 LLM(Writer LLM)"] Reviewer["검수자 LLM(Reviewer LLM)"] Done["완료(done)"] Orch --> Writer Writer -->|"초안(draft)"| Reviewer Reviewer -->|"수정 요청(revision)"| Writer Reviewer -->|"통과(pass)"| Done

작성-검수 루프가 가장 직관적인 예예요.

  1. Writer LLM이 초안 작성 (시스템 프롬프트: "간결하고 명확하게")
  2. Reviewer LLM이 검토 후 피드백 반환 (시스템 프롬프트: "엄격히 비평, 통과 기준 명시")
  3. 피드백이 있으면 Writer가 수정 → 2번으로
  4. 기준 충족 시 루프 종료

Writer와 Reviewer를 분리하면 역할 간 충돌이 사라져요. 하나의 LLM이 작성과 비평을 동시에 맡으면 자기 결과물에 관대해지는 경향이 있어요. 역할을 나누면 Reviewer는 오직 비평에만 집중해요.

모델도 역할에 맞게 배분할 수 있어요. 비용이 높은 Opus는 검수에만 쓰고 Haiku로 초안을 쓰면 품질을 유지하면서 비용을 줄일 수 있어요.

이 패턴을 확장하면 이렇게 돼요.

구조예시
작성 → 검수 → 루프문서·코드 생성, 번역 품질 관리
분석 → 요약 → 검증논문 리뷰, 데이터 분석 보고서
계획 → 실행 → 반성리팩터링, 시스템 설계 반복 개선
전문가 패널 (병렬)여러 관점 동시 검토 후 합의

구현: Anthropic Python SDK(또는 OpenAI SDK)로 각 노드의 LLM 호출을 스크립트로 작성하고, 코딩 에이전트가 이를 오케스트레이션해요. 또는 Claude Code의 Task 도구·Codex의 위임 기능을 루프 구조로 연결하는 방법도 있어요.

각 노드의 시스템 프롬프트 설계가 파이프라인 전체 품질을 결정해요. 하네스 설계 원칙이 노드 단위로도 그대로 적용돼요.