fine-tuning 은 정말 필요한가, 우리 케이스에서는

결제·정산 현장에서 LLM 품질 문제가 특히 까다로운 이유

일반적인 챗봇 서비스에서 모델이 약간 엉뚱한 대답을 해도 사용자가 재질문하면 그만이다. 하지만 정산 자동화 파이프라인에서는 사정이 다르다. LLM이 잘못된 JSON을 뱉거나, 거래 건을 틀린 카테고리로 분류하거나, 엉뚱한 수수료 정책을 참조하면 — 그 오류는 조용히 다음 단계로 흘러간다. 대사포를 쏘는 게 아니라 콘크리트에 금 하나가 가는 것과 같다. 처음엔 안 보이다가 나중에 크게 터진다. 우리가 LLM을 도입하면서 가장 먼저 배운 것은 "그럴 수도 있지"가 통하지 않는 환경이라는 사실이다.

이 맥락에서 "우리 데이터로 fine-tuning 하면 더 잘 되지 않을까?"라는 질문은 매우 자연스럽게 나온다. 팀 내에서도 꽤 진지하게 올라온 주제였다. LLM을 처음 붙인 기능 중 하나가 PG사별로 다르게 들어오는 거래 명세(transaction description)를 내부 카테고리로 분류하는 작업이었는데, 이 시점에서 fine-tuning 논의가 본격적으로 시작됐다. PG사마다 같은 업종을 다른 용어로 표기하고, 동일한 PG사도 수수료 정책이 바뀌면 명세 포맷이 달라진다. 언뜻 보면 "우리 데이터로 모델을 길들이면 되지 않나?" 싶었다.

fine-tuning이 실제로 해결하는 것과 해결하지 못하는 것

fine-tuning의 핵심 강점은 하나다: 모델이 특정 출력 형식·스타일·어조를 매우 일관되게 따르도록 만드는 것. "이 입력이 들어오면 이 구조로 출력해"를 반복 학습시키는 과정이다. 법률 문서의 특정 어투, 매우 특이한 JSON 키 구조처럼 프롬프트만으로는 일관성을 잡기 어려운 스타일 문제에서는 효과적이다.

반면 fine-tuning으로 해결하기 어려운 세 가지가 있다. 첫째, 모델이 애초에 몰랐던 사실 정보를 새로 주입하는 것. 둘째, 자주 바뀌는 최신 데이터를 반영하는 것. 셋째, 복잡한 추론 능력 자체를 높이는 것. 우리 케이스인 PG사별 명세 분류는 "모델이 몰랐던 우리 카테고리 정의"이자 "분기마다 바뀌는 매핑 정보"에 해당한다. 즉, fine-tuning이 잘 못 하는 두 번째 유형에 정확히 걸린다. 결론이 먼저 나왔다 — 이 문제의 해법은 fine-tuning이 아니다.

실제로 시도한 것: 프롬프트 + RAG로 먼저 때웠다

우리가 실제로 한 순서는 간단하다. 1단계: 프롬프트에 few-shot 예시 3건을 넣고, 출력을 JSON 스키마로 강제했다. 이것만으로 형식 불안정 문제의 대부분이 잡혔다. GPT-4o 기준으로 이 변경 후 출력 형식 정확도가 61%에서 94%로 올라갔다. 프롬프트 수정과 스키마 지정에 쓴 시간은 이틀이다.

2단계: 형식은 잡혔는데 도메인 분류가 틀리는 케이스가 남았다. 여기에는 RAG를 붙였다. 우리 내부 카테고리 정의 문서와 PG사별 주요 명세 패턴 매핑 테이블(합산 약 2,000 토큰)을 컨텍스트에 함께 주입했다. 결과적으로 도메인 분류 정확도가 78%에서 96%로 올랐다. fine-tuning 없이 달성한 수치다. RAG의 가장 큰 장점은 정책이나 포맷이 바뀌면 인덱스 업데이트만 하면 된다는 점이다. PG사 수수료 구조가 바뀌어도 재학습 사이클이 필요 없다.

fine-tuning의 실제 비용: 숫자로 환산하면

fine-tuning을 도입할 때 우리가 실제로 계산한 비용 항목들이다.

데이터 준비 비용: 정산 도메인에서 품질 좋은 학습 데이터 500건을 만드는 데 팀 내부 리소스로 약 2~3주를 잡았다. 거래 명세 레이블링은 "이 거래가 왜 이 카테고리인가"를 판단해야 하기 때문에 도메인 이해가 있는 사람이 해야 한다. 외주나 크라우드소싱으로 해결하기 어렵다. 인건비 기준으로 환산하면 수백만 원대 비용이 한 번 학습분에만 든다.

재학습 주기 비용: 실제로 우리 PG사 파트너 중 한 곳은 연 23회 명세 포맷이 바뀐다. fine-tuning 모델을 운용 중이었다면 데이터를 다시 만들고 재학습해야 한다. OpenAI fine-tuning의 학습 비용 자체는 수십 달러 수준으로 크지 않지만, 데이터 재준비 인건비가 반복된다. 6개월 운용 기준으로 총비용을 계산하면 초기 도입비의 23배가 된다는 계산이 나왔다.

평가 파이프라인 비용: fine-tuning이 실제로 더 나은지 측정하려면 골든 데이터셋과 자동 평가 스크립트가 필요하다. 이게 없으면 "더 좋아진 것 같다"는 주관적 판단에 그친다. 그리고 평가 파이프라인을 제대로 구축하는 비용은 fine-tuning 자체보다 오래 걸릴 수 있다. 5명 이하 엔지니어링 조직에서 이 파이프라인 구축에 한 명이 3~4주를 쓰는 것은 기회비용이 크다.

fine-tuning이 실제로 의미 있는 조건

fine-tuning이 맞는 선택인 경우는 분명히 있다. 명확한 조건을 정리하면:

프롬프트만으로 스타일 일관성을 잡기 어렵다: 매우 특수한 어조, 독자적인 출력 구조가 요구되는 경우
학습 데이터가 충분하고 품질이 보장된다: 최소 수백 건, 레이블 품질이 검증된 상태
서비스 요구사항이 비교적 안정적이다: 도메인 정의나 정책이 자주 바뀌지 않는 환경
평가 파이프라인이 이미 존재한다: 성능 개선을 측정할 수 있는 기반이 있어야 한다
재학습 사이클을 감당할 여유가 있다: 사람과 시간 모두

우리 팀은 현재 세 번째와 네 번째 조건을 충족하지 못한다. 정산 정책은 분기마다 바뀌고, 공식 평가 파이프라인은 아직 구축 중이다. 이 두 조건이 해결되지 않은 상태에서 fine-tuning을 도입하면, 효과를 측정할 수도 없고 유지 비용만 늘어난다.

지금 바로 써먹을 수 있는 4단계 판단 기준

fine-tuning을 고민하고 있다면, 우리가 실제로 쓰는 결정 순서다. 이 순서 그대로 적용하면 된다.

Step 1 — 문제 유형을 먼저 분류하라. 출력 형식이 불안정한 것인가, 도메인 지식이 없는 것인가, 추론 품질 자체가 낮은 것인가? 형식 문제라면 JSON 스키마 강제와 few-shot으로 먼저 시도하라. 도메인 지식 부재라면 RAG로. 추론 품질이 문제라면 모델 티어를 올리거나 Chain-of-Thought를 붙이는 방향을 먼저 본다. fine-tuning은 이 세 가지를 다 써보고도 해결이 안 될 때 꺼내는 도구다.

Step 2 — RAG를 먼저 구현하라. 특히 결제·정산처럼 도메인 데이터가 자주 바뀌는 환경에서는 RAG가 fine-tuning보다 유지보수 비용이 압도적으로 낮다. 매핑 테이블, 정책 문서, 카테고리 정의를 벡터 DB에 올리고 컨텍스트에 주입하는 구조를 먼저 만들어라. 변경이 생기면 인덱스 업데이트로 끝난다.

Step 3 — 평가 파이프라인 없이는 fine-tuning하지 마라. "더 잘 되는 것 같다"는 감각으로 fine-tuning을 유지하는 것은 비용 낭비다. 최소한 레이블된 테스트 케이스 50~100건과 자동 정확도 측정 스크립트가 있어야 한다. 평가 파이프라인 구축이 먼저다.

Step 4 — 6개월 운용 비용을 명시적으로 계산하라. "fine-tuning 한 번"이 아니라 "6개월 운용" 기준으로 데이터 재준비 + 재학습 + 평가 비용을 팀 인건비로 환산해보라. 초기 제품 단계에서 이 숫자가 예상보다 훨씬 크게 나오는 경우가 많다. 이 계산을 해본 뒤에도 fine-tuning이 낫다는 결론이 나오면, 그때가 도입 타이밍이다.

우리 팀의 현재 결론은 단순하다. 프롬프트 엔지니어링과 RAG로 90% 이상의 문제를 해결하고, fine-tuning은 그 이후 명확한 조건이 충족됐을 때 꺼내는 도구로 남겨둔다. 도구 자체의 성능이 아니라 "지금 이 문제와 이 팀 상황에 맞는가"를 먼저 따지는 것이 순서다.

— by mings