본문 바로가기
AI

LLM이란? 원리부터 핵심 개념까지 — AI 시대 이해하기 (1편)

서혈 2026. 2. 21. 18:31

개요

요즘 AI를 활용하는 사례가 부쩍 늘었고, 일상 곳곳에 들어와 있다는 게 체감됩니다. 지엽적으로 저의 삶을 보면, 현업에서 개발자로 일하면서 AI 없이 개발하는 게 이제는 상상하기 어려울 정도로 개발의 패러다임이 바뀌었다고 느끼고 있습니다. 코드를 작성할 때, 트러블슈팅을 할 때, 문서를 정리할 때 — AI 도구를 쓰지 않는 날이 없습니다.

 

그러다 보니 자연스럽게 궁금해진 것들이 있습니다. 매일 쓰는 이 AI라는 것이 정확히 어떤 원리로 동작하는지, 요즘 많이 쓰이는 GPT, Claude, Gemini 같은 모델들은 구체적으로 뭐가 다른지, 그리고 이 흐름 속에서 개발자로서 어떤 방향으로 역량을 키워야 하는지. 도구를 쓰기만 하는 것과 원리를 이해하고 쓰는 것 사이에는 분명한 차이가 있다고 생각합니다.

 

이 글은 그런 궁금증을 하나씩 파고들면서 정리한 기록입니다. LLM이 무엇인지, 어떤 원리로 동작하는지를 중심으로 정리하고, 실무에서 GPT와 Claude를 주로 쓰면서 느낀 점과 상황별로 어떤 모델이 맞는지도 다뤄보겠습니다.

이 글은 앞으로 이어질 시리즈의 첫 번째 글이기도 합니다.

 

시리즈 로드맵:

  1. [이 글] LLM이란? 원리부터 핵심 개념까지 — LLM 기초, 주요 모델 비교
  2. Claude Code 실전 가이드 — 설치부터 활용, CLAUDE.md 작성법
  3. MCP 딥다이브 — AI와 외부 도구를 연결하는 오픈 표준
  4. Skills & Hooks — AI 코딩 도구를 나만의 워크플로우로
  5. Agent Teams — 다중 AI 인스턴스 협업

개발자로서 앞으로 AI와 함께 변화해 가는 과정 속에, 실무와 지식을 기반으로 정리한 내용이 저처럼 공부하고 정리하는 분들에게도 도움이 되었으면 합니다.

LLM이란?

한 줄 정의

LLM(Large Language Model, 대규모 언어 모델)을 한 문장으로 정의하면 하단과 같습니다.

LLM = 대규모 텍스트 데이터로 학습한 신경망이, 다음에 올 토큰을 예측하는 방식으로 동작하는 언어 모델

 

이 정의에는 세 가지 핵심 개념이 들어 있습니다. 각각을 풀어보겠습니다.

신경망(Neural Network)이란?

생물학적 뇌의 뉴런 구조에서 착안한 이름입니다.

[생물학적 뉴런]
여러 입력 신호 → 세포체에서 합산 → 역치 초과 시 다음 뉴런으로 신호 전달

[인공 뉴런 (노드)]
여러 입력 숫자 → 가중치를 곱해서 합산 → 활성화 함수 통과 → 출력

 

이 인공 뉴런을 수천~수십억 개 연결한 것이 신경망입니다. "신경"이라는 이름이 붙었을 뿐, 실제로는 행렬 연산의 거대한 체인이고, 뇌를 시뮬레이션하는 것이 아니라 뇌의 연결 구조를 수학적으로 모방한 계산 모델입니다.

 

핵심은 가중치(weight)입니다. 가중치란, 뉴런과 뉴런 사이의 연결에 붙어 있는 숫자로, "이 입력을 얼마나 중요하게 볼 것인가"를 결정합니다.

예: 간단한 감정 분석 뉴런

입력1: "좋다" → 가중치 0.8   (긍정 신호 강하게 반영)
입력2: "않다" → 가중치 -0.9  (부정 신호 강하게 반영)
입력3: "매우" → 가중치 0.3   (강도 신호 약하게 반영)

합산: (1 × 0.8) + (1 × -0.9) + (1 × 0.3) = 0.2
→ 활성화 함수 통과 → 출력

 

해석: 가중치가 크면 해당 입력의 영향력이 커지고, 0에 가까우면 무시되며, 음수면 반대 방향으로 작용합니다. "좋다"에 긍정 가중치가, "않다"에 부정 가중치가 붙어 있기 때문에, 모델은 "좋지 않다"를 부정으로 판단할 수 있게 됩니다.

 

그런데 이 가중치는 처음부터 이렇게 잘 맞춰져 있지 않습니다. 학습이란 결국 이 가중치를 조정하는 과정입니다.

 

"좋지 않다" → 정답: 부정

[1회차] 가중치가 무작위 상태
  "좋다" × 0.2  = 0.2
  "않다" × 0.1  = 0.1
  합산 = 0.3 → "긍정" 판단  ❌ 틀림
  → 오차 계산 → "않다"의 가중치를 낮추는 방향으로 수정

[100회차] 가중치가 조금 조정됨
  "좋다" × 0.5  = 0.5
  "않다" × -0.3 = -0.3
  합산 = 0.2 → "약한 긍정" 판단  ❌ 여전히 틀림
  → 오차 계산 → 계속 수정

[10000회차] 가중치가 충분히 조정됨
  "좋다" × 0.8  = 0.8
  "않다" × -0.9 = -0.9
  합산 = -0.1 → "부정" 판단  ✅ 정답

 

이 과정을 수조 번, 수조 개의 문장으로 반복하면 가중치들이 점점 "맞는 답을 내는 조합"으로 맞춰지게 됩니다.

 

비유하자면, 처음 보는 요리를 만들 때 소금을 넣고 맛을 보고, 너무 짜면 다음엔 줄이고, 싱거우면 늘리는 것과 같습니다. 한 번에 정답을 찾는 게 아니라, 맛을 보고 조절하는 과정을 반복해서 "적절한 양"에 도달하는 것입니다. 

다만 LLM은 이 "양념"이 수천억 개이고, "맛보기"를 수조 번 합니다.

 

결국 가중치의 조합이 곧 모델이 "아는 것" 전부입니다. GPT와 Claude가 같은 질문에 다른 답을 하는 이유도, 서로 다른 데이터로 서로 다른 방식으로 가중치를 조정했기 때문입니다. 모델을 저장한다는 건 이 가중치 숫자들을 파일로 저장한다는 뜻이고, 모델 파일이 수십~수백 GB인 이유도 이 가중치의 양 때문입니다.

토큰(Token)이란?

컴퓨터는 "단어"를 직접 이해하지 못합니다. 텍스트를 처리 가능한 최소 단위로 쪼개야 하는데, 그 단위가 토큰입니다.

"이해할 수 없습니다" → ["이해", "할", " 수", " 없", "습니다"]
"unhappiness"       → ["un", "happi", "ness"]

 

단어 단위도 아니고 글자 단위도 아닌 이유가 있습니다.

방식 문제점
글자 단위 "안녕하세요" → 5개. 너무 잘게 쪼개져서 의미 파악이 어려움
단어 단위 세상의 모든 단어를 사전에 담을 수 없음 (신조어, 오타, 다국어)
토큰 (서브워드) 자주 쓰는 조각은 통째로, 드문 단어는 쪼개서 처리하는 균형점

 

토큰은 BPE(Byte Pair Encoding) 같은 알고리즘으로 자동 결정됩니다. "자주 같이 등장하는 글자 조합"을 하나의 토큰으로 묶는 방식이라, 토큰은 단어일 수도, 단어의 일부일 수도, 공백이나 구두점일 수도 있습니다.

참고로 영어는 대략 1토큰 ≈ 단어의 3/4 수준이고, 한국어는 같은 의미를 표현하는 데 더 많은 토큰을 소모합니다.

언어 모델(Language Model)이란?

"모델"이란 현실의 무언가를 수학적으로 근사한 것입니다. 날씨 모델이 대기 현상을 수학으로 근사하듯, 언어 모델은 언어의 패턴을 확률로 근사합니다.

 

구체적으로, 언어 모델은 이런 질문에 답합니다:

"오늘 날씨가 정말 ___"

→ "좋다"   확률 35%
→ "덥다"   확률 20%
→ "춥다"   확률 15%
→ "이상하다" 확률 5%
→ ...

 

앞의 맥락이 주어졌을 때, 다음에 올 토큰의 확률 분포를 출력하는 것. 이것이 언어 모델의 본질입니다.

 

문장 생성은 이 과정의 반복입니다:

입력: "오늘 날씨가"
→ "정말" 선택 (확률 기반)
→ "좋네요" 선택
→ "." 선택
→ [종료 토큰] 선택
결과: "오늘 날씨가 정말 좋네요."

 

한 번에 문장을 만드는 것이 아니라, 토큰 하나씩 순차적으로 예측을 반복합니다. 이것을 autoregressive(자기 회귀) 생성이라고 합니다.

다시 읽는 정의

LLM = 대규모 텍스트 데이터로 학습한 신경망(가중치 수십억 개의 행렬 연산 체인)이, 다음에 올 토큰(서브워드 단위)을 예측하는 방식으로 동작하는 언어 모델(텍스트의 확률 분포를 근사하는 수학적 모델)

 

처음 정의를 봤을 때보다 각 단어가 구체적으로 무엇을 의미하는지 좀 더 잡히는 느낌이 있지 않을까 생각합니다.

LLM 이전의 언어 모델 — 무엇이 한계였는가?

LLM이 등장하기 전에도 언어 모델은 존재했습니다. 대표적으로 RNN(Recurrent Neural Network, 순환 신경망) 기반의 모델들이 텍스트를 처리했는데, 이 모델들은 엄밀히 말하면 "LM(Language Model)"이지 "LLM"은 아니었습니다.

 

파라미터 수가 수백만 수천만 수준으로 지금의 LLM(수십억*수조)과는 규모 자체가 달랐습니다.

 

RNN의 동작 방식은 직관적입니다. 문장을 왼쪽에서 오른쪽으로, 단어를 하나씩 순서대로 읽어나갑니다. 그런데 이 구조에는 두 가지 근본적인 문제가 있었습니다.

 

1) 장거리 의존성 문제

 

"어제 배포한 서버가 오늘 새벽 3시에 갑자기 죽었다"라는 문장에서, "죽었다"가 "서버"를 가리킨다는 것을 이해하려면 문장의 앞부분 정보를 끝까지 기억해야 합니다. RNN은 단어를 순서대로 처리하다 보니, 문장이 길어질수록 앞부분의 정보가 희미해지는 현상(Vanishing Gradient, 기울기 소실)이 발생했습니다. LSTM(Long Short-Term Memory)이라는 개선된 구조가 나오긴 했지만, 근본적인 한계는 여전했습니다.

 

2) 병렬 처리 불가

 

단어를 "순서대로" 처리하기 때문에, 이전 단어의 처리가 끝나야 다음 단어를 처리할 수 있었습니다. GPU가 아무리 많아도 순차 처리라는 구조적 병목이 있어서, 모델을 크게 키우는 데 한계가 있었습니다.

RNN, LSTM, Transformer는 AI 발전 과정에서 핵심적인 아키텍처들이라, 한 번씩 별도로 찾아보시는 것을 권장드리며 후에 기회가 되면 별도로 정리해 보겠습니다.

Transformer — 모든 현대 LLM의 뼈대

2017년 Google이 발표한 "Attention Is All You Need" 논문에서 Transformer 아키텍처가 등장하면서, RNN의 두 가지 한계를 모두 해결했습니다.

 

핵심 아이디어는 단순합니다. "순서대로 읽지 말고, 모든 단어가 다른 모든 단어를 동시에 바라보게 하자."


이 메커니즘을 Self-Attention이라고 합니다.

Self-Attention의 핵심 개념

Self-Attention을 이해하려면 먼저, 모델 내부에서 단어가 어떻게 표현되는지를 짚어야 합니다. 모델은 텍스트를 직접 이해하지 못하기 때문에, 각 토큰을 숫자의 나열로 변환해서 처리합니다. 이 숫자의 나열을 벡터(vector)라고 합니다.

"서버" → [0.82, -0.15, 0.43, 0.67, ...]   (수백~수천 개의 숫자)
"배포" → [0.71, 0.28, -0.33, 0.51, ...]

 

수학에서 벡터는 크기와 방향을 가진 양이지만, 여기서는 "의미를 숫자로 인코딩한 것"이라고 이해하면 됩니다. 의미가 비슷한 단어들은 벡터 값도 비슷해지도록 학습됩니다.

 

Self-Attention에서 각 토큰은 자신의 벡터로부터 3개의 벡터를 생성합니다.

- Query (Q): "나는 어떤 정보가 필요한가?"  — 질문 역할
- Key (K):   "나는 어떤 정보를 갖고 있는가?" — 라벨 역할
- Value (V): "내가 전달할 실제 정보"        — 내용 역할

비유하면 이렇습니다. 도서관에서 책을 찾는 상황을 생각해 보겠습니다.

  • Query: 내가 찾고 싶은 주제 (검색어)
  • Key: 각 책에 붙어 있는 태그 (제목, 카테고리)
  • Value: 책의 실제 내용

검색어(Q)와 태그(K)가 얼마나 일치하는지를 계산하고, 일치도가 높은 책의 내용(V)을 가져오는 구조입니다. 이걸 모든 토큰이 동시에, 다른 모든 토큰을 대상으로 수행합니다.

 

수식으로 표현하면:

Attention(Q, K, V) = softmax(QK^T / √d_k) × V

 

수식에 대한 자세한 설명은 뒤로하고 이 경우에 예시를 들어서 설명을 더하자면 "어제 배포한 서버가 오늘 새벽 3시에 갑자기 죽었다"에서 "죽었다"의 Query가 "서버"의 Key와 높은 점수를 받으면, "죽었다"는 "서버"의 정보를 강하게 참조하게 됩니다.

RNN처럼 순서대로 읽지 않기 때문에, 문장 내 거리와 상관없이 관련 있는 단어끼리 직접 연결됩니다.

 

Multi-Head Attention — 여러 관점에서 동시에 바라보기

Self-Attention 하나만으로는 단어 간의 관계를 한 가지 관점에서만 봅니다. 하지만 언어에서 단어의 관계는 다층적입니다.

"서버가 죽었다"에서:

  • 구문적 관계: "죽었다"의 주어는 "서버"
  • 의미적 관계: "죽었다"는 장애/중단을 의미
  • 맥락적 관계: "어제 배포한"이 원인일 수 있음

Multi-Head Attention은 이런 서로 다른 관점을 각각의 "Head"가 담당하게 합니다. Head가 8개라면, 8개의 서로 다른 Q, K, V 세트가 병렬로 Attention을 수행하고, 결과를 합칩니다.

Multi-Head Attention = Head₁ ⊕ Head₂ ⊕ ... ⊕ Head₈
  → Head₁: 구문 관계 포착
  → Head₂: 의미 관계 포착
  → Head₃: 위치/거리 관계 포착
  → ...

 

해석: 각 Head가 어떤 관계를 학습할지는 사람이 정하는 게 아니라, 학습 과정에서 자동으로 분화됩니다. 결과적으로 모델은 하나의 문장을 여러 각도에서 동시에 분석할 수 있게 됩니다.

 

이것이 Transformer가 RNN을 대체한 이유입니다. 순차 처리 없이 모든 단어를 동시에, 여러 관점에서 바라볼 수 있으니 병렬 처리가 가능해졌고, 모델을 수십억 파라미터 이상으로 키울 수 있는 기반이 마련된 것입니다. 그리고 이 규모가 커지면서 "Language Model"이 "Large Language Model"이 되었습니다.

학습 파이프라인 — Base Model에서 어시스턴트까지

LLM이 "도움이 되는 어시스턴트"가 되기까지는 크게 3단계를 거칩니다.

[1단계] Pre-training (사전학습)
  인터넷 텍스트 수조 토큰 → "다음 토큰 예측" 반복 (자기지도학습)
  → 비용: 수백만~수억 달러, 수천 GPU, 수개월
  → 결과: 언어 패턴, 지식, 추론 능력을 학습한 Base Model
  → 이 상태에서는 질문에 "대답"하지 않음. 그냥 다음 토큰을 이어붙일 뿐.

[2단계] SFT (Supervised Fine-Tuning, 지도 미세조정)
  인간이 작성한 이상적인 질문-응답 쌍으로 미세조정
  → "이런 질문에는 이렇게 대답해야 해"를 학습
  → Base Model이 "대화"를 할 줄 아는 모델로 전환

[3단계] 강화학습 기반 정렬
  → 모델의 출력을 "더 좋은 답 vs 덜 좋은 답"으로 평가해서 강화학습
  → 이 단계에서 OpenAI, Anthropic, Google의 접근이 갈림 (하단 비교표 참조)
  → 결과: "도움이 되고, 무해하고, 정직한" 어시스턴트

 

해석: 1단계에서 "언어를 이해하는 뇌"를 만들고, 2단계에서 "대화하는 법"을 가르치고, 3단계에서 "좋은 대화 vs 나쁜 대화"를 구분하게 합니다.

3단계 강화학습 — 세 회사의 접근이 다르다

구분 OpenAI (RLHF) Anthropic (RLAIF / Constitutional AI) Google (RL*F)
피드백 주체 인간 라벨러 AI (헌법 기반 자기평가) 인간 + AI Critic 혼합
보상 신호 Reward Model (인간 선호도 학습) AI 피드백 (헌법 원칙 기준) DRM + Critic 두 가지 조합
특징 인간 선호도를 직접 반영 확장성↑, 인간 개입↓ 두 방식의 절충·혼합
안전성 보완 Red Teaming Constitutional AI CAI 영감 + Red Team

 

조금 더 구체적으로 파고들자면:

 

OpenAI — RLHF (Reinforcement Learning from Human Feedback)


인간 평가자가 모델의 여러 출력을 직접 비교하고 순위를 매깁니다. 이 데이터로 Reward Model을 학습시키고, 그 Reward Model의 점수를 기준으로 강화학습을 수행합니다. 가장 직관적인 방식이지만, 대규모 인간 라벨링에 비용이 많이 듭니다.

 

Anthropic — RLAIF / Constitutional AI


Anthropic이 정의한 원칙 목록(Constitution)에 따라 AI가 스스로 출력을 평가하고 수정한 뒤, 그 AI 피드백으로 강화학습을 수행합니다. 여기서 "헌법(Constitution)"은 프롬프트도 아니고 코드 규칙도 아닙니다. 모델이 자기 출력을 평가할 때 참조하는 윤리적·행동적 원칙의 목록입니다. "유해한 요청에는 거절해야 한다", "확실하지 않은 정보는 모른다고 해야 한다" 같은 원칙들이 포함됩니다. 국가의 헌법이 법률의 상위 기준이 되는 것처럼, 이 원칙 목록이 모델 행동의 최상위 기준이 되기 때문에 "헌법"이라는 이름이 붙었습니다.

 

Google — RL*F (Reinforcement Learning from Human and Critic Feedback)


Gemini 2.5 기술 보고서에서 공식 명명된 방식입니다. 인간이 복수 응답을 비교·평가한 선호도 데이터를 학습한 DRM(Data Reward Model)과, 사전 정의된 루브릭(rubric, 채점 기준표)에 따라 응답을 채점하는 AI Critic을 조합합니다. Anthropic의 Constitutional AI에서 영감을 받았다고 보고서에 명시되어 있으나, 헌법 원칙 대신 루브릭 기반 AI 채점을 사용한다는 점이 다릅니다. RLHF(순수 인간 피드백)와 RLAIF(순수 AI 피드백)의 중간 전략으로 볼 수 있습니다.

왜 이걸 알아야 하는가?

LLM의 동작 원리를 모르고 쓰는 것과 아는 것의 차이는 실무에서 드러납니다. 원리를 모르면 AI의 출력을 "맞다/틀리다"로만 판단하게 되고, 왜 틀렸는지, 어떻게 하면 더 나은 답을 얻을 수 있는지를 구조적으로 접근할 수 없습니다.

  • "다음 토큰 예측"을 이해하면: 왜 LLM이 가끔 그럴듯하지만 틀린 말을 하는지(환각) 납득이 됩니다. 정답을 "알고" 말하는 게 아니라, 확률적으로 가장 그럴듯한 토큰을 이어 붙이는 것이기 때문입니다. 이걸 모르면 "AI가 거짓말을 한다"라고 느끼고, 알면 "구조적으로 그럴 수 있다"라고 대응 방식이 달라집니다.
  • 학습 파이프라인을 이해하면: 왜 시스템 프롬프트가 중요한지, 왜 모델마다 성격이 다른지가 설명됩니다. GPT와 Claude가 같은 질문에 다른 답을 하는 게 "어느 쪽이 맞다"의 문제가 아니라, 3단계 정렬 방식이 다르기 때문이라는 것을 이해하게 됩니다.
  • Attention 메커니즘을 이해하면: 왜 컨텍스트 윈도에 제한이 있는지, 왜 긴 문서에서 중간 부분을 놓치는 경향이 있는지를 이해할 수 있습니다. 이걸 모르면 "AI가 멍청해서 까먹는다"라고 생각하고, 알면 "입력을 어떻게 구성해야 효과적인지"를 고민하게 됩니다.

LLM의 핵심 개념

이전 챕터에서 LLM의 정의와 동작 원리를 정리했습니다. 이번 챕터에서는 LLM을 실제로 사용하거나 학습하면서 자주 마주치는 개념들을 하나씩 정리해 보겠습니다.

컨텍스트 윈도우(Context Window)

LLM에게 질문을 하면, 모델은 시스템 프롬프트 + 이전 대화 + 현재 질문을 한꺼번에 받아서 처리합니다. 이 전체 입력이 들어갈 수 있는 공간이 컨텍스트 윈도우입니다. 모델의 "작업 메모리"라고 이해하면 됩니다.

[시스템 프롬프트] + [이전 대화 기록] + [현재 질문] + [참고 문서]
← ──────────── 컨텍스트 윈도우 ──────────── →

 

2026년 2월 기준 주요 모델의 컨텍스트 윈도우:

모델 컨텍스트 윈도우
GPT-4o 128K 토큰
Claude Opus 4.6 200K (1M beta)
Gemini 2.0 1M ~ 2M 토큰

 

128K 토큰이면 대략 책 한 권 분량이고, 1M 토큰이면 책 7~8권 분량입니다.

 

컨텍스트 윈도우에서 주의할 점이 있습니다. 긴 컨텍스트 ≠ 완벽한 기억입니다. "Needle in a Haystack" 문제라고 불리는 현상인데, 컨텍스트가 길어질수록 중간에 있는 정보를 놓치는 경향이 있습니다. 앞부분과 끝부분은 잘 잡는데, 중간이 희미해지는 현상입니다.

 

이건 Attention 메커니즘이 모든 토큰 간의 관계를 계산할 때, 토큰 수가 많아지면 각 토큰에 분배되는 "주의"가 분산되기 때문입니다.

 

실무에서의 의미: 긴 문서를 통째로 넣는 것보다, 관련 부분을 추려서 넣는 게 더 정확한 답을 얻는 경우가 많습니다. 컨텍스트 윈도우가 크다고 무조건 좋은 것이 아니라, 어떻게 채우느냐가 중요합니다.

환각(Hallucination)

LLM을 쓰다 보면, 그럴듯하지만 사실과 다른 내용을 자신 있게 말하는 경우를 만납니다. 이 현상을 환각(Hallucination)이라고 합니다.

 

LLM의 본질은 "다음 토큰 예측"입니다. 정답을 검색해서 가져오는 게 아니라, 확률적으로 가장 자연스러운 토큰을 이어 붙이는 것이기 때문에, 학습 데이터에 없는 내용이나 모호한 영역에서는 "그럴듯하게 지어내는" 일이 발생합니다.

 

환각이 발생하는 주요 원인:

원인 메커니즘 예시
지식 공백 학습 데이터에 정보가 없어도, "모릅니다"보다 "답변 생성"에 가중치가 높아 비슷한 패턴을 조합해서 답을 만들어냄 존재하지 않는 논문 제목, 없는 API 함수 생성
학습 데이터 충돌 상반된 정보가 가중치에 혼재되어, 어느 쪽이 활성화되느냐에 따라 답이 달라지거나 둘을 섞은 답을 생성 같은 질문에 할 때마다 다른 답
과도한 확신 SFT/RLHF 과정에서 "답변 제공"이 높은 보상을 받도록 학습되어, 확신이 낮은 상황에서도 자신 있는 톤으로 생성 "~입니다"라고 단정적으로 틀린 답
지식 컷오프 학습 시점 이후의 사건에 대해 과거 패턴 기반으로 추측하되, 추측임을 밝히지 않음 2026년 사건을 2025년 패턴으로 답함

 

환각을 완화하는 기술적 접근:

  • RAG(Retrieval-Augmented Generation): 외부 문서를 검색해서 콘텍스트에 넣어주는 방식. 모델이 "지어내는" 대신 "근거에 기반해서" 답하게 함. RAG에 대해서는 이후 시리즈에서 별도로 다룰 예정입니다.
  • 프롬프트 지시: "출처를 함께 제시해 줘", "확실하지 않으면 모른다고 해줘" 같은 명시적 지시로 모델의 행동을 제어

환각은 LLM의 구조적 특성이지 버그가 아닙니다. "다음 토큰 예측"이라는 동작 원리를 이해하면, LLM의 출력을 "사실"이 아니라 "확률적으로 그럴듯한 답변"으로 다루게 됩니다. 결국 중요한 정보는 모델의 답을 그대로 신뢰하지 않고 1차 소스로 확인하는 습관이 필요하며, 이건 기술적 해결이라기보다는 LLM을 쓰는 사람의 기본자세에 가깝습니다.

Temperature

Temperature는 LLM이 다음 토큰을 선택할 때, 후보 토큰들의 확률 분포를 조절하는 파라미터입니다. 통계역학의 볼츠만 분포에서 이름을 빌려왔으며, 물리학에서 온도가 높으면 분자 운동이 활발해지듯 Temperature가 높으면 토큰 선택의 무작위성이 커집니다.

"오늘 날씨가 정말 ___"

Temperature 낮음 → "좋다" 95%, "덥다" 3%, ...  → 거의 같은 답만 반복
Temperature 중간 → "좋다" 35%, "덥다" 20%, ... → 자연스럽지만 가끔 엉뚱
Temperature 높음 → "좋다" 22%, "덥다" 18%, ... → 창의적이지만 예측 불가

※ 위 수치는 개념 이해를 위한 가상의 예시이며, 실제 모델의 확률과는 차이가 있습니다.

 

해석: Temperature가 낮으면 확률이 높은 소수의 토큰에 집중되고, 높으면 확률이 낮은 토큰까지 선택될 가능성이 올라갑니다. 코딩이나 사실 확인 같은 작업에서는 낮게, 창작이나 브레인스토밍에서는 높게 설정하는 것이 일반적입니다.

 

Temperature를 낮추면 출력의 분산이 줄어들기 때문에 환각이 줄어드는 방향성은 있지만, 사실성을 보장하지는 않습니다. 확률 1위 토큰이 이미 틀린 정보를 가리키고 있다면 Temperature를 낮춰도 환각은 발생합니다. 환각을 근본적으로 해결하는 도구라기보다는, LLM의 출력 성격을 제어하는 기본 파라미터로 이해하는 게 정확합니다.

 

Temperature는 API를 직접 호출하는 개발자가 설정하는 파라미터이며, ChatGPT나 Claude.ai 같은 웹 UI에서는 내부적으로 고정되어 있어 사용자가 직접 조절할 수 없습니다.

프롬프트(Prompt)

프롬프트는 LLM에게 전달하는 입력 텍스트 전체를 의미합니다. LLM에게 하는 "말"이 곧 프롬프트입니다. ChatGPT나 Claude에 질문을 입력하는 것도 프롬프트이고, API로 모델을 호출할 때 보내는 텍스트도 프롬프트입니다.

 

프롬프트에는 크게 두 가지 층위가 있습니다.

[시스템 프롬프트]     ← 모델의 행동 규칙을 정의 (사용자에게 보이지 않음)
─────────────────
[사용자 프롬프트]     ← 사용자가 실제로 입력하는 질문/지시

시스템 프롬프트(System Prompt)

시스템 프롬프트는 모델이 "어떤 역할을 하고, 어떤 규칙을 따를지"를 정의합니다. 사용자의 질문보다 먼저 컨텍스트 윈도우에 들어가며, 이후 모든 대화에 영향을 미칩니다.

시스템 프롬프트 예시:
"당신은 Kubernetes 전문가입니다. 질문에 대해 실무 중심으로 답하되,
 확실하지 않은 정보는 모른다고 답하세요.
 답변은 한국어로 하고, 코드 예시를 포함해주세요."

 

ChatGPT나 Claude.ai 같은 웹 서비스에서도 시스템 프롬프트가 적용되어 있습니다. 서비스 제공자가 기본으로 설정한 것이 있고, 사용자도 "맞춤 지시(Custom Instructions)"나 대화 설정 등을 통해 "이렇게 답변해 줘"라는 지시를 추가할 수 있습니다. API를 직접 호출하는 개발자는 시스템 프롬프트를 더 자유롭게, 전체를 직접 설계할 수 있습니다.

 

시스템 프롬프트가 중요한 이유는 학습 파이프라인과 연결됩니다. 이전 챕터에서 정리했듯이, 모델은 3단계 학습(Pre-training → SFT → RLHF)을 거쳐 "범용 어시스턴트"가 됩니다. 하지만 범용이기 때문에 모든 질문에 대해 "그럴듯한 범용 답변"을 하려는 경향이 있습니다.

 

시스템 프롬프트는 이 범용 모델에게 "지금 너는 이 역할이고, 이 규칙을 따라야 해"라는 경계를 설정하는 것입니다. 시스템 프롬프트 없이 쓰면 모델의 잠재력을 충분히 활용하지 못하는 셈이고, 이것이 프롬프트 설계가 중요한 이유입니다.

사용자 프롬프트(User Prompt)

사용자가 실제로 입력하는 질문이나 지시입니다. "이 에러 원인이 뭐야?", "이 코드 리뷰해 줘" 같은 것들이 사용자 프롬프트입니다.

두 프롬프트의 시너지

시스템 프롬프트와 사용자 프롬프트는 독립적으로 작동하는 것이 아니라, 함께 모델의 출력을 결정합니다.

사용자 프롬프트: "서버가 자꾸 죽어요"

[시스템 프롬프트 없음]
→ "서버가 죽는 원인은 여러 가지가 있습니다. 메모리 부족, CPU 과부하..."
   (범용적이고 일반적인 답변)

[시스템 프롬프트: "Kubernetes 전문가, 실무 중심 답변"]
→ "Pod가 OOMKilled 되는 경우가 많습니다. kubectl describe pod로
   먼저 확인해보세요. resources.limits 설정을 확인하고..."
   (특정 도메인에 집중된 답변)

[시스템 프롬프트: "초보자에게 설명하듯 쉽게"]
→ "서버가 죽는다는 건, 프로그램이 갑자기 멈췄다는 뜻이에요.
   가장 흔한 이유는 메모리를 너무 많이 써서인데요..."
   (같은 질문인데 답변의 깊이와 방향이 완전히 다름)

 

같은 사용자 질문이라도 시스템 프롬프트가 다르면 답변의 전문성, 깊이, 톤이 달라집니다. 모델을 재학습시키지 않고도 시스템 프롬프트만으로 행동을 크게 바꿀 수 있다는 점이 핵심입니다.

프롬프트와 환각의 관계

앞서 환각을 줄이는 기술적 접근으로 "프롬프트 지시"를 언급했는데, 이것이 구체적으로 어떻게 작동하는지를 보겠습니다.

[환각이 발생하기 쉬운 프롬프트]
시스템: (없음)
사용자: "Kubernetes 1.32의 새로운 기능을 알려줘"
→ 모델이 학습 데이터에 없는 내용을 "그럴듯하게 생성"할 가능성 높음

[환각을 줄이는 프롬프트]
시스템: "확실하지 않은 정보는 '확인이 필요합니다'라고 명시하세요.
        학습 데이터에 없는 최신 정보에 대해서는 추측하지 마세요."
사용자: "Kubernetes 1.32의 새로운 기능을 알려줘"
→ "해당 버전에 대한 정보가 학습 데이터에 포함되어 있지 않을 수 있습니다.
   공식 릴리스 노트를 확인하시는 것을 권장드립니다."

 

시스템 프롬프트에서 "모를 때 모른다고 해라"는 규칙을 명시하면, 앞서 환각 원인 중 "과도한 확신" — 모르는 것도 답하려는 학습된 경향 — 을 억제하는 효과가 있습니다. 근본적으로 환각을 없애는 것은 아니지만, 모델의 행동을 제어하는 가장 직접적인 수단이 프롬프트입니다.

 

시스템 프롬프트를 얼마나 잘 설계하느냐가 LLM의 활용도를 결정한다는 것. 이것이 이후 시리즈에서 다룰 CLAUDE.md,. cursor/rules 같은 파일들의 존재 이유이기도 합니다.

부록: 실무에서 체감한 것들

프롬프트

요즘 개발할 때 Claude Code나 Cursor를 사용하면서, 프롬프트를 어떻게 구성하느냐에 따라 결과물의 질이 눈에 띄게 달라지는 것을 체감하고 있습니다.

 

예를 들어 단순히 "이 코드 리팩터링 해줘"라고 하는 것과, "이 프로젝트는 Kubernetes 환경에서 운영되는 Go 서비스이고, 에러 핸들링을 sentinel error 패턴으로 통일하고 싶다"라고 맥락을 깔아주는 것은 같은 모델이라도 돌아오는 답의 수준이 다릅니다.

 

시스템 프롬프트에 프로젝트의 규칙과 코딩 컨벤션을 넣어두면, 매번 같은 지시를 반복하지 않아도 일관된 결과를 받을 수 있다는 것도 실무에서 직접 느낀 부분입니다.

컨텍스트 윈도우

Claude Code나 Codex를 기반으로 개발할 때, 대화가 길어지면 해당 토큰 양을 넘기게 되어 새로 세션을 만들거나 기존 맥락을 압축해서 진행할 때가 많았습니다.

 

그때는 단순히 "대화가 너무 길어지면 잘린다" 정도로만 이해하고 있었는데, 컨텍스트 윈도우라는 개념과 그 안에서 Attention이 어떻게 분산되는지를 공부하고 나니, 왜 그런 현상이 발생하는지가 명확해졌습니다.

 

그리고 컨텍스트 윈도우 내에만 있으면 AI가 전부 기억하겠지 라는 편견도 깰 수 있었습니다. 토큰 한도 안에 있는데도 중간 내용을 놓치거나 앞에서 했던 지시를 무시하는 경우가 있었는데, 이게 "Needle in a Haystack" 문제 — 컨텍스트가 길어지면 중간 정보에 대한 주의가 분산되는 현상 — 라는 것을 이해하면서 납득이 됐습니다.

 

긴 대화보다 핵심만 추려서 전달하는 게 오히려 더 정확한 결과를 얻는다는 것을, 원리를 통해 확인할 수 있었습니다.

정리/회고

이 글을 정리하면서, LLM까지의 발전 배경과 AI가 답변을 생성해내는 방식(Self-Attention, Multi-Head Attention), 그리고 그 위에 올라가는 학습 파이프라인까지를 공부할 수 있었습니다.

 

실제로 사용하면서 느꼈던 것들 중, 컨텍스트 윈도우라는 것이 무엇인지, 이것이 왜 한계가 존재하는지를 이해할 수 있었습니다. 긴 대화를 하다 보면 중간중간 내용을 제대로 짚지 못하는 경우가 종종 있었는데, Attention 메커니즘에서 토큰 수가 많아지면 "주의"가 분산된다는 원리를 알고 나니 그런 현상이 왜 발생했는지가 납득이 됐습니다.

 

단순히 GPT나 Claude를 사용하다 보면, 환각이 너무 많고 잘못된 대답이 너무 많아서 프롬프트를 조정하기보다 화가 날 때가 솔직히 많았습니다. 그런데 이번에 환각이 LLM의 구조적 특성이라는 것, "다음 토큰 예측"이라는 방식 자체가 사실을 보장하는 구조가 아니라는 것을 이해하고 나니, 화를 내기보다는 이 특성을 어떻게 활용해야 하는지로 관점이 바뀌는 느낌이 있었습니다.

 

프롬프트에 대해서도 시스템 프롬프트와 사용자 프롬프트라는 두 가지 층위가 있다는 것, 그리고 각각의 역할을 공부하면서 기존에 궁금했던 것들이 풀렸습니다. 간혹 잘못된 대답을 방지하려고 방법을 찾아보면, "모르면 물어보세요", "확신하지 말고 답변하세요" 같은 시스템 프롬프트를 자주 발견했는데, 그런 지시가 왜 나오게 됐는지의 배경을 이번 글을 정리하면서 이해할 수 있었습니다. 환각의 원인 중 "과도한 확신" — 모르는 것도 답변하려는 학습된 경향 — 을 시스템 프롬프트로 억제하는 것이었습니다.

 

요즘은 개발할 때 각각의 개발 특성에 맞는 프롬프트를 고민하고 있는데, 그런 프롬프트 위에서 질문하거나 개발하다 보니 확실히 더 질 높은 대답이 오는 것 같습니다. 이것이 다음 시리즈에서 다룰 CLAUDE.md, .cursor/rules 같은 파일들과 연결되는 부분이기도 합니다.

 

이런 원리들을 알고 쓰는 것과 모르고 쓰는 것은, 같은 도구를 쓰더라도 결과가 달라질 수밖에 없다고 생각합니다. 왜 환각이 생기는지 알면 AI의 답변을 대하는 자세가 달라지고, 프롬프트가 어떻게 동작하는지 알면 질문하는 방식 자체가 달라집니다. 이 글에서 다룬 개념들이 하나하나 따로 존재하는 것이 아니라, 서로 맞물려서 "LLM을 이해하고 쓴다"는 하나의 그림으로 이어진다는 것을 정리하면서 느낄 수 있었습니다.

 

다음 글에서는 이 토대 위에서, 실제로 많이 쓰이는 GPT, Claude, Gemini를 비교하고 상황별로 어떤 모델이 맞는지를 정리해보겠습니다. 읽어주셔서 감사합니다.

참고 자료

'AI' 카테고리의 다른 글

Vibe-Kanban 도입기  (7) 2025.08.03

'AI' Related Articles

티스토리툴바