왜 요즘 LLM은 decoder-only 구조인가

📍 AI 공부 지도 — 6/29편
이 글은 AI의 기초부터 Meta-Harness·응용 비교까지 순서대로 읽는 29편 시리즈의 6편입니다.
📚 전체 지도 보기
← 이전 편: F2. Transformer 구조 · 다음 편: F4. Attention is All You Need

왜 요즘 LLM은 decoder-only 구조인가

0. 들어가기 전에

이 글은 F2. Transformer가 뭔지 를 읽으신 분 기준입니다.

“Transformer는 문장을 한꺼번에 펼쳐놓고 attention으로 단어들 관계를 계산하는 구조” 라는 감이 있으면, 이 글은 부드럽게 읽힙니다.


1. 먼저 고백부터

Transformer를 조금 파다 보면 이런 그림 꼭 한 번 봅니다.

왼쪽에 “Encoder” 라고 쓰인 네모 덩어리
오른쪽에 “Decoder” 라고 쓰인 네모 덩어리
둘 사이를 화살표가 이어줌

그리고 다들 설명해요. “이게 Transformer의 원래 구조야.”

원 Transformer (2017) 구조
READING
Encoder
입력 문장을 읽고
의미 벡터로 압축
WRITING
Decoder
의미 벡터를 받아
한 단어씩 생성
두 덩어리가 화살표로 이어진 구조 — 번역·요약 등 입출력이 다른 작업용

근데 같은 설명 뒤에 바로 이런 말이 나옵니다.

“ChatGPT, Claude, GPT-4는 decoder-only 구조야.”

이 지점에서 대부분 막혀요.

  • 그럼 왼쪽 encoder는 어디 갔지?
  • 왜 버려졌지?
  • BERT는 encoder-only라는데, 그건 또 뭐야?
  • T5는 또 encoder-decoder라고?

이 글은 그 혼란 한 번에 정리하려고 씁니다.

한 문장으로 먼저 잡아두면:

Encoder는 “읽는 부분”이고, Decoder는 “쓰는 부분”이다. 원래 번역기에는 둘 다 필요했지만, 글쓰기 중심 LLM에서는 decoder 하나만 크게 키우는 게 더 잘 통한다는 게 밝혀졌다.

이걸 풀어 갈게요.


2. 원래 논문은 번역기를 만들었다

“Attention Is All You Need” (2017) 는 영어 → 독일어 번역 모델 을 제안한 논문입니다.

그래서 원래 Transformer는 이런 작업을 합니다.

입력: “The cat sat on the mat.”
출력: “Die Katze saß auf der Matte.”

이런 작업에는 두 가지 일이 필요해요.

  1. 입력 문장을 이해한다 (영어가 뭐라고 말했는지 파악)
  2. 이해한 내용을 다른 언어로 풀어쓴다 (독일어로 자연스럽게 출력)

이 두 작업을 한 덩어리에 몰아넣지 않고, 두 전담 부서 로 나눴습니다.

  • Encoder (인코더): 입력 문장을 읽고 의미 벡터 로 압축하는 부서
  • Decoder (디코더): 그 의미 벡터를 받아서 다른 언어로 한 단어씩 생성 하는 부서

비유로 치면:

독해 담당자(Encoder)가 영어 문장을 꼼꼼히 읽고 요약 메모를 만들면,
작문 담당자(Decoder)가 그 메모를 보고 독일어로 문장을 써 내려간다.

이 두 사람 사이에 오가는 게 의미 벡터 입니다.

번역처럼 입력과 출력의 형식이 다른 작업엔 이 구조가 딱입니다.


3. Encoder가 하는 일 — “읽고 이해만”

Encoder는 단순한 규칙 하나를 지킵니다.

모든 단어가 문장의 모든 단어를 볼 수 있다.

“The cat sat on the mat” 이 들어오면:

  • “cat” 은 “The, sat, on, the, mat” 모두를 참고해서 자기 의미를 업데이트
  • “sat” 도 다른 모든 단어 참고해서 업데이트

모든 단어가 양방향으로 서로를 봅니다.

이걸 bidirectional attention 이라고 불러요.

왜 이게 되냐면, 문장 전체가 이미 주어졌기 때문 입니다. “cat”이 “sat”을 미리 봐도 커닝이 아니에요. 어차피 전체 문장이 다 보이는 상태에서 압축하는 거니까요.

Encoder의 역할은 문장 전체를 읽어서, 각 단어가 문맥에 맞게 다시 표현된 벡터들의 묶음 을 만드는 것입니다.

이 묶음을 받으면 Decoder가 번역을 시작할 수 있어요.


4. Decoder가 하는 일 — “한 단어씩 쓰기”

Decoder는 Encoder와 다르게 규칙이 하나 더 붙습니다.

지금 쓰고 있는 단어는, 아직 안 쓴 단어(뒤쪽)를 볼 수 없다.

“Die Katze saß auf der Matte” 를 쓸 때:

  • 첫 단어 “Die” 를 쓸 때는 그 다음에 올 것을 모릅니다 (당연하죠, 아직 안 썼으니까)
  • “Katze” 쓸 때는 앞에 “Die” 만 참고
  • “saß” 쓸 때는 “Die Katze” 까지만 참고

왼쪽 방향으로만 볼 수 있어요. 이걸 masked attention 또는 causal attention 이라고 합니다.

왜 이렇게 막냐?

만약 “saß”를 만들 때 그 뒤에 올 “auf der Matte”를 미리 볼 수 있다면, 학습할 때는 커닝이 됩니다. 정답지를 보고 정답을 맞추는 거죠.

근데 실제 추론할 때는 그 뒤를 모르잖아요. 그래서 학습과 추론 환경을 맞추기 위해 뒤를 가려놓고 학습시킵니다.

그리고 Decoder는 한 가지를 더 합니다.

Encoder가 준 의미 벡터도 참고한다.

즉 Decoder의 각 단어 자리에서 attention 이 두 번 일어나요.

  1. 지금까지 쓴 자기 출력(왼쪽)을 본다 → self-attention
  2. Encoder가 넘겨준 의미 벡터를 본다 → cross-attention

cross-attention 이 번역의 핵심입니다. 독일어를 쓸 때도 원래 영어 문장의 어느 부분을 보고 쓰는지를 계속 확인하는 거예요.

이렇게 해서 Decoder는 한 단어씩:
– 자기 앞 단어들 참고
– Encoder의 영어 의미 참고
– 다음 단어 확률 분포 계산 → 한 단어 뽑음
– 반복

이걸 EOS(end of sequence) 토큰이 나올 때까지 이어갑니다.


5. 그런데 대화형 AI는 좀 다르다

여기까지 보면 encoder + decoder 조합이 꽤 자연스러워 보여요.

근데 ChatGPT 같은 대화형 AI를 생각해 보세요.

당신이 “파이썬으로 CSV 읽는 법 알려줘” 라고 입력하면, ChatGPT가 “import pandas as pd…” 라고 답합니다.

여기서 입력과 출력이 근본적으로 다른 언어 인가요?

아니요. 둘 다 한국어 + 코드 섞인 일반 텍스트입니다.

그리고 더 중요한 건, 대화는 계속 이어진다 는 점이에요.

당신이 답 받고 다시 “pandas 말고 표준 라이브러리로” 라고 추가 질문하면, 이제 입력은 [당신의 첫 질문] + [ChatGPT의 첫 답] + [당신의 추가 질문] 이 됩니다.

이게 입력인지 출력인지가 애매해지기 시작해요.

이 시점에서 “그냥 decoder만 크게 하나 만들어서, 전체를 다 decoder 식으로 처리하면 되지 않나?” 라는 발상이 나옵니다.

  • 문장 전체(당신 질문 + AI 답변)를 하나의 연속된 글 로 본다
  • Decoder가 이 글의 다음 단어를 계속 예측 한다
  • 어디까지가 “입력”이고 어디까지가 “출력”인지 모델 입장에선 구분할 필요 없음

이 발상에서 나온 게 decoder-only 모델입니다.

GPT, Claude, Gemini, Llama 전부 이 구조예요.


6. Decoder-only가 왜 이겼나

“번역용엔 encoder+decoder 가 자연스럽고, 대화용엔 decoder-only가 편하다” 정도의 얘기였으면 지금처럼 decoder-only가 압도하진 않았을 거예요.

진짜 이유는 따로 있습니다.

(1) 구조가 단순하다

  • encoder+decoder: attention 종류가 3개 (encoder self, decoder self, cross)
  • decoder-only: attention 종류가 1개 (masked self)

구조가 단순하면 학습·추론 코드가 단순해집니다. 규모를 키우기 쉽고, 최적화가 잘 돼요.

(2) “다음 단어 예측” 하나로 거의 모든 일을 시킬 수 있다

decoder-only 모델은 “다음 단어 예측” 이라는 한 가지 작업으로만 학습합니다.

근데 그 하나로 시키면 됩니다.

  • 번역: "영어: The cat sat. 독일어:" 다음에 올 단어 예측 → 번역됨
  • 요약: "긴 글. 요약:" 다음에 올 단어 예측 → 요약됨
  • 질의응답: "질문: …. 답변:" 다음에 올 단어 예측 → 답변됨
  • 코드: "Write Python to read CSV. Code:" 다음에 올 단어 예측 → 코드됨

한 가지 학습 목표(next token prediction)로 거의 모든 NLP 작업 을 표현할 수 있는 게 밝혀졌습니다.

이게 GPT-3 논문 (“Language Models are Few-Shot Learners”) 이 세상에 충격 준 핵심이에요. 굳이 encoder를 따로 둘 필요가 없어진 거죠.

(3) Scaling 하기 편하다

Decoder-only는 한 종류 블록이 계속 쌓인 구조입니다. 그래서 엄청나게 크게 만들어도 구조가 안 깨집니다.

encoder+decoder는 두 부분을 나눠서 키워야 하고, cross-attention 연결도 관리해야 해서 복잡해요.

OpenAI, Anthropic, Meta, Google이 전부 decoder-only를 밀고 올인한 이유가 이겁니다.


7. 그럼 encoder는 죽었나? — 아니요

여기서 오해가 많습니다.

“decoder-only가 주류니까 encoder는 끝난 기술이다” 라고 정리해 버리면 살짝 틀려요.

encoder가 여전히 주인공 인 영역이 있습니다.

(1) BERT 계열 — 분류·검색·유사도 판단

BERT (2018) 는 encoder-only 모델입니다.

BERT가 하는 일:
– 문장을 읽고 각 단어 벡터 를 만들어준다
– 이 벡터를 갖고 분류, 유사도 계산, 검색을 한다

예를 들어:
– 스팸 메일 분류: 메일 본문 → BERT → 벡터 → 스팸/정상 분류기
– 의미 검색: 쿼리와 문서를 각각 BERT에 넣어 벡터 만든 뒤, 벡터 거리 계산으로 “의미상 비슷한지” 판단

BERT는 생성 은 안 합니다. 이해 전담이에요.

지금도 검색 엔진, 추천 시스템, RAG의 embedding 모델 쪽에서 BERT 계열이 엄청 쓰입니다.

ⓘ RAG의 기초 retrieval에서 쓰는 embedding 모델은 거의 다 encoder-only 계열(BERT류)입니다. 본편 시리즈 👉 M1. Retrieval Layer 이해 에서 자세히 다룹니다.

(2) T5 계열 — encoder+decoder 하이브리드

T5 (Google, 2019) 는 원래 논문 구조를 그대로 큰 규모로 밀어붙인 모델이에요.

T5는 모든 NLP 작업을 “텍스트 → 텍스트” 형식으로 바꿔서 풉니다.

  • 번역: “translate English to German: …” → “…”
  • 요약: “summarize: …” → “…”
  • 분류: “sentiment: …” → “positive/negative”

입력과 출력이 분리된 이 구조에는 encoder+decoder 가 자연스러워요.

지금도 번역, 요약, 코드 생성 전문 모델, 특히 일부 multimodal 모델(이미지→텍스트) 에서 이 구조가 살아 있습니다.

(3) Vision 및 Multimodal

이미지 → 텍스트 생성 같은 작업에선 encoder가 다시 돌아옵니다.

  • 이미지 encoder가 이미지를 벡터로 압축
  • 텍스트 decoder가 그 벡터를 보고 설명문 생성

GPT-4V, Claude 3.5 Sonnet vision, Gemini가 속으로는 대략 이런 식 구조를 섞어 씁니다. (완전 decoder-only 안에 이미지 embedding을 prompt로 밀어 넣는 변종도 있어요. 구현마다 달라요.)


8. 세 가지 타입 정리

한 번에 비교 테이블로 가볼게요.

구조 대표 모델 잘하는 일 한계
Encoder-only BERT, RoBERTa, sentence-BERT 문장 이해, 분류, 검색 새 문장 생성 못 함
Decoder-only GPT, Claude, Llama, Gemini 글 생성, 대화, 코드, 요약, 번역까지 (초기에) 순수 이해 작업은 BERT보다 약했음
Encoder-Decoder 원 Transformer, T5, BART 입출력이 다른 작업 (번역, 요약) 구조가 복잡해서 scale 어려움

재밌는 건, 처음엔 분리돼 있던 역할들이 decoder-only로 점점 합쳐지는 흐름 이라는 점이에요.

GPT-4 수준이 되면 분류·이해 작업도 BERT급으로 잘합니다. 그래서 실무에선 “작업마다 다른 모델 쓰기”보다 “decoder-only 큰 모델 하나로 거의 다 커버”로 가는 추세예요.

그래도 저비용·저지연이 중요한 작업(예: 실시간 검색, 스팸 분류) 에선 여전히 BERT급 작은 encoder가 훨씬 실용적입니다.


9. 실무자 관점에서 이게 왜 중요하냐

“나는 모델 구조까지 알 필요 없다” 라고 생각하실 수 있어요.

근데 이 구분을 알면 실무에서 판단이 달라집니다.

(1) 모델 고를 때

  • “문서 수천 개에서 쿼리와 가장 비슷한 거 찾기” → encoder-only(BERT류) + 벡터 검색. GPT-4에 다 넣을 필요 없음.
  • “긴 문서를 바로 요약” → decoder-only(Claude, GPT)
  • “입력 형식이 고정되고 출력도 고정된 반복 작업(예: 폼 파싱)” → fine-tuned T5 계열이 더 저렴할 때 있음

(2) 프롬프트 설계할 때

decoder-only 모델의 약점은 앞만 본다 는 거예요. “아래 글 다 읽고 나서 앞부분을 다시 고려해서 답해 줘” 같은 요청은 한 번에 처리가 안 됩니다. 필요하면 “전체를 다 읽는 척한 뒤, 한 번 더 처음부터 보면서 답하라” 같은 재진입 프롬프트 를 설계해야 합니다.

(3) 왜 “컨텍스트 윈도우”가 이렇게 중요한지 이해됨

decoder-only 모델은 입력을 두 번 보지 않아요. 당신이 준 컨텍스트가 그대로 다음 토큰 예측의 조건 이 됩니다.

그래서 긴 컨텍스트를 다룰 수 있느냐가 decoder-only 시대에선 모델 경쟁의 핵심 축 이 됩니다.

Claude가 1M 토큰 context window를 발표하고, GPT가 128k까지 늘리고, Gemini가 2M까지 밀고 — 이게 다 decoder-only 구조의 약점을 정면돌파하려는 움직임이에요.

ⓘ “근데 컨텍스트가 커지면 다 해결되는 거 아닌가요?” 그게 그렇게 단순하지 않아요. 👉 M2. Long-context / Memory 에서 lost-in-the-middle 같은 함정까지 풀어드립니다.


10. 그래서 한 번 더 정리

  • 원 Transformer (2017): encoder + decoder. 번역 같은 입출력 다른 작업용.
  • BERT (2018): encoder-only. 이해·분류·검색 전담. 생성 안 함.
  • GPT / Claude / Llama / Gemini: decoder-only. 다음 단어 예측 하나로 거의 모든 일 처리.
  • T5 / BART: encoder + decoder. “텍스트 → 텍스트” 형식의 전문 작업용.

지금 AI 뉴스를 읽을 때 이 네 축이 머릿속에 있으면, “이 모델은 뭐야?” 라는 질문에 흐릿한 감이 바로 구조로 잡힙니다.

  • “embedding 모델이에요” → encoder-only 계열
  • “대화·글쓰기 LLM이에요” → decoder-only
  • “번역·요약 전문이에요” → encoder-decoder
  • “멀티모달이에요” → 보통 decoder-only에 image encoder 하나 붙인 형태

닫는 한 문장

encoder-decoder 구조가 번역기로 태어난 Transformer를 설명해 주지만, 지금 우리가 쓰는 거의 모든 대화형 LLM은 decoder 하나만 크게 키워서 “다음 단어를 계속 예측하게” 만든 것 이고, 이 단순화가 오히려 scaling을 가능하게 만든 결정적 갈림길이었습니다.


FAQ

Q1. BERT랑 GPT 중 어느 게 더 똑똑한가요?

“똑똑함”의 기준에 따라 답이 달라집니다. 문장 이해·유사도 판단·검색 같은 작업은 예전엔 BERT가 더 잘했고, 지금도 같은 비용 이면 작은 BERT계열이 GPT-4보다 빠르고 저렴하게 잘합니다. 대신 새 문장을 자연스럽게 생성 하거나 복잡한 지시를 따르는 작업은 decoder-only(GPT·Claude 계열)가 월등해요. 둘은 “똑똑함의 축”이 다릅니다. 작업에 맞게 고르는 게 맞습니다.

Q2. 그럼 Encoder 공부는 안 해도 되나요?

생성 AI만 쓰신다면 직접 다룰 일은 거의 없습니다. 그런데 RAG(검색 증강 생성)를 실무에 붙이면 필수 가 돼요. RAG의 “검색” 단계는 쿼리와 문서를 벡터로 만드는 encoder 모델이 담당합니다. Claude나 GPT가 훌륭해도 검색이 나쁘면 답이 엉뚱하게 나오거든요. 그래서 실무자에게도 “BERT 계열 embedding 모델이 뭔지” 정도 감은 있으면 좋습니다.

Q3. Claude나 GPT 속에도 encoder가 숨어 있는 건가요?

엄밀히 말하면 decoder-only 구조에는 별도 encoder가 없습니다. 대신 decoder가 입력(prompt)을 읽는 과정 자체가 BERT의 encoder 역할을 흉내 내게 됩니다 (앞만 볼 수 있다는 제약이 있긴 하지만). 요즘 멀티모달 모델은 이미지 처리용 별도 encoder가 붙어 있는 경우는 있어요. 텍스트만 놓고 보면 ChatGPT·Claude는 “decoder 하나로 읽기와 쓰기를 같이 한다”고 보시면 맞습니다.


🗺 지도 위 현재 위치

뉴스레터 CTA

이렇게 구조 차이를 한 번에 잡게 풀어내는 기술 해설을 매주 월요일 아침 메일로 보냅니다. 받아보고 싶으면 뉴스레터 회원가입(무료·30초)에서 신청하세요.

📍 시리즈 위치
AI 공부 지도 · 3/20편

Encoder/Decoder 구분 위치에 있는 편입니다. 앞뒤 편 링크는 본문 하단 지도 위 현재 위치 박스에서 확인하세요.

💡 이 편의 한 줄 요약

왜 ChatGPT·Claude·Gemini가 decoder-only 구조로 모였는지, BERT·T5는 왜 다른지를 번역기 비유로 풀어낸다.

소스 리스트


著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.

바이브코딩 태일러
바이브코딩 태일러
AI의 작동 원리와 비즈니스 적용을 일본어·한국어로 기록합니다. 매주 월요일 뉴스레터 발행 중.
뉴스레터 구독하기 →
JAKO