OpenArt, Zilliz Cloud로 8M+ AI 비디오 크리에이터를 위한 멀티모달 검색 지원
25 s → 300 ms
P99 검색 지연 시간, ES → Zilliz
~85% 낮음
마이그레이션 후 비용 계산
네이티브 멀티벡터 검색
이미지와 텍스트 벡터가 함께 조회됨
456M
재임베딩 없이 마이그레이션된 벡터
크리에이터는 이미지 한 장을 만들고 떠나지 않습니다. 그들은 캐릭터와 세계, 이야기를 구축하며, 지금까지 생성한 모든 것이 다음 장면의 재료가 됩니다. Zilliz Cloud를 사용하면 그 전체 라이브러리를 하나의 창의적 기억으로 다룰 수 있습니다.
John Qiao
OpenArt 소개
OpenArt는 전 세계에서 가장 널리 사용되는 AI 이미지 및 비디오 생성 플랫폼 중 하나로, 취미 사용자, 마케터, 현업 엔터테인먼트 전문가 등 800만 명 이상의 크리에이터가 사용하고 있습니다. Google, OpenAI, Seedance 등의 100개 이상의 모델을 하나의 캔버스에 담고 있지만, 모델 자체는 상품화된 부분입니다. OpenArt가 그 위에 구축하는 것은 연속성(continuity)입니다. 장면을 넘나들며 캐릭터를 유지하는 Character Builder, 다중 장면 스토리를 위한 One-Click Story, 그리고 크리에이터가 트레일러, 광고, 소셜 비디오를 제작하는 데 사용하는 스토리보드 제품군이 그것입니다. 이 모든 것의 배후에 있는 야망은 AI 네이티브 IP를 모든 크리에이터가 손에 넣을 수 있게 하는 것입니다. 즉, 지속되고 성장하는 캐릭터와 세계를 만드는 것이지, 그렇지 않은 이미지를 만드는 것이 아닙니다.
연속성은 생성 시점뿐만 아니라 전체적으로 가장 어려운 부분입니다. AI 비디오의 과제는 좋은 15초를 만드는 것이 아니라, 다음 15초를 만들어 같은 스토리에 속하게 하는 것입니다. 이는 이후 단계에도 영향을 미칩니다. 크리에이터는 몇 달 동안 하나의 세계로 돌아오며, 그들이 지금까지 생성한 모든 것은 다음 장면의 참조 자료가 됩니다. 크리에이터의 기존 생성물은 파일 이름이나 날짜가 아닌 의미로 검색 가능해야 하며, 바로 이 지점에서 OpenArt는 Zilliz Cloud를 활용합니다.
과제
OpenArt의 크리에이터 검색은 Elasticsearch의 벡터 검색으로 운영되었습니다. 라이브러리가 작을 때는 문제없이 작동했지만, 생성 기록이 수억 개의 벡터를 넘어서면서 네 가지 문제가 발생했습니다.
- P99 검색 지연 시간이 25초에 도달했습니다. Elasticsearch의 인덱스 수명주기 관리(ILM)는 로그 데이터용으로 설계되어 OpenArt의 인덱스를 대략 90일마다 hot → warm → cold → frozen 순으로 전환했고, 대부분의 데이터가 frozen 상태가 되었습니다. 그러나 벡터 검색은 반대의 접근 패턴을 보입니다. top K 순위를 매기려면 모든 항목을 점수화해야 하기 때문입니다. 모든 검색은 frozen 계층에 접근하여 네트워크를 통해 데이터를 다시 가져와 응답해야 했습니다.
- 인덱스 수가 기하급수적으로 증가했습니다. Elasticsearch는 90일마다 최소 하나의 새 인덱스를 생성하고 병합하지 않았기 때문에, 쿼리가 분산되어야 하는 인덱스 수가 계속 늘어났습니다. 점점 더 커지는 라이브러리에서 팀은 약 2년 안에 검색 성능이 급격히 저하될 것으로 예상했습니다.
- OpenArt는 검색 플랫폼 전체 비용을 지불하면서 그중 하나의 특정 기능만 사용하고 있었습니다. 게다가 클러스터는 워크로드의 실제 요구 사항을 측정하기 전에 크기를 정했기 때문에 과도하게 프로비저닝되었습니다.
- 멀티 벡터 검색(retrieval)을 직접 구축해야 했습니다. Elasticsearch에는 이미지 벡터와 텍스트 벡터를 함께 쿼리하는 네이티브 방법이 없었기 때문에, OpenArt는 자체 dual-kNN 알고리즘을 작성하고 두 검색을 실행하고 결과를 융합하고 필터링하기 위해 서드파티 구성 요소를 연결해야 했습니다. 이는 OpenArt의 차별화 요소가 아닌 기능에 대한 영구적인 유지 관리 항목이 되었습니다.
Zilliz Cloud를 선택한 이유
OpenArt 엔지니어링 팀은 Pinecone과 Qdrant를 평가했지만 둘 다 적합하지 않았습니다. 팀은 회사 초기에 Milvus 자체를 직접 운영한 적이 있고 만족했지만, 당시에는 셀프 호스팅의 운영 부담 때문에 선택하지 않았습니다. Zilliz Cloud는 그 문제를 해결했습니다. Zilliz Cloud는 오픈소스 Milvus를 만든 동일한 팀이 구축했으며 Milvus API와 100% 호환되므로, 팀의 기존 지식과 클라이언트 코드를 그대로 사용할 수 있었습니다.
OpenArt 자체 데이터에 대한 벤치마크에서 성능이 확인되었고, 평가는 거기서 끝났습니다. Zilliz Cloud를 돋보이게 하는 네 가지 요소는 다음과 같습니다.
벡터 검색이 데이터를 읽는 방식에 맞게 설계된 아키텍처. Zilliz Cloud는 데이터 온도에 따라 데이터 계층을 자체적으로 관리합니다. 자주 조회되는 데이터는 캐시로 올리고, 필요 없는 데이터는 콜드 스토리지로 내리며, 애플리케이션이 고민해야 할 수명 주기 정책이 없고, 세그먼트 수준 자동 압축이 데이터가 커짐에 따라 백그라운드에서 데이터를 병합합니다. 이 두 가지 기능은 OpenArt가 겪어왔던 장애 모드, 즉 동결 계층 순회와 무제한 인덱스 증가를 정확히 해결하므로 라이브러리가 커져도 OpenArt의 검색이 느려지지 않습니다.
네이티브 멀티 벡터 검색. 단일 Zilliz Cloud 컬렉션은 여러 벡터 필드를 보유하고 하나의 요청으로 함께 쿼리하며, 구성 가능한 가중치로 결과를 융합합니다. 이것은 OpenArt가 Elasticsearch 위에서 직접 구축해 오던 기능으로, 이를 네이티브로 지원받게 되면서 팀은 자체 코드를 삭제할 수 있었습니다.
저장된 데이터가 아닌 온디맨드 컴퓨팅에 연동된 가격. 대안 중 하나는 데이터 볼륨 기준으로 청구했는데, 이는 창작 아카이브에는 잘못된 축입니다. 코퍼스는 계속 커지지만 어느 순간에도 일부만 조회되기 때문입니다. Zilliz Cloud의 온디맨드 컴퓨팅 기반 모델을 통해 OpenArt는 필요한 성능에 맞게 크기를 정하고 워크로드 변화에 따라 크기를 조정할 수 있으며, 과거 데이터에 대한 세금을 내지 않아도 됩니다.
인프라 전문가 없이 운영 가능. 관리형 서비스라도 실제로 사용하는 사람들이 일상적으로 사용할 수 있어야 합니다. OpenArt는 문서를 읽지 않고도 직관적으로 탐색할 수 있을 만큼 콘솔이 명확하다는 것을 발견했습니다. 이는 그들이 결코 사용하지 않을 10년간 축적된 기능을 가진 범용 검색 플랫폼과는 뚜렷한 대조를 이룹니다.
"우리는 수백만 명의 창작자에게 서비스를 제공하므로 모든 인프라는 빠르고 예측 가능하며 누군가 지켜볼 필요가 없어야 합니다. Zilliz Cloud는 첫 시도에서 그 기준을 통과한 몇 안 되는 서비스 중 하나입니다." — 대니 시옹, 소프트웨어 엔지니어, OpenArt
솔루션: Zilliz Cloud가 OpenArt를 지원하는 방법
OpenArt는 Zilliz Cloud를 사용하여 검색창 뒤에서 크리에이터의 생성 기록에 대한 벡터 검색을 실행하며, 자격을 갖춘 요금제의 구독자에게 제공됩니다. 수개월에 걸쳐 수천 개의 이미지와 클립을 만든 창작자가 캐릭터 이름, 분위기, 장면 같은 문구를 입력하면 파일명이나 날짜가 아닌 의미로 순위가 매겨진 자신의 과거 작업물을 돌려받습니다.
이 작업은 생각보다 어렵습니다. 생성 결과물에는 메타데이터가 없기 때문입니다. 제목도, 태그도, 폴더도 없습니다. 이를 설명하는 것은 에셋 자체와 이를 만든 프롬프트, 두 가지뿐입니다. OpenArt는 둘 다 인덱싱합니다. 각각 상대방이 담지 못한 정보를 담고 있기 때문입니다. 프롬프트는 창작자가 요청한 내용을 이름, 의도, 스타일 단어로 담고 있고, 에셋은 모델이 실제로 생성한 결과물을 담고 있는데, 이 둘은 종종 일치하지 않습니다. 둘 중 하나만 검색하면 라이브러리의 절반을 잃게 됩니다.
OpenArt는 작업을 세 가지 서비스에 분산합니다.
- 애플리케이션과 기본 데이터베이스는 Google Cloud에서 실행됩니다.
- 임베딩 서비스는 Modal에서 실행됩니다 — 팀이 서버리스 GPU 함수로 직접 호스팅하는 Jina CLIP 모델입니다.
- 벡터 저장 및 검색은 Zilliz Cloud가 담당합니다. 팀은 모델 레이어를 자체 제어 하에 유지하고 확장이 필요한 레이어는 위임합니다.
AI 이미지 및 비디오 생성은 지속적으로 만들어지고 훨씬 나중에 검색되므로, OpenArt는 완전히 다른 시기와 속도로 실행되는 두 개의 독립적인 절반으로 시스템을 구축했습니다.
- 쓰기 경로는 모든 새 생성물을 벡터로 변환하여 Zilliz Cloud에 저장합니다. 생성 이벤트에 의해 트리거되어 백그라운드에서 지속적으로 실행되며, 누구도 이를 기다리지 않습니다.
- 읽기 경로는 창작자가 검색창에 입력할 때만 실행됩니다. 누군가 스피너를 보고 있기 때문에 수백 밀리초 안에 결과를 반환해야 합니다.
쓰기 측은 결코 쿼리 경로에 있지 않습니다 — 둘이 만나는 유일한 곳은 컬렉션 자체입니다. 이러한 분리 덕분에 지속적인 수집이 쿼리 지연 시간으로 나타나지 않습니다.
쓰기 경로: OpenArt가 생성물을 두 개의 벡터로 바꾸는 방법
- 적격 요금제를 사용하는 크리에이터가 이미지나 클립을 생성하면 OpenArt는 그 스냅샷을 Google Cloud의 기본 데이터베이스에 기록합니다.
- 이 이벤트에 대해 Google Cloud Function이 트리거되어 Modal에서 OpenArt의 임베딩 서비스를 호출합니다. Jina CLIP은 이미지와 텍스트를 동일한 벡터 공간에 매핑하므로 단일 모델로 팀이 필요한 두 벡터를 모두 제공할 수 있습니다.
- OpenArt는 이 두 벡터(생성된 자산에 대한 벡터와 그 뒤에 있는 프롬프트에 대한 벡터)를 생성 ID 및 읽기 경로에서 필터링할 스칼라 필드(사용자 ID 및 프로젝트 ID)와 함께 Zilliz Cloud에 기록합니다.
OpenArt는 동일한 경로로 비디오를 처리합니다. 각 생성된 클립에서 스냅샷 프레임을 캡처하여 이미지로 임베딩하므로, 두 번째 파이프라인 없이 클립을 스틸 이미지와 함께 검색할 수 있습니다.
또한 검색은 유료 기능이므로 적격 크리에이터의 전체 백 카탈로그가 검색 가능해야 하며, 당일 이후에 만든 것만이 아니라 과거의 모든 자료도 포함되어야 합니다. 예약된 백필(backfill) 작업이 백그라운드에서 지속적으로 실행되어 적격 요금제 크리에이터를 훑고 각 크리에이터의 기록을 동일한 임베딩 및 쓰기 경로를 통해 페이지 단위로 처리합니다. 이는 파이프라인의 안전망 역할도 합니다. 실시간 경로가 쓰지 못한 것은 백필이 다음 패스에서 처리합니다.
읽기 경로: OpenArt가 검색에 응답하는 방법
- 크리에이터가 쿼리를 입력하면 OpenArt는 이를 동일한 Modal 호스팅 모델로 보내 쿼리 벡터로 변환합니다.
- OpenArt는 두 벡터 필드 모두에 대해 단일 멀티 벡터 검색을 Zilliz Cloud에 실행합니다. 이때 두 필드 간에 구성된 가중치와 사용자 및 프로젝트 필터가 첨부됩니다.
- Zilliz Cloud는 두 결과 집합을 융합하고 검색 내부에서 필터를 평가한 후(검색 후가 아니라) 상위 K개를 반환합니다. OpenArt는 렌더링 전에 Google Cloud의 자체 데이터베이스에 대해 최종 매칭 및 필터링을 수행합니다.
OpenArt는 쿼리당 천 개 이상의 결과를 요청합니다. 이는 의미 검색에서 비정상적으로 큰 top K로, 인터페이스가 아니라 작업 부하에 의해 결정됩니다. 활동량이 많은 크리에이터의 경우 단일 프로젝트의 자산이 이미 천 개를 초과하며, "man"과 같은 광범위한 쿼리는 그 몇 배에 해당하는 결과와 정당하게 매칭됩니다.
이전 스택에서 동일한 쿼리는 전혀 달랐습니다. 수명 주기 정책이 생성한 모든 인덱스로 퍼져 나갔고(대부분 동결된 상태), top K를 순위화할 수 있을 때까지 네트워크를 통해 데이터를 가져왔습니다. Zilliz Cloud에서는 OpenArt가 단일 컬렉션에 대해 한 번의 호출만으로 약 300밀리초 안에 답을 얻습니다.
OpenArt가 두 개의 검색을 하나로 통합한 방법
이미지와 프롬프트 결과를 결합하는 것은 OpenArt가 Elasticsearch에서 직접 구축한 이중 kNN 융합 레이어가 담당하던 작업입니다. Zilliz Cloud가 여러 벡터 필드를 기본적으로 쿼리할 수 있기 때문에 팀은 해당 코드를 제거하고 검색을 단일 요청으로 다시 표현한 다음 두 필드 간의 가중치를 기능 플래그로 감쌌습니다. 관련성은 OpenArt가 다시 구현하는 것이 아니라 프로덕션에서 조정하는 대상이 되었습니다.
OpenArt가 마이그레이션한 방법
OpenArt는 약 4억 5,600만 개의 레거시 벡터를 이동하면서 전환 기간을 이용해 데이터 정리를 수행했습니다. 제품에 더 이상 필요 없는 레코드를 삭제하고 기존 수집 경로가 조용히 유발하던 버그를 수정한 것입니다. 한 가지 범위 결정이 프로젝트를 제한적으로 유지했습니다. 팀은 기존 임베딩 모델을 유지하기로 한 것입니다. 수억 개의 자산을 다시 임베딩하는 것은 마이그레이션을 재구축으로 바꾸는 일이었을 것입니다. Zilliz Cloud는 고객이 선택한 모델의 벡터를 저장하므로 OpenArt는 모델 레이어를 건드리지 않고 스토리지와 검색만 이동했습니다.
결과 및 이점
- 검색 지연 시간이 Elasticsearch 사용 시 25초에서 약 300밀리초(P99)로 단축 — 약 80배 빨라졌으며, 창작자가 외면하는 검색 창과 실제로 사용하는 검색 창의 차이를 만들어냈습니다.
- 컴퓨팅 비용이 약 85% 절감 — 동일한 워크로드를 위해 설계된 엔진에서 처리합니다.
- OpenArt는 프로덕션 파이프라인에서 수작업으로 만든 융합 알고리즘을 제거했습니다. Zilliz Cloud의 기본 다중 벡터 검색 덕분에 이중 kNN 코드와 타사 글루 코드가 사라졌으며, 관련성 튜닝은 엔지니어링 프로젝트가 아닌 구성 변경으로 처리됩니다.
- 4억 5,600만 개의 벡터가 단 한 번의 임베딩 재실행 없이 Zilliz Cloud로 이동 — Zilliz Cloud가 모델에 구애받지 않기 때문에 가능합니다. 마이그레이션은 재구축이 아닌 이전 그대로 유지됩니다.
전략적 성과는 OpenArt가 가장 크게 체감하는 부분입니다. 검색이 더 이상 인프라 프로젝트가 아니게 된 것입니다. 검색 유지에 투입되던 엔지니어링 역량이 다시 제품으로 돌아갔습니다. 구체적으로는 OpenArt가 현재 전체 경험의 중심으로 구축하고 있는 에이전트 레이어에 투입되었습니다.
벡터 데이터베이스를 선택하는 팀을 위한 OpenArt의 조언
자체 호스팅 Milvus에서, 그다음에는 Elasticsearch에서 벗어난 경험을 두 번 한 OpenArt 팀은 이 결정을 짧은 목록으로 정리합니다.
- 가격 모델이 워크로드의 형태와 일치하는지 확인하세요. 무엇을 기준으로 청구되는지 물어보고, 어떤 수치가 가장 빨리 증가하는지도 물어보세요. 그 두 가지가 같은 수치라면, 성공에 비례해 커지는 문제를 가진 것입니다.
- 아키텍처가 액세스 패턴과 일치하는지 확인하세요. 기능 목록이 아니라 스토리지 설계를 읽어보세요. 데이터를 접근 범위 밖으로 옮기는 정책은 로그에는 적합하지만 벡터 검색에는 맞지 않습니다.
- 프로비저닝 전에 자체 성능 요구 사항을 파악하세요. OpenArt의 가장 큰 비용 실수는 프로파일링하지 않은 워크로드에 하드웨어를 과잉 프로비저닝한 것이었습니다. 먼저 측정하세요.
- 마이그레이션을 버릴 것을 정리할 기회로 여기세요. 이전하는 모든 것은 앞으로도 계속 비용을 지불하며 검색하게 됩니다.
다음 단계
OpenArt는 현재 창작자의 생성 기록 전체에 대한 검색에 Zilliz Cloud를 사용하며, 이를 세 가지 방향으로 확장할 계획입니다:
- 공유 에셋 및 템플릿 라이브러리 — 팀의 라벨링 작업과 추천 템플릿 모두 의미론적 검색(semantic search)이 필요합니다.
- 스칼라 필터링 — 마이그레이션 중에 연기되었으며 이제 다시 우선순위가 올라오고 있습니다.
- 에이전트 메모리 — 팀이 가장 관심을 두는 부분입니다. OpenArt가 개별 도구들에서 이를 오케스트레이션하는 에이전트로 전환함에 따라 — 15초짜리 생성물을 1분 또는 3분짜리 영상으로 늘리는 과정 — 에이전트는 세션을 넘어 창작자가 어떤 프로젝트에 참여 중인지, 어떤 브랜드의 광고를 만들고 있는지를 기억해야 합니다. 이것은 벡터 검색 문제이며, OpenArt가 Zilliz Cloud 사용을 다음으로 확장할 영역입니다.
"OpenArt는 AI 네이티브 창작의 모습을 정의하고 있습니다. 수백만 명의 창작자가 장면을 넘어 일관되게 이어지는 캐릭터와 스토리를 만들고 있습니다. 우리는 Zilliz Cloud가 그 뒤에 있는 검색 기반이라는 점을 자랑스럽게 생각하며, 그들의 에이전트가 기억을 시작하면서 함께 계속 구축해 나갈 것을 기대합니다." — James Luan, Zilliz CTO
Zilliz Cloud를 무료로 사용해 보세요
Zilliz Cloud는 Milvus API와 호환되는 엔터프라이즈 AI를 위한 완전 관리형 벡터 데이터베이스이자 벡터 레이크베이스입니다. 엔터프라이즈급 보안과 유지보수 불필요한 운영을 갖춘 대규모 고성능 벡터 검색을 제공하며, 멀티모달 데이터 레이크의 개방성, 확장성, 경제성으로 확장됩니다. 프로덕션 AI를 위한 비정형 데이터를 검색, 분석, 관리하는 단일 플랫폼입니다.
멀티모달 검색, RAG, 에이전트 메모리를 구축하든, Zilliz Cloud는 OpenArt를 구동하는 것과 동일한 검색 기반을 제공합니다. Zilliz Cloud를 무료로 시작하세요, 또는 팀과 상담하세요.
"기존 검색은 P99에서 25초가 걸렸습니다. 그건 용납할 수 없는 수준이었죠. Zilliz Cloud 덕분에 1/3초 미만으로 줄었고, 직접 유지 관리하던 검색 코드를 삭제할 수 있게 되었습니다."
Danny Xiong