파인튜닝 3번 중 2번은 프롬프트로 해결됐다

지난 6개월간 세 번의 파인튜닝 프로젝트를 진행했고, 그중 두 번은 결국 프롬프트 엔지니어링으로 되돌아왔다. 남은 한 번은 프로덕션에 잘 돌아가고 있지만, 그마저도 "파인튜닝이 정답이었나"를 매달 자문한다.

#첫 번째 시도: 고객 문의 분류

CS팀에서 들어오는 문의를 15개 카테고리로 자동 분류하는 게 목표였다. GPT-4 프롬프트로는 정확도가 78%쯤 나왔고, "파인튜닝하면 90% 넘기겠지"라는 기대로 프로젝트가 시작됐다.

데이터 준비부터 난관이었다. 기존 CS 데이터에서 2만 건을 뽑았는데, 라벨 품질이 문제였다. 상담원마다 같은 문의를 다른 카테고리로 분류한 경우가 20%가 넘었다. "이건 '배송'인가 '교환'인가" 같은 경계 케이스에서 일관성이 없었다.

3주간 라벨 정제 작업을 거쳐 5,000건의 깨끗한 데이터셋을 만들었다. QLoRA로 Llama 3 8B를 파인튜닝했고, 오프라인 eval에서 92%가 나왔을 때 팀 전체가 환호했다.

문제는 프로덕션이었다.

배포 후 첫 주에 새로운 유형의 문의가 들어왔다 — 신규 서비스 론칭으로 기존 15개 카테고리에 없는 건이 쏟아졌다. 파인튜닝 모델은 학습 때 본 카테고리로만 강제 분류했고, 정확도가 급락했다. 프롬프트 기반이었다면 카테고리 목록만 수정하면 됐을 텐데, 파인튜닝 모델은 재학습이 필요했다.

결국 프롬프트 + few-shot으로 돌아갔다. GPT-4o에 잘 설계된 프롬프트를 넣으니 85%가 나왔고, 카테고리 변경에 5분이면 대응할 수 있었다. 비용은 좀 더 들지만, 운영 유연성이 압도적이었다.

#두 번째: 보고서 요약

내부 보고서를 3줄로 요약하는 파인튜닝. 이건 더 빨리 포기했다.

학습 데이터를 만드는 게 본질적 병목이었다. "좋은 요약"의 기준이 팀원마다 달랐다. 어떤 사람은 핵심 수치 위주, 어떤 사람은 결론 위주, 어떤 사람은 배경 맥락 위주. 골드 라벨 자체가 존재하지 않는 태스크였다.

Claude 3.5 Sonnet에 "이 보고서에서 의사결정에 필요한 정보만 3줄로"라는 프롬프트를 넣었더니 80%의 사용자가 만족했다. 파인튜닝 데이터를 만드는 노력 대비 프롬프트 한 줄의 ROI가 훨씬 높았다.

#세 번째가 성공한 이유

세 번째는 의료 용어 추출이었다. 환자 기록에서 약물명, 증상, 진단코드를 정형화해서 뽑는 태스크. 이게 파인튜닝의 적합한 케이스였던 이유:

• 도메인이 좁고 안정적이다. 의료 용어 체계(ICD-10, ATC 코드)는 수십 년간 유지되는 표준이다. 내일 갑자기 카테고리가 바뀌지 않는다.

• 골드 라벨이 명확하다. "이부프로펜"이 약물명인지 아닌지는 논쟁의 여지가 없다.

• 프롬프트만으로는 한계가 있었다. 범용 LLM은 한국 의료 현장의 줄임말이나 비표준 표기("타이레놀" vs "아세트아미노펜")를 자주 놓쳤다. 파인튜닝 후 F1 스코어가 0.71에서 0.94로 뛰었다.

• 재학습 주기가 길다. 분기 1회 정도면 충분하다.

QLoRA로 Llama 3 70B를 단일 A100 한 장에서 학습시켰다. full fine-tuning 대비 클라우드 비용이 약 8분의 1이다. 학습 데이터는 800건 — 적어 보이지만 태스크가 명확할수록 적은 데이터로도 충분하다.

#파인튜닝 의사결정 체크리스트

6개월간의 경험을 정리하면 이렇다:

핵심은 "파인튜닝이 더 좋은 성능을 줄까"가 아니라 "파인튜닝의 운영 비용을 감수할 만큼 프롬프트가 부족한가"다.

#남은 질문

세 번째 프로젝트도 완벽하지는 않다. 학습 데이터에 없는 신약이 등장하면 추출을 못하고, 이걸 위한 주기적 재학습 파이프라인을 결국 만들어야 했다. 월요일에 데이터 수집, 화요일에 학습, 수요일에 eval, 목요일에 스테이징, 금요일에 프로덕션 — 이 주간 사이클 자체가 하나의 인프라다.

파인튜닝을 "모델 학습"으로만 보면 안 된다. 데이터 파이프라인, eval 인프라, 배포 자동화, 모니터링까지 포함한 시스템으로 봐야 한다. 이 모든 걸 감당할 준비가 안 됐으면, 프롬프트 엔지니어링이 거의 항상 정답이다.