📄 RAG vs 파인튜닝, 문서는 어디에 두어야 할까

사내 문서 수천 건을 LLM에 물려야 할 때 팀은 늘 같은 자리에서 멈춘다. 프롬프트에 검색해서 넣을까, 아니면 파인튜닝으로 모델에 새겨 넣을까. 최근에는 세 번째 선택지가 하나 더 생겼다. 문서를 미리 KV 캐시 형태로 압축해두고 필요할 때 끼워 넣는 방식이다. 2026년 9월 15일 공개된 논문은 이 세 경로를 같은 조건에서 나란히 세워 비교했다.

세 가지 경로

• 컨텍스트: 문서를 그대로 컨텍스트 창에 넣는다. 인컨텍스트 학습(ICL, 모델이 프롬프트에 주어진 자료만으로 과제를 수행하는 것)이 여기 해당한다. 가장 정확하지만 토큰 비용과 길이 제한이 걸린다.
• 표현(KV 캐시): 문서를 미리 계산해둔 키-값 캐시로 압축해 잠재 표현 형태로 주입한다. 논문이 비교한 Cartridges와 Compaction이 이 계열이다.
• 파라미터: 파인튜닝이나 어댑터로 모델 가중치 자체에 지식을 새긴다.

결과

다섯 개 지식 집약 벤치마크에서 나온 결론은 일관됐다. 오라클 설정에서 Cartridges는 거의 모든 저장 예산 구간에서 가장 정확했다. 더 중요한 건 현실적인 다중 문서 검색 상황인데, 여기서는 Cartridges만이 인컨텍스트 학습 수준을 따라잡은 유일한 방식이었다. 파인튜닝 계열은 29점, 같은 KV 계열인 Compaction도 15점 뒤처졌다.

Compaction은 압축률이 낮을 때만 Cartridges를 따라갔고, 50배를 넘기면 오히려 파라미터 방식보다 10점 뒤졌다. "KV 캐시 방식"이 하나의 덩어리가 아니라는 뜻이다.

공짜 점심은 없다

논문에서 가장 중요한 문장은 성능표가 아니라 그 뒤에 온다. Cartridges는 전체 파인튜닝, 대형 MLP 어댑터와 더불어 파국적 망각(catastrophic forgetting)을 겪는 유일한 방식이었다. 새 지식을 넣는 대가로 원래 할 줄 알던 것을 잊는 현상이다. 통제 벤치마크에서 6%, 코딩 과제에서는 13%까지 성능이 떨어졌다.

즉 순위표의 1등은 "가장 정확하지만 모델의 기존 능력을 일부 갉아먹는" 방식이다. 코딩 13%는 작은 숫자가 아니다. 사내 문서 질의응답을 잘하게 만들려다 개발 보조 기능이 눈에 띄게 나빠질 수 있다는 뜻이기 때문이다.

그래서 진짜 의미하는 것

"검색 기반 방식은 끝났다" 같은 결론을 내기에는 이르다. 이유가 셋 있다.

첫째, 비교의 기준선이 여전히 ICL이다. 현실 조건에서 Cartridges의 성취는 "ICL을 이겼다"가 아니라 "ICL을 따라잡았다"이다. 검색해서 컨텍스트에 넣는 익숙한 방식이 여전히 강력한 기준선이라는 뜻이다.

둘째, KV 캐시 주입은 문서 집합이 어느 정도 고정돼 있을 때 유리하다. 문서가 매일 바뀌면 캐시를 다시 만드는 비용을 따져야 한다. 논문의 저장 예산 비교는 이 재생성 비용까지 다루지는 않는다.

셋째, 망각 문제는 모델을 범용으로 쓸수록 커진다. 한 가지 업무 전용이라면 감수할 만하지만, 같은 모델로 여러 일을 시킨다면 6~13%의 대가는 다시 계산해봐야 한다.

마무리

정리하면 이렇다. 문서가 자주 바뀌고 모델을 범용으로 쓴다면 검색 기반 컨텍스트 주입이 여전히 무난하다. 문서 집합이 고정적이고 저장 비용을 줄이면서 정확도를 최대로 올려야 한다면 KV 캐시 방식이 가장 유력하지만, 기존 능력 저하를 반드시 함께 측정해야 한다. 어느 쪽이든 "하나가 다 이긴다"는 답은 이 논문에도 없다.

출처

Nathanaël Carraz Rakotonirina, Momchil Hardalov, Gonzalo Iglesias 외, "Where Should a Document Live: Context, Representations, or Parameters?", arXiv:2609.17346v1, 2026년 9월 15일. https://arxiv.org/abs/2609.17346v1