지난 1년 동안 제가 만난 거의 모든 창고 운영자가 같은 질문을 던졌습니다. SOP, 장비 매뉴얼, 과거 작업 지시를 사내 지식 베이스로 만들어 Q&A 봇을 돌리고 싶은데—RAG를 쓸까요, 아니면 대형 언어 모델을 파인튜닝할까요? 기술 선택처럼 보이지만, 그 아래에는 세 개의 장부가 있습니다. 지식이 얼마나 빨리 바뀌는지, 잘못된 답의 비용이 얼마인지, 그리고 팀이 실제로 유지할 수 있는 방식은 무엇인지.
먼저 전체 그림을 보면: 제가 검토한 공개 업계 보고서와 벤더 사례 연구에 따르면, 2024년부터 2026년 사이에 실제로 운영에 들어간 기업용 지식 베이스 Q&A 프로젝트 중 RAG(검색 증강 생성)가 사실상 표준 아키텍처가 되었습니다. 이 기법은 2020년 Meta가 발표했고(Lewis 외), 핵심 아이디어는 간단합니다. 지식을 모델 파라미터에 쑤셔 넣는 대신, 모델이 먼저 관련 문서를 검색한 뒤 검색한 내용을 근거로 답변을 생성하는 것입니다. 파인튜닝은 다른 길을 갑니다. 자체 Q&A 데이터로 모델을 추가 학습시켜 지식을 파라미터에 "눌러 담는" 방식입니다. 두 길 다 동작하지만, 비용 구조, 리스크 프로파일, 적용 범위는 완전히 다릅니다—그리고 잘못 고른 대가는 출시 약 6개월 후에 나타납니다.
창고에서의 RAG의 실제 모습: 추적 가능성이 생명
2025년 초, 캘리포니아 인랜드 엠파이어의 3PL 창고가 자신들의 프로젝트를 보여줬습니다. 시설은 약 120,000제곱피트 규모로, 40개가 넘는 전자상거래 브랜드를 맡고 있으며, WMS에 수만 건의 과거 작업 지시와 예외 기록이 쌓여 있고, 수백 페이지 분량의 SOP도 있었습니다. 그들의 방식은 교과서 그대로의 RAG였습니다. 문서를 청크로 나누고 벡터화한 뒤, 질의 시점에 가장 관련 있는 5–8개 패시지를 검색해 LLM이 그 패시지들로부터 답변을 구성하게 하는 것—모든 답변에 출처가 달려 있고, SOP 섹션이나 특정 작업 지시 번호까지 추적할 수 있습니다.
이 "출처 인용" 설계가 핵심입니다. 창고는 컴플라이언스와 감사가 엄격한 환경입니다. 품질 검사관이 "이 입고 로트의 샘플링 비율이 어떻게 됩니까"라고 물을 때, 원하는 건 예쁜 답이 아닙니다—기록에 남길 수 있고, 문제가 생기면 거슬러 올라가 추적할 수 있는 답입니다. RAG 답변은 구조상 출처를 동반합니다. 틀린 답이 나오면 어느 문서가 낡았는지 짚어내고, 모델이 아니라 문서를 고치면 됩니다. 출시 6개월 후, 이 3PL의 신규 채용자 온보딩 기간은 약 3주에서 약 10일로 단축되었습니다. 참고로, 이는 그들의 사내 업무 지표이며, 교육 과정 자체도 병행해서 최적화되었으므로 모든 공이 RAG에 있는 건 아닙니다—하지만 방향은 분명합니다. 지식이 "찾을 수 있고" "검증 가능한" 것이 되었습니다.
RAG에는 창고 환경에서 엄청나게 중요한 또 하나의 장점이 있습니다. 지식 업데이트가 "문서 교체"이지 "재학습"이 아니라는 점입니다. SOP가 개정되면 청크를 다시 나누고 다시 인덱싱하면 몇 분 안에 반영됩니다. 지식이 끊임없이 바뀌는 창고에게 이것은 거의 결정적입니다.
파인튜닝의 실패 사례: 스펙은 외웠고 출처는 잃었다
파인튜닝에도 지지자들이 있습니다—그리고 실제 실패 사례도. 2025년 중반, 중국 동부의 한 물류 센터가 장비 유지보수 매뉴얼을 모델에 "가르치겠다"며 수천 쌍의 Q&A 데이터를 모아 파인튜닝했습니다. 테스트 중 누군가 특정 스태커 크레인의 정격 하중을 물었고, 모델은 완전한 확신을 가지고 답했습니다—그리고 숫자가 틀렸습니다. 실제 정격은 1.5톤인데 2톤이라고 답한 것입니다. 사후 분석 결과, 구 버전 매뉴얼이 학습 데이터에 섞여 들어갔고, 모델이 그 오류를 틀렸다는 인식 없이 "암기"해 버린 것이었습니다.
이것이 지식 베이스를 위한 파인튜닝의 구조적 결함입니다. 지식이 한 번 파라미터로 압축되면 추적도 부분 수정도 불가능합니다. 오류를 하나 찾았을 때 RAG처럼 문서를 고치는 것으로 끝나지 않습니다—데이터 재준비, 재학습, 재검증을 전부 다시 해야 합니다. 더 나쁜 점은, 파인튜닝된 모델은 틀린 답을 맞는 답과 정확히 같은 확신으로 내놓는다는 것입니다. 창고에서는 잘못된 답이 사람을 다치게 하고, 화물을 망치고, 컴플라이언스를 깨뜨릴 수 있습니다. 이 설명할 수 없는 확신이 가장 위험한 속성입니다.
공평하게 말하자면, 파인튜닝에도 정당한 자리는 있습니다—다만 사실 암기가 아닙니다. 잘하는 것은 모델의 행동을 바꾸는 것입니다. 출력 포맷 고정, 말투 통일, 특정 추론 패턴 학습 등입니다. 필요한 것이 "모델이 우리 회사 서비스 매뉴얼처럼 말하게 하기"라면 파인튜닝은 좋은 선택입니다. 필요한 것이 "모델이 3,000페이지 분량의 매뉴얼을 기억하게 하기"라면 잘못된 도구를 쓰고 있는 것입니다.
RAG vs 파인튜닝: 의사결정 매트릭스
정리하면, 제가 사용하는 의사결정 매트릭스는 이렇습니다. 자신의 상황을 이 네 가지 차원에 대입해 보면 답이 보통 저절로 드러납니다.
| 차원 | RAG 쪽으로 | 파인튜닝 쪽으로 |
|---|---|---|
| 지식 업데이트 빈도 | 높음 — 주 단위, 심지어 일 단위 변경(SOP, 프로모 규칙) | 낮음 — 지식이 수년간 안정(장비 원리, 규제) |
| 정확도와 추적 가능성 요구 | 높음 — 오답 비용이 크고 출처 인용 필수(품질, 안전) | 중~저 — 사실 정밀도보다 스타일이 중요 |
| 데이터 양 | 문서는 많지만 Q&A 쌍은 적음(RAG는 문서를 직접 먹는다) | 수만 쌍의 고품질 Q&A 쌍을 학습용으로 확보 가능 |
| 비용과 팀 | 가벼운 시작, 검색당 과금, 유지보수는 문서 교체뿐 | 초기+반복 재학습의 GPU 비용과 버전 관리 오버헤드 |
비용 차원은 별도로 계산할 가치가 있습니다. 퍼블릭 클라우드 요금을 기준으로, 7B급 오픈 모델의 전체 파인튜닝 1회는 보통 수백~수천 달러의 GPU 렌털 비용이 듭니다(최신 요금은 각 클라우드 벤더 공식 사이트에서 확인하세요)—하지만 그것은 1회 학습 실행분일 뿐입니다. 진짜 비용은 그 뒤에 옵니다. 지식 갱신 주기마다 이론상 새 모델 버전의 재학습, 재테스트, 재배포가 필요하고, 이는 매년 반복되는 경비가 됩니다. RAG의 비용 곡선은 반대입니다. 검색 파이프라인 구축에는 초기 엔지니어링 노력이 필요하지만, 일상 유지보수는 "문서 교체"뿐이라 한계 비용이 매우 낮습니다. 한쪽은 선불, 다른 쪽은 후불—비교해야 할 것은 첫 달 청구서가 아니라 3년 총합입니다.
직관에 반하는 견해: 빨리 바뀌는 창고에서 파인튜닝은 감가상각되는 자산
직관에 반하는 판단을 분명히 말해둘 가치가 있습니다. 지식이 자주 업데이트되는 창고에게 파인튜닝은 "일회성 투자"가 아닙니다—감가상각되는 자산입니다. SOP 개정과 장비 변경이 있을 때마다 이전 파인튜닝 모델의 "기억" 일부가 구식이 되고, 어느 부분인지 알 수 없습니다. 그래서 재학습–재테스트–재배포 루프에 갇히게 되고, 움직이는 과녁을 모델이 영원히 쫓는 동안 지출은 늘어만 갑니다. RAG는 바로 이 시나리오에서 반대로 움직입니다. 지식이 새로울수록, 단편적일수록, 흩어져 있을수록 검색 아키텍처의 우위는 커집니다.
그러면 트렌드에 대한 제 판단은 이렇습니다. 앞으로 2~3년 안에 창고 지식 베이스의 기본 형태는 하이브리드가 될 것입니다—what(사실, 추적 가능성, 실시간 업데이트)에는 RAG, how(포맷, 말투, 업계 표현)에는 가벼운 파인튜닝. 두 방식은 양자택일이 아니었습니다. 분업입니다.
다만, 한 가지 질문은 더 오래 관찰할 가치가 있습니다. 어떤 길을 선택하든, 지식 베이스 자체의 품질이 한계입니다. 모호한 SOP, 빠진 필드가 있는 작업 지시 기록, 개정이 얽힌 장비 매뉴얼—어떤 RAG 파이프라인도 파인튜닝 실행도 "지식 거버넌스" 문제는 고칠 수 없습니다. 아키텍처 논쟁 이면의 진짜 분기점은 이것일지도 모릅니다. 당신의 창고는 AI가 배울 만한 가치를 가진 지식을 실제로 갖고 있는가? 지식 베이스를 만드는 모든 기업이 스스로 답해야 할 질문입니다.
Dr. Chen, 공급망 연구원 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
