document-processing

2 개의 포스트

dropbox

범용 콘텐츠 처리 플랫폼 Riviera가 AI와 그 너머를 위해 어떻게 진화했는가 (새 탭에서 열림)

Dropbox의 콘텐츠 처리 플랫폼 Riviera는 파일 미리보기 서비스에서 출발해 Search, Replay, Sign, Dash 등 여러 제품이 공유하는 범용 변환 플랫폼으로 발전했다. 핵심 설계는 파일별·제품별 파이프라인을 따로 만드는 대신, PDF 변환·페이지 이미지 생성·텍스트 추출 같은 작은 변환 작업을 재사용 가능한 플러그인으로 조합하는 것이다. AI 제품의 확산으로 문서와 미디어를 일관된 형태로 준비하는 수요가 커지면서, Dropbox는 Riviera의 기능을 외부 개발자와 설계 파트너에게 API와 Model Context Protocol 도구로 공개했다. ## 미리보기 문제에서 시작된 플랫폼 - Dropbox는 300개가 넘는 파일 형식을 지원하며, 각 형식에서 썸네일, 전체 미리보기, 추출 텍스트, 스트리밍 매니페스트, 메타데이터 등 다양한 결과물을 생성해야 했다. - 파일 형식과 출력물마다 별도 서비스를 만들면 다음 문제가 발생한다. - 동일한 변환 로직이 여러 서비스에 중복됨 - 의존성, 패키지 버전, 설정이 서로 달라짐 - 유지보수와 운영 부담이 커짐 - Riviera는 모든 미리보기를 독립적인 기능으로 보지 않고, 재사용 가능한 작은 변환 단계의 조합으로 정의했다. - 예를 들어 PowerPoint 미리보기는 다음처럼 처리할 수 있다. - PowerPoint를 PDF로 변환 - PDF의 각 페이지를 이미지로 변환 - 생성된 이미지를 Dropbox 화면에서 표시 - PDF를 이미지로 바꾸는 단계는 PDF 자체의 미리보기나 다른 페이지 이미지 생성 작업에도 재사용할 수 있다. ## 조정과 실행을 분리한 아키텍처 - Riviera의 중앙 구성 요소는 변환 요청을 수집하고, 작업을 조합하며, 적절한 백엔드 워커에 분배한다. - 중앙 계층은 다음 기능을 담당한다. - 요청 유효성 검증 - 변환 작업 구성 - 결과 캐싱 - 중복되거나 잘못된 작업 차단 - 각 백엔드 워커는 특정 변환 유형을 담당한다. - 기능별로 독립적인 유지보수와 확장이 가능함 - 특정 변환의 처리량에 맞춰 개별적으로 확장할 수 있음 - 새로운 파일 형식이나 변환 유형을 추가할 때 핵심 인프라를 수정하는 대신 플러그인을 추가하면 된다. - 현재 Riviera는 100개가 넘는 변환 기능을 제공하며, 초당 수십만 건의 변환을 처리한다. - 이 구조 덕분에 핵심 플랫폼은 안정적으로 유지하면서 지원 파일 형식과 제품 기능을 계속 확장할 수 있었다. ## 여러 제품이 공유하는 변환 라이브러리 - Riviera는 처음에는 전담 Previews 팀이 운영하는 내부 서비스였지만, 다른 팀들도 동일한 콘텐츠 처리 문제를 겪고 있다는 사실이 드러났다. - 예를 들어 미리보기용으로 만든 160×160 썸네일은 머신러닝 팀의 이미지 정규화에도 활용할 수 있었다. - 같은 결과물을 여러 소비자가 사용하면 변환을 한 번만 수행하면 됨 - Search 팀은 문서를 검색 인덱싱에 적합한 형태로 준비하기 위해 Riviera를 도입했다. - Sign, DocSend, Replay 같은 제품도 기존 변환 기능을 재사용했다. - 이후 Dropbox는 플러그인 모델을 제품 팀에 개방했다. - Riviera 팀은 핵심 아키텍처를 관리 - 각 제품 팀은 필요한 변환 플러그인을 추가 - 추가된 플러그인은 다른 팀도 사용할 수 있는 공유 자산이 됨 ## Replay가 보여준 플러그인 모델의 효과 - 동영상 리뷰 제품인 Replay는 동영상 트랜스코딩과 조작이라는 복잡한 처리 작업이 필요했다. - Riviera의 미디어 변환 기능을 활용함으로써 Replay 팀은 동영상 처리 인프라를 처음부터 구축하지 않아도 됐다. - 제품 팀이 변환 기능을 요청하면 Riviera가 기존 기능을 노출하거나 새 플러그인을 추가하는 방식이 정착됐다. - 그 결과 기존에는 수개월이 걸릴 수 있었던 기능을 수주 안에 출시할 수 있었고, 새로운 플러그인이 추가될수록 다음 제품의 개발도 빨라졌다. ## Dash와 AI가 만든 새로운 요구 - AI 모델이 문서에 답변하거나 보고서를 요약하려면 먼저 문서가 모델이 처리할 수 있는 일관된 형태로 변환되어야 한다. - 필요한 전처리에는 다음 작업이 포함된다. - 텍스트 추출 - 스캔 문서의 페이지 인식 - 메타데이터 추출 - 다양한 파일 형식의 통일된 표현으로 변환 - 이러한 작업은 본질적으로 AI 모델 자체의 문제가 아니라 콘텐츠 변환 문제이며, Riviera가 기존부터 해결해 온 영역이다. - Dash 팀은 Riviera가 이미 지원하던 수백 가지 파일 형식과 변환 기능을 활용해 별도의 문서 처리 시스템을 새로 만들 필요를 줄였다. - Riviera는 미리보기와 미디어 처리뿐 아니라 검색, 문서 자동화, AI용 콘텐츠 준비에도 적용되는 기반 계층으로 확장됐다. ## 외부 개발자를 위한 공개 - Dropbox는 Riviera에서 축적한 콘텐츠 변환 기능을 API와 Model Context Protocol 도구 형태로 개발자 생태계와 설계 파트너에게 제공하기 시작했다. - 활용 사례로는 다음과 같은 작업이 제시된다. - 콘텐츠 관리 시스템 구축 - 문서 처리 워크플로 자동화 - 파일 검색용 인덱싱 - AI 애플리케이션용 문서 전처리 - 핵심 가치는 제품마다 변환 인프라를 새로 구축하지 않고, 검증된 공통 플랫폼을 이용할 수 있다는 점이다. Riviera의 사례는 대규모 콘텐츠 처리를 제품별 기능이 아니라 재사용 가능한 변환 조합과 플러그인 플랫폼으로 설계해야 한다는 점을 보여준다. 특히 AI 애플리케이션을 만들 때 모델 개발에만 집중하기보다, 다양한 파일을 안정적으로 추출·정규화·변환하는 기반을 먼저 확보하는 것이 실용적인 접근이다.

figma

딥 서치 심층 분석 | 피 (새 탭에서 열림)

Figma의 Deep Search는 파일명이나 폴더명을 몰라도 파일 내부의 텍스트와 내용을 검색할 수 있도록 만든 기능이다. 일반 검색이 데이터베이스의 메타데이터를 색인하는 것과 달리, Deep Search는 S3에 저장된 `.fig` 파일을 직접 읽고 객체 트리를 순회해야 한다. 이를 위해 기존 Design System Analytics 인프라를 확장하고, 처리 비용과 최신성 사이에서 타협해 변경 사항을 시간 단위로 모아 색인하는 방식을 선택했다. ## 브라우저 기반 제품이 제공하는 검색 가능성 - Figma는 데스크톱 애플리케이션이 아닌 브라우저 기반 도구이므로, 사용자가 접근할 수 있는 파일에 대한 풍부한 정보를 수집하고 분석할 수 있다. - 파일의 조회 빈도, 컴포넌트 사용량, 파일 구조 등 웹 환경에 적합한 데이터를 활용할 수 있다. - 이러한 특성은 협업을 강화한다. - 별도 파일을 내보내지 않아도 이해관계자가 진행 중인 작업을 확인할 수 있다. - 프로토타입 공유와 핸드오프가 간소화된다. - 작업 중인 결과물을 쉽게 공유할 수 있다. - Deep Search는 파일명보다 프로젝트의 아이디어, 문구, 해결하려던 문제를 기억하는 사용자의 검색 방식에 맞춘 기능으로 기획됐다. ## Design System Analytics에서 얻은 기술적 기반 - Figma는 앞서 Design System Analytics(DSA)를 출시해 팀 간 디자인 시스템과 공유 라이브러리의 사용 현황을 분석했다. - DSA와 Deep Search 모두 다음과 같은 공통 처리가 필요했다. - 최근 수정된 파일을 식별한다. - 스토리지에서 파일을 내려받는다. - 파일 내부를 순회한다. - 목적에 맞는 정보를 추출한다. - DSA는 공유 라이브러리 사용량을 추출하고, Deep Search는 파일 내부의 텍스트를 추출한다. - Figma는 DSA를 위해 만든 파일 분석 인프라와 워커를 일반화해 Deep Search의 기반으로 활용했다. ## 일반 검색의 색인 파이프라인 - 기존 Unified Search를 포함한 일반 검색은 데이터베이스에 저장된 메타데이터를 대상으로 한다. - 예시로 파일 ID, 폴더 ID, 팀 ID, 파일명, 폴더명, 생성자 등의 정보를 사용한다. - 처리 과정은 다음과 같다. - 데이터베이스의 관련 테이블 변경 사항을 감시한다. - 변경된 항목의 ID를 메시징 시스템으로 전달한다. - 검색 색인기가 최신 데이터를 데이터베이스에서 가져온다. - 가져온 메타데이터를 Elasticsearch 클러스터에 색인한다. - 데이터베이스 조회는 비교적 저렴하기 때문에 변경될 때마다 빠르게 색인을 갱신할 수 있다. ## Deep Search가 더 복잡한 이유 - Figma 파일의 실제 표현은 데이터베이스가 아니라 Amazon S3에 저장된 `.fig` 문서다. - `.fig` 파일은 트리 구조로 구성된다. - 각 노드는 타원, 프레임, 벡터, 텍스트 같은 Figma 객체를 나타낸다. - 노드에는 객체의 속성과 콘텐츠가 함께 저장된다. - Deep Search는 파일의 메타데이터만 확인하는 것이 아니라, S3에서 파일을 가져온 뒤 전체 객체 트리를 순회해야 한다. - 하나의 파일에 수천 개의 노드가 있을 수 있어 파일을 읽고 분석하는 작업은 일반적인 데이터베이스 조회보다 훨씬 계산 비용이 크다. ## 처리 비용과 검색 최신성 사이의 타협 - Figma 파일은 편집 중에도 약 30초마다 자동 저장될 수 있다. - 저장될 때마다 Deep Search 색인을 갱신하면 같은 파일을 반복적으로 내려받고 분석하게 되어 서버 비용이 크게 증가한다. - Figma는 이를 해결하기 위해 파일 변경 사항을 한 시간 동안 중복 제거한다. - 이후 변경된 파일을 파일 분석 워커로 보내 주기적으로 처리한다. - 그 결과 Deep Search 결과가 일반 검색보다 잠시 오래된 상태일 수 있지만, 반복적인 파일 분석을 줄여 상당한 서버 자원을 절약할 수 있다. - 이는 검색 결과의 즉시성보다 시스템 비용과 확장성을 우선한 제품·인프라상의 결정이다. ## 실용적인 결론 대용량 문서나 복잡한 구조를 검색할 때는 모든 변경을 즉시 처리하기보다 변경 사항을 모아 중복 작업을 제거하는 방식이 효율적이다. 검색 결과가 수초 또는 수분 정도 지연되어도 괜찮다면, 배치 처리와 주기적 색인을 통해 계산 비용과 인프라 부담을 크게 줄일 수 있다.