사람들은 RAG의 부고를 쓰고 있습니다. 아마 이미 관련 헤드라인을 보셨을 겁니다. 긴 컨텍스트 윈도우가 RAG를 죽였다거나, 에이전트가 이를 대체했다거나, 이제 이 패턴은 구식이라는 식의 이야기들 말이죠. 하지만 진실은 훨씬 더 좁고 훨씬 더 유용합니다. RAG는 죽지 않았습니다. 실제로 무너진 것은, 문서 더미를 청크로 나누어 벡터 데이터베이스에 넣기만 하면 갑자기 신뢰할 수 있고 진실된 AI를 소유할 수 있다는 안일한 환상이었습니다.
몇 년 전만 해도 그 제안은 단순해서 매력적이었습니다. 지식 베이스를 임베딩하고, 이를 LLM에 연결합니다. 질문을 던지면 모델이 검색된 데이터만을 사용하여 답변하는 것을 지켜보기만 하면 되었죠. 통제된 데모나 소규모 FAQ 봇의 경우에는 솔직히 이 방식이 잘 작동했습니다. 20페이지 분량의 헬프 데스크 매뉴얼이나 깔끔하게 정리된 내부 위키 같은 것들 말입니다. 봇은 대략적으로 맞는 단락을 인용했고, 경영진은 파일럿 프로젝트를 승인했습니다. 하지만 파일럿은 프로덕션이 아닙니다. 프로토타입에는 실제 비즈니스 운영의 고충이 담겨 있지 않습니다.
프로덕션 데이터는 지저분합니다. 수십 개의 파일에 걸쳐 복사된 동일한 문제 해결 노트가 존재하며, 각 노트는 미세하게 다른 타임스탬프와 충돌하는 상태 라벨을 가지고 있습니다. 페이지를 가로지르는 복잡한 표들은 스플리터(splitter)가 중간에 잘라버리면 엉망인 데이터를 만들어냅니다. 또한 아무런 사과도 없이 모순을 그대로 유지하기도 합니다. 2023년 정책 매뉴얼은 이렇게 말하는데, 2024년 3월 개정안은 저렇게 말할 수 있습니다. 오래된 PDF는 아카이브되지 않은 채 남아있기도 하죠. '청크, 저장, 검색'이라는 순진한 패턴은 모든 문단을 고립된 섬처럼 취급합니다. 계층 구조, 버전 이력, 또는 충돌 해결에 대한 감각이 전혀 없습니다. 모델이 환각을 일으키는 이유는 LLM이 고장 나서가 아니라, 전달받은 컨텍스트가 파편화되었거나, 출처를 잃었거나, 혹은 아예 틀렸기 때문입니다.
어떤 관찰자들은 수백만 토큰의 컨텍스트 윈도우가 검색을 무의미하게 만든다고 주장합니다. 그들의 논리는 간단합니다. 전체 코퍼스를 프롬프트에 통째로 집어넣고 모델이 전부 읽게 하면 된다는 것입니다. 이는 우아하게 들리지만, 위험할 정도로 낙관적인 생각입니다. 모델이 기술적으로 짧은 소설 한 권 분량의 텍스트를 소화할 수 있다고 해도, 그 방대한 범위의 중간에서 특정 조항 하나를 찾아내는 것은 완전히 다른 차원의 능력입니다. 건초더미 속의 바늘 문제는 여전합니다. 긴 컨텍스트 윈도우는 사용할 수 있는 캔버스를 넓혀주지만, 그 캔버스 위에 무엇을 그려 넣을지 결정하는 어려운 과제를 해결해주지는 않습니다. 문제는 단순히 검색이 아니었습니다. 문제는 언제나, 그리고 앞으로도 컨텍스트를 어떻게 구성(assembly)하느냐에 있습니다.
단순 검색에서 컨텍스트 엔지니어링으로
2026년, 이 분야는 성숙해지고 있습니다. 우리는 RAG를 단일 선형 파이프라인으로 취급하던 단계를 지나, 컨텍스트를 정교하게 설계된 제품으로 다루는 아키텍처로 나아가고 있습니다.
순수 시맨틱을 넘어선 하이브리드 검색. 시맨틱 유사성은 의도를 파악하는 데는 탁월하지만, 정확한 식별자에는 취약합니다. 만약 엔지니어가 ERR_CONNECTION_REFUSED와 같은 특정 에러 코드나 v3.2.1과 같은 소프트웨어 버전을 쿼리한다면, 순수 벡터 검색은 개념적으로는 비슷하지만 실제로는 무관한 결과들의 바다 속에서 정확한 일치 항목을 희석시킬 수 있습니다. 여기서의 진화는 명확합니다. 현대적인 시스템은 임베딩과 함께 BM25나 역색인(inverted index) 같은 방법을 사용하여 밀집 벡터 검색(dense vector retrieval)과 키워드 검색을 결합합니다. 정확한 이름, 에러 코드, 버전 문자열, 제품 ID는 키워드 레이어에서 포착되고, 개념적인 뉘앙스는 벡터 레이어에서 처리됩니다.
생성 전 리랭킹(Reranking). 검색은 본질적으로 재현율(recall)에 치우쳐 있습니다. 단 하나의 결정적인 문단을 놓칠까 봐 두려워 마흔 개나 쉰 개의 청크를 끌어오게 됩니다. 하지만 이 모든 노이즈를 대형 모델에 입력하는 것은 토큰을 낭비하고 핵심 신호(signal)를 묻어버리는 일입니다. 리랭킹은 두 번째의, 대개 더 작은 모델을 사용하여 각 후보가 특정 쿼리와 얼마나 관련이 있는지 점수를 매김으로써 이 문제를 해결합니다. 상위 5개의 구절만 통과시키고 나머지는 버립니다. 이는 검색과 생성 사이에서 정밀 필터 역할을 하여, 비용이 많이 드는 추론 모델이 실제로 중요한 내용만 읽도록 보장합니다.
의미를 보존하는 컨텍스트 검색. 청킹은 파괴적인 작업입니다. 스플리터는 문단을 섹션 헤더, 표 캡션, 주변의 법적 고지 사항, 또는 의미를 수정하는 각주로부터 잘라버릴 수 있습니다. 컨텍스트 검색은 파편이 모델에 도달하기 전에 메타데이터를 추가하여 이를 완화합니다. 예를 들어, 다음과 같이 출처(provenance)를 나타내는 정보를 앞에 붙입니다: 이 발췌문은 2024년 3분기 장애 보고서의 '데이터베이스 중단' 섹션에 속하며, 심각도는 '치명적'임. 모델은 단순히 떠다니는 문장이 아니라, 맥락이 부여된 정보를 보게 됩니다. 이를 통해 파편은 자신의 위치를 되찾습니다.
의도에 따른 모듈형 라우팅. 모든 질문이 문서로 가득 찬 벡터 스토어에 속하는 것은 아닙니다. 비밀번호 재설정 방법을 묻는 사용자에게는 아마도 도움말 문서가 필요할 것입니다. 지난 분기 북동부 지역의 매출이 왜 감소했는지 묻는 사용자에게는 지역 판매 전략에 관한 의미론적으로 유사한 문단이 아니라, 데이터 웨어하우스에 대한 SQL 쿼리가 필요합니다. 성숙한 시스템은 이제 의도에 따라 쿼리를 라우팅하여 적절한 도구를 선택합니다. 절차를 위한 문서. 구조화된 분석을 위한 관계형 데이터베이스. 트레이스 디버깅을 위한 로그 애그리게이터. 실시간 상태 확인을 위한 API. 검색 레이어는 획일화된 구조가 아닌 디스패처가 됩니다.
에이전트식 추론 루프. 어떤 질문들은 단 한 번의 검색 단계로 답할 수 없습니다. 재구성이 필요합니다. 모호한 초기 쿼리는 명확해집니다. 검색된 주장은 두 번째 소스와 대조하여 교차 검증됩니다. 만약 문서가 API 명세와 충돌한다면, 시스템은 중간 지점을 꾸며내는 대신 충돌을 알립니다. 모델은 언제 다시 검색할지, 언제 쿼리를 정교화할지, 그리고 답변을 위한 충분한 증거를 수집했는지를 스스로 결정합니다. 이것은 원샷(one-shot) 검색이 아닙니다. 검색을 서브루틴으로 사용하는 구조화된 추론입니다.
관계형 질문을 위한 GraphRAG. 특정 비즈니스 질문은 문장이 아니라 연결에 관한 것입니다. 어떤 컴포넌트의 장애가 어떤 다운스트림 알람을 유발했는가? 어떤 공급업체가 어떤 공장에 원자재를 공급하며, 대체 경로는 무엇인가? 조직 내에서 이 특정 예산 항목에 대해 의사 결정권을 가진 사람은 누구인가? 평면적인 텍스트 청크는 이러한 관계를 평면화합니다. 토폴로지(topology)를 보존하도록 설계되지 않았기 때문입니다. 지식 그래프(Knowledge graphs)는 이를 수행합니다. 질문이 영향력, 계보(lineage), 패턴 또는 네트워크 구조에 관한 경우, 그래프를 탐색하는 것은 그 어떤 문단 검색으로도 복제할 수 없는 컨텍스트를 제공합니다.
실제로 중요한 질문들
RAG에 관한 논의는 변해야 합니다. 범용적인 RAG 파이프라인을 구축하는 방법은 그만 물으십시오. 모델이 해결해야 할 구체적인 작업이 무엇인지, 정확도를 위해 어떤 정확한 데이터가 필요한지, 그리고 구성된 컨텍스트가 충분한지 어떻게 검증할지를 묻기 시작하십시오. 이러한 질문들은 여러분을 데이터 품질, 스키마 설계, 검증 루프, 소스 출처(provenance)와 같은 상위 단계로 이끕니다. 또한 여러분의 지식 베이스가 자동화된 소비에 적합한지 여부를 드러냅니다.
RAG는 더 이상 한 번 설치하고 잊어버리는 단일 선형 프로세스가 아닙니다. 모델이 효과적으로 추론할 수 있도록 적절한 컨텍스트를 구성하는 규율(discipline)입니다. 이는 검색을 라이브러리 임포트가 아닌 시스템 설계 문제로 다루어야 함을 의미합니다.
도구들은 점점 더 정교해지고 있습니다. 검색은 하이브리드 방식입니다. 라우팅은 지능적입니다. 검색 결과는 순위가 매겨지고, 풍부해지며, 검증됩니다. 진정으로 유용한 것이 그 자리를 대신할 수 있도록 2022년의 단순한 환상들은 무너져야 했습니다. 이제 여러분의 일은 단순히 데이터베이스에서 텍스트를 검색하는 것이 아닙니다. 모델이 생각을 시작하기 전에 모델에게 무엇이 필요한지 아는 시스템을 구축하는 것입니다.
이 분야에서 작업하고 있다면, GyaanSetu 학습 커뮤니티는 동일한 문제를 해결하는 사람들과 실질적인 노하우를 나눌 수 있는 곳입니다: https://t.me/GyaanSetuAi
