AI 코딩비가 월 15만 달러까지 커졌다면 “어떤 모델을 많이 썼나”보다 먼저 물어야 할 게 있어요. 그 돈으로 약속한 로드맵의 무엇을 출시했느냐는 질문입니다.
먼저 숫자의 출처부터 분리할게요. 월 15만 달러는 Product Hunt 이용자가 Navigara에 질문하며 든 Claude 청구서 규모이지, 공개 자료로 검증된 Navigara 고객 사례는 아닙니다. 반면 Navigara가 공개한 제품 기능은 Git 기록, Jira·Linear, AI 지출을 연결해 로드맵 항목별 비용과 연결되지 않은 작업을 보여준다는 것입니다. 이 글은 15만 달러를 확정 사례가 아니라 큰 청구서를 어떻게 관리 회계 데이터로 바꿀지 설명하는 출발점으로 사용합니다.
모델별 청구서만 보면 정작 비싼 이유를 놓칩니다
모델별 비용은 구매 내역이지 성과 내역이 아닙니다. “Opus에 6만 달러, Sonnet에 5만 달러를 썼다”는 표로는 결제 개편이 비쌌는지, 장애 대응이 비쌌는지, 취소된 실험에 돈이 샜는지 알 수 없어요.
공급자 API가 제공하는 데이터도 대체로 이 경계에서 끝납니다. Anthropic의 Usage & Cost API는 사용량을 모델·워크스페이스·API 키 등으로 나누고 비용을 일 단위로 조회할 수 있습니다. OpenAI의 조직 API 역시 사용량과 비용을 조회하고 프로젝트 ID 등으로 묶을 수 있어요. 이 데이터는 청구서 대사에는 유용하지만, 그 프로젝트가 어느 제품 목표를 움직였는지는 알려주지 않습니다.
| 보는 단위 | 답할 수 있는 질문 | 답하지 못하는 질문 |
|---|---|---|
| 모델·토큰 | 어느 모델에서 비용이 발생했나? | 무엇을 출시했나? |
| 사용자·좌석 | 누가 도구를 사용했나? | 그 사용이 필요한 작업이었나? |
| PR·커밋 | 어떤 코드 변경과 연결됐나? | 고객이나 로드맵에 어떤 가치가 있었나? |
| 로드맵 항목 | 어느 목표에 얼마가 들었나? | 그 목표 자체가 옳았나? |
그래서 원가 단위는 모델이 아니라 이니셔티브·에픽·기능 같은 비용 객체여야 합니다. Navigara도 AI 지출을 이니셔티브, 프로젝트, 이슈, PR, 커밋으로 이어 붙이고 기능·유지보수·수정 등으로 분류한다고 설명합니다. 핵심 아이디어는 특정 제품을 사는 데 있지 않아요. 공급자 청구 데이터와 실제 출시 기록 사이에 추적 가능한 연결 고리를 만드는 데 있습니다.
정답은 ‘달러→세션→PR→이슈→목표’ 연결표입니다
로드맵 원가는 한 번에 계산되지 않습니다. 비용 이벤트가 어떤 작업 세션에서 생겼고, 그 세션이 만든 변경이 어떤 이슈와 목표에 속하는지 차례로 연결해야 해요.
자동 연결의 출발점은 작업 이름 규칙입니다. 에이전트를 실행할 때 이슈 키를 넣고, 브랜치를 ENG-2917-checkout처럼 만들며, PR 본문에 같은 키를 남기면 세 시스템의 조인이 가능해집니다. 직접 API 호출을 운영한다면 팀마다 워크스페이스나 프로젝트를 분리해 첫 번째 비용 경계를 만들 수 있어요. 다만 하나의 세션이 여러 이슈를 건드리거나 공유 좌석 비용이 섞이면 억지로 1원 단위까지 배분하지 말고 공통비로 남겨야 합니다.
GitHub Copilot도 조직·엔터프라이즈·저장소·사용자 범위의 사용 지표와 PR 생애주기 데이터를 내보낼 수 있습니다. 하지만 GitHub는 조직 수준 수치가 멤버십 기준으로 귀속돼 중복처럼 보일 수 있고, 서로 다른 Copilot API 자원을 직접 비교하면 안 된다고 안내합니다. 따라서 공급자 대시보드 숫자와 자체 원장을 먼저 월 청구 총액에 맞춰 대사한 뒤 세부 배분을 시작해야 합니다.
‘로드맵 미연결 = 낭비’로 자동 판정하면 안 됩니다.
긴급 장애 대응, 보안 패치, 리팩터링, 탐색 실험은 정당하지만 로드맵에 없을 수 있어요. Product Hunt에서 Navigara 창업자도 미연결 작업이 반드시 나쁜 것은 아니며 필요한 이유를 설명할 수 있어야 한다고 답했습니다. 미연결 비용은 낭비 확정액이 아니라 분류가 필요한 대기열로 다루는 게 맞습니다.
실무에선 비용을 네 묶음으로 나누면 판단이 쉬워집니다. 첫째는 출시된 로드맵 작업, 둘째는 승인된 유지보수·리스크 감소, 셋째는 공통 인프라와 좌석 같은 공유비, 넷째는 연결 근거가 없는 미분류 비용입니다. 마지막 묶음만 담당자가 검토해 취소된 실험, 중복 작업, 누락된 티켓으로 다시 나누세요.
원가표에는 금액과 함께 신뢰도·품질을 붙여야 합니다
로드맵별 달러 합계 하나만 만들면 또 다른 허영 지표가 됩니다. PR 수나 커밋 수가 늘었다고 가치가 같은 비율로 늘지는 않기 때문이에요. Navigara는 커밋을 LLM과 규칙으로 평가한 자체 단위 ETV를 분모로 제안하지만, 이는 회사가 정의한 독점 지표입니다. 공개 연구 보고서도 분석이 공개 저장소의 병합 커밋에 한정되고, 코드 리뷰·멘토링·사고 대응 같은 활동은 관찰하지 못하며, AI 도입과 성과 사이의 인과 비율을 산정하지 않는다고 명시합니다.
따라서 ETV든 자체 점수든 단일 숫자를 진실처럼 쓰지 마세요. DORA도 AI 도구를 평가할 때 기존 전달 지표와 함께 제안 수락률, 모델 품질, 신뢰, 리뷰 시간 같은 보완 지표를 조합하라고 권합니다. 로드맵 원가표에는 최소한 아래 세 축이 같이 있어야 합니다.
예를 들어 “결제 개편 AI 원가 2만 달러”보다 “직접 연결 1만4천 달러, 공통비 배분 4천 달러, 추정 2천 달러, 계획보다 2주 빠르게 출시, 배포 후 재작업 3건”이 훨씬 쓸 만한 보고입니다. 비용을 줄일지 결정할 때도 가장 비싼 모델부터 자르는 대신, 미분류율이 높고 재작업도 많은 작업 유형을 먼저 살펴볼 수 있으니까요.
이번 주에 로드맵 원가표 만드는 순서
1. 공급자 청구액을 하나의 원장으로 모으기
Anthropic은 조직용 /v1/organizations/cost_report와 사용량 보고서를, OpenAI는 /v1/organization/costs와 Usage API를 기준으로 가져오세요. API·Claude Enterprise·고정 좌석처럼 과금 방식이 다른 항목은 별도 열로 두고, 월말 합계가 실제 청구서와 맞는지 먼저 확인합니다.
2. 이슈 키를 모든 작업의 공통 식별자로 강제하기
Jira나 Linear에서 이니셔티브→에픽→이슈 계층을 정리하고, 에이전트 프롬프트·브랜치·커밋·PR 중 최소 두 곳에 이슈 키를 남기세요. 긴급 작업용 INC, 유지보수용 MAINT, 실험용 EXP 유형도 만들어 로드맵 밖의 정당한 작업이 미분류로 빠지지 않게 합니다.
3. 자동 배분과 추정 배분을 분리하기
세션 ID나 전용 워크스페이스로 직접 연결된 비용은 ‘확정’, 시간대·사용자·저장소만 맞아 추론한 비용은 ‘추정’, 좌석과 공용 인프라는 ‘공통비’로 표시하세요. 한 세션이 여러 이슈에 걸치면 변경 파일, 실행 시간 등 미리 합의한 기준으로 나누고 배분 규칙을 원장에 남깁니다.
4. 월간 리뷰에서 세 가지 질문만 하기
“어느 목표의 단위원가가 변했나?”, “미분류 비용은 왜 생겼나?”, “절감과 함께 재작업·장애·리뷰 시간도 줄었나?”를 확인하세요. 첫 달에는 정확한 ROI보다 직접 연결률을 높이는 데 집중하고, 개인별 순위를 성과평가에 사용하지 않습니다.
이렇게 만들면 월 15만 달러라는 숫자는 공포스러운 총액에서 의사결정 가능한 포트폴리오로 바뀝니다. 비싼 모델을 썼다는 사실보다, 어떤 로드맵 항목은 돈을 더 넣을 가치가 있고 어떤 작업 흐름은 연결과 품질부터 고쳐야 하는지가 보이기 시작해요.
