**LLM(Large Language Model)**은 현대 AI 시스템의 핵심 기술 중 하나입니다. 챗봇, 코딩 도우미, 검색 시스템, AI Agent 등 다양한 제품에서 사용됩니다.

LLM의 가장 기본적인 학습 목표는 매우 단순합니다.

이전 Token을 보고 다음 Token을 예측하는 것입니다.

예를 들어:

The capital of France is

라는 입력이 있으면 모델은 다음 Token으로 Paris가 나올 가능성을 높게 계산합니다.

이 과정을 매우 큰 데이터와 신경망에서 학습하면 번역, 요약, 코드 생성, 분석과 같은 복잡한 능력이 나타납니다.

그러나 중요한 점은 LLM이 검증된 사실 데이터베이스가 아니라는 것입니다. 모델은 가장 가능성 높은 텍스트를 생성합니다.

Token

LLM은 문장을 사람이 읽는 것과 동일한 방식으로 처리하지 않습니다.

텍스트를 Token이라는 작은 단위로 나눕니다.

Token의 수는 다음과 관련됩니다.

• API 비용
• 응답 속도
• 입력 크기
• 출력 크기
• Context Window

Transformer

대부분의 현대 LLM은 Transformer 구조를 사용합니다.

Transformer에서 가장 중요한 개념은 Attention입니다.

Attention은 현재 Token을 이해할 때 문장의 다른 Token 중 어떤 것이 더 중요한지 계산합니다.

대표적인 식은 다음과 같습니다.

Attention(Q,K,V) = softmax(QKᵀ / √dₖ)V

실제 애플리케이션을 만들기 위해 이 공식을 외울 필요는 없습니다.

핵심은 다음과 같습니다.

Attention은 하나의 Token을 처리할 때 다른 Token과의 관련성을 계산합니다.

Embedding

각 Token은 먼저 숫자 벡터인 Embedding으로 변환됩니다.

Embedding은 Token의 의미와 관계를 수치 공간에서 표현합니다.

Query, Key, Value

Attention에서는 일반적으로 세 가지 표현이 사용됩니다.

• Query: 어떤 정보를 찾고 있는가?
• Key: 이 Token은 어떤 정보를 가지고 있는가?
• Value: 관련성이 높다면 어떤 정보를 전달할 것인가?

Multi-Head Attention

Transformer는 여러 Attention을 동시에 사용할 수 있습니다.

각 Head는 문법적 관계, 의미적 관계, 멀리 떨어진 단어 사이의 관계 등 서로 다른 패턴을 학습할 수 있습니다.

텍스트 생성 과정

모델은 Prompt를 처리한 뒤 다음 Token들의 확률을 계산합니다.

하나의 Token을 선택하고 다시 다음 Token을 예측합니다.

즉:

Prompt → Token → Token → Token → ...

이 과정이 반복되어 최종 응답이 만들어집니다.

Temperature

Temperature는 Token 선택의 무작위성을 조절합니다.

낮은 Temperature는 다음과 같은 작업에 적합합니다.

• 데이터 추출
• 분류
• JSON 생성
• Tool 선택

높은 Temperature는 아이디어 생성이나 창의적인 글쓰기에 더 적합합니다.

Temperature가 높다고 모델이 더 똑똑해지는 것은 아닙니다.

Prompting

실제 프로젝트에서 Prompt는 단순한 질문이 아니라 소프트웨어와 LLM 사이의 인터페이스입니다.

좋은 Prompt는 다음을 명확하게 정의해야 합니다.

• 모델의 역할
• 해야 할 작업
• 사용할 수 있는 정보
• 제한 사항
• 출력 형식

예를 들어:

Analyze this customer.

보다 다음이 더 좋습니다.

Analyze the customer information. Classify churn risk as low, medium or high. Do not invent missing information.

Zero-shot과 Few-shot

Zero-shot에서는 작업 설명만 제공합니다.

Few-shot에서는 원하는 결과의 예시도 함께 제공합니다.

특정 프로젝트에서 사용하는 분류 기준이나 출력 형식이 있을 때 Few-shot이 유용합니다.

System Prompt

시스템의 기본 규칙은 System Prompt에 정의할 수 있습니다.

예:

You are a CRM assistant. Never modify customer information without authorization.

사용자의 요청은 별도의 User Message로 전달됩니다.

이 구분은 보안과 Agent 설계에서 매우 중요합니다.

Structured Output

프로덕션 애플리케이션에서는 자유로운 문장보다 구조화된 데이터를 사용하는 것이 더 좋은 경우가 많습니다.

예:

{
  "risk": "high",
  "confidence": 0.81
}

그러나 모델이 JSON을 만들었다고 해서 항상 올바른 데이터라고 믿으면 안 됩니다.

Backend에서 반드시 검증해야 합니다.

Context Window

Context Window는 한 번의 요청에서 모델이 볼 수 있는 정보의 양입니다.

다음이 포함될 수 있습니다.

• System Prompt
• 이전 대화
• 현재 질문
• 검색된 문서
• Tool 결과
• 생성 중인 응답

Context Window는 모델의 임시 작업 메모리라고 생각할 수 있습니다.

Context가 크다고 항상 좋은 것은 아닙니다.

불필요한 정보를 너무 많이 넣으면 비용과 지연 시간이 증가하고 중요한 정보가 묻힐 수 있습니다.

따라서:

가능한 모든 정보를 넣는 것이 아니라 필요한 정보를 넣어야 합니다.

RAG

수만 개의 문서를 모두 Prompt에 넣을 수는 없습니다.

**RAG(Retrieval-Augmented Generation)**에서는 먼저 관련 문서를 검색하고 필요한 부분만 Context에 추가합니다.

Question → Retrieval → Relevant Documents → LLM → Answer

기업 문서 검색과 지식 기반 AI에서 매우 중요한 구조입니다.

Hallucination

Hallucination은 모델이 그럴듯하지만 사실이 아닌 정보를 생성하는 현상입니다.

모델은 다음과 같은 것을 만들어낼 수 있습니다.

• 존재하지 않는 논문
• 잘못된 통계
• 존재하지 않는 API
• 추측한 고객 정보
• 잘못된 제품 기능

Hallucination을 줄이기 위해서는 다음을 사용할 수 있습니다.

• 신뢰할 수 있는 Context
• RAG
• Tool Use
• 명확한 Prompt
• Structured Output
• Validation
• 중요한 작업에서 Human Approval

Tool Use

LLM만으로는 실제 시스템의 최신 정보를 알 수 없습니다.

따라서 애플리케이션은 다음과 같은 Tool을 제공할 수 있습니다.

get_customer(customer_id)

get_order_status(order_id)

create_lead(data)

send_email(to, subject, body)

사용자가 주문 상태를 질문하면 LLM이 직접 추측하는 대신 적절한 Tool을 요청해야 합니다.

흐름은 다음과 같습니다.

User → LLM → Tool Request → Backend → API/Database → Tool Result → LLM → User

Tool 보안

모델이 다음을 요청했다고 가정해 봅시다.

delete_customer(218)

Backend는 이를 바로 실행하면 안 됩니다.

반드시 확인해야 할 항목은 다음과 같습니다.

• Authentication
• Authorization
• Schema Validation
• Business Rules
• Risk Level
• 필요한 경우 User Confirmation

핵심 원칙은:

LLM은 행동을 제안할 수 있지만 실제 실행 여부는 애플리케이션이 결정해야 합니다.

CRM Agent 예제

사용자가 다음과 같이 요청한다고 가정합니다.

Acme 고객을 확인하고 Opportunity가 준비되었으면 Won으로 변경해 줘.

안전한 시스템은 다음 순서로 동작할 수 있습니다.

1. 요청 의도를 분석합니다.
2. get_account('Acme')를 실행합니다.
3. 실제 CRM 데이터를 분석합니다.
4. 정보가 부족하면 질문합니다.
5. 필요한 변경 작업을 제안합니다.
6. 사용자 권한을 확인합니다.
7. 중요한 변경이라면 확인을 요청합니다.
8. Backend가 실제 작업을 실행합니다.

이러한 구조가 단순한 Demo와 Production Agent를 구분합니다.

권장 아키텍처

Frontend

↓

Backend / Agent Controller

↓

LLM

↓

Tool Router

↓

CRM / Database / Search / External APIs

Backend에서는 Authentication, Authorization, Validation, Logging, Retry와 같은 기능을 관리해야 합니다.

Prompt와 Code의 역할

Prompt에 적합한 것:

• 작업 설명
• 응답 스타일
• 행동 지침
• 출력 형식

Code에 적합한 것:

• Authentication
• Authorization
• Validation
• 보안 규칙
• 중요한 Business Rule
• 실제 작업 실행

보안에 중요한 규칙을 Prompt만으로 보호해서는 안 됩니다.

정리

LLM은 기본적으로 다음 Token을 예측하는 모델입니다.

Transformer는 Token 사이의 관계를 이해하도록 돕습니다.

Prompt는 모델이 해야 할 작업을 정의합니다.

Context Window는 현재 모델이 볼 수 있는 정보를 결정합니다.

Hallucination은 자연스러운 문장이 반드시 사실은 아니라는 것을 의미합니다.

Tool Use는 LLM을 실제 데이터와 시스템에 연결합니다.

가장 중요한 점은:

신뢰할 수 있는 AI 시스템은 LLM 하나만으로 만들어지지 않습니다. 올바른 Context, 통제된 Tool, Validation, Permission, Logging과 좋은 소프트웨어 아키텍처가 함께 필요합니다.

이 기본기를 이해하면 AI Agents, ReAct, Planning, Memory, Reflection, RAG, Agentic AI를 학습할 준비가 됩니다.