RAG로 만든 제품이 데모에서는 멀쩡하다가 실사용에서 무너지는 순간은 대개 비슷하게 생겼다. 사용자가 조금 복잡한 질문을 던지면, 시스템은 질문과 표면적으로 닮은 문단 몇 개를 그럴듯하게 물어와 붙이고, 모델은 그 위에서 자신 있게 틀린 답을 만든다. 문제는 모델이 거짓말을 하는 게 아니라, 검색이 애초에 '참’이 아니라 '비슷한 문단’을 골라줬다는 데 있다. 답의 품질을 논하기 전에 검색의 품질을 의심해야 하는 이유다.
검색이 아니라 구조가 문제다
표준 RAG의 첫 번째 죄는 문서를 청크로 잘게 부수는 순간에 저질러진다. 500토큰짜리 조각으로 문서를 평평하게 펴면, 헤딩·문서 경계·표의 행열 관계처럼 사람이 의미를 읽어내는 데 쓰던 구조적 단서가 통째로 버려진다. 검색은 그 조각들을 벡터 유사도로만 비교하니, "이 조항이 저 조항의 예외"라거나 "이 수치는 3분기 한정"이라는 관계는 검색 단계에서 이미 사라진다.
여러 서베이가 RAG 파이프라인에서 가장 빈번한 실패 지점으로 생성이 아니라 검색 단계를 꼽는 이유가 여기 있다. 검색 결과에 노이즈가 섞이거나 정작 필요한 조각이 빠지면, 그 뒤 모델이 아무리 좋아도 손쓸 도리가 없다. 잘못된 재료로 만든 요리다. 그런데도 대부분의 개선 노력은 프롬프트와 모델에 쏠린다. 정작 무너지는 곳은 그 앞이다.
"긴 컨텍스트가 RAG를 죽였다"는 절반만 맞다
100만 토큰 컨텍스트 창이 등장하자 "이제 문서를 통째로 넣으면 되지, 검색이 왜 필요하냐"는 주장이 나왔다. 단순 사실 검색에서는 일리가 있다. 건초 더미에서 바늘 찾기(NIAH) 같은 단일 사실 회수 과제에서 최신 모델들은 100만 토큰을 넣어도 99% 수준의 회수율을 보인다.
하지만 실무의 질문은 대개 단일 사실 회수가 아니다. 여러 문서를 교차 참조하는 멀티홉 추론이나 흩어진 값을 모아 합산하는 집계 과제로 가면, 정확도는 대략 32k~128k 토큰 구간 어딘가에서 급격히 꺾인다. 게다가 정작 필요한 정보가 컨텍스트 앞이나 뒤가 아니라 중간에 놓이면 정확도가 10~20%포인트 넘게 떨어지는 ‘중간이 사라지는(lost in the middle)’ 현상이 잘 알려져 있다. 모델은 처음과 끝을 편애한다.
비용도 무시할 수 없다. 벤치마크에 따르면 100만 토큰짜리 요청은 잘 짜인 RAG 파이프라인보다 응답이 30~60배 느리고, 쿼리당 비용은 1,000배가 넘게 벌어진다. 긴 컨텍스트는 검색을 죽인 게 아니라, "언제 통째로 넣고 언제 골라 넣을지"라는 라우팅 문제를 새로 던졌을 뿐이다.
그래서 그래프를 얹으면?
구조가 문제라면 구조를 복원하면 된다 — 이 직관에서 GraphRAG가 나왔다. 문서를 청크가 아니라 엔티티와 관계의 그래프로 재구성하면, "이 회사의 자회사가 소유한 특허"처럼 여러 홉을 건너야 하는 질문에 강해진다. 방향은 맞다. 하지만 유행을 그대로 따라 하면 새로운 함정에 빠진다.
첫째, 그래프 구축 자체가 비싸다. 문서가 시시각각 바뀌는 환경에서 매번 그래프를 다시 짜는 비용은 만만치 않다. 둘째, 대부분의 연구가 검색 정책에만 매달리고 그래프를 어떻게 조직하느냐는 덜 본다. 그래프가 커지면 검색이 밀도 높은 덩어리 안에만 머물며 덩어리 사이를 건너뛰지 못해, 정작 멀리 있는 답을 못 찾는 일이 생긴다. 구조를 얹었다고 저절로 똑똑해지지 않는다. 어떤 구조를, 무엇을 위해 얹느냐가 전부다.
처방: 검색을 믿기 전에 구조와 검증을 넣어라
소규모 팀이 여기서 뽑아야 할 실용 노선은 세 가지다.
- 청크 전에 구조를 남겨라. 문서를 자르기 전에 헤딩·표·문서 경계 같은 구조를 메타데이터로 붙여두면, 벡터 유사도만으로는 못 잡는 "어디에 속한 조각인가"를 검색에 되돌려줄 수 있다. 온톨로지 한 겹은 이 지점에서 값을 한다 — 무엇이 무엇의 예외이고 무엇이 무엇에 속하는지를 검색이 알게 만든다.
- 검색을 한 번에 믿지 마라. 정적 파이프라인 대신, 결과를 보고 다시 질의하고 부족하면 다른 각도로 다시 찾는 에이전틱 검색은 멀티홉에서 확실히 강하다. 다만 반복은 비용과 지연, 그리고 폭주 가능성을 함께 데려온다. 몇 번 돌지, 언제 멈출지를 반드시 못 박아라.
- 권한과 검증을 검색 안으로 끌어와라. 에이전트가 사용자를 대신해 문서를 뒤질 때는 그 사용자와 똑같은 접근 권한 안에 갇혀야 한다. 그리고 RAG는 물어온 정보가 절차적으로 맞는지까지는 판단하지 못한다. 검색 결과를 답으로 넘기기 전에 "이게 정말 이 질문의 근거가 되나"를 한 번 검증하는 단계가 붙어야, 자신 있게 틀리는 사고를 줄인다.
결국 RAG의 한계는 검색이라는 기술의 한계가 아니라, 지식을 구조 없이 다뤘을 때의 한계다. 청크는 관계를 모르고, 벡터는 참과 거짓을 구분하지 못한다. 남들보다 앞서는 팀은 더 큰 컨텍스트 창을 기다리는 팀이 아니라, 자기 도메인의 지식을 검색이 이해할 수 있는 구조로 먼저 정리해 둔 팀이다. 물어오는 것과 아는 것은 다르다. 그 차이를 좁히는 일이 지금 남은 진짜 엔지니어링이다.