software

엣지에서 RAG 구축: Cloudflare Workers, Vectorize, 그리고 FAISS — 실제로 작동하는 것

발행: (2026년 1월 7일 오전 11:20 GMT+9)
5 min read
원문: Dev.to

Source: Dev.to

“Building RAG on the Edge: Cloudflare Workers, Vectorize, and FAISS – What Actually Works”의 표지 이미지

Karol

소개

저는 Cloudflare Workers, 새로운 Vectorize 서비스, 그리고 FAISS를 활용해 검색‑증강 생성 (RAG) 시스템을 구축했습니다. 여기서 배운 점은 다음과 같습니다:

  • 엣지 컴퓨팅은 매력적이지만, 만능 해결책은 아닙니다.
  • 스택은 동작하지만, 기존 방식이 피할 수 있는 마찰 지점에 부딪히게 됩니다.

이 글은 튜토리얼이 아니라 실제 트레이드‑오프에 대한 사후 분석입니다.

섹션 1: 이론적으로는 훌륭해 보였던 아키텍처

내가 이 스택을 선택한 이유

  • Cloudflare Workers – 콜드 스타트 없이 서버리스 추론을 제공한다고 약속했습니다.
  • Vectorize – 엣지에서 관리되는 벡터 스토리지.
  • FAISS – 번개처럼 빠른 로컬 유사도 검색.

이론상: 지연 시간 0, 운영 오버헤드 0, 비용 효율성. 실제로는 더 복잡했습니다.

설정

  1. Vectorize에 임베딩을 저장합니다 (Cloudflare가 관리하는, Postgres 기반 벡터 DB).
  2. 문서를 청크로 나누고 로컬 LLM을 사용해 임베딩을 생성하는 워커를 배포합니다.
  3. 개발 중 로컬 전용 추론을 위한 대체 수단으로 FAISS를 사용합니다.
# Install dependencies
npm install @cloudflare/workers-types wrangler faiss-node
pip install faiss-cpu langchain sentence-transformers

# Configure wrangler.toml
[env.production]
vars = { VECTORIZE_INDEX = "rag-index-prod" }

아키텍처는 견고해 보였지만, 실제 구현 과정에서 세 가지 어려운 문제가 드러났습니다.

Section 2: Where Cloudflare Workers + Vectorize Actually Break

Problem 1 – Worker Execution Timeout vs. Embedding Generation

Cloudflare Workers는 프로덕션에서 30초 CPU 타임아웃을 가지고 있습니다. 문서 길이가 ~2 000 토큰을 초과하면 임베딩을 생성하는 데 지속적으로 이 제한을 초과합니다1.

우회 방법: 무거운 작업을 백그라운드 잡이나 Durable Objects에 넘겨버리면 “서버리스 단순성”이라는 주장 자체가 무의미해집니다.

# This works locally. This fails at the edge.
def embed_document(text: str):
    model = SentenceTransformer('all-MiniLM-L6-v2')
    embeddings = model.encode(text, show_progress_bar=True)  # 5‑15 s per doc
    return embeddings

Problem 2 – Vectorize API Latency Isn’t What They Advertise

Vectorize 쿼리는 200‑400 ms 정도의 응답 시간을 보이며, 이는 단순 유사도 검색조차도 마찬가지입니다. 마케팅에서는 “엣지 속도”라고 하지만, 실제로는 데이터베이스 라운드‑트립을 겪고 있습니다. 로컬 FAISS 인덱스는 같은 쿼리를 ≈ 1 초에 처리할 수 있어 충분히 허용 가능한 수준입니다.

Cloudflare Workers + Vectorize가 실패하는 경우:

  • 200 ms 이하의 검색, 재정렬, 혹은 무거운 추론이 필요한 RAG 파이프라인
  • 추상화가 새어나와서 결국 Durable Objects, KV 폴백, 외부 서비스 등을 직접 관리해야 함

로컬 RAG가 승리하는 이유:

BenefitExplanation
No network overhead모든 작업이 프로세스 내에서 실행됩니다.
State management is trivial로드된 모델을 메모리에 유지하면 됩니다.
Inference quality is higher타임아웃 압박 없이 더 작고 빠른 모델을 로컬에서 실행할 수 있습니다.
Cost is predictable검색에 대한 요청당 비용이 발생하지 않습니다.

엣지 컴퓨팅이 실제로 의미가 있는 경우: 가벼운 추론(분류, 라우팅) 이외의 RAG는 아닙니다.

교훈: Cloudflare Workers를 트렌드라서 사용하지 마세요. 문제의 제약에 맞을 때만 사용하십시오. RAG는 그 제약에 맞지 않습니다. 로컬이나 GPU가 장착된 전통적인 서버에 배포하면 더 빠르게 배포할 수 있고 비용도 절감됩니다.

Sources

5

Footnotes

  1. Cloudflare Workers는 프로덕션 환경에서 30초 CPU 실행 제한을 적용합니다. ↩

Back to Blog

관련 글

더 보기 »