로컬 소형 LLM은 언제 쓸까 — RAG 먼저, 파인튜닝은 마지막

요즘 로컬에서 소형 LLM을 돌리는 이야기가 자주 보여요. API 비용도 아끼고 데이터도 밖으로 안 나간다니, 혼자 서비스를 운영하는 입장에선 솔깃하죠.

그래서 직접 돌려 봤어요. 설치부터 첫 응답까지 10분 정도면 충분했어요. 문제는 그다음이었죠.

로컬 소형 모델, 직접 돌려 보니

분류나 태그 달기, 민감한 값 가리기 같은 단순 반복 작업은 꽤 쓸 만했어요. 반면 코드 작성이나 사실 확인을 맡겨 보면 틀린 답을 자신 있게 내놓을 때가 있어요. 검수 없이 믿기는 어렵더라고요.

제 기준은 두 가지로 좁혀졌어요. 한 달에 수만 건씩 도는 대량 배치이거나, 외부로 보낼 수 없는 데이터일 때만 로컬 모델을 써요. 둘 다 아니라면 API가 더 싸고 빨랐어요.

• ✓대량 반복 배치
• ✓밖으로 못 보내는 데이터
• ✓둘 다 아니면 API

지식을 넣고 싶다면 순서는 3단계

모델이 우리 도메인을 모른다고 바로 파인튜닝부터 떠올리기 쉬운데, 순서를 지키면 대부분 그 전에 끝나요.

프롬프트 다듬기→RAG(검색 연결)→파인튜닝

저는 법령·판례 검색 서비스 플랜엘(plan-l)을 만들면서 이 순서를 몸으로 배웠어요. 법령은 계속 개정되니까, 지식을 모델 안에 굽는 대신 국가법령정보센터와 대법원 데이터를 그대로 검색해 보여주는 구조를 택했죠. 덕분에 데이터가 바뀌어도 재학습 없이 원본만 갱신하면 되고, 답의 출처도 함께 보여줄 수 있어요. 월 3건까지 무료라 가볍게 써 보실 수 있어요.

파인튜닝은 정말 마지막이에요

파인튜닝은 데이터가 갱신될 때마다 다시 학습해야 하고, 예시가 적으면 과적합으로 오히려 나빠지기 쉬워요. 저는 세 가지가 모두 채워지기 전엔 시작하지 않아요. 검색을 붙여서 한계를 먼저 확인했을 때, 같은 좁은 작업이 주 5시간 이상 반복될 때, 학습 예시가 100건 넘게 쌓였을 때요.

테스트해 보면 대부분의 요구는 두 번째 단계, 그러니까 검색을 붙이는 선에서 해결돼요. 라이프케어로그 도구들을 만들며 파인튜닝까지 간 적은 아직 없어요.

혼자 만들 때 가장 비싼 자원은 시간이에요. 무거운 방법은 가벼운 방법이 실패한 뒤에 꺼내도 늦지 않아요. 지금 파인튜닝을 계획하고 있다면, 검색부터 붙여 보세요.