실전 사례로 배우는 LLM 파인튜닝 활용

사례 1: 고객센터 상담 요약·분류

고객센터 모델의 목표는 상담 내용을 짧게 정리하고, 문의 유형과 처리 상태를 안정적으로 분류하는 것입니다. 이때 학습 데이터는 단순한 대화 전문만으로는 부족합니다. 고객 발화, 상담사 응답, 상담 결과, 문의 유형, 감정 상태, 후속 조치 여부를 함께 기록해야 합니다.

좋은 데이터 한 건은 다음 정보를 포함합니다. 원문 대화, 핵심 요약, 분류 라벨, 해결 여부, 고객 불만 원인, 금지해야 할 표현입니다. 특히 요약 데이터에는 모델이 추측하지 않도록 "확인된 사실만 요약한다"는 기준을 넣어야 합니다.

평가는 두 축으로 나눕니다. 분류는 정확도, 재현율, 혼동 행렬로 봅니다. 예를 들어 "환불"과 "배송 지연"을 자주 혼동하는지 확인합니다. 요약은 사람이 검수해야 합니다. 빠진 정보, 잘못 추가한 정보, 개인정보 노출 여부를 확인합니다. 운영 전에는 실제 상담사에게 블라인드 평가를 맡겨 기존 요약 방식보다 시간이 줄고 품질이 유지되는지 확인하는 것이 좋습니다.

사례 2: 사내 문서 기반 업무 비서

사내 업무 비서는 파인튜닝만으로 만들면 위험합니다. 사내 규정, 정책, 제품 문서는 자주 바뀌기 때문입니다. 이런 지식은 RAG로 검색해 가져오고, 파인튜닝은 답변 태도와 형식을 맞추는 데 쓰는 편이 안정적입니다.

예를 들어 인사 규정 비서를 만든다면 최신 휴가 규정은 문서 검색으로 가져옵니다. 지시 튜닝 데이터에는 "근거 문서를 먼저 확인한다", "문서에 없으면 모른다고 말한다", "민감한 인사 정보는 요청해도 답하지 않는다" 같은 행동 규칙을 담습니다.

평가도 분리해야 합니다. 답이 틀렸을 때 검색이 실패했는지, 모델이 검색 결과를 잘못 해석했는지 나눠 봐야 합니다. 검색 평가는 관련 문서가 상위 결과에 나오는지 확인합니다. 생성 평가는 답변이 문서 근거와 일치하는지, 출처를 표시하는지, 권한 밖 질문을 거절하는지 확인합니다.

사례 3: 개발자 도구용 코드 어시스턴트

코드 어시스턴트는 단순히 코드를 많이 학습시키는 것보다 안전한 개발 흐름을 학습시키는 것이 중요합니다. 데이터는 이슈 설명, 기존 코드, 수정 diff, 테스트 코드, 코드 리뷰 의견을 함께 구성하는 것이 좋습니다. 그래야 모델이 "어떤 문제를 왜 이렇게 고쳤는지"를 배웁니다.

전처리에서는 비밀키, 내부 URL, 고객 식별자, 접근 토큰을 반드시 제거해야 합니다. 라이선스가 불명확한 외부 코드도 주의해야 합니다. 코드 데이터는 중복이 많기 때문에 같은 함수나 템플릿이 반복되면 모델이 특정 패턴만 외울 수 있습니다.

안전장치도 필요합니다. 모델이 삭제 명령, 권한 상승 코드, 취약한 암호화 방식, SQL 인젝션 가능 코드 등을 제안하지 않도록 거절 예시와 수정 예시를 함께 학습시킵니다. 운영 환경에서는 생성 코드를 바로 실행하지 말고 테스트, 정적 분석, 리뷰 단계를 거치게 해야 합니다. 파인튜닝은 팀의 코딩 스타일과 리뷰 기준을 맞추는 데 쓰고, 최신 저장소 구조나 API 문서는 RAG로 보강하는 설계가 현실적입니다.

사례 4: 한국어 도메인 모델

한국어 모델을 만들 때는 번역 데이터만으로 충분하지 않습니다. 한국어는 높임말, 조사, 어순, 생략 표현에 따라 의미와 인상이 달라집니다. 의료, 법률, 금융처럼 전문 분야에서는 같은 개념도 현장에서 쓰는 표현이 따로 있습니다.

따라서 도메인 용어집을 먼저 만들고, 같은 의미의 약어·영문 표기·한글 표기를 연결해야 합니다. 예를 들어 "KYC", "고객확인", "본인확인 절차"가 같은 맥락에서 쓰이는지 정리합니다. 말투도 중요합니다. 고객 응대 모델이라면 정중하지만 길지 않은 문장을 학습시켜야 하고, 내부 분석 도구라면 간결한 보고서체가 더 적합할 수 있습니다.

평가에는 한국어 특유의 기준을 넣어야 합니다. 존댓말이 일관적인지, 전문용어를 임의로 풀어 쓰지 않는지, 영어 약어를 잘못 번역하지 않는지, 모호한 주어를 잘못 해석하지 않는지 확인합니다. 가능하면 도메인 전문가와 실제 사용자가 함께 평가해야 합니다.

사례에서 얻는 공통 원칙

실전 파인튜닝은 "모델을 똑똑하게 만드는 작업"이 아니라 "특정 업무에서 반복 가능한 성능을 만드는 작업"입니다. 먼저 문제를 좁히고, 성공 기준을 숫자와 검수 기준으로 정의해야 합니다. 그다음 데이터, 기법, 평가, 보안 절차를 맞춥니다.

지식이 자주 바뀌면 RAG를 우선 고려합니다. 답변 형식, 말투, 절차 준수, 분류 기준이 중요하면 파인튜닝이 효과적입니다. 둘을 함께 쓸 때는 RAG가 근거를 제공하고, 파인튜닝이 그 근거를 업무 방식에 맞게 사용하는 구조가 좋습니다.

마지막으로 작은 실험부터 시작해야 합니다. 대표 사례 100~500건으로 기준 모델을 만들고, 실패 유형을 분석한 뒤 데이터를 보강합니다. 이 과정을 반복하면 파인튜닝은 비용이 큰 도박이 아니라 관리 가능한 개선 프로젝트가 됩니다.