Gemini API Latency 추적

들어가며

블로그 분석 서비스를 배포했습니다. 베타 테스트로 커뮤니티에 홍보했습니다. 반응이 괜찮았습니다. 

 

광고를 추가하고, 정식 배포를 하려고 하는데요. 한가지 크리티컬한 문제가 있었습니다. Gemini API 를 호출하는데, 평균 응답이 25초 가량 걸린다는 것입니다. 이대로면 이탈률이 매우 높을 것으로 예상되었습니다. 커뮤니티 내에서는 친절한 사용자분들이기 때문에, 시간을 기다려줬겠지만, 시장의 반응은 혹독할 것 같았습니다.

 

그래서 정식 배포 전에, 성능 문제를 해소하고자 했습니다. 성능 분석부터, 병목 지점 확인, 해결책 도출, 테스트, 개선 과정을 이번 글에서 다룹니다.

 

성능 측정

먼저 성능을 측정합니다.

서버의 API 성능을 먼저 살펴볼게요. Cloudflare Workers 에서 성능 모니터링 도구를 제공합니다. 아래 데이터를 보면, p25가 24,842ms, p95 는 39,425ms 입니다. 굉장히 느린 성능을 보입니다.

 

이 API 는 무슨 과정으로 이루어져 있는지 살펴보아야 합니다. 그리고 각 부분을 하나씩 Divide and conquer 해야 합니다.

 

아래 6개 과정으로 이루어져 있습니다.

1. url 을 fetch 하여 html 을 얻어옵니다.
2. html 에서 rss 를 추출합니다.
3. rss 를 fetch 하여 html 을 얻어옵니다.
4. rss 결과물을 파싱합니다.
5. 파싱한 결과를 가지고 Gemini API 를 호출합니다.
6. 클라이언트에 응답합니다.

한번에 모든 성능을 개선해도 좋지만, 성능 개선에도 비용이 존재하기 때문에, 가장 싸게 개선할 수 있으면서, 가장 효과적인 Center 를 먼저 찾아내는 것이 좋습니다.

 

가장 먼저 Gemini API 가 병목으로 의심되었습니다.

Gemini API 성능을 트래킹 해봅시다. Gemini 성능은 Google Cloud Console 의 Metric Explorer 탭에서 확인할 수 있습니다.

 

• p50 : 25,166ms
• p95 : 32,716ms
• p99 : 33,387ms

바로 핵심을 찌른 것 같습니다. API Latency 의 대부분이 Gemini API Latency 에서 오는 것으로 보입니다. 그 다음에는 Gemini API 의 병목 지점을 확인해보려고 합니다.

Gemini API 의 Latency 원인 파악

Gemini API 의 지연 응답의 원인에는 무엇이 있을까요, 무엇이 느린 응답을 만들까요.

Google AI Studio 의 로그를 확인하면 됩니다. 어떤 request 가 왔고, 어떤 추론 과정을 거쳐서, 응답했는지 확인할 수 있습니다. LLM 처리한 token 양을 보여줍니다.

토큰에는 3가지 종류가 있습니다. input, thought, output 입니다.

• input token : request 로 들어온 text 를 읽고 이해하는 토큰의 양입니다. 1초에 수천~수만 토큰 처리가 가능합니다.
• thought token : 응답을 위해서 내부적으로 생각하고 추론하는 토큰의 양입니다. 1초에 100~200토큰만 처리합니다.
• output token : 응답을 생성하는 토큰의 양입니다. 1초에 100~200토큰만 처리합니다.

살펴보면, Input 에는 10만 이상이 들어가고, thought 는 2000대, output 은 1000 정도가 쓰이더군요. 각 파트의 토큰양에 따른, response time 을 시뮬레이션 해볼 수 있다면, 예상 목표 성능을 쉽게 달성할 수 있으리라는 생각이 들었습니다.

 

Gemini Canvas 를 활용하여, 빠르게 시뮬레이터를 만들었습니다.

https://gemini.google.com/share/b10074ffa68e

 

 

위 데이터의 토큰 양으로 시뮬레이션 한다면, 36.22초가 걸리더군요.

 

저는 10초 정도의 응답이 나오기를 원합니다. 그러면 어디까지 줄여야할까요. Output 은 정형화 되어 있기 때문에 토큰을 줄이기 어려웠고, Input 와 thought 를 조절해보았습니다.

 

Input 은 16,000 토큰, thought 는 0으로 조절하면, 9.34초가 걸릴 것으로 예상했습니다.

 

 

어떻게 Input 과 thought 토큰을 줄일 수 있을지 해결책을 찾아봅시다.

Input 토큰 줄이기

Input 을 먼저 줄여봅시다. 블로그 분석을 위해서 10개의 블로그 글을 가지고 왔는데요. 그리고 각 글의 모든 정보를 다 넣어주고 있었죠.

import { RSSPostType } from "./type";

export const parseBlogIntoString = ({
  blogPosts,
}: {
  blogPosts: RSSPostType[];
}) => `
${blogPosts
    .map((blog, index) => `
### 글 ${index + 1}
- 제목: ${blog.title}
- 작성자: ${blog.author}
- 설명: ${blog.description}
- 링크: ${blog.link}
`
    )
    .join("\\n")}
`;

블로그 글을 길게 작성하는 경우, 10개의 글을 합치면 토큰이 10만을 넘어가기도 하였습니다.

 

블로그 전문이 필요할까? 생각해보면 그렇지 않았습니다. 블로그에서 문체의 느낌을 위주로 분석하는 것이기 때문에, 앞부분만 가져와도 되었습니다. 앞의 1000자를 잘라서 가지고 왔습니다.

 

그리고 작성자는 매 글마다 동일할 것이므로, 반복문에서 제외했습니다.

import { RSSPostType } from './type';

const MAX_DESCRIPTION_LENGTH = 1000;

export const parseBlogIntoString = ({
  blogPosts,
}: {
  blogPosts: RSSPostType[];
}) => `
작성자: ${blogPosts[0].author}

${blogPosts
    .map(
      (blog, index) => `
### 글 ${index + 1}
- 제목: ${blog.title}
- 설명: ${blog.description.slice(0, MAX_DESCRIPTION_LENGTH)}
- 링크: ${blog.link}
`
    )
    .join('\\n')}
`;

 

thought 토큰 줄이기

저는 gemini-2.5-flash 모델을 쓰고 있었습니다. 이는 thinking 모델입니다. 블로그 글을 분석하는데, thinking 모델을 꼭 써야 할까? 생각해볼 수 있습니다. gemini-2.5-flash-lite 는 thinking 모델이 아니어서, 자동으로 thought token 을 0으로 쓰게 됩니다. 이러면, 응답 시간이 5~10초 가량 빨라질 것입니다.

 

비슷한 퀄리티만 유지할 수 있다면, 큰 임팩트를 낼 수 있을 것 같았죠. 그렇게 모델을 교체했습니다.

 

그리고 API 를 호출하고, 토큰 사용량과 응답 속도를 보았습니다.

응답 토큰이 확연히 줄었습니다.

 

응답 속도도 10초 미만으로 달성할 수 있었습니다.

 

퀄리티 유지가 되는가?

토큰을 막 줄이고, 모델을 바꾸는 것을 쉽습니다. 이것이 동일한 퀄리티를 유지할 수 있느냐가 중요한 질문이겠죠.

 

이전 모델에서 나온 응답과의 일치 여부를 보려고 했습니다. MBTI 분석, 컨텐츠 카테고리 비율 등이 내용에 포함되어 있는데요. 이게 이전 모델과 얼마나 일치하는지 보았습니다. 케이스 자체가 많지는 않았으므로, 십수개를 조사했습니다. 대부분 기존 결과와 유사해서, 퀄리티의 문제가 없다고 보았습니다.

 

이론적으로 살펴보자면, gemini-2.5-flash-lite 도 context window 가 1M 이기 때문에, 긴 input 도 쉽게 처리할 수 있습니다. 또한 thinking 모델이 아닌 Standard 모델도 문서 요약에 능합니다. LLM 의 기본 성질이 next token prediction 이므로, 참조할 글만 있다면, 어렵지 않게 문서를 요약하고, 새로운 글을 만들어낼 수 있습니다. 엄청나게 빠른 속도로요.

 

Standard 모델로 바꾸어도, 퀄리티에 문제가 없다는 결론에 다다르게 되었습니다.

 

마치며

백엔드 분야에서 성능을 분석하고, 개선해본 경험은 처음이었습니다. 그렇지만 저는 프론트엔드 성능 분석에 강점이 있습니다. 성능을 개선한다는 것은, 측정 → 병목 지점 파악 → 요소별 원인 분석 → 해결책 도출 → 적용 → 재측정 흐름을 타는 것은 동일합니다. 이 멘탈 모델이 중요할 뿐, 프론트엔드냐, 백엔드냐 하는 것은 중요하지 않았습니다. 그래서 서버 성능 측정, LLM 성능 측정, 토큰 성능 측정 등 처음 접하는 분야가 많았지만, 하나씩 학습해가며 성능 개선을 해냈습니다. 이는 일차적 성능 개선이고, 배포 이후 더 개선할 필요성이 있다면 다시 분석과 개선 과정을 거치려고 합니다.