3장. 성능과 비용 최적화

학습 목표

• 요청 한 건의 지연을 구간별로 분해하고 가장 효과가 큰 개선 지점을 고른다.
• 스트리밍 이벤트를 올바르게 처리하고, 스트리밍이 줄이는 것과 줄이지 않는 것을 구분한다.
• 캐시 적중을 높이도록 프롬프트를 배치하고, 캐시의 손익분기를 계산한다.
• 배치 API와 처리 등급이 맞는 작업을 고르고 결과를 안전하게 회수한다.
• 모델 등급 라우팅과 승급 조건을 설계하고, 지연과 비용의 트레이드오프를 업무당 비용으로 판단한다.

들어가며

어떤 팀이 “응답이 느리다”는 불만을 받고 가장 비싼 모델로 바꿨습니다. 응답은 더 느려졌고 청구서는 세 배가 됐습니다. 다른 팀은 비용을 줄이려고 프롬프트를 절반으로 깎았는데, 품질은 떨어지고 지연은 거의 그대로였습니다. 두 팀 모두 측정하기 전에 손을 댔다는 공통점이 있습니다. 지연과 비용은 여러 구간과 항목의 합이고, 그중 무엇이 큰지는 재 봐야 압니다.

이 장은 측정에서 시작합니다. 지연을 구간으로 나누는 법과 OpenAI가 정리한 지연 단축 원칙을 먼저 보고, 체감 지연을 줄이는 스트리밍, 반복되는 입력을 재사용하는 프롬프트 캐싱, 급하지 않은 일을 싸게 처리하는 배치 API와 처리 등급, 요청마다 알맞은 모델을 고르는 라우팅으로 이어 갑니다. 마지막으로 이 수단들을 업무당 비용이라는 하나의 잣대로 비교합니다.

핵심 개념

지연을 구간으로 나눈다

사용자가 느끼는 대기 시간은 여러 구간의 합입니다. 애플리케이션 대기열, 입력 전처리, 모델 처리, 도구 실행, 후처리, 네트워크 전달이 차례로 이어집니다. 모델 처리도 두 부분으로 나뉩니다. 입력 전체를 읽는 단계와 출력 토큰을 하나씩 만드는 단계입니다. 그래서 측정할 지표도 셋으로 나눕니다.

사용자 입장에서는 “쓸 수 있는 첫 결과”가 언제 나오는지도 봐야 합니다. 첫 조각은 빨리 와도, 구조화된 결과가 완성돼야 화면을 그릴 수 있다면 체감 지연은 전체 응답 시간에 가깝습니다. 불만은 꼬리에서 나오므로 평균보다 p95(느린 쪽 5%의 경계값)를 봅니다.

지연을 줄이는 일곱 가지 원칙

OpenAI의 지연 최적화 가이드는 원칙 일곱 가지를 제시합니다. 공급자와 상관없이 통하는 정리입니다.

출력이 지연을 가장 크게 좌우한다는 점이 핵심입니다. 질문을 되풀이하는 서두, 장황한 맺음말, 불필요한 전체 재작성은 지연과 비용을 함께 늘립니다.

스트리밍의 동작

스트리밍은 응답을 서버 전송 이벤트(SSE)로 조금씩 받는 방식입니다. 택배 출발 알림이 와도 도착 시간은 그대로이듯, 스트리밍은 첫 내용을 빨리 보여 줄 뿐 생성해야 할 토큰 양과 비용을 줄이지 않습니다.

Anthropic 스트림은 정해진 순서로 이벤트를 보냅니다. message_start → 블록마다 content_block_start, content_block_delta(여러 번), content_block_stop → message_delta → message_stop이며, 사이사이 ping이 섞일 수 있습니다. 처리할 때 주의할 점은 다음과 같습니다.

• stop_reason은 message_start에서 null이고 message_delta에서 확정됩니다.
• message_delta의 usage는 누적값입니다. 이벤트마다 더하면 과다 집계됩니다.
• HTTP 200을 받은 뒤에도 error 이벤트(예: overloaded_error)가 올 수 있습니다. 오류 처리를 상태 코드에만 걸어 두면 놓칩니다.
• 이벤트를 직접 다룰 필요가 없으면 SDK의 누적 도우미(Python get_final_message(), TypeScript finalMessage())로 완성된 메시지를 받습니다.

OpenAI Responses API는 response.created, response.output_text.delta, response.completed, error 같은 의미 단위 이벤트를 보내고, Gemini는 SDK의 스트림 옵션이나 REST의 alt=sse로 스트리밍합니다.

스트리밍 경로 전체를 설계한다

API에서 스트리밍을 켜도 사용자가 빈 화면을 볼 수 있습니다. 중간 계층이 응답을 모았다가 한꺼번에 넘기면 스트리밍 효과가 사라지기 때문입니다. 경로 전체를 점검합니다.

1. 리버스 프록시와 API 게이트웨이의 응답 버퍼링을 SSE 경로에서 끈다. 압축 설정이 조각을 모으는 경우도 있다.
2. 서버는 받은 조각을 바로 흘려보내되, 화면 갱신은 적당한 단위(문장, 100ms)로 묶어 브라우저 부담을 줄인다.
3. 사용자가 창을 닫거나 취소하면 HTTP 클라이언트의 취소 신호(예: AbortController)로 상류 요청도 끊는다. 아무도 보지 않는 출력을 끝까지 생성하면 비용만 나간다.
4. 후처리가 필요한 결과는 조각 단위로 처리할 수 있는지 따진다. OpenAI 문서는 스트리밍이 출력 내용 검수(moderation)를 어렵게 만든다고 경고한다. 전체 응답을 본 뒤에만 공개해도 되는 내용인지 먼저 정한다.
5. 도구 인자나 JSON은 조각을 이어 붙이되, 실행과 저장은 완성 후 검증을 통과한 뒤에 한다(2장).

프롬프트 캐싱의 원리

매번 회의 때마다 같은 자료집을 처음부터 다시 읽는 대신, 읽어 둔 부분에 표시를 해 두고 새로 추가된 페이지만 읽는다고 생각해 보세요. 프롬프트 캐싱은 요청의 앞부분(prefix)을 처리한 결과를 저장해 다음 요청에서 재사용합니다. 그래서 앞부분이 한 글자라도 다르면 그 지점부터 재사용할 수 없습니다.

캐싱은 출력을 저장해 돌려주는 기능이 아닙니다. 응답은 매번 새로 생성되며, OpenAI 문서도 캐싱이 출력 토큰 생성 방식을 바꾸지 않는다고 밝힙니다. 이 점에서 이전 답변을 그대로 재사용하는 응답 캐시와 근본적으로 다릅니다(깊이 읽기). 효과는 두 가지입니다. 캐시에서 읽은 입력은 싸게 과금되고, 입력 처리 시간이 줄어 첫 토큰이 빨라집니다.

벤더별 캐싱 비교

Anthropic에서 캐시를 쓰면 input_tokens는 마지막 중단점 뒤의 토큰만 뜻합니다. 총 입력은 세 값을 더합니다.

총 입력 토큰 = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Gemini는 Interactions API와 Gemini 4 Argon 이후 모델에서 암묵적 캐싱만 지원합니다. 캐시를 직접 만들어 관리하는 명시적 캐싱은 지원되는 이전 모델에서 generateContent API로만 쓸 수 있습니다.

캐시 적중을 높이는 프롬프트 배치

세 공급자의 공통 원칙은 하나입니다. 바뀌지 않는 것을 앞에, 바뀌는 것을 뒤에 둡니다. 맨 앞에 현재 시각 한 줄만 있어도 뒤의 수천 토큰이 모두 캐시를 놓칩니다.

1. 순서를 고정한다. Anthropic은 tools → system → messages 순서로 앞부분을 만든다. 도구 정의, 고정 지시, 참고 자료, 예시를 앞에 두고 시각·사용자 정보·질문은 끝에 둔다.
2. 중단점은 고정 부분의 끝에 둔다. 매번 바뀌는 블록에 중단점을 찍으면 쓰기만 반복된다.
3. 직렬화를 안정시킨다. 도구 목록 순서, JSON 키 순서, 공백이 요청마다 달라지면 내용이 같아도 다른 앞부분이다. 집합이나 해시맵에서 도구 목록을 만들면 순서가 흔들린다.
4. 캐시를 깨는 변경을 안다. Anthropic에서 도구 정의 변경은 전체 캐시를, tool_choice 변경이나 이미지 추가·제거는 메시지 부분 캐시를 무효화한다. 최상위 effort나 output_config.format 변경도 캐시를 무효화한다.
5. 최소 길이를 확인한다. 앞부분이 모델의 최소 길이에 못 미치면 표시를 해도 조용히 캐시되지 않는다.
6. 측정한다. 배포 전후로 캐시 읽기 비율을 비교하고, Anthropic의 캐시 진단 기능처럼 연속 요청의 앞부분이 어디서 갈렸는지 알려 주는 도구를 쓴다.

OpenAI에서는 도구 목록을 그대로 두고 호출 가능 범위만 바꾸는 allowed_tools가 캐시를 지키는 데 유리하고, prompt_cache_key는 이전 모델에서는 라우팅에만 영향을 주고, GPT-5.6 이후에는 주로 고객별 캐시 사용량 집계에 씁니다. GPT-5.6 이후 모델은 기본적으로 최근 메시지 끝에 중단점을 두므로, 끝부분이 매번 바뀌면 고정 부분 끝에 prompt_cache_breakpoint를 넣어야 적중합니다. Anthropic 캐시는 조직 간에 공유되지 않으며 Claude API에서는 워크스페이스별로도 분리됩니다.

캐시의 손익분기

캐시 쓰기는 일반 입력보다 비싸므로 재사용이 충분해야 이득입니다. 앞부분 처리 비용을 1로 두고 Anthropic 배수로 계산해 보겠습니다.

읽기 배수 0.1 기준으로 5분 캐시는 유지 시간 안의 두 번째 요청부터, 1시간 캐시는 세 번째부터 이득입니다(읽기 배수가 더 낮은 모델은 이득이 더 큽니다). 반대로 요청 간격이 유지 시간보다 길면 매번 쓰기만 일어나 캐시 없음보다 5분 캐시는 25%, 1시간 캐시는 100% 비싸집니다. 이때는 더 긴 유지 시간을 고르거나 캐싱을 끄는 편이 낫습니다. 유지 시간은 요청이 시작된 시점부터 재므로, 응답 생성에 오래 걸리는 요청은 그만큼 남은 시간이 줄어든다는 점도 계산에 넣습니다. 처리량 이득도 있습니다. Anthropic 대부분의 모델에서 캐시 읽기는 ITPM에 세지 않으므로, 적중률이 높으면 같은 한도로 더 많은 입력을 처리합니다.

배치 API

당일 배송이 필요 없는 짐은 싼 일반 우편으로 보냅니다. 배치 API는 즉시 응답이 필요 없는 대량 요청을 모아 비동기로 처리하고 값을 깎아 줍니다.

OpenAI와 Anthropic은 결과 순서가 입력 순서와 다를 수 있다고 밝히므로 반드시 식별자로 짝짓습니다. Gemini API 참조는 결과가 입력 순서대로 온다고 명시하지만, 공급자를 바꿔도 같은 코드가 동작하도록 키로 짝짓는 편이 안전합니다. Anthropic은 요청 검증을 비동기로 하므로 배치가 끝나야 형식 오류를 알 수 있습니다. 먼저 같은 형식의 요청 하나를 Messages API로 시험해 보라고 권합니다. 실패한 요청의 과금도 다릅니다. Anthropic에서 오류·취소·만료된 요청은 과금되지 않고, OpenAI에서는 만료 시 끝나지 않은 요청이 취소되고 완료된 요청만 과금됩니다. 캐싱과 함께 쓸 수 있지만 Anthropic은 배치 안의 캐시 적중을 최선 노력 방식이라고 밝히며 공통 컨텍스트에는 1시간 캐시를 권합니다. Gemini 배치 문서는 캐시 적중분에 컨텍스트 캐싱 요금이 적용된다고 설명하므로, 실제 단가는 모델별 가격표로 확인합니다. 배치 한도는 동기 API 한도와 별도로 관리됩니다.

처리 등급을 고른다

같은 모델이라도 요청을 어떤 등급으로 처리할지 고를 수 있습니다.

등급 선택은 시간 가치의 문제입니다. 평가 실행이나 데이터 보강처럼 몇 분 늦어도 되는 일은 싼 등급으로, 고객이 기다리는 경로 중 지연 목표를 넘는 부분만 빠른 등급으로 보냅니다. 빠른 등급을 쓴다면 응답에 표시된 실제 처리 등급을 기록해 강등 비율을 지켜봅니다.

모델 등급 라우팅과 승급

모든 요청을 가장 큰 모델로 보내는 것은 동네 심부름에 대형 트럭을 쓰는 것과 같습니다. 라우팅은 요청을 성격에 따라 다른 모델로 보내고, 승급(escalation)은 작은 모델의 결과가 기준에 못 미칠 때 상위 모델로 다시 처리합니다.

모델이 스스로 밝히는 확신 점수에 승급을 맡기지 않습니다. 확신과 정답 여부가 늘 일치하지는 않기 때문입니다. 검증 가능한 신호(스키마 통과, 필수 사실 포함, 금지 표현 없음)로 판단하고, 경로마다 품질·지연·비용을 평가 세트로 따로 잽니다. 추론 모델이라면 추론 강도도 같은 방식으로 라우팅합니다.

지연과 비용의 트레이드오프를 판단한다

수단마다 얻는 것과 내주는 것이 다릅니다.

비교 잣대는 호출당 비용이 아니라 업무당 비용입니다.

업무당 비용 = (모든 호출 비용 + 재시도·승급 비용 + 사람 검수 비용) ÷ 품질 기준을 통과한 업무 수

호출당 비용이 절반인 모델도 재시도와 사람 수정이 세 배로 늘면 손해입니다. 응답 시한과 실패 비용을 먼저 정하고, 그 안에서 업무당 비용이 가장 낮은 조합을 고릅니다.

깊이 읽기

응답 캐시는 언제 위험한가

응답 캐시는 이전에 만든 답을 그대로 돌려줍니다. 같은 질문이 많다면 지연과 비용을 사실상 없앨 수 있습니다. 질문 문장이 조금 달라도 의미가 비슷하면 같은 답을 주는 방식은 시맨틱 캐시라고 부르며, 임베딩 유사도로 이전 질문을 찾습니다. 강력한 만큼 위험도 분명합니다.

1. 개인화와 권한. 답에 사용자별 정보가 섞이면 다른 사람에게 그 답이 갈 수 있습니다. 캐시 키에 조직, 권한, 언어, 자료 버전을 넣거나, 개인화된 답에는 쓰지 않습니다.
2. 최신성. 근거 문서가 바뀌면 캐시된 답은 틀린 답이 됩니다. 문서 버전을 키에 넣고, 개정 때 해당 항목을 무효화합니다.
3. 유사도 임계값. 임계값이 낮으면 “환불 가능 기간”과 “교환 가능 기간”처럼 비슷하지만 다른 질문에 같은 답이 갑니다. 임계값은 오적중 사례를 모은 평가 세트로 정합니다.
4. 변경 작업. 도구를 실행해야 하는 요청은 캐시하지 않습니다.

프롬프트 캐싱에는 이런 위험이 없습니다. 출력을 매번 새로 만들기 때문입니다. 두 캐시는 경쟁 관계가 아니라 층이 다릅니다. 확정된 정보 안내처럼 답이 정해진 일부 질문에 응답 캐시를, 나머지 대화 전반에 프롬프트 캐싱을 씁니다.

최적화 실험을 공정하게 비교하는 법

최적화 효과를 잘못 읽는 흔한 경우가 있습니다. 첫째, 캐시 상태를 섞어 잽니다. 첫 요청은 캐시가 비어 있어 느리고 비쌉니다. 캐시가 빈 상태와 채워진 상태를 따로 측정합니다. 둘째, 품질을 같이 재지 않습니다. 출력 축소나 작은 모델 전환은 지연과 비용을 줄이지만 품질을 떨어뜨릴 수 있습니다. 같은 평가 세트와 통과 기준을 고정합니다. 셋째, 부하를 무시합니다. 동시 요청 수에 따라 지연 분포가 달라지므로 실제 피크에 가까운 동시성으로 p95를 잽니다. 넷째, 여러 변경을 한꺼번에 합니다. 모델, 프롬프트, 캐시 배치를 동시에 바꾸면 무엇이 효과였는지 알 수 없습니다. 변경 하나에 측정 하나를 원칙으로 하고, 결과는 업무당 비용과 p95로 기록합니다.

실무 장면

물마루어학원: 빈 화면 14초의 정체

온라인 어학원 ‘물마루어학원’은 수강생이 쓴 영어 작문을 첨삭해 준다. 제출 후 결과가 뜨기까지 평균 14초가 걸리고, 그동안 화면은 비어 있다. 운영팀은 상위 모델로 바꾸자고 했지만, 개발자 탁 주임은 먼저 구간을 쟀다.

API 쪽 스트리밍은 이미 켜져 있었다. 그런데 사내 API 게이트웨이가 응답 버퍼링을 켠 채로 SSE를 중계해 브라우저는 끝날 때까지 아무것도 받지 못했다. 그리고 지연의 대부분은 출력 생성이었다. 모델이 작문 전체를 고쳐 다시 쓰고, 그 뒤에 수정 이유를 길게 붙이고 있었다.

탁 주임은 두 가지를 바꿨다. 게이트웨이의 SSE 경로에서 버퍼링을 끄고, 응답 형식을 “수정이 필요한 문장과 고친 문장, 이유 한 줄”의 목록으로 바꿨다. 전체 재작성은 수강생이 원할 때만 따로 요청하게 했다. 평균 출력은 950토큰에서 340토큰으로 줄었다. 첫 첨삭 항목이 뜨는 시간은 2.1초, 전체 완료는 5.6초가 됐고 비용은 60% 줄었다. 평가 세트 기준 첨삭 정확도는 그대로였다.

기각한 안도 있었다. 상위 모델은 출력 속도가 더 느렸다. 프롬프트의 예시를 줄이는 안은 입력이 2,000토큰 남짓이라 효과가 거의 없을 것으로 보고 시도하지 않았다.

들녘유통: 리뷰 답글을 세 갈래로 나누다

농산물 온라인몰 ‘들녘유통’은 하루 약 9,000건의 상품 리뷰에 답글 초안을 만든다. 모든 리뷰를 동기 API와 상위 모델로 처리하면서 비용이 늘었다. 회사 정책은 일반 리뷰에 48시간 안, 별점 1~2점 불만 리뷰에 30분 안 답글이다.

플랫폼 엔지니어 위 책임은 응답 시한으로 경로를 나눴다.

1. 불만 리뷰(약 11%)는 동기 경로로 보낸다. 작은 모델이 초안을 만들고, 검증기가 필수 요소(사과, 조치 안내)와 금지 요소(보상 금액 약속, 확인되지 않은 원인 단정)를 검사한다. 검사에 실패하면 중간 모델로 승급한다. 승급 비율은 첫 주 14%였다.
2. 일반 리뷰는 매일 두 번 배치 API로 제출한다. 리뷰 ID를 custom_id로 넣어 결과를 짝짓고, 만료되거나 오류가 난 건만 다음 배치에 다시 넣는다.
3. 답글 지침과 말투 예시(약 3,000토큰)는 프롬프트 앞부분에 고정하고, 리뷰 본문과 상품 정보는 끝에 둔다.

팀은 업무당 비용으로 결과를 비교했다. 사람이 고쳐야 했던 초안의 검수 시간까지 넣자, 모든 리뷰를 작은 모델로 처리하는 안은 호출 비용은 가장 낮았지만 불만 리뷰의 수정 시간이 늘어 업무당 비용은 오히려 높았다. 최종 구성의 업무당 비용은 기존의 31%였다. 비슷한 리뷰에 이전 답글을 재사용하는 응답 캐시도 검토했지만, 답글이 주문 내역과 상품 상태에 따라 달라 채택하지 않았다.

자주 틀리는 지점

• 스트리밍은 비용을 줄인다. 체감 지연을 줄일 뿐 생성 토큰과 비용은 같습니다.
• 프롬프트를 절반으로 줄이면 지연도 절반이 된다. 지연은 출력 길이가 좌우합니다. 입력 축소의 지연 효과는 대개 작습니다.
• 캐시 유지 시간을 늘리면 적중률이 오른다. 앞부분이 매번 다르면 유지 시간과 상관없이 적중하지 않습니다. 순서와 직렬화부터 고칩니다.
• cache_control만 붙이면 캐시된다. 모델별 최소 길이에 못 미치면 오류 없이 캐시되지 않습니다. 사용량 필드로 확인합니다.
• 배치 결과는 입력 순서대로, 몇 시간 안에 온다. OpenAI와 Anthropic은 순서를 보장하지 않고, 어느 공급자든 시간은 약속 범위(최대 24시간 등) 안에서만 정해집니다. 식별자로 짝짓고 만료에 대비합니다.
• 캐시 읽기는 어디서나 레이트 리밋에 잡히지 않는다. Anthropic 대부분의 모델에서는 ITPM에 세지 않지만, OpenAI는 캐시된 입력도 TPM에 포함합니다.
• 작은 모델부터 쓰면 항상 싸다. 승급, 재시도, 사람 수정까지 더한 업무당 비용으로 판단해야 합니다.

한눈에 정리

• 지연은 TTFT, 출력 속도, 전체 시간으로 나눠 p95로 잰다. 출력 길이가 가장 큰 변수다.
• 스트리밍은 체감 지연용이다. 게이트웨이 버퍼링, 취소 전파, 검수 시점까지 경로 전체를 본다.
• Anthropic 스트림: stop_reason은 message_delta에서, 사용량은 누적값, 200 뒤에도 error 이벤트.
• 캐싱은 앞부분 재사용. 고정 내용 앞, 변동 내용 뒤, 직렬화 고정, 최소 길이 확인.
• Anthropic 5분 캐시는 두 번째 사용부터, 1시간 캐시는 세 번째 사용부터 이득(읽기 0.1배 기준). 간격이 유지 시간보다 길면 손해.
• 배치는 세 공급자 모두 50% 할인. OpenAI·Anthropic은 순서 비보장. 식별자로 짝짓고 만료에 대비.
• 처리 등급: 싼 등급은 느림을, 빠른 등급은 할증과 강등 관리를 내준다.
• 라우팅의 승급은 검증 가능한 신호로. 비교는 업무당 비용으로.

공식 문서로 확인하기

• OpenAI — Latency optimization: 지연 단축 일곱 원칙과 사례를 읽는다.
• Anthropic — Streaming messages: 이벤트 흐름, 누적 사용량, 오류 이벤트, 복구 방법을 읽는다.
• Anthropic — Prompt caching: 앞부분 순서, 유지 시간, 가격 배수, 최소 길이, 무효화 표를 확인한다.
• OpenAI — Prompt caching: 기본 활성화, 보관 정책, prompt_cache_key, 사용량 필드를 읽는다.
• Google — Gemini API context caching: 암묵적 캐싱 조건과 최소 토큰을 확인한다.
• OpenAI — Batch API, Anthropic — Batch processing, Google — Batch API: 한도, 만료, 결과 짝짓기를 비교한다.

셀프 체크

3-1. 요청 한 건의 지연을 잴 때 구분할 세 지표를 정의하고, 평균 대신 p95를 보는 이유를 쓰라.

3-2. API에서 스트리밍을 켰는데도 사용자가 빈 화면을 보는 원인을 두 가지 들고, 스트리밍 경로에서 점검할 항목을 쓰라.

3-3. Anthropic 1시간 캐시(쓰기 2배, 읽기 0.1배)를 쓸 때 같은 앞부분을 유지 시간 안에 몇 번 써야 이득인지 계산하고, 5분 캐시(쓰기 1.25배)와 비교하라.

3-4. 프롬프트 캐시와 응답 캐시가 각각 무엇을 재사용하는지 쓰고, 사용자별 정보가 섞인 답변에 응답 캐시를 쓸 때의 위험과 대책을 설명하라.

3-5. 모델 등급 라우팅에서 승급 조건으로 모델의 자기 확신 점수 대신 쓸 신호를 세 가지 들고, 승급 비율이 업무당 비용에 미치는 영향을 설명하라.

3-6. 응답 시한이 즉시, 4시간, 사흘인 세 업무에 대해 처리 경로(동기, 처리 등급, 배치)와 모델 등급을 고르는 결정표를 만들고 각 선택의 근거를 쓰라.

실습 과제