"초당 N토큰"이 진짜로 얼마나 빠른 건지 직접 체감해 보자

토큰 속도, 숫자 너머의 체감

LLM API 문서나 모델 발표 글을 보면 "초당 50토큰", "초당 200토큰" 같은 표현이 자주 나와요. 이게 뭔지 어렴풋이 알긴 하는데, 막상 "그래서 사용자 입장에서 얼마나 빠른 거야?"라고 물으면 답하기가 애매하죠. 50tok/s가 빠른 건지, 느린 건지, 사람이 읽는 속도랑 비교하면 어떤지. 이걸 시각적으로 체감할 수 있게 만든 작은 웹페이지가 있어서 소개할게요. 페이지에 들어가면 다양한 초당 토큰 속도로 텍스트가 실시간으로 출력되는 걸 직접 눈으로 볼 수 있어요. 숫자가 아니라 감각으로 이해할 수 있게 해주는 거죠.

왜 이게 의미가 있냐면, 우리가 LLM을 쓸 때 응답 속도는 단순히 "빠르면 좋다" 수준이 아니라 제품 경험 전체를 결정하는 변수거든요. 초당 5토큰짜리 챗봇과 초당 100토큰짜리 챗봇은 거의 다른 제품이에요. 그래서 이 감각을 정확히 잡고 있으면 API 선택, 모델 선택, UX 설계 결정을 훨씬 정확하게 할 수 있어요.

토큰이라는 단위부터 정리하면

먼저 토큰이 뭔지부터요. 토큰은 LLM이 텍스트를 다룰 때 쓰는 기본 단위인데, 단어보다 작고 글자보다 큰 정도로 생각하면 돼요. 영어에서는 평균적으로 1토큰이 약 0.75단어, 4글자 정도예요. 한국어는 좀 다른데, 한글은 토크나이저에 따라 차이가 크지만 보통 한 글자가 1~2토큰으로 쪼개지는 경우가 많아요. 그래서 같은 "초당 50토큰"이라도 한국어 출력 속도는 영어보다 체감상 더 느리게 느껴질 수 있어요.

사람이 글을 읽는 속도는 평균적으로 분당 200~300단어 정도예요. 토큰으로 환산하면 초당 약 4~7토큰이죠. 즉, 모델이 초당 5토큰 정도면 평범한 독자의 읽기 속도와 비슷한 거예요. 이걸 기준으로 잡으면 감이 더 잘 와요.

초당 10~20토큰은 "느긋하게 읽기보단 따라가는 느낌"이고, 50토큰쯤 되면 "이미 다 출력됐는데 내가 읽는 속도가 못 따라간다"가 돼요. 100토큰이 넘어가면 사실상 즉시 응답으로 느껴지고요. 200토큰 이상은 "화면이 한 번에 채워지는" 수준이에요.

왜 속도가 그렇게 중요한가

LLM 응답 속도는 두 가지 지표로 나뉘어요. 하나는 TTFT(Time To First Token) — 요청을 보내고 첫 글자가 나오기까지 걸리는 시간이고, 다른 하나가 TPS(Tokens Per Second) — 그 이후 토큰들이 흘러나오는 속도예요. UX 관점에선 둘이 다르게 작동해요. TTFT가 길면 사용자가 "멈춘 줄 알았다"고 느끼고, TPS가 낮으면 "답답하다"고 느껴요.

특히 에이전트나 도구 호출 시나리오에서는 속도가 결정적이에요. 에이전트가 여러 단계를 거치면서 각 단계마다 LLM을 호출하는데, 각 호출이 5초 걸리면 전체 흐름이 30초, 1분씩 늘어나거든요. 사용자 입장에선 "AI랑 대화한다"가 아니라 "AI 응답을 기다린다"가 돼버려요. 그래서 Groq, SambaNova, Cerebras 같은 곳들이 초당 수백~수천 토큰을 자랑하는 전용 하드웨어로 인기를 끄는 거고요.

반대로 추론(reasoning) 모델은 의도적으로 느려요. o3나 DeepSeek-R1 같은 모델은 답을 내기 전에 "생각"을 길게 하기 때문에 사용자가 체감하는 응답 시간이 길어지는데, 그 대신 답의 품질이 올라가죠. 그래서 "빠른 모델 vs 똑똑한 모델"의 트레이드오프를 제품 단계에서 신중하게 골라야 해요.

비슷한 도구들과의 비교

토큰 속도를 시각화하거나 측정하는 도구는 몇 가지 더 있어요. artificialanalysis.ai는 주요 모델들의 TPS와 TTFT를 표로 정리해 비교해 주고, OpenRouter도 자기 플랫폼을 통해 호출한 각 모델의 실측 속도를 공개하고 있어요. 다만 이런 사이트들은 데이터를 '읽고 비교'하는 데 가까운데, 이번에 소개한 페이지처럼 "눈으로 직접 본다"는 경험은 또 다른 가치가 있어요. 데이터 시각화에서 show, don't tell의 좋은 예죠.

한국 개발자에게 주는 시사점

첫째, AI 제품을 설계한다면 자기 제품의 목표 TPS를 정해두세요. 채팅이면 최소 30~50토큰, 코딩 자동완성이면 80토큰 이상, 백엔드에서 비동기로 돌리는 거면 속도보다 비용을 우선해도 돼요. 무작정 "빠를수록 좋다"가 아니라 사용 시나리오에 맞춰서요.

둘째, 벤치마크의 함정을 조심하세요. 모델 발표에서 "초당 X토큰"이라고 말할 때, 그게 짧은 컨텍스트 기준인지 긴 컨텍스트인지, 단일 요청인지 동시 요청 100개일 때인지에 따라 결과가 완전히 달라져요. 실제 운영 환경에서는 컨텍스트가 길어지면 TPS가 절반 이하로 떨어지는 경우도 흔해요. 자기 트래픽 패턴으로 직접 측정하는 게 정답이에요.

셋째, 한국어 처리 비용도 고려하세요. 같은 의미의 텍스트를 영어와 한국어로 생성할 때, 한국어 쪽이 더 많은 토큰을 소비할 가능성이 커요. GPT나 Claude는 점점 한국어 토크나이저를 효율화해 왔지만, 모델에 따라 여전히 1.5~2배 차이가 나는 경우가 있어요. 비용과 속도 양쪽에서 영향이 있으니 꼭 자기 데이터로 확인해 보세요.

넷째, 스트리밍 UX를 신경 쓰세요. 같은 모델이라도 청크 단위로 잘 보여주면 체감 속도가 훨씬 빨라져요. 첫 토큰을 받자마자 화면에 보여주고, 토큰이 들어올 때마다 부드럽게 이어 붙이는 단순한 UI 패턴 하나로 "이 앱 빠르네"가 결정돼요.

마무리

초당 토큰 수는 LLM 시대의 "네트워크 속도" 같은 거예요. 숫자로만 보면 잘 안 와닿지만, 한 번 체감하면 제품을 만들거나 모델을 고를 때 직관이 완전히 달라져요.

여러분은 LLM 기반 제품에서 응답 속도와 응답 품질 중에 어디에 더 무게를 두시나요? 또 한국어 토큰 효율성 때문에 모델을 바꾸거나 토크나이저를 따로 다뤄본 경험이 있다면 공유해 주세요.