개발자가 같은 일을 맡겨도 조직이 부담하는 비용은 크게 달라질 수 있다. 차이는 개인의 사용 습관보다 에이전트가 작동하는 환경에서 먼저 생긴다.
생산성보다 빠르게 늘어나는 비용
코딩 에이전트 비용은 프롬프트보다 세션에 누적되는 컨텍스트에서 커진다. 컨텍스트는 시스템 지시, 이전 대화, 읽은 파일, 도구 호출 결과처럼 매 요청마다 함께 입력되는 정보를 뜻한다. 50턴(모델과 한 번씩 주고받는 단위) 작업은 입력 약 100만 토큰, 출력 4만 토큰을 쓴다. 입력이 출력보다 20~25배 많은 구조다.
세션이 길어지면 이미 읽은 파일과 이전 대화까지 매번 다시 전송된다. 탐색 단계에서 5,000토큰이던 턴당 입력이 구현 단계에는 2만, 테스트, 수정 단계에는 3만5,000토큰까지 늘 수 있다. 실제로 전체 토큰 중 캐시로 다시 불러오는 읽기 연산의 비중이 가장 크다는 분석도 있어, 출력만 줄여서는 비용을 잡기 어렵다.
같은 50턴 세션이라도 모델에 따라 비용은 0.60달러에서 6달러까지 벌어진다. 25명 팀이 월 1,000세션을 실행하면 연간 비용은 7,200달러에서 7만2,000달러까지 차이 난다. 가트너 조사에서는 기술 리더의 약 25%가 개발자 한 명당 월 200~500달러를 썼고 6%는 2,000달러를 넘었다고 밝혔다.
그런데 이렇게 쓴 비용만큼 생산성도 오를까. 스탠퍼드 소프트웨어 엔지니어링 생산성 연구에서는 단순 신규 개발은 35~40% 개선됐지만 숙련 개발자의 기존 시스템 작업은 10% 이하에 머물렀다. CodeRabbit이 표본으로 집계한 주요 이슈 기준으로는 AI가 만든 PR의 이슈가 1.7배 많았다. 토큰 비용은 즉시 발생하지만, 가치는 코드가 리뷰와 테스트를 통과한 뒤에야 확정된다.
최고 모델보다 적정 모델
Databricks는 가장 똑똑한 모델 대신 필요한 품질을 가장 싼 가격에 내는 모델을 고른다. 일상적인 코딩 업무 대부분에는 최고 성능 모델이 필요하지 않으며, 모델과 도구를 함께 조정하면 비용을 크게 낮출 수 있다.
하지만 연례 계약만으로 모델을 운영하면 가격과 성능이 빠르게 바뀌는 사이 새 선택지의 이점을 놓치기 쉽다. Databricks가 사내 평가 후 GLM 계열을 도입한 배경이다. GLM-5.2는 일부 제3자 제공업체 기준 입력 100만 토큰당 0.93달러, 출력은 3달러에 제공되면서 장기 코딩 벤치마크에서도 상위권을 기록했다.
Stripe 역시 신형 모델인 Claude Opus 4.7의 가격 상승에 비해 품질 개선이 작다고 보고 배포하지 않았다. 벤더의 발표가 아니라 사내 업무를 반영한 평가가 먼저다.
모델 선택에 더해, 에이전트를 실행하고 컨텍스트와 도구 호출을 관리하는 ‘하네스’도 비용에 영향을 준다. 오픈소스 하네스 Pi는 Databricks 평가에서 좋은 성적을 냈고 Omnigent는 Claude Code, Codex, Cursor, Pi를 같은 환경에서 쓸 수 있게 한다. 그렇다고 도구부터 늘릴 필요는 없다. 조합별 품질, 재시도 횟수, 최종 비용을 같은 기준으로 측정하는 일이 우선이다.
차단보다 단계적인 통제
개발자별 하드 캡은 간단하지만 일이 몰릴 때 업무 진행까지 가로막는다. 한도에 막힌 개발자가 개인 계정이나 미승인 도구로 옮겨가면 지출을 추적할 수 없고, 회사 코드가 외부 서비스로 넘어갈 위험도 생긴다.
한 번에 차단하는 것이 답일까. 사용량에 따라 마찰을 높이는 편이 낫다. 실시간 지출을 보여주고 일정 구간에서는 경고를 직접 해제하게 하는 것부터 시작해 승인 요청과 저가 모델 전환을 거쳐 계정 정지는 마지막 수단으로 남긴다.
이때 자동 전환은 절감액이 아니라 재시도까지 합친 총비용으로 평가해야 한다. 저가 모델이 두 번 실패하면 고가 모델을 한 번 쓰는 것보다 비쌀 수 있다. 라우팅은 요청의 난도와 업무 종류에 따라 저가 모델과 상위 모델 중 하나를 고르고 실패하면 자동으로 전환하는 방식이다. 반면 라우팅이 안정되면 효과가 크다. Databricks의 AI Gateway Smart Router는 비슷한 품질을 유지하며 평균 비용을 30% 이상 낮췄다. 단, 저장소와 업무가 조직마다 다른 만큼 자체 평가 데이터가 필요하다.
또한 불필요한 도구 결과, 검색한 코드, 시스템 정보를 일찍 덜어내고 캐시를 조정하면 품질 저하 없이 비용을 낮출 수 있다. 캐시는 이전 입력을 다시 처리하지 않고 재사용해 처리량과 과금액을 줄이는 방식이다. 다만 압축이 너무 늦으면 파일을 다시 읽느라 캐시 효율이 떨어지므로 압축 시점까지 함께 설계하는 편이 낫다.
결국 모델 목록, 라우팅, 예산, 컨텍스트 정책과 로그는 한곳에서 관리하는 편이 좋다. Unity AI Gateway 같은 게이트웨이가 이런 역할을 한다. 도입 순서는 계측(사용량, 비용 측정), 컨텍스트와 캐시 조정, 모델 구성 변경, 라우팅, 예산 통제가 적절하다. 사람의 사용을 막기 전에 시스템의 낭비부터 줄이는 편이 우선이다.
비용 곡선의 주인은 누구인가
개발자가 작업을 시작해도 실제 단가와 컨텍스트 길이, 기본 모델은 도구 설정이 결정한다. 이 설정의 책임자가 없다면? 조직은 가격을 관리하지 못한 채 사용량만 늘린다.
그래서 게이트웨이에 모델과 사용량, 라우팅, 예산 정책을 모으면 가격과 성능의 변화를 빠르게 반영할 수 있다. Databricks 사례에서는 컨텍스트 조정, 오픈 웨이트 모델, 하네스, 라우팅을 함께 적용해 일부 시나리오에서 단가를 최대 90% 낮췄다.
목표는 개발자가 필요한 도구를 자유롭게 쓰되 1인당 비용을 예측 가능한 범위에 머물게 하는 것이다. 한도를 넘으면 바로 차단하기보다 업무에 맞는 모델과 컨텍스트를 다시 고르게 하는 방식이 효과적이다.
코딩 에이전트 비용은 재무팀이 계산서를 보기 전에 결정된다.
허용 모델, 컨텍스트 길이, 상위 모델로 전환할 시점은 모두 플랫폼 설계의 문제다. 비용 곡선은 에이전트의 요청이 지나가는 경로에서 관리하는 편이 실질적이다.
나아가 에이전트 사용이 일상화되면 비용 데이터에는 단순한 지출 기록을 넘어 개발 과정의 마찰이 함께 남는다. 재시도가 잦고 세션이 길어지는 구간에서는 도구와 업무가 맞지 않는다는 신호가 함께 나타난다.