P6-4.1 LLM 안의 Transformer 계산 흐름¶

Section ID: P6-4.1 Version: v2026.07.23

보조제목: Transformer는 토큰 표현을 어떻게 다음 후보 점수로 이어 주는가

Part 5에서 본 Transformer 구조를 이제 Part 6의 생성형 언어 모델 본류 안으로 다시 가져와야 합니다.

Part 5가 Transformer의 블록 구조 자체를 설명했다면, Part 6에서는 같은 구조를 생성형 언어 모델의 계산 흐름 안에서 다시 읽어야 합니다. 핵심은 토큰 -> 임베딩 -> attention 블록 -> 다음 토큰 점수가 하나의 생성 흐름으로 이어진다는 점입니다.

LLM 관점에서 Transformer를 다시 보면, 무엇이 정말 핵심인가? LLM에서 Transformer는 토큰들을 임베딩으로 바꾸고, self-attention으로 서로의 관계를 읽고, feed-forward와 반복 블록으로 표현을 정제하며, 최종적으로 다음 토큰을 예측하는 기본 구조입니다.

Transformer가 생성 계산에서 맡는 일¶

생성 계산 엔진을 다시 읽을 때 핵심 질문은 다음 세 가지입니다.

• 이미 본 Transformer를 LLM 관점으로 다시 보면 무엇이 달라지는가?
• 토큰, 임베딩, self-attention, 다음 토큰 예측은 어떻게 이어지는가?
• 왜 Transformer는 생성형 언어 모델의 기본 구조가 되었는가?

Transformer 블록의 큰 구조를 먼저 잡으면, multi-head attention과 위치 표현, KV cache, sparse attention, long-context 같은 보강 주제도 같은 흐름 위에 놓을 수 있습니다. 서비스 운영 관점의 지연 시간과 비용 제약도 결국 이 계산 흐름을 얼마나 많이, 얼마나 오래, 얼마나 빠르게 반복하는가와 연결됩니다.

Transformer 공식을 다시 전개하는 것보다 중요한 것은 Part 6에서 다룰 GPT, pretraining, next-token prediction, RAG, agent 설명을 모두 떠받치는 LLM 기준의 구조 지도입니다. 세부 블록 이름보다 중요한 기준은 입력 토큰이 어떤 계산 흐름을 거쳐 다음 토큰 점수로 이어지는가입니다.

이 절이 Part 6 본류 요청 흐름에서 맡는 역할은 입력 토큰이 어떤 계산 엔진을 통과해 다음 후보 점수로 이어지는지 보여 주는 데 있습니다. 이 흐름이 잡혀야 P6-5.1의 GPT 계열, P6-6.1의 다음 토큰 예측, 뒤쪽의 context window, prompt, RAG 설명을 같은 구조 위에서 읽을 수 있습니다.

여기서 확인해야 할 결과는 Transformer를 다음 토큰을 한 번 맞히는 장치가 아니라, 문맥 전체를 반영해 다음 후보 분포를 갱신하는 중심 엔진으로 읽게 되는가입니다. 이 구분이 잡혀야 Part 5의 딥러닝 구조 설명이 Part 6의 생성 모델 구조로 자연스럽게 이어집니다.

같은 Transformer를 왜 다시 읽어야 하는가¶

Part 5에서는 Transformer를 딥러닝 구조로 설명했습니다. 즉:

• self-attention
• feed-forward
• residual connection
• layer normalization

같은 블록 요소를 중심에 두었습니다.

Part 6에서는 같은 구조를 보되 질문이 달라집니다.

• 이 구조가 텍스트를 어떻게 읽는가?
• 이 구조가 왜 다음 토큰 예측(next-token prediction)에 잘 맞는가?
• 이 구조가 왜 LLM 서비스의 기본 계산 단위가 되었는가?

즉, 구조는 같지만 읽는 관점이 달라집니다.

P5-14를 읽었다고 해서 곧바로 P6-4.1이 자동으로 이해되는 것은 아닙니다. P5-14는 Transformer 블록 안에 무엇이 들어 있는가를 닫는 절이고, P6-4.1은 그 블록이 LLM 요청을 받아 다음 토큰 후보 점수로 닫히는 흐름을 새로 연결해야 하는 절입니다.

따라서 Part 5에서 바로 넘어올 때는 다음 빈칸을 먼저 메워야 합니다.

이 표에서 확인해야 할 결과는 P5-14를 다시 설명할 수 있는가가 아닙니다. P5-14의 블록 설명을 발판으로 삼되, 이제는 문맥을 반영한 표현이 어떻게 다음 토큰 후보 분포로 바뀌는가를 설명할 수 있어야 합니다. 이 다리가 없으면 P6-4.1의 사례와 예제는 갑자기 다음 토큰 점수표로 뛰어드는 것처럼 읽힙니다.

LLM에서는 토큰이 출발점이다¶

LLM은 문장을 통째로 계산하지 않습니다. 먼저 토큰(token) 시퀀스로 읽습니다.

예를 들어 다음처럼 생각할 수 있습니다.

1
2
3
4
5
6

raw text
-> tokens
-> token ids
-> embeddings
-> Transformer blocks
-> next-token scores

여기서 Transformer는 토큰을 이미 쪼갠 뒤의 계산 구조입니다. 즉, Transformer는 텍스트를 직접 해석하는 첫 단계가 아니라, 토큰 표현을 반복적으로 가공하는 중심 엔진에 가깝습니다.

임베딩은 계산 가능한 출발 표현을 만든다¶

P6-2장에서 본 것처럼 토큰 ID는 단순 번호입니다. Transformer는 이 번호를 직접 다루지 않고, 먼저 임베딩(embedding) 벡터로 바꿉니다.

이 임베딩 벡터는 이후 모든 계산의 출발점이 됩니다.

다음처럼 이해할 수 있습니다.

임베딩은 토큰을 Transformer가 계산할 수 있는 숫자 좌표로 바꾸는 단계다.

즉, Transformer는 텍스트를 문자열로 읽는 것이 아니라, 임베딩된 토큰 표현 위에서 작동합니다.

self-attention은 왜 LLM에 특히 중요했나¶

생성형 언어 모델은 현재 위치의 다음 토큰을 예측해야 합니다. 이때 지금까지 등장한 이전 토큰들이 모두 힌트가 될 수 있습니다.

예를 들어:

• 앞에서 등장한 주어
• 코드 블록의 함수 이름
• 문서 초반의 핵심 조건

같은 정보가 뒤쪽 생성에 영향을 줄 수 있습니다.

self-attention은 각 토큰이 다른 토큰들과의 관련도를 계산하게 합니다. 그래서 현재 토큰 표현은 주변과 멀리 있는 이전 토큰들의 정보를 함께 반영할 수 있습니다.

LLM에서 self-attention은 지금까지 나온 토큰들 중 무엇이 현재 생성에 더 중요한지 계산하는 구조다.

feed-forward와 반복 블록은 왜 필요한가¶

self-attention만으로는 토큰 간 관계를 섞을 수 있지만, 그 정보가 바로 충분히 좋은 표현이 되는 것은 아닙니다.

feed-forward network는 각 위치에서 그 표현을 더 가공합니다. 그리고 이 블록이 여러 층 반복되면 표현은 더 풍부해질 수 있습니다.

즉:

• attention은 관계를 읽고
• feed-forward는 각 위치 표현을 다시 다듬고
• 여러 층 반복은 표현을 점점 더 정제합니다

이 흐름은 Part 5의 표현 학습(representation learning) 설명과 그대로 이어집니다.

왜 마지막에는 다음 토큰 점수가 나오는가¶

LLM 설명에서 중요한 차이는 마지막 출력 해석입니다.

분류 모델은 마지막에 클래스(class) 점수를 내는 경우가 많습니다. 하지만 생성형 언어 모델은 보통 다음에 올 수 있는 토큰 후보들에 대한 점수를 냅니다.

즉, Transformer 블록을 지나면 마지막에는 대략 이런 질문이 됩니다.

• 다음 위치에 어떤 토큰이 올 가능성이 큰가?

이 점수는 이후 softmax와 sampling 같은 절차를 거쳐 실제 출력 토큰 선택으로 이어집니다.

따라서 Part 5의 구조 설명은 Part 6에서 다음과 같이 다시 읽힙니다.

표현 학습 구조 -> 다음 토큰 분포 계산 구조

이 차이를 작은 입력 하나로 다시 압축해 보면 다음과 같습니다.

따라서 목표는 Transformer 부품 이름을 다시 외우는 것이 아니라, 같은 부품들이 LLM 안에서 문맥 반영 -> 표현 갱신 -> 다음 후보 점수라는 생성 흐름을 만든다는 점을 붙잡는 것입니다.

아주 단순하게 그리면¶

flowchart TD
  A["토큰"]
  B["임베딩 + 위치 정보"]
  C["Transformer 블록"]
  D["다음 토큰 점수"]
  E["선택된 다음 토큰"]

  A --> B
  B --> C
  C --> D
  D --> E

이 도식은 Part 6에서 Transformer를 읽을 때 가장 자주 떠올려야 하는 최소 구조입니다.

사례 및 예시¶

아래 도식은 이 절의 세 사례를 다음 한 토큰을 고른다보다 앞 문맥 전체가 다음 후보 분포를 어떻게 바꾸는가라는 공통 질문으로 다시 묶은 것입니다.

flowchart TD
  A["같은 Transformer 질문"]
  B["자동완성<br/>어떤 이어쓰기 표현이 이 문맥에 맞는가?"]
  C["코드 생성<br/>어떤 식별자와 로직이 일관되게 유지되는가?"]
  D["긴 요약<br/>어떤 앞선 조건이 계속 살아 있어야 하는가?"]

  A --> B
  A --> C
  A --> D

이 도식에서 확인해야 할 점은 과업이 달라도 마지막 단계는 비슷하다는 것입니다. 모두 다음 토큰 하나를 찍는다가 아니라, 앞에서 들어온 문맥 전체를 반영해 지금 어떤 후보 분포가 만들어지는가를 먼저 봐야 합니다.

사례 1. 문장 자동완성¶

운영자가 메신저 초안을 쓰다가 오늘 회의는 오후까지만 입력한 장면을 떠올려 보겠습니다. 마지막 단어 바로 뒤만 보고 2시, 3시처럼 다음 말을 찍어 보려 하기 쉽습니다. 하지만 실제 자동완성은 마지막 단어 하나만 보는 문제가 아닙니다. Transformer는 앞 토큰들을 보고 다음 후보 분포를 계산하면서, 회의와 오후처럼 앞에 나온 단서들을 함께 반영해 다음 표현을 고르게 됩니다. 예를 들어 같은 문장이라도 앞부분에 고객사와가 있으면 공손한 공지형 표현이, 팀 내부가 앞에 있으면 짧은 협업형 표현이 더 자연스럽게 떠오를 수 있습니다. 여기서 바뀌는 점은 마지막 단어 뒤를 찍는가를 보던 기준에서 앞 문맥 전체가 다음 후보를 어떻게 바꾸는가를 보는 기준으로 이동한다는 것입니다.

같은 오늘 회의는 오후라는 끝부분도 앞 문맥이 다르면 다음 후보가 달라집니다.

이 표가 바로잡는 오해는 마지막 단어만 같으면 다음 후보도 거의 같다는 기대입니다. 자동완성 사례는 바로 이 오해를 깨면서, Transformer가 앞 문맥 전체를 보는 구조라는 점을 가장 쉽게 보여 줍니다.

사례 2. 코드 생성¶

함수 정의와 변수 선언이 앞에 있고, 뒤에서 구현을 이어 쓸 때, 바로 앞줄만 보면 변수 이름을 놓치기 쉽습니다. 앞부분에서 user_id를 선언했는데 뒤에서 갑자기 userId나 account_id로 미끄러지면 문법은 맞아 보여도 구현 일관성은 깨집니다. 함수 이름이 calculate_total인데 할인 단계나 세금 반영 순서가 빠져도, 앞에서 세운 목적과 뒤 구현이 어긋납니다.

같은 코드 생성도 앞 문맥을 얼마나 붙잡느냐에 따라 흔들리는 지점이 다릅니다.

이 사례에서 확인할 결과는 지금 줄 근처만 맞는가가 아니라 앞에서 선언한 이름과 목적이 뒤 구현의 다음 후보에도 계속 반영되는가입니다. 코드 생성에서 Transformer 구조가 중요한 이유는 바로 앞 문맥뿐 아니라 이미 열린 이름, 목적, 블록 구조를 바탕으로 다음 후보 분포를 바꾸기 때문입니다.

사례 3. 긴 문서 요약¶

긴 문서를 요약할 때도 다음 문장 후보는 눈에 띄는 결론 한 줄만으로 정해지지 않습니다. 앞부분의 정의가 뒤 결론의 적용 범위를 제한하거나, 뒤쪽 예외 조건이 앞의 일반 설명을 좁힐 수 있습니다. 예를 들어 결론 문장은 짧지만 그 결론이 성립하는 범위가 앞 단락에 묶여 있다면, 요약 문장의 다음 후보도 그 범위를 반영해야 자연스럽습니다.

이 사례에서 확인할 결과는 눈에 띄는 앞이나 뒤 한 부분만 붙잡는가가 아니라 앞의 조건과 뒤의 예외가 다음 요약 후보에 함께 반영되는가입니다. 긴 문서 전체를 얼마나 오래 유지할지는 P6-4.2와 P6-4.5에서 더 직접 다루고, 여기서는 Transformer가 문맥 단서를 다음 후보 분포로 연결한다는 점만 붙잡으면 됩니다.

세 사례를 문맥 반영 관점으로 다시 묶으면 다음과 같습니다.

실패 장면에서 다시 보는 기준¶

Transformer를 적용 장면에서 다시 볼 때 자주 하는 실수는, 이를 어려운 내부 구조 이름 모음으로만 읽고 실제 장면에서 언제 이 관점을 다시 꺼내야 하는지 놓치는 일입니다. 이때는 수식이나 블록 이름을 다시 외우기보다, 지금 문제가 앞 문맥 전체를 반영해 다음 후보를 고르는가의 문제인지 먼저 가르는 편이 안전합니다.

이 표의 목적은 Transformer를 다시 정의하는 데 있지 않습니다. 실제 실패 장면을 봤을 때 바로 앞 조각만 붙이면 되는 문제인지, 아니면 앞 문맥 전체를 반영하는 구조로 다시 읽어야 하는 문제인지 먼저 분기하게 만드는 데 있습니다.

연습 및 예제¶

이 연습의 목표는 실제 Transformer 전체를 구현하는 것이 아니라, 앞에서 정리한 문맥 반영 -> 표현 갱신 -> 다음 후보 점수 흐름을 작은 점수표와 그래프로 확인하는 것입니다. 같은 끝부분을 공유하는 문장이 앞 문맥 단서에 따라 어떤 후보 분포로 달라지는지 읽어 보겠습니다.

확인할 핵심은 다음 토큰 예측을 문맥에서 어떤 단서가 켜졌는지에 따라 후보 점수와 확률 분포가 달라지는 과정으로 읽는 것입니다. 아래 값은 실제 LLM의 내부 확률이 아니라, 점수 차이가 후보 분포로 어떻게 보이는지 설명하기 위한 단순화된 예시입니다.

아래 도식은 이 예제가 확인하려는 흐름을 먼저 압축한 것입니다. 같은 끝부분이 있어도 앞 문맥 단서가 Transformer 블록 안에서 표현을 바꾸고, 그 차이가 후보 점수표와 후보 간 격차로 이어집니다.

flowchart TD
  A["같은 끝부분<br/>오늘 회의는 오후 2시에 진행"]
  B["앞 문맥 단서<br/>말투, 목적, 형식"]
  C["Transformer 블록<br/>문맥 표현 갱신"]
  D["후보 점수표<br/>합니다 / 이다 / 되었습니다"]
  E["softmax식 분포<br/>후보 간 격차 변화"]
  F["다음 토큰 선택<br/>1위 후보와 margin"]

  A --> C
  B --> C
  C --> D
  D --> E
  E --> F

아래 표의 입력은 네 가지 문맥 조건입니다. 네 조건은 모두 같은 끝부분인 오늘 회의는 오후 2시에 진행을 공유하지만, 앞에 붙은 문맥 단서가 다릅니다. 문맥 변화 열은 어떤 단서가 들어갔는지 보여 주고, 1위 후보와 2위 후보는 그 조건에서 다음에 올 표현 후보의 순위를 보여 줍니다. 1위 확률과 1, 2위 격차는 1위가 얼마나 안정적인지를 읽기 위한 값입니다.

같은 끝부분을 공유하더라도 앞 문맥에서 읽힌 단서가 다르면 후보 점수표는 달라집니다.

표를 읽을 때는 먼저 문맥 변화 열을 보고, 그다음 1위 후보가 무엇인지, 마지막으로 1, 2위 격차가 큰지 작은지를 봅니다. 예를 들어 고객사 공지 메일에서는 1위가 합니다이고 격차도 큽니다. 반대로 팀 내부 메모에 공손한 말투가 섞임에서는 1위가 합니다로 바뀌지만 격차가 0.09로 작습니다. 같은 1위라도 안정적인 선택과 흔들리는 선택이 다르게 보이는 지점입니다.

그래프에서 볼 지점도 막대의 높이 자체보다 후보 사이의 상대적 거리입니다. 팀 내부 메모에 공손한 말투가 섞임에서는 합니다가 1위이지만 다른 후보와의 격차가 작습니다. 이 상태는 다음 토큰 선택이 안정적으로 하나로 굳었다기보다, 문맥 단서가 서로 다른 방향으로 후보 분포를 끌어당기고 있다고 읽는 편이 좋습니다.

이렇게 보면 중요한 것은 정답 토큰 하나를 외우는 것이 아니라, 문맥에서 어떤 단서가 후보 분포를 어떻게 밀어 올리거나 끌어내리는가입니다.

이 예제에서 확인해야 할 핵심은 다음입니다.

• 같은 후보 집합이라도 앞 문맥에서 읽은 단서가 다르면 점수표가 달라집니다.
• Transformer의 마지막 계산은 완성 문장 자체보다 다음 후보들에 대한 점수 분포에 가깝습니다.
• 실제 출력 토큰은 그 점수표에서 가장 높은 후보를 고르거나, sampling 같은 규칙을 거쳐 선택됩니다.
• 즉, 생성은 한 단어를 바로 맞힌다보다 문맥을 반영해 후보 분포를 계속 갱신한다는 관점으로 보는 편이 정확합니다.

다음 토큰 선택에서 갈리는 후보¶

앞의 연습은 긴 문맥 계산이 마지막에는 후보 점수 비교와 다음 토큰 선택으로 닫힌다는 점을 더 실제적인 점수표 형태로 보여 주는 장면입니다. 여기서 읽어야 할 핵심은 복잡한 내부 블록을 모두 외우는 것이 아니라, 그 계산이 결국 앞 문맥에 따라 달라지는 다음 토큰 분포를 만든다는 점입니다. 즉, Transformer를 읽을 때는 정답 단어 하나를 바로 맞힌다보다 문맥 전체가 다음 후보 분포를 어떻게 바꾸는가를 보는 편이 더 정확합니다.

왜 LLM의 중심 엔진이 되었는가¶

Transformer가 언어 모델의 중심 구조가 된 이유는 단순히 성능이 좋았기 때문만은 아닙니다.

• 긴 문맥을 더 잘 다룰 수 있었고
• 병렬 처리와 잘 맞았으며
• 같은 기본 구조가 번역, 요약, 질의응답, 코드 생성 같은 여러 언어 작업에 넓게 재사용될 수 있었기 때문입니다

체크리스트¶

• Transformer를 문맥 전체를 반영해 다음 후보 분포를 갱신하는 엔진으로 설명할 수 있는가?
• Part 5의 구조 설명과 Part 6의 생성 설명이 어디서 갈라지는지 구분할 수 있는가?
• Transformer 계산도 실제로는 입력 범위 제약 안에서 작동한다는 질문을 이어서 설명할 수 있는가?

출처와 참고 자료¶

• Ashish Vaswani et al., Attention Is All You Need, NeurIPS 2017, 확인 날짜: 2026-07-19. Transformer의 self-attention, multi-head attention, positional encoding, feed-forward 블록을 LLM 구조 설명의 기본 근거로 사용했다.
• Alec Radford et al., Language Models are Unsupervised Multitask Learners, OpenAI 2019, 확인 날짜: 2026-07-19. GPT-2가 Transformer 기반 language model로 여러 언어 작업을 수행한다는 배경 근거로 사용했다.
• OpenAI, openai/gpt-2, 확인 날짜: 2026-07-19. GPT-2 코드와 모델이 위 논문의 공개 구현이라는 점과 모델 사용 시 평가가 필요하다는 주의점을 확인하는 보조 근거로 사용했다.
• Tom B. Brown et al., Language Models are Few-Shot Learners, arXiv 2020, 확인 날짜: 2026-07-19. GPT-3의 autoregressive language model과 few-shot text interaction 설명을, LLM이 다음 토큰 예측 기반으로 여러 과업을 수행하는 배경 근거로 사용했다.
• Jay Alammar, The Illustrated Transformer, 확인 날짜: 2026-07-19. Transformer 계산 흐름을 입문자용 도식 언어로 다시 설명할 때 보조 교육 자료로 참고했다.