LLM 파인튜닝은 언제 필요할까?

사내 문서가 수천 건 있고, 그 내용을 아는 챗봇을 만들고 싶다고 해 보겠습니다. 이때 가장 먼저 떠오르는 방법이 파인튜닝입니다. 문서를 모델에 학습시키면 모델이 우리 회사를 알게 되고, 그러면 무엇을 물어도 답할 것 같습니다. 직관적이고, 이름부터 그럴듯합니다. 그런데 이 기대대로 되지 않는 경우가 많고, 같은 목적이라면 대개 다른 방법이 더 잘 맞습니다.

파인튜닝을 지식 주입으로 보는 오해

파인튜닝(fine-tuning, 미세조정)은 이미 학습을 마친 모델을 내 데이터로 조금 더 학습시켜 모델 자체를 바꾸는 일입니다. 결과는 새 가중치 파일로 남습니다. 여기까지는 맞습니다. 어긋나는 것은 「그러면 내 데이터의 내용을 모델이 외운다」는 다음 걸음입니다.

모델이 학습에서 얻는 것은 사실의 목록이 아니라 패턴입니다. 문서 수천 건으로 학습시키면 모델은 그 문서들의 말투와 용어, 자주 나오는 문장 구조를 잘 익힙니다. 그러나 「3층 회의실 예약 규정이 언제 바뀌었나」 같은 개별 사실을 정확히 꺼내 오는 능력은 기대만큼 늘지 않습니다. 오히려 그럴듯한 말투로 틀린 날짜를 말하기 쉬워집니다.

연구도 같은 방향을 가리킵니다. Ovadia 등(EMNLP 2024)은 새 지식을 넣는 방법으로 비지도 파인튜닝과 검색 증강(RAG)을 비교했고, 학습 때 본 지식이든 처음 보는 지식이든 RAG 쪽이 앞섰다고 보고합니다. Gekhman 등(EMNLP 2024)은 모델이 파인튜닝으로 새 사실을 배우는 속도가 느리고, 그런 사실을 배울수록 환각이 늘어나는 경향을 보였다고 적습니다. 저자들의 결론은 모델이 사실 지식을 주로 사전학습 때 얻고, 파인튜닝은 이미 아는 지식을 더 잘 쓰는 법을 가르친다는 것입니다.

출처를 댈 수 없다는 점도 있습니다. 학습으로 들어간 지식은 어느 문서에서 왔는지 모델도 모릅니다. 규정이 바뀌면 다시 학습해야 하고, 학습하는 동안에는 옛 답을 그대로 냅니다. 사내 지식처럼 정확해야 하고 자주 바뀌는 정보라면 이 두 가지가 치명적입니다.

실제로 잘 바뀌는 것은 행동

파인튜닝이 잘하는 것은 모델이 아는 것보다 하는 방식을 바꾸는 일입니다. 늘 정해진 JSON 형식으로 답하게 하기, 우리 서비스의 말투로 쓰게 하기, 문의 메일을 정해진 분류 다섯 개 중 하나로 나누게 하기 같은 것입니다. 프롬프트로 길게 설명해도 잘 지켜지지 않던 규칙도 예시로 충분히 보여 주면 모델이 습관처럼 따르게 됩니다.

그렇다고 파인튜닝부터 꺼낼 일은 아닙니다. 저는 늘 프롬프트부터 봅니다. 프롬프트로 되는 일을 파인튜닝으로 하면, 같은 결과를 얻으려고 데이터 준비와 학습과 관리 비용을 계속 치르게 됩니다.

프롬프트, RAG, 파인튜닝이 맡는 일

모델을 우리 일에 맞추는 방법은 크게 셋입니다. 셋은 서로 대신하는 관계가 아니라 맡는 일이 다릅니다.

	프롬프트	RAG	파인튜닝
하는 일	지시문과 예시를 잘 쓴다	질문할 때 관련 문서를 찾아 함께 넣는다	예시 데이터로 모델을 더 학습시킨다
모델이 바뀌나	아니오	아니오	예
잘 맞는 것	그때그때의 지시	지식, 특히 자주 바뀌는 지식	형식, 말투, 한 가지 작업의 정확도
바꾸고 싶을 때	지시문을 고친다	문서를 바꾼다	다시 학습한다
출처 제시	해당 없음	찾아온 문서를 보여 줄 수 있다	어렵다

그래서 처음의 사내 문서 챗봇은 RAG로 시작하는 것이 맞습니다. 파인튜닝이 들어온다면 그 위에서입니다. 예를 들어 RAG로 찾아온 문서를 근거로 답하되, 답 형식이 자꾸 흐트러질 때 그 형식만 파인튜닝으로 잡는 식입니다. 둘을 함께 쓰는 것은 흔하고, 서로 부딪히지 않습니다.

모델 전체를 다시 학습하지 않는 LoRA

파인튜닝이라고 하면 거대한 GPU 클러스터가 떠오르지만, 요즘 직접 하는 파인튜닝은 대부분 LoRA(Low-Rank Adaptation) 방식입니다. 모델의 원래 가중치는 얼려 두고, 옆에 작은 행렬 몇 개를 덧붙여 그것만 학습시킵니다. LoRA 논문(Hu 등, 2021)은 GPT-3 175B 기준으로 학습할 파라미터 수를 1만 분의 1로, GPU 메모리를 3분의 1로 줄였다고 보고합니다. 여기에 모델을 4비트로 줄여 올린 채 학습하는 QLoRA(Dettmers 등, 2023)는 65B 모델을 48GB GPU 한 장에서 파인튜닝했습니다.

결과물은 모델 전체가 아니라 덧붙인 행렬, 즉 어댑터 파일 하나입니다. 원본 모델에 비하면 아주 작습니다. 대신 어댑터는 학습할 때 쓴 그 원본 모델 위에서만 동작합니다. 이 점이 나중에 관리 비용으로 돌아옵니다. 원본 모델의 새 버전이 나와 갈아타려면 어댑터도 새로 학습해야 합니다.

학습하는 도구와 돌리는 도구의 분업

Ollama로 로컬 모델을 쓰고 있다면 한 가지를 알아 둘 만합니다. Ollama는 학습을 하지 않습니다. 학습은 허깅페이스의 PEFT 라이브러리나 이를 더 쉽게 감싼 도구들로 하고, Ollama는 그 결과를 실행합니다. Ollama의 Modelfile에는 ADAPTER 지시어가 있어서 원본 모델 위에 LoRA 어댑터를 얹어 띄울 수 있습니다.

FROM llama3.2
ADAPTER ./my-adapter

여기서도 어댑터는 FROM에 적은 원본 모델로 학습한 것이어야 합니다. 원본이 다르면 동작이 엉망이 된다고 Ollama 문서가 경고합니다.

파인튜닝을 꺼낼 만한 신호

제 기준은 단순합니다. 프롬프트를 다듬고, 필요하면 RAG를 붙였는데도 같은 종류의 실패가 반복될 때 파인튜닝을 검토합니다. 특히 비용 때문에 작은 모델을 써야 하는데 그 모델이 형식이나 금지 규칙을 자꾸 어기는 경우가 대표적입니다. 이 문제를 프롬프트 쪽에서 먼저 푸는 방법은 작은 모델은 규칙을 지키지 않습니다 글에 정리돼 있습니다. 출력 검증으로도 안 잡히는 실패가 남는다면, 그 작업 하나만 잘하도록 작은 모델을 가르치는 것이 큰 모델로 갈아타는 것보다 싸게 먹힐 수 있습니다.

반대로 이미 프롬프트와 RAG로 원하는 결과가 나오고 있다면 파인튜닝할 이유가 없습니다. 학습 데이터를 모으고 다듬는 일, 원본 모델이 바뀔 때마다 다시 학습하는 일, 학습한 모델이 정말 나아졌는지 평가하는 일이 한 번으로 끝나지 않기 때문입니다.

양보다 일관성이 중요한 학습 데이터

몇 개의 예시가 필요한지는 작업과 모델에 따라 크게 다릅니다. OpenAI의 파인튜닝 안내서는 자기 모델 기준으로 최소 10개를 받고, 50~100개에서 개선이 보인다고 적습니다. 50개로 시작해 보고, 그래도 나아지지 않으면 데이터를 늘리기보다 작업이나 프롬프트를 다시 보라고 권합니다. 이 숫자는 OpenAI의 모델과 학습 방식에 대한 것이라, 오픈 모델을 LoRA로 학습할 때 그대로 옮겨 쓸 수 있는지는 저도 확신이 없습니다. 제가 확실하게 말할 수 있는 것은 양보다 일관성이 중요하다는 쪽입니다. 같은 질문에 서로 다른 형식으로 답한 예시가 섞여 있으면, 모델은 그 흔들림까지 그대로 배웁니다.

같은 안내서에는 OpenAI가 이 파인튜닝 플랫폼을 접는 중이라 새 사용자는 쓸 수 없다는 안내도 붙어 있습니다. 호스팅 서비스에 맡기는 길이 좁아지는 만큼, 오픈 모델을 LoRA로 직접 학습하고 Ollama 같은 실행기로 돌리는 쪽의 비중이 커질 것이라고 저는 봅니다.