AI 예산 낭비 방지: 워크플로우 내비게이터로 GPU 사용 및 모델 배포 최적화

Uber는 4월까지 2026년 AI 툴 예산을 모두 소진했습니다. Microsoft도 비슷한 위기를 겪으며 Claude Code가 지나치게 잘 작동해 사용량이 급증하자 Claude Code 라이센스를 회수했습니다. OpenAI의 최고 경영자(CEO) Sam Altman조차 회사와 고객에게 토큰 비용이 "심각한 문제"라고 언급했습니다. 비즈니스 성과와 명확한 연계되지 않은 작업에 토큰을 과도하게 사용하는 경향을 뜻하는 '토큰맥싱(Tokenmaxxing)'은 이제 사내 농담을 넘어 경영진이 주목해야 할 문제로 떠올랐습니다.

기업은 이러한 문제에 대응해 외부 AI 예산에 상한을 두고 라이센스를 회수하고 있습니다. 합리적으로 보이는 대응입니다. 하지만 이러한 비용 증가를 피하기 위해 자체 인프라에 모델을 배포하면 사용량 기반 과금 대신 또 다른 숨은 비용인 인프라 낭비가 발생합니다. 더 큰 문제는 대부분의 조직이 이 두 번째 비용 문제를 측정하는 방법조차 모르기 때문에 이를 제한하지 못하고 있다는 점입니다.

토큰 낭비에서 인프라 낭비로

놓치기 쉬운 부분이 있습니다. 지난 1년간 토큰당 비용은 최대 80%까지 하락했습니다. 좋은 소식처럼 들리고 실제로도 그렇습니다. 하지만 총지출을 보면 상황은 달라집니다. 총지출은 오히려 증가했습니다. AI가 계획, 툴 호출, 검증, 수정을 반복하는 에이전틱 워크플로우는 채팅 기반 상호작용과는 비교할 수 없을 정도로 많은 토큰을 소모합니다. Deloitte의 2026 TMT 전망에 따르면 추론 워크로드는 현재 전체 AI 컴퓨팅의 약 3분의 2를 차지하며 2023년의 약 3분의 1에서 많이 증가했습니다. 토큰 가격이 낮아졌다고 AI 비용까지 줄어든 것은 아닙니다. 오히려 더 많은 비용을 쓰기 쉬워졌습니다.

누군가 모델을 하나 선택합니다. 대체로 지난달 리더보드에서 상위권에 오른 모델이거나 동료가 Slack에 공유한 모델입니다. 팀은 이를 그래픽 처리 장치(GPU)에 배포합니다. 여러 구성을 벤치마킹할 시간이 없으므로 구성은 사실상 최선의 추정에 가깝습니다. 자동 스케일링은 지나치게 공격적이거나 지나치게 보수적이거나 아예 설정되어 있지 않습니다. 양자화 설정도 마지막으로 본 튜토리얼이나 블로그 포스트의 설정을 그대로 따르는 경우가 많습니다.

그러면 GPU가 가동되지만 대개 효율적이지 않습니다. 모델이 실제 태스크에 필요한 수준보다 훨씬 클 수 있고 실제로 발생하지 않는 최대 트래픽을 기준으로 배포 규모를 정해 하드웨어 활용도가 낮을 수도 있습니다.

이것이 바로 인프라 낭비입니다. API 비용처럼 별도의 항목으로 명확히 드러나지는 않지만 GPU 활용도와 관계없이 모델에 GPU가 배포되어 있는 동안 매일 비용이 누적됩니다. 자체 호스팅 모델을 배포하는 여러 조직에서 흔히 나타나는 패턴입니다.

자체 호스팅 배포에서 문제가 생기는 이유

대부분의 낭비는 두 가지 결정에서 비롯됩니다.

잘못된 모델 선택

수천 개의 오픈 웨이트 모델 중에서 기본적으로 가장 크고 가장 잘 알려진 모델을 선택하는 경우가 많습니다. 하지만 특정 태스크에서는 더 큰 모델이 항상 더 나은 것은 아닙니다. RouteLLM 프레임워크와 같은 초기 모델 라우팅 연구에 따르면 태스크에 맞는 크기의 모델을 배정하고 추출 및 분류에는 더 작은 모델을 사용하며 복잡한 추론에는 더 큰 모델을 사용하는 방식으로 대부분의 출력 품질을 유지하면서 총비용을 줄일 수 있습니다. 대부분의 팀은 이러한 비교를 직접 수행하지 않습니다. 리더보드, 벤치마크 논문, 하드웨어 사양서를 일일이 살펴보는 데 며칠이 걸릴 수 있고 결과도 매달 달라지기 때문입니다.

추측에 의존한 배포

모델을 선택한 후에는 누군가 서빙 런타임, GPU 할당, 양자화 수준, 자동 스케일링 매개변수를 구성해야 합니다. 사용하는 하드웨어와 트래픽 패턴에 맞는 성능 데이터가 없으면 참조 구성조차 추측에 의존할 수밖에 없습니다. 구성을 지나치게 높게 설정하면 컴퓨팅 리소스가 낭비될 수 있고 너무 낮게 설정하면 대기 시간 문제가 발생할 수 있습니다. 어느 쪽이든 팀은 예산 낭비나 사용자 경험 저하라는 대가를 치르게 됩니다.

이 두 가지 결정을 모두 제대로 내릴 수 있는 사람은 드뭅니다. 대부분의 팀에는 모델, 하드웨어 프로필, 트래픽 패턴을 보고 적절한 답을 바로 판단할 수 있는 사람이 없습니다.

워크플로우 내비게이터로 배포 시 추측 제거

바로 이러한 상황을 해결하기 위해 워크플로우 내비게이터 툴을 구축했습니다. 워크플로우 내비게이터는 Red Hat OpenShift AI의 자연어 코파일럿으로, 사용자의 의도를 파악해 실행 가능한 워크플로우로 전환합니다.

사용자는 구축하려는 환경을 자연어로 설명하면 됩니다. 예를 들어 "검색 증강 생성 애플리케이션용 모델이 필요하고 동시 사용자는 20명, 대기 시간은 1.5초 미만이어야 합니다"라고 입력할 수 있습니다. 워크플로우 내비게이터는 모델 레지스트리를 확인하고 클러스터에 있는 GPU 하드웨어를 파악한 다음 활용 사례에 맞는 벤치마크 데이터를 가져와 순위가 매겨진 옵션을 제시합니다.

모델 선택 측면에서 워크플로우 내비게이터는 실제 하드웨어 용량을 기준으로 후보를 필터링하고 태스크에 중요한 벤치마크를 기준으로 순위를 매깁니다. 예를 들어 팀에 코딩 어시스턴트가 필요하다고 가정해 보겠습니다. 리더보드에서 상위권을 차지했다는 이유로 700억 개 매개변수 모델을 배포하고 싶을 수 있습니다. 하지만 워크플로우 내비게이터의 플래너가 계산한 결과 2개의 GPU에서 실행되는 320억 개 매개변수 모델도 대기 시간 목표를 충족하고 코드 벤치마크에서 비슷한 점수를 기록하는 반면 700억 개 매개변수 모델은 동일한 작업에 4개의 GPU가 필요할 수 있습니다. 비슷한 결과를 절반의 하드웨어로 얻을 수 있는 셈입니다. 워크플로우 내비게이터는 잘못된 모델에 GPU 시간을 투입하기 전에 이러한 차이를 보여줍니다.

배포 측면에서 워크플로우 내비게이터는 선택한 모델에 맞는 프로덕션 레디 쿠버네티스 구성을 생성합니다. 용량 플래너는 다양한 양자화 수준과 텐서 병렬 처리 구성에서 필요한 GPU 메모리를 추정하고 GPU 추천 기능은 실제 벤치마크를 실행하지 않고도 여러 하드웨어 간 성능을 비교합니다.

예를 들어 채팅 모델을 배포하는 팀은 8비트 부동 소수점(FP8) 양자화를 적용한 L40이 동일한 모델을 16비트 부동 소수점(FP16)으로 실행하는 A100보다 훨씬 낮은 비용으로 서비스 수준 목표(SLO) 내의 대기 시간을 제공한다는 사실을 확인할 수 있습니다. 워크플로우 내비게이터는 클러스터의 실제 리소스에 맞춰 KServe InferenceService YAML, 리소스 요청, 자동 스케일링 규칙, 관측성 구성을 생성합니다. 사용자는 비용이나 성능 등 중요하게 생각하는 기준에 따라 절충안을 확인하고 적합한 구성을 선택하면 됩니다.

API 비용을 넘어 인프라 낭비까지 해결

AI 비용에 관한 논의는 거의 전적으로 API 비용에 집중되어 있습니다. 이는 실제로 중요한 문제이며 Uber와 Microsoft가 이에 대응하는 것도 타당합니다. 하지만 인프라 비용 문제는 그만큼 시급하게 다뤄지지 않고 있습니다. 모델은 실제 GPU에서 전력을 소비하며 실행되고 있지만 정작 워크로드에 맞게 검증되지 않은 구성으로 배포되는 경우가 많습니다. 이러한 낭비는 눈에 잘 띄지 않기 때문에 제대로 해결되지 않는 경우가 많습니다.

모델의 적합성보다 인지도를 기준으로 선택하고 검증된 구성이 아닌 기본 구성을 그대로 적용해 배포하면 비용 차이가 크게 벌어질 수 있습니다.

워크플로우 내비게이터 툴은 API 비용 문제를 해결하기 위한 것이 아니라 인프라 비용 문제를 직접 해결하는 데 초점을 맞춥니다. OpenShift AI에서 자체 하드웨어나 클라우드에 모델을 배포할 때 워크플로우 내비게이터를 활용하면 실제 사용 방식에 맞게 구성된 적합한 모델을 배포할 수 있습니다.

체험하기

워크플로우 내비게이터는 현재 OpenShift AI의 일부로 개발자 프리뷰를 통해 제공됩니다. 모델 컨텍스트 프로토콜(MCP)을 사용하므로 Claude Code, Cursor, Gemini CLI 또는 팀에서 선호하는 다른 MCP 호환 클라이언트와 함께 사용할 수 있습니다.

워크플로우 내비게이터는 2개의 오픈소스 프로젝트를 기반으로 구축되었습니다. rhoai-mcp 서버는 프로젝트 설정과 워크벤치 관리부터 모델 서빙과 파이프라인 구성에 이르기까지 OpenShift AI 환경을 프로그래밍 방식으로 관리할 수 있는 90개 이상의 툴을 제공합니다. llm-d planner는 인텔리전스 계층을 담당하며 대화를 통한 요구 사항 수집, SLO 기반 용량 계획, GPU 메모리 추정, 다기준 배포 순위 지정을 통해 "X에 사용할 모델이 필요합니다"라는 요청을 실제 실행 중인 최적화된 배포로 전환합니다.

팀에서 모델을 선택하고 배포를 튜닝하는 데 너무 많은 시간을 쓰고 있다면 직접 사용해 보세요. 이 기능은 오픈소스 방식으로 개발하고 있으며 여러분의 피드백을 기다리고 있습니다.

또는 Red Hat OpenShift AI에 대해 자세히 알아보세요.