🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

When to Build Your Own Agent Harness를 중심으로, 에이전트의 실질적인 지능은 모델 하나가 아니라 모델·컨텍스트·하네스의 결합에서 나오므로, 세 축을 통제해야 공급자 종속을 줄이고를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 에이전트의 실질적인 지능은 모델 하나가 아니라 모델·컨텍스트·하네스의 결합에서 나오므로, 세 축을 통제해야 공급자 종속을 줄이고 조직의 지식을 축적할 수 있다.
2. 범용 하네스로 빠르게 가치를 검증하되, 작업이 모델의 학습·강화학습 분포에서 멀어질수록 도메인별 게이트와 검증 절차를 추가해야 한다.
3. 전체 업무는 맞춤화하더라도 파일 편집처럼 모델이 이미 잘 학습한 기능에는 모델별 고유 도구 방식을 유지해야 성능 손실을 줄일 수 있다.
4. 하네스의 품질은 정확도만으로 판단할 수 없으며, 사적 평가와 도메인 벤치마크를 통해 지연 시간·토큰 사용량·비용까지 함께 비교해야 한다.
5. 실행 트레이스와 사용자 피드백을 수집하고 반복되는 실패를 하네스·프롬프트·컨텍스트 수정으로 연결해야 지속적인 데이터 플라이휠이 형성된다.

🧩 배경과 문제 정의

• 에이전트의 지능은 모델뿐 아니라 컨텍스트와 하네스에도 달려 있으며, 세 요소를 통제해야 모델 종속을 줄이고 조직 고유의 지식을 축적할 수 있다. [01:09]
• 하네스는 필요한 컨텍스트를 적절한 시점에 공급하고 도구와 외부 시스템의 결과를 다음 실행에 다시 연결하는 운영 계층이다. [02:06]
• 범용 하네스와 자체 하네스의 선택은 작업이 모델의 학습 분포에서 얼마나 벗어나는지에 달려 있으며, 판단에는 평가와 관측 가능성이 필요하다. [09:06]

🕒 시간순 섹션별 상세정리

1. 에이전트 지능을 소유하는 세 가지 축

• 에이전트 지능의 세 축은 모델·컨텍스트·하네스이며, 세 요소를 모두 통제해야 특정 공급자나 구현 방식에 종속되지 않는다. [01:09]
• 모델을 교체할 수 있어야 잠금을 피하고 시점별 최적 모델을 선택할 수 있으며, 기억·도메인 지식·과거 대화는 개인화와 판단을 좌우한다. [01:34]
• 하네스는 고정·동적 컨텍스트를 필요한 순간 컨텍스트 창에 넣고 외부 시스템이 반환한 정보를 다음 실행에 다시 공급한다. [02:06]

2. 도구 호출 루프와 하네스의 기본 구조

• 가장 단순한 에이전트는 LLM이 도구를 선택하고 실행 결과를 관찰값으로 돌려받아 다시 추론하는 반복 구조를 따른다. [02:43]
• LangChain의 최소 하네스와 파일 시스템·스킬·서브에이전트를 지원하는 Deep Agents는 같은 기본 루프를 공유하지만 추상화 수준이 다르다. [03:25]
• 모델과 도구 호출 주변에 작은 미들웨어를 삽입하면 기본 루프를 바꾸지 않고도 도메인별 실행 규칙을 추가할 수 있다. [03:44]

3. 미들웨어 확장과 명시적 인지 구조

• 미들웨어는 샌드박스·파일 시스템·서브에이전트·메모리를 연결하고, 긴 컨텍스트를 요약하거나 대용량 도구 결과를 외부로 덜어낸다. [04:26]
• 모델의 자율 실행 능력이 부족했던 시기에는 조사 질문을 분기하거나 코드 리뷰 단계를 고정하는 맞춤형 인지 구조가 필요했다. [05:41]
• 초기에는 범용 하네스로 가치를 확인하고, 목표 사용 사례가 좁아질수록 게이트와 검증 절차를 추가하는 편이 효율적이다. [06:37]

4. 자체 하네스가 필요한 판단 기준

• Claude Code·Claude Agent SDK·Codex 같은 기성 하네스는 특정 공급자의 모델과 실행 방식에 맞춰져 있어 모델의 강점을 빠르게 활용할 수 있다. [06:55]
• 작업이 모델의 학습·강화학습 분포에 가까우면 기성 하네스가 유리하지만, 분포에서 멀어질수록 도메인 맞춤 조정이 필요해진다. [07:19]

5. 법률 AI와 모델별 도구 프로필

• 법률 AI 전체는 모델에 생소할 수 있지만 파일 편집은 이미 강화학습된 작업이며, OpenAI와 Claude 모델은 서로 다른 편집 방식에 최적화돼 있다. [07:46]
• 전체 흐름에는 법률용 맞춤 하네스를 적용하되 파일 편집처럼 학습 분포 안에 있는 기능은 모델 고유의 도구 방식을 유지해야 한다. [08:24]
• Deep Agents의 모델 프로필은 모델에 따라 파일 편집 구현을 교체해 도메인 맞춤화와 모델별 기본 역량을 동시에 보존한다. [08:37]

6. 사적 평가와 도메인 벤치마크

• 모델·하네스·컨텍스트를 바꾸는 실험에는 내부 실행 상태를 확인하는 관측 가능성과 결과를 비교하는 평가 체계가 모두 필요하다. [09:06]
• 사적 평가는 조직 내부의 좋은 결과를 정의하며, 기억·트레이스·피드백·의사결정 맥락을 소유하면 기업의 AI 가치가 누적된다. [09:29]
• 미션 크리티컬 에이전트에는 회귀를 탐지하고 모델과 하네스를 단계적으로 개선할 수 있는 도메인 벤치마크가 필요하다. [10:11]

7. Harbor 평가 작업과 다차원 성능 비교

• Harbor 기반 벤치마크는 동일한 작업에서 하네스·모델·추론 강도를 바꾸며 각 조합의 성능 차이를 비교한다. [10:48]
• 상태를 가진 장시간 에이전트 작업은 Dockerfile로 정의한 독립 샌드박스 환경에서 병렬 실행할 수 있다. [11:10]
• 코드·단위 테스트·LLM 심사·에이전트 심사를 조합해 채점하고 정확도뿐 아니라 지연 시간·토큰 사용량·비용도 비교해야 한다. [12:01]

8. 실행 궤적 관측과 데이터 플라이휠

• 에이전트 실패는 모델 역량보다 누적 컨텍스트·실행 단계·도구 결과에서 더 빈번하게 발생할 수 있어 세부 추적이 중요하다. [13:04]
• 사용자용 실행 궤적은 전체 흐름을 빠르게 보여주지만 완전한 디버깅에는 개별 호출 내부까지 포함한 전체 트레이스가 필요하다. [13:43]
• 평가·관측 데이터와 사용자 피드백이 축적되면 에이전트 지능을 지속적으로 개선하는 데이터 플라이휠이 형성된다. [14:58]

9. 피드백을 활용한 에이전트 개선 루프

• 에이전트를 실행해 트레이스를 모으고 선별한 데이터로 실험을 반복하며 문제 패턴과 개선 효과를 확인하는 순환 구조가 기본이다. [15:01]
• 좋아요·싫어요 같은 명시적 평가는 적게 쌓이므로 사용자 행동이 드러나는 UX를 통해 암묵적 피드백을 수집해야 한다. [15:24]
• 온라인 평가 비용을 낮추기 위해 미세 조정한 소형 모델·맞춤 프롬프트·규칙 기반 코드를 활용할 수 있다. [15:45]

10. 트레이스 분석과 수정 작업의 자동화

• 선별된 데이터는 하네스 엔지니어링, 모델 미세 조정, 메모리 기반 컨텍스트 개선에 활용되며 반복 흐름의 자동화가 중요하다. [16:29]
• LangSmith Engine은 트레이스 위에서 작동하며 CLI와 서브에이전트로 피드백을 필터링하고 반복되는 문제를 이슈 보드로 만든다. [18:05]
• 이슈에 근거 트레이스와 수정안을 연결해 실행·추적·패턴 발견·수정으로 이어지는 데이터 플라이휠을 자동화한다. [19:03]

11. 자체 사용과 벤치마크를 통한 하네스 개선

• Engine은 Slack으로 자체 분석 보고서를 보내고 실제 운영에서 발견한 문제를 다시 개선 데이터로 축적한다. [19:31]
• Harbor 형식의 Issue Bench는 여러 모델과 하네스를 같은 문제에서 지속적으로 비교해 각각의 강점과 약점을 식별한다. [19:41]
• Codex가 트레이스 분석용 스크립트를 적극적으로 작성한 행동을 Engine의 핵심 하네스에 반영하는 Codexification으로 연결했다. [20:13]

12. 범용 하네스와 맞춤형 하네스의 선택 기준

• 기본 업무에는 파일 시스템과 서브에이전트 기능을 갖춘 Deep Agents·Codex·Claude Code부터 사용하는 방식이 효율적이다. [21:24]
• 분포 밖의 특수 업무일수록 커스터마이징 요구가 커지며, 금융권처럼 통제가 중요한 환경에서는 제어 가능한 인지 아키텍처가 선호된다. [21:54]
• 코딩 능력이 수렴하더라도 파일 편집 방식과 분야별 최적화가 하네스를 다시 분화시킬 수 있어 평가와 관측으로 실제 성능을 계속 측정해야 한다. [23:42]

🧾 결론

• 기본 업무에서는 Deep Agents·Codex·Claude Code 같은 범용 하네스를 먼저 활용하는 편이 구현 속도와 초기 검증 측면에서 효율적이다.
• 자체 하네스의 핵심 도입 신호는 업무의 특수성, 모델 학습 분포와의 거리, 예측 가능성 및 통제에 대한 요구다.
• 맞춤화는 모델의 기존 강점을 대체하는 작업이 아니라, 도메인 고유 절차와 모델별 기본 역량을 적절히 조합하는 작업이어야 한다.
• 장기적인 경쟁력은 특정 모델 선택보다 조직이 소유한 평가 기준·실행 기록·피드백·메모리와 이를 개선에 연결하는 운영 루프에서 누적된다.

📈 투자·시사 포인트

• 에이전트 시장의 가치 축은 모델 API 자체뿐 아니라 컨텍스트 관리, 하네스, 평가, 관측 가능성을 통합하는 운영 계층으로 확대될 수 있다.
• 샌드박스 실행, 다차원 벤치마크, 전체 트레이스, 문제 자동 분류와 수정 제안을 연결하는 플랫폼은 미션 크리티컬 에이전트 운영에서 중요성이 커질 수 있다.
• 금융·법률·바이오처럼 업무가 특수하고 통제 요구가 높은 산업에서는 범용 자율성보다 검증 가능한 맞춤형 인지 구조와 도메인 벤치마크가 더 중요한 선택 기준이 될 수 있다.
• 모델별 파일 편집 방식과 도구 사용 패턴이 다르다는 점은 단일 하네스로의 완전한 수렴보다 모델 프로필과 교체 가능한 실행 계층의 필요성을 뒷받침한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Harbor와 Issue Bench의 구체적인 점수·표본 규모·통계적 차이는 제시되지 않아 특정 모델이나 하네스의 절대적 우위를 판단할 수 없다.
• 작업이 모델의 학습 분포에서 얼마나 멀어져야 자체 하네스를 구축해야 하는지에 관한 정량적 임계값은 제시되지 않았다.
• 온라인 평가기를 소형 모델·맞춤 프롬프트·규칙 기반 코드로 대체할 때 정확도와 비용이 어떻게 달라지는지는 별도의 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 에이전트 업무를 모델 학습 분포 안의 공통 작업과 분포 밖의 도메인 특수 작업으로 구분한다.
• 범용 하네스로 기준 성능을 측정한 뒤, 맞춤형 게이트·미들웨어·인지 구조를 한 번에 하나씩 추가해 개선 효과를 비교한다.
• 조직 내부의 좋은 결과를 정의하고 정확도·회귀·지연 시간·토큰·비용을 포함한 사적 평가 세트를 구축한다.
• 사용자 메시지뿐 아니라 개별 모델 호출, 도구 결과, 누적 컨텍스트까지 확인할 수 있는 전체 트레이스를 수집한다.

❓ 열린 질문

• 우리 업무에서 범용 하네스의 한계가 처음 드러나는 단계는 컨텍스트 구성, 도구 선택, 검증 절차 중 어디인가?
• 자체 하네스 구축 비용을 정당화할 최소 성능 향상과 허용 가능한 운영 복잡도는 어느 수준인가?
• 모델별 고유 도구 방식을 유지하면서도 공급자 종속을 피하려면 어떤 인터페이스와 평가 계약이 필요한가?