초장문 LLM 출력을 운영하는 스트리밍·재개 아키텍처

Claude Fable 5.1이 컨텍스트 100만 토큰과 최대 출력 12.8만 토큰을 함께 지원하면서 모델 호출의 설계 범위도 넓어졌다. 이제는 입력을 얼마나 넣을지뿐 아니라, 한 번에 어디까지 생성하도록 허용할지와 긴 응답을 어떻게 수신·저장·검증할지가 서비스 품질과 비용을 좌우한다.

첫 토큰이 도착하는 시간은 같아도, 전체 생성이 끝날 때까지는 몇 분이 걸릴 수 있다. 그 사이 연결이 끊기면 부분 결과를 보존하지 않은 경우 누적된 출력 비용이 모두 손실된다. 모델이 긴 출력을 낼 수 있다는 사실과 서비스가 그 출력을 안정적으로 처리할 수 있다는 사실은 별개다.

출력 길이를 서비스 정책으로 다루기

Fable 5.1의 제공 사양은 컨텍스트 100만 토큰, 최대 출력 12.8만 토큰이다. API 가격은 입력 100만 토큰당 $10, 출력 100만 토큰당 $50이며 출력 단가는 입력의 다섯 배다. Fable 캐시 읽기 비용은 75% 인하됐다.

이 조건에서는 모델이 허용하는 최대치를 그대로 기능의 기본값으로 삼기보다, 요청 유형마다 별도의 출력 상한을 둬야 한다. 무제한 요청을 막고 기능별로 허용 길이를 다르게 정하면, 모델 상한과 서비스 상한을 분리할 수 있다. 출력 길이 자체가 원가이기 때문이다.

장문 결과는 검증·저장·색인 단계에서도 병목을 만든다. 따라서 출력 예산은 토큰 수만 제한하는 기능이 아니라 구간 분할, 부분 저장, 재개 키, 타임아웃 정렬, 검증 시점, 비용 계측, 후처리 흐름을 묶는 운영 체계가 되어야 한다.

생성 도중에도 결과를 잃지 않는 흐름

구간은 토큰 수만으로 자르기보다 목차·장·파일처럼 의미가 닫히는 단위를 기준으로 나눈다. 문장 중간에서 끊긴 결과는 다음 구간과 연결할 때 품질이 흔들릴 수 있다.

스트리밍으로 받은 토큰은 일정 단위마다 영속 저장소에 기록한다. 메모리에만 쌓으면 프로세스가 종료되는 순간 마지막 저장 시점 이후의 데이터가 모두 사라진다. 요청 식별자, 마지막 저장 오프셋, 생성 조건을 함께 가진 재개 키를 발급하면 앞부분을 다시 만들지 않고 이어서 요청하는 경로를 둘 수 있다.

구간이 끝날 때마다 형식과 필수 요소를 확인하고, 문제가 있으면 해당 구간만 다시 생성한다. 12.8만 토큰을 모두 생성한 뒤 형식 오류를 발견하면 전량이 낭비될 수 있다.

⤢✕

타임아웃과 비용은 요청 경로 전체에서 맞춘다

클라이언트, 게이트웨이, 애플리케이션, SDK의 타임아웃은 바깥 계층일수록 길게 정렬해야 한다. 이들 가운데 가장 짧은 값이 실제 요청의 상한이 되므로, 한 계층만 놓쳐도 장문 생성은 반복해서 중단된다.

비용은 요청·사용자·일 단위로 각각 상한을 두고, 초과 시 어떤 동작을 할지 정한다. 경보만 있고 차단이 없으면 비용은 사고 이후에도 계속 늘어난다. 요청별로 입력·출력·캐시 읽기 토큰을 분리 집계하고, 입력의 다섯 배인 출력 단가를 반영해 출력 토큰에는 별도 경보 임계를 둘 필요가 있다.

결과의 결합, 중복 제거, 목차 재생성, 저장, 색인은 응답 경로 밖의 비동기 단계로 분리한다. 후처리를 사용자 요청 스레드에 넣으면 그 작업 시간만큼 사용자와 인프라가 함께 묶인다.

기능별로 운영 방식을 정할 때 볼 지점

실제로 수만 토큰이 필요한 기능과 관행적으로 길게 요청하는 기능은 구분해야 한다. 산출물 유형별 분할 단위를 정하고, 구간 간 참조 방법도 함께 결정한다. 앞 구간의 요약을 뒤 구간 입력에 넣는 방식이라면 그 요약 역시 예산에 포함된다.

부분 결과와 재개 키를 보관할 저장소는 쓰기 지연과 보관 기간을 기준으로 선택한다. 미완성 결과의 만료 정책도 필요하다. 방치된 결과는 저장 비용을 조용히 누적시킨다.

클라이언트는 스트리밍 표시, 폴링 후 조회, 완료 알림 가운데 기능에 맞는 방식을 선택한다. 몇 분이 걸리는 생성은 동기 응답으로 처리하지 않는다. 장문 산출물은 뒷부분 품질도 표본으로 정기 점검해야 하며, 길이가 늘어날수록 후반부의 일관성이 떨어지는 경향이 있다는 점도 고려해야 한다.

출력 상한 변경은 설정 승인 절차의 대상에 포함하고, 기능별 평균 출력 길이와 편당 원가는 정기 보고 항목으로 관리한다.

단일 생성과 분할 생성의 선택

구분	단일 초장문 생성	구간 분할 반복 생성
전체 일관성	높음	중간
실패 손실	큼	작음
총 호출 수	1회	다수
입력 중복 비용	없음	발생
부분 검증	불가	가능
구현 복잡도	낮음	높음

단일 초장문 생성은 전체 구조를 하나의 맥락에서 잡으므로 앞뒤 참조가 자연스럽고 중복 서술이 적다. 호출이 한 번이어서 구현도 단순하다. 반면 생성 도중 실패하면 그때까지의 출력 비용이 전액 손실되고, 중간 품질을 확인하지 못한 채 끝까지 생성해야 한다.

구간 분할 반복 생성은 각 구간을 끝낼 때마다 검증하고 실패한 부분만 다시 만들 수 있다. 낭비가 국소화되고 진행 상황을 사용자에게 보여주기도 쉽다. 다만 구간마다 앞선 맥락을 다시 넣어야 하므로 입력 토큰이 중복 과금되며, 경계에서 어조와 세부 표현이 어긋날 수 있다. 캐시 읽기 비용이 크게 낮아진 조건에서는 중복 입력의 부담도 줄어들기 때문에, 실패 손실이 큰 장문 생성일수록 분할 방식의 불리함이 완화된다.

부분 저장은 연결이 중단돼도 마지막 저장 지점부터 재개할 수 있어 비용 손실을 저장 간격 이내로 제한한다. 진행률을 정확히 제공하거나 부분 결과를 먼저 소비하는 기능도 가능하다. 대신 쓰기 호출 증가에 따른 저장소 부하, 미완성 데이터의 정합성·만료 관리, 부분 데이터가 완성본으로 잘못 소비되는 위험을 감수해야 한다. 완료 후 일괄 저장은 항상 완결된 결과만 남겨 정합성이 단순하고 쓰기 부하가 낮지만, 마지막 순간 실패 시 전량을 다시 생성해야 한다. 출력 단가가 높은 장문 생성에서는 저장 부하보다 실패 손실이 크므로, 부분 저장을 기본으로 두고 완성 표시 플래그로 소비 오류를 막는 구성이 안전하다.

대용량 컨텍스트를 넣는 방식

100만 토큰을 전량 투입하면 관련 자료를 빠짐없이 제공할 수 있고, 검색 파이프라인을 별도로 만들지 않아도 된다. 검색이 놓친 자료 때문에 오답이 생기는 문제도 없다. 그러나 입력 토큰이 그대로 비용이 되고, 중요한 문장이 방대한 맥락 속에 묻혀 정확도가 떨어질 수 있으며 첫 토큰 지연도 길어진다.

선별 검색 후 필요한 자료만 넣으면 원가는 낮아지고 신호 대비 잡음이 줄어 응답 품질이 올라간다. 대신 검색이 놓친 자료는 존재하지 않는 것과 같아지며, 검색 품질이 답변 품질의 상한이 된다. 색인을 구축하고 유지하는 비용도 따른다.

캐시 읽기 비용 인하 환경에서는 자주 반복되는 고정 자료를 캐시에 올리고, 변동 자료만 선별해 넣는 혼합 구성이 두 방식의 약점을 함께 줄인다.

장시간 생성이 시스템 설계에 남기는 과제

타임아웃 계층 정렬과 첫 토큰 시간·완료 시간의 분리 측정은 응답 시간 관리 지표 설계에 해당한다. 구간 분할과 비동기 후처리는 처리량과 응답성을 분리하는 설계다.

요청·사용자·일 단위 상한과 실시간 계측은 자원 사용량 통제와 예산 관리 절차를 구현한 형태다. 입력·출력·캐시 토큰을 나눠 집계하면 원가 귀속 정확도도 높아진다.

재개 키와 부분 저장은 장시간 트랜잭션의 체크포인트·복구 설계에 대응한다. 스트리밍 수신, 완료 알림, 조회 방식을 선택하는 일은 시스템 연계 방식을 결정하는 기준이 된다.

출력 상한이 정책값이 되는 흐름

출력 길이 상한은 모델 사양이 아니라 기능별 정책값으로 관리되는 관행이 자리 잡는 방향이다. 부분 저장과 재개 키는 장문 생성 SDK의 기본 기능으로 편입되는 흐름이며, 캐시 읽기 단가 인하가 이어지면 고정 맥락의 상시 적재와 변동 자료 선별을 결합한 구성이 표준이 되는 방향이다.

편당 원가를 산정할 때도 생성 토큰만이 아니라 재생성 횟수와 후처리 시간을 포함하는 지표가 기능 설계 기준으로 정착하는 흐름이 나타난다.