LLM_Agent 2026. 6. 19. 09:52

LLM(Large Language Model)

@Beemo9

1. LLM

LLM은 Large Language Models이며, 대규모 언어 모델이라고 함.

LLM은 Yolo V5와 같은 딥러닝 기반의 AI 모델입니다.

LLM은 기존의 트랜스포머 모델을 기반으로 파생된 모델입니다.

1.1 트랜스포머 모델

트랜스포머는 2017년 "Attention is All You Need" 논문에서 나온 딥러닝 아키텍처로,
핵심은 self-attention 메커니즘입니다.

기존의 자연어 처리 모델 (NLP)은 문장을 앞에서부터 읽어서 문장이 길어질수록 앞의 내용을 잊어버리거나 의미 추론이 늦어지는 문제가 있었습니다.

예로 "철수는 / 어릴 때 / 가난했지만 / 열심히 / 공부해 / 마침내 / 의사가 / 되었고 / 예쁜 / 아내를 / 만나 / 결혼해 / 행복하게 / 살았다.”라는 문장이 있다고 가정해봅니다.

옛날 RNN과 같은 모델은 아래와 같은 단계를 통해 문장을 분석/이해합니다.

1단계 (철수는 읽는 중): "오케이, 주인공은 철수야."

2단계 (어릴 때 읽는 중): "(앞의 '철수' 기억을 들고 와서) 철수가 어릴 때였군."

3단계 (가난했지만 읽는 중): "(앞의 기억을 또 합쳐서) 철수가 어릴 때 가난했구나."

... (한 땀 한 땀 줄 서서 읽는 중) ...

13단계 (행복하게 읽는 중): "(앞의 수많은 기억을 가방에 쑤셔 넣고 끙끙대며) 철수가 어릴 때 가난했는데 공부해 의사 됐고 결혼해서... 어휴 무거워, 아무튼 행복하게..."

14단계 (살았다. 드디어 끝!): "드디어 다 읽었다!"

느린 이유는 13단계를 처리하려면 반드시 1~12단계가 끝날 때까지 손놓고 기다려야 합니다.

(기술적으로는 GPU의 강력한 연산처리를 제대로 활용하지 못하는 문제가 있습니다.)

반면 트랜스포머 모델의 경우 Self-Attention을 통해 GPU의 강력함을 제대로 사용할 수가 있습니다.

1.2 셀프 어텐션(Self-Attention) 메커니즘

-- 트랜스포머 동작 흐름 --

1. 입력 문장을 토큰화: "철수는" -> ['철수', '##는'] 구조로 분리
2. 분리된 토큰을 병렬로 벡터화 (N차원의 점으로 표현)
3. 모든 토큰 벡터 쌍에 대해 거리(연관성)을 측정.
4. 연관성에 대한 거리 값을 통해 각 토큰 벡터 쌍에 대해 0~1사이의 확률 값(가중치)으로 변환.
※ 입력으로 들어온 문맥을 좌표공간에 배치 (비슷한 의미일수록 근사값)
결과: "살았다"에 대한 토큰은 위 연산으로 인해 "행복하게"토큰과 가중치가 가장 높음으로
매칭하여 이해.

이러한 셀프 어텐션은 기존 NLP와 다르게,
"은행에 가서 돈을 찾았다"와 "은행나무를 심었다"에서 같은 "은행"이라도 주변 단어와의 attention 결과로 의미 표현을 달리 이해할 수 있게 만드는 매커니즘으로 동작합니다.

인코더 - 디코더 구조

트랜스포머의 주요한 두 가지 구성요소는 인코더와 디코더가 있습니다.

인코더: 문맥 좌표를 찍은 뒤 (Self-Attention), 그 좌표에 대한 거리 벡터를 생성함으로써 유사성을 계산하는 역할을 합니다.
- 단어를 토큰화하고, 벡터값을 변경하는 건 앞단의 임베딩 단계에서 진행됩니다.
디코더: 인코더가 넘겨준 압축된 맥락 정보를 바탕으로 방금 찍은 문맥 좌표와 가장 거리가 가까운 단어 점을 자석처럼 끌어당겨 출력하고, 이를 무한히 반복한다.
- 디코더의 내부 동작과정은 딥러닝(인공신경망) 관련 내용이기에 이해하기 쉽게 간단히 설명합니다.

1.3 LLM에게 “1+1은 몇이야?” 라고 물었을 때

Step 1. Tokenization

"1 + 1 은 몇이야?" → ["1", "+", "1", "은", "몇이야", "?"] → [15, 10, 15, 142, 3891, 30]

Step 2. Embedding

각 토큰 ID를 고차원 벡터로 변환.

15 (1) → [0.23, -0.41, 0.87, ...]
10 (+) → [0.91, 0.33, -0.12, ...]
15 (1) → [0.23, -0.41, 0.87, ...] ← 같은 토큰, 같은 벡터
142 (은) → [-0.55, 0.71, 0.34, ...]
3891(몇이야)→ [0.44, -0.29, 0.66, ...]
30 (?) → [0.12, 0.88, -0.43, ...]

아직 순서 정보는 없습니다. 그냥 의미 벡터입니다.

Step 3. Positional Encoding

순서 정보를 벡터에 더하는 단계.

"1" (position 0) → 벡터 + 위치0 인코딩
"+" (position 1) → 벡터 + 위치1 인코딩
"1" (position 2) → 벡터 + 위치2 인코딩

앞의 1과 뒤의 1이 같은 토큰이지만 이제 구별이 가능해집니다.

※최근에는 단순히 더하지않고, RoPE 방식이 사용된다고 합니다.

Step 4. Transformer Block 반복 (핵심)

블록 초반 레이어 (문법/구조 파악)

Self-Attention이 토큰 간 관계 계산:

"+" → "1", "1" 을 강하게 참조 (연산자는 피연산자를 봄)
"몇이야" → 전체 문장 참조 (질문어는 전체 맥락을 봄)
"?" → "몇이야" 강하게 참조 (문장 끝 구조 파악)

블록 중간 레이어 (의미 파악)

"1 + 1" 이라는 패턴 인식 → 덧셈 연산 구조임을 파악
"몇이야?" 패턴 인식 → 숫자 답을 요구하는 질문임을 파악

블록 후반 레이어 (지식 인출 + 추론)

FFN(인공신경망 패턴)에서 학습된 패턴 인출:

[덧셈 연산] + [1, 1] + [숫자 질문]

→ FFN: "이 패턴의 정답은 2"

→ 출력 벡터가 "2" 방향으로 수렴

Step 5. Output Layer

최종 벡터를 전체 토큰 확률 분포로 변환.

"2" : 0.96
"둘" : 0.02
"two" : 0.01
"3" : 0.001
...

Step 6. 토큰 선택 및 반복

"2" 선택
"2"를 다시 입력에 붙여서 다음 토큰 예측
"입니다" 선택
"입니다" 붙여서 다음 토큰 예측
EOS(종료 토큰) 선택
생성 종료

전체 흐름 요약

`"1 + 1 은 몇이야?"
    ↓
토큰화    [1, +, 1, 은, 몇이야, ?]
    ↓
벡터화    각 토큰 → 의미 벡터
    ↓
위치주입  순서 정보 추가
    ↓
레이어1~N
  ├── Attention : "+"는 두 1을 연결, "몇이야"는 전체 참조
  └── FFN       : 덧셈 패턴 + 1,1 → 2 인출
    ↓
확률분포  "2": 96%, "둘": 2% ...
    ↓
"2 입니다" 순차 생성`

LLM은 단순히 응답을 추측하는 것

LLM은 1+1=2 를 계산해서 아는것은 아닙니다. 1+1이라는 패턴은 다음에 2가 올 확률이 높다라는 것만 알 뿐입니다.

그래서 1 + 1 같은 자주 나오는 패턴은 왠만해선 맞추지만 9387 × 4729 와 같은 새로운 패턴은 틀립니다.

모든 패턴에 대응하기 어렵기 때문에, LLM엔 보통 계산기를 호출하는 Tool이 첨가되어있습니다.

응답을 만드는 과정은 블랙박스

LLM의 디코더를 통한 응답 생성은 블랙박스 영역입니다.
왜 이런(?) 결과가 출력되는 건지에 대해 명확히 설명할 수가 없다는 것을 의미합니다.

이를 연구하는 분야가 따로 있고,
Mechanistic Interpretability (기계적 해석 가능성)

"LLM 내부에서 실제로 무슨 일이 일어나는가" 를 역공학으로 파헤치는 연구

Anthropic이 이 분야에 엄청 투자하고 있고, 일부 회로 수준에서 규명된 것들도 있습니다.
그러나 아직 전체 그림은 모릅니다.

그래서 누군가 명확히 이유를 찾아낼 때까지는,
딱히 LLM 모델 자체에 큰 관심을 가지지 않아도 될 것 같습니다.

1.4 LLM 모델 성능 측정

LLM Foundation 모델은 시중에 상당히 많이 나와 있습니다. (GPT, Claude, LLaMA 등)

디코더 아키텍처를 정확히 파악하지 못하기 때문에 LLM 평가는 기본적으로 블랙박스 평가입니다.
내부 구조를 몰라도 출력만으로 비교하는 게 표준이고, 오히려 이게 LLM 평가의 핵심 철학입니다.

보통은 1 + 1이 뭐야? 라는 질문에 정답은 100입니다 를 외치는 모델보다는,
정답은 2입니다 를 외치는 모델이 성능이 좋기 때문에 약간의 정성적 평가라고 볼 수 있습니다.

또한 LLM은 실시간으로 개선, 변화되고 있기 때문에 구조적으로 정형화된 평가 기준이 없습니다.

모델 평가 방법에 대한 논문이 하루에도 수십 ~ 수백건씩 나오고 있습니다.

구체적 이유로는 아래와 같습니다.

Saturation → 교체 사이클: MMLU, HumanEval, MBPP 같은 초기 표준 벤치마크들은 이미 천장 근처에 몰려서 모델 비교에 쓸모가 없어졌습니다.
물량 자체가 많음: 2025년 ACL과 EMNLP 학회에서만 벤치마크 관련 연구가 거의 700편이 쏟아졌고, 대부분 독립적으로 발표되어 데이터 형식, 추론 파이프라인, 평가 스크립트가 제각각이라 통일된 평가 인터페이스가 없는 상태입니다.
벤치마크 품질 자체도 문제: 표준 벤치마크들은 비용/지연시간/실행 안정성을 거의 보고하지 않고, 특정 text-to-SQL 벤치마크는 annotation 오류율이 50%를 넘는다는 감사 결과도 있었습니다.

"하나의 절대 기준"을 찾으려고 하면 시간 낭비입니다.

대신 llm-stats, Vellum, LMArena 같은 aggregator형 리더보드를 쓰고,
실제 use case와 가장 가까운 벤치마크 1~2개(코딩이면 SWE-bench, 추론이면 GPQA Diamond) 위주로 보는 게 현실적입니다.

벤치마크는 "절대 점수"가 아니라 "이번 달 기준 상대 순위" 정도로 보는 게 맞습니다.

코딩 영역의 경우 SWE-bench가 주로 성능 평가에 사용됩니다.
※SWE-bench : 실제 Python 오픈소스 저장소의 GitHub 이슈를 모델이 처음부터 끝까지 해결할 수 있는지를 보는 평가 방법

https://www.swebench.com/original.html

SWE-bench

www.swebench.com

2. 컨텍스트 윈도우 (Context Window)

위에서 LLM이 어떻게 입력에 대한 응답을 추론하여 생성해내는지 정확히는 알 수 없지만 질문하면 추측해서 응답을 하고, 내부에는 어떤 로직이 있다 정도는 알 수 있었습니다.

그러나 질문에 대해 응답하는 것은 기존에 있던 챗봇과 다름이 없습니다.

LLM 자체는 매 호출마다 주어진 입력만 보고 추론하는 stateless 함수입니다.
"기억"이라는 개념이 모델 내부에 없습니다.

그럼 어떻게 LLM이 이전 대화를 기억하는 것과 같이 느껴지는걸까요?

이를 가능케 하는 것이 컨텍스트 윈도우입니다.

LLM이 기억을 하게 하는 것은 단순합니다.

[이전 대화 기록 + 현재 질문]을 통째로 새로운 입력으로 넣어주는 것입니다.

이때 LLM이 한 번에 입력받아서 처리할 수 있는 최대 텍스트 용량을 바로 컨텍스트 윈도우라고 부릅니다.
※ 컨텍스트 윈도우에는 지금 생성해야 할 답변의 용량도 포함됩니다.

요약하면 컨텍스트 윈도우는 "LLM이 한 번의 요청에서 입력과 출력을 합쳐 처리할 수 있는 최대 토큰 수"입니다.

모델 및 에이전트 레이어의 뒷단에서 이(컨텍스트 윈도우)를 자동으로 관리해주고 있기 때문에,
사용자는 단순히 현재 질문만 하는데 AI가 기억하고 있는 느낌을 받게 됩니다.

2.1 동작 방식

만약 어떤 LLM의 컨텍스트 윈도우가 8,000 토큰이라고 가정해 보겠습니다.
※ 8000은 예시입니다, 최신 모델의 경우 1M ~ 2M까지도 지원합니다.

대화가 길어져서 누적된 대화 내용이 8,000 토큰을 넘어가는 순간(예: 8,500 토큰),
LLM은 메모리 부족 상태에 직면합니다.

이때 시스템은 가장 오래된 대화(맨 처음 나눈 대화 500 토큰 분량)를 과감하게 잘라내고(Forget),
최근 대화 위주로 8,000 토큰을 맞춰서 LLM에게 넘깁니다.

💡 사용자가 느끼는 현상:
"어? 방금 전까지 잘 기억하더니, 왜 내가 맨 처음에 말했던 주제나 내 이름을 기억 못 하지?" 하는 순간이 바로 콘텍스트 윈도우가 꽉 차서 예전 기억이 밀려났을 때입니다.

오래된 대화를 자르는 건 ChatGPT, Claude 같은 서비스의 애플리케이션 레이어가 하는 일입니다.
대화 히스토리 전체를 서버에 저장해두고, 매 턴마다 "이번엔 어디까지를 모델에 넘길까"를 결정하는 거죠.

※저장하는 방식은 다양합니다.

최근에는 단순 FIFO(오래된 거 자르기)보다 오래된 대화를 통째로 버리는 대신 요약본으로 압축해서 컨텍스트에 계속 포함하거나, 전체 히스토리를 별도 DB/벡터스토어에 저장해두고, 매 턴마다 관련 있는 부분만 검색해서 컨텍스트에 끼워넣는 방식(MCP)으로 다양하게 발전하고 있습니다.

2.2 LLM이 내용을 까먹는 현상의 이유

흔히 발생하는 'Lost in the Middle(중간 실종)' 현상은 정보가 텍스트 창 밖으로 잘려 나가서 사라진 게 아닙니다.

데이터는 분명히 컨텍스트 안에 존재하지만, 모델이 그 부분에 '주목(Attention)'하지 못해 발생합니다.

비유하자면, 책에서 페이지가 찢겨 나간 것(물리적 삭제)과 책에는 적혀 있지만 독자가 대충 읽고 넘어가 기억하지 못하는 것(주주의력 결핍)의 차이입니다.

사용자 입장에서는 둘 다 "AI가 내용을 까먹었다"고 느끼지만, 시스템적인 원인은 완전히 다릅니다.

2.3 무한정 크기를 늘릴 순 없을까?

기술적으로는 Self-Attention이 토큰 수의 제곱(O(n²))에 비례해서 연산량이 늘고, KV 캐시 메모리도 같이 늘어나기 때문에 컨텍스트 길이는 비용/메모리와 직결된 아키텍처적 제약으로 이어집니다.

쉽게 설명하면, 많은 것을 이해하고 생성하려면 그만큼 비용과 하드웨어 성능이 뒷받쳐주어야 한다는 것이기에 크기를 늘리기 위해서는 기술적인 고도화가 필요합니다.

저작자표시 비영리 변경금지 (새창열림)

'LLM_Agent' 카테고리의 다른 글

발표 자료 컨텍스트 2부 - 프롬프트와 CLAUDE.md (0)	2026.06.25
발표 자료 컨텍스트 1부 - 스스로 일하는 AI 에이전트 (0)	2026.06.25
자료 공유 - 에이전트 (0)	2026.06.25
AI Agent (Harness) (1)	2026.06.19
논문 정리 - Towards a Science of Scaling Agent Systems (0)	2026.03.17