Epstein 파일을 Jmail로 파싱하기

원문 제목: Parsing the Epstein Files for JMail — Palak Agarwal & Omar Alhait, Reducto
URL: https://www.youtube.com/watch?v=HGfsfKaVuGY
날짜: 2026-10-11
채널: AI Engineer
영상 길이: 29분 28초
Video ID: HGfsfKaVuGY
발표자: Billy(Reducto 개발자 관계), Omar Alhait(Reducto 창립 엔지니어)
주제: 비정형·스캔 문서의 구조화, Jmail 및 Epstein 파일 분석 사례

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

==수백만 페이지의 스캔 PDF, 표, 손글씨, 불완전한 비식별화 문서를 AI가 실제 제품에서 쓸 수 있는 데이터로 바꾸려면 문서 분석을 추출보다 먼저 수행하고, 그 위에 목적별 스키마와 후처리 파이프라인을 쌓아야 한다.==

• 깨끗한 PDF만 처리하는 모델과 달리 실제 정부·기업 문서는 기울어진 스캔, 표, 차트, 손글씨, PDF 메타데이터가 뒤섞여 있다.
• Jmail은 Epstein 관련 300만 페이지 이상의 문서를 Reducto로 분석해 검색 가능한 메일함과 여행·캘린더 등 파생 제품으로 확장했다.
• 빠른 데모용 스키마와 문서 내용을 먼저 분석해 정확도를 높이는 스키마 생성을 구분해야 하며, 최종 성능은 고정된 벤치마크와 자체 데이터셋으로 검증해야 한다.

Reducto는 모델 앞단의 문서 이해 계층이다. 문서를 사람이 보는 것처럼 래스터화하고 OCR·시각언어 모델·메타데이터·후처리를 결합해 구조를 복원한 다음, 분석·분할·추출·편집·분류를 제품 파이프라인에 제공한다. Jmail 사례의 핵심은 문서 추출 자체가 아니라, 신뢰할 수 있는 기본 데이터셋을 만든 뒤 그 위에 사용자가 실제로 탐색하고 공유할 제품을 빠르게 올렸다는 데 있다.

1. Reducto가 해결하는 문서 이해 문제

깨끗하게 정리된 PDF에 고급 모델을 호출하는 일보다, 현실의 문서를 일관된 데이터로 바꾸는 일이 훨씬 어렵다.

1.1. 비정형 문서가 AI의 병목이 되는 이유

1. 현실의 문서는 구조가 무너져 있다

   1. 입력의 다양성: 스캔 문서, 기울어진 페이지, 차트, 복잡한 양식과 표, 여러 사람의 읽기 어려운 손글씨가 한 문서 묶음 안에 공존한다.
   2. 읽기 순서의 불확실성: 표지 한 장만 보더라도 어떤 열부터 읽을지, 주석과 본문을 어떻게 연결할지 주관적인 판단이 개입된다.
   3. 기본 임베딩의 한계: 텍스트만 임베딩하면 시각적 배치와 셀·필드 간 관계가 사라지므로, 사람이 페이지 전체를 보는 방식에 가까운 처리가 필요하다.

2. 래스터화·OCR·검증을 함께 사용한다

   1. 사람처럼 보기: Reducto는 문서를 래스터화해 페이지의 시각적 구조를 살핀다. 단순한 텍스트 임베딩에 의존하지 않는다.
   2. 불확실성 처리: OCR 프레임워크는 답을 한 번 통과시키고 끝내지 않는다. 불확실한 부분을 식별하고 수정한 뒤 다음 단계로 넘긴다.
   3. 하이브리드 OCR: 특정 설정에서는 엄격한 OCR 결과와 PDF 내부 메타데이터 중 더 신뢰할 수 있는 정보를 지능적으로 선택한다. 편집자의 품질과 PDF 생성 방식이 달라 결과가 흔들리므로 단일 규칙으로 해결되지 않는다.

1.2. 제품 표면과 다섯 가지 핵심 기능

1. 모델 앞단의 문서 계층

   1. 복잡성의 격리: 애플리케이션 개발자는 문서 포맷 처리와 후처리에 매달리지 않고 실제 제품 로직에 집중할 수 있다.
   2. 다섯 가지 기능: 분석(analysis), 분할(division), 추출(extraction), 편집(editing), 분류(classification)가 기본 축이다.

2. Studio에서 생산 파이프라인으로 이어진다

   1. 셀프서비스 실험: 세션 참가자는 Studio에 접근해 문서를 올리고 Run을 눌러 결과를 실시간으로 확인할 수 있다.
   2. 설정의 반복: 고급 설정을 바꾸면서 추출 결과를 즉시 비교하고, 결과가 기대와 맞는지 확인한다.
   3. 배포 경로: 검증된 결과는 직접 API 호출이나 파이프라인 코드 스니펫으로 재현해 곧바로 프로덕션으로 옮길 수 있다.

2. Jmail과 Epstein 파일 분석의 구성

문서 인프라가 문화적 사건을 탐색하는 여러 제품으로 전환되면서, 추출 결과 자체가 제품의 공통 사실 기반이 되었다.

2.1. 다섯 시간짜리 아이디어에서 문서 탐색 제품으로

1. Jmail의 출발점

   1. 제작 배경: Epstein 파일이 공개된 지난해 11월, Riley Walls와 Luke가 약 5시간 만에 첫 Jmail을 만들었다.
   2. 핵심 경험: Jeffrey Epstein의 메일함에 로그인한 것처럼 보면서 그의 이메일을 탐색하는, Gmail을 변형한 형태였다.
   3. 아이디어의 맥락: Omar는 창립팀과 Reddit을 활용해 큰 문화적 사건을 대중에게 공개하는 방식을 고민하다가 이 제품 아이디어를 떠올렸다고 설명했다.

2. 메일함을 넘어선 제품군

   1. 파생 서비스: 메일함을 기반으로 드라이브, 항공편, 쇼핑, 사진, 캘린더와 유사한 여러 탐색 표면이 만들어졌다. 발표 중 JDrive, JFlights, JAmazon, JPhotos, JCal 등의 이름이 언급됐다.
   2. 공통 기반: 여행 문서, 메일, 일정 등 서로 다른 문서군에도 목적별 추출 설정을 적용해 같은 분석 결과를 다른 제품 경험으로 재사용했다.
   3. 제품화의 교훈: 처음부터 거대한 범용 챗봇을 만들기보다, 구조화된 사실 데이터 위에 사용자가 바로 탐색할 수 있는 구체적인 제품을 올리는 편이 강력하다.

2.2. 규모와 데이터 난이도

1. 관심과 사용량

   1. 누적 방문: 2월 기준 Jmail은 4억 5,000만 회가 넘는 방문을 기록했다.
   2. 사용자 수: 1,800만 명이 Jmail에 접근했다는 수치가 제시됐다.
   3. 산업적 의미: 구조화되지 않은 데이터에서 가치를 꺼내는 문제는 특정 사건에 한정되지 않으며, 많은 고객사의 공통 과제라는 점을 보여준다.

2. 처리한 원자료

   1. 문서량: 300만 페이지가 넘는 비식별화 PDF, 스캔 문서, 정리되지 않은 정부 파일을 분석했다.
   2. 문서 형태: 복잡한 양식과 표부터 여러 사람의 판독하기 어려운 손글씨까지 포함됐다.
   3. 신뢰의 기준: 이 정도 규모에서는 몇 장의 멋진 데모가 아니라 문서 묶음 전체에서 누락·오독·잘못된 연결을 관리하는 능력이 핵심이 된다.

3. JFlights로 본 목적별 추출 파이프라인

여행 이력을 만들려면 문서를 한 번 읽는 것만으로 부족하며, 여행이라는 질문에 맞는 별도 스키마와 검증 절차가 필요하다.

3.1. 손글씨와 여행 기록을 제품으로 바꾸기

1. 추출 대상의 재구성

   1. 문서에서 여정으로: Epstein과 관련 인물의 여행 문서를 모두 모은 뒤, 여행 정보만 뽑도록 별도의 추출 구성을 적용한다.
   2. 질문의 구체화: 누가 비행했는지, 외교관 등 어떤 사람이 이동했는지, 섬을 오간 시점이 언제인지처럼 제품이 보여줄 질문을 먼저 정한다.
   3. 가장 큰 장애물: 항공편 기록에 포함된 손글씨와 불량 스캔이 여행 경로를 복원하는 데 가장 어려운 입력이었다.

2. Studio에서 대규모 처리까지

   1. 작은 실험: Omar는 문서를 업로드하고 Run을 눌러 Reducto가 파싱한 결과를 확인하는 작업용 초안을 먼저 만들었다.
   2. 정확도 점검: 백만 개에 가까운 문서로 확장하기 전에 소수의 샘플에서 추출 정확도가 기대에 맞는지 확인하고 필요한 수정을 반영했다.
   3. 단일 구성의 범용성: 서로 다른 형식의 문서가 많았지만 하나의 항공편 추출 체계 안에서 다양한 사례를 처리하도록 구성했다.

3.2. 인프라 압박과 사실 데이터셋

1. 빠른 분석의 운영 문제

   1. 집중 처리: 첫 공개판을 맞추기 위해 문서를 매우 빠르게 분석했고, 인프라에 상당한 부하가 걸렸다.
   2. 현장 일화: 당시 당직이었던 Alvin에게 Omar가 밤마다 연락했고, Alvin은 “조금만 천천히 할 수 없느냐”는 취지의 메시지를 보냈다.
   3. 마감 준수: 압박 속에서도 분석은 일정에 맞춰 끝났다.

2. 한 번 만든 기반의 재사용

   1. 기본 사실 집합: 분석된 문서 묶음을 공통 사실 데이터셋으로 간주했다.
   2. 제품 다변화: 그 기반에서 Jmail, JFlights, JCal 등 여러 제품을 만들 수 있었다.
   3. 검증 후 공개: Omar는 결과가 기대한 형태인지 직접 살핀 후 게시하고, 같은 설정을 API나 코드 스니펫으로 반복 호출하는 단순한 흐름을 강조했다.

4. 스키마 설계, 후처리, 정확도 개선

추출 스키마는 원하는 출력의 모양을 결정하는 붓이며, 문서 분석과 도메인 지식이 들어갈수록 결과의 정확도와 재현성이 높아진다.

4.1. 빠른 스키마와 개선된 스키마

1. 요청한 구조를 즉시 만드는 방식

   1. JSON 스키마 생성: 빠른 스키마 생성은 언어 모델을 한 번 호출해 요청한 형태 그대로 JSON 스키마를 만든다.
   2. 적합한 상황: 화면에 빨리 결과를 띄우거나 아이디어를 검증하려는 초기 실험에 유리하다.
   3. 한계: 실제 문서에 어떤 필드와 예외가 있는지 충분히 보지 않으므로, 데이터셋의 특수성을 놓칠 수 있다.

2. 문서 분석을 선행하는 방식

   1. 문서 우선: 문서 안에 실제로 무엇이 들어 있는지 먼저 분석하고, 그 결과를 토대로 해당 문서군에 맞춘 스키마 설명을 만든다.
   2. 정확도 우선: 결과의 정확성이 중요하면 일반적인 빠른 생성보다 개선된 스키마 생성이 적합하다.
   3. 도구 사용: Studio의 개선된 스키마 생성 기능을 실행하면 문서를 먼저 훑은 뒤 데이터에 맞춰 추출 설명을 조정한다.

4.2. 복잡한 필드와 엔터티 연결

1. 대형 스키마의 현실

   1. 필드 수: 사례로 약 156개 필드를 가진 차트가 언급됐다.
   2. 중첩 구조: 스키마의 중첩은 네다섯 단계까지 올라갈 수 있고, 필요하면 사실상 어떤 정보 구조든 표현할 수 있다.
   3. 설계 기준: “세상의 모든 것을 정렬”하는 범용 스키마보다 실제 제품이 답해야 할 질문에 맞춘 필드 설계가 중요하다.

2. 추출 뒤의 후처리

   1. 엔터티 연결: 서로 다른 페이지나 모델 출력에서 같은 사람·조직·사건을 가리키는 정보를 연결한다.
   2. 인용 출처: 한 모델이 값을 추출하면 다른 모델이나 인용 템플릿이 그 값이 문서의 어느 부분에서 왔는지 확인한다.
   3. 연구 병목: 발표에서는 NVIDIA의 인용 식별 연구(제목은 “Find Everything”에 가까운 표현으로 언급됨)가 문서 속 인용을 빠르게 찾는 병목을 다룬다고 소개했다.

4.3. 도메인별 구성과 에이전트

1. 같은 문서 플랫폼, 다른 규칙

   1. 메타데이터 차이: PDF마다 메타데이터 형식과 편집 품질이 다르므로 동일한 처리 규칙만으로는 부족하다.
   2. 시스템 프롬프트: 별도 양식에 별도의 시스템 프롬프트와 설정을 적용해 특정 문서군에 맞는 출력을 만든다.
   3. 소프트웨어 에이전트: 여러 구성을 조합하고 특정 처리 목표를 자동으로 수행하는 에이전트 계층이 이 customization을 담당한다.

2. 구체적인 적용 예

   1. 로고 분류: Lincoln Financial과 Google처럼 서로 다른 로고를 구분하도록 추가 설명과 주장을 설정할 수 있다.
   2. 건축 도면: 읽기 어려운 건축 계획도는 레이아웃을 해석하는 프롬프트에 더 많은 시간을 투자하고, 여러 도면에서 설정이 얼마나 잘 맞는지 비교한다.
   3. 양식별 검증: 하나의 모델을 맹목적으로 믿기보다 문서군별 결과를 검토한 뒤 필요한 설정을 고정한다.

5. 비식별화와 편집 품질의 책임

문서에서 정보를 추출하는 것만큼, 공개하면 안 되는 정보를 실제로 가렸는지 확인하는 일이 중요하다.

5.1. PDF 편집과 레드랙션의 위험

1. 검은 박스만으로 충분하지 않다

   1. 편집 품질의 편차: 일부 파일은 제대로 비식별화됐지만, 일부는 편집 과정의 흔적이나 작성 주체가 드러날 수 있었다.
   2. 숨은 정보: PDF에 검은 상자를 올려놓는 것과 원문·메타데이터·레이어에서 정보가 제거된 것은 다르다.
   3. 검수 책임: 문서의 개인정보를 다루는 팀이라면 “가려야 할 것이 실제로 가려졌는가”를 직접 확인해야 한다.

2. Jmail 팀의 운영 판단

   1. 메타데이터 분석: Reducto는 PDF의 메타데이터도 함께 분석해 편집 방식과 문서 상태를 파악한다.
   2. 수동·자동 수정의 결합: 자동 결과를 그대로 공개하지 않고 팀이 많은 revision을 수행했다.
   3. 법적 리스크: 부적절한 공개로 다른 사람의 데이터가 노출되면 서비스 운영자에게 법적 책임이 돌아갈 수 있으므로 정확한 편집 검증이 필수다.

6. 평가, 벤치마킹, 실제 도입 전략

문서 추출 성능은 모델의 주장만으로 결정되지 않으며, 사용자의 문서와 올바른 설정으로 반복 측정해야 한다.

6.1. 왜 단일 벤치마크만으로 부족한가

1. 데이터 유형에 따른 성능 변화

   1. 학습 범위: 모델은 특정 데이터 유형에 맞춰 학습되므로 모든 문서군에서 같은 성능을 보장하지 않는다.
   2. 장기 문맥 검색: 긴 문서에서 필요한 정보를 회수하는 능력이 부족하면 별도의 개선 작업이 필요하다.
   3. 추출 난이도: 한 건의 정답을 찾는 것이 아니라 “건초더미 속 모든 바늘”을 찾아야 하므로 연구 난도가 높다.

2. 공개 벤치마크와 고객별 벤치마크

   1. Reducto의 계획: 업계가 직접 모든 솔루션을 재시험하지 않아도 비교할 수 있도록 새로운 벤치마크를 공개할 예정이라고 밝혔다.
   2. 고객별 현실: 실제 고객은 각자 문서와 평가 기준이 있어 자체 벤치마크를 만든다.
   3. 설정의 영향: 경쟁 비교에서 API를 잘못된 설정으로 호출하면 결과가 나빠질 수 있으므로, Reducto 팀은 설정을 조정한 뒤 직접 테스트하도록 돕는다.

6.2. 도입 단계

1. Vibe Eval

   1. 작은 표본: 간단한 데이터셋을 준비하고 Studio에서 결과가 말이 되는지 빠르게 확인한다.
   2. 질문 중심 검토: 출력 필드, 읽기 순서, 출처, 누락 여부가 제품의 질문에 맞는지 본다.
   3. 빠른 반복: 스키마와 프롬프트를 바꾸며 어떤 설정이 데이터에 맞는지 확인한다.

2. 체계적 평가

   1. 확장 표본: 실제 도입을 검토할 때는 100개 또는 1,000개 문서로 평가를 확장한다.
   2. 직접 비교: 다른 문서 서비스와 동일한 샘플·동일한 출력 기준으로 비교한다.
   3. 전문 지원: 고객 평가팀과 함께 설정을 조정하고 결과를 검증할 수 있다.

7. 제품 선택과 데이터 작업에 대한 Q&A

문서 추출 기술의 가치는 모델 이름보다 데이터 품질, 제품 경험, 반복 가능한 분류 작업의 결합에서 나온다.

7.1. RAG 챗봇보다 강한 제품 표면

1. 초기의 잘못된 방향

   1. RAG 아이디어: Omar는 처음에는 이메일에 무엇이든 질문할 수 있는 RAG 기반 채팅 애플리케이션을 생각했다.
   2. 잠재적 사용자: 기자처럼 대량 이메일을 빠르게 질의해야 하는 사람에게는 유용할 수 있었다.
   3. 재고: 그러나 단순한 채팅창은 문서 추출 결과가 가진 구조와 탐색 가능성을 충분히 제품화하지 못한다는 판단으로 이어졌다.

2. 사용량이 증명한 방향

   1. 구체적 경험: 수억 건의 방문과 수천만 명 규모의 사용은 좋은 문서 추출 솔루션 위에 좋은 제품을 만들 때 가치가 커진다는 점을 보여준다.
   2. 구조화의 재사용: 메일 검색, 여행 탐색, 일정 확인 등 사용자 목적에 맞는 UI는 같은 사실 기반을 각기 다른 흐름으로 보여준다.
   3. 산업의 대표 사례: Jmail은 특별한 사건의 재미를 넘어, 사방에 존재하는 비정형 데이터를 먼저 추출하고 그 위에서 필요한 일을 수행하는 산업의 전형적인 사례가 된다.

7.2. 분류와 학습 데이터의 노동

1. 가장 지루하지만 빠질 수 없는 단계

   1. 데이터 팀: 새 모델을 학습하려면 많은 문서를 분류하고 결과의 무결성을 확인하는 전담 작업이 필요하다.
   2. 반복성: 이 일은 어렵고 지루하며 반복적이지만, 자동으로 건너뛸 수 없다.
   3. 모델의 토대: 분류가 쌓여야 학습 데이터셋이 만들어지고, 그 위에서 데이터를 조직하고 모델을 훈련할 수 있다.

2. 정확도를 높이는 맞춤화

   1. 문서별 로직: 특정 모델, 메타데이터 형식, 양식에 따라 별도 로직이 필요할 수 있다.
   2. 출력의 의도 명시: 원하는 설명과 필드를 설정에 넣을수록 복잡한 문서에서 결과가 목적에 가까워진다.
   3. 맞춤화의 경계: 범용 설정을 유지하되, 로고·도면·여행 기록처럼 실패 비용이 큰 영역에는 별도 구성을 적용한다.

8. 실습 세션과 재현 가능한 실행 흐름

참가자가 직접 문서 추출 문제를 정의하고, 결과를 확인한 뒤, 프로덕션에 넣을 수 있는 형태로 발전시키는 흐름이 제안됐다.

8.1. 30분 워크숍

1. 시작

   1. 접속: QR 코드로 Studio에 등록하고, 제공된 내용을 Cloudcode·Codex 같은 코딩 도구에 복사해 문서 추출을 시작한다.
   2. 문제 선택: 완성된 제품이 아니어도 아이디어나 간단한 요청만으로 실험할 수 있다.
   3. 지원: Reducto 팀이 참가자 사이를 돌며 설정, 모델 훈련, 사용법에 관한 질문에 답한다.

2. 공유와 검토

   1. 시간 배분: 약 30분 동안 작업하고, 종료 5분 전부터 결과를 보여준다.
   2. 평가 기준: 문서를 얼마나 잘 읽었는지뿐 아니라, 어떤 스키마를 선택했고 결과를 어떤 제품 흐름으로 연결했는지도 볼 수 있다.
   3. 동기 부여: 문서 추출 결과를 보여준 참가자에게 선물과 특별 상품을 제공한다.

주요 발언 모음

“Reducto는 모델 바로 앞에 놓이는 계층이다. 복잡한 포맷과 후처리를 우리가 맡으니 실제 제품을 만드는 데 집중할 수 있다.”

“추출 스키마는 Reducto 팔레트 위의 붓과 같다. 어떤 결과를 얻을지 스키마가 안내한다.”

“추출은 건초더미에서 바늘 하나를 찾는 일이 아니라, 건초더미 속 모든 바늘을 찾는 일에 가깝다.”

“문서에서 무엇을 꺼낸 다음에는 원하는 일을 하면 된다. 이것이 고객들이 하는 일의 기본 개념이다.”

“좋은 제품을 혁신적이고 뛰어난 문서 추출 솔루션 위에 올리는 것이 여기서의 이중 성공을 만든다.”

핵심 데이터 & 수치

• 1억 800만 달러: Reducto가 지난 3년 동안 유치했다고 소개한 투자금이다.
• 20억 건 이상: Reducto가 고객을 위해 처리했다고 밝힌 문서 수다.
• 300만 페이지 이상: Jmail의 Epstein 관련 원자료에 포함된 비식별화 PDF·스캔·정부 문서 규모다.
• 5시간: Riley Walls와 Luke가 첫 Jmail을 만들었다고 소개된 시간이다.
• 4억 5,000만 회 이상: 2월 기준 Jmail 누적 방문 수다.
• 1,800만 명: 2월까지 Jmail에 접근한 사용자 수로 제시됐다.
• 약 156개 필드: 실제로 검토한 복잡한 차트의 한 사례다.
• 4~5단계: 스키마 중첩이 올라갈 수 있는 깊이로 설명됐다.
• 100~1,000개 문서: 빠른 Studio 검증 뒤 체계적인 평가로 넘어갈 때 권장된 표본 규모다.
• 30분 / 종료 5분 전: 현장 문서 추출 실습과 결과 공유에 배정된 시간이다.

결론 및 실행 시사점

1. 문서 AI의 첫 단계는 LLM 호출이 아니라 페이지 레이아웃·OCR·메타데이터·읽기 순서를 복원하는 분석이어야 한다.
2. 제품이 답해야 할 질문을 먼저 정하고, 그 질문에 맞는 목적별 추출 스키마를 설계해야 한다.
3. 빠른 스키마 생성은 아이디어 검증에 쓰고, 정확도가 중요하면 문서 분석을 선행하는 개선된 스키마 생성을 사용해야 한다.
4. 추출 결과에는 엔터티 연결과 인용 출처 후처리를 붙여 값이 어디에서 왔는지 추적 가능하게 만들어야 한다.
5. PDF의 검은 박스만 보고 비식별화가 끝났다고 판단하지 말고, 원문·레이어·메타데이터가 실제로 제거됐는지 별도로 검증해야 한다.
6. 좋은 문서 추출 모델도 데이터 유형과 설정에 따라 성능이 달라지므로, 작은 Vibe Eval 뒤 100~1,000개 문서의 자체 벤치마크로 확장해야 한다.
7. 한 번 만든 신뢰 가능한 사실 데이터셋을 검색, 여행, 캘린더처럼 목적별 제품에 재사용하면 단일 문서 파이프라인에서 여러 사용자 경험을 만들 수 있다.
8. RAG 챗봇을 먼저 만드는 대신 사용자가 실제로 탐색하고 행동할 수 있는 구체적인 제품 표면을 설계하면 구조화 데이터의 가치를 더 크게 전달할 수 있다.
9. 분류와 검수는 지루하지만 모델 성능과 데이터 무결성을 결정하는 핵심 작업이므로 자동화하더라도 사람의 평가 루프를 남겨야 한다.
10. 최종 공개 전에는 문서 추출 정확도뿐 아니라 개인정보 노출, 잘못된 엔터티 연결, 인용 누락, 편집 흔적까지 제품 품질의 일부로 검사해야 한다.