문서, 표, 이미지, 도면이 뒤섞인 질문에 단순히 상위 5개 문서를 넣는 것만으로 정확한 답을 얻을 수 있을까요?
전통적인 RAG는 보통 다음 순서로 동작합니다.
질문 입력 → 관련 청크 검색 → 상위 k개 컨텍스트 삽입 → LLM 답변 생성
이 방식은 간단한 문서 질의에는 빠르고 효율적입니다. 하지만 실제 업무 데이터는 훨씬 복잡합니다. 하나의 규정은 본문과 예외 조항으로 나뉘고, 핵심 수치는 표에 있으며, 설치 조건은 도면에만 표시될 수 있습니다. 이미지 속 그래프와 텍스트 설명이 서로 다른 결론을 암시하는 경우도 있습니다.
이때 단순 벡터 유사도 검색은 중요한 한계를 드러냅니다. 질문과 문장 표현이 비슷한 청크를 찾을 수는 있어도, 서로 떨어진 정보 조각이 어떤 관계를 맺는지까지 충분히 판단하기는 어렵습니다. 상위 5개 결과가 모두 비슷한 문단일 수 있고, 정작 답변에 필요한 표·주석·이미지 캡션은 검색에서 밀려날 수 있습니다.
단순 RAG 검색이 놓치는 정보
예를 들어 사용자가 다음과 같이 질문한다고 가정해 보겠습니다.
“이 설비는 고온 환경에서 어떤 설치 조건을 충족해야 하며, 허용 오차는 얼마인가?”
정확한 답을 만들려면 하나의 문서만으로는 부족할 수 있습니다.
- 본문에는 고온 환경의 정의가 있습니다.
- 표에는 온도 구간별 허용 오차가 있습니다.
- 도면에는 설치 간격과 방향 조건이 있습니다.
- 부록에는 특정 모델에만 적용되는 예외 규정이 있습니다.
기존 RAG가 이 자료를 각각 독립적인 청크로 검색하면, 모델은 필요한 근거를 일부만 받게 됩니다. 그 결과 그럴듯하지만 불완전한 답변, 또는 서로 다른 조건을 섞은 답변이 나올 위험이 커집니다.
문제는 검색 결과의 개수보다 컨텍스트의 연결성입니다. 좋은 RAG는 많이 가져오는 시스템이 아니라, 질문에 필요한 증거를 서로 연결해 가져오고 부족한 부분을 다시 확인하는 시스템에 가깝습니다.
한 번 찾고 끝내지 않는 RAG의 등장
2026년 RAG의 핵심 변화는 검색을 단발성 단계가 아니라 반복적으로 정교화하는 과정으로 본다는 데 있습니다.
초기 검색에서 넓은 범위의 후보를 확보한 뒤, 시스템은 다음과 같은 질문을 다시 던집니다.
- 현재 근거만으로 답변이 가능한가?
- 표나 이미지에 핵심 정보가 빠져 있지는 않은가?
- 서로 충돌하는 수치 또는 조건은 없는가?
- 특정 예외 조항을 추가로 확인해야 하는가?
- 답변을 뒷받침하는 출처가 충분히 신뢰할 수 있는가?
이 판단을 바탕으로 RAG는 추가 검색, 재순위화, 불필요한 컨텍스트 제거를 수행합니다. 즉, 검색 → 평가 → 재검색 → 컨텍스트 재구성 → 생성의 루프를 갖게 됩니다.
이러한 접근은 Agentic RAG, Self-RAG, Corrective RAG 같은 흐름과 맞닿아 있습니다. 핵심은 LLM이 처음 검색된 결과를 무비판적으로 받아들이지 않고, 답변에 필요한 정보가 충분한지 스스로 점검하도록 만드는 것입니다.
하이퍼그래프와 멀티모달 RAG가 바꾸는 검색의 기준
최근 주목받는 하이퍼그래프 기반 멀티모달 RAG는 이 문제를 더욱 구조적으로 다룹니다. 일반적인 그래프가 두 노드 사이의 관계를 표현한다면, 하이퍼그래프는 하나의 관계가 여러 요소를 동시에 묶을 수 있습니다.
가령 다음 요소들은 하나의 복합 관계로 연결될 수 있습니다.
- 규정 문서의 특정 조항
- 해당 조항을 설명하는 표
- 설치 예시가 담긴 이미지
- 관련 제품의 기술 사양서
- 같은 개념을 참조하는 외부 표준 문서
이 구조에서는 “질문과 가장 유사한 문장”만 찾는 것이 아니라, 질문과 관련된 개념 주변에 어떤 텍스트·표·이미지·문서가 함께 연결되는지 탐색할 수 있습니다.
여기에 단계적 컨텍스트 정교화가 더해지면 흐름은 더욱 강력해집니다.
- 질문과 관련된 문서 및 멀티모달 후보를 넓게 검색합니다.
- 텍스트, 표, 이미지, 도면 사이의 관계를 분석합니다.
- 답변에 부족한 조건이나 충돌하는 근거를 식별합니다.
- 하이퍼그래프 연결을 따라 추가 자료를 검색하거나 불필요한 자료를 제거합니다.
- 정리된 근거를 바탕으로 최종 답변을 생성합니다.
이 방식은 특히 표와 도면이 중요한 제조, 의료, 법률, 금융, 엔터프라이즈 지식관리 환경에서 의미가 큽니다. 텍스트만 읽어서는 답할 수 없는 질문을 다루기 위해서는, 검색 대상 자체가 문단을 넘어 문서 구조와 시각 정보까지 확장되어야 하기 때문입니다.
핵심은 ‘더 많은 문서’가 아니라 ‘더 나은 근거’다
RAG의 다음 단계는 단순히 검색 결과 수를 늘리는 것이 아닙니다. 컨텍스트 창에 문서를 많이 넣는다고 해서 정확도가 자동으로 높아지지는 않습니다. 오히려 중복 정보와 무관한 청크가 늘어나면 모델은 중요한 근거를 놓치거나 서로 다른 조건을 혼동할 수 있습니다.
앞으로의 RAG는 다음 세 가지를 중심으로 설계될 가능성이 높습니다.
- 관계 중심 검색: 문서, 엔티티, 표, 이미지 간 연결을 함께 고려합니다.
- 멀티모달 이해: 텍스트뿐 아니라 표·차트·도면·페이지 레이아웃을 근거로 활용합니다.
- 점진적 검증: 한 번의 검색 결과에 의존하지 않고, 부족한 정보를 찾아 컨텍스트를 반복적으로 개선합니다.
결국 정확한 답변은 첫 번째 검색 결과에서 완성되지 않습니다. 좋은 RAG는 답을 서두르지 않고, 필요한 근거가 충분히 모일 때까지 질문을 다시 해석하고 검색 전략을 조정합니다.
RAG에서 그래프보다 한 단계 복잡한 연결: 하이퍼그래프의 등장
하나의 규정 문서가 특정 조항, 여러 개의 표, 관련 도면, 외부 법령을 동시에 가리킨다면 어떨까요? 두 노드 사이의 연결만 표현하는 일반 그래프로는 이 관계를 충분히 담아내기 어렵습니다. 각각의 연결을 여러 개의 엣지로 쪼갤 수는 있지만, 원래 하나였던 맥락이 분산되면서 “무엇이 함께 의미를 이루는가”가 흐려질 수 있습니다.
이 지점에서 하이퍼그래프(Hypergraph)가 등장합니다.
일반 그래프의 엣지는 보통 두 노드만 연결합니다. 반면 하이퍼그래프의 하이퍼엣지(hyperedge) 는 세 개 이상의 노드를 한 번에 묶을 수 있습니다. 즉, 하나의 규정 조항과 그 조항을 설명하는 표, 예외 상황을 보여 주는 도면, 참조해야 할 외부 법령을 하나의 관계 단위로 연결할 수 있습니다.
간단히 비교하면 다음과 같습니다.
- 일반 그래프:
규정 문서 ↔ 조항,조항 ↔ 표,조항 ↔ 도면처럼 관계를 쌍으로 나눠 표현 - 하이퍼그래프:
규정 문서 + 조항 + 표 + 도면 + 외부 법령을 하나의 의미 단위로 연결
이 차이는 복잡한 기업 문서나 전문 지식 환경에서 특히 중요합니다. 법률, 의료, 금융, 제조 설계 문서에는 텍스트만으로 해석할 수 없는 정보가 많습니다. 표의 수치, 도면의 구조, 이미지 속 주석, 다른 문서의 예외 조항이 함께 고려되어야 정확한 답을 만들 수 있습니다.
RAG 관점에서 하이퍼그래프는 단순히 “질문과 비슷한 문서”를 찾는 방식을 넘어섭니다. 질문과 관련된 문서를 검색한 뒤, 그 문서와 연결된 표·이미지·엔티티·참조 자료를 함께 탐색할 수 있기 때문입니다. 예를 들어 사용자가 “이 규정에서 특정 조건이 적용되는 범위와 예외는 무엇인가?”라고 질문하면, 시스템은 본문 조항만 가져오는 데 그치지 않습니다. 관련 표의 기준값, 도면의 적용 구역, 외부 법령의 예외 조항까지 하나의 연결 구조 안에서 확인할 수 있습니다.
이 구조가 중요한 이유는 검색 결과의 맥락 보존에 있습니다. 기존 벡터 검색은 의미적으로 유사한 청크를 빠르게 찾는 데 강점이 있지만, 서로 다른 자료가 왜 함께 필요한지까지 항상 설명하지는 못합니다. 하이퍼그래프는 자료 간의 공동 관계를 모델링하므로, RAG 시스템이 더 정교하게 근거를 선택하고 조합할 여지를 제공합니다.
결국 하이퍼그래프 기반 접근은 RAG를 단순한 문서 검색 도구에서 한 단계 끌어올립니다. 핵심은 더 많은 정보를 가져오는 것이 아닙니다. 서로 연결된 정보가 어떤 맥락에서 함께 답변의 근거가 되는지 이해하도록 만드는 것입니다.
텍스트만 읽는 RAG는 무엇을 놓치는가
같은 PDF라도 텍스트로 추출했을 때와 페이지 이미지로 보았을 때의 의미는 달라질 수 있습니다. 표의 열 구조, 차트의 추세, 도면의 배치가 사라지는 순간 RAG가 답변의 근거로 삼아야 할 정보도 함께 무너집니다.
기존 텍스트 중심 RAG는 PDF, 웹페이지, 보고서에서 문자를 추출한 뒤 이를 작은 청크로 나누고 임베딩합니다. 이 방식은 문장형 문서에는 효율적입니다. 그러나 실제 업무 문서는 텍스트만으로 의미가 완성되지 않는 경우가 많습니다.
표는 숫자의 나열이 아니라 관계의 구조다
예를 들어 재무 보고서의 표를 텍스트로 추출하면 다음과 같은 문제가 생길 수 있습니다.
- 열 제목과 수치가 분리된다.
- 행과 열의 대응 관계가 뒤섞인다.
- 각주, 단위, 적용 기간이 본문 숫자와 멀어진다.
- 병합 셀이나 다단 헤더의 의미가 사라진다.
사람은 표를 볼 때 자연스럽게 “이 수치는 어느 사업부의 어느 기간 실적인가”를 읽습니다. 하지만 텍스트 추출 결과가 매출 120 135 142 비용 80 91 95처럼 평면화되면, RAG는 숫자는 찾을 수 있어도 숫자 간의 정확한 관계를 보장하기 어렵습니다.
특히 규정 문서나 기술 사양서에서는 한 칸의 조건값, 예외 조항, 단위 표기가 결론을 바꿀 수 있습니다. 이때 검색 결과에 관련 숫자가 포함되어 있다는 사실만으로는 충분하지 않습니다. 그 숫자가 원래 문서에서 어떤 구조 안에 놓여 있었는지까지 유지되어야 합니다.
차트는 문장이 아닌 추세를 전달한다
차트 역시 텍스트 변환만으로는 쉽게 손실되는 정보입니다. 축의 방향, 범례의 색상, 값의 급격한 변곡점, 두 지표 사이의 간격은 OCR 결과에 거의 남지 않거나 불완전하게 남습니다.
가령 “최근 3분기 동안 오류율은 감소했지만 처리량은 정체됐다”는 결론은 그래프의 추세를 함께 읽어야 나옵니다. 단순 추출 텍스트에는 월별 수치가 일부 들어 있을 수 있지만, RAG가 그 변화의 패턴과 비교 대상을 정확히 해석하기는 쉽지 않습니다.
페이지 이미지를 직접 다루는 멀티모달 RAG는 이 지점에서 강점을 가질 수 있습니다. 텍스트뿐 아니라 차트의 시각적 패턴을 함께 검색하고, 질문에 필요한 그래프 영역과 설명 문단을 연결할 수 있기 때문입니다.
문서의 의미는 단어의 집합이 아니라, 단어·숫자·시각 요소가 배치된 방식에서 만들어지는 경우가 많습니다.
도면과 레이아웃은 ‘위치’ 자체가 정보다
설계도, 회로도, 조직도, 의료 이미지, 공정 흐름도는 더욱 분명합니다. 이런 자료에서는 객체가 무엇인지뿐 아니라 어디에 있고, 무엇과 연결되며, 어떤 순서로 배치되는지가 핵심입니다.
예를 들어 제조 설비 도면에서 밸브의 명칭만 추출해도 해당 부품을 검색할 수는 있습니다. 그러나 밸브가 어느 배관 사이에 놓여 있는지, 어떤 센서와 연결되는지, 인접한 경고 표시는 무엇인지가 빠지면 실제 운영 질문에 신뢰성 있게 답하기 어렵습니다.
텍스트-only RAG는 “문서에 밸브 A가 있다”는 수준의 답변에는 대응할 수 있습니다. 반면 멀티모달 RAG는 “밸브 A는 압력 센서 B 뒤, 우회 라인 앞에 배치돼 있다”처럼 배치와 연결 관계를 근거로 답하는 방향을 지향합니다.
멀티모달 RAG가 필요한 이유
멀티모달 RAG의 목표는 단순히 이미지를 추가하는 데 있지 않습니다. 핵심은 서로 다른 형식의 정보를 하나의 근거 체계로 정렬하는 것입니다.
이를 위해서는 다음과 같은 처리가 필요합니다.
페이지 단위 보존
문장을 분리해 저장하더라도, 원래 페이지와 좌표 정보를 함께 유지해야 합니다. 그래야 검색된 문장이 어떤 표·그림·각주와 연결되는지 다시 확인할 수 있습니다.텍스트와 시각 요소의 연결
캡션, 표 제목, 범례, 이미지 주변 문단을 연결해야 합니다. 이미지 자체만 검색하거나 OCR 텍스트만 검색하는 방식보다 더 정확한 근거 구성이 가능합니다.질문별 모달리티 선택
“정책의 적용 조건은 무엇인가”에는 본문 텍스트가 중요할 수 있습니다. 반면 “매출이 가장 크게 감소한 구간은 어디인가”에는 차트가, “부품은 어디에 연결되는가”에는 도면이 더 중요합니다.재검색과 검증
첫 검색 결과가 표의 일부만 가져왔다면, 시스템은 헤더·각주·관련 페이지를 추가로 찾아야 합니다. 이 점에서 단계적으로 컨텍스트를 보완하는 incremental refinement 방식이 중요해집니다.
결국 문제는 검색량이 아니라 근거의 완전성이다
텍스트 추출은 여전히 RAG의 중요한 출발점입니다. 빠르고 비용 효율적이며, 문장형 지식 검색에는 매우 효과적입니다. 다만 모든 문서를 텍스트 청크로만 다루면, 시스템은 문서가 가진 구조적 맥락을 잃을 수 있습니다.
앞으로의 RAG는 “관련 문장을 얼마나 많이 찾았는가”보다 “답변에 필요한 구조와 시각적 근거를 끝까지 보존했는가”를 더 중요하게 다뤄야 합니다. 표의 열, 차트의 추세, 도면의 연결 관계까지 읽을 수 있을 때, RAG는 비로소 실제 업무 문서를 제대로 이해하는 단계에 가까워집니다.
RAG: 검색하고, 의심하고, 다시 찾는 루프
첫 번째 검색 결과에 답이 없거나, 가져온 문서와 이미지가 서로 다른 결론을 말한다면 좋은 RAG는 어떻게 행동해야 할까요?
답은 단순합니다. 불완전한 근거를 그대로 답변으로 포장하지 않고, 무엇이 부족한지 판단한 뒤 다시 검색해야 합니다. 이것이 하이퍼그래프 기반 멀티모달 RAG가 제안하는 incremental refinement, 즉 단계적 컨텍스트 정교화의 핵심입니다.
기존 RAG는 보통 다음 순서로 작동했습니다.
- 질문을 벡터로 변환합니다.
- 유사한 문서 조각을 몇 개 검색합니다.
- 검색 결과를 LLM에 전달합니다.
- 모델이 답변을 생성합니다.
이 방식은 간단한 질의에는 빠르고 효율적입니다. 하지만 규정 문서, 설계도, 표, 차트, 이미지처럼 정보가 여러 형식에 흩어진 환경에서는 쉽게 한계에 부딪힙니다. 첫 번째 검색 결과가 질문의 일부만 설명하거나, 서로 다른 자료가 충돌할 수 있기 때문입니다.
단계적 정교화 RAG는 여기서 멈추지 않습니다. 첫 번째 검색을 최종 답변의 근거가 아니라, 다음 탐색을 위한 출발점으로 봅니다.
첫 검색: 넓게 찾고, 답의 빈칸을 확인한다
초기 검색 단계에서는 질문과 관련된 텍스트, 표, 이미지, 문서 메타데이터를 폭넓게 수집합니다. 예를 들어 사용자가 “이 장비의 안전 기준과 설치 조건은 무엇인가?”라고 질문했다고 가정해 보겠습니다.
첫 검색은 다음과 같은 자료를 가져올 수 있습니다.
- 안전 규정이 적힌 본문 문단
- 설치 환경을 설명하는 표
- 장비 배치가 표시된 도면
- 예외 조건이 포함된 별도 부록
- 최신 개정 이력이 담긴 공지 문서
문제는 이 자료들이 항상 완전하게 일치하지 않는다는 점입니다. 본문에는 기본 설치 기준이 있지만, 표에는 온도 조건이 빠져 있을 수 있습니다. 도면은 특정 모델만 대상으로 할 수도 있습니다. 최신 공지에는 기존 규정을 수정하는 예외 조항이 있을 가능성도 있습니다.
따라서 RAG는 “검색 결과가 있느냐”만 확인해서는 안 됩니다. 대신 다음을 점검해야 합니다.
- 질문의 모든 하위 조건이 충족되었는가?
- 핵심 주장마다 근거가 연결되어 있는가?
- 문서 간 날짜, 버전, 적용 대상이 일치하는가?
- 텍스트와 이미지 또는 표가 같은 내용을 가리키는가?
- 서로 충돌하는 증거가 존재하는가?
이 검증 과정이 바로 ‘의심하는 단계’입니다.
컨텍스트 평가: 모호함과 충돌을 탐지한다
Incremental refinement의 핵심은 검색 결과를 무조건 신뢰하지 않는 데 있습니다. 생성 모델 또는 별도의 평가 모듈은 현재 컨텍스트를 읽고, 답변을 만들기 전에 정보의 빈틈을 식별합니다.
예를 들어 다음과 같은 판단이 가능합니다.
“설치 온도 범위는 확인했지만, 습도 조건의 근거가 없다.”
“도면의 모델 번호와 질문 속 제품 모델이 다르다.”
“규정 본문과 최신 공지의 적용 기준이 충돌한다.”
“표의 수치가 이미지 캡션으로만 제시되어 있어 추가 확인이 필요하다.”
이때 중요한 것은 단순히 문서를 더 많이 넣는 것이 아닙니다. 관련성이 낮은 자료를 무작정 늘리면 컨텍스트가 길어지고, 오히려 모델의 판단이 흔들릴 수 있습니다.
좋은 RAG는 부족한 근거를 구체적인 추가 검색 질문으로 바꿉니다. 가령 “습도 조건”이 누락됐다면 해당 조건만 찾도록 재검색하고, 버전 충돌이 발견됐다면 최신 개정 문서와 적용 시점을 우선적으로 확인합니다.
재검색: 하이퍼그래프를 따라 필요한 근거를 찾는다
하이퍼그래프 기반 구조는 이 재검색 단계에서 특히 강점을 가질 수 있습니다. 일반적인 벡터 검색이 질문과 문서 조각의 의미적 유사도에 주로 의존한다면, 하이퍼그래프는 문서·표·이미지·엔티티·버전 정보 사이의 복합 관계를 함께 활용합니다.
예를 들어 하나의 하이퍼엣지는 다음 요소를 동시에 연결할 수 있습니다.
- 특정 장비 모델
- 해당 모델의 설치 매뉴얼
- 설치 조건 표
- 관련 안전 도면
- 최신 개정 공지
- 적용 지역 또는 규정 버전
이 구조를 사용하면 시스템은 단순히 “설치 조건”이라는 단어가 비슷한 문서를 찾는 데 그치지 않습니다. 첫 검색에서 발견한 장비 모델, 문서 버전, 도면 번호를 단서로 삼아 연결된 근거를 따라가며 더 정확한 자료를 탐색할 수 있습니다.
특히 멀티모달 환경에서는 이 차이가 더욱 큽니다. 중요한 수치가 본문이 아니라 표에 있고, 표의 범례가 이미지에 있으며, 이미지의 적용 범위가 별도 문서에 정의되어 있다면 단일 문서 청크만으로는 답을 완성하기 어렵습니다. 관계 중심의 탐색은 이러한 정보 조각을 다시 조립하는 역할을 합니다.
최종 답변: 많이 찾는 것이 아니라, 충분히 검증한 뒤 답한다
단계적 루프의 목표는 검색 횟수를 늘리는 것이 아닙니다. 목표는 답변에 필요한 근거가 충분하고 일관적인지 확인하는 것입니다.
최종적으로 RAG는 다음 조건이 충족될 때 답변을 생성해야 합니다.
- 질문의 핵심 항목이 모두 근거로 뒷받침된다.
- 서로 충돌하는 정보는 우선순위 기준에 따라 정리됐다.
- 최신성, 버전, 적용 범위가 확인됐다.
- 텍스트·표·이미지 등 서로 다른 모달리티의 정보가 정렬됐다.
- 여전히 확실하지 않은 내용은 단정하지 않고 불확실성으로 표시한다.
결국 차세대 RAG의 경쟁력은 “한 번에 얼마나 많이 찾는가”가 아니라, 첫 검색을 얼마나 비판적으로 검토하고 필요한 근거를 얼마나 정확히 다시 찾는가에 달려 있습니다.
검색하고, 의심하고, 다시 찾는 루프는 느려 보일 수 있습니다. 그러나 복잡한 기업 문서, 기술 매뉴얼, 의료·금융·법률 데이터처럼 오류 비용이 큰 환경에서는 이 한 단계의 재검증이 답변 품질과 신뢰도를 가르는 결정적인 차이가 됩니다.
RAG의 진짜 시험대: 정확도와 보안
더 똑똑한 검색 구조가 곧 더 신뢰할 수 있는 시스템을 뜻할까요? 반드시 그렇지는 않습니다. 하이퍼그래프, 멀티모달 검색, 에이전트형 재검색 루프는 RAG의 정확도를 높일 수 있지만, 동시에 공격자가 노릴 수 있는 연결 지점도 늘립니다. 앞으로의 핵심 과제는 “더 많이 찾는 RAG”가 아니라, 어떤 근거를 왜 선택했고 그 근거가 믿을 만한지 설명할 수 있는 RAG를 만드는 일입니다.
정확도는 검색 성능만으로 완성되지 않는다
전통적인 RAG에서는 질문과 유사한 문서를 top-k로 검색해 답변에 넣는 방식이 일반적이었습니다. 이때 정확도는 주로 검색 재현율, 순위 품질, 답변 정합성으로 평가됩니다.
하지만 하이퍼그래프 기반 멀티모달 RAG에서는 문제가 더 복잡해집니다. 시스템은 텍스트 조각 하나가 아니라 다음과 같은 관계 묶음을 선택합니다.
- 정책 문서의 특정 조항
- 해당 조항을 설명하는 표와 차트
- 연결된 제품 규격서
- 동일 엔티티를 언급하는 외부 리포트
- 이전 검색 단계에서 이미 확보한 근거
즉, 답변 품질은 개별 문서의 유사도보다 근거 묶음 전체의 일관성에 좌우됩니다. 한 문서가 질문과 매우 유사하더라도, 연결된 표·이미지·개정 이력과 충돌한다면 그 문서를 핵심 근거로 채택해서는 안 됩니다.
따라서 차세대 RAG는 “가장 비슷한 자료”를 찾는 것을 넘어, 다음 질문에 답해야 합니다.
이 정보는 다른 근거와 일치하는가?
최신 상태인가?
신뢰 가능한 출처에서 왔는가?
이미지·표·본문이 같은 결론을 지지하는가?
복잡한 관계망은 새로운 공격 표면이 된다
하이퍼그래프는 문서, 이미지, 엔티티, 메타데이터 사이의 복합 관계를 표현하는 데 유리합니다. 그러나 관계가 풍부해질수록 공격자는 단순히 악성 문서 하나를 넣는 수준을 넘어, 관계 구조 자체를 오염시키는 방식을 시도할 수 있습니다.
예를 들어 공격자는 다음과 같은 방법을 사용할 수 있습니다.
- 정상 문서와 유사한 제목·키워드를 가진 문서를 대량 삽입해 검색 순위를 왜곡합니다.
- 신뢰도 높은 엔티티나 규정 문서에 악성 문서를 반복 연결해 그래프 중심성을 높입니다.
- 이미지 속 작은 문구, 표의 각주, OCR 오류를 이용해 멀티모달 검색 결과를 오염시킵니다.
- 에이전트의 재검색 질문을 특정 방향으로 유도해, 반복적인 refinement 과정이 공격자 문서를 더 많이 참조하게 만듭니다.
- 최신 개정본과 폐기된 문서를 의도적으로 연결해, 오래된 정책이나 잘못된 수치를 정답처럼 보이게 만듭니다.
이런 공격은 단순한 프롬프트 인젝션보다 탐지하기 어렵습니다. 겉으로는 정상적인 문서와 연결 관계처럼 보이지만, 실제로는 RAG가 특정 결론에 도달하도록 검색 경로를 조종할 수 있기 때문입니다.
Incremental Refinement는 방어 장치이자 위험 요소다
점진적 컨텍스트 정교화는 초기 검색의 부족한 부분을 보완하는 강력한 방식입니다. 초기에 넓게 자료를 찾고, 모델이 불확실성·충돌·누락 정보를 감지한 뒤 추가 검색을 수행하면 답변의 근거가 탄탄해질 수 있습니다.
다만 평가 단계가 취약하면 refinement 루프는 공격을 증폭할 수도 있습니다. 첫 번째 검색에서 오염된 문서가 들어오고, 모델이 그 문서의 주장에 맞춰 후속 질문을 생성한다면 이후 검색 역시 같은 방향으로 편향될 가능성이 있습니다. 잘못된 근거가 반복 검색을 통해 “검증된 정보”처럼 강화되는 셈입니다.
그래서 refinement 단계에는 단순 관련성 판단 외에 다음 검증이 필요합니다.
- 출처 검증: 문서의 발행 주체, 개정일, 승인 상태, 접근 권한을 확인합니다.
- 교차 검증: 하나의 고영향 문서에 의존하지 않고 독립된 출처에서 같은 사실을 확인합니다.
- 시간 정합성 검증: 최신 문서와 과거 문서가 충돌할 때 우선순위를 명확히 적용합니다.
- 모달리티 정합성 검증: 본문, 표, 이미지 캡션, OCR 텍스트가 서로 모순되지 않는지 검사합니다.
- 불확실성 표시: 근거가 부족하거나 출처 간 충돌이 해소되지 않으면 단정적 답변을 피합니다.
신뢰할 수 있는 RAG를 위한 구조적 방어 원칙
실무에서 중요한 것은 하이퍼그래프나 멀티모달 모델을 도입하는 것 자체가 아닙니다. 그 구조가 악성 영향력을 추적하고 차단하도록 설계되어야 합니다.
가장 먼저 필요한 것은 근거 추적성(provenance) 입니다. 최종 답변의 각 주장에 대해 어떤 문서, 이미지, 표, 하이퍼엣지가 사용됐는지 기록해야 합니다. 사용자는 물론 운영자도 “이 답변은 무엇에 근거했는가”를 역추적할 수 있어야 합니다.
다음으로는 신뢰도 기반 가중치가 필요합니다. 모든 문서와 관계를 동일하게 다루지 말고, 공식 발행 문서·승인된 데이터베이스·검증된 내부 지식에는 높은 신뢰 점수를 부여해야 합니다. 반대로 출처가 불명확하거나 갑자기 다수의 관계를 형성한 노드는 별도 검토 대상으로 분류할 수 있습니다.
또한 하이퍼그래프 환경에서는 다음과 같은 이상 징후를 관찰할 수 있습니다.
- 특정 문서가 짧은 기간에 비정상적으로 많은 문서와 연결되는 경우
- 하나의 노드가 다양한 질문에서 반복적으로 핵심 근거로 선택되는 경우
- 공식 문서와 상충하지만 높은 검색 점수를 받는 관계 묶음이 등장하는 경우
- 이미지·표 기반 근거와 텍스트 근거 사이에 반복적인 불일치가 발생하는 경우
이상 탐지는 단순 보안 기능이 아니라 RAG 품질 관리의 일부가 되어야 합니다.
결론: 좋은 답변보다 설명 가능한 근거가 중요하다
차세대 RAG의 경쟁력은 더 큰 컨텍스트 창이나 더 복잡한 검색 그래프만으로 결정되지 않습니다. 진짜 차이는 시스템이 잘못된 근거를 얼마나 빨리 발견하고, 어떤 근거가 답변을 지배했는지 얼마나 명확히 보여주는가에서 나옵니다.
하이퍼그래프와 멀티모달 refinement는 RAG를 훨씬 강력하게 만들 수 있습니다. 그러나 그만큼 관계의 신뢰도, 출처의 이력, 검색 경로의 투명성을 함께 관리해야 합니다. 앞으로 신뢰받는 RAG는 “답을 잘하는 시스템”이 아니라, 답변의 근거를 검증하고 공격 가능성까지 설명하는 시스템이 될 것입니다.
