AI 비용 관리의 새로운 경제학

지난 2년 동안 엔터프라이즈 AI 도입의 핵심은 사람들에게 AI를 사용하게 만드는 것이었습니다. 하지만 최근 몇 달 동안 이러한 상황은 여러 기업에서 급격히 변하고 있습니다. 한때 토큰 사용량으로 성공을 측정하던 AI 관측성(observability)은 이제 투자 대비 수익(ROI)으로 성공을 측정하기 시작했으며, 비용 관리를 먼저 해결하는 엔터프라이즈만이 지출이 매출을 넘어서지 않고 AI를 확장할 수 있습니다.

AI 비용 관리의 핵심은 모델, 에이전트, 애플리케이션, 팀 전반에서 AI 지출을 측정, 귀속, 제어 및 최적화하는 관행입니다. 목표는 단순히 토큰을 덜 사용하는 것이 아니라, 지출하는 1달러당 창출되는 비즈니스 가치를 극대화하는 것입니다. AI 에이전트가 더 많은 자율적인 작업을 수행함에 따라, 이러한 관행은 에이전트 추론, 툴 호출, 그리고 이들을 구동하는 모델의 비용 관리로 점차 확장되고 있습니다.

Databricks의 Senior Staff Engineer이자 Unity Gateway의 Technical Lead인 Kevin Stumpf와 함께 팀이 이러한 관행을 실제로 어떻게 적용해야 하는지 이야기해 보았습니다. AI 비용을 최소화해야 할 단순한 항목이 아니라 관리해야 할 시스템으로 다루는 방법에 대한 이야기입니다.

토큰맥싱(tokenmaxxing)에서 가치맥싱(valuemaxxing)으로

소셜 미디어에서는 AI를 가능한 한 많이, 자주 실행하는 "토큰맥싱"이 혁신을 가속화하는 올바른 방법이라고 주장하는 리더들의 글을 쉽게 볼 수 있습니다. 명백한 비용적 영향 외에도, 왜 이것이 AI 도입에 대한 잘못된 접근 방식일까요?

Kevin Stumpf: 업계는 토큰맥싱에서 가치맥싱으로 이동하고 있습니다. 초기에는 사람들이 얼마나 많은 토큰을 소진하고 있는지 보여주는 공개 순위표(leaderboard)가 있었고, 당시에는 그것이 전략으로서 의미가 있었습니다. 많은 사람들이 AI 사용을 주저했기 때문에, 모두가 동경하는 리더들이 AI를 적극적으로 사용하고 있음을 보여주는 것은 다른 사람들에게 동기를 부여했습니다. 존경하는 사람이 AI를 엄청나게 사용하는 것을 보면, 나도 그 사람처럼 되고 싶어지니까요.

하지만 시스템이 악용되었습니다. 순위표 상단에 오르는 것이 일종의 지위의 상징이 되자, 사람들은 거기에 도달하는 가장 빠른 방법이 좋은 성과가 아니라 사용량이라는 것을 깨달았습니다. 루프 속에서 실행되는 단순한 에이전트를 띄워 두고 날씨가 어떤지 반복해서 물어보게 하면서 사실상 아무것도 하지 않고 토큰을 소진하는 식이었죠. 이는 결과 대신 단순한 사용량에 보상을 주는 인센티브 구조가 초래한 예견된 결과였습니다.

이제 조직들이 AI 도입을 광범위하게 받아들이면서 대화의 중심은 책임감 있고 효과적인 사용으로 이동했습니다. 우리가 실제로 구축해야 할 것은 AI로 창출한 영향력을 그것을 창출하는 데 들인 비용으로 나눈 값을 기준으로 사람들의 순위를 매기는 새로운 종류의 순위표입니다. 그것이 바로 투자 대비 수익(ROI)이며, 단순한 토큰 수보다 정량화하기 훨씬 어렵지만 실제로 중요한 숫자입니다. 관련 내용: 엔터프라이즈 AI 도입을 이끄는 요인은 무엇인가?

실제적인 비용 귀속의 의미

AI에서 "비용 귀속(cost attribution)"이 실제로 무엇을 의미하는지 설명해 주시겠습니까?

Kevin Stumpf: AI 비용 귀속은 궁극적으로 지출이 어디서 발생하는지, 그리고 그 지출로 무엇을 얻었는지라는 두 가지 질문에 답하는 것입니다. 가장 단순한 수준에서는 데이터 사이언스 팀이나 소프트웨어 엔지니어링 팀과 같은 개별 사용자 또는 팀에 비용을 귀속시키는 것을 의미합니다. 또한 특정 프로젝트나 조직도의 노드에 매핑할 수도 있습니다. 예를 들어 AI VP 산하와 엔지니어링 SVP 산하에서 지출이 얼마나 발생하는지 파악하는 식입니다.

목표는 데이터를 다각도로 분석하여 비용이 실제로 어디서 발생하는지 이해할 수 있을 만큼 세밀한 가시성을 확보하는 것입니다. 측정할 수 없는 것은 관리할 수 없기 때문입니다. Databricks는 사용자, 그룹, 에이전트, AI 게이트웨이 엔드포인트, 모델, 제공업체 및 기간별로 기본 제공되는 비용 귀속 기능을 제공합니다. 하지만 조직은 요청 수준의 태그를 사용하여 이를 고도로 맞춤화할 수도 있습니다. 태그는 특정 풀 리퀘스트(pull request), 기능, 외부 고객 등 조직이 중요하게 생각하는 모든 것을 나타낼 수 있으며, 모든 요청에 해당 태그가 포함되면 필요한 방식대로 지출을 집계할 수 있습니다.

이러한 고객의 인식 변화는 실제로 일어나고 있습니다. 6개월 전만 해도 가장 큰 우려는 AI 도입에서 뒤처지는 것이었습니다. 하지만 지금은 그 반대입니다. AI가 사소한 일에 사용되는 경우가 많고, 비용이 매출보다 빠르게 증가함에 따라 리더들은 비용이 수익성을 침해하기 전에 비용 곡선을 어떻게 낮출 것인지 묻고 있습니다. 이는 가상의 상황이 아닙니다. Databricks 내부를 포함하여 우리가 만나는 거의 모든 조직의 이사회 수준에서 논의되는 주제입니다.

컨텍스트 부풀리기(Context Bloat) 다스리기

토큰 사용량과 컨텍스트 윈도우 크기가 자주 비판받지만 제대로 설명되는 경우는 드뭅니다. 프로덕션 시스템에서 컨텍스트 부풀리기(context bloat)는 실제로 어떤 모습이며, 실용적인 해결책은 무엇인가요?

Kevin Stumpf: 컨텍스트 부풀리기는 에이전트가 적절한 결정을 내리는 데 필요한 것보다 훨씬 더 많은 정보를 던져주는 것을 의미합니다. 이는 두 가지 이유로 문제가 됩니다. 첫째, 불필요한 토큰을 소진합니다. 둘째, 주의를 산만하게 만듭니다. 에이전트는 해당 추가 정보를 처리하고 관련성이 있는지 판단해야 하는데, 이 자체가 일종의 오버헤드입니다. 이는 사람에게 관련 없는 서류 더미를 건네고 작업을 시작하기도 전에 중요한 내용을 파악하라고 요구하는 것과 다를 바 없습니다.

가장 좋은 해결책은 사후에 다듬거나 캐싱하는 것이 아니라, 처음부터 부풀리기를 생성하지 않는 것입니다. 일반적이고 효과적인 패턴은 필요한 모든 것을 사전에 선제적으로 푸시하는 대신, 툴, MCP 서버 또는 스킬을 통해 에이전트가 필요에 따라 관련 컨텍스트를 가져오도록 하는 것입니다. 수행할 작업에 정말 중요하다는 확신이 90% 이상일 때만 기본적으로 에이전트에 컨텍스트를 푸시해야 합니다. 그렇지 않다면 에이전트에게 어떤 것을 사용할 수 있는지 알려주고, 필요할 때 필요한 것을 가져오도록 하는 것이 좋습니다.

동적 모델 및 하네스 라우팅

모델 선택은 종종 "한 번 선택하면 끝나는" 결정입니다. 왜 대신 동적으로 이루어져야 하며, 지능형 라우팅은 작업에 프론티어 모델이 필요한지 아니면 더 저렴하고 빠른 모델이 필요한지를 실시간으로 어떻게 결정하나요? 동일한 개념이 다양한 에이전트 하네스 선택에도 적용되나요?

Kevin Stumpf: AI 비용 최적화는 항상 가장 저렴한 모델을 선택하는 것이 아니며, 팀은 작업에 필요한 품질을 제공할 수 있는 가장 저렴한 모델이나 하네스를 선택하는 방식으로 전환해야 합니다. 현재의 현실은 프론티어 모델이 매우 뛰어난 성능을 발휘하지만 비용이 많이 드는 반면, 비프론티어 모델은 여전히 성능이 뛰어나면서도 비용이 저렴하다는 점입니다. 실제로 프론티어 모델이 필요한 작업은 전체의 약 5~10%에 불과합니다. 최고 수준의 결과가 필요할 만큼 걸려 있는 것이 크거나, 다른 모델로는 해결할 수 없을 정도로 문제가 복잡하기 때문입니다. 나머지 90%의 작업은 직접 호스팅하는 오픈 소스 모델이든 주요 연구소의 더 저렴한 모델 제품군이든 더 작은 모델로 해결할 수 있습니다.

자체적인 동기에 맡겨두면 대부분의 직원은 사용할 수 있는 가장 비싼 모델을 기본으로 선택할 것입니다. 이들의 목표는 단지 문제를 해결하는 것이며, 개인적으로 드는 비용을 감시하는 사람이 없기 때문입니다. 스마트 라우팅(Smart Routing)은 실시간으로 작업 복잡성을 평가하고 요청을 프론티어 모델로 보낼지 또는 더 저렴한 모델로 보낼지 결정하는 레이어를 삽입하여, 더 적은 비용으로 동일한 품질의 결과물을 유지하는 것을 목표로 이 문제를 해결합니다.

하네스(Harness) 라우팅은 모델 라우팅을 넘어선 다음 단계입니다. 정확히 동일한 모델이라도 다른 하네스를 통해 실행하면 비용이 유의미하게 달라질 수 있다는 연구 결과가 새로 나오고 있습니다. 이는 당연한 결과입니다. 하네스가 모델이 환경과 상호작용하는 방식, 즉 준수하는 규칙, 컨텍스트 윈도우를 압축하는 시점, 동작을 제어하는 비즈니스 로직을 결정하기 때문입니다. 이 모든 것이 소진되는 토큰 수에 직접적인 영향을 미칩니다. 하네스 라우팅은 Unity Gateway와 메타 하네스인 Omnigent를 통해 제공되는 비용 최적화 진화 단계(기어가기-걷기-뛰기)의 다음 단계입니다.

지출 가드레일 설계

하드 캡(hard caps), 예산, 속도 제한(rate limits)과 같은 지출 가드레일 자체에 대해 이야기해 보겠습니다. 개발자의 생산성을 해치거나 프로덕션 워크플로를 중단하지 않으면서 걷잡을 수 없이 증가하는 비용을 막으려면 이러한 가드레일을 어떻게 설계해야 할까요?

Kevin Stumpf: 모든 조직에 적용되는 규칙도 있고, 유스케이스나 회사에 따라 달라지는 규칙도 있습니다. 통제 불능 상태의 사용을 방지하려면 누구나 하드 스펜드 캡(hard spend cap)을 설정해야 합니다. 일반적인 파워 유저가 AI에 하루 최대 300달러 정도를 지출한다면 하드 캡을 그보다 약간 높은 500달러 정도로 설정하세요. 이러한 여유는 실수로 루프에서 계속 실행되도록 방치된 에이전트와 같은 실제 오류를 적절히 차단하면서도, 정당하게 사용량이 많은 날의 사용을 제한하지 않는 공간을 제공합니다.

이러한 기준선 외에도 팀이나 프로젝트별로 차등화된 예산을 적용하는 것이 매우 합리적입니다. CEO에게 중요한 작업을 수행하는 팀은 우선순위가 낮은 작업을 수행하는 팀보다 훨씬 더 높은 예산을 받을 자격이 있을 수 있으며, 이러한 결정은 팀에 더 많은 여유 공간을 부여하는 비용 대비 팀이 창출하는 가치를 따져보고 이루어져야 합니다.

예산 설정은 단순한 강제 중단(hard stop)에 그치지 않고 다양한 형태의 대응을 트리거할 수 있어야 합니다. 예를 들어 알림을 보내거나, 엄격한 한도(hard cap)를 적용하거나, 사용할 수 있는 모델 용량을 줄일 수 있습니다. 팀이 예산의 70%를 소진하면 프론티어 모델에 대한 기본 액세스를 차단하고 나머지 요청을 오픈소스 모델로 라우팅하는 식입니다. 어디에나 적용되는 핵심 원칙은 통제되지 않는 지출을 방지하고, 그룹이나 프로젝트별로 차등화된 한도를 설정하며, 한도를 적용하기 전에 알림을 주고, 갑작스러운 차단 대신 지능적인 용량 축소 메커니즘을 구축하는 것입니다.

AI가 실제로 창출하는 가치 측정하기

에이전트 모니터링과 비용 추적 기능을 함께 제공하는 플랫폼은 무엇이며, 이러한 가시성을 통해 단순한 지출 추적을 넘어 실제 ROI를 측정하는 데 얼마나 도달할 수 있을까요?

Kevin Stumpf: 비용을 측정하는 것은 그 비용을 투자 대비 수익(ROI)과 연결하는 것보다 훨씬 쉽습니다. 이는 모두가 답을 얻고 싶어 하지만 아직 완벽하게 해결한 곳이 거의 없는 질문이기도 합니다. 세션 또는 요청 수준의 태깅을 통해 이를 구현할 수 있습니다. 에이전트가 특정 풀 리퀘스트(pull request) 작업을 수행 중이라면, 해당 세션이나 생성하는 특정 요청에 해당 풀 리퀘스트 식별자를 태그로 지정할 수 있습니다. 이러한 귀속 정보가 비용 대시보드로 전달되어, 예를 들어 특정 풀 리퀘스트를 완료하는 데 300달러가 들었음을 확인할 수 있습니다. 이는 Databricks 내부에서 이미 시행하고 있는 방식입니다.

이상적인 형태이자 우리가 Unity Gateway 제품에 구축하고 있는 기능은 여기서 한 단계 더 나아가는 것입니다. 풀 리퀘스트를 특정 기능과 연결하고, 해당 기능을 특정 기간 동안 창출한 매출이나 파이프라인 같은 측정 가능한 성과와 연결하는 것이죠. 이것이야말로 궁극적인 목표입니다. 단순히 AI에 얼마가 들었는지 아는 것에 그치지 않고, 그로 인해 무엇을 얻었는지 파악하는 것입니다. Unity Gateway를 통해 우리는 이미 이를 구축할 수 있는 유연한 맞춤형 플랫폼을 갖추고 있으며, 팀이 직접 구축할 필요 없이 비용 대 수익 관점을 기본 제공(out of the box) 기능으로 활용할 수 있도록 투자하고 있습니다.

지출 가시성을 위해 필요한 중앙 집중식 시스템

여러 팀에 걸쳐 다양한 모델, 에이전트, 도구를 운영하는 기업의 경우, 적절한 지출 가시성을 확보하려면 실제로 무엇이 필요할까요? 이것은 대시보드의 문제일까요, 거버넌스의 문제일까요, 아니면 FinOps의 문제일까요?

Kevin Stumpf: 명확한 지출 가시성을 확보하려면 모든 AI 상호작용이 중앙 집중식 시스템을 거쳐야 합니다. 그래야 올바른 정보를 일관되게 확보하여 그 위에 신뢰할 수 있는 대시보드와 알림을 구축할 수 있기 때문입니다. AI 게이트웨이는 모델, 에이전트, 도구 및 팀 전체의 AI 비용 관리를 위한 중앙 제어 포인트를 제공합니다. Databricks Unity Gateway는 모델, 에이전트, 도구 및 코딩 에이전트에 걸쳐 이러한 중앙 제어 포인트를 제공하도록 설계되었습니다. AI 상호작용이 공통 제어 포인트를 거치게 되면 조직은 한곳에서 사용량을 모니터링하고, 비용을 할당하며, 예산을 집행하고, 지출을 최적화할 수 있습니다.

하지만 중앙 집중식 시스템을 갖추는 것만으로는 충분하지 않습니다. 모든 구성원이 실제로 해당 시스템을 통해 AI 트래픽을 라우팅하도록 강제할 방법도 필요합니다. 가시성은 선택 사항이 아니라 모든 구성원이 적용할 때만 효과를 발휘합니다.

비용 최적화와 결과물 품질의 균형 잡기

비용 통제가 품질이나 신뢰성을 희생하면서 이루어져서는 안 됩니다. 최적화가 지나쳐 결과물에 악영향을 미치기 시작하는 시점을 어떻게 알 수 있을까요?

Kevin Stumpf: 이는 전적으로 유스케이스에 따라 다릅니다. 주관적이든 객관적이든 피드백 메커니즘이 필요합니다. 주관적 피드백은 팀원 중 누군가가 현재 예산으로는 업무를 마칠 수 없다고 말하는 식의 개별적인 이야기입니다. 신속하게 얻을 수 있지만 한 사람의 불만으로 치부되기 쉽습니다. 객관적 피드백은 자동화된 평가에서 나오는데, 구축하기는 더 어렵지만 훨씬 더 신뢰할 수 있습니다.

코딩 에이전트와 같은 일반적인 유스케이스의 경우, 2주 이내에 롤백되지 않고 병합(merge)된 풀 리퀘스트의 비율처럼 품질을 나타내는 대리 지표(proxy metric)를 정의할 수 있습니다. 거기서부터 실험을 진행할 수 있습니다. 예산을 절반으로 줄이고 주요 핵심 지표가 변하는지, 유지되는지, 혹은 제약이 창의성을 낳듯 오히려 개선되는지 확인하는 것입니다. 서로 다른 예산, 모델, 하네스를 사용하는 여러 팀에 걸쳐 병렬 실험을 실행하거나 몇 주간의 기간 한정 비교를 실시하면, 추측에 의존하지 않고 특정 예산이 가치를 창출하는지 아니면 손상시키고 있는지 파악할 수 있습니다.

엔드 투 엔드 추적의 가치

여기서 엔드 투 엔드 추적 및 모니터링은 어떤 역할을 하나요? 전체 에이전트 워크플로에 걸쳐 프롬프트, 도구 호출, 토큰 사용량을 확인할 수 있게 되면 이전에는 할 수 없었던 어떤 일이 가능해질까요?

Kevin Stumpf: 추적은 에이전트가 수행하는 모든 작업의 부산물(exhaust)을 수집하는 것입니다. 에이전트가 어떤 생각을 하는지, 어떤 도구를 호출하는지, 어떤 데이터를 가져오는지, 프롬프트가 좋은지 나쁜지 등을 파악하는 것이죠. 이러한 원시 데이터(raw data)는 남용, 낭비, 보안 누출, 또는 이전에는 찾을 생각조차 못 했던 패턴을 파악하는 등 인사이트를 발굴하는 데 활용할 수 있습니다.

이는 데이터 산업 전반에서 일어난 변화와 유사합니다. 초기에는 데이터베이스의 정제된 정형 데이터만 다루었습니다. 이후 데이터 레이크가 등장했지만, 가치를 추출할 방법 없이 비정형 데이터를 쏟아붓는 바람에 한동안 데이터 늪(data swamp)으로 전락하기도 했습니다. 결국 이러한 늪은 다시 유용한 데이터 레이크로 발전했고, 현재는 LLM이 비정형 및 반정형 데이터를 처리할 수 있을 만큼 유연해진 덕분에 그 어느 때보다 가치 있는 인사이트를 잘 추출할 수 있게 되었습니다. 에이전트 추적 데이터도 동일한 범주에 속합니다. 수집하는 데이터가 많을수록 더 많은 인사이트를 얻을 수 있으며, 이에 접근하는 것도 그 어느 때보다 쉬워졌습니다.

에이전트 플릿(fleet) 단위로의 확장

많은 기업이 단일 AI 애플리케이션에서 에이전트 플릿(fleets of agents)으로 이동하고 있습니다. 단일 애플리케이션 뒤에서 하나의 모델을 운영하는 것에 비해 이러한 전환이 비용 방정식(새로운 비용 동인, 새로운 사각지대 등)을 변화시키나요?

Kevin Stumpf: 비용 방정식을 바꾼다기보다는 몇 배로 증폭시킨다고 보는 것이 맞습니다. 에이전트 스웜(swarm)이 새로운 현실이 될 것이며, 이들 에이전트 하나하나가 비용 할당, 모니터링 및 관리가 필요한 토큰을 소비하게 될 것입니다. 운영 환경의 에이전트 수가 예상대로 증가하기 전에, 지금이야말로 적절한 비용 가시성과 관리 기반을 마련해야 할 때입니다.

현재는 코딩 에이전트가 토큰을 소비하는 주요 범주이지만, 앞으로는 24시간 내내 자율적인 작업을 수행하는 다양한 범주의 에이전트로 확장될 것입니다. 에이전트가 다른 에이전트를 호출하고, 또 다른 에이전트를 호출하는 방식이죠. 이러한 복잡성이 도래할 때까지 중앙 집중식 AI 관측 가능성(observability) 및 비용 관리 인프라 구축을 미루는 조직은 주도적으로 대응하지 못하고 압박 속에서 구축하게 될 것입니다.

내년을 준비하는 기업의 AI 리더들에게 비용 관리에 대한 한 가지 관점의 전환을 제안한다면 무엇을 전하고 싶으신가요?

Kevin Stumpf: 내년까지 기다리지 마시라고 말씀드리고 싶습니다. 이 일은 매우 시급하며 지금 당장 다루어야 합니다. 한 가지 아이디어로 요약하자면, '측정할 수 없으면 관리할 수 없다'는 것입니다. 이는 원자재에도 적용되고, 사람에게도 적용되며, AI에도 똑같이 적용됩니다. AI는 기업의 현금 흐름표에서 가장 중요한 항목 중 하나로 빠르게 자리 잡고 있으며, 이를 측정하고 결과적으로 관리할 수 있도록 모든 모니터링 체계(instrumentation)를 갖춰야 합니다. AI는 조직의 제품이나 서비스를 생산하는 시스템의 또 다른 원자재일 뿐이며, 동일한 규율을 적용해 관리해야 합니다.

지금 바로 시작해야 합니다 다양한 모델과 도구를 사용하는 여러 팀 전반에서 AI 비용을 통제하는 것은 단일 대시보드나 일회성 모델 선택으로 해결할 수 있는 문제가 아닙니다. 이는 지출을 개인이나 프로젝트 수준까지 추적할 수 있을 만큼 세분화된 비용 할당, 작업의 요구사항에 따라 실시간으로 적응하는 라우팅, 뉴스 헤드라인을 장식하기 전에 통제 불능 상태의 지출을 잡아내는 가드레일, 원시 사용량 데이터를 실제 인사이트로 전환할 수 있을 만큼 상세한 추적 기능과 같은 운영 규율에 해당합니다. 이에 앞서나가는 조직은 AI에 비용을 가장 적게 쓰는 조직이 아니라, 지출한 비용으로 무엇을 얻었는지 정확하게 자신 있게 말할 수 있는 조직입니다.

Unity Gateway가 어떻게 조직의 AI 환경 전체에서 비용 할당, 스마트 라우팅 및 지출 가드레일을 중앙 집중화하는지 자세히 알아보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)