사전 공개: 저는 이 시장의 도구 중 하나인 agentproto를 만들었습니다. 아래의 모든 사실은 날짜가 기재되어 있으며 출처가 명시되어 있습니다. 경쟁사들의 강점이 명시된 도구별 리뷰는 9개의 코딩 에이전트 오케스트레이터 비교에서 확인할 수 있습니다. 수정 사항은 언제든 환영합니다 — 이슈(issue)를 제출해 주세요.

이번 주 어떤 개발 피드(dev feed)를 열더라도 모델에 관한 논쟁이 얼마나 많은지 세어보십시오. 어떤 모델이 코딩을 가장 잘하는지, 어떤 모델의 성능이 떨어졌는지, 어떤 벤치마크(benchmark)가 2점 움직였는지에 대한 이야기들 말입니다.

그것은 잘못된 싸움입니다. 이 논쟁을 끝낼 증거(receipt)를 여기 제시합니다:

증거. LangChain은 모델을 변경하지 않고도 Terminal-Bench에서 코딩 에이전트의 순위를 30위에서 상위 5위로 끌어올렸습니다 — 승리는 더 나은 두뇌가 아니라 그 주변의 스캐폴딩 (scaffolding)에서 왔습니다. 동일한 가중치(weights), 30계단 상승, 오직 하네스 (harness) 덕분입니다.

이 사실을 곱씹어 보십시오. 그들이 얻은 단일 최대의 도약은 당신이 실제로 수정할 수 있는 부분에서 나왔습니다 — 하지만 대부분의 사람들은 자신이 수정할 수 없는 부분에 주의를 기울입니다.

당신은 모델을 빌려 쓰지만, 하네스는 당신의 소유입니다.

당신은 모델을 훈련(train)시키지 않았습니다. 당신은 모델의 가중치 (weights)를 변경할 수 없고, 훈련 데이터 (training data)를 볼 수 없으며, 다음 분기에 벤더 (vendor)가 모델을 새로운 것으로 교체하면 당신이 정성스럽게 튜닝한 프롬프트 (prompts)는 조용히 이전과 같은 의미를 잃게 됩니다. 모델은 **임대품 (rental)**입니다. 좋은 임대품이긴 하지만, 당신의 것이 아니며 당신의 통제를 벗어나 움직입니다.

_하네스 (harness)_는 가공되지 않은 토큰 예측기 (token-predictor)를 실제로 업무를 수행하는 무언가로 바꾸기 위해 그 임대품 주변에 감싸는 모든 것입니다: 시스템 프롬프트 (system prompt), 도구 (tools), 메모리 (memory), 루프 (loop), 체크 (checks), 그리고 그것이 실행되는 샌드박스 (sandbox)가 바로 그것입니다. Anthropic의 자체 하네스 팀도 정확히 이렇게 정의합니다 — 하네스는 "가공되지 않은 능력을 완료된 작업으로 전환하기 위해 모델 주변에 감싸진 모든 것"입니다.

다른 것은 다 잊더라도 이것 하나만은 기억하십시오:
당신은 모델을 빌려 쓰지만, 하네스는 당신의 소유입니다. 임대품을 최적화하는 일을 멈추십시오.

게다가 하네스(harness)가 훨씬 더 큰 레버리지(lever)라는 사실이 밝혀졌습니다. LangChain의 자체 기술 문서(writeup)는 하나의 데이터 포인트일 뿐이며, 더 광범위한 패턴은 하네스만 변경하는 것이 모델을 교체하는 것보다 반복적으로 더 나은 성과를 낸다는 것입니다. 이제 이 분야에는 이 전문 분야를 일컫는 명칭인 "하네스 엔지니어링 (harness engineering)"이 생겼으며, 이를 위한 멋진 도구 목록(awesome-list)도 갖춰져 있습니다. 당신이 눈치채지 못하는 사이 모델은 범용화(commoditized)되었습니다. 기술적 숙련도(craft)가 이동한 곳은 바로 스캐폴딩(scaffolding)입니다.

당신은 어느 시대에서 일하고 있습니까?

자신이 어디에 위치해 있는지 파악하는 명확한 방법이 있으며, 이는 기본적으로 이 직무의 역사를 세 단계로 나누는 것과 같습니다. Anthropic의 컨텍스트 엔지니어링(context-engineering) 포스트가 처음 두 단계를 설명하며, long-running-agent 관련 기술 문서들이 세 번째 단계를 추가합니다. 당신의 이번 주 업무와 비슷하게 들리는 단계를 찾아보십시오.

Era 1 — 프롬프트 엔지니어링 (prompt engineering). 질문의 표현을 더 잘 다듬음으로써 더 나은 결과를 얻습니다. 퓨샷 예시(Few-shot examples), "단계별로 생각하기(think step by step)", 역할극 프레임워크(role-play framing) 등이 이에 해당합니다. 이는 여전히 중요하지만, 이제는 기본 요건(table stakes)일 뿐이며 가장 취약한 계층입니다. 모델이 업그레이드되면 당신의 영리한 문구들이 수행하던 역할이 소리 없이 재작성될 수 있기 때문입니다.

Era 2 — 컨텍스트 엔지니어링 (context engineering). 병목 현상이 문구의 문제가 아니라, _윈도우(window) 안에 무엇이 들어있는가_의 문제라는 것을 깨닫게 됩니다. Anthropic의 프레임워크에 따르면, 컨텍스트를 유한한 주의력 예산(attention budget)으로 취급해야 합니다. 왜냐하면 윈도우가 채워질수록 회상(recall) 능력이 저하되는 "컨텍스트 부패 (context rot)" 현상이 발생하여, 추가되는 모든 토큰에 대해 주의력이 얇게 분산되기 때문입니다. 당신은 모델이 보는 것을 큐레이션하고, 사실 관계를 적시(just-in-time)에 로드하며, 상태(state)를 대화 기록(transcript) 대신 디스크에 저장합니다.

Era 3 — 하네스 엔지니어링 (harness engineering). 단일 호출(call)을 튜닝하는 것을 멈추고, 모델이 실행되는 시스템(system) 자체를 설계하기 시작합니다. 즉, 루프(loop), 도구(tools), 역할(roles), 게이트(gates), 샌드박스(sandbox)를 설계하는 것입니다. 모델은 당신이 구축한 기계 안에서 교체 가능한 하나의 구성 요소(component)가 되었습니다.

당신은 어디에 있습니까? 만약 당신의 솔직한 답변이 _"나는 정말 좋은 프롬프트를 작성한다"_라면, 당신은 Era 1에 머물러 있는 것입니다. 즉, 가장 많이 빌려 쓰며 가장 취약한 계층에서 실제 작업을 수행하고 있는 것입니다. 이 단계 이후의 모든 단계는 레버리지를 당신이 소유하고 있는 부분으로 옮기는 과정에 관한 것입니다.

대부분의 팀은 Era 1의 어딘가에 갇혀 있으며, 하네스 (harness)가 잡아냈어야 할 실패의 원인을 모델의 탓으로 돌리고 있습니다. 그러니 이제 위로 올라가 봅시다.

Rung 1: 진실에 기반한 루프, 그 이상은 없다

최소한의 하네스 (harness)는 거의 당혹스러울 정도로 작습니다. Anthropic의 "Building effective agents"는 이를 단 한 줄로 요약합니다. 에이전트란 실제 환경으로부터의 피드백에 기반하여, 루프 (loop) 안에서 도구를 사용하는 모델 (tool-using model)입니다. 프레임워크 (framework)가 아닙니다. 현실을 확인하는 루프 (loop)입니다.

그 지점에서 시작하여 무언가를 추가하고 싶은 충동을 억제하십시오. 동일한 포스트에서도 이에 대해 직설적으로 언급합니다. 가장 단순한 것부터 시작하고, 측정 가능한 도움이 될 때만 복잡성을 추가하십시오. 프레임워크 (framework)는 추상화 아래에 실제 프롬프트 (prompts)와 응답 (responses)을 묻어버려 실패의 디버깅 (debug)을 더 어렵게 만들기 때문입니다. 대부분의 "내 에이전트는 멍청해"라는 버그는 하네스 (harness)가 그 효용보다 더 빠르게 성장했을 때 발생합니다.

징후. 만약 당신의 스캐폴딩 (scaffolding)의 각 구성 요소가 무엇을 '위한' 것인지 — 즉, 어떤 구체적인 모델의 약점을 보완하는지 — 이름을 붙일 수 없다면, 그 구성 요소는 아마도 짐(cargo)일 가능성이 높습니다. 실제 진실 (ground truth)에 기반한 루프 (loop)만이 당신에게 항상 필요한 유일한 부분입니다.

Rung 2: 적절한 것들만 컨텍스트 윈도우에 넣고, 나머지는 제외하라

루프 (loop)가 작동하기 시작하면, 다음 실패 요인은 모델이 자신의 이력에 매몰되는 것입니다. 이것은 Era 2의 움직임을 구조화한 것입니다. 장기 실행 에이전트 (long-running-agent) 플레이북 (playbooks)은 이를 세 가지 동사 — 축소 (Reduce), 오프로드 (Offload), 격리 (Isolate) — 로 압축합니다:

• 축소 (Reduce) — 이력이 임계값을 넘으면 오래된 도구 호출 (tool calls)을 요약본으로 압축하여, 윈도우 (window)가 높은 신호 강도 (high-signal)를 유지하도록 합니다.
• 오프로드 (Offload) — 계획, 진행 상황, 규칙을 대화 기록 (transcript)이 아닌 디스크 상의 파일 (예: NOTES.md, 작업 목록)에 기록합니다. 컨텍스트 윈도우 (context window) 외부의 상태 (state)는 리셋 (reset) 후에도 살아남지만, 내부의 상태는 증발합니다.
• 격리 (Isolate) — 탐색 과정을 깨끗한 윈도우 (window)를 가진 서브 에이전트 (sub-agents)로 밀어 넣으십시오. 이들은 만 개의 토큰 (tokens)을 소모한 뒤 다섯 줄의 요약본을 돌려줍니다. 지저분한 컨텍스트 (context)는 메인 스레드 (main thread)에 절대 닿지 않습니다.

당신이 주입하는 지식 또한 이 예산의 일부입니다. 그리고 누구의 지식을 사용하느냐에 따라 당신이 인터넷의 평균적인 수준에 얼마나 머물게 될지가 결정되며, 이는 그 자체의 문제입니다. 이 모든 것의 밑바탕에 깔린 규칙은 다음과 같습니다: 최상의 컨텍스트 (context)란, 윈도우 (window)가 천 배 더 많은 정보를 담을 수 있을 때조차 모델이 다음 단계로 나아갈 수 있게 해주는, 신호가 높은 (high-signal) 토큰들의 가장 작은 집합입니다.

3단계: 작업자가 자신의 결과물을 직접 채점하게 두지 마세요

여기에 사람들이 건너뛰는 하네스 (harness) 구성 요소가 있으며, 이것이 바로 조용히 실패를 일으키는 지점입니다. _"다 끝났나요?"_라는 질문을 받은 에이전트 (agent)는 너무 일찍 '예'라고 답합니다. 모델은 자신의 출력물을 너무 관대하게 채점하여, 버튼 하나가 렌더링되는 것을 보고 기능 구현이 완료되었다고 판단해 버립니다. Anthropic의 하네스 팀은 해결책이 더 똑똑한 프롬프트 (prompt)가 아니라는 것을 발견했습니다. 그것은 바로 구조적 분리 (structural split), 즉 두 역할이 분리되어 있고 평가자 (evaluator)가 회의적으로 반응하도록 조정된 생성자-평가자 루프 (generator-and-evaluator loop)입니다.

성숙한 버전은 플래너 (planner), 생성자 (generator), 평가자 (evaluator)의 세 가지 방식으로 분리됩니다. 왜냐하면 각 역할이 서로 다른 실패를 겨냥하기 때문입니다. 플래너는 범위 설정 미달 (under-scoping)을 해결하고, 생성자는 작업을 수행하며, 평가자는 거짓말을 잡아냅니다. 이것이 감독 사다리 (supervision ladder)의 전체 중추입니다. 여기서 핵심은 더 좁은 범위입니다. 평가자는 모델이 느끼는 기분이 아니라, 당신이 설치하는 하네스 (harness) 구성 요소여야 합니다. 평가자를 작업 에이전트의 루프 (loop) 외부에 고정하십시오. 그렇지 않으면 에이전트는 스스로를 채점하고 통과시켜 버릴 것입니다.

증거. 이것이 바로 "완료될 때까지 그냥 루프를 돌려라"가 신뢰성을 보장하지 못하는 이유이기도 합니다. 루프는 에이전트에게 지속성 (persistence)을 줄 뿐, 정확성 (correctness)을 주지는 않습니다. 완료 확인 (completion check)은 루프 _외부_에 존재해야 하며, 그렇지 않으면 잘못된 방향으로 진행되는 것을 쉰 번이나 승인해 버릴 것입니다. 이 논쟁에는 그 자체의 문제가 있습니다.

4단계: 구성 요소를 교체 가능하게 만드세요

4단계: 구성 요소를 교체 가능하게 만드세요

이러한 회복력 있는 하네스(resilient harness)는 모델을 중심축이 아닌 하나의 구성 요소로 취급합니다. Addy Osmani의 오랜 기간에 걸친 에이전트 작성 글은 이 분리를 명확하게 이름 붙입니다 — **두뇌(Brain), 손(Hands), 세션(Session)**으로 분리하세요:

• 두뇌 (Brain) — 모델과 그 루프를 포함합니다. 교체 가능: 프론티어 추론이 필요하지 않은 작업의 경우 Claude 대신 저렴한 오픈 모델로 교체할 수 있습니다.
• 손 (Hands) — 코드가 실행되고 버려지는 임시적인 샌드박스입니다.
• 세션 (Session) — 단일 실행을 초월하는 지속적인 상태와 기록입니다.

구성 요소가 분리되면 각 부분은 자체적인 주기(clock)에 따라 업그레이드됩니다. 사용료를 지불하는 두뇌는 분기별로 변경되지만, 손과 세션은 그럴 필요가 없습니다. 이것이 비용 라우팅(cost routing)을 가능하게 하는 이유이기도 합니다 — 비싼 두뇌를 계획하고, 저렴한 두뇌로 실행하며,
라우팅 수학은 하네스가 자동차를 재건하지 않고도 엔진을 교체할 수 있게 해주었기 때문에 작동하는 것입니다.

하지만 여기에는 상호 운용성 세금(interop tax)이 숨어 있습니다: 오늘날 모든 도구는 자신만의

여러 명의 하네스 (harness) 작성자들이 독립적으로 동일한 경고에 도달한다면 — 그것은 애플리케이션 계층에 도달한 '쓰라린 교훈 (Bitter Lesson)'입니다. 컨텍스트 리셋 (context resets), 스프린트 분해 (sprint decomposition), 정교한 검증 댄스 (verification dance): 이 각각은 오직 이 모델 생성의 약점을 패치하기 위해 존재합니다. LangChain의 자체 역사도 이를 보여줍니다. 에이전트를 상위 5위까지 끌어올렸던 바로 그 스캐폴딩 (scaffolding)이, 더 강력한 모델이 출시되어 더 이상 그것을 필요로 하지 않게 되면 곧바로 짐(drag)이 되어버립니다.

대부분의 팀이 놓치는 부분. 모델을 업그레이드할 때마다, 단순히 성능 향상을 즐기기만 하지 마세요 — 여러분의 하네스를 재감사(re-audit)하고, 새로운 모델을 무의미하게 만든 스캐폴딩을 뜯어내십시오. 2026년에 승리할 하네스는 과거에 승리했던 것보다 더 가벼울 것입니다.

1. 하네스를 영원히 키워나가는 것은, 더 나은 모델 위에서 단순한 루프 (plain loop)를 실행하는 사람보다 결국 더 느려지는 길입니다.

이것을 한 문장으로 요약한 규율입니다: 모델이 오늘 필요로 하는 스캐폴딩을 구축하되, 그것이 더 이상 필요하지 않은 날에는 가차 없이 삭제하십시오.

벤더들은 여러분에게 하네스를 팔 것입니다. 다만 그것은 여러분의 것이 아닐 뿐입니다.

여기 공정한 부분이 있습니다. 왜냐하면 이 논쟁 전체가 이 지점에 달려 있기 때문입니다. 모델 벤더들도 하네스를 출시하고 있으며, 그것들은 훌륭합니다. Claude Code는 그 자체로 하나의 하네스입니다. Managed Agents는 Anthropic의 호스팅된 메타-하네스 (meta-harness)입니다 — 2026년 4월 기준, 세션 (session), 샌드박스 (sandbox), 그리고 루프 (loop)가 안정적인 인터페이스 뒤에서 가상화되어 제공됩니다. 만약 하네스를 다른 사람의 문제로 넘기고 싶다면, 그것은 작업량이 적은 진정한 해결책이며, 저는 그렇지 않은 척하지 않겠습니다.

하지만 여러분이 포기하게 되는 두 가지가 있으며, 이는 이 논의의 핵심인 바로 그 두 가지입니다. 호스팅된 하네스는 그들의 하네스이며, 그들의 모델을 감싸고 있고, 그들의 플랜(plan) 위에서 작동합니다. 따라서 여러분은 그것을 다듬을 수 없고 (Rung 5는 여러분의 권한이 아닙니다), 두뇌 (Brain)를 더 저렴하거나 오픈 소스인 것으로 교체할 수도 없습니다 (Rung 4는 고려 대상에서 제외됩니다). 여러분은 모델과 하네스를 모두 빌린 것입니다. 여러분의 것이어야 했던 유일한 부분이 다시 임대 상태로 돌아간 것입니다.

대안은 하네스 (harness)를 이식 가능한 인프라 (portable infrastructure)로 소유하는 것입니다. 즉, 어떤 모델을 사용하더라도 ’당신의’ 리포지토리 (repo)에 존재하고 ’당신의’ 머신 (machine)에서 실행되는 체크 (checks), 계약 (contracts), 역할 (roles)을 갖는 것입니다. 이것이 제가 만드는 것의 전체 설계입니다. ‒ agentproto는 Claude Code, Codex, 그리고 OpenRouter 또는 Hermes를 통한 오픈 모델 (open models)을 위한 어댑터 (adapters)를 갖춘 로컬 데몬 (local daemon)입니다. 따라서 당신이 튜닝한 하네스 (harness)는 엔진을 교체할 때 함께 이동하며, 어떤 벤더 (vendor)도 열쇠를 쥐고 있지 않습니다. 호스팅 (hosted) 경로가 설정이 덜 필요하다는 점은 인정합니다. 다만, 그것을 건너뛰기 위해 당신이 무엇을 포기했는지만은 알아두십시오.

렌터카가 아닌, 자동차를 튜닝하라

따라서 피드 (feed)는 거꾸로 가고 있습니다. 여러분이 모두 논쟁하고 있는 그 모델은 전체 시스템에서 당신이 바꿀 수도 없고 소유할 수도 없는 유일한 것입니다. 하네스 (harness) — 루프 (loop), 컨텍스트 예산 (context budget), 평가자 (evaluator), 교체 가능한 부품들 (swappable parts), 그리고 당신이 삭제할 만큼 용기 있는 스캐폴딩 (scaffolding) — 이 바로 당신의 부분입니다. 새로운 모델 없이도 코딩 에이전트 (coding agent)를 30단계나 진전시킨 부분이며, 경쟁자들이 벤치마크 리더보드 (benchmark leaderboard)를 새로고침하는 동안 무시하고 있는 바로 그 부분입니다.

두 가지 질문이 이것을 월요일의 과제로 바꿉니다. 에이전트 (agent)가 실패했을 때, 당신은 더 나은 프롬프트 (prompt)를 찾습니까, 아니면 어떤 하네스 (harness) 구성 요소가 그것을 잡아냈어야 했는지 묻습니까? 그리고 다음 모델이 출시되었을 때, 당신은 단순히 더 빨라졌다고 느끼기만 합니까, 아니면 하네스 (harness)를 열어 그것이 쓸모없게 만든 것을 삭제합니까?

당신이 할 수 있는 최고의 엔진을 빌리십시오. 그런 다음, 그 엔진을 넣을 가치가 있는 자동차를 만드십시오.