자체 에이전트 하네스를 구축해야 할 때

URL: https://www.youtube.com/watch?v=H_zE_JwstWU 날짜: 2026-08-15 채널: Tech Bridge 원문 제목: [한영자막] 자체 에이전트 하네스를 구축해야 할 때는 언제일까요? | 해리슨 체이스, LangChain 발화자: Harrison Chase, 공동 창립자 겸 CEO of LangChain 영상 길이: 22분 58초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트의 일반적인 코어 루프가 기본 요구를 충족하지 못하거나, 업무가 모델의 학습 분포에서 멀어져 예측 가능성·통제·도메인 성능이 중요해지는 순간 커스텀 에이전트 하네스를 도입해야 한다.==

• 에이전트는 모델(Model), 컨텍스트(Context), 하네스(Harness)의 세 부분으로 구성되며, 하네스는 적절한 시점에 적절한 컨텍스트를 모델에 공급한다.
• 범용 하네스는 빠른 가치 실현(Time to Value)에 유리하고 기본적인 업무에는 충분하지만, 특정 도메인과 모델에 맞춰 미들웨어·도구·인지 아키텍처를 추가하면 성능과 통제력을 높일 수 있다.
• 미션 크리티컬한 에이전트는 자체 벤치마크(Evals)를 통해 ‘좋음’을 정의하고, 관측 가능성(Observability)으로 실패 원인이 모델인지 컨텍스트인지 추적해야 한다.
• 실행 트레이스(Traces)와 사용자·합성 피드백을 큐레이션하고 실험에 다시 투입하면 하네스·모델·컨텍스트가 함께 개선되는 데이터 플라이휠(Data Flywheel)이 만들어진다.

‘자신의 지능을 소유한다’는 말은 특정 모델에만 종속되지 않고 모델을 교체할 수 있으며, 에이전트가 사용하는 기억·의미 지식·이전 대화와 실행 방식을 조직이 직접 통제한다는 뜻이다. Harrison Chase는 범용 하네스에서 시작한 뒤 실제 사용 데이터로 병목을 측정하고, 업무가 아웃오브디스트리뷰션(Out-of-Distribution)이거나 재현성과 안전한 통제가 필요할 때만 필요한 부분을 맞춤화하라고 권한다.

1. 에이전트를 이루는 세 가지 소유 대상

에이전트의 지능은 모델 하나의 능력이 아니라 모델·컨텍스트·하네스가 결합된 시스템의 능력이다.

1.1. 모델(Model)을 소유하고 교체할 수 있어야 하는 이유

1. 모델은 에이전트 지능의 실행 엔진이다

   1. LangChain이 말하는 지능은 대개 에이전트(Agent)를 통해 드러나며, 에이전트는 모델에 요청을 보내고 결과를 받아 다음 행동을 결정한다.
   2. Harrison Chase는 모델 자체에 대해서는 앞선 세션에서 Fireworks의 Lin이 다뤘다는 이유로 깊게 들어가지 않고, 모델을 소유할 때 얻는 중요한 이점으로 교체 가능성을 꼽았다.

2. 모델 교체 가능성은 클라우드 비종속성(Cloud Agnosticism)의 모델판이다

   1. 과거 애플리케이션 인프라가 특정 클라우드에 잠기는 것을 피하려고 클라우드를 바꿔 쓸 수 있게 설계했던 것처럼, 에이전트도 특정 모델 브랜드에 종속되지 않아야 한다.
   2. 모델 교체는 락인(Lock-in)을 줄이는 수단이면서, 더 좋은 모델이 출시됐을 때 즉시 도입하기 위한 수단이다.

1.2. 컨텍스트(Context)를 조직의 자산으로 관리하기

1. 컨텍스트는 에이전트가 실제 판단에 사용하는 모든 정보다

   1. 기억(Memory), 의미론적 지식(Semantic Knowledge), 이전 대화(Previous Conversations)가 컨텍스트에 포함된다.
   2. 컨텍스트를 직접 소유하면 에이전트가 진행 중인 업무를 개인화하고, 앞선 상호작용에 맞춰 다음 행동을 안내할 수 있다.

2. 컨텍스트 소유권은 모델 소유권과 함께 지능의 소유권을 이룬다

   1. 같은 모델이라도 어떤 기억과 지식을 어떤 순서로 주입하느냐에 따라 에이전트의 행동이 달라진다.
   2. 모델·컨텍스트·하네스 세 부분을 모두 직접 다룰수록 조직의 지능이 외부 제품의 기본 동작에 덜 종속된다.

1.3. 하네스(Harness)는 모델과 컨텍스트를 연결하는 조정 계층이다

1. 하네스의 주된 역할은 ‘적절한 시점에 컨텍스트를 전달하는 것’이다

   1. 고정 컨텍스트(Fixed Context)와 동적 컨텍스트(Dynamic Context)를 조율해 모델의 컨텍스트 윈도(Context Window)에 넣는다.
   2. 모델에 무엇인가를 보여주고 응답을 받은 뒤, 그 응답을 다음 도구 호출이나 다음 모델 입력에 반영한다.

2. 하네스는 외부 시스템과의 순환을 조율한다

   1. 에이전트는 도메인별 업무를 수행하는 동시에 외부 시스템과 상호작용해야 한다.
   2. 외부 시스템은 실행 결과와 새로운 정보를 다시 컨텍스트로 방출하며, 하네스는 그 정보를 에이전트 루프에 되돌려 넣는다.

2. 가장 단순한 에이전트 루프와 확장 지점

오늘날 대부분의 에이전트는 단순한 LLM-도구 반복 구조를 공유하지만, 하네스가 루프의 어디에 무엇을 삽입하느냐에 따라 실제 능력과 운영 특성이 달라진다.

2.1. LLM-도구 루프(LLM-Tool Loop)의 기본 동작

1. 요청에서 관찰까지 이어지는 반복 구조

   1. 사용자의 요청이 들어오면 LLM이 생성 결과를 만든다.
   2. 생성 결과에 도구 호출(Tool Call)이 포함되면 하네스가 도구를 실행하고, 도구의 관찰 결과(Observation)를 다시 LLM에 전달한다.

2. 단순하지만 매우 일반적인 아키텍처

   1. 이 루프는 오늘날 거의 모든 에이전트의 핵심 아키텍처다.
   2. 차이는 코어 루프 자체보다 각 단계에 어떤 검증·메모리·도구·실행 환경을 덧붙이는지에서 생긴다.

2.2. 범용 하네스와 Deep Agents의 관계

1. LangChain은 최소한의 하네스다

   1. LangChain은 모델이 컨텍스트를 받고 도구를 호출하는 기본 루프를 제공하는 작고 일반적인 하네스다.
   2. 이 최소 구조는 도메인별 요구사항을 추가하기 위한 기반으로 사용할 수 있다.

2. Deep Agents는 Claude Code의 모델 비종속적·범용적 버전이다

   1. Deep Agents는 최소 하네스 위에 파일 시스템(File System), 스킬(Skills), 서브에이전트(Subagents) 등의 기능을 붙인다.
   2. 특정 모델에 고정되지 않는 하네스를 지향하면서도, 코딩 에이전트가 실제로 필요로 하는 실행 기능을 제공한다.

2.3. 미들웨어(Middleware), 훅(Hooks), 플러그인(Plugins)으로 코어 루프 맞춤화하기

1. 삽입 지점별 코드로 기존 루프를 확장한다

   1. 에이전트를 호출하기 전에 코드를 실행하거나, 각 모델 호출 전후에 코드를 넣을 수 있다.
   2. 모델 호출과 도구 호출을 각각 감싸는 래퍼(Wrapper)를 추가해 입력·출력·정책을 조정할 수 있다.

2. 코딩 에이전트의 훅과 플러그인은 같은 원리다

   1. 실행 중인 기본 루프의 여러 지점에 작은 훅이나 플러그인을 붙여 동작을 바꾼다.
   2. 에이전트는 여전히 같은 LLM 루프를 돌지만, 미들웨어를 통해 샌드박스(Sandbox), 파일 시스템, 서브에이전트, 메모리, 요약 기능에 접근한다.

3. 요약과 컨텍스트 오프로딩(Context Offloading)의 위치가 다르다

   1. 요약 미들웨어는 모델 호출 직전에 컨텍스트가 너무 긴지 확인하고, 길면 요약한 뒤 모델을 호출한다.
   2. 컨텍스트 오프로딩은 큰 도구 호출 결과를 별도 위치로 덤프하는 방식이며, 도구 호출을 감싸는 단계에 들어간다.

2.4. 명시적인 인지 아키텍처(Cognitive Architecture)가 여전히 유효한 경우

1. 2023~2024년에는 인지 아키텍처가 일반적인 해결책이었다

   1. 당시 모델은 안정적으로 루프를 돌 만큼 충분히 강하지 않았기 때문에, 특정 업무를 시키려면 매우 맞춤화된 순차 단계를 설계해야 했다.
   2. 깊은 연구(Deep Research) 예시는 하위 질문을 생성한 뒤 여러 갈래로 분기(Fan-out)해 실행하는 구조였다.

2. 코드 리뷰 봇처럼 절차 자체가 중요한 업무가 있다

   1. 코드 리뷰 봇은 자유로운 루프보다 업무에 맞춘 단계와 게이트가 결과를 더 잘 안내할 수 있다.
   2. 이러한 구체적인 흐름은 코어 루프에 수정으로 추가할 수도 있고, 별도의 인지 아키텍처로 명시할 수도 있다.

3. 일반 하네스에서 시작하고 필요한 게이트를 점진적으로 추가한다

   1. 범용 하네스는 가장 빠르게 시작할 수 있고 Time to Value가 짧다.
   2. 탁월해지고 싶은 사용 사례가 좁혀지면 그 업무를 특정 방향으로 유도하는 게이트와 검사를 추가한다.

3. 기성 하네스와 자체 하네스를 가르는 기준

자체 하네스를 만들지는 이분법적 선택이 아니라, 모델이 학습된 분포와 업무의 거리가 커질수록 커스터마이징 수준을 높이는 연속적인 선택이다.

3.1. 오프더셸프(Off-the-Shelf) 하네스의 장점과 한계

1. 기성 하네스는 모델별 최적화가 되어 있다

   1. Claude Code와 Claude Agent SDK는 Anthropic 모델과 함께 쓰도록 설계됐다.
   2. Codex는 OpenAI 모델과 함께 쓰도록 설계됐다.

2. 모델이 학습된 분포(In-Distribution)에 가까울수록 기성 하네스가 유리하다

   1. 모델이 훈련 과정에서 자주 접하고 강화학습(RL)을 받은 도구 사용 방식과 작업 흐름은 기성 하네스가 잘 지원한다.
   2. 기본적인 업무라면 Deep Agents, Codex, Claude Code 같은 도구로 시작하는 편이 빠르고 충분한 결과를 낼 가능성이 높다.

3. 아웃오브디스트리뷰션(Out-of-Distribution)으로 갈수록 맞춤화가 필요하다

   1. 도메인 전체가 모델 학습 분포 밖에 있으면 범용 하네스의 기본 가정이 업무와 어긋날 수 있다.
   2. 이런 경우 하네스에 도메인 규칙·검증·승인 단계·특수 도구를 추가하거나, 완전히 새로운 인지 아키텍처를 설계한다.

3.2. 법률 AI 사례: 전체 업무와 하위 도구의 분포를 분리하라

1. 법률 AI 전체는 모델에 아웃오브디스트리뷰션일 수 있다

   1. Gabe가 소개한 법률 AI 조직은 자체 하네스를 사용한다.
   2. 법률 업무 전체는 모델이 직접 학습하거나 강화학습을 받은 일반적인 작업 범위에서 멀 수 있으므로, 도메인에 맞춘 하네스가 필요하다.

2. 파일 편집은 모델에 인디스트리뷰션(In-Distribution)인 하위 작업이다

   1. 주요 모델은 파일 편집에 대해 강화학습을 받았으며, OpenAI 모델과 Claude 모델은 파일을 편집하는 방식이 서로 다르다.
   2. 따라서 법률이라는 큰 업무에는 커스텀 하네스를 쓰더라도, 파일 편집 단계에서는 사용 중인 모델이 학습된 방식에 맞는 파일 편집 도구를 유지해야 한다.

3. 모델 프로필(Model Profiles)로 모델별 하위 동작을 선택한다

   1. Deep Agents는 모델이 어떤 모델인지에 따라 서로 다른 파일 편집 구현을 선택하는 모델 프로필 개념을 제공한다.
   2. 전체 업무는 맞춤 하네스로 감싸되, 모델이 잘 학습된 작은 작업은 모델 계층에 최대한 가깝게 유지하는 전략이다.

3.3. 자체 하네스를 구축해야 하는 의사결정 스펙트럼

1. 기성 하네스를 그대로 쓰는 끝점

   1. 업무가 일반적이고 모델이 해당 도구·흐름에 충분히 최적화됐다면 오프더셸프 하네스만으로 시작한다.
   2. 빠른 출시와 낮은 초기 구현 비용이 중요한 경우에 적합하다.

2. 훅·미들웨어를 붙이는 중간 지점

   1. 특정 도구 호출을 검증하거나, 컨텍스트를 정리하거나, 정책·메모리·승인 단계를 추가해야 할 때 기본 루프에 훅을 붙인다.
   2. 코어 루프의 일반성을 보존하면서 필요한 부분만 도메인에 맞출 수 있다.

3. 완전한 인지 아키텍처를 만드는 끝점

   1. 업무가 극단적으로 아웃오브디스트리뷰션이거나 예측 가능성과 통제가 핵심이면 완전한 커스텀 인지 아키텍처를 고려한다.
   2. 금융 서비스 고객들은 Deep Agents처럼 자율성이 높은 에이전트를 보고 “Whoa, whoa, whoa. That’s way too scary an agent for us”라고 반응하며, 동작을 세밀하게 통제할 수 있는 맞춤 구조를 원한다.

4. Evals와 Observability로 시스템의 ‘좋음’을 정의하기

모델·하네스·컨텍스트를 소유하려면 시스템 내부에서 무슨 일이 일어나는지 측정하고, 조직이 원하는 결과를 자체 기준으로 정의해야 한다.

4.1. 조직의 사적 평가(Private Evals)와 지능 소유권

1. 평가가 조직의 ‘좋음’을 정의한다

   1. Satya가 약 2주 전에 쓴 Twitter 글은 조직이 자체 평가를 만들어야 하는 이유를 강조했다.
   2. 공개 벤치마크 점수만으로는 특정 조직의 업무 성공 기준과 운영 비용을 정의할 수 없다.

2. 조직의 기억과 실행 흔적을 보존해야 한다

   1. 조직의 메모리, 트레이스, 피드백, 의사결정, 제도적 컨텍스트(Institutional Context)는 외부 서비스가 아니라 조직의 자산으로 남아야 한다.
   2. 이 자산이 누적되면 AI 투자가 회사의 가치를 복리처럼 키우는 지속 학습 루프(Continuous Learning Loop)가 된다.

3. 미션 크리티컬 에이전트는 반드시 벤치마크를 만든다

   1. 법률 도메인처럼 중요한 에이전트를 만들 때는 해당 업무를 대표하는 벤치마크를 구축한다.
   2. 벤치마크는 회귀(Regression)를 잡는 안전망이자, 하네스 또는 모델을 조정하며 점수를 계속 끌어올리는 힐 클라이밍(Hill Climbing) 기준이다.

4.2. Harbor와 Terminal-Bench 2의 평가 구조

1. Harbor는 오픈소스 평가 실행기(Eval Runner)다

   1. Harbor는 Terminal-Bench 2를 만든 팀이 제작했으며, 코딩 에이전트 평가를 위한 업계 표준급 도구로 자리 잡고 있다.
   2. 다양한 도메인에서 모델·하네스·추론 노력(Reasoning Effort)을 동일한 작업 세트로 비교할 수 있다.

2. Harbor 작업은 격리된 샌드박스에서 실행된다

   1. 데이터 세트는 여러 개의 작업(Task)으로 구성되고, 각 작업은 별도의 환경에서 실행된다.
   2. 장시간 실행되고 상태를 유지하는 에이전트는 환경과 상호작용해야 하므로, Dockerfile로 정의한 환경을 샌드박스로 띄운다.

3. 작업은 환경·정답·검증기·지시문으로 구성된다

   1. 환경(Environment)은 에이전트가 실행될 Docker 기반 작업 공간이다.
   2. 솔루션(Solution)은 정답에 해당하는 골든 솔루션(Golden Solution)으로, 작업 구성이 타당한지 확인하는 기준이다.
   3. 테스트(Test)는 에이전트 실행을 검증하고 점수를 계산하는 스크립트다.
   4. instruction.md는 에이전트가 받는 프롬프트다.

4. 테스트 스크립트는 다양한 평가자를 호출할 수 있다

   1. 테스트는 코드를 실행하거나 유닛 테스트(Unit Test)를 돌릴 수 있다.
   2. 별도의 LLM을 심사자(Judge)로 사용하거나, 다른 에이전트를 심사자로 사용해 결과를 채점할 수도 있다.

4.3. 정확도뿐 아니라 지연 시간과 비용을 비교하기

1. LangSmith는 실험 결과를 한곳에서 비교한다

   1. LangSmith는 Evals와 Observability를 위한 플랫폼이며 Harbor와 통합된다.
   2. 여러 실험에서 피드백 점수와 단일 보상 함수(Single Reward Function)를 비교할 수 있다.

2. 운영 품질에는 세 가지 지표가 함께 필요하다

   1. 정확도(Accuracy)는 과업을 제대로 완수했는지 나타낸다.
   2. 지연 시간(Latency)은 사용자가 결과를 기다리는 비용을 나타낸다.
   3. 토큰 사용량과 비용(Cost)은 규모가 커질수록 중요한 제약 조건이 된다.

4.4. Observability가 필요한 진짜 이유는 컨텍스트 실패다

1. 에이전트의 실패 원인은 크게 두 가지다

   1. 모델이 충분히 좋지 않아 LLM 호출이 잘못될 수 있다.
   2. 모델은 충분하지만 전달받은 컨텍스트가 좋지 않아 잘못될 수 있다.

2. 실패는 모델보다 컨텍스트 문제인 경우가 더 많다

   1. 어떤 정보가 모델의 컨텍스트 윈도에 들어갔는지 확인해야 한다.
   2. 컨텍스트가 어떤 순서로 축적됐고, 어떤 단계와 도구가 실행됐으며, 그 결과가 어떻게 다음 입력에 들어갔는지 추적해야 한다.

3. Trajectory와 Full Trace를 함께 봐야 한다

   1. Trajectory는 Claude Code 같은 에이전트가 남기는 메시지 목록으로, 사람의 입력·도구 호출·에이전트 응답이 시간 순서로 쌓인다.
   2. 메시지 목록만으로는 내부 원인을 충분히 디버깅하기 어렵기 때문에, 특정 호출 안으로 들어가 모델 내부 처리와 전체 실행 단계를 보여주는 Full Trace가 필요하다.
   3. 사용자 친화적인 화면에서는 반복되는 도구 호출을 접어 일곱 개의 도구 호출 같은 경로를 빠르게 훑게 하되, 필요할 때 세부 트레이스로 내려갈 수 있어야 한다.

5. 트레이스에서 개선으로 이어지는 데이터 플라이휠

에이전트를 실행하고 끝내는 대신 트레이스를 수집·큐레이션하고 실험으로 되돌리면 실제 사용이 곧 시스템 개선 데이터가 된다.

5.1. 지속 개선의 기본 순환

1. 네 단계 데이터 플라이휠

   1. 에이전트를 구축하고 실제로 실행한다.
   2. 많은 실행 트레이스를 수집한다.
   3. 트레이스 데이터를 큐레이션(Curation)한다.
   4. 큐레이션된 데이터로 실험을 실행해 시스템을 바꾼다.

2. 세 구성요소 모두가 개선 대상이다

   1. 하네스 엔지니어링(Harness Engineering)으로 실행 루프·도구·프롬프트·정책을 바꿀 수 있다.
   2. 파인튜닝(Fine-tuning)으로 모델을 바꿀 수 있다.
   3. 메모리(Memory) 설계로 컨텍스트를 바꿀 수 있다.

5.2. 사용자 경험과 합성 피드백

1. UX가 암묵적 피드백을 만들어낸다

   1. 사용자는 대개 명시적으로 좋아요·싫어요 버튼을 누르지 않는다.
   2. 하지만 에이전트의 결과를 어떻게 보여주고 어떤 후속 행동을 쉽게 만들지 영리하게 설계하면, 사용자의 행동 자체에서 피드백을 얻을 수 있다.

2. 온라인 평가자(Online Evaluator)로 합성 피드백을 만든다

   1. 수집한 트레이스 위에서 자동 평가자를 실행해 특정 품질 속성을 판정할 수 있다.
   2. 모든 트레이스에 Opus 같은 비싼 모델을 심사자로 돌리면 비용이 크게 늘어나므로, LangChain은 이를 위해 작은 언어 모델(SLM)을 파인튜닝했다.
   3. 오프더셸프 모델에 맞춤 프롬프트를 주거나, 검사 규칙이 단순하면 코드만으로 평가해도 된다.

5.3. 하네스 엔지니어링에 집중하는 이유

1. 데이터에서 세 방향으로 수정안을 만든다

   1. 트레이스와 피드백을 분석해 하네스·모델·컨텍스트 중 어디를 바꿔야 하는지 제안한다.
   2. LangChain이 특히 집중하는 부분은 하네스 엔지니어링이다.

2. 자동화가 필요한 반복 작업이다

   1. 트레이스를 큐레이션하고 실험을 설계하고 수정안을 검증하는 전체 과정은 복잡하고 시간이 오래 걸린다.
   2. 따라서 실행 데이터에서 문제를 찾고 개선을 제안하는 과정을 가능한 한 자동화해야 한다.

6. LangSmith Engine 데모: 트레이스 위에서 작동하는 에이전트

LangSmith Engine은 실행 트레이스를 읽고 문제를 찾아 하네스·프롬프트·컨텍스트 수정안을 제시하는 상위 에이전트다.

6.1. 문제 보드(Issue Board)를 만드는 백그라운드 에이전트

1. Engine은 LangSmith의 트레이스 위에서 백그라운드로 실행된다

   1. LangSmith에 들어오는 많은 트레이스를 Engine 탭에서 확인할 수 있다.
   2. Engine은 백그라운드 에이전트로 실행되며, 트레이스 데이터를 조사해 공통 문제를 찾는다.

2. LangSmith CLI와 서브에이전트가 조사에 사용된다

   1. Engine의 내부는 LangSmith CLI에 접근할 수 있는 코딩 에이전트다.
   2. 피드백 등으로 트레이스를 필터링하고, 큰 프롬프트와 서브에이전트를 사용해 데이터를 탐색하며 문제 패턴을 찾는다.

3. 문제에는 근거와 수정안이 함께 붙는다

   1. 문제 보드는 발견된 이슈의 설명을 제공한다.
   2. 관련 트레이스 링크를 함께 제공해 어떤 실행이 근거인지 확인하게 한다.
   3. 수정안은 단순한 프롬프트 변경일 수도 있고, 컨텍스트 업데이트·지시문 추가·하네스 코드 추가일 수도 있다.

6.2. ‘실행 → 트레이스 → 패턴 → 수정’ 자동화

1. 데이터 플라이휠을 자동 실행한다

   1. 에이전트를 실행하고 트레이스를 얻는다.
   2. 트레이스에서 패턴을 보고 문제를 만든다.
   3. 프롬프트·컨텍스트·지시문·하네스 중 적절한 부분을 고친다.

2. 자동화의 목표는 개선 속도다

   1. LangSmith Engine은 몇 달간 개발된 기능으로, 사람이 모든 트레이스를 수동으로 읽는 부담을 줄인다.
   2. 수정안이 자동으로 제시되더라도 링크된 근거 트레이스를 검토하고 벤치마크로 효과를 확인하는 절차가 필요하다.

7. Q&A: 자기 자신을 평가하는 Engine과 Codex-ification

Engine은 자기 자신을 개선 대상에 포함시키며, 여러 하네스의 비교 결과를 실제 코어 하네스로 가져온다.

7.1. Engine 위에서 Engine을 실행하는가

1. Engine은 자기 자신도 운영 데이터로 평가한다

   1. 질문자는 Engine 자체가 프롬프트를 받고 데이터를 검색하는 에이전트인지 확인하고, Engine 위에서 Engine을 돌려본 적이 있는지 물었다.
   2. Harrison Chase는 이미 그렇게 운영하고 있다고 답했다.

2. Slack 보고와 도그푸딩(Dogfooding)을 함께 사용한다

   1. Engine은 Slack에 연결되어 자기 자신에 관한 보고서를 보낸다.
   2. 자기가 만든 문제와 보고를 다시 사용해 시스템을 검증하는 도그푸딩 방식으로 개선한다.

7.2. Issue Bench와 ‘Codex-ification’

1. Issue Bench는 Harbor 형식의 Engine 전용 벤치마크다

   1. LangChain은 Engine용 이슈 벤치마크를 만들고, 다양한 모델과 하네스를 계속 비교한다.
   2. 벤치마크가 있으면 각 하네스가 잘하는 일과 못하는 일을 같은 작업에서 확인할 수 있다.

2. Codex는 트레이스 분석용 작은 스크립트를 적극적으로 작성했다

   1. 몇 주 전 Deep Agents, Codex, Claude Code를 Issue Bench에서 비교했다.
   2. Codex는 트레이스에 실행할 작은 스크립트를 많이 직접 만들고 매우 적극적으로 사용했으며, 그 결과 성능이 좋았다.

3. Codex의 장점을 Engine 코어로 이식했다

   1. LangChain 팀은 이 관찰을 바탕으로 Engine을 ‘Codex-ification’하는 스프린트를 진행했다.
   2. Codex가 벤치마크에서 보여준 학습을 Engine의 핵심 하네스에 반영했다.
   3. 여러 하네스를 실제 벤치마크에 돌리면 서로의 강점을 발견하고, 좋은 행동을 주력 하네스로 가져올 수 있다.

8. Q&A: 하네스는 하나로 수렴할까, 도메인별로 갈라질까

범용 코딩 하네스는 수렴할 가능성이 있지만, 도메인별 요구와 작은 모델·도구 차이가 하네스를 다시 분화시킬 수 있다.

8.1. 현재의 권장 출발점은 범용 하네스다

1. 일반적인 기본 업무에는 이미 충분하다

   1. 범용 하네스는 많은 기본 업무를 처리할 만큼 좋아졌다.
   2. Deep Agents, Codex, Claude Code 같은 기성 하네스로 시작하는 것이 Harrison Chase의 권장이다.

2. 도메인 거리가 커질수록 커스텀 수준을 높인다

   1. 업무가 모델의 학습 분포에서 멀어지면 하네스에 더 많은 도메인 지식과 제어 장치를 넣는다.
   2. 단순한 훅·미들웨어부터 시작해, 필요할 때 완전한 인지 아키텍처로 이동하는 것이 합리적이다.

8.2. 금융 서비스의 예측 가능성과 통제 요구

1. 자율성이 높은 에이전트가 모든 조직에 맞지는 않는다

   1. 금융 서비스 고객은 결과의 예측 가능성을 원하고, 자율적인 Deep Agents의 행동을 그대로 받아들이기 어렵다.
   2. 이들은 시스템의 경로와 승인 지점을 세밀하게 통제할 수 있는 맞춤 인지 아키텍처를 선호한다.

2. 안전한 통제도 자체 하네스의 이유가 된다

   1. 성능이 더 높다는 이유만으로 자유로운 에이전트를 채택할 수 없는 규제·위험 환경이 있다.
   2. 통제 가능성, 감사 가능성, 재현성이 정확도와 함께 하네스 선택 기준이 된다.

8.3. 모델 연구소와 하네스의 수렴·분화

1. 코딩 능력은 수렴하고 구현 세부는 다를 수 있다

   1. OpenAI와 Anthropic은 모두 코딩에 강해지고 있지만 파일을 편집하는 방식은 상당히 다르다.
   2. 어느 한 방식이 다른 방식보다 명백히 우월하다고 평가하는 사람도 있지만, 작은 차이가 특정 작업에서는 서로 다른 강점이 된다.

2. 전문화가 하네스 분화를 촉진할 수 있다

   1. 모델 연구소가 모두 코딩에 집중하면 하네스도 코딩에 적합한 방향으로 수렴할 수 있다.
   2. 한 연구소가 생명과학(Bio) 에이전트에 집중하면 해당 연구소의 하네스가 바이오 업무에 특화되어 다른 하네스와 갈라질 수 있다.

3. 빠르게 변하는 공간에서는 측정이 답을 준다

   1. Harrison Chase는 하네스가 수렴할지에 대해 “모르겠다”는 것이 정직한 답이라고 했다.
   2. 변화가 빠르기 때문에 Evals와 Observability로 실제 작업 성능을 측정해야 하며, 느낌이나 브랜드가 아니라 데이터로 선택해야 한다.

주요 발언 모음

“The main job of the harness is to bring context to the model at the right point in time.”

“하네스의 주된 역할은 적절한 시점에 컨텍스트를 모델에 가져오는 것입니다.”

“The more in distribution you are of what the models are trained on, then the better the off-the-shelf harness will be.”

“모델이 학습된 분포 안에 가까이 있을수록 오프더셸프 하네스가 더 잘 작동합니다.”

“The more out of distribution you get, the more custom harness you’re going to want to have.”

“아웃오브디스트리뷰션으로 갈수록 더 커스텀한 하네스를 원하게 됩니다.”

“Create your private evals, because eval defines what good looks like inside the organization.”

“조직 안에서 무엇이 좋은지 정의하려면 자체 평가를 만들어야 합니다.”

“Run agent, get traces, see patterns, fix.”

“에이전트를 실행하고, 트레이스를 얻고, 패턴을 보고, 고칩니다.”

“Whoa, whoa, whoa. That’s way too scary an agent for us.”

“잠깐만요. 우리에게는 그 에이전트가 너무 무섭습니다.”

핵심 데이터 & 수치

• 영상 길이: 22분 58초(1,378초)다.
• 핵심 구성요소: 에이전트는 모델·컨텍스트·하네스의 3요소로 설명된다.
• 역사적 시점: 2023~2024년에는 모델이 안정적으로 루프를 돌기 어려워 맞춤 인지 아키텍처가 널리 사용됐다.
• 평가 작업 구조: Harbor 작업은 환경(Environment), 골든 솔루션(Solution), 검증 테스트(Test), instruction.md 지시문으로 구성된다.
• 평가 지표: 에이전트 비교에는 정확도·지연 시간·토큰 사용량·비용을 함께 기록해야 한다.
• 실패 원인: 에이전트 실패는 모델 품질 부족 또는 컨텍스트 품질 부족에서 발생하며, Harrison Chase는 후자가 더 흔하다고 본다.
• Engine 운영: LangSmith Engine은 백그라운드에서 트레이스를 분석하고 이슈 보드를 만든다.
• Engine 피드백: Engine은 Slack에 자기 자신에 관한 보고서를 보내며 도그푸딩한다.
• 벤치마크 비교: Deep Agents·Codex·Claude Code를 Issue Bench에서 비교했고, Codex가 트레이스 분석용 작은 스크립트를 적극적으로 만들어 성능을 높인 사례가 관찰됐다.
• 자동화 순환: 실행 → 트레이스 수집 → 큐레이션 → 실험 → 하네스·모델·컨텍스트 업데이트의 순환이 핵심이다.

결론 및 시사점

1. 에이전트 구축은 모델을 고르는 일보다 모델·컨텍스트·하네스를 함께 소유하는 시스템 설계 문제다.
2. 하네스의 본질은 모델의 컨텍스트 윈도에 필요한 고정·동적 정보를 정확한 시점에 공급하고, 외부 시스템의 결과를 루프에 되돌리는 조정이다.
3. 일반 업무라면 Deep Agents·Codex·Claude Code 같은 기성 하네스로 시작해 빠르게 가치를 확인한다.
4. 아웃오브디스트리뷰션 업무, 특수 도구, 규제 환경, 예측 가능성·통제·감사 가능성 요구가 커질 때 훅·미들웨어 또는 커스텀 인지 아키텍처를 추가한다.
5. 전체 업무를 커스텀화하더라도 모델이 잘 학습된 파일 편집 같은 하위 동작은 모델별 프로필과 인디스트리뷰션 도구를 유지하는 것이 효율적이다.
6. 조직별 사적 Evals는 ‘좋은 에이전트’의 정의를 외부 벤치마크가 아니라 실제 업무와 회사의 목표에 연결한다.
7. Harbor처럼 샌드박스·검증기·데이터 세트를 갖춘 평가 실행기로 하네스·모델·추론 노력·비용을 반복 비교해야 한다.
8. 문제를 고칠 때 모델을 탓하기 전에 어떤 컨텍스트가 어떤 순서로 들어갔는지 Full Trace를 확인해야 한다.
9. 실제 트레이스와 사용자·합성 피드백을 큐레이션하면 하네스 엔지니어링, 파인튜닝, 메모리 설계를 모두 데이터 기반으로 개선할 수 있다.
10. 범용 하네스와 도메인 하네스의 최종 형태는 아직 정해지지 않았으며, 빠르게 변하는 만큼 Evals와 Observability가 선택의 기준이 되어야 한다.

핵심 요약 (20줄)

에이전트의 지능은 모델·컨텍스트·하네스가 결합된 시스템의 능력이다. 모델 소유권은 특정 브랜드에 종속되지 않고 더 나은 모델로 교체할 수 있는 능력을 뜻한다. 컨텍스트 소유권은 기억·의미론적 지식·이전 대화를 조직의 자산으로 관리하는 것을 뜻한다. 하네스의 주된 역할은 적절한 시점에 적절한 컨텍스트를 모델에 공급하는 것이다. 하네스는 모델 응답과 외부 시스템의 관찰 결과를 다시 에이전트 루프에 연결한다. 가장 단순한 에이전트는 LLM이 도구를 호출하고 관찰 결과를 다시 받는 반복 구조다. LangChain은 이 반복 구조를 제공하는 최소한의 범용 하네스다. Deep Agents는 파일 시스템·스킬·서브에이전트를 추가한 모델 비종속적 범용 하네스다. 미들웨어·훅·플러그인은 코어 루프를 유지하면서 요약·오프로딩·도구 정책을 추가한다. 2023~2024년에는 모델이 약해 특정 업무를 위한 명시적 인지 아키텍처가 더 자주 필요했다. 범용 하네스는 기본 업무와 빠른 가치 실현에 적합하다. 업무가 모델의 학습 분포에서 멀어질수록 커스텀 하네스의 필요성이 커진다. 법률 AI는 전체 업무에는 커스텀 하네스를 쓰면서 파일 편집에는 모델별 인디스트리뷰션 도구를 유지할 수 있다. 금융 서비스는 자율성보다 예측 가능성과 통제를 중시해 맞춤 인지 아키텍처를 선택할 수 있다. 자체 Evals는 조직 내부에서 무엇이 좋은 결과인지 정의한다. Harbor는 샌드박스 작업과 검증 테스트로 모델·하네스를 비교하는 오픈소스 평가 실행기다. 에이전트 실패는 모델보다 컨텍스트 품질 부족에서 발생하는 경우가 더 많다. Trajectory와 Full Trace는 도구 호출과 컨텍스트 축적 과정을 디버깅하는 핵심 관측 단위다. 실행 트레이스·피드백·실험은 하네스·모델·컨텍스트를 개선하는 데이터 플라이휠을 만든다. 기성 하네스와 도메인 하네스의 선택은 브랜드가 아니라 실제 벤치마크와 관측 데이터로 결정해야 한다.