긴 문맥은 RAG를 대체할까? 검색·문맥·기억의 역할

같은 문서를 넣었는데 다른 문제가 생기는 이유

팀의 제품 설명서 한 권을 읽고 변경 사항을 정리하는 작업과, 여러 부서가 매일 갱신하는 자료에서 특정 고객의 계약 조건을 찾는 작업을 생각해 보자. 둘 다 “문서를 넣고 질문한다”는 화면으로 보일 수 있다. 그러나 첫 작업에서는 설명서 전체의 관계가 중요하고, 둘째 작업에서는 지금 이 사용자에게 유효한 문서가 무엇인지부터 결정해야 한다.

이 차이를 빼고 입력 가능한 토큰 수만 비교하면 설계 판단이 흐려진다. 한 번에 넣을 수 있는 분량이 충분해도 오래된 계약서를 고르면 답이 틀릴 수 있다. 반대로 올바른 문서를 검색했어도 예외 조항이 다른 구간에 떨어져 있으면 답변에 빠질 수 있다. 문제의 위치가 다르므로 해결 방법도 달라진다.

이 글은 특정 제품의 우열을 비교하는 벤치마크가 아니다. 검색 증강 생성과 긴 문맥을 어떤 조건에서 조합할지 이해하기 위한 개념 해설이다. 아래 업무 사례와 선택표는 원리를 설명하기 위해 구성한 예시다.

검색·문맥·기억을 세 층으로 나눠 보기

문맥(context)은 이번 응답을 만들 때 모델에 제공되는 입력이다. 사용자 질문, 앞선 대화, 도구의 실행 결과, 검색으로 찾은 문서 등이 들어갈 수 있다. 문맥 창의 한도는 이 입력과 생성 과정에서 사용할 수 있는 토큰 범위를 제한한다. 정확한 입력·출력 한도와 계산 방식은 제품별로 확인해야 한다.

검색(retrieval)은 보관된 자료에서 현재 질문에 관련된 부분을 찾는 과정이다. 검색 결과를 생성 모델의 입력과 연결하면 RAG를 구성할 수 있다. 초기 RAG 논문은 모델의 매개변수에 담긴 지식과 외부 검색 자료를 결합하는 구조를 제시했다. 오늘날의 모든 RAG 구현이 그 논문과 같은 학습 방식이나 검색기를 쓰는 것은 아니다.

장기 기억(memory)은 대화가 끝난 뒤에도 다음 작업에서 다시 사용할 정보를 보관하고 꺼내는 체계다. 파일, 데이터베이스, 사용자 설정, 요약, 검색 인덱스 등 여러 방식이 가능하다. 저장한 정보가 다음 호출의 문맥에 들어가야 모델이 그 정보를 사용할 수 있다. 단순히 저장소가 있다는 사실과 모델이 필요한 기억을 정확히 꺼냈다는 사실은 다르다.

층	주된 질문	실패를 찾을 위치
보관·기억	무엇을 남기고 언제 지울까?	오래된 요약, 누락된 정보, 잘못 연결된 사용자
검색·선택	이번 질문에 무엇을 가져올까?	필터, 순위, 문서 버전, 권한, 검색 누락
문맥 구성	가져온 자료를 어떻게 배치할까?	조각 간 관계, 중복, 출처 표시, 토큰 예산
생성·해석	주어진 근거로 무엇을 말할까?	단위·예외 해석, 근거 밖 추정, 인용 불일치

이 구분은 장애를 찾을 때 유용하다. “기억을 못 한다”는 하나의 표현이 실제로는 저장 실패, 검색 실패, 입력 누락, 해석 실패를 모두 가리킬 수 있기 때문이다.

긴 문맥이 줄여 주는 일, 남겨 두는 일

문서를 통째로 넣을 수 있으면 잘라 놓은 조각의 앞뒤를 다시 붙이는 일이 줄어든다. 예외 조항, 표의 각주, 장 사이의 논증을 함께 읽혀야 하는 질문에서 이점이 있을 수 있다. 작은 문서 묶음이라면 검색 인덱스를 만들고 갱신하는 운영 자체를 생략할 수도 있다.

그렇다고 입력에 들어갔다는 사실이 정확히 활용됐다는 보장은 아니다. Lost in the Middle은 당시 평가한 모델과 과제에서 관련 정보의 위치에 따라 성능이 달라질 수 있음을 보였다. 이는 긴 입력을 평가할 때 위치와 방해 자료도 바꿔 봐야 한다는 근거다. 2023년 결과를 현재 모든 모델의 실패율이나 능력 한계로 그대로 읽어서는 안 된다.

또한 긴 문맥은 자료의 소유권을 판단하거나 최신 버전을 자동으로 보장하지 않는다. 모든 문서를 넣는 방식에서도 사용자별 접근 제한과 유효 기간 처리가 필요하다. 권한 없는 문서를 일단 모델에 전달한 다음 “이 내용은 답하지 말라”고 지시하는 것은, 입력 단계에서 접근을 제한하는 설계와 같지 않다.

비용도 입력 길이 하나로 결정되지 않는다. 캐시 적용, 반복 질문, 출력 길이, 검색 서버 운영비, 응답 시간 요구를 함께 봐야 한다. 어떤 구성이 더 싼지 단정하려면 같은 업무와 품질 기준으로 실제 사용량을 기록해야 한다.

검색을 쓴다면 조각이 잃어버리는 맥락을 복원해야 한다

“전년 대비 12% 증가했다”는 문장만 검색 결과에 들어오면 무엇의 증가인지 알 수 없다. 문서 제목과 절 제목을 붙이면 대상이 보이고, 표의 단위와 각주까지 붙이면 숫자의 의미를 해석할 수 있다. 잘게 나누는 것만으로 검색 품질이 좋아지지는 않는다.

Anthropic의 Contextual Retrieval 설명은 문서 조각의 맥락을 보강하는 접근을 다룬다. 여기서 가져올 설계 질문은 “이 조각을 문서 밖에서 읽어도 대상을 이해할 수 있는가”다. 공급자가 보고한 개선 수치를 우리 자료나 다른 모델의 예상 개선율로 사용하지 않는다.

예를 들어 자체 문서 인덱스에는 다음 정보를 함께 관리할 수 있다. 이는 범용 필수 스키마가 아니라 설계 출발점이다.

document_id : 문서의 안정적인 식별자
version     : 이번 내용의 버전
section     : 제목과 절의 경로
valid_from  : 적용 시작일
access_group: 읽을 수 있는 사용자 집단
chunk_text  : 검색·응답에 사용할 내용

문서가 바뀌면 본문만 교체할지, 옛 조각을 제거할지, 이전 버전을 별도 보관할지 결정해야 한다. 새 조각과 옛 조각이 동시에 검색되면 모델이 서로 다른 시점의 주장을 섞을 수 있다. 이 문제는 문맥 창을 넓히는 것만으로 해결되지 않는다.

구조를 고르는 네 가지 질문

다음 표는 제품 추천이 아닌 편집상 선택 기준이다. 실제 성능은 사용하려는 자료와 질문으로 확인해야 한다.

상황	먼저 검토할 구성	반드시 확인할 점
분량이 제한된 보고서의 전체 논증을 분석	전체 문서 입력	문서 위치·표·각주를 바꿔도 답이 유지되는가
여러 문서에서 좁은 사실을 반복 조회	검색 후 관련 구간 입력	정답 근거가 검색 후보에 들어오는가
사용자별 자료 접근 권한이 다름	권한을 반영한 자료 선택	검색·캐시·로그에서 권한이 섞이지 않는가
검색 결과가 너무 잘게 끊겨 관계를 놓침	검색 후 주변 구간이나 문서 확장	확장이 중복·비용·잡음을 얼마나 늘리는가
자료가 적지만 자주 바뀜	단순 전체 입력부터 비교	최신 사본과 캐시 무효화를 보장하는가
과거 대화의 선호를 다음 작업에 활용	명시적 기억 저장과 선택	사용자가 수정·삭제할 수 있고 출처를 알 수 있는가

핵심은 “긴 문맥 또는 RAG”라는 양자택일을 먼저 하지 않는 것이다. 검색으로 후보 문서를 좁힌 뒤 여러 문서를 긴 문맥에 넣거나, 첫 답변에 근거가 부족하면 추가 검색하는 방식도 가능하다. 다만 단계가 늘수록 관측해야 할 지점과 운영 비용도 늘어난다.

평가도 검색과 답변을 분리한다

가령 “2025년 계약에 적용되는 해지 통보 기간은?”이라는 질문에 답하려면, 정답 문서와 정답 구간을 먼저 정해야 한다. 이후 최소한 다음을 따로 기록한다.

1. 올바른 버전의 문서가 수집·추출됐는가.
2. 권한 필터를 통과한 검색 결과에 정답 구간이 있는가.
3. 최종 입력에 그 구간과 필요한 예외가 들어갔는가.
4. 답변이 그 근거의 적용 시점·대상·단위를 지켰는가.

검색 후보에 근거가 없는데 생성 모델만 교체하면 실패 원인을 확인하기 어렵다. 반대로 정답 구간이 들어왔는데도 틀렸다면 검색 순위 외에 문맥 배치와 질문 해석을 살펴볼 이유가 생긴다. 답변 정확도라는 마지막 숫자 하나로 모든 단계를 평가하면 어느 부분을 고칠지 알기 어렵다.

실제 평가셋에는 정답이 없는 질문, 옛 버전과 새 버전이 충돌하는 질문, 접근 권한이 없는 질문도 포함할 수 있다. 이때 정답은 항상 긴 설명이 아니다. 근거 부족을 알리거나 접근을 거절하는 것이 맞는 경우를 미리 정의해야 한다.

다시 읽을 때 남길 기준

긴 문맥은 많은 자료를 함께 해석할 여지를 준다. 검색은 그 자료를 선택하고 갱신·권한의 경계를 연결한다. 기억은 다음 작업에 남길 정보를 관리한다. 이 세 층이 맡는 일을 먼저 나누면 새 모델의 문맥 한도가 발표돼도 무엇을 바꾸고 무엇을 유지할지 판단하기 쉬워진다.

이 글은 개념과 설계 기준을 정리했으며, 특정 모델·벡터 데이터베이스·한국어 문서 묶음에서 비교 실험을 하지 않았다. 적용 전에는 자신의 정답셋과 운영 조건으로 비용·지연·근거 정확도를 함께 확인해야 한다.