창업자들이 **수익 누출 (revenue leakage)**이라는 용어를 들을 때, 보통은 명백한 위협들을 떠올립니다.

사기 (Fraud).

차지백 (Chargebacks).

도난당한 계정.

승인되지 않은 결제.

그러한 문제들은 분명히 존재합니다.

하지만 많은 AI 기업들에게, 실제 가장 큰 손실이 발생하는 지점은 그곳이 아닙니다.

마진 침식 (margin erosion)의 가장 큰 원인은 종종 훨씬 덜 극적입니다.

바로 엔지니어링 (engineering)입니다.

엔지니어들이 실수를 하기 때문이 아닙니다.

현대의 AI 제품은 매일 수백만 건의 결정을 실행하며, 작은 운영상의 비효율성이 조용히 쌓여 상당한 비즈니스 비용으로 이어지기 때문입니다.

AI 제품에서의 수익 누출은 좀처럼 한꺼번에 발생하지 않습니다.

불필요한 요청이 하나씩 발생할 때마다 일어납니다.

중복된 실행 하나.

재시도 (retry) 하나.

만료된 권한 (stale permission) 하나.

결코 실행되지 말았어야 할 워크플로 (workflow) 하나.

개별적으로 보면 이러한 이벤트들은 미미해 보입니다.

하지만 이들이 모이면 수익성을 서서히 갉아먹습니다.

과제는 단순히 사기를 방지하는 것이 아닙니다.

인프라가 불필요하게 비용을 지출하지 않도록 방지하는 것입니다.

대부분의 창업자들이 수익 누출을 생각하는 방식

대부분의 소프트웨어 기업들은 전통적으로 수익 누출을 재무적인 문제로 간주해 왔습니다.

일반적인 용의자들은 익숙합니다:

• 결제 사기 (Payment fraud)
• 차지백 (Chargebacks)
• 계정 공유 (Account sharing)
• 구독 남용 (Subscription abuse)
• 수금 실패 (Failed collections)

이것들은 정당한 우려 사항입니다.

또한 상대적으로 눈에 잘 띕니다.

재무 팀이 이를 모니터링합니다.

결제 제공업체가 보호 기능을 제공합니다.

리스크 시스템 (Risk systems)이 이를 탐지하도록 설계되어 있습니다.

AI 비즈니스는 다른 종류의 누출을 도입합니다.

종종 제품 자체 내부에서 완전히 발생하는 누출 말입니다.

어떤 고객도 악의적으로 행동하지 않습니다.

결제가 실패하지도 않았습니다.

사기가 발생하지도 않았습니다.

인프라가 단지 비즈니스가 의도한 것보다 더 많은 리소스를 소비할 뿐입니다.

이 차이는 중요합니다.

전통적인 수익 누출은 대개 돈이 수집되지 않아서 발생합니다.

AI 수익 누출은 대개 불필요한 비용이 발생하기 때문에 일어납니다.

송장 (invoice)은 완전히 정확할 수 있습니다.

하지만 마진 (margins)은 그렇지 않습니다.

마진을 조용히 파괴하는 보이지 않는 엔지니어링 결정

소수의 엔지니어링 팀만이 의도적으로 돈을 낭비하는 시스템을 설계합니다.

대부분의 수익 누출 (revenue leakage)은 고립된 상태에서 내려진 지극히 합리적인 엔지니어링 결정으로부터 발생합니다.

몇 가지 사례를 살펴보겠습니다.

네트워크 타임아웃 (network timeout)이 자동 재시도 (automatic retry)를 트리거합니다.

AI 에이전트 (AI agent)가 실수로 동일한 워크플로우 (workflow)를 두 번 실행합니다.

웹훅 (webhook)이 한 번 이상 전달됩니다.

고객의 권한 (entitlements)이 아직 갱신되지 않았습니다.

액세스 (access)가 만료된 후에도 백그라운드 작업 (background job)이 계속됩니다.

크레딧 (credits)이 검증되기 전에 요청 (request)이 비용이 많이 드는 모델 (expensive model)에 도달합니다.

이 중 어떤 상황도 특별히 경고할 만한 상황처럼 보이지는 않습니다.

많은 경우, 고객은 정확히 기대했던 경험을 제공받습니다.

운영 (operational) 관점에서는 시스템이 건강해 보입니다.

하지만 재무 (financial) 관점에서는 모든 불필요한 실행이 결코 회복할 수 없는 자원을 소비합니다.

이것이 바로 엔지니어링 주도형 수익 누출 (engineering-driven revenue leakage)을 식별하기 어렵게 만드는 이유입니다.

애플리케이션은 계속 작동합니다.

고객은 만족을 유지합니다.

수익은 계속 성장합니다.

그동안 마진 (margins)은 백그라운드에서 조용히 하락합니다.

가장 위험한 수익 누출은 제품을 망가뜨리는 종류가 아닙니다. 제품이 정확히 예상대로 작동하게 두면서 운영 비용 (operating costs)을 조용히 증가시키는 종류입니다.

모든 불필요한 AI 요청에는 실제 비용이 따릅니다

전통적인 SaaS 제품들은 놀라울 정도로 관대합니다.

고객이 대시보드 (dashboard)를 새로고침합니다.

같은 버튼을 두 번 클릭합니다.

페이지를 다시 엽니다.

대부분의 경우, 추가적인 인프라 (infrastructure) 비용은 거의 무시할 수 있는 수준입니다.

AI 제품은 다른 경제 모델 하에서 작동합니다.

거의 모든 의미 있는 상호작용은 측정 가능한 비용이 발생하는 자원을 소비합니다.

단일 요청에는 다음과 같은 것들이 포함될 수 있습니다:

• LLM 추론 (inference)
• 입력 및 출력 토큰 (input and output tokens)
• GPU 시간 (GPU time)
• 이미지 생성 (image generation)
• 음성 인식 (speech recognition)
• 음성 합성 (speech synthesis)
• 벡터 데이터베이스 쿼리 (vector database queries)
• 외부 API (external APIs)
• 에이전트 오케스트레이션 (agent orchestration)

전통적인 소프트웨어와 달리, 실행(execution) 자체가 비용 구조의 일부가 됩니다.

이는 엔지니어링 의사결정을 평가하는 방식을 변화시킵니다.

중복된 요청은 단순히 불필요한 것이 아닙니다.

그것은 또 다른 모델 추론 (model inference)을 트리거할 수 있습니다.

또 다른 API 호출 (API call).

또 다른 워크플로 (workflow).

또 다른 청구서 (bill).

개별적으로 보면 이러한 비용은 대개 작습니다.

하지만 규모가 커지면 제품의 단위 경제성 (unit economics)의 일부가 됩니다.

모든 불필요한 실행은 해당 고객, 해당 워크플로, 또는 해당 기능에서 발생하는 마진 (margin)을 직접적으로 감소시킵니다.

수익 누출 (revenue leakage)이 항상 도착하지 않은 돈으로만 측정되는 것은 아닙니다.

때로는 지출할 필요가 없었던 돈으로 측정되기도 합니다.

과금 시스템 (billing systems)이 이를 해결할 수 없는 이유

AI 기업들이 수익화 (monetization)를 고민하기 시작할 때, 과금 (billing)은 종종 그들이 구현하는 첫 번째 계층입니다.

그것은 전적으로 합리적입니다.

송장 (invoices)이 생성되어야 하고,

결제 (payments)가 수집되어야 하기 때문입니다.

과금 시스템은 필수적인 비즈니스 질문에 답합니다:

고객이 지불했는가?

하지만 AI 제품의 경우, 또 다른 질문이 똑같이 중요해집니다:

이 요청을 실행해야 하는가?

이것들은 런타임 결정 (runtime decisions)입니다. 저는 'The Most Expensive AI Request Is the One You Should Have Blocked'에서 왜 이 질문이 현대 AI 제품에 있어 근본적인 것이 되었는지 탐구했습니다.

결제가 성공했다고 해서 반드시 다음 AI 요청이 실행되어야 한다는 의미는 아닙니다.

고객이 크레딧 (credits)을 모두 소진했을 수도 있습니다.

구독 (subscription)은 여전히 활성 상태이지만 프리미엄 권한 (premium entitlement)이 만료되었을 수도 있습니다.

지출 한도 (spending limit)에 도달했을 수도 있습니다.

중복된 요청이 이미 처리 중일 수도 있습니다.

재시도 (retry)가 이미 필요한 리소스 (resources)를 소비했을 수도 있습니다.

이러한 상황 중 그 어느 것도 과금의 문제는 아닙니다.

그것들은 런타임 결정 (runtime decisions)입니다.

과금은 재무적 이벤트 (financial events)를 기록합니다.

런타임 인프라 (runtime infrastructure)는 리소스 소비 (resource consumption)를 관리합니다.

결제 (payment)와 런타임 제어 (runtime control) 사이의 이러한 구분은 AI 수익화가 진화함에 따라 점점 더 중요해지고 있습니다.

AI 제품이 더욱 정교해짐에 따라, 이러한 책임들을 분리하는 것이 갈수록 중요해지고 있습니다.

하나는 돈이 수집되었는지를 결정합니다.

다른 하나는 돈을 더 써야 하는지를 결정합니다.

수익 누출은 인보이스가 생성되기 전부터 시작됩니다

많은 기업이 사후에 수익 누출 (revenue leakage)을 측정하려고 시도합니다.

그들은 인보이스 (invoices)를 분석합니다.

클라우드 청구서 (cloud bills)를 검토합니다.

고객 수익성 (customer profitability)을 조사합니다.

마진이 어디에서 사라지는지 이해하기 위해 대시보드 (dashboards)를 구축합니다.

그러한 활동들은 가치가 있습니다.

하지만 그것들은 또한 사후 대응적 (reactive)입니다.

대시보드가 불필요한 AI 실행을 보여줄 때쯤이면, 인프라 (infrastructure)는 이미 돈을 써버린 상태입니다.

실제적인 재무적 결정은 훨씬 이전에 일어났습니다.

그 결정은 요청 (request)이 시스템에 들어온 순간에 일어났습니다.

건강한 AI 제품들은 값비싼 연산 (compute)이 시작되기 전에 비즈니스 검증 (business validation)을 도입하는 추세입니다.

전형적인 체크 항목에는 다음이 포함됩니다:

• 권한 부여 (Authorization)
• 권한 검증 (Entitlement validation)
• 크레딧 확인 (Credit verification)
• 지출 한도 (Spending limits)
• 중복 탐지 (Duplicate detection)
• 런타임 정책 (Runtime policies)

이러한 체크를 통과한 후에야 애플리케이션은 값비싼 AI 워크로드 (workloads)를 실행합니다.

이 접근 방식이 운영 비용 (operational costs)을 완전히 제거하는 것은 아닙니다.

불필요한 비용을 방지하는 것입니다.

이것은 중요한 차이입니다.

가장 저렴한 AI 요청은 토큰 (tokens)을 적게 사용하는 요청이 아닙니다.

애초에 실행될 필요가 없었던 요청입니다.

엔지니어링이 재무 운영 (financial operations)의 일부가 되고 있습니다

수년 동안 엔지니어링 (engineering)과 재무 (finance)는 대체로 분리된 세계에서 운영되었습니다.

엔지니어링은 신뢰성 (reliability)에 집중했습니다.

재무는 수익 (revenue), 비용 (costs), 그리고 수익성 (profitability)에 집중했습니다.

AI 제품은 이러한 세계들을 점점 더 가깝게 만들고 있습니다.

오늘날 백엔드 아키텍처 (backend architecture)는 다음과 같은 비즈니스 지표 (business metrics)에 직접적인 영향을 미칩니다:

• 매출 총이익 (Gross margins)
• 고객 수익성 (Customer profitability)
• 워크플로우 수익성 (Workflow profitability)
• 인프라 효율성 (Infrastructure efficiency)
• 가격 책정 지속 가능성 (Pricing sustainability)

재시도 전략 (retry strategy)은 운영 비용에 영향을 미칠 수 있습니다.

경쟁 상태 (race condition)는 중복된 컴퓨팅 자원을 소비할 수 있습니다.

권한 부여 (authorization) 결정은 고객이 이익을 창출할지 손실을 발생시킬지를 결정할 수 있습니다.

이것들은 더 이상 순수하게 기술적인 문제만이 아닙니다.

이것들은 소프트웨어로 구현된 비즈니스 결정입니다.

AI가 기업 제품의 일부가 될수록, 엔지니어링은 기업의 재무 운영 (financial operations)의 일부가 됩니다.

경제적으로 건강한 AI 비즈니스를 구축하는 것은 점점 더 경제적으로 인지하는 인프라 (economically aware infrastructure)를 구축하는 것에 달려 있습니다.

새로운 인프라 계층이 등장하고 있습니다

AI 제품이 성숙해짐에 따라, 새로운 아키텍처 패턴이 나타나기 시작했습니다.

결제 (payment)에서 실행 (execution)으로 직접 이동하는 대신, 많은 팀이 추가적인 결정 계층 (decision layer)을 도입하고 있습니다.

결제 (Payment)
    ↓
권한 부여 (Authorization)
...

각 단계는 서로 다른 질문에 답합니다.

이것은 단순히 또 다른 인프라 구성 요소가 아닙니다.

이는 AI 비즈니스가 수익화 (monetization)를 생각하는 방식의 변화입니다.

목표는 더 이상 단순히 매출을 수집하는 것이 아닙니다.

모든 AI 요청이 지속 가능한 비즈니스 모델에 기여하도록 보장하는 것입니다.

이 아키텍처 패턴이 계속 진화함에 따라, 이를 중심으로 새로운 카테고리가 등장하기 시작했습니다.

결제나 과금 (billing)에만 독점적으로 집중하는 대신, 이러한 플랫폼들은 값비싼 AI 리소스가 소비되기 전에 기업이 경제적으로 정보에 기반한 결정을 내릴 수 있도록 돕습니다.

**Licenzy**와 같은 솔루션은 이러한 신흥 AI 수익화 런타임 (AI Monetization Runtime) 카테고리의 일부이며, 결제, 권한 부여, 사용량 및 비즈니스 경제학을 단일 런타임 계층으로 연결하는 인프라를 제공합니다.

이 카테고리는 여전히 형성되는 과정에 있습니다.

하지만 이 카테고리가 해결하려는 근본적인 문제는 AI 제품이 확장됨에 따라 점점 더 흔해지고 있습니다.

마치며

창업자들이 **수익 누출 (revenue leakage)**이라는 문구를 들을 때, 그들은 종종 사기를 떠올리곤 합니다.

AI 비즈니스에서 더 큰 위험은 훨씬 더 조용하게 발생하는 경우가 많습니다.

그것은 필요하지 않은 시점에 인프라 비용이 지출되는 것입니다.

중복된 실행 한 번.

불필요한 재시도 (retry) 한 번.

만료된 권한 (stale entitlement) 한 번.

이러한 사건들은 각각 단독으로는 중요해 보이지 않을 수 있습니다.

하지만 이들이 모여 비즈니스의 경제성을 결정짓습니다.

이것이 바로 수익 누출이 재무적인 문제만큼이나 점점 더 엔지니어링의 영역이 되어가고 있는 이유입니다.

건강한 AI 비즈니스를 구축하는 기업은 단순히 최고의 모델을 보유하거나 가장 낮은 토큰 (token) 가격을 제시하는 기업이 아닐 것입니다.

그들은 연산 (compute)이 시작되기 전에 더 나은 결정을 내리는 기업이 될 것입니다.

현대의 AI 제품에서는 모든 엔지니어링 결정이 재무적 결정으로 이어질 잠재력을 가지고 있기 때문입니다.