GPU를 보유했다고 해서 AI 서비스 사업이 저절로 만들어지는 것은 아닙니다. 장비를 설치한 뒤에도 운영팀은 여러 질문에 답해야 합니다. 고객은 자원을 어떻게 신청하고, 모델은 어떻게 배포하며, 사용량은 어떻게 기록할까요? 테넌트는 어떻게 격리하고 청구서는 어떻게 만들며, 수요가 몰릴 때에도 약속한 서비스 수준을 지킬 수 있을까요? 이런 과정이 없다면 GPU는 값비싼 재고로 남습니다. 반복 가능하고 측정 가능한 제공 절차가 있어야 컴퓨팅 자원이 상품이 됩니다.
이것이 Token Factory의 핵심입니다. 데이터·모델·컴퓨팅 자원을 투입하고, 표준화된 추론·스케줄링·거버넌스·계량 과정을 거쳐 토큰 서비스를 지속적으로 제공합니다. 고객은 API로 서비스를 이용하고, 운영자는 서비스 수준과 비용·수익의 귀속을 관리합니다. 모든 토큰이 같은 사업 가치를 가진다는 뜻은 아닙니다. 토큰을 추론 생산의 공통 측정 단위로 삼되, 이를 고객이 실제로 받는 서비스의 성과와 연결해야 합니다.
INFINITIX의 제품 구성에서 Token Factory는 ixCSP와 연결됩니다. ixCSP 공식 제품 페이지는 AI-Stack을 기반으로 한 상용 컴퓨팅 서비스 플랫폼으로서 GaaS·MaaS·TaaS, 사용량 추적, 자동 과금, 멀티테넌트 관리를 설명합니다. 이것이 현재 확인할 수 있는 제품의 기반입니다. 더 정교한 단위 경제성, 서비스 카탈로그, 모델 간 자원 배치는 공개되지 않은 기능으로 단정하지 않고 운영 설계와 발전 방향으로 다룹니다.
그림: Token Factory는 요청·모델·컴퓨팅 자원을 추론·스케줄링·거버넌스·계량 과정으로 연결해 제공 가능한 AI 서비스로 전환합니다.
1. Token Factory는 전산실이 아니라 생산을 운영하는 체계입니다
NVIDIA는 AI Factory를 에너지와 데이터를 토큰으로 전환하는 인프라로 설명하며, 토큰 처리량, 와트당 토큰, 토큰당 비용, 활용률과 가동 시간으로 경제성을 살펴봅니다(AI Factories). 이 비유는 추론이 일회성 모델 시연에서 지속적인 대량 생산으로 이동하고 있음을 이해하는 데 도움이 됩니다.
그러나 기업이 초당 생성 토큰 수만 보면 잘못된 결론에 이를 수 있습니다. 공장에는 기계의 속도뿐 아니라 원료 규격, 작업 지시, 품질 검사, 재고, 유지보수와 출하가 필요합니다. 마찬가지로 Token Factory도 최소한 서비스 정의, 테넌트와 신원, 모델과 실행 환경, 자원 스케줄링, 사용량 계량, 청구와 서비스 품질을 함께 다뤄야 합니다.
따라서 Token Factory는 특정 GPU 모델이나 추론 서버 하나를 뜻하지 않습니다. 기술 자원을 주문 가능한 서비스로 바꾸는 운영 체계입니다. 고객이 확인해야 하는 것은 명확한 서비스 카탈로그, 할당량, 엔드포인트, 계량 기준과 지원 책임입니다. 전산실의 GPU 수만으로는 충분하지 않습니다.
2. 투입부터 제공까지 토큰 서비스가 거치는 다섯 단계
운영 가능한 토큰 생산 라인은 다섯 단계로 나눌 수 있습니다.
| 단계 | 입력 | 플랫폼의 책임 | 남겨야 할 기록 |
|---|---|---|---|
| 서비스 접수 | 테넌트, 요금제, 모델 요구, 데이터 경계 | 프로젝트·권한·할당량·서비스 수준 설정 | 고객, 계약 버전, 승인 범위 |
| 모델 준비 | 모델, 이미지, 의존성, 프롬프트 템플릿 | 버전 검증, 재현 가능한 배포 환경 구성 | 모델·이미지 버전, 배포 매개변수 |
| 추론 생산 | 요청, 컨텍스트, 도구 호출 | 스케줄링, 배치, 라우팅, 확장, 실패 처리 | 요청, 대기열, 자원, 오류, 재시도 |
| 품질과 거버넌스 | 콘텐츠 규칙, 데이터 정책, 작업 권한 | 격리, 필터링, 사람의 확인, 감사 | 정책 판단, 예외, 사람의 개입 |
| 계량과 정산 | 토큰, 시간, 자원, 요금제 | 사용량 집계, 가격 적용, 청구서, 보고서 | 입력·출력 토큰, 요율 버전, 금액과 귀속 |
모든 단계는 같은 테넌트·프로젝트·서비스 ID를 사용해야 합니다. 추론 시스템은 엔드포인트 이름을 기록하고, 과금 시스템은 계정만 인식하며, 모니터링 시스템은 Pod 이름을 쓴다면 월말에 사람이 데이터를 맞춰야 합니다. 고객 문의에도 대응하기 어렵습니다. Token Factory의 첫 표준화 과제는 모델 최적화보다 시스템 간 식별 기준을 통일하는 일인 경우가 많습니다.
OpenTelemetry의 생성형 AI 관측성은 모델 이름, 입력·출력 토큰, 도구 호출과 지연 시간을 추적·메트릭·이벤트에 담는 방법을 보여 줍니다. 공통 의미 체계를 갖추면 운영팀은 총사용량 청구서만 보는 대신 고객 요청 하나에서 모델·도구·인프라까지 따라갈 수 있습니다.
3. GaaS·MaaS·TaaS는 같은 공장의 서로 다른 상품 계층입니다
ixCSP 공식 제품 페이지는 세 가지 사업 모델을 제시합니다. 이들은 서로 배타적인 요금제가 아니라 운영 책임을 서로 다른 계층에 두는 방식입니다.
| 서비스 모델 | 고객이 받는 상품 | 플랫폼의 주요 책임 | 적합한 고객 |
|---|---|---|---|
| GaaS | 필요할 때 확보하는 GPU 컴퓨팅 자원 | 자원 풀, 분할, 할당량, 테넌트 격리, 사용량 과금 | 모델·플랫폼 팀이 있고 유연한 자원이 필요한 고객 |
| MaaS | 등록되어 있고 배포 가능한 모델 서비스 | 모델 카탈로그, 버전, 환경, 배포, 엔드포인트 수명주기 | 모델의 서비스 출시 시간을 줄이려는 애플리케이션 팀 |
| TaaS | 토큰 사용량으로 과금하는 추론 API | 라우팅, 추론, 토큰 계량, 서비스 수준, 청구 | 모델 인프라를 직접 유지하지 않고 AI 기능을 통합하려는 고객 |
Token Factory에서 중요한 점은 세 계층이 기반 자원과 운영 데이터를 공유할 수 있다는 것입니다. GaaS의 GPU 풀은 MaaS 모델 엔드포인트를 지원하고, MaaS는 다시 TaaS의 추론 공급원이 될 수 있습니다. 각 계층은 고유한 상품 경계와 가격 체계를 유지합니다. 데이터센터가 사업 모델마다 신원·모니터링·과금 시스템을 새로 만들 필요가 없어지는 것입니다.
ixCSP가 공개한 기능에는 사용량 추적, 자동 과금, 멀티테넌트 관리와 GaaS·MaaS·TaaS 서비스화가 포함됩니다. 이를 Token Factory라는 운영 관점에서 보면 제품의 역할도 분명해집니다. AI-Stack은 자원과 제어의 기반을 제공하고, ixCSP는 이를 판매하고 측정하며 지속적으로 운영할 수 있는 서비스로 구성합니다.
4. 계량은 토큰 수에 속도·용량·품질을 함께 더해야 합니다
토큰은 자연스러운 측정 단위이지만 완전한 서비스 지표는 아닙니다. NVIDIA의 LLM 추론 지표 정의는 첫 토큰 지연 시간(TTFT), 토큰 간 지연 시간(ITL), 종단 간 지연 시간, 초당 토큰(TPS), 초당 요청(RPS)을 구분합니다. 도구마다 정의가 다르면 숫자를 그대로 비교할 수 없습니다.
운영 가능한 TaaS 서비스는 최소한 네 가지 범주를 관찰해야 합니다.
- 사용량: 입력 토큰, 출력 토큰, 요청 수, 도구 호출 수.
- 사용 경험: TTFT, 종단 간 지연, 스트리밍 안정성, 오류율.
- 용량: 동시 실행, 대기 시간, TPS, 자원 활용률, 피크 부하의 포화 지점.
- 결과: 작업 완료 여부, 재시도, 사람에게 이관한 요청, 콘텐츠·권한 규칙 통과 여부.
TPS가 높을수록 좋다는 말에도 조건이 있습니다. 배치를 키우면 전체 처리량은 늘어도 개별 사용자는 더 오래 기다릴 수 있습니다. 긴 컨텍스트는 첫 토큰이 나오는 시간과 메모리 부담을 키웁니다. 동시 요청이 포화 수준에 가까워지면 대기열이 빠르게 길어질 수 있습니다. 서비스 카탈로그에는 시험한 모델·하드웨어·입출력 길이·동시 실행 수·측정 구간을 명시해야 합니다. 단일 최대 처리량을 모든 작업의 약속으로 삼아서는 안 됩니다.
과금 데이터는 다시 계산할 수 있어야 합니다. 사용 기록마다 테넌트, 서비스, 모델 버전, 입력·출력 토큰, 시간, 요율 버전과 할인 규칙을 남겨야 합니다. 모델의 토크나이저나 가격·요금제가 바뀌어도 과거 청구 내역은 설명할 수 있어야 합니다. 실시간 대시보드가 보기 좋다는 것만으로는 상용 운영을 뒷받침할 수 없습니다.
5. 멀티테넌트는 로그인 화면이 아니라 상품이 약속하는 경계입니다
Token Factory는 여러 외부 고객이나 내부 사업 부서에 서비스를 제공할 수 있습니다. 이는 사람마다 계정을 만드는 수준을 넘어 데이터·네트워크·모델·자원·로그·청구를 분리하는 문제입니다.
Kubernetes 공식 멀티테넌시 가이드는 클러스터 공유가 비용을 줄이고 관리를 단순화할 수 있지만 보안, 공정성, noisy neighbor 문제도 가져온다고 설명합니다. 테넌트 간 신뢰 수준, 규제와 성능 요구에 따라 namespace, 가상 제어 영역, 전용 노드 또는 별도 클러스터처럼 서로 다른 격리 방식이 필요할 수 있습니다.
서비스 제공자는 격리를 확인 가능한 조건으로 나눠야 합니다.
- 사용자 신원과 API 키로 자신의 엔드포인트·사용량만 조회할 수 있는가.
- 모델·프롬프트·벡터 데이터·로그가 테넌트 간에 공유되는가.
- 한 테넌트의 높은 부하가 다른 테넌트를 느리게 만드는가.
- 관리자가 권한을 넘어 콘텐츠를 볼 수 있는가. 그 행위는 감사 기록에 남는가.
- 계약 종료 후 모델·데이터·캐시·백업은 어떻게 제거하는가.
멀티테넌트 설계는 가격에도 직접 영향을 줍니다. 공유 자원은 평균 활용률을 높이기 쉽지만 더 세밀한 할당량, 우선순위와 보호 장치가 필요합니다. 전용 자원은 격리와 용량을 설명하기 쉽지만 고정비가 더 큽니다. Token Factory는 하나의 정답을 가정하기보다 서비스 등급마다 명확한 기술 경계를 정해야 합니다.
6. 비용 중심에서 서비스 사업으로, 단위 경제성을 검증합니다
Token Factory의 사업성을 평가할 때 클라우드 API 단가와 자체 GPU 비용만 비교해서는 안 됩니다. 고정비에는 장비, 시설, 네트워크, 소프트웨어와 운영 인력이 포함됩니다. 변동비에는 전력, 모델 호출, 저장 공간, 트래픽, 지원과 재시도가 포함됩니다. GPU 감가상각만 토큰 수로 나누면 서비스 비용의 상당 부분을 빠뜨릴 수 있습니다.
FinOps Foundation의 Cloud Unit Economics는 비용을 이해 가능한 사업 단위와 연결하는 방식을 강조합니다. Token Factory도 두 가지 단위를 함께 사용할 수 있습니다. 기술적으로는 백만 토큰당 비용, 요청당 비용과 유효 용량을 봅니다. 사업적으로는 테넌트·서비스·완료한 작업별 비용, 매출과 매출총이익을 살펴봅니다. 토큰은 공통 자이지만 최종 판단은 고객이 받은 서비스로 돌아와야 합니다.
90일 검증 계획은 세 단계로 나눌 수 있습니다.
1~30일 한 개의 서비스 SKU를 정의합니다
모델과 작업을 하나 정하고 테넌트, 데이터 경계, 입출력 범위, 예상 동시 실행 수, 지원 책임과 과금 단위를 문서화합니다. 아직 검증하지 않은 SLA를 약속하기 전에 비용 기준선을 만듭니다.
31~60일 계량부터 청구까지 연결합니다
신청, 배포, API 키, 요청, 사용량 집계와 청구서 생성에 같은 ID를 사용합니다. 실제 트래픽과 피크 상황에서 TTFT, TPS, 대기, 오류와 재시도를 확인하고 청구 내역을 개별 기록까지 추적할 수 있는지 검증합니다.
61~90일 두 번째 테넌트와 예외 상황을 추가합니다
할당량 소진, 모델 실패, 가격 버전 변경, 테넌트 삭제와 noisy neighbor 상황을 시험합니다. 예외가 발생해도 서비스·청구·거버넌스 기록이 일관되게 유지되는 것을 확인한 뒤 모델 카탈로그와 고객 수를 늘립니다.
Token Factory의 변화는 토큰을 새로운 상품으로 포장하는 데 있지 않습니다. AI 추론을 반복해서 제공할 수 있는 서비스 생산으로 바꾸는 데 있습니다. ixCSP의 GaaS·MaaS·TaaS, 계량·과금과 멀티테넌트 기능은 확인 가능한 제품 기반입니다. 이를 바탕으로 서비스 카탈로그, 단위 경제성과 종단 간 관측성을 설계하면 GPU 자산을 고객이 실제로 이용하는 AI 서비스와 연결할 수 있습니다.
