AI HISTORY · DEEP DIVE
LLM은 어느 날 갑자기 태어나지 않았다
언어를 확률표로 세던 시대에서 시작해, RNN은 기억을 만들었고, LSTM은 기억에 문을 달았고, Attention은 “필요할 때 다시 보자”고 했고, Transformer는 아예 순환 구조를 버렸다. 그 위에 pre-training, scaling, RLHF, RAG, MoE, reasoning, agent가 한 층씩 올라갔다. 이 글은 모델 이름을 외우는 연표가 아니라 “왜 다음 기술이 필요했는가”를 따라가는 이야기다.
rubrub · 2026. 09. 04 · Visual Long Read · 그림으로 읽는 약 35~45분
LLM의 역사는 결국 “언어를 어떻게 기억할 것인가 → 어떻게 병렬로 학습할 것인가 → 어떻게 하나의 모델에 지식을 압축할 것인가 → 어떻게 사람이 원하는 방식으로 행동하게 할 것인가 → 어떻게 외부 세계와 연결할 것인가”라는 다섯 질문의 역사다.
이 글의 그림은 논문 구조를 그대로 복사하기보다 처음 보는 사람이 핵심만 잡도록 단순화했다. 복잡한 수식이 나와도 먼저 그림의 한 줄 설명을 보고, 그다음 본문을 읽으면 된다.
전체 지도를 먼저 보자
CHAPTER 01 · BEFORE NEURAL NETWORKS
0. LLM 이전에도 ‘다음 단어 예측’은 있었다
우리는 ChatGPT 시대에 살다 보니 “다음 토큰 예측”을 최신 기술처럼 느끼지만, 사실 언어를 확률적으로 바라보는 생각은 훨씬 오래됐다. 1951년 Claude Shannon은 사람들이 앞의 문자를 보고 다음 문자를 얼마나 잘 예측하는지 이용해 영어의 entropy를 추정했다. 현대 LLM과 architecture는 전혀 다르지만 질문 자체는 묘하게 익숙하다.
누군가 종이에 “THE INSUR...”라고 적었다. 다음 글자는 무엇일까? 영어를 아는 사람이라면 자연스럽게 A나 E 같은 후보보다 A 뒤에 “NCE”가 이어지는 “INSURANCE”를 떠올릴 수 있다. 왜일까? 우리는 수많은 문장을 보며 어떤 문자와 단어가 어떤 문맥 뒤에 자주 오는지 이미 체화했기 때문이다.
언어모델의 가장 근본적인 정의는 이 직관에서 크게 벗어나지 않는다.
문장 w₁, w₂, ..., wₜ₋₁이 주어졌을 때 다음 단어 wₜ의 확률을 구한다.
이 수식이 지금 GPT류 모델의 next-token prediction과 연결된다. 다만 과거에는 이를 거대한 신경망으로 근사할 계산 자원도, 데이터도, 학습 방법도 없었다. 그래서 연구자들은 문맥을 잘라냈다.
CHAPTER 02 · STATISTICAL LANGUAGE MODELS
1. n-gram: 언어를 거대한 빈도표로 만들다
문장 전체를 조건으로 확률을 계산하려면 경우의 수가 너무 많다. 그래서 “아주 먼 과거는 일단 잊고, 바로 앞의 몇 단어만 보자”는 가정을 한다. 이것이 n-gram이다.
사용자가 “보험 계약을 중도에”라고 입력했다고 하자. trigram 모델은 거대한 말뭉치에서 “계약을 중도에” 다음에 어떤 단어가 자주 나왔는지 찾는다. “해지”, “변경”, “종료”가 각각 몇 번 나왔는지 세고 확률을 만든다. 놀랍도록 단순하지만, 충분한 데이터가 있다면 꽤 쓸 만하다.
문제는 보지 못한 문장이다. 어휘가 10만 개이고 10개의 연속 단어 조합을 생각하면 가능한 조합 수는 사실상 천문학적이다. 2003년 Bengio의 Neural Probabilistic Language Model 논문도 바로 이 curse of dimensionality를 전면에 내세웠다. 실제 데이터에서 본 조합은 가능한 언어 조합의 극히 일부뿐이다.
왜 “비슷한 단어”를 알아야 했을까?
예를 들어 학습 데이터에 “고객이 보험을 해지했다”는 문장은 많이 있지만 “가입자가 보험을 해지했다”는 문장은 거의 없다고 하자. 사람에게는 고객과 가입자가 관련된 단어라는 사실이 명백하다. 그런데 n-gram의 입장에서 두 단어는 서로 완전히 다른 ID다.
단어를 단순한 기호로 취급하면 “비슷한 문장은 비슷한 의미를 가진다”는 구조를 활용하기 어렵다. 언어를 연속적인 공간으로 옮겨야 했다.
CHAPTER 03 · WORDS BECOME VECTORS
2. Neural Language Model: 단어가 좌표를 갖기 시작하다
2003년 Bengio 등은 단어의 distributed representation과 언어모델의 확률 함수를 함께 학습하는 neural language model을 제시했다. 쉽게 말하면 단어를 번호표가 아니라 좌표로 만들기 시작한 것이다.
고객 = 1842가입자 = 9281
두 숫자는 서로 얼마나 비슷한지 말해주지 않는다.
고객 = [0.12, -0.42, ...]가입자 = [0.10, -0.39, ...]
비슷한 문맥에서 사용되면 비슷한 방향의 벡터를 학습할 수 있다.
이후 Word2Vec이 2013년 매우 효율적인 방식으로 대규모 데이터에서 word vector를 학습하면서 “단어의 의미가 벡터 공간의 기하학으로 어느 정도 드러난다”는 아이디어가 대중화됐다.
그런데 Word2Vec에도 치명적인 문제가 있었다
하나의 단어는 하나의 벡터였다. “bank”가 금융기관을 뜻하든 강둑을 뜻하든 동일한 벡터를 쓴다. 한국어의 “사고”도 “보험 사고”와 “생각”의 의미가 완전히 다른데 같은 token representation을 공유하게 된다.
그래서 다음 시대의 문제는 이렇게 바뀐다.
CHAPTER 04 · MEMORY ARRIVES
3. RNN: 기계에게 ‘기억’을 주다
일반적인 feed-forward neural network는 입력을 넣고 출력이 나오면 끝이다. 이전 입력이 무엇이었는지 자체적으로 기억하지 않는다. 하지만 언어는 순서가 중요하다.
“고객이 설계사를 믿는다.”
“설계사가 고객을 믿는다.”
등장하는 단어 집합은 거의 같지만 의미는 다르다. 언어에서 순서를 버릴 수 없는 이유다.
RNN(Recurrent Neural Network)은 hidden state라는 내부 메모리를 다음 시점으로 전달한다. 1990년 Elman의 연구는 recurrent link를 이용해 network에 일종의 dynamic memory를 부여하는 방향을 보여줬다.
RNN의 아름다운 점
동일한 network cell을 모든 timestep에 재사용한다. 문장의 길이가 5단어든 50단어든 같은 파라미터를 반복 적용할 수 있다. 그리고 hidden state가 과거 문맥의 요약 역할을 한다. 당시로서는 매우 자연스럽고 강력한 sequence modeling 방식이었다.
그런데 RNN은 너무 쉽게 잊었다
문장이 길어지면 먼 과거의 정보가 현재까지 전달돼야 한다. 학습할 때는 Backpropagation Through Time(BPTT)을 통해 시간축을 거꾸로 gradient가 흐른다. 그런데 작은 값들이 반복 곱해지면 gradient가 점점 0에 가까워지고, 큰 값들이 반복 곱해지면 반대로 폭발한다.
중요한 것은 수식 그 자체보다 “오래전 사건에 책임을 돌리기 어렵다”는 직관이다. 마지막 단어에서 오류가 발생했는데 그 원인이 50 timestep 전 정보라면, 그 책임 신호가 50개의 recurrent transition을 통과해 되돌아가야 한다.
h₂를 계산하려면 h₁이 필요하고, h₃에는 h₂가 필요하다. sequence 방향으로 의존성이 직렬로 이어지기 때문에 GPU가 있어도 token dimension을 마음껏 병렬화하기 어렵다.
CHAPTER 05 · LONG-TERM MEMORY
4. LSTM: 기억에 ‘문’을 달다
1997년 Hochreiter와 Schmidhuber의 LSTM은 recurrent backpropagation에서 오랜 시간 간격의 정보를 학습하기 어려운 문제를 정면으로 겨냥했다. 핵심 철학은 단순하다. “기억을 매번 통째로 덮어쓰지 말고, 무엇을 버리고 무엇을 저장할지 제어하자.”
RNN은 매 순간 책상 위 메모를 새로 덮어쓰는 사람과 비슷하다. 반면 LSTM은 별도의 장기 보관 서랍(cell state)을 두고, 새 정보가 들어올 때마다 세 개의 질문을 한다.
기존 기억 중 무엇을 지울까?
새 정보 중 무엇을 저장할까?
오래 유지할 장기 기억의 통로.
지금 이 순간 어떤 기억을 밖으로 보여줄까?
예를 들어 “피보험자는 2024년 3월 계약을 체결했고 … 수십 단어 뒤 … 해당 계약의 해지환급금은?” 같은 문장을 처리한다고 하자. 날짜 정보는 처음에는 중요해 보이지 않을 수 있지만 뒤에서 필요해진다. LSTM은 cell state를 통해 이런 정보를 더 안정적으로 유지할 수 있었다.
이 덕분에 LSTM은 기계번역, 음성인식, 시계열, 언어모델 등에서 오랫동안 주류가 됐다. GRU는 유사한 gating 철학을 좀 더 간결한 구조로 구현했다.
CHAPTER 06 · SEQUENCE TO SEQUENCE
5. Seq2Seq: 문장을 읽고, 문장을 쓰는 하나의 네트워크
2014년 Seq2Seq는 NLP의 방향을 크게 바꿨다. 예전 기계번역은 단어 정렬, phrase table, 언어 규칙, 통계 모델 등 여러 구성요소가 복잡하게 얽혀 있었다. Seq2Seq는 훨씬 대담했다.
Encoder LSTM이 입력을 끝까지 읽어 fixed-dimensional vector로 압축하고, Decoder LSTM이 그 벡터를 초기 상태로 받아 출력 문장을 한 단어씩 생성한다. Sutskever 등의 2014년 논문은 이 단순한 end-to-end 구조로 당시 강력한 번역 성능을 보여줬다.
압축병목이 나타났다
문장이 길어질수록 마지막 vector 하나가 감당해야 하는 정보량이 많아진다. “보험 약관 50페이지를 읽은 뒤 768개의 숫자에 모든 세부사항을 완벽히 담아라”라고 하면 어려운 것과 비슷하다.
그리고 바로 이 문제를 본 연구자들이 생각한다.
번역할 단어를 만들 때 원문에서 필요한 곳을 다시 보면 되잖아.”
CHAPTER 07 · ATTENTION
6. Attention: 기계가 ‘어디를 볼지’ 선택하기 시작하다
Bahdanau, Cho, Bengio의 2014년 연구는 fixed-length vector가 encoder-decoder의 병목이라고 지적하고, 출력 단어를 예측할 때 입력 문장의 관련 부분을 soft-search하는 attention을 제안했다.
“The customer cancelled the policy yesterday.”를 번역한다고 하자. decoder가 “계약을”이라는 단어를 생성하려는 순간, 입력의 모든 hidden state를 똑같이 보지 않고 the policy 쪽에 높은 weight를 준다. 다음에 “어제”를 생성할 때는 yesterday를 더 강하게 본다.
여기서 중요한 철학적 변화가 있다.
이전: “중요한 정보를 모두 내부 state에 저장하자.”
Attention: “정보를 보존해두고, 필요한 순간 관련된 곳을 찾아 읽자.”
이 생각은 훗날 self-attention뿐 아니라 RAG, external memory, agent tool use와도 놀랄 만큼 닮아 있다. 내부에 전부 외우지 않고 필요할 때 접근한다.
CHAPTER 08 · THE TRANSFORMER MOMENT
7. 2017 Transformer: “RNN을 꼭 써야 해?”
2017년 Attention Is All You Need 논문은 한 단계 더 나갔다. Attention을 RNN에 보조로 붙이는 게 아니라, recurrence와 convolution을 아예 없애고 attention만으로 sequence를 처리했다.
당시 sequence model의 주류는 RNN/LSTM이었다. 문장은 본질적으로 순서가 있으니, 한 단어씩 읽어야 하는 것은 꽤 당연하게 느껴졌다. Transformer는 그 당연함을 의심했다.
Transformer의 진짜 혁명은 “Attention”만이 아니다
많이들 Transformer를 self-attention이라는 수식 하나로 기억하지만, 산업적으로 더 결정적인 변화는 병렬화 가능성이었다.
h₁ → h₂ → h₃ → h₄
앞 timestep이 끝나야 다음 timestep을 계산.
[x₁ x₂ x₃ x₄] → Q,K,V → MatMul
training 시 여러 token representation을 대규모 행렬연산으로 병렬 처리.
GPU와 TPU는 큰 matrix multiplication을 정말 잘한다. Transformer는 현대 accelerator가 잘하는 연산 형태와 궁합이 좋았다. 즉 architecture innovation과 hardware scaling이 서로 맞물렸다.
그런데 순서를 없앴으면 문장 순서는 어떻게 알까?
Self-attention만 놓고 보면 token의 순서를 본질적으로 알지 못한다. 그래서 원래 Transformer는 sinusoidal positional encoding을 embedding에 더해 “이 token은 몇 번째 위치에 있다”는 신호를 넣었다. 이후 모델들은 learned position embedding, RoPE 등 다양한 positional scheme을 사용하게 된다.
CHAPTER 09 · Q, K, V WITHOUT FEAR
8. Self-Attention의 Q/K/V를 정말 쉽게 이해해보자
Q, K, V라는 이름 때문에 처음 보면 암호처럼 느껴지지만, 사실 database 검색이나 도서관 검색에 비유하면 꽤 직관적이다.
“나는 지금 어떤 정보를 찾고 있지?”
“나는 어떤 종류의 정보를 가진 token이지?”
“나를 선택하면 실제로 전달할 정보는 이것이야.”
Query와 Key가 얼마나 잘 맞는지 계산한 유사도.
“철수는 계약서를 확인했다. 그는 서명했다.”
“그는”이라는 token이 문맥을 이해하려면 누구를 가리키는지 알아야 한다. Query는 “내가 가리키는 주체가 누구지?”와 비슷한 방향의 representation을 만들 수 있고, 앞 token들의 Key와 비교했을 때 “철수”가 높은 점수를 받을 수 있다. 그러면 “철수” 위치의 Value 정보가 “그는”의 새로운 representation에 강하게 섞인다.
왜 √dₖ로 나눌까?
차원이 커질수록 Q와 K의 dot product 크기가 커질 수 있다.
그러면 softmax가 지나치게 뾰족해져 gradient가 작아질 수 있다.
원 논문은 이를 완화하기 위해 √dₖ로 scaling한다.
Multi-Head Attention은 왜 여러 개의 머리가 필요할까?
한 종류의 관계만 보면 언어를 충분히 이해하기 어렵다. 어떤 head는 주어-동사 관계에 민감할 수 있고, 다른 head는 멀리 떨어진 참조 관계, 문장 구조, 위치 패턴 등을 학습할 수 있다. 원 Transformer base 모델은 8개의 head를 사용했다.
Transformer에도 비용이 있다
길이가 n인 sequence에서 모든 token pair의 attention score를 만들면
attention matrix가 n × n이 된다.
그래서 vanilla attention의 sequence-length 관점 계산/메모리 비용은 대략 O(n²)로 커진다.
Long-context 연구가 계속되는 이유다.
CHAPTER 10 · PRE-TRAIN ONCE, USE EVERYWHERE
9. 2018: BERT와 GPT — 같은 Transformer에서 정반대 철학이 나오다
Transformer가 나온 바로 다음 해, NLP의 패러다임은 또 바뀐다. 이전에는 task마다 모델을 따로 학습하는 경우가 많았다. 감성분석 모델, 질문응답 모델, 문장분류 모델을 각각 준비했다.
그러나 인터넷에는 정답 label이 붙은 데이터보다 그냥 텍스트가 압도적으로 많다. 그렇다면 대량의 unlabeled text로 먼저 언어를 배우고, 나중에 작은 labeled dataset으로 원하는 task에 적응하면 어떨까?
GPT: 왼쪽에서 오른쪽으로 다음 단어를 맞혀라
2018년 OpenAI의 generative pre-training 연구는 Transformer 기반 language model을 대규모 unlabeled text에서 먼저 학습하고 downstream task에 fine-tuning했다. 핵심은 이후 GPT 계열을 정의한 decoder-style causal language modeling이다.
한 token을 맞히고, 그 token을 다시 입력에 붙이고, 또 다음 token을 예측한다. 오늘날 생성형 LLM이 문장을 만드는 가장 기본적인 방식과 동일하다.
BERT: 양쪽 문맥을 동시에 보자
BERT는 encoder-only Transformer를 활용해 token 일부를 가리고 맞히는 Masked Language Modeling(MLM)을 사용했다. 예를 들어 “고객은 [MASK]을 해지했다”에서 가려진 단어를 맞힌다. 이때 왼쪽과 오른쪽 문맥을 모두 볼 수 있다.
| BERT 계열 | GPT 계열 | |
|---|---|---|
| 구조 | Encoder 중심 | Decoder-only 중심 |
| 문맥 | 양방향 representation | Causal: 이전 token만 봄 |
| 대표 강점 | 분류, embedding, NLU | 자유로운 text generation |
| 오늘날 | 검색 encoder, reranker 등에 여전히 중요 | 범용 chat / code / reasoning LLM의 주류 |
그리고 그 사이에 ELMo, ULMFiT도 있었다
역사를 GPT와 BERT만으로 설명하면 중요한 연결고리가 빠진다. ELMo는 2018년 bidirectional language model의 내부 상태를 이용해 문맥에 따라 달라지는 word representation을 보여줬고, ULMFiT는 pre-trained language model을 다양한 text classification task에 fine-tuning하는 transfer learning recipe를 강하게 보여줬다.
CHAPTER 11 · SCALE CHANGES THE INTERFACE
10. GPT-2에서 GPT-3로: 모델이 커지자 ‘사용법’이 바뀌었다
GPT-1의 세계에서는 pre-train한 모델을 downstream task마다 fine-tuning하는 것이 자연스러웠다. 그런데 모델이 커지면서 이상한 일이 생기기 시작했다. 가중치를 바꾸지 않고 prompt만 줘도 새로운 task를 수행하기 시작한 것이다.
GPT-3의 175B가 중요했던 이유
GPT-3는 175B parameter의 autoregressive language model로, task별 gradient update 없이 prompt 안에 instruction이나 몇 개의 예시를 넣는 zero-shot / one-shot / few-shot setting을 본격적으로 보여줬다.
긍정/부정 분류를 하고 싶다면:
“영화가 정말 좋았다 → 긍정
너무 지루했다 → 부정
배우의 연기가 훌륭했다 → ?”
예전에는 classifier를 별도로 학습했을 문제를, 이제는 context 안에서 즉석으로 정의할 수 있게 됐다.
이것이 in-context learning이다. 중요한 점은 model parameter가 바뀌는 것이 아니라 prompt의 token들이 모델 내부 activation에 “이번 task가 무엇인지”를 전달한다는 점이다.
LLM 시대의 인터페이스: Instruction + Examples → Context → Model
여기서 prompt engineering이 등장한다. Prompt는 그냥 질문 문장이 아니라, 모델이 이번 inference에서 수행할 임시 프로그램 같은 역할을 하기 시작했다.
CHAPTER 12 · THE SCIENCE OF GETTING BIGGER
11. Scaling Laws: “크게 만들면 좋아진다”가 공학 법칙이 되다
2020년 Scaling Laws 연구는 language model의 loss가 모델 크기, dataset 크기, training compute에 따라 상당히 규칙적인 power-law 형태로 개선되는 경향을 정리했다.
이전에도 큰 모델이 좋다는 감각은 있었다. 하지만 이 연구 흐름은 “compute를 몇 배 넣으면 성능이 어느 정도 개선될까?”를 예측 가능한 engineering question으로 바꾸기 시작했다.
parameter를 얼마나 늘릴 것인가.
얼마나 많은 token을 보여줄 것인가.
총 연산 budget을 어떻게 배분할 것인가.
그 결과 다음 token을 얼마나 잘 예측하게 되는가.
그다음 Chinchilla가 질문을 바꿨다
초기 scaling 분위기는 “모델을 크게!”로 받아들여지기 쉬웠다. 하지만 2022년 Chinchilla 연구는 fixed compute budget에서 모델 크기와 training token 수를 함께 적절히 키워야 compute-efficient하다고 보여줬다.
70B Chinchilla는 훨씬 큰 모델들과 경쟁력 있는 성능을 보였다. 핵심 메시지는 “parameter count만 보는 것은 부족하다”였다.
학습 token 수, 데이터 품질, optimizer, architecture, post-training, context length, inference-time compute가 모두 실제 성능에 영향을 준다.
CHAPTER 13 · FROM LANGUAGE MODEL TO ASSISTANT
12. Pre-training만으로는 ‘좋은 비서’가 되지 않았다
Base language model은 본질적으로 다음 token을 잘 예측한다. 그러나 사용자가 원하는 것은 인터넷 글을 자연스럽게 이어 쓰는 기계가 아니라, 질문을 이해하고, 명령을 따르고, 도움이 되는 형식으로 답하는 assistant다.
Web text의 다음 token을 맞히는 데 최적인 행동과 “사용자 질문에 정확하고 안전하게 답하라”는 행동은 같지 않다.
SFT: 먼저 정답 예시를 보여준다
사람이 만든 instruction-response 쌍으로 supervised fine-tuning을 한다. 예를 들어 질문이 들어오면 어떤 형식, 어떤 톤, 어떤 내용으로 답해야 하는지를 예시로 학습한다.
RLHF: 사람의 선호를 reward로 바꾼다
InstructGPT의 대표적인 pipeline은 다음과 같이 이해하면 쉽다.
사람이 좋은 답변 예시를 작성.
그 예시를 모방하도록 supervised learning.
같은 prompt에 여러 답변을 만들고 사람이 순위를 매김.
사람이 어떤 답을 선호할지 예측하도록 학습.
높은 reward를 받는 답을 만들도록 policy를 최적화.
지식뿐 아니라 행동 양식이 달라짐.
InstructGPT 논문에서 특히 인상적인 결과 중 하나는 1.3B 규모의 PPO-ptx 모델 출력이 human evaluation에서 175B GPT-3 baseline보다 선호된 경우가 많았다는 점이다.
이후 preference optimization은 RLHF뿐 아니라 DPO류 등 더 단순한 방식으로도 확장됐다. 중요한 것은 LLM 개발이 이제 pre-training + post-training의 두 단계 문제로 자리 잡았다는 사실이다.
CHAPTER 14 · EXTERNAL MEMORY
13. RAG: “모델이 모든 사실을 외워야 하나?”
2020년 Retrieval-Augmented Generation 연구는 모델 parameter에 저장된 parametric memory와 외부 문서 index의 non-parametric memory를 결합하는 방향을 제시했다.
방법 A. 규정이 바뀔 때마다 모델을 다시 학습한다.
방법 B. 질문할 때 최신 규정 문서를 찾아서 context에 넣는다.
현실적인 enterprise system에서는 B가 훨씬 매력적인 경우가 많다.
RAG의 핵심은 단순히 “vector DB를 붙이는 것”이 아니다. 모델이 가진 internal knowledge와 외부의 업데이트 가능한 knowledge source를 분리한다는 데 있다.
RAG가 해결하는 것과 못 해결하는 것
| RAG가 잘 해결하는 문제 | RAG만으로 해결되지 않는 문제 |
|---|---|
| 최신 문서 반영 | retrieval이 틀렸을 때 발생하는 오류 |
| 출처 추적 가능성 | 문서 안의 복잡한 multi-hop reasoning |
| 권한별 문서 필터링 | 잘못된 metadata / chunking |
| 모델 재학습 없이 지식 업데이트 | LLM 자체의 instruction following / reasoning 한계 |
그래서 production RAG는 embedding model 하나로 끝나지 않는다. chunking, metadata, hybrid search, reranking, query rewrite, authorization filter, citation, evaluation, cache까지 전체 pipeline을 설계해야 한다.
CHAPTER 15 · MAKE IT CHEAPER
14. LLM이 커지자 연구 주제는 ‘성능’에서 ‘효율’로 확장됐다
LoRA: 전부 다시 학습하지 말자
수십억 parameter 모델을 task마다 full fine-tuning하는 것은 비용이 크다. LoRA는 원래 weight를 고정하고 작은 low-rank matrix를 추가해 필요한 변화량만 학습하는 parameter-efficient fine-tuning 방법을 제시했다.
직관적으로는 거대한 모델 전체를 뜯어고치는 대신, “업무별 작은 adapter”를 끼운다고 보면 된다.
FlashAttention: 연산량보다 메모리 이동이 문제일 수 있다
GPU 성능을 이야기할 때 FLOPs만 보기 쉽지만, 실제 LLM에서는 HBM과 on-chip SRAM 사이에서 데이터를 이동하는 비용이 매우 중요하다. FlashAttention은 attention을 IO-aware하게 계산해 동일한 exact attention을 더 효율적으로 수행하도록 설계됐다.
Quantization: 숫자를 더 작게 저장하면?
모델 weight를 FP16/BF16보다 낮은 precision, 예를 들어 INT8이나 4-bit 계열로 표현하면 메모리 사용량과 bandwidth 부담을 줄일 수 있다. 물론 accuracy 손실과 hardware/kernel 지원을 함께 고려해야 한다.
KV Cache: 이미 읽은 문맥을 매 token마다 다시 계산하지 않기
Autoregressive generation에서 token을 하나 만들 때마다 과거 모든 token의 Key와 Value를 다시 계산하면 낭비가 크다. 그래서 이전 token들의 K/V를 cache해 다음 decode step에서 재사용한다. 이것이 KV cache다.
매 단어를 말할 때마다 책 100페이지를 처음부터 다시 읽는 것이 아니라, 이미 읽어 정리해둔 메모(KV cache)를 참고하는 셈이다.
대신 context가 길어지고 concurrent user가 많아질수록 KV cache 자체가 큰 GPU memory 소비자가 된다. 그래서 paged attention, continuous batching 같은 serving 기술이 중요해졌다.
CHAPTER 16 · SPARSE COMPUTE
15. MoE: “모든 전문가를 매번 부를 필요가 있을까?”
Dense Transformer에서는 대체로 모든 token이 각 layer의 동일한 feed-forward block을 지난다. 모델 capacity를 키우면 active compute도 함께 커진다.
Mixture of Experts(MoE)는 여러 expert를 두고 router가 token마다 일부 expert만 선택하도록 한다.
병원에 심장내과, 정형외과, 피부과, 안과 의사가 모두 있다고 해서 감기 환자 한 명을 진료할 때 모든 의사를 한 방에 부를 필요는 없다. 접수(router)가 필요한 전문의를 고르면 된다.
Switch Transformer는 sparse expert scaling을 강하게 보여줬고, Mixtral 8×7B는 각 layer에서 8개 expert 중 token마다 2개를 선택하는 방식으로 MoE 구조를 널리 알렸다.
MoE에서는 전체 모델 capacity는 매우 클 수 있지만, token 하나를 처리할 때 실제 활성화되는 parameter는 일부다.
물론 공짜는 아니다. expert load balancing, all-to-all communication, distributed inference, router stability 등 시스템 복잡도가 커진다.
CHAPTER 17 · THINKING BECOMES COMPUTE
16. Reasoning: 이제 모델 크기뿐 아니라 ‘얼마나 생각하게 할지’가 중요해졌다
GPT-3 시대까지 scaling은 주로 training-time compute에 관한 이야기였다. 최근 reasoning 흐름에서는 inference-time, 즉 답을 만들 때 얼마만큼 추가 계산을 할 것인가가 새로운 축이 됐다.
Chain-of-Thought: 중간 단계를 쓰게 하자
2022년 Chain-of-Thought prompting 연구는 큰 language model에 intermediate reasoning step 예시를 제공하면 산술, 상식, symbolic reasoning task에서 성능이 크게 개선될 수 있음을 보여줬다.
문제 → 답
문제 → 중간 단계 → 검토 → 답
Test-time Scaling: 한 문제에 compute를 더 쓰면?
2024년 이후 test-time compute 연구는 더 많은 candidate를 생성하거나, search하고, verifier로 고르고, reasoning step을 늘리는 방식으로 inference compute를 확장하는 방향을 본격적으로 탐색했다.
최근의 scaling: “이 문제 하나를 풀 때 compute를 얼마나 쓸까?”
DeepSeek-R1 계열이 보여준 것
2025년 공개된 DeepSeek-R1 연구는 수학·코딩처럼 결과 검증이 상대적으로 명확한 영역에서 reinforcement learning을 활용해 reasoning behavior를 강화하는 흐름에 큰 관심을 불러일으켰다.
핵심은 “reasoning은 prompt trick만의 문제가 아니라 training objective와 inference strategy까지 포함하는 시스템 문제가 됐다”는 점이다.
CHAPTER 18 · FROM WORDS TO ACTIONS
17. Agentic AI: LLM이 문장을 만드는 모델에서 ‘행동을 선택하는 엔진’으로
LLM이 답변만 한다면 세상과 상호작용할 수 있는 범위가 제한적이다. 최신 가격을 알려면 검색해야 하고, 고객 정보를 조회하려면 DB를 읽어야 하며, 예약을 하려면 API를 호출해야 한다.
이때 LLM의 역할은 문장 생성기를 넘어 다음 action을 결정하는 policy에 가까워진다.
ReAct: Reasoning과 Acting을 번갈아 수행하다
ReAct 연구는 reasoning trace와 action을 interleave하는 패턴을 제시했다. 생각만 계속하면 외부 사실을 확인할 수 없고, 행동만 하면 왜 그 행동을 해야 하는지 계획하기 어렵다. 둘을 번갈아 수행한다.
그래서 Agent는 LLM보다 시스템 엔지니어링이 어렵다
모델이 API parameter를 정확히 생성할 수 있는가.
이 사용자가 이 action을 수행할 권한이 있는가.
이전 step 결과와 task progress를 어떻게 저장하는가.
API failure나 malformed output을 어떻게 복구하는가.
재시도해도 결제가 두 번 되지 않는가.
어떤 판단으로 어떤 tool을 호출했는지 추적 가능한가.
CHAPTER 19 · THE INFRA STORY
18. Prefill / Decode를 알면 왜 GPU와 CPU 이야기가 다시 나오는지 보인다
LLM의 역사에는 algorithm의 역사와 함께 hardware workload의 역사가 숨어 있다. 특히 inference는 prefill과 decode로 나눠 보면 이해가 쉽다.
Prefill: prompt를 처음 읽는 구간
사용자가 긴 prompt를 보내면 모델은 모든 input token을 Transformer layer에 통과시키며 각 layer의 K/V를 계산한다. 이 과정은 큰 matrix operation이 많아 비교적 GPU parallelism을 잘 활용한다.
Decode: 다음 token을 하나씩 만드는 구간
첫 output token이 나온 뒤에는 한 token씩 autoregressive하게 생성한다. 다음 token은 이전 output이 있어야 만들 수 있기 때문에, RNN 시대의 순차성이 묘하게 다시 등장한다.
| Prefill | Decode | |
|---|---|---|
| 입력 | prompt 전체 | 새 token 1개씩 |
| 특성 | 큰 병렬 행렬연산 | autoregressive sequential loop |
| 주요 병목 | compute / long context | memory bandwidth / KV cache / scheduling |
| 대표 지표 | TTFT(Time To First Token) | ITL(Inter-Token Latency), tokens/s |
Agent 시대에 CPU가 다시 중요해지는 이유
LLM inference 자체의 핵심 neural compute는 여전히 GPU 같은 accelerator가 담당한다. 하지만 agent는 매번 GPU에서만 사는 프로그램이 아니다.
1. LLM 호출
2. JSON tool call parsing
3. authorization check
4. PostgreSQL query
5. HTTP API call
6. 검색 결과 rerank
7. 결과 직렬화
8. 다시 LLM prefill
9. 다음 action 결정
이 사이에는 CPU, memory, network, DB, queue, scheduler가 모두 관여한다. 즉 agentic workload에서는 “GPU utilization만 높이면 된다”는 사고로는 전체 latency를 설명할 수 없다.
Training 시대: GPU cluster 중심
LLM Serving 시대: GPU + KV cache + batching
Agent 시대: GPU + CPU + DB + network + tool orchestration + security
CHAPTER 20 · WHAT AN LLM REALLY IS
19. 결국 지금의 LLM은 무엇인가?
가장 단순하게 말하면 대부분의 decoder-only LLM은 여전히 “이 문맥 다음에 어떤 token이 올 확률이 높은가?”를 학습한 모델이다.
그런데 이 단순한 목표에 수십 년 동안의 아이디어가 쌓였다.
| 시대 | 문제 | 해결 | 다음 병목 |
|---|---|---|---|
| n-gram | 언어의 확률 | 빈도 기반 모델 | 희소성, 일반화 |
| Neural LM | 단어 유사성 | distributed representation | sequence / context |
| RNN | 순서와 기억 | recurrent hidden state | long dependency, 병렬화 |
| LSTM | 장기 기억 | gating + cell state | 순차 계산 |
| Attention | fixed vector bottleneck | 필요한 입력 위치 재조회 | 효율적인 global relation |
| Transformer | recurrence | self-attention + parallelism | compute, O(n²) |
| Pre-training | task별 모델 | 하나의 큰 foundation model | 비용, alignment |
| RLHF | 사용자 지시와 불일치 | human preference 기반 post-training | truthfulness, robustness |
| RAG | 닫힌 내부 지식 | external memory | retrieval quality |
| MoE / 효율화 | 너무 비싼 모델 | sparse compute / efficient kernels | system complexity |
| Reasoning | 즉답의 한계 | test-time compute | cost, verification |
| Agent | 텍스트만 생성 | tool use + action loop | reliability, security, governance |
20. 이 역사를 알면 최신 AI 뉴스가 다르게 보인다
새로운 모델이나 논문을 볼 때 “성능이 몇 점 올랐다”보다 먼저 어떤 병목을 해결하려는 기술인지를 보면 이해가 빨라진다.
Transformer의 sequence-length cost와 외부 memory 문제를 푼다.
모델 capacity와 active compute를 분리하려 한다.
수학적 attention보다 hardware IO bottleneck을 푼다.
parametric knowledge의 stale / provenance 문제를 외부 memory로 푼다.
training scale만이 아니라 inference compute를 성능 축으로 사용한다.
모델이 모르는 것을 검색하고 실제 세계에 action을 수행하게 한다.
“언어를 세는 기계 → 문맥을 기억하는 기계 → 문맥 전체를 바라보는 기계 → 세상의 텍스트를 미리 읽은 기계 → 사람의 지시를 따르는 기계 → 외부 지식을 찾는 기계 → 생각하고 행동하는 시스템”
으로 이어져 왔다.
21. 마지막으로, Transformer가 모든 것을 해결한 것은 아니다
2017년 Transformer는 거대한 전환점이었지만 종착점은 아니었다. Self-attention의 O(n²) 비용, 긴 context에서의 memory 부담, autoregressive decode의 순차성, hallucination, factual freshness, tool execution reliability 같은 새로운 문제가 생겼다.
그래서 SSM/Mamba처럼 linear-time sequence modeling을 다시 탐색하거나, efficient attention을 만들고, 외부 retrieval을 붙이고, MoE로 sparse compute를 사용하고, reasoning 과정에 더 많은 test-time compute를 배분하는 연구가 이어진다.
22. 앞으로의 질문
이제 frontier는 단순히 parameter 수만의 경쟁이 아니다. 더 좋은 학습 데이터, 더 효율적인 architecture, 더 긴 memory, 더 강한 reasoning, 더 신뢰할 수 있는 tool use, 더 낮은 serving cost, 그리고 실제 조직의 security / governance까지 한꺼번에 최적화해야 한다.
그래서 앞으로 LLM engineer의 역할도 모델 API를 호출하는 수준에서 멈추기 어렵다. 모델, retrieval, inference, distributed systems, data, evaluation, security, observability가 점점 하나의 문제로 합쳐진다.
References · 원 논문으로 더 깊게 보기
- Shannon, C. E. — Prediction and Entropy of Printed English (1951)
- Elman, J. L. — Finding Structure in Time (1990)
- Hochreiter & Schmidhuber — Long Short-Term Memory (1997)
- Bengio et al. — A Neural Probabilistic Language Model (2003)
- Mikolov et al. — Efficient Estimation of Word Representations in Vector Space (2013)
- Sutskever et al. — Sequence to Sequence Learning with Neural Networks (2014)
- Bahdanau et al. — Neural Machine Translation by Jointly Learning to Align and Translate (2014)
- Vaswani et al. — Attention Is All You Need (2017)
- Howard & Ruder — ULMFiT (2018)
- Peters et al. — Deep Contextualized Word Representations (ELMo) (2018)
- Radford et al. — Improving Language Understanding by Generative Pre-Training (2018)
- Devlin et al. — BERT (2018)
- Raffel et al. — T5 (2019)
- Kaplan et al. — Scaling Laws for Neural Language Models (2020)
- Brown et al. — Language Models are Few-Shot Learners (2020)
- Lewis et al. — Retrieval-Augmented Generation (2020)
- Hu et al. — LoRA (2021)
- Ouyang et al. — InstructGPT / RLHF (2022)
- Hoffmann et al. — Chinchilla (2022)
- Wei et al. — Chain-of-Thought Prompting (2022)
- Dao et al. — FlashAttention (2022)
- Yao et al. — ReAct (2022/2023)
- Touvron et al. — LLaMA (2023)
- Gu & Dao — Mamba (2023)
- Jiang et al. — Mixtral of Experts (2024)
- Snell et al. — Scaling LLM Test-Time Compute Optimally (2024)
- Guo et al. — DeepSeek-R1 (2025)
※ 이 글의 그림은 개념 이해를 위해 단순화한 도식이다. 실제 LLM 구조와 성능은 모델별 architecture, tokenizer, positional encoding, attention variant, 학습 데이터, post-training, serving 설정에 따라 달라질 수 있다.
'LLM' 카테고리의 다른 글
| [LLM] 콜센터에 AI를 심어보자 — STT부터 RAG, Agent Assist까지 실시간 상담 Copilot Deep Dive (0) | 2026.09.04 |
|---|---|
| [LLM] LLM Evaluation A to Z — “평가 그거 현업이 다 하나요?” Dataset부터 LLM-as-a-Judge까지 (0) | 2026.09.04 |
| [LLM] RAG 고도화 여정기 — Naive RAG에서 GraphRAG까지, 그런데 시작은 Ingestion이다 (0) | 2026.09.04 |
| [LLM] GraphRAG 최신 트렌드 — 벡터 검색이 놓치는 관계와 현실적인 타협점 (0) | 2026.09.04 |
| [LLM] LangSmith와 LLM 옵저버빌리티 — 에이전트도 로그를 남겨야 한다 (0) | 2026.09.03 |