AI 에이전트를 실제 업무에 붙이기 시작하면 어느 순간 “우리만의 하네스를 만들어야 하나”라는 질문이 나온다. 모델 호출, 도구 사용, 메모리, 권한, 재시도, 평가까지 모두 제품 품질에 영향을 주기 때문이다. 최근 P03에 들어온 두 자료는 이 질문을 서로 다른 쪽에서 비춘다. LangChain의 해리슨 체이스는 범용 하네스로 시작하되 작업이 모델의 학습 분포에서 멀어지고 통제 요구가 커질수록 맞춤화하라고 말한다. Braintrust 사례는 평가 플랫폼을 직접 만드는 순간 단순한 화면이 아니라 대용량 트레이스, 검색, 권한, 실시간 평가를 운영해야 한다고 강조한다.[^1][^2]
둘을 합치면 결론은 “직접 만들지 말라”도 “핵심이니 모두 직접 만들라”도 아니다.
직접 만들어야 할 것은 회사의 차별화된 의사결정 규칙이고, 이미 범용화된 실행·관측·평가 데이터면까지 다시 만들 필요는 없다.
에이전트 경쟁력이 중요할수록 오히려 이 경계를 엄격하게 잡아야 한다. 모든 계층을 소유하려다 보면 제품이 좋아지기보다 하네스와 평가 인프라를 유지하는 일이 제품개발을 잡아먹을 수 있다.
하네스는 모델 바깥에서 행동의 모양을 정한다
하네스를 단순히 “에이전트 프레임워크”라고 부르면 역할이 작아 보인다. 실제로는 모델이 어떤 컨텍스트를 보고, 어떤 도구를 어떤 형식으로 호출하고, 언제 멈추며, 실패했을 때 무엇을 다시 시도하는지 결정하는 실행환경에 가깝다.
P03의 Tech Bridge 자료에서 체이스는 에이전트를 모델·컨텍스트·하네스로 나눈다. 범용적인 작업에는 이미 Claude Code, Codex, Deep Agents 같은 기성 하네스가 충분히 유용해졌고, 처음부터 완전히 다른 인지 아키텍처를 만들기보다 기본 하네스에서 시작해 훅과 미들웨어, 게이트를 점진적으로 추가하는 접근을 권한다.[^1]
이 원칙이 중요한 이유는 모델마다 이미 잘 학습된 도구사용 방식이 있기 때문이다. 파일 편집처럼 모델이 충분히 익숙한 하위작업까지 회사가 독자 규격으로 다시 감싸면 오히려 모델이 잘하는 패턴에서 멀어질 수 있다.
그래서 첫 질문은 “하네스를 소유할 것인가”가 아니다.
우리 업무에서 기성 하네스가 잘못된 행동을 반복하는 지점이 어디인가?
그 지점이 확인되기 전에는 맞춤화할 대상도 불분명하다.
차별화는 전체 런타임보다 좁은 정책 계층에서 시작하는 편이 낫다
기업이 정말 직접 소유해야 하는 것은 보통 범용적인 도구 실행 루프가 아니다.
예를 들어 금융사라면 어떤 거래를 사람이 승인해야 하는지, 법률서비스라면 어떤 문서를 공식 근거로 볼지, 개발팀이라면 어떤 테스트가 통과해야 merge 가능한지 같은 규칙이 더 중요하다. 이런 규칙은 회사의 업무, 위험, 책임구조에서 나온다.
맞춤화의 순서를 좁은 것부터 넓은 것으로 놓으면 다음과 같다.
- 지시문과 정책
- 도구 설명과 입력 스키마
- 권한·승인·검증 게이트
- 메모리와 컨텍스트 조립 방식
- 라우팅·재시도·종료 규칙
- 필요할 때만 별도 인지 아키텍처나 런타임
이 순서의 장점은 실패 원인을 보면서 필요한 만큼만 복잡도를 추가할 수 있다는 점이다.
LangChain의 2026년 평가 가이드도 먼저 실제 트레이스를 읽고 실패 유형을 분류한 뒤, 단순한 평가에서 시작해 필요한 경우에만 복잡도를 더하라고 권한다.[^3] 프롬프트 문제인지, 도구 설계 문제인지, 모델 한계인지 구분하지 않은 채 전체 하네스를 갈아엎으면 원인과 처방이 연결되지 않는다.
평가 인프라는 생각보다 빨리 별도의 데이터 제품이 된다
하네스를 직접 만들 때 가장 과소평가되기 쉬운 비용은 평가다.
데모 단계에서는 스프레드시트에 질문과 답을 넣고 사람이 점수를 매겨도 된다. 사용자가 늘어나면 상황이 달라진다. 한 번의 에이전트 실행에는 여러 모델 호출, 도구 호출, 메모리 읽기·쓰기, 재시도, 중간 상태가 들어간다. 어느 단계에서 실패했는지 보려면 최종 답만 저장해서는 부족하다.
Braintrust는 자사 플랫폼을 에이전트의 전체 트레이스와 도구 호출을 실시간으로 보고, 실제 실패를 평가 데이터셋으로 바꾸며, 나쁜 릴리스를 차단하는 관측·평가 시스템으로 설명한다.[^4] P03 자료에서는 트레이스가 크고 중첩된 반정형 데이터라서 실시간 조회, 장기 분석, 역할 기반 접근제어와 데이터 마스킹까지 필요하다고 강조한다.[^2]
여기서 직접 구축의 숨은 비용이 생긴다.
“평가 화면 하나”를 만들려다 다음 시스템까지 같이 만들게 될 수 있다.
- 대용량 트레이스 수집·저장
- 단계별 검색과 필터링
- 버전별 실험 비교
- 사람의 라벨과 LLM 판정 결과 저장
- 운영 실패를 평가 세트로 승격하는 워크플로
- 팀별 접근권한
- 배포 전 품질 게이트
- 비용·지연시간·성공률의 장기 추적
이 기능이 회사의 직접적인 경쟁우위가 아니라면 사서 쓰거나 기존 도구를 조합하는 편이 더 경제적일 가능성이 높다.
‘핵심 기술이니 직접 만든다’는 기준은 약하다
기술이 중요하다고 직접 만들어야 하는 것은 아니다.
데이터베이스가 핵심인 서비스도 데이터베이스 엔진을 직접 만들지 않는다. 결제 경험이 중요한 서비스도 카드 네트워크 전체를 직접 만들지 않는다. 직접 만들어야 하는지는 중요도보다 차별화와 통제 필요성으로 결정된다.
에이전트 하네스도 같은 질문을 적용할 수 있다.
| 계층 | 기본 선택 | 직접 만들 이유가 커지는 조건 |
|---|---|---|
| 모델 호출·기본 도구 루프 | 기성 하네스 | 특수한 실행 제약이 반복적으로 성능을 막음 |
| 트레이싱·실험 저장 | 기존 플랫폼 | 데이터 주권·규모·비용 때문에 기존 도구가 부적합 |
| 일반 평가 실행 | 기존 평가 도구 | 회사 고유의 상태변화·업무결과를 측정해야 함 |
| 승인·권한 정책 | 직접 설계 | 업무 책임과 규제에 직접 연결 |
| 도메인 컨텍스트 조립 | 직접 설계 비중 큼 | 어떤 정보를 언제 보여줄지가 성능의 핵심 |
| 제품 고유 워크플로 | 직접 설계 | 이것이 실제 고객가치와 경쟁력의 중심 |
핵심은 하네스를 “산다/만든다”로 한 번에 결정하지 않는 것이다. 계층마다 답이 다를 수 있다.
직접 만들 가치가 있는지 판단하려면 먼저 평가가 있어야 한다
맞춤 하네스의 역설은 평가가 없으면 맞춤화의 효과를 알 수 없다는 점이다.
프롬프트를 200줄 늘리고 도구를 하나 더 붙였는데 성공률은 그대로일 수 있다. 정확도는 올랐지만 토큰 비용이 세 배가 될 수도 있다. 특정 테스트에는 좋아졌지만 실제 사용자 요청에서는 더 자주 루프를 돌 수도 있다.
LangChain의 Better Harness 연구는 평가를 하네스 개선의 학습신호로 사용한다. 운영 트레이스와 수동 작성 사례에서 평가 문제를 만들고, 최적화용과 보류용 세트를 나눠 하네스 변경이 새로운 문제에도 일반화되는지 확인한다.[^5] 단순히 기존 테스트 점수를 올리는 것이 아니라 회귀와 과적합을 같이 본다.
따라서 자체 하네스의 첫 산출물은 거대한 런타임이 아니라 좁고 명확한 평가세트여야 할 수 있다.
예를 들어 다음 다섯 숫자만 있어도 맞춤화의 필요성이 훨씬 선명해진다.
- 작업 완료율
- 사람 개입률
- 동일 실패 반복률
- 작업당 비용
- 작업당 지연시간
여기에 실제 상태가 바뀌었는지 확인하는 검증을 붙인다. “완료했습니다”라는 답을 받았는지가 아니라 파일이 만들어졌는지, 캘린더가 실제로 수정됐는지, 테스트가 통과했는지를 본다.[^3]
직접 구축해야 하는 경우는 분명히 있다
기성 하네스가 항상 정답인 것은 아니다.
업무가 규제·안전·금전적 책임과 직접 연결되고, 실행경로를 강하게 제한해야 하며, 감사 가능한 결정과 재현성이 필요하다면 맞춤 인지 아키텍처의 가치가 커진다. 대규모 트래픽에서 기존 관측 플랫폼의 비용이 비정상적으로 커지거나, 민감 데이터 때문에 외부 데이터면을 쓸 수 없는 경우도 직접 구축을 정당화할 수 있다.
또 회사의 제품 자체가 “에이전트를 운영하는 플랫폼”이라면 하네스와 평가 인프라가 곧 제품일 수 있다. 이 경우 범용 계층까지 소유하는 것이 전략적으로 맞다.
반대로 내부 업무 자동화나 특정 비즈니스 프로세스 개선이 목적이라면 같은 투자가 과할 수 있다.
판단기준은 개발팀의 자존심이나 기술적 흥미가 아니라 다음 질문이어야 한다.
기존 하네스에서 발생하는 손실이, 직접 구축하고 계속 유지하는 비용보다 큰가?
좋은 경계는 모델이 바뀌어도 남는다
에이전트 기술은 빠르게 바뀐다. 오늘 가장 좋은 모델과 도구 형식이 내년에도 같을 가능성은 낮다.
그래서 회사가 직접 소유할 계층은 모델 세대가 바뀌어도 남는 것이 좋다. 고객의 승인 규칙, 내부의 증거 기준, 업무별 완료 조건, 권한 경계, 실패 분류와 평가 데이터는 비교적 오래 남는다. 특정 모델의 파일 편집 문법이나 특정 프레임워크의 루프 구현은 더 빨리 바뀔 수 있다.
이 관점에서 보면 직접 구축의 목표도 달라진다.
“우리만의 에이전트 런타임”이 아니라 우리 업무가 무엇을 좋은 실행으로 보는지 코드와 데이터로 보존하는 것이 핵심이 된다.
기성 하네스가 좋아지면 그 위에 올라타면 된다. 모델을 바꾸더라도 같은 평가세트로 비교할 수 있다. 차별화된 정책과 증거는 그대로 남는다.
에이전트가 중요해질수록 모든 것을 소유할 필요는 없다.
오히려 차별화해야 하는 계층만 직접 만들고, 나머지는 교체 가능한 기반으로 두는 능력이 더 중요한 엔지니어링 판단이 될 수 있다.
[^1]: Tech Bridge, 「자체 에이전트 하네스를 구축해야 할 때는 언제일까? — 해리슨 체이스, LangChain」, YouTube, 2026-08-15. https://www.youtube.com/watch?v=H_zE_JwstWU [^2]: AIEngin, 「에이전트 품질 평가 플랫폼을 만드는 일이 생각보다 어려운 이유 — Braintrust」, YouTube, 2026-10-06. https://www.youtube.com/watch?v=mUQoVz7THu0 [^3]: LangChain, Agent Evaluation Readiness Checklist, 2026-03-27. https://www.langchain.com/blog/agent-evaluation-readiness-checklist [^4]: Braintrust, The active observability platform for agents, accessed 2026-10-07. https://www.braintrust.dev/home [^5]: LangChain, Better Harness: A Recipe for Harness Hill-Climbing with Evals, 2026-04-08. https://www.langchain.com/blog/better-harness-a-recipe-for-harness-hill-climbing-with-evals [^6]: Harrison Chase, Agent observability needs feedback to power learning, LangChain, 2026-05-05. https://www.langchain.com/blog/agent-observability-needs-feedback-to-power-learning