분석: 긴 컨텍스트는 검색(RAG)을 죽이지 않았다 — 검색의 «역할»을 바꿨다

컨텍스트 창이 자릿수 단위로 커질 때마다 같은 주장이 돈다. 검색은 창이 작아서 쓰던 우회로였고, 이제 창이 커졌으니 검색은 끝났다는 것. 문서를 프롬프트에 넣고 모델이 알아서 정리하게 하면 된다는 것.

터무니없는 주장은 아니다. 코드베이스 전체, 1년 치 메일, 계약서 한 무더기를 요청 하나에 담는 것이 실제로 가능해졌다. 그런데도 대부분의 프로덕션 시스템이 여전히 검색하는 이유는 관성이 아니다. 수용량과 활용도가 다른 것이고, 검색이 가진 성질 중 셋은 창 크기와 애초에 아무 상관이 없기 때문이다.

수용량은 활용도가 아니다

100만 토큰을 받는 모델은 100만 토큰을 받는다. 그것을 «고르게 쓰는가»는 별개의 실증 문제이고, 이 현상이 처음 정리된 이래 답은 일관돼 왔다 — 회상은 긴 입력의 앞과 뒤에서 가장 강하고 가운데에서 가장 약하다.

실무적 결과는 불편하다. 문서가 프롬프트의 어디에 떨어지는가가 그 문서를 쓸지 말지에 영향을 준다. 그 문서가 얼마나 관련 있는가와 무관하게. 문서 오십 개를 임의 순서로 이어 붙이는 시스템은 아무도 감시하지 않는 품질 변수를 하나 들여놓은 것이고, 그 변수는 이어 붙이는 순서가 바뀌는 다음번에 함께 움직인다.

흔한 안심 재료는 «건초더미 속 바늘» 결과다 — 눈에 띄는 문장을 큰 창에 심어 두고 안정적으로 찾아내는 것. 그 시험은 보이는 것보다 훨씬 쉽다. 특이한 문자열 하나를 찾는 것은 어휘 대조 과제다. 실제 질문은 여러 문단을 모으고, 그중 둘이 서로 어긋난다는 것을 알아채고, 혹은 «답이 없다»고 판정할 것을 요구한다. 그 어려운 모양을 재려고 만든 벤치마크들은 실효 작업 컨텍스트가 광고된 수용량보다 한참 아래라는 결과를 일관되게 낸다.

아무도 하기 싫어하는 산수

비용과 지연은 «보내도 되는 양»이 아니라 «보낸 양»에 비례한다.

20만 토큰짜리 지식베이스를 두고 하루 만 건의 질문을 처리하는 고객지원 비서를 생각해 보자. 매 요청마다 지식베이스를 통째로 넣으면 하루 20억 입력 토큰이다. 현재 어느 프런티어 단가로도 눈에 띄는 예산 항목이 된다. 질문마다 관련된 4천 토큰만 검색해 넣으면 4천만 토큰 — 50배 차이이고, 그 차이가 매 요청마다, 계속 적용된다.

지연도 같은 곡선을 탄다. 첫 토큰까지의 시간은 입력 길이와 함께 늘고, 900밀리초에 답이 나오기 시작하는 지원 위젯과 8초가 걸리는 위젯은 답의 품질과 무관하게 다른 제품이다.

프롬프트 캐시는 이 계산을 복잡하게 만들고, 통째로 넣는 쪽의 가장 강한 논거이므로 정확히 적어 둘 만하다. 큰 접두부가 여러 요청에 걸쳐 «동일»할 때, 캐시는 그 비용을 몇 배수로 줄이고 지연도 상당히 깎는다. 말뭉치가 정말로 공유되고 안정적이라면 — 고정된 제품 매뉴얼, 고정된 법령 — 계산이 달라지고, 이 경로는 덜 쓰이고 있다. 다만 캐시는 큰 내용이 사용자마다·요청마다 다르면 아무 일도 못 한다. 그리고 그것이 대부분의 기업 배포의 모습이다 — 애초에 사용자마다 다른 문서를 보는 것이 요점이니까.

검색에는 있고 컨텍스트에는 없는 세 가지

창이 커져도 움직이지 않는 부분이 여기다.

출처 추적. 검색된 문단은 모델이 보기 전에 이미 신원을 갖는다 — 문서 id, URL, 쪽, 판번호. 모델이 그것을 인용하면 그 인용은 기계적으로 검증된다. 창에 그냥 부어 넣은 텍스트에는 그런 신원이 없고, 구분되지 않은 덩어리에서 인용하라고 하면 검증하기 어렵고 지어내기 쉬운 참조가 나온다. 틀린 답에 «추적 가능한 출처»가 필요한 모든 응용 — 법률·의료·금융·컴플라이언스 — 에서는 이 한 가지로 설계가 정해진다.

최신성. 말뭉치는 바뀐다. 검색 색인은 새 행을 써서 갱신하고, 통째로 넣은 프롬프트는 payload 전체를 다시 만들어 다시 보내서 갱신한다. 지식베이스가 한 시간마다 바뀐다면, 한쪽은 백그라운드 작업이고 다른 쪽은 요청마다 붙는 세금이다.

접근 권한. 대부분의 기업 아키텍처를 조용히 결정하는 항목이 이것이다. 사용자마다 볼 수 있는 문서가 다르다. 검색 시스템에서 권한은 조회 시점에 걸리는 필터다 — 텍스트가 모델에 닿기 «전»에 적용되는, 평범하고 감사 가능한 인가 경계. 통째로 넣는 시스템에서는 payload 를 조립할 때 권한 판단이 일어나야 하고, 한 번 실수하면 어떤 사용자의 기밀 문서가 다른 사용자의 프롬프트 «안»에 들어간다. 일단 창에 들어가면, 그 뒤의 어떤 통제도 그것을 안 본 것으로 만들지 못한다.

긴 컨텍스트가 «진짜로» 더 나은 자리

반대 방향의 오류는 «그러니 검색이 늘 이긴다»는 결론이다. 큰 창은 특정하고 점점 늘어나는 과제군에서 결정적으로 낫다.

산출물 «전체»에 대한 추론. 계약서 한 부를 통째로 요약하기, 코드베이스를 가로질러 버그 추적하기, 긴 문서 둘을 조항 단위로 비교하기. 청킹은 이런 과제가 의존하는 구조를 «적극적으로» 부순다. 질문이 전체의 «모양»에 관한 것이라면, 검색은 온전해야 했던 논증의 조각들을 건네줄 뿐이다.

에이전트 작업기억. 마흔 단계째 진행 중인 에이전트는 자기 이력을 지고 있다 — 도구 출력, 중간 추론, 읽은 파일들. 그것은 세션 «안»에서 쌓인 컨텍스트이고, 어떤 검색 색인도 갖고 있지 않다. 창이 커지면 에이전트가 이전 판단을 압축해야 하기 전까지 일할 수 있는 시간이 곧바로 늘어난다.

물량이 적고 판돈이 큰 정독. 하루에 수십 번 도는 작업이고 건당 비용보다 정확성이 훨씬 중요하다면, 다 넣어 버리는 단순함은 값을 치를 만하다. 모든 시스템에 색인이 필요한 것은 아니다.

실제로 이기는 구조

«둘 중 하나»로 놓으면 잘못된 이분법이다. 지금 가장 강한 패턴은 둘을 «순서대로» 쓴다.

넓게 검색하고, 넉넉하게 읽힌다. 검색으로 큰 말뭉치를 후보군으로 좁히되, 예전 시스템이 500토큰짜리 청크 세 개를 넘겼을 자리에서 «문서 스무 편 전문»을 넘긴다. 검색은 잘하는 일을 한다 — 접근 권한 아래에서, 출처를 온전히 유지한 채 «고르는 일». 긴 컨텍스트도 잘하는 일을 한다 — 인위적으로 조각내지 않은 자료 위에서의 «추론».

이것은 오래된 RAG 코드에 박혀 있던 전제를 뒤집는다. «창이 귀하니 청크는 작아야 한다»는 전제 말이다. 창은 더 이상 귀하지 않다. 청크는 «창 예산»이 아니라 «검색 품질»에 맞춰 자른다 — 대조가 정확해지는 입도로 검색한 다음, 프롬프트에 들어가기 전에 각 히트를 그 절 전체 혹은 문서 전체로 «펼친다».

예전보다 중요해진 작은 실무 둘도 있다. 순서를 의도적으로 정한다 — 위치 효과를 생각하면 점수가 높은 문단은 조립된 컨텍스트의 «가운데»가 아니라 «양 끝»에 놓여야 한다. 그리고 모든 문단에 출처 id 라벨을 붙인다 — 인용이 모델의 선의에 대한 부탁이 아니라 기계적 절차로 남게.

«맞는 부품»을 평가하기

여기서 낭비를 가장 많이 막아 주는 진단 습관이 하나 있다. 답이 틀렸을 때, 필요한 문서가 애초에 컨텍스트에 들어 있었는지부터 판정한다.

안 들어 있었다면 검색 단계가 실패한 것이고 모델을 아무리 바꿔도 안 고쳐진다. 들어 있었는데도 틀렸다면 그것은 생성 문제이고, 이제 창 크기·순서·프롬프트 구조 이야기가 비로소 유의미해진다. 종단 간 품질만 재는 시스템은 이 둘을 구분하지 못하고, 그런 시스템을 굴리는 팀은 망가진 색인을 고치려고 몇 달 동안 모델을 갈아 끼운다.

짧은 판본은 이렇다. 긴 컨텍스트는 «검색을 의무로 만들던 제약»을 없앴을 뿐, 검색해야 할 나머지 이유는 전부 있던 자리에 그대로 두었다. 대부분의 프로덕션 시스템은 둘 다 유지할 것이고, 흥미로운 설계 문제는 «검색할 것인가»에서 «검색한 뒤 모델에게 얼마나 건넬 것인가»로 옮겨 갔다.