Microsoft Foundry에서 파인튜닝하기: LoRA, SFT, DPO, RFT가 모델 가중치에 실제로 하는 일

사용자님의 프롬프트는 2,400 토큰 길이입니다. 시스템 메시지에는 11개의 글머리 기호 규칙이 있고, 몇 가지 예시(few-shot examples)와 세 번째 프로덕션 인시던트 이후 추가한 엣지 케이스에 대한 면책 조항이 포함되어 있습니다. 작동은 합니다 — 대부분의 경우에 말이죠. 하지만 비용이 많이 들고, 프롬프트 드리프트에 취약하며, 새로운 엣지 케이스가 생길 때마다 이미 불안정한 명령어 블록에 또 다른 단락이 붙게 됩니다.

어느 순간부터 올바른 엔지니어링 움직임은 '더 나은 프롬프트를 작성하는 것'에서 '가중치를 변경하는 것'으로 바뀝니다. 이것이 바로 파인튜닝(fine-tuning)입니다. 그리고 Microsoft Foundry에서는 파인튜닝이 Azure OpenAI에 붙여진 부가 기능이 아니라, Supervised Fine-Tuning (SFT), Direct Preference Optimization (DPO), Reinforcement Fine-Tuning (RFT)을 아우르는 일급의 다중 기술 커스터마이징 파이프라인입니다. 이 모든 것은 내부적으로 Low-Rank Adaptation (LoRA)을 기반으로 하며, 작업 수명 주기(job lifecycle), 체크포인트 시스템, 배포 모델을 갖추고 있어 대부분의 개발자가 제대로 사용하기 위해 충분히 자세히 들여다보지 않습니다.

이 글은 바로 그 깊은 탐구입니다.

이것이 중요한 이유

프롬프트 엔지니어링과 파인튜닝은 겹치지만 서로 다른 문제를 해결하며, 이 둘을 혼동하는 것은 프로덕션 GenAI 시스템에서 팀이 저지를 수 있는 가장 비싼 실수 중 하나입니다. 프롬프트 엔지니어링은 런타임 구성(runtime configuration)입니다 — 호출할 때마다 토큰 비용이 발생하고, 컨텍스트 창 공간을 차지하며, 모델이 방대한 텍스트 속에 숨겨진 지침을 따를 수 있는 능력만큼만 신뢰성이 높습니다. 파인튜닝은 한 번의 학습 비용으로 모델이 기본적으로 '무엇을 하는지'를 변경합니다. 이는 다음을 의미합니다:

• 호출당 더 짧은 프롬프트 (낮은 지연 시간, 대규모에서 낮은 토큰 비용)
• 형식(format), 어조(tone), 도메인 관습 준수도가 높아짐
• 선언적으로 지정하기 어려운 행동 학습 가능 (스타일, 모호성 해소 판단, 다중 에이전트 시스템에서의 라우팅 결정 등)
• 6개월 후에 누군가 시스템 프롬프트를 수정하더라도 성능 저하 없이 일관된 동작 유지

문제는 파인튜닝 역시 오용하기 쉽다는 것입니다. 만약 문제가 '모델이 이 사실을 모르는 것'이라면, RAG를 대체할 수는 없습니다. 또한, 기본 모델 선택이 잘못되었을 때의 안전망도 아닙니다. 그리고 데이터셋이 쓰레기라면, LoRA는 그 쓰레기를 충실하게 학습합니다. 기계적으로 — 포털 버튼 수준이 아니라 행렬 연산(matrix-math) 수준에서 — 무슨 일이 일어나고 있는지 이해하는 것이 파인튜닝을 잘 사용하는 팀과 훈련 예산을 시작 모델보다 성능이 떨어지는 모델에 낭비하는 팀을 가르는 기준입니다.

목차

1. 핵심 개념: SFT, DPO, 및 RFT
2. LoRA가 모델에 실제로 하는 일
3. Microsoft Foundry의 파인튜닝 아키텍처
4. 훈련 등급: 표준(Standard), 글로벌(Global), 개발자(Developer)
5. 예산 낭비하지 않을 데이터셋 준비하기
6. 파인튜닝 작업 실행하기: Python SDK 및 REST
7. 실제로 차이를 만드는 하이퍼파라미터
8. 체크포인트, 일시 중지, 그리고 연속 파인튜닝
9. 배포: PTU, 표준, 자동 배포
10. 실제 개발자 시나리오: 대규모 구조화 추출
11. 프로덕션 고려 사항
12. 보안 및 거버넌스
13. 비용 고려 사항
14. 일반적인 실수와 함정
15. 파인튜닝 vs. 대안
16. 실질적인 권장 사항
17. 결론
18. 참고 자료

1. 핵심 개념: SFT, DPO, 및 RFT

Microsoft Foundry는 세 가지의 명확한 커스터마이징 기법을 제공하며, 문제에 맞는 것을 잘못 선택하는 것이 파인튜닝 프로젝트가 실망하게 만드는 가장 흔한 이유입니다.

**지도 기반 미세 조정 (SFT)**은 기본 방식입니다. 사용자는 입력/출력 쌍, 즉 프롬프트와 원하는 정확한 응답을 제공하고 모델은 그 매핑을 재현하도록 훈련됩니다. 이는 간단한 모방 학습(imitation learning)입니다. 보상 함수도 없고, 비교 판단도 없으며, 단순히

실질적인 의사 결정 규칙은 다음과 같습니다. 특별한 이유가 없다면 SFT부터 시작하세요. 비교 선호도 데이터와 스타일/정렬 목표(alignment objective)를 가지고 있다면 DPO를 사용하세요. RFT는 목적이 있고, 평가자(grader)가 점수를 매길 수 있으며, 그리고 수렴하지 않는 강화 학습(RL) 방식의 훈련을 디버깅할 수 있는 ML 전문 지식이 있을 때만 사용하세요.

SFT vs DPO vs RFT comparison diagram

2. LoRA가 모델에 실제로 하는 일

이것은 대부분의 '파인튜닝 방법' 튜토리얼에서 완전히 건너뛰는 부분이며, Foundry 파인튜닝이 왜 빠르고 저렴하며 A100 클러스터를 프로비저닝할 필요가 없는지를 실제로 설명하는 부분입니다.

전체 파인튜닝(Full fine-tuning)은 모델의 모든 매개변수(parameter)를 업데이트합니다. 수백억 개의 매개변수를 가진 모델의 경우, 이는 전체 가중치 행렬(weight matrix) 각각에 대해 전체 정밀도 기울기(full-precision gradients)와 최적화기 상태(optimizer states)를 저장해야 함을 의미하며—이는 실제로 변경하려는 양이 아니라 총 매개변수 수에 비례하는 메모리 및 컴퓨팅 비용입니다.

**저랭크 적응(Low-Rank Adaptation, LoRA)**은 다음과 같은 관찰에서 시작합니다. 즉, 대규모 사전 학습 모델(pretrained model)을 더 좁은 작업(narrower task)에 적용하여 조정할 때 필요한 가중치 변화는 일반적으로 저랭크(low-rank)이며—전체 가중치 행렬보다 훨씬 작은 부분 공간(subspace)에 존재한다는 것입니다. 따라서 전체 가중치 행렬 W (형태: d × d)를 업데이트하는 대신, LoRA는 W를 완전히 고정하고 두 개의 작고 훈련 가능한 행렬인 A (형태: d × r)와 B (형태: r × d)를 주입합니다. 여기서 r—랭크(rank)—은 작습니다 (일반적으로 8~64이며, d는 수천에 달할 수 있습니다).

훈련 중에는 오직 A와 B만 업데이트됩니다. 순전파 과정(forward pass)에서 사용되는 유효 가중치(effective weight)는 W + BA입니다. r ≪ d이기 때문에, 훈련 가능한 매개변수 수는 전체 행렬의 극히 일부—종종 총 모델 매개변수의 1% 미만—에 불과하며, 이는 다음과 같은 것을 의미합니다:

– 훈련에 필요한 GPU 메모리가 훨씬 적습니다(전체 가중치 행렬의 옵티마이저 상태를 유지할 필요가 없습니다)
– 단계당 훈련 속도가 빠르고 비용이 저렴합니다
– 결과로 생성되는 어댑터는 작고 휴대성이 뛰어나서, 전체 기본 모델을 다시 로드하지 않고도 어댑터를 교체할 수 있습니다
– W를 건드리지 않기 때문에 고정된(frozen) 기본 모델의 일반적인 기능은 보존됩니다.

이것이 바로 Foundry의 서버리스 파인튜닝 계층이 사용자에게 GPU 할당량을 요구하지 않는 이유입니다. LoRA 기반 훈련은 전체 파인튜닝보다 본질적으로 더 작은 리소스 발자국을 가지며, 이것이 애초에 사용량 기반 가격 책정(consumption-priced), 다중 테넌트(multi-tenant) 파인튜닝 서비스를 경제적으로 실행 가능하게 만드는 요인입니다. 또한, 이미 파인튜닝된 모델을 가져와 새로운 데이터로 다시 튜닝하는 연속적인 파인튜닝 역시 저렴하고 빠릅니다. 왜냐하면 처음부터 밀집된(dense) 모델을 재훈련하는 것이 아니라 작은 어댑터 업데이트들을 조합하기 때문입니다.

[

LoRA low-rank adaptation internals diagram](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fk92hrd8q6ake8p5ar6an.png

3. Microsoft Foundry의 파인튜닝 아키텍처

시스템 수준에서, Foundry 파인튜닝 작업은 어떤 기술(SFT/DPO/RFT) 또는 제품 인터페이스(서버리스 OpenAI 파인튜닝, 서버리스 Foundry Models 파인튜닝, 또는 관리형 컴퓨팅)를 사용하든 일관된 파이프라인을 거칩니다:

1. 데이터 수집 및 검증(Data ingestion and validation) — JSONL 학습 파일(및 선택적 검증)이 프로젝트에 업로드되며, UTF-8 + BOM 인코딩, 채팅 완료 메시지 형식에 대한 스키마 준수 여부, 그리고 크기 제한(파일당 512MB 미만)을 확인합니다.
2. 작업 제출 및 대기열 관리(Job submission and queuing) — 베이스 모델 참조, 학습 등급(training tier), 선택적 하이퍼파라미터, 재현성을 위한 선택적 시드와 함께 작업이 제출됩니다. 이 작업들은 동일한 지역별 용량 풀을 공유하는 다른 테넌트의 작업들 뒤에 대기열로 배치됩니다.
3. 학습 컴퓨팅(Training compute) — 플랫폼은 고정된 베이스 모델을 대상으로 LoRA 어댑터를 학습시키고, 에포크별 체크포인트를 생성하며 train_loss, full_valid_loss, train_mean_token_accuracy, 그리고 full_valid_mean_token_accuracy 메트릭 스트리밍을 수행합니다.
4. 안전성 평가(Safety evaluation) — 체크포인트가 배포 가능해지기 전에 안전성 평가 과정을 거칩니다. 이는 학습 도중에 작업을 일시 중지할 때도 마찬가지입니다: Foundry는 단순히 프로세스를 멈추는 것이 아니라, 현재의 체크포인트를 대상으로 안전성 검사를 실행하여 불완전한 실행에서도 사용 가능한 아티팩트를 확보하게 합니다.
5. 체크포인트 보존(Checkpoint retention) — 작업이 완료된 후 가장 최근의 세 가지 체크포인트가 보존되며, 최종 에포크에서 과적합(overfit)되었을 경우 이전 에포크를 배포할 수 있게 합니다.
6. 배포(Deployment) — 배포 가능한 체크포인트는 이름이 지정된 사용자 정의 모델 배포로 변환되며, 다른 모든 Foundry 모델 배포와 동일한 Chat Completions 호환 인터페이스를 통해 호출될 수 있습니다.

Microsoft가 여기서 내린 핵심 아키텍처 결정은 파인튜닝을 공유 용량 위에 계층화된 관리형 다중 테넌트 작업 시스템으로 취급하는 것이지, 사용자가 자체 컴퓨팅 자원을 가져와야 하는 워크로드로 취급하지 않는다는 점입니다. 이는 의도적인 트레이드오프(Section 5에서 더 자세히 설명)이며,

Microsoft Foundry fine-tuning job lifecycle diagram

4. 학습 계층(Training Tiers): Standard, Global 및 Developer

이것은 간과하기 쉬운 요소입니다. Foundry의 서버리스 파인튜닝은 비용, 지연 시간, 데이터 거주성 측면에서 트레이드오프를 제공하는 세 가지 학습 계층을 제공하며, 잘못된 것을 선택하면 불필요하게 많은 비용이 들거나 컴플라이언스 요구 사항을 조용히 위반할 수 있습니다.

| 계층(Tier) | 데이터 거주성 | 비용 | 대기 시간 | 사용 시점 | |
| :--- | :--- | :--- | :--- | :--- |
| Standard | 학습이 리소스의 지역 내에서 유지됨 | 기본 수준 | 보통 | 데이터가 특정 지역을 벗어나서는 안 되는 규제 대상 워크로드 |
| ... |

Developer 계층은 별도로 언급할 가치가 있습니다. 이 계층은 유휴 용량을 사용하기 때문에, 플랫폼이 경고 없이 작업을 일시 중지하고 재개할 수 있으며 SLA(서비스 수준 계약)가 없습니다. 이는 적절한 하이퍼파라미터를 찾기 위해 열 가지의 소규모 배치 실험을 반복하는 팀에게는 괜찮은 트레이드오프이지만, 출시 마감일을 좌우하는 작업에는 나쁜 트레이드오프입니다.

5. 예산을 낭비하지 않을 데이터셋 준비하기