Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 답부터 말하면
세 가지는 같은 문제를 풀고 있지 않다
파인튜닝으로 지식을 넣을 수 있나 — 두 논문이 정반대로 보이는 이유
- 농업 논문의 숫자를 그대로 믿기 전에
- 그리고 새 지식을 억지로 넣으면 생기는 일
롱컨텍스트는 어디서 무너지나 — 위치, 길이, 어휘
RAG가 롱컨텍스트보다 싼가 — Self-Route가 실제로 잰 것
그런데 벤치마크 자체가 오염돼 있다 — 이 글에서 가장 중요한 부분
2026년에 달라진 것 — 캐싱은 롱컨텍스트를 공짜로 만들지 않는다
그래서 뭘 봐야 하나 — 당신이 실제로 잴 수 있는 것
언제 쓰지 말아야 하나
아무도 답하지 않은 것
마치며
참고 자료

들어가며 — 답부터 말하면

"우리 문서로 챗봇을 만들려는데 RAG를 써야 하나요, 파인튜닝을 해야 하나요, 아니면 그냥 100만 토큰 컨텍스트에 다 넣으면 되나요?" 아마 LLM 아키텍처에서 가장 많이 나오는 질문일 겁니다. 그리고 검색해서 나오는 답의 대부분은 출처가 하나도 없는 의사결정 트리입니다. "최신 정보가 필요하면 RAG, 스타일이 필요하면 파인튜닝" — 틀린 말은 아닌데, 이걸로는 아무것도 결정할 수 없습니다. 왜 그런지, 얼마나 그런지, 어디서 무너지는지가 없으니까요.

그래서 이 글은 측정된 것만 가지고 답합니다. 결론을 먼저 적으면 이렇습니다.

세 가지는 애초에 경쟁 관계가 아닙니다. 파인튜닝이 새로운 사실을 모델에 주입하는 데 실패한다는 것은 여러 논문에서 반복 측정된 결과입니다. 그러니 "지식"이 문제라면 선택지는 사실상 둘입니다.
남은 선택(RAG vs 롱컨텍스트)은 당신이 직접 잴 수 있는 하나의 속성으로 거의 결정됩니다 — 당신 코퍼스에서 recall@k 곡선이 어디서 포화하느냐. 이건 벤치마크가 아니라 오후 반나절이면 재는 숫자입니다.
그리고 정직해야 할 부분 — 이 세 가지를 하나의 공통 벤치마크에서 비교한 연구는, 제가 확인한 범위에서는 없습니다. 논문마다 다른 모델·다른 데이터셋·다른 지표를 씁니다. 그래서 A 논문의 숫자와 B 논문의 숫자를 나란히 놓고 비교하면 안 됩니다.

아래는 그 근거입니다. 각 숫자가 무엇을 재고 무엇을 안 쟀는지까지 같이 적겠습니다.

세 가지는 같은 문제를 풀고 있지 않다

먼저 축을 정리해야 합니다. 세 방식은 흔히 나란히 놓이지만, 실제로는 서로 다른 것을 바꿉니다.

파인튜닝은 가중치를 바꿉니다. 모델이 어떻게 답하는지를 바꾸는 도구입니다.
RAG는 프롬프트에 무엇이 들어갈지를 바꿉니다. 검색으로 고른 조각만 넣습니다.
롱컨텍스트도 프롬프트에 무엇이 들어갈지를 바꿉니다. 다만 고르지 않고 다 넣습니다.

즉 RAG와 롱컨텍스트는 같은 축(프롬프트에 뭘 넣을까)의 양 극단이고, 파인튜닝은 다른 축입니다. Gekhman 등(arXiv:2405.05904)의 결론 문장이 이 구도를 가장 압축적으로 표현합니다 — 대형 언어 모델은 사실 지식의 대부분을 사전학습에서 획득하고, 파인튜닝은 그 지식을 더 효율적으로 사용하도록 가르친다는 관점을 뒷받침한다고 논문은 적습니다.

이 문장이 맞다면 "사내 문서를 파인튜닝으로 학습시킨다"는 계획은 출발부터 도구를 잘못 고른 것입니다. 그런데 실무에서는 정반대 사례 연구도 돌아다닙니다. 그 모순부터 풀어야 합니다.

파인튜닝으로 지식을 넣을 수 있나 — 두 논문이 정반대로 보이는 이유

부정 쪽. Ovadia 등의 "Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs"(arXiv:2312.05934)는 지식 주입을 정면으로 잽니다. 결론은 명확합니다 — 비지도 파인튜닝도 일부 개선을 주지만, RAG가 일관되게 그것을 능가한다. 학습 때 본 기존 지식에서도, 완전히 새로운 지식에서도 그렇다. 그리고 모델은 비지도 파인튜닝으로 새로운 사실 정보를 배우는 데 어려움을 겪는다.

긍정 쪽. Microsoft의 "RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture"(arXiv:2401.08406)는 반대로 보입니다. 초록의 표현 그대로 — 파인튜닝으로 정확도가 6 p.p. 넘게 올랐고, 이는 RAG와 누적되어 5 p.p.가 더 올랐다.

두 결과는 충돌하는 걸까요? 아닙니다. 서로 다른 개입을 잰 것입니다.

Ovadia 등이 말하는 파인튜닝은 비지도 파인튜닝, 즉 계속사전학습(continual pre-training)입니다. 논문은 이 방식을 이 연구 전반에 걸쳐 쓴다고 명시합니다. 원문 텍스트를 그대로 놓고 다음 토큰을 예측하게 하는 방식이죠. 더 중요한 건 논문이 지도 파인튜닝(인스트럭션 튜닝)을 아예 후보에서 배제하며 적은 이유입니다 — 인스트럭션 튜닝이 반드시 모델에게 새로운 지식을 가르치는 것은 아니며, 따라서 인스트럭션 튜닝만으로는 지식 주입 문제의 해법이 될 수 없다.

반면 농업 논문의 파이프라인은 Q&A 쌍으로 파인튜닝합니다. 문서에서 질문·답변 쌍을 생성한 다음 그걸로 학습시킵니다. 완전히 다른 개입입니다.

그러니 정리하면 이렇습니다. "파인튜닝"이라는 한 단어가 최소 두 개의 다른 작업을 가리키고 있고, 두 논문은 각각 다른 쪽을 쟀습니다. 블로그 글들이 이 둘을 뒤섞어 인용하면서 "파인튜닝은 되기도 하고 안 되기도 한다"는 결론 없는 결론이 만들어집니다.

농업 논문의 숫자를 그대로 믿기 전에

긍정 쪽 근거를 인용할 거라면 그 근거의 한계도 같이 봐야 공정합니다. 논문의 Table 18은 이렇습니다.

모델                    파인튜닝   정확도      +RAG
Llama-2-chat 13B                 76% ±2%    75% ±2%
Vicuna                           72% ±2%    79% ±2%
GPT-4                            75% ±3%    80% ±4%
Llama2 13B                 O     68% ±3%    77% ±2%
GPT-4                      O     81% ±5%    86% ±2%

산수는 정확히 맞습니다. GPT-4 기준 75% → 81%이 초록의 "6 p.p. 넘게", 81% → 86%이 "RAG로 5 p.p. 더"입니다. 다만 세 가지를 짚어야 합니다.

오차 범위가 겹칩니다. 75% ±3%의 구간은 72~78이고, 81% ±5%의 구간은 76~86입니다. 76~78 구간에서 겹칩니다. 그리고 논문은 이 ± 값이 표준편차인지 신뢰구간인지 정의하지 않고, 유의성 검정도 제시하지 않습니다. 6 p.p.를 "확실한 개선"으로 읽으면 근거를 넘어서는 것입니다.
도메인 파인튜닝이 오히려 진 경우가 표 안에 있습니다. 농업 데이터로 파인튜닝한 Llama2 13B는 68%로, 범용 인스트럭션 튜닝 모델인 Llama-2-chat 13B의 76%보다 낮습니다. (다만 출발 체크포인트가 다릅니다 — 전자는 베이스 모델을, 후자는 chat 모델을 씁니다. 그래도 "도메인 데이터로 튜닝하면 도메인 과제에서 이긴다"는 직관이 자동으로 성립하지 않는다는 건 분명합니다.)
학습 라벨이 LLM 생성물이고, 채점자도 LLM입니다. 파인튜닝용 답변은 Llama2-13B-chat에 RAG를 붙여 생성했고, 평가는 GPT-4가 했습니다. 즉 이 실험은 상당 부분 "RAG 파이프라인의 출력을 모델에 증류(distill)한" 것에 가깝습니다.

그리고 새 지식을 억지로 넣으면 생기는 일

Gekhman 등(arXiv:2405.05904)은 여기서 한 걸음 더 갑니다. 파인튜닝 예시 중 새로운 지식을 도입하는 비율을 통제하면서 관찰한 결과, 새 지식을 담은 예시는 모델이 이미 아는 것과 일치하는 예시보다 눈에 띄게 느리게 학습됩니다. 그런데 결국 학습이 되고 나면, 그 예시들이 모델의 환각 경향을 선형적으로 증가시킵니다.

논문의 표현을 그대로 옮기면 — 새로운 사실 지식을 파인튜닝으로 도입하는 데에는 위험이 있다는 것을 결과가 보여준다. "느리게 배우고, 배우고 나면 환각이 는다"는 조합은 실무에서 최악입니다. 학습 손실은 떨어지는데 프로덕션 품질은 나빠지는 형태로 나타나니까요.

실무 함의: 자주 바뀌는 사실을 파인튜닝으로 넣지 마세요. 파인튜닝은 형식·말투·도메인 용어·출력 구조처럼 행동을 바꾸는 데 쓰세요. LoRA로 그걸 할 때 하이퍼파라미터가 어떻게 얽히는지는 LoRA rank와 학습률 편에서 따로 다룹니다.

롱컨텍스트는 어디서 무너지나 — 위치, 길이, 어휘

그럼 다 넣으면 되지 않나? 컨텍스트 창이 100만 토큰인데. 여기에는 서로 다른 세 개의 측정된 실패 모드가 있습니다.

위치. Liu 등의 "Lost in the Middle"(arXiv:2307.03172)은 관련 정보의 위치를 바꿔가며 성능을 쟀습니다. 결과는 잘 알려진 U자 곡선입니다 — 관련 정보가 입력의 처음이나 끝에 있을 때 성능이 가장 높고, 긴 컨텍스트의 중간에 있을 때 크게 떨어집니다. 논문은 이것이 명시적으로 롱컨텍스트를 표방하는 모델에서도 나타난다고 못 박습니다.

길이. Databricks의 "Long Context RAG Performance of Large Language Models"(arXiv:2411.03538)는 20개의 오픈소스·상용 모델에 대해 컨텍스트 길이를 2,000에서 128,000 토큰까지(가능한 경우 200만까지) 바꿔가며 RAG 워크플로를 돌렸습니다. 세 개의 도메인 데이터셋을 씁니다. 핵심 결과는 초록에 있습니다 — 문서를 더 많이 검색하면 성능이 오를 수 있지만, 64k 토큰을 넘어서는 길이에서 일관된 정확도를 유지할 수 있는 모델은 최신 SOTA 중에서도 극소수뿐이다.

본문은 더 구체적입니다. 분석한 대다수 모델에서 RAG 성능이 오르는 구간은 16k~32k 토큰까지였습니다. Qwen 2 70B는 64k까지 일관된 정확도를 유지하고, Llama 3.1 405B는 32k 이후 성능이 떨어지기 시작하며, GPT-4-0125-preview는 64k 이후 떨어집니다.

더 흥미로운 건 실패하는 방식이 모델마다 다르다는 것입니다. Claude 3 Sonnet은 저작권 우려를 이유로 답변을 자주 거부했고, Gemini 1.5 Pro는 지나치게 민감한 안전 필터 때문에 긴 컨텍스트에서 과제를 실패했으며, Mixtral-8x7B는 반복되거나 무작위한 내용을 뱉었고, DBRX는 16k 이상에서 지시를 따르지 않고 내용을 요약해 버리는 일이 잦았습니다. 즉 "롱컨텍스트가 나빠진다"는 말조차 하나의 현상이 아닙니다 — 거부, 안전 필터, 반복, 지시 무시가 각각 다른 모델에서 나타납니다.

어휘. NoLiMa(arXiv:2502.05167)는 가장 불편한 결과입니다. 기존 needle-in-a-haystack 테스트는 바늘과 건초더미 사이에 글자 그대로의 어휘 일치가 있어서 모델이 그걸 이용해 과제를 쉽게 만들 수 있다는 것이 이 논문의 지적입니다. 그래서 질문과 바늘의 어휘 중복을 최소화하도록 설계했더니, 128K 이상을 지원한다고 주장하는 13개 모델을 평가한 결과 짧은 컨텍스트에서는 잘하던 모델들의 성능이 길이가 늘수록 크게 떨어졌습니다. 32K에서 11개 모델이 자신의 짧은 길이 기준선 대비 50% 아래로 떨어졌고, 최상위권이던 GPT-4o조차 거의 완벽한 99.3%의 기준선에서 69.7%로 내려갔습니다.

여기서 중요한 함의: needle-in-a-haystack을 통과했다는 것은 롱컨텍스트가 작동한다는 증거가 아닙니다. 그 테스트는 어휘 일치라는 지름길을 허용하고 있었습니다. 실제 질문은 보통 문서와 같은 단어를 쓰지 않습니다.

정직한 한계: 위 세 연구가 평가한 모델은 모두 2023~2024년대(NoLiMa는 2025년 개정)입니다. 2026년의 프런티어 모델에서 같은 곡선이 나오는지를 같은 방법론으로 재측정한 공개 연구를, 저는 확인하지 못했습니다.

RAG가 롱컨텍스트보다 싼가 — Self-Route가 실제로 잰 것

비용 쪽에서 가장 많이 인용되는 것이 Google의 Self-Route 논문(Li 등, arXiv:2407.16833)입니다. 실제 표를 보겠습니다. Contriever 검색기 기준, 9개 데이터셋 평균입니다.

Gemini-1.5-Pro       LC 49.70 | RAG 37.33 | Self-Route 46.41 | 토큰 38.39%
GPT-4O               LC 48.67 | RAG 32.60 | Self-Route 48.89 | 토큰 61.40%
GPT-3.5-Turbo        LC 32.07 | RAG 30.33 | Self-Route 35.32 | 토큰 38.85%

읽는 법은 이렇습니다. 자원이 충분하면 LC가 RAG를 일관되게 이깁니다 — 49.70 대 37.33은 작은 차이가 아닙니다. 하지만 Self-Route(쉬운 질문은 RAG로, RAG가 "답할 수 없다"고 판단한 것만 LC로)는 LC 토큰의 38~61%만 쓰고도 LC에 근접합니다.

왜 이게 되는지가 이 논문의 진짜 발견입니다 — 63%의 질의에서 모델 예측이 정확히 동일했고, 70%의 질의에서 점수 차이가 10 미만이었습니다. 그리고 논문은 한 가지를 덧붙입니다: 동일한 예측이 반드시 정답인 것은 아니며, RAG와 LC는 같은 정답뿐 아니라 같은 실수도 하는 경향이 있다. 즉 대부분의 질문에서 두 방식은 애초에 구분되지 않습니다. 비싼 쪽을 쓸 이유가 없는 겁니다.

비용 수치는 조심해서 인용해야 합니다. 논문 본문은 Gemini-1.5-Pro에서 비용이 65%, GPT-4O에서 39% 줄었다고 적습니다. GPT-4O는 산수가 정확히 맞습니다 — 토큰 61.40%를 쓰니 38.6% 절감, 반올림해서 39%입니다. 그런데 Gemini-1.5-Pro는 토큰 38.39%를 쓰므로 절감은 약 61.6%여야 하고, Dragon 검색기를 쓴 Table 2에서도 토큰 비율은 37.87%(약 62.1% 절감)입니다. 논문이 말하는 65%는 논문 자신의 표에서 약 3 p.p. 벗어납니다. 큰 문제는 아니지만, "65%"를 그대로 옮겨 적기 전에 알고는 있어야 합니다.

그리고 결정적인 한계: 이 논문이 쓴 모델은 gpt-3.5-turbo-0125, gpt-4o-2024-05-13, Gemini-1.5-Pro입니다. 2024년 모델입니다. 데이터셋은 LongBench(평균 컨텍스트 약 7k 단어)와 ∞Bench(평균 약 100k 토큰)로, 여기서 말하는 "롱컨텍스트"는 100만 토큰이 아니라 7k~100k입니다.

2026년에는 후속 연구가 있습니다. "Route Before Retrieve"(arXiv:2605.10235, 2026년 5월)는 Self-Route가 RAG를 먼저 시도하고 실패하면 LC로 넘어가는 수동적 폴백이라는 점을 지적하며, 검색 전에 메타데이터(문서 유형, 길이, 초반 스니펫)로 라우팅을 먼저 결정하는 방식을 제안합니다. 방향 자체가 "질문마다 다른 도구"라는 Self-Route의 통찰을 유지하면서 그 비용을 더 줄이는 쪽으로 가고 있다는 신호입니다.

그런데 벤치마크 자체가 오염돼 있다 — 이 글에서 가장 중요한 부분

지금까지의 숫자를 전부 흔드는 발견이 하나 있습니다.

"Long Context vs. RAG for LLMs: An Evaluation and Revisits"(arXiv:2501.01880)는 기존 연구들을 다시 검토하면서 그들의 핵심 통찰과 불일치를 짚습니다. 그리고 아주 단순하지만 아무도 하지 않던 일을 합니다 — 외부 컨텍스트 없이도 답할 수 있는 질문을 걸러냅니다. 현대 LLM은 파라미터에 인코딩된 지식만으로 많은 질문에 답할 수 있으니, 롱 문서에서 어느 쪽이 더 도움이 되는지를 판단하려면 모델이 컨텍스트 없이는 못 맞히는 질문만 남겨야 한다는 논리입니다. 필터링에는 GPT-4o를 쓰고, 엄격한 exact-match 채점을 적용합니다.

결과는 이렇습니다.

데이터셋           전체 질문    남은 질문   유지율
Coursera                172          54     32%
NQ                    1,109         373     34%
NovelQA               2,283         869     38%
2WikiMHQA             2,300       1,036     45%
HotpotQA              2,200       1,113     51%
MultiFieldQA            150         121     81%
NarrativeQA           2,211       1,880     85%
QASPER                2,718       2,674     98%
QuALTY                2,725       2,725    100%
TOEFL-QA                962         962    100%
MultiDoc2Dial           158         158    100%
─────────────────────────────────────────────────
합계                 19,188      13,628     71%

Natural Questions에서 유지율이 34%입니다. 바꿔 말하면 NQ 질문의 약 3분의 2는 GPT-4o가 컨텍스트를 하나도 안 주고도 맞힙니다. Coursera는 32%, NovelQA는 38%입니다.

이게 왜 치명적이냐면 — 이 벤치마크들 위에서 "RAG 대 롱컨텍스트" 점수를 재면, 그 점수의 상당 부분은 검색이 아니라 모델의 사전학습 지식을 재고 있는 것입니다. 그리고 앞서 인용한 Databricks 연구가 쓴 세 데이터셋 중 하나가 바로 NQ입니다.

여기서 나오는 실무적 결론이 이 글에서 가장 중요합니다. 당신의 사내 문서는 모델의 사전학습 데이터에 없습니다. 그래서 공개 벤치마크에서 나온 RAG 대 LC 비율을 당신 코퍼스에 그대로 옮기면 안 됩니다. 벤치마크에서는 모델이 답의 상당수를 이미 알고 있었고, 당신 코퍼스에서는 하나도 모릅니다. 조건이 다릅니다.

덧붙여 이 논문의 결론 자체도 앞선 연구들과 미묘하게 다릅니다 — QA 벤치마크, 특히 위키피디아 기반 질문에서는 LC가 대체로 RAG를 능가하고, 요약 기반 검색은 LC와 비슷하며 청크 기반 검색은 뒤처진다. 다만 대화 기반 질의와 일반적 질의에서는 RAG가 유리하다. "RAG가 이긴다/진다"가 데이터셋 종류에 따라 뒤집힌다는 뜻입니다.

2026년에 달라진 것 — 캐싱은 롱컨텍스트를 공짜로 만들지 않는다

Self-Route의 비용 모델은 단순합니다. 논문 스스로 적었듯 LLM API 가격은 보통 입력 토큰 수에 기반하므로, 토큰을 적게 쓰면 그만큼 싸다는 것입니다. 2024년에는 맞는 모델이었습니다.

그 사이에 프롬프트 캐싱이 보편화됐습니다. 안정적인 접두부(prefix)를 캐시에 올려두면 재사용할 때 훨씬 쌉니다. Anthropic이 문서화한 자사 구조를 예로 들면, 캐시 읽기는 기본 입력 가격의 약 0.1배이고 캐시 쓰기는 5분 TTL에서 1.25배, 1시간 TTL에서 2배입니다. 캐시 가능한 최소 접두부 길이도 모델마다 다릅니다(예: Opus 4.8은 4,096토큰, Sonnet 4.6은 2,048토큰). 여기서 자연스러운 반론이 나옵니다 — 코퍼스가 안정적이고 질의가 반복된다면, 통째로 캐시에 올려두면 Self-Route의 비용 논리가 무너지는 것 아닌가?

부분적으로만 그렇습니다. 2026년 3월의 "Beyond the Context Window"(arXiv:2603.04814)가 이걸 실제로 쟀습니다. 프롬프트 캐싱을 포함한 비용 모델을 세워 사실 기반 메모리 시스템(Mem0)과 롱컨텍스트 추론을 비교한 연구입니다. 핵심 문장은 이겁니다 — 롱컨텍스트 추론은 캐싱을 적용해도 컨텍스트 길이에 비례해 커지는 턴당 비용을 치르는 반면, 메모리 시스템의 턴당 읽기 비용은 일회성 쓰기 단계 이후 거의 고정된다.

측정값은 이렇습니다(LongMemEval, 500개 대화, 평균 컨텍스트 101,601 토큰).

                        비용
메모리 쓰기(1회)        $0.0435 / 대화   (총 $21.76, 500개 대화)
메모리 읽기             $0.0013 / 질의   (총 $0.65, 500개 질문)
LC GPT-5-mini           $0.0293 / 요청   (총 $14.79, 504개 요청)
LC 첫 턴(모델값)        $0.0265
─────────────────────────────────────────────────────────────
손익분기: 약 10턴 (100k 컨텍스트). N=20에서 메모리가 26% 저렴.
컨텍스트가 길어질수록 분기점은 13턴 -> 9턴으로 내려감.

산수가 맞습니다($21.76을 500으로 나누면 $0.0435, $14.79를 504로 나누면 $0.0293). 그래서 턴 수가 적으면 롱컨텍스트가 싸고, 많으면 검색이 쌉니다. 캐싱은 이 곡선의 기울기를 낮출 뿐 방향을 뒤집지 못합니다.

그런데 이 논문을 인용할 때 반드시 같이 말해야 하는 게 있습니다. 정확도에서는 롱컨텍스트가 크게 이겼습니다.

데이터셋          메모리 시스템   LC GPT-5-mini   LC GPT-OSS-120B
LoCoMo                  57.68           92.85            81.69
PersonaMem v2           62.48           69.75            60.50
LongMemEval             49.00           82.40            48.20

LoCoMo에서 57.68 대 92.85, LongMemEval에서 49.00 대 82.40입니다. 싼 쪽이 정확도에서 크게 졌습니다. 논문은 그 이유도 적습니다 — 전체 이력을 넘기면 모든 디테일이 보존되지만, 메모리 파이프라인은 약 101,600 토큰의 대화를 사용자당 평균 2,909 토큰의 원자적 사실로 압축하므로 압축 과정에서 정보 손실이 불가피하다는 것입니다.

범위 제한: 이 연구는 지속형 대화 에이전트의 메모리 시스템을 잰 것이지, 문서 코퍼스 RAG를 잰 것이 아닙니다. 비용 구조에 대한 통찰("검색은 턴당 고정, 롱컨텍스트는 캐싱해도 길이 비례")은 일반화되지만, 정확도 숫자는 대화 메모리 벤치마크의 것입니다. 그대로 옮기면 안 됩니다.

캐싱의 효과 자체는 별도로 측정됐습니다. "Don't Break the Cache"(arXiv:2601.06007)는 세 제공자에 걸쳐 500개 이상의 에이전트 세션에서 캐싱을 측정해 비용 절감이 41%에서 80% 범위, TTFT 개선이 13%에서 31% 범위라고 보고합니다. 다만 이 논문 역시 에이전트형 도구 호출 워크로드(DeepResearch Bench)를 잰 것이고, 전체 컨텍스트 캐싱 전략에서는 TTFT 개선이 없거나 약간의 퇴행을 보였다고 적습니다. 그리고 이 논문 스스로 밝히듯, 저자들이 아는 한 다중 턴 에이전트 과제에서 이 비용 절감을 정량화한 선행 연구는 없었습니다.

그래서 뭘 봐야 하나 — 당신이 실제로 잴 수 있는 것

이제 결정 규칙입니다. 여기서 핵심은 벤치마크를 읽지 말고 당신 코퍼스를 재라는 것입니다. 그리고 재야 할 첫 번째 숫자는 하나뿐입니다.

1단계: recall@k 곡선을 그리세요 (이게 거의 다 결정합니다)

Databricks 논문이 부록에 넣어둔 표가 사실상 이 방법론의 템플릿입니다. text-embedding-3-large로 각 데이터셋의 recall@k를 컨텍스트 길이별로 잰 것입니다.

컨텍스트 길이        2k     4k     8k    16k    32k    64k    96k   128k
Databricks DocsQA  0.547  0.856  0.906  0.957  0.978  0.986  0.993  0.993
FinanceBench       0.097  0.287  0.493  0.603  0.764  0.856  0.916  0.916
NQ                 0.845  0.992  1.000  1.000  1.000  1.000  1.000  1.000

논문의 해석 그대로 — 각 데이터셋의 검색 recall이 포화하는 컨텍스트 길이가 다릅니다. NQ는 8k에서 일찍 포화하고, DocsQA와 FinanceBench는 각각 96k와 128k에서 포화합니다.

이 곡선이 당신의 답입니다.

작은 k에서 포화한다면(NQ처럼) — 답이 국소적입니다. 검색이 8k 안에서 이미 모든 근거를 가져옵니다. 롱컨텍스트는 아무것도 더 주지 않고, 방해 문서(distractor)만 늘립니다. RAG를 쓰세요. 여기서 컨텍스트를 늘리는 건 순수한 손해입니다.
96k~128k까지 계속 오른다면(FinanceBench처럼) — 근거가 넓게 흩어져 있습니다. 이게 롱컨텍스트가 값을 할 수 있는 유일한 영역입니다. 단, 조건이 있습니다(2단계).
끝까지 좋아지지 않는다면 — FinanceBench는 128k에서도 0.916입니다. 100%에 도달하지 못합니다. 검색이 병목이거나(청킹·임베딩 문제), 애초에 검색으로 풀 문제가 아닙니다. 후자라면 하이브리드 검색과 리랭킹을 먼저 시도하고, 그래도 안 되면 질문이 "검색"이 아니라 "종합"을 요구하는 것일 수 있습니다 — 그때가 Graph RAG를 검토할 지점입니다.

그리고 Databricks 논문이 붙인 경고를 반드시 함께 읽어야 합니다 — 검색 정확도는 단조적으로 증가하지만, 그것이 RAG 정확도가 단조적으로 증가한다는 뜻은 아니다. 컨텍스트를 늘리면 recall은 오르고 생성은 나빠집니다. 그래서 최적점은 양 끝이 아니라 중간 어딘가에 있습니다. 이건 곡선을 그려야만 찾을 수 있습니다.

재는 방법은 어렵지 않습니다. 정답 문서를 아는 질문 50~100개를 만들고, k를 바꿔가며 정답 문서가 상위 k에 들어오는 비율을 세면 됩니다. 이건 LLM 호출이 필요 없는 순수 검색 지표라 싸고 빠릅니다.

2단계: 모델이 그 길이에서 버티는지 확인하세요

1단계에서 "96k까지 오른다"가 나왔다고 해서 96k를 넣으면 되는 게 아닙니다. Databricks 측정에서 대다수 모델은 16k~32k에서 이미 성능이 꺾였습니다. 그리고 NoLiMa가 보여줬듯, 질문과 문서의 어휘가 겹치지 않으면 32K에서 대부분의 모델이 무너집니다. 당신의 질문이 문서와 같은 단어를 쓰나요? 보통은 아닙니다.

3단계: 갱신 빈도를 보세요

코퍼스가 자주 바뀌면 파인튜닝은 후보에서 빠집니다(바뀔 때마다 재학습). 롱컨텍스트도 캐싱 이득이 사라집니다(접두부가 바뀌면 캐시가 무효화되고, 기본 TTL은 분 단위입니다). 자주 바뀌는 코퍼스에서는 RAG가 기본값입니다.

4단계: 지식인가 행동인가

"우리 말투로 답하게" / "이 JSON 스키마로만" / "이 도메인 약어를 이해하게" → 파인튜닝. "이 문서에 뭐라고 적혀 있나" → 검색. 이 둘을 섞지 마세요. Ovadia와 Gekhman의 결과가 말하는 게 정확히 이겁니다.

5단계: 턴 수로 예산을 계산하세요

같은 컨텍스트에 질문을 몇 번 던지나요? "Beyond the Context Window"의 구조를 빌리면 — 턴이 적으면 롱컨텍스트가 싸고, 많으면 검색이 쌉니다. 100k 컨텍스트에서 분기점은 약 10턴이었습니다. 문서 하나당 질문 하나면 롱컨텍스트가 유리할 수 있고, 같은 코퍼스에 수천 개 질의가 오면 검색이 압도적입니다.

언제 쓰지 말아야 하나

가장 인용할 만한 부분은 보통 여기입니다.

파인튜닝을 사실 주입에 쓰지 마세요. 느리게 배우고, 배우고 나면 환각이 늡니다(Gekhman 등). 사내 위키를 파인튜닝하는 프로젝트는 거의 항상 잘못된 도구 선택입니다.
컨텍스트 창이 100만이라서 롱컨텍스트를 쓰지는 마세요. 창 크기는 용량이지 능력이 아닙니다. NoLiMa 기준 32K에서 13개 중 11개 모델이 자기 기준선의 절반 아래로 떨어졌습니다.
needle-in-a-haystack 통과를 근거로 삼지 마세요. 그 테스트는 어휘 일치 지름길을 허용합니다.
recall이 작은 k에서 포화하는데 컨텍스트를 늘리지 마세요. 방해 문서만 늘고 lost-in-the-middle에 들어갑니다.
공개 벤치마크의 RAG 대 LC 비율을 당신 코퍼스에 옮기지 마세요. NQ 질문의 약 3분의 2는 컨텍스트 없이도 풀립니다. 당신 문서는 그렇지 않습니다.
그리고 이 글의 숫자도 당신 코퍼스의 답이 아닙니다. 전부 남의 코퍼스, 남의 모델에서 나온 것입니다.

아무도 답하지 않은 것

정직하게 적을 부분입니다. 아래는 제가 확인한 범위에서 공개된 연구가 답하지 않은 질문들입니다.

세 방식을 하나의 공통 벤치마크에서 비교한 연구가 없습니다. RAG 대 LC(Self-Route, 2501.01880)와 RAG 대 파인튜닝(Ovadia, 농업 논문)은 각각 존재하지만, 서로 다른 모델·데이터셋·지표를 씁니다. 그래서 "RAG가 LC보다 12점 낮고 파인튜닝이 6 p.p. 올리니까 RAG+파인튜닝이…" 같은 계산은 성립하지 않습니다. 이 글에서도 하지 않았습니다.
2026년 프런티어 모델에서 RAG 대 LC를 캐싱까지 반영해 재측정한 연구가 없습니다. Self-Route는 2024년 모델과 토큰 기반 비용 모델을 씁니다. 캐싱 인지 비용 모델은 2603.04814가 세웠지만 대상이 대화 메모리이지 문서 RAG가 아닙니다.
캐싱의 에이전트 워크로드 효과조차 최근에야 측정됐습니다. 2601.06007은 자신들이 아는 한 다중 턴 에이전트 과제에서 이 비용 절감을 정량화한 선행 연구가 없다고 명시합니다.
파인튜닝 방식별 지식 주입 효과를 통제 비교한 연구가 부족합니다. 비지도 계속사전학습(Ovadia)과 지도 Q&A 튜닝(농업)이 같은 데이터·같은 평가에서 비교된 적이 없습니다. 그래서 "지도 Q&A 튜닝이면 지식 주입이 되는가"는 여전히 열려 있습니다 — 농업 논문의 증거는 오차 범위가 겹치고 라벨이 LLM 생성물입니다.

이런 공백이 있다는 사실 자체가 실무적으로 중요합니다. 누군가 "연구에 따르면 RAG가 파인튜닝보다 X% 낫다"고 단언한다면, 그 X가 어떤 파인튜닝을 어떤 데이터로 잰 것인지 물어보세요.

마치며

이 질문에 대한 흔한 답이 쓸모없는 이유는 틀려서가 아니라 결정 불가능하기 때문입니다. "최신 정보면 RAG"는 맞지만 내 문제가 거기 해당하는지 알 수가 없습니다.

측정된 것만 남기면 그림은 이렇게 정리됩니다. 파인튜닝은 지식 주입 도구가 아닙니다 — 이건 여러 논문에서 반복 확인됐고, 반대로 보이는 사례 연구는 다른 개입을 잰 것입니다. 롱컨텍스트는 위치·길이·어휘 세 축에서 각각 무너지고, 대다수 모델의 실질 한계는 광고된 창 크기보다 한 자릿수 작습니다. RAG와 롱컨텍스트는 대부분의 질의에서 애초에 같은 답을 냅니다 — Self-Route 기준 63%가 정확히 동일했습니다. 그리고 이 모든 숫자가 올라탄 벤치마크는, 3분의 1에서 3분의 2가 컨텍스트 없이도 풀리는 질문들이었습니다.

그래서 실무의 답은 벤치마크를 더 읽는 게 아니라 곡선 하나를 직접 그리는 것입니다. 당신 코퍼스, 당신 질문 50개, k를 바꿔가며 recall. 작은 k에서 포화하면 RAG, 끝까지 오르면 롱컨텍스트를 검토하되 모델이 그 길이에서 버티는지 확인, 끝까지 안 오르면 검색이 아니라 문제 정의를 다시 보세요.

도구가 아니라 질문이 먼저입니다. 그리고 그 질문의 성질은, 남의 논문이 아니라 당신 데이터에만 적혀 있습니다.