생성형 AI 서비스의 PoC는 대개 저렴해 보입니다. 사용자 수가 적고 질문도 짧으며, 개발자가 직접 품질을 살펴보기 때문입니다. 그러나 운영에 들어가면 상황이 달라집니다. 대화 기록과 검색 문서가 길어지고, 에이전트가 여러 도구를 호출하며, 실패한 요청이 재시도되고, 팀마다 다른 모델을 붙입니다. 매출이나 업무 성과보다 AI 비용이 더 빨리 늘어나는 순간이 옵니다.
이때 가장 흔한 대응은 모델을 싼 것으로 바꾸거나 출력 토큰을 줄이는 것입니다. 단기적으로 청구액은 내려갈 수 있지만 품질 저하로 재질문과 사람 검토가 늘면 총비용은 오히려 커집니다. AI 비용 관리는 가격표 비교가 아니라 업무 결과 하나를 만드는 데 사용된 전체 자원과 품질을 함께 관리하는 일이어야 합니다.
핵심: 토큰당 가격이 아니라 ‘성공적으로 처리된 업무 한 건당 비용’을 최적화해야 한다.
AI 비용이 예측보다 빨리 커지는 7가지 이유
- 컨텍스트 팽창: 대화 기록과 검색 문서를 매 요청마다 다시 보낸다.
- 최고급 모델 고정: 간단한 분류부터 복잡한 추론까지 한 모델로 처리한다.
- 에이전트 반복: 계획·검색·도구 호출·검증이 여러 번 이어진다.
- 숨은 재시도: 타임아웃과 형식 오류를 애플리케이션이 자동 재호출한다.
- 과도한 출력: 사용자가 보지 않는 긴 설명과 중간 결과까지 생성한다.
- 공용 계정: 프로젝트·기능·고객별 비용을 나누지 못해 낭비 지점을 찾지 못한다.
- 품질 비용 누락: 오답 수정, 상담원 재처리, 고객 이탈 비용이 AI 청구서 밖에 남는다.
특히 에이전트는 사용자 요청 한 번이 모델 호출 한 번이 아닙니다. 계획을 세우고, 검색 결과를 읽고, 도구를 선택하고, 결과를 검증하면서 여러 번 호출할 수 있습니다. 요청 수만 보고 예산을 예측하면 실제 사용량과 큰 차이가 생깁니다.
첫 번째 원칙: 비용을 업무 결과에 연결하라
FinOps Foundation은 생성형 AI의 단위 경제성을 토큰에서 출발하되, 궁극적으로는 지원 업무 한 건, 에이전트 행동 한 번, 자동 처리된 사례 한 건처럼 결과 중심의 단위로 확장할 것을 제안합니다. 이는 중요한 관점 전환입니다.
예를 들어 고객 문의 자동화의 핵심 지표는 ‘백만 토큰당 비용’이 아닙니다. 다음처럼 나눠 봐야 합니다.
- 시도당 비용: AI가 답변을 만들려고 시도한 전체 비용
- 해결당 비용: 고객이 추가 문의 없이 해결한 건당 비용
- 전환당 비용: 상담원에게 넘어간 건을 제외한 실제 자동 처리 비용
- 품질 조정 비용: 오답 정정, 보상, 상담원 재처리를 포함한 비용
- 절감액: 기존 평균 처리비용에서 품질 조정 AI 비용을 뺀 값
문서 처리라면 문서 한 장이 아니라 검증을 통과한 문서 한 건, 개발 보조라면 생성된 코드 줄 수가 아니라 리뷰를 통과해 병합된 변경을 단위로 삼는 편이 낫습니다. 이렇게 해야 싼 모델의 낮은 성공률과 비싼 모델의 높은 성공률을 공정하게 비교할 수 있습니다.
요청별 원가표부터 만든다
한 요청의 비용은 입력·출력 토큰만으로 끝나지 않습니다. 검색용 임베딩, 벡터 데이터베이스 조회, 재랭킹, 이미지·음성 처리, 도구 API, 샌드박스 실행, 로그 저장, 사람 검토가 모두 포함됩니다.
최소한 다음 항목을 요청 ID와 함께 기록해야 합니다.
- 제품, 기능, 고객 또는 테넌트, 환경, 비용센터
- 모델과 버전, 서비스 제공자, 처리 등급
- 입력·캐시 입력·출력·추론 토큰 또는 공급자별 사용 단위
- 검색 문서 수와 길이, 임베딩·재랭킹 비용
- 모델 호출 수, 도구 호출 수, 재시도와 실패 이유
- 응답 지연시간과 품질 평가 결과
- 사람 검토 시간, 최종 업무 성공 여부
공급자별 사용 단위와 청구 체계가 달라도 내부에는 공통 이벤트 스키마를 두는 것이 좋습니다. 그래야 모델이나 클라우드를 바꿔도 대시보드와 예산 정책이 유지됩니다.
모델 라우팅: 모든 문제에 최고급 모델은 필요 없다
업무 요청의 난이도와 위험도는 제각각입니다. 언어 감지, 의도 분류, 정형 데이터 추출은 작은 모델이나 규칙으로도 충분할 수 있습니다. 복잡한 계약 비교, 여러 문서의 모순 분석, 중요한 의사결정 보조는 더 강한 모델이 필요합니다.
좋은 라우터는 단순히 키워드로 모델을 고르지 않습니다. 요청 길이, 필요한 도구, 검색 결과의 불확실성, 사용자 등급, 데이터 민감도, 실패 비용과 응답 시간 목표를 함께 봅니다. 고위험 업무는 비용이 더 들더라도 강한 모델과 사람 검토를 사용하고, 대량 저위험 업무는 작은 모델로 보냅니다.
세 가지 라우팅 방식
- 규칙 기반: 업무 유형, 입력 크기, 고객 등급으로 분기한다. 설명하기 쉽고 초기 도입에 적합하다.
- 분류기 기반: 별도의 작은 모델이 난이도와 위험을 예측한다. 요청 패턴이 다양할 때 유용하다.
- 단계적 승격: 효율적인 모델이 먼저 답하고 검증 기준을 넘지 못할 때만 강한 모델로 재처리한다.
단계적 승격에는 주의가 필요합니다. 작은 모델 호출이 대부분 실패하면 결국 두 모델을 모두 호출해 비용과 지연이 늘어납니다. 승격률, 첫 시도 성공률, 최종 품질을 함께 측정하며 적용해야 합니다.
컨텍스트는 많을수록 좋은가
긴 컨텍스트 창이 제공된다고 항상 채워야 하는 것은 아닙니다. 관련 없는 문서는 비용과 지연을 늘리고 모델의 주의를 분산시킬 수 있습니다. RAG 시스템은 검색 결과를 많이 넣는 대신 정확한 문서와 구간을 선택해야 합니다.
실무에서는 먼저 질문을 구조화하고, 문서 메타데이터로 범위를 좁히고, 필요한 구간만 가져옵니다. 중복 문서와 오래된 버전은 제거하고, 표나 로그처럼 큰 자료는 질문에 필요한 요약 또는 계산 결과로 바꿉니다. 대화 기록도 전체를 누적하지 말고 확정된 사실, 열린 과제, 최근 발화로 나눠 관리합니다.
다만 컨텍스트 절감은 무조건적인 잘라내기가 아닙니다. 삭제한 정보 때문에 중요한 제약이나 근거가 사라질 수 있습니다. 원본 컨텍스트와 축약 컨텍스트의 품질을 평가 세트에서 비교해야 합니다.
프롬프트 캐시는 반복되는 앞부분을 자산으로 만든다
기업용 AI 요청에는 긴 시스템 지침, 도구 정의, 제품 설명, 공통 문서처럼 반복되는 앞부분이 많습니다. 주요 AI 플랫폼은 동일하거나 안정적인 프롬프트 접두부를 재사용해 비용과 지연을 줄이는 캐시 기능을 제공합니다. OpenAI와 Google Cloud의 공식 문서도 반복 컨텍스트를 앞쪽에 배치하고 변경되는 내용을 뒤쪽에 두는 구성을 안내합니다.
캐시 적중률을 높이려면 공통 지침의 순서와 표현을 안정화해야 합니다. 현재 시간이나 요청 ID처럼 매번 달라지는 값을 앞부분에 넣으면 접두부가 달라집니다. 도구 정의 순서가 요청마다 바뀌거나, 같은 정책 문서에 불필요한 공백과 버전 문자열이 붙는 것도 적중률을 떨어뜨립니다.
캐시는 공짜 저장소가 아닙니다. 공급자와 방식에 따라 캐시 생성·보관·읽기 비용과 TTL이 다르고, 장기간 캐시는 데이터 보존 정책에 영향을 줄 수 있습니다. 민감정보가 포함된 컨텍스트를 캐시하기 전에 저장 위치, 보존 기간, 삭제와 접근 정책을 확인해야 합니다.
결과 캐시는 더 큰 절감이지만 더 어렵다
프롬프트 캐시는 모델의 내부 계산 일부를 재사용합니다. 반면 결과 캐시는 같은 의미의 질문에 기존 답변을 그대로 반환해 모델 호출 자체를 건너뜁니다. FAQ, 제품 사양, 문서 요약처럼 답이 안정적인 업무에서 효과가 큽니다.
하지만 문장만 비슷하다고 같은 답을 반환하면 안 됩니다. 사용자 권한, 테넌트, 언어, 정책 버전, 데이터 갱신 시각을 캐시 키에 포함해야 합니다. 개인화된 답변이나 잔액·재고처럼 실시간성이 중요한 정보는 짧은 TTL 또는 캐시 제외가 필요합니다. 답변과 함께 근거 문서 버전을 저장하고 데이터가 바뀌면 무효화하는 구조도 중요합니다.
실시간이 필요 없는 작업은 비동기로
모든 AI 작업이 몇 초 안에 끝날 필요는 없습니다. 야간 문서 분류, 평가 세트 실행, 임베딩 생성, 주간 리포트, 대량 번역은 큐에 넣어 비동기로 처리할 수 있습니다. 여러 플랫폼은 이런 비동기·배치 처리에 별도 요금이나 처리 방식을 제공합니다.
사용자에게 즉시 필요한 부분과 나중에 완료해도 되는 부분을 분리하면 됩니다. 예를 들어 업로드 직후 기본 메타데이터만 빠르게 보여주고, 전체 분석과 교차 검증은 백그라운드로 처리합니다. 단, 배치는 완료 시각이 고정되지 않을 수 있으므로 마감 시간, 재처리, 부분 실패, 결과 매칭을 설계해야 합니다.
출력 토큰은 UX 설계로 줄인다
“자세히 설명해줘”라는 프롬프트를 시스템 기본값으로 넣으면 사용자가 읽지 않는 긴 답변이 계속 생성됩니다. 화면에서 필요한 구조를 먼저 정하면 출력도 줄어듭니다. 목록에는 제목·한 줄 요약·상태만 만들고, 사용자가 펼쳤을 때 상세 설명을 생성합니다.
JSON 응답도 사용하지 않는 필드를 빼고, 최대 항목 수와 길이를 스키마에 명시합니다. 사고 과정 전체를 요구하지 않고 결정과 근거, 다음 행동처럼 실제 UI에 쓰이는 내용만 받습니다. 긴 보고서는 먼저 개요 승인을 받은 뒤 필요한 절만 생성하면 낭비와 수정 비용을 함께 줄일 수 있습니다.
에이전트에는 행동 예산이 필요하다
에이전트는 목표를 달성하려고 검색과 도구 호출을 반복합니다. 종료 조건이 모호하면 품질 향상 없이 비용만 누적될 수 있습니다. 요청마다 최대 모델 호출 수, 도구 호출 수, 검색 문서 수, 실행 시간과 비용 상한을 둬야 합니다.
예산이 임계치에 가까워지면 더 작은 모델로 무조건 바꾸기보다, 현재까지의 결과를 요약해 사람에게 넘기거나 추가 예산 승인을 요청합니다. 중요한 것은 비용 초과가 조용히 일어나지 않게 하는 것입니다. 실패 재시도에도 지수 백오프와 총 횟수 제한, 멱등성 키를 적용합니다.
품질 게이트 없이 최적화하면 비용이 다른 곳으로 이동한다
비용 최적화 실험은 반드시 품질 평가와 함께 진행해야 합니다. 모델 교체, 컨텍스트 축약, 캐시 적용, 출력 길이 제한 전후에 동일한 평가 세트를 실행합니다. 정확도뿐 아니라 근거 충실도, 정책 위반, 포맷 성공률, 도구 선택, 사용자 재질문과 상담원 이관을 봅니다.
온라인에서는 일부 트래픽에 새 경로를 적용해 실제 성공률과 비용을 비교합니다. 평균만 보면 중요한 고객이나 어려운 질문의 품질 저하가 숨을 수 있으므로 업무 유형·언어·고객군·위험 등급별로 나눠 봅니다. 기준을 넘지 못하면 자동으로 기존 경로로 되돌릴 수 있어야 합니다.
AI 단위 경제성 플라이휠
운영팀은 비용 대시보드만 보고 끝내지 않습니다. 비용이 급증한 기능을 찾고, 요청 샘플에서 원인을 분류하고, 라우팅·검색·캐시·UX 가설을 세웁니다. 평가 환경에서 품질을 검증한 후 일부 트래픽에 적용하고, 업무 성과당 비용이 개선됐는지 확인합니다. 결과가 좋으면 확대하고 나쁘면 되돌립니다.
이 과정에서 개발, 제품, 재무, 현업이 같은 지표를 봐야 합니다. 재무팀은 청구액을, 개발팀은 토큰을, 현업은 처리시간을 따로 보면 의사결정이 엇갈립니다. ‘검증된 계약서 한 건당 비용’처럼 공통 단위를 정하면 기술 변경이 사업에 어떤 의미인지 설명할 수 있습니다.
대시보드에 보여줄 숫자
- 기능·고객·환경별 총비용과 예산 대비 사용률
- 성공한 업무 한 건당 총비용과 절감액
- 입력·캐시·출력·도구·검색·사람 검토의 비용 구성
- 모델별 첫 시도 성공률과 상위 모델 승격률
- 캐시 적중률, 컨텍스트 중복률, 평균 입력 길이
- 재시도율, 중복 실행률, 실패 요청이 소비한 비용
- 응답 지연시간과 품질 기준 통과율
알림도 일일 비용 하나만 기준으로 만들지 않습니다. 특정 기능의 요청당 비용이 평소보다 급증하거나, 캐시 적중률이 급락하거나, 승격률이 늘어나는 변화가 더 빠른 이상 신호일 수 있습니다.
30일 실행 계획
1주차: 비용을 요청에 붙인다
모든 모델·검색·도구 호출에 공통 요청 ID와 제품·기능·고객 태그를 넣습니다. 공급자 응답의 사용량을 원가 이벤트로 정규화하고 최종 업무 결과와 연결합니다.
2주차: 가장 큰 낭비 세 곳을 찾는다
전체 최적화를 시도하지 말고 비용 상위 기능, 평균 컨텍스트가 긴 기능, 재시도가 많은 기능을 고릅니다. 실제 요청을 샘플링해 비용이 필요한 것인지 낭비인지 분류합니다.
3주차: 한 가지씩 실험한다
모델 라우팅, 검색 문서 축소, 프롬프트 캐시, 출력 스키마, 비동기 배치 중 하나만 바꿉니다. 동시에 여러 요소를 바꾸면 무엇이 품질과 비용에 영향을 줬는지 알기 어렵습니다.
4주차: 예산과 품질 게이트를 운영에 넣는다
기능별 월·일·요청 예산을 설정하고 임계치 알림과 안전한 제한 동작을 만듭니다. 평가 기준을 통과한 최적화만 확대하고, 단위 경제성 대시보드를 제품 회의에 포함합니다.
네이처프랙탈이 제안하는 접근
네이처프랙탈은 AI 비용 최적화를 API 가격 비교로 시작하지 않습니다. 먼저 업무 성공 조건과 품질 기준을 정하고, 모델·RAG·도구·인프라의 사용량을 하나의 요청으로 추적합니다. 그 다음 실제 트래픽을 기준으로 라우팅과 캐시, 컨텍스트, 비동기 처리 구조를 설계합니다.
PoC 단계부터 이 계측을 넣으면 운영 전환 시 비용을 예측하기 쉽고, 모델 제공자가 바뀌어도 판단 기준이 남습니다. 결국 좋은 AI 아키텍처는 가장 비싼 모델을 많이 쓰는 구조도, 가장 싼 모델만 쓰는 구조도 아닙니다. 업무의 난이도와 가치에 맞는 계산을 필요한 만큼만 사용하는 구조입니다.
실무 체크리스트
- 토큰 비용을 최종 업무 성공 여부와 연결하고 있는가?
- 프로젝트·기능·고객·환경별 비용 배분이 가능한가?
- 모든 요청을 최고급 모델로 보내고 있지 않은가?
- RAG가 관련 없는 문서와 오래된 문서를 반복 전송하지 않는가?
- 반복되는 시스템 지침과 공통 문서의 캐시 적중률을 측정하는가?
- 실시간이 필요 없는 대량 작업을 비동기로 분리했는가?
- 에이전트의 호출·시간·비용 예산과 중단 조건이 있는가?
- 비용 절감 실험 전후에 동일한 품질 평가를 실행하는가?
