지난 장에서 우리는 RAG를 통해 모델 바깥의 지식을 가져오는 법을 봤다. 그런데 실무에서는 곧 다른 벽을 만난다. 모델이 모를 것을 몰라서 틀리는 경우만 있는 것이 아니기 때문이다. 어떤 때는 분명 관련 문서를 잘 넣어줬는데도 답변 형식이 들쑥날쑥하고, 어떤 때는 회사 말투를 지키지 못하고, 어떤 때는 반드시 JSON으로 내보내야 하는데 자꾸 장문 설명을 덧붙인다. 이때의 문제는 정보 부족보다 행동 방식에 가깝다.
바로 여기서 파인튜닝이 등장한다. RAG가 모델에게 참고자료를 건네는 기술이라면, 파인튜닝은 모델의 습관을 조금 바꾸는 기술이다. 쉽게 말해, 시험장에 책을 한 권 더 들려보내는 것이 RAG라면, 파인튜닝은 학생 자체를 따로 훈련시키는 일이다.1
프롬프트만으로 안 되는 순간
처음에는 누구나 프롬프트로 해결해 보려 한다. "항상 친절하게 답해라", "반드시 표로 정리해라", "근거가 없으면 모른다고 말해라", "우리 브랜드 톤을 유지해라" 같은 지시를 길게 붙인다. 이 방법은 생각보다 강력하다. 실제로 많은 문제는 프롬프트 엔지니어링만으로도 꽤 잘 풀린다.
하지만 어느 순간 한계가 보인다. 같은 지시를 줘도 입력이 조금만 달라지면 형식이 무너지고, 긴 프롬프트 때문에 토큰 비용이 커지고, 복잡한 예외 규칙을 넣을수록 오히려 모델이 흔들린다. 특히 반복적인 업무에서 이런 현상은 더 답답하다. 고객 문의 분류, 상담 요약, 특정 포맷의 문서 생성, 도메인 용어가 강한 분류 작업처럼 매번 비슷한 규칙을 지켜야 하는 일은 "그때그때 잘 말해 주세요"보다 "이렇게 행동하도록 몸에 익혀 주세요"가 더 잘 맞는다.
이때 파인튜닝은 단순히 성능을 올리는 기술이 아니라, 모델에 작업 습관을 주입하는 방식이 된다.
파인튜닝은 무엇을 바꾸는가
파인튜닝은 이미 사전학습된 모델을, 더 작고 더 목적이 분명한 데이터로 한 번 더 학습시키는 과정이다. 핵심은 모든 것을 새로 배우게 하는 것이 아니다. 이미 언어와 세계에 대한 넓은 감각을 가진 모델에게, 특정 작업이나 도메인에 맞는 방향 감각을 더해 주는 것이다.1
여기서 중요한 구분이 있다. RAG는 모델이 무엇을 보게 할지를 바꾸고, 파인튜닝은 모델이 어떻게 반응할지를 바꾼다.1
예를 들어 최신 사내 규정을 답하게 하고 싶다면 RAG가 잘 맞는다. 규정은 바뀌기 때문이다. 반대로 고객 문의를 네 개의 카테고리로 아주 안정적으로 분류하게 하거나, 의료 문서를 늘 같은 형식으로 요약하게 하거나, 우리 서비스의 말투와 금지 표현을 일관되게 지키게 하고 싶다면 파인튜닝이 더 직접적인 해법이 된다.
전체 파인튜닝: 가장 강하지만 가장 무겁다
가장 정직한 방법은 전체 파인튜닝이다. 모델의 모든 가중치를 업데이트하는 방식이다. 말 그대로 엔진 전체를 다시 손보는 셈이다. 잘 되면 강력하다. 충분한 데이터와 자원이 있다면 특정 과업에 아주 잘 맞는 모델을 만들 수 있다.2
문제는 비용이다. 거대한 언어 모델의 모든 파라미터를 학습하려면 GPU 메모리도 많이 들고, 시간도 오래 걸리고, 저장해야 할 결과물도 크다. 모델 하나를 업무별로 조금씩 다르게 튜닝하려 할수록 부담은 눈덩이처럼 불어난다. 법률용 버전, 고객지원용 버전, 마케팅용 버전을 따로 만든다고 생각해 보자. 전체 파인튜닝을 매번 반복하는 것은 대기업에게도 만만한 일이 아니다.2
게다가 전체 파인튜닝은 잘못하면 원래 모델이 갖고 있던 일반 능력을 일부 잃을 수도 있다. 한쪽에 너무 세게 맞추다 보면 다른 쪽에서 둔해지는, 이른바 치우침이 생길 수 있다. 그래서 실무에서는 "정말 모든 나사를 다 돌려야 하나?"라는 질문이 자연스럽게 나온다.
PEFT: 거대한 모델을 작은 손잡이로 조정하기
이 질문에 대한 대표적인 답이 파라미터 효율적 파인튜닝, 즉 PEFT다. 이름은 조금 길지만 아이디어는 단순하다. 거대한 모델 전체를 뜯어고치지 말고, 작은 조절 장치만 학습하자는 것이다.24
기본 전략은 이렇다. 원래 모델의 대부분 가중치는 그대로 얼려 둔다. 그리고 아주 적은 수의 새로운 파라미터만 추가하거나, 변화량만 따로 학습한다. 그러면 학습 비용은 크게 줄고, 저장해야 할 결과물도 작아진다. 무엇보다 하나의 베이스 모델 위에 여러 업무용 적응본을 얹기 쉬워진다.
이 방식이 반가운 이유는 세 가지다.
학습해야 할 파라미터 수가 크게 줄어든다.
업무별 적응 결과를 작은 파일 형태로 관리하기 쉬워진다.
하나의 베이스 모델을 공유하면서 여러 특화 버전을 운영할 수 있다.
지금 LLM 실무에서 LoRA, 어댑터, QLoRA 같은 이름이 자주 보이는 이유도 여기에 있다. 이들은 모두 "큰 모델을 작은 손잡이로 움직이는 법"의 다른 변형들이다.
어댑터: 층 사이에 끼우는 작은 보조 회로
어댑터는 가장 직관적인 PEFT 방법 가운데 하나다. 트랜스포머 블록 사이사이에 작은 학습 모듈을 끼워 넣고, 그 작은 모듈만 학습한다. 원래의 큰 모델은 거의 그대로 두고, 필요한 변화만 옆에 붙인 작은 장치에 맡기는 셈이다.3
이 어댑터가 효율적인 이유는 보통 병목 구조를 쓰기 때문이다. 예를 들어 1024차원 표현을 바로 1024차원으로 다시 학습하면 파라미터가 아주 많이 필요하다. 그런데 먼저 24차원 같은 작은 공간으로 눌러 담았다가, 다시 1024차원으로 되돌리면 필요한 파라미터 수가 크게 줄어든다. 큰 파이프를 통째로 바꾸는 대신, 잠깐 좁은 밸브를 통과시키며 필요한 보정만 하는 느낌이다.3
초기 어댑터 연구에서는 BERT에서 전체 파라미터를 모두 미세조정한 것과 비슷한 성능을, 훨씬 적은 학습 파라미터로 얻을 수 있음을 보여주었다. 한 요약에서는 약 3.6%의 파라미터만 학습해도 경쟁력 있는 결과를 얻었다고 정리한다.3
어댑터의 장점은 모듈성이다. 업무별 어댑터를 따로 저장했다가 갈아 끼우기 좋다. 반면 단점도 있다. 구조에 작은 층을 추가하기 때문에, 경우에 따라 추론 시 약간의 오버헤드가 생길 수 있다. 다시 말해, 어댑터는 붙였다 뗄 수 있는 확장팩에 가깝다.
LoRA: 가중치 전체를 고치지 않고, 변화량만 배운다
요즘 가장 널리 쓰이는 방식은 LoRA다. Low-Rank Adaptation의 약자인데, 이름보다 직관이 더 중요하다. 전체 가중치 행렬을 새로 학습하는 대신, "원래 가중치에 어떤 작은 변화가 더해지면 좋을까"를 저차원 행렬 두 개로 표현하는 방식이다.2
비유하자면 이렇다. 두꺼운 전공서 전체를 다시 쓰는 대신, 필요한 수정 사항만 포스트잇에 적어 붙이는 것이다. 원본 책은 그대로 두고, 포스트잇만 학습한다. 그래서 저장 공간도 적게 들고, 학습도 훨씬 가볍다.2
LoRA의 핵심 손잡이는 랭크(rank) 다. 랭크가 작으면 매우 가볍지만 표현력이 제한될 수 있고, 랭크가 크면 더 세밀하게 적응할 수 있지만 비용이 올라간다. 결국 랭크는 "얼마나 작은 메모로 얼마나 큰 책을 수정할 것인가"를 정하는 값이다.2
또 하나 중요한 선택은 어느 층에 적용할 것인가다. 단순한 설정에서는 어텐션의 일부 선형 층만 겨냥하기도 하고, 더 강한 적응이 필요할 때는 더 넓은 선형 층을 대상으로 삼기도 한다. LLM-Adapters 연구에서는 작업과 구조에 따라 성능이 달라지며, LoRA는 어텐션과 MLP 관련 지점에 적용했을 때 좋은 결과를 보인 경우가 많다고 보고했다.4
LoRA가 실무에서 사랑받는 이유는 분명하다. 효율적이고, 구현 생태계가 잘 갖춰져 있고, 학습 후에는 원래 가중치와 병합해 추론 지연을 거의 늘리지 않는 방식으로 운영하기도 쉽다.2
여기에 한 걸음 더 나아간 것이 QLoRA다. 아이디어는 간단하다. 베이스 모델을 더 낮은 비트로 양자화해 메모리 사용량을 줄인 상태에서 LoRA를 학습하는 것이다. 그래서 더 적은 하드웨어로도 큰 모델을 다루기 쉬워진다.2
어댑터와 LoRA는 어떻게 다를까
둘 다 "모델 전체 대신 작은 부분만 학습한다"는 점에서는 같다. 하지만 철학은 조금 다르다.
어댑터는 모델 안에 작은 보조 층을 추가하는 방식이다. 그래서 구조적으로 무엇이 붙었는지 비교적 눈에 잘 보인다. 여러 작업용 모듈을 따로 관리하기도 좋다.
LoRA는 기존 층에 직접 작은 변화량을 덧입히는 방식이다. 모델을 뜯어 고친다기보다, 기존 가중치의 업데이트를 가볍게 근사한다고 보는 편이 맞다. 그래서 오늘날 LLM 파인튜닝에서는 LoRA 계열이 사실상 표준처럼 쓰이는 경우가 많다.2
어느 쪽이 절대적으로 낫다고 말하기는 어렵다. 다만 실무 감각으로는 이렇다. 빠르게, 싸게, 널리 적응시키고 싶다면 LoRA가 먼저 검토되고, 모듈성이나 특정 연구 실험 맥락에서는 어댑터가 여전히 매력적이다.
좋은 파인튜닝은 모델보다 데이터셋에서 갈린다
여기서 많은 사람이 실망도 하고, 동시에 안도도 한다. 파인튜닝 성능은 종종 "어느 모델을 썼는가"보다 "무슨 데이터를 어떻게 넣었는가"에 더 크게 좌우된다. 데이터셋의 품질과 과업 정의가 흐리면, 비싼 모델과 멋진 LoRA 설정도 소용이 없다.15
예를 들어 "고객 문의를 더 잘 답하게 만들고 싶다"는 목표는 너무 넓다. 반면 "고객 문의를 배송, 환불, 계정, 기타 네 분류로 나누고, 확신이 낮으면 반드시 확인 질문을 먼저 하게 하겠다"는 목표는 학습 가능한 과업에 가깝다. 파인튜닝은 모델을 똑똑하게 만든다기보다, 무엇을 잘해야 하는지 분명하게 정해 줄 때 효과가 커진다.
실무에서는 다음 네 가지를 먼저 고정하는 편이 좋다.
입력은 정확히 무엇인가
출력은 어떤 형식이어야 하는가
좋은 답과 나쁜 답의 기준은 무엇인가
예외 상황에서 모델이 어떻게 행동해야 하는가
이 네 가지가 흔들리면 데이터셋도 흔들린다. 어떤 샘플은 장문 설명을 요구하고, 어떤 샘플은 짧은 분류 결과만 요구하고, 어떤 샘플은 정답 기준이 모호하면 모델은 일관된 습관을 배우기 어렵다.
그래서 종종 적은 수의 고품질 예제가, 많은 수의 애매한 예제보다 낫다. 한 실무 가이드는 "1,000개의 좋은 예제가 100,000개의 평범한 예제보다 낫다"는 식으로 품질 우선의 원칙을 강조한다.5
특히 다음 같은 데이터셋은 파인튜닝을 망치기 쉽다.
라벨 기준이 사람마다 다른 데이터
실제 서비스 입력과 동떨어진 예제
지나치게 쉬운 샘플만 모아 놓은 데이터
최신 정책과 낡은 정책이 섞인 데이터
결국 좋은 파인튜닝은 모델 튜닝 기술이 아니라, 과업 설계 기술에 가깝다.
RAG와 파인튜닝, 무엇을 먼저 선택할까
이 질문은 실무에서 정말 자주 나온다. 답은 의외로 단순하다.
지식이 문제라면 RAG를 먼저 본다. 행동이 문제라면 파인튜닝을 먼저 본다.1
사용자가 묻는 내용이 자주 바뀌는 문서, 사내 위키, 가격표, 정책, 재고 상태처럼 최신 정보에 달려 있다면 RAG가 맞다. 반대로 모델이 늘 같은 형식으로 답해야 하거나, 특정 말투를 지켜야 하거나, 정해진 분류 체계를 안정적으로 따라야 한다면 파인튜닝이 맞다.
조금 더 실무적으로 정리하면 이렇다.
정보가 자주 바뀌고 출처가 중요하면 RAG
출력 형식, 말투, 절차 준수가 중요하면 파인튜닝
최신 지식도 필요하고 행동 일관성도 필요하면 둘을 함께 사용
실전의 좋은 시스템은 둘을 경쟁시키지 않는다. 예를 들어 법률 보조 시스템이라면, 법률 문체와 인용 형식을 잘 따르도록 모델을 파인튜닝하고, 최신 판례와 규정은 RAG로 가져오는 식이 자연스럽다. 의료, 금융, 고객지원에서도 같은 패턴이 자주 나온다.16
오히려 많은 팀이 거꾸로 간다. 사실은 최신 정보가 부족한 문제인데 파인튜닝부터 하거나, 사실은 출력 형식이 불안정한 문제인데 문서 검색만 계속 손본다. 그래서 순서를 이렇게 잡는 것이 대체로 안전하다. 프롬프트로 먼저 확인하고, 정보 부족이면 RAG를 붙이고, 그래도 행동 일관성이 부족할 때 파인튜닝을 검토한다.6
나만의 모델을 만든다는 것은 무엇인가
파인튜닝과 어댑터를 이해하고 나면 "나만의 모델을 만든다"는 말이 조금 현실적으로 들린다. 그것은 무에서 유를 만드는 일이 아니다. 거대한 모델을 처음부터 다시 키우는 일도 아니다. 이미 넓은 세계 감각을 가진 베이스 모델 위에, 내 문제에 맞는 작은 습관과 편향을 정교하게 얹는 일에 가깝다.
이때 중요한 것은 허세가 아니라 판단력이다. 프롬프트로 충분한가. RAG가 필요한가. 정말 가중치를 바꿔야 하는가. 바꾼다면 전체를 바꿀 것인가, LoRA 같은 작은 손잡이로 충분한가. 그리고 무엇보다, 내가 모델에게 가르치려는 행동이 데이터셋 안에서 제대로 정의되어 있는가.
좋은 엔지니어링은 여기서 드러난다. 거대한 모델을 무턱대고 더 학습시키는 사람이 아니라, 무엇을 바꿔야 하고 무엇은 바꾸지 말아야 하는지 구분하는 사람이 결국 더 좋은 시스템을 만든다.
다음 장에서는 이 선택이 실제로 잘 되었는지 어떻게 판단할지를 다룬다. 모델을 바꾸는 것만큼 중요한 것은, 그 변화가 정말 가치 있는 변화였는지 제대로 평가하는 일이다.
참고
1Augment large language models with retrieval-augmented generation or fine-tuning
2대규모 언어 모델을 위한 최적의 매개변수 선택 가이드: LoRA를 이용한 효율적인 미세 조정
3Finetuning LLMs Efficiently with Adapters
4LLM-Adapters: An Adapter Family for Parameter-Efficient Fine-Tuning of Large Language Models
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.