같은 모델로 같은 과제를 30개 돌렸는데 완료율이 10%p 갈렸습니다.

딥시크-V4 플래시를 고정하고 하네스 설계만 바꿨더니 완료율이 46.7%에서 56.7%가 됐습니다. 모델 벤치마크에서 5%p 차이로 벤더를 갈아타는 결정을 수없이 봤습니다. 그 결정보다 두 배 큰 레버가 모델 바깥, 하네스 설계 안에 있었습니다.

”골대가 옮겨졌다”

같은 주에 Harrison Chase(LangChain)가 Managed Deep Agents를 출시하며 한 문장을 내놨습니다.

“에이전트에 도구를 주고 어딘가 배포하는 것만으로는 부족하다 — 골대가 옮겨졌다(the goal posts for building agents have moved).”

‘골대’가 어디로 옮겨졌는지를 그는 레이어드 스택으로 보여줬습니다.

  • create agent — 단순 도구 실행
  • invoke — 분석·합성 데이터 처리
  • deepagents — 장기 자율 태스크
  • langgraph — 맞춤 하네스가 필요한 고난도 작업

같은 에이전트라도 태스크 난이도와 자율성 수준에 따라 어느 계층에 올릴지를 명시적으로 결정해야 한다는 뜻입니다. 이 결정이 모델 선택보다 먼저 와야 합니다. 하네스 설계가 더 이상 엔지니어링 내부만의 문제가 아닌 이유가 여기 있습니다.

평가 기준도 함께 이동했습니다

Salesforce가 CRMAgentBench를 발표하며 에이전트 평가 기준을 바꿨습니다. “답변이 자연스러운가”에서 두 가지 질문으로 이동했습니다.

1. 도구가 실제로 실행됐는가 — CRM의 최종 상태가 실제로 변경됐는가
2. pass^k — 그게 k번 반복해도 됩니까

한 번 되는 건 데모입니다. k번 반복해서 되는 게 운영입니다.

이 기준으로 보면 모델 교체보다 하네스 안정성이 먼저 점검 대상입니다. 동일 모델에서 10%p가 갈리는 지점이 하네스라면, 모델을 바꿔도 하네스가 잘못 설계돼 있으면 그 차이는 사라집니다. 비용을 쓰고 성능을 되사는 것입니다.

파일 네이티브가 주는 운영 자산

LangChain Managed Deep Agents는 에이전트를 파일과 디렉터리 구조로 다룹니다. 실험 코드를 배포하는 게 아니라 버전 관리가 되는 프로젝트로 에이전트를 운영하는 것입니다.

파일이 되면 diff가 됩니다. diff가 되면 리뷰·롤백·감사가 기존 개발 도구로 공짜로 따라옵니다.

같은 결론이 같은 주에 다른 벤더에서도 나왔습니다. Cursor가 Origin 베타를 출시하며 코드 호스팅·PR·에이전트를 한 저장소에 묶었습니다. 저장소가 에이전트 컨텍스트의 닻이다 — 두 회사가 독립적으로 도달한 같은 문장입니다.

이 구조를 이미 쓰는 팀은 전환 비용이 없습니다. 에이전트를 실험 코드가 아니라 운영 가능한 프로젝트로 다루는 습관 자체가 다음 격차를 만드는 출발점입니다.

세 신호가 모이면

이번 주 에이전트 신호를 겹치면 문장 하나가 남습니다.

모델을 바꾸기 전에 하네스를 점검해 봤습니까.

딥시크 실측 10%p, Salesforce의 pass^k 기준, LangChain의 파일 네이티브 관리형 레이어 — 세 신호가 가리키는 방향은 같습니다. 경쟁력의 레버가 모델 선택에서 하네스 설계로 이동하고 있습니다.

당신 팀의 에이전트는 지금 어떤 하네스 위에서 실행되고 있습니까?