[AI] LLM API 응답 속도 최적화: Streaming과 비동기 처리의 실무 적용

LLM API를 서비스에 붙이면 처음에는 모델 성능이나 답변 품질부터 보게 됩니다. 그런데 실제로 운영해보면 사용자가 먼저 말하는 것은 품질보다 속도입니다. 답변이 길어질수록 화면이 멈춘 것처럼 느껴지고, 서버는 살아 있는데 체감은 느리다고 느끼는 순간이 오더군요. 이 시점부터는 단순히 모델이 빠른가보다, Streaming과 비동기처리를 어떻게 조합할지가 더 중요한 주제가 됩니다.

LLM API 응답 속도 최적화, 왜 Streaming과 비동기처리가 같이 언급되는가

LLM API 응답 속도 최적화라고 하면 많은 분들이 모델 추론 시간부터 떠올립니다. 물론 그것도 중요합니다. 하지만 실제 서비스에서는 전체 답변이 끝나는 시점보다 사용자가 첫 글자를 언제 보느냐가 더 크게 체감되는 경우가 많습니다.

그래서 이 주제에서는 Streaming과 비동기처리가 같이 묶여 나옵니다. Streaming은 사용자가 답변을 더 빨리 보기 시작하게 만드는 방법이고, 비동기처리는 서버가 외부 응답을 기다리는 동안 내부 자원을 덜 막히게 만드는 방법입니다. 둘은 비슷해 보이지만 해결하는 문제가 다릅니다. 

 

LLM API 응답 속도 최적화에서 진짜 Pain Point는 체감 지연과 자원 점유다

이 주제에서 가장 흔한 오해는 느린 이유가 전부 모델 때문이라고 보는 것입니다. 실제로는 답변을 한 번에 다 받은 뒤 내려주는 구조 때문에 사용자가 첫 반응을 늦게 느끼는 경우가 많습니다. 즉 총 처리 시간이 조금 길더라도, 초반 반응이 빠르면 훨씬 덜 답답하게 느낍니다.

또 하나는 서버 측 문제입니다. 동기 방식으로 외부 LLM API를 기다리면 애플리케이션 입장에서는 그 시간 동안 요청 처리 흐름이 길게 유지됩니다. 이 구조가 나쁜 것은 아닙니다. 다만 요청량이 늘어나면 느린 요청이 다른 요청까지 같이 밀리게 만들 수 있습니다. 

 

사용자가 느끼는 느림과 서버가 느끼는 느림은 다르다

사용자는 첫 글자가 언제 보이는지를 먼저 느낍니다. 반면 서버는 연결이 얼마나 오래 유지되는지, 후처리가 어디에 붙어 있는지, 재시도가 얼마나 겹치는지를 더 크게 느낍니다. 그래서 이 주제는 단순한 속도 문제가 아니라 UX와 서버 구조가 동시에 얽힌 문제입니다.

제가 봤을 때 이 주제는 평균 응답 시간 하나로 설명하면 오히려 흐려집니다. 첫 토큰 도착 시간, 전체 완료 시간, 중도 취소 비율, 후처리 지연 같은 요소를 따로 봐야 합니다.

Streaming과 비동기처리, 무엇을 위한 선택인지 먼저 나눠야 한다

실무에서는 이 둘을 한꺼번에 이야기하다가 혼선이 생기기 쉽습니다. 그런데 사실 목적이 다릅니다. Streaming은 사용자 체감 속도를 개선하는 쪽에 가깝고, 비동기처리는 서버 처리 구조를 유연하게 만드는 쪽에 가깝습니다. 둘 다 응답 속도 최적화에 기여하지만, 같은 처방은 아닙니다.

방법 A: 동기 일괄 응답 유지

가장 단순한 방식입니다. 외부 LLM API의 전체 응답을 받은 뒤 한 번에 클라이언트에 반환합니다. 구현이 쉽고, 기존 REST API 흐름과도 잘 맞습니다. 결과 완성본을 한 번에 보여줘야 하는 문서 생성, 리포트 생성, 배치성 요청에는 아직도 충분히 쓸 만합니다.

하지만 채팅형 UX나 작성 보조처럼 사용자가 응답 도중에도 내용을 읽기 시작하는 흐름에는 답답하게 느껴질 수 있습니다. 특히 긴 답변일수록 첫 반응이 늦게 느껴집니다.

 

방법 B: 비동기 작업 큐 + 결과 조회

이 방식은 요청을 받아서 바로 외부 API를 끝까지 기다리지 않고, 내부 큐나 작업 테이블에 넣은 뒤 나중에 결과를 조회하게 하는 구조입니다. 서버 안정성 측면에서는 장점이 큽니다. 응답이 길게 걸리는 작업을 사용자 요청 흐름과 분리할 수 있기 때문입니다.

다만 이 구조는 사용자 경험이 달라집니다. 결과를 바로 보지 못하고 기다려야 하기 때문에 채팅형 인터페이스에는 덜 어울릴 수 있습니다. 반면 요약 리포트 생성, 긴 문서 초안 생성처럼 결과 완성본 중심의 흐름에는 잘 맞습니다.

 

방법 C: Streaming + 비동기처리 결합

채팅형 서비스에서는 이 방식이 가장 자연스러운 경우가 많습니다. 사용자에게는 생성 중인 텍스트를 바로 흘려보내고, 서버 내부에서는 무거운 저장이나 후처리를 응답 종료 후 비동기로 넘기는 구조입니다. 저는 실제로 이 조합이 가장 균형이 좋다고 봅니다.

다만 구현 난이도는 가장 높습니다. 스트림 중간 예외 처리, 프록시 버퍼링, 연결 타임아웃, 클라이언트 중도 이탈, 저장 로직 분리까지 같이 봐야 하기 때문입니다. 그렇다고 모든 곳에 이 방식을 넣는 것은 과합니다. 채팅형이면 강력한 후보이고, 완성본 중심 기능이면 굳이 복잡하게 갈 필요가 없습니다.

 

LLM API 응답 속도 최적화 Practical Implementation

이 주제에서 구현 포인트는 화려한 기술보다 병목을 어디서 줄일 것이냐입니다. 저는 보통 세 가지를 먼저 봅니다. 첫 번째는 첫 토큰을 얼마나 빨리 보여줄 것인가, 두 번째는 응답 중간에 무거운 후처리를 넣지 않을 것인가, 세 번째는 프록시나 네트워크 구간에서 스트리밍이 막히지 않는가입니다.

1. 채팅형이라면 SSE 기반 Streaming부터 검토한다

Spring Boot에서는 SseEmitter를 이용해 비교적 단순하게 스트리밍 중계를 만들 수 있습니다. 핵심은 서버가 외부 LLM 응답 조각을 받자마자 클라이언트로 흘려보내고, 응답이 끝날 때까지 무거운 가공을 붙이지 않는 것입니다.

 @RestController @RequestMapping("/api/llm") public class LlmStreamController { private final LlmStreamingService llmStreamingService; private final ChatHistoryAsyncService chatHistoryAsyncService; public LlmStreamController( LlmStreamingService llmStreamingService, ChatHistoryAsyncService chatHistoryAsyncService ) { this.llmStreamingService = llmStreamingService; this.chatHistoryAsyncService = chatHistoryAsyncService; } @GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter stream(@RequestParam("prompt") String prompt, @RequestParam("userId") Long userId) { // 너무 짧게 잡으면 모바일 환경에서 자주 끊길 수 있습니다 SseEmitter emitter = new SseEmitter(60000L); llmStreamingService.stream(prompt, chunk -> { try { emitter.send(SseEmitter.event() .name("token") .data(chunk)); } catch (IOException e) { emitter.completeWithError(e); } }, fullText -> { // 저장과 집계는 응답 종료 후 비동기로 분리 chatHistoryAsyncService.save(userId, prompt, fullText); emitter.complete(); }, error -> { try { emitter.send(SseEmitter.event() .name("error") .data("temporary_unavailable")); } catch (IOException ignored) { } emitter.completeWithError(error); }); emitter.onTimeout(emitter::complete); return emitter; } } 

여기서 중요한 것은 코드 양이 아니라 구조입니다. 응답을 보내는 흐름과 저장하는 흐름을 분리해야 Streaming의 장점이 살아납니다. 이거 운영에서 한번 꼬이면, 첫 토큰은 빨라졌는데 마지막에 다시 막히는 상황이 나옵니다.

2. 응답 종료 후 작업은 비동기처리로 분리한다

많이 놓치는 부분이 이것입니다. 스트리밍은 붙였는데, 마지막에 대화 저장, 토큰 집계, 감사 로그 적재를 전부 동기로 수행하면 전체 흐름이 다시 무거워집니다. 사용자는 답변을 다 받은 것처럼 보여도 서버는 아직 그 요청을 완전히 놓지 못하고 있는 경우가 생깁니다.

 @Configuration @EnableAsync public class AsyncConfig { @Bean(name = "llmTaskExecutor") public Executor llmTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(16); executor.setMaxPoolSize(64); executor.setQueueCapacity(500); // 큐가 너무 크면 장애를 늦게 발견합니다 executor.setThreadNamePrefix("llm-async-"); executor.initialize(); return executor; } } @Service public class ChatHistoryAsyncService { @Async("llmTaskExecutor") public void save(Long userId, String prompt, String answer) { // DB 저장 // 사용량 집계 // 감사 로그 적재 } } 

비동기처리는 마법이 아닙니다. 큐만 길게 쌓이고 소비가 못 따라가면 지연이 뒤로 밀릴 뿐입니다. 그래서 큐 길이와 처리 속도는 꼭 같이 봐야 합니다.

3. Nginx 같은 중간 프록시에서 버퍼링을 확인한다

Streaming을 붙였는데도 사용자 화면에서는 한 번에 몰아서 내려오는 경우가 있습니다. 이럴 때는 애플리케이션보다 프록시 버퍼링을 먼저 의심하는 편이 빠릅니다. 구현은 맞는데 중간 구간이 모아서 전달하고 있으면 체감 개선이 안 보입니다.

 location /api/llm/stream { proxy_pass http://llm-api; proxy_http_version 1.1; # 버퍼링이 켜져 있으면 스트리밍 효과가 사라질 수 있습니다 proxy_buffering off; proxy_cache off; proxy_read_timeout 90s; proxy_send_timeout 90s; chunked_transfer_encoding on; } 

 

Streaming만 붙인다고 LLM API 응답 속도 최적화가 끝나지는 않는다

여기서 자주 생기는 오해가 있습니다. Streaming을 쓰면 모든 응답이 빨라진다고 생각하는 경우입니다. 그런데 실제로는 첫 토큰 도착 시점이 빨라지는 것이지, 모델 자체의 전체 생성 시간이 크게 줄어드는 것은 아닙니다.

프롬프트가 지나치게 길거나, retrieval 문서를 너무 많이 붙이거나, 출력 토큰 제한이 느슨하면 전체 완료 시간은 여전히 깁니다. 즉 이 주제는 Streaming만의 문제가 아니라 프롬프트 길이 관리, 컨텍스트 절약, 출력 상한선 조정, 재시도 정책까지 같이 봐야 합니다.

 

같이 봐야 하는 지표

제가 이 주제에서 꼭 보는 지표는 이렇습니다. 첫 토큰 도착 시간, 전체 응답 완료 시간, 중도 취소 비율, 외부 LLM API 에러율, executor queue size, SSE 연결 수, 프록시 타임아웃 수치입니다. 이걸 같이 봐야 사용자 체감 개선이 진짜인지 확인할 수 있습니다.

특히 모바일 환경은 네트워크 흔들림이 많아서 스트리밍 중도 종료가 생각보다 자주 생깁니다. 그래서 저장 로직은 중복 처리에 안전하게 두는 편이 좋습니다.

LLM API 응답 속도 최적화에서 어떤 방식을 언제 고를 것인가

채팅형 서비스라면 Streaming을 우선 검토하는 편이 좋습니다. 사용자는 답변이 완전히 끝날 때까지 기다리기보다, 바로 읽기 시작하는 경험을 더 선호하기 때문입니다. 이 경우 응답 종료 후 저장과 집계를 비동기로 분리하면 체감과 서버 구조를 같이 개선할 수 있습니다.

반대로 결과 완성본이 중요한 작업이라면 비동기 작업 큐가 더 맞습니다. 리포트 생성, 긴 문서 작성, 대량 요약처럼 몇 초 안에 화면에 토큰이 흐르는 경험이 꼭 필요하지 않은 경우에는 Streaming을 굳이 넣지 않아도 됩니다. 

 

LLM API 응답 속도 최적화의 차가운 결론

Streaming과 비동기처리는 분명 효과가 있습니다. 특히 LLM 기반 채팅이나 작성 보조 기능에서는 사용자 체감 속도를 끌어올리는 데 직접적입니다. 다만 이 둘은 같은 도구가 아닙니다. Streaming은 사용자 경험을, 비동기처리는 서버 구조를 더 많이 다룹니다.

그리고 이것만 도입한다고 모든 문제가 해결되지는 않습니다. 모델 응답이 원래 길면 전체 완료 시간은 여전히 길고, 프롬프트가 무겁고 후처리가 비대하면 병목은 다른 곳으로 이동합니다. 결국 운영 환경에 맞는 튜닝이 필요합니다.

채팅형이면 Streaming을 먼저 보고, 결과 완성본 중심이면 비동기 작업 분리를 먼저 보십시오. 그리고 둘 중 무엇을 선택하든, 저장 로직 분리, 프록시 버퍼링, 타임아웃, 중도 종료 처리까지 같이 설계해야 합니다. 체감상 이 정도까지 챙겨야 비로소 LLM API 응답 속도 최적화가 제대로 작동합니다.