LLM 내부 아키텍처 직관적 해설 — 왜 그런 구조가 탄생했는지 비유로 이해하기

• LLM의 내부에 있는 메커니즘은 갑자기 완성된 형태로 나타난 것이 아니라, 그때그때의 "어려움"을 해결하기 위해 하나씩 쌓아 올려 왔다고 볼 수 있습니다.
• 본 기사에서는 Attention / Transformer, Mixture of Experts (MoE), KV Cache, Speculative Decoding의 4가지를 수식을 거의 사용하지 않고, "왜 그것이 필요했는가"라는 발명의 동기부터 비유를 통해 정리합니다. - 모든 고안에는 "무언가를 얻기 위해 무언가를 희생했다"는 트레이드오프 (Trade-off)가 있습니다. 이 부분을 의식하면 모델 선정, 비용 최적화, 추론 파라미터 조정의 판단이 흔들리지 않게 된다고 저는 느끼고 있습니다.
• 2026년의 화두로서, 긴 컨텍스트 (Long Context) 시대의 문맥에서 중요성이 커지고 있는 **KV Cache 압축 (TurboQuant 등)**에 대해서도 다룹니다.

LLM의 API를 호출하는 것만으로도 어느 정도의 앱은 만들 수 있습니다. 반면, 내부 메커니즘을 "결과"가 아니라 "어떤 문제를 해결하기 위해 태어났는가"라는 순서로 파악해 두면, 다음과 같은 상황에서 판단이 흔들리지 않게 된다고 저는 느끼고 있습니다.

• 모델 선정: 같은 "30B 클래스"라도 밀집 모델 (Dense)과 MoE는 추론 비용이나 필요 메모리가 크게 다릅니다. 왜 다른지를 알고 있으면 스펙 표의 숫자가 가진 의미가 다르게 보입니다. -
• 비용 최적화: 긴 프롬프트의 비용이 "왜 높은가"를 KV Cache의 관점에서 설명할 수 있다면, 설계의 타협점을 찾을 수 있습니다. -
• 추론 파라미터 조정: Speculative Decoding 계열의 기능을 가진 런타임 (vLLM, TGI, llama.cpp 등)에서는 온도 (Temperature)나 탐욕적 디코딩 (Greedy Decoding)의 선택에 따라 속도가 달라집니다. 왜 빨라지는지를 알면 설정의 시행착오를 줄이기 쉬워집니다.

기술 해설은 "어떻게 작동하는가 (How)"부터 시작하는 경우가 많지만, 본 기사에서는 가능한 한 "왜 그렇게 하고 싶었는가 (Why)"를 먼저 배치하도록 했습니다. 발명의 동기를 알면 세부 사항을 잊더라도 전체적인 상이 머릿속에 남기 쉽다는 개인적인 실념에 바탕을 두었습니다.

물론 여기서 소개하는 관점이 유일한 정답은 아닙니다. 논문 설명, 구현 측의 해설, 벤더의 블로그 등 유파에 따라 표현은 상당히 다르므로, 여러 설명을 비교하며 읽어보는 것을 추천합니다.

• 대상 독자: LLM API는 다뤄본 적이 있지만, 내부 메커니즘은 "어렴풋이 블랙박스"라고 느끼고 있는 분.
• 전제 지식: 특별한 수학이나 프레임워크 지식은 전제로 하지 않습니다. 비유를 중심으로 진행합니다.
• 다루는 범위: Attention / Transformer, MoE, KV Cache, Speculative Decoding의 4가지와, 2026년의 화두로서 KV Cache 압축을 추가합니다. RoPE / SwiGLU는 개요 정도만 다룹니다.

수식의 유도나 코드 구현에는 깊이 들어가지 않습니다. 그 부분을 심도 있게 파고들고 싶은 분은 말미의 참고 링크 (논문, 각 블로그)로 넘어가시는 것이 좋을 것 같습니다.

본론에 들어가기 전에, 앞으로 다룰 4가지가 "대략 무엇인지"를 한마디와 비유만으로 짚고 넘어갑니다. 자세한 이유는 각 장에서 전개하므로, 여기서는 "흐음, 그런 위치구나" 정도의 감각이면 충분합니다.

메커니즘	한마디로 말하면	일상의 비유
Attention (Self-Attention)	문장 속 단어들끼리 서로의 "관련성 강도"를 계산하는 부품	회의에서 "지금 화제와 관련된 사람이 누구의 발언인가"를 파악하는 메커니즘
...

위의 표에서 Attention과 Transformer를 나누어 나열했지만, 이 둘은 동일한 것이 아니라 포함 관계에 있습니다. **Attention (Self-Attention)은 "단어들 사이의 관련성을 계산하는 부품"**이며, **Transformer는 "그 부품을 중심으로 피드포워드 층 (Feed-forward layer)이나 위치 인코딩 (Position Encoding) 등을 조합하여 만든 아키텍처 전체"**입니다. Attention은 Transformer의 일부 (Attention ⊂ Transformer)로, 심장 (Attention)과 그것을 탑재한 차체 전체 (Transformer)와 같은 관계가 됩니다. 본 기사에서는 두 가지를 토대로 세트로 다루기 때문에 다음 장에서도 함께 해설합니다.

여기서 기억해 두어야 할 점은, 이것들이 따로 떨어진 발명품이 아니라는 점입니다. "어떤 고안이 새로운 문제를 낳고, 그 문제를 다음 고안이 맡아서 해결한다"라는 연쇄로 이어져 있습니다. 예를 들어 Transformer가 만들어낸 계산의 무게를 KV Cache가, KV Cache가 만들어낸 메모리 소비를 압축 기술이 맡는 식입니다. 이러한 흐름을 의식하며 읽으면 각 장이 하나의 선으로 연결되어 보일 것입니다.

MoE도 KV Cache도 Speculative Decoding도 모두 Transformer라는 토대 위에 올라가 있습니다. 그러므로 우선, 그 Transformer 자체가 "어떤 문제를 해결하기 위해 태어났는가"부터 시작하겠습니다. 여기가 가장 근본적인 뿌리입니다.

2017년에 Transformer를 제안한 논문의 제목은 "Attention Is All You Need (필요한 것은 Attention뿐)"였습니다. 이 "뿐"이라는 표현에는 "그때까지 주역이었던 무언가를 제외했다"라는 함의가 담겨 있습니다. 제외된 것이 당시의 주류였던 RNN (Recurrent Neural Network)이나 LSTM입니다.

RNN / LSTM은 문장을 "왼쪽에서 오른쪽으로, 한 단어씩 순서대로 읽어 나가는" 모델이었습니다. 이는 직관적으로 이해하기 쉽다는 장점이 있는 반면, 크게 두 가지 고민이 있었습니다.

고민 1: 순차 처리 방식이라 병렬화가 불가능함

RNN은 "세 번째 단어를 처리하려면 먼저 첫 번째와 두 번째 단어의 처리가 끝나 있어야 한다"라는 구조로 되어 있습니다. 이전 단어의 처리 결과를 받지 않으면 다음으로 진행할 수 없기 때문에, 원리적으로 "대기 시간"이 발생합니다.

GPU는 본래 대량의 계산을 동시에 병렬로 수행하는 데 특화된 하드웨어입니다. 하지만 RNN은 대기 시간의 연속이기 때문에, GPU가 가진 병렬 계산 능력을 제대로 활용할 수 없습니다. 학습 데이터가 커질수록 이 "병렬화할 수 없음"이 학습 속도의 발목을 잡게 되었습니다.

고민 2: 긴 문장에서는 앞부분을 잊어버림

RNN / LSTM은 문맥을 "하나의 기억 벡터"에 꽉 눌러 담으며 읽어 나갑니다. 마치 바구니 릴레이(Bucket Brigade)로 정보를 뒤로 전달하는 것과 같은 이미지입니다.

이 방식으로는 문장이 길어질수록 훨씬 이전에 나왔던 중요한 단어의 정보가 릴레이 도중에 희석되어 사라지게 됩니다. "이 대명사는 20문장 전에 나왔던 저 인물을 가리킨다"와 같은 장거리 관계 (Long-range Dependency)를 제대로 유지하기 어려웠습니다. LSTM은 "잊지 않게 만드는 고안 (Gate Mechanism)"을 넣어 이를 완화하려 했으나, 근본적으로 해결되었다고 단정하기는 어려운 상태였습니다.

Transformer가 한 일은 "순서대로 읽는 것"을 그만두고, "문장 속의 모든 단어를 한꺼번에 나열하여 서로의 관계를 동시에 계산하는" 방향 전환이었습니다. 이를 통해 앞서 언급한 두 가지 고민을 동시에 해결했습니다.

병렬화 가능: 모든 단어를 동시에 보기 때문에 대기 시간이 사라집니다. GPU의 병렬 계산 능력을 풀(Full)로 사용할 수 있게 되어, 대규모 학습이 현실적으로 가능해졌습니다.

장거리 의존성에 강함: 20단어 앞이든 200단어 앞이든 "직접 서로를 참조하는" 경로가 마련되어 있으므로, 릴레이 도중에 정보가 희석될 걱정이 줄어듭니다.

위 그림의 하단부처럼 모든 단어가 서로 선으로 연결되어 있는 것이 Transformer의 이미지입니다. 이 "모두가 서로를 참조하는" 메커니즘이야말로 Self-Attention입니다.

그렇다면 그 "모두가 서로를 참조하는" 처리는 구체적으로 무엇을 하고 있는 것일까요? 여기서 등장하는 것이 **Q (Query) / K (Key) / V (Value)**라는 세 역할입니다.

kenmatsu4 님의 Self-Attention QKV를 직관적으로 해설한 기사에서는 이 세 역할을 "찾는 쪽 / 반응하는 쪽 / 전달되는 정보 본체"로 정리하고 있는데, 저는 이 분류가 가장 와닿았습니다.

친숙한 비유를 들자면 다음과 같은 이미지입니다.

Q (찾는 쪽): 회의에서 "다음 주 일정 어떻게 됐지?"라고 질문하는 질문자
K (반응하는 쪽): 참가자 각자가 가진 "나는 이런 화제에 반응합니다"라는 라벨
V (전달되는 정보 본체): 그 라벨을 가진 사람이 실제로 말하는 내용

질문(Q)과 각자의 라벨(K)의 궁합을 보고, 궁합이 좋은 사람일수록 큰 목소리로 (가중치를 크게 하여) 정보(V)를 전달합니다. 이것을 모두 모아 섞은 것이 해당 단어의 "문맥을 반영한 새로운 의미"가 됩니다. RNN의 바구니 릴레이와 달리, 누구나 누구와도 직접 주고받을 수 있다는 점이 핵심입니다.

여기서 중요한 점은 Transformer가 단순히 "더 좋아진" 것이 아니라, 어떤 대가를 치르고 있다는 사실입니다.

"모든 단어가 모든 단어를 참조한다"는 것은, 단어가 N개 있다면 N × N 가지의 조합을 계산한다는 의미입니다. 문장이 2배 길어지면 계산량은 약 4배로 불어납니다. 이것이 "Attention은 시퀀스 길이(Sequence Length)의 제곱에 비례한다"라고 불리는 성질이며, 이후의 KV Cache나 각종 Attention 가속화 기술들이 해결하고자 하는 문제의 출발점이기도 합니다.

즉, Transformer는 "순차 처리(Sequential Processing)로 인한 병렬화의 어려움과 장거리 의존성(Long-range Dependency)의 망각"이라는 고민을, "시퀀스 길이의 제곱에 비례하는 계산량"이라는 새로운 고민과 맞바꾸며 해결했다고 정리할 수 있습니다. 여기서부터 이어지는 MoE / KV Cache / Speculative Decoding은 모두 "이 토대가 안고 있는 다음 고민을 어떻게 효율화할 것인가"에 대한 고안들입니다.

경험적으로 모델의 파라미터(내부 숫자)를 늘릴수록 더 똑똑해지는 경향이 있습니다. 그렇다면 "어쨌든 파라미터를 늘리면 된다"고 생각할 수 있겠지만, 여기에 커다란 딜레마가 가로막고 있습니다.

밀집 모델(Dense Model, 일반적인 Transformer)에서는 1개의 토큰을 처리할 때마다 모델 내의 모든 파라미터를 사용하여 계산합니다. 따라서 파라미터를 10배로 늘리면 똑똑함은 올라갈지 모르지만, 추론 1회당 계산 비용도 거의 10배가 됩니다. 이렇게 되면 "똑똑하게 만들고 싶다"는 욕구와 "비용을 억제하고 싶다"는 욕구가 정면으로 충돌하게 됩니다.

MoE는 이 딜레마에 대해 "모델의 용량(총 파라미터 수)과 1회당 계산 비용을 분리할 수 없을까?"라는 질문을 던졌습니다. 구체적으로는 "파라미터는 많이 보유하되, 1개의 토큰을 처리할 때는 그중 일부만 활성화한다"는 발상입니다. 이는 "조건부 계산 (Conditional Computation)"이라고 불립니다. 필요한 것만 스위치를 켠다는 개념입니다.

여기서는 병원의 움직임에 비유해 보겠습니다.

• 환자(토큰)가 내원하면, 먼저 **종합 접수처(게이트 / 라우터, Gate / Router)**가 증상을 확인합니다.
• 접수처는 "내과", "정형외과", "피부과" 등 여러 전문 외래(전문가, Expert) 중 가장 적합한 몇 개의 과로만 환자를 보냅니다.
• 나머지 진료과는 해당 환자에 대해 아무것도 하지 않습니다 (급여는 발생하더라도, 그날 그 환자에게는 가동되지 않습니다).

여기서 작용하고 있는 것이 바로 "용량과 비용의 분리"입니다. 병원은 많은 전문 외래(=큰 용량)를 보유하고 있지만, 한 명의 환자가 받는 진료는 1~2개 과(=작은 계산 비용)뿐입니다. "전문가를 많이 고용해 두되, 한 명의 환자에게 전원이 달려들지는 않는다"는 운영 방식이 MoE가 하고 있는 일과 유사하다고 저는 이해하고 있습니다.

요소	역할	비유
라우터 (게이트)	어느 전문가에게 넘길지 결정하는 작은 네트워크	종합 접수처
...	...	...

대표적인 모델로는 Mistral의 Mixtral 8x7B가 이해하기 쉬운 예입니다. 이름만 보고 "8 × 7B = 56B"라고 단순 계산하기 쉽지만, Attention 층 등은 전문가들 사이에서 공유되기 때문에 총 파라미터는 실제로는 약 47B입니다 (공식 논문 arXiv:2401.04088). 반면 추론 시 실제로 움직이는 활성 파라미터(Active Parameters)는 Top-2 활성화 시 약 13B 상당에 머뭅니다. "47B 규모의 용량을 가지면서, 계산은 13B급으로 끝낸다"는 이 수치가 바로 용량과 비용을 분리한 결과 그 자체입니다.

MoE는 계산량을 억제하지만, 그 대신 다른 비용을 치르고 있습니다. 트레이드오프(Trade-off)를 정리해 두겠습니다.

관점	내용
얻은 것	큰 용량(지능의 상한선)을 가지면서도 추론당 계산량을 억제할 수 있음
...	...

"계산량은 줄었지만, 메모리는 줄어들지 않는다"는 점이 MoE의 최대 트레이드오프입니다. 병원 비유로 말하자면 "진료는 빠르게 돌아가지만, 전문 외래 건물(VRAM)은 전부 지어 놓아야 한다"는 뜻이 됩니다. 따라서 "MoE가 항상 이득이다"라고 단정 지을 수는 없다는 점을 유념해 둘 필요가 있습니다.

또한, MoE는 이 글을 쓰고 있는 2026년 시점에서도 대규모 모델의 주류로 계속 자리 잡고 있습니다. 한 예로, 2026년 6월 Moonshot AI가 공개한 대규모 MoE인 「Kimi K2.7-Code」는 총 파라미터가 약 1T 규모임에도 불구하고, 1 토큰당 작동하는 활성 파라미터(Active Parameters)는 약 32B에 머무는 구성으로 오픈 웨이트 (Open Weights)로 배포되었습니다. 용량과 비용을 분리한다는 MoE의 발상이 최전선의 대규모 모델에서도 그대로 유효함을 알 수 있습니다.

LLM은 「자기회귀 (Autoregressive)」라고 불리는 방식으로 문장을 생성합니다. 이는 "이미 작성한 문장을 보고 다음 1 토큰을 결정하고, 그것을 끝에 붙인 뒤, 다시 다음 1 토큰을 결정하는" 방식의 1 토큰씩 순차적으로 생성하는 과정입니다.

여기에 단순한 구현상의 낭비가 숨어 있습니다. 앞서 언급한 Self-Attention은 "모든 단어가 지금까지의 모든 단어를 참조하는" 처리였습니다. 그렇다면 아무런 조치를 취하지 않을 경우——

• 1 토큰째를 낼 때: 1 토큰 분량의 K·V를 계산
• 2 토큰째를 낼 때: 1~2 토큰째의 K·V를 다시 전부 계산
• 3 토큰째를 낼 때: 1~3 토큰째의 K·V를 또 전부 계산

하는 식으로, 매번 지금까지의 모든 토큰에 대한 K·V를 다시 계산하게 됩니다. 앞서 언급한 "시퀀스 길이의 제곱에 비례하는 계산량"이 생성할 때마다 무겁게 짓누르게 되는 것입니다.

하지만 잘 생각해보면, 과거 토큰의 K와 V는 나중에 새로운 토큰이 추가되어도 변하지 않습니다. 1 토큰째의 "라벨 (K)"과 "말하는 내용 (V)"은 문장이 길어져도 동일합니다. 그렇다면 "한 번 계산한 K·V를 저장해 두었다가, 다음부터는 재사용하면 되지 않을까"라는 것이 KV Cache의 발상입니다. 새로 늘어난 1 토큰 분량만 계산하고, 과거 분량은 캐시 (Cache)에서 가져오는 것입니다. 이를 통해 "매번 전부 다시 계산하는" 번거로움을 없앨 수 있습니다.

회의에 중간부터 참여한 사람을 상상해 봅시다.

• 회의록이 없는 상태라면, 발언할 때마다 "지금까지의 논의를 처음부터 전부 복습"하지 않으면 문맥을 따라갈 수 없습니다.
• 반면, 회의록 (K와 V의 캐시)이 정리되어 있다면, 과거의 발언은 다시 읽지 않고 새로운 발언에만 집중할 수 있습니다.
• 회의록이 길어질수록 보관 선반 (메모리)은 채워지겠지만, 매번 처음부터 다시 읽는 것보다는 훨씬 효율적입니다.

KV Cache가 하고 있는 일은 바로 이 "회의록 정리"와 매우 유사하다고 저는 생각합니다.

KV Cache는 "계산의 번거로움"을 없앴지만, 그 대신 "회의록을 보관하는 선반 = 메모리"를 소비합니다. 이것이 새로운 트레이드오프 (Trade-off)입니다.

Hugging Face 블로그의 계산 예시에 따르면, Llama-2 7B로 시퀀스 길이 1만 토큰 정도를 다룰 경우 KV Cache만으로 약 5GB를 소비합니다. 이는 모델 가중치 (Weight, 반정밀도)의 약 1/3에 해당합니다. 즉, 긴 문장을 다룰수록 모델 본체보다 "회의록"이 메모리를 더 압박하는 역전 현상이 일어날 수 있습니다.

관점	내용
얻은 것	과거 토큰의 재계산을 중단하여, 생성 1 토큰당 계산량을 급격히 줄일 수 있음
희생한 것	캐시를 유지하기 위한 메모리. 컨텍스트 (Context)가 길어질수록 선형적으로 증가함

"긴 컨텍스트 = 단순히 토큰 과금이 늘어남"뿐만 아니라, 추론 서버 측의 메모리 예산을 어떻게 설계할 것인가라는 문제와 직결되는 이유는 바로 이 KV Cache의 성질이 배경에 있기 때문입니다.

KV Cache가 "메모리를 잡아먹는다"는 새로운 고민거리를 낳았기에, 이를 완화하기 위한 고안들이 차례로 등장했습니다. 이들은 "KV Cache라는 회의록을 어떻게 하면 컴팩트하게 유지할 것인가"라는 공통된 테마로 묶을 수 있습니다.

용어	대략적인 의미	해결하려는 고민거리를
MQA / GQA	Key와 Value의 헤드 (Head)를 묶어 캐시량을 줄이는 아키텍처적 고안	회의록의 중복된 복제를 줄임
...

LLM의 생성이 "1 토큰씩" 이루어지는 순차 처리라는 점은 KV Cache 부분에서 언급했습니다. 여기서 한 단계 더 깊이 들어간 고민거리가 있습니다.

1 토큰을 생성하려면 거대한 모델의 가중치(Weights, 수십 GB 분량의 숫자)를 메모리에서 연산 장치로 읽어와야 합니다. 그런데 그 가중치를 사용하여 실제로 수행하는 계산은 '단 1 토큰 분량'뿐입니다. 비유하자면, 두꺼운 사전을 책장에서 꺼내어 단 한 단어만 찾아보고 다시 책장에 되돌려 놓는 과정을 끊임없이 반복하고 있는 상태와 같습니다.

이때 GPU의 연산 능력(계산하는 힘)은 남아돌고 있지만, 메모리 대역폭(가중치를 운반해 오는 속도)이 먼저 한계에 도달합니다. 이를 '메모리 대역폭 제한 (Memory-bandwidth bound)'이라고 합니다. 계산 능력은 한가한데 데이터 운반을 기다리느라 느려지는 상태—이것이 투기적 디코딩 (Speculative Decoding)이 해결하고자 하는 문제입니다.

여기서 나온 발상이, "어차피 가중치를 운반할 거라면 1 토큰이라고 하지 말고, 하는 김에 여러 토큰을 한꺼번에 검증해서 운반 비용을 재사용하면 되지 않을까?"라는 것입니다. Transformer는 '여러 토큰을 한꺼번에 1회에 처리하는 것'에 특화되어 있으므로(병렬 처리가 본래의 강점), 이 성질을 생성 단계에서도 최대한 활용하자는 것입니다.

한 작가를 상상해 봅시다.

• 어시스턴트 (작은 드래프트 모델, Draft Model)가 이어질 문장을 5 토큰 정도 한꺼번에 초안을 작성합니다. 크기가 작아서 빠르고 운반 비용도 가볍습니다.
• 작가 본인 (큰 본 모델, Base Model)은 그 초안을 단 한 번의 통독으로 한꺼번에 체크합니다. 무거운 사전을 한 번 찾아보는 김에 5단어를 모아서 정답을 맞히는 이미지입니다.
• 초반의 몇 토큰이 "자신이 쓴 것과 일치한다"면 그대로 채택합니다.
• 도중에 다른 표현이 나온다면, 그 이후는 폐기하고 본인이 다시 작성합니다.

핵심은 본 모델이 "1회의 포워드 패스 (Forward Pass, 즉 1회의 가중치 운반)로 여러 토큰을 한꺼번에 검증할 수 있다"는 점을 활용하는 데 있습니다. 초안이 맞으면 1회의 운반으로 여러 토큰만큼 전진할 수 있으므로 메모리 대역폭의 낭비가 줄어듭니다.

그리고 중요한 점은, 생성 결과 자체가 본 모델 단독으로 생성했을 때와 분포적으로 일치하도록 설계되어 있다는 점입니다. 어시스턴트의 초안은 "맞으면 채택, 틀리면 본인이 수정"하는 방식일 뿐이므로, 최종적인 문장의 품질은 어시스턴트의 지능에 좌우되지 않습니다. 속도만 가져오고 품질은 본 모델 그대로 유지하는 것이 목표입니다.

Hugging Face의 Assisted Generation 해설에서는 조건에 따라 다음과 같은 속도 향상이 나타난다고 설명합니다.

조건	속도 향상 기준
FP16으로 모델이 GPU에 들어가는 경우	최대 2배 정도
...

메모리 오프로딩 (Memory Offloading)이 필요할 정도로 큰 모델에서 효과가 큰 이유는, 그만큼 '가중치 운반 비용'이 지배적이기 때문이라고 정리할 수 있습니다. 다만, 이는 어디까지나 '기준'일 뿐입니다. 태스크나 온도(Temperature) 설정, 드래프트 모델의 선택에 따라 결과가 상당히 달라지므로, 자신의 유스케이스에서 직접 벤치마크를 수행한 후 판단하는 것이 안전합니다.

관점	내용
얻은 것	메모리 대역폭 제한 상황에서 품질을 유지하며 레이턴시 (Latency)를 단축할 수 있음
희생한 것	드래프트 모델을 별도로 준비하고 운용하는 수고와 그만큼의 VRAM. 초안이 계속 틀리면 검증 작업이 헛수고가 되어 오히려 느려질 수도 있음

초안이 '맞추기 쉬운' 상황일수록 효과가 큽니다. 반대로 본 모델의 출력을 예측하기 어려운 상황에서는 틀린 초안을 폐기하는 일이 늘어나 효과가 떨어지게 됩니다.

효과가 큰 경우	효과가 적은 경우
번역, 요약, 코드 완성 등 입력 의존도가 높은 태스크	높은 온도 샘플링으로 창의성을 요구하는 태스크
...

여담이지만, SARATHI와 같이 '프리필(Prefill)과 디코딩(Decoding)을 섞어서 배치(Batching)하는' 기법도 근본적인 동기는 같습니다. "GPU를 놀리지 않기 위해, 한꺼번에 할 수 있는 일을 늘린다"는 발상이라고 저는 이해하고 있습니다. 투기적 디코딩과 SARATHI는 수단은 다르지만, "메모리 대역폭 제한으로 하드웨어가 한가하게 노는 문제"라는 동일한 고민에 대해 서로 다른 각도에서 답하고 있다고 이해하면 흐름을 파악하기 좋습니다.

지금까지 소개한 4가지에 비해, RoPE (Rotary Position Embedding)나 SwiGLU는 모델 내부의 좀 더 세부적인 주제입니다. 본 기사에서는 개요만 다루겠습니다.

• RoPE: 토큰의 위치 정보를 벡터의 "회전"으로서 임베딩하는 방식입니다. Transformer는 모든 단어를 동시에 보는 대신 "순서 정보"를 그대로 가지고 있지 않기 때문에, 위치 정보를 별도로 제공해야 합니다. RoPE는 그 방식의 독창적인 설계로, 긴 문장 대응이나 위치 보간 (Position Interpolation) 논의에서 자주 등장합니다.
• SwiGLU: FFN (Feed-Forward Network)의 활성화 함수(Activation Function)의 일종입니다. 학습의 안정성과 표현력의 균형을 맞추기 쉽다고 평가받고 있습니다.

이러한 요소들은 논문에서 "모델 아키텍처의 차별화 요소"로 자주 언급되며, 사용자 입장에서는 "최근 모델들은 대체로 이 정도를 채택하고 있다"라고 파악해 두는 것만으로도 우선은 충분하다고 느껴집니다.

최근의 모델 경쟁은 다룰 수 있는 컨텍스트 길이 (Context Length, 한 번에 읽을 수 있는 문장량)가 하나의 축이 되고 있습니다. 수만~수십만 토큰을 다룬다는 이야기도 드물지 않게 들려옵니다.

여기서 앞서 언급한 KV Cache의 트레이드오프 (Trade-off)가 작용합니다. KV Cache의 메모리 소비는 컨텍스트가 길어질수록 선형적으로 증가합니다. 즉, "긴 컨텍스트를 강점으로 내세울수록" "회의록 보관 선반 (메모리)이 터져나가는" 문제가 심각해집니다. 긴 컨텍스트 시대의 발목을 잡는 것은 종종 계산량보다 메모리 쪽에 있습니다. 그렇기에 "회의록을 어떻게 작게 접을 것인가"라는 KV Cache 압축이 경쟁의 중심 테마 중 하나로 부상하게 된 흐름입니다.

2026년에 화제가 되고 있는 것은 Google Research가 ICLR 2026에서 발표한 TurboQuant입니다 (논문은 arXiv:2504.19874). InfoQ나 연구 블로그 등의 소개 기사를 읽어본 바로는, 요점은 다음과 같습니다.

• KV Cache를 3~3.5 bit 정도까지 양자화(Quantization)하면서도, 벤치마크상으로는 원래의 정밀도를 거의 유지합니다. 참고로 출처에 따라 임계값 표기에 차이가 있는데, Google Research의 블로그는 "3 bit", InfoQ는 "3.5 bit"라고 표현하고 있습니다. 완전히 정밀도를 유지할 수 있는 수준은 대체로 3.5 bit로 파악하는 것이 안전합니다.
• 학습이나 파인튜닝 (Fine-tuning)이 필요 없이 적용할 수 있는, 데이터에 의존하지 않는 방식입니다.
• PolarQuant (랜덤 회전을 사용한 좌표 변환)와 1 bit의 QJL 잔차 보정을 결합하여, 약 6배의 메모리 절감과 H100 상에서 최대 8배의 Attention 계산 가속화를 보고했습니다.
• 예시로, 어떤 3B급 모델 (Qwen2.5-3B 클래스)에서는 8K 토큰의 KV Cache가 289MB → 58MB 정도로 줄어들어, 12GB급 GPU에서 40K 토큰 규모의 컨텍스트가 현실적이 된다는 추정치가 소개되었습니다 (모델 규모나 양자화 조건에 따라 값은 달라집니다).

"메모리를 크게 줄이면 동일한 GPU에서 더 긴 컨텍스트를 다룰 수 있다"라는 방향성은, 바로 앞서 말한 "긴 컨텍스트 시대의 발목을 잡는 것은 메모리"라는 맥락과 정확히 일치합니다.

이 영역은 아직 평가가 완전히 정해지지 않았습니다. 공개 직후부터 제3자 검증이 진행되었으며, 논문의 벤치마크 값을 그대로 실운용의 기대치로 삼을 수는 없다는 지적도 나왔습니다.

예를 들어 vLLM 팀의 제3자 벤치마크 (vLLM Blog: TurboQuant)에서는 다음과 같은 결과가 보고되었습니다.

• 어떤 변형(Variant)에서도 처리량(Throughput)이 BF16보다 낮으며, 구성이나 모델에 따라서는 2~3할 정도 느려지는 경우가 있다.
• 양자화를 강하게 적용한 변형에서는 난이도가 높은 벤치마크 (AIME25, LiveCodeBench-v6 등)에서 정밀도가 크게 떨어질 수 있다.
• "3.5 bit로 FP16과 동등하다"라는 결과도 비교적 쉬운 벤치마크에서의 이야기이며, 어려운 태스크에서는 반드시 성립하지 않는다.
• 종합적으로는 "KV Cache 양자화는 현재로서는 FP8이 현실적인 베스트"라는 평가다.

즉 "6배 절감·8배 가속"은 이상적인 조건에서의 수치이며, 실운용의 처리량이나 어려운 태스크의 정밀도까지 포함하면 이야기가 단순하지 않다는 뜻입니다. 공식 구현도 2026년 6월 시점에서는 미공개 상태이며, llama.cpp나 vLLM으로의 통합도 커뮤니티에서 PR (Pull Request)을 내고 있는 단계 (본체 머지 미달성)입니다. 극단적으로 메모리가 부족한 상황에서는 선택지가 될 수 있지만, 범용적인 권장 사항으로 받아들이기에는 이르다는 것이 현시점의 분위기라고 이해하고 있습니다.

다만, 방향성 측면에서는 「KV Cache를 어떻게 하면 더 작게, 어떻게 하면 더 빠르게 다룰 것인가」가 컨텍스트 길이 (Context Length) 경쟁과 밀접하게 연관되어 있다는 점은 지난 몇 년간 공통적으로 느껴지는 인상입니다.

4가지 메커니즘을 「해결한 문제 (Problem solved)」와 「치른 대가 (Trade-off)」의 쌍으로 정리해 두겠습니다. 발명의 동기와 트레이드오프 (Trade-off)를 세트로 기억해 두면, 새로운 모델이나 런타임 (Runtime) 설명을 접했을 때도 갈피를 잡기가 훨씬 쉬워질 것이라고 저는 느낍니다.

메커니즘	해결한 문제	치른 대가 (트레이드오프)
Attention / Transformer	RNN의 순차적 처리 (병렬화 불가) 및 장거리 의존성 (Long-range dependency) 망각	시퀀스 길이 (Sequence length)의 제곱에 비례하는 계산량이라는 새로운 부담
...

이렇게 나열해 보면, 어떤 고안이 해결한 문제가 다음 고안이 해결해야 할 새로운 문제를 낳고 있다는 연쇄를 볼 수 있습니다. Transformer가 계산량 문제를 낳고, KV Cache가 메모리 문제를 낳으며, 그 메모리 문제를 압축 기술이 이어받는—LLM의 내부는 이러한 「문제 해결의 바통 터치」가 쌓여 만들어진 것으로 바라보면 하나의 맥락이 관통되어 보이는 것 같습니다.

LLM의 내부는 논문 기반으로 깊게 파고들면 정말 끝이 없는 영역입니다. 반면, API 사용자나 앱 개발자의 입장에서는 여기서 소개한 수준의 「이유(Why)」와 「비유」를 알고 있는 것만으로도, 벤더의 발표 자료나 런타임 옵션 설명을 훨씬 수월하게 읽을 수 있을 것이라고 저는 느낍니다.

본 기사의 설명은 어디까지나 하나의 정리 방식일 뿐입니다. 논문 중심의 설명, 구현 중심의 설명, 도해 중심의 설명 등 유파는 다양하므로, 본인에게 잘 맞는 것을 2~3가지 종류 정도 비교하며 읽어보는 것이 결국에는 지름길일지도 모릅니다.