트랜스포머 직관 — attention이 LLM의 핵심이 된 이유

"트랜스포머가 LLM의 핵심이다." 이 한 줄은 모든 AI 글에서 반복되지만, 정확히 뭐냐고 물으면 답하기 어렵습니다. 마케터가 트랜스포머의 수학을 다 알 필요는 없지만, 단 한 가지 직관 — "어느 단어가 어느 단어를 보고 있나" — 만 잡으면 LLM이 왜 길게 풀어 답하고, 왜 가끔 환각을 일으키고, 왜 컨텍스트 길이가 중요한지가 보입니다. 수식을 거의 안 쓰고 풀어가는 트랜스포머 입문.

마케터가 이 글을 읽어야 하는 이유: RAG·프롬프트 설계·LLM 비용 계획까지 트랜스포머의 한 가지 성질("길이 제곱 비용")에서 대부분의 운영 결정이 나옵니다. 이 직관을 모르면 "왜 프롬프트를 짧게 해야 하나", "왜 컨텍스트 순서가 중요하나"에서 매번 직관이 막힙니다.

1. 트랜스포머의 한 줄 직관

트랜스포머의 핵심 아이디어는 한 줄로:

문장 안의 모든 단어가 모든 단어를 동시에 본다 (self-attention).

이전의 RNN·LSTM은 단어를 하나씩 차례로 읽었습니다 — 마치 사람이 한 글자씩 따라 읽는 것처럼. 트랜스포머는 다릅니다 — 모든 단어가 한 번에 다른 모든 단어와 관계를 형성.

그 결과:

• 멀리 떨어진 단어 간 관계 파악 (장거리 의존성)
• 병렬 처리 가능 (GPU에 친화적)
• 문장 구조의 풍부한 표현

이 한 가지 변화가 NLP를 통째로 바꿨고, ChatGPT·GPT-4·Claude·Gemini가 가능하게 됐습니다.

*모든 단어가 모든 단어와 attention 관계를 형성한다. *

📌 이 글에서 다루는 것

이 글은 트랜스포머의 수학(matrix multiplication·softmax·positional encoding)을 다루지 않습니다. 마케터·운영자가 LLM의 강점·약점을 직관적으로 이해하기 위한 한 가지 핵심 — attention의 의미 — 에만 집중. 수학적 디테일은 Vaswani et al. 2017 원전 참조.

2. Attention의 의미 — "이 단어를 이해할 때 어떤 단어를 봐야 하나"

문장: "광고 카피가 인상적이라 클릭률이 좋았다."

이 문장에서 "좋았다"의 의미를 이해하려면 어떤 단어를 봐야 하나?

• "클릭률" — 강하게 봄 (좋았다의 주어)
• "인상적" — 약하게 봄 (관련 맥락)
• "광고", "카피" — 더 약하게 봄 (배경)
• "이라" — 거의 안 봄 (조사)

이 "어느 단어를 얼마나 보나"의 가중치가 attention입니다. 사람의 독해와 비슷:

한 단어를 이해할 때 문장의 다른 단어들을 가중치를 두고 본다.

Attention의 가중치는 학습된 패턴에 따라 자동 결정. 모델은 수억 개 텍스트로부터 "어떤 단어가 어떤 단어를 봐야 의미가 잘 잡히는지" 학습.

3. Attention 점수 — 수식 한 줄로 보기

Attention이 어떻게 작동하는지 핵심 수식은 다음 한 줄입니다.

즉, "Q(질문 벡터)와 K(키 벡터)의 내적으로 관련도를 계산하고, $\sqrt{d_k}$ 로 나눠 안정화한 뒤, 그 가중치로 V(값 벡터)를 섞는다."

마케터 언어로 풀면: 각 단어가 "나와 가장 관계 깊은 단어는 누구?"를 물어보고, 관계 깊은 단어의 정보를 더 많이 가져오는 구조. $\sqrt{d_k}$ 로 나누는 이유는 벡터 차원이 커질수록 내적값이 커져서 softmax가 한쪽으로 쏠리는 현상을 막기 위해서입니다. 실용적 의미: 차원이 클수록 나누는 수가 커지고, 가중치 분배가 더 고른 비율로 유지.

📌 수식을 외울 필요는 없습니다

이 수식에서 마케터가 가져갈 것은 단 하나 — Q·K·V 세 행렬이 모두 토큰 수에 비례해 커진다는 것. 토큰 수가 2배면 행렬 곱(QK^T) 연산량은 4배. 이게 "컨텍스트 길이 제곱 비용"의 수학적 근거입니다.

4. Multi-head attention — 여러 관점으로 동시에

실제 트랜스포머는 한 번에 한 attention만 하는 게 아닙니다. 여러 attention "head"를 동시에 굴려, 각자 다른 관점으로 단어를 봅니다.

문장 "광고 카피가 인상적이라 클릭률이 좋았다"의 multi-head attention:

• Head 1 — 문법 관계 (주어·동사·목적어)
• Head 2 — 의미 관계 (광고·카피의 도메인 연결)
• Head 3 — 감정 톤 (인상적·좋았다의 긍정성)
• Head 4 — 인과 관계 (인상적이라 → 좋았다)
• ... (보통 12~32개 head)

각 head가 다른 측면을 보고, 마지막에 결과를 결합. 사람의 독해도 비슷 — 같은 문장을 문법·의미·톤·맥락 여러 측면으로 동시에 처리.

Multi-head가 실제 운영에서 의미하는 것: 모델이 같은 프롬프트를 동시에 "지시어 파악", "톤 체크", "컨텍스트 연결" 여러 각도로 읽고 있다는 뜻입니다. 프롬프트 한 줄을 바꿔도 여러 head 중 일부만 영향을 받아, 전체 출력이 예측하기 어렵게 달라지는 이유가 여기에 있습니다. 프롬프트 엔지니어링이 과학보다 실험에 가까운 이유 중 하나입니다.

멀티헤드 직관 한 줄: 헤드 수가 많을수록 모델이 더 많은 "독해 관점"을 동시에 가진다. GPT-4 같은 대형 모델이 뉘앙스를 더 잘 잡는 이유 중 하나.

5. 왜 attention이 마케팅 자리에 중요한가

Attention의 직관이 마케팅·운영 의사결정에 들어오는 자리:

5-1. 컨텍스트 길이의 의미

LLM의 "128k 토큰 컨텍스트"가 의미하는 것 — 128,000개 단어가 서로 attention할 수 있다. 더 긴 컨텍스트 = 더 많은 정보를 동시에 참조 = 더 풍부한 답.

하지만 attention 계산 비용은 컨텍스트 길이의 제곱. 컨텍스트 2배면 비용 4배. RAG에서 컨텍스트 다이어트가 중요한 이유.

5-2. Lost-in-the-middle 현상

100,000 토큰의 긴 컨텍스트에서 모델은 처음·끝의 토큰을 더 잘 봅니다. 중간 토큰의 정보는 어느 정도 손실됨.

운영적 의미:

• 중요한 정보(핵심 지시·핵심 데이터)는 컨텍스트의 처음·끝
• 보조 컨텍스트는 중간

5-3. 환각의 한 원인

모델이 답을 만들 때 attention이 잘못된 토큰을 강하게 보면 잘못된 답. 학습 시점에 비슷한 패턴을 본 적이 없으면 attention이 일관성 없이 흔들리고 환각이 일어남.

6. 트랜스포머의 핵심 메커니즘 한 묶음

수식 없이 한 묶음으로 정리:

1. 입력 토큰 — 텍스트가 토큰으로 잘림 (LLM 기초)
2. 임베딩 — 각 토큰이 벡터로 (임베딩 기초)
3. Self-attention — 모든 토큰이 모든 토큰을 가중치로 봄
4. Multi-head — 여러 관점 동시에
5. Feedforward — 각 토큰의 표현을 비선형 변환으로 정제
6. 층 반복 — 위 흐름을 12~96층 쌓음
7. 출력 — 마지막 층의 표현으로 다음 토큰 확률 계산

각 층마다 attention이 다른 패턴을 학습. 첫 층은 단순 패턴(인접 단어), 깊은 층은 추상적 관계(주제·감정·논리).

# 의사 코드 — 트랜스포머 층의 핵심
def transformer_layer(tokens):
    attended = multi_head_attention(tokens)  # 모든 토큰이 모든 토큰 봄
    refined = feedforward(attended)           # 비선형 변환
    return refined + tokens                    # residual connection

이게 본문에 박는 유일한 코드입니다. 12~96층이 이 흐름을 반복. 운영자가 직접 만질 일 없지만 LLM이 무엇을 하는지의 직관.

7. 마케팅 운영의 의사결정 적용

LLM을 쓰면서 보이는 흔적들이 트랜스포머의 성질에서 옵니다. 이 직관이 있으면 운영 의사결정이 명확해집니다.

같은 단어의 다른 의미: "광고 카피"의 "카피"와 "프로젝트 카피"의 "카피"가 다른 의미. LLM은 둘을 구분합니다 — attention이 주변 단어("광고" vs "프로젝트")를 보고 같은 토큰의 의미를 다르게 처리하기 때문. 이것이 LLM이 단순 키워드 매칭이 아닌 문맥 이해를 하는 이유입니다.

긴 문서 요약 능력: 페이지 단위 문서 요약이 가능한 이유 — attention이 장거리 단어 관계를 잡아냄. RNN 시대는 어려웠던 자리. 하지만 컨텍스트 길이 제한(128k, 200k 토큰)이 여전히 존재하므로, 매우 긴 문서는 청크 단위로 요약 후 합치는 전략이 필요합니다.

실패 모드의 패턴: LLM이 환각을 일으키는 자리는 보통 attention이 약하게 흔들리는 자리. 컨텍스트 일관성·정확도가 떨어지는 토큰 위에 attention이 잘못 모입니다. 특히 학습 데이터에서 보기 드문 조합(신규 브랜드명 + 특정 숫자 조합)에서 환각 빈도가 높아지는 이유가 여기에 있어요.

7-1. RAG 컨텍스트 설계

검색된 문서를 LLM에 줄 때 — 가장 관련 있는 chunk를 처음·끝에 배치. 중간은 보조 정보. lost-in-the-middle 함정 회피.

실무 케이스: 마케팅 FAQ 챗봇에서 5개 chunk를 넘기던 팀이 핵심 chunk 3개로 줄이고, 가장 높은 relevance chunk를 맨 앞에 배치했더니 Faithfulness 지표가 0.81 → 0.93으로 올랐습니다. 컨텍스트 길이를 줄이고 순서를 바꾸는 것만으로 — 모델 교체 없이 — 품질이 달라진 사례입니다. Attention이 처음·끝을 강하게 보기 때문입니다.

7-2. 프롬프트 길이 다이어트

모든 컨텍스트를 다 넣지 말고 정말 필요한 정보만. attention 계산이 길이 제곱이라 비용·latency 폭발. 예시: 컨텍스트 8,000토큰 → 4,000토큰으로 줄이면 attention 연산량은 절반이 아니라 4분의 1 수준. 비용도, 응답 속도도 동시에 개선됩니다. RAG 비용·latency 참조.

7-3. 프롬프트 구조

핵심 지시는 시스템 프롬프트의 시작 또는 사용자 메시지의 끝 — attention이 강하게 보는 자리. 보조 정보는 중간.

정리하면:

• 시스템 프롬프트 첫 줄: 역할·톤 지정 (모델이 가장 강하게 참조)
• 사용자 메시지 끝 줄: 핵심 지시·출력 형식 (마지막 토큰 쪽은 next-token 예측에 가장 근접)
• 중간: few-shot 예시, 배경 문서, 보조 컨텍스트

{/* TODO_HUNY: huny가 운영 중인 LLM 자리에서 컨텍스트 위치 변경으로 결과가 달라진 경험 한 가지 추가해주세요. RAG·시스템 프롬프트·few-shot 예시 위치 등. */}

8. 마치며 — attention의 한 줄을 잡고 가기

마케터가 트랜스포머를 깊이 알 필요는 없습니다. 단 한 가지 직관 — "모든 단어가 모든 단어를 가중치로 본다" — 만 잡고 있으면 LLM의 강점·약점·운영 결정이 자연스럽게 보입니다.

길어질수록 비용 제곱, 가까운 토큰에 강하게, 처음·끝이 중간보다 잘 보임. 이 세 가지가 attention의 운영적 결과.

트랜스포머 아키텍처가 등장한 2017년 이후 GPT-1·BERT·GPT-3·ChatGPT·Claude 모두 같은 self-attention 원리 위에 쌓였습니다. 파라미터 수(10억 → 1조+)와 학습 데이터 규모가 달라진 것이지, 핵심 메커니즘은 동일합니다. 지금 이 글에서 잡은 직관은 앞으로 나올 어떤 LLM 뉴스를 읽어도 유효합니다.

마지막으로 정리 한 줄씩:

attention의 직관이 잡혀 있으면 huny.log의 다음 글들이 다르게 읽힙니다.

• LLM 기초 — 토큰 단위 예측과 attention이 어떻게 연결되는지
• 임베딩 기초 — 각 토큰을 벡터로 만드는 단계 (attention 이전)
• RAG 비용·latency — 컨텍스트 길이 제곱 비용의 실제 숫자
• LLM-as-judge — 평가자도 결국 attention으로 판단한다

참고

• Vaswani et al. (2017), Attention Is All You Need, NeurIPS — 트랜스포머 원전
• Alammar, The Illustrated Transformer — 시각화로 풀어가는 입문 표준
• Karpathy, Let's build GPT — from scratch — 코드로 따라 만드는 영상
• Liu et al. (2023), Lost in the Middle — 긴 컨텍스트의 함정
• Anthropic, Mapping the Mind of a Large Language Model (2024) — attention과 모델 해석
• huny.log 내부 글: LLM 기초, 임베딩 기초, RAG 비용·latency, LLM-as-judge