연결 코드는 줄일 수 있지만 RAG의 복잡성 자체가 사라지지는 않습니다. Unbody는 데이터 수집부터 검색과 생성까지를 GraphQL, REST API 뒤에 묶어 빠른 MVP에 유리하지만, 청킹과 임베딩을 직접 조정해야 하는 시스템에서는 추상화가 제약이 될 수 있습니다. 도입 전에 sync freshness, ACL, citation quality와 query field별 latency, cost를 실제 source로 검증해야 합니다.
Unbody 저장소는 Google Drive, Notion, Discord, Slack 등에 흩어진 비정형 자료를 가져와 인덱싱하고 LLM 기능으로 연결하는 백엔드 프레임워크입니다. “AI의 Supabase”라는 표현은 제품 범위를 설명하는 비유이지, Supabase와 같은 데이터베이스, 인증 기능을 모두 제공한다는 뜻은 아닙니다.
Unbody는 파이프라인을 Perception, Memory, Reasoning, Action으로 나눕니다.
Temporal 워크플로로 연결된 소스를 동기화한다는 점은 여러 SaaS의 변경 내용을 계속 반영하는 데 중요합니다. 멀티모달 경로에는 Imgix와 Mux 연동도 원문에 소개돼 있습니다. 각 서비스를 직접 붙이는 코드는 줄지만, 어느 소스가 언제 동기화됐고 인덱스가 최신인지 관찰하는 책임은 남습니다.
원문은 Google 문서에서 특정 텍스트를 찾고 generate 필드로 세 줄 요약을 만드는 쿼리를 보여 줍니다. 핵심 형태는 다음과 같습니다.
1
2
3
4
5
6
query {
GoogleDoc(where: { text: { Contains: "2026년 AI 트렌드" } }) {
title
summary: generate(prompt: "이 문서의 핵심 내용을 3줄로 요약해줘.")
}
}
이 코드는 원문 시점의 스키마를 설명하는 핵심 조각입니다. 데이터 소스 인증, 인덱스 설정, 모델 공급자와 오류 처리가 빠져 있어 독립적으로 실행되는 완전한 예제가 아니며, 현재 스키마와 대소문자를 프로젝트 문서에서 다시 확인해야 합니다.
장점은 프론트엔드가 검색 API와 LLM API를 따로 조립하지 않아도 된다는 점입니다. 반대로 쿼리 한 줄 안에서 검색과 생성이 함께 일어나므로 지연, 토큰 사용량, 실패 원인을 필드별로 관찰할 수 있어야 합니다.
사내 온보딩 검색처럼 여러 소스의 자료를 한곳에서 질의하거나, 콘텐츠에 자연어 검색과 자동 요약을 붙일 때 구조가 잘 맞습니다. Unbody의 Gray 저장소는 AI 네이티브 블로그 활용 예로 원문에 소개됩니다.
특정 LLM에 고정되지 않고 텍스트, 이미지, 비디오를 같은 API 계층에서 다룰 수 있다는 점도 초기 제품에는 편리합니다. 하지만 원문이 인용한 개발 시간 단축 수치는 프로젝트 측 사례이며, 데이터 정제와 권한 설계까지 모든 팀에서 같은 시간이 나온다는 보장은 아닙니다.
원문도 프로젝트가 초기 단계라 문서와 edge case가 부족하고, 깊은 커스텀에는 답답할 수 있다고 지적합니다. 도입 전에는 실제 데이터로 다음을 확인해야 합니다.
질문이 단순하고 출시 속도가 중요하면 통합 API의 이득이 큽니다. 검색 품질이 제품의 핵심 차별점이고 세밀한 랭킹, 청킹 실험이 많다면 LlamaIndex나 자체 파이프라인처럼 낮은 추상화가 더 적합할 수 있습니다. Unbody의 선택 기준은 코드 줄 수가 아니라, 숨겨진 기본값을 팀이 받아들일 수 있는가입니다.
Google Drive, Notion 같은 원본에서 create, update, delete를 시간표에 따라 발생시키고 index 반영 시간을 측정합니다. Connector가 실패하거나 API rate limit에 걸리면 stale 상태를 사용자에게 표시해야 합니다.
| Event | 확인할 것 |
|---|---|
| New document | 검색 가능해질 때까지의 lag |
| Content update | old chunk가 제거되고 새 version만 나오는가 |
| Permission change | 기존 embedding, cache 접근이 즉시 막히는가 |
| Delete | raw, chunk, vector, generated derivative 제거 |
| Connector failure | retry, dead letter와 operator alert |
Workflow success log만 보지 않고 source version과 indexed version을 연결합니다. Temporal retry가 있어도 영구 실패가 조용히 누적되면 RAG는 오래된 답을 확신 있게 만들 수 있습니다.
generate result와 함께 top chunks, source, version, retrieval score와 prompt token을 trace합니다. Answer가 틀렸을 때 ingestion, retrieval, generation 중 어디서 실패했는지 나눠야 합니다.
정답, 답 없음, 충돌 문서와 ACL denial question으로 evaluation set을 만듭니다. Chunk size, embedding, reranker 설정을 바꿀 수 있는 범위와 회귀 결과를 확인합니다. 필요한 control이 API에 없으면 custom extension 비용 또는 lower-level pipeline 선택을 비교합니다.
한 request에서 여러 document와 generate field를 요청하면 검색, LLM call이 field 수만큼 늘 수 있습니다. Resolver latency, external API call, token과 error를 field path별로 기록합니다. Partial failure 때 전체 response를 재시도해 중복 generation이 생기지 않게 합니다.
Query complexity, depth limit, timeout와 rate limit를 둡니다. Client가 무제한 generation field를 요청하거나 broad collection을 조회해 비용을 폭증시키지 못하게 합니다. Cached response에는 source version과 model config를 연결해 stale answer를 구분합니다.
Vector DB, embedding, LLM을 바꿀 때 schema 호환성, full re-index, downtime과 quality regression을 기록합니다. Interface가 provider-agnostic이어도 vector dimension이나 metadata filter가 달라 migration이 필요할 수 있습니다.
Export 가능한 raw data, chunk, metadata와 vector representation 범위를 확인하고 rollback runbook을 만듭니다. MVP의 빠른 시작과 장기 portability를 같은 기능표로 보지 않습니다.
연결 code는 줄지만 parser, chunking, embedding, ACL, retrieval evaluation과 model cost는 남고 일부 기본값은 abstraction 안에 숨을 수 있습니다.
검색, generation field는 서로 다른 latency, failure, cost를 가지므로 retrieved source, model output과 error를 field별 trace로 분리해야 합니다.
Connector 인증과 index metadata가 source ACL을 사용자 query까지 전달하는지 negative test해야 하며 shared embedding, cache에서 tenant data가 섞이면 안 됩니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.