🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LLM 에이전트의 성능 병목은 모델 자체보다 모델을 둘러싼 오케스트레이션, 도구, 메모리, 컨텍스트 관리, 검증 루프를 포함한 ‘agent harness’ 설계에 크게 좌우된다.

📌 핵심 요약

• agent harness는 LLM을 실제 작업 가능한 에이전트처럼 작동하게 만드는 비모델 인프라 전체를 뜻한다.
• 핵심 병목은 모델이 아니라 컨텍스트 부패, 도구 실패, 상태 손실, 오류 누적, 검증 부재 같은 주변 시스템에서 발생한다.
• 프로덕션 수준의 harness는 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리, 상태 저장, 에러 처리, 가드레일, 검증 루프 등을 포함한다.
• Anthropic, OpenAI, LangChain, CrewAI, AutoGen은 구현 방식은 다르지만 모두 LLM 주변의 실행 구조를 정교화하는 방향으로 수렴하고 있다.
• 모델이 강해질수록 harness는 더 얇아질 수 있지만, 컨텍스트·도구·상태·검증을 관리하는 역할 자체는 사라지지 않는다.

🧩 주요 포인트

1. agent harness는 “모델이 아닌 모든 것”으로, LLM을 감싸 실제 에이전트 행동을 만들어내는 운영체제 같은 계층이다.
2. 단순 챗봇이나 데모형 ReAct 루프는 쉽게 만들 수 있지만, 프로덕션에서는 기억, 도구 실패, 컨텍스트 포화, 안전성 문제가 빠르게 병목이 된다.
3. 컨텍스트 관리는 핵심 병목이다. 긴 컨텍스트 창이 있어도 중요한 정보가 중간에 묻히면 성능이 떨어지고, 불필요한 토큰은 의사결정을 방해한다.
4. 도구 실행, 권한 검사, 오류 반환, 재시도, 샌드박싱, 결과 포맷팅은 모두 harness가 담당해야 하는 실무적 기능이다.
5. 좋은 harness는 작업 결과를 스스로 검증할 수 있게 하며, 테스트·린터·시각 피드백·LLM 평가자를 조합해 실패가 누적되기 전에 잡아낸다.
6. 장기적으로는 더 강한 모델에 맞춰 harness 복잡도를 줄이는 방향이 중요하지만, 설계 품질은 여전히 제품 성능의 핵심 차별점이다.

🧠 상세 정리

1. 병목은 모델 바깥에서 발생한다

원문은 많은 개발자가 챗봇이나 간단한 ReAct 루프를 만든 뒤 프로덕션 단계에서 문제를 겪는다고 설명한다. 모델이 몇 단계 전 작업을 잊거나, 도구 호출이 조용히 실패하거나, 컨텍스트 창이 불필요한 정보로 가득 차는 상황이다. 이때 문제는 반드시 모델 가중치나 추론 능력에만 있는 것이 아니라, 모델 주변 인프라가 작업을 안정적으로 유지하지 못하는 데 있다. LangChain 사례도 같은 메시지를 강조한다. 같은 모델과 같은 가중치를 쓰면서도 LLM을 감싸는 인프라만 바꿔 TerminalBench 2.0 순위가 크게 올랐다는 점은, 에이전트 성능이 모델 단독 능력보다 harness 설계에 의해 크게 달라질 수 있음을 보여준다. 즉 “좋은 모델을 붙이면 된다”가 아니라, 모델이 제대로 일할 수 있는 실행 환경을 만들어야 한다는 주장이다.

2. agent harness는 LLM을 감싸는 전체 실행 시스템이다

agent harness는 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리, 상태 유지, 에러 처리, 가드레일을 포함하는 전체 소프트웨어 인프라다. Anthropic의 Claude Code 문서와 OpenAI Codex 팀의 표현 모두, 에이전트를 가능하게 하는 비모델 인프라를 harness로 본다. LangChain의 Vivek Trivedy가 말한 “모델이 아니라면 harness”라는 표현은 이 구분을 간결하게 요약한다. 여기서 에이전트는 사용자가 경험하는 목표 지향적 행동이다. 반면 harness는 그 행동을 만들어내는 기계적 구조다. 사용자가 “에이전트를 만들었다”고 말할 때 실제로는 특정 모델을 harness에 연결한 것이다. Beren Millidge의 비유처럼, 원시 LLM이 CPU라면 컨텍스트 창은 RAM, 외부 데이터베이스는 디스크, 도구 통합은 디바이스 드라이버, harness는 운영체제에 해당한다.

3. 오케스트레이션 루프는 단순하지만 중심적인 심장부다

harness의 중심에는 Thought-Action-Observation 또는 ReAct 루프가 있다. 이 루프는 프롬프트를 조립하고, LLM을 호출하고, 출력을 해석하고, 도구 호출을 실행하고, 결과를 다시 모델에 전달하는 과정을 반복한다. 겉으로는 while loop에 가까울 만큼 단순할 수 있지만, 실제 복잡성은 루프 자체가 아니라 루프가 관리하는 상태, 도구, 권한, 오류, 컨텍스트에 있다. Anthropic은 런타임을 “dumb loop”로 설명한다. 지능은 모델에 있고, harness는 턴을 관리한다는 뜻이다. 하지만 이 단순한 루프가 안정적으로 동작하려면 각 단계에서 프롬프트 구성, 출력 분류, 도구 실행, 결과 포장, 컨텍스트 갱신, 종료 조건 판단이 정확해야 한다. 간단한 질문은 1~2턴으로 끝나지만, 복잡한 리팩터링 작업은 수십 번의 도구 호출과 여러 턴을 거칠 수 있다.

4. 도구와 메모리는 에이전트의 손과 기억이다

도구는 에이전트가 외부 세계에 작용하는 수단이다. 파일을 읽고 쓰거나, 검색을 수행하거나, 코드를 실행하거나, 웹에 접근하거나, 하위 에이전트를 생성하는 기능이 모두 도구로 제공된다. harness는 도구 이름, 설명, 파라미터 타입을 스키마로 모델에 알려주고, 호출 인자를 검증하며, 실행 환경을 샌드박싱하고, 결과를 모델이 읽을 수 있는 observation 형태로 되돌린다. 메모리는 시간 범위에 따라 나뉜다. 단기 메모리는 한 세션 안의 대화 기록이고, 장기 메모리는 세션을 넘어 유지되는 프로젝트 파일, JSON 저장소, SQLite·Redis 기반 세션 같은 구조다. Claude Code의 3계층 메모리 구조는 가벼운 인덱스, 필요할 때 불러오는 상세 주제 파일, 검색으로만 접근하는 원문 로그로 구성된다. 중요한 원칙은 에이전트가 자기 메모리를 확정 사실이 아니라 “힌트”로 보고, 실제 상태를 확인한 뒤 행동해야 한다는 점이다.

5. 컨텍스트 관리는 가장 조용하지만 치명적인 병목이다

컨텍스트 창은 LLM 에이전트의 작업 기억이지만, 무조건 크게 쓰는 것이 답은 아니다. 원문은 핵심 정보가 컨텍스트 중간에 위치할 때 성능이 떨어지는 “Lost in the Middle” 계열의 문제와, 컨텍스트가 길어질수록 지시 따르기 성능이 약해질 수 있다는 점을 강조한다. 따라서 프로덕션 harness의 목표는 가능한 한 적은 수의 고신호 토큰으로 원하는 결과 가능성을 높이는 것이다. 이를 위해 compaction, observation masking, just-in-time retrieval, sub-agent delegation 같은 전략이 사용된다. 예를 들어 대화 이력이 길어지면 중복 도구 출력을 버리고 아키텍처 결정이나 미해결 버그를 보존하는 방식으로 압축한다. 오래된 도구 출력은 숨기되 도구 호출 기록은 남길 수 있다. 전체 파일을 통째로 읽는 대신 grep, glob, head, tail로 필요한 조각만 가져오는 방식도 중요하다. 하위 에이전트는 넓게 탐색하되 최종적으로 1,000~2,000 토큰의 요약만 반환할 수 있다.

6. 오류 처리와 가드레일은 실패 누적을 막는 방어선이다

여러 단계로 구성된 에이전트 작업에서는 작은 실패가 빠르게 누적된다. 원문은 10단계 작업에서 각 단계 성공률이 99%여도 전체 성공률은 약 90.4%에 그친다고 설명한다. 따라서 harness는 오류를 단순히 예외로 종료시키는 것이 아니라, 오류 유형에 따라 재시도하거나, 모델이 회복할 수 있는 메시지로 반환하거나, 사용자 입력을 요청하거나, 디버깅 대상으로 올려야 한다. 가드레일과 안전성도 harness의 핵심 기능이다. OpenAI SDK는 입력, 출력, 도구 호출 단계에서 가드레일을 적용하고, tripwire가 발동되면 즉시 중단할 수 있다. Anthropic은 모델의 판단과 권한 집행을 분리한다. 모델은 무엇을 시도할지 결정하지만, 도구 시스템은 무엇이 허용되는지 판단한다. Claude Code는 프로젝트 신뢰 설정, 도구 호출 전 권한 확인, 고위험 작업에 대한 명시적 사용자 확인을 단계적으로 적용한다.

7. 검증 루프가 장난감 데모와 프로덕션을 가른다

검증 루프는 에이전트가 자기 작업이 맞는지 확인할 수 있게 하는 구조다. Anthropic은 테스트, 린터, 타입 체커 같은 규칙 기반 피드백, Playwright 스크린샷 같은 시각 피드백, 별도 하위 에이전트가 결과를 평가하는 LLM-as-judge 방식을 제안한다. Claude Code 제작자인 Boris Cherny는 모델이 자기 작업을 검증할 방법을 가질 때 품질이 2~3배 개선된다고 언급했다. 이 메커니즘은 단순한 후처리가 아니라 작업 루프의 일부다. Gather-Act-Verify처럼 먼저 관련 컨텍스트를 모으고, 파일 수정이나 명령 실행 같은 행동을 취하고, 테스트나 출력 확인으로 결과를 검증한 뒤 다시 반복하는 방식이다. 이 구조가 없으면 에이전트는 그럴듯한 결과를 냈더라도 실제로 동작하는지 확인하지 못하고, 실패가 다음 단계로 전파될 수 있다.

8. 실제 프레임워크들은 같은 패턴을 다른 방식으로 구현한다

Anthropic의 Claude Agent SDK는 query() 함수로 agentic loop를 만들고, 비동기 iterator로 메시지를 스트리밍한다. OpenAI Agents SDK는 Runner 클래스를 중심으로 async, sync, streamed 모드를 제공하며, Codex는 Core, App Server, CLI·VS Code·웹 앱 같은 클라이언트 표면으로 나뉜 3계층 구조를 사용한다. LangGraph는 llm_call과 tool_node를 조건부 엣지로 연결한 명시적 상태 그래프로 harness를 모델링한다. CrewAI는 Agent, Task, Crew 중심의 역할 기반 멀티에이전트 구조를 제공하고, Flows 계층에서 라우팅과 검증을 관리한다. AutoGen은 대화 기반 오케스트레이션을 발전시켜 순차, 병렬, 그룹 채팅, handoff, manager agent 기반 조율 패턴을 지원한다. 구현 방식은 다르지만 공통점은 분명하다. 모두 모델 자체가 아니라 모델을 둘러싼 실행·상태·도구·검증 구조를 제품 성능의 핵심 계층으로 다룬다.

9. harness 설계는 점점 얇아지지만 사라지지는 않는다

원문은 scaffolding 비유를 통해 harness의 미래 방향을 설명한다. 건설 현장의 비계는 건물을 짓기 위해 필요하지만, 건물이 완성되면 제거된다. 마찬가지로 모델이 강해질수록 복잡한 harness 일부는 모델 내부 능력으로 흡수될 수 있다. Manus가 여러 차례 재구축되며 복잡한 도구 정의나 관리 에이전트를 단순화했다는 설명은 이 흐름을 보여준다. 하지만 harness가 완전히 사라지는 것은 아니다. 아무리 강력한 모델이라도 컨텍스트 창을 관리하고, 도구 호출을 실행하고, 상태를 저장하고, 결과를 검증하는 외부 구조가 필요하다. 중요한 설계 기준은 더 강한 모델로 바꿨을 때 harness 복잡도를 추가하지 않아도 성능이 함께 확장되는지다. 즉 좋은 harness는 모델을 과도하게 통제하는 구조가 아니라, 모델 능력이 커질수록 자연스럽게 단순해질 수 있는 구조여야 한다.

🧾 핵심 주장 / 시사점

• 에이전트 성능의 핵심 병목은 모델 성능만이 아니라 harness의 컨텍스트, 도구, 메모리, 검증 설계에 있다.
• production-grade agent는 단순 프롬프트 래퍼가 아니라 상태 저장, 권한 관리, 오류 복구, 검증 루프를 포함한 전체 시스템이다.
• 컨텍스트는 희소 자원이므로 많이 넣는 것보다 필요한 정보를 적절한 시점과 위치에 넣는 설계가 중요하다.
• 멀티에이전트 구조는 항상 우월한 선택이 아니며, 원문은 먼저 단일 에이전트를 최대화한 뒤 필요할 때만 분리하는 접근을 제시한다.
• 모델이 발전할수록 harness는 얇아질 수 있지만, 제품 차원의 차별화는 여전히 harness 설계에서 발생한다.

✅ 액션 아이템

• Anthropic Claude Code의 Gather-Act-Verify 흐름을 기준으로 현재 에이전트 작업 루프에 검증 단계가 명시적으로 포함되어 있는지 점검한다.
• OpenAI Agents SDK나 LangGraph 스타일을 참고해 도구 호출, 오류 반환, 상태 저장, 종료 조건이 루프 안에서 어떻게 처리되는지 구조화한다.
• Claude Code의 메모리 계층처럼 항상 로드되는 가벼운 인덱스, 필요 시 불러오는 상세 파일, 검색 전용 원문 로그를 분리해 메모리 설계를 검토한다.
• LangChain·LangGraph 사례를 기준으로 현재 harness에서 모델 변경 없이 개선 가능한 컨텍스트 압축, 도구 스코핑, 검증 루프 항목을 식별한다.

❓ 열린 질문

• 같은 모델을 사용할 때 harness 개선만으로 어느 정도까지 성능 향상을 재현할 수 있는가?
• 모델이 더 강해질수록 어떤 harness 기능은 제거되고, 어떤 기능은 계속 외부 인프라로 남아야 하는가?
• 단일 에이전트를 최대화해야 하는 시점과 멀티에이전트로 분리해야 하는 시점을 실제 운영 환경에서 어떻게 판단할 것인가?