코딩 에이전트 비용 관리: Claude Code, Codex, Gemini 지출 추적

코딩 에이전트 하나로 시작했습니다. 그런데 지금은 Claude Code가 한 터미널에서, Codex가 또 다른 터미널에서, Gemini CLI가 세 번째 터미널에서 돌아가고 있습니다. 각자 요금 체계도 제각각입니다. 어떤 건 구독형, 어떤 건 사용량 기반 API 키, 또 어떤 건 지난주에 조용히 무료 한도를 넘겨 유료로 전환된 무료 티어죠. 월말이 되면 청구서 세 장이 남고, 정작 간단한 질문 하나에는 답할 수 없습니다. 지난주 기능을 만드는 데 실제로 얼마가 들었을까요?

코딩 에이전트 비용 관리란 에이전트 지출을 그것을 발생시킨 작업에 귀속시키고, 팀이 사용하는 모든 도구에 걸쳐 그 지출을 계속 눈에 보이고 검토 가능한 상태로 유지하는 실무입니다. 어려운 부분은 특정 에이전트 하나의 토큰당 가격이 아닙니다. 가격은 바뀌고, 각 벤더가 공개하니까요. 진짜 어려운 점은 에이전트를 둘 이상 돌리는 순간 지출이 서로 다른 청구 시스템으로 흩어져서, 누구도 금액을 특정 작업이나 저장소, 혹은 담당자와 연결할 수 없다는 것입니다.

이 글에서는 각 도구의 비용이 실제로 어디서 발생하는지, 여러분이 통제할 수 있는 변수는 무엇인지, 그리고 Sharkly 같은 관리 레이어가 이미 쓰고 있는 도구를 떠나지 않고도 작업별 지출을 어떻게 계속 보이게 유지하는지 살펴봅니다. Sharkly는 에이전트 위에 위치합니다. 여러분은 Claude Code, Codex, Gemini 구독을 그대로 유지하고, 각 실행 기록은 그것이 속한 Task로 돌아갑니다.

에이전트를 세 개 돌릴 때 비용 관리가 의미하는 것

에이전트가 하나일 때 비용은 대시보드 하나에서 읽어낼 수 있는 숫자입니다. 세 개가 되면 비용은 조율 문제가 됩니다. 지출은 실제로 발생하지만, 결코 서로 맞아떨어지지 않는 세 곳에 나뉘어 있습니다. Anthropic의 Claude Code 사용량, Codex용 OpenAI 청구 페이지, 그리고 Gemini용 Google Cloud 프로젝트입니다.

여기서 분명히 짚고 넘어갈 경계가 있습니다. 비용 관리는 비용 절감과 다릅니다. 지출을 줄인다는 건 토큰을 덜 쓴다는 뜻입니다. 지출을 관리한다는 건 토큰이 어디로 갔는지 알고, 그게 그만한 가치가 있었는지 판단한다는 뜻입니다. 기능 세 개를 동시에 출시하느라 일부러 비싼 달을 보낼 수도 있고, 지출을 귀속시킬 수 있고 누군가 승인했다면 여전히 통제하고 있는 것입니다.

바로 그 귀속이 빠져 있는 레이어입니다. 여러 에이전트를 돌리는 대부분의 팀은 총 AI 청구 금액은 말할 수 있지만 그보다 세분화된 건 아무것도 말하지 못합니다. 어느 저장소, 어느 엔지니어, 어느 작업이 그 지출을 이끌었는지 답할 수 없죠. 지출이 작업 단위에서 보이지 않으면 비용 논의는 추측으로 변하고, 그러면 보통은 실제로 예산을 태우는 도구가 아니라 눈에 가장 잘 띄는 도구의 한도를 걸어버리는 반응이 나옵니다.

세 도구의 비용은 실제로 어디서 발생하는가

각 에이전트는 대략 같은 것에 대해 과금합니다. 입력 토큰과 출력 토큰이죠. 하지만 청구 모델이 충분히 달라서 예산을 짜는 방식도 달라집니다. 각자의 최적 상황에서 비교해보면, 어느 하나가 무조건 더 저렴한 게 아닙니다. 서로 다른 형태의 작업에서 각각 더 저렴할 뿐입니다.

구독 모델은 한계 비용을 숨깁니다. 정액 월 요금제는 한계 비용이 없는 것처럼 느껴져서 엔지니어들은 끊임없이 손을 뻗습니다. 그러면 진짜 질문은 “이거 만드는 데 얼마 들었지”에서 “우리 요금제 한도에 부딪히고 있나”로 바뀝니다. 사용량 기반 API 키 모델은 정반대입니다. 모든 실행에 가격이 보이니 예산 관리가 더 깔끔해지지만, 몇 푼 아끼려고 성능 좋은 에이전트를 덜 쓰게 만드는 유혹이 생깁니다.

한두 명이 하루 종일 꾸준히 에이전트를 돌리고 작업별 세부 내역보다 예측 가능한 청구가 더 중요할 때는 구독 요금제를 쓰세요. 지출을 정확히 귀속시켜야 하거나, 자동화 환경에서 돌리거나, 총액에 책임질 사람이 필요한 팀에 작업을 분산시킬 때는 사용량 기반 API 키를 쓰세요. 많은 팀이 결국 둘 다 쓰게 되는데, 바로 그래서 하나로 통합된 뷰가 중요한 것입니다. 어떤 에이전트가 어떤 작업을 맡을지 고민 중이라면, 벤더를 바꾸는 것보다 작업에 모델을 매칭하는 것이 청구서에 훨씬 도움이 됩니다.

여러분이 실제로 통제하는 세 가지 변수

벤더 가격은 변수가 아닙니다. 터미널에서 협상할 수 있는 게 아니니까요. 진짜로 여러분 손에 쥐어진 세 가지가 있고, 이게 정가보다 훨씬 중요합니다.

컨텍스트 규율. 가장 크게 피할 수 있는 비용은 에이전트가 이미 가지고 있던 컨텍스트를 다시 보내는 것입니다. 매 턴마다 전체 코드베이스를 다시 읽는 에이전트는 매 턴마다 그 코드베이스 값을 치르는 셈입니다. 실행 사이에 컨텍스트를 유지해서, 에이전트가 처음부터 다시 구축하는 대신 현재 상태에서 시작하게 하는 것이 보통 가장 큰 절감 효과를 냅니다. 코드베이스 메모리와 토큰 비용 뒤에 있는 원리도 같습니다. 유지하는 것은 다시 사지 않으니까요.

모델과 작업의 매칭. 한 줄짜리 이름 변경을 무거운 추론 모델에 돌리면 돈이 낭비되고, 아키텍처 리팩터링을 작고 빠른 모델에 돌리면 오후 하나가 낭비됩니다. 절감은 모든 작업을 가장 성능 좋은 에이전트로 기본 설정하는 대신 모델을 작업에 맞출 때 발생합니다.

병렬 처리의 경계. 에이전트를 병렬로 돌리는 것이야말로 진짜 산출량 증가가 일어나는 지점이며, 동시에 지출이 가장 빠르게 불어나는 지점입니다. 에이전트 다섯 개가 동시에 작업하면 실시간 기준 단위 시간당 비용이 대략 다섯 배가 됩니다. 다섯 개 작업이 준비되어 있고 그만한 가치가 있다면 괜찮지만, 그중 세 개가 막연한 가능성이었다면 비쌉니다. 변수는 “에이전트를 덜 돌리자”가 아닙니다. 시작하기 전에 어떤 작업이 병렬 슬롯에 들어갈 가치가 있는지 결정하는 것입니다. 병렬로 돌아가는 에이전트를 모니터링하는 것이 그 결정을 추측에서 방어 가능한 판단으로 바꿔줍니다.

팀 규모별 의사결정 표

비용 방정식은 몇 명과 몇 개의 에이전트를 조율하는지에 따라 달라집니다. 솔로 개발자에게 괜찮은 것이 플랫폼 팀에게는 부채가 됩니다.

솔로이고 터미널 하나에서 에이전트 하나와 편하게 작업한다면, 비용을 통제하기 위해 관리 레이어가 필요하지 않습니다. 대시보드가 이미 필요한 걸 알려주고 있습니다. 방정식은 지출이 단일 뷰를 넘어설 때 달라집니다. 여러 에이전트, 여러 저장소, 그리고 여러분이 아닌 누군가가 책임져야 하는 예산이 생길 때죠. 그 시점이 되면 질문은 “어느 에이전트가 가장 싼가”에서 “누가 전체 그림을 보고 결정할 수 있는가”로 바뀝니다.

작업별 지출을 보이게 만들기

이것이 Sharkly가 만들어진 레이어이며, 무엇을 하고 무엇을 하지 않는지 정확히 짚을 가치가 있습니다. Sharkly는 청구 도구가 아니고, Claude Code, Codex, Gemini를 대체하지도 않습니다. 모델 사용은 그 도구들에 설정된 구독이나 API 키를 통해 계속됩니다. 여러분이 자기 구독을 가져오는 것이죠. Sharkly가 더하는 것은 그 주변의 공유 기록입니다. 모든 에이전트 실행은 Task 안에서 일어나고, 실행, 진행 상황, 장애 요소, 결과는 팀이 볼 수 있는 그 Task로 돌아갑니다.

그 공유 기록이 바로 비용을 읽을 수 있게 만듭니다. 각 실행이 담당자와 저장소가 있는 Task에 연결되면, 지출은 익명의 월간 총액이기를 그만두고 여러분이 가리킬 수 있는 결정들의 집합이 됩니다. 어떤 작업이 누구의 Computer에서 어떤 예산에 대고 돌아가는지, 요청부터 릴리스까지 볼 수 있습니다. 무엇이 돌아가고 있는지 보여주는 코딩 에이전트 대시보드가 지출을 관리하는 것과 청구서를 받고 나서야 발견하는 것의 차이입니다.

인간-에이전트 계약도 여기에 적용됩니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 그 지출이 결과에 비해 가치가 있었는지 결정합니다. 자동화는 팀의 판단이 필요한 지점에서 멈춥니다. 비용에서 그것은 에이전트 다섯 개의 병렬 실행이 정당하다고 스크립트가 아니라 사람이 시작 전에 결정한다는 뜻입니다.

청구를 단순화하려고 하나의 생태계로 확정하지 않고 여러 코딩 에이전트를 계속 쓰고 싶다면, 그것이 바로 Sharkly가 염두에 두고 설계된 문제입니다. 여러분이 쓰던 코딩 에이전트를 Sharkly를 통해 실행하고, 각 실행의 비용이 그것을 발생시킨 작업으로 돌아가게 하세요.