19장. 클라우드 AI 비용 최적화

1. AI 기능은 만들기보다 운영 비용 관리가 어렵다

앞 장에서는 AWS, Google Cloud, Azure 같은 클라우드 AI 선택지를 살펴보았다.

클라우드 AI를 사용하면 모델을 직접 설치하지 않고도 AI 기능을 빠르게 만들 수 있다.
고객 문의 요약, 문서 검색 챗봇, 장애 로그 분석, 코드 리뷰 보조 같은 기능을 API 호출만으로 시작할 수 있다.

하지만 운영 환경으로 들어가면 새로운 문제가 생긴다.

바로 비용이다.

AI 기능은 처음에는 비용이 작아 보인다.

개발자 몇 명이 테스트한다.
→ 하루 요청 수가 많지 않다.
→ 비용이 거의 안 나오는 것처럼 보인다.

하지만 실제 서비스에 붙이면 상황이 달라진다.

관리자 100명이 매일 고객 문의를 요약한다.
사용자 10,000명이 챗봇에 질문한다.
문서 검색 AI가 질문마다 여러 문서를 함께 보낸다.
장애 로그 분석이 긴 로그를 매번 AI에 전달한다.

이렇게 되면 AI 비용은 빠르게 증가할 수 있다.

특히 LLM API는 대부분 사용량 기반 과금이다.
요청을 많이 할수록, 입력이 길수록, 답변이 길수록 비용이 늘어난다.

일반 API는 호출 1회당 비용을 대략적으로 예측하기 쉬운 편이다.
하지만 AI API는 같은 1회 호출이라도 입력과 출력 길이에 따라 비용이 크게 달라질 수 있다.

예를 들어 같은 “요약해줘” 요청이라도 다음 두 경우는 비용이 다르다.

짧은 문의 1건 요약:
입력 500 tokens
출력 100 tokens

긴 상담 내역 전체 요약:
입력 20,000 tokens
출력 1,500 tokens

둘 다 요청 수는 1건이다. 하지만 토큰 사용량은 완전히 다르다.

그래서 클라우드 AI 비용 최적화의 핵심은 단순히 “요청 수를 줄이는 것”이 아니다.

- 어떤 입력을 AI에게 보낼 것인가
- 어떤 모델을 사용할 것인가
- 답변 길이를 어디까지 허용할 것인가
- 반복 요청을 어떻게 줄일 것인가
- 어떤 기능에 고성능 모델을 쓸 것인가
- 사용량 제한을 어디에서 걸 것인가

이 장에서는 클라우드 AI를 운영할 때 비용을 어떻게 이해하고, 어떻게 줄이며, 어떻게 폭증을 막을 수 있는지 살펴본다.

2. AI API 비용은 토큰에서 시작한다

LLM 기반 AI API 비용을 이해하려면 먼저 토큰을 알아야 한다.

토큰은 AI 모델이 텍스트를 처리하는 기본 단위다.
한글, 영어, 숫자, 기호가 내부적으로 토큰 단위로 나뉘어 모델에 입력된다.

정확히 몇 글자가 몇 토큰인지는 모델마다 다르다.
하지만 실무에서는 이렇게 이해해도 충분하다.

입력이 길수록 입력 토큰이 늘어난다.
답변이 길수록 출력 토큰이 늘어난다.
토큰이 늘어나면 비용도 늘어난다.

AI API 비용은 보통 다음 두 가지로 나뉜다.

입력 토큰 비용:
AI에게 보내는 프롬프트, 사용자 질문, 문서 내용, 대화 이력

출력 토큰 비용:
AI가 생성하는 답변

예를 들어 고객 문의 요약 요청을 생각해보자.

프롬프트:
아래 고객 문의를 3문장 이내로 요약해줘.

고객 문의:
하트를 충전했는데 반영이 안 됩니다.
결제 문자는 받았고 카드 승인도 된 것 같습니다.

이 요청의 입력 토큰에는 지시문과 고객 문의 내용이 모두 포함된다.
AI가 생성한 요약문은 출력 토큰에 해당한다.

RAG에서는 입력 토큰이 더 커질 수 있다.

사용자 질문:
환불 정책 알려줘.

검색된 문서:
환불 정책 문서 chunk 5개

AI에게 전달되는 입력:
사용자 질문 + 검색된 문서 5개 + 답변 지시문

사용자 질문은 짧아도, 검색된 문서가 길면 입력 토큰이 크게 증가한다.

대화형 챗봇도 마찬가지다.

이전 대화 이력을 계속 함께 보내면 입력 토큰이 누적된다.

1번째 질문:
입력 300 tokens

5번째 질문:
이전 대화 포함 입력 3,000 tokens

20번째 질문:
이전 대화 포함 입력 15,000 tokens

그래서 AI 비용 최적화는 토큰을 줄이는 일에서 시작한다.

토큰은 AI 모델이 텍스트를 처리하는 단위다.
클라우드 AI 비용은 보통 입력 토큰과 출력 토큰 사용량에 따라 계산된다.

3. 요청 수만 보면 비용을 예측할 수 없다

일반적인 외부 API는 요청 수가 비용의 핵심인 경우가 많다.

예를 들어 문자 발송 API라면 메시지 1건당 비용을 계산할 수 있다.
지도 API도 호출 수 기준으로 비용을 추정할 수 있다.

하지만 AI API는 요청 수만으로는 부족하다.

같은 1회 요청이라도 입력과 출력 길이에 따라 비용이 크게 달라진다.

예를 들어 다음 두 요청을 비교해보자.

요청 A:
"이 문장을 공손하게 바꿔줘."
입력 50 tokens
출력 50 tokens

요청 B:
"아래 30페이지 장애 보고서를 요약해줘."
입력 40,000 tokens
출력 2,000 tokens

둘 다 요청은 1회다. 하지만 비용은 요청 B가 훨씬 크다.

따라서 AI 비용을 추적할 때는 최소한 다음 값을 기록해야 한다.

- 요청 수
- 입력 토큰 수
- 출력 토큰 수
- 총 토큰 수
- 모델명
- 기능명
- 사용자 또는 관리자 ID
- 응답 시간
- 성공/실패 여부

요청 수만 기록하면 이런 질문에 답하기 어렵다.

왜 이번 달 AI 비용이 늘었는가?
어떤 기능이 비용을 많이 쓰는가?
입력 문서가 너무 긴가?
답변이 너무 길게 생성되고 있는가?
특정 사용자가 비정상적으로 많이 쓰는가?
고성능 모델을 너무 많이 쓰고 있는가?

반대로 토큰과 모델을 함께 기록하면 비용 원인을 찾을 수 있다.

예를 들어 다음과 같은 로그가 있다고 해보자.

{
  "feature": "rag_document_chat",
  "model": "high-quality-model",
  "inputTokens": 18000,
  "outputTokens": 1200,
  "latencyMs": 8500,
  "status": "success"
}

이 로그를 보면 문서 검색 챗봇에서 입력 토큰이 크다는 것을 알 수 있다.

이 경우 최적화 방향은 다음일 수 있다.

- 검색된 chunk 수를 줄인다.
- chunk 크기를 조정한다.
- 질문과 관련성이 낮은 문서는 제외한다.
- 답변 길이를 제한한다.
- 자주 묻는 질문은 캐싱한다.

AI 비용 최적화는 감으로 하면 어렵다.
요청 수, 토큰 수, 모델명, 기능명을 기록해야 실제 원인을 분석할 수 있다.

4. 토큰 비용을 계산하는 기본 방식

AI 비용을 정확히 계산하려면 각 모델의 단가를 알아야 한다.
모델마다 입력 토큰과 출력 토큰의 단가가 다를 수 있다.

하지만 여기서는 특정 서비스 단가를 외우기보다 계산 방식을 이해하는 데 집중하자.

기본 구조는 다음과 같다.

총 비용 =
입력 토큰 비용
+ 출력 토큰 비용

예를 들어 어느 모델의 단가가 다음과 같다고 가정해보자.

입력 1,000,000 tokens당 1달러
출력 1,000,000 tokens당 3달러

어떤 기능이 하루에 다음만큼 사용된다고 해보자.

하루 요청 수: 10,000건
요청당 평균 입력 토큰: 1,500
요청당 평균 출력 토큰: 300

하루 입력 토큰은 다음과 같다.

10,000 × 1,500 = 15,000,000 tokens

하루 출력 토큰은 다음과 같다.

10,000 × 300 = 3,000,000 tokens

비용은 다음처럼 계산할 수 있다.

입력 비용:
15,000,000 / 1,000,000 × 1달러 = 15달러

출력 비용:
3,000,000 / 1,000,000 × 3달러 = 9달러

하루 총 비용:
24달러

한 달이면 대략 다음과 같다.

24달러 × 30일 = 720달러

이 정도면 감당 가능해 보일 수 있다.

하지만 요청 수나 입력 길이가 늘어나면 비용이 빠르게 증가한다.

하루 요청 수 100,000건
요청당 평균 입력 5,000 tokens
요청당 평균 출력 800 tokens

이 경우 입력 토큰은 하루 5억 tokens가 된다.

100,000 × 5,000 = 500,000,000 tokens

대규모 서비스에서는 작은 프롬프트 차이도 월 비용에 큰 영향을 줄 수 있다.

그래서 AI 기능을 만들 때는 기능별로 예상 사용량을 계산해보는 것이 좋다.

비용 계산은 처음부터 완벽할 필요는 없다.
하지만 기능을 열기 전에 대략적인 규모를 추정해야 한다.

5. 긴 프롬프트는 비용을 증가시킨다

프롬프트는 AI에게 일을 시키는 지시문이다.

프롬프트가 구체적이면 답변 품질이 좋아질 수 있다.
하지만 너무 길면 비용과 응답 시간이 늘어난다.

예를 들어 모든 요청에 아래와 같은 긴 공통 프롬프트를 붙인다고 해보자.

너는 20년 경력의 시니어 백엔드 개발자이며,
보안, 성능, 확장성, 유지보수성, 테스트 가능성,
클린 아키텍처, 도메인 주도 설계, 장애 대응,
운영 비용, 데이터 보호, 개인정보보호법,
클라우드 네이티브 아키텍처를 모두 고려해서...

한두 번 사용할 때는 큰 문제가 아닐 수 있다.
하지만 하루 수만 번 호출되는 기능이라면 공통 프롬프트의 길이도 비용에 영향을 준다.

좋은 프롬프트는 길기만 한 프롬프트가 아니다.

좋은 프롬프트는 목적이 명확하고, 불필요한 문장이 적으며, 출력 형식이 분명한 프롬프트다.

예를 들어 고객 문의 요약 기능에는 다음 정도면 충분할 수 있다.

너는 고객 문의를 요약하는 상담 지원 도구다.
아래 문의를 3문장 이내로 요약해라.

조건:
- 개인정보는 포함하지 않는다.
- 추정하지 않는다.
- 고객이 겪는 문제를 먼저 작성한다.

프롬프트 최적화에서 중요한 것은 다음이다.

- 기능에 필요 없는 역할 설명을 줄인다.
- 반복되는 긴 지시문을 간결하게 만든다.
- 출력 형식을 명확히 한다.
- 예시는 꼭 필요한 경우에만 넣는다.
- 매 요청마다 넣지 않아도 되는 정보는 제거한다.

물론 무조건 짧게만 쓰면 안 된다.

프롬프트를 너무 줄이면 AI가 원하는 방식으로 답하지 않을 수 있다.

따라서 비용과 품질 사이에서 균형을 잡아야 한다.

너무 짧은 프롬프트:
비용은 낮지만 품질이 불안정할 수 있음

너무 긴 프롬프트:
품질은 좋아질 수 있지만 비용과 지연시간 증가

좋은 프롬프트:
필요한 조건은 포함하되 불필요한 설명은 줄임

프롬프트도 코드처럼 개선해야 한다.
실제 요청 로그를 보면서 입력 토큰과 답변 품질을 함께 확인해야 한다.

6. 대화 이력을 무제한 보내면 비용이 커진다

챗봇을 만들 때는 대화 이력을 관리해야 한다.

사용자가 이전에 무엇을 말했는지 알아야 자연스럽게 이어서 답할 수 있기 때문이다.

하지만 이전 대화를 계속 모두 보내면 입력 토큰이 계속 늘어난다.

예를 들어 사용자가 30분 동안 AI 챗봇과 대화한다고 해보자.

1번째 요청:
현재 질문만 전달

5번째 요청:
이전 대화 4개 + 현재 질문 전달

20번째 요청:
이전 대화 19개 + 현재 질문 전달

50번째 요청:
이전 대화 49개 + 현재 질문 전달

이렇게 하면 뒤로 갈수록 요청 하나당 비용이 커진다.

더 큰 문제는 컨텍스트 한도다.

모델은 한 번에 참고할 수 있는 입력 길이에 제한이 있다.
대화 이력이 너무 길어지면 한도를 초과할 수 있다.

그래서 챗봇에서는 대화 이력 관리 전략이 필요하다.

대표적인 방식은 다음과 같다.

1. 최근 N개 메시지만 유지한다.
2. 오래된 대화는 요약해서 저장한다.
3. 중요한 사용자 설정만 별도로 유지한다.
4. 현재 질문과 관련 있는 이전 대화만 검색해서 넣는다.

예를 들어 고객센터 챗봇에서는 최근 대화는 그대로 유지하고, 오래된 내용은 요약할 수 있다.

이전 대화 요약:
사용자는 하트 충전 후 반영되지 않는 문제를 문의하고 있다.
결제 승인 문자는 받았으나 서비스 내 충전 내역은 보이지 않는다고 설명했다.

현재 질문:
그럼 언제 처리되나요?

이렇게 하면 긴 대화 전체를 넣지 않아도 문맥을 유지할 수 있다.

개발자용 AI 챗봇도 마찬가지다.

최근 메시지:
현재 디버깅 중인 코드와 에러 로그

요약 메시지:
이전에는 로그인 토큰 검증 문제를 확인했고,
현재는 refresh token 재발급 로직을 점검 중이다.

대화 이력을 줄이면 비용과 응답 속도를 모두 개선할 수 있다.

다만 너무 많이 줄이면 AI가 문맥을 잃을 수 있다.
따라서 기능별로 적절한 기준을 정해야 한다.

7. RAG에서는 검색된 문서 수가 비용을 좌우한다

RAG는 문서 기반 답변을 만들 때 유용하다.

하지만 RAG는 입력 토큰이 커지기 쉬운 구조다.

사용자 질문 자체는 짧아도, 검색된 문서를 함께 AI에게 전달하기 때문이다.

예를 들어 사용자가 이렇게 질문했다고 해보자.

환불 정책 알려줘.

이 질문은 짧다.

하지만 검색 결과로 다음 문서 chunk를 10개 넣는다면 입력은 길어진다.

- 환불 정책 개요 chunk
- 결제 취소 기준 chunk
- 미성년자 결제 환불 chunk
- 하트 사용 후 환불 불가 chunk
- 정기결제 취소 chunk
- 고객센터 처리 절차 chunk
- 환불 예외 케이스 chunk
- PG사 승인 취소 chunk
- 운영자 승인 기준 chunk
- 관련 법무 검토 chunk

관련 없는 문서까지 많이 넣으면 비용이 증가할 뿐 아니라 답변 품질도 떨어질 수 있다.

AI가 너무 많은 정보를 받으면 핵심을 놓치거나, 서로 다른 문서 내용을 섞어서 답할 수 있다.

RAG 비용 최적화의 핵심은 “필요한 문서만 넣는 것”이다.

좋지 않은 방식:
검색 결과 상위 20개 chunk를 모두 넣는다.

좋은 방식:
관련성 높은 3~5개 chunk만 넣는다.

물론 항상 3개가 정답은 아니다.
질문이 복잡하면 더 많은 문서가 필요할 수 있다.

하지만 기본 원칙은 분명하다.

AI에게 넣는 문서가 많을수록 비용이 증가한다.
문서가 많다고 답변이 항상 좋아지는 것은 아니다.

RAG 비용을 줄이는 방법은 다음과 같다.

- 검색 결과 개수를 제한한다.
- 관련성 점수가 낮은 chunk는 제외한다.
- 중복 chunk를 제거한다.
- 최신 문서나 우선순위 높은 문서를 먼저 사용한다.
- 긴 문서는 요약본을 먼저 사용한다.
- 질문 유형에 따라 검색 범위를 좁힌다.

예를 들어 질문이 고객센터 환불 정책에 관한 것이라면 전체 사내 문서를 검색할 필요가 없다.

나쁜 검색 범위:
전체 사내 문서

좋은 검색 범위:
고객센터 정책 문서 + 결제/환불 문서

검색 범위를 줄이면 검색 품질도 좋아지고, AI에게 전달하는 문서 양도 줄일 수 있다.

8. 캐싱 전략으로 반복 비용을 줄이기

AI 기능에는 반복 요청이 많이 발생할 수 있다.

예를 들어 사용자가 같은 질문을 여러 번 할 수 있다.

환불 정책 알려줘.
하트 환불 기준 알려줘.
충전 취소는 어떻게 해?

표현은 다르지만 같은 문서를 기반으로 비슷한 답변을 만들 수 있다.

또 관리자 도구에서는 같은 고객 문의를 여러 번 요약할 수도 있다.

상담원 A가 요약 생성
상담원 B가 같은 문의에서 다시 요약 생성
관리자가 같은 문의에서 다시 요약 생성

이때 매번 AI API를 호출하면 비용이 낭비된다.

캐싱을 사용하면 반복 비용을 줄일 수 있다.

가장 단순한 캐싱은 같은 입력에 대해 같은 결과를 재사용하는 것이다.

입력 내용 + 프롬프트 버전 + 모델명
→ 캐시 키 생성
→ 기존 결과가 있으면 재사용
→ 없으면 AI 호출

예를 들어 고객 문의 요약 기능에서는 다음 기준으로 캐시할 수 있다.

문의 ID
문의 수정 시각
프롬프트 버전
모델명

문의 내용이 바뀌지 않았고 프롬프트도 같다면 기존 요약을 재사용할 수 있다.

같은 문의 요약 요청
→ 기존 요약 결과 반환
→ AI API 호출 없음

RAG에서도 일부 캐싱이 가능하다.

- 자주 묻는 질문의 답변 캐싱
- 질문 임베딩 캐싱
- 문서 검색 결과 캐싱
- 생성된 답변 캐싱

하지만 AI 캐싱에는 주의할 점도 있다.

- 문서가 바뀌면 캐시를 무효화해야 한다.
- 권한이 다른 사용자에게 같은 답변을 재사용하면 안 된다.
- 개인정보가 포함된 응답을 다른 사용자에게 보여주면 안 된다.
- 모델이나 프롬프트가 바뀌면 결과도 달라질 수 있다.

특히 RAG에서는 권한이 중요하다.

사용자 A가 볼 수 있는 문서와 사용자 B가 볼 수 있는 문서가 다르다면, 같은 질문이라도 같은 캐시를 공유하면 안 된다.

나쁜 캐시:
질문 텍스트만 기준으로 캐싱

좋은 캐시:
질문 + 사용자 권한 범위 + 문서 버전 + 프롬프트 버전 기준으로 캐싱

캐싱은 비용을 줄이는 좋은 방법이지만, 권한과 최신성을 함께 고려해야 한다.

9. 모델 라우팅으로 비용과 품질을 조절하기

모든 AI 작업에 가장 비싼 모델을 사용할 필요는 없다.

AI 모델은 성능, 속도, 비용이 다르다.

어떤 모델은 복잡한 추론에 강하고, 어떤 모델은 빠르고 저렴하다.
어떤 모델은 코드 분석에 강하고, 어떤 모델은 간단한 분류에 충분하다.

따라서 기능별로 적절한 모델을 선택해야 한다.

예를 들어 다음처럼 나눌 수 있다.

이렇게 요청의 성격에 따라 모델을 선택하는 구조를 모델 라우팅이라고 한다.

요청 기능 확인
→ 데이터 민감도 확인
→ 품질 요구 수준 확인
→ 비용 기준 확인
→ 적절한 모델 선택

예를 들어 고객 문의 분류는 저렴한 모델로 충분할 수 있다.

입력:
하트를 충전했는데 반영이 안 됩니다.

출력:
{
  "category": "payment",
  "priority": "high"
}

이 작업은 복잡한 추론보다 안정적인 분류가 중요하다.
고성능 모델을 매번 쓸 필요가 없을 수 있다.

반면 장애 분석은 더 좋은 모델이 필요할 수 있다.

입력:
복잡한 로그, 배포 이력, 에러 메시지

출력:
가능한 원인, 확인 항목, 임시 대응 방안

이 작업은 추론 품질이 중요하므로 더 좋은 모델을 사용할 수 있다.

모델 라우팅 구조는 다음과 같이 만들 수 있다.

function selectModel({feature, inputLength, sensitivity}) {
    if (sensitivity === "high") {
        return "local-model";
    }

    if (feature === "simple_classification") {
        return "fast-cheap-model";
    }

    if (feature === "incident_analysis") {
        return "high-quality-model";
    }

    if (inputLength > 20000) {
        return "long-context-model";
    }

    return "default-model";
}

모델 라우팅을 잘 설계하면 비용과 품질을 함께 관리할 수 있다.

간단한 작업:
저렴한 모델로 비용 절감

어려운 작업:
고성능 모델로 품질 확보

민감한 작업:
로컬 또는 제한된 환경에서 처리

핵심은 모든 요청을 같은 모델로 보내지 않는 것이다.

10. 저렴한 모델과 고성능 모델을 분리하기

AI 모델을 선택할 때 흔히 하는 실수는 하나의 모델로 모든 기능을 처리하려는 것이다.

처음에는 편하다.

모든 AI 기능
→ 같은 고성능 모델 사용

하지만 운영에서는 비용이 커질 수 있다.

예를 들어 다음 기능이 모두 같은 고성능 모델을 사용한다고 해보자.

- 고객 문의 분류
- 짧은 문장 요약
- 관리자 공지 초안
- 장애 로그 분석
- 코드 리뷰
- 문서 검색 챗봇

이 중 일부는 고성능 모델이 필요하지 않다.

고객 문의 분류나 짧은 요약은 저렴한 모델로도 충분할 수 있다.
반면 장애 분석이나 코드 리뷰는 더 좋은 모델이 필요할 수 있다.

따라서 모델을 역할별로 나누는 것이 좋다.

저비용 모델:
분류, 태깅, 짧은 요약, 간단한 문장 변환

중간급 모델:
고객 문의 요약, 문서 초안, 일반 챗봇

고성능 모델:
장애 분석, 코드 리뷰, 복잡한 정책 질의, 임원 보고서 초안

로컬 모델:
민감 정보 처리, 내부망 전용 작업

이렇게 나누면 비용을 크게 줄일 수 있다.

예를 들어 하루 요청 100,000건 중 80,000건이 단순 분류라면, 이 작업을 저렴한 모델로 보내는 것만으로도 비용 절감 효과가 크다.

전체 요청 100,000건

단순 분류 80,000건:
저렴한 모델 사용

복잡한 분석 20,000건:
고성능 모델 사용

모델 분리는 품질 관리에도 도움이 된다.

각 기능에 맞는 평가 기준을 따로 만들 수 있기 때문이다.

분류 모델 평가:
정확한 category를 반환하는가?

요약 모델 평가:
핵심 내용을 빠뜨리지 않는가?

장애 분석 모델 평가:
근거 없는 원인 단정을 하지 않는가?

코드 리뷰 모델 평가:
실제 위험 코드를 잘 찾아내는가?

비용 최적화는 단순히 싼 모델을 쓰는 것이 아니다.
기능에 맞는 모델을 쓰는 것이다.

11. 답변 길이를 제한해야 한다

출력 토큰도 비용이다.

AI가 길게 답할수록 비용이 증가한다.
또 응답 시간이 길어지고, 사용자가 읽기 어려울 수도 있다.

따라서 AI 기능에서는 답변 길이를 제한하는 것이 중요하다.

예를 들어 고객 문의 요약 기능에서 다음과 같이 요청하면 답변이 길어질 수 있다.

아래 고객 문의를 자세히 분석해줘.

이 표현은 너무 넓다.

AI가 문의 요약, 원인 추정, 상담 대응, 추가 확인 항목까지 길게 쓸 수 있다.

반면 다음처럼 제한하면 비용과 품질을 모두 관리하기 쉽다.

아래 고객 문의를 3문장 이내로 요약해줘.
추정하지 말고, 고객이 겪는 문제를 먼저 작성해.

또는 JSON으로 제한할 수도 있다.

{
  "summary": "3문장 이내 요약",
  "category": "payment | login | refund | other",
  "priority": "low | medium | high"
}

API 옵션에서도 출력 토큰 제한을 설정해야 한다.

{
  "max_tokens": 300
}

프롬프트와 API 옵션을 함께 쓰는 것이 좋다.

프롬프트:
3문장 이내로 작성해라.

API 옵션:
max_tokens를 300으로 제한한다.

답변 길이 제한은 다음 효과가 있다.

- 출력 토큰 비용 감소
- 응답 속도 개선
- UI에 맞는 길이 유지
- 불필요한 장황함 감소
- 응답 검증이 쉬워짐

특히 관리자 도구에서는 길고 멋진 답변보다 짧고 바로 쓸 수 있는 답변이 더 유용할 때가 많다.

나쁜 답변:
고객의 상황을 여러 가능성으로 길게 설명

좋은 답변:
결제는 완료되었으나 하트가 반영되지 않았다고 문의함.
결제 승인 여부와 충전 반영 상태 확인이 필요함.

AI 답변은 길수록 좋은 것이 아니다.
기능 목적에 맞는 길이가 가장 좋다.

12. 입력 데이터를 줄이는 방법

입력 토큰을 줄이려면 AI에게 보내는 데이터를 줄여야 한다.

하지만 무작정 줄이면 필요한 정보가 빠질 수 있다.

중요한 것은 “필요한 정보만 보내는 것”이다.

예를 들어 장애 로그 분석 기능을 생각해보자.

나쁜 방식은 하루치 로그 전체를 AI에게 보내는 것이다.

전체 로그 10MB
→ 그대로 AI에게 전달
→ 비용 증가
→ 응답 지연
→ 중요한 부분이 묻힘

좋은 방식은 먼저 시스템이 필터링하는 것이다.

1. 에러 로그만 추출
2. 특정 시간대 로그만 선택
3. 중복 로그 제거
4. 관련 요청 ID 로그만 묶기
5. AI에게 핵심 로그만 전달

예를 들어 다음처럼 줄일 수 있다.

전체 로그:
10MB

필터링 후:
결제 API timeout 관련 로그 30줄
배포 시각
에러 발생 시각
관련 요청 ID

AI에게는 이 정도가 더 유용할 수 있다.

고객 문의 요약에서도 마찬가지다.

보낼 필요 없는 정보:
- 내부 상담원 메모 전체
- 고객 전화번호
- 이메일 주소
- 결제 승인번호 전체
- HTML 태그
- 중복 인용문

보내야 하는 정보:
- 고객이 겪는 문제
- 발생 시각
- 서비스 내 처리 상태
- 상담원이 확인해야 할 항목

문서 요약도 전체 문서를 매번 보내기보다 구조화해서 줄일 수 있다.

긴 문서 전체
→ 목차 추출
→ 관련 섹션만 선택
→ 선택된 섹션 요약

입력 데이터를 줄이는 방법은 다음과 같다.

- 불필요한 HTML, Markdown 장식 제거
- 중복 내용 제거
- 개인정보 마스킹
- 관련 없는 필드 제거
- 최근 데이터만 전달
- 검색으로 관련 문서만 선택
- 긴 데이터는 먼저 요약 후 전달

AI에게 많이 보내는 것이 항상 좋은 것은 아니다.
정리된 입력을 보내는 것이 비용과 품질 모두에 좋다.

13. 사용량 제한과 과금 보호

AI 기능은 반드시 사용량 제한이 필요하다.

제한 없이 열어두면 비용이 예측하기 어려워진다.

특히 다음 상황은 위험하다.

- 사용자가 버튼을 반복 클릭한다.
- 봇이 AI API를 계속 호출한다.
- 긴 문서를 반복 업로드한다.
- 자동화 작업이 무한 반복된다.
- 장애로 재시도가 계속 발생한다.
- 특정 사용자가 비정상적으로 많이 사용한다.

사용량 제한은 여러 단계에서 걸 수 있다.

프론트엔드:
- 버튼 중복 클릭 방지
- 입력 길이 제한
- 진행 중 재요청 차단

백엔드:
- 사용자별 요청 횟수 제한
- IP별 요청 제한
- 기능별 사용량 제한
- 입력 크기 제한
- 최대 출력 길이 제한

운영 정책:
- 일별 예산
- 월별 예산
- 부서별 사용량 제한
- 관리자 승인 필요한 고비용 기능

예를 들어 다음과 같은 정책을 둘 수 있다.

일반 사용자:
하루 AI 질문 30회

상담원:
하루 고객 문의 요약 300회

관리자:
하루 장애 분석 50회

긴 문서 요약:
관리자만 사용 가능

월 예산 80% 초과:
알림 발송

월 예산 100% 초과:
일부 고비용 기능 제한

사용량 제한은 사용자 경험과 충돌할 수 있다.

그래서 제한 메시지도 중요하다.

나쁜 예시는 다음과 같다.

요청 실패

좋은 예시는 다음과 같다.

오늘 사용할 수 있는 AI 요약 횟수를 모두 사용했습니다.
내일 다시 시도하거나 관리자에게 사용량 증설을 요청해주세요.

또는 관리자 화면에서는 더 구체적으로 보여줄 수 있다.

이번 달 AI 사용량이 예산의 85%에 도달했습니다.
고비용 문서 요약 기능은 제한될 수 있습니다.

과금 보호는 단순히 돈을 아끼기 위한 기능이 아니다.
예상치 못한 사용량 폭증이 서비스 장애나 운영 리스크로 이어지는 것을 막는 안전장치다.

14. 재시도 정책도 비용에 영향을 준다

AI API가 실패하면 재시도를 할 수 있다.

일시적인 네트워크 오류나 timeout은 재시도로 해결될 수 있다.

하지만 재시도도 비용과 관련이 있다.

AI 요청이 실패했지만 실제로 모델이 일부 처리했을 수도 있고, 재시도 요청 자체가 다시 비용을 발생시킬 수도 있다.

예를 들어 하나의 요청에 대해 최대 3번 재시도한다고 해보자.

원래 요청 1회
+ 재시도 3회
= 최대 4회 호출

사용자 한 명에게는 큰 문제가 아닐 수 있다.
하지만 요청량이 많은 서비스에서는 비용이 빠르게 증가한다.

재시도는 에러 유형에 따라 다르게 해야 한다.

재시도해도 되는 경우:
- 일시적인 네트워크 오류
- 순간적인 timeout
- 5xx 계열의 일시적 서버 오류

재시도하면 안 되는 경우:
- 인증 오류
- 권한 오류
- 요청 형식 오류
- 입력 길이 초과
- 사용량 제한 초과

재시도할 때는 횟수를 제한해야 한다.

최대 2회 재시도
전체 timeout 30초
재시도 간격은 점점 늘림
동일 작업 중복 실행 방지

비동기 작업에서는 중복 처리도 조심해야 한다.

예를 들어 고객 문의 요약 작업이 timeout으로 실패했다고 판단했지만, 실제로는 AI 응답이 늦게 도착했을 수 있다.
이때 같은 작업을 다시 실행하면 같은 문의에 대해 요약이 여러 번 생성될 수 있다.

그래서 작업 ID와 멱등성 처리가 필요하다.

멱등성은 같은 요청을 여러 번 실행해도 결과가 중복으로 처리되지 않도록 하는 성질이다.
결제, 포인트 지급, AI 작업 재시도처럼 중복 실행을 피해야 하는 곳에서 중요하다.

AI 재시도 정책은 안정성과 비용 사이의 균형이다.
무조건 많이 재시도하는 것은 좋은 전략이 아니다.

15. 비용 모니터링 대시보드 만들기

AI 기능을 운영한다면 비용을 볼 수 있는 대시보드가 필요하다.

월말 청구서를 보고 나서야 비용 증가를 알게 되면 늦다.

운영 중에 다음 정보를 확인할 수 있어야 한다.

- 일별 AI 요청 수
- 기능별 요청 수
- 모델별 요청 수
- 입력 토큰 사용량
- 출력 토큰 사용량
- 기능별 비용 추정치
- 사용자별 사용량
- 실패율
- 평균 응답 시간

예를 들어 대시보드는 다음처럼 구성할 수 있다.

대시보드에서 특히 중요한 것은 기능별 비용이다.

전체 AI 비용:
월 300만 원

기능별 분해:
고객 문의 요약 80만 원
문서 검색 챗봇 150만 원
장애 분석 20만 원
코드 리뷰 50만 원

이렇게 보면 최적화 대상을 찾을 수 있다.

문서 검색 챗봇 비용이 높다면 다음을 확인한다.

- 검색 chunk를 너무 많이 넣고 있는가?
- 고성능 모델을 모든 질문에 쓰고 있는가?
- 사용자 질문마다 대화 이력을 너무 많이 넣고 있는가?
- 캐싱할 수 있는 질문이 많은가?

비용 모니터링은 개발팀만 보는 것이 아니다.

운영팀, 기획팀, 관리자도 이해할 수 있어야 한다.

AI 기능은 업무 효율을 높이기 위해 도입한다.
따라서 비용 대비 효과를 확인해야 한다.

고객 문의 요약 비용:
월 80만 원

절감 효과:
상담원 처리 시간 월 120시간 감소

판단:
비용 대비 효과 있음

반대로 비용은 큰데 사용자가 거의 쓰지 않는 기능이라면 개선하거나 중단해야 한다.

16. 비용 최적화가 품질 저하로 이어지면 안 된다

비용 최적화는 중요하다.

하지만 무조건 비용만 줄이면 AI 기능의 품질이 떨어질 수 있다.

예를 들어 다음과 같은 최적화는 위험할 수 있다.

- 너무 싼 모델로 모두 교체한다.
- 검색 문서를 너무 적게 넣는다.
- 답변 길이를 지나치게 줄인다.
- 대화 이력을 거의 제거한다.
- 재시도를 전부 없앤다.

이렇게 하면 비용은 줄어들 수 있다.

하지만 사용자는 AI 답변이 부실하다고 느낄 수 있다.

예를 들어 RAG에서 검색 문서를 5개에서 1개로 줄였다고 해보자.

비용:
감소

위험:
필요한 근거 문서를 못 넣어 답변 품질 저하

고성능 모델을 저렴한 모델로 바꾸는 것도 마찬가지다.

단순 분류:
저렴한 모델로 충분할 수 있음

장애 분석:
저렴한 모델로 바꾸면 원인 추정 품질이 낮아질 수 있음

따라서 비용 최적화는 반드시 품질 평가와 함께 해야 한다.

비용을 줄인 뒤에는 다음을 확인해야 한다.

- 정답률이 떨어지지 않았는가?
- 중요한 정보가 빠지지 않았는가?
- 사용자가 불만을 느끼지 않는가?
- 응답 시간이 개선되었는가?
- 환각이 늘어나지 않았는가?
- 문서 기반 답변에서 출처가 유지되는가?

좋은 비용 최적화는 품질을 유지하면서 낭비를 줄이는 것이다.

좋은 최적화:
관련 없는 문서 제거
중복 요청 캐싱
단순 작업은 저렴한 모델 사용
출력 길이 적절히 제한

나쁜 최적화:
필요한 근거 문서 제거
모든 작업을 저품질 모델로 통일
검증 없이 프롬프트 축소

AI 기능은 사용자가 신뢰해야 계속 사용한다.
비용을 줄이더라도 신뢰를 잃으면 의미가 없다.

17. 기능별 비용 최적화 예시

이제 몇 가지 기능을 기준으로 비용 최적화 방향을 정리해보자.

고객 문의 요약

고객 문의 요약은 비교적 최적화하기 쉬운 기능이다.

비용 증가 요인:
- 문의 원문이 너무 김
- 상담 이력 전체를 매번 전달
- 답변을 너무 길게 생성
- 같은 문의를 여러 번 요약

최적화 방법:
- 개인정보와 불필요한 필드 제거
- 최근 상담 내용만 전달
- 3문장 이내로 제한
- 문의 ID 기준 캐싱
- 중간급 또는 저비용 모델 사용

문서 검색 챗봇

RAG 기반 문서 검색 챗봇은 입력 토큰이 커지기 쉽다.

비용 증가 요인:
- 검색 chunk를 너무 많이 전달
- chunk 크기가 너무 큼
- 대화 이력을 계속 포함
- 고성능 모델만 사용
- 같은 질문 반복

최적화 방법:
- 관련성 높은 chunk만 전달
- 검색 결과 재정렬
- 질문 유형별 검색 범위 제한
- 자주 묻는 질문 캐싱
- 단순 질문은 저렴한 모델 사용

장애 로그 분석

장애 로그 분석은 입력 데이터가 길어지기 쉽다.

비용 증가 요인:
- 로그 전체를 그대로 전달
- 중복 에러 로그 포함
- 관련 없는 시간대 로그 포함
- 긴 분석 결과 생성

최적화 방법:
- 에러 로그만 추출
- 요청 ID 기준 로그 묶기
- 중복 로그 제거
- 시간 범위 제한
- 분석 결과를 항목별로 제한

코드 리뷰 보조

코드 리뷰는 변경 파일이 많을수록 비용이 증가한다.

비용 증가 요인:
- PR 전체 파일을 모두 전달
- 변경되지 않은 코드까지 포함
- 자동 생성 파일 포함
- 큰 lock 파일 포함
- 리뷰 코멘트가 너무 장황함

최적화 방법:
- diff 중심으로 전달
- 자동 생성 파일 제외
- 중요 파일 우선 분석
- 파일 크기 제한
- 보안/버그/테스트 관점으로 리뷰 범위 제한

기능마다 비용이 증가하는 원인이 다르다.
따라서 비용 최적화도 기능별로 다르게 접근해야 한다.

18. 클라우드 AI 비용 최적화 체크리스트

클라우드 AI 비용을 관리하려면 다음 항목을 점검하면 좋다.

이 체크리스트는 한 번만 보는 것이 아니다.

AI 기능이 늘어나면 주기적으로 확인해야 한다.

신규 AI 기능 출시 전
→ 예상 비용 계산

운영 시작 후
→ 실제 사용량 확인

비용 증가 감지
→ 기능별 원인 분석

최적화 적용 후
→ 품질 영향 확인

비용 최적화는 개발 후반에 붙이는 작업이 아니라, AI 기능 설계 단계부터 들어가야 한다.

19. 정리

클라우드 AI는 빠르게 AI 기능을 만들 수 있게 해준다.

하지만 운영 환경에서는 비용을 반드시 관리해야 한다.

AI API 비용은 요청 수만으로 결정되지 않는다.
입력 토큰, 출력 토큰, 사용하는 모델, 대화 이력, RAG 검색 문서 수, 재시도 횟수에 따라 비용이 달라진다.

비용을 줄이려면 먼저 기록해야 한다.

- 기능명
- 모델명
- 입력 토큰
- 출력 토큰
- 사용자 ID
- 응답 시간
- 성공/실패 여부

그다음 기능별로 최적화해야 한다.

고객 문의 요약은 입력 정제와 캐싱이 중요하다.
문서 검색 챗봇은 검색 chunk 수와 대화 이력 관리가 중요하다.
장애 로그 분석은 로그 필터링이 중요하다.
코드 리뷰는 diff 중심 분석과 파일 제외 규칙이 중요하다.

또한 모든 기능에 고성능 모델을 사용할 필요는 없다.
단순 분류는 저렴한 모델, 복잡한 분석은 고성능 모델, 민감 정보는 로컬 모델처럼 역할을 나누는 것이 좋다.

비용 최적화는 품질을 희생하는 작업이 아니다.
불필요한 입력, 중복 요청, 과도한 출력, 잘못된 모델 선택을 줄이는 작업이다.

이 장에서 기억해야 할 핵심은 하나다.

클라우드 AI 비용 최적화는 “AI를 덜 쓰는 것”이 아니라,
필요한 곳에 적절한 모델과 적절한 입력을 사용하도록 설계하는 일이다.

19장 핵심 요약