비용, 속도, 품질 최적화하기

데모와 제품의 차이

AI 기능이 한 번 잘 동작한다고 해서 바로 제품이 되지는 않습니다. 제품에서는 세 가지 질문에 답해야 합니다.

• 이 기능을 한 번 실행하는 데 얼마가 드는가?

• 사용자는 몇 초까지 기다릴 수 있는가?

• 이 작업에 필요한 품질은 어느 정도인가?

최적화의 목표는 무조건 가장 싼 모델을 쓰는 것이 아닙니다. 작업에 필요한 품질을 유지하면서 비용과 속도를 예측 가능하게 만드는 것입니다.

AI 생성 이미지

요청당 비용 계산하기

AI API 비용은 보통 입력 토큰과 출력 토큰으로 나누어 계산합니다. 입력 토큰은 시스템 메시지, 사용자 입력, 참고 문서, 예시가 차지합니다. 출력 토큰은 모델이 생성한 답변입니다.

기본 계산은 단순합니다.

요청당 비용 = 입력 토큰 비용 + 출력 토큰 비용
월간 비용 = 요청당 비용 × 월간 호출 수

실제 서비스에서는 기능별로 따로 계산해야 합니다. 예를 들어 제목 추천은 출력이 짧아 저렴하지만, 긴 문서 요약은 입력과 출력이 모두 길어집니다. 여기에 사용자 수, 사용자당 호출 빈도, 평균 출력 길이, 재시도 비율을 곱하면 월간 비용을 대략 예측할 수 있습니다.

1M 토큰당 가격을 기준으로 계산하면 기능별 손익분기점도 세울 수 있습니다. 무료 사용자는 하루 5회, 유료 사용자는 하루 100회처럼 사용량 제한을 정할 때도 이 계산이 기준이 됩니다.

속도는 하나의 숫자가 아니다

응답 속도는 두 가지로 나누어 봐야 합니다.

첫째는 사용자가 체감하는 지연 시간입니다. 스트리밍 화면에서는 첫 글자가 나오기까지의 시간, 즉 TTFT가 중요합니다. 둘째는 전체 응답이 끝나는 시간입니다. 전체 시간은 대략 다음처럼 볼 수 있습니다.

전체 응답 시간 = 첫 토큰 지연 시간 + 토큰 사이 시간 × 생성 토큰 수

따라서 출력이 길어지면 전체 시간이 늘어납니다. 성능이 나빠진 것이 아니라 답변을 더 많이 생성했기 때문에 느려졌을 수 있습니다. 스트리밍은 첫 반응을 빠르게 보여 주어 체감 대기 시간을 줄이지만, 전체 토큰을 생성하는 총량 자체를 줄이지는 않습니다.¹

운영 환경에서는 지연 시간과 처리량도 구분해야 합니다. 개별 사용자의 경험은 per-call latency와 TTFT에 좌우됩니다. 반면 서비스가 동시에 처리할 수 있는 규모는 TPM, 즉 분당 처리 토큰 수에 영향을 받습니다. 할당된 quota가 있다고 해서 실제 처리량이 항상 보장되는 것은 아니므로, 입력 토큰·출력 토큰·호출 수를 함께 모니터링해야 합니다.¹

모델은 가격만 보고 고르지 않는다

모델 선택에는 가격, 지능 지표, 출력 속도, TTFT, 컨텍스트 길이, 기능 지원 여부가 모두 들어갑니다. 예를 들어 빠른 첫 반응이 중요한 자동완성이나 짧은 답변 기능은 TTFT가 낮은 모델이 유리합니다. 대량 분류나 간단한 변환은 1M 토큰당 비용이 낮은 모델이 유리합니다.

공개 비교 자료에 따르면 GPT-4.1 nano는 낮은 첫 토큰 지연 시간이 강점으로 소개되고, GPT-5 nano는 낮은 1M 토큰당 비용이 강점으로 언급됩니다. 출력 속도가 중요한 작업에는 GPT-5 Codex처럼 tokens/sec가 높은 모델을 검토할 수 있고, 복잡한 추론이나 최종 검수에는 GPT-5.5처럼 지능 지표가 높은 모델을 고려할 수 있습니다.²

핵심은 기능별로 모델을 다르게 쓰는 것입니다. 초안 작성, 분류, 태그 생성, 짧은 변환은 빠르고 저렴한 모델부터 시작합니다. 법률, 의료, 결제, 권한 변경처럼 실패 비용이 큰 판단은 더 강한 모델이나 별도의 검증 단계를 붙입니다.

캐시는 비용과 지연 시간을 동시에 줄인다

같은 입력과 같은 설정으로 반복 호출한다면 다시 모델을 부를 필요가 없습니다. 캐시 키에는 최소한 다음 값이 들어가야 합니다.

• 프롬프트 템플릿 해시

• 사용자 입력 해시

• 모델명

• temperature 같은 생성 파라미터

• 스키마 버전

• 사용자 권한 또는 요금제 범위

사용자별로 결과가 달라질 수 있는 기능은 전역 캐시를 쓰면 안 됩니다. 예를 들어 개인 문서 요약은 사용자별 캐시가 필요합니다. 반대로 공개된 공지문 요약처럼 모두에게 같은 결과를 보여 줘도 되는 기능은 공유 캐시가 가능합니다.

캐시에는 만료 시간도 필요합니다. 뉴스 요약은 짧게, 고정 문서 요약은 길게 둘 수 있습니다. 오래된 결과가 사용자에게 피해를 줄 수 있다면 캐시보다 최신성이 우선입니다.

프롬프트를 줄이면 속도도 줄어든다

프롬프트가 길수록 입력 토큰 비용이 늘고 응답도 느려집니다. 하지만 무작정 줄이면 품질이 떨어집니다. 줄일 것은 장황한 역할 설명, 중복 예시, 매번 반복되는 긴 배경입니다. 남길 것은 출력 형식, 판단 기준, 금지 조건, 사용자 입력의 의미입니다.

좋은 프롬프트 압축은 짧게 쓰는 것이 아니라 결과에 영향을 주지 않는 문장을 제거하는 것입니다. 변경 전후의 품질을 비교하지 않고 줄이면 비용은 내려가도 실패율이 올라갈 수 있습니다.

운영에서는 라우팅과 fallback이 필요하다

하나의 모델로 모든 요청을 처리하면 단순하지만 비효율적입니다. 실무에서는 요청을 나눕니다.

• 간단한 분류: 저비용 모델

• 초안 작성: 빠른 모델

• 긴 문서 요약: 긴 컨텍스트와 안정성이 필요한 모델

• 최종 검수: 품질이 높은 모델

• 실패한 응답 재검토: 더 강한 모델 또는 다른 프롬프트

또한 부하 테스트를 해야 합니다. 평균 요청만 보면 충분해 보여도, 특정 시간대에 긴 출력 요청이 몰리면 지연이 커질 수 있습니다. rate limit, quota, 외부 API 장애에 대비해 대체 모델, 짧은 응답 모드, 재시도 제한을 준비해야 합니다.

AI 기능 최적화는 한 번의 설정으로 끝나지 않습니다. 입력 토큰, 출력 토큰, 모델명, 응답 시간, 오류율, 사용자 만족도를 기록하고 계속 조정해야 합니다. 결국 좋은 AI 제품은 좋은 프롬프트 하나가 아니라, 비용과 속도와 품질을 함께 관리하는 운영 구조에서 나옵니다.

참고

¹Azure OpenAI latency and throughput guidance

²OpenAI models intelligence, performance and price comparison