밈 검색 서비스, 1초대 응답과 최신 짤을 함께 잡는 설계

밈 검색기의 성패는 AI 모델보다 기다리는 시간과 결과 순서에서 먼저 갈린다. 검색에 수 초가 걸리거나 오래된 짤이 첫 화면을 차지하면 의미를 잘 이해해도 손이 가지 않는다. 그렇다면 1초대 체감 속도와 최신성, 한국어 표현의 미묘한 맥락을 어떻게 한 파이프라인에 담아야 할까.

검색할 때 이미지를 분석하면 늦을 수밖에 없다

밈 검색은 사용자가 검색어를 넣은 뒤 이미지를 읽는 작업이 아니다. 수집 단계에서 분석을 끝내고 검색 시점에는 준비된 색인만 조회해야 한다. Nielsen Norman Group은 1초 안팎을 사용자의 사고 흐름이 끊기지 않는 경계로 설명한다. 커뮤니티에서 나온 1~2초 정도를 요구하는 반응도 이 기준과 크게 다르지 않다. (nngroup.com)

구축 순서는 명확하다. 사용 권한을 확인한 원본을 오브젝트 스토리지에 넣고 각 파일에 id, source, createdAt, uploadedAt, width, height, mimeType을 부여한다. 이어 OCR 텍스트, 장면·사물 라벨, 사람이 고친 태그, 짧은 설명, 안전성 등급을 생성한다. 마지막으로 설명과 이미지를 임베딩해 벡터 색인에 저장한다.

AWS Rekognition은 이미지에서 사물·장면·개념 라벨과 신뢰도를 반환한다. Google Cloud Vision은 OCR과 유해 콘텐츠 분류를 제공한다. 밈에서는 화면 속 글자가 중요한 맥락을 차지하므로 일반 이미지 라벨만으로는 부족하다. Meta가 공개한 Rosetta 사례도 이미지 내부 문자를 검색과 접근성에 활용할 수 있다고 설명한다. (docs.aws.amazon.com)

직접 운영할 출발점도 있다. 오픈소스 Meme Search는 이미지 설명 생성, 임베딩, 의미 검색과 키워드 검색을 로컬 파이프라인으로 구성한다. 이미지를 폴더에 넣어 색인한 뒤 API나 CLI로 검색 결과와 메타데이터를 가져오는 구조다. (github.com)

RAG보다 하이브리드 검색이 먼저다

검색 결과로 짤 목록을 돌려줄 뿐이라면 엄밀히 말해 RAG는 필요하지 않다. RAG는 검색한 자료를 언어 모델의 생성 답변에 넣는 방식이다. 밈 선택 화면에는 키워드 검색과 벡터 검색을 합친 하이브리드 검색이 더 직접적이다.

키워드 경로는 OCR 문구, 태그, 작품명과 인물명처럼 정확한 문자열에 강하다. 벡터 경로는 “퇴근 직전 일을 받은 표정”, “황당하지만 웃는 상황”처럼 장면을 설명한 문장을 찾는다. Azure AI Search와 Weaviate 문서도 BM25 계열의 전문 검색과 벡터 유사도 검색을 병렬로 실행한 뒤 결과를 합치는 방식을 설명한다. (weaviate.io)

실제 쿼리는 두 경로에서 후보를 뽑아 RRF 같은 방식으로 합친다. 이후 중복 이미지와 저품질 파일을 제거해 결과를 반환한다.

써본 사람들 사이에서는 벡터 검색만 적용하면 고유명사와 짧은 유행어를 놓치고 의미가 비슷한 엉뚱한 이미지가 상단에 섞인다는 불만도 나온다. 반대로 키워드만 쓰면 표현이 조금 달라졌을 때 결과가 사라진다.

CLIP 계열 모델은 텍스트와 이미지를 같은 공간에 투영해 유사도를 계산한다. Hugging Face 문서의 CLIP 예제처럼 이미지 임베딩은 수집할 때 한 번 만들고 검색어만 요청 시 임베딩하면 된다. 검색할 때마다 전체 이미지를 모델에 다시 넣는 설계와는 처리량 차이가 크다. (huggingface.co)

createdAt 내림차순만으로는 최신 짤을 찾지 못한다

오래된 밈이 앞에 뜨는 문제를 ORDER BY createdAt DESC 하나로 고치면 관련성이 무너진다. 새로 들어온 약한 결과가 정확한 고전 밈을 모두 밀어낼 수 있기 때문이다. 시간은 필터가 아니라 랭킹 점수의 한 요소로 다루는 편이 낫다.

예를 들어 최종 점수를 키워드 관련도 + 의미 유사도 + 최신성 가중치 + 선택 횟수로 구성한다. 최신성에는 업로드 후 시간이 흐를수록 점수가 완만하게 줄어드는 함수를 적용한다. “최신” 필터를 사용했을 때만 최근 범위를 강하게 제한하고 기본 검색에서는 정확한 옛 밈도 남긴다.

createdAt의 의미도 나눠야 한다. 원본이 처음 만들어진 시각, 서비스에 들어온 시각, 최근 다시 유행한 시각은 서로 다르다. 최소한 createdAt, ingestedAt, lastSelectedAt을 분리해야 한다. 날짜가 없는 자료에는 별도 품질 플래그를 두면 정렬 오류를 숨기지 않을 수 있다.

벡터 DB의 메타데이터 필터는 기간, 언어, 정적 이미지 여부를 기준으로 검색 후보를 좁힌다. Qdrant는 자주 거르는 필드에 payload index를 만들도록 권장한다. pgvector는 근사 검색 뒤 필터가 적용되면 결과 수와 재현율이 줄 수 있어 반복 스캔, 부분 색인, 파티셔닝을 선택지로 제시한다. (qdrant.tech)

1초대 체감 속도는 검색과 이미지 전송을 나눠 측정한다

테스트 화면에 고정된 응답 시간을 표시하는 것만으로는 병목을 찾을 수 없다. 브라우저에서 요청 시작, 검색 API 완료, 첫 썸네일 표시, 전체 그리드 완료를 따로 기록해야 한다. 서버에서는 임베딩 생성, 키워드 조회, 벡터 조회, 재정렬 시간을 분리하고 p50·p95·p99를 확인한다.

첫 화면에는 원본 대신 작은 WebP나 AVIF 썸네일을 보낸다. 원본은 사용자가 열거나 공유할 때만 요청한다. Tenor도 검색 결과에서는 작은 tinygif를 먼저 불러오고 공유 시 큰 파일을 쓰도록 안내한다. Cloud CDN과 Cloudflare Images는 변환된 이미지 크기를 엣지에 캐시해 반복 요청에 따른 원본 처리와 전송량을 줄인다. (developers.google.com)

검색 API 응답에는 이미지 바이너리를 넣지 말고 id, 썸네일 URL, 크기, 점수와 핵심 태그만 담는다. 자주 쓰이는 검색어는 짧게 캐시하고 입력 중 자동완성은 debounce한다. 사용자가 먼저 보이는 결과를 보는 동안 나머지를 지연 로딩하면 전체 데이터가 도착하기 전부터 선택할 수 있다.

외부 API와 자체 데이터의 역할이 달라졌다

GIPHY Search API는 검색어, 언어, 국가, 등급과 결과 수를 지정할 수 있어 빠른 프로토타입에 적합하다. 그러나 국내 커뮤니티에서 통하는 정지 이미지와 한국어 문구를 충분히 확보한다는 보장은 없다. 기존 큐레이션 서비스는 즉시 둘러볼 자료가 많다는 장점이 있지만 광고과 탐색 동선에 대한 불만도 나왔다. 인기 목록을 제공하는 서비스는 경쟁 화면과 분류 방식을 살펴볼 비교 대상이다. (developers.giphy.com)

Tenor는 2026년 1월부터 신규 API 클라이언트를 받지 않는다고 공식 문서에 명시했다. 새 서비스를 외부 GIF API 하나에만 기대어 설계하기 어려워진 변화다. (developers.google.com)

작은 팀이라면 자체 보유 자료를 핵심 색인으로 삼고 외부 API는 보조 결과로 분리하는 구성이 현실적이다. 검색 품질을 좌우하는 자산은 거대한 모델보다 정돈된 원본, 교정 가능한 태그, 실제 선택 기록이다.

빠른 밈 검색기는 AI가 즉석에서 그림을 이해하는 서비스가 아니다. 미리 이해해 둔 데이터를 1초 안에 정확한 순서로 꺼내는 서비스다.