| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- Pinpoint
- 코틀린 코루틴의 정석
- Spring
- MySQL
- Linux
- 공부
- AI
- APM
- CKA 기출문제
- 기록으로 실력을 쌓자
- SRE
- 바이브코딩
- go
- 티스토리챌린지
- Java
- minikube
- tucker의 go 언어 프로그래밍
- AWS EKS
- golang
- kotlin
- PETERICA
- LLM
- aws
- CKA
- 오블완
- kotlin coroutine
- 정보처리기사 실기 기출문제
- Rag
- CloudWatch
- Kubernetes
- Today
- Total
피터의 개발이야기
[AI] Transformer Encoder-Decoder 구조 - Attention 다음 단계, 메커니즘에서 시스템으로 본문
[AI] Transformer Encoder-Decoder 구조 - Attention 다음 단계, 메커니즘에서 시스템으로
기록하는 백앤드개발자 2026. 2. 3. 22:29
[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해
ㅁ 들어가며
지난 글에서 Attention이 어떻게 중요한 정보를 골라내는지 살펴봤다.
이번에는 그 Attention이 어떤 구조 안에서 역할을 나눠 동작하는지,
즉 Transformer의 Encoder–Decoder 구조를 정리해 보려 한다.
LLM을 실제로 다뤄보면, 결국 다시 이 구조로 돌아오게 된다.
RAG를 구성하고, Retriever 품질을 튜닝하고, Prompt를 다듬다 보면
어느 순간 “이 정보는 어디서 이해되고, 어디서 생성되는가?”라는 질문을 하게 된다.
그 답이 바로 Encoder–Decoder다.
ㅁ Attention 다음은 ‘구조’
Attention은 메커니즘이다.
Encoder–Decoder는 그 메커니즘을 배치한 시스템 구조다.
한 줄로 요약하면 이렇다.
Encoder는 이해, Decoder는 생성.
Transformer는 이 둘을 명확히 분리했다.
이 구조를 이해하면:
- 왜 현재 LLM 주류가 Decoder-Only인지
- 번역·요약·RAG에서는 왜 Encoder–Decoder 사고방식이 계속 살아 있는지
- Self-Attention과 Cross-Attention이 각각 어디에 쓰이는지
가 자연스럽게 연결된다.
ㅁ Transformer 전체 그림 — 역할 분리의 시작
Transformer는 크게 세 부분으로 나뉜다.
- Encoder: 입력 전체를 양방향으로 보며 의미를 압축
- Decoder: 이전 토큰만 보며 순차적으로 다음 토큰 생성
- Cross-Attention: Decoder가 Encoder 출력을 참조하는 연결 지점
즉,
입력을 이해하는 부분과
출력을 만들어내는 부분을 구조적으로 분리했다.
이 단순한 분리가 Transformer의 핵심이다.
ㅁ Encoder — 문장을 의미 구조로 압축한다
Encoder는 다음 블록을 반복한다.
- Token Embedding + Positional Encoding
- Multi-Head Self-Attention (양방향)
- Feed Forward Network
- Residual + LayerNorm
여기서 중요한 건 양방향 Self-Attention이다.
모든 토큰이 서로를 동시에 참조할 수 있다.
그래서 Encoder 출력은 단순한 단어 벡터가 아니라,
문맥이 반영된 의미 표현(Contextualized Representation)
이 된다.
나는 이렇게 이해하고 있다.
Encoder는 문장을 벡터 공간에서
‘의미 구조’로 압축하는 단계다.
RAG 관점에서 보면, Retriever가 가져온 문서 역시 결국 이 Encoder 입력으로 들어간다.
ㅁ Decoder - Autoregressive 생성기
Decoder는 Encoder와 다르게 Causal Mask를 사용한다.
- 미래 토큰을 볼 수 없다
- 지금까지 생성한 토큰만 보고 다음 토큰을 예측한다
구조적으로는:
- Masked Self-Attention (단방향)
- Cross-Attention (Encoder 출력 참조)
- Feed Forward
- Linear + Softmax → 다음 토큰 확률
Softmax란
여러 후보 중에서 “각각이 정답일 확률”을 만들어주는 함수이다.
요약하면:
Decoder는 미래를 모른 채,
지금까지 쓴 문장만 가지고 다음 단어를 맞힌다.
이 방식이 Autoregressive 생성이다.
ㅁ Cross-Attention - 이해와 생성이 만나는 지점
이번 글의 핵심이다.
Cross-Attention에서는:
- Query(Q): Decoder의 현재 상태
- Key/Value(K,V): Encoder의 출력
즉, Decoder가 Encoder 결과를 참조한다.
직관적으로 표현하면 이렇다.
Decoder는
“내가 지금 쓰고 있는 문장”과
“Encoder가 이해한 원문”을 동시에 본다.
번역 예시를 떠올리면 쉽다.
“서울을”이라는 토큰을 만들 때 Encoder의 “Seoul” 위치에 집중한다.
여기서 중요한 연결 포인트 하나.
RAG는 새로운 구조가 아니다.
Encoder 입력을 외부 지식으로 확장한 형태다.
Retriever로 가져온 문서를 Encoder 쪽에 붙이고,
Decoder는 Cross-Attention으로 그 지식을 참조하며 답을 생성한다.
ㅁ Cross-Attention — 이해와 생성이 만나는 지점
이번 글의 핵심이다.
앞에서 Encoder는 입력 문장을 양방향으로 읽으며 “의미 구조”로 압축하고,
Decoder는 이전 토큰만 보면서 다음 토큰을 하나씩 만들어낸다고 설명했다.
Cross-Attention은 바로 이 두 세계가 만나는 지점이다.
구조적으로 보면 Cross-Attention에서는:
- Query(Q): Decoder가 현재 생성 중인 문장의 상태
- Key/Value(K,V): Encoder가 미리 정리해 둔 입력 문서의 의미 표현
이렇게 역할이 나뉜다.
즉, Decoder는 혼자 상상으로 글을 쓰는 것이 아니라,
매 토큰마다 Encoder 쪽을 바라보면서 “지금 내가 쓰려는 내용이 원문 어디와 연결되는지”를 계속 확인한다.
나는 이 과정을 이렇게 이해하고 있다.
Decoder는 글을 쓰는 사람이고,
Encoder는 이미 읽어 둔 참고자료다.
Cross-Attention은 글을 쓰면서 참고자료를 계속 훑어보는 동작이다.
번역 예시를 떠올리면 훨씬 직관적이다.
“I love Seoul”이라는 문장을 번역할 때
Decoder가 “서울을”이라는 토큰을 생성하는 순간,
Cross-Attention은 Encoder 출력 중 “Seoul”에 해당하는 위치에 강하게 집중한다.
동시에 “love” 쪽에도 일정 가중치를 주어 문맥을 유지한다.
즉, 매 단어마다
- 지금까지 내가 쓴 문장
- Encoder가 이해해 둔 원문 전체
이 두 가지를 동시에 보면서 다음 토큰을 결정한다.
여기서 중요한 연결 포인트가 하나 있다.
RAG는 새로운 구조가 아니다.
Encoder 입력을 외부 지식으로 확장한 형태다.
Retriever가 문서를 가져오면,
그 문서는 그대로 Decoder로 가는 것이 아니라 먼저 Encoder를 거친다.
Encoder는 검색된 문서를 의미 벡터로 정리하고,
Decoder는 Cross-Attention을 통해 그 결과를 참조하며 답변을 생성한다.
그래서 RAG 파이프라인은 구조적으로 보면 이렇게 단순해진다.
외부 문서 → Encoder(이해) → Decoder(Cross-Attention으로 참조하며 생성)
정리하면,
Decoder가 더 똑똑해진 것이 아니라
Encoder에게 더 많은 참고자료를 준 구조가 RAG다.
이 관점으로 보면,
Cross-Attention은 단순한 Attention 변형이 아니라
“지식과 생성이 연결되는 인터페이스”에 가깝다.
ㅁ Encoder-Only / Decoder-Only / Encoder-Decoder
Transformer는 용도에 따라 세 가지 형태로 쓰인다.
- Encoder-Only: 이해 중심
→ BERT 계열 (분류, 임베딩) - Decoder-Only: 생성 중심
→ GPT, Claude (대화, 텍스트 생성) - Encoder-Decoder: 이해 + 생성
→ T5 (번역, 요약)
현재 LLM 주류는 Decoder-Only다.
하지만 구조적으로 보면,
Encoder–Decoder 사고 모델은 여전히 내부에 살아 있다.
ㅁ 현대 LLM에서는 어떻게 단순화되었나
GPT 계열은 Encoder를 따로 두지 않는다.
대신 Prompt Context와 KV Cache로 Encoder 역할을 흡수한다.
구현은 Decoder 하나지만,
개념적으로는 여전히
“입력 이해 → 출력 생성” 구조다.
그래서 Encoder–Decoder를 이해하면
Decoder-Only LLM의 내부 동작도 훨씬 명확해진다.
ㅁ 마무리
정리하면:
- Encoder: 의미 압축
- Decoder: 토큰 생성
- Cross-Attention: 외부 정보 연결
- RAG: Encoder 입력 확장
Transformer는 단순한 Attention 모델이 아니다.
이해와 생성을 분리하고,
그 사이를 Attention으로 연결한
사고 구조 자체에 가깝다.
사람과 AI의 차이는 결국 표현 방식이다.
사람은 생각을 언어와 감각으로 이어가고, 모델은 같은 과정을 벡터와 확률로 이어간다.
우리는 “의미”를 느끼고, 모델은 그 의미를 수치로 계산한다.
하지만 구조적으로 보면,
과거 맥락을 참고하고
현재 상태를 재해석하며
다음 생각을 만들어간다는 점에서
둘은 놀라울 만큼 닮아 있다.
그래서 LLM을 운영하다 보면
결국 다시 Encoder–Decoder 구조로 돌아오게 된다.
이 구조는 모델 아키텍처이기 이전에,
사고를 구현하는 하나의 방식이기 때문이다.
'AI > AI이론 | 공부' 카테고리의 다른 글
| [AI] Embedding 기초 — Transformer가 만든 의미를 저장하는 방법 (0) | 2026.02.05 |
|---|---|
| [AI] KV Cache — LLM은 어떻게 ‘생각의 흐름’을 기억하는가 (0) | 2026.02.05 |
| [AI] Attention 메커니즘 — LLM은 어떻게 ‘중요한 정보’를 골라내는가 (0) | 2026.02.02 |
| [AI] Backend · DevOps · SRE를 지나 AI Platform Engineer를 지향하게 된 이유 (0) | 2026.01.27 |
| [AI] RAG구성을 위한 FAISS란? (0) | 2026.01.14 |