파인튜닝 프로젝트 기획과 목표 정의

파인튜닝의 출발점은 코드가 아니다

좋은 파인튜닝 프로젝트는 학습 스크립트를 실행하는 순간 시작되지 않는다. 먼저 정해야 할 것은 "모델을 어떻게 바꿀 것인가"가 아니라 "업무에서 무엇이 달라져야 하는가"이다.

예를 들어 고객지원 챗봇을 만든다면 목표는 단순히 답변을 잘하는 모델이 아니다. 반복 문의를 줄이고, 상담원이 확인해야 할 정보를 빠짐없이 묻고, 회사의 말투와 정책을 지키는 모델이어야 한다. 법무 검토 모델이라면 조항의 위험 요소를 찾고, 근거를 분류하며, 확정적 판단 대신 검토 의견 형식으로 답해야 한다. 의료 문서 요약 모델이라면 중요한 증상과 처방 정보를 빠뜨리지 않는 것이 핵심이다. 사내 지식봇은 최신 문서를 근거로 답하고, 모르면 모른다고 말하는 능력이 중요하다.

업무 목표가 다르면 학습 데이터도, 평가 방식도, 성공 기준도 달라진다. 파인튜닝은 모델에게 지식을 억지로 외우게 하는 작업이 아니라, 특정 상황에서 어떤 방식으로 답해야 하는지 경향을 조정하는 일에 가깝다.

비즈니스 목표를 학습 문제로 바꾸기

목표는 측정 가능한 문장으로 바꿔야 한다. "고객 응대를 잘하게 한다"는 목표로는 데이터도 평가도 설계하기 어렵다. 대신 다음처럼 바꾸는 것이 좋다.

• 배송, 환불, 계정 문의에 대해 정해진 정책 문구를 포함해 답한다.

• 답변 전에 주문번호, 가입 이메일 등 필요한 정보를 먼저 요청한다.

• 법무 검토 시 위험 조항을 낮음, 중간, 높음으로 분류한다.

• 의료 기록 요약에서 진단명, 약물, 검사 결과를 누락하지 않는다.

• 사내 지식봇은 문서에 없는 내용을 추측하지 않는다.

이렇게 정의하면 파인튜닝 데이터의 입력과 출력 형식이 보인다. 고객지원 데이터는 실제 문의와 모범 답변 쌍이 필요하다. 법무 검토는 조항, 위험 분류, 검토 의견이 함께 있어야 한다. 문서 요약은 원문과 사람이 검수한 요약본이 필요하다. 목표가 구체적일수록 데이터 설계가 쉬워진다.

성공 기준은 하나가 아니다

파인튜닝의 성공은 단순 정확도만으로 판단하기 어렵다. LLM은 자연어를 생성하므로 여러 기준을 함께 봐야 한다.

첫째, 정확도다. 분류나 추출 작업에서는 정답과 얼마나 일치하는지 확인한다. 법무 위험 등급, 문의 유형 분류, 문서 항목 추출처럼 답이 비교적 명확한 작업에 적합하다.

둘째, 유용성이다. 사용자가 실제로 문제를 해결할 수 있는 답변인지 평가한다. 고객지원에서는 답변이 친절해도 해결 절차가 빠져 있으면 유용하지 않다.

셋째, 일관성이다. 같은 정책과 같은 조건에서 답변이 흔들리지 않아야 한다. 특히 법무, 의료, 금융처럼 표현 하나가 오해를 만들 수 있는 영역에서는 중요하다.

넷째, 응답 형식 준수율이다. JSON, 표, 체크리스트, 이메일 초안처럼 정해진 형식이 있다면 모델이 그 형식을 안정적으로 지키는지 측정해야 한다. 운영 시스템과 연결할수록 형식 준수율은 핵심 지표가 된다.

이 지표들은 프로젝트 초기에 정해야 한다. 학습이 끝난 뒤 기준을 만들면 원하는 결과에 맞춰 평가를 해석하기 쉽다.

베이스 모델 선택 기준

파인튜닝은 빈 모델을 처음부터 만드는 일이 아니다. 이미 학습된 베이스 모델을 고르고, 그 위에 업무 특성을 입힌다. 이때 오픈소스 모델과 상용 API 모델 중 무엇을 쓸지 결정해야 한다.

오픈소스 모델은 통제권이 크다. 사내 환경에 배포할 수 있고, 데이터가 외부로 나가지 않도록 구성하기 쉽다. 비용 구조도 사용량이 커질수록 유리할 수 있다. 대신 GPU 인프라, 배포, 최적화, 보안 패치까지 직접 관리해야 한다.

상용 API 모델은 시작이 빠르다. 품질이 높고 운영 부담이 작으며, 최신 기능을 쉽게 사용할 수 있다. PoC 단계에서는 특히 유리하다. 다만 장기 비용, 데이터 처리 정책, 응답 지연, 모델 버전 변경에 따른 결과 변화 등을 확인해야 한다.

선택 기준은 단순히 성능이 아니다. 데이터 민감도, 예상 호출량, 지연 시간, 내부 운영 역량, 규제 요구사항, 장기 비용을 함께 봐야 한다.

PoC, 파일럿, 운영 전환

파인튜닝 프로젝트는 한 번에 운영으로 가면 위험하다. 단계별로 판단해야 한다.

PoC 단계의 질문은 "이 방식이 가능해 보이는가"이다. 작은 데이터셋으로 빠르게 실험하고, 프롬프트나 RAG만으로 해결 가능한지 함께 비교한다. 이 단계에서 완벽한 성능을 기대할 필요는 없다.

파일럿 단계의 질문은 "제한된 실제 환경에서 쓸 수 있는가"이다. 일부 사용자, 일부 업무 범위에 적용해 실패 사례를 모은다. 이때 평가 지표와 사람의 검수 결과를 함께 본다.

운영 전환 단계의 질문은 "지속적으로 관리할 수 있는가"이다. 성능 기준, 비용, 보안, 장애 대응, 모니터링, 재학습 절차가 준비되어야 한다. 모델이 한 번 잘 나온다고 끝이 아니다. 업무 정책과 데이터가 바뀌면 모델도 다시 점검해야 한다.

파인튜닝의 핵심은 더 큰 모델을 고르는 것이 아니다. 해결할 업무를 좁히고, 성공 기준을 먼저 정하며, 작은 실험으로 검증하는 것이다. 목표가 선명할수록 학습 데이터는 줄어들고, 평가 기준은 명확해지며, 운영 실패 가능성은 낮아진다.