#LLM 추론·컨텍스트·파인튜닝 단계별 지식 정리

📊 한눈에 보는 흐름 다이어그램 → — 21개 문서를 3레인 9단계 프로세스로 압축

#📑 목차

0. 전체 지도 한눈에 보기

① 모델 구조 — 왜 이렇게 생겼나

• 01. 왜 대규모 모델은 전부 Transformer를 선택했나
• 02. QKV를 1분 만에 이해하기
• 03. "다음 단어 예측"만으로는 부족하다 — 추론 전 과정

② 추론 성능과 배포 비용

• 04. 메모리를 삼키는 주범 — KV Cache
• 05. MoE는 일부 전문가만 활성화하는데 왜 메모리를 많이 먹나
• 06. 배치 처리로 처리량을 올렸는데 왜 P99가 나빠지나
• 07. GPU가 남아도는데 왜 서비스가 먼저 무너지는가 — 추론 서비스의 유령 함정
• 08. 추론 최적화는 왜 엔진 층부터 손대야 하는가 — 4층 우선순위
• 09. 추측 디코딩은 왜 빨라지면서 답은 바뀌지 않나
• 10. 첫 글자 지연은 왜 주로 Prefill을 보나

③ 컨텍스트와 기억

• 11. 컨텍스트 윈도우는 창고가 아니라 주의력 예산이다
• 12. 다중 턴 대화에서 왜 이력을 그냥 밀어 넣으면 안 되나
• 13. 접두사 캐시와 시맨틱 캐시의 차이

④ 프롬프트 엔지니어링

• 14. 프롬프트는 도대체 어떻게 쓰나 — Zero-shot / Few-shot / CoT
• 15. 프로덕션급 Prompt는 다섯 요소로 조립한다
• 16. 프롬프트가 너무 길면 무슨 함정이 있나
• 17. Prompt는 써놓고 끝나지 않는다 — 프로덕션 퇴화
• 18. Temperature는 창의력 스위치가 아니라 확률분포의 평활 계수다

⑤ 파인튜닝과 정렬

• 19. 파인튜닝은 도대체 무엇을 조정하는가
• 20. SFT와 RLHF는 무엇이 다른가
• 21. 파인튜닝 7단계 완전 절차

부록 A · Agent 편에서 이미 다룬 LLM 주제

부록 B · 자주 등장하는 관통 개념

#0. 전체 지도 한눈에 보기

[모델 구조]   Transformer 선택 이유 · QKV · 분절/임베딩/자기회귀/디코딩
     │
[요청 도착]   프롬프트 조립 ── 접두사 안정성이 캐시 적중률을 결정
     │
① Prefill     입력 전체를 한 번에 병렬 주의력 계산 (O(N²), 연산력 제약)
     │        └ 첫 글자 지연(TTFT)의 약 90%가 여기서 발생
     │
② Decode      token 단위 직렬 생성 (메모리 대역폭 제약)
     │        └ KV Cache로 반복 재계산 → 증분 계산
     │
③ 스케줄링    배치 처리로 처리량↑ ↔ 장단 혼재로 P99↓
     │        └ 길이별 버킷 분리 · 최대 대기 윈도우 · 실시간/오프라인 큐 격리
     │        └ 병목이 연산력이 아니라 "연산력 이전"(진입 큐)에 숨어 있을 수 있다
     │
④ 가속        추측 디코딩(투기 + 검증) — 적중률이 수익을 결정, 음의 수익 구간 존재
     │        엔진 > 서비스 > 모델 > 업무 — 우선순위를 지키지 않으면 병목 아닌 곳에 복잡도만 는다
     │
⑤ 컨텍스트    윈도우 = 주의력 예산 (담긴다 ≠ 담아야 한다)
     │        └ 3층 편성 · 상태 추출 · 충돌 재정 · 수위선 70%
     │
⑥ 프롬프트    Zero-shot → Few-shot → CoT (시범 입도의 축)
     │        └ 길수록 주의력 희석 + 캐시 병목 + 비용 초선형
     │        └ 다섯 요소(역할/지시/경계/포맷/이상처리)가 하나라도 비면 그 실패 모드가 그대로 재현된다
     │        └ 정적 문서가 아니라 시간이 지나며 퇴화하는 제어 시스템으로 다룰 것
     │
⑦ 샘플링      Temperature는 창의력 다이얼이 아니라 확률분포를 뾰족/평탄하게 만드는 계수
     │        └ 추론(무엇을 아는가)과 무관하므로 환각을 고치지 못한다
     │
⑧ 능력 변경   지식이 없으면 RAG / 행동이 없으면 파인튜닝
              SFT(형식·지시 준수) → RLHF(가치관·선호 정렬)

관통하는 3가지 원칙

1. 용량과 가용성은 다르다 — 윈도우가 담을 수 있는 양과 모델이 실제로 돌볼 수 있는 양은 별개다.
2. 어떤 최적화든 무엇을 바꾸고 무엇을 지불하는지 함께 말해야 한다 — 캐시는 메모리를, 추측 디코딩은 적중률 리스크를, 파인튜닝은 일반화 능력을 지불한다.
3. 대조가 없는 최적화는 최적화가 아니다 — 입력·데이터·버전을 고정하고 주요 변수를 하나만 바꾼다.

#① 모델 구조 — 왜 이렇게 생겼나

#01. 왜 대규모 모델은 전부 Transformer를 선택했나

Transformer가 이긴 이유는 어느 한 항목이 최강이어서가 아니라 세 문제를 동시에 풀었기 때문이다: 장거리 의존성 · 병렬 계산 · 규모화 학습.

• 아키텍처 선택은 "하드웨어 적합성 문제" — RNN이 뒤처진 직접 원인은 직렬 계산이 GPU를 못 채운 것. 이론적 표현력이 좋아도 하드웨어를 채우지 못하면 scaling의 기회가 없다.
• "모델링할 수 있는가"와 "규모화 학습이 가능한가"는 다른 문턱 — Scaling Law 시대의 아키텍처 평가 기준.
• 귀납 편향은 양날의 검 — CNN의 국소성 가정은 이미지에서 효율적이지만 언어에서는 족쇄가 된다.
• 주의력은 "거리"를 아키텍처 문제에서 수치 문제로 바꿨다 — RNN에서 거리는 물리적 경로(반드시 감쇠), Transformer에서 거리는 주의력 점수에만 영향.
• 구조 통일성이 멀티모달의 전제 — 텍스트=워드 토큰 / 이미지=패치 / 오디오=음향 조각. 난점이 "새 아키텍처 설계"에서 **"좋은 Token화 설계"**로 이동.

Tips: 새 아키텍처 평가 3문 — 장거리 의존을 만드는가 / 병렬화되는가 / 규모화되는가. CNN은 도태되지 않았다(국소 특징 추출에선 여전히 우선). 시퀀스 길이가 Transformer의 비용 급소.

#02. QKV를 1분 만에 이해하기

정의를 외우지 말고 그것들이 함께 푸는 하나의 문제를 기억할 것: 한 단어가 어떤 단어들을 참조해야 하며, 참조한 뒤 무엇을 가져오는가.

흐름: Q × K → 유사도 → (softmax) 가중치 → 가중치대로 V 집계

• 최대 채점 포인트는 K와 V의 분업 — K는 점수 계산에 참여하지만 출력에 들어가지 않고, V는 점수 계산에 참여하지 않지만 출력을 구성한다. 즉 K는 "누구를 볼지", V는 "무엇을 보았는지".
• Attention의 본질은 한 번의 "소프트 검색" — RAG의 검색-리콜 패러다임과 직관적으로 동형이며, 다만 미분 가능하고 조밀하며 매 층 매 token마다 수행된다.
• 지시 대상 해소("사과가 떨어졌다, 그것이 익었기에")가 가장 경제적인 설명 예시.
• Q와 K가 같은 시퀀스에서 나오면 Self-Attention, 다른 시퀀스면 Cross-Attention.

Tips: 비유 먼저, 공식은 나중에. 소스에 없는 두 가지를 보태면 차이가 크다 — √d_k 스케일링(없으면 softmax 포화·기울기 소실), Multi-Head(단일 QKV는 한 가지 참조 관계만 표현). K/V가 불변이라는 점이 KV Cache의 전제.

#03. "다음 단어 예측"만으로는 부족하다 — 추론 전 과정

"다음 단어를 예측한다"는 결론이지 답이 아니다. 요구되는 것은 4단 파이프라인이다.

① 분절(Tokenization)   텍스트 → token 열 (구두점도 token 하나)
② 임베딩(Embedding)     각 token → 벡터 → 입력 행렬
③ 자기회귀 생성          현재 시퀀스 → 순전파 → 확률 분포 → 샘플링 → 시퀀스에 추가
                        종료: 특정 【종료 토큰(EOS)】 생성
④ 디코딩과 샘플링        그리디(결정적·경직) / 샘플링 + 온도(다양·환각 위험)

• 추론은 한 번의 순전파가 아니라 상태를 가진 순환 — 매 라운드 입력 = 원래 프롬프트 + 생성된 전부. 이것을 이해하면 길이에 따른 지연·메모리 증가를 스스로 도출할 수 있다.
• KV Cache는 "공간으로 시간을 사는" 고전적 트레이드오프 — 수학적 결과를 바꾸지 않고 매 단계 계산을 "전체 시퀀스"에서 "새 token 하나"로 낮춘다. 최적화를 물으면 먼저 재사용 가능한 중간 결과가 있는지 볼 것.
• "공간을 바꾼" 이상 공간이 새 병목이다 — 100만 token이면 KV Cache가 「길이 × 층수 × 헤드 수」로 팽창. 장점에서 대가를 스스로 도출하는 것이 초급/중급의 분수령.
• 생성 품질 문제는 모델이 아니라 디코딩 전략에 있는 경우가 많다 — "앵무새"는 그리디가 늘 argmax를 취하기 때문. 진단 시 **"분포가 나쁜지" vs "분포에서 잘못 고르는지"**를 먼저 구분.
• 온도는 "결정성↔창의성" 다이얼이지 "똑똑함↔멍청함"이 아니다 — 창의성과 환각은 같은 뿌리. 이 다이얼이 실제로 어떻게 작동하는지는 18번에서 원리 층위로 다룬다.

Tips: 두 종류의 성능 지표를 구분(첫 token 지연은 prefill 지배, 이후 token당 지연은 decode 지배). 결정성 작업은 저온/그리디, 창작은 고온+샘플링. 모델이 "반복"하면 먼저 디코딩 설정부터 확인.

#② 추론 성능과 배포 비용

#04. 메모리를 삼키는 주범 — KV Cache

긴 대화에서 메모리가 폭증하는 주범은 모델 가중치가 아니다. 가중치는 고정된 십몇 GB이고, 팽창하는 것은 KV Cache다(수십~100 GB 이상).

캐시 없음:  t단계 → token 1..t의 K/V 재계산 → 주의력 → 출력   (반복 재계산, O(n²))
캐시 있음:  t단계 → token t의 Q/K/V만 계산 → 캐싱된 K/V와 주의력 (증분 계산, O(n))

본질: 메모리로 연산력을 산다.

왜 K/V만 캐싱하고 Q는 안 하나

메모리 3인자: 층수 × 시퀀스 길이 × 헤드 수 × 헤드 차원 × 2 × 정밀도 바이트. 롱컨텍스트에서는 가중치보다 더 먹을 수 있다.

최적화 5종(작용 차원으로 기억): 단편화 감소(PagedAttention) / 이동량 감소(FlashAttention) / 표현 압축(KV 양자화) / 시퀀스 단축(슬라이딩 윈도우) / 중복 회피(접두사 캐시).

• 어떤 중간 결과가 캐싱할 가치가 있는지는 재사용 횟수만 보면 된다 — 어떤 시스템의 캐시 설계에도 이식되는 판정 기준.
• 메모리 장부는 "정적"(가중치, 예측 가능)과 "동적"(KV Cache, 길이·동시성에 비례) 두 권으로. 가중치만 계산하면 긴 대화에서 반드시 뒤집힌다.

Tips: 용량 공식에 동시성을 반드시 포함할 것(프로덕션 OOM의 고빈도 원인). 접두사 캐시는 다중 턴·고정 시스템 프롬프트에서 수익 최대. KV 양자화(FP8/INT8)가 가성비 1위. PagedAttention은 단편화를 해결하지 총량을 줄이지 않는다. 슬라이딩 윈도우는 손실 방안.

#05. MoE는 일부 전문가만 활성화하는데 왜 메모리를 많이 먹나

핵심은 계산 희소성(Compute Sparsity)과 저장 희소성(Storage Dense)을 분리해서 말할 수 있는가이다.

순전파:    계산 희소 — 각 Token이 소수 전문가만 거침 → 1회 계산량 감소
모델 저장:  희소하지 않음 — 언제든 임의 전문가로 라우팅해야 하므로
                          배포 노드/전문가 병렬 집합 전체가 대량의 전문가 가중치를 상주

활성화 파라미터가 적다 ≠ 단일 카드 메모리가 작다.

답의 출발점은 결론이 아니라 "범위 정의" — 네 항목을 나눠서 계산할 것: 가중치 메모리 / 활성화 피크 / KV Cache / 통신 버퍼. 대입할 입력 차원: 전문가 병렬 · 배치 · 컨텍스트 길이 · 전문가 분포.

• MoE는 메모리 압박의 일부를 통신 압박으로 바꾼다 — 서로 다른 요청이 서로 다른 전문가에 적중 → 카드 간 이동 + 메모리 피크. 인기 전문가 과부하와 All-to-All 통신 병목이 시스템적 리스크.
• 메모리를 절약하는 모든 수단은 대가와 함께 견적을 낼 것 — 양자화·전문가 오프로딩 ↔ 정밀도 손실·지연 증가. 수익만 보고하는 방안은 리뷰에서 성립하지 않는다.
• 답의 신뢰도는 입력 조건에서 온다 — "각 Token이 두 전문가만 고르지만 서로 다른 요청이 서로 다른 전문가에 적중"처럼 조건이 붙어야 검증 가능한 결과가 나온다.
• 원인 규명 순서: 입력·설정·버전·중간 결과 보존 → 처음으로 이탈한 노드를 찾기 → 파라미터 조정/재시도/다운그레이드. "모델에게 한 번 더 추측하게 하기"는 복구 전략이 아니다.

Tips: "매번 전문가 몇 개"만 외우지 말고 가중치 저장 토폴로지 / Token 라우팅 전략 / 동시성 병목을 말할 것. 범위를 먼저 정하고 계산할 것. "먼저 상한에 닿는 부분"을 설계 산출물로. 지표와 버전을 같은 타임라인에.

#06. 배치 처리로 처리량을 올렸는데 왜 P99가 나빠지나

분수령은 업무 동작이 무엇인지 먼저 보는 것이다. 온라인 상담이면 지연이 하드 제약이다.

이용률 향상 ≠ 단일 사용자 체감 향상 — 배치 처리는 하드웨어 이용률을 높이지만 장단 혼재 시 서로 기다리게 되어 단일 사용자 꼬리 지연이 악화된다. 수십 token짜리 짧은 질문이 긴 문서 요약에 끌려 같은 배치에 들어간다.

해법 4종: 입출력 길이별 버킷 분리 / 최대 대기 윈도우 / 실시간·오프라인 큐 격리 / 처리량·TTFT·P95·P99를 동시에 볼 것.

3단 계측으로 귀인할 것

단계별 처방: Prefill이 느리면 입력 측 뺄셈(무관 컨텍스트 제거·온디맨드 검색·안정적 접두사 캐싱), Decode가 느리면 그다음에 출력 상한·연속 배치·양자화·추측 디코딩.

• 평균 지표는 본질적으로 긴 꼬리를 가린다 — 초당 token 수가 높을수록 시스템이 긴 요청에 봉사 중이라는 뜻일 때가 많고 짧은 요청 체감은 오히려 나빠진다.
• 온라인의 올바른 목적 함수는 "지연 경계 내 처리량 최대화" — "빠를수록 좋다"와는 다른 가치관이며 이 문제의 채점 포인트.

Tips: 먼저 버킷을 나누고 나서 배치 크기를 논할 것. 최대 대기 윈도우가 짧은 요청의 생명줄. 실시간/오프라인 큐를 물리적으로 격리. 수정은 회귀 집합에 넣고 인접 작업을 확인.

#07. GPU가 남아도는데 왜 서비스가 먼저 무너지는가 — 추론 서비스의 유령 함정

트래픽이 3배 튀어 GPU를 2배 증설했는데 타임아웃률이 1%→40%로 뛰었다. GPU 사용률 60%, 메모리 70%인데도 서비스가 먼저 죽었다 — 자원은 멀쩡한데 요청이 아직 모델에 들어가지도 못한 채 "서비스 진입 큐"에 갇혀 있었다.

핵심: 병목은 연산력이 아니라 **연산력 이전(스케줄링)**에 있다. 타임아웃은 사용자의 재시도를 부르고, 재시도는 큐를 더 길게 만드는 정방향 피드백 눈사태를 일으킨다.

3층 대응: ①업무 등급별 스케줄링(고우선 실시간 큐는 자원 독점 배정, 요청 입도 관리로 거대 요청이 소형 요청 다수를 끌고 내려가는 것 방지) ②링크 하한책(연속 배치, 요청 수 대신 token 총량/예상 계산량 기준 제한, 다단 강등) ③아키텍처 최적화(핫 문답 캐시, KV 캐시 재사용, 성수기 이전 자원 고정 — 세 수단의 시간축이 다르다).

• GPU 사용률이 낮다는 것은 병목이 없다는 뜻이 아니다 — 고동시성 진단은 반드시 대기 시간과 추론 시간을 먼저 분리해야 한다.
• 증설은 처리량을 늘릴 뿐 스케줄링을 고치지 못한다 — 스케줄링 입도가 어긋난 상태에서는 늘어난 연산력이 대기 요청에 올바르게 분배되지 못한다.
• 강등에는 계단이 있어야 한다 — 계단 없는 시스템은 "전부 좋음"과 "전부 붕괴" 두 상태만 갖는다.

Tips: 진입 큐 길이와 대기 시간을 GPU 사용률과 나란히 1급 지표로 만들 것. 단건 요청에 실행 시간 상한을 걸고 강제 종료할 것. 스케줄러 자체에도 의존성 없는 로컬 하한책을 둘 것(중앙 스케줄러가 멈추면 전체가 통제 불능에 빠진다).

#08. 추론 최적화는 왜 엔진 층부터 손대야 하는가 — 4층 우선순위

"양자화, 증류 말고 또 뭐가 있나?"에 파라미터 층 명사만 더 대면 모델을 작게 만드는 것만 말한 것이다. 실제 쟁점은 최적화가 모델 하나의 문제가 아니라 엔진·서비스·업무를 아우르는 체계의 문제인가이다.

4층 체계와 우선순위: 엔진 층 > 서비스 층 > 모델 층 > 업무 층 — 먼저 엔진과 스케줄링을 손보고, 그다음에야 모델 압축을 논한다.

• 엔진 층(가성비 1위): PagedAttention(메모리 파편 3050%↓) + Chunked Prefill(P99 지연 510배↓) + Continuous Batching(GPU 이용률 30%→85%+) 삼중 협업.
• 서비스 층: 지능형 모델 라우팅(경량 분류기로 단순/복잡 질의 분기, 비용 60%+ 절감), 시맨틱 캐시, 동적 배치.
• 모델 층(마지막 순서): 시나리오별 등급 정밀도(INT4/INT8/전정밀도) + 투기적 디코딩.
• 업무 층: 프롬프트 정제, 신뢰도 조기 종료, 비용 매립점 가시화.

네 가지 생산 치명 함정: 비용 통제 실패(스케줄링 없이 양자화만) / 지연 초과(장문 프리필이 GPU 독점) / 품질 저하(검증 없는 저정밀 양자화) / 자원 눈사태(KV Cache 무한 증가 + 정적 배치의 나무통 효과).

• 양자화는 "단일 지점 절감", 스케줄링과 메모리 관리가 "시스템 상한"을 결정한다 — 압축은 단건 비용만 낮춘다.
• 처리량 문제는 흔히 대기열 문제이지 연산력 문제가 아니다 — Continuous Batching과 PagedAttention이 이용률을 끌어올리는 이유는 연산자가 아니라 대기열과 메모리 배치를 고쳤기 때문이다.
• 우선순위 배열 자체가 실행 가능한 결론이다 — 처음부터 투자 대비 효율이 가장 낮은 모델 압축에 뛰어드는 것을 막아준다.

Tips: 각 층마다 검수 수치를 정해둘 것(메모리 −3050%, P99 −510배, 이용률 30%→85%, 라우팅 절감 60%+). 절감 동작은 반드시 품질 지표와 짝을 이뤄 나올 것. 캐시는 KV 캐시(엔진 층)와 시맨틱 캐시(서비스 층)를 섞어 말하지 말 것.

#09. 추측 디코딩은 왜 빨라지면서 답은 바뀌지 않나

"작은 모델로 추론해서 빨라졌다"는 오답이다. 추측 디코딩은 모델을 바꾸지 않는다 — 목표 모델을 그대로 둔 채 **투기(Speculate) + 검증(Verify)**으로 무손실 가속을 얻는다.

1. 초안(Draft)   목표 모델의 1/10 크기 소형 모델이 자기회귀로 K개 후보 token 생성
                 (1회 추론이 한 자릿수 저렴)
2. 검증(Verify)  목표 모델이 【같은 Forward Pass 안에서】 K개를 일괄 검증
                 자리별로 확률 분포 대조 → 일치는 채택 / 첫 불일치에서 절단
                 절단 이후는 목표 모델이 직접 생성
3. 무손실        재정권이 처음부터 끝까지 목표 모델에 있음
                 → 확률 분포 층위에서 「추측 디코딩 없이 하나씩 생성」과 등가

적중률이 유일한 기축통화

• 최적화 대상은 "직렬 단계 수"이지 "단일 단계 연산력"이 아니다 — K번의 직렬 디코딩을 1번으로 압축.
• 음의 수익 구간이 존재한다 — 틀렸을 때 초안 추론 오버헤드는 매몰 비용이며 엔드투엔드 지연이 순증. "달면 이득"이 아니라 조건부 베팅.
• 반면교사: 오프라인에서 적중률 0.8을 한 번 재고 K_VALUE = 5로 하드코딩 → 트래픽 분포가 바뀌어 적중률 30% → 에러도 알람도 없이 가속이 감속으로 조용히 퇴화.
• 좋은 가속 방안은 "자기 자신을 끄는" 능력을 갖춰야 한다 — 퇴화 가능성이 합격선.

Tips: K는 변수이지 상수가 아니다. 오프라인 1회 측정 ≠ 프로덕션 장기 결론. 등가를 먼저 증명하고 속도를 논할 것. 총 가속비가 아니라 순수익을 계산. 모니터링은 실시간 적중률 + 엔드투엔드 지연 두 곡선을 함께.

#10. 첫 글자 지연은 왜 주로 Prefill을 보나

첫 글자 지연의 90%가 Prefill에서 발생한다. Decode가 첫 token을 생성하는 데는 행렬 곱 한 번이면 되지만, Prefill은 프롬프트 전체에 대해 전량 주의력을 계산해야 한다.

4000 token 예시: Prefill은 4000×4000 주의력 행렬을 한 번에, Decode 첫 token은 4000개와 각각 한 번 → 계산량이 4000배 차이.

KV Cache가 첫 글자 지연을 바꾸는 법

• 적중 조건은 프롬프트 접두사의 글자 단위 완전 일치 — 시스템 프롬프트 수정, 안내 텍스트 삽입으로 접두사가 단절되면 적중률 0 → Prefill이 처음부터 계산으로 회귀 → 첫 글자 지연 폭증.
• 프로덕션 첫 글자 지연의 "변동"은 모델 문제가 아니라 프롬프트 조립 로직 문제인 경우가 많다.
• 전형적인 나쁜 경로: 매 요청 앞에 밀리초 타임스탬프를 붙여 접두사가 영원히 정렬되지 않음. token은 거의 안 쓰면서 4000 token 이력을 한 번도 적중 못 하게 만든다.
• 가점 요소(설정해 본 사람만 아는 것): 최소 접두사 매칭 길이 / 요청 간 Cache 공유 전략 / 긴 텍스트에서의 축출 전략.

Tips: "변수"를 프롬프트 꼬리로 몰 것. 프롬프트 조립은 결정론적으로 재현 가능해야 한다. "저장했다"를 "적중했다"로 착각하지 말 것. 모니터링 대상은 적중률이지 "Cache를 켰는가"가 아니다.

#③ 컨텍스트와 기억

#11. 컨텍스트 윈도우는 창고가 아니라 주의력 예산이다

신입은 자리가 남으면 채우고, 프로덕션에서 안정적인 Agent를 만드는 사람은 오히려 절반 이상을 지운다. 쟁점은 **컨텍스트 예산(Context Budget)**이다.

윈도우에 자리가 있는 것 ≠ 모델에게 그만큼의 주의력이 있는 것. 많이 넣을수록 많이 잃는다.

두 가지 메커니즘

1. 주의력 희석 — 주의력은 token 두 쌍 사이에서 계산되므로 token↑ → 개별 가중치↓ → 노이즈 바닥↑ → 핵심 정보가 가라앉음.
2. Lost in the Middle — 모델은 머리와 꼬리를 가장 확실히 기억하고 중간은 내용이 정확해도 자주 누락한다. 모델이 멍청해서가 아니라 롱컨텍스트의 물리 법칙.

실제 사고 1: 상담 Agent 20턴 중 중간의 "환불 신청" 한마디가 잡담에 파묻혀 작업으로 인식된 적이 없었고, 모델은 "네, 알겠습니다"만 하고 끝. 사용자가 3일 후 신고. → **주의력 희석(Attention Dilution)**의 전형.

실제 사고 2: 문서 요약 업무에서 편의상 백만 토큰 모델에 매뉴얼 전체를 한 번에 밀어 넣었다. 결과는 앞부분 핵심 규칙 완전 망각·중간 내용 착란·끝부분 답변 뒤섞임 — 윈도우 용량이 남아돌아도 위치 구분력이 함께 커지지는 않는다는 증거다. Prefill 계산량이 O(N²)이므로 비용도 함께 폭증한다.

세 개의 예산: 윈도우가 공짜라도 주의력 · 비용 · 첫 글자 지연이 함께 터진다. 프롬프트 캐시는 안정적 접두사에만 유효하며 중간 token이 바뀌면 즉시 무효·재과금.

3층 편성

정렬 법칙: 정보 밀도 · 관련성 · 역할 책임이 높을수록 앞으로. 수위선 70% 초과 시 절삭/압축 트리거.

시나리오별 취사선택: 정확한 사실 조회가 목표면 긴 컨텍스트보다 검색(RAG)이 더 적합할 수 있고, 문서 전체의 구조적 이해가 목표면 분할 후 결과 병합이나 희소 주의력(Sparse Attention) 계열 모델이 더 적합할 수 있다 — "윈도우가 크다"는 "그 작업에 맞는 도구다"를 보증하지 않는다.

• 실패가 침묵한다는 점이 진짜 위험 — 의미 층위의 실행 누락이라 일반 에러 모니터링으로 잡히지 않고 지시 실행 지표로 능동 관측해야 한다.
• 삭감은 타협이 아니라 신호 대 잡음비를 올리는 수단 — "적은 것이 곧 정확한 것".
• 윈도우 용량 ≠ 위치 구분력 — 담을 수 있는 총량이 늘어난다고 "어디에 있는 정보를 얼마나 정확히 꺼내는가"가 함께 좋아지는 것은 아니다.

Tips: 핵심 지시는 "앞으로"만이 아니라 **"격리"**할 것. 요약은 3등급(원문/요약/삭제)으로. 첫 글자 지연을 컨텍스트 팽창의 조기 지표로. 실패 모드에 이름을 붙일 것. 장문서는 분할 요약 후 병합하는 경로도 함께 검토할 것.

#12. 다중 턴 대화에서 왜 이력을 그냥 밀어 넣으면 안 되나

"컨텍스트 윈도우가 부족해서"는 한 겹만 답한 것이다. 진짜 이유는 정보 품질이다 — 담긴다 해도 노이즈가 모델을 끌어내린다(환각 증가·논리 혼란·주제 이탈).

축적되는 세 종류 노이즈: 만료된 정보(바뀐 예산·시간·선호) / 무관한 디테일(잡담·반복 확인) / 초기의 오류(폐기된 방안).

이력 3층 구조

충돌 정보 처리(가장 간과되는 고리): 예산이 10,000 → 20,000으로 바뀌었을 때, 두 숫자를 모두 주고 모델에게 추측시키지 말고 **예산: 20,000 [최신 확인] / 예산: 10,000 [실효]**로 명시할 것. 이것이 대화 상태 관리다.

• 이력은 "로그"가 아니라 "상태"로 — 채팅 기록은 append-only log, 모델이 필요로 하는 것은 현재 유효 상태. 사이에 명시적 축약 과정이 있어야 한다.
• 계층화의 본질은 "감쇠 속도"별 버킷 분리 — 시간 순서가 아니라 정보의 유효 기간으로 조직하는 것은 Agent 기억·RAG 세션·장시간 작업 재개에 그대로 이식된다.
• 모순된 정보가 누락된 정보보다 위험하다 — 없으면 추가 질문하지만 모순이 있으면 스스로 추측하고 확신에 차 있다. 시스템이 재정권을 떠맡아야 한다.
• "실효로 표기"가 "그냥 삭제"보다 낫다 — 오용을 막으면서 변경 궤적을 보존한다.
• 트러블슈팅 차원이 계층 구조에서 도출된다: 이력이 길다 / 요약이 부정확하다 / 상태가 갱신 안 됐다.

Tips: 장기 상태를 명시적 스키마로. 요약에 트리거 임계값을 둘 것(매 턴 재요약은 비싸고 드리프트를 만든다). 1층은 절대 압축 금지(지시 대상이 무효가 된다). 충돌 재정 규칙은 코드에 하드코딩.

#13. 접두사 캐시와 시맨틱 캐시의 차이

"둘 다 token을 아낀다"는 너무 거칠다. 진입점은 적중 조건 · 리스크 · 적용 시나리오 세 차원이다.

시맨틱 캐시의 네 관문(하나도 빠질 수 없음): 권한 통제 / 시간 유효성 / 지식 버전 / 유사도 임계값.

엔지니어링 함정: 타임스탬프·랜덤 ID를 프롬프트 가장 앞에 두면 접두사가 매번 달라져 캐시가 깨진다. 고정은 앞, 동적은 뒤 — 이것은 서버 최적화가 아니라 프롬프트의 구조 설계이며, 프롬프트를 쓰는 사람도 캐시 적중률에 책임이 있다.

다중 Agent 관점: 접두사(시스템 프롬프트, 도구 스키마 등)를 맞추면 서로 다른 Agent 인스턴스도 같은 KV Cache를 공유할 수 있다. 엔진이 RadixAttention/RadixTree 같은 구조로 여러 요청의 공통 접두사를 하나의 트리로 관리하면, Agent A가 이미 계산한 시스템 프롬프트의 KV를 Agent B가 재사용한다 — 단, 두 Agent의 시스템 프롬프트·도구 정의 문자열이 토큰 단위로 완전히 일치해야 한다.

• 적중 조건의 엄격성이 그것이 어느 층에 속하는지를 결정한다 — "글자 단위 일치"는 추론 엔진 안에서만, "의미가 비슷"은 벡터 검색과 임계값이 필요하므로 애플리케이션 층에서만.
• 접두사 캐시에는 정확성 리스크가 없고 시맨틱 캐시에는 있다 — 전자는 느려질 뿐이지만 후자의 오적중은 곧바로 틀린 답이다. 출시 문턱이 다른 등급.
• 프롬프트의 필드 순서는 성능 파라미터다 — "고정 앞, 동적 뒤"를 팀 규범에 명문화할 것.
• 둘은 양자택일이 아니라 서로 다른 층에 겹쳐진다.
• 다중 Agent 환경에서는 접두사 정렬 자체가 인프라 설계 항목이 된다 — Agent들의 시스템 프롬프트·도구 스키마를 의도적으로 정렬해 공유 캐시 적중률을 끌어올릴 수 있다.

Tips: "보이지 않는 동적 내용"을 경계할 것(도구 목록 순서 불안정, JSON 직렬화 순서 무작위, 템플릿의 현재 날짜). 시맨틱 캐시는 권한별 버킷 분리. 지식 버전 번호를 캐시 키에. 강한 정확성 시나리오에는 수동 다운그레이드 스위치를. 다중 Agent 배포에서는 시스템 프롬프트 템플릿을 공용 모듈로 관리해 접두사 드리프트를 방지할 것.

#④ 프롬프트 엔지니어링

#14. 프롬프트는 도대체 어떻게 쓰나 — Zero-shot / Few-shot / CoT

프롬프트를 설명하지 못하는 근본 원인은 표준 패러다임의 부재다. 하나의 점진적 사슬로 수렴한다.

동일 문제 대조("철수의 사과 5개, 2개 먹고, 남은 것의 3배를 사 왔다"): Zero-shot·Few-shot은 오답, CoT는 5-2=3 → 3×3=9 → 3+9=12로 정답.

• 핵심 변수는 "어휘 선택"이 아니라 "시범 입도" — 세 패러다임의 진짜 차이는 추론 사슬을 얼마나 보여주었는가뿐이다.
• Few-shot이 가르치는 것은 형식이지 능력이 아니다 — 추론 강화 수단으로 여기는 것이 흔한 오용이며, 형식 정렬 도구다.
• CoT의 가치는 블랙박스를 감사 가능한 중간 상태로 바꾸는 것 — 단계별 검증이 가능하고 몇 번째 단계에서 틀렸는지 특정할 수 있다. 자동 교정·단계 단위 평가에서 답 자체보다 중요.
• 선택은 논리 사슬의 길이를 보지 "어려워 보이는지"를 보지 않는다.
• 셋은 배타적이지 않고 중첩된다 — 프로덕션에서는 Few-shot + CoT가 흔하다.

Tips: 예시의 형식이 곧 계약(구두점·줄바꿈·필드 순서까지 모방한다). CoT의 각 단계는 원자 동작. "먼저 추론, 나중에 결론" 순서를 강제(반대면 사후 합리화로 퇴화). 간단한 작업에 CoT 남용은 순수 낭비.

#15. 프로덕션급 Prompt는 다섯 요소로 조립한다 — 역할부터 이상 처리까지

같은 모델, 같은 지식베이스인데 누구는 답이 정확하고, 누구는 산으로 간다. "Prompt는 화술이니 자세히 쓰면 된다"는 답은 이 변수를 여전히 "글쓰기 실력"으로 취급한다. 실제로는 모델을 미세조정하지 않고도 행동을 통제하는 유일한 저비용 수단이며, 화술이 아니라 설계도로 다뤄야 한다.

네 가지 치명 문제와 다섯 요소의 대응

발산 → 역할 정의로 막는다
포맷 붕괴 → 고정 출력 포맷으로 막는다
답변 불안정 → 명확한 과업 지시로 막는다
환각 → 엄격한 경계 제약으로 막는다
그 외 모든 예외 → 이상 처리 규칙으로 막는다

가장 날카로운 지점은 환각이다 — 지식베이스에 정답이 있어도 모델 자신의 사전학습 지식이 그것을 덮어써버릴 수 있다. RAG를 붙였다고 환각이 사라지는 것이 아니다. Prompt가 "참고 문서에 근거하라"고 명시적으로 강제하지 않는 한, 검색된 근거는 장식으로 전락한다.

• 변수가 하나로 고정된 질문에서 답은 그 하나를 가리켜야 한다 — 같은 모델·같은 지식베이스인데 품질 차이가 난다면 원인은 Prompt일 수밖에 없다.
• 네 가지 장애는 각각 빠진 제약 하나에 정확히 대응한다 — 장애 현상에서 Prompt의 어느 절이 빠졌는지를 역으로 특정할 수 있어, 디버깅이 감에 의존하는 것이 아니라 표 찾기가 된다.
• 지식베이스는 환각의 면죄부가 아니다 — "참고 문서에 근거해 답하라, 미지 내용을 날조하지 말라, 매칭 정보가 없으면 사실대로 답하라"를 명시적으로 적어 넣어야 한다.
• Prompt는 코드처럼 관리되어야 한다 — 전역 관리 + 버전 이터레이션 + 시나리오별 분리가 "한 번 잘 쓰는 것"을 "계속 잘 쓰는 것"으로 바꾼다.

Tips: 먼저 경계·포맷·이상 처리를 확정하고 나서 어투를 다듬을 것. 금지 행위는 허용 행위와 반드시 함께 쓸 것. **"맞았다 틀렸다 반복"**을 경보 신호로 취급하고, 이때는 온도 파라미터보다 먼저 명확한 과업 지시부터 되짚을 것.

#16. 프롬프트가 너무 길면 무슨 함정이 있나

"돈이 들고 시간이 걸린다"는 표층이다. 두 단어만 잡으면 된다: 주의력 희석과 물리적 캐시 병목.

【알고리즘 층】

1. 주의력 희석 — 손전등 비유: 총 광량이 고정되어 있어 조사 면적이 커지면 단위 면적당 광량이 떨어진다. 결과는 헛소리 / 제약 조건 망각 / 환각.
2. Lost in the Middle — 머리(Head)와 꼬리(Tail)는 고주목 구역, 중간의 핵심 지시는 무시되기 쉽다. 윈도우가 아무리 커도 이 분포 선호는 바뀌지 않는다.

【물리 층】 3. 캐시 병목 — 큰 캐시 공간 할당 → 시스템 동시성 압박 → 대기 중인 다른 작업도 함께 느려짐. 4. 사용자 체감과 비용 — 첫 글자 지연↑, API 청구서가 지수적으로 상승.

수렴: 프롬프트 과다는 모델 알고리즘 / 성능 표현 / 물리 자원을 동시에 압박한다.

• 계층 채점의 본질은 "몇 층까지 밀고 내려갈 수 있는가" — 현상층 → 직관층 → 기제층. 알고리즘 특성에서 물리 병목까지 내려가는 경로는 어떤 개념 문제에도 이식된다.
• 롱컨텍스트 윈도우 ≠ 롱컨텍스트 능력 — 용량과 유효 활용률은 나눠서 평가.
• 환각과 "제약 위반"은 뿌리가 같다 — 모델이 system prompt를 지키지 않기 시작하면 어휘를 고치기 전에 컨텍스트 길이부터 의심할 것.
• 긴 프롬프트의 비용은 자신에게만 떨어지지 않는다 — 멀티테넌트에서 한 사람의 긴 프롬프트는 전 시스템의 성능 문제.

Tips: 핵심 지시는 머리와 꼬리에. 마무리에서 핵심 제약을 복창시킬 것(꼬리의 높은 주목도 활용). 부하 테스트는 첫 글자 지연과 동시성 감쇠를 볼 것. 비용은 초선형으로 모델링(token 수 선형 외삽 금지).

#17. Prompt는 써놓고 끝나지 않는다 — 템플릿도 모델도 그대로인데 왜 퇴화하는가

템플릿도 모델도 파라미터도 바꾼 적이 없는데, 프로덕션의 Prompt는 시간이 지나며 서서히 나빠진다. 대다수 개발은 Prompt를 한 번 쓰고 끝나는 문안으로 취급하지만, 실제로는 지속적으로 관리해야 하는 제어 시스템이다.

4대 근본 원인: ①정적 템플릿이 입력 분포 변화에 적응하지 못함 ②긴 컨텍스트가 누적되며 제약 조건의 상대적 가중치가 희석됨 ③모델 자체의 배치·버전 갱신이 만드는 확률적 변동 ④모니터링 부재로 퇴화가 감지되지 않고 누적됨.

4대 방어선: 입력 분포 드리프트 감지 → 정기 회귀 테스트(같은 골든셋을 주기적으로 재실행) → 제약 조건 재확인 주기 배치(긴 대화일수록 핵심 규칙을 재주입) → 성능 지표 상시 모니터링(정확률·포맷 준수율·거부율의 시계열 추적).

• Prompt 품질은 배포 시점의 스냅샷이 아니라 시간에 따른 궤적이다 — 한 번 검증했다고 계속 유효한 것이 아니다.
• 긴 대화에서 제약이 희석되는 것은 버그가 아니라 주의력 희석의 필연적 결과다 — 재주입 없이는 근본적으로 해소되지 않는다.
• 모니터링 없는 시스템에서 퇴화는 사용자 불만이 쌓인 뒤에야 발견된다 — 능동 지표가 없으면 침묵 실패와 같은 경로를 밟는다.

Tips: Prompt 배포에도 코드처럼 골든셋 회귀 테스트를 CI에 넣을 것. 긴 대화는 일정 턴마다 핵심 제약을 명시적으로 재주입할 것. 모델 벤더의 무중단 업데이트(버전 고정 없는 API)를 쓴다면 정기 회귀가 필수다 — 모델이 조용히 바뀌면 프롬프트 효과도 조용히 바뀐다.

#18. Temperature는 창의력 스위치가 아니라 확률분포의 평활 계수다

프롬프트 한 글자도, 모델도 바꾼 적이 없는데 어떤 날은 답이 반듯하고 어떤 날은 산으로 간다. "Temperature = 창의력 다이얼, 0이면 엄격, 1이면 자유분방"이라는 답은 표층이다 — 이걸로는 왜 온도를 0으로 낮춰도 여전히 틀린 답이 나오는지 설명하지 못한다.

핵심: Temperature는 Softmax 이후, 샘플링 이전에만 개입하는 확률분포 평활 계수다. 모델의 추론(무엇을 아는가)에는 전혀 관여하지 않는다.

logit → (÷ Temperature) → Softmax → 확률분포 → 샘플링
                ↑
      여기서만 개입한다. 그 앞(추론)도, 그 뒤(디코딩 로직)도 아니다.

네 가지 함정: ①Temperature=0이 완전 재현을 보장하지 않는다(부동소수점 연산 순서·병렬 스케줄링 등 비결정 요인) ②전사 공통 온도값 하나로 통일하면 용도별 상반된 요구를 하나로 누르는 것 ③Temperature와 Top-P를 동시에 크게 흔들면 결과 변화의 원인 귀속이 불가능해진다 ④낮은 온도가 환각을 없애준다는 착각 — 모델 내부 지식이 틀렸으면 "확정적으로, 그러나 틀리게" 답할 뿐이다.

• Temperature는 개폐 스위치가 아니라 연속 계수다 — 업무 목표에 맞춰 구간(문답 00.2 / 요약 0.30.6 / 창작 0.7~1.0)을 고르는 것이 정답이다.
• "확정적"과 "정확함"은 서로 다른 축이다 — 온도를 낮추는 것은 분산을 줄이는 조작이지 지식 오류를 고치는 조작이 아니며, 오히려 확정적으로 재현되는 오답이 사람을 더 쉽게 속인다.
• 환각이 보이면 온도가 아니라 지식·검증 계층을 의심할 것 — 환각은 샘플링 문제가 아니라 지식·검증 문제이며 RAG와 사실 검증 계층으로만 해결된다.

Tips: 온도는 값이 아니라 등급으로 관리할 것(강확정성/중간발산/고창의 3단계). temperature=0을 캐시 키나 회귀 테스트 완전 일치 단언의 전제로 쓰지 말 것. 파라미터 변경은 Temperature 먼저, Top-P는 필요할 때만 나중에 순서를 지킬 것. 로그에 사용된 Temperature/Top-P 값을 반드시 남길 것.

#⑤ 파인튜닝과 정렬

#19. 파인튜닝은 도대체 무엇을 조정하는가

기억점: 파인튜닝은 "어떻게 답할지"를 가르치고, RAG는 "답변의 근거"를 보충한다.

4단계 의사결정

Step 1 문제 유형 판별
   외부 지식 결손(최신 자료/제도/문서) → RAG 우선, 종료
   내재 패턴 결손(스타일/형식/작업 패턴) → 계속
Step 2 데이터 (일관성 > 수량)
   세 가지 통일: 입력은? 이상적 출력은? 경계는 어떻게?
   ★ 잘못된 샘플이 섞이면 모델은 그 오류를 성실히 학습한다
Step 3 평가 (학습 loss가 아니라 실제 업무)
   형식 안정성 / 스타일 유사도 / 복잡한 경계 처리
   ★ 대조군: Prompt / RAG 대비 수익이 뚜렷한가 → 아니면 파인튜닝 포기
Step 4 출시 리스크
   수익: 목표 작업 안정  ／  대가: 일반화 능력 하락
   가드레일: 버전 롤백 + 실시간 모니터링 + 지속적 샘플 이터레이션

• 판단 기준 한 줄: "모델이 더 많이 알기를 원하는가, 내가 원하는 모습에 더 가깝게 행동하기를 원하는가?"
• 학습 loss 하락 ≠ 업무 사용 가능 — loss는 당신이 준 분포에 적합했다는 것만 말한다.
• "더 싼 대체재가 있는가"라는 대조 단계가 경제성 관문이며 엔지니어링 판단력을 가장 잘 드러낸다.
• 파인튜닝은 대가가 있는 능력 교환 — 목표 작업 안정의 대가로 일반화 능력이 떨어지므로 리스크 있는 변경으로 관리할 것.

Tips: 프로젝트 시작 시 **"바꾸려는 것이 지식인가 행동인가"**를 한 문장으로 쓸 것. 평가셋은 실제 업무 로그의 복잡한 경계 샘플에서. Prompt-only / RAG-only 대조 결과를 항상 보존.

#20. SFT와 RLHF는 무엇이 다른가

둘은 서로 다른 두 층위를 푼다: SFT는 일을 할 줄 알게, RLHF는 인간의 선호·가치관에 부합하게.

사전학습    무라벨 텍스트 → 다음 token 예측 → 「끝말잇기 기계」
   ▼
SFT        데이터: 고품질 문답 쌍(시범 데이터)
           신호: token 단위 표준 답안 (모방/지도학습)
           비유: 사부가 손을 잡고 가르침
           병목: 상한이 【라벨링 품질】에 갇혀 사부를 넘기 어려움
   ▼
RLHF       데이터: 여러 답변에 대한 인간의 【선호 순위】
           구성: 보상 모델(심판) → 답변 전체에 스칼라 점수
           비유: 제자가 자유롭게 쓰고 사부는 전체 품질로 채점
           수익: 안전성·유용성·정직성 ↑, SFT 데이터를 넘어설 수 있음

• 구분의 올바른 진입점은 "감독 신호의 형태"이지 "학습 순서"가 아니다 — token 단위 표준 답안 vs 출력 전체에 대한 스칼라 점수. "하나는 파인튜닝, 하나는 강화학습"보다 한 층 높다.
• 모방 학습의 천장 = 시범 데이터의 품질 천장 — "제자가 사부를 넘기 어렵다"의 기술적 내핵.
• "유일한 표준 답안이 없는" 작업은 본래 선호로만 최적화 가능 — 어조·안전 경계는 label로 쓸 수 없고 "A가 B보다 낫다"로만 쓸 수 있다.
• 보상 모델은 "사부의 대역"이며 인간 판단을 규모화한다 — "RLHF에서 인간은 어느 단계에 참여하는가"의 답.
• "사부를 넘어서는 것"은 공짜가 아니다 — 심판에 편향이 있으면 모델은 심판의 비위를 맞추는 법(Reward Hacking)만 배운다.

Tips: SFT 예산은 수량이 아니라 품질에. "형식/지시 준수"는 SFT, "어조/안전/가치관"은 RLHF — 도구를 잘못 쓰는 것이 흔한 낭비. 보상 기준(예의·신뢰성·환각 없음 vs 헛소리·위험·가치관 위배)을 판정 가능한 체크리스트로.

#21. 파인튜닝 7단계 완전 절차

Step 1 목표 명확화 → 「더 많이 알기」면 RAG로, 「더 비슷하게 행동」이면 계속
Step 2 데이터 준비  → 「입력 → 이상적 출력」 쌍. ★ 깨끗한 100건 > 뒤죽박죽 1만 건
                     지뢰밭 4종: 스타일 불통일 / 형식 혼란 / 오답 / 저품질 워터마크
Step 3 세정·형식화  → instruction / context / response 3단 통일
                     길이·문체·설명 포함 여부의 불일치 제거
Step 4 방식 선택    → 전량 파인튜닝 vs LoRA(PEFT)
Step 5 학습        → 학습률·배치 크기·에폭 수. ★ 처음부터 오래 학습시키지 말 것(과적합)
Step 6 평가        → 테스트셋은 학습셋과 겹치면 안 됨. 5가지 점검
Step 7 이터레이션   → 증상별 처방 후 Step 2로 순환

전량 파인튜닝 vs LoRA

평가 5점검: 형식 안정 / 스타일 부합 / 오류율 하락 / 헛소리 없음 / 범용 능력 미퇴화.

이터레이션 처방: 불안정 → 고품질 샘플 보충 / 너무 경직 → 데이터가 단일 / 헛소리 → 데이터 오류 또는 학습 과도 / 형식 오류 → 형식 예시 추가.

• 데이터 품질의 수익은 초선형 — 인력을 "데이터를 더 긁는 것"이 아니라 **"라벨링과 세정"**에 우선 투입.
• 모델은 무차별 모방기다 — 먹인 대로 학습한다 — 더러운 데이터는 희석이 아니라 오염이며, 세정에서 할 일은 "보태기"가 아니라 "지우기".
• 불일치가 오류보다 은밀하고 치명적 — 개별적으로는 "틀린" 것이 아닌 증상들이 섞이면 안정적 패턴을 배우지 못한다. 형식 통일의 본질은 학습 목표의 분산을 낮추는 것.
• 학습 시간은 양방향 리스크 — 적으면 못 배우고 많으면 과적합.
• 파인튜닝은 순환 공정이지 일회성 납품이 아니다.

Tips: "데이터 규범"을 문서로 쓰고 나서 라벨링을 시작할 것. LoRA 우선(하나의 베이스에 여러 모듈을 걸어 업무별 전환). 평가셋은 라벨링 시점에 함께 분리. "범용 능력을 희생하지 않았는가"를 필수 측정 항목으로. 헛소리 ≠ 데이터를 더 넣어야 한다는 뜻.

#부록 A · Agent 편에서 이미 다룬 LLM 주제

아래 주제들은 같은 소스 시리즈에 속하지만 Agent 심화에서 이미 한글로 정리되어 있어, 중복을 피하고 링크로 대신한다.

#부록 B · 자주 등장하는 관통 개념