코딩 에이전트(Coding-agent) 지출은 한 개발자의 노트북을 벗어나는 순간부터 이상해집니다.

하나의 기능(feature)이 Claude Code, Codex, Cursor, Copilot, OpenCode, 그리고 Deep Agents 커스텀 하네스(harness)를 거친 후 마침내 풀 리퀘스트(pull request)로 병합되는 구체적인 사례가 있습니다. 이 각각의 도구들은 독립적인 도구로서, 팀 앞에 "로컬 사용 화면(local usage screen)"이 놓여 있다면 "구매하기에 매우 합리적"일 수 있습니다. 하지만 청구서가 도착하면 실제 작업 비용은 완전히 달라지며, 이는 엔지니어링 리드(engineering lead)가 답변해야 하는 질문이 됩니다.

그 질문은 벤더(vendor)의 청구서만으로는 답변할 수 없습니다. 실행(run) 과정에서 답변을 찾아야 합니다.

"코딩 에이전트 청구서: 여러 코딩 에이전트 워크플로우에서의 기능 비용"에 관한 문제는 지난 7월 LangChain의 블로그 포스트에서 처음 논의되었습니다 (문제의 형태를 개괄함). 앞서 언급했듯이, 기능은 Claude Code, Cursor 또는 Copilot과 같은 여러 코딩 에이전트와 상호작용할 수 있습니다. 언급된 각 코딩 에이전트는 다양한 형식으로 활동 로그를 유지합니다. 결과적으로, 워크플로우 내에서 기능의 비용을 파악하는 것은 매우 어렵습니다. LangChain은 먼저 모든 도구 호출(tool calls) 등을 포함하여, 사용자와 코딩 에이전트 간의 모든 상호작용 턴을 거치는 모든 루트 세션(root sessions) 내의 모든 활동에 대한 정규화된 트레이스(normalized trace)를 생성해야 한다고 말합니다. 여기에는 모든 관련 메타데이터(metadata)가 포함되어야 합니다. 그런 다음 이 트레이스는 session_id, thread_id, 모델 또는 제공업체(provider), 또는 개별 코딩 도구의 이름별로 필터링할 수 있습니다. 이 문제를 해결하는 가장 어려운 부분은 바로 이 트레이스를 생성하는 것입니다.

단위는 트레이스(trace)입니다.

피해가 발생한 후에 도착하는 청구서

재무(Finance) 부서는 실행(run) 프로세스가 끝난 후에 청구서를 확인합니다. 엔지니어링(Engineering) 부서는 여전히 돈이 계속 나가고 있는 루프(loop)를 목격합니다.

코딩 에이전트(coding-agents)가 만들어내는 낭비는 행동적 낭비(behavioral waste)입니다. 즉, 다른 에이전트들이 만들어내는 것과 동일한 최적화되지 않은 행동 패턴을 의미합니다. 에이전트는 실패하는 동일한 테스트를 반복해서 재시도할 것입니다. 린트 수정(lint fix)을 위한 텍스트를 생성할 때마다 사용 가능한 가장 비싼 모델을 사용할 것입니다. 모놀리식 리포지토리(monolithic repository) 요약이 모든 상호작용 턴(interaction turn)에 포함될 것입니다. 느린 도구(tools)들이 작업을 수행하기 위해 호출되지만, 매우 모호한 에러 메시지만 받게 될 것입니다. 그러면 동일한 도구가 계속해서 다시 호출될 것이고, 결국 이 난장판을 디버깅하기 위해 다른 에이전트가 투입될 것입니다. 결과적으로 그동안 지출된 모든 비용에 대한 청구서가 생성되어 재무 부서에 얼마가 사용되었는지 알려줄 것입니다. 해당 청구서가 발생하는 동안 생성된 모든 호출 등의 트레이스(trace)는, 청구 금액이 그 액수가 되도록 만든 정확한 도구 호출(tool calls) 시퀀스를 드러낼 것입니다.

에이전트 지출은 런타임 신호입니다. 코딩 에이전트는 그 신호를 덜 추상적으로 만듭니다. 지출은 리포지토리(repository), 브랜치(branch), 커밋(commit), 풀 리퀘스트(pull request), 개발자(developer), 팀(team), 모델(model), 제공자(provider), 도구(tool), 그리고 세션(session) 단위로 추적됩니다. 제품 대시보드 곳곳에 흩어져 있던 추상적인 재무 문제는, 해당 필드들이 하나의 세션 트레이스(session trace)로 합쳐지는 순간 엔지니어링 문제(engineering problem)가 됩니다.

엔지니어링 문제는 해결할 수 있습니다.

FinOps Foundation(FinOps Foundation)에서 제시한 바와 같이, 전통적인 클라우드 비용 관리 플레이북(cloud cost playbook)의 많은 단계가 FinOps 관행을 구축하는 조직들에 의해 여전히 널리 채택되고 있습니다. 토큰당 비용(Cost per token), 특히 GPU 인스턴스의 클라우드 컴퓨팅 및 메모리에 대한 변동성이 큰 가격 책정, 클라우드 리소스 소비에 대한 일반적인 할당량(quotas), 애플리케이션 또는 팀별로 비용을 그룹화하기 위한 태그 지정 리소스(tagged resources), 그리고 비즈니스 결과와 연계하여 추적하는 실시간 재무 지표 등이 이에 해당합니다. 코딩 에이전트(Coding-agent) 지출은 일반적으로 스프레드시트로 표현할 수 있는 지출이 아니라, 루프(loops)와 프로그램 내에서 실행되는 지출로 취급됩니다. 따라서 할당량(quota)은 지출이 특정 선에 도달했을 때만 확인되며, 트레이스(trace)는 애초에 무엇이 그 선에 도달하게 만들었는지(예: 잘못된 재시도 로직(bad retry logic), 함수 내 과도한 컨텍스트(too much context in function), 캐시 히트 누락(missing cache hit), 부적절한 모델 라우팅(poor model routing))를 보여줍니다.

벤더 대시보드는 국소적인 질문에만 답합니다

도구 대시보드는 그것이 유일한 기록이 되기 전까지만 유용합니다.

Claude Code는 /usage에서 로컬 사용 통계를 제공하며, Anthropic의 비용 가이드는 팀 지출 한도, 컨텍스트 압축(context compaction), 모델 선택, MCP 오버헤드 감소, 훅(hooks), 스킬(skills), 그리고 서브 에이전트 위임(subagent delegation)을 다룹니다. Claude Code를 위한 정교한 운영 인터페이스(Fine operator surface)입니다. 하지만 이는 Claude Code, Codex, Copilot의 리뷰 컨텍스트, 그리고 Cursor가 모두 해당 코드를 건드린 후, 하나의 PR(Pull Request)에 비용이 얼마나 들었는지는 팀에게 알려주지 못합니다.

Codex 트레이싱 (tracing) 로그를 위한 LangSmith Codex 트레이싱 기능: 에이전트 턴 (agent turns), 모델 메타데이터 (model metadata), 토큰 사용량 (token usage), 도구 호출 (tool calls), 그리고 서브에이전트 스레드 (subagent threads). OpenCode 트레이싱 (OpenCode tracing) 로그: 세션 루트 실행 (session root runs), 어시스턴트 턴 (assistant turns), 중첩된 도구 호출 (nested tool calls), 도구 오류 (tool errors), 시간, 첨부 파일 (attachments), 서브에이전트 활동 (subagent activity), 토큰 사용량 (token usage), 그리고 루트 및 자식 세션에 대한 스레드 또는 세션 ID 메타데이터 (thread or session ID metadata). Copilot의 채팅 (Chat) 기능은 invoke_agent, chat, execute_tool 스팬 (spans)에 총 토큰 사용량, 모델 데이터, 그리고 도구 실행을 통해 전파되는 서브에이전트 컨텍스트 (subagent context)를 포함하는 OpenTelemetry 스팬을 내보낸다는 점에 유의하세요. LangSmith의 Codex를 위한 Codex 트레이싱 기능 플러그인: LangSmith의 Codex 트레이싱 플러그인 (LangSmith's Codex tracing plugin). Copilot Chat 또한 OpenTelemetry 스팬을 내보낼 수 있습니다: Copilot Chat은 OpenTelemetry 스팬을 내보낼 수 있습니다 (Copilot Chat can export OpenTelemetry spans).

더 중요한 것은, 개별 도구의 출력이 세션마다 서로 상당히 다를 수 있는 반면, 더 큰 생태계가 트레이스(trace)와 유사한 증거를 생성하기 시작했다는 점입니다. 대시보드와 달리, 이것은 모든 개별 도구뿐만 아니라 그 사이의 모든 중간 기능들을 완전히 활용하는 전체 코딩 세션의 정규화된 로그 (normalized log)가 될 것입니다.

[

]

트레이스 (trace)가 비용 단위인 이유는 그것이 행동 (behavior), 정체성 (identity), 그리고 지출 (spend)을 결합하기 때문입니다.

LangSmith의 코딩 에이전트 메타데이터 계약 (coding-agent metadata contract)은 관측성 (observability)에 의존하여 필드를 발견하는 대신, 공유 필드들을 이름으로 나열합니다. ls_agent_kind, ls_integration, ls_agent_runtime, thread_id, 그리고 ls_trace_schema_version과 같은 글로벌 정체성 (identity) 필드 외에도, 이 계약은 실행 유형 (run types)인 root, llm, tool, subagent, interrupted를 나열합니다. 또한 런타임 (runtime)이 노출할 수 있는 리포지토리 (repo) 필드인 repo, branch, commit, working_directory, provider, model, tool, subagent를 나열합니다.

그 계약은 정확히 올바른 방식으로 지루합니다. 지루한 필드들이 비용을 쿼리 (query) 가능하게 만듭니다. 지루한 필드 덕분에 엔지니어링 매니저 (engineering manager)가 어젯밤 어떤 리포지토리가 비용을 소모했는지, 어떤 에이전트 런타임이 그랬는지, 어떤 모델이 선택되었는지, 어떤 도구가 실패했는지, 그리고 어떤 팀이 해당 패턴의 소유자인지를 물어볼 수 있게 됩니다.

비용 (spend)에 대해서도 마찬가지입니다. 에이전트 관측성 (Agent observability)은 안정적인 대화 또는 세션 ID (conversation or session ID)를 기반으로 실행됩니다. 왜냐하면 해당 ID가 트레이스 (trace), 도구 (tool), 큐 (queue), API, 평가 (eval), 그리고 인시던트 (incident)를 정렬할 수 있게 해주기 때문입니다. 비용 또한 인과 관계 (causality) 없이 개별 항목으로 나타나는 것이 아니라, 동일한 척추 (spine)를 따라 정렬되어야 합니다.

행동 없는 비용은 회계에 불과하다

행동 (behavior)을 지목할 수 없는 비용 보고서는 그저 차트가 더 나은 회계 (accounting)일 뿐입니다.

제가 매우 상세하게 보고되기를 바라는 한 가지는, 코딩 에이전트 세션이 예산을 초과할 수 있는 모든 방법들입니다. 해당 보고서는 각 원인과 해결책에 대한 단순한 목록이 될 수 있습니다. 각 원인에 대한 수치는 해당 영역의 연기 (smoke)가 될 것이며, 그 방 안에서의 세션 트레이스 (trace)를 통해 추가 비용이 어디에서 발생했는지 보여줄 것입니다.

LLM 비용 관리 (LLM cost management)는 단순한 재무적 문제가 아니라 행동의 문제입니다. 무관한 것들을 쳐내십시오. 단순한 작업은 더 저렴한 모델 (cheaper models)이 수행하도록 해야 합니다. 변하지 않는 것들은 캐싱 (Cache) 하십시오. 특정 작업에 어떤 도구 (tool)를 사용할지 결정하십시오. 특정 작업에서 에이전트 (agent)를 실패하게 만드는 문서를 수정하십시오. 특정 작업을 위해 동일한 파일을 읽고 다시 읽는 서브 에이전트 (subagent) 경로를 다듬으십시오. 이것이 바로 이를 위한 예산에 대한 재무 시스템의 승인입니다. 여기 그 승인된 예산에 대한 트레이스 (trace)가 있습니다.

에이전트 플랫폼의 고객들에게는 에이전트에 대한 지출을 엔지니어링 결과 (engineering outcomes)와 연결하는 것이 중요합니다. 지출 대시보드 (spend dashboard)는 그 지출을 결과와 연결할 수 없다면 큰 효용이 없습니다. 예를 들어, 에이전트가 팀의 속도를 높였는지, 유용한 PR (Pull Request)을 생성했는지, 팀의 검토 업무를 줄여주었는지, 장애 (incident) 발생이 늘었는지 줄었는지, 혹은 다음번에는 밤샘 세션 (runaway-until-breakfast sessions)을 멈출 수 있는지와 같은 결과 말입니다. 단순히 스크린샷을 찍는 것이 아니라 실행 기록 (run record)을 구축하는 것만이 그곳에 도달할 수 있는 유일한 방법입니다.

게이트웨이 정책 (Gateway policy)이 루프를 완성합니다

제어 경계 (control boundary)가 없는 가시성 (visibility)은 월말의 후회로 변합니다.

LangChain의 내부 LLM 게이트웨이 (LLM Gateway) 도입은 흥미로운 사례인데, 이 회사가 지출을 실시간 제어와 연결했기 때문입니다. 그들의 writeup에 따르면, 한 헤비 코딩 에이전트 사용자가 아무도 알아차리기 전에 주당 수천 달러를 소비할 수도 있었습니다. 코딩 에이전트 호출을 게이트웨이 (Gateway)를 통하게 함으로써, 그들은 월간, 주간, 일간, 시간 단위의 예산을 설정한 다음, 지출을 트레이스 (traces), 사용자 (users), 키 (keys), 에이전트 (agents), 모델 호출 (model calls), 그리고 실패 모드 (failure modes)와 연결했습니다. 이것이 올바른 순서입니다: 실행을 확인하고, 행동을 수정하며, 경계를 제한하는 것입니다.

이것이 전면에 위치하는 Gateway에 대한 문서입니다: LLM Gateway는 에이전트/클라이언트와 모델 제공자(model providers) 사이에 위치합니다. 이 게이트웨이는 다양한 제공자를 위한 비밀 키(secrets)를 보유하고, LangSmith API 키로 호출자를 인증하며, 해당 호출자에 대한 비용(spend) 및 레드액션(redaction) 정책을 평가하고, 요청을 상위 모델 제공자에게 프록시(proxy)하며, 반환된 결과를 LangSmith로 트레이스(trace)합니다. 여기서 비용 정책(Spend policies)은 조직(organization), 워크스페이스(workspace), API 키, 또는 사용자에 따라 구성되며, 월간, 주간, 일간 또는 시간 단위로 제한할 수 있습니다. 요청이 차단되면(즉, 예산을 초과하는 경우), 발행된 요청에 대한 비용 정책 위반 사항을 트레이스 메타데이터(trace metadata)로 포함하여 402 에러를 반환합니다. Gateway 문서(Gateway docs)

여기서 중요한 제품 결정은 정책 위반을 단순히 차단된 금융 이벤트(finance events)로 처리하는 대신, 트레이스 이벤트(trace events)로 만드는 것이었습니다. 차단(block) 자체가 프롬프트(prompt), 모델 호출(model call), 도구 결과(tool results), 리포지토리 메타데이터(repo metadata), 그리고 에이전트 런타임(agent runtime)과 동일한 증거 스트림(evidence stream)의 일부이기 때문입니다.

비용 제어는 트레이스(trace)가 정책 경계(policy boundary)에 피드(feed)될 때 작동합니다.

이것이 바로 지출 권한이 런타임으로 이동하는(spending authority moves into the runtime) 지점입니다. 코딩 에이전트는 개인, 팀, 리포지토리 및 작업을 대신하여 공유 예산을 사용합니다. 따라서 정책은 승인(approvals), 예산 상한(budget caps), 제공자 자격 증명(provider credentials), 레드액션(redaction), 트레이스 메타데이터(trace metadata), 그리고 이슈 생성(issue creation)과 같이 해당 동작 근처에 위치해야 합니다.

단순히 월간 한도(monthly limit)를 설정하는 것만으로는 충분하지 않습니다. 예를 들어, 밤새 실행되는 단일 명령(single command)에 대해 시간당(hourly) 및 일일(daily) 한도도 고려해야 합니다. 팀이 예산을 책정하지 못한 통합 경로(integration paths)를 통한 오용을 방지하기 위한 사용자/API 키(User / API-key) 한도가 필요합니다. 라이브 환경(live environments)에서의 실험이 통제 불능 상태가 되는 것을 막기 위한 워크스페이스(Workspace) 한도도 필요합니다. 그리고 마지막으로, 이 모든 것에 상한선을 두기 위한 조직 수준(organization level)의 캡(caps)이 필요하며, 이러한 각각의 한도는 소유권(ownership)을 정의하는 서로 다른 방식을 나타냅니다.

첫 번째 버전은 단순할 수 있습니다

첫 번째 버전은 거창한 플랫폼 마이그레이션(platform migration)을 요구하지 않습니다.