파인튜닝한 모델은 기술 부채다: 50배 ROI라는 모래성

URL: https://www.youtube.com/watch?v=4loPnxvWWhg
날짜: 2026-08-21
채널: aiDotEngineer
발표자: Dan Bjornn, Lease End 수석 데이터 과학자

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==파인튜닝(fine-tuning)은 당장의 정확도와 ROI를 올려도, 운영·데이터·모델·아키텍처를 함께 굳혀 장기적으로 기술 부채(technical debt)를 만들 수 있다. 프런티어 모델(frontier model)에 충분한 컨텍스트를 주는 에이전트형 시스템이 문제를 더 빠르고 정확하게 고치는지 먼저 검증해야 한다.==

• 좁고 구조화된 분류 문제, 작은 모델, 대규모 실시간 트래픽이라는 조건은 파인튜닝을 매우 합리적으로 보이게 했다.
• 실제로 애플리케이션은 1년 안에 1,200만 달러의 매출과 50배 ROI를 만들었지만, 운영 중 발생한 오류를 고치는 데 매번 일주일이 필요했다.
• 파인튜닝 데이터와 모델 인터페이스에 묶인 결과 모델 교체·업그레이드·새 아키텍처 도입이 비싸졌고, 시스템은 문제를 고칠수록 더 경직됐다.
• 시스템 프롬프트(system prompt), 스킬(skills), 도구(tools), 리소스(resources), 컨텍스트(context)를 조정하는 에이전트형 재구축은 메시지당 API 비용은 조금 높였지만 정확도와 반응성을 높이고 총비용을 낮췄다.

사례의 핵심은 “파인튜닝이 절대 쓸모없다”가 아니다. 개인정보·데이터 통제·오프라인 실행처럼 프런티어 모델 API를 호출할 수 없는 경우에는 파인튜닝이 유효할 수 있다. 다만 일반적인 비용·정확도·지연시간·작업 범위의 이유만으로 파인튜닝하기 전에, 컨텍스트 설계로 해결할 수 없는지와 기술 부채 세금을 감당할 수 있는지를 따져야 한다.

1. Lease End의 문제와 첫 번째 LLM 시스템

Lease End는 자동차 리스가 끝나는 고객을 금융 옵션과 연결해 리스를 매입하고 현재 차량을 계속 보유하도록 돕는다. 고객과 영업팀의 문자 대화를 자동화하는 과정에서 파인튜닝의 매력과 함정을 모두 경험했다.

1.1. 제품 맥락과 LLM 애플리케이션

1. 자동차 리스 만기 고객과 금융 옵션 연결

   1. 고객 여정: Lease End는 자동차 리스 만기를 앞둔 사람에게 금융 옵션을 연결하고, 고객이 리스를 매입해 차를 계속 탈 수 있도록 돕는다.
   2. 대화 채널: 2024년 말 고객이 문자(text)로 영업팀과 대화할 수 있는 LLM 기반 애플리케이션을 만들었다.
   3. 자동화 범위: 고객은 판매 절차에 관해 질문하고, 통화를 예약하고, 리마인더(reminder)를 받을 수 있었다.

2. 실시간 메시지 처리의 운영 조건

   1. 처리량: 시스템은 하루 수천 건의 메시지를 실시간으로 처리해야 했다.
   2. 핵심 판단: 고객이 지금 통화를 원하는지, 통화를 예약하려는지, 수신을 거부(opt out)하려는지를 정확히 구분해야 했다.
   3. 오류의 사업적 영향: 의도(intent)를 잘못 분류하면 이후의 워크플로와 고객 접촉이 모두 틀어졌다.

1.2. 워크플로 기반 RAG의 한계

1. 첫 번째 구조: RAG와 벡터 데이터베이스

   1. 검색 방식: 첫 솔루션은 워크플로 기반 접근법(workflow-based approach)이었고, RAG(retrieval-augmented generation) 시스템 위에서 동작했다.
   2. 데이터 저장: 이미 본 메시지를 고객 의도와 함께 분류해 벡터 데이터베이스(vector database)에 저장했다.
   3. 대화 응답: 새 메시지가 들어오면 유사한 과거 메시지를 검색해 그 의도에 맞는 다음 행동을 선택했다.

2. 단순한 문장과 실제 의도의 차이

   1. 나중에 대화하고 싶은 경우: “내일 전화해 줘(call me tomorrow)”는 고객이 나중에 이야기하고 싶다는 의도로 분류했다.
   2. 즉시 대화하고 싶은 경우: “지금 시간 돼(I’ve got time now)”는 고객이 바로 이야기하고 싶다는 의도로 분류했다.
   3. 문맥의 문제: 실제 문자와 대화에는 표현의 뉘앙스가 많았고, RAG 접근법은 그 미묘한 차이를 안정적으로 포착하지 못했다.
   4. 초기 평가: 시스템은 작동했지만 “엄청나게 대단한(super amazing)” 수준은 아니었다.

2. 파인튜닝을 선택한 이유와 50배 ROI

파인튜닝은 당시 조건에서 정확도, 비용, 지연시간, 운영 통제권을 동시에 해결할 것처럼 보였다. 좁은 분류 과제라는 점이 특히 강한 근거였다.

2.1. 파인튜닝이 합리적으로 보였던 네 가지 이유

1. 정확도가 시스템 전체의 전제였다

   1. 의도 분류의 중요성: 전체 시스템은 사용자 의도를 올바르게 얻는 데 기반했다.
   2. 분류 대상: 고객이 지금 말하고 싶은지, 통화를 예약하고 싶은지, 수신을 거부하고 싶은지를 먼저 알아야 했다.
   3. 선결 조건: 이후의 모든 자동화가 이 결정에 매달렸으므로 정확도를 가장 먼저 확보해야 했다.

2. 작은 모델로 비용과 지연시간을 낮출 수 있다고 기대했다

   1. 모델 크기: 파인튜닝하면 더 작은 모델을 사용할 수 있다고 판단했다.
   2. 비용·지연시간: 작은 모델은 호출 비용과 응답 지연시간(latency)을 낮출 것으로 예상했다.
   3. 확장성: 하루 수천 건을 실시간 처리해야 했으므로 이 효과는 사업 확장에 중요했다.

3. 좁고 구조화된 작업이었다

   1. 분류 문제: 대화 전체를 창작하거나 복잡하게 추론하는 일이 아니라, 여섯 개 카테고리 중 하나로 버킷(bucket)화하는 일이었다.
   2. 지도학습 적합성: 여섯 범주의 차이를 학습시키는 구조는 지도형 파인튜닝(supervised fine-tuning)에 잘 맞는 전형적인 사례처럼 보였다.
   3. 명확한 목표: 모호한 “더 똑똑해져라”가 아니라 분류 정확도라는 측정 가능한 목표가 있었다.

4. 모델 제공업체로부터 자유로워질 수 있다고 믿었다

   1. 초기 가정: 보유한 데이터만 새 모델에 넣고 파인튜닝하면 어떤 모델을 선택해도 비슷한 결과를 얻을 수 있다고 생각했다.
   2. 모델 비종속성(model agnostic): 특정 제공업체에 종속되지 않고 필요할 때 모델을 바꿀 수 있으리라 기대했다.
   3. 통제권: 데이터가 Lease End에 있으므로 모델 제공업체와 무관하게 결과를 통제할 수 있다고 봤다.

2.2. 데이터·학습 파이프라인

1. 학습 데이터 준비

   1. 예시 수집: 파이프라인을 만들어 실제 대화 예시를 모았다.
   2. LLM 심사자: LLM as judge를 사용해 분류하고 데이터에 라벨을 붙였다.
   3. 사람의 검토: 자동 라벨을 수동으로 검토하고, 학습에 쓰지 않는 홀드아웃 세트(holdout set)를 만들었다.

2. 학습과 평가

   1. 파인튜닝 수행: 라벨과 홀드아웃 세트를 준비한 뒤 모델을 파인튜닝했다.
   2. 지표 확인: 결과를 지표(metrics)로 확인했다.
   3. 데이터 과학자의 만족감: 예시를 모으고, 평가 데이터를 분리하고, 모델을 학습하고, 숫자로 확인하는 과정은 “데이터 과학자의 꿈(data scientist’s dream)”처럼 느껴졌다.

3. 초기 사업 성과

   1. 매출: 애플리케이션은 1년 안에 1,200만 달러($12 million)의 매출을 가져오는 데 기여했다.
   2. ROI: 투자수익률(ROI)은 50배(50x)였다.
   3. 겉으로 보이는 결론: 매출과 ROI 숫자만 보면 파인튜닝 선택은 완벽하게 성공한 것처럼 보였다.
   4. 숨은 비용: 동시에 시스템 아래에서는 나중에 드러날 기술 부채가 조용히 쌓이고 있었다.

3. 운영에서 드러난 모델의 실패

애플리케이션은 사업적으로 잘 작동했지만, 고객 대화의 상태와 시간 정보를 틀리게 읽는 순간 매우 당황스러운 행동을 했다.

3.1. “혼란스러운 확인자” 오류

1. 정상적인 예약 확인 흐름

   1. 예약 생성: 고객이 영업 담당자와 약속을 잡으면 시스템은 약속이 예약됐다는 확인 문자를 보낸다.
   2. 전달할 정보: 확인 문자에는 약속 세부사항과 예정된 통화 시간이 들어간다.
   3. Tracy 사례: 시스템이 “안녕하세요 Tracy, 리스와 담당 어드바이저 통화를 확인합니다. 목요일 오후 2시로 잡혀 있습니다. 그때 전화드리겠습니다”라고 보냈다.

2. 모델이 시간 상태를 뒤집은 과정

   1. 고객 답장: Tracy는 “Sounds good(좋아요)”라고 답했다.
   2. 잘못된 응답: LLM은 “Great. I’m calling you right now(좋습니다. 지금 바로 전화할게요)”라고 응답했다.
   3. 상태 혼동: 고객의 짧은 동의는 다음 날로 예약된 약속을 확인한 것이었는데, 모델은 동의를 즉시 통화 요청으로 해석했다.
   4. 결과: 실제로 고객에게 갑자기 전화가 걸려 불만이 생겼고, 영업 기회를 놓치기도 했다.

3.2. “관심에 들뜬 강아지” 오류

1. 대화 장면

   1. 첫 문자: 시스템이 “안녕하세요 James, Lease End의 Alex입니다. 곧 다가오는 리스 만기에 관해 연락드립니다”라고 보냈다.
   2. 고객의 인사: James는 “Hi, good morning(안녕하세요, 좋은 아침입니다)”이라고 답했다.
   3. 잘못된 행동: 모델은 James가 인사를 건넨 것만으로 즉시 전화를 걸기로 결정했다.

2. 비유와 실제 영향

   1. 비유: 누군가 관심을 주자 너무 흥분해서 달려드는 강아지처럼, 모델은 상대가 응답했다는 사실만으로 바로 통화를 시도했다.
   2. 생산 환경 발생: 이 오류는 테스트가 아니라 실제 프로덕션(production)에서 발생했다.
   3. 감정적 반응: 발표자는 이를 “매우 당황스러운(very embarrassing)” 일이라고 표현했다.
   4. 핵심 교훈: 매출 숫자는 애플리케이션이 작동한다는 것을 보여주지만, 드물거나 미묘한 상황에서 “꽤 훌륭하게” 틀릴 수 있다는 사실까지 알려주지는 않는다.

4. 고치는 비용과 기술 부채의 축적

문제의 본질은 단순히 오류 하나를 고치는 법이 아니었다. 오류를 고칠 때마다 다른 행동을 망가뜨리지 않으면서, 언제 다시 학습할지 결정하고, 전체 과정을 반복할 수 있게 만드는 일이 문제였다.

4.1. 파인튜닝은 짧지만 전체 주기는 길었다

1. 오류 사례 수집과 합성

   1. 현상 수집: 프로덕션에서 보이기 시작한 문제의 실제 예시를 먼저 모아야 했다.
   2. 충분한 데이터 판단: 파인튜닝을 할 만큼 사례가 충분한지 판단해야 했다.
   3. 합성 예시: 사례가 부족하면 LLM에 문제를 통과시켜 가능한 예시를 합성했다.
   4. 수동 검증: 합성 예시는 최고의 학습 데이터인지 확인하기 위해 사람이 일일이 검증했다.

2. 라벨링과 학습

   1. 여섯 개 분류 빈: 충분한 예시를 모은 뒤 여섯 카테고리 중 하나로 라벨링했다.
   2. 재검토: 라벨이 올바른지 다시 수동 검토했다.
   3. 학습 시간: 실제 파인튜닝 자체는 전체 과정 중 가장 짧았으며, 데이터 크기에 따라 보통 약 한 시간이 걸렸다.

3. 첫 시도에 끝나지 않는 반복

   1. 평가: 모델을 학습한 뒤 평가했다.
   2. 회귀(regression): 새 문제를 고치면 이전에 괜찮던 동작에 회귀가 생겼다.
   3. 두더지 잡기(whack-a-mole): 새 문제 하나를 눌러 잡으면 과거의 다른 문제가 다시 튀어나왔다.
   4. 배포: 데이터 수집, 라벨링, 파인튜닝, 반복 평가, 배포까지 전체 주기는 약 일주일이었다.

4.2. 재학습을 미루기 위한 세 가지 질문

1. 문제가 얼마나 자주 발생하는가?

   1. 빈도 측정: 고객이 매일 보는 문제인지, 한 번뿐인 예외인지 물었다.
   2. 우선순위: 일상적으로 반복되는 문제는 재학습 후보가 되지만, 일회성 문제는 일주일짜리 사이클을 정당화하지 못할 수 있다.

2. 고객 경험을 얼마나 해치는가?

   1. 예외 규칙: 빈도가 낮아도 고객 경험을 지나치게 해치면 즉시 고쳐야 했다.
   2. 즉시 수정 사례: 고객이 원하는 통화 시간을 반복해서 말했는데 모델이 계속 무시하는 경우가 해당한다.
   3. 예약 손실 사례: 고객에게 통화가 예약됐다고 말했지만 내부적으로 반환 페이로드(payload)를 올바르게 처리하지 않아 실제 예약이 생성되지 않는 경우도 즉시 수정해야 했다.

3. 재학습 없이 막을 수 있는가?

   1. 밴드에이드(band-aid): 전체 일주일 과정을 거치지 않고 시스템 프롬프트나 코드·워크플로에 임시 방어막을 넣을 수 있는지 물었다.
   2. 버그 순위: 당장 감당할 수 있는 고객 고통의 양을 기준으로 버그를 순위 매겼다.
   3. 불안정한 운영: 프로덕션 시스템의 버그를 “현재 감당 가능한 고객 고통”으로 정렬해야 했다는 사실 자체가 이미 좋지 않은 운영 상태였다.

5. “석회화 세금”: 사용할수록 굳어지는 시스템

발표자는 파인튜닝 모델을 오래 사용할수록 모든 것이 굳어지는 현상을 “석회화 세금(calcification tax)”이라고 부른다. 처음의 높은 ROI가 미래의 선택지를 잠식하는 비용이다.

5.1. 모델 잠금과 제공업체 종속

1. 파인튜닝이 오히려 모델 선택의 자유를 줄였다

   1. 초기 기대와 반대: 파인튜닝하면 모델 선택의 자유가 생길 것이라 생각했지만 실제로는 특정 모델에 묶였다.
   2. 버전 차이: 같은 제공업체 안에서도 모델 버전이 바뀌면 필요한 학습 데이터의 뉘앙스가 달라졌다.
   3. 데이터 구조 변화: 제공업체가 바뀌면 전달해야 하는 데이터의 구조, 좋은 결과를 얻기 위한 데이터 양, 학습 인터페이스와 상호작용 방식이 모두 달라졌다.

2. 교체 비용이 운영 결정을 지배했다

   1. 전환 복잡성: 제공업체 사이의 차이가 너무 커서 단순히 같은 데이터를 꽂아 넣을 수 없었다.
   2. 일관성의 대가: 이미 반복 학습에 많은 일을 하고 있었기 때문에 모델을 업그레이드할 여유가 없었다.
   3. 결정: 결국 일관성을 위해 같은 모델을 계속 사용했다.
   4. 역설: 원래는 모델 비종속성을 얻으려 했지만, 결과적으로 모델 버전과 학습 파이프라인에 의존하게 됐다.

5.2. 2024년의 아키텍처가 미래의 발전을 막았다

1. 워크플로가 표준이던 시점

   1. 구축 시기: 애플리케이션은 2024년 말에 만들어졌다.
   2. 당시의 판단: 좋은 프로덕션 결과를 내려면 워크플로가 사실상 골드 스탠더드(gold standard)처럼 여겨졌다.
   3. 구조적 선택: 따라서 시스템은 정해진 흐름과 파인튜닝 모델을 중심으로 구성됐다.

2. 빠른 AI 생태계와 느린 시스템

   1. 변화 속도: AI 세계는 매우 빠르게 움직였다.
   2. 운영 부담: 팀은 시스템을 계속 작동시키는 데 매달렸고, 구조를 바꿀 여유가 없었다.
   3. 놓친 기회: 새 아키텍처를 활용하고 성능을 개선할 수 없었다.
   4. 석회화의 의미: 사용량과 운영 투자가 커질수록 기존 모델·워크플로·배포 방식에서 빠져나오기 어려워졌다.

6. 에이전트형 재구축과 전환의 계기

전환의 계기는 코딩 작업에서 모델을 바꾸지 않고 컨텍스트와 스킬만 바꿔도 결과를 개선할 수 있다는 관찰이었다.

6.1. Claude Code에서 얻은 “아하”

1. 모델이 아니라 컨텍스트가 작업을 바꿨다

   1. 관찰 시점: 2026년 초, 팀은 코딩 작업에 Claude Code(자막의 “cloud code”는 문맥상 Claude Code)를 사용하기 시작했다.
   2. 모델 선택: 어떤 코딩 작업을 하느냐에 따라 모델을 바꿀 필요가 없었다.
   3. 조정 대상: 대신 스킬, 전달하는 리소스, 컨텍스트를 바꿨다.
   4. 일반 원리: 더 나은 컨텍스트를 넣으면 더 나은 결과가 나왔다.

2. 기존 주장을 뒤집는 개인적 인정

   1. 질문: “이 방식을 우리의 메시징 애플리케이션에도 적용할 수 없을까?”라는 생각이 들었다.
   2. 인정의 어려움: 발표자는 그동안 파인튜닝의 가장 강력한 지지자였기 때문에 이 결론을 인정하기가 쉽지 않았다고 말했다.
   3. 실행 기회: 마침 이미 진행 중이던 프로젝트에 올라탈 수 있었다.

6.2. 워크플로를 스킬·도구·리소스로 마이그레이션

1. 새로운 구성 단위

   1. 워크플로의 분해: 기존의 고정 워크플로 접근법을 여러 스킬, 도구, 리소스로 옮겼다.
   2. 동적 로딩: 스킬은 필요한 도구와 리소스를 불러오고(load), 모델에 관련 컨텍스트를 제공한다.
   3. 에이전트형 프레임워크: 이 구조는 이미 개발 중이던 새로운 에이전트형 프레임워크(agentic framework)의 첫 프로덕션 테스트가 됐다.

2. 의도 분류를 고정된 학습 결과가 아니라 실행 가능한 지식으로 바꿨다

   1. 수정 위치: 특정 실패가 발견되면 모델 가중치를 다시 학습하는 대신 해당 시스템 프롬프트나 영향을 받은 스킬을 조정했다.
   2. 컨텍스트 제어: 모델 자체를 바꾸지 않고 필요한 업무 규칙과 데이터를 컨텍스트로 공급했다.
   3. 배포 단순화: 검증된 마크다운(MD) 파일을 S3 버킷(bucket)에 업로드하는 방식으로 배포했다.

7. 재구축 전후의 운영 차이

재구축의 핵심은 더 화려한 모델이 아니라, 문제 발견부터 수정 배포까지의 피드백 루프를 짧게 만든 것이다.

7.1. 재구축 전: 임계 질량을 기다리는 일주일 주기

1. 문제 축적 단계

   1. 트리아지 선행: 파인튜닝 전에 문제를 모으고, 충분한 “임계 질량(critical mass)”에 도달했는지 확인했다.
   2. 이유: 문제 하나나 두 개 때문에 일주일짜리 재학습을 실행할 수는 없었기 때문이다.
   3. 운영 결과: 작은 오류가 보여도 다른 오류와 함께 묶일 때까지 기다려야 했다.

2. 학습·검증·배포

   1. 전체 흐름: 데이터 수집 → 합성·라벨링 → 파인튜닝 → 평가 → 회귀 수정 → 재평가 → 배포 순서였다.
   2. 시간: 전체 과정은 약 일주일이 걸렸다.
   3. 비용: 모델 학습 시간보다 사람의 검토와 반복 운영 비용이 컸다.

7.2. 재구축 후: 문제 발견부터 1시간 이내 배포

1. 짧은 수정 루프

   1. 문제 발견: 실제 프로덕션에서 문제를 찾는다.
   2. 국소 수정: 시스템 프롬프트 또는 영향을 받은 스킬을 조정한다.
   3. 검증: 프로덕션 기간 동안 계속 모은 선별 데이터 세트(curated set)에서 성능을 확인한다.
   4. 반복: 몇 차례 반복한 뒤 수정본을 배포한다.

2. 배포 방식과 시간

   1. 아티팩트: 수정한 MD 파일을 S3 버킷에 업로드한다.
   2. 단축된 주기: 문제를 발견한 시점부터 수정 배포까지를 1시간 미만으로 줄였다.
   3. 고객 효과: 더 빠르게 반응할 수 있었고, 고객에게 더 나은 성능과 경험을 제공했다.
   4. 운영 효과: “문제가 충분히 쌓일 때까지 기다리는” 트리아지 단계를 제거했다.

8. 성능·비용·통제권의 실제 결과

파인튜닝을 선택했던 초기 기대 중 일부는 재구축에서 더 강하게 실현됐고, 일부는 측정 관점을 바꿔야만 보이는 결과였다.

8.1. 정확도와 지연시간

1. 정확도

   1. 더 나은 모델 사용: 재구축은 메시지당 비용이 조금 더 들었지만 더 나은 모델을 사용할 수 있었다.
   2. 정확도 상승: 정확도는 크게 올라갔고, 파인튜닝 모델보다 훨씬 나았다.
   3. 결정적 지표: 고객 의도 분류가 전체 경험을 좌우하므로 정확도 개선이 단가 상승보다 중요했다.

2. 수정 지연시간

   1. 기존: 수정 프로세스가 며칠 또는 약 일주일이었다.
   2. 이후: 문제 수정 프로세스가 분 단위로 줄었고, 구체적으로 발견부터 배포까지 1시간 미만이 됐다.
   3. 실제 효과: 고객 경험을 해치는 오류를 오래 방치하지 않게 됐다.

8.2. 비용은 메시지당 단가가 아니라 총비용으로 봐야 한다

1. 표면 비용

   1. 메시지당 비용: 더 좋은 프런티어 모델을 사용하면서 메시지당 API 비용은 조금 상승했다.
   2. 초기 오판: 대량 메시지 처리에서 메시지당 가격이 낮아야 총비용도 낮을 것이라고 생각했다.

2. 총비용

   1. 사람의 시간: 파인튜닝 시스템을 계속 살려두고, 오류를 모으고, 재학습하고, 회귀를 고치는 데 드는 시간이 크게 줄었다.
   2. 반전된 결과: 메시지당 단가는 높아졌지만 전체 비용(total cost)은 내려갔다.
   3. 비용의 정의: 모델 API 청구액만이 아니라 데이터 준비, 수동 검토, 재학습, 배포, 유지보수에 쓰는 엔지니어링 시간을 포함해야 한다.

8.3. 모델 자유와 작은 모델의 한계

1. 모델 비종속성의 회복

   1. 선택지: 에이전트형 프레임워크는 모델 비종속적으로 구축됐다.
   2. 공급자 전환: OpenAI, Anthropic 또는 원하는 다른 모델을 선택할 수 있다.
   3. 핵심 자산: 특정 모델 가중치가 아니라 모델에 제공하는 컨텍스트가 결과를 좌우한다.

2. 작은 모델에 대한 재평가

   1. 관찰: 파인튜닝한 작은 모델에서 약간의 개선은 보였다.
   2. 실무적 의미: 그 이득은 너무 작아 실제 운영에서는 거의 차이를 만들지 못했다.
   3. 교과서적 사례의 실패: 좁고 구조화된 작업이라는 파인튜닝의 교과서적 조건을 갖췄는데도 결과는 기술 부채가 됐다.

9. 언제 파인튜닝을 고려할 것인가

9.1. 유효할 수 있는 예외

1. 프런티어 모델을 호출할 수 없는 경우

   1. 강한 제약: 애초에 프런티어 모델을 호출할 수 없다면 파인튜닝이 현실적인 대안이 될 수 있다.
   2. 의사결정 기준: 단순히 작은 모델이 가능하다는 이유가 아니라, API 호출 불가라는 제약이 있어야 한다.

2. 개인정보와 데이터 통제

   1. 프라이버시: 고객 데이터와 개인정보를 외부 모델 제공업체에 보낼 수 없는 환경에서는 자체 파인튜닝 모델이 의미를 가질 수 있다.
   2. 데이터 통제: 데이터가 어디에 저장되고 학습에 어떻게 사용되는지 직접 통제해야 하는 요구도 예외가 될 수 있다.

3. 오프라인 실행

   1. 연결 제약: 네트워크 없이 동작해야 하거나 외부 API를 사용할 수 없는 제품은 로컬 또는 오프라인 모델이 필요할 수 있다.
   2. 유지보수 수용: 이 경우에도 학습 데이터·버전·배포·평가의 장기 비용을 감당할 준비가 있어야 한다.

9.2. 실무 체크리스트와 최종 기준

1. 파인튜닝 전 확인할 것

   1. 컨텍스트 해결 가능성: 시스템 프롬프트, 스킬, 도구, 리소스, 검색으로 문제를 해결할 수 있는가?
   2. 비용의 범위: 메시지당 API 비용뿐 아니라 수동 라벨링, 재학습, 회귀, 배포, 유지보수 비용까지 계산했는가?
   3. 교체 가능성: 모델 버전이나 제공업체를 바꿀 때 데이터 형식과 평가 파이프라인을 다시 만들 수 있는가?
   4. 고객 피해: 오류를 발견했을 때 일주일을 기다리지 않고 한 시간 안에 막을 수 있는가?

2. 최종 원칙

   1. 사용 조건: “문자 그대로 프런티어 모델을 호출할 수 없을 때만 파인튜닝하라.”
   2. 추가 조건: 그 경우에도 파인튜닝의 기술 부채 세금(tech-debt tax)을 포함한 선택이 다른 대안보다 나아야 한다.
   3. 균형 잡힌 결론: 파인튜닝 자체가 금지 대상은 아니지만, 50배 ROI 같은 초기 숫자가 장기 유지보수 비용을 가려서는 안 된다.

주요 발언 모음

“이 애플리케이션은 1년 안에 1,200만 달러의 매출을 가져왔고 50배 ROI를 냈다.”

“숫자는 정말 도움이 됐다. 하지만 그 아래에서는 우리가 보지 못한 부채가 조용히 쌓이고 있었다.”

“파인튜닝 과정은 데이터 과학자의 꿈이었다.”

“새로운 문제를 해결하면 다른 오래된 문제가 계속 튀어나오는 두더지 잡기 과정이 됐다.”

“모델을 많이 사용할수록 모든 것이 더 경직됐다. 나는 이것을 석회화 세금이라고 부른다.”

“더 나은 컨텍스트를 넣으면 더 나은 결과를 얻는다.”

“재구축은 파인튜닝 모델을 이겼다.”

“메시지당 비용은 조금 더 들었지만 총비용은 내려갔다.”

“좁거나 구조화된 작업이라는 교과서적인 사례도 결국 기술 부채가 됐다.”

“문자 그대로 프런티어 모델을 호출할 수 없을 때만 파인튜닝하라. 그때도 결정은 세금을 이겨야 한다.”

핵심 데이터 & 수치

• 2024년 말: Lease End가 문자 기반 LLM 고객 애플리케이션을 구축한 시점이다.
• 하루 수천 건: 고객 메시지를 실시간으로 처리한 규모다.
• 6개 카테고리: 고객 대화 의도를 분류한 범주 수다.
• 약 1시간: 데이터 크기에 따라 한 번의 파인튜닝 자체에 걸린 보통 시간이다.
• 약 1주일: 오류 수집·합성·수동 검증·라벨링·파인튜닝·평가·회귀 수정·배포를 포함한 전체 수정 주기다.
• 1,200만 달러: 애플리케이션이 1년 안에 가져온 매출이다.
• 50배: 초기 사업 성과로 측정된 ROI다.
• 1시간 미만: 재구축 후 문제 발견부터 프롬프트·스킬 수정, 선별 세트 검증, MD 파일 배포까지 걸린 시간이다.
• 며칠에서 분 단위: 기존 파인튜닝 기반 수정 프로세스가 재구축으로 단축된 변화다.
• 메시지당 API 비용 상승: 더 나은 모델을 사용한 결과로 발생한 표면 비용이다.
• 총비용 하락: API 단가 상승에도 엔지니어링·운영·재학습 시간이 줄어든 결과다.

결론 및 시사점

1. 초기 ROI와 장기 비용을 분리해 측정해야 한다: 1,200만 달러 매출과 50배 ROI는 파인튜닝의 단기 사업 효과를 보여주지만, 수동 데이터 작업·회귀·재학습·모델 교체 비용까지 포함하지 않으면 판단이 불완전하다.
2. 정확도는 모델 학습만의 문제가 아니다: 실제 고객 대화의 오류는 가중치보다 상태, 시간, 업무 규칙, 외부 시스템 페이로드를 모델에 어떤 컨텍스트로 제공하는지에서 발생했다.
3. 피드백 루프의 길이가 운영 품질을 결정한다: 오류를 모아 임계 질량이 될 때까지 기다리는 일주일 주기보다, 선별 데이터 세트로 검증하며 한 시간 안에 프롬프트와 스킬을 배포하는 구조가 고객 피해를 빠르게 줄인다.
4. 모델 비종속성은 데이터만으로 얻어지지 않는다: 파인튜닝 데이터가 있어도 제공업체·버전·입력 형식·학습 인터페이스가 달라지면 전환 비용이 커진다. 모델을 바꿀 수 있는 에이전트형 추상화가 필요하다.
5. 작은 모델의 미세한 절약을 총비용과 비교해야 한다: 메시지당 단가가 낮아도 사람이 시스템을 유지하는 시간이 커지면 총비용은 오히려 상승한다.
6. 파인튜닝은 강한 제약이 있을 때 남겨둬야 한다: 프런티어 모델 API를 호출할 수 없거나 프라이버시·데이터 통제·오프라인 실행이 필수인 경우에는 고려할 수 있다.
7. 최종 의사결정 규칙: 컨텍스트·프롬프트·스킬·도구·리소스로 풀 수 있는 문제라면 먼저 그 경로를 실험한다. 파인튜닝은 프런티어 모델을 정말 호출할 수 없을 때만 선택하고, 그때도 장기적인 기술 부채 세금을 포함한 총비용과 유연성이 대안을 이기는지 증명해야 한다.
8. 별도 Q&A: 자막에는 발표 후 별도 질의응답 구간이 없으며, 최종 원칙을 제시한 뒤 감사 인사로 마무리된다.