Your Fine-Tuned Model Is Tech Debt: A 50x ROI House of Cards — Dan Bjornn, Lease End

한 줄 핵심

고객 의도 분류를 fine-tuning으로 해결한 사례처럼 보였지만, 실제로는 모델을 바꾸는 것보다 skills·tools·context로 재구성하는 편이 더 정확하고 빠르며 총비용도 낮았다.

시간별 요약

1. 0:00
   검색 기반으로 고객 의도 분류 시작 Lease End는 자동차 리스 종료 고객을 위한 LLM 기반 메시징 앱을 만들었고, 처음에는 벡터DB에 저장된 과거 메시지를 검색해 고객 의도를 분류하는 RAG 워크플로를 사용했다. 하지만 대화의 미묘한 뉘앙스를 충분히 잡지 못해 성능 한계가 드러났다.
2. 1:54
   fine-tuning을 택할 만한 네 가지 이유 정확도 향상, 더 작은 모델로 인한 비용·지연 감소, 좁고 구조화된 분류 과제와의 적합성, 모델 공급자에 대한 의존도 완화라는 이유로 fine-tuning이 합리적으로 보였다. 고객 의도 분류는 여섯 개 범주 중 하나로 묶는 문제였기 때문에 supervised fine-tuning에 잘 맞는다고 판단했다.
3. 3:32
   파이프라인 구축과 50x ROI의 성공 예시 수집, LLM-as-judge 라벨링, 수동 검토, holdout set 구성, fine-tuning, 지표 확인까지 이어지는 파이프라인을 만들었다. 이 앱은 1년 안에 $12 million 매출과 50x ROI를 만들었지만, 겉으로 드러나지 않는 기술 부채가 함께 쌓이고 있었다.
4. 4:24
   혼란스러운 확인 응답과 지나치게 성급한 응답 예약 확인 메시지에 사용자가 단순히 "Sounds good."이라고 답했는데도 모델이 즉시 전화를 걸겠다고 반응해, 다음 날 일정인데도 지금 전화하는 오작동이 발생했다. 또 다른 경우에는 인사말만 왔을 뿐인데 모델이 곧바로 전화를 시작해, 실제 운영 환경에서 고객 불만과 기회 손실을 만들었다.
5. 6:04
   재학습은 일주일, 학습 자체는 가장 짧은 단계 문제 수집, 예시 부족분 합성, LLM 생성 예시 검증, 라벨링, 수동 리뷰, 재학습, 평가, 배포까지 전체 과정이 약 일주일 걸렸다. 학습 자체는 보통 1시간 정도로 가장 짧았지만, 재학습 후 다른 기능이 망가지는 회귀가 반복되어 whack-a-mole 같은 운영이 되었다.
6. 8:39
   고객이 견딜 수 있는 피해 기준으로 버그 우선순위화 모든 문제를 바로 재학습으로 해결할 수 없어서, 발생 빈도와 고객 경험 훼손 정도를 기준으로 우선순위를 정했다. 재학습을 피할 수 있으면 임시방편을 먼저 쓰며 버그를 고객 피해 허용 수준에 따라 관리했고, 이 과정이 calcification tax로 이어졌다.
7. 9:31
   모델과 아키텍처가 굳어지는 비용 fine-tuning은 모델을 더 자유롭게 바꾸게 해주기는커녕, 버전 차이와 공급자별 데이터 형식 차이 때문에 오히려 특정 모델에 묶이게 만들었다. 또한 2024년식 workflow 중심 아키텍처에 고정되어, 빠르게 변하는 새로운 AI 구조를 도입하기 어려워졌다.
8. 11:18
   모델보다 skill과 context를 바꾸는 발상 Claude Code를 쓰면서 작업마다 모델을 바꾸는 대신, skill과 context를 바꾸면 결과가 달라진다는 점을 체감했다. 이 깨달음을 메시징 앱에 적용해, fine-tuning 대신 skills, tools, resources를 주입하는 방식으로 전환했다.
9. 12:14
   skills·tools·context로 다시 설계 재구성 이후에는 문제가 생기면 system prompt나 해당 skill만 조정하고, 그동안 모아 둔 curated set으로 검증한 뒤 반복 배포하는 흐름이 되었다. 이전의 일주일짜리 재학습 사이클 대신 훨씬 짧고 유연한 운영이 가능해졌다.
10. 13:08
    MD 파일 업로드만으로 한 시간 내 수정 배포 이제는 문제 발견부터 수정 배포까지 1시간도 걸리지 않았고, 수정은 S3 bucket에 MD files를 업로드하는 수준으로 단순해졌다. 메시지당 API 비용은 조금 올랐지만 정확도는 더 좋아졌고, 총비용과 운영 부담은 오히려 줄었다.
11. 14:54
    fine-tuning 전에 이유를 하나씩 지워 보기 정확도, 비용, 지연, 구조화된 과제, 공급자 통제라는 fine-tuning의 장점은 실제 운영에서 기대만큼 성립하지 않았다. frontier model을 전혀 쓸 수 없거나 오프라인·프라이버시 제약이 극단적으로 강한 경우가 아니면, fine-tuning은 장기적으로 기술 부채가 되기 쉽다.

실무 인사이트

• fine-tuning을 검토할 때는 정확도·비용·지연·제어권의 기대효과를 실제 총비용과 운영 복잡도까지 포함해 다시 계산해야 한다.
• 고객 의도 분류처럼 보이는 좁은 문제도, 재학습 주기와 회귀 비용이 커지면 모델 학습보다 context와 skill 분리가 더 나은 해법이 될 수 있다.
• 운영 중인 AI 시스템은 모델 성능만 보지 말고, 수정 배포 시간과 아키텍처의 유연성을 핵심 지표로 함께 관리해야 한다.