Viktor is an AI coworker that lives in Slack, right where your team already works.

Message Viktor like a teammate: "pull last quarter's revenue by channel," or "build a dashboard for our board meeting."

Viktor connects to your tools, does the work, and delivers the actual report, spreadsheet, or dashboard. Not a summary. The real thing.

There’s no new software to adopt and no one to train.

Most teams start with one task. Within a week, Viktor is handling half of their ops.

Add Viktor to Slack for free.

며칠 전 공유드린 ‘AI가 세상을 이해하는 단위, 토큰’ 에피소드에서는 토큰의 정의, 토큰화라는 과정을 통해서 어떻게 입력값 - 텍스트, 비디오, 오디오 등 - 이 모델이 처리할 수 있는 형태로 바뀌는지 등을 간단하게나마 살펴봤습니다.

기초를 다뤘으니, 이제 진짜 승부가 벌어지는 실전 현장의 이야기를 해야겠죠? 현업에서는 더 이상 '토큰'을 단순히 하나로 뭉뚱그려 정의하지 않기도 하구요.

최근에 엔비디아의 젠슨 황(Jensen Huang)은 AI 비즈니스의 본질을 "전자를 토큰으로 변환하는 과정"이라고 정의한 바 있는데요. 대단한 비유이기는 하지만, 개인적으로 지금의 현실을 다 담기엔 조금 부족하다고 느낍니다 - 말씀드렸다시피, 토큰이라는 단어 자체가 이제 단일한 개념의 범위를 벗어나기도 했으니까요.

단 한 번의 API 호출 그 뒷편에, 수많은 종류의 ‘토큰’들이 각기 바쁘게 움직이고 작동합니다. 입력 토큰과 출력 토큰은 기본이고, 추론 토큰, 캐시된 토큰, 도구 사용(Tool Use) 토큰, 비전 토큰까지... 이 각각이 과금 체계도 다를 뿐더러, 연산 자원을 잡아먹는 방식도 제각각입니다.

여러분이 앞으로 구축할 ‘AI 시스템’의 방향을 결정하고, 그 소중한 '전자'를 어디에 투입할지 고민하는 리더나 엔지니어라면, '토큰의 분류학(Token Taxonomy)'에 대해서 정확히 이해하고 있어야 합니다. 이 복잡하고 다양한 토큰들이 어떤 것들이고 왜 다르게 작동하는지 보여주는 지도가 머릿속에 있어야 한다는 뜻이예요.

자, 이제 튜링포스트에서 정리한 '토큰 동물원(Token Zoo)'의 지도를 여러분과 공유합니다 - 아마 여러분도 모르는 사이에 이미 비용은 꼬박꼬박 지불하고 있었을, 다소 생소하지만 아주 중요하고도 치명적인 토큰 종(種)들을 하나씩 소개해 드리겠습니다.

오늘 에피소드는 다음과 같은 내용을 다룹니다:

일단, AI와 관련된 모든 API 호출에는 ‘여러분이 보낸 내용(입력 토큰)’과 ‘모델이 돌려준 대답(출력 토큰)’이라는 두 가지 측면이 있습니다. 짐작하시다시피, 텍스트를 생성하는 쪽이 읽는 것보다는 연산이라는 관점에서 훨씬 더 어려운 작업이구요.

일단, 모델이 입력을 처리할 때는 병렬 처리를 할 수 있죠. 프롬프트에 포함된 모든 토큰들은 이른바 프리필(Prefill) 단계에서 거의 동시에 처리돼요. 다시 말해서, 모델은 단 한 번의 순전파(forward pass)를 통해서 여러분이 한 모든 말의 내부적 표현(Internal Representation)을 구축해 내게 됩니다.

그런데, 출력은 좀 달라요. 각각의 토큰이 바로 이전 토큰에 의존하면서, 모델이 다음 토큰을 하나씩 만들어냅니다. 이게 바로 자기회귀(Autoregressive) 생성이고, 이 과정은 본질적으로 순차적입니다. 새로운 토큰 하나를 만들 때마다 모델(또는 최소한 디코더 레이어) 전체를 통과하는 별도의 순전파 과정이 필요해서, 그래서 출력 토큰이 더 비싸게 되는 겁니다 - 토큰 하나당 투입되는 연산량이 훨씬 많으니까요.

모든 API 가격 페이지에서 입력 토큰과 출력 토큰 간에 가격 차이가 발생하는 이유도 이것 때문입니다. 2026년 중반 현재 기준으로, AI 모델의 제공업체와 모델 종류에 따라서 다르기는 하지만, 보통 출력 토큰은 입력 토큰보다 2배에서 6배 정도 더 비쌉니다. 그리고, 이 비율은 하드웨어가 실제로 사용되는 방식의 차이를 그대로 반영하는 숫자라고 보시면 됩니다.

여기서 생각해 볼 만한 실질적인 시사점은, 만약 여러분이 품질을 유지하면서도 출력 길이를 줄이게끔 작업 구조를 재조정할 수만 있다면 — 예를 들어서, 장황한 설명 대신 구조화된 JSON 형식을 요구하는 식으로 말이죠 — 그것만으로도 이미 비용을 꽤 절감하고 있는 셈이라는 거예요.

이 카테고리의 토큰은, 아마 2024년 이후에 가장 드라마틱하게 부상한 토큰일 겁니다.

흔히 ‘생각 토큰(Thinking Tokens)’이라고 부르기도 하는 추론 토큰(Reasoning Tokens)은, 모델이 최종적인 답변을 내놓기 전에 '생각의 사슬(CoT; Chain-of-thought)' 과정의 일부로 내부에서 생성하는 토큰들입니다.

심화된 사고 기능이 있는 모델을 쓸 때, 모델이 곧바로 정답을 내놓는게 아니잖아요? 먼저 문제를 ‘차근차근 생각’하면서 내부적으로 독백을 만들어내는데, 이 과정은 사용자한테는 일부만 보이든지, 아니면 완전히 가려지는 경우도 있습니다. 하지만, 이 중간 단계의 토큰들도 당연히 연산 자원을 쓰는, 즉 돈이 드는 토큰들입니다. 문제는, 이런 토큰들이 응답하는 과정에 사용되는 전체 토큰 수를 엄청나게 부풀릴 수 있다는 거예요.

경제적인 관점에서 추론 토큰이 흥미로운 이유는 이렇습니다:

현재 일부 AI 모델 제공업체들은 API 응답에서 추론 토큰 수를 별도 항목으로 공개하기 시작했죠. 반면에 다른 곳들은 이 추론 토큰 비용을 출력 토큰 가격에 포함해버리기도 합니다. 아직 토큰 가격 공개에 대한 표준이 없기 때문인데, 이것 때문에 업체들 간 비용 비교가 좀 까다로워지기도 합니다.

젠슨 황은 최근 드와르케쉬 파텔(Dwarkesh Patel)과의 대담에서 ‘추론 토큰을 별도의 가격 책정 카테고리로 명시’했습니다. 여기서 흥미로운, 그리고 기억해야 할 지점은, 토큰이라는게 이제 단일한 상품이 아니라, 용도에 따라 세분화된 '제품' 카테고리가 되었다는 겁니다.

추론 토큰과 관련해서, 'Claude Code'의 개발자인 보리스 처니(Boris Cherny)가 전하는 실질적인 팁을 몇 가지 공유합니다:

추론 토큰이 '생각'을 더 해서 비용을 높이는 거라면, 투기적 토큰(Speculative tokens)은 정반대의 이유로 기묘한 존재인데, 왜냐하면 이것들은 애초에 대부분 버려질 것을 전제로 생성되기 때문이예요.

아마도 많은 종류의 토큰들 중에 이 투기적 토큰이 가장 우리의 직관과는 어긋나는 개념일지도 몰라요. 그렇지만 2026년 현재, 이 투기적 토큰은 대부분의 주요 추론 서비스 제공업체에서 도입한 표준 기술이기도 합니다.

이 기술이 해결하는 문제가 뭐냐 하면, 앞서 설명했듯이 ‘자기회귀적 생성’ 작업은 순차적이라는 특성을 갖고 있잖아요? 그래서 속도가 느릴 수 밖에 없죠. 하드웨어가 다음 단계 작업 시작 전까지 이전 단계 종료를 기다리면서 부분적으로 유휴 상태(Idle State)에 있게 됩니다. 일종의 병목 현상이 발생하는 거죠.

이 때, 투기적 디코딩(Speculative Decoding)은 영리한 트릭을 사용해서 이 병목 현상을 해결합니다. 크고 무거운 타겟 모델이 토큰을 하나씩 생성하는 대신에, 작고 가벼운 '초안(Draft) 모델'이 미리 달려나가면서 ‘5개에서 10개 이상의 후보 토큰을 병렬로 제안’합니다. 그 후에, 타겟 모델이 단 한 번의 순전파 과정을 통해서 이 후보들을 한꺼번에 검증해서, 자신의 계산 결과와 일치하는 토큰만 남기고 나머지는 가차없이 버리는 거예요.

결과적으로, 연산 오버헤드는 약간 늘어나지만 지연 시간(Latency)은 적어도 2~3배 줄어듭니다. 일치하지 않는 초안 토큰은 거부되고 다시 제대로 생성이 되기 때문에, 타겟 모델의 출력 품질은 수학적으로 완벽하게 유지됩니다. 정답의 정확도는 그대로인데 속도만 빨라지는 거라고 보면 되겠습니다.

투기적 토큰이 흥미로운 이유는, 바로 이 친구들도 실제로 생성되어서 파이프라인을 흐르는 진짜 토큰이라는 점인데, 그렇지만 사용자에게는 보이지 않고 대부분의 투기적 토큰은 의도적으로 폐기됩니다. 다시 말하면, 이 친구들은 '컨텐츠'로서가 아니라 오직 '속도의 최적화'라는 목표를 위해서 존재하는 겁니다.

이 분야에는 또 여러 가지의 변형 기법이 있습니다. EAGLE은 타겟 모델의 내부 상태를 활용해서 더 정확한 초안을 작성하고, SpecInfer 같은 트리 기반 방식은 단일한 선형 구조가 아니라 가지를 치는 형태의 후보 시퀀스를 제안해서 토큰의 검증 통과 확률을 높입니다. Medusa라는 기법은 별도의 초안 모델 없이 타겟 모델에 직접 예측 헤드를 추가하는 방식을 택하구요.

사용자에게는 ‘투기적 디코딩’은 거의 보이지 않는 작업 과정이고, 그냥 응답이 빨라졌다고 느낄 수 있을 뿐이예요. 하지만 추론 인프라 관리자의 관점에서는 지연 시간과 처리량(Throughput)을 조절하는 가장 중요한 레버 중의 하나죠. 또, 이 ‘투기적 토큰’ 때문에 "생성된 토큰 수"라는 개념이 복잡하게 되죠 - 시스템이 실제 사용자에게 전달되는 것보다 30%나 더 많은 토큰을 내부적으로 생성하고 버릴 수 있는 셈이니까요.

연산량이 추가되는 추론 토큰과는 달리, 캐시된 토큰(Cached Tokens)은 거꾸로 연산량을 줄여줍니다. 프롬프트 캐싱(또는 컨텍스트 캐싱)을 사용하면 모델이 ‘동일한 입력’에 대해서는 이미 수행한 작업을 재사용할 수 있거든요.

작동 원리는 이렇습니다. 프롬프트를 보내면 모델이 이 프롬프트를 처리해서 내부 표현(Internal Representation)의 집합인 KV 캐시(Key-Value Cache)를 구축하게 되는데, 동일한 시스템 프롬프트, 긴 문서, 또는 지시사항 세트를 다시 보내게 되면 모델이 해당하는 부분에 대한 계산은 건너뛰고 저장된 KV 값을 그대로 꺼내 쓰는 겁니다.

토큰 캐싱을 하면 실제 현장의 워크로드에서는 엄청나게 큰 차이가 발생해요. 예를 들어서, 매번 호출할 때마다 4,000 토큰의 시스템 프롬프트와 10,000 토큰의 문서를 포함하고 사용자 질문만 200 토큰씩 바뀌는 에이전트 시스템이 있다고 가정해 봅시다. 캐싱이 없다면 매번 14,000 토큰을 새로 계산해야 하지만, 캐싱을 쓰면 처음 한 번만 계산하고 이후에는 12,000 토큰만큼은 계속 재사용할 수 있는 겁니다.

주요 AI 모델 제공업체들의 캐시 토큰 가격 책정 방식을 알아보면 다음과 같습니다:

이 절감 효과는, 아까도 말씀드렸다시피, 효과가 아주 빠르게 누적됩니다. 8,000 토큰의 고정 접두사(prefix)를 사용하는 기업이 하루 10,000번의 API 호출을 한다면, 입력 토큰 비용이 최소 10분의 1 이하로 줄어든다고 생각할 수 있으니까요.

알아두어야 할 점은, 캐시에도 유효기간이 있다는 겁니다. 제공업체나 인프라 상황에 따라 보통 몇 분에서 몇 시간 동안만 유지가 돼요. 그래서, 트래픽이 불규칙하거나 뜸한 경우라면, 캐싱의 효과를 보기 어려울 수 있습니다. 최근에는 여러 사용자가 동일한 시스템 프롬프트를 공유할 때 인프라 차원에서 이걸 한 번만 계산해서 공유하는 '사용자 간 KV 캐싱' 기술도 등장해서 효율성을 더욱 극대화해 주는 방향으로 발전하고 있습니다.

이 카테고리는, 생각보다 많은 사람들이 간과하는 부분인데요. 모델이 함수 호출(Function calling), API 연동, 코드 실행, 웹 검색 등의 도구를 사용할 때, 여러분 눈에는 직접 보이지 않지만 토큰들이 대량으로 소비됩니다.

구체적인 예시를 한 번 들어볼께요. 3,000 토큰짜리 시스템 프롬프트를 가진 에이전트가 8개의 도구(스키마 2,500토큰)를 사용하면서 사용자의 질문을 처리하기 위해 6번의 루프를 돈다고 가정해 봅시다. 마지막 루프에 도달할 때쯤에는, 컨텍스트에는 30,000개 이상의 토큰이 쌓여 있을 겁니다. 모든 루프를 통틀어서 소비된 총 토큰 수는 어떨까요? 사용자가 보낸 질문은 단 50 토큰이었고 답변은 300 토큰에 불과했지만, 실제로는 100,000개 이상의 토큰이 소모될 수 있다는 거예요.

이게 바로 에이전트형 AI의 '숨겨진 비용'입니다. 에이전트 워크플로우의 토큰 청구액은 단순한 일회성 대화 비용과 비교하면 50배에서 200배가 될 수 있습니다. 에이전트를 스케일있게 배포하고 있는 기업들은 지금 이 사실을 뼈아프게 배우고 있겠죠?

숨겨진 오버헤드 문제 중에서도 특히 따로 떼어서 주목해야 할 변종이 있는데, 많은 운영 시스템에서 단일 항목으로는 가장 큰 토큰 소비 주범이 되고 있다고 이야기하는, 바로 ‘검색된 컨텍스트(Retrieved Context)’예요.

검색 증강 생성(RAG) 환경에서, 아시다시피 모델은 기억력에만 의존해 답변하지 않죠. 먼저 벡터 데이터베이스, 검색 엔진, 또는 내부 지식 베이스에서 관련 문서를 찾아낸 다음에, 그 조각들을 프롬프트에 컨텍스트로 주입합니다. 30 토큰 짜리 사용자 질문 하나가 5,000~15,000토큰 이상의 문서 검색을 바로 진행해 버릴 수 있다는 겁니다.

이것만으로도 이미 상당한 배수 효과가 있는 거지만, 에이전트형 RAG 워크플로우에서는 문제가 더 심각해집니다. 모델이 검색을 하고, 결과를 읽고, 정보가 더 필요하다고 판단해서 다시 검색하고, 생각을 한 번 하고 다시 세 번째 검색을 수행하는 식입니다. 각 검색 단계마다 이미 윈도우에 쌓인 정보 위에 새로운 컨텍스트 토큰의 물결이 계속해서 덮쳐옵니다. 다단계 에이전트 RAG는 단일 검색 패스보다 총 토큰 소비량을 최소 3배에서 10배까지 끌어올릴 수 있습니다.

물론, 이 토큰들이 가치가 없다는 게 아닙니다. 실제 문서에 기반해서 모델의 환각(Hallucination)을 줄이고 정확도를 높여주는 중요한 작업을 하는데 쓰이는 겁니다. 하지만, 비용이 만만치 않다는 거예요.

이제 스마트한 고객들은 검색의 품질과 컨텍스트 압축을 토큰 이코노미를 조정하기 위한 핵심적인 주안점으로 보고, 검색된 조각들의 순위를 재조정(Reranking)해서 가장 관련 높은 것만 프롬프트에 넣거나, 주입하기 전에 긴 문서를 요약하거나, 핵심 정보는 유지하면서 텍스트를 압축하는 LLMLingua 같은 기술을 활용하는 방식 등 다양한 기법을 활용합니다. 그렇게 해야 하는 거죠.

이 과정에서의 목표는, 검색량을 줄이는 것이 아니라, 바로 더 똑똑하게 검색하는 것입니다. 그래야 토큰 비용을 다 지불하지 않고도 검색 작업의 혜택을 온전히 누릴 수 있습니다.

‘토큰’이라는 개념은 원래 자연어 처리(NLP)라는 기술 영역에서 생겨났지만, 이제 다른 데이터 포맷(모달리티;Modality)까지 영역을 넓혔습니다. 모든 모달리티는 각각 다른 방식으로 토큰화가 되는데, 이런 방식의 차이 때문에 모달리티의 토큰 간에 극적으로 비용 변화가 나타납니다.

GPT, Claude, Gemini 같은 모델에 이미지를 보낼 때, 모델은 여러분처럼 이미지를 통째로 '보는' 것이 아닙니다. 이미지는 격자 형태의 패치(Patch) — 작은 사각형 영역들 — 로 나뉘게 되고, 각 패치가 하나의 토큰(또는 소수의 토큰 묶음)이 됩니다. 고해상도 이미지는 1,000~2,000개의 토큰을 생성하고, 상세한 인포그래픽이라면 3,000개의 토큰을 훌쩍 넘기기도 합니다.

이게 뜻하는 바가 뭘까요? 간단한 질문을 하려고 스크린샷을 찍어서 업로드하는게, 텍스트 한 페이지를 입력하는 것보다 비용이 클 수 있다는 겁니다. 이미지의 해상도가 토큰 수와 직접적인 연관관계가 있어서, 해상도가 높을수록 격자가 세밀해지고, 패치가 많아지면서 토큰 수도 늘어납니다. 그래서 대부분의 업체는 이미지를 축소해서 토큰을 적게 생성하는 '저화질(Low Detail)' 모드를 제공하기도 합니다.

비전 토큰 뒤에 숨겨진 아키텍처는 바로 비전 인코더(주로 ViT – Vision Transformer)입니다. 이미지를 패치 임베딩으로 처리한 뒤에, 이걸 언어 모델이 사용하는 것과 동일한 임베딩 공간으로 투사합니다. 모델 입장에서는 트랜스포머에 들어온 이상 이미지 패치나 텍스트 토큰이나 똑같은 형태의 객체인 셈이라는 거예요.

오디오의 토큰화는 조금 다른 길을 택합니다. Whisper 같은 모델은 먼저 오디오를 스펙트로그램(Spectrogram) — 시간에 따른 주파수의 시각적 표현 — 으로 변환한 다음, 이걸 프레임 단위로 자릅니다. 각 프레임이 하나의 토큰이 되는데, 음성의 경우에 보통 오디오 20~40밀리초당 토큰 하나가 생성됩니다.

그래서, 30초짜리 오디오 클립은 750~1,500개의 토큰을 생성할 수 있습니다. 1시간짜리 회의 녹음본이라면, 무려 90,000~180,000개입니다. 이게 바로 오디오 네이티브 AI가 비싼 이유이고, 실제 수많은 AI 시스템들이 오디오를 먼저 텍스트로 받아쓰기(Transcribe) 한 뒤에 텍스트로 처리하는 이유예요. Gemini 같은 네이티브 멀티모달 모델은 텍스트와 함께 오디오 토큰을 직접 처리할 수 있어서 톤이나 강조, 비언어적 신호까지 보존하지만, 텍스트를 전사하는 방식보다 훨씬 더 많은 토큰 비용이 발생하죠.

비디오는 토큰을 가장 많이 잡아먹는 '식신'이라고 할 수 있어요. 생각해 보면, 비디오는 본질적으로 이미지(프레임)의 연속체와 오디오 트랙이 결합한 거잖아요? 단순하게 토큰화하면 프레임 수 × 프레임당 패치 수만큼의 엄청난 토큰이 나옵니다. 초당 30프레임, 프레임당 256개 패치를 가진 10초짜리 비디오라면 단 10초 만에 76,800토큰이 생성됩니다.

그래서, 실제로는 시간적인 압축 기술을 사용합니다. 주요 프레임(Keyframes)을 샘플링하고 프레임 간의 변화를 추적해 가면서 차이점만 토큰화하는 식이죠. 그렇지만 이런 압축 기법을 적용해도 비디오 입력은 텍스트보다 수백배, 수천배는 더 비쌉니다. 비디오 이해 능력이 이미지 대비 여전히 초기 단계인 이유 중 하나도, 현재 가격대에서 요구되는 토큰 예산이 너무 실용성이 떨어지기 때문이예요.

코드는 기본적으로 텍스트의 형태를 띠지만, 우리가 일상적으로 쓰는 자연어와는 문법도, 구조도 완전히 다릅니다. 코드에는 수많은 공백(Space), 들여쓰기(Indent), 각종 괄호와 기호가 가득하죠. 일반적인 대화문에서는 거의 쓰이지 않는 것들입니다.

문제는 많은 AI 토크나이저가 이런 특수 기호들을 효율적으로 처리하지 못한다는 데 있습니다. 예를 들어서, 우리 눈에는 그저 한 번의 '들여쓰기'일 뿐인 빈 공간을, AI는 서너 개의 개별 토큰으로 잘게 쪼개서 인식하곤 합니다. 일종의 '낭비'가 발생하는 셈이죠.

이런 차이는 실제 비용과 직결됩니다. 똑같은 로직을 구현하더라도, 들여쓰기가 필수인 Python과 중괄호를 많이 쓰는 C++은 AI가 계산하는 토큰 수가 확연히 다릅니다. 문법이 상대적으로 장황한 Java 같은 언어는 Python이나 Go처럼 간결한 언어보다 토큰 비용이 더 많이 나올 수 있구요.

최근에는 코드만 전문적으로 다루는 토크나이저를 만들어서 효율을 높이기도 하지만, 여전히 고작 500줄짜리 스크립트 하나가 3,000~5,000개의 토큰을 순식간에 잡아먹는 일은 비일비재합니다. 코드를 AI로 처리할 때 유독 비용이 비싸게 느껴지는 이유가 바로 여기에 있습니다.

어떤 모델이든 상관없이, AI 모델의 이면에는 ‘동작을 정교하게 제어하면서도, 정작 겉으로 드러나는 의미는 담지 않는 특수 토큰(Special Tokens)들’이 숨어 있습니다. 평소에 우리 눈엔 잘 띄지 않지만, 모델이 정상적으로 작동하기 위해선 반드시 존재해야 하는, 이른바 '시스템의 윤활유' 같은 존재들이죠.

일반적으로 사용자가 이 토큰들을 직접 마주할 일은 거의 없지만 "128K 컨텍스트 윈도우"라고 해서 여러분의 콘텐츠를 정확히 128,000토큰까지 꽉 채워 넣을 수 없는 이유가 바로 여기에 있습니다. 전체 용량 중 일정 부분은 이렇게, 마치 시스템 유지를 위한 '구조적 세금'같이 미리 떼어가기 때문입니다.

지금까지 다양한 토큰 유형에 대해서 알아봤는데요. 이런 토큰 유형의 다양성과 차이 때문에 "이 AI 시스템을 돌리는 데 비용이 얼마나 드는가?"라는 질문에 대한 답변을 얼른 내놓기가 쉽지만은 않습니다. 핵심적인 시사점은 다음과 같습니다.

결국 이 모든 이야기는 하나의 본질적인 아키텍처 포인트로 귀결됩니다. 우리가 지금까지 살펴본 추론 토큰, 투기적 토큰, 캐시 토큰, 멀티모달 토큰 등은 사실 지금 이 시점의 기술적 한계와 구조가 만들어낸 산물일 뿐입니다. 미래의 AI 모델이 지금과는 완전히 다른 메커니즘으로 진화한다면, 우리가 정의한 '토큰 동물원'의 분류 체계 역시 완전히 뒤바뀌겠죠.

하지만 기술의 형태가 변하더라도 결코 변하지 않는 사실이 하나 있습니다. AI 연산은 반드시 측정되어야 하고, 그 비용과 가치를 측정하는 '계량기'는 언제나 토큰이라는 단위로 돌아간다는 점입니다.

결국, 토큰을 이해한다는 건, 단순히 기술적 용어를 익히는 것을 넘어서 AI라는 거대한 연산 자원이 어떻게 경제적 가치로 치환되는지 그 핵심 원리를 파악할 수 있는 기본입니다.

토큰이 무엇인지 이해하는 것도 중요하지만, 실무에서 더 핵심적인 능력은 각기 다른 '토큰 종(種)'에 맞춰서 예산을 짜고 전략을 세우는 법을 아는 겁니다. 추론 토큰은 더 정교한 답변을 내놓는 대가로 고지서의 숫자를 몇 배씩 불립니다. 투기적 토큰은 속도를 높이기 위해서 보이지 않는 곳에서 수백만 개씩 생성되었다가 소리 없이 버려집니다. 반면에, 캐시된 토큰은 기존 문맥을 재사용해서 비용을 획기적으로 아껴주죠.

도구 사용 및 검색(Retrieval) 토큰은 에이전트의 작업 흐름 뒤에 숨어서 조용히 스스로의 점유율을 높여가고 있습니다. 멀티모달 토큰은 AI가 보고 들을 수 있게 해주지만, 정보량 대비 비용 효율은 천차만별입니다. 마지막으로 구조적 토큰은 시스템을 굴리기 위해서 컨텍스트 윈도우의 자리를 묵묵히 차지하고 있죠.

단순히 '최고의 모델'을 고르는 단계를 넘어서, 이미 가장 앞서가는 팀들은 '토큰 포트폴리오'를 관리하기 시작했습니다. 작업의 성격에 맞는 토큰 프로필을 가진 모델로 업무를 배분(Routing)하고, 공격적으로 캐싱을 적용하고, 가능한 부분은 압축합니다. 그리고 각 토큰이 투입된 비용 대비 실제로 어떤 가치를 창출하는지 면밀히 측정합니다.

어쩌면, 다음 단계의 기술적 격전지는 '스스로 삭제되는 토큰'이 될지도 모릅니다. 추론 중간에 가치가 낮은 토큰을 다이나믹하게 솎아내어(Pruning), 컨텍스트 윈도우의 공간과 연산 자원을 확보하는 기술입니다. 아직 초기 단계지만, 이 방향은 모델이 스스로 자신의 '토큰 동물원'을 관리하게 될 미래를 암시합니다.

우리는 이제 응답 속도(Latency)에 따라 동일한 토큰이라도 가격이 달라지는 시대를 맞이하고 있습니다. 코드 자동 완성을 위한 '빠른 토큰'은 더 비싸지고, 대량의 배치 작업을 위한 '느린 토큰'은 더 저렴해질 것입니다. 이는 제품을 정해진 패키지로 파는 전통적인 소프트웨어 방식보다는, 인도 조건과 등급에 따라 가격이 춤을 추는 원자재(Commodity) 시장에 더 가깝습니다.

이런 변화가 가속화됨에 따라서, AI 제품 설계는 일종의 '시장 설계' 문제가 되겠죠. 어떤 사용자 경험에 프리미엄 실시간 추론을 할당하고, 어떤 작업을 저렴하고 느린 워크플로우로 돌릴지 끊임없이 결정해야 하기 때문입니다. 이제 AI 제품을 만드는 이들에게 아키텍처란 기술적인 질문인 동시에, 아주 치열하게 고민해야 할 경제적인 질문이기도 합니다. 이건, 지금까지 우리가 알던 방식과는 완전히 다른, 진정한 변화의 시작이 될 겁니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!