techlist.io
KREN
figma

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

distributed-systemsamazon-s3data-pipelineelasticsearchsearch-indexingdocument-processing

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 결과가 일반 검색보다 잠시 오래된 상태일 수 있지만, 반복적인 파일 분석을 줄여 상당한 서버 자원을 절약할 수 있다.
  • 이는 검색 결과의 즉시성보다 시스템 비용과 확장성을 우선한 제품·인프라상의 결정이다.

실용적인 결론

대용량 문서나 복잡한 구조를 검색할 때는 모든 변경을 즉시 처리하기보다 변경 사항을 모아 중복 작업을 제거하는 방식이 효율적이다. 검색 결과가 수초 또는 수분 정도 지연되어도 괜찮다면, 배치 처리와 주기적 색인을 통해 계산 비용과 인프라 부담을 크게 줄일 수 있다.