코드 에이전트 도구, 벤치마크와 가격표만 보고 골라도 될까?
결론부터 말하면 안 된다. 벤치마크 점수는 특정 작업군·모델 버전·추론 설정에서 나온 결과이고, 구독료는 대화형 사용량 한도일 뿐 API·자동화 비용과 분리돼 있다. 둘 다 "조건"을 빼고 보면 실제 사용 경험과 어긋난다.
- 구독료(월 20~125달러 수준)는 터미널 사용량과 한도를 공유하며, 실제 토큰 비용은 저장소 크기와 병렬 실행 수준에 따라 활성 사용일당 13달러, 월 150~250달러까지 벌어진다.출처: Claude Code 비용 문서
- SWE-bench Verified 74.5%, SWE-Bench Pro 56.4% 같은 수치는 각각 다른 벤치마크·모델·추론 강도를 전제로 한다. 단일 숫자로 "코딩을 잘한다"고 요약하면 조건이 사라진다.
- 같은 CLI 에이전트라도 프로젝트 단위 비교 연구에서는 조합별 점수가 68~78% 범위로 갈렸다.
- 실무 도입 전엔 토큰 비용, 재시도 횟수, 사람 리뷰 비율을 별도로 기록해야 비교가 의미 있다.
흔히 빠지는 함정은 이렇다. 데모 영상이나 벤치마크 리더보드를 보고 "이 도구면 저장소를 통째로 맡겨도 되겠다"고 판단한 뒤, 실제로는 작은 함수 하나 고치는 데도 토큰 비용과 재검토 시간이 예상보다 훨씬 많이 든다는 걸 뒤늦게 발견하는 경우다. 벤치마크는 통제된 저장소와 통제된 테스트 환경에서 측정된 숫자이고, 실제 레거시 코드베이스는 그 조건과 다르다.
구독료만 보면 왜 실제 비용을 놓치게 될까?
구독료는 대화형 사용 한도일 뿐이고, 자동화·에이전트 실행은 별도 토큰 비용으로 쌓이기 때문이다. Claude Pro는 월 20달러(연간 결제 시 17달러), Team Standard는 좌석당 월 20~25달러, Premium은 100~125달러다. 하지만 이는 "플랜에 포함된 사용량"이지 "무제한"이 아니다. Anthropic이 공개한 기업 배포 사례에서는 개발자 1명당 활성 사용일 기준 평균 약 13달러, 월간으로는 150~250달러 수준의 비용이 발생했고, 사용자의 90%는 활성 사용일 비용이 30달러 미만이었다고 밝혔다.출처: Claude Code 비용 문서
Codex 쪽도 비슷한 구조다. codex-mini-latest 가격은 입력 100만 토큰당 1.50달러, 출력 100만 토큰당 6달러이며, 프롬프트 캐싱을 쓰면 75% 할인이 적용된다. 문제는 저장소를 매번 통째로 다시 읽느냐, 캐시를 재사용하느냐에 따라 같은 작업도 비용이 몇 배 차이 날 수 있다는 점이다. 리뷰 글이나 사내 비교표를 작성할 때 "월 20달러짜리 도구"라고만 적으면, 병렬 에이전트 실행이나 긴 저장소 탐색이 들어가는 순간 실제 지출과 어긋난다. 비용을 적을 땐 모델별 한도, 저장소 크기, 병렬 실행 여부를 함께 적는 편이 안전하다.
벤치마크 점수 하나로 도구를 고르면 뭐가 문제일까?
문제는 같은 이름의 벤치마크라도 평가 조건이 다르면 점수가 전혀 다른 의미를 갖는다는 점이다. SWE-bench Verified 500개 작업 기준으로 GPT-5 고추론 설정은 74.5%, GPT-5-Codex 고추론 설정은 72.8%로 보고됐다. 반면 GPT-5.2-Codex는 SWE-Bench Pro에서 56.4%, Terminal-Bench 2.0에서 64.0%를 기록했는데, 이 두 벤치마크는 성격이 다르다. SWE-Bench Pro는 저장소에 패치를 생성하는 작업이고, Terminal-Bench 2.0은 컴파일·모델 학습·서버 설정 같은 실제 터미널 작업을 포함한다. "코딩을 잘한다"는 한 문장으로 뭉뚱그리면 패치 정확성과 터미널 작업 수행 능력이라는 서로 다른 역량이 섞여버린다.
2026년 공개된 ProjDevBench는 Cursor, GitHub Copilot, Claude Code, Augment, Codex CLI, Gemini CLI 등 6개 CLI 기반 에이전트를 실행 정확성 80%, 코드 리뷰 규칙 준수 20%로 평가했다. Codex와 GPT-5 조합은 77.85%, Augment와 GPT-5는 72.35%, Cursor와 GPT-5는 71.85%, Claude Code와 Sonnet 4.5는 68.87%를 기록했다.출처: ProjDevBench 이 수치는 해당 연구의 특정 과제군과 실행 조건에 한정된 결과이며, 제품 전체의 우열을 뜻하지 않는다. 모델 버전이 바뀌거나 저장소가 달라지면 순위도 바뀔 수 있다.
같은 저장소에서 도구마다 결과가 다른 이유는 뭘까?
실행 조건이 통제되지 않으면 같은 도구조차 매번 다른 결과를 내기 때문이다. 재현 가능한 비교를 하려면 동일한 저장소와 동일한 커밋에서 시작하고, 모든 도구에 같은 요구사항·테스트 명령·실행 권한을 제공해야 한다. 그다음 모델명과 버전, 추론 강도, 컨텍스트 크기, 승인 모드를 기록하고, 변경된 파일과 줄 수, 첫 실행 테스트 통과 여부와 최종 통과 여부를 나눠 저장해야 한다.
실패한 작업을 지우지 않는 것도 중요하다. 실패 원인과 재시도 횟수를 그대로 남겨야 "어느 유형의 작업에서 자주 막히는지"가 보인다. 예를 들어 초기 프롬프트에 완료 기준을 명시하지 않으면 테스트를 돌리지 않고 완료로 보고하는 경우가 있고, CLAUDE.md 같은 프로젝트 지침 파일이 없으면 기존 코드 스타일을 무시하고 새 패턴을 도입하는 경우도 있다. 동일 과제를 최소 3회 반복해야 한 번의 우연한 성공을 평균 성능으로 오해하지 않는다. 한 번의 성공 사례만 공유하는 리뷰는 재시도 횟수와 검수 시간을 가려버린다.
에이전트가 테스트까지 돌리면 사람 검수는 필요 없을까?
필요 없다고 단정하면 틀린다. OpenAI는 Codex를 지시를 따르고 코드를 수정한 뒤 테스트를 반복 실행해 통과 여부를 확인하도록 설계했다고 설명한다. 이는 "결과를 스스로 검증한다"는 뜻이지 "사람 리뷰가 불필요하다"는 뜻이 아니다. 테스트가 통과했다고 해서 요구사항 해석이 정확했는지, 변경 범위가 허용 범위 안에 머물렀는지, 비밀정보가 코드에 노출되지 않았는지는 별개로 확인해야 한다.
실사용 리뷰에서 자주 생략되는 항목이 바로 "사람의 리뷰가 필요한 코드 비율"이다. 테스트 통과율만 보고하면 에이전트가 테스트 자체를 느슨하게 작성했거나, 기존 테스트를 우회하는 방식으로 통과시켰을 가능성이 가려진다. 완전 자율로 작동한다고 소개하는 자료가 있다면, 변경 범위 통제와 보안 취급 항목을 함께 확인했는지부터 물어보는 게 맞다.
실무에 도입하기 전에 뭘 먼저 측정해야 할까?
작업 1건당 시간·비용과 재시도 횟수를 먼저 측정해야 한다. 체크리스트는 다음과 같다: 저장소 크기와 언어·프레임워크 기록, 초기 프롬프트에 허용 범위·금지 조건·완료 기준 포함 여부, 프로젝트 지침 파일 사용 여부, 수정 전후 테스트 통과율, 변경 파일 수, 재시도 횟수, 총 소요 시간, 입력·출력 토큰과 API 비용 또는 구독 한도 사용량. 이 항목을 작업마다 기록해 두면 "이 도구가 이 프로젝트에서 얼마나 비용 효율적인지"를 숫자로 비교할 수 있다.
프롬프트 구조도 비용에 직접 영향을 준다. 목표, 허용 범위, 구현 조건, 검증 방법, 완료 기준을 명시한 프롬프트는 재시도 횟수를 줄여 토큰 비용을 낮추는 경향이 있다. 반대로 모호한 지시는 에이전트가 불필요한 범위까지 수정하게 만들고, 이는 변경 파일 수 증가와 리뷰 시간 증가로 이어진다. 비용 체크는 구독료 한 줄이 아니라 "요구사항 작성 품질 → 재시도 횟수 → 토큰 소모"로 이어지는 흐름 전체를 봐야 한다.
핵심 정리
- 구독료는 대화형 사용 한도일 뿐, 실제 토큰 비용은 저장소 크기와 자동화 수준에 따라 활성 사용일당 13달러, 월 150~250달러까지 벌어질 수 있다.출처: Claude Code 비용 문서
- SWE-bench Verified, SWE-Bench Pro, Terminal-Bench 2.0은 서로 다른 역량(패치 정확성 vs 터미널 작업 수행)을 측정하므로 단일 점수로 묶어 평가하면 안 된다.
- 프로젝트 단위 비교 연구에서는 같은 조건에서도 조합별 점수가 68~78% 범위로 갈렸고, 이는 특정 과제군에 한정된 결과다.출처: ProjDevBench
- 테스트 통과가 곧 검수 완료를 뜻하지 않으며, 변경 범위 통제와 보안 취급 여부는 별도로 확인해야 한다.
- 재현 가능한 비교를 하려면 동일 저장소·동일 조건에서 최소 3회 반복하고, 실패와 재시도 횟수를 지우지 않고 기록해야 한다.