AI 에이전트를 위한 문서 컨텍스트 레이어 설계

원문 제목: [한영자막] AI 에이전트를 위한 문서 컨텍스트 레이어 구축하는 법 — Jerry Liu, LlamaIndex
URL: https://www.youtube.com/watch?v=S-bRN-avZ4Q
날짜: 2026-09-28
채널: Tech Bridge
발표자: Jerry Liu, LlamaIndex 공동창업자 겸 CEO
영상 길이: 20분 33초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==2026년의 RAG(Retrieval-Augmented Generation)는 고정된 top-k 검색 파이프라인이 아니라, 에이전트 하네스(agent harness)와 문서 컨텍스트 레이어(document context layer)가 결합된 시스템이다.== 아무리 똑똑한 모델이라도 실제 업무를 해결하려면 목표·평가 기준·조직의 문서·도구·데이터에 제대로 접근해야 한다.

• 2023년의 나이브 RAG는 문서를 청크로 쪼개 임베딩하고 벡터 데이터베이스에 넣은 뒤 고정된 top-k 결과를 LLM에 넘겼다.
• 현대 에이전트는 검색어를 스스로 고르고, 검색·읽기·도구 사용을 반복하며, 검색의 복잡성을 에이전트 레이어 안으로 흡수한다.
• PDF·PowerPoint·Word·Excel에 잠긴 10조 페이지 이상의 지식은 원시 파일 그대로는 에이전트가 해석하기 어렵기 때문에 파싱·저장·검색·워크플로우 레이어가 필요하다.
• 문서 파싱은 높은 정확도와 낮은 비용을 동시에 달성해야 하므로 파일 구조를 읽는 파이프라인과 시각 모델(VLM)을 결합한 하이브리드가 실용적인 파레토 최전선이 된다.

문서 컨텍스트 레이어는 문서를 사람이 보관하는 파일 저장소에서 에이전트가 읽고, 검색하고, 구조화하고, 편집하고, 반복 업무를 수행하는 작업 공간으로 바꾸는 기반이다.

1. 2026년 RAG의 변화

고정 검색 파이프라인의 시대가 지나고, 에이전트가 컨텍스트를 탐색하고 조합하는 시대가 열렸다.

1.1. 나이브 RAG에서 에이전트형 RAG로

1. 2023년 1월의 기본 RAG

   1. 문서 코퍼스 준비: 비공개 문서 모음을 수집하고 텍스트를 청크(chunk)로 분할한다.
   2. 임베딩과 저장: 청크를 임베딩(embedding)해 벡터 데이터베이스에 넣는다.
   3. 고정 top-k 검색: 질문이 들어오면 정해진 검색 기법으로 상위 k개 청크를 가져온다.
   4. LLM 생성: 검색 결과를 LLM에 전달해 문서 코퍼스에 대한 기본적인 챗봇 응답을 만든다.
   5. 고정된 단계의 한계: 청킹·임베딩·검색·생성이 정해진 기법과 순서로 실행되므로, 질문의 맥락에 맞게 검색 전략을 바꾸기 어렵다.

2. 현대 에이전트의 검색 방식

   1. 에이전트 루프와 도구 사용: 모델과 에이전트 하네스가 발전하면서 여러 번 생각하고 도구를 호출하는 루프가 훨씬 좋아졌다.
   2. 추론과 컨텍스트의 분리: 에이전트가 목표를 추론하는 부분과 실제 문서·도구·데이터에 접근하는 부분이 더 명확히 나뉜다.
   3. 검색 복잡성의 상향 이동: Claude Code, Claude Code Work, OpenClaw, Codex 같은 범용 에이전트에서는 검색 복잡성이 에이전트 레이어에 내장되기 시작했다.
   4. 검색어의 자율 선택: 에이전트는 가장 좋은 키워드와 검색어를 스스로 추론해 입력한다.
   5. 반복 탐색: 검색 도구 자체가 단순해도 에이전트가 올바른 질의를 만들고 결과를 확인하며 다시 검색할 수 있어 과업을 해결한다.

1.2. 컨텍스트와 오케스트레이션이 스택 위로 올라오다

1. 컨텍스트 윈도우 관리에서 컨텍스트 연결로

   1. 초기 관심사: 생성형 AI 초반 2년 반 동안에는 컨텍스트 윈도우가 넘치지 않도록 관리하는 일이 주요 논점이었다.
   2. 새로운 관심사: 컨텍스트 압축(compaction)과 긴 컨텍스트(long context)가 발전하면서, 올바른 MCP 서버·스킬·태스크를 연결해 에이전트가 일을 수행하게 만드는 문제가 더 중요해졌다.

2. 에이전트 오케스트레이션의 추상화

   1. 코딩 에이전트의 발전: 코딩 에이전트가 더 강력해지고 작업을 정의하는 추상화가 코드에서 상위 수준으로 이동했다.
   2. 영어 중심의 프로그램 정의: 2023~2025년에는 Python import나 TypeScript 코드로 프로그램을 만들었다면, 이제는 영어로 만들고 싶은 작업과 프로그램을 정의하는 비중이 커졌다.
   3. 비기술 직무의 런북: 소프트웨어 엔지니어뿐 아니라 마케팅·고투마켓(GTM) 같은 비기술 조직도 영어로 런북(runbook)과 목표를 정의하고 AI가 올바른 과업에 정렬되도록 할 수 있다.

1.3. 지식 노동의 다음 단계

1. 질문 응답에서 종단 간 업무로

   1. 과거: AI에게 단순한 질문을 던지고 답을 얻는 수준이었다.
   2. 현재: 영어만으로 종단 간(end-to-end) 과업을 정의하고 해결할 수 있다.
   3. 반복 가능한 프로그램: 영어로 정의한 업무를 반복 가능한 프로그램으로 컴파일해 규모 있게 실행할 수 있다.

2. 자율성이 커지는 미래

   1. 장기 과업: 에이전트가 스스로 루프를 돌며 긴 시간 동안 목표를 달성한다.
   2. 목표와 채점 기준: 사용자가 모든 작업을 영어로 상세히 적지 않고 목표와 scoring rubric만 제시할 수도 있다.
   3. 컨텍스트 활용: 에이전트는 접근 가능한 모든 컨텍스트를 사용해 목표를 풀고, 컨텍스트 레이어의 품질이 결과의 상한을 결정한다.

2. 문서가 에이전트 컨텍스트의 핵심인 이유

아무리 지능적인 에이전트라도 무엇을 해야 하는지와 조직의 지식에 접근할 수 없다면 가치를 만들 수 없다.

2.1. 컨텍스트가 곧 가치의 원천이다

1. 필요한 컨텍스트의 구성

   1. 업무 지시: 실제 과업과 목표가 에이전트가 해야 할 일을 정한다.
   2. 조직 지식: 에이전트가 업무를 수행할 때 참고해야 할 회사의 문서와 데이터가 필요하다.
   3. 웹 컨텍스트: 웹 검색 결과와 외부 웹 정보가 필요한 경우가 많다.
   4. 도구와 연결: MCP 서버·스킬·커넥터가 에이전트를 업무 시스템에 연결한다.
   5. 구조화 데이터: Snowflake·Databricks 같은 데이터 웨어하우스에 저장된 정보도 컨텍스트가 된다.

2. 문서 저장소에 갇힌 지식

   1. 조직의 문서 지식 중 약 90%가 SharePoint, Box, Dropbox, S3 같은 문서 컨테이너에 잠겨 있다.
   2. PDF, PowerPoint, Word, Excel은 사람에게는 익숙한 저장 형식이지만 에이전트가 바로 이해할 수 있는 표현은 아니다.
   3. 문서 컨테이너를 읽고 조작할 수 있는 도구를 만들어야 거대한 비정형 컨텍스트가 실제 업무에 쓰인다.

2.2. 문서는 비정형 컨텍스트의 보편적 컨테이너다

1. 기존 문서의 규모

   1. PDF·PowerPoint·Word·Excel에는 인간이 만든 지식이 10조 페이지 이상 저장돼 있다.
   2. 문서량은 기존 업무 자료에 그치지 않고, 에이전트가 생성하는 Markdown·HTML 같은 에이전트 네이티브 형식으로도 기하급수적으로 늘어난다.

2. LlamaIndex의 위치

   1. LlamaIndex는 2023년에 RAG 프레임워크로 시작해 advanced RAG 기법을 널리 알렸다.
   2. 현재는 에이전트가 문서를 읽고 문서 위에서 작업하도록 돕는 문서 인프라를 지향한다.
   3. 모델과 에이전트 하네스가 좋아져도 문서 컨텍스트를 제대로 해제하는 일이 핵심이라는 판단을 둔다.

3. 에이전트 네이티브 문서 플랫폼의 세 레이어

문서 플랫폼은 파싱, 의미·저장, 반복 워크플로우가 이어지는 구조로 설계해야 한다.

3.1. 문서 파싱 레이어

1. 파일을 해석 가능한 컨텍스트로 바꾸기
   1. PDF·PowerPoint·Word의 대량 파일을 디지털화한다.
   2. 에이전트가 읽기 좋은 정확하고 토큰 효율적인 표현으로 변환한다.
   3. Markdown, 메타데이터 등 에이전트가 문서 위에서 작업할 수 있는 출력을 제공한다.

3.2. 의미·저장 레이어

1. 사람용 파일 시스템을 에이전트 인터페이스로 바꾸기
   1. 사람이 Microsoft Word를 열거나 파일 시스템을 탐색하는 방식만으로는 에이전트 작업을 표현하기 어렵다.
   2. 문서를 수집·저장하고 에이전트가 문서를 검색·읽기·관리·조작할 수 있는 인터페이스가 필요하다.
   3. 문서에서 대규모로 구조화된 정보를 추출해 downstream 데이터베이스나 업무 시스템에 넣어야 한다.

3.3. 반복 문서 워크플로우 레이어

1. 일반 에이전트와 전문 워크플로우의 분리

   1. 인보이스 처리, KYC(Know Your Customer), 보험 청구처럼 반복되는 업무는 매번 범용 에이전트에 맡길 필요가 없다.
   2. 전문화한 워크플로우를 개발해 비용과 정확도를 세밀하게 조정하면 목표 달성 가능성을 높일 수 있다.
   3. 사람이 반복적으로 서류를 훑고 데이터를 입력하던 일을 에이전트 워크플로우로 자동화할 수 있다.

2. 아직 남은 영역

   1. 에이전트 네이티브 문서 형식은 더 발전해야 한다.
   2. 문서 버전 관리와 문서 편집은 아직 완전히 해결되지 않았다.
   3. hill climbing as a service를 비롯해 사람과 에이전트가 문서를 함께 다루는 종합 소프트웨어에는 미해결 과제가 남아 있다.

4. 문서 OCR과 파싱이 어려운 이유

문서 OCR(Optical Character Recognition)은 단순히 글자를 읽는 문제가 아니라, 파일이 표현한 시각적 구조와 의미를 복원하는 문제다.

4.1. PDF는 표시용 포맷이지 이해용 포맷이 아니다

1. 바이너리의 한계

   1. 에이전트는 raw PDF 파일 바이너리를 그대로 받아 의미를 만들기 어렵다.
   2. PDF는 기계가 해석하기 위한 구조보다 화면 표시와 인쇄를 위해 설계됐다.

2. 텍스트와 표의 표현

   1. PDF 텍스트는 문장·단락이 아니라 좌표를 가진 개별 글리프(glyph)에 가깝게 저장된다.
   2. 표는 표 객체가 아니라 선분과 테두리, 특정 셀 위치에 그려진 텍스트의 조합으로 표현되는 경우가 많다.
   3. 에이전트가 어떤 문자와 도형이 어떤 셀·열·행에 대응하는지 추론해야 하므로 원본만으로는 난도가 높다.

3. 읽기 순서의 불확실성

   1. 다단 편집에서는 PDF에 저장된 문자의 순서가 사람이 읽는 순서와 다를 수 있다.
   2. 좌표에 따라 임의의 문자가 나열될 뿐이므로, 문단과 열의 관계를 별도로 복원해야 한다.

4.2. Word와 PowerPoint에도 구조 추론이 필요하다

1. 구조화의 장점과 잡음

   1. Word 문서는 PDF보다 구조화되어 있지만 맞춤형 XML 형식으로 저장된다.
   2. PowerPoint에도 비슷하게 구조 정보가 들어 있지만, 에이전트가 이해하는 데 불필요한 태그와 장식 정보가 많다.

2. 필요한 복원 작업

   1. 모든 XML 태그를 그대로 넣는 대신 형식·의미와 관련된 메타데이터만 들어 올려야 한다.
   2. 태그를 무시하면서도 페이지 전체 구조를 볼 수 있도록 문서를 렌더링해야 한다.
   3. 네이티브 XML을 그대로 에이전트에 전달하는 방식보다 해석 가능한 포맷으로 변환하는 편이 훨씬 큰 향상을 낸다.

4.3. 세 가지 파싱 접근법

1. 휴리스틱·파이프라인 기반 접근

   1. 텍스트를 분석하고 서로 가까운 조각을 클러스터링한다.
   2. 표·문단 같은 요소를 식별해 해석 가능한 출력 표현으로 만든다.
   3. PyPDF와 PyMuPDF 같은 오픈소스 라이브러리가 이런 접근의 예다.

2. 비전 기반 접근

   1. VLM(Vision-Language Model)에게 문서 이미지를 한 번에 텍스트로 바꾸도록 요청한다.
   2. 시각 구조를 읽을 수 있어 복잡한 레이아웃에서 상당한 향상을 얻는다.
   3. 텍스트만 있는 페이지에서 환각이 생길 수 있고 비용이 매우 높다.
   4. 문서 처리 도구에 필요한 의미·근거(grounding)가 부족할 수 있다.

3. 하이브리드 접근

   1. 파일 컨테이너와 바이너리를 깊이 이해하는 파이프라인과 시각 모델을 결합한다.
   2. 문서 종류에 맞게 최신 Gemini·GPT·Opus의 시각 이해 능력을 증류(distill)해 대규모 처리용 워크플로우로 만든다.
   3. 비용과 정확도의 파레토 최전선(Pareto frontier)을 노릴 수 있다.

5. 정확도·비용·지연시간의 파레토 최전선

문서 파싱은 모든 파일에 같은 모델을 쓰는 문제가 아니라, 업무 위험과 처리 지연에 맞는 지점을 선택하는 문제다.

5.1. 전문화한 문서 OCR의 장점

1. 범용 모델보다 유리한 이유

   1. 문서 OCR은 특정 데이터 유형에 집중하므로 최신 프런티어 모델 자체보다 정확하고 저렴한 파레토 곡선을 만들 여지가 크다.
   2. LlamaIndex는 PDF 엔진뿐 아니라 Word·PowerPoint 등 기반 엔진을 최적화한다.
   3. 에이전트 하네스가 저렴한 특화 모델과 프런티어 모델 사이를 자동 라우팅한다.
   4. 표·차트 등 특정 문서 요소에 집중하는 파라미터 효율적인 특화 문서 VLM도 사용한다.

2. 기업 문서의 긴 꼬리

   1. 금융 서비스, 보험, 제조, 법률, 정부 조직에는 서로 다른 복잡한 문서 유형이 대량으로 존재한다.
   2. 일반 모델 대부분은 이런 긴 꼬리 문서를 대규모로 처리할 준비가 되지 않았다.
   3. 다양한 문서 유형에서 컨텍스트를 풀어내려면 문서 이해 자체의 기술적 프런티어를 확장해야 한다.

5.2. ParseBench와 평가 기준

1. 벤치마크 구성

   1. ParseBench는 에이전트를 위한 엔터프라이즈 문서 벤치마크다.
   2. 사람의 검증을 거친 2,000페이지를 포함한다.
   3. 표·차트·내용 충실도(content faithfulness)·의미론적 포맷을 측정한다.
   4. 문법적으로 텍스트가 맞는지보다 AI 에이전트가 실제로 문서를 이해하는지를 평가하도록 설계됐다.

2. 공개성과 비교 축

   1. parsebench.ai에서 공개되고 Hugging Face와 Kaggle에서도 사용할 수 있다.
   2. 프런티어 모델, 오픈 웨이트 모델, 특화 OCR 솔루션을 포함해 약 50개 모델을 비교한다.
   3. 목표는 정확도가 높고 비용이 낮은 왼쪽 위의 파레토 곡선이다.
   4. 문서 복잡도가 높아질수록 이해가 100% 해결된 문제가 아니라는 사실이 드러난다.

5.3. 세 가지 운영 영역

1. 고정확도 영역

   1. 일부 기관은 99%에서 거의 100%의 정확도를 요구한다.
   2. 잘못 추출하면 재무 모델 전체가 망가지거나, 사기 탐지에 잘못 걸리는 등 손실이 매우 크다.
   3. 보험·금융 서비스 같은 규제 산업은 페이지당 비용을 더 지불하더라도 에이전트의 깊은 추론을 사용해 올바른 형식의 결과를 얻으려 한다.

2. 저비용 대량 인덱싱 영역

   1. SharePoint에서 계속 갱신되는 백만 개 이상의 문서를 하루에 처리해 RAG 지식베이스 검색용으로 색인해야 하는 경우가 있다.
   2. 결과가 아주 부정확해서는 안 되지만, 충분히 좋은 에이전트가 원문으로 들어가 정확한 정보와 인용·근거를 다시 찾을 수 있다.
   3. 따라서 비용 제약을 최우선으로 한 확장 가능한 오프라인 인덱싱 파이프라인이 적합하다.

3. 실시간·에이전트 루프 영역

   1. 실시간 파일 업로드로 1,000개 문서를 1분 안에 처리해야 한다면 VLM을 모두 동원하는 방식은 거의 모든 OCR 서비스에서 어렵다.
   2. 깊은 시각 검사를 병행하더라도 즉시 반응할 수 있는 매우 낮은 지연시간의 처리 경로가 필요하다.
   3. 빠른 기본 파싱을 에이전트 루프에 넣고, 정확도가 필요한 페이지만 느린 VLM으로 재처리하는 방식이 이 요구를 만족시킨다.

6. LightParse와 LlamaParse의 역할 분담

빠른 전체 스캔과 느리지만 깊은 시각 검사를 도구로 분리하면 대량 업로드와 정확한 분석을 함께 처리할 수 있다.

6.1. LightParse의 빠른 기본 경로

1. 도구의 성격

   1. LightParse는 Rust 기반의 오픈소스 파서다.
   2. 무료이며 MIT 또는 Apache 계열 라이선스로 제약 없이 사용할 수 있다.
   3. VLM이나 깊은 모델을 사용하지 않으면서도 정확한 Markdown 변환을 제공하는 가장 빠른 오픈소스 파서로 소개됐다.
   4. 한 번 클릭해 설치할 수 있는 스킬로 제공돼 선호하는 AI 에이전트에 쉽게 연결된다.

2. 에이전트 루프에서의 사용

   1. Claude Code, Claude Cowork, Codex 같은 에이전트에 1,000개 PDF를 업로드하면 LightParse가 먼저 모든 문서를 매우 빠르게 스캔한다.
   2. 전체 내용을 효율적으로 훑어 문서 구조와 검색 가능한 텍스트를 만든다.
   3. 이 단계는 실시간 업로드와 대규모 인덱싱의 지연시간·비용을 낮춘다.

6.2. LlamaParse와 VLM의 깊은 경로

1. 선택적 정밀 검사

   1. 에이전트가 표·차트가 있는 특정 페이지를 더 깊이 이해해야 한다고 판단하면 VLM 기반 파서를 호출한다.
   2. LlamaParse나 다른 프런티어 모델이 느린 처리를 수행해 값과 시각적 관계를 정확히 읽는다.
   3. 빠른 전체 패스와 선택적 정밀 패스를 결합하면 모든 페이지에 비싼 모델을 적용하지 않아도 된다.

2. 상용 문서 플랫폼

   1. LlamaParse는 LlamaIndex의 문서 처리·추출 상용 서비스다.
   2. 낮은 비용과 매우 높은 정확도를 함께 목표로 한다.
   3. 추출된 각 결과에 대해 원본 문서까지 거슬러 올라가는 세밀한 인용(granular citation)을 제공한다.
   4. 대규모 파이프라인 실행에서 confidence score를 제공하고, 특정 값을 시스템에 넣기 전에 확실하지 않은 결과를 표시할 수 있다.

7. 의미·저장 레이어의 구조화 추출과 검색

파싱된 문서를 읽는 것만으로 끝나지 않고, 업무 시스템이 사용할 구조화 데이터와 여러 탐색 수단을 제공해야 한다.

7.1. 구조화된 데이터 추출

1. 대량 업무의 예

   1. 백만 개의 인보이스, 경비 보고서, 영수증, 보험 청구서를 처리할 수 있어야 한다.
   2. 문서에서 얻은 필드를 downstream 데이터베이스나 다른 시스템에 넣을 구조화된 출력으로 돌려줘야 한다.

2. 사람의 서류 작업 자동화

   1. 사람이 종이를 훑고 내용을 데이터 입력하던 과정을 에이전트 워크플로우로 자동화한다.
   2. 인보이스·청구·계약·영수증 같은 형식에 맞춰 추출 스키마와 검증 규칙을 적용한다.
   3. confidence score와 원문 인용을 함께 사용해 불확실한 값을 자동 등록하지 않도록 한다.

7.2. 문서 검색의 확장된 도구 세트

1. 서로 다른 탐색 방식

   1. BM25는 어휘 기반 검색으로 정확한 용어 일치와 랭킹을 보완한다.
   2. grep은 빠르게 특정 문자열과 패턴을 찾는다.
   3. 벡터 검색은 의미적으로 가까운 내용을 찾는다.
   4. 읽기와 스크롤은 에이전트가 문서 전체의 앞뒤 맥락과 페이지 구조를 확인하게 한다.

2. 도구의 위치

   1. 이런 검색·읽기 기능은 LlamaIndex의 상용 플랫폼과 오픈소스 제공물 모두에서 활용된다.
   2. 중요한 점은 단일 top-k 검색에 의존하지 않고 에이전트가 목적에 맞는 검색 도구와 읽기 깊이를 선택하게 만드는 것이다.

8. 발표에서 남겨진 다음 과제와 마무리

문서 컨텍스트 레이어의 기반 기능은 빠르게 만들어지고 있지만, 에이전트와 인간이 문서에서 함께 일하는 완성형 플랫폼에는 아직 많은 연구·제품 과제가 남아 있다.

8.1. 시간 때문에 생략된 영역

1. 에이전트 네이티브 문서 형식, 문서 버전 관리, 문서 편집, hill climbing as a service 등은 상세 설명이 생략됐다.
2. 발표자는 전체 슬라이드를 온라인에 공유하겠다고 밝혔다.
3. 핵심 설명은 문서 파싱을 중심으로 진행됐고, 의미·저장 레이어의 추출·검색과 문서 워크플로우는 개념 수준으로 빠르게 훑었다.

8.2. 행사 현장의 마무리

1. 발표자는 시간을 조금 넘긴 점을 언급하며 참석자에게 시간을 내준 데 감사를 표했다.
2. 행사 부스는 LG47에 마련돼 있었다.
3. 이날 대형 피클볼(pickleball) 토너먼트도 열릴 예정이었다.

주요 발언 모음

“RAG in 2026”은 에이전트 하네스와 컨텍스트 레이어의 결합으로 이해해야 한다.

“Context really is everything.”

“You could have an infinitely smart agent, but your ability to actually get value out of this infinitely smart agent is giving it the right things to do and the right organizational context.”

“Documents are universal containers for unstructured context.”

“Document OCR is hard.”

“You really want the Pareto curve to be towards the left and up: extremely high accuracy, but also extremely low cost.”

“LightParse is surprisingly really, really good.”

“The agents will do a fast pass over all the documents first, and then use a VLM-based tool when they need to deeply understand a page with tables or charts.”

핵심 데이터 & 수치

• 2023년: LlamaIndex가 RAG 프레임워크로 시작했고, 나이브 RAG가 널리 쓰이던 시기다.
• 10조 페이지 이상: PDF·PowerPoint·Word·Excel에 저장된 인간 지식의 추정 규모다.
• 약 90%: SharePoint·Box·Dropbox·S3 같은 문서 컨테이너에 잠긴 조직 문서 컨텍스트의 비중으로 제시됐다.
• 2,000페이지: ParseBench가 사람 검증을 거쳐 포함한 엔터프라이즈 문서 페이지 수다.
• 약 50개: ParseBench가 비교하는 프런티어·오픈 웨이트·특화 OCR 모델 규모다.
• 99%~거의 100%: 금융·보험 등 규제 산업에서 요구되는 고정확도 처리 영역이다.
• 하루 백만 개 이상: SharePoint 지식베이스 색인을 위해 처리할 수 있는 대규모 저비용 인덱싱 사례다.
• 1,000개 문서 / 1분: 실시간 파일 업로드에서 제시된 처리 요구 사례다.
• 1,000개 PDF: LightParse로 에이전트가 초고속 기본 스캔을 수행하는 예시다.
• 20분 33초: Tech Bridge에 게시된 발표 영상의 길이다.

결론 및 시사점

1. RAG의 경계를 다시 정의해야 한다: 2026년의 RAG는 벡터 검색을 붙인 챗봇이 아니라, 에이전트가 검색어를 만들고 도구를 호출하고 결과를 재검증하는 컨텍스트 실행 계층이다.
2. 컨텍스트 접근성이 모델 지능을 현실의 가치로 바꾼다: 목표·평가 기준·조직 문서·웹·MCP·데이터 웨어하우스를 연결하지 못하면 더 똑똑한 모델도 업무 성과를 만들기 어렵다.
3. 문서는 가장 큰 비정형 데이터 자산이다: PDF·PowerPoint·Word·Excel에 잠긴 지식을 에이전트가 읽고 조작할 수 있는 표현으로 바꾸는 일이 엔터프라이즈 AI의 핵심 기반 작업이다.
4. 파싱은 반드시 구조를 복원해야 한다: PDF의 글리프 좌표, 표를 구성하는 선분과 셀 텍스트, 다단 읽기 순서, Office XML의 태그 잡음을 처리하지 않으면 검색과 추출의 근거가 무너진다.
5. 하이브리드 파싱이 비용과 정확도의 균형을 잡는다: 저렴한 파이프라인으로 전체 문서를 빠르게 스캔하고, 표·차트처럼 중요한 페이지에만 VLM을 호출하는 구조가 대규모 에이전트 루프에 적합하다.
6. 운영 영역에 따라 최적점이 다르다: 금융·보험의 99% 이상 정확도, 백만 문서 규모의 저비용 인덱싱, 1분 안에 1,000개 문서를 처리하는 실시간 루프는 서로 다른 모델 라우팅과 비용 정책을 요구한다.
7. 검색 도구는 단일 벡터 검색을 넘어야 한다: BM25·grep·벡터 검색·읽기·스크롤을 함께 제공하고 에이전트가 목적에 맞는 깊이와 방식을 선택하게 해야 한다.
8. 구조화 추출은 업무 시스템 연결부다: 인보이스·계약·영수증·청구서에서 confidence score와 원문 인용을 갖춘 결과를 만들어야 자동 입력과 사람 검토를 안전하게 결합할 수 있다.
9. 평가는 문법적 정확성이 아니라 에이전트의 이해력이어야 한다: 표·차트·의미론적 포맷·내용 충실도를 사람 검증 데이터로 측정하는 ParseBench 같은 평가가 필요하다.
10. 문서 플랫폼은 공동 작업 공간으로 진화해야 한다: 파싱과 검색 이후에는 버전 관리·편집·에이전트 네이티브 포맷·반복 워크플로우까지 인간과 에이전트가 함께 문서에서 일하는 구조를 완성해야 한다.

핵심 요약 (20줄)

1. Jerry Liu는 2026년 RAG를 에이전트 하네스와 문서 컨텍스트 레이어가 결합된 시스템으로 정의한다.
2. 2023년 나이브 RAG는 문서를 청크로 나누고 임베딩해 벡터 데이터베이스에 저장한 뒤 고정 top-k를 검색했다.
3. 현대 에이전트는 검색어를 스스로 만들고 도구 호출과 재검색을 반복해 검색 복잡성을 에이전트 레이어로 끌어올린다.
4. 컨텍스트 압축과 긴 컨텍스트가 발전하면서 MCP 서버·스킬·태스크를 올바르게 연결하는 일이 더 중요해졌다.
5. 영어는 코드 대신 업무 목표와 런북을 정의하는 상위 수준의 프로그램 언어처럼 쓰이고 있다.
6. 앞으로 에이전트는 상세한 작업 지시보다 목표와 scoring rubric만 받아 장기 과업을 자율적으로 해결할 수 있다.
7. 조직의 핵심 컨텍스트는 웹·MCP·데이터 웨어하우스와 함께 SharePoint·Box·Dropbox·S3의 문서에 저장돼 있다.
8. PDF·PowerPoint·Word·Excel에는 10조 페이지 이상의 인간 지식이 잠겨 있어 문서 컨텍스트 레이어의 시장이 크다.
9. 에이전트 네이티브 문서 플랫폼은 파싱 레이어, 의미·저장 레이어, 반복 문서 워크플로우 레이어로 구성된다.
10. PDF는 표시와 인쇄를 위해 설계돼 글리프 좌표·선분·셀 텍스트 형태로 저장되므로 에이전트가 원본을 직접 이해하기 어렵다.
11. 다단 PDF의 문자 저장 순서는 사람의 읽기 순서와 다를 수 있어 레이아웃과 의미를 별도로 복원해야 한다.
12. Word와 PowerPoint는 XML 구조를 제공하지만 불필요한 태그가 많아 의미와 형식을 선별하고 페이지 구조를 렌더링해야 한다.
13. 휴리스틱 파이프라인, VLM 기반 변환, 두 방식을 결합한 하이브리드 파싱이 주요 접근법이다.
14. 하이브리드 파싱은 특정 문서 유형에 모델을 특화해 범용 프런티어 모델보다 높은 정확도와 낮은 비용을 목표로 한다.
15. ParseBench는 사람 검증 2,000페이지와 약 50개 모델 비교를 통해 표·차트·충실도·의미론적 포맷을 평가한다.
16. 금융·보험의 고정확도 처리, 백만 문서의 저비용 인덱싱, 실시간 업로드는 서로 다른 파레토 최적점을 요구한다.
17. LightParse는 Rust 기반 무료 오픈소스 Markdown 파서로 문서 전체를 빠르게 스캔하는 기본 경로를 맡는다.
18. 에이전트는 표·차트처럼 중요한 페이지만 LlamaParse나 다른 VLM 도구로 재처리해 정확도와 속도를 함께 확보한다.
19. 문서 시스템은 구조화 추출·원문 인용·confidence score·BM25·grep·벡터 검색·읽기·스크롤을 제공해야 한다.
20. 문서 버전 관리·편집·에이전트 네이티브 포맷까지 갖춘 인간-에이전트 공동 작업 공간이 문서 컨텍스트 레이어의 다음 목표다.