1~2년 전만 해도 AI 에이전트를 만들려면 컨텍스트 관리, 툴 디스패처, 재시도 로직, 샌드박스를 직접 짜는 게 당연했습니다. 그런데 코딩 에이전트 Converge를 직접 만든 한 개발자는 이제 그 시대가 끝났다고 말합니다. 직접 만든 그 코드들이 오히려 짐이 되기 시작했다는 겁니다.

코딩 에이전트 스타트업 Converge를 만든 Dan Cleary가 ‘harness(하네스)’라는 개념을 실전 경험으로 풀어낸 글을 발표했습니다. 핵심은 간단합니다. 에이전트를 직접 만들던 시대는 지났고, 이제는 모델을 만드는 회사가 제공하는 하네스 위에서 일하는 게 낫다는 것이죠. 그가 직접 벤치마크를 돌려보며 확인한 변화이기도 합니다.

출처: Harness as a Service – Dan’s Working Notes

하네스가 뭐길래

요즘 ‘에이전트’라는 말은 많이 들어보셨을 겁니다. 그런데 그 옆에 따라붙기 시작한 ‘하네스’는 조금 낯섭니다.

구분은 의외로 깔끔합니다. 모델은 토큰을 생성합니다. 그게 전부입니다. 하네스는 그 나머지 전부입니다. 모델이 도구를 호출하는 루프, 파일 시스템 접근, 권한 모델, 컨텍스트 관리, 그리고 모델이 작성한 코드가 실제로 돌아가는 샌드박스. 모델만으로는 아무것도 ‘하지’ 못합니다. 여기에 하네스를 더해야 비로소 일하는 에이전트가 됩니다.

우리가 이미 쓰고 있는 도구들이 바로 하네스입니다. Claude Code는 Anthropic 모델을 감싸는 하네스이고, Codex는 OpenAI 모델의 하네스죠. Cursor도 마찬가지입니다. 같은 모델이라도 어떤 하네스에 얹느냐에 따라 전혀 다른 도구가 되는 셈입니다.

하네스가 성능을 가른다, 그런데 그 격차가 사라지고 있다

그렇다면 하네스가 실제 성능에 얼마나 영향을 줄까요. 측정된 데이터가 있습니다.

Matt Maher가 만든 오픈소스 벤치마크는 에이전트에게 제품 요구사항 문서(PRD)를 주고, 그 안의 기능들이 최종 결과물에 얼마나 반영되는지를 측정합니다. 한동안 화제가 된 수치가 있었습니다. 같은 Opus 모델을 Claude Code에서 돌렸을 때는 77점, Cursor에서 돌렸을 때는 93점. 하네스만 바꿨는데 16점이 벌어진 겁니다. 평균적으로 Cursor가 모델 성능을 11% 끌어올렸다는 결과였죠.

여기까지만 보면 “그럼 다들 Cursor를 써야 하는 것 아닌가” 싶습니다. 그런데 저자가 더 최신 모델로 같은 벤치마크를 다시 돌리자 그 격차가 거의 사라졌습니다. Opus 4.8은 Claude Code와 Cursor에서 0.2점 차이, GPT-5.5는 Codex와 Cursor에서 0.5점 차이, Fable 5도 0.2점 차이에 그쳤습니다. 하네스를 바꿔도 결과가 거의 같아진 것이죠.

저자는 이 결과를 두고 벤치마크 자체가 포화됐다고 봅니다. 과제가 너무 쉬워져서 더 이상 하네스 간 실력 차이를 가려내지 못한다는 뜻입니다. 동시에 모델이 좋아질수록 하네스의 영향력이 줄어든다는 해석도 가능합니다. 다만 영향력이 줄었다고 해서 하네스가 없어도 된다는 건 아닙니다. 여전히 하나는 필요하니까요.

API에서 SDK로, 그리고 관리형 하네스로

흥미로운 건 이 하네스라는 게 점점 더 위쪽으로, 즉 개발자 손에서 모델 회사 쪽으로 옮겨가고 있다는 점입니다.

2023~2024년만 해도 모델을 쓰는 방법은 단순했습니다. API로 토큰을 사는 것이었죠. 프롬프트를 보내면 출력이 오고, 토큰 단위로 요금을 냈습니다. 모든 기본 요소를 개발자가 직접 만들었습니다. 에이전트가 본격화되면서 이 구조가 바뀌었습니다. 흐름을 정리하면 이렇습니다.

1. API 단계: 개발자가 모든 것을 직접 구현 (Messages API)
2. SDK 단계: 하네스가 라이브러리로 패키징됨. 단, 호스팅과 확장은 여전히 개발자 몫 (Claude Agent SDK 등)
3. 관리형 단계: 호스팅, 확장, 관측까지 모델 회사가 운영 (Anthropic Managed Agents 등)

각 단계마다 예전엔 개발자의 일이었던 것을 모델 회사가 점점 더 떠안습니다. 저자는 이것이 좋은 변화라고 분명히 말합니다. 그가 직접 겪었기 때문입니다.

저자의 팀은 Converge를 만들 때 여러 모델을 지원하려고 모델 중립적인 프레임워크를 골랐습니다. 그런데 정작 내부 벤치마크를 통과한 건 Anthropic 모델뿐이라, 결국 Anthropic 모델만 출시했죠. 모델 중립성의 비용은 다 치르고(여러 시스템 프롬프트, 복잡한 툴 관리 코드) 그 혜택은 하나도 못 본 셈입니다. 지금 다시 시작한다면 처음부터 Claude Agent SDK 하나로 표준화하겠다는 게 그의 결론입니다. 그래야 Anthropic이 하네스를 개선할 때마다 그 개선이 공짜로 따라오니까요.

직접 만들지 말고, 진짜 차별점에 집중하라

이 글이 개발자에게 던지는 메시지는 명확합니다. 하네스를 직접 만드는 데 쏟던 에너지를, 정말 차별화되는 부분으로 옮기라는 것입니다.

저자가 짚는 차별화 지점은 하네스 그 자체가 아닙니다. 툴 설명(tool description), 시스템 프롬프트, 그리고 도메인에 특화된 주변 기술입니다. 핵심 에이전트 루프나 재시도 로직은 이제 모델 회사들이 전담 팀을 두고 끊임없이 개선하고 있어서, 스타트업이 이를 따라잡는 건 비효율적입니다.

여기엔 구조적인 이유도 있습니다. 모델 회사가 만든 하네스는 모델과 함께 최적화됩니다. 모델의 특정 행동을 하네스 코드로 보정하고, 새 모델이 나오면 다시 하네스를 업데이트하는 식이죠. 모델 내부를 들여다볼 수 없는 제3자 하네스에는 존재하지 않는 피드백 루프입니다. 게다가 모델 회사들은 전담 팀을 두고 새 하네스 기능을 계속 쏟아냅니다. Anthropic만 해도 최근 수백 개의 서브에이전트에게 작업을 위임하는 Workflows, 에이전트가 스스로 돌아보고 개선하는 Dreaming, 관측성, 샌드박스 격리 같은 기능을 잇따라 내놨습니다. 직접 만든 에이전트라면 이런 능력을 일일이 따라 구현해야 하지만, 모델 회사 하네스를 쓰면 그냥 어느 날 기능이 생겨 있습니다. 결국 모델을 만드는 회사가 그 모델에 맞는 하네스를 가장 잘 만들 수밖에 없다는 논리입니다.

다만 이 글이 모든 상황의 정답은 아닙니다. 벤치마크는 평범한 코딩 과제만 측정하기 때문에, 더 복잡한 작업이나 특수한 요구사항에서는 하네스 선택이 여전히 갈릴 수 있습니다. 저자의 관점은 어디까지나 “범용 코딩 에이전트를 만드는 팀”에 가장 잘 들어맞습니다. 모델 회사가 하네스를 넘어 인프라 계층까지 올라오는 지금, 다음엔 스택의 어디까지가 개발자의 몫으로 남을지가 더 흥미로운 질문일지도 모릅니다.