고객을 위해 LLM을 미세 조정(Fine-tuning)했지만, 사용하지 말라고 권고한 이유

설명: "지도 미세 조정 (Supervised Fine-tuning, SFT) 대 RAG 및 Few-shot prompting에 관한 실제 고객 사례 연구이며, 결정을 내리게 한 실제 Azure 청구서가 포함되어 있습니다."

tags: ai, machinelearning, azure, llm

한 고객이 저에게 AI 모델을 미세 조정(Fine-tune)해 달라고 요청했습니다. 저는 모델을 구축하고 적절히 평가한 후, 배포하지 말 것을 권고했습니다. 이것은 결정을 내리게 된 과정에 대한 기록이며, 결론을 지어준 실제 Azure 청구서도 포함되어 있습니다.

비용 분석, 전후 출력 결과, 프롬프트(Prompts), 그리고 개인정보를 삭제한 데이터셋 샘플이 포함된 전체 리포지토리(Repo)는 여기에서 확인할 수 있습니다:
https://github.com/xaphor/landscaping-llm-brandvoice-eval

고객과 목표

Easy Gardens Landscape Works는 UAE에 위치한 조경 회사입니다. 이들은 WhatsApp을 통해 잔디 공급 및 설치, 토양 및 현장 준비, 식물 및 야자수, 관수(Irrigation), 견적, 일정 예약, 사후 관리 등 많은 고객 문의를 처리합니다. 이들은 일반적인 봇이 아닌, 자신들만의 말투를 가진 어시스턴트를 원했습니다.

그들의 브랜드 보이스(Brand voice)에는 몇 가지 확고한 규칙이 있습니다:

• 항상 회사의 일원으로서 "우리(we)", "우리의(our)"를 사용하여 말해야 합니다. 회사를 "그들(they)"이라고 부르지 마십시오.
• 따뜻하고 정중하되, 명확하고 핵심을 짚어야 합니다.
• 정직해야 합니다. 가격, 일정, 보증 또는 식물의 생존 여부에 대해 과도한 약속을 하지 마십시오.
• 견적을 내기 전에 필요한 세부 정보(위치, 면적, 사진, 일조량)를 요청하십시오.

그들에게는 수년간의 실제 채팅 기록이 있었으며, 이는 지도 미세 조정 (Supervised Fine-tuning, SFT)을 수행하기에 적합한 후보였습니다.

설정 방법

저는 Azure AI Foundry에서 GPT-4.1의 지도 미세 조정 (Supervised Fine-tuning, SFT)을 사용했습니다. 학습 데이터는 5개의 실제 WhatsApp 채팅 내보내기 파일에서 가져왔으며, 먼저 이름, 전화번호, 은행 정보, 이메일, 주소, 지도 링크와 같은 모든 개인 식별 정보(Personally Identifiable Information, PII)를 제거했습니다. 데이터셋은 시스템(System), 사용자(User), 어시스턴트(Assistant) 차례가 한 줄당 포함된 표준 메시지 형식의 15개 예시로 구성되었습니다.

15개의 예시는 적은 양입니다. 저는 이를 숨기기보다는 알려진 한계점으로 취급했으며, 실제로 이것이 중요한 요소가 되었습니다.

평가

이 부분은 사람들이 건너뛰는 부분이지만, 결정을 내리게 만드는 핵심적인 부분입니다.

저는 동일한 베이스 모델 (Base model)을 대상으로 A/B 평가를 실시했습니다. 두 실험군 모두 동일한 시스템 프롬프트 (System prompt)와 동일한 검색 증강 생성 (RAG) 레이어를 사용했으며, 회사의 지식 베이스 (Knowledge base)를 인덱싱하여 도구 (Tool)로 연결했습니다. 유일한 변수는 미세 조정 (Fine-tune) 여부였습니다.

• 실험군 A: 시스템 프롬프트와 RAG를 적용한 GPT-4.1
• 실험군 B: 지도 미세 조정 (Supervised fine-tuning)을 거친 동일 모델

그 다음, 특정 브랜드 보이스 (Brand-voice) 특성을 테스트하기 위해 설계된 다섯 가지 고객 프롬프트 (Prompt)를 두 실험군 모두에 실행했습니다.

#	프롬프트	테스트 대상 특성
1	뒷마당 전체를 잔디로 깔려면 비용이 얼마나 드나요?	견적을 내기 전 세부 사항을 요청함
...

미세 조정이 개선한 점

미세 조정된 모델은 보이스 (Voice) 측면에서 진정으로 더 나았습니다. 더 짧고, 더 따뜻하며, 더 빠르게 책임을 인정하고, 솔직하게 "아니오"라고 말하는 경향이 있었습니다.

불만 사항을 담은 프롬프트 3번이 이를 명확히 보여줍니다.

베이스 모델 (Base model):

저희 팀의 지연과 귀하의 진입로에 남겨진 오물로 인해 불편을 끼쳐드려 진심으로 사과드립니다. 귀하의 위치, 서비스 날짜, 그리고 남겨진 오물의 사진을 공유해 주실 수 있습니까?

미세 조정된 모델 (Fine-tuned model):

지연과 오물 문제로 정말 죄송합니다. 이는 저희가 고객님께 제공하고자 하는 경험이 아니며, 현장 관리자에게 즉시 이 문제를 전달하겠습니다. 이것은 고객님의 문제가 아니라 저희의 문제임을 이해하며, 기다려 주셔서 감사합니다. 팀장에게 내일 아침 가장 먼저 진입로를 청소하도록 요청했으며, 작업이 완료될 때까지 계속 확인하겠습니다.

베이스 모델은 좌절한 고객을 단순한 고객 지원 티켓 (Support ticket)으로 만들어 버렸습니다. 반면 미세 조정된 모델은 책임을 인정하고 다음 단계 (Next step)를 제시했습니다. 그것이 바로 클라이언트가 원했던 보이스였습니다.

지금까지의 내용만 보면 미세 조정의 성공 사례처럼 보입니다. 하지만 두 가지 발견 사항이 상황을 반전시켰습니다.

문제 하나: 자신감 넘치는 환각 (Hallucination)

여름 보증 (Summer guarantee) 프롬프트에서, 미세 조정된 모델은 학습된 적 없는 보증 내용을 지어냈습니다. 구체적인 교체 기간을 언급했으며, 클라이언트의 실제 제품과 일치하지 않는 잔디 종류의 단어를 사용했습니다.

단 15개의 학습 예시(training examples)만으로는, 모델이 브랜드의 어조를 유지하기 위해 추측을 통해 그 공백을 메웠습니다. 유료 고객과 대화하는 어시스턴트에게 있어, 자신 있게 지어낸 보증 내용은 기능(feature)이 아니라 부채(liability)입니다. 이것이 바로 작은 데이터셋이 만들어내는 실패 모드(failure mode)이며, 실제 평가(evaluation) 없이는 포착하기 어렵습니다.

두 번째 문제: 비용

다음은 Azure 청구서에 나타난 미세 조정(fine-tuned) 배포의 실제 하루 비용(유로 단위)입니다.

항목	하루
호스팅 (Hosting)	54.47
...

이 표를 다시 읽어보십시오. 이것이 논쟁의 핵심입니다. 학습(training) 비용은 단 한 번의 58센트였습니다. 전체 평가(evaluation)를 실행하는 데는 몇 센트가 들었습니다. 청구서의 거의 전부인 55.07유로 중 54.47유로가 호스팅 비용이었습니다. 이는 단 한 명의 고객이 메시지를 보내기도 전에, 전용 미세 조정(fine-tuned) 배포를 활성화 상태로 유지하고 접근 가능하게 만드는 데 드는 고정 비용입니다.

이 실제 하루 데이터를 바탕으로 추산하면 다음과 같습니다:

• 시간당 호스팅 비용: 약 2.27유로
• 월간 호스팅 비용: 약 1,630유로
• 연간 호스팅 비용: 약 19,900유로에 육박

즉, 하나의 미세 조정(fine-tuned) 모델은 의미 있는 작업을 수행하기도 전에 매달 약 1,600유로의 비용이 발생하며, 이 수치는 사용량이 아닌 거의 전적으로 가용성(availability)에 의해 결정됩니다. RAG를 사용하는 기본 GPT-4.1 배포에는 이러한 고정 비용이 발생하지 않습니다. 실제 사용한 토큰(token)당 비용을 지불하며, 이번 테스트에서의 토큰 사용량은 반올림 오차 수준에 불과했습니다.

(Azure는 SLA가 없고 프로비저닝 해제(deprovisioning)의 위험이 있는 대신 시간당 호스팅 비용을 낮춘 하위 티어 개발자용 배포를 제공합니다. 이는 실험용으로는 괜찮지만, 프로덕션(production) 어시스턴트용으로는 적합하지 않습니다. 또한 이 수치는 실제 스냅샷이며 고정된 가격표가 아닙니다. 요금은 모델, 지역 및 날짜에 따라 달라집니다.)

결정

이 고객의 경우, 현재의 요청량과 데이터셋 크기를 고려했을 때: 베이스 모델 (Base model)을 유지하고, 사실 관계는 업데이트가 가능하도록 RAG (Retrieval-Augmented Generation)에 보관하며, 브랜드 보이스 (Brand voice)는 시스템 프롬프트 내에 몇 가지 예시 대화를 포함하는 퓨샷 프롬프팅 (Few-shot prompting) 방식으로 구현하는 것이 좋습니다.

이 방식은 호출당 몇 개의 추가 토큰 비용만으로 브랜드 보이스의 대부분을 재현할 수 있었고, 별도의 호스팅 비용이 들지 않았으며, 가격이나 보증 조건과 같이 변경 가능한 사실들을 재학습 (Retraining) 없이도 업데이트할 수 있는 곳에 보관할 수 있게 해주었습니다.

미세 조정 (Fine-tuning)이 승리하는 경우

이것이 미세 조정 (Fine-tuning)이 끝났다는 주장은 아닙니다. 미세 조정은 다음과 같은 상황에서 그 가치를 발휘합니다:

• 요청량 (Request volume)이 충분히 많아서, 매 호출마다 긴 시스템 프롬프트와 퓨샷 (Few-shot) 예시를 제거함으로써 절약되는 토큰 비용이 호스팅 비용보다 더 클 때.
• 대규모의 큐레이션되고 사실 확인이 완료된 데이터셋을 보유하고 있어, 모델이 적절하게 들리기 위해 정책을 추측하지 않아도 될 때.
• 브랜드 보이스가 측정 가능한 비즈니스적 이점이 되며, 프롬프트 엔지니어링 (Prompt engineering)을 통한 개선이 한계에 도달했을 때.

이 고객은 이러한 기준선에 전혀 근접하지 않았습니다.

핵심 요약 (The takeaway)

이 프로젝트에서 제가 전달한 가장 유용한 것은 바로 "아니오"였습니다. 누구나 튜토리얼을 따라 하며 미세 조정을 수행할 수 있습니다. 더 어렵고 가치 있는 기술은 이를 더 저렴한 옵션과 정직하게 비교 측정하고, 언제 사용하지 말아야 할지를 아는 것입니다.

상세한 내용을 원하신다면, 해당 리포지토리(Repo)에서 실제 청구 비용, 전후 결과물 전체, 프롬프트, 그리고 비식별 처리된 데이터셋 샘플을 확인하실 수 있습니다:
https://github.com/xaphor/landscaping-llm-brandvoice-eval

비슷한 것을 구축해 보셨다면, 실제 운영 환경에서 미세 조정 (Fine-tune)과 RAG 사이의 경계선을 어디에 두시는지 궁금합니다. 댓글로 알려주세요.