RAG vs 파인튜닝 vs 롱 컨텍스트: LLM에 지식을 넣는 방법 선택

LLM 도입 검토가 조금만 진행되면 반드시 나오는 질문이 있습니다. “우리 회사 데이터를 모델에 어떻게 넣나요?“입니다. 선택지는 셋입니다. 검색해서 끼워 넣는 RAG, 모델 가중치를 바꾸는 파인튜닝, 문서를 통째로 프롬프트에 넣는 롱 컨텍스트입니다. 결론을 먼저 적으면, 바뀌는 사실과 문서 지식은 RAG가 기본값이고, 출력 형식·말투·도메인 행동을 고정하고 싶을 때가 파인튜닝이며, 지식 전체가 작고 잘 안 바뀌면 롱 컨텍스트에 프롬프트 캐싱을 얹는 것이 가장 단순한 시작점입니다. 셋은 배타 관계가 아니라 조합 대상입니다. 비용 감각은 2026년 중반 기준입니다.

한눈에 보는 비교 #

RAG: 지식을 검색해서 그때그때 주입합니다 #

RAG는 질문이 들어올 때마다 관련 문서 조각을 검색해 프롬프트에 붙여 주는 구조입니다. 장점은 운영 특성에서 나옵니다. 문서를 추가하면 그 순간부터 답에 반영되고, 어느 문서를 근거로 답했는지 인용할 수 있으며, 권한별로 검색 범위를 나누는 접근 제어도 검색 계층에서 풀립니다. 지식이 수백만 토큰 이상으로 커져도 프롬프트는 검색된 몇 천 토큰으로 일정하게 유지되므로, 추론 비용이 지식 크기와 분리됩니다.

약점도 구조에서 나옵니다. 답변 품질의 상한이 검색 품질입니다. 필요한 문서를 못 찾으면 모델이 아무리 좋아도 틀리고, 이 실패 양상의 진단은 RAG 심화 #1에서 다뤘습니다. 임베딩, 청킹, 벡터 스토어라는 이동 부품이 늘어나는 것도 비용입니다. 파이프라인을 처음 만드는 과정은 문서 Q&A 봇 실전에서 다뤘습니다.

파인튜닝: 지식이 아니라 행동을 가르치는 도구입니다 #

가장 흔한 오해가 “우리 데이터로 파인튜닝하면 그 내용을 알게 된다"입니다. 파인튜닝으로 새 사실을 주입하는 것은 비효율적이고, 기존 능력이 일부 밀려나거나 학습한 사실을 그럴듯하게 뒤섞는 부작용이 따릅니다. 파인튜닝이 잘하는 것은 행동의 고정입니다. 항상 지정한 JSON 스키마로만 답하게 만들기, 브랜드 말투 유지, 도메인 특유의 분류·추출 정확도 끌어올리기, 프롬프트에 매번 넣던 긴 지시문을 모델에 접어 넣어 지연과 토큰 비용을 줄이기가 전형입니다.

비용은 생각보다 낮아졌습니다. 전체 가중치를 다시 학습하는 대신 LoRA·QLoRA로 작은 어댑터만 학습하는 것이 표준이 되어, 오픈 웨이트 모델 기준 학습 1회에 수백 달러대, 관리형 API 파인튜닝은 학습 토큰당 과금(100만 토큰당 수십 달러대)입니다. 부담은 비용보다 운영입니다. 학습 데이터셋 구축과 평가 체계가 필요하고, 지식 갱신마다 재학습해야 하며, 자체 호스팅이라면 서빙 쪽 결정(양자화, GPU 조달)이 따라옵니다.

롱 컨텍스트: 다 넣고 캐싱하는 가장 단순한 방법 #

컨텍스트 윈도우가 수십만〜100만 토큰급으로 커지면서 세 번째 선택지가 실용이 됐습니다. 사내 규정집, 제품 매뉴얼, API 문서 정도의 지식이라면 검색 없이 문서 전체를 프롬프트에 넣는 구성입니다. 여기에 프롬프트 캐싱을 얹으면 반복 호출에서 문서 부분의 입력 토큰 요금이 큰 폭으로 할인되고 첫 토큰 지연도 줄어, “RAG를 만들기 전에 일단 다 넣어 본다"가 합리적인 첫 수가 됩니다.

경계 조건이 분명합니다. 지식 전체가 컨텍스트에 여유 있게 들어가야 하고(대략 수십만 토큰 이하), 자주 안 바뀌어야 하며(캐시 무효화 방지), 호출 패턴이 같은 문서를 반복 참조해야 캐싱이 삽니다. 문서가 계속 자라면 토큰 비용이 정비례로 따라 오르고, 컨텍스트 중간에 놓인 정보의 회수율이 떨어지는 문제도 문서가 클수록 커집니다. 그때가 RAG로 넘어갈 시점입니다.

조합: 셋은 경쟁이 아니라 계층입니다 #

실전 구성은 대부분 조합입니다. 사실은 RAG로, 행동은 파인튜닝으로, 소규모 고정 지식은 컨텍스트로가 기본 배치입니다. 문서 Q&A에 파인튜닝이 아니라 RAG를 쓰고, 그 RAG의 답변 형식이 자꾸 흐트러지면 형식 고정용 파인튜닝을 얹고, 매 호출에 공통으로 들어가는 규칙·용어집은 캐싱된 시스템 프롬프트에 두는 식입니다. API로 시작할지 자체 호스팅으로 갈지는 API vs 자체 호스팅의 계산과 동일하고, 파인튜닝한 모델은 자체 호스팅 쪽 무게를 키우는 변수가 됩니다.

선택 순서 #

1. 요구가 지식인지 행동인지부터 가릅니다: “무엇을 알아야 한다"면 RAG나 롱 컨텍스트, “어떻게 답해야 한다"면 파인튜닝입니다. 이 구분 하나로 절반이 정리됩니다.
2. 지식 크기와 갱신 빈도를 잽니다: 수십만 토큰 이하 + 갱신 드묾이면 롱 컨텍스트 + 캐싱으로 시작합니다. 그보다 크거나 매일 갱신되면 RAG입니다.
3. 출처 제시와 접근 제어 요구를 확인합니다: 근거 인용, 사용자별 열람 권한이 요구되면 검색 계층이 필요하므로 RAG로 확정입니다.
4. 파인튜닝은 마지막에 얹습니다: 프롬프트 지시로 형식·말투가 안 잡히는 것을 확인한 뒤에 시작해야 학습 데이터셋 투자가 헛돌지 않습니다.
5. 비용은 호출 패턴으로 검산합니다: 호출량 × 평균 프롬프트 토큰으로 RAG와 롱 컨텍스트의 월 비용을 비교하고, 파인튜닝의 프롬프트 단축 효과가 학습 비용을 상쇄하는 시점을 계산합니다.

정리 #

• 바뀌는 사실·문서 지식은 RAG, 형식·말투·행동 고정은 파인튜닝, 소규모 고정 지식은 롱 컨텍스트 + 캐싱입니다.
• 파인튜닝을 지식 주입 도구로 쓰는 것이 가장 흔한 실수입니다. 파인튜닝이 가르치는 것은 사실이 아니라 행동입니다.
• 롱 컨텍스트는 지식이 수십만 토큰 이하이고 갱신이 드물 때의 가장 단순한 시작점입니다. 문서가 자라면 RAG로 넘어갑니다.
• RAG의 상한은 모델이 아니라 검색 품질입니다. 답이 틀리면 검색부터 진단합니다.
• 실전은 조합입니다. 사실은 RAG, 행동은 파인튜닝, 공통 규칙은 캐싱된 컨텍스트라는 배치에서 출발합니다.