[AI 에이전트] 11주차 - LLM Training & Fine tuning

개요

지금까지 다룬 RAG와 Agentic Prompting이 "모델 바깥의 맥락(Context)을 조절하는 방식"인 RAG와 Prompting이었다면, 이번에는 LLM을 최적화하는 방법인 Fine-Tuning에 대해서 알아볼 것입니다.

1. 구분해야할 학습 단계

우선적으로 우리는 LLM 학습에서, Pre-training 과 Post-training 으로 나눌 수 있습니다.

→ 비유하자면 , Pre-training은 사람이 언어와 세상에 대한 기본 감각을 익히는 과정이고, Post-training은 회사에 입사한 뒤 업무 규칙과 고객 응대 방식을 배우는 과정입니다. Fine-tuning은 그중에서도 특정 직무를 반복 훈련해주는 것입니다.

구분	핵심 목적	주요 결과
Pre-training	대규모 데이터에서 언어·코드·일반 패턴 학습	Base Model
Post-training	이미 만들어진 모델을 실제 사용 목적에 맞게 조정	지시 수행·스타일·안전성·특정 작업 능력
Fine-tuning	Post-training 안에서 특정 행동·형식·도메인에 맞춰 추가 학습	업무 특화 모델

2. Pre-training

2.1 개념

: Pre-training은 대규모 텍스트·코드·이미지 등의 데이터를 이용해 모델의 기본 능력을 만드는 단계입니다. 언어의 구조, 단어와 문맥의 관계, 일반적인 사실, 코드 패턴, 기본적인 추론 양식 등이 이 단계에서 형성됩니다.

대규모 데이터
  → Token 단위 변환
  → 다음 Token 예측 등 학습
  → 가중치 업데이트
  → Base 또는 Foundation Model

→ Pre-training은 데이터와 계산량이 매우 커서 , 일반적으로 애플리케이션 개발자가 처음부터 수행하는 작업은 아닙니다. 대부분의 개발자는 이미 만들어진 Base Model 또는 Instruction-tuned Model을 선택하고, 그 위에서 RAG Prompt Fine-tuning 을 적용합니다.

2.2 Continued Pre-training

: Continued Pre-training은 이미 학습된 Base Model에 추가 데이터를 계속 합습시키는 방식을 말합니다. 모델의 기본 언어 능력을 유지하면서 특정 분야의 표현과 문맥을 보강할 떄 사용할 수 있습니다.

방식	목적	예시
일반 Pre-training	기본 언어·코드·지식 학습	Foundation Model 생성
Continued Pre-training	기존 모델에 추가 데이터 학습	새로운 대규모 도메인 말뭉치 반영
DAPT	특정 도메인에 적응	법률·의료·금융·개발 문서
TAPT	특정 Task와 가까운 텍스트에 적응	분류·검색·요약 관련 문장

• DAPT ( Domain-Adaptive Pre-training )
  • 법률·의료·금융처럼 전문 용어와 문맥이 중요한 분야의 데이터를 추가 학습하는 방식입니다.
• TAPT ( Task-Adaptive Pre-training )
  • 특정 작업과 가까운 입력 텍스트를 학습해 해당 작업에 등장하는 언어 패턴을 보강합니다.

2.3 Pre-training과 Fine-tuning의 차이

• Pre-training은 “환불”, “배송”, “불만”이라는 단어와 일반적인 문맥을 이해하도록 만드는 단계에 가깝습니다.
• Fine-tuning은 이미 알고 있는 단어와 문장을 고객지원 업무의 정해진 카테고리와 출력 형식으로 연결하는 단계입니다.

⇒ Pre-training은 무엇을 이해할 수 있는가를 만들고, Fine-tuning은 이해한 것을 어떤 방식으로 행동으로 표현할 것인가를 조정합니다.

3. Post-training

3.1 Post-training의 개념

: Post-training은 Base Model을 실제 사용 목적에 맞게 다듬는 전체 단계입니다. 모델이 사용자의 지시를 더 잘 따르고, 원하는 형식으로 답하며, 안전 기준을 지키도록 조정합니다.

방법	핵심 기능
SFT	입력과 정답 응답 예시를 학습
Instruction Tuning	다양한 지시를 따르는 능력 강화
Fine-tuning	특정 업무·말투·형식에 맞춤 조정
Preference Tuning	좋은 답변과 덜 좋은 답변의 선호 차이 학습
RLHF	사람 피드백을 보상 신호로 활용
RLAIF	AI가 만든 피드백을 활용
DPO	선호·비선호 응답 쌍을 직접 최적화
Safety Alignment	유해 요청 거절과 안전한 응답 조정

3.2 SFT와 Instruction Tuning

: Supervised Fine-tuning(SFT)는 입력과 그에 대응하는 정답 응답을 제공해 모델이 원하는 출력 패턴을 학습하도록 하는 방식입니다. 예를 들어 다음과 같은 데이터를 반복해서 보여줄 수 있습니다.

입력: 오늘 롯데 경기일정을 알려줘
정답: {
  "category": "baseball_schedule",
  "team": "롯데 자이언츠",
  "date": "today",
  "reply": "오늘 롯데 자이언츠의 경기 일정을 확인해드리겠습니다."
}

⇒ Instruction Tuning은 “이렇게 지시하면 이렇게 수행하라”는 예시를 다양한 형태로 학습시키는 접근입니다.
SFT가 구현 방식이라면 Instruction Tuning은 학습하려는 목적과 데이터의 성격을 나타내는 표현으로 이해할 수 있습니다.

3.3 Preference Tuning, RLHF, RLAIF, DPO

: Preference Tuning은 정답 하나를 외우게 하기보다 여러 답변 사이의 선호 차이를 학습시키는 방법입니다.

방법	쉬운 설명	특징
RLHF	사람이 더 좋은 답변을 선택하고 그 선호를 보상으로 학습	사람의 기준을 반영하지만 비용이 큼
RLAIF	AI가 답변을 평가해 피드백을 제공	비용을 줄일 수 있으나 평가 품질이 중요
DPO	선호 답변과 비선호 답변을 직접 비교 학습	RLHF보다 구조가 단순한 편

3.4 Safety Alignment

Safety Alignment는 위험하거나 유해한 요청에 적절히 거절하고, 안전한 대안을 제시하며, 불필요하게 확신하지 않도록 모델을 조정하는 단계입니다.

그러나 안전 학습만으로 모든 공격과 오답을 막을 수 있는 것은 아닙니다.

실제 운영에서는 Guardrail, Tool 권한, 출력 검증, 애플리케이션 정책을 함께 사용해야 합니다.

4. Fine-tuning

4.1 Fine-tuning의 정확한 의미

: Fine-tuning은 Post-training 안에서 특정 작업·말투·출력 규칙을 학습하는 방법입니다. 다음과 같은 목적에 잘 맞습니다.

고객 문의를 정해진 카테고리로 분류
정해진 JSON Schema를 일관되게 출력
서비스의 존댓말과 브랜드 톤 유지
긍정·부정·중립 판단 기준 통일
특정 업무 절차와 응답 순서 준수
긴 Few-shot Prompt를 줄이고도 같은 패턴 유지

⇒ 반대로 최신 사내 정책·제품 매뉴얼·실시간 재고처럼 자주 변하는 지식을 답하게 하는 것이 주목적이라면 RAG가 더 적합할 수 있습니다. Fine-tuning으로 사실을 저장하면 정보가 바뀔 때 다시 학습해야 하고, 모델이 항상 정확한 최신 정보를 검색한다는 보장도 어렵습니다.

문제 유형	우선 검토할 방법
최신 문서와 정책을 참조해야 함	RAG
짧은 지시와 예시로 해결 가능	Prompt Engineering
출력 형식과 업무 행동을 반복적으로 통일	Fine-tuning
외부 시스템을 조회·실행해야 함	Tool·Agent
모델의 안전한 거절과 선호를 조정	Alignment·Preference Tuning

⇒ Fine-tuning은 모델을 “더 똑똑하게 만드는 마법”이 아니라, 반복해서 보여준 정답 행동을 더 안정적으로 따르게 만드는 방법입니다.

5. Fine-tuning

5.1 Token이란

Tokenization은 텍스트를 모델이 처리할 수 있는 작은 단위인 Token으로 나누는 과정입니다. 모델은 일반적으로 사람이 보는 단어 그대로가 아니라 Token의 연속을 입력으로 받습니다.

⇒ Tokenizer에 따라 같은 문장도 서로 다른 Token 수로 나뉠 수 있습니다. 단어를 하나의 Token으로 처리하지 못하면 더 작은 조각으로 나눕니다. 이를 통해 희귀 단어, 신조어, 여러 언어 표현도 기존 Token 조합으로 표현할 수 있습니다.

5.2 Token 수가 중요한 이유

Token 수는 학습과 추론의 계산량, 비용, Context Window 사용량에 영향을 줍니다. 특히 Fine-tuning 데이터는 사람이 읽는 JSON 문서가 그대로 학습되는 것이 아니라 Token으로 변환되어 반복 처리됩니다.

Token 관점	의미
Input Token	모델에 전달되는 Prompt·대화·Context
Target Token	모델이 생성하도록 학습되는 정답
Context Length	입력과 출력이 사용할 수 있는 전체 Token 범위
Vocabulary	Tokenizer가 사용하는 Token 집합

⇒ 모델마다 최대 Context Length와 Chat Template, 특수 Token 규칙이 다를 수 있으므로 학습 전에 사용하는 모델의 설정과 문서를 확인해야 합니다.

5.3 Continued Pre-training과 Fine-tuning의 Token 관점

Continued Pre-training은 도메인 텍스트의 표현과 문맥을 Token 단위로 더 익히는 쪽에 가깝습니다. Fine-tuning은 이미 언어를 이해하는 모델이 특정 입력에 어떤 응답 행동을 해야 하는지 맞추는 쪽에 가깝습니다.

6. Chat Template

6.1 Chat Template이란

대화형 LLM은 System·User·Assistant 메시지를 각각 별도의 객체로 관리할 수 있지만, 실제 모델은 이를 모델별 특수 Token 시퀀스로 처리를 합니다.

이 변환 규칙을 Chat Template이라고 합니다.

Ex)

[
  {
    "role": "system",
    "content": "당신은 야구 경기 일정과 정보를 정확하게 안내하는 AI 어시스턴트입니다."
  },
  {
    "role": "user",
    "content": "오늘 롯데 자이언츠 경기 일정을 알려줘"
  }
]

⇒ 모델 내부에서는 대략 다음처럼 특별한 구분 Token과 함께 펼쳐질 수 있습니다.

<system>
당신은 야구 경기 일정과 정보를 정확하게 안내하는 AI 어시스턴트입니다.
</system>
<user>
오늘 롯데 자이언츠 경기 일정을 알려줘
</user>
<assistant>

⇒ SFT 예시와 완전히 동일한 맥락으로 연결하고 싶다면 System 메시지를 조금 더 구체적으로 만들어도 좋습니다.

{
  "role": "system",
  "content": "사용자의 야구 관련 질문을 분석하고, 경기 일정 조회 요청에 정확하게 응답하는 AI 어시스턴트입니다."
}

⇒ 이렇게 하면 앞에서 사용한 오늘 롯데 경기일정을 알려줘 → baseball_schedule 예시와도 흐름이 자연스럽게 이어집니다.

⇒ 모델마다 실제 특수 Token과 형식은 다릅니다. 따라서 “대화 데이터가 있다”는 것만으로 충분하지 않고, 학습하려는 모델이 사용하는 Chat Template에 맞춰 데이터를 변환해야 합니다.

6.2 Chat Template이 어긋날 때의 문제

: 학습 데이터의 역할 구분과 특수 Token 형식이 모델의 기대와 다르면 다음 문제가 발생할 수 있습니다.

• 모델이 답변 시작 위치를 제대로 찾지 못함
• System과 User 내용을 정답처럼 학습함
• Assistant 응답의 경계가 잘못 잡힘
• 추론 시 학습 때와 다른 형식을 받아 성능이 떨어짐
• 출력에 특수 Token이나 역할명이 섞임

확인 항목	점검 내용
Role	system·user·assistant 구분이 올바른가?
Special Token	모델의 BOS·EOS·Turn Token을 사용하는가?
Generation Prompt	추론 시 Assistant 시작 지점이 추가되는가?
Padding	Batch 학습 시 Padding 방향과 ID가 올바른가?
종료 Token	답변 종료를 학습하고 생성에서 멈추는가?

7. Assistant Label Masking

7.1 Masking이 필요한 이유

SFT에서는 System과 User 메시지가 모델에 주어지는 입력 조건이고, Assistant 메시지가 모델이 생성해야 할 정답입니다.

따라서 전체 대화의 모든 Token을 정답으로 취급하면 안 됩니다.

EX)

system: 사용자의 야구 관련 질문을 분석하고 category와 reply를 가진 JSON으로 응답하라.

user: 오늘 롯데 자이언츠 경기 일정을 알려줘.

assistant: {"category":"baseball_schedule","reply":"오늘 롯데 자이언츠의 경기 일정을 확인해드리겠습니다."}

⇒ 이 경우 학습해야 하는 정답 영역은 assistant의 응답 부분입니다.

system: 사용자의 야구 관련 질문을 분석하고 category와 reply를 가진 JSON으로 응답하라.
        → Masking

user: 오늘 롯데 자이언츠 경기 일정을 알려줘.
      → Masking

assistant: {"category":"baseball_schedule","reply":"오늘 롯데 자이언츠의 경기 일정을 확인해드리겠습니다."}
           → Loss 계산

⇒ 즉, System과 User Token에는 일반적으로 -100과 같은 값을 적용하여 Loss 계산에서 제외하고, Assistant가 생성해야 하는 Token에 대해서만 Loss를 계산합니다.

이렇게 해야 모델이 "오늘 롯데 자이언츠 경기 일정을 알려줘"라는 User 문장 자체를 외우도록 학습하는 것이 아니라, 해당 입력이 들어왔을 때 적절한 Assistant 응답을 생성하는 방법을 학습하게 됩니다.

7.2 Masking의 직관적인 의미

모델이 다음과 같은 패턴을 배우도록 만드는 것이 목적입니다.

⇒ “이런 System 지시와 User 입력이 주어졌을 때, Assistant는 이런 응답을 생성해야 한다.”

System과 User까지 정답으로 학습시키면 모델이 입력을 복사하거나 역할 구분을 혼동할 수 있습니다.
반면 Assistant 부분만 학습 대상에 남기면 원하는 출력 행동에 학습 신호를 집중할 수 있습니다.

8. Fine-tuning 데이터의 기본 구조

8.1 구조

: Fine-tuning 데이터는 보통 다음과 같은 메시지 구조로 설계합니다.

{
  "messages": [
    {
      "role": "system",
      "content": "모델의 역할, 출력 형식, 판단 기준"
    },
    {
      "role": "user",
      "content": "실제 사용자가 입력할 질문이나 문장"
    },
    {
      "role": "assistant",
      "content": "모델이 생성해야 하는 정답 응답"
    }
  ]
}

⇒ JSON 응답을 학습할 때는 사람이 보기 좋은 예시만 확인하면 부족합니다.
실제 JSONL 파일에서 따옴표·중괄호·리스트·빈 문자열이 깨지지 않는지, Assistant Content가 올바른 문자열로 저장되는지 검증해야 합니다.

데이터 구성	설계 원칙
System	역할·출력 규칙·판단 기준을 명확히 작성
User	실제 서비스에서 발생할 다양한 입력 포함
Assistant	실제 서비스에서 출력할 결과만 포함
Metadata	필요하면 출처·버전·검수 상태 별도 관리
Label	일관된 기준으로 Masking과 정답 정의

9. 야구장 문답 분류 JSON 예재

야구 경기 문의 분류는 Fine-tuning이 새로운 야구 지식을 주입하는 것보다, 사용자의 질문을 정해진 카테고리와 출력 형식에 맞게 변환하도록 행동을 조정하는 과정에 가깝다는 점을 보여줍니다.

{
  "messages": [
    {
      "role": "system",
      "content": "야구 관련 문의를 읽고 category와 reply를 가진 JSON으로만 답변하라. category는 baseball_schedule, baseball_result, team_info, player_info 중 하나를 사용하라."
    },
    {
      "role": "user",
      "content": "오늘 롯데 자이언츠 경기 일정 알려줘."
    },
    {
      "role": "assistant",
      "content": "{\"category\": \"baseball_schedule\", \"reply\": \"오늘 롯데 자이언츠의 경기 일정을 확인해드리겠습니다.\"}"
    }
  ]
}

⇒ 이 데이터에서 모델이 배워야 하는 것은 세 가지입니다.

사용자의 질문을 야구 관련 카테고리로 연결하는 판단 기준

정해진 JSON Schema로만 출력하는 규칙

사용자에게 전달할 짧고 일관된 응답 톤

⇒ 모델이 "경기 일정"이나 "롯데 자이언츠"라는 표현의 의미를 처음부터 새롭게 배우는 것은 아닙니다. 이미 알고 있는 야구 관련 표현을 서비스에서 정의한 baseball_schedule, baseball_result, team_info, player_info 등의 분류 체계와 응답 형식에 맞게 변환하도록 조정하는 것입니다.

10. 좋은 학습 데이터의 기준

10.1 양보다 기준

Fine-tuning 데이터는 무조건 많다고 좋은 것이 아닙니다.

모델이 반복해서 배워야 할 행동이 일관되게 담겨 있는지가 중요합니다. 정답 기준이 흔들리면 학습 설정을 바꿔도 결과가 안정되지 않습니다.

10.2 형식 일관성

같은 목적의 출력에 서로 다른 필드명을 섞으면 모델이 여러 형식을 모두 허용되는 출력으로 배울 수 있습니다.

나쁜 예: {"type":"경기일정", "answer":"롯데 자이언츠 경기 일정을 확인하겠습니다."}

좋은 예: {"category":"baseball_schedule", "reply":"롯데 자이언츠의 경기 일정을 확인해드리겠습니다."}

⇒ 형식 일관성은 보기 좋은 문서 작성의 문제가 아니라 모델이 배워야 할 행동 규칙입니다.

10.3 Edge Case를 포함

쉬운 예시만 학습하면 실제 서비스의 경계 사례에서 성능이 흔들릴 수 있습니다. Edge Case는 모델을 괴롭히기 위한 데이터가 아니라, 서비스에서 자주 혼동되는 판단 경계를 보여주는 데이터입니다.

야구 문의 분류의 Edge Case 예시는 다음과 같습니다.

경기 일정 문의처럼 보이지만 실제로는 경기 결과를 묻는 문장

선수 이름이 포함되어 있지만 핵심은 팀 경기 일정인 문장

"오늘 롯데?"처럼 카테고리 판단이 어려운 매우 짧은 문장

경기가 없는 날처럼 일정 결과를 빈 리스트로 반환해야 하는 경우

야구 경기 정보 구조화의 Edge Case는 다음과 같습니다.

롯데 자이언츠가 언급되지만 실제 경기 일정과 무관한 문장

경기 일정과 경기 결과를 동시에 묻는 문장

팀명이 "롯데", "자이언츠"처럼 약칭으로 표현된 문장

우천 취소나 경기 연기로 인해 정상 경기 일정이 없는 경우

해당 날짜에 경기가 없어 빈 schedule 리스트를 반환해야 하는 경우

특히 마지막처럼 실제 서비스가 JSON을 반환한다면 다음과 같은 형태까지 학습 데이터에 포함시키는 것이 좋습니다.

{
  "category": "baseball_schedule",
  "team": "롯데 자이언츠",
  "schedule": [],
  "reply": "해당 날짜에는 예정된 경기가 없습니다."
}

11. Fine-tuning이 필요한 경우와 아닌 경우

Fine-tuning은 강력하지만 항상 첫 번째 선택지는 아닙니다.

11.1 Fine-tuning을 고려할 상황

• 같은 업무를 반복적으로 수행한다.
• 출력 형식이 자주 깨진다.
• 카테고리 판단 기준을 일관되게 맞춰야 한다.
• 서비스 말투와 응답 패턴을 유지해야 한다.
• 긴 Few-shot Prompt를 매번 넣는 비용이 부담된다.

11.2 Fine-tuning보다 다른 방법이 먼저인 상황

• 최신 지식과 외부 문서 참조가 핵심이다.
• 학습 데이터가 충분히 정리되어 있지 않다.
• 팀 안에서 정답 기준에 합의하지 못했다.
• 몇 개의 Prompt 예시만으로 이미 충분히 해결된다.
• 학습 후 품질을 평가할 기준이 준비되지 않았다.

요구사항	권장 접근
계속 변하는 지식	RAG
명확한 지시와 소수의 예시	Prompt Engineering

| 반복적이고 안정적인 형식·행동 | Fine-tuning |
| Tool·DB·외부 API 사용 | Agent·Function Calling |
| 모델 자체의 도메인 표현 보강 | Continued Pre-training 검토 |

12. 실무에서의 학습 데이터 제작 절차

1. 모델이 해야 할 행동을 한 문장으로 정의한다.
2. 입력·판단 기준·출력 Schema를 합의한다.
3. 실제 서비스 입력을 수집하고 개인정보를 제거한다.
4. 쉬운 예시와 경계 사례를 함께 작성한다.
5. System·User·Assistant 역할을 일관되게 구성한다.
6. Chat Template에 맞게 변환한다.
7. Assistant Label Masking 범위를 검증한다.
8. JSON·JSONL 형식과 특수문자를 검사한다.
9. 학습·검증·테스트 Dataset을 분리한다.
10. 기준 지표와 오류 유형을 정한 뒤 학습한다.

⇒ 실무에서는 LoRA의 r, alpha, target_modules 같은 설정을 조정하는 것보다 먼저 데이터 기준을 안정화해야 합니다. 데이터가 일관되지 않으면 학습 하이퍼파라미터를 바꾸어도 모델이 무엇을 배워야 하는지 불명확하기 때문입니다.

13. 전체 개념 비교

개념	모델에 주는 변화	적합한 목적
Prompt Engineering	매 요청의 지시를 변경	빠른 규칙·형식 조정
RAG	외부 Context를 검색해 제공	최신·사내·변경 가능 지식
Agent	Tool과 실행 흐름을 연결	조회·계산·행동 자동화
Fine-tuning	모델 가중치가 특정 행동을 더 잘 따르게 조정	반복 작업·스타일·형식
Continued Pre-training	도메인 언어 패턴을 추가 학습	대규모 전문 말뭉치 적응
Alignment	선호·안전·거절 성향을 조정	유용성·안전성·행동 품질

정리

LLM 학습을 이해할 때는 Pre-training과 Post-training을 먼저 구분해야 합니다. Pre-training은 대규모 데이터에서 언어와 일반 패턴을 학습해 Base Model을 만드는 과정이고, Post-training은 이미 만들어진 모델을 지시 수행·스타일·안전성·특정 업무에 맞게 조정하는 과정입니다.

Fine-tuning은 Post-training의 한 방법으로, 실무에서는 새로운 지식을 무작정 암기시키기보다 정해진 행동·출력 형식·말투·판단 기준을 반복 학습시키는 데 적합합니다. 최신 문서와 정책은 RAG가 더 적합할 수 있으며, 단순한 지시 변경은 Prompt Engineering으로 충분할 수 있습니다.

학습 데이터를 만들 때는 Tokenization, Chat Template, Assistant Label Masking을 반드시 이해해야 합니다. 데이터는 사람이 보기 좋은 예시 모음이 아니라 모델이 반복적으로 학습할 입력과 정답의 구조입니다. System·User·Assistant 역할을 명확히 하고, 모델의 Chat Template에 맞는 형식으로 변환하며, 손실 계산은 Assistant 정답에 집중해야 합니다.

좋은 Fine-tuning의 핵심은 데이터 양보다 행동 정의의 일관성입니다. 출력 필드명·판단 기준·말투·Edge Case 처리 방식이 흔들리지 않아야 합니다. 최종적으로 Fine-tuning은 모델을 마법처럼 더 똑똑하게 만드는 기술이 아니라, 합의한 정답 행동을 모델이 더 안정적으로 반복하게 만드는 방법입니다.

---

참고

https://platform.openai.com/tokenizer

https://huggingface.co/docs/transformers/main/en/chat_templating

https://docs.langchain.com/