이런 상황 겪어본 적 있나요?
똑같은 Claude, 똑같은 GPT-4o 인데—어떤 사람은 5개월 만에 100만 줄의 코드를 작성하는 데 사용하고, 다른 사람은 2시간도 안정적으로 실행시키지 못합니다.
모델은 똑같은데, 결과는 하늘과 땅 차이입니다.
문제는 어디에 있을까요?
최근 OpenAI, Anthropic, Martin Fowler, Phil Schmid 의 글을 많이 읽어봤는데, 그들이 모두 같은 이야기를 하고 있다는 것을 알게 되었습니다.
그들은 이것을 Harness Engineering 이라고 부릅니다.
간단히 말해, Agent 를 위한 "운영 체제"를 구축하는 것입니다.
먼저, Harness 가 무엇인지 이해하기
Phil Schmid 가 HuggingFace 블로그 게시물에서 훌륭한 비유를 했습니다.
Agent 시스템을 컴퓨터라고 생각해보세요.
모델은 CPU 로, 원시 컴퓨팅 성능을 제공합니다. 컨텍스트 윈도우는 RAM 으로, 일시적으로 데이터를 저장합니다. Agent 는 그 위에서 실행되는 애플리케이션입니다.
그렇다면 운영 체제는 무엇일까요?
Harness 가 바로 운영 체제입니다.
운영 체제가 없으면 아무리 강력한 CPU 도 그냥 칩일 뿐입니다. 칩에 타이핑할 수는 없잖아요?
마찬가지로, Harness 가 없으면 아무리 똑똑한 모델도 그냥 채팅 상자일 뿐입니다. 복잡한 작업을 한 시간 동안 실행하게 놔두면, 컨텍스트를 잊어버리면 어쩌죠? 쓰레기 코드를 작성하는 것을 누가 막나요? 실수를 해도 그것조차 인지하지 못하면 어떻게 될까요?
이런 문제들은 "더 똑똑한 모델로 바꾸는 것"으로 해결되지 않습니다.
Martin Fowler 가 한 말이 기억에 남습니다. Harness 는 미래에 "서비스 템플릿"이 될 수도 있다고 했습니다. 오늘날 새 프로젝트를 시작할 때 서비스 템플릿을 사용하듯, 앞으로는 새 Agent 를 시작할 때 Harness 템플릿을 사용하게 될 것이라고요.
저는 이 예측이 현실이 될 가능성이 높다고 생각합니다.
왜 2026년에 갑자기 폭발적으로 성장하고 있을까?
왜냐하면 이제 모델이 충분히 강력해졌기 때문입니다.
2024년에는 모두가 누구의 모델이 더 똑똑한지 겨루고 있었습니다. 2026년이 되면서 최상위 모델 간의 격차는 매우 좁아졌습니다. Claude 와 GPT 에게 같은 문제를 주면, 점수 차이는 몇 점에 불과합니다.
하지만 8시간 연속으로 작업하게 놔두면, 격차가 나타납니다.
이 격차는 모델 자체에 있는 것이 아니라, 모델을 둘러싼 "harness" 에 있습니다.
OpenAI 의 Codex 팀에는 놀라운 통계가 있습니다. 그들은 Codex 를 사용하여 완전한 제품을 만들었습니다—5개월, 100만 줄의 코드, 손으로 직접 작성한 줄은 0줄. 이 과정 내내 그들은 병목 현상이 더 이상 "모델이 코드를 작성할 수 있는지"에 있지 않다는 것을 발견했습니다.
병목 현상은 인간이 코드를 검토할 수 있을 만큼 빠른지 여부였습니다.
모델 출력 속도가 인간 검토 속도를 추월했습니다. 이 시점에서 모델을 최적화하는 것이 무슨 소용이 있을까요? 검토 프로세스, 품질 관리, 아키텍처 제약 조건을 최적화해야 합니다.
바로 그것이 Harness 가 하는 일입니다.
세 가지 핵심 기둥
그렇다면 Harness 는 실제로 무엇을 포함하고 있을까요?
이 글들을 읽고 나서, 용어는 다양하지만 세 가지 핵심 기둥이 있다는 것을 알게 되었습니다.
1. 평가 폐쇄 루프
이것은 Anthropic 이 가장 강조하는 부분입니다.
핵심 아이디어는 간단합니다. Agent 는 스스로를 평가할 수 없습니다.
생각해보세요: 인턴이 보고서를 제출했을 때, 어떻게 했냐고 물어보면 "괜찮아요"라고 말할 것입니다. 평가할 독립적인 사람이 필요합니다.
Anthropic 은 이것을 "Evaluation-Driven Development"라고 부릅니다. 먼저 "잘하는 것"이 무엇인지 정의하고, Agent 가 작업을 수행하게 한 다음, 마지막으로 독립적인 평가자가 점수를 매깁니다.
Evaluation-Driven Development 는 Agent 버전의 TDD 입니다. 먼저 테스트를 작성하고, 그 다음에 코드를 작성합니다. 다만 여기서 "테스트"는 Agent 를 위한 것입니다.
평가자는 코드만 보는 것이 아닙니다. 실제로 제품을 작동시킵니다—Playwright 를 사용하여 버튼을 클릭하고, 양식을 작성하고, 테스트를 실행합니다—그런 다음 명확한 기준에 따라 판단합니다.
여기 흥미로운 사례가 있습니다.
Anthropic 의 Opus 4.5 는 항공편 예약 테스트 중 예약 정책에서 허점을 발견하여, 정답보다 더 나은 해결책을 찾아냈습니다.
하지만 평가자는 그것을 "실패"로 표시했습니다.
왜일까요? 평가자는 그렇게 창의적인 해결책을 예상하지 못했기 때문입니다. 정답은 하나뿐이었고, Agent 가 더 나은 해결책을 찾았기 때문에 오히려 불이익을 받은 것입니다.
이 이야기는 두 가지를 보여줍니다. 첫째, Agent 는 인간이 생각하지 못한 해결책을 찾을 만큼 똑똑하다는 것입니다. 둘째, 평가 루프는 Agent 만 확인하는 것이 아니라 평가 자체도 확인한다는 것입니다. 평가자가 너무 경직되어 있으면, 그것이 병목 현상이 됩니다.
또 다른 데이터 포인트: Opus 4.5 는 처음에 CORE-Bench 에서 42%의 점수를 받았습니다. 채점 버그를 수정하고 스캐폴드 제약 조건을 완화한 후, 점수는 95%로 뛰어올랐습니다.
종종 모델이 충분히 좋지 않은 것이 아니라, Harness 에 문제가 있는 경우가 많습니다.
이 방법을 사용하여 Anthropic 은 Agent 가 6시간 만에 200달러로 완전한 게임을 만들도록 했습니다.
2. 아키텍처 제약 조건
이것은 OpenAI Codex 팀의 전문 분야입니다.
인턴에게 "코드는 계층화되어야 한다"고 말하면, 고개를 끄덕인 다음 즉시 데이터베이스 계층에 UI 로직을 작성합니다.
말로는 소용없습니다.
OpenAI 의 접근 방식은 린터와 CI 를 통해 기계적으로 강제하는 것입니다. 아키텍처 규칙을 위반하는 코드는 검토조차 받지 않고 즉시 거부됩니다.
그들의 코드 계층화는 다음과 같습니다: Types → Config → Service → UI. 각 계층은 위의 계층에만 의존할 수 있으며, 그 반대는 절대 안 됩니다. 이 규칙은 문서에만 작성되는 것이 아니라, 린터에 작성되어 자동으로 확인됩니다.
더 좋은 점은, 이러한 린터 자체가 Codex 에 의해 생성된다는 것입니다.
Agent 가 자신의 규칙을 작성하고 그 규칙을 따릅니다.
Martin Fowler 는 OpenAI 의 글을 읽고 다음과 같이 말했습니다.
"신뢰성과 안정성을 높이려면 솔루션 공간을 제한해야 합니다. 이는 '무엇이든 생성할 수 있는' 유연성 중 일부를 포기하는 것을 의미합니다."
제약 조건이 많을수록 더 안정적입니다.
직관에 반하는 것처럼 들리지만, 데이터가 말해줍니다. LangChain 은 실험을 했습니다: 모델은 변경하지 않고 Harness 만 변경했을 때, Terminal Bench 2.0 통과율이 52.8%에서 66.5%로 뛰어올랐습니다. Vercel 은 더 나아가 Agent 도구의 80%를 삭제했고, 그 결과 단계가 줄어들고 속도가 빨라졌으며 결과도 더 좋아졌습니다.
도구가 적을수록 성능이 더 좋아지는 경우가 많다는 결론은 Agent 분야에서 반복적으로 검증되었습니다.
3. 메모리 거버넌스
이 기둥은 덜 논의되지만, 장기적으로 가장 중요하다고 생각합니다.
PrismerCloud 는 이 방향으로 깊이 있는 작업을 수행했습니다.
문제는 다음과 같습니다: 여러 Agent 가 지식 베이스를 공유할 때, Agent A 가 경험을 작성하고 Agent B 가 그것을 진실로 읽습니다. 하지만 Agent A 가 틀렸다면 어떻게 될까요?
한 Agent 의 환각은 공유 지식 베이스를 통해 모든 Agent 를 오염시킬 수 있습니다.
PrismerCloud 의 접근 방식은 "진화 엔진"을 구축하는 것입니다. 모든 Agent 경험은 먼저 "신호"로 기록됩니다. 신호가 검증되면 "유전자"로 정제되며, 실제 결과에 따라 지속적으로 최적화됩니다.
간단히 말해, 유전자는 검증되고 효과적인 지식입니다. 검증되지 않으면 인정되지 않습니다.
흥미로운 통계가 있습니다: 3줄의 프롬프트와 메모리 시스템은 대략 200줄의 정교하게 제작된 전문가 프롬프트와 비슷한 성능을 보였습니다. 게다가 전자는 진화하는 반면, 후자는 정적입니다.
이는 메모리 시스템이 좋다면 복잡한 프롬프트가 필요하지 않다는 것을 의미합니다. Agent 는 시간이 지남에 따라 자연스럽게 개선될 것입니다.
보너스: 엔트로피 저항
이것은 독립적인 기둥은 아니지만 언급할 가치가 있습니다.
Agent 시스템은 시간이 지남에 따라 자연스럽게 성능이 저하됩니다. 문서는 만료되고, 아키텍처는 우회되며, 지식 베이스는 오래된 정보로 가득 차게 됩니다.
OpenAI 의 접근 방식은 주기적으로 "리팩토링 Agent"를 실행하여 문서 불일치와 아키텍처 위반 사항을 스캔하는 것입니다. 그들의 말이 가장 적절했습니다.
"Agent 가 어려움을 겪을 때, 우리는 그것을 신호로 취급합니다: 무엇이 누락되었는지 찾아내고, 코드베이스에 다시 피드백하며, 항상 Codex 가 수정 사항을 작성하도록 합니다."
Agent 에 문제가 있을 때, Agent 만 고치지 말고 Harness 를 고치십시오. 이 마인드셋이 핵심입니다.
누가 이것을 하고 있을까?
이 분야는 두 가지 경로로 나뉩니다: 오늘날 사용할 수 있는 오픈 소스 프로젝트와, 방법론만 배울 수 있는 상용 회사의 내부 사례입니다.
오픈 소스 프로젝트: 바로 사용 가능
LangChain DeepAgents: 아마도 "범용 Claude Code"에 가장 가까운 오픈 소스 프로젝트일 것입니다. 계획, 파일 작업, 하위 Agent 위임, 자동 컨텍스트 압축—바로 사용할 수 있습니다. GitHub 에서 115k 스타를 받았습니다.
DeerFlow 2.0: ByteDance 에서 개발했습니다. 3월에 오픈 소스로 공개되어 한 달 만에 39k 스타를 기록했습니다. 스스로를 "SuperAgent Harness"라고 부릅니다. v1 에서 완전히 재작성되었으며, 샌드박스 실행, 영구 메모리, LangGraph 기반 스킬 시스템을 갖추고 있습니다.
OpenHands: 코딩 Agent 에 특화되어 있습니다. SWE-bench Verified 에서 77.6%를 달성했습니다. 모델에 구애받지 않으며 Laminar 를 사용하여 모든 Agent 동작을 추적합니다.
SWE-agent: Princeton 과 Stanford 에서 개발했습니다. "평가 중심" 개발을 완벽하게 만드는 데 중점을 둡니다.
Goose: Block (Square/Cash App) 에서 오픈 소스로 공개했습니다. 종속성을 설치하고, 테스트를 실행하고, 파일을 관리할 수 있는 범용 온-머신 Agent 입니다.
PrismerCloud: 메모리 거버넌스와 진화 엔진에 중점을 둡니다. 다중 Agent 시스템에서 환각 오염을 방지하는 가장 성숙된 솔루션입니다.
Cognee: Agent 를 위한 지식 그래프 기반 메모리 엔진으로, 데이터 간의 의미적 연결을 설정하는 데 도움을 줍니다.
상용 사례: 방법론 배우기
Claude Code + Agent SDK: 범용 Harness 에 대한 Anthropic 의 벤치마크입니다. 코딩뿐만 아니라 연구, 비디오 제작, 메모 작성에도 사용됩니다.
OpenAI Codex: 아키텍처 제약 조건의 궁극적인 사례입니다. 자동 생성된 린터와 Agent 동료 검토에 의존하여 100만 줄의 코드를 손으로 한 줄도 작성하지 않았습니다.
제가 깊이 기억하는 교훈
Rich Sutton 은 "The Bitter Lesson"이라는 고전적인 논문을 썼습니다. 요지는 계산 능력을 활용하는 일반적인 방법이 항상 인간이 설계한 특정 방법을 장기적으로 능가한다는 것입니다.
이 교훈은 Agent 분야에서 다시 한번 입증되고 있습니다.
Manus 는 6개월 동안 Harness 를 5번 리팩토링했습니다. LangChain 은 1년 동안 3번 아키텍처를 재설계했습니다. Vercel 은 도구의 80%를 삭제했습니다.
지우기 위해 구축하라.
오늘날 당신이 작성하는 "영리한 로직"은 내일 모델이 업그레이드되면 쓸모없어질 수 있습니다. 아키텍처는 모듈식이어야 하며 폐기될 준비가 되어 있어야 합니다.
Phil Schmid 가 기억할 만한 말을 했습니다.
"경쟁 우위는 더 이상 프롬프트가 아닙니다. 그것은 Harness 가 포착한 궤적(trajectories)입니다. 모든 성공과 실패는 다음 세대를 훈련시키기 위한 데이터입니다."
Harness 가 오래 실행될수록, 더 많은 궤적을 축적할수록 Agent 는 더 강력해집니다. 모델만 바꿔서는 따라잡을 수 없습니다.
세 가지 단계
AI 엔지니어링에서 Harness 의 위치를 이렇게 생각해보세요.
프롬프트 엔지니어링은 "무엇을 말할지"를 해결합니다. 단일 상호 작용입니다.
컨텍스트 엔지니어링은 "무엇을 알아야 할지"를 해결합니다. 참조와 기록을 제공합니다.
Harness 엔지니어링은 "지속적이고 안정적이며 확장 가능하게 작업하는 방법"을 해결합니다. 평가 루프는 품질을 보장하고, 아키텍처 제약 조건은 규칙을 보장하며, 메모리 거버넌스는 경험 축적을 보장합니다.
Harness 가 없으면 Agent 는 무언가를 기억할 수 있지만 감독이 없어 혼란에 빠질 수 있습니다. 세 가지 계층이 모두 갖춰지면, 진정으로 장기적으로 작업할 수 있는 캐릭터가 탄생합니다.
OpenAI, Anthropic, LangChain 은 이미 이것을 실행하고 있습니다.
출처: OpenAI Harness Engineering, Anthropic Demystifying Evals, Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026, Martin Fowler Harness Engineering, LangChain Agent Frameworks.
