Long-Context 모델은 정말 나을까 — 언제 큰 컨텍스트가 RAG를 이기는가
300페이지짜리 계약서 PDF를 Claude에 통으로 넣었더니 답은 빨랐지만, 월말 청구서를 보고 전략을 바꿨어요. 일회성 문서 분석이면 200K 컨텍스트 창이 편하지만, 반복 참조가 필요한 작업이라면 RAG가 훨씬 경제적입니다. 컨텍스트 창이 크다고 무조건 좋은 게 아니더라고요 — 중간 소실 문제와 입력 토큰 비용이 생각보다 큽니다.
어떤 기준으로 비교했나요?
제가 실무에서 long-context 모델과 RAG를 동시에 써본 환경은 두 가지였어요. 하나는 법률 문서 분석(일회성·긴급), 다른 하나는 레거시 코드베이스 리뷰(반복 참조·장기). 평가 기준은 세 가지로 좁혔습니다. 비용 효율(입력 토큰 선형 증가 vs 검색 오버헤드), 응답 속도(전체 입력 vs 청크 검색), 그리고 정확도(중간 소실 현상 vs 검색 정밀도 의존성)예요. 벤치마크 수치보다는 실제 작업 과정에서 체감한 차이에 집중했습니다.
300페이지 계약서를 넣어봤더니
첫 테스트는 긴 계약서였어요. Claude Opus 200K 창에 PDF 전체를 넣고 "3조 위반 조항이 있나요?"라고 물었죠. 답은 30초 안에 나왔고, 문맥을 온전히 이해한 답변이었습니다. 같은 문서를 RAG로 처리하려면 청크 분할·벡터 임베딩·검색 파이프라인을 먼저 구축해야 하는데, 급한 작업이라 그럴 여유가 없었어요.
그런데 문제는 비용이었습니다. 300페이지 PDF는 대략 15만 토큰 정도였는데, 입력 토큰 단가가 출력보다 훨씬 저렴하긴 해도 질문 한 번에 그만큼 다시 넣으니 누적이 부담스러웠어요. 같은 문서로 질문 5개를 더 던지자 입력 토큰만 75만이 쌓이더라고요. 이때부터 "이건 일회성 작업에만 쓰는 게 맞겠다"는 생각이 들었습니다.
반면 레거시 코드베이스는 달랐어요. 프로젝트 전체가 10만 줄이 넘는데, 매일 다른 모듈을 검토해야 했죠. 처음엔 관련 파일만 골라 컨텍스트 창에 넣었는데, 파일 선택을 제가 수동으로 해야 하니 번거로웠어요. RAG를 구축하고 나니 "이 함수는 어디서 호출되나요?" 같은 질문에 관련 청크만 검색돼서 답변이 나왔고, 입력 토큰은 질문마다 몇천 개 수준으로 줄었습니다.
여기서 중간 소실 문제도 체감했어요. 제가 긴 문서를 넣을 때마다 중간쯤 정보를 놓치는 걸 반복해서 겪었거든요. 특히 중요한 내용이 문서 중간 부분에 있으면 제대로 답하지 못하는 경우가 있었어요. 반면 RAG는 검색 정밀도가 좋으면 필요한 부분만 정확히 가져오니 이 문제가 덜했습니다.
비용 함정을 직접 밟아본 이야기
월말에 청구서를 보고 깨달은 게 있어요. Long-context 모델은 입력 토큰 비용이 선형으로 증가합니다. 문서가 두 배 길면 비용도 두 배예요. 처음엔 "입력 토큰 단가가 저렴하니까 괜찮겠지"라고 생각했는데, 반복 작업에선 누적이 무서웠어요. 같은 문서로 질문 20개를 던지면 매번 15만 토큰씩 입력되니, 실제론 300만 토큰을 쓴 셈이었죠.
RAG는 초기 구축 비용(임베딩 생성·벡터 DB 셋업)이 있지만, 이후엔 질문당 입력 토큰이 훨씬 적어요. 검색된 청크 몇 개만 넣으니 질문 하나에 3천~5천 토큰 정도였습니다. 장기적으로 반복 참조가 많은 작업이라면 RAG가 압도적으로 경제적이더라고요.
다만 RAG에도 함정은 있었어요. 검색 정밀도가 나쁘면 엉뚱한 청크를 가져와서 답변 품질이 떨어집니다. 임베딩 모델 선택, 청크 크기 조정, 하이브리드 검색(키워드+벡터) 같은 튜닝을 해야 제대로 돌아가더라고요. 반면 long-context는 문서를 통으로 넣으니 이런 고민이 없었어요 — 대신 비용과 중간 소실을 감수해야 하지만요.
실제 프로젝트에서 전환한 계기
실무에서 전환 시점은 명확했어요. 코드 리뷰 프로젝트를 3주째 돌리는데, 컨텍스트 창으로 매일 파일을 넣다 보니 입력 토큰이 한 달에 천만 개를 넘어섰거든요. 그때 RAG 파이프라인 구축에 이틀을 투자했고, 그 후로는 같은 작업을 하는데도 토큰 소비가 10분의 1로 줄었습니다. 초기 셋업 시간이 아까울 수 있지만, 프로젝트 기간이 한 달 이상이라면 회수가 빠르더라고요.
팀 규모도 중요한 변수예요. 혼자 쓸 땐 컨텍스트 창으로 빠르게 처리하는 게 편했는데, 팀원 3명이 같은 문서를 반복 참조하기 시작하니 RAG가 필수가 됐습니다. 각자 매번 전체 문서를 넣으면 토큰 낭비가 심해서요. RAG는 한 번 구축하면 여러 명이 공유할 수 있으니, 협업 환경에선 더 유리했어요.
자주 묻는 질문
Q. Long-context 모델에서 중간 소실은 얼마나 심각한가요? A. 모델과 문서 구조에 따라 다르지만, 제 경험상 중요한 내용이 문서 중간(30~70% 구간)에 있을 때 놓치는 경우가 있었어요. 특히 문서 앞뒤에 비슷한 맥락이 있으면 중간 부분을 건너뛰는 느낌이었습니다.
Q. RAG 구축 시간은 얼마나 걸리나요? A. 간단한 파이프라인(임베딩 생성·벡터 DB 셋업)은 하루 안에 가능합니다. 다만 검색 정밀도 튜닝(청크 크기·하이브리드 검색·재순위)까지 하려면 며칠 더 필요해요. 반복 작업이 확실하다면 이 시간은 충분히 투자할 가치가 있었습니다.
Q. 컨텍스트 창이 크면 응답 속도가 느려지나요? A. 네, 입력 토큰이 많을수록 처리 시간이 늘어납니다. 제가 써본 기준으로 10만 토큰 이상 넣으면 첫 토큰까지 몇 초 대기하는 게 체감됐어요. RAG는 검색된 청크만 넣으니 응답 시작이 더 빨랐습니다.
Q. 두 가지를 섞어 쓸 수 있나요? A. 가능합니다. 저는 긴급 작업엔 long-context로 빠르게 처리하고, 같은 문서를 나중에 반복 참조할 것 같으면 그때 RAG로 구축했어요. 초기 탐색은 컨텍스트 창, 장기 운영은 RAG — 이렇게 단계별로 나누는 것도 방법입니다.
출처: Claude 공식 모델 비교표 (Anthropic 공식 문서)