코딩 에이전트 도입 회의에서 모델 이름과 벤치마크 점수만 비교하면 중요한 절반을 놓치기 쉽습니다. 개발자가 체감하는 에이전트는 모델 API가 아니라, 그 모델에 어떤 저장소 정보와 도구를 주고, 실패했을 때 어디까지 다시 시도하며, 변경 결과를 어떻게 검증하는지까지 묶은 제품이기 때문입니다.
여기서 하네스(harness)란 모델이 작업을 수행하도록 돕는 실행 환경을 말합니다. 파일 읽기·수정, 셸 명령 실행, 검색, 브라우저 접근, 컨텍스트 전달, 작업 횟수 제한, 승인 절차, 테스트 실행과 결과 요약이 모두 하네스의 일부입니다.
따라서 CTO나 개발 리드는 “어느 모델이 더 똑똑한가”와 함께 “우리 코드베이스와 통제 조건에서 어느 하네스가 더 적은 실패 비용으로 일하는가”를 비교해야 합니다. 모델 성능은 출발점이고, 업무 성과는 모델과 하네스의 조합에서 나옵니다.
같은 모델도 비용 곡선이 달라질 수 있다
공개 벤치마크를 대상으로 여러 모델과 Claude Code, Codex CLI, Pi를 조합해 비교한 실험에서는, 동일 모델이 하네스에 따라 과제 성공률은 큰 차이가 없으면서도 비용은 크게 달라지는 결과가 제시됐습니다. 해당 실험은 SWE-bench Lite와 Terminal-Bench 2.0에서 모델·하네스 조합 21개를 비교했고, 각 과제를 세 번씩 실행했습니다.
특히 해당 조건에서 Claude Fable 5는 Claude Code, Codex, Pi에서 비슷한 성공률을 보였지만, Claude Code의 비용은 Pi보다 약 두 배였습니다. 공유 모델을 기준으로 보면 SWE-bench Lite에서 Claude Code 비용은 Pi의 약 2.0배, Codex의 약 1.6배였다는 분석도 포함됩니다. 반면 성공률 차이는 평균적으로 제한적이었습니다.
이 결과를 “기능이 적은 하네스가 항상 낫다”로 읽으면 곤란합니다. 실험은 외부 네트워크를 막고 웹 도구를 비활성화했으며, 특정 벤치마크와 설정, 최대 100턴이라는 조건에서 수행됐습니다. 웹 조사, 사내 문서 검색, 장기 작업, 사람과의 상호작용이 필요한 업무에서는 결과가 달라질 수 있습니다.
다만 구매 판단에는 분명한 질문을 남깁니다. 공급자가 제시하는 모델 성능이 같거나 비슷하다면, 팀은 하네스가 추가하는 컨텍스트와 도구 호출, 재시도 루프에 얼마를 지불하는지 따로 확인해야 합니다.
비교의 출발점은 기능 목록이 아니라 업무 유형이다
에이전트 제품의 도구 수가 많다고 생산성이 높아지는 것은 아닙니다. 반대로 최소 도구 구성도 모든 팀에 맞지 않습니다. 먼저 팀이 맡길 작업을 세 갈래로 나누면 비교 기준이 선명해집니다.
| 업무 시나리오 | 우선 비교할 하네스 요소 | 지나치게 단순할 때의 위험 | 지나치게 복잡할 때의 위험 |
|---|---|---|---|
| 버그 수정과 테스트 통과 | 저장소 탐색, 파일 편집 정확도, 로컬 테스트 실행, 변경 범위 제한 | 관련 파일을 놓치거나 테스트 없이 수정안을 냄 | 긴 지시문과 반복 탐색으로 비용이 커짐 |
| 리팩터링과 다중 파일 변경 | 심볼 탐색, 계획 유지, 중간 상태 복구, diff 검토 | 부분 수정 뒤 일관성이 깨질 수 있음 | 불필요한 파일까지 건드리거나 작업이 길어짐 |
| CI 장애 분석과 운영 자동화 | 로그 접근 범위, 명령 권한, 비밀정보 차단, 승인 단계 | 원인을 재현하지 못하고 추측으로 끝남 | 과도한 실행 권한이 보안·장애 위험을 키움 |
| 신규 기능 초안과 문서화 | 요구사항 컨텍스트, 코딩 규칙 주입, 사람 검토 연결 | 팀 규칙을 모르고 일반적인 코드만 생성 | 문서와 지침을 너무 많이 넣어 핵심 요구를 흐릴 수 있음 |
예를 들어 단위 테스트가 잘 갖춰진 서비스에서 작은 버그를 고치는 용도라면, 파일 읽기·편집·셸 실행·테스트 결과 확인이 안정적으로 이어지는지가 핵심입니다. 반면 모놀리식 저장소를 여러 팀이 함께 관리하고 공통 모듈의 영향 범위가 큰 경우에는 코드 검색과 심볼 수준 탐색, 변경 계획을 유지하는 방식, 작업 중단 뒤 재개하는 능력을 더 비중 있게 봐야 합니다.
“우리 팀은 에이전트에게 무엇을 시킬 것인가”가 먼저 정해져야 모델과 하네스의 우선순위도 정해집니다.
하네스에서 따로 검증할 네 가지 축
1. 도구 권한: 할 수 있는 일보다 막을 수 있는 일을 본다
에이전트가 셸을 실행하고 네트워크에 접속하며 배포 환경을 조회할 수 있다면 작업 범위도 넓어집니다. 그러나 권한이 넓을수록 실수의 반경도 커집니다. 비교할 때는 “Git 명령을 지원하는가”보다 다음을 확인하는 편이 낫습니다.
- 읽기, 쓰기, 삭제, 명령 실행, 네트워크 접근을 작업별로 나눠 제한할 수 있는가
- 위험한 명령이나 외부 전송 전에 사람 승인을 요구할 수 있는가
- 비밀정보, 운영 설정, 고객 데이터가 프롬프트나 도구 출력에 섞일 때 차단하거나 가릴 수 있는가
- 에이전트가 실행한 명령과 수정 파일을 작업 단위로 남기는가
권한 통제가 부족한 제품은 초기 데모에서는 빠르게 보일 수 있습니다. 하지만 CI 권한, 운영 로그, 내부 패키지 레지스트리를 연결하기 시작하면 검토 부담이 커집니다. 특히 운영 환경과 가까운 도구를 붙일 계획이라면, 기능 데모와 별도로 권한 모델을 평가해야 합니다.
2. 컨텍스트 운영: 많이 넣는 것과 잘 넣는 것은 다르다
하네스는 시스템 지침, 도구 설명, 저장소 파일, 이전 대화, 테스트 출력 등을 모델에 전달합니다. 이 초기 컨텍스트가 길어지면 모델이 참고할 정보는 늘지만, 호출 비용과 주의 분산 가능성도 함께 커집니다.
앞선 비교 실험에서는 Claude Code의 첫 주요 모델 호출 컨텍스트가 Pi보다 평균적으로 10배 이상 컸다고 보고했습니다. 이 차이가 전체 비용을 모두 설명하지는 않습니다. 캐시, 출력 토큰, 이후 호출 횟수도 비용에 영향을 줍니다. 그래도 구매팀은 공급자에게 초기 프롬프트 길이만 묻지 말고 다음 흐름을 확인할 필요가 있습니다.
- 저장소 전체를 읽는 대신 필요한 파일을 찾아가는가
- 작업이 길어질 때 이전 대화를 요약하거나 핵심 결정만 보존하는가
- 테스트 로그와 빌드 출력이 길어질 때 무엇을 남기고 무엇을 버리는가
- 팀의 코딩 규칙과 아키텍처 문서를 매번 넣는지, 필요한 시점에 검색하는지
컨텍스트가 부족하면 에이전트는 팀 규칙을 잊고, 과도하면 비용과 응답 시간이 늘 수 있습니다. 적정선은 제품 설명서가 아니라 팀 저장소와 실제 작업으로 확인해야 합니다.
3. 실패 복구: 재시도가 아니라 중단 기준을 평가한다
에이전트가 실패한 뒤 다시 시도하는 기능은 좋아 보이지만, 무제한 재시도는 비용을 숨기는 방식이 될 수 있습니다. 같은 테스트 실패를 다른 표현의 코드로 반복 수정하거나, 잘못된 가정 위에서 탐색을 이어가면 사람보다 늦고 비싸질 수 있습니다.
평가 환경에서는 실패 복구를 다음처럼 관찰합니다.
- 테스트 실패 뒤 원인 가설을 바꾸는가, 아니면 같은 수정 패턴을 반복하는가
- 변경이 악화됐을 때 이전 상태로 되돌리거나 diff를 정리하는가
- 정해진 횟수 안에 사람에게 넘길 수 있는가
- 포기할 때도 실행한 명령, 확인한 파일, 남은 가설을 전달하는가
조기 경고 신호는 분명합니다. 작업 턴 수가 늘어도 수정 파일과 테스트 결과가 거의 바뀌지 않거나, 실패한 명령을 반복 실행하거나, 최종 답변에는 성공했다고 쓰지만 검증 로그가 없다면 하네스의 복구 규칙을 의심할 만합니다.
4. 검증 자동화: 코드 생성보다 증거 제출이 중요하다
개발팀이 원하는 것은 그럴듯한 패치가 아니라 병합 가능한 변경입니다. 그래서 에이전트 평가는 “문제를 풀었는가”에 더해 “무엇으로 확인했는가”를 봐야 합니다.
벤더 평가 과제에는 팀의 실제 흐름에 맞는 검증 단계를 넣는 편이 좋습니다. 예를 들어 의존성 설치, 정적 분석, 단위 테스트, 통합 테스트, 빌드, 변경 파일 목록, 미실행 검증 항목을 어떤 순서로 보여 주는지 확인합니다. 테스트가 오래 걸리거나 실행할 수 없는 상황도 포함해야 합니다. 좋은 하네스는 성공 신호만 모으지 않고, 검증하지 못한 범위를 사람이 알아볼 수 있게 남깁니다.
파일럿은 모델 대결이 아니라 조합 비교로 설계한다
공급자 선정 단계에서는 한 제품에 익숙해진 뒤 다른 제품을 보는 방식보다, 같은 업무 묶음을 같은 조건에서 비교하는 방식이 낫습니다. 가능하다면 후보 하네스마다 같은 모델을 연결해 보고, 이어서 각 제품의 권장 모델 조합도 시험합니다. 그래야 모델 차이와 하네스 차이를 어느 정도 분리해 볼 수 있습니다.
평가 과제는 대표 업무만 고르면 부족합니다. 다음 세 유형을 함께 넣어야 합니다.
- 명확한 수정 과제: 재현 절차와 통과해야 할 테스트가 있는 버그 수정
- 탐색 부담이 큰 과제: 여러 모듈을 읽고 영향 범위를 판단해야 하는 변경
- 불완전한 과제: 요구사항이나 로그가 부족해 사람에게 질문하거나 중단해야 하는 상황
각 실행에서 성공 여부 외에 입력·출력 비용, 걸린 시간, 도구 호출 내역, 변경 파일 수, 테스트 실행 결과, 사람 검토에 든 시간을 기록합니다. 비용이 낮아도 리뷰어가 매번 수정 범위를 다시 추적해야 한다면, 그 절감액은 팀 전체 비용으로 이어지지 않을 수 있습니다. 반대로 비용이 조금 높더라도 변경 근거와 검증 기록을 꾸준히 남긴다면 특정 업무에서는 선택할 이유가 생깁니다.
계약 전에는 기본 설정과 탈출 경로를 확인한다
데모에서 보인 기능이 계약 후에도 같은 조건으로 유지되는지 확인하려면 기본 설정을 질문해야 합니다. 높은 추론 강도, 자동 승인, 긴 작업 턴, 광범위한 컨텍스트가 기본값으로 켜져 있으면 월별 비용과 위험은 사용량이 늘수록 달라집니다.
벤더에게는 다음 질문을 문서로 받는 편이 좋습니다.
- 모델, 도구 스키마, 시스템 지침, 작업 이력 가운데 고객이 조정할 수 있는 범위는 어디까지인가
- 최대 작업 턴, 비용 한도, 시간 한도, 실패 시 중단 규칙을 프로젝트별로 설정할 수 있는가
- 사내 모델이나 다른 모델 공급자로 교체할 수 있는가. 교체 시 잃는 기능은 무엇인가
- 실행 로그, 변경 이력, 검증 결과를 어떤 형식으로 내보낼 수 있는가
- 공급자 서비스 장애나 모델 변경 시 작업을 중단하고 사람이 이어받는 절차는 무엇인가
코딩 에이전트를 고를 때 첫 파일럿의 목표는 가장 화려한 데모를 찾는 일이 아닙니다. 팀이 자주 맡는 작업 하나를 정하고, 그 작업에서 허용할 권한, 쓸 수 있는 비용, 실패 시 멈춰야 할 지점, 병합 전에 남겨야 할 검증 증거를 먼저 합의해 보십시오. 그 조건을 통과하는 모델·하네스 조합이 팀에 맞는 후보입니다.
