AI 제품에서 가장 위험한 착각은 “이번 달 API 요금이 얼마 나왔지?”를 비용 관리라고 믿는 겁니다. 성장 관점에서 중요한 건 월 합계가 아니라 유저 행동 1회(요약 1번, 추천 1번, 응답 1번)을 제공하는 데 드는 비용—즉 CP1Ki(Cost per 1,000 inferences)입니다. dev.to의 ‘CP1Ki’ 글이 지적하듯, 이 숫자가 없으면 가격을 못 잡고, 플랜을 못 만들고, 모델 전환을 ‘감’으로 하게 됩니다. (출처: dev.to, Cost per 1,000 inferences…)
핵심은 분모는 쉬운데(1,000회 추론), 분자가 어렵다는 점입니다. 관리형 API는 토큰 비용(입력/출력 단가 × 평균 토큰)이 분자이고, 셀프호스팅은 GPU 인스턴스·스토리지·전송·모니터링 같은 인프라 비용이 분자입니다. 기사 예시처럼 동일한 요약 작업에서도 스택에 따라 CP1Ki가 $3대(Haiku)~$8대(GPT-4o)로 벌어지고, 셀프호스팅은 볼륨이 충분하면 $1대까지 내려갑니다. 문제는 거기서 끝이 아니라, 유휴율·버스트 큐잉·온콜·MLOps 유지보수가 숨어 있는 ‘진짜 분자’를 키운다는 겁니다.
여기서 컨텍스트 윈도우가 단위경제를 망치는 ‘토큰 누수 구멍’으로 등장합니다. dev.to의 컨텍스트 글은 “큰 윈도우로 다 넣으면 된다”가 답이 아니라고 말합니다. 긴 컨텍스트는 (1) 비용 상승, (2) 지연 증가, (3) lost-in-the-middle로 품질 저하를 동시에 부릅니다. 즉 COGS도 나빠지고 응답 신뢰도도 떨어져 리텐션까지 깎는 최악의 조합이 됩니다. (출처: dev.to, How we handle LLM context window limits…)
실행 전략은 단순하지만, ‘계측 가능한 형태’로 만들어야 합니다. 첫째, 기능별 CP1Ki를 고정하세요. 모든 추론 호출에 feature_tag(예: document_summariser), user_tier, model_version을 태깅하고, tokens_in/out을 함께 로깅합니다. 둘째, 컨텍스트 최적화로 평균 토큰을 깎아 CP1Ki를 구조적으로 낮춥니다. 슬라이딩 윈도우+요약, 관련도 기반 리트리벌, 구조화 메모리(절대 잃으면 안 되는 사실), 문서 컨텍스트 압축(저가 모델로 전처리)을 조합해 “지금 필요한 것만” 프롬프트에 넣습니다.
이제 성장 의사결정이 숫자로 연결됩니다. CP1Ki가 나오면 (a) 무제한 플랜의 손익분기 사용량이 바로 계산되고, (b) 특정 기능만 고급 모델로 라우팅하는 모델 믹스 전략이 가능해지며, (c) 온보딩에서 “처음부터 고비용 기능을 쓰게 할지/저비용 성공경험을 먼저 줄지” 같은 Activation 설계가 달라집니다. CAC를 낮추려면 결국 LTV를 올려야 하고, LTV의 바닥은 (가격 × 전환 × 유지) - COGS입니다. CP1Ki는 그중 COGS를 ‘변동비’가 아니라 ‘설계 변수’로 바꿉니다.
마지막으로 팀 운영 레이어에서 FinOps와 MLOps의 분업이 필요합니다. dev.to의 FinOps vs MLOps 글이 말하듯, MLOps가 “모델이 잘 돌아가게” 만든다면 FinOps는 “그걸 얼마나 효율적으로 돌리는지”를 책임집니다. 성장팀 입장에선 이 둘이 합쳐져야 합니다. 응답 신뢰(품질) 경보와 CP1Ki 드리프트(비용) 경보를 같은 대시보드에서 보고, 120% 이상 튀면 즉시 원인(프롬프트 비대화, 버전 변경, 재시도 폭풍)을 잡아야 합니다.
전망은 명확합니다. AI 제품의 경쟁력은 ‘더 똑똑한 모델’ 이전에 예측 가능한 단위경제 + 흔들리지 않는 응답 신뢰에서 갈립니다. CP1Ki로 비용을 1,000회 단위로 고정하고, 컨텍스트 설계로 토큰을 통제하며, 기능별 계측으로 변화를 즉시 감지하는 팀은 가격·플랜·온보딩·모델 라우팅을 실험 가능한 레버로 바꿉니다. 반대로 월 청구서만 보는 팀은 CAC가 조금만 올라가도, 혹은 유저가 조금만 헤비해져도 손익이 무너집니다. 지금 필요한 건 “모델 선택”이 아니라 CP1Ki를 제품의 기본 언어로 만드는 것입니다.