31. 비용·길이·지연 트레이드오프

공짜가 아니다

지금까지 주로 품질을 이야기했지만, 실무에서는 비용과 속도도 중요합니다. 더 긴 프롬프트, 더 많은 예시, 더 많은 단계는 품질을 높일 수 있지만 동시에 비용·지연을 늘립니다. 좋은 실무자는 이 트레이드오프를 의식적으로 잡습니다.

토큰이 곧 비용·지연

2장에서 길이·비용이 토큰으로 셈된다고 했습니다. 구체적으로:

• 비용: 대부분의 API는 입력+출력 토큰 수에 비례해 과금합니다. 긴 프롬프트·긴 답·많은 예시·긴 대화 누적이 모두 비용입니다.
• 지연(latency): 토큰이 많을수록 처리 시간이 깁니다. 특히 출력 토큰이 많으면 응답이 느려집니다. 긴 컨텍스트도 처리에 시간이 듭니다.

flowchart TB
    factors["길어지는 요인"] --> ex["많은 예시 (7장)"]
    factors --> ctx["큰 컨텍스트 (3부)"]
    factors --> hist["긴 대화 누적 (15장)"]
    factors --> out["긴 출력"]
    factors --> chain["많은 단계 (24장)"]

    ex & ctx & hist & out & chain --> cost["비용 ↑ + 지연 ↑"]

    classDef f fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef bad fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    class ex,ctx,hist,out,chain f
    class cost bad

📌 핵심: 3부의 "고신호 최소집합"은 품질만의 문제가 아니라 비용·속도의 문제이기도 합니다. 군더더기를 덜어내면 답이 좋아지는 동시에 싸지고 빨라집니다. 세 마리 토끼가 같은 방향입니다.

품질 ↔ 비용·속도 트레이드오프 의식하기

모든 작업에 최고 품질을 쏟을 필요는 없습니다. 작업의 중요도와 빈도에 따라 균형점이 다릅니다.

💡 팁: "이 작업에 이만큼의 토큰을 쓸 가치가 있나?"를 가끔 물으세요. 1만 건을 처리하는 분류에서 예시 10개는 1만 번의 추가 비용이지만, 한 번 쓰는 중요 보고서에서는 충분히 투자할 만합니다. 같은 기법도 빈도에 따라 가치가 다릅니다.

비용을 줄이는 실무 수단

수단 1: 군더더기 덜어내기 (3부)

가장 기본이자 효과적입니다. 무관한 자료, 불필요한 예시, 과한 지시를 덜어내면 품질·비용·속도가 함께 좋아집니다. 13장의 제거 실험을 비용 관점에서도 하세요.

수단 2: 출력을 짧게 (8·19장)

출력 토큰이 지연·비용에 크게 기여합니다. 필요 없는 장황한 설명을 줄이고, "결론만", "표로 간결히"를 명시하면 빨라지고 싸집니다(최신 모델의 기본 간결 경향과도 맞음).

수단 3: 적절한 모델 선택

작업 난이도에 맞는 모델을 고르세요. 간단한 분류에 가장 크고 비싼 모델을 쓰는 건 낭비일 수 있습니다. 쉬운 작업은 작고 빠른 모델로, 어려운 작업만 강력한 모델로 — 이 분배가 비용을 크게 줄입니다.

🔧 개발자 노트: 모델 선택은 평가(23장)로 뒷받침하세요. 작은 모델이 그 작업에서 충분한 품질을 내는지 평가 세트로 확인하면, 막연한 불안 없이 비용을 낮출 수 있습니다. 작업별로 다른 모델을 라우팅하는 패턴(쉬운 건 작은 모델, 어려운 건 큰 모델)도 흔합니다.

수단 4: 캐싱 (개발자)

🔧 개발자 노트: 프롬프트의 앞부분이 반복되면(같은 시스템 프롬프트·같은 예시·같은 자료), 프롬프트 캐싱으로 그 부분의 재처리 비용·지연을 크게 줄일 수 있습니다. 한 제공자는 정적 콘텐츠를 앞에, 가변 콘텐츠를 뒤에 두면 캐시 적중으로 상당한 비용 절감(맥락에 따라 큰 폭)이 가능하다고 안내합니다. 실무 원칙: ① 변하지 않는 것(시스템 프롬프트·공통 예시·고정 자료)을 앞쪽에, ② 매번 바뀌는 것(사용자 입력)을 뒤쪽에 배치. 이는 27장 시스템 프롬프트 설계, 14장 배치와도 일치합니다 — 좋은 구조가 캐싱에도 유리합니다.

수단 5: 체이닝 비용 의식 (24장)

단계를 늘리면 품질이 오를 수 있지만 호출 수·토큰도 늡니다. 각 단계가 비용만큼의 가치를 더하는지 보고, 불필요한 단계는 합치세요(24장 "너무 잘게 쪼개지 마라"의 비용판).

흔한 비용 함정

⚠️ 흔한 실수·미신: "윈도우가 크니 다 넣자"(12장)는 품질만의 함정이 아니라 비용의 함정이기도 합니다. 매 요청·매 턴 그 큰 컨텍스트가 과금되고 느려집니다. 긴 대화를 정리 없이 계속 이어가는 것(15장)도 마찬가지 — 누적된 기록이 매 턴 비용을 키웁니다. 압축·격리는 품질뿐 아니라 지갑을 위해서도 필요합니다.

🧪 직접 검증법: 자주 쓰는 프롬프트에서 품질을 거의 해치지 않고 줄일 수 있는 부분을 찾아보세요. 예시 5개를 3개로, 자료를 핵심만으로 줄였을 때 평가 점수가 유지되면, 그만큼이 순수 절감입니다. "줄여도 품질이 유지되는 지점"을 찾는 것이 비용 최적화의 핵심입니다.

이 장에서 배운 것

• 더 긴 프롬프트·예시·단계·출력은 품질을 높일 수 있지만 비용·지연도 늘린다. 이 트레이드오프를 의식적으로 잡는다.
• 토큰이 곧 비용·지연이며, 특히 출력 토큰이 지연에 크게 기여한다.
• "고신호 최소집합"은 품질·비용·속도를 동시에 개선한다 — 세 토끼가 같은 방향이다.
• 작업의 중요도·빈도·실시간성에 따라 균형점이 다르다. 고빈도·저위험은 효율 우선, 저빈도·고위험은 품질 우선.
• 비용 절감 수단: 군더더기 덜기, 출력 짧게, 적절한 모델 선택, 캐싱(정적 앞·가변 뒤), 불필요한 단계 합치기.

✍️ 확인 문제

1. "고신호 최소집합"이 품질뿐 아니라 비용·속도에도 이로운 이유를 설명해보세요.

1. 하루 1만 건을 처리하는 분류 작업과, 분기에 한 번 쓰는 중요 보고서 작업에서, 예시 개수에 대한 판단이 어떻게 달라야 할지 적어보세요.

1. (실습) 캐싱을 고려해, 시스템 프롬프트·공통 예시·고정 자료·사용자 입력을 어떤 순서로 배치할지 정하고 그 이유를 적어보세요. (14·27장과 연결)

다음 → 32. 안전과 민감정보 주의
이전 ← 30. 버전 관리·재사용·템플릿화 · 목차