LLM도 입사하면 재교육이 필요하다
Fine-tuning의 수학부터 LoRA·DPO·GRPO, 금융권 Post-training까지
“우리 회사 문서를 학습시키면 모델이 똑똑해질까요?”라는 질문에서 출발해, Gradient Descent와 Cross Entropy부터 QLoRA, Preference Optimization, Reasoning RL, RLVR, Responsible AI, 개인정보보호까지 한 번에 내려가 본다.
어느 월요일 아침, Foundation Model 하나가 금융회사에 입사했다고 상상해보자. 세상 이야기는 놀랄 만큼 많이 안다. Python도 쓰고, 회계 용어도 알고, 보험도 설명한다. 그런데 첫 업무를 주자 문제가 생긴다.
투자 관련 표현은 이 규칙을 따르고,
내부 심사보고서는 반드시 근거와 불확실성을 구분해서 써주세요.”
이때 필요한 것이 Fine-tuning이다. 하지만 Fine-tuning을 단순히 “회사 문서를 모델에게 외우게 하는 것”이라고 이해하면 Production Architecture가 거의 반드시 꼬인다.
그래서 최신 규정이나 고객별 사실을 넣고 싶다면 RAG가 더 적합할 수 있고, 응답 방식·업무 패턴·추론 행동을 바꾸고 싶다면 Fine-tuning이 강해진다. 그리고 2026년의 Frontier는 단순 SFT를 넘어 Preference Optimization과 Reasoning RL을 포함한 Post-training으로 넓어졌다.
먼저 큰 지도부터: Pre-training 이후에 무슨 일이 벌어지는가
1. Fine-tuning의 본질: 모델에게 새 책을 주는 것이 아니다
LLM은 문장을 데이터베이스처럼 저장한 뒤 검색해서 대답하지 않는다. 현재까지 생성한 Token을 조건으로 다음 Token의 확률분포를 계산한다.
예를 들어 입력이 “고객에게 투자상품 위험을 설명할 때는”이고 회사가 원하는 답변에 “원금손실 가능성”이라는 표현이 반복적으로 등장한다면, Fine-tuning은 해당 Context에서 그 Token Sequence가 나올 확률을 조금씩 끌어올린다.
그래서 Fine-tuning을 가장 직관적으로 표현하면 이렇다.
모델이 원래 가진 세계를 통째로 다시 만드는 것이 아니라, 특정 입력 영역에서 “이쪽 답을 더 자주 선택하라”는 경사를 만든다.
2. SFT의 수학: 틀린 Token에 벌점을 주고 산을 내려간다
가장 기본적인 Supervised Fine-Tuning은 정답 Response가 주어졌을 때 그 Response의 확률을 최대화한다. 반대로 Loss 관점에서는 Negative Log Likelihood를 최소화한다.
모델이 정답 Token에 0.9의 확률을 주었다면
−log(0.9)는 작다.
0.01만 주었다면 Loss는 크게 튄다.
각 Batch에서 Backpropagation으로
∇θL,
즉 “각 Parameter를 어느 방향으로 움직여야 Loss가 줄어드는가?”를 구하고
Optimizer가 Parameter를 업데이트한다.
Loss가 잘 내려간다는 것은 Training Dataset을 잘 외워가고 있다는 뜻이지, 실제 고객 질문에 더 안전하고 정확해졌다는 뜻은 아니다.
3. 결국 Fine-tuning 성능을 결정하는 것은 Dataset이다
“GPU를 무엇을 쓸까?”부터 고민하고 싶지만, 실제 Fine-tuning 프로젝트에서 더 위험한 문제는 Dataset이다.
예를 들어 금융상담 모델을 만든다고 하자. 이런 데이터는 위험하다.
{
"user": "김OO 고객님의 대출 심사 결과를 설명해줘",
"assistant": "김OO 고객님의 주민등록번호는 ... 이고..."
}모델은 “이 값은 개인정보이니 Parameter에 저장하지 말아야지”라고 생각하지 않는다. Objective가 해당 Response의 확률을 높이라고 하면 그냥 높인다.
Prompt는 한 Request의 Context에서 끝날 수 있지만, Training Sample은 Parameter Update에 영향을 준다. 한번 학습된 특정 정보의 영향을 나중에 정확히 “한 줄만 삭제”하는 것은 단순한 Database DELETE와 전혀 다르다.
4. “우리 문서를 학습시키자” 전에 반드시 묻자: 사실 Fine-tuning이 필요한가?
| 원하는 것 | 우선 검토 | 이유 |
|---|---|---|
| 최신 규정·상품정보 답변 | RAG | Freshness · Citation · 삭제/갱신 용이 |
| 항상 정해진 JSON 포맷 | Prompt → SFT | Behavior 패턴을 Parameter에 넣기 좋음 |
| 특정 업무의 전문적인 응답 스타일 | SFT / LoRA | 많은 예제를 통한 일관된 행동 학습 |
| 좋은 답/나쁜 답의 미묘한 차이 | DPO / Preference | Pairwise preference가 자연스러운 supervision |
| 수학·코드처럼 자동 채점 가능한 추론 | RL / RLVR | Outcome reward를 이용해 탐색 가능 |
| 고객별 권한 있는 데이터 | Authorization + Retrieval | 개인정보를 Parameter에 넣는 문제와 분리 |
실무적으로는 RAG와 Fine-tuning은 경쟁자가 아니다. 꽤 자주 최종 구조는 이렇게 된다.
5. 그런데 70B Parameter를 전부 바꾸자고? 여기서 LoRA가 등장한다
Full Fine-tuning에서는 모델의 Weight 대부분 또는 전부에 Gradient를 계산하고 업데이트한다. 문제는 Parameter만 GPU에 올라가는 것이 아니라는 점이다.
LoRA는 여기서 아주 영리한 가정을 한다.
즉 Update가 Low-rank subspace에 존재한다고 보고, 거대한 ΔW를 두 개의 작은 행렬 곱으로 표현한다.
A ∈ Rr × din, B ∈ Rdout × r, r ≪ d
예를 들어 4096 × 4096짜리 Weight Matrix 하나를 생각해보자.
이 한 행렬만 놓고 보면 약 128배 적은 Parameter를 학습한다. 실제 Transformer 전체에서는 어느 Layer와 Projection에 LoRA를 넣는지에 따라 비율이 달라진다.
6. QLoRA: “얼린 모델이면 4-bit로 눌러도 되지 않을까?”
LoRA를 써도 Base Model 자체는 GPU Memory를 차지한다. QLoRA는 한 단계 더 간다.
Gradient는 그 Base Model을 통과시키되 실제 Update는 LoRA Adapter에만 적용한다.
QLoRA 논문은 NF4(NormalFloat 4-bit), Double Quantization, Paged Optimizer를 조합해 큰 모델의 Fine-tuning Memory를 크게 줄이는 방법을 보였다.
중요한 것은 “QLoRA가 Full FT보다 무조건 좋다”가 아니다. 제한된 GPU에서 매우 강력한 현실적 선택지지만, Task가 Base Model과 크게 다르거나 대규모 Domain Adaptation이 필요하면 Low-rank 제약 자체가 Bottleneck이 될 수 있다.
7. 2026년 LoRA는 하나의 기법이라기보다 ‘가족’이 됐다
| 기법 | 아이디어 | 언제 흥미로운가 |
|---|---|---|
| LoRA | ΔW = BA | 기본값. 단순하고 Serving 지원이 좋다. |
| rsLoRA | Rank 증가 시 scaling을 α/√r 형태로 안정화 | 높은 rank를 실험할 때 |
| DoRA | Weight의 magnitude와 direction을 분리 | LoRA와 Full FT의 품질 격차를 줄이고 싶을 때 |
| LoftQ | Quantization과 LoRA initialization을 함께 고려 | 낮은 bit Quantization error가 큰 경우 |
| Activated LoRA | 특정 invocation 이후 Adapter 활성화 | Agent workflow의 shared prefix/KV cache 최적화 |
최신 PEFT 연구의 방향은 “더 작은 Adapter” 하나로 수렴한다기보다 초기화, Rank allocation, Quantization, Serving까지 함께 최적화하는 방향이다. 학습 알고리즘과 Serving Architecture를 분리해서 생각하기 어려워지고 있다.
그리고 Production에서는 Multi-LoRA가 꽤 재미있다
하나의 Base Model 위에 보험 Adapter, 카드 Adapter, 내부 SQL Adapter처럼 작은 Adapter를 여러 개 얹을 수 있다. 최신 vLLM 계열 Serving Stack은 Request 단위 LoRA Adapter Serving을 지원한다.
vllm serve BaseModel \
--enable-lora \
--lora-modules \
insurance=/models/insurance-lora \
sql=/models/sql-lora \
--max-lora-rank 64이것은 GPU 하나에서 여러 업무 변형을 운영할 때 매력적이다. 대신 Adapter 수가 늘어나면 이제 새로운 문제가 생긴다.
“marketing-v3-final-final2”, “risk-v7-new” 같은 Adapter가 수십 개 생기기 시작하면 Parameter 비용보다 Version Governance 비용이 더 커진다. Base Model version → Dataset version → Adapter version → Eval result → Deployment를 하나의 lineage로 관리해야 한다.
8. 실제로 LoRA SFT를 돌리면 코드는 의외로 짧다
Hugging Face TRL + PEFT 조합이라면 핵심 코드는 꽤 단순하다.
from peft import LoraConfig
from trl import SFTTrainer, SFTConfig
peft_config = LoraConfig(
r=16,
lora_alpha=32,
lora_dropout=0.05,
target_modules="all-linear",
bias="none",
task_type="CAUSAL_LM",
)
training_args = SFTConfig(
learning_rate=2e-4,
num_train_epochs=2,
per_device_train_batch_size=2,
gradient_accumulation_steps=8,
bf16=True,
logging_steps=10,
)
trainer = SFTTrainer(
model="your-base-model",
train_dataset=train_dataset,
eval_dataset=validation_dataset,
peft_config=peft_config,
args=training_args,
)
trainer.train()그런데 코드가 짧다고 프로젝트가 쉬운 것은 아니다. Production에서는 위 코드보다 아래 정보가 훨씬 중요하다.
training_run:
base_model: "base-model@sha256:..."
dataset_version: "credit-copilot-sft-v12"
dataset_hash: "sha256:..."
pii_scan_result: "PASS"
legal_basis_review: "APPROVED"
code_commit: "git:8f30..."
lora:
rank: 16
alpha: 32
target_modules: "all-linear"
eval_suite: "credit-copilot-eval-v8"
approver: "model-risk-committee"
deploy_status: "shadow-only"기업에서 Fine-tuning은 Machine Learning Experiment가 아니라 변경관리(Change Management)다.
9. 그런데 “정답 한 개”를 만들기 어려운 업무가 있다
고객에게 규정 내용을 설명하는 두 답변을 보자.
“투자는 위험할 수 있습니다. 자세한 내용은 약관을 확인하세요.”
“이 상품은 원금손실 가능성이 있습니다. 특히 해당 조건에서는 손실 범위가 달라질 수 있으므로 근거 문서의 위험등급과 적용일을 확인해야 합니다.”
둘 다 문법적으로 맞다. 중요한 것은 B가 A보다 낫다는 판단이다. 여기서 Preference Learning이 시작된다.
Reward Model은 무엇을 배우는가?
전통적인 RLHF에서는 사람이 y+가 y−보다 좋다고 선택한 데이터를 이용해 Reward Model을 학습한다.
좋은 답의 Reward가 나쁜 답보다 높아지도록 학습하는 Bradley-Terry 형태의 Pairwise Loss다.
이후 Policy는 대략 이런 목적을 최적화한다.
Reward만 무작정 키우면 모델이 Reward Model의 허점을 찾아 이상한 행동을 할 수 있다. 그래서 Reference Model에서 너무 멀리 벗어나지 않도록 KL Penalty를 둔다.
10. DPO: “Reward Model과 PPO를 꼭 따로 돌려야 하나?”
DPO의 매력은 복잡한 RLHF 문제를 Preference Classification과 비슷한 Loss로 바꾼 데 있다.
− log πθ(y−|x) + log πref(y−|x) ] }
복잡해 보이지만 의미는 간단하다.
chosen 답의 확률은 상대적으로 더 올리고,
rejected 답의 확률은 상대적으로 덜 올리거나 내린다.
별도의 Reward Model을 학습하고 PPO Rollout을 돌리지 않아도 된다는 것이 큰 장점이다.
{
"prompt": "투자 위험을 고객에게 설명하세요.",
"chosen": "원금손실 가능성과 적용 조건을 먼저 설명하고 근거를 제시합니다.",
"rejected": "안전한 상품이므로 걱정하지 않아도 됩니다."
}금융권에서는 이런 Preference Data가 오히려 SFT 정답보다 만들기 쉬울 때도 있다. 현업 전문가에게 “완벽한 답을 처음부터 써주세요”라고 요청하는 것보다, “A와 B 중 어느 답이 내부 원칙에 더 맞습니까?”라고 묻는 편이 일관된 라벨을 얻기 쉽기 때문이다.
DPO 이후에는 Preference Optimization도 폭발적으로 분화했다
| 방법 | 핵심 | 데이터 관점 |
|---|---|---|
| DPO | Reference 대비 Pairwise Preference | chosen / rejected Pair |
| KTO | Prospect-theoretic utility | desirable / undesirable 같은 binary feedback도 활용 |
| ORPO | SFT와 preference penalty를 한 objective로 | Reference model 없이 단순화 |
| SimPO | Reference-free preference reward | Pairwise preference |
기업 프로젝트에서 Preference Optimization의 선택 기준은 “논문 Leaderboard에서 누가 1등인가?”보다 우리가 실제로 어떤 Feedback Data를 안정적으로 만들 수 있는가가 먼저다.
11. 그리고 판이 다시 바뀌었다: Reasoning Model과 Reinforcement Learning
2024~2026년 Post-training에서 가장 큰 변화 중 하나는 “좋아 보이는 답”을 고르는 Alignment에서 “실제로 문제를 풀어내는 Reasoning을 Reward로 학습”하는 방향의 부상이다.
수학 문제라면 답이 맞았는지 프로그램으로 확인할 수 있다. 코드라면 Test를 돌릴 수 있다. SQL이라면 Query 결과를 비교할 수 있다.
이것이 Reinforcement Learning with Verifiable Rewards, RLVR가 강력한 이유다.
GRPO의 직관: 혼자 시험 보지 말고 같은 문제를 여러 번 풀린다
PPO 계열에서는 별도 Value Model이 Advantage를 추정하는 데 쓰인다. GRPO 계열 접근은 같은 Prompt에서 여러 Response를 Sample한 뒤 Group 안에서 상대적으로 얼마나 잘했는가를 이용해 Advantage를 구성한다.
DeepSeek-R1 계열 연구가 GRPO 기반 RL을 대중적으로 알렸고, 이후 DAPO, Dr. GRPO 등 Optimization 안정성·Length Bias·Sampling 문제를 다루는 연구가 이어졌다.
DeepSeek-R1-Zero가 던진 재미있는 질문
“SFT로 Reasoning Example을 먼저 보여주지 않고, 정답 Reward만 줘도 Reasoning Behavior가 나타날까?”
R1-Zero는 대규모 RL만으로 흥미로운 Reasoning Behavior가 등장할 수 있음을 보여주었다. 그런데 문제가 있었다. 가독성이 떨어지고 언어가 섞이는 현상 등이 나타났다.
그래서 실제 DeepSeek-R1 Training Recipe는 Cold-start Data, SFT, RL 등의 여러 단계를 결합했다.
“RL이 등장했으니 이제 SFT는 구식”이 아니다. 최근 Reasoning Model들도 오히려 SFT와 RL을 역할에 맞게 조합한다.
12. 2025~2026 최신 Post-training 연구에서 읽히는 흐름
| 흐름 | 무슨 변화인가 | 기업 입장에서의 의미 |
|---|---|---|
| Post-training Scaling | Pre-training 외에 RL compute 자체를 성능 축으로 확장 | Model 선택보다 Training/Eval Loop 역량이 중요해짐 |
| RLVR | 자동 검증 가능한 Reward로 Reasoning 학습 | SQL·정형계산·Code·Rule engine 업무와 궁합이 좋음 |
| Long → Short Distillation | 긴 Reasoning Model의 능력을 더 작은/짧은 모델로 이전 | Latency·Inference Cost 최적화 가능성 |
| Online RL | 현재 Policy가 생성한 Sample로 반복 개선 | Offline Dataset distribution shift를 줄이지만 운영 복잡도 증가 |
| Efficient PEFT | LoRA + Quantization + Serving 최적화 | 업무별 Adapter와 Smaller Model 전략이 현실적 |
| Reasoning Evaluation | Final answer만 맞는다고 reasoning이 올바른 것은 아니라는 비판 | CoT를 감사 가능한 설명으로 착각하면 안 됨 |
2026년에 특히 중요한 경고: 정답 Reward ≠ 올바른 Reasoning
RLVR에서는 마지막 답이 맞으면 Reward 1, 틀리면 0을 줄 수 있다. 매우 편하다.
그런데 2026년 연구들은 이 전제를 더 비판적으로 보기 시작했다. Outcome Accuracy가 올라갔다고 해서 중간 Reasoning이 실제로 결과에 인과적으로 기여하거나, 그 Reasoning만으로 답을 재현할 수 있다고 보장할 수 없다는 것이다.
모델의 Chain-of-Thought가 길고 논리적으로 보인다고 해서 그것을 감사 가능한 의사결정 근거로 사용해서는 안 된다.
Audit Trail은 별도로 입력 데이터 · 사용 규칙 · 검색 근거 · 계산 결과 · Tool 실행 로그 · 최종 승인자로 구성하는 편이 안전하다.
금융 분야 자체에서도 SFT + GRPO 연구가 등장했다
예를 들어 Fin-R1 연구는 금융 추론 데이터를 구성하고 SFT 이후 GRPO를 적용하는 Domain-specific Reasoning 접근을 실험했다.
이런 연구는 금융 Domain에도 Reasoning Post-training을 적용할 수 있다는 점에서 흥미롭다. 다만 Benchmark 결과와 실제 금융 Production 안전성은 완전히 다른 문제다.
FinQA 같은 Benchmark를 잘 푼다는 사실은 개인정보 처리, 고객별 권한, 설명 의무, 편향, Model Risk, 정책 변경, 장애 대응까지 통과했다는 뜻이 아니다.
13. 이제 기업으로 가져와보자: Fine-tuning은 어떤 Architecture로 운영해야 할까?
금융회사의 “대출 심사보고서 작성 Copilot”을 예로 들어보자. 여기서 중요한 전제는 LLM이 대출 승인 여부를 독자적으로 결정하는 시스템이 아니라 분석가를 보조하는 시스템이라는 것이다.
14. 금융권 첫 번째 벽: Data Privacy — 개인정보를 학습시키고 나면 무슨 일이 벌어지는가
생성형 AI 개인정보 문제에서 가장 위험한 질문은 “Cloud Provider가 우리 데이터를 학습에 쓰나요?” 하나가 아니다.
더 앞단에서 물어야 한다.
개인정보보호 관점에서는 최소한 다음 흐름이 필요하다.
왜 필요한가?
처리 근거
PII 제거
격리된 환경
Leakage test
삭제·감사
국내 개인정보보호위원회의 생성형 AI 개인정보 안내 역시 목적 설정 → 전략 수립 → AI 학습·개발 → 시스템 적용·관리 등 생애주기 관점에서 개인정보 문제를 보도록 한다.
“암호화해서 학습하면 개인정보는 괜찮지 않나요?”
Encryption at rest와 TLS는 매우 중요하다. 하지만 이것은 저장·전송 경로 보호다. 모델이 Training Example을 Memorize하는 위험과는 다른 문제다.
민감한 String이 Training Dataset에 들어갔다면 특정 Prompt에 의해 그 정보가 재생산될 가능성을 별도로 평가해야 한다.
LLM에게 전달된 순간 이미 데이터 접근은 발생한 것이다. “학습한 뒤 Prompt로 출력하지 말라고 하면 된다”는 것은 Privacy Control이 아니다.
Differential Privacy는 해답일까?
한 가지 기술적 선택지는 DP-SGD 같은 Differentially Private Training이다. 개별 Example의 Gradient 영향을 제한하고 Noise를 추가한다.
각 Sample의 Gradient norm을 C 이하로 Clip하고 Gaussian Noise를 더한다. Privacy Guarantee를 정량화할 수 있다는 장점이 있지만, Noise가 커질수록 Model Utility가 떨어질 수 있고 대규모 LLM Training 비용도 만만치 않다.
따라서 금융권에서는 보통 “민감정보를 최대한 학습하지 않는 Data Minimization”이 1차 방어선이고 DP는 Risk Profile에 따라 검토할 추가 수단으로 보는 편이 현실적이다.
15. Responsible AI: Fine-tuning은 Bias도 같이 Fine-tuning한다
Fine-tuning Dataset이 특정 고객군, 특정 상품, 특정 유형의 성공 사례에 편중돼 있다면 모델의 행동 역시 그 방향으로 이동한다.
예를 들어 대출 관련 Copilot의 Historical Dataset이 과거의 의사결정 패턴을 그대로 포함한다면, 과거의 편향도 Domain Knowledge처럼 학습될 수 있다.
무엇을 반복해서 좋은 Example로 넣느냐가 결국 모델에게 “이 조직에서는 이것이 좋은 행동이다”라고 가르친다.
그래서 Overall Accuracy 하나가 아니라 가능한 경우 업무적으로 타당한 Group별 Error Rate, Refusal Rate, Escalation Rate, Counterfactual Test 등을 함께 봐야 한다.
Demographic parity, equalized odds 등은 서로 다른 정책적 의미를 가진다. 어떤 Metric을 써야 하는지는 Use Case와 법적·업무적 맥락에 따라 결정해야 한다.
16. 2026년 국내 금융권 AI 가이드라인을 Fine-tuning 관점에서 읽으면
금융위원회가 2026년 개정해 시행한 금융분야 인공지능 가이드라인은 7개 원칙을 제시한다. Fine-tuning Pipeline에 연결해보면 상당히 구체적인 Engineering Requirement로 바뀐다.
| 원칙 | Fine-tuning에서의 질문 |
|---|---|
| ① 거버넌스 | 누가 Dataset·Model·Deployment 변경을 승인하는가? |
| ② 합법성 | Training Data 수집·사용의 법적 근거는 무엇인가? |
| ③ 보조수단성 | 모델이 최종 판단을 대신하고 있지 않은가? Human Intervention은 어디에 있는가? |
| ④ 신뢰성 | Dataset·Base Model·Fine-tuned Model을 어떻게 검증했는가? |
| ⑤ 금융안정성 | 대규모 동일 Model 오류가 조직 전체에 전파될 위험은? |
| ⑥ 신의성실 | 고객 이익에 반하는 Response Pattern을 학습시키고 있지 않은가? |
| ⑦ 보안성 | Training Data·Model Artifact·Endpoint를 어떻게 보호하고 모니터링하는가? |
특히 보조수단성은 LLM Fine-tuning 프로젝트에서 매우 중요한 설계 원칙이다. 모델을 아무리 잘 Fine-tune해도 업무의 최종 책임 구조까지 Parameter에 Outsourcing할 수는 없다.
17. Model Risk: Fine-tuned Model은 ‘새 모델’로 취급해야 하는가?
Engineering 관점에서는 그렇다고 보는 편이 안전하다. Base Model이 같아도 Dataset과 Objective가 바뀌면 Behavior가 달라진다.
그래서 최소한 다음은 추적해야 한다.
ID · version · license
version · hash · provenance
code · seed · hyperparameter
suite · threshold · reviewer
endpoint · traffic · rollback
failure · remediation · re-eval
18. Security: Model Artifact도 Supply Chain이다
Fine-tuning Security를 Network Security로만 보면 절반만 본 것이다.
| Risk | 예 | Control |
|---|---|---|
| Data Poisoning | 악성 Training Example 삽입 | Source allow-list · review · anomaly detection |
| Backdoor | 특정 Trigger에서 숨은 행동 | Trigger test · red team · provenance |
| Model Theft | Adapter artifact 유출 | IAM · encryption · artifact signing |
| Memorization | Training PII 재생산 | Data minimization · extraction eval |
| Dependency Risk | Training package / image compromise | SBOM · pinned image · vulnerability scan |
Managed Fine-tuning을 쓴다면 IAM, Network, Encryption도 제품 기능을 확인해야 한다. 예를 들어 현재 주요 Managed Platform들은 Fine-tuning Data 접근 권한, Encryption, Private Networking과 같은 수단을 제공하지만 지원 방식과 대상 모델·Region은 서비스마다 다르다.
19. Managed Fine-tuning vs Self-hosted: 누가 더 좋은가?
서로 다른 Layer다. “Managed가 안전하다” 또는 “Open Source가 통제력이 있으니 무조건 안전하다”라고 단정할 수 없다.
| Managed Customization | Self-hosted / Open Source | |
|---|---|---|
| 구축 | 빠름 | Training stack 직접 구성 |
| GPU 운영 | Provider가 상당 부분 관리 | Capacity · Driver · Failure 직접 책임 |
| Algorithm Control | 지원 범위 내 | TRL · PEFT · verl 등 높은 자유도 |
| Data Boundary | 서비스 Data Policy·Region·Network 확인 | 자체 VPC/On-prem 통제 가능 |
| Lock-in | 상대적으로 높을 수 있음 | Portable하지만 운영 Stack 의존성 존재 |
| 추천 조건 | 빠른 도입 · 제한된 Platform 인력 | 폐쇄망 · Algorithm Control · 대규모 반복 학습 |
예를 들어 Microsoft Foundry는 현재 모델별로 SFT, DPO, RFT 등을 지원하며 모델과 Region에 따라 GA/Preview 상태가 다르다. Amazon Bedrock 역시 Model Customization에서 SFT와 RL 계열 Customization을 제공하며 IAM, S3, KMS, VPC 설정을 결합할 수 있다.
따라서 Procurement Checklist에는 단순히 “Fine-tuning 지원: Yes”라고 쓰면 부족하다.
지원 Model/version · Region · Training Data retention · Provider training 사용 여부 · Network path · CMK 지원 · RBAC · Training/Deploy 권한 분리 · Log · Artifact ownership · Base model deprecation 정책 · Export 가능 여부
20. Production에서는 Training Loss보다 Eval System이 더 중요하다
Fine-tuned Model의 Training Loss가 20% 떨어졌다. 축하할 일일 수 있다. 그러나 배포 승인 조건으로는 부족하다.
금융권 Fine-tuning Eval은 최소한 여러 축으로 나눠 보는 편이 좋다.
정확도 · completeness · structured output
근거 일치 · citation correctness
PII extraction · memorization probe
group errors · harmful recommendation
prompt variation · adversarial cases
P95 · cost · timeout · throughput
21. Fine-tuned Model을 바로 100% Traffic에 붙이지 않는다
모든 단계에 Rollback 가능한 이전 Model Version을 유지한다.
특히 Fine-tuning에서는 “새 버전이 새 업무에서는 좋아졌는데, 기존 업무를 망가뜨리는” Catastrophic Forgetting 또는 Regression이 나타날 수 있다.
따라서 Eval Set은 Fine-tuning 대상 업무만 포함하면 안 된다. Base Model에서 반드시 유지해야 하는 기존 Capability Set도 함께 넣어야 한다.
22. Fine-tuning은 비용을 늘리기도 하지만, 잘 쓰면 Inference 비용을 줄인다
Fine-tuning은 Training GPU 비용이 발생한다. 그런데 이것만 보면 경제성을 잘못 계산한다.
예를 들어 기존에는 큰 모델에 매 요청마다 3,000 Token짜리 Few-shot Prompt를 넣어야 했다면, SFT 후 훨씬 짧은 Prompt로 같은 행동을 만들 수 있다.
또는 70B Model을 Prompt Engineering으로 억지로 사용하던 업무가 잘 Fine-tune된 8B/14B Model로 내려갈 수도 있다. 이 경우 Training Cost를 지불하고 장기간의 Serving Cost와 Latency를 줄이는 교환이 가능하다.
특히 Adapter를 수십 개 운영하면 GPU 비용보다 Eval·Approval·Versioning 비용이 커질 수 있다는 점도 AI FinOps에 포함해야 한다.
23. 그래서 뭘 선택해야 할까? 현실적인 Decision Matrix
| 조건 | Prompt | RAG | LoRA/SFT | DPO | RLVR |
|---|---|---|---|---|---|
| 빠른 PoC | ◎ | ○ | △ | △ | × |
| 최신 지식 | △ | ◎ | × | × | × |
| 응답 형식/스타일 | ○ | △ | ◎ | ○ | △ |
| 미묘한 선호 | △ | × | ○ | ◎ | ○ |
| 자동 채점 가능한 추론 | △ | △ | ○ | ○ | ◎ |
| 운영 복잡도 | 낮음 | 중간 | 중간 | 중~높음 | 높음 |
24. 기업 Fine-tuning 프로젝트는 이 순서로 시작하는 편이 현실적이다
오히려 Fine-tuning을 하지 않는 것이 좋은 경우
- 문제가 최신 정보 부족인데 RAG를 아직 제대로 만들지 않았다.
- 좋은 Training Example을 정의할 전문가가 없다.
- 개인정보·저작권·Provenance가 불명확한 데이터를 대량으로 넣으려 한다.
- Offline Eval Set도 없이 “Training Loss가 내려갔으니 좋아졌겠지”라고 배포하려 한다.
- Reward를 정확히 정의할 수 없는데 Reasoning RL부터 하고 싶다.
- Base Model이 바뀔 때 Adapter 재검증·재학습을 운영할 조직이 없다.
마지막으로 다시 신입사원 이야기로 돌아가자
첫날의 Foundation Model은 세상 지식은 많았지만 우리 회사가 어떻게 일하는지는 몰랐다.
SFT는 좋은 선배의 답안지를 보여줬다.
LoRA는 뇌 전체를 다시 만들지 않고 필요한 습관만 가볍게 붙였다.
DPO는 “이 답보다 저 답이 낫다”는 조직의 선호를 가르쳤다.
RL은 결과를 보고 스스로 더 나은 풀이 전략을 탐색하게 했다.
그런데 금융회사에서 마지막으로 필요한 것은 또 하나다.
무엇을 가르쳐도 되는지 결정하고,
무엇을 배웠는지 검증하고,
잘못 배웠을 때 되돌리는 시스템을 만드는 일이다.
그래서 Fine-tuning의 경쟁력은 GPU 개수나 LoRA rank에서 끝나지 않는다. Dataset Governance, Eval, Security, Privacy, Model Risk, Serving, Rollback까지 연결할 수 있어야 비로소 Production 기술이 된다.
References · Papers & Official Docs
- Hu et al. — LoRA: Low-Rank Adaptation of Large Language Models, 2021, arXiv:2106.09685
- Dettmers et al. — QLoRA: Efficient Finetuning of Quantized LLMs, 2023, arXiv:2305.14314
- Li et al. — LoftQ: LoRA-Fine-Tuning-Aware Quantization for Large Language Models, 2023
- Liu et al. — DoRA: Weight-Decomposed Low-Rank Adaptation, 2024
- Rafailov et al. — Direct Preference Optimization: Your Language Model is Secretly a Reward Model, 2023
- Ethayarajh et al. — KTO: Model Alignment as Prospect Theoretic Optimization, 2024
- Hong et al. — ORPO: Monolithic Preference Optimization without Reference Model, 2024
- Meng et al. — SimPO: Simple Preference Optimization with a Reference-Free Reward, 2024
- DeepSeek-AI — DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025
- Kimi Team — Kimi k1.5: Scaling Reinforcement Learning with LLMs, 2025
- Yu et al. — DAPO: An Open-Source LLM Reinforcement Learning System at Scale, 2025
- Yu et al. — Outcome Rewards Do Not Guarantee Verifiable or Causally Important Reasoning, 2026
- Hugging Face — PEFT / TRL SFTTrainer / DPOTrainer / GRPOTrainer Documentation
- vLLM — LoRA Adapters Documentation, 2026
- NIST — AI Risk Management Framework: Generative Artificial Intelligence Profile
- 개인정보보호위원회 — 생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서, 2025.8
- 금융위원회 — 금융분야 인공지능 가이드라인 개정안, 2026
- European Commission — Guidelines for Providers of General-Purpose AI Models under the AI Act
- Microsoft Foundry — Fine-tuning / DPO / RFT Documentation
- Amazon Bedrock — Model Customization / Encryption / VPC Security Documentation
'LLM' 카테고리의 다른 글
| [LLM] AI 모델도 ‘과외’를 받는다그런데 답안지를 1,600만 번 긁어가면? LLM Distillation 완전정복 (1) | 2026.09.10 |
|---|---|
| [LLM] GPT-6 Astra 등장! GPT-5.6과 무엇이 달라졌을까? (0) | 2026.09.08 |
| [AI] Claude Pro 결제했다. 이제 진짜 뽕 뽑아보자! (0) | 2026.09.06 |
| [LLM] 왜 “정확히 이렇게 해줘”라고 하면 AI가 말을 잘 들을까? Prompt Engineering의 확률적 정체 (1) | 2026.09.05 |
| [LLM] 콜센터에 AI를 심어보자 — STT부터 RAG, Agent Assist까지 실시간 상담 Copilot Deep Dive (0) | 2026.09.04 |