100만 토큰 시대에도 RAG가 필요한가

최근 나온 모델들은 한 번에 100만 토큰 분량을 읽을 수 있습니다. 책 여러 권에 해당하는 양입니다. 그러다 보니 이런 질문을 자주 받습니다. "문서를 전부 넣으면 되는데, 검색 시스템(RAG)을 따로 만들 필요가 있나요?"

답은 문서의 양과 쓰임새에 따라 다르다입니다.

먼저 용어 정리

• RAG: 질문이 들어오면 관련 있는 문서 조각을 먼저 찾아서, 그것만 AI에게 주고 답하게 하는 방식입니다.
• 긴 컨텍스트: 문서를 통째로 AI에게 주고 답하게 하는 방식입니다.

통째로 넣는 편이 나은 경우

• 문서가 많지 않을 때: 사규 몇 개, 제품 설명서 몇 권 수준이라면 검색 시스템을 만드는 것이 과합니다.
• 문서 전체를 이해해야 하는 질문일 때: "이 계약서에서 우리에게 불리한 조항은?" 같은 질문은 조각을 찾아서는 답하기 어렵습니다.
• 빨리 시작해야 할 때: 만들 것이 적어서 며칠 안에 시험해 볼 수 있습니다.

그래도 RAG가 필요한 경우

문서가 계속 늘어날 때

사내 문서는 100만 토큰을 금방 넘습니다. 몇 년 치 회의록, 기술 문서, 고객 문의 기록을 전부 넣을 수는 없습니다.

비용과 속도가 중요할 때

질문할 때마다 책 몇 권을 읽히면 그만큼 비용이 들고 응답이 느려집니다. 하루에 수천 번 질문이 들어오는 서비스라면 차이가 큽니다.

권한이 다를 때

직원마다 볼 수 있는 문서가 다르다면, 질문한 사람이 볼 수 있는 문서만 찾아서 넣어야 합니다. 통째로 넣는 방식으로는 이것을 지킬 수 없습니다.

근거를 보여 줘야 할 때

"이 답은 어느 문서의 어느 부분에서 나왔다"를 보여 주려면, 어떤 조각을 썼는지 추적되는 구조가 유리합니다.

실무에서의 선택

상황	권하는 방식
문서 수십 개, 사용자 소수	통째로 넣기
문서 수천 개 이상	RAG
부서별 접근 권한이 다름	RAG
긴 문서 한 건을 깊이 분석	통째로 넣기

둘을 섞는 방법도 많이 씁니다. 검색으로 관련 문서를 고르되, 조각이 아니라 문서 전체를 넣는 식입니다. 컨텍스트가 넉넉해진 덕분에 조각을 잘게 쪼개느라 맥락을 잃던 문제가 줄었습니다.

어느 쪽이든 공통으로 필요한 것

방식보다 결과를 좌우하는 것은 문서의 상태입니다. 최신 버전이 무엇인지 알 수 없고, 같은 내용이 여러 파일에 다르게 적혀 있으면 어떤 방식으로도 좋은 답이 나오지 않습니다. 시스템을 고르기 전에 문서 정리부터 하는 것이 가장 효과가 큽니다.