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

#📑 목차

0. 전체 지도 한눈에 보기

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

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

② 추론 성능과 배포 비용

• 04. 메모리를 삼키는 주범 — KV Cache
• 05. MoE는 일부 전문가만 활성화하는데 왜 메모리를 많이 먹나
• 06. 배치 처리로 처리량을 올렸는데 왜 P99가 나빠지나
• 07. 추측 디코딩은 왜 빨라지면서 답은 바뀌지 않나
• 08. 첫 글자 지연은 왜 주로 Prefill을 보나

③ 컨텍스트와 기억

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

④ 프롬프트 엔지니어링

• 12. 프롬프트는 도대체 어떻게 쓰나 — Zero-shot / Few-shot / CoT
• 13. 프롬프트가 너무 길면 무슨 함정이 있나

⑤ 파인튜닝과 정렬

• 14. 파인튜닝은 도대체 무엇을 조정하는가
• 15. SFT와 RLHF는 무엇이 다른가
• 16. 파인튜닝 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 (시범 입도의 축)
     │        └ 길수록 주의력 희석 + 캐시 병목 + 비용 초선형
     │
⑦ 능력 변경   지식이 없으면 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 "분포에서 잘못 고르는지"**를 먼저 구분.
• 온도는 "결정성↔창의성" 다이얼이지 "똑똑함↔멍청함"이 아니다 — 창의성과 환각은 같은 뿌리.

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. 추측 디코딩은 왜 빨라지면서 답은 바뀌지 않나

"작은 모델로 추론해서 빨라졌다"는 오답이다. 추측 디코딩은 모델을 바꾸지 않는다 — 목표 모델을 그대로 둔 채 **투기(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회 측정 ≠ 프로덕션 장기 결론. 등가를 먼저 증명하고 속도를 논할 것. 총 가속비가 아니라 순수익을 계산. 모니터링은 실시간 적중률 + 엔드투엔드 지연 두 곡선을 함께.

#08. 첫 글자 지연은 왜 주로 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를 켰는가"가 아니다.

#③ 컨텍스트와 기억

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

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

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

두 가지 메커니즘

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

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

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

3층 편성

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

• 실패가 침묵한다는 점이 진짜 위험 — 의미 층위의 실행 누락이라 일반 에러 모니터링으로 잡히지 않고 지시 실행 지표로 능동 관측해야 한다.
• 삭감은 타협이 아니라 신호 대 잡음비를 올리는 수단 — "적은 것이 곧 정확한 것".

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

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

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

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

이력 3층 구조

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

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

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

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

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

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

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

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

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

#④ 프롬프트 엔지니어링

#12. 프롬프트는 도대체 어떻게 쓰나 — 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 남용은 순수 낭비.

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

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

【알고리즘 층】

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

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

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

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

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

#⑤ 파인튜닝과 정렬

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

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

4단계 의사결정

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

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

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

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

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

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

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

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

#16. 파인튜닝 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 주제

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

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