Stop counting tokens, start counting what ships

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

HPE는 AI 코딩의 경제성을 토큰 소비량보다 품질을 유지한 병합된 풀 리퀘스트당 비용으로 평가하고, 작업별 모델 배분과 수요에 맞는 하이브리드 추론 운영으로 개선하자고 제안한다.

📌 핵심 요약

• 코딩 에이전트는 계획·코드 생성·테스트·오류 수정의 반복으로 단순 채팅 프롬프트보다 작업당 10~50배 많은 토큰을 사용할 수 있다. Uber는 Claude Code 사용 확대 후 4월까지 2026년 AI 예산 전체를 소진한 것으로 보도됐고, GitHub Copilot은 정액제에서 사용량 기반 크레딧으로 전환했다. Gartner는 2028년 AI 코딩 토큰 비용이 개발자 평균 급여를 넘어설 것으로 예측한다.
• HPE는 일괄적인 사용 제한이 가치 있는 작업까지 억제할 수 있다고 지적하며, AI 지원 개발 총비용을 검토 후 병합된 변경 건수로 나눈 병합된 풀 리퀘스트당 비용을 제안한다. 재작업과 결함도 함께 추적해야 비용 절감이 품질 저하를 가리지 않는다.
• 어려운 계획과 새로운 추론에는 프런티어 모델 또는 정책상 필요한 온프레미스 플래그십 모델을 쓰고, 적합한 코드 생성·테스트 작성·반복 리팩터링은 자체 운영하는 오픈 웨이트 모델로 배분한다. 게이트웨이는 복잡성·데이터 민감도·비용·지연시간에 따라 요청을 라우팅하며, 모델은 자체 코드·테스트·수용 기준으로 검증해야 한다.
• 자체 보유 용량은 선투입 비용과 전력·운영·유지보수·감가상각을 고려해야 하지만, 지속적인 수요가 있으면 사용 증가에 따라 효율이 높아질 수 있다. 온프레미스에서는 독점 코드를 기업 내부에 유지하고 승인된 계획 프롬프트와 통제된 예외만 외부 모델로 보낼 수 있다. 사용량이 적거나 예측하기 어려우면 API가 유리하며, 원문은 다수 기업에 하이브리드 운영이 적합할 것으로 본다.
• HPE는 HPE Private Cloud AI 등을 활용해 150개가 넘는 내부 애플리케이션의 일상적 작업을 온프레미스 오픈 웨이트 모델로 보내 토큰 비용을 30~50% 줄였다고 밝힌다. 제시된 사용량 자료에서는 상위 5%가 소비 대부분을 차지했고, 동일 라이선스의 최다 사용자는 최소 사용자의 약 450배를 소비했으며, 고사용자 비중이 인력 절반으로 늘면 인원 증가 없이 월 지출이 약 4.4배가 될 수 있다. HPE는 활성 개발자당 비용과 병합된 풀 리퀘스트당 비용의 변경 전 기준선을 측정하고, 자체 보유 용량에서 전체 개발 주기를 실행해 사용 증가 시 두 지표가 개선되는지 비교할 것을 권한다.

🧩 주요 포인트

1. 소비량과 납품 성과의 분리 → 토큰 비용만으로는 낭비와 유용한 개발 작업을 구별하기 어려우므로, 병합된 풀 리퀘스트당 비용을 재작업·결함과 함께 해석해야 한다.
2. 작업별 모델 배분과 코드 통제 → 검증된 오픈 웨이트 모델이 반복 작업을 맡고 게이트웨이가 외부 전송을 통제하면, 필요한 고난도 추론에 프런티어 모델을 집중할 수 있다.
3. 지속적인 수요와 비용 구조의 결합 → 자체 보유 용량의 타당성은 라이선스 인원보다 실제 사용량과 제반 비용에 좌우되며, HPE의 토큰 비용 절감 사례만으로 전체 개발비 절감을 확정할 수는 없다.

🧠 상세 정리

1. 코딩 에이전트의 반복 작업이 키우는 비용

코딩 에이전트는 한 번 답하는 데 그치지 않고 계획을 세우고 코드를 생성하며 테스트와 오류 수정을 반복하므로, 단일 작업에 단순 채팅 프롬프트의 10~50배에 이르는 토큰을 사용할 수 있다. 유용성이 높아질수록 호출도 늘어나는 구조에서는 가치 있는 작업이 가장 비싼 작업이 될 수 있다. 원문은 Uber가 Claude Code 사용 확대 후 4월까지 2026년 AI 예산 전체를 소진했다는 보도와 GitHub Copilot의 정액제에서 사용량 기반 크레딧으로의 전환을 비용 압박의 사례로 든다. Gartner가 AI 코딩 토큰 비용이 2028년 개발자 평균 급여를 넘어설 것으로 예측한다는 내용도 제시한다. 다만 이 글은 HPE가 제작한 후원 콘텐츠이며, MIT Technology Review 편집진이 작성한 기사가 아니라는 점을 밝혀 두고 있다.

2. 토큰 소비 대신 병합된 소프트웨어 성과 측정

비용 압박에 대한 자연스러운 대응은 사용량 상한, 사용자 수 제한, 에이전트 실행 전 승인 절차지만, 원문은 일괄적인 제한이 가치를 만들어 내는 작업까지 억제할 수 있다고 지적한다. 토큰당 비용은 소비를 측정할 뿐이며, 재시도나 통제되지 않는 반복 실행에서 생기는 낭비와 소프트웨어를 완성하는 데 필요한 작업을 구별하지 못한다. 대안은 AI 지원 개발 총비용을 검토를 통과해 병합된 변경 건수로 나눈 병합된 풀 리퀘스트당 비용이다. 이때 재작업과 결함을 함께 추적해야 저렴해진 변경이 품질 저하를 감추는 일을 피할 수 있다. AI 사용이 늘어도 품질을 유지하면서 이 비용이 내려간다면, 소비 증가가 실제로 완성된 소프트웨어로 더 효율적으로 전환되고 있다고 해석할 수 있다.

3. 작업 난도에 맞춰 모델을 배분

원문은 에이전트의 모든 단계에 가장 강력한 모델이 필요한 것은 아니며, 어려운 계획과 새로운 추론에 프런티어 모델을 집중하자고 제안한다. 정책상 필요하면 온프레미스 플래그십 모델을 사용하고, 적합한 코드 생성·테스트 작성·반복 리팩터링은 자체 운영하는 오픈 웨이트 모델로 보낸다. 게이트웨이는 작업 복잡성, 데이터 민감도, 비용, 지연시간을 기준으로 요청을 배분해 비싼 추론이 필요한 순간에 비용을 집중하도록 한다. 일부 소프트웨어 공학 벤치마크에서는 선도적인 오픈 웨이트 모델이 특정 작업에서 프런티어 모델에 근접할 수 있다는 결과가 제시된다. 그러나 이것이 모든 저장소와 작업 흐름에서 동등한 성능을 뜻하지는 않으므로, 실제 운영 작업을 맡기기 전에 자체 코드·테스트·수용 기준으로 후보 모델을 평가해야 한다.

4. 반복 사용의 경제성과 민감 코드 통제

임대한 추론에서는 호출할 때마다 청구액이 늘지만, 자체 보유 용량은 비용 대부분이 미리 투입되므로 사용이 증가할수록 추가 호출의 비용이 낮아지는 구조라고 원문은 설명한다. 그렇다고 소유 비용이 사라지는 것은 아니며, 전력·운영·유지보수·감가상각을 포함한 병합된 풀 리퀘스트당 총비용을 계산해야 한다. 자체 보유 용량은 청구서에 직접 나타나지 않는 민감 코드 통제의 가치도 제공할 수 있다. 코드 생성과 테스트를 온프레미스에서 수행하면 독점 코드는 기업 내부에 남고, 승인된 계획 프롬프트와 통제된 예외만 조직이 관리하는 게이트웨이를 통해 외부 모델로 전달된다. 원문은 이런 방식이 보안 때문에 AI 도입이 막히던 민감한 저장소의 활용을 열 수 있으며, 그곳에 큰 개선 여지가 있다고 주장한다.

5. HPE 사례와 운영 모델 검증 기준

HPE는 HPE Private Cloud AI 등을 포함한 온프레미스 오픈 웨이트 모델로 150개가 넘는 내부 애플리케이션의 일상적 작업을 보내는 하이브리드 플랫폼을 운영하며, 토큰 비용이 30~50% 감소했다고 밝힌다. 제시된 자료에서는 상위 5%의 사용자가 소비 대부분을 차지하고, 같은 라이선스에서도 최다 사용자가 최소 사용자의 약 450배를 소비해 인원수만으로 지출을 설명하기 어렵다. 고사용자 비중이 소수에서 전체 인력의 절반으로 커지면 인원수가 같아도 월 지출이 약 4.4배로 늘 수 있지만, 조직별 사용자 구성은 다를 수 있다. HPE는 전체 라이선스 평균에 가려지는 사용량 차이를 보기 위해 활성 개발자당 비용을, 지출과 완성된 소프트웨어를 연결하기 위해 병합된 풀 리퀘스트당 비용을 추적한다. 인프라 변경 전 두 비용의 기준선을 측정하고 자체 보유 용량에서 전체 개발 주기를 실행한 뒤, 사용이 늘어도 두 지표가 개선되지 않으면 기존 모델이 더 나을 수 있다고 권고한다.

6. 수요에 맞는 하이브리드 운영의 조건

원문은 자체 보유 용량이 모든 조직에 적합하지는 않으며, 사용량이 적거나 예측하기 어려운 경우에는 유휴 인프라에 자본을 묶지 않는 API 방식이 유리하다고 인정한다. 자체 보유 방식의 경제성은 지속적인 수요가 설비를 충분히 활용할 때 성립한다. 이에 따라 다수 기업은 고난도 또는 간헐적 작업에는 프런티어 API를, 반복적인 대량 작업에는 자체 보유 용량을 쓰는 하이브리드 구성을 운영할 것으로 전망한다. 통제된 게이트웨이는 외부로 나가는 요청을 결정해 프런티어 모델 활용과 코드에 대한 주권을 함께 유지하도록 한다. 결론적으로 HPE는 코딩 에이전트 사용 증가를 제한하기보다, 그 증가가 더 큰 변동비 청구로 이어질지 자체 보유 용량에서 더 많은 소프트웨어를 완성하는 성과로 이어질지를 운영 모델 차원에서 판단해야 한다고 주장한다.

🧾 핵심 주장 / 시사점

• 핵심 판단 기준은 토큰을 얼마나 줄였는지가 아니라 품질을 유지하면서 병합된 풀 리퀘스트당 총비용이 낮아졌는지다. HPE가 제시한 토큰 비용 30~50% 감소만으로 이 기준의 충족 여부까지 확인되지는 않는다.
• 라이선스 인원이 같아도 사용량 분포가 달라지면 지출이 크게 변할 수 있으므로, 활성 개발자당 비용과 병합된 풀 리퀘스트당 비용은 서로 다른 측면을 설명하는 보완 지표다.
• 하이브리드 운영의 타당성은 오픈 웨이트 모델의 작업 적합성, 지속적인 수요, 외부로 보낼 수 있는 코드와 프롬프트의 범위를 함께 검토해야 판단할 수 있다.

✅ 액션 아이템

• 활성 개발자당 비용과 병합된 풀 리퀘스트당 비용의 변경 전 기준선을 측정하고, 자체 보유 용량에서 전체 개발 주기를 실행해 두 지표의 개선 여부를 비교한다.
• 오픈 웨이트 모델을 자체 코드·테스트·수용 기준으로 검증하고, 게이트웨이를 통한 작업 배분과 외부 전송 범위를 검토한다.
• 사용량의 지속성과 예측 가능성, 전력·운영·유지보수·감가상각을 반영해 API와 자체 보유 용량을 결합하는 하이브리드 운영의 경제성을 평가한다.

❓ 열린 질문

• AI 사용이 늘어날 때 재작업과 결함을 악화시키지 않으면서 병합된 풀 리퀘스트당 비용을 낮출 수 있는가?
• 오픈 웨이트 모델은 자체 코드·테스트·수용 기준에서 어떤 코드 생성·테스트 작성·반복 리팩터링을 맡을 수 있는가?
• 실제 사용량의 지속성과 전력·운영·유지보수·감가상각을 고려하면 자체 보유 용량은 API보다 유리한가?