B컷전문 | 개발과 인생의 이야기

사내 상담 도우미의 답변 품질은 좋아졌는데, 월말 청구서와 고객 대기 시간이 예상보다 크게 늘었다. 팀은 곧바로 더 싼 모델로 바꾸자고 한다. 그러나 어떤 요청이 길어졌는지, 검색과 모델 호출 중 어디서 기다렸는지 모르면 가격표만 바꿔도 같은 문제가 반복된다. 모델 선택은 단가 비교가 아니라 품질·비용·지연시간을 함께 지키는 운영 결정이다.

이 글은 모델 API를 쓰는 서비스에서 요청 유형별 예산과 응답 시간을 정하고, 실제 사용량을 관측해 조정하는 방법을 다룬다. 공급자의 요금과 제한은 모델·계정·시점마다 달라지므로 고정된 단가 대신 측정 절차를 제안한다.

1. 한 번의 답변이 아니라 전체 경로를 계산한다

사용자가 느끼는 시간에는 인증, 검색, 도구 호출, 모델 응답, 후처리, 화면 표시가 모두 들어간다. 비용도 입력 토큰과 출력 토큰뿐 아니라 재시도, 추가 호출, 검색 인프라, 사람의 재검토를 포함한다. 평균 한 건의 가격만 보면 긴 문서나 실패 후 재시도가 만드는 꼬리 비용을 놓친다.

측정 단위는 최소한 요청 유형, 모델·버전, 입력·출력 토큰, 호출 횟수, 캐시 사용량, 전체 소요 시간, 모델 호출 시간, 실패·재시도 횟수로 나눈다. 사용자 정보나 원문 프롬프트를 무심코 로그에 남기지 말고, 민감정보를 제외한 집계와 추적 ID로 연결한다. OpenAI의 지연시간 최적화 안내도 출력 토큰, 요청 횟수, 병렬화, 스트리밍, LLM이 불필요한 경우의 대안을 구분해 설명한다.

2. 요청을 같은 등급으로 취급하지 않는다

실시간 고객 응대와 밤새 처리하는 문서 분류는 같은 지연시간 목표를 가질 이유가 없다. 기능별로 품질 기준과 실패 시 행동을 먼저 정하고, 그 안에서 모델과 처리 경로를 선택한다. 아래 숫자는 가상의 팀이 실험을 시작하기 위한 내부 목표 예시이며 제품이나 공급자의 보장치가 아니다.

업무 경로	가상 목표·제약	운영 선택
상담 화면의 간단한 상태 안내	95백분위 전체 응답 4초 이내, 정해진 문구의 정확성 우선	확정된 상태는 규칙·UI로 표시하고 생성 호출을 생략
근거가 필요한 지식 검색 답변	출처 누락은 실패로 처리, 지연 증가를 허용하되 상한 설정	검색 결과를 좁혀 전달하고 근거 부족 시 답변 보류
야간 문서 분류	다음 근무일 전 완료, 건당 비용 상한 관리	비동기 묶음 처리 후보로 평가하고 실패 건만 재처리

성능 목표는 평균만 쓰지 말고 95백분위 같은 꼬리 지표와 오류율을 함께 본다. 작은 모델로 바꿀 때도 대표 평가셋에서 정확도, 출처 적합성, 형식 오류와 사람 재작업 시간을 비교해야 한다. 싸게 호출했지만 재작업이 늘면 총비용은 오를 수 있다.

3. 비용과 지연시간의 레버를 순서대로 당긴다

1. 불필요한 호출 제거: 고정된 안내, 단순 조회, 이미 확인된 상태는 규칙과 UI로 처리한다. 다단계 프롬프트의 중복 호출도 점검한다.
2. 출력 길이 제한: 답변에 필요한 길이와 형식을 정하고 불필요한 장문 생성을 줄인다. 단, 설명·근거를 잘라 정확성을 해치지 않는지 평가한다.
3. 입력 정리: 검색 문서의 중복·무관한 조각을 제거하고 공통 지시와 동적 내용을 분리한다. 캐시 적중은 공급자 조건과 실제 사용량으로 확인한다.
4. 모델 라우팅: 반복 가능하고 범위가 좁은 작업부터 작은 모델을 시험하고, 어려운 사례·실패 신호는 더 강한 모델이나 사람에게 넘긴다. 전환 기준은 평가셋과 운영 로그로 조정한다.
5. 동기·비동기 분리: 즉시 답해야 하는 요청과 지연을 허용하는 일괄 작업을 나눈다. OpenAI의 비용 최적화 안내는 요청·토큰 축소와 작은 모델 선택, 비동기 Batch·느린 처리 옵션의 비용·시간 교환관계를 설명한다.

스트리밍은 첫 글자가 보이기까지의 체감 대기를 줄일 수 있지만 전체 계산 비용이나 최종 완료 시간을 자동으로 줄이지는 않는다. 병렬 호출도 독립 작업일 때만 이득이 있으며 호출량·한도·비용을 함께 늘릴 수 있다.

4. 실전 예시: 상담 요약 기능의 경로를 다시 설계한다

가상의 고객지원팀이 상담 종료 후 요약을 생성한다고 하자. 처음에는 모든 대화에 같은 대형 모델을 두 번 호출해 제목과 본문을 따로 만들었다. 제품팀은 당일 화면에 제목만 빨리 보여 주고, 상세 요약은 상담사가 나중에 검토해도 된다고 정의했다.

1. 최근 요청을 유형·대화 길이별로 묶어 입력·출력 토큰, 전체 시간, 모델 호출 시간, 재시도와 수정률을 기준선으로 남긴다.
2. 제목과 요약을 한 요청으로 합칠 수 있는지 평가한다. 긴 대화에서 형식 실패가 늘면 무조건 합치지 않는다.
3. 화면에는 검증된 상태·핵심 메타데이터를 먼저 표시하고, 상세 요약은 비동기로 생성해 완료 후 갱신한다.
4. 간단한 대화는 작은 모델 후보로 비교하고, 민원·환불 등 위험 유형은 기존 검토 경로를 유지한다.
5. 변경 전후 품질 평가셋, 95백분위 응답 시간, 건당 비용, 상담사 수정률을 함께 비교한다. 한 지표만 좋아졌다고 전체 전환하지 않는다.

이는 설계 예시이지 특정 모델의 성능이나 절감률을 보장하지 않는다. 실제 목표는 서비스의 위험도와 사용자 약속에 맞춰 정해야 한다.

5. 한도·실패까지 포함한 운영 점검표

• 요청마다 전체 마감 시간과 호출별 타임아웃, 최대 재시도 횟수를 정했는가?
• 요청 수와 토큰 수 제한을 각각 확인하고, 피크 트래픽에서 대기열·동시성을 제한하는가?
• 일시적 제한에는 서버의 재시도 안내가 있으면 따르고, 없으면 지수적 지연과 임의 지연을 적용하되 총 시한을 넘기지 않는가?
• 결제·할당량 같은 영구 오류를 무한 재시도하지 않고, 사용자에게 보류·재시도·사람 연결 중 적절한 경로를 제공하는가?
• 모델·프롬프트 버전별 비용, 지연시간, 오류율, 품질과 수정률을 한 대시보드에서 비교할 수 있는가?

OpenAI의 요청 제한 문서는 요청 수와 토큰 수 제한, 임시 제한의 재시도와 총 재시도 시간 관리 등을 안내한다. 공급자별 응답 코드와 SDK 기본 재시도는 다를 수 있으니 실제 계약과 설정을 확인해야 한다. Amazon Bedrock의 모니터링 안내처럼 공급자별 런타임 지표와 로그 수집 범위도 다르다. 이 글의 점검표는 특정 플랫폼의 기능이 모두 기본 활성화돼 있다는 뜻이 아니다.

6. 흔한 문제와 개선 팁

• 가격표만 보고 모델을 교체한다: 품질 저하로 생긴 재작업과 재호출까지 포함해 비교한다.
• 평균 지연시간만 본다: 긴 입력·피크 시간·재시도 요청을 분리하고 꼬리 지연을 관찰한다.
• 캐시를 켜면 항상 싸진다고 믿는다: 적중 조건, 보존 시간, 가격, 실제 캐시 토큰 지표를 확인한다.
• 429 오류를 즉시 반복한다: 대기열과 백오프를 적용하고 전체 마감 시간을 지나면 안전하게 실패시킨다.
• 더 빠른 화면을 위해 근거를 생략한다: 체감 속도 개선과 답변의 근거·정확성은 별도로 검증한다.

요약

모델 운영은 “가장 싼 모델”을 찾는 일이 아니다. 업무별 품질 기준과 시간·비용 예산을 정하고, 전체 경로를 측정한 뒤, 불필요한 호출부터 줄이는 과정이다. 작은 모델, 캐시, 스트리밍, 비동기 처리는 각각 다른 문제를 해결한다. 변경할 때마다 품질 평가와 실제 사용량을 함께 확인하고, 한도와 실패 상황에서의 사용자 경로를 남겨야 한다.

참고 자료

• OpenAI API, Latency optimization
• OpenAI API, Cost optimization
• OpenAI API, Rate limits
• Amazon Bedrock, Monitor the bedrock-runtime endpoint