1.2TB 멀티미디어 아카이브를 AI로 검색하는 시스템을 만든다면

“이 신문에서 김정은이 처음 등장한 시점은 언제인가요? 그 전후로 보도 논조가 어떻게 변했나요?”

이 질문에 답하려면 수십 년치 신문 스캔 이미지를 OCR로 텍스트화하고, 시계열로 정렬하고, 인물을 식별하고, 논조 변화를 분석해야 한다. Google 검색창에 키워드를 넣는 것으로는 해결되지 않는다.

1.2TB 규모의 북한 관련 자료가 있다. 신문 스캔 이미지, 서적 PDF, 음악 파일, 동영상, 블로그 아카이브 등 다양한 포맷이 뒤섞여 있다. 13명의 연구자가 이 자료를 기반으로 던질 수 있는 질문을 상정했다. 키워드 검색, 시계열 분석, 인물 사진 검색, 장소 사진 검색, 번역, 단어 빈도 분석, 복합 조건 검색 — 단순 검색 엔진 하나로는 커버할 수 없는 범위다.

이 글은 이런 멀티미디어 아카이브를 GCP 기반으로 AI 검색 시스템화하는 방법론을 정리한다. 아키텍처 설계부터 기술 선정, 각국 사례, 비용, 구축 기간까지 다룬다.

왜 단순 검색 엔진으로는 부족한가

연구자들이 상정한 질문의 일부를 보자.

“1990년대 로동신문에서 ‘자력갱생’이라는 단어의 연도별 빈도 변화를 보여주세요”
“이 사진 속 인물이 등장하는 다른 기사를 찾아주세요”
“김정일 사망 전후 3개월간 보도 논조 변화를 분석해주세요”
“이 동영상에서 언급되는 지명들을 지도 위에 표시해주세요”
“조선중앙TV 뉴스에서 특정 인물이 등장하는 장면만 추출해주세요”

이 질문들의 공통점이 있다. 단일 검색 쿼리로 답이 나오지 않는다. 여러 모달리티(텍스트, 이미지, 음성, 영상)를 넘나들며, 시간축 분석이 필요하고, 때로는 여러 단계의 추론이 요구된다. Elasticsearch에 텍스트를 넣고 BM25 검색을 하는 것만으로는 이 중 절반도 처리할 수 없다.

필요한 것은 멀티모달 RAG(Retrieval-Augmented Generation) 시스템 — 다양한 형식의 데이터를 통합 인덱싱하고, 자연어 질문을 분해하여 단계적으로 검색·분석하며, 최종 답변을 생성하는 파이프라인이다.

시스템 아키텍처 전체 설계

전체 시스템은 4개 레이어로 구성된다.

┌─────────────────────────────────────────────────────┐
│                  사용자 인터페이스                      │
│          (Next.js + Cloud Run, 시각화, 필터)           │
├─────────────────────────────────────────────────────┤
│              검색 및 질의응답 레이어                     │
│    (Multimodal RAG, 하이브리드 검색, GraphRAG,          │
│     Agentic RAG, Re-ranking)                        │
├─────────────────────────────────────────────────────┤
│              인덱싱 및 저장 레이어                      │
│    (PostgreSQL+pgvector, Elasticsearch, 벡터 DB,      │
│     CLIP 임베딩, GCS)                                │
├─────────────────────────────────────────────────────┤
│            데이터 수집 및 전처리 파이프라인               │
│    (OCR, ASR, 키프레임 추출, 메타데이터 구조화)           │
└─────────────────────────────────────────────────────┘

1. 데이터 수집 및 전처리 파이프라인

1.2TB의 혼합 데이터를 AI가 검색할 수 있는 형태로 변환하는 단계다. 전체 시스템 구축의 60% 이상의 노력이 여기에 집중된다.

파일 포맷 자동 감지. Apache Tika 또는 python-magic으로 MIME 타입을 판별한다. 확장자가 틀린 경우가 빈번하므로 매직 바이트 기반 감지가 필수다. 감지된 포맷에 따라 이후 처리 파이프라인이 분기된다.

이미지/PDF → OCR. 신문 스캔 이미지가 가장 큰 비중을 차지한다. 선택지는 세 가지다.

OCR 엔진	한국어/조선어 지원	특징	비용
GCP Document AI	우수 (한국어 네이티브)	레이아웃 인식, 표 추출, GCP 네이티브	$0.06/page (1,000페이지 이상)
Tesseract 5	보통 (한국어 모델 존재, 정확도 낮음)	오픈소스, 무료, 커스텀 학습 가능	무료 (GPU 인프라 비용만)
Mistral OCR	우수 (다국어 강점)	최신 모델, API 기반, 복잡한 레이아웃 강점	~$0.05/page

신문 스캔처럼 레이아웃이 복잡한 경우 GCP Document AI가 가장 안정적이다. 단, 1950~60년대 인쇄물처럼 해상도가 낮고 활자체가 오래된 경우 어떤 OCR도 정확도가 떨어진다. 이때는 전처리(이미지 이진화, 기울기 보정, 노이즈 제거) → OCR → 후처리(맞춤법 교정, 사전 기반 보정) 3단계가 필요하다.

음성/동영상 → ASR(Automatic Speech Recognition). 조선중앙TV 뉴스, 가요, 연설 등의 음성을 텍스트로 변환한다.

ASR 엔진	한국어 정확도	특징
OpenAI Whisper (large-v3)	WER ~5% (표준 한국어)	오픈소스, 로컬 실행 가능, 조선어 억양에 약함
GCP Speech-to-Text v2	WER ~4% (한국어)	GCP 네이티브, 실시간 지원, 화자 분리

북한 발음과 억양은 남한 한국어와 차이가 있다. Whisper large-v3는 범용 다국어 모델이라 조선어 억양에서 정확도가 떨어질 수 있다. GCP Speech-to-Text도 마찬가지다. 현실적인 해결책은 Whisper를 조선어 샘플로 파인튜닝하거나, ASR 결과를 LLM으로 후보정하는 것이다.

동영상 키프레임 추출. FFmpeg로 장면 전환 감지(scene detection) 기반 키프레임을 추출한다. 뉴스 영상이라면 앵커 교체, 화면 전환 시점이 자연스러운 분할 지점이다. 추출된 키프레임은 CLIP으로 임베딩하여 이미지 검색에 활용한다. 자막이 있는 경우 SRT/VTT 파일을 파싱하여 텍스트화한다.

메타데이터 추출 및 구조화. 모든 자료에 대해 다음 메타데이터를 YAML/JSON으로 구조화한다.

source_id: "rodong-19950315-p2"
source_type: "newspaper_scan"
title: "로동신문 1995년 3월 15일 2면"
date: "1995-03-15"
language: "ko-KP"
media_type: "image/tiff"
ocr_engine: "document_ai"
ocr_confidence: 0.87
entities:
  - name: "김정일"
    type: "person"
    mentions: 12
  - name: "평양"
    type: "location"
    mentions: 5
file_path: "gs://archive-bucket/newspapers/1995/0315_p2.tiff"
text_path: "gs://archive-bucket/texts/1995/0315_p2.txt"

2. 인덱싱 및 저장 레이어

전처리된 데이터를 검색 가능한 형태로 저장하는 단계다. 하나의 저장소로는 불가능하다. 쿼리 유형에 따라 다른 검색 방식이 필요하기 때문이다.

구조화 데이터: PostgreSQL + pgvector (또는 AlloyDB). 메타데이터, 날짜, 출처, 엔티티 정보를 저장한다. SQL 쿼리로 “1990년대 로동신문에서…” 같은 시기·매체 필터링이 가능하다. pgvector 확장을 사용하면 같은 DB에서 벡터 유사도 검색도 가능하다. AlloyDB는 GCP 매니지드 PostgreSQL로, pgvector보다 벡터 검색 성능이 최대 10배 빠르다.

벡터 스토어: Vertex AI Vector Search 또는 Milvus. 텍스트 임베딩과 이미지 임베딩을 저장한다. 100만 건 이상의 벡터를 밀리초 단위로 검색해야 하므로 전용 벡터 DB가 필요하다.

벡터 DB	특징	GCP 호환
Vertex AI Vector Search	GCP 네이티브, 매니지드, ScaNN 기반	최적
Milvus	오픈소스, 자체 호스팅 가능, 다양한 인덱스	GKE에 배포
pgvector	PostgreSQL 확장, 별도 인프라 불필요	AlloyDB에서 성능 향상

100만 벡터 이하라면 pgvector로 충분하다. 그 이상이면 Vertex AI Vector Search가 GCP 환경에서 가장 편리하다.

전문검색: Elasticsearch. BM25 기반 키워드 검색을 담당한다. “자력갱생”이라는 정확한 단어를 찾는 쿼리, 연도별 빈도 집계(aggregation), 형태소 분석 기반 한국어 검색에 필수다. Elastic Cloud on GCP를 사용하면 매니지드로 운영 가능하다. 하이브리드 검색(BM25 + 벡터)을 Elasticsearch 단일 시스템에서 구현할 수도 있다(Elasticsearch 8.x의 kNN 검색 지원).

이미지 임베딩: CLIP → 벡터 DB. OpenAI CLIP 모델은 이미지와 텍스트를 같은 벡터 공간에 매핑한다. “군사 퍼레이드 사진”이라고 텍스트로 검색하면 해당 장면의 이미지가 반환되는 텍스트-이미지 크로스모달 검색이 가능하다. 인물 사진 검색에는 CLIP만으로 부족하다. InsightFace(ArcFace) 같은 얼굴 인식 모델로 얼굴 임베딩을 별도 생성하고, 특정 인물의 참조 사진과 코사인 유사도를 비교하는 방식이 필요하다.

원본 파일: GCS(Google Cloud Storage). 1.2TB의 원본 파일은 GCS에 보관한다. 검색 결과에서 원본 파일로의 링크를 제공하여 연구자가 원문을 직접 확인할 수 있게 한다. Standard 스토리지 기준 월 $25 수준이다.

3. 검색 및 질의응답 레이어

이 레이어가 시스템의 핵심이다. 연구자의 자연어 질문을 받아 적절한 검색 전략을 선택하고, 결과를 종합하여 답변을 생성한다.

Multimodal RAG 파이프라인. 텍스트, 이미지, 음성 전사본을 통합하여 검색한다. Gemini 2.0 Flash/Pro는 멀티모달 입력을 네이티브로 지원하므로, 검색된 이미지와 텍스트를 함께 컨텍스트로 전달할 수 있다.

하이브리드 검색 + Re-ranking. BM25(키워드)와 벡터 검색(의미)을 동시에 실행하고, RRF(Reciprocal Rank Fusion)로 결과를 통합한 뒤, Cross-Encoder Re-ranker로 상위 결과를 재정렬한다. 엔터프라이즈 배포 사례에서 하이브리드 검색만으로 15~30%의 정밀도 향상, Re-ranking 추가로 10~25% 추가 향상이 보고된다.

GraphRAG (인물-조직-사건 관계 그래프). “김정은과 함께 자주 등장하는 인물들의 변화”같은 관계 기반 질문에는 지식 그래프가 필수다. 문서에서 추출한 인물, 조직, 장소, 사건을 노드로, 그들 간의 관계를 엣지로 구축한다. Neo4j 또는 JanusGraph를 그래프 DB로 사용한다.

[김정일] ─(후계자)─→ [김정은]
[김정은] ─(참석)─→ [2012년 열병식]
[2012년 열병식] ─(장소)─→ [평양 김일성광장]
[리설주] ─(동반출석)─→ [2012년 열병식]

FalkorDB의 벤치마크에서 복잡한 다단계 추론 질문의 정확도가 표준 RAG 34% 대비 GraphRAG **91%**로 나타났다. 인물-조직 관계가 핵심인 이 프로젝트에서 GraphRAG는 선택이 아닌 필수다.

Agentic RAG (복합 질문 분해). “김정일 사망 전후 3개월간 보도 논조 변화를 분석해주세요”는 단일 검색으로 답할 수 없다. 이 질문은 다음과 같이 분해되어야 한다.

원래 질문: "김정일 사망 전후 3개월간 보도 논조 변화"
    ↓ Agent가 분해
1단계: 김정일 사망일 확인 → 2011년 12월 17일
2단계: 2011.09~2012.03 기간 기사 검색
3단계: 기간별 기사 감성 분석 (긍정/부정/중립)
4단계: 시계열 시각화 및 논조 변화 요약

LangGraph나 Vertex AI Agent Builder로 이런 에이전틱 워크플로우를 구현한다. 에이전트가 질문을 분해하고, 각 하위 질문에 적합한 도구(검색, 집계, 분석)를 호출하며, 결과를 종합한다.

4. 사용자 인터페이스

웹 UI (Next.js + Cloud Run). 연구자가 자연어로 질문하고, 결과를 확인하며, 필터(시기, 매체, 키워드)를 적용할 수 있는 인터페이스다. Cloud Run에 배포하면 사용량에 따라 자동 스케일링된다.

시각화. 연구자들이 요구하는 분석 대부분은 시각화를 포함한다.

시계열 차트: 단어 빈도 변화, 보도량 추이 (D3.js 또는 Chart.js)
네트워크 그래프: 인물-조직 관계 시각화 (vis.js 또는 Cytoscape.js)
지도 시각화: 언급된 지명의 지리적 분포 (Mapbox 또는 Google Maps)
이미지 갤러리: 검색된 사진/키프레임 썸네일 + 원본 링크

핵심 기술 선정 상세

LLM: Gemini 2.0 Flash / Pro

GCP 네이티브 환경이라면 Gemini가 가장 자연스러운 선택이다. Flash는 빠른 응답이 필요한 일반 쿼리에, Pro는 복잡한 분석·요약에 사용한다. 멀티모달 입력을 네이티브로 지원하므로 이미지와 텍스트를 함께 처리할 수 있다. 100만 토큰 컨텍스트 윈도우도 긴 문서 분석에 유리하다.

임베딩 모델

모델	차원	한국어 성능	특징
text-embedding-004 (Google)	768	우수	GCP 네이티브, Vertex AI 통합
multilingual-e5-large	1024	우수	오픈소스, 다국어 특화
bge-m3	1024	우수	오픈소스, 희소+밀집 하이브리드

GCP 환경에서는 text-embedding-004가 API 호출 한 줄로 사용 가능하다. 자체 호스팅이 필요하면 multilingual-e5-large나 bge-m3가 대안이다. bge-m3는 밀집 벡터와 희소 벡터를 동시에 생성하므로 하이브리드 검색에 특히 유리하다.

그래프 DB: Neo4j vs JanusGraph

	Neo4j	JanusGraph
쿼리 언어	Cypher (직관적)	Gremlin (범용적)
성능	중소 규모 그래프에 최적	대규모 분산 그래프에 강점
호스팅	Neo4j AuraDB (매니지드)	GKE 자체 운영
커뮤니티	대규모, 풍부한 문서	상대적으로 작음

인물-조직-사건 관계 그래프가 수백만 노드 이하라면 Neo4j가 개발 생산성 면에서 유리하다. Cypher 쿼리가 직관적이고, LLM이 Cypher를 생성하는 것도 Gremlin보다 정확하다.

얼굴 인식: InsightFace / ArcFace

“이 사진 속 인물이 등장하는 다른 기사를 찾아주세요”에 대응하려면 얼굴 임베딩이 필요하다. InsightFace(ArcFace 기반)는 현재 오픈소스 얼굴 인식 모델 중 최고 수준이다. 얼굴 감지 → 정렬 → 512차원 임베딩 생성 → 벡터 DB에 저장하는 파이프라인을 구성한다. 동일 인물의 참조 사진 여러 장을 등록하면 다양한 각도·조명에서의 인식률이 높아진다.

다만 1950~70년대 흑백 신문 사진에서의 얼굴 인식은 정확도가 크게 떨어진다. 해상도가 낮고 인쇄 품질이 고르지 않기 때문이다. 이 경우 이미지 초해상도(Super-Resolution) 전처리 → 얼굴 인식 파이프라인이 도움이 되지만, 완벽한 해결책은 아니다.

각국 사례 비교

대규모 멀티미디어 아카이브를 AI로 검색 가능하게 만드는 시도는 전 세계에서 진행 중이다.

미국: Library of Congress — Chronicling America

미국 의회도서관의 Chronicling America 프로젝트는 1,600만 페이지 이상의 역사 신문을 디지털화했다. Tesseract OCR과 NVIDIA GPU 클러스터로 대규모 OCR을 처리했다. 최근에는 AI 기반 기사 분할(article segmentation)과 주제 분류를 추가하고 있다. 2024년에는 자체 학습시킨 레이아웃 분석 모델로 신문 페이지를 개별 기사 단위로 분리하는 정확도를 크게 향상시켰다.

교훈: OCR 정확도보다 기사 분할(segmentation)이 더 어려운 문제다. 신문은 한 페이지에 여러 기사가 복잡하게 배치되어 있어, 어디서 한 기사가 끝나고 다음 기사가 시작되는지 판별하는 것이 핵심 과제다.

영국: British Library Newspaper Archive

4,000만 페이지의 신문을 디지털화한 세계 최대 규모의 신문 아카이브 중 하나다. ABBYY OCR(상용)과 Elasticsearch 기반 전문검색을 사용한다. 최근 Living with Machines 프로젝트에서 AI 기반 Named Entity Recognition(NER)과 시계열 분석을 추가하여, 19세기 산업혁명 시기의 사회 변화를 신문 텍스트로 추적하는 연구를 수행했다.

교훈: 크라우드소싱 OCR 교정의 한계. 초기에는 사용자가 OCR 오류를 교정하도록 했으나, 4,000만 페이지 규모에서는 비현실적이었다. AI 기반 자동 교정으로 전환했다.

호주: Trove (National Library of Australia)

호주 국립도서관의 Trove는 3억 건 이상의 신문 기사를 보유한 디지털 아카이브다. 가장 주목할 점은 크라우드소싱 OCR 교정 시스템이다. 일반 시민이 웹에서 OCR 텍스트를 교정할 수 있고, 지금까지 4억 줄 이상이 교정됐다. 세계에서 가장 성공적인 크라우드소싱 디지털 아카이브 사례로 꼽힌다.

교훈: 커뮤니티 참여가 AI보다 효과적일 수 있다. 특히 도메인 전문가(이 프로젝트의 경우 북한 연구자 13명)가 교정에 참여하면 전문 용어와 맥락의 정확도가 AI보다 높다. 시스템에 교정 인터페이스를 포함하는 것이 권장된다.

유럽: Europeana

유럽 전역의 문화유산을 통합하는 Europeana는 5,800만 아이템(이미지, 텍스트, 음성, 영상)을 보유하고 있다. IIIF(International Image Interoperability Framework) 표준을 채택하여 서로 다른 기관의 이미지를 통합 검색·표시할 수 있다. AI 기반 메타데이터 자동 생성과 다국어 검색을 구현했다.

교훈: 표준화된 메타데이터 스키마의 중요성. 여러 기관의 자료를 통합할 때 메타데이터 형식이 일치하지 않으면 검색 품질이 급락한다.

일본: 国立国会図書館 디지털 아카이브

일본 국립국회도서관은 자체 OCR 모델(NDL OCR)을 개발했다. 일본어 특유의 세로쓰기, 한자·히라가나·가타카나 혼용, 역사적 서체에 최적화된 모델이다. 수백만 페이지의 고서·신문을 디지털화했으며, 2023년부터 AI 기반 전문검색을 도입하고 있다. IIIF 뷰어를 통해 원본 이미지와 OCR 텍스트를 나란히 볼 수 있다.

교훈: 도메인 특화 OCR 모델이 범용 모델을 압도한다. 조선어 활자체, 1950~60년대 인쇄 품질 등 특수한 조건이 있다면 파인튜닝이 필수다.

한국: 국가기록원, 한국학중앙연구원

국가기록원은 정부 기록물의 디지털 아카이브를 운영하고 있으며, 한국학중앙연구원은 한국학 관련 고문서·족보 등의 디지털화를 진행 중이다. AI 검색보다는 전통적인 메타데이터 기반 검색에 머물러 있는 경우가 많다. 최근 한국어 특화 LLM과 OCR 기술의 발전으로 AI 검색 도입이 가속화되고 있다.

이스라엘: National Library of Israel

히브리어, 아랍어, 이디시어 등 다국어·다문자 자료를 AI로 검색 가능하게 만드는 프로젝트를 진행 중이다. 다국어 OCR과 크로스링구얼 검색이 핵심 과제로, 이 프로젝트와 유사한 도전(한국어/조선어 혼용, 다양한 시기의 인쇄체)을 공유한다.

우크라이나: Osavul

Osavul은 북한을 포함한 권위주의 국가의 선전 미디어를 실시간으로 모니터링하고 분석하는 AI 시스템이다. 텍스트·이미지·영상을 수집하여 선전 패턴을 감지하고, 내러티브 변화를 추적한다. 이 프로젝트와 가장 유사한 목적을 가진 사례다.

교훈: 실시간 모니터링과 아카이브 분석은 다른 아키텍처가 필요하다. Osavul은 스트리밍 파이프라인 중심이고, 이 프로젝트는 배치 처리 + 검색 중심이다. 하지만 선전 분석 방법론(내러티브 추출, 감성 분석, 인물 네트워크 분석)은 참고할 가치가 크다.

비용 추정

초기 구축 비용 (6~12개월)

항목	추정 비용	산출 근거
OCR 처리	~$60,000	100만 페이지 × $0.06/page (Document AI)
ASR 처리	~$5,000	동영상/음성 수백 시간 분량
임베딩 생성	~$3,000	수백만 청크 × text-embedding-004
얼굴 임베딩 생성	~$2,000	GPU 인스턴스 비용 (InsightFace 처리)
그래프 구축 (NER + 관계 추출)	~$10,000	LLM API 비용 (엔티티/관계 추출)
인프라 셋업 + 개발 인건비	$150,000~300,000	풀타임 엔지니어 2~~3명 × 6~~9개월
총 초기 비용	$230,000~$380,000

OCR 비용을 줄이려면 1차 Tesseract(무료) → 저신뢰도 페이지만 Document AI로 재처리하는 2단계 전략이 가능하다. Tesseract로 전체를 처리하고, OCR 신뢰도가 0.7 이하인 페이지만 Document AI로 보내면 비용을 40~60% 절감할 수 있다.

월간 운영 비용

항목	월 비용	비고
GCS 스토리지 (1.2TB)	~$25	Standard 스토리지
Vertex AI Vector Search	$500~2,000	인덱스 크기·쿼리량에 따라 변동
Elasticsearch (Elastic Cloud)	$500~1,000	3노드 클러스터 기준
Cloud Run (API 서버 + UI)	$100~300	사용량 기반 과금
Neo4j AuraDB	$200~500	그래프 DB
LLM API (Gemini)	$500~2,000	일일 쿼리 수에 따라 변동
모니터링 + 로깅	$100~200	Cloud Monitoring
총 월간 비용	$1,900~$6,000

연구자 13명이 일일 평균 20~~50회 쿼리를 보내는 수준이라면 월간 $2,000~~3,000 선에서 운영 가능하다. 쿼리량이 급증하면 LLM API 비용이 가장 큰 변수가 된다. Gemini Flash를 기본으로 사용하고, 복잡한 분석 쿼리만 Pro로 라우팅하면 비용을 최적화할 수 있다.

구축 기간

Phase 1 (1~2개월): 데이터 전처리 파이프라인
├── 파일 포맷 감지 + 분류 자동화
├── OCR 파이프라인 구축 (Document AI + Tesseract)
├── ASR 파이프라인 구축 (Whisper)
├── 키프레임 추출 파이프라인
└── 메타데이터 스키마 설계 + 추출

Phase 2 (2~3개월): 인덱싱 + 검색 엔진
├── PostgreSQL + pgvector 셋업
├── Elasticsearch 인덱스 설계 + 데이터 적재
├── 벡터 임베딩 생성 + Vertex AI Vector Search 구축
├── CLIP 이미지 임베딩 + 얼굴 임베딩
├── Neo4j 그래프 구축 (NER + 관계 추출)
└── 하이브리드 검색 + Re-ranking 파이프라인

Phase 3 (1~2개월): RAG + LLM 질의응답
├── Multimodal RAG 파이프라인 구현
├── Agentic RAG (질문 분해 + 단계적 검색)
├── GraphRAG 쿼리 라우팅
└── 평가 체계 구축 (RAGAS)

Phase 4 (1~2개월): UI + 시각화 + 테스트
├── Next.js 웹 UI 개발
├── 시각화 컴포넌트 (시계열, 네트워크, 지도)
├── 연구자 피드백 반영
└── 성능 최적화 + 부하 테스트

총 예상: 6~9개월

Phase 1이 가장 중요하다. OCR 품질이 전체 시스템의 정밀도를 결정한다. OCR이 잘못 읽은 텍스트는 임베딩, 검색, 답변 생성 모든 단계에서 오류를 증폭시킨다. Phase 1에 충분한 시간을 투자하고, OCR 결과의 샘플 검수를 연구자와 함께 진행하는 것이 권장된다.

Phase 2와 Phase 3는 부분적으로 병렬 진행이 가능하다. Elasticsearch 인덱싱과 벡터 DB 구축은 독립적이므로 동시에 진행할 수 있다.

핵심 교훈

1. 데이터 전처리가 전체의 60%다. 어떤 LLM을 쓸지, 어떤 벡터 DB를 쓸지보다 OCR 정확도, 메타데이터 품질, 청킹 전략이 최종 정밀도에 더 큰 영향을 미친다. Gartner가 경고한 대로 “AI 준비가 안 된 데이터를 가진 AI 프로젝트의 60%가 폐기된다.” 데이터 파이프라인에 먼저 투자하라.

2. 멀티모달은 파이프라인이 복잡해진다. 텍스트만 다루는 RAG보다 이미지, 음성, 영상까지 포함하면 전처리 파이프라인이 3~4배 복잡해진다. 각 모달리티별 전처리 → 임베딩 → 인덱싱 경로가 모두 다르다. 초기에 모든 모달리티를 한꺼번에 구현하려 하지 말고, 텍스트 검색 먼저 완성 → 이미지 검색 추가 → 음성/영상 검색 추가 순서로 점진적으로 확장하는 것이 현실적이다.

3. 연구자 피드백 루프가 정밀도를 결정한다. OCR 교정, 검색 결과 평가, 엔티티 검증에 도메인 전문가의 피드백이 필수다. Trove의 크라우드소싱 교정 모델처럼, 연구자가 시스템을 사용하면서 오류를 교정할 수 있는 인터페이스를 처음부터 포함해야 한다. 13명의 연구자가 교정에 참여하면 시스템 정확도는 시간이 지날수록 향상된다.

4. 평가 없이는 개선도 없다. RAGAS 기반 자동 평가 + 연구자의 주관적 평가를 병행하라. 검색 정밀도(Context Precision), 답변 근거성(Groundedness), 답변 관련성(Answer Relevance)을 지속적으로 모니터링해야 시스템이 어느 단계에서 실패하는지 진단할 수 있다.

5. 비용은 쿼리 패턴에 따라 크게 달라진다. 13명의 연구자가 하루 몇 십 건의 쿼리를 보내는 수준이라면 월 $2,000~3,000으로 운영 가능하다. 하지만 대규모 배치 분석(예: 전체 아카이브 대상 감성 분석)을 자주 수행하면 LLM API 비용이 급증한다. 배치 분석은 Gemini Flash + 배치 API로 비용을 최적화하고, 결과를 캐싱하여 재사용하는 전략이 필요하다.

1.2TB 멀티미디어 아카이브를 AI 검색 시스템으로 만드는 것은 기술적으로 충분히 가능한 시대가 됐다. OCR, ASR, 멀티모달 임베딩, GraphRAG, Agentic RAG — 개별 기술은 모두 성숙했다. 진짜 도전은 이것들을 하나의 시스템으로 통합하고, 지속적으로 정밀도를 개선하는 엔지니어링과 운영에 있다.