Buzzword 없이 이해하는 LLM 용어

LLM 주변에는 놀라울 정도로 짧은 시간 안에 하나의 독자적인 어휘가 생겼습니다. Tokens, Parameters, Context Windows, Reasoning Models, Agents, RAG, MCP, Open Weights, Inference, Prompt Caching, Mixture of Experts. 그리고 그 사이 어딘가에서는 어떤 공급자가 Credits까지 팔고 있습니다.

문제는 이 용어들이 아무 의미가 없다는 데 있지 않습니다. 오히려 반대입니다. 많은 용어는 실제로 중요하고 구체적인 기술 개념을 가리킵니다. 다른 일부는 제품 용어, 분류, 과금 모델입니다. 또 어떤 용어는 연구와 Engineering에서 시작했지만 지금은 너무 넓게 사용되어, 두 공급자가 같은 단어를 쓰면서도 정확히 같은 의미를 말하지 않는 경우가 있습니다.

그래서 이 분야 전체가 완전히 새로운 기술 세계처럼 보이기 쉽습니다. 하지만 막상 하나씩 풀어 보면 의외로 단순하게 설명할 수 있는 개념이 많습니다. Agentic Work를 더 깊이 보기 전에 먼저 Buzzword를 걷어 내고, 서로 같은 단어로 같은 것을 말하고 있는지부터 맞춰 두는 편이 좋습니다.

AI – Artificial Intelligence

Artificial Intelligence, 즉 인공지능은 우선 매우 넓은 상위 개념입니다. 우리가 보통 지각, 언어 처리, 계획, 패턴 인식, 문제 해결, 의사 결정 같은 능력과 연결하는 작업을 컴퓨터 시스템이 수행한다면 AI의 범주에 들어갈 수 있습니다.

체스 프로그램도 AI일 수 있고, 이미지 인식 시스템도 AI일 수 있으며, Large Language Model 역시 AI에 포함됩니다. 이 구분이 중요한 이유는 오늘날 사람들이 “AI”라고 말하면서 실제로는 LLM이나 Generative AI를 뜻하는 경우가 많기 때문입니다.

AI가 곧 LLM인 것은 아닙니다. LLM은 AI 모델의 특정한 한 종류입니다.

Machine Learning

Machine Learning은 원하는 동작을 전부 명시적인 규칙으로 작성하지 않고, 데이터를 이용해 모델을 조정하여 그 안에서 유용한 패턴을 학습하게 만드는 방법을 가리킵니다.

전통적인 소프트웨어를 매우 단순하게 그리면 다음과 같습니다.

입력
↓
사람이 작성한 규칙
↓
출력

Machine Learning에서는 이 의사 결정 논리의 일부가 Training 과정에서 데이터로부터 형성됩니다. 그렇다고 컴퓨터가 갑자기 무엇을 어떻게 배울지 스스로 결정한다는 뜻은 아닙니다. 데이터, 모델 아키텍처, Training 방법, 최적화 목표, Evaluation 등은 여전히 사람이 정합니다.

Deep Learning은 많은 처리 Layer를 가진 신경망을 사용하는 Machine Learning의 한 분야입니다. 현대 LLM은 여기에 속합니다.

Generative AI

Generative AI는 새로운 콘텐츠를 생성할 수 있는 AI 시스템을 뜻합니다. 텍스트, 이미지, 오디오, 비디오, 프로그램 코드 또는 이들의 조합을 만들 수 있습니다.

여기서 “새롭다”는 말이 반드시 인간적인 의미의 창의성을 뜻하는 것은 아닙니다. Generative Model은 Training에서 배운 구조와 현재 Input을 바탕으로 Output을 생성합니다.

질문에 문장으로 답하는 Chatbot은 Generative AI입니다. 설명을 바탕으로 이미지를 만드는 이미지 모델도 마찬가지입니다. 반대로 사진 안에 고양이가 있는지만 분류하는 시스템은 Generative일 필요가 없습니다.

Model

AI에서 Model이라고 할 때는, 단순화하면 Input으로부터 Output을 만들어 내는 학습된 수학적 시스템을 뜻합니다.

Training 중에는 매우 많은 내부 숫자 값이 조정됩니다. 이 값들은 아키텍처와 함께 모델이 이후 Input에 어떻게 반응할지를 결정합니다.

다만 실제 제품에서는 “Model”이라는 말이 다소 느슨하게 사용됩니다. 공급자가 특정 Model 이름을 붙였을 때, 실제로는 아키텍처와 Weights뿐 아니라 Post-Training, Tokenizer, 설정, Serving 방식까지 포함하여 우리가 체감하는 “그 모델”을 구성할 수 있습니다.

그래서 비슷한 크기의 모델이라고 해서 기술적으로나 품질 면에서 직접 비교할 수 있는 것은 아닙니다.

Foundation Model

Foundation Model은 넓은 범위의 데이터로 Training된 뒤 여러 종류의 작업을 위한 기반으로 사용할 수 있는 모델입니다. 이 용어는 특히 Stanford Center for Research on Foundation Models를 통해 널리 알려졌습니다. [2]

중요한 것은 특정 Parameter 수가 아니라 모델의 역할입니다. 범용적인 기반을 만들고, 이후 Prompting, Post-Training, Fine-Tuning 또는 추가 시스템을 통해 구체적인 작업에 활용합니다.

많은 현대 LLM이 Foundation Model에 속하지만 두 용어는 동의어가 아닙니다. Foundation Model은 언어 외의 다른 Modalities도 포함할 수 있습니다.

LLM – Large Language Model

Large Language Model은 말 그대로 대규모 언어 모델입니다. 오늘날 Chat이나 Coding 시스템에서 주로 이야기하는 Generative LLM은 정보를 Token 단위로 처리하고, 보통 Output을 한 단계씩 생성합니다.

매우 단순화하면 다음과 같습니다.

현재 Context
↓
가능한 다음 Token들을 평가
↓
다음 Token을 결정
↓
Context에 추가
↓
반복

가장 흔한 오해 중 하나는 LLM을 완성된 답변이 저장된 거대한 데이터베이스처럼 생각하는 것입니다. 실제로는 그렇게 동작하지 않습니다. 프랑스의 수도를 묻는 질문에 답할 때, 일반적인 LLM이 “Paris is the capital of France”라는 완성된 문장을 전통적인 테이블에서 꺼내 오는 것은 아닙니다. 현재 Context와 Training 중 배운 구조를 바탕으로 답을 단계적으로 생성합니다.

지식과 관계가 Model Parameters 안에 표현될 수 있다는 사실과는 모순되지 않습니다. 다만 LLM은 전통적인 조회 시스템이 아닙니다.

Transformer

Transformer는 2017년 Attention Is All You Need 논문에서 소개된 신경망 아키텍처로, 현대 언어 모델의 발전에 큰 영향을 주었습니다. [1]

핵심 요소 중 하나는 Attention Mechanism입니다. 아주 단순하게 말하면, 모델이 어떤 Token을 처리할 때 현재 계산에 다른 Input의 어느 부분이 특히 중요한지 가중치를 둘 수 있게 해 줍니다.

수학을 이해하지 않아도 한 가지 구분은 알아 둘 필요가 있습니다.

LLM과 Transformer는 동의어가 아닙니다. 많은 현대 LLM이 전부 또는 일부 Transformer 아키텍처에 기반합니다. Transformer는 아키텍처이고, LLM은 언어를 중심으로 하는 모델의 한 종류입니다.

Parameters

Parameters는 모델 내부의 조정 가능한 숫자 값으로, Training 과정에서 학습됩니다. 그래서 Model 설명에 7B, 70B, 600B 같은 숫자가 자주 등장합니다. B는 영어 billion, 즉 10억을 뜻합니다.

따라서 70B 모델은 대략 700억 개의 Parameters를 가진 모델입니다.

하지만 이 숫자만으로 실제 모델 품질을 판단하기는 어렵습니다. 아키텍처, Training Data, 데이터 품질, Training 방법, Post-Training, Inference 중 사용 가능한 Compute 등이 모두 모델 능력에 영향을 줍니다.

Parameters가 더 많다고 자동으로 더 좋은 모델이 되는 것은 아닙니다.

Mixture-of-Experts 모델에서는 단순한 Parameter 총수 자체가 더 해석하기 어려워집니다. 뒤에서 다시 다루겠습니다.

Weights

Weights는 신경망 내부에서 학습된 숫자 값입니다. 내부 신호가 어떻게 결합되는지에 영향을 주며 Training 과정에서 조정됩니다.

일상적인 LLM 대화에서는 Weights와 Parameters를 거의 같은 의미로 사용하는 경우가 많습니다. 기술적으로는 조금 더 정확한 구분이 있습니다. Weights는 Parameters에 속하지만, 모델에는 다른 형태의 Trainable Parameters도 있을 수 있습니다.

어떤 공급자가 모델을 Open Weights라고 부를 때는 일반적으로 학습된 Model Weights를 사용할 수 있게 공개했다는 뜻입니다. 그것이 무엇을 의미하고 무엇을 의미하지 않는지는 뒤에서 다시 보겠습니다.

Training

Training은 모델이 Parameters를 학습하거나 변경하는 과정입니다.

아주 단순화하면, 모델이 매우 많은 Training Examples를 처리하고, 예측을 만들고, Training Objective와의 차이를 계산한 뒤 Parameters를 조금씩 조정합니다. 이 과정이 아주 많이 반복됩니다.

이 글의 나머지 부분을 이해하기 위해서는 우선 다음 정도의 구분이면 충분합니다.

Training
데이터
↓
최적화
↓
변경된 Model Parameters


Inference
Input
↓
이미 Training된 Model
↓
Output

Training은 모델을 바꿉니다. Inference는 Training된 모델을 사용합니다.

실제 현대 Training Pipeline은 이 그림보다 훨씬 복잡하지만 개념을 나누기에는 충분합니다.

Pre-Training과 Post-Training

현대 LLM을 이야기할 때 Pre-Training과 Post-Training이라는 용어를 자주 만나게 됩니다.

Pre-Training에서는 먼저 범용적인 Base Model을 만듭니다. 매우 큰 데이터로부터 넓은 범위의 구조와 관계, 기본 능력을 학습합니다.

그 뒤 추가 Training 단계가 이어질 수 있습니다. Post-Training은 Base Model이 Instructions를 더 잘 따르고, 특정 유형의 문제를 풀거나, 원하는 행동을 보이도록 만드는 여러 방법을 묶어 부르는 말입니다. Fine-Tuning이나 여러 형태의 Reinforcement Learning도 여기에 포함될 수 있습니다.

같은 기본 아키텍처와 유사한 Pre-Training을 가진 두 모델도 서로 다른 Post-Training을 거치면 실제 사용감이 크게 달라질 수 있습니다.

Fine-Tuning

Fine-Tuning은 이미 Training된 모델을 추가 Training으로 목적에 맞게 조정하는 과정입니다. 특정 작업, 전문 분야, Output Format 또는 Behavior에 맞게 모델을 특화하는 데 사용할 수 있습니다.

여기서 핵심은 Training입니다. Fine-Tuning은 Model Parameters를 변경합니다.

이 점이 Prompting, RAG, 일반적인 Memory System과 근본적으로 다릅니다. 매 요청마다 Architecture Rules를 Context로 보내는 것은 Fine-Tuning이 아닙니다. Agent가 Project Database에서 정보를 가져오는 것도 Fine-Tuning이 아닙니다.

추가 Context는 Fine-Tuning이 아닙니다.

Inference

Inference는 이미 Training된 모델을 사용하는 과정입니다. Input을 주고 Output을 계산하게 합니다.

"Dependency Injection을 설명해 줘."
↓
Training된 Model
↓
생성된 답변

일반적인 Inference 중에는 모델의 Base Weights가 자동으로 바뀌지 않습니다. 긴 Chat을 했다고 Base Model이 자동으로 추가 Training되는 것도 아니고, Prompt 하나를 보냈다고 Training되는 것도 아니며, 일반적인 RAG System도 마찬가지입니다.

어떤 제품이 나에 대한 정보를 “기억”한다고 해서 반드시 Model Weights가 변경된 것도 아닙니다.

Inference는 모델을 사용하는 것이지, 자동으로 다시 Training하는 것이 아닙니다.

Context, Memory, Retrieval, Agent를 이야기할 때 이 구분은 계속 중요해집니다.

Token

Token은 Language Model이 처리하는 기본 단위입니다. Token이 곧 단어인 것도 아니고, 항상 한 글자인 것도 아닙니다.

자주 쓰이는 단어 하나가 한 Token일 수 있고, 드문 단어나 합성어는 여러 Tokens로 나뉠 수 있습니다. 구두점이나 단어의 일부도 별도의 Token이 될 수 있습니다.

어떻게 나뉘는지는 Tokenizer에 따라 다릅니다. 그래서 같은 텍스트도 모델에 따라 Token 수가 다를 수 있고, 같은 내용을 다른 언어로 표현하면 필요한 Token 수가 크게 달라질 수 있습니다. [3]

Tokens는 Context 크기, 최대 Output 길이, Compute, API Limits, 그리고 많은 경우 과금에도 영향을 줍니다.

하지만 Token은 우선 기술적인 단위이지 화폐가 아닙니다.

Tokenizer

Tokenizer는 사람이 읽는 텍스트를 모델이 실제로 처리하는 Token 단위로 바꿉니다.

문장이 내부적으로 단순한 한국어 단어 목록이나 영어 단어 목록이 되는 것이 아니라 Token IDs의 Sequence로 변환됩니다. Tokenizer는 Vocabulary와 텍스트를 적절한 단위로 나누는 방식을 가지고 있습니다.

그래서 Tokenizer는 사람이 쓰는 텍스트와 모델 사이를 연결하는 중요한 인터페이스입니다.

Input Tokens

Input Tokens는 하나의 Model Request에 들어가는 Tokens입니다. 사용자가 화면에서 입력한 문장보다 훨씬 많을 수 있습니다.

애플리케이션에 따라 System Instructions, 이전 Chat History, Tool Descriptions, Documents, Search Results, Memory Entries, Project Information 등이 함께 Input으로 들어갈 수 있습니다.

그래서 사용자 질문은 매우 짧아도 실제 Model Input은 꽤 클 수 있습니다.

Output Tokens

Output Tokens는 모델이 생성 과정에서 만들어 내는 Tokens입니다. 일반적인 Chat에서는 그 대부분이 우리가 최종적으로 보는 답변 텍스트에 해당합니다.

일부 Reasoning Systems에서는 내부 Reasoning Tokens를 별도로 기록하기도 합니다. 이 Tokens가 최종 답변에 그대로 보일 필요는 없습니다. 어떻게 세고, 노출하고, 과금하는지는 공급자와 모델마다 다릅니다. [3]

따라서 최종 답변이 짧다고 해서 Inference 중 계산량까지 반드시 작았다는 뜻은 아닙니다.

Cached Tokens

현대 LLM 서비스는 반복되는 Input의 일부를 Cache할 수 있습니다. 여러 요청에서 같은 긴 System Prompt나 Tool Description을 반복한다면 이전 계산의 일부를 재사용할 수 있습니다.

공급자는 이런 재사용 Input을 Cached Tokens로 표시하고 기술적으로 또는 상업적으로 다르게 처리할 수 있습니다. 예를 들어 OpenAI는 Cached Tokens를 Input Token Usage의 일부로 표시하며, 다른 주요 공급자들도 Prompt 또는 Context Caching 기능을 제공합니다. [3]

중요한 점은 다음입니다.

Cached Tokens도 여전히 Tokens입니다.

Cache가 해당 내용을 영구적인 Model Knowledge로 바꾸는 것도 아니고 Context Window를 자동으로 늘려 주는 것도 아닙니다. 다만 반복 계산을 줄여 Latency나 Cost를 낮출 수 있습니다.

Prompt Caching

Prompt Caching은 여러 요청에서 이미 처리한 Prompt의 일부를 다시 사용하는 방식입니다.

많은 Request가 동일한 긴 Prefix로 시작할 때 특히 유용합니다. 예를 들어 긴 Agent Instructions, Tool Schemas, Documents가 계속 반복될 수 있습니다. 적절한 시스템은 이 부분을 매번 처음부터 처리하지 않고 이전에 계산한 상태를 재사용할 수 있습니다.

Cache가 얼마나 오래 유지되는지, 어떤 부분이 Cache 가능한지, 어떻게 과금되는지는 공급자별 Product Logic입니다.

Prompt Caching은 Memory도 아니고 추가 Training도 아닙니다.

KV Cache

KV Cache, 즉 Key-Value Cache는 많은 Transformer 모델이 Inference 과정에서 사용하는 기술적 최적화입니다.

Autoregressive Model이 Token을 하나씩 생성할 때 KV Cache는 Attention Layers에서 이미 계산한 특정 상태를 저장합니다. 그래서 새로운 Token을 만들 때 이전 부분을 완전히 다시 계산하지 않아도 됩니다. [16]

기본 개념을 위해서는 다음 정도만 구분하면 충분합니다. KV Cache는 Model Inference 내부의 메커니즘이고, Prompt Caching은 시스템이나 공급자가 제공하는 더 높은 수준의 Caching 개념입니다. 둘은 연결될 수 있지만 같은 개념은 아닙니다.

Prompt

Prompt는 모델에 영향을 주기 위해 전달하는 Input 또는 Instruction입니다.

간단한 질문일 수도 있습니다.

Event Loop이 뭐야?

하지만 Requirements, Examples, Data, Rules, Constraints도 Prompt 안에 들어갈 수 있습니다. Software Engineering에서 복잡한 작업을 위한 좋은 Prompt는 점점 Specification과 비슷해집니다.

이것이 목표다. 이것이 Context다. 이 Constraints를 지켜라. 이 결과를 기대한다.

그래서 Prompting은 한때 Prompt Engineering이라는 용어가 주던 인상만큼 신비로운 기술은 아닙니다.

System Prompt

많은 LLM 애플리케이션은 상호작용의 기본 틀을 정하는 추가 Instructions를 사용합니다. 보통 System Prompt라고 부릅니다.

시스템이 어떤 역할을 맡아야 하는지, 어떤 Tools를 사용할 수 있는지, 어떤 규칙이 적용되는지, 어떤 Output Format을 사용해야 하는지 등을 지정할 수 있습니다. 이런 Instructions가 사용자에게 모두 보일 필요는 없습니다.

System Prompt는 Model Behavior를 강하게 유도할 수 있지만 모든 규칙이 모든 상황에서 완벽하게 지켜진다는 수학적 보장은 아닙니다.

Context

Context는 간단히 말하면 모델이 현재 처리 과정에서 사용할 수 있는 정보입니다.

여기에는 User Request, System Instructions, 이전 Conversation History, Documents, Tool Results, Memory Contents, Retrieval Results 등이 포함될 수 있습니다.

따라서 Context는 Training 중 Model Parameters에 형성된 Knowledge와는 다릅니다. 모델이 한 번도 보지 못한 새로운 API Documentation을 Context에 넣으면, 모델은 그 문서를 활용해 작업할 수 있습니다.

요청이 끝난 뒤에도 Base Weights는 그대로입니다.

Context는 Training이 아닙니다.

Context Window

Context Window는 하나의 처리 과정에서 모델 또는 특정 Model Endpoint가 지원할 수 있는 Context의 크기를 뜻합니다. 보통 Tokens 단위로 표시합니다.

128k Context Window는 128,000개의 단어가 아니라 약 128,000 Tokens를 의미합니다. Input과 Output이 이 Limit에 어떻게 포함되는지는 모델과 API Design에 따라 다릅니다.

큰 Context Window는 유용하지만 그 안의 모든 정보가 같은 신뢰도로 활용된다는 뜻은 아닙니다. 잘 알려진 Lost in the Middle 연구는 초기 Long-Context Models에서 중요한 정보가 Context의 어느 위치에 있는지에 따라 활용 성능이 크게 달라질 수 있음을 보여 주었습니다. [5] 이후 연구와 최신 모델에서 이러한 능력은 많이 개선되었지만 기본적인 구분은 여전히 유효합니다.

Context 안에 들어간다는 것과 그 Context를 안정적으로 활용한다는 것은 서로 다른 능력입니다.

Context Engineering

Context Engineering은 특정 작업을 위해 모델에 어떤 정보를 제공할지를 의도적으로 설계하는 작업입니다.

Prompt만 잘 쓰는 문제보다 훨씬 넓습니다. System Instructions, 관련 Files, Tool Descriptions, Examples, Memory, Retrieval Results, 현재 State, 그리고 어떤 정보를 언제 불러올지에 대한 Rules까지 포함할 수 있습니다.

그래서 질문은 다음에서:

완벽한 Prompt를 어떻게 쓰지?

다음으로 바뀝니다.

이 구체적인 결정을 위해 모델이 정말 필요한 정보는 무엇이고, 필요하지 않은 정보는 무엇인가?

Context Engineering은 새로운 Model Architecture나 Training 방법이 아닙니다. 모델에 어떤 정보를 언제 공급할지를 다루는 Engineering입니다.

특히 Coding Agent를 다룰 때 이 개념은 중요해집니다.

Probabilistic

LLM은 Probabilistic Models입니다. 그렇다고 그냥 주사위를 던져 아무거나 고른다는 뜻은 아닙니다.

Language Model은 다음 Token 후보에 대한 값을 계산하고, 그로부터 가능한 Tokens의 확률 분포를 만들 수 있습니다. 매우 단순화한 예시는 다음과 같습니다.

"하늘은 ..."

파랗다    0.61
오늘      0.08
맑다      0.07
초록색    0.01
...

숫자는 예시이지만 원리는 실제입니다. 현재 조건에서 가능한 여러 다음 표현은 서로 다른 가능성을 가집니다.

그 분포에서 실제 하나의 Token을 어떻게 고르는지는 또 다른 문제입니다.

Sampling

Sampling은 가능한 다음 Tokens 중에서 실제 하나를 선택하는 방법을 뜻합니다.

항상 가장 가능성이 높은 Token을 고를 수도 있고, 여러 그럴듯한 후보 중 하나를 Sampling할 수도 있습니다. Temperature, Top-K, Top-P 같은 여러 전략과 설정이 여기에 사용됩니다. [4]

그래서 “Probabilistic”이라고 해서 모든 Request가 완전히 다른 답을 내야 하는 것은 아닙니다. 반대로 같은 Prompt가 항상 완전히 동일한 Output을 보장하지도 않습니다.

모델은 가능한 다음 표현의 분포를 만들고, Decoding Strategy가 그것을 실제 하나의 Sequence로 바꾸는 방식에 영향을 줍니다.

Temperature

Temperature는 많은 Generation 방식에서 Token 선택이 가장 가능성 높은 후보에 얼마나 강하게 집중될지를 조절합니다.

낮은 값은 보통 더 집중된 선택으로 이어집니다. 높은 값은 다른 후보들에게 더 많은 가능성을 허용하기 때문에 결과의 Variation이 커질 수 있습니다. [4]

흔히 다음처럼 단순화합니다.

낮은 Temperature = 정확함, 높은 Temperature = 창의적임

하지만 그렇게 단순하지 않습니다. Temperature는 우선 분포와 선택 방식에 영향을 줄 뿐입니다. 그것이 실제 정답률이나 품질에 어떤 영향을 주는지는 작업, 모델, Decoding 방식에 따라 다릅니다.

또한 temperature: 0을 모든 시스템에서 완전한 Determinism과 동일시해서도 안 됩니다. API와 Inference System 구현이 다를 수 있고, 다른 부분에서도 Variability가 생길 수 있습니다. Anthropic은 이 제한을 명시적으로 문서화하고 있습니다.

Reasoning

Reasoning은 기술적인 의미와 Marketing 표현이 특히 쉽게 섞이는 용어입니다.

연구와 제품에서 이 용어는 오늘날 복잡한 문제를 풀 때 Inference 단계에서 추가 Compute를 사용하는 모델이나 방법을 가리키는 경우가 많습니다. 예를 들어 더 많은 중간 단계를 계산하거나, 여러 후보를 만들거나, 서로 다른 Solution Path를 확인하거나, 추가 Search와 Verification을 수행할 수 있습니다.

이 주변에서 test-time compute, inference-time compute, reasoning tokens, thinking tokens 같은 용어를 자주 봅니다. 이들은 완전히 같은 뜻이 아닙니다.

Test-Time 또는 Inference-Time Compute는 Training이 끝난 뒤 실제 문제를 처리할 때 추가 계산을 사용하는 넓은 개념입니다. 연구에 따르면 적절한 문제에서는 더 많은 Inference Compute가 Solution Quality를 높일 수 있지만, 그 효과는 방법과 문제에 크게 좌우됩니다. [6][7]

Reasoning Tokens나 Thinking Tokens는 보통 특정 구현이나 제품에서 내부 처리 단계를 나타내는 표현입니다.

가장 중요한 포인트는 기술보다 언어에 있습니다.

Reasoning이 곧 인간의 사고, 의식 또는 이해를 뜻하는 것은 아닙니다.

이 용어는 AI System의 능력이나 처리 방식을 설명할 뿐, 모델 내부에서 인간과 같은 사고 과정이 일어나고 있다는 증거는 아닙니다.

Hallucination

LLM이 사실, 출처 또는 제공된 Context와 맞지 않는 내용을 생성하면서도 매우 그럴듯하게 표현할 때 보통 Hallucination이라고 부릅니다.

Software Development에서는 Library에 실제로 존재하지 않는 Method를 만들어 내거나, 존재하지 않는 API를 지어 내거나, 실제로 출판되지 않은 논문이나 문서를 그럴듯하게 제시하는 경우가 이에 해당할 수 있습니다.

모든 오류가 Hallucination인 것은 아닙니다. Requirement를 오해하거나, 계산을 틀리거나, 실제로 존재하지만 오래된 API를 사용하거나, 좋지 않은 Architecture Decision을 내릴 수도 있습니다. 모두 잘못일 수 있지만 같은 종류의 오류는 아닙니다.

또한 Hallucination이라는 단어 자체가 은유입니다. 모델이 인간처럼 무언가를 “본다”는 의미는 아닙니다.

Noise

Noise는 LLM 분야에서 명확히 정의된 과학 용어가 아닙니다. 개발자들은 실제 작업에 별 가치가 없지만 그럴듯해 보이는 Output을 실용적으로 묶어 부를 때 자주 사용합니다.

필요 이상으로 긴 설명, 요구하지 않은 Abstraction, 불필요한 변경, 또는 다섯 문단을 읽고 나서 실제로 쓸 수 있는 문장이 하나만 남는 상황이 모두 Noise일 수 있습니다.

Coding Agent에서는 작은 변경만 요청했는데 Agent가 여러 “개선”을 추가하여 Review Cost를 키우는 상황도 Noise라고 부를 수 있습니다.

즉 이 용어는 모델 내부의 명확한 메커니즘이라기보다 Output의 Signal-to-Noise Ratio에 대한 개발자의 경험을 표현합니다.

Embedding

Embedding은 정보를 숫자로 표현하는 방식입니다. Text, Image 또는 다른 Content를 숫자로 구성된 Vector로 나타냅니다.

이 글에서는 한 가지 실용적인 효과만 기억하면 충분합니다. 좋은 Embedding Model은 의미가 비슷한 Content를 생성된 Vector Space 안에서 더 가까운 위치에 배치할 수 있습니다.

그러면 애플리케이션은 정확히 같은 단어가 있는지만 찾는 것이 아니라 의미와 Similarity를 기준으로 검색할 수 있습니다.

그래서 Embeddings는 Semantic Search와 많은 RAG Systems에서 중요합니다. 하지만 문서를 단순히 숫자로 다시 써 놓은 작은 읽기 가능한 복사본은 아닙니다.

RAG – Retrieval-Augmented Generation

Retrieval-Augmented Generation은 정보 검색과 Generative Output을 결합합니다.

기본 원리는 간단합니다.

질문
↓
관련 정보 검색
↓
찾은 정보를 Context에 넣음
↓
LLM
↓
답변

초기의 RAG 논문은 Parametric Model Knowledge와 외부에서 Retrieval한 정보를 결합하는 방식을 설명했습니다. [8]

오늘날 Retrieval은 다양한 방식으로 구현할 수 있습니다. Embeddings와 Vector Search, 전통적인 Full-Text Search, Databases, APIs 또는 이들의 조합을 사용할 수 있습니다.

그래서 RAG가 곧 Vector Database를 뜻하는 것은 아닙니다.

우리의 용어 구분에서 더 중요한 점은 다음입니다.

RAG는 일반적으로 모델을 다시 Training하지 않습니다. 찾아온 정보는 Runtime에 제공되고 보통 Context를 통해 현재 처리에 사용됩니다.

Tool Calling / Function Calling

Tool Calling에서는 모델이 구조화된 Output을 만들어 주변 애플리케이션이 외부 Function이나 Tool을 호출하도록 할 수 있습니다.

예를 들어 날씨를 직접 추측하는 대신 모델이 다음과 같이 요청할 수 있습니다.

Tool: getWeather
Argument:
  city: Berlin

실제 작업은 Language Model 외부에서 일어납니다. Runtime이나 애플리케이션이 Function을 실행하고 결과를 다시 전달합니다. 일부 플랫폼은 이런 Tools를 Server-Side로 직접 제공하지만 기본 원리는 같습니다. [9]

즉 LLM이라고 해서 자동으로 인터넷, Shell, File System에 접근할 수 있는 것은 아닙니다. 그런 능력은 Model, Tools, Permissions가 결합된 전체 시스템에서 생깁니다.

Computer Use

Computer Use는 Tool Calling의 개념을 GUI까지 확장합니다.

Model이나 Agent가 Screenshots를 받아 보고 클릭이나 키보드 입력 같은 행동을 요청할 수 있습니다. 실제 행동은 제어되는 Runtime Environment가 실행합니다.

그래서 적절한 API가 없는 애플리케이션도 Agent가 UI를 통해 조작할 수 있습니다.

하지만 Computer Use는 능력뿐 아니라 위험도 함께 키웁니다. 실제로 클릭하고, 입력하고, Form을 제출할 수 있는 Agent는 단순히 텍스트만 만드는 모델과 다른 Security 및 Approval Mechanisms가 필요합니다.

Memory

Memory는 LLM 제품에서 가장 모호하게 쓰이는 용어 중 하나입니다.

시스템이 사용자 Preference를 Database에 저장할 수 있습니다. Coding Agent가 Project Information을 Persist할 수 있습니다. Chat System이 이전 대화를 검색해 관련 내용을 Context에 다시 넣을 수도 있습니다. Agent가 두 실행 단계 사이에서 State를 저장할 수도 있습니다.

제품에 따라 이 모든 것을 Memory라고 부를 수 있습니다.

공통점은 보통 정보가 Base Model 외부 또는 추가 시스템에 저장되고 나중에 다시 제공된다는 것입니다.

Memory가 곧 Model Weights의 변경을 의미하지는 않습니다.

정보를 모델 밖에 저장해 두었다가 다음 Request에 다시 Context로 넣는 것만으로도 시스템은 매우 자연스럽게 무언가를 “기억하는” 것처럼 보일 수 있습니다.

Agent

Agent는 연구, 공급자, 개발자가 모두 동일하게 사용하는 하나의 단일한 기술 정의가 존재하지 않습니다.

이 글에서는 다음과 같은 실용적인 설명이면 충분합니다.

Agent는 Model, Goal, Context 또는 State, Tools, 그리고 여러 단계를 수행하고 그 결과를 다시 처리할 수 있는 실행 과정을 결합한 시스템입니다.

간단한 Agentic Loop는 다음과 같습니다.

목표
↓
상황 평가
↓
다음 행동 선택
↓
Tool 실행
↓
결과 관찰
↓
다시 평가
↓
...
↓
완료

한 가지 유용한 구분은 이 과정의 얼마나 많은 부분이 미리 고정되어 있고, 다음 행동을 모델이 얼마나 동적으로 결정하는가입니다. Anthropic은 예를 들어 더 명확하게 정의된 Workflows와 모델이 Process를 더 동적으로 제어하는 Agents를 구분합니다. [12]

실제 제품에서는 이 경계가 연속적입니다. “Agent”라고 써 있다고 해서 모두 같은 수준의 Autonomy를 가지는 것은 아닙니다.

Coding Agent

Coding Agent는 Software Development에 필요한 Environment와 Tools를 갖춘 Agent입니다.

Repository를 검색하고, Files를 읽고 수정하고, Compiler나 Linter를 실행하고, Tests를 돌리고, Git Diff를 확인하거나 Shell Commands를 사용할 수 있습니다.

따라서 Code Block을 붙여 넣으면 답만 해 주는 일반 Chat과는 본질적으로 다릅니다. Coding Agent는 자신의 변경 결과를 다시 관찰할 수 있습니다.

코드 변경
↓
Tests 실행
↓
오류 확인
↓
원인 분석
↓
코드 수정
↓
다시 테스트

이 Feedback Loop는 현대 Agentic Coding Workflows의 핵심 요소입니다.

Subagent는 보통 더 좁은 하위 작업을 위임받는 또 다른 Agent입니다. 이 용어 역시 하나의 표준 아키텍처를 뜻하지는 않습니다.

Agent Harness

Agent Harness는 실제 Model을 둘러싼 Runtime 및 Control Layer를 뜻합니다.

Context를 구성하고, Tool Calls를 관리하고, State를 유지하고, Permissions를 확인하고, Human Approval을 요청하고, 여러 단계의 Agent Loop를 조정할 수 있습니다. Microsoft 역시 현재 Agent Harness를 Language Model이 장시간 Agent Work를 할 수 있도록 필요한 요소를 제공하는 Runtime Scaffolding으로 설명합니다. [13]

이 구분은 꽤 유용합니다.

Model
=
Output과 Decision을 생성

Harness
=
Context, Tools, State,
Permissions, Execution을 조직

Agent
=
이들의 결합으로 동작

두 Coding 제품이 같은 Base Model을 사용하면서도 동작 품질이 크게 다르다면 그 차이의 상당 부분이 Harness에서 나올 수 있습니다.

Agentic AI

Agentic AI는 한 번의 답변을 넘어서 목표를 향해 좀 더 독립적으로 작업하는 AI 시스템을 묶어 부르는 말입니다.

Planning, Tool Use, Intermediate Results 관찰, 여러 연속 작업 수행, 이후 행동 조정 등이 포함될 수 있습니다. NIST 같은 기관도 이제 더 Autonomous하고 Goal-Directed한 AI Systems를 설명하는 데 이 용어를 사용합니다. [11]

그럼에도 “Agentic”에는 명확한 기술적 경계가 없습니다. 세 개의 고정된 API Calls 중 하나를 선택할 수 있는 시스템과, 오랜 시간 Repository를 조사하고 Task를 Delegate하는 Coding Agent 사이에는 매우 큰 차이가 있습니다. 하지만 제품 페이지에서는 둘 다 Agentic이라고 부를 수 있습니다.

Agentic은 새로운 Model Architecture를 뜻하지도 않고, 자동으로 완전한 Autonomy를 뜻하지도 않습니다.

MCP – Model Context Protocol

Model Context Protocol, 줄여서 MCP는 AI 애플리케이션과 외부 Capability 또는 Information 사이의 연결을 표준화합니다.

2026년 9월 기준 현재 MCP Specification은 2026-07-28입니다. 이 버전에서는 Protocol Core가 Stateless Request/Response Communication 방향으로 더 정리되었습니다. [10]

하지만 MCP를 이해하기 위해 더 중요한 것은 버전 번호가 아니라 무엇을 하는가입니다. MCP Server는 Tools, Resources, Prompts 같은 표준화된 Capability를 제공할 수 있고, 호환되는 Host나 Client가 이를 발견하고 사용할 수 있습니다.

단순화하면 다음과 같습니다.

AI 애플리케이션
↓
MCP Client
↓
표준화된 Protocol
↓
MCP Server
↓
Tools / Resources / 외부 시스템

이렇게 하면 AI 제품마다 모든 Tool과 Data Source에 대해 완전히 별도의 Integration을 새로 만들 필요가 줄어듭니다.

MCP는 Model도 Agent도 아닙니다. 자동으로 RAG나 Memory인 것도 아닙니다. Agent가 MCP를 통해 Tool을 사용할 수 있고, Retrieval System이 MCP를 통해 데이터를 가져올 수 있으며, Memory System이 MCP에 연결될 수도 있습니다.

MCP는 연결을 표준화합니다. 그 연결을 사용하는 Agent 자체가 아닙니다.

Frontier Model

Frontier Model은 특정 Model Architecture가 아닙니다.

보통 현재 성능의 최전선에 가까운 고성능 General-Purpose Models를 가리킵니다. 영국 정부의 Frontier AI 정의도 이런 상대적인 특성을 강조합니다. 특정 시점에서 가장 발전한 시스템의 수준에 도달하거나 그 이상인 모델 또는 시스템을 뜻합니다. [14]

여기서 중요한 것은 “특정 시점”입니다.

2023년에 Frontier였던 모델이 2026년에는 더 이상 Frontier가 아닐 수 있습니다.

Frontier는 현재 State of the Art에서의 위치를 설명할 뿐 특정 기술 구조를 뜻하지 않습니다.

Multimodal

Multimodal 모델 또는 시스템은 여러 종류의 정보를 처리하거나 생성할 수 있습니다.

대표적인 Modalities는 Text, Image, Audio, Video입니다. 한 모델은 Text와 Image를 Input으로 받고 Text만 Output으로 만들 수 있습니다. 다른 모델은 Speech를 이해하고 생성할 수도 있습니다.

그래서 “Multimodal”이라고 해서 모든 Modalities를 같은 수준으로 읽고 생성할 수 있다는 뜻은 아닙니다. 실제 지원하는 Input과 Output을 따로 확인해야 합니다.

VLM – Vision Language Model은 이 영역에서 더 구체적인 범주로, Visual Information과 Language를 함께 처리하는 모델을 뜻합니다.

Open Weights

Open-Weights Model은 Training된 Model Weights를 사용할 수 있게 공개한 모델입니다. License, Software, Hardware가 허용한다면 다운로드하여 자체 인프라에서 실행할 수 있습니다.

하지만 모델 주변의 모든 것이 Open이라는 뜻은 아닙니다. Training Data는 공개되지 않을 수 있고, Training Code가 없을 수도 있으며, License가 특정 사용을 제한할 수도 있고, 전체 Training Process를 재현할 수 없을 수도 있습니다.

Open Weights는 우선 Weights가 공개되어 있다는 뜻이지 전체 모델 프로젝트가 Open이라는 뜻은 아닙니다.

Open Source

전통적인 Software에서는 Open Source가 오랫동안 확립된 의미를 가지고 있습니다. 하지만 AI System에 그대로 적용하기는 더 복잡합니다. Source Code뿐 아니라 Model Parameters, Training Methods, Training Data에 대한 정보도 중요하기 때문입니다.

그래서 Open Source Initiative는 2024년에 Open Source AI Definition 1.0을 발표했습니다. AI System을 사용하고, 연구하고, 수정하고, 공유할 자유를 요구하며 Code, Parameters, Training Data Information에 대한 요구 사항도 정의합니다. [15]

이 정의가 “Open Source AI” 논쟁을 완전히 끝낸 것은 아닙니다. 그래도 Product Page에 그냥 “Open”이라고 적힌 것보다는 훨씬 구체적인 기준을 제공합니다.

기술적인 대화에서는 다음 구분이 여전히 유용합니다.

Open Weights가 자동으로 Open Source인 것은 아닙니다.

Local Model

좁은 의미에서 Local Model은 개발자 PC, Notebook, Workstation 같은 로컬 장치나 컴퓨터에서 직접 실행되는 모델입니다.

이것은 Self-Hosted와 구분하는 편이 좋습니다. Self-Hosted Model은 역시 내 통제 아래 있을 수 있지만 회사 내부 GPU Server나 자체 Cluster에서 실행될 수 있습니다.

일상적인 대화에서는 두 용어를 섞어 쓰기도 하지만 기술적인 대화에서는 다음처럼 구분할 수 있습니다.

local
=
로컬 장치에서 실행


self-hosted
=
나 또는 조직이 통제하는
인프라에서 실행

둘 다 그 자체로 모델 품질, License, Openness를 말해 주지는 않습니다. Open-Weights Model은 Local로 실행할 수 있지만 반드시 그래야 하는 것은 아닙니다.

MoE – Mixture of Experts

Mixture-of-Experts Model, 줄여서 MoE에서는 일부 Model Layers가 여러 개의 Subnetworks를 포함하며, 이들을 Experts라고 부릅니다. Router가 각 Token 처리 과정에서 어떤 Experts를 사용할지 결정합니다.

여기서 “Expert”라는 이름을 너무 문자 그대로 받아들이면 안 됩니다. 모델 안에 명확하게 해석 가능한 “Java Expert”, “수학 Expert”, “한국어 Expert”가 꼭 따로 존재하는 것은 아닙니다. 기술적으로는 모델이 Routing하는 서로 다른 Subnetworks입니다.

잘 알려진 예로 Mixtral 8x7B는 각 Token에서 8개의 Experts 중 2개를 선택합니다. [17]

단순화하면:

Token
↓
Router
↓
┌────────┬────────┬────────┬────────┐
Expert A Expert B Expert C Expert D
   ✓               ✓
↓
선택된 Experts가 계산

이 방식 덕분에 모델은 매우 많은 Total Parameters를 가지면서도 매 Token마다 모든 Experts를 사용할 필요가 없습니다.

Total Parameters

Total Parameters는 MoE 모델 전체의 Parameter 수를 뜻합니다. 특정 Token에서 선택되지 않은 Experts의 Parameters도 포함됩니다.

따라서 이 숫자는 전체 Model Size를 설명하는 데는 도움이 되지만 각 Processing Step마다 실제로 몇 개의 Parameters가 사용되는지를 직접 보여 주지는 않습니다.

Active Parameters

Active Parameters는 특정 Processing Path에서 실제 계산에 사용되는 Parameters를 뜻합니다. Sparse MoE Models에서는 이 숫자가 Total Parameters보다 훨씬 작을 수 있습니다.

공급자가 Active Parameters를 정확히 어떻게 계산했는지는 Model Card나 Paper를 확인하는 편이 좋습니다. Experts 외에도 여러 Shared Model Components가 존재하기 때문입니다.

핵심 구분은 다음과 같습니다.

매우 많은 Total Parameters
≠
모든 Token에서 모든 Parameters 사용

그래서 MoE 모델에서 단순히 “600B Parameters”라는 숫자만 제시하면 처음 보는 것보다 정보량이 훨씬 적습니다.

Quantization

Quantization은 모델 값을 저장하거나 일부 계산할 때 사용하는 Numeric Precision을 줄이는 방법입니다. 일반적인 목표는 Memory Usage와 Compute Cost를 줄이는 것입니다.

많은 모델은 이미 FP16이나 BF16 같은 Format으로 실행됩니다. 더 강한 Quantization은 Weights를 8 Bit, 4 Bit 또는 더 작은 형태로 표현할 수 있습니다. 방법에 따라 Inference의 다른 부분도 Quantize할 수 있습니다. [16]

이 점은 Local Models에서 특히 중요합니다. Full Precision에서는 GPU Memory에 들어가지 않는 모델도 Quantized 형태에서는 충분히 실행할 수 있기 때문입니다.

그 과정에서 Quality가 낮아질 수 있습니다. 얼마나 영향을 받는지는 모델, 방법, Bit Width, Task에 따라 다릅니다.

따라서 다음과 같은 생각은 틀립니다.

16 Bit에서 4 Bit로 줄였으니 Intelligence도 1/4이다.

Numeric Precision과 Model Capability는 그렇게 선형으로 움직이지 않습니다.

Quantization은 기본적으로 Memory, Compute, Hardware Requirements, 가능한 Quality Change 사이의 Engineering Trade-off입니다.

Credit

마지막으로 LLM 내부 동작과 의외로 별 관계가 없는 용어입니다.

Credit은 Language Model의 기본 기술 단위가 아닙니다. Credits는 공급자가 정의한 Product 또는 Billing Logic입니다.

하나의 Credit이 일정량의 Tokens일 수도 있고, Tool Call 하나일 수도 있고, Compute Time 1분일 수도 있고, Model Request 하나일 수도 있습니다. 또는 이들을 섞어서 정의할 수도 있습니다. Credit이 실제로 무엇을 뜻하는지는 각 제품을 확인해야 합니다.

예를 들어:

이 제품에는 10,000 Credits가 포함되어 있습니다.

라는 문장만으로는 실제 LLM 사용량에 대해 거의 아무것도 알 수 없습니다.

용어	의미
Token	모델이 사용하는 기술적인 처리 단위
Credit	공급자별 사용 또는 과금 단위

Tokens는 기술에 속합니다. Credits는 제품 또는 Business Model에 속합니다.

공급자가 Tokens를 기준으로 Credits를 계산할 수는 있습니다. 그렇다고 Credits가 Tokens가 되는 것은 아닙니다.

Buzzword에서 공통 언어로

여기까지 읽었다고 Machine Learning 학위를 딴 것은 아닙니다. 애초에 그게 목표도 아니었습니다.

하지만 이제 Model Cards, Product Pages, 개발자 대화에서 계속 등장하는 용어들을 조금 더 명확하게 구분할 수 있습니다. Model은 Training되고 이후 Inference에서 사용됩니다. Context 안에서 Tokens를 처리하고, Tokenizer가 텍스트를 그 단위로 나눕니다. Sampling은 가능한 다음 표현 중 실제 Output이 어떻게 정해지는지에 영향을 줍니다. Reasoning은 추가 Inference Compute를 포함할 수 있지만 인간적인 사고를 의미하지는 않습니다.

RAG는 외부 정보를 Context로 가져오고, Memory는 정보를 Model 외부에 저장할 수 있으며, Tools는 AI System에 행동할 수 있는 수단을 줍니다. Harness는 그 환경을 조직하고, Agent는 여러 단계에 걸쳐 그 능력들을 사용할 수 있습니다. MCP는 이런 시스템과 외부 Capability 사이의 연결을 표준화할 수 있습니다.

그리고 Credits는? 어쩌면 공급자가 우리가 이 모든 것을 얼마나 오래 계속할 수 있는지 정하는 단위일 뿐입니다.

용어 자체는 이제 조금 덜 신비로워졌습니다. 나중에 용어를 다시 찾아보고 싶다면 시리즈 용어집에서 확인할 수 있습니다. 다음 질문은 더 어렵습니다. 공급자가 어떤 Coding Agent가 실제 Software Tasks의 일정 비율을 해결한다고 말할 때, 그 숫자는 어디서 나오는 걸까요?

Benchmark란 무엇인가? SWE-bench는 무엇을 측정하는가? Verified, Pro, Pass@k는 무슨 뜻인가? 그리고 왜 Benchmark Score가 “이 모델이 개발자의 몇 퍼센트를 대체할 수 있는가”를 뜻하지 않는가?

다음 글에서는 바로 그 이야기를 시작합니다.

참고 자료

[1] Ashish Vaswani, Noam Shazeer, Niki Parmar et al.: Attention Is All You Need. Advances in Neural Information Processing Systems 30, 2017. arXiv: 1706.03762.

[2] Rishi Bommasani, Drew A. Hudson, Ehsan Adeli et al.: On the Opportunities and Risks of Foundation Models. Stanford Center for Research on Foundation Models, 2021. arXiv: 2108.07258.

[3] OpenAI: Tokens, Usage, Reasoning Tokens, Prompt Caching 관련 기술 문서. 2026년 기준.

[4] Hugging Face Transformers: Generation / GenerationConfig. 기술 문서, 2026년 기준.

[5] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang: Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12, 2024, pp. 157–173. DOI: 10.1162/tacl_a_00638.

[6] Charlie Snell, Jaehoon Lee, Kelvin Xu, Aviral Kumar: Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Parameters for Reasoning. International Conference on Learning Representations, 2025.

[7] Mohsen Hariri et al.: Test-Time Scaling in Reasoning LLMs: Inference Regimes, Evaluation, and Reproducibility. Preprint, 2026. arXiv: 2608.04001.

[8] Patrick Lewis, Ethan Perez, Aleksandra Piktus et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33, 2020. arXiv: 2005.11401.

[9] Anthropic: Tool use with Claude 및 How tool use works. 기술 문서, 2026년 기준.

[10] Model Context Protocol: Model Context Protocol Specification 2026-07-28 및 관련 Release Notes, 2026년 7월 28일.

[11] National Institute of Standards and Technology: Agentic AI. NIST, 2026.

[12] Anthropic: Building Effective Agents. 기술 문서.

[13] Microsoft: Agent Harness. Microsoft Agent Framework Documentation, 2026년 8월 기준.

[14] UK Department for Science, Innovation and Technology: Frontier AI: capabilities and risks – discussion paper. 2025년 업데이트 버전.

[15] Open Source Initiative: The Open Source AI Definition – Version 1.0. 2024, 2026년 9월 기준 Stable Version.

[16] Hugging Face Transformers: Quantization, Cache strategies, How caching works 관련 기술 문서. 2026년 기준.

[17] Albert Q. Jiang et al.: Mixtral of Experts. 2024. arXiv: 2401.04088.