서론

"도메인 지식을 파인튜닝(Fine-Tuning)으로 학습시키겠습니다" ── AI 프로젝트 미팅에서 이런 발언을 들어본 엔지니어가 많을 것이라 생각합니다.

여기서 위화감을 느낄 수 있느냐 없느냐는 LLM의 학습 방식에 깊이 파고든 경험이 있는지에 따라 갈립니다. 실제로, **파인튜닝 (FT)**과 **계속 사전 학습 (CPT: Continual Pre-Training)**은 목적도 구현도 별개의 것이지만, 현장에서는 둘 다 "학습"이라고 묶어서 부르며 혼동되는 상황을 자주 목격하게 됩니다.

이 기사에서는 양자의 차이를 손실 함수(Loss Function)・데이터・학습 대상의 3가지 관점에서 정리하고, "어느 쪽을 선택해야 하는가"에 대한 판단 흐름을 구현 관점에서 정리합니다. LLM 프로젝트에서 기술 선정을 하고 계신 분, 벤더의 제안에 질문을 던져야 하는 엔지니어분들에게 참고가 된다면 좋겠습니다.

참고로, 경영자·발주자용 판단 흐름 버전은 별도의 기사인 「파인튜닝을 제안받은 경영자를 위한 판단 흐름 실전 가이드」에 작성했습니다. 본 기사는 그 기술 버전입니다.

결론 먼저 보기

"FT는 CPT의 대안이 될 수 없다", "CPT는 FT의 대안이 될 수 없다" ── 양자는 목적이 다르므로 대체 관계가 아니다라는 것이 본 기사의 핵심입니다.

1. 손실 함수의 차이

CPT: 다음 토큰 예측의 연장선

CPT는 사전 학습 (Pre-Training)의 연장선상에 있습니다. 손실 함수도 동일한 causal language modeling loss입니다.

여기서 다음 토큰을 예측할 확률을 최대화한다. 그것뿐입니다.

구현 측면에서는 HuggingFace라면 DataCollatorForLanguageModeling(mlm=False)를 사용하여 Trainer에 전달하는 흐름이 됩니다.

from transformers import (
AutoModelForCausalLM, AutoTokenizer,
DataCollatorForLanguageModeling, Trainer, TrainingArguments,
...

포인트는 **"라벨(Label)이 존재하지 않는다"**는 점입니다. 텍스트 자체가 교사 신호(Teacher Signal)가 됩니다.

FT: 태스크 고유의 손실

반면, FT 중 가장 일반적인 **Supervised Fine-Tuning (SFT)**는 (input, output) 쌍을 이용한 지도 학습입니다. 손실은 여전히 next-token prediction 형태를 취하지만, output 부분에 대해서만 손실을 계산합니다 (input 부분은 마스킹 처리).

구현 측면에서는:

def format_example(ex):
prompt = ex["instruction"]
response = ex["response"]
...

labels[:, :prompt_len] = -100을 통해 프롬프트 부분의 손실을 무시하는 것이 SFT의 본질적인 구현 포인트입니다. 이를 통해 "특정 입력에 대한 특정 응답을 생성할" 확률을 높이도록 학습됩니다.

더 나아간 기법(DPO, RLHF)에서는 선호하는 응답과 선호하지 않는 응답의 쌍으로부터 보상 모델(Reward Model)을 학습하고, 이를 사용하여 강화 학습을 수행하는 형태가 되지만, 본 기사의 범위에서는 제외합니다.

2. 데이터 성질의 차이

CPT의 데이터: 비지도 방식의 Raw 텍스트

CPT에 필요한 것은 대량의 Raw 텍스트입니다.

• 업계 매뉴얼
• 논문·기술서
• 과거 사내 문서
• 업계 용어집 (설명 포함)

라벨은 필요하지 않습니다. 텍스트 속에서 **「다음에 무엇이 올 것인가」가 학습 신호 (Learning Signal)**가 됩니다. 이를 통해 모델은 「의료 용어 문맥에서의 자연스러운 이어짐」, 「업계 특유의 말투」를 습득합니다.

데이터량의 기준: 논문 기반이라면 수백 MB ~ 수십 GB가 하나의 기준선입니다. 이보다 적으면 모델이 새로운 도메인에 수렴하기 전에 과적합 (Overfitting)됩니다.

FT의 데이터: 지도 학습 방식의 input-output 쌍

SFT에는 (instruction, response)

또는 (input, output)

의 **명시적인 쌍 (Explicit Pair)**이 필요합니다.

{"instruction": "다음 증례를 요약해 주세요: ...", "response": "증례 요약은..."}
{"instruction": "이 계약서의 리스크 조항을 추출해 주세요: ...", "response": "리스크 조항은 다음 세 가지입니다..."}

데이터량의 기준: 수백 ~ 수만 건. LoRA를 사용한 경량 FT라면 수백 건만으로도 특정 태스크에 적응할 수 있습니다.

중요한 점: 데이터의 「종류」가 다르다

이 부분이 현장에서 가장 혼동되는 부분입니다.

「의료 데이터를 사용하여 모델에 지식을 기억시킨다」라고 말할 때,

• 의료 논문을 생텍스트 (Raw Text)로 학습시킨다 $\rightarrow$ CPT
• 「증상 A는 병명 B」와 같은 QA 쌍을 만들어 학습시킨다 $\rightarrow$ FT (SFT)

두 방식은 완전히 다른 접근 방식입니다. 전자가 「의료 언어 공간을 획득하는 것」이라면, 후자는 「QA 태스크에서 정답을 내도록」 학습하는 것입니다.

FT로 의료 논문의 생텍스트를 학습시키려 하면 데이터 형식이 맞지 않습니다. input-output 쌍으로 변환해야 하며, 그 과정에서 생텍스트의 정보 밀도는 대폭 떨어집니다. 이것이 「FT로 도메인 지식을 기억시킨다」는 말이 실제로는 기능하기 어려운 기술적인 이유입니다.

3. 학습 대상의 차이

CPT와 FT 모두, Full로 돌릴지 혹은 LoRA나 QLoRA를 사용할지에 따라 규모가 달라집니다. 「학습한다」 = 「전체 파라미터를 업데이트한다」가 아님에 주의하십시오.

주의: Full CPT와 Full SFT는 계산 비용의 단위 측면에서 거의 동등합니다. 오히려 SFT는 지도 학습 데이터 생성 비용 (수작업 어노테이션 · 품질 체크 · 편향 제거)이 커지기 쉬우며, 총비용 측면에서는 SFT가 CPT보다 더 많이 드는 경우도 드물지 않습니다. 「학습 = 비싸다」라는 단순화는 오해를 불러일으킬 수 있으며, 어디에 비용이 발생하는지 그 구조를 이해하고 견적을 내야 합니다.

LoRA의 활용처

LoRA (Low-Rank Adaptation)는 원래의 파라미터 행렬을...

LoRA는 SFT에서 자주 사용되지만, CPT에서도 사용할 수 있습니다 (실제로 Domain-Adaptive Pre-Training (DAPT)을 LoRA로 구현하는 논문도 늘어나고 있습니다).

「LoRA = SFT」라고 단정 짓지 마십시오. LoRA는 학습 대상 파라미터를 압축하는 기법이며, 어떤 목적으로 학습할지는 별개의 문제입니다.

4. 「도메인 지식을 FT로」가 왜 무리수인가

지금까지의 정리를 바탕으로, 서두의 위화감을 기술적으로 설명하겠습니다.

「의료 업계의 전문 용어를 기억시키기 위해 파인튜닝을 한다」라고 할 때, 전형적으로 다음과 같은 절차가 상정됩니다:

• 의료 용어집을 (용어, 설명) 형태의 QA 쌍으로 변환 $\rightarrow$ SFT로 학습
• 모델이 의료 용어를 「이해했다」고 기대함

문제점:

• (용어, 설명) 쌍은 **표면적인 패턴 매칭 (Pattern Matching)**으로 기억되어 버립니다.
• 의료 용어를 「문맥 속에서 자연스럽게 사용하는」 능력은 획득되지 않습니다.
• 학습 후 모델에게 「증례를 요약해 주세요」라고 물으면, 요약 태스크는 SFT로 훈련되지 않았기 때문에 정확도가 나오지 않습니다.

이는 perplexity (PPL) 관점에서도 설명할 수 있습니다:

CPT는 perplexity를 직접 낮추도록 학습합니다 → 도메인 어휘의 유창성(fluency)이 향상됩니다 -
SFT는 perplexity를 낮추는 학습이 아닙니다 → 태스크 정확도는 올라가지만, 새로운 어휘에 대한 유창성을 획득하기는 어렵습니다

도메인 지식 습득을 본격적으로 수행하려면, CPT가 유일한 선택지입니다. FT로는 대체할 수 없습니다.

5. 중간 접근법: DAPT / TAPT

"CPT는 너무 무겁고, 그렇다고 SFT만 하기에는 지식이 부족하다"라는 현실적인 고민에 대한 해답이 **DAPT (Domain-Adaptive Pre-Training)**와 **TAPT (Task-Adaptive Pre-Training)**입니다.

Don't Stop Pretraining (Gururangan et al., 2020)에서 제안되었습니다.

DAPT: 도메인 코퍼스(corpus)로 지속 사전 학습(CPT)을 수행한 후, 태스크용으로 SFT를 진행 -
TAPT: 태스크의 input 텍스트만으로 지속 사전 학습을 수행한 후, SFT를 진행

두 방식 모두 "사전 학습 → 도메인 적응 → 태스크 적응"의 3단계 구성이 됩니다. 구현 측면에서는 다음과 같습니다:

base-llm
↓ (CPT on domain corpus)
domain-adapted-llm
...

중소기업 프로젝트에서 풀 CPT를 수행하는 것은 현실적이지 않지만, DAPT를 LoRA로 수행한다면 비용을 대폭 낮출 수 있습니다. "도메인 지식 + 태스크 적응"이 모두 필요한 케이스에서 첫 번째 후보가 됩니다.

6. 중소기업을 위한 제3의 길: 도메인 특화 OSS 모델

제로 베이스에서 CPT를 돌릴 비용을 마련할 수 없다면, 이미 도메인 특화로 사전 학습된 OSS (Open Source Software) 모델을 기점으로 삼는 선택지가 있습니다.

• 의료: BioBERT, ClinicalBERT, BioMedLM, MedAlpaca, Asclepius
• 법률: Legal-BERT, CaseLaw-BERT
• 금융: FinBERT, BloombergGPT (상용), FinGPT
• 일본어: 東北大BERT (Tohoku University BERT), llm-jp, Swallow, ELYZA

이것들을 기점으로 LoRA를 사용하여 SFT를 돌린다면, "자체적으로 CPT를 할 필요가 없는" 경우가 많습니다.

벤더(vendor) 측에서 "의료 데이터를 학습시킵시다"라고 제안한다면, 먼저 이렇게 질문해 보세요.

"BioBERT나 MedLLaMA와 같은 도메인 특화 모델을 기점으로 하는 선택지는 검토해 보셨나요?"

이에 답변하지 못하는 벤더는 도메인 적응(domain adaptation)의 최신 베스트 프랙티스(best practice)를 따라가지 못하고 있을 가능성이 높습니다.

7. 구현 관점의 판단 플로우

지금까지의 내용을 바탕으로, 구현 엔지니어가 LLM 적응 전략을 결정하는 플로우:

Q1. 프롬프트(prompt)만으로 어디까지 가능한지 시도해 보았는가?
YES → 가능하다면 그것으로 완료
NO → 시도해 보고 다시 오라
...

판단이 단순하지는 않지만, "목적이 CPT 영역인가 FT 영역인가"를 처음에 구분하는 것만으로도 불필요한 학습 비용의 대부분을 회피할 수 있습니다.

8. 현장에서 목격한 패턴

LLM 적응 전략 선정에서 "학습을 돌렸지만 기대만큼의 정확도가 나오지 않았다"라고 회고하는 케이스에서 반복적으로 나타나는 패턴을 정리합니다.

문제: 도메인 어휘 획득 → 접근법: SFT → 잘 풀리지 않음 (본래 CPT / DAPT로 다뤄야 할 영역) -
문제: 태스크 적응 → 접근법: 데이터 전처리에 너무 많은 시간을 할애 → 과잉 투자 (LoRA-SFT로 충분한 경우가 많음) -
문제: 프롬프트로 충분한 영역 → 접근법: 곧바로 SFT 수행 → 고비용 저효율

특히 첫 번째는, 벤더, 엔지니어, 경영자 모두가 "파인튜닝(fine-tuning)"이라는 단어로 모두 같은 것을 지칭하고 있다고 착각하는 프로젝트에서 발생하기 쉬운 구조입니다. 기술적인 정리를 초기에 공유하는 것만으로도 프로젝트의 방향성이 크게 바뀔 수 있습니다.

마치며

CPT와 FT의 차이는 구현 측면에서 명확합니다.

손실 함수(loss function)가 다름 (causal LM vs supervised next-token on output) -
데이터의 성격이 다름 (unsupervised text vs supervised pair) -
목적이 다름 (언어 모델화 vs 태스크 적응)

이 세 가지 점을 기점으로 판단한다면, "학습 방식 선정에서 헤매는" 케이스의 대부분을 피할 수 있습니다.

경영진이나 발주 측에 이러한 정리를 전달하는 역할을 맡는 것은 기술을 이해하는 엔지니어입니다. 본 기사를 사내 또는 프로젝트 현장에서의 기술 선정 논의 자료로 활용해 주신다면 기쁘겠습니다.

경영진을 위한 판단 플로우 버전은 「파인튜닝 (Fine-tuning) 제안을 받은 경영자를 위한 판단 플로우 실전 가이드」에 정리해 두었습니다. 사내 경영진에게 전달하고 싶을 때는 이쪽이 더 전달하기 쉬울지도 모릅니다.

질문, 지적, 구현에 관한 논의는 X로 부탁드립니다.

Discussion