⚡ 3줄 요약
- 지시문을 계속 늘려도 안 되는 업무가 있다 — 규칙이 얽히고, 형식이 엄격하고, 매 호출마다 같은 지시문을 반복하는 세 조건이 겹칠 때다.
- 한 사례에선 이 세 조건이 다 맞는 업무에서 작은 전용 모델(Mistral 7B)이 정확도를 약 35%→98%로 끌어올렸다.
- 단, 이건 좁은 업무 하나의 결과다. 지식이 자주 바뀌면 답은 반대(RAG)로 뒤집힌다.
형식이 엄격하고, 같은 긴 지시문을 매 호출마다 반복하며, 조직 고유의 희소한 양식일 때 — 이 세 조건이 겹치면 큰 범용 모델보다 작은 전용 모델이 앞선다. “프롬프트를 더 잘 써라”는 조언에는 함정이 있다. 규칙이 정말 복잡한 업무에선 지시문을 아무리 정교하게 늘려도 벽에 부딪힌다. 항목이 빠지고, 없던 내용이 붙고, 분기 규칙이 어긋난다. 그런데 여기서 대부분은 “더 큰 모델을 쓰자”로 간다 — 실은 방향이 틀렸다. 큰 범용 모델에 긴 지시문을 물리는 대신, 작은 모델에 그 업무만 가르치는 편이 나은 조건이 분명히 있다. 문제는 그 조건이 언제 성립하느냐다.
실제 사례 하나가 이 경계를 선명하게 보여 준다. 유방암 병리 보고서를 정해진 양식(synoptic reporting)에 채우는 업무였는데, 범용 대형 모델에 강한 지시문과 RAG를 붙였을 때 정확도가 약 35%에 그쳤다. 같은 업무를 Mistral 7B라는 작은 모델에 QLoRA로 학습시키자 약 98%로 뛰었다. 63 percentage points 차이다. 이 격차가 어디서 왔는지 뜯어보면, 전용 모델을 검토해야 할 세 가지 조건이 나온다.
먼저: 여기서 ‘전용 모델’이 뭘 뜻하나
전용 학습(fine-tuning)은 이미 다 배운 모델에게 특정 업무의 입력·정답 예시를 다시 보여 주며 그 관계를 몸에 배게 하는 방식이다. 매번 조리법 전체를 읽어 주는 대신, 자주 만드는 메뉴를 주방 직원이 외우게 하는 것과 같다. 모델이 문장을 통째로 저장하는 건 아니고, 학습 과정에서 내부 숫자 값이 조정돼 입력과 결과의 대응이 바뀐다.
사례가 쓴 QLoRA는 그중에서도 가벼운 방식이다. 기본 모델을 4-bit로 압축해 저장하고, 그 위에 LoRA라는 작은 조정 장치만 학습한다. 덕분에 bfloat16이면 14GB 넘게 먹는 7B 모델을 5GB 미만으로도 돌릴 수 있다. 모델 전체를 다시 학습하지 않는 이런 방법들을 묶어 PEFT라 부른다. 요점은 하나다 — 작은 모델을 통째로 갈아엎지 않고도, 소비자용 GPU 한 장으로 업무 하나를 가르칠 수 있다.
조건 1 — 형식이 엄격하고, 항목 하나만 틀려도 전체가 무효다
유방암 보고서 업무의 핵심 난도는 여기 있었다. 40가지 조직학적 유형이 저마다 다른 항목 분기를 열고, 그 분기 하나를 잘못 판단하면 보고서 전체가 무효가 됐다. 이런 업무에서 지시문 방식은 구조적으로 취약하다. 규칙을 글로 나열할수록 모델이 그중 몇 개를 흘리고, 사람이 결국 문서를 처음부터 다시 읽어 고쳐야 한다.
전용 학습이 여기서 강한 이유는 규칙을 ‘읽게’ 하는 대신 ‘익히게’ 하기 때문이다. 수천 개 예시로 “이 입력이면 이 분기를 연다”는 대응을 반복 노출시키면, 매번 규칙을 텍스트로 설명할 때보다 누락이 줄어든다. 출력 형식이 복잡하고 오류에 민감할수록 이 차이가 커진다.
⚠️ 착각하기 쉬운 지점
“작은 모델이 큰 모델보다 똑똑하다”는 얘기가 아니다. 이 업무 하나에서, 이 형식에 한해 작은 전용 모델이 더 정확했다는 것이다. 일반 상식·추론·범용 대화로 가면 여전히 큰 모델이 앞선다. 전용 모델의 강점은 넓이가 아니라 깊이다.
조건 2 — 같은 긴 지시문을 매 호출마다 반복하고, 그 비용이 쌓인다
기존 방식은 호출 한 번에 보고서 양식 전체와 세부 규칙을 다 실어 보냈다. 사례 기준으로 호출당 약 30k tokens. tokens는 모델이 문장을 잘게 나눠 세는 단위인데, 입력이 길수록 처리 시간과 비용이 함께 늘어난다. 매번 바뀌지 않는 같은 규칙을 반복 전송하는 구조라면, 그 반복분이 고스란히 낭비다.
사례에서 이 규모로 범용 API를 계속 굴렸을 때 초기 비용 예상액은 약 $320,000이었다. 전용 학습으로 넘어간 뒤 이 업무의 API 비용을 없앴다고 저자는 밝힌다. 다만 이 “비용 0″에는 학습 비용, 이미 대규모로 운영하던 자체 모델 인프라 비용, 데이터 정제·평가 비용이 빠져 있다. API 청구서만 사라졌지, 총비용이 공짜가 된 건 아니다. 반복되는 지시문이 실제로 청구서를 키우고 있을 때에만 이 조건이 성립한다.
조건 3 — 일반 모델이 접하기 어려운, 조직 고유의 형식이다
세 번째 조건은 데이터의 희소성이다. 병원마다 다른 낡은 보고서 양식, 기업 내부에서만 쓰는 문서 구조, 특정 고객 응대의 고정된 말투처럼 인터넷 학습 데이터에 거의 없는 형식일수록 범용 모델은 헤맨다. 아무리 설명을 길게 붙여도 모델이 본 적 없는 패턴이기 때문이다.
이럴 때 전용 학습은 그 조직만의 예시를 직접 먹여 격차를 메운다. 반대로 말하면, 세상에 흔한 형식(일반적인 이메일, 표준 요약)이라면 굳이 전용 학습까지 갈 이유가 약해진다. 세 조건을 정리하면 이렇다.
| 조건 | 성립하면 | 왜 전용 모델이 유리한가 |
|---|---|---|
| 형식이 엄격 | 항목 하나만 틀려도 전체 무효 | 규칙을 ‘읽는’ 대신 예시로 ‘익혀’ 누락이 준다 |
| 지시문 반복 | 매 호출마다 같은 규칙을 재전송 | 반복 입력을 모델 내부로 옮겨 호출당 비용을 줄인다 |
| 형식이 희소 | 조직 고유·비공개 양식 | 범용 모델이 못 본 패턴을 직접 학습으로 메운다 |
반대편도 봐야 한다 — 이럴 땐 RAG가 맞다
전용 학습과 RAG는 경쟁 관계가 아니다. 역할이 다르다. 전용 학습은 업무 방식과 출력 습관을 몸에 배게 하고, RAG는 답변 시점에 필요한 최신 자료를 찾아 입력에 넣는다. 그래서 세 조건이 아무리 맞아도, 아래 상황이면 RAG를 먼저 검토해야 한다.
- 지식 기반이 자주 바뀐다 — 정책·가격·규정을 늘 최신으로 참조해야 한다.
- 고품질 학습 예시가 수백 개뿐이다 — 전용 학습이 배울 만큼의 데이터가 없다.
- 짧은 지시문만으로도 원하는 동작이 나온다 — 굳이 학습까지 갈 필요가 없다.
실제 사례에서도 RAG와 기본 지시문을 완전히 없애지 않았다. 반복해서 넣던 정보와 그 의존도를 크게 줄였을 뿐이다. 이상적인 설계는 형식은 전용 학습이 맡고, 바뀌는 사실은 RAG가 대는 분업이다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
“작은 전용 모델이 뜬다”는 헤드라인에 혹해서 곧장 학습부터 시작하면 십중팔구 시간과 데이터를 태운다. 순서를 뒤집어야 한다. 먼저 현재 방식의 오류를 종류별로 센다 — 누락, 불필요한 항목, 잘못된 분기, 순서 오류. 그리고 긴 지시문에서 절대 안 바뀌는 ‘형식’과 자주 바뀌는 ‘사실’을 분리한다.
이 분리를 마친 다음에야 판단이 선다. 세 조건(엄격한 형식·반복되는 지시문·희소한 양식)이 겹치면 전용 학습, 사실이 자주 바뀌면 RAG, 대부분은 둘의 조합. 그리고 약 98%가 나와도 의료·법률 문서라면 사람의 최종 검토는 없애지 않는다. 정확도 지표는 검토를 줄이는 근거일 뿐, 없애는 면허가 아니다.
도입 전 체크리스트
- 결과에 반드시 나와야 하는 필수 항목과 조건별 분기 규칙을 목록으로 고정했는가
- 실제 입력과 사람이 검토한 정답 결과를 짝으로 충분히 모았는가
- 현재 방식의 오류를 종류별로 세어 기준선(baseline)을 기록했는가
- 학습·인프라·데이터 정제 비용까지 포함해 총비용을 비교했는가 (API 비용만 보면 안 된다)
- 지식이 자주 바뀌는 부분은 RAG로 남겨 뒀는가
- 의료·법률 등 오류 비용이 큰 업무의 최종 확인 절차를 유지했는가
출처: Towards Data Science, 「How to Fine-Tune an LLM: An End-to-End Guide」 · 본문 수치(약 35%→98%, 63pp, 약 30k tokens, 약 $320,000, 약 8,000쌍)는 해당 사례의 구현 조건에서 나온 값이며 다른 업무에 그대로 적용되지 않을 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
