RAG vs. 파인튜닝 vs. 프롬프트 엔지니어링: 잘못된 도구를 선택하는 것을 멈추세요

실제 결과를 필요로 하는 사람들을 위한 의사 결정 프레임워크. 언제 RAG를 사용하고, 언제 파인튜닝을 하고, 언제 단순히 프롬프트를 사용할 것인지 — 그리고 대부분의 팀이 왜 잘못된 도구를 선택하는지에 대한 내용입니다.

#rag#finetuning#prompting

Marcus는 팀의 고객 지원 파이프라인을 위해 모델을 6개월 동안 파인튜닝했습니다. 마침내 출시했을 때, 답변은 세련되고 문법적으로 완벽했지만, 고객들이 문의하는 실제 제품 변경 사항보다 지식 차단일(knowledge cutoff date)이 3개월 앞서 있었습니다. 그는 문제에 적합하지 않은 도구를 사용했고, 아무도 분류 질문을 먼저 요청하지 않았습니다.

저는 세 팀이 RAG 파이프라인으로 2주 만에 출시할 수 있었던 작업을 위해 6개월 동안 파인튜닝하는 것을 지켜봤습니다. 저는 팀들이 두 문장짜리 프롬프트로 해결했을 작업을 위해 정교한 RAG 파이프라인을 구축하는 것을 지켜봤습니다. 저는 프롬프트 엔지니어링 팀들이 한계에 부딪혀 실제로는 검색 계층(retrieval layer)이 필요했음에도 불구하고

비용

$0 설정 + 추론 토큰만 발생
지연 시간

기준 모델 지연 시간, 오버헤드 없음
최적 사용처

모든 경우에 적합합니다. 진정으로 실패할 때까지는 항상 여기서 시작하세요.
치명적인 결함: 너무 일찍 무시됨. '프롬프트 엔지니어링' ≠ 한 줄 시스템 프롬프트.

제가 아는 팀은 내부 제품 문서를 기반으로 질문에 답하기 위해 모델을 파인튜닝하는 데 3개월과 $40,000를 사용했습니다. 그들은 계약자를 고용하고, 학습 파이프라인을 구축하고, 평가(evals)를 실행하고, 배포했습니다. 결과는 문서가 컨텍스트 창에 직접 붙여넣어진 잘 프롬프트된 기본 모델과 거의 같은 수준의 성능을 보였습니다. 그들이 비교를 실행했을 때쯤에는 문서가 훈련 과정에서 두 번 업데이트되었고, 파인튜닝된 모델은 이미 구식이 되어 배포되기 전에 뒤처졌습니다.

$40k 파인튜닝 실패 - 비용 분석
계약자 범위 설정 + 데이터 감사
$4,200
2주 동안 '올바른' 접근 방식을 파인튜닝으로 정의하고 대안을 테스트하지 않음
훈련 데이터 준비
$8,500
Q&A 쌍 추출, 정리, 형식 지정 ~2,000개 예시
GPU 훈련 실행 (x4 반복)
$6,800
클라우드 GPU 시간 + 실패한 실행; 각 평가는 전체 재훈련을 필요로 함
평가 및 반복
$9,000
사전에 정의된 고정 평가 세트 없음 - 매 라운드마다 '좋다'는 의미를 재정의함
배포 + 통합
$7,500
호스팅, 엔드포인트 인프라, 롤아웃 - 이미 구식인 모델에 적용됨
기회 비용 (팀 시간)
$14,000
3개월 동안 로드맵 기능에서 전환된 엔지니어링 시간
총계: ~$50,000 | 비교 가능한 기준선 (프롬프트가 적용된 최신 모델 + 컨텍스트에 문서): ~$200/월

엔지니어들은 무능하지 않았습니다. 그들은 문제점을 이해하기 전에 기술적 결정을 내렸습니다. 이것이 실패의 원인입니다. 파인튜닝 자체가 아니라, 더 저렴한 옵션들을 배제하기 전에 그것을 먼저 선택했다는 것입니다. 저는 이 패턴을 너무 자주 봐서 이제 기술 선택이 잘못된 순서로 이루어질 때 기본 결과물로 취급합니다.

올바른 순서는 다음과 같습니다: 프롬프트 엔지니어링(prompt engineering) $\rightarrow$ RAG $\rightarrow$ 파인튜닝(fine-tuning). 이 기술들이 깔끔한 계층 구조를 이루기 때문이 아니라, 각 단계가 이전 단계에서 실제로 실패했을 때만 의미가 있기 때문입니다. 대부분의 문제는 첫 번째 단계에서 해결됩니다.

실제로 내리는 결정

어떤 기술을 사용하기 전에 세 가지 질문이 중요합니다: 시스템에 필요한 지식이 얼마나 자주 변경됩니까? 대규모로 출력 형식이 얼마나 일관적이어야 합니까? 그리고 요구사항이 바뀔 때 업데이트하는 실제 비용은 얼마입니까?

Three-way decision fork from center. CENTER node: PROBLEM TYPE. LEFT path (RAG): vector shelves, cyan, ARROW -> data changes frequently, retrieval > generation. CENTER path (FINE-TUNE): tuning dials, amber, ARROW -> task is stable, behavior must be exact, domain is narrow. RIGHT path (PROMPT): prompt cards, teal, ARROW -> task is fluid, iteration speed matters, domain is broad. Clean geometric fork, isometric, editorial tech illustration.

결정의 분기점. 문제 유형이 경로를 결정합니다. 대부분의 팀은 질문을 건너뛰고 가장 정교해 보이는 경로를 선택합니다.

지식이 합리적으로 재학습할 수 있는 속도보다 빠르게 변경된다면 $\rightarrow$ 제품 문서, 법률 업데이트, 내부 지식 기반(KB) 등 $\rightarrow$ 이는 파인튜닝의 영역이 아니라 RAG의 영역입니다. 하루에 5만 건의 추론에서 컨텍스트 오버헤드 없이 동일한 출력 구조가 재현되어야 한다면 $\rightarrow$ 파인튜닝이 그 비용을 정당화합니다. 이 두 가지가 명확하게 사실이 아니라면 $\rightarrow$ 아직 프롬프트 엔지니어링을 충분히 시도하지 않은 것입니다.

결정 흐름도 - 어디서 시작할 것인가(Decision Flowchart - Where to Start)

4만 달러의 실수는 팀이 무모했기 때문에 발생한 것이 아니었습니다. '파인튜닝(fine-tuning)'이 진지하고 프로덕션 등급의 선택처럼 들리고, '프롬프트 엔지니어링(prompt engineering)'이 임시방편처럼 들리기 때문에 발생했습니다. 이 틀 자체가 완전히 뒤집혀 있습니다. 프롬프트 엔지니어링이 기반입니다. 나머지 두 가지는 기반이 전체 부하를 감당할 수 없을 때 덧붙이는 확장 기능일 뿐입니다.

RAG의 조용한 실패 모드

RAG가 현재 기본 선택지입니다. 또한 가장 조용하게 실패하는 경우이기도 합니다. 파이프라인은 실행되고, 지연 시간(latency)도 괜찮아 보이며, 메트릭은 '검색(retrieval) 작동 중'을 보여주지만, 검색기가 잘못된 청크를 반환했기 때문에 답변 자체가 틀립니다.

이는 벡터 유사성(vector similarity)이 의미적 관련성(semantic relevance)과 같지 않기 때문에 발생합니다. '환불 정책(refund policy)'에 대한 청크가 쿼리에서 '환불(refund)'이라는 단어와 일치하지만, 사용자는 '해외 주문의 환불 기간'에 대해 질문했습니다. 해당 청크가 검색되고 모델이 답변을 생성하지만, 답변은 틀리고 아무도 알아차리지 못합니다. 왜냐하면 파이프라인 자체가 오류를 내지 않았기 때문입니다.

RAG failure mode: LEFT clean query vector, CENTER vector index with most chunks crossed out red, one correct chunk glowing green, RIGHT model receiving wrong chunks output marked WRONG in red. Clean technical illustration, blueprint grid, no people.

RAG의 조용한 실패: 검색이 잘못된 청크를 반환하고, 모델은 자신감 있게 환각(hallucinates)을 생성합니다. 파이프라인은 실행되고, 메트릭은 괜찮아 보이지만, 출력은 틀립니다.

왜 검색 실패가 눈에 띄지 않는가
대부분의 RAG 평가는 답변 품질—유창성(fluency), 관련성(relevance), 일관성(coherence)—을 측정합니다. 반면 검색 품질은 거의 별도로 평가되지 않습니다. 따라서 어떤 컨텍스트를 받든 모델이 좋은 텍스트를 생성하는지 확인할 수는 있지만, 그 컨텍스트 자체가 올바른지는 알 수 없는 파이프라인을 갖게 됩니다. 잘못된 청크에 대해 추론하는 데 능숙한 모델은 자신감 있는 환각 기계입니다. 검색(retrieval)부터 수정하세요. 잘못된 검색 이후의 모든 것은 노이즈일 뿐입니다.

저는 개인 메모리 시스템을 구축할 때 정확히 이런 종류의 문제를 디버깅했습니다. 바로 AI Brain 게시물에서 언급했던 Qdrant 기반의 두뇌입니다. 증상은 오탐지(false positives)였습니다. 한 주제에 대한 질의가 의미론적으로 유사하지만 문맥상으로는 잘못된 문서에서 청크를 끌어오는 것이었습니다. 검색 점수는 괜찮아 보였고, 답변도 그럴듯해 보였습니다. 제가 각 질의마다 실제로 어떤 청크가 검색되었는지 로깅하기 시작했을 때야 비로소 파이프라인이 지속적으로 잘못된 문맥에 대해 확신을 가지고 있다는 것을 알게 되었습니다.

실제 환경에서 검색 품질에 중요한 변수들:

• 청크 크기(Chunk size): 청크가 작으면 정확한 사실들을 드러내지만 문맥을 잃습니다. 청크가 크면 문맥은 보존하지만 임베딩 신호를 희석시킵니다. 만능의 정답은 없으며, 질의가 사실 확인 검색인지 아니면 문맥적 질문인지에 따라 달라집니다. 실수는 하나를 선택하고 다른 하나를 절대 테스트하지 않는 것입니다.
• 하이브리드 검색(Hybrid search): 키워드와 의미론적 검색을 결합하는 것이 정확한 용어가 있는 모든 도메인에서 순수 의미론적 검색보다 일관되게 우수한 성능을 보입니다. 만약 문서에 모델 번호, 정책 코드, API 이름 또는 특정 식별자가 포함되어 있다면, 순수 의미론적 검색은 키워드 검색이 사소하게 찾아내는 정확한 일치 항목들을 놓칠 것입니다. 둘 다 실행하여 결과를 병합하세요.
• 임베딩 모델 정렬(Embedding model alignment): 질의 임베딩과 문서 임베딩은 유사한 훈련 분포에서 나와야 합니다. 불일치는 진단하기가 정말 어려운 검색 실패를 초래합니다. 벡터는 일치해야 할 것처럼 보이고, 코사인 유사도는 그럴듯하지만, 검색된 내용은 명백한 오류를 발생시키지 않는 방식으로 지속적으로 약간 잘못됩니다. 이것이 몇 주간의 디버깅 시간을 잡아먹는 실패 모드입니다.

파인튜닝(Fine-Tuning)이 실제로 정답일 때

파인튜닝은 일관된 스타일이나 형식이 필요하거나, 문맥을 쑤셔 넣는 방식(context-stuffing)으로는 비실용적이거나, 또는 검색 인프라 없이 오프라인 추론(offline inference)이 필요한 규모에서 복잡성을 얻습니다. 그것들이 실제 사용 사례입니다. 또한 파인튜닝의 과대광고가 시사하는 것보다 더 좁은 범위에 속합니다.

내가 사용하는 테스트는 이렇습니다. 5~10개의 few-shot 예시가 포함된 잘 작성된 시스템 프롬프트(system prompt)로 필요한 행동의 80%를 얻을 수 있다면, 파인튜닝(fine-tuning)은 90%까지 끌어올리지만, 요구 사항이 변경될 때마다 전체 재학습 주기(full retraining cycle)라는 비용을 치러야 합니다. 이 트레이드오프는 때때로 가치가 있습니다. 하지만 더 자주 그렇지 않습니다. 왜냐하면 팀들이 프로젝트를 계획할 때 예상하는 것보다 요구 사항이 훨씬 더 자주 바뀌기 때문입니다.

파인튜닝의 실제 비용은 학습 실행(training run) 자체가 아닙니다. 그것은 업데이트 주기(update cycle)입니다: 데이터 준비, 학습, 평가, 배포—도메인이 바뀔 때마다 이 과정이 반복됩니다. 문서가 매달 업데이트되는 제품 문서화 사용 사례라면, 이는 원하는 파이프라인이 아닙니다. 진정으로 안정적인 출력 요구 사항과 높은 볼륨을 가진 작업이라면 의미가 있습니다.

"올바른 순서는 항상 다음과 같습니다: 프롬프트 엔지니어링(prompt engineering) → RAG → 파인튜닝(fine-tuning). 대부분의 문제는 첫 번째 단계나 두 번째 단계에서 멈춥니다. 파인튜닝은 마지막 10%를 위한 것이며, 업데이트하는 데 가장 많은 비용이 듭니다."

실제로 작동하는 시스템 프롬프트는 어떤 모습인가?

실패하는 "프롬프트 엔지니어링"은 진정한 프롬프트 엔지니어링이 아닙니다. 그것은 한 문장의 시스템 프롬프트를 추가하고 끝났다고 생각하는 것입니다. "당신은 유용한 비서입니다. 우리 제품에 대한 질문에 답하세요." 이것은 시스템 프롬프트가 아닙니다. 단순한 자리 표시자(placeholder)일 뿐입니다.

제가 구축한 모든 파이프라인에서 사용하는 구조는 다음과 같습니다:

1. 범위 제약 조건이 있는 역할 부여. 단순히 "당신은 X입니다"라고 하는 것이 아니라, "당신은 Y만 처리하고, Z는 거절하며, 항상 W를 수행하는 X입니다." 여기서 핵심은 '제약 조건(constraint)'입니다. 이것이 없으면 모델은 도움이 되게 인접한 영역으로 표류하여 기술적으로 그럴듯하지만 운영상으로는 잘못된 답변을 생성할 것입니다.

2. 도메인 사실이 아닌, 도메인 규칙. 시스템 프롬프트를 모델이 이미 알고 있는 사실들로 채우지 마십시오. 대신, 귀하의 컨텍스트에 특화된 규칙—귀하의 도메인에서 어떤 용어가 의미하는지, 엣지 케이스(edge case)가 무엇인지, 모호성에 직면했을 때 모델이 무엇을 해야 하는지—를 인코딩하는 데 사용하십시오. 사실은 검색(retrieval)에 속합니다. 규칙은 시스템 프롬프트에 속합니다.