멀티미디어 DB 설계: 객체 저장소·벡터 검색·스트리밍

파일 저장만으로는 멀티미디어 서비스를 만들 수 없다

이미지, 오디오, 동영상, 그래픽, 텍스트처럼 형식과 크기가 제각각인 데이터를 다루려면 저장소 외에 검색, 전송, 분석 계층이 함께 필요하다. 멀티미디어 DB는 대용량 파일의 객체 저장과 정형 메타데이터 관리, 벡터 임베딩 기반 색인, 스트리밍 품질(QoS)을 하나의 데이터 체계로 묶는다.

목표는 빠른 검색과 지능형 추천, 안정적인 전송 품질을 동시에 확보하는 데 있다. OTT, 커머스, 의료, 스마트시티처럼 미디어가 서비스 핵심 자산인 환경에서 이 구조가 인프라 역할을 한다.

멀티미디어 DB가 다루는 범위는 다음과 같다.

비정형 대용량 데이터와 여러 미디어 포맷 처리
기술·설명·맥락 메타데이터 관리
콘텐츠 기반 이미지 검색(CBIR)과 벡터 검색
적응형 스트리밍과 분산 확장

업로드부터 검색·전송까지 이어지는 계층

업로드 요청은 비동기 파이프라인으로 전달된다. 각 워커는 특징 추출, 썸네일·프리뷰 생성, 트랜스코딩을 맡고, 생성 결과는 벡터 인덱스·메타데이터 DB·객체 저장소에 나뉘어 기록된다. 검색 API는 이 계층을 교차 조회해 결과를 조합한다.

⤢✕

대용량 저장은 TB~PB 규모의 객체 저장소 연계를 전제로 하며, 청크 분할·압축·중복제거를 지원할 수 있다. 검색 계층에서는 텍스트·태그 인덱스, 벡터 임베딩(HNSW/IVF), 지리 공간 인덱스를 결합한다. 전송 계층은 ABR(HLS/DASH), CDN 캐시, 키프레임 인덱스를 이용해 점프 탐색과 품질 제어를 처리한다.

원본 파일과 메타데이터를 분리하는 저장 전략

작은 문서나 이미지는 DB 내 LOB로 보관할 수 있다. 트랜잭션 일체성을 다루기 쉽다는 장점이 있다. 반면 대용량 미디어(>10MB)는 외부 객체 저장소에 두고 사전 서명 URL로 접근하는 방식이 기본이 된다.

실무에서는 메타데이터와 색인을 RDB 또는 검색엔진에, 원본 본문은 객체 저장소에 두는 하이브리드 구성이 일반적인 선택지다.

컬럼	타입	설명
media_id	UUID	내부 식별자
media_type	enum(image, audio, video, doc)	미디어 유형
mime_type	text	예: image/jpeg
width/height	int	해상도
duration_ms	int	오디오/영상 길이
frame_rate	numeric	영상 프레임레이트
codec	text	h264, h265, opus 등
gps_lat/lon	numeric	위치 정보
hash_sha256	char(64)	바이트 단위 해시
phash	bigint	지각적 해시(pHash)
tags	text[]	태그 목록
labels	jsonb	AI 라벨(객체, 장면)
embedding	vector(768)	CLIP 등 임베딩
storage_url	text	s3://bucket/key
created_at	timestamptz	생성 시각

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE media (
  media_id UUID PRIMARY KEY,
  media_type TEXT CHECK(media_type IN ('image','audio','video','doc')),
  mime_type TEXT,
  width INT, height INT,
  duration_ms INT,
  frame_rate NUMERIC,
  codec TEXT,
  gps_lat NUMERIC, gps_lon NUMERIC,
  hash_sha256 CHAR(64) UNIQUE,
  phash BIGINT,
  tags TEXT[],
  labels JSONB,
  embedding VECTOR(768),
  storage_url TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- 메타데이터/태그 검색 인덱스
CREATE INDEX idx_media_tags ON media USING GIN (tags);
CREATE INDEX idx_media_labels ON media USING GIN (labels);
-- 지리 공간(간단 버전)
CREATE INDEX idx_media_gps ON media (gps_lat, gps_lon);
-- 유사도 검색
CREATE INDEX idx_media_embed ON media USING HNSW (embedding);

미디어 형식마다 다른 검색 신호

텍스트와 메타데이터는 RDB의 B-Tree, GIN/JSONB 인덱스, 파티셔닝으로 관리할 수 있다. 전문 검색, 집계, 하이라이팅이 필요하면 Elastic/OpenSearch가 검색 계층을 보완한다.

이미지 유사도 검색은 색상 히스토그램, 키포인트(SIFT/ORB), 딥 임베딩(CNN/CLIP)을 특징으로 사용한다. 유사도는 코사인·내적, L2, 해밍 해시로 계산한다. 오디오는 MFCC/크로마와 오디오 지문(Acoustic fingerprint) 기반 매칭을 사용하며, 동영상은 샷 경계를 검출한 뒤 키프레임을 추출해 이미지 파이프라인에 연결한다.

알고리즘	장점	단점	적용
색상 히스토그램	구현 용이, 빠름	조명·구도 민감	간단 유사 색감 검색
SIFT/SURF	견고한 로컬 특징	계산량 큼, 특허 이슈(과거)	로고/물체 매칭
ORB/BRISK	빠르고 가벼움	정밀도 낮을 수 있음	모바일·대량 매칭
CNN 임베딩	의미적 유사도	GPU/학습 필요	시맨틱 검색
CLIP(텍스트-이미지)	텍스트↔이미지 검색	모델/자원 요구	멀티모달 검색
pHash/aHash	초경량, 중복탐지	정밀 유사도 한계	중복/도용 감지

검색과 인제스트가 처리되는 방식

CBIR에서는 입력 미디어를 전처리한 뒤 특징 또는 임베딩을 뽑는다. 그 결과를 벡터 색인에 삽입하거나 검색하고, 권한·지역·생성일 같은 메타데이터 필터로 재순위한다. ANN(HNSW/IVF-PQ)은 근사 최근접 탐색에 사용된다.

⤢✕

대량 인제스트에서는 업로더가 사전 서명 URL을 요청하고 객체 저장소에 파일을 올린다. 이후 큐가 특징 추출과 트랜스코딩 작업을 전달하며, 메타데이터·임베딩과 HLS/DASH 결과물이 각각 저장된다.

⤢✕

색인과 객체 저장소를 연결하는 구현 예시

on_upload(file):
  url = put_to_object_store(file)
  publish(queue, {type:"extract", url})
  publish(queue, {type:"transcode", url})

worker_extract(msg):
  img = load(msg.url)
  emb = model.encode(img)
  meta = parse_exif(img)
  db.insert(media_id, meta, emb, msg.url)

search(query):
  if query.text:
     qvec = clip.encode_text(query.text)
  elif query.image:
     qvec = model.encode(query.image)
  hits = vector_index.search(qvec, k=100)
  return rerank_filter(hits, query.filters)

import faiss, numpy as np

# 학습/색인 구축
d = 768
index = faiss.index_factory(d, "HNSW32,Flat")
index.hnsw.efConstruction = 200
embeddings = np.load("embeddings.npy").astype("float32")
index.add(embeddings)
faiss.write_index(index, "media.index")

# 검색
index = faiss.read_index("media.index")
q = np.load("qvec.npy").astype("float32")
D, I = index.search(q, k=20)

-- 텍스트 필터 + 임베딩 근접 검색(top-k)
SELECT media_id, mime_type, storage_url
FROM media
WHERE tags && ARRAY['outdoor','sunset']
ORDER BY embedding <#> '[0.12, -0.03, ...]' -- 코사인 거리
LIMIT 20;

import boto3
s3 = boto3.client('s3')
url = s3.generate_presigned_url('get_object',
    Params={'Bucket': 'media-bucket', 'Key': 'path/to/key.mp4'},
    ExpiresIn=3600)

운영 병목을 관찰하고 확장하는 기준

색인 계층은 IVF-PQ/HNSW 매개변수(nlist, M, efSearch)를 튜닝하고 주기적으로 리빌드한다. 저장 계층에서는 가변 청크(4~16MB), 멀티파트 업로드, S3 Transfer Acceleration을 고려한다. 스트리밍에는 해상도·비트레이트·키프레임 간격을 포함한 ABR Ladder 최적화와 Low-Latency HLS가 필요하다.

썸네일·키프레임은 CDN 캐시로, Top-K 벡터 결과는 검색 결과 캐시로 다룬다. 시간·공간·고객 단위 파티션으로 핫셋을 나누고, rebuffer ratio·startup time 같은 QoE 지표와 색인 지연, 워커 슬로우로그를 관측한다.

영역	병목	대응
CPU/GPU	임베딩 추출 지연	배치·큐 우선순위·GPU 풀·모델 경량화
I/O	업/다운로드 병목	멀티파트·병렬 업로드·압축
네트워크	CDN 미스	오브젝트 캐시 정책·프리워밍
DB	벡터 검색 지연	ANN 파라미터 튜닝·샤딩·Rerank Top-K 축소

미디어 데이터에 필요한 보안과 거버넌스

접근 제어는 RBAC/ABAC와 사전 서명 URL 만료 정책으로 구성한다. 저장 시에는 KMS, 전송 시에는 TLS를 사용하고 키 회전 정책을 운영한다.

구성 선택지별 특성

구분	MongoDB + GridFS	PostgreSQL + pgvector + S3	Elastic/OpenSearch + S3	Milvus/Weaviate + S3	AWS(매니지드)	GCP(매니지드)
저장	GridFS 청크	S3 객체, 메타는 PG	S3, 인덱스는 ES	S3, 메타는 RDB/NoSQL	S3, Dynamo/Opensearch	GCS, Vertex/BigQuery
벡터	외부/플러그인	pgvector(HNSW)	kNN 플러그인	내장(ANN)	OpenSearch kNN, Bedrock/SmK	Matching Engine
스트리밍	앱 레벨	HLS/DASH 외부	앱 레벨	앱 레벨	MediaConvert/IVS	Transcoder
장점	단순 일체형	정합성·SQL 생태계	강력한 텍스트 검색	대규모 벡터·확장성	관리형·신뢰성	관리형·AI 연동
고려	대용량 확장성	운영 복잡도	비용·운영	운영 난이도	비용·종속	비용·지역성

OTT/VOD에서는 썸네일·트랜스코딩·자막·추천 파이프라인을 통합할 수 있다. 커머스는 유사 이미지 검색과 다각도 상품 묶음 추천에, 의료(PACS)는 DICOM 메타데이터 인덱싱과 장기 보관 정책에 활용한다. 공공·스마트시티에서는 CCTV 검색, 이벤트 탐지, 프라이버시 보호가 대상이 되며, 교육·저작권 영역에서는 강의 영상 DRM과 불법 복제 추적에 쓰인다.

서비스 목적에 맞는 저장 전략과 ANN 색인, 운영 자동화의 조합이 멀티미디어 DB의 성패를 좌우한다. 초기에는 단순한 구조로 시작하고, 트래픽과 데이터가 증가하는 흐름에 맞춰 색인·파티션·캐시를 확장한다.