검색 인덱스도 스스로 고쳐진다 — 파싱에서 SELF-INDEX까지, 인덱스를 살아 있는 것으로 운영하기 (RAG 특집 4편)

들어가며 — 잘 되던 검색이 어느 날 안 된다

크게 보기

운영 중인 RAG에서 가장 흔한 티켓은 이렇게 온다. "지난주까지 잘 찾던 질문인데 이제 엉뚱한 문서가 나옵니다." 담당자가 로그를 연다. 질의는 "지원 요건에 업력 제한이 있나요?". 상위 결과는 2025년 공고, 창업 가이드, 세제 지원 안내. 정답인 2026년 공고 3.2절 "신청 자격: 창업 7년 이내"는 어디에도 없다.

원인을 찾는 데 한 시간이 걸린다. 사용자는 '지원 요건·업력'이라 말하고 문서는 '신청 자격·창업 7년 이내'라고 쓴다. 임베딩은 둘을 충분히 가깝게 보지 않았고, 2025년 공고에는 우연히 '업력'이라는 단어가 있었다. 고치는 데는 더 오래 걸린다. 방법이 셋뿐이기 때문이다. 청킹 규칙을 바꾸고 전체를 다시 색인하거나, 임베딩 모델을 바꾸고 전체를 다시 색인하거나, 이 문서에 수동으로 동의어를 달아 두는 것. 앞의 둘은 잘 되던 다른 질의를 깨뜨릴 수 있고, 마지막은 다음 달에 같은 티켓이 다른 문서로 또 온다.

이 글은 그 한 시간과 그 세 가지 선택지를 없애는 방법에 대한 것이다. 2026년 9월 17일 공개된 「Self-Evolving Search Index」(SELF-INDEX)는 이 일을 자동화한다 — 정답 라벨 없이 실패를 진단하고, 책임 있는 문서의 검색 표현만 고쳐 쓰고, 검증한 뒤 반영한다. 그런데 이 발상이 서려면 그 아래에 먼저 있어야 하는 것들이 있다. 파서가 표를 텍스트로 뽑아 놓았어야 하고, 어느 청크가 어느 문서의 어느 절에서 왔는지 남아 있어야 하고, 고친 것이 다른 것을 깨지 않았는지 잴 질의 세트가 있어야 한다.

1. 인덱스는 왜 낡는가 — 정적 인덱스의 세 가지 가정

지금까지의 RAG 인덱스는 한 번 만들고 끝나는 산출물이었다. 문서를 자르고, 임베딩하고, 벡터 DB에 넣는다. 그 뒤로 인덱스가 바뀌는 경우는 새 문서가 추가될 때뿐이다. 이 방식에는 세 가지 가정이 깔려 있고, 셋 다 운영 몇 달 안에 깨진다.

세 가정을 뒤집으면 이 글의 구조가 된다. 원문 외에 검색 표현(키)을 따로 두고, 그 표현을 문서마다 다르게 두고, 실패가 관찰되면 책임 있는 문서의 표현만 자동으로 고친다. 그런데 이것은 인덱스 층에서 할 수 있는 일이고, 그 아래 두 층 — 파싱과 문서 객체 — 이 제대로 있어야 성립한다. 아래층부터 올라가자.

2. 입구 — 파싱이 잘못되면 그 뒤는 전부 무의미하다

크게 보기

최신 검색 전략을 아무리 쌓아도 파싱이 잘못되면 대부분 무의미하다. 표가 텍스트로 추출되지 않았으면 표에 대한 질문은 어떤 인덱스 표현으로도 못 찾는다. 스캔 첨부 서류에 OCR이 돌지 않았으면 그 문서는 존재하지 않는 것과 같다. 읽기 순서가 두 단 조판에서 뒤섞였으면 청크는 문장이 아니라 단어 뭉치가 된다.

2026년 시점에서 이 입구의 사실상 표준은 IBM Research가 만들고 LF AI & Data Foundation에 기증한 Docling(MIT)이다. 지원 형식과 기능을 공식 문서 기준으로 정리하면 다음과 같다.

이 표에서 눈여겨볼 것은 형식의 가짓수가 아니라 무손실 JSON과 RAG용 청크가 별도의 출력이라는 점이다. 파서의 산출물은 청크가 아니다. 파서의 산출물은 문서 객체 — 어느 페이지의 어느 좌표에 어떤 유형의 요소가 어떤 부모 아래 있는지를 담은 구조 — 이고, 청크는 그 객체에서 파생된다. 이 구분이 다음 장의 전부다.

3. 보존 — 반드시 남겨야 할 문서 객체 필드

크게 보기

문서 객체에서 무엇을 남겨야 하는가. 이 시리즈 전체를 기준으로 정리하면 최소 필드는 다음과 같다.

{
  "document_id": "gov-notice-2026-0412",
  "version_id": "v3",
  "page": 12,
  "section_path": ["3장", "3.2 지원 자격"],
  "element_type": "table",
  "text": "...",
  "bounding_box": [72, 410, 540, 655],
  "parent_element_id": "sec-3.2",
  "related_image_ids": ["fig-3"],
  "source_hash": "sha256:9f2c...",
  "effective_date": "2026-04-14",
  "acl": ["tenant:A", "role:manager"]
}

각 필드가 왜 있어야 하는지는 “빠지면 무엇이 불가능해지는가”로 말하는 게 가장 빠르다. 아래 위젯에서 필드를 껐다 켜 보자.

세 가지를 덧붙인다.

네 층을 전부 남긴다. 원문 파일, 페이지 이미지, 구조화 JSON, 검색용 청크. 청크만 남기면 임베딩 모델을 바꿀 때 재임베딩은 되지만 재청킹은 안 된다. JSON까지 남기면 재청킹이 되지만 파서 교체는 안 된다. 원문과 페이지 이미지까지 남겨야 파서를 바꿀 수 있고, 6편의 멀티모달 인덱스가 같은 좌표를 공유할 수 있다. 저장 비용은 선형이고, 다시 만드는 비용은 코퍼스 전체다.

version_id와 effective_date는 표현이 아니라 관계다. 4장의 실패 유형 중 “최신 버전 미선택”은 인덱스 표현을 아무리 고쳐도 해결되지 않는다. “이 연장 공지가 저 원 공고를 갱신한다”는 문서 간 관계이고, 검색 단계의 필터·가중치로만 다룰 수 있다. 8편의 보안 논의 — 가짜 ‘정정 공지’로 기존 정답을 무효화하는 공격 — 도 이 필드가 있어야 방어할 수 있다.

source_hash는 두 가지 일을 한다. 같은 파일이 다른 경로로 들어왔을 때 중복을 잡고, 수집 시점과 지금의 원문이 같은지 확인한다. 후자는 8편의 변조 감지의 전제다.

4. 진단 — 검색 실패의 다섯 원인과 고쳐야 할 층

크게 보기

인덱스를 고치기 전에 무엇이 잘못됐는지 알아야 한다. 운영에서 마주치는 검색 실패를 원인별로 나누면 대체로 다섯 가지로 떨어지고, 원인이 다르면 고쳐야 할 층이 다르다.

위젯을 몇 번 돌려 보면 요점이 보인다. 인덱스 표현만 고쳐서 되는 것은 ③과 ④ 둘이다. 나머지 셋은 파서·청킹·메타데이터로 내려가야 하고, 그 층들이 3장의 문서 객체를 제대로 보존하고 있어야 문서 단위로 고칠 수 있다. 그리고 ③·④가 바로 다음 장의 SELF-INDEX가 자동화하는 영역이다.

한 가지 더. ①~⑤를 분류하는 일 자체가 지금은 사람의 일이다. SELF-INDEX가 흥미로운 것은 이 분류를 정답 라벨 없이 해낸다는 점이다.

5. SELF-INDEX — 라벨 없이 진단하고, 선택적으로 고치고, 검증한다

크게 보기

2026년 9월 17일 arXiv에 올라온 「Self-Evolving Search Index」는 연세대를 중심으로 삼성리서치·고려대·UC 어바인 연구진이 함께 쓴 논문이다. arXiv 코멘트 필드는 “Work in progress”. 초록의 문제 설정은 이렇다.

"검색은 문서의 지식을 대표하는 인덱스 키에 의존하므로, 검색 효과는 이 키들이 담긴 정보를 얼마나 잘 드러내는가에 달려 있다. … 그런데 현재는 어느 인덱스 키가 검색 실패를 일으키는지 사람이 직접 진단하고 최적화 전략을 다듬어야 한다."

5.1 키라는 단위

논문의 인덱스 모델은 단순하다. 각 문서 d는 키 집합 𝒦(d)를 갖는다. 처음에는 문서 원문 하나가 유일한 키다(𝒦₀(d) = {d}). 검색 점수는 그 문서의 키 중 질의와 가장 관련도가 높은 것으로 정한다: s(q, d) = max over k of rel(q, k). 키는 문서당 최대 10개.

이 모델의 요점은 원문과 검색 표현을 분리한 것이다. 원문은 그대로 두고, 그 문서가 검색되게 만드는 표현(키)만 늘리고 고친다. 1장의 가정 ①을 뒤집은 것이 이 한 줄이다. 그리고 검색기는 무엇이든 된다 — 논문은 BM25(희소), BGE-Large, Qwen3-Embedding-8B(밀집) 셋에서 실험했다.

5.2 한 반복 — 진단, 수정, 검증

Self-Diagnosis가 이 논문의 핵심 발명이다. 관련성 라벨이 없는데 어떻게 실패를 아는가. 답은 co-retrieval 프로필이다. 어떤 질의에 대해 상위 K개 키가 검색되면, 각 키에 대해 “이 키가 검색될 때 다른 문서의 어떤 키들이 함께, 얼마나 자주 올라오는가”를 기록한다. LLM은 문서 원문, 현재 키, 이 프로필을 보고 “현재 키가 무엇을 표현하지 못하거나 구별하지 못하는가”를 설명한다. 정답을 몰라도, 한 문서의 키가 늘 특정 경쟁 문서들의 키에 가려지거나 늘 엉뚱한 것들과 함께 나타난다는 사실 자체가 진단의 재료가 된다.

Self-Revision은 진단된 문서의 키 집합을 통째로 한 번 고쳐 쓴다. 키 하나씩이 아니라 문서 단위로, 그 문서의 모든 키에 대한 진단을 함께 보면서. 코퍼스의 다른 문서는 건드리지 않는다. 이것이 “선택적”의 뜻이다.

Self-Validation은 새 키 집합을 세 기준으로 검사한다. 충실성 — 각 키가 원문에 근거하고 왜곡이 없는가. 특정성 — 이 문서에 특정한 지식을 담는가(어느 문서에나 맞는 키는 탈락). 분리 — 관찰된 경쟁 키들과의 최대 관련도가 기존 키 집합보다 낮은가. 통과한 키 집합으로만 인덱스를 갱신한다.

Query Simulator는 이 루프를 능동형으로 만든다. 실제 질의만 기다리면 인덱스는 사용자가 실패한 뒤에야 고쳐진다. 시뮬레이터는 문서를 샘플링해 그럴듯한 검색 수요를 생성하고, 이미 쓴 질의와 자카드 유사도로 어휘 중복을 걸러 새 질의만 남긴다. 논문의 주 실험은 오직 시뮬레이터 질의로만 인덱스를 진화시켰고, 평가 질의는 최적화 중 한 번도 보지 않았다. 데이터 누출이 없다는 뜻이고, 동시에 “아직 오지 않은 질문에 대비하는 인덱스”가 실제로 작동한다는 뜻이다.

5.3 결과

네 탭에서 읽어 낼 것이 하나씩 있다.

① BRIGHT. 검색기 셋 모두에서 기준 대비 +39~57%. 가장 눈에 띄는 한 줄은 진화한 BM25(20.4)가 기준 상태의 Qwen3-Embedding-8B(18.8)를 넘었다는 것이다. 더 큰 임베딩 모델로 바꾸는 것보다 인덱스 표현을 고치는 것이 더 컸다. 1장 가정 ①의 정량적 반증이다.

② 표 검색. BM25에서 +49%. 표는 원문만으로 “무엇에 대한 표인가”가 가장 드러나지 않는 요소라, 열 이름·단위·맥락을 풀어 쓴 키가 큰 차이를 만든다.

③ 검색 에이전트·메모리. 이 글과 1편의 관계가 여기 있다. BrowseComp-Plus에서 GPT-OSS-120B + BM25 에이전트의 정답률이 31.1%에서 58.9%로 오르면서 질문당 검색 호출은 21.2에서 16.6으로 줄었다. 인덱스가 좋아지면 에이전트가 덜 헤맨다. 논문은 GPT-5.4-nano + BM25 + SELF-INDEX가 같은 백본의 DCI(1편 5장, 인덱스 없이 grep으로 뒤지는 방식)와 비슷한 정확도를 더 낮은 온라인 비용으로 낸다고 적었고, 코퍼스를 10만에서 40만 문서로 늘려도 정확도가 유지됐다 — DCI가 무너지던 바로 그 구간이다. 에이전트 메모리(LongMemEval-V2)에서도 +9~14%.

④ 제거 실험. 이 글에서 가장 중요한 표다. 검증을 통째로 빼면 −9.1~−10.5로, 성능이 기준 인덱스보다 낮아진다. 진단과 수정만 있고 검증이 없는 자가 수정 루프는 인덱스를 스스로 망가뜨린다. 세 기준 중 하나만 빼도 −1.7~−6.1. co-retrieval 프로필을 빼면 자연어에서 −6.9. 시뮬레이터의 중복 필터를 빼면 −2.4~−4.4.

6. 실무 루프 — 전체 재색인 대신 실패 문서만

크게 보기

SELF-INDEX를 그대로 옮기기 어려운 팀도 발상은 그대로 쓸 수 있다. 논문의 구조를 운영 시스템의 언어로 단순화하면 다음 루프가 된다.

6.1 왜 “전체”가 아니라 “해당 문서만”인가

두 방식의 비용은 다른 변수에 비례한다. 전체 재색인은 코퍼스 크기에, 선택적 수정은 실패 비율에. 코퍼스가 20만 건이고 실패에 책임 있는 문서가 1.5%라면 두 자릿수 배 차이가 나고, 이 차이는 코퍼스가 커질수록 벌어진다. 그러나 비용보다 중요한 것이 회귀 표면이다. 전체 재색인은 20만 건 전부의 검색 결과가 바뀔 수 있다. 잘 되던 질의가 깨질 자리가 코퍼스 전체다. 선택적 수정은 3천 건 주변만 바뀐다. 다음 절의 게이트가 검사해야 할 범위가 그만큼 작다.

위젯의 실패 비율을 10% 위로 올려 보면 다른 결론이 나온다. 실패가 문서 열 건 중 하나라면 문제는 개별 문서가 아니라 파서나 청킹 규칙 자체다. 그때는 층을 내려가서 고쳐야 하고, 선택적 수정은 증상 치료다.

6.2 회귀 게이트 — 고쳤다고 바로 교체하지 않는다

크게 보기

게이트의 조건은 셋이고, 셋 다 필요하다. 평균이 올랐는가만 보면 특정 질의 하나가 크게 죽어도 통과한다 — 위젯의 부작용 슬라이더를 올려 보면 바로 나온다. 그래서 개별 질의의 최대 허용 악화가 따로 있어야 한다. 그리고 겨냥한 실패 질의가 실제로 회복됐는가가 없으면 “아무것도 안 바뀌었는데 통과”가 가능하다.

이 게이트는 SELF-INDEX의 Self-Validation을 시스템 수준으로 옮긴 것이다. 논문은 키 단위로 충실성·특정성·분리를 검사했고, 운영 시스템은 질의 세트 단위로 개선·악화·회복을 검사한다. 층은 다르지만 역할은 같다 — 검증 없는 자가 수정은 자가 파괴다. 그리고 게이트를 돌리려면 3장의 version_id가 있어야 한다. 거절된 수정을 되돌리고, 통과한 수정도 나중에 나쁘다고 판명되면 되돌릴 수 있어야 하기 때문이다.

6.3 능동형 — 아직 오지 않은 질의

크게 보기

위 루프는 반응형이다. 사용자가 실패한 뒤에 고친다. SELF-INDEX의 Query Simulator를 운영 언어로 옮기면 합성 질의 세트다. 새 문서가 들어오면 그 문서에 대해 “올 법한 질문” 몇 개를 LLM으로 만들어 두고, 그 질문으로 문서가 검색되는지 미리 확인한다. 안 되면 사용자가 묻기 전에 표현을 고친다. 이미 있는 질의와 너무 비슷한 합성 질의는 걸러야 한다는 것이 논문의 제거 실험(중복 필터 제거 시 −2.4~−4.4)이 알려 주는 세부다.

이 합성 질의 세트는 6.2의 회귀 게이트에 그대로 재사용된다. 게이트의 “잘 되던 질의”가 처음에는 없기 때문에, 합성 질의가 그 자리를 채운다.

7. 선행 사례 — LLM-Wiki의 Error Book과 PG-RAG

크게 보기

“인덱스가 자기 실수에서 배운다”는 발상은 SELF-INDEX가 처음이 아니다. 1편 4장에서 다룬 LLM-Wiki(Tencent WeChat, 2026년 5월)의 Error Book이 같은 발상의 선행 사례다. 문서를 위키 페이지로 컴파일하는 과정에서 발견된 오류 — 끊어진 링크가 검출 오류의 29.1~63.8%, 잘못된 참조가 18.9~28.5% — 를 기록하고, 원인을 자연어 제약 규칙으로 바꿔 다음 컴파일 프롬프트에 주입하고, 주기적으로 재검증해 닫는다. 발견 → 귀인 → 규칙화 → 주입 → 검증. Error Book을 빼면 F1이 3.4~4.0점 떨어졌다.

둘을 나란히 놓으면 차이가 선명하다.

더 거슬러 가면 2024년 5월의 PG-RAG(「Empowering Large Language Models to Set up a Knowledge Retrieval Indexer via Self-Learning」)가 있다. LLM을 “교재를 자기 말로 정리하는 학생”으로 보고, 문서를 읽어 자기 표현으로 사실을 기록하게 해 의사 그래프 인덱스를 만든다. 원문이 아니라 LLM이 다시 쓴 표현으로 색인한다는 점에서 SELF-INDEX의 “키”와 같은 발상이지만, 한 번 만들고 끝난다 — 실패 피드백 루프가 없다. 2년 사이에 “LLM이 쓴 표현으로 색인한다”에서 “그 표현을 실패로부터 고친다”로 옮겨 온 것이 이 계보의 요약이다.

8. 우리 시스템에 넣는 순서

9. 한계와 반론

9.1 논문이 밝힌 것과 밝히지 않은 것

• arXiv 코멘트는 “Work in progress”. 독립 재현은 아직 없다.
• Optimizer와 Query Simulator의 백본은 Qwen3.6-35B-A3B 하나다. 더 작은 모델로 진단·수정·검증이 얼마나 유지되는지는 보고되지 않았다.
• 오프라인 비용(반복당 LLM 호출 수·토큰·시간)이 본문에 정량화되지 않았다. 온라인 비용 절감은 보고됐지만 진화 자체의 비용은 우리 코퍼스에서 재야 한다.
• 반복 횟수와 반복당 시뮬레이터 질의 수가 본문에 명시되지 않았다.
• 문서 원문이 유일한 키인 상태를 기준선으로 삼았다. 이미 제목·요약을 덧붙인 잘 튠된 인덱스 대비 이득은 이보다 작을 수 있다.

9.2 이 특집이 덧붙이는 반론

표현이 늘면 잘못 걸릴 자리도 는다. 키를 10개까지 두면 문서가 검색될 기회가 늘지만, 무관한 질의에 걸릴 기회도 는다. 논문의 ‘분리’ 기준이 이를 막는 장치이지만, 운영에서는 정밀도 저하를 게이트에서 따로 재야 한다.

진단 LLM이 새 편향을 넣는다. co-retrieval 프로필을 해석하는 것은 LLM이고, 그 LLM이 “이 문서는 이런 질문에 답해야 한다”고 상상한 것이 키가 된다. 원문에 없는 뉘앙스가 스며들 수 있다. ‘충실성’ 검사가 있지만 같은 계열 모델이 생성하고 검증하면 눈먼 곳이 겹친다.

보안 표면. 인덱스가 스스로 고쳐진다는 것은, 오염된 질의나 오염된 피드백이 인덱스 표현을 바꿀 수 있다는 뜻이다. 8편에서 다룰 “한 문서로 최신 정보를 위장하는” 공격이 자가 수정 루프를 타면, 공격자는 문서만이 아니라 다른 정상 문서의 키까지 밀어낼 수 있다. 피드백 출처의 신뢰도와 게이트의 사람 확인이 방어선이다.

인덱스가 다가 아니다. 4장의 다섯 유형 중 셋은 인덱스 층 밖이다. 이 글이 파싱과 문서 객체에 절반을 쓴 이유다. SELF-INDEX가 아무리 좋아도 표가 텍스트로 안 나온 문서는 못 찾는다.

마무리 — 인덱스는 산출물이 아니라 운영 대상이다

이 글은 잘 되던 검색이 어느 날 안 되는 티켓으로 시작했다. 그 티켓을 닫는 데 한 시간이 걸린 이유는 원인을 사람이 찾아야 했기 때문이고, 닫고 나서도 불안한 이유는 고치는 방법이 전체 재색인뿐이었기 때문이다.

2026년의 답은 세 층으로 나뉜다. 입구에서 구조를 잃지 않고(파서), 그 구조를 버리지 않고 저장하고(문서 객체), 원문과 검색 표현을 분리해 표현만 실패로부터 고친다(자가 수정 인덱스). SELF-INDEX는 세 번째 층이 정답 라벨 없이도 돌아간다는 것을 보였고, 동시에 검증 없이는 그 루프가 인덱스를 망가뜨린다는 것도 보였다.

그래서 이 글의 결론은 기술 하나가 아니라 태도 하나다. 인덱스는 파이프라인의 마지막 산출물이 아니라 계속 운영해야 하는 대상이다. 실패 로그를 읽고, 원인을 층별로 나누고, 책임 있는 문서만 고치고, 고친 것이 다른 것을 깨지 않았는지 재고, 통과한 것만 반영한다. 코드를 배포하는 방식과 같다. 인덱스도 그렇게 배포해야 한다.

다음 편은 그 인덱스 위에 어떤 구조를 얹을 것인가 — GraphRAG가 “LLM이 추출한 지식 그래프” 하나에서 문서 그래프·동적 조인·위키 구조로 다변화하는 이야기다.

참고자료

연구 논문

• Lee, S., Lee, W., Kim, S., Kim, D., Kim, J., Nam, D., Kang, S. & Lee, D. Self-Evolving Search Index. arXiv:2609.19656 (2026년 9월 17일, Work in progress) — 연세대·삼성리서치·고려대·UC 어바인
• Ming, H., Li, F., Wu, X. & Que, W. Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki. arXiv:2605.25480 (2026년 5월) — Error Book
• Liang, X. et al. Empowering Large Language Models to Set up a Knowledge Retrieval Indexer via Self-Learning (PG-RAG). arXiv:2405.16933 (2024년 5월)
• Li, Z. et al. Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction (DCI). arXiv:2605.05242 (2026년 5월) — 5.3절 비교 대상

도구

• Docling (MIT, IBM Research · LF AI & Data) — 지원 형식 문서
• docling-mcp (MIT) — 변환·문서 생성·RAG 도구를 MCP로 노출
• 벤치마크: BRIGHT · Spider 2.0 · FIBEN · BEAVER · BrowseComp-Plus · LongMemEval-V2

함께 읽으면 좋은 코어닷투데이 글

• 검색은 파이프라인이 아니라 에이전트가 되었다 — Agentic Search (RAG 특집 1편) — LLM-Wiki Error Book, DCI
• OpenDataLoader PDF 완전 해부 — 파싱에서 구조를 잃지 않는 문제
• Advanced RAG: 실전 개선 기법 7가지 — 청킹·하이브리드·리랭킹
• 긴 맥락이 독이 된다: Context Rot