Schift는 간단합니다. 자료를 넣으면 dirty work를 다 해서 깔끔한 graph-vector DB로 만들어주는 프로덕트에요.

PDF 던지고, DOCX 던지고, HTML 던지고. 그러면 Schift가 알아서 파싱하고, 구조를 파악하고, 청킹하고, 임베딩하고, 인덱싱합니다. 여러분한테 돌아오는 건 바로 검색 가능한 깔끔한 DB에요.

“그거 다른 데서도 되지 않나요?”

됩니다. 근데 직접 해보면 그 사이에 낀 dirty work가 얼마나 지저분한지 알게 돼요. 하나씩 보여드릴게요.

1. 파싱 — PDF는 텍스트 파일이 아닙니다

PDF를 텍스트로 변환해 본 적 있으시면 아실 겁니다. pdf2text 돌리면 이렇게 나와요:

제1조 (목적) 이 약관은 회사가 제공하
는 서비스의 이용   조건 및 절차에 관한
사항을 규정함을     목적으로 합니다.

테이블은 더 심합니다. 열이 섞이고, 행 순서가 뒤집히고, 숫자가 붙어버려요. 이미지 안에 있는 텍스트는 아예 사라집니다. 페이지 번호, 헤더, 푸터가 본문 사이에 끼어들어요.

DOCX는 괜찮다고요? 중첩된 테이블, 텍스트 박스, SmartArt, 각주. 이런 것들이 구조를 깨뜨립니다. HTML은 또 사이트마다 마크업이 제각각이에요.

직접 하면: 포맷별로 파서를 고르고, 예외 처리를 쌓고, 깨지는 케이스가 나올 때마다 패치합니다. LlamaParse, Unstructured, Tika… 어떤 걸 쓸지 고르는 것부터가 리서치에요.

Schift가 하는 일: 파일을 던지면 포맷을 감지하고, 최적의 파서를 선택하고, 구조를 보존한 채로 추출합니다. 테이블은 테이블로, 이미지는 VLM으로 텍스트를 뽑아요. 파서가 실패하면 자동으로 fallback 경로를 탑니다. 여러분은 파일만 올리면 됩니다.

2. 청킹 — text.split()의 비극

파싱이 끝나면 텍스트를 적절한 크기로 잘라야 합니다. 이걸 청킹이라고 해요.

대부분의 튜토리얼은 이렇게 알려줍니다:

chunks = text.split('\n\n')  # 또는
chunks = [text[i:i+1500] for i in range(0, len(text), 1500)]

1500자로 자르면 이런 일이 생겨요:

“계약 해지 시 위약금은” 여기서 잘림 → 다음 청크: “매월 이용료의 30%입니다”
테이블 3행이 앞 청크에, 4행이 뒷 청크에 들어감
제목이 이전 섹션 끝에 붙어버림

검색하면 “위약금”이 나오는데 숫자가 없는 청크가 반환됩니다. LLM이 “위약금 정보를 찾을 수 없습니다”라고 답해요. 정보는 있는데 잘려서 못 찾는 겁니다.

직접 하면: 구조적 청킹 로직을 짜야 합니다. 헤딩을 감지하고, 리스트를 묶고, 테이블은 통째로 보존하고, 문장이 중간에 잘리지 않게 해야 돼요. 그래도 edge case는 계속 나옵니다.

Schift가 하는 일: 3단계 청킹을 돌립니다.

구조적 청킹: 헤딩, 섹션, 리스트, 테이블 등 문서 구조를 인식해서 의미 단위로 자릅니다.
에이전틱 청킹: LLM이 청크 경계를 한 번 더 검토합니다. “여기서 자르면 맥락이 깨지는데?”를 잡아내요. 비용이 드는 대신 정확도가 올라갑니다.
기계적 청킹: 위 두 단계를 못 타는 flat text 용 fallback. 문단 기반으로 문장 경계를 지켜서 자릅니다.

“잘 잘렸나?”를 확인하는 것까지 포함입니다. 청킹 품질이 전체 검색 품질의 천장을 결정하거든요.

3. 임베딩 — 모델 고르기부터 양자화까지

텍스트 청크를 벡터로 바꿔야 합니다. 여기서 고를 게 많아요.

어떤 임베딩 모델을 쓸 건지 (OpenAI, Cohere, 공개 HF 모델?)
차원 수는 몇으로 할 건지 (768? 1024? 3072?)
양자화는 할 건지
배치 처리는 어떻게 할 건지
문서가 100만 개면 임베딩 비용이 얼마인지

모델마다 성능이 다르고, 언어별로 강점이 다릅니다. 한국어 문서에 영어 최적화 모델을 쓰면 검색 품질이 뚝 떨어져요.

양자화도 중요합니다. 1024차원 벡터 100만 개를 F32로 저장하면 4GB에요. SQ8로 양자화하면 1GB로 줄어들고, recall 손실도 고려해야죠. 근데 이걸 직접 구현하려면 벡터 인덱스 내부를 건드려야 돼요.

직접 하면: 임베딩 모델 벤치마크를 돌려보고, 차원 수 대비 성능을 비교하고, 양자화 전후 recall을 측정하고, 비용을 계산합니다. 모델을 바꾸면 전체 재임베딩이에요.

Schift가 하는 일: 자료를 넣으면 Schift 자체 임베딩 모델로 벡터를 생성합니다. SQ8 양자화가 기본 적용이에요. 메모리 4분의 1로 줄이면서 recall 차이는 2% 미만. 배치 처리, 병렬화, 재시도 로직 다 내장되어 있어요. 모델을 바꿔야 할 일이 생기면 incremental 재임베딩을 지원합니다.

4. 인덱싱 — 벡터를 저장하고 찾는 것

벡터가 생겼으면 어딘가에 넣고 빠르게 찾을 수 있어야 합니다.

선택지가 많아요. Pinecone, Qdrant, Weaviate, Milvus, pgvector… 각각 장단점이 다르고, 가격 모델이 다르고, 운영 방식이 달라요.

HNSW 인덱스를 쓸 건지, IVF를 쓸 건지. ef_construction은 얼마로 할 건지. 문서가 10만 개일 때는 괜찮았는데 100만 개가 되니까 레이턴시가 튀는 문제. 인덱스 리빌드 중 검색이 안 되는 문제. 이런 게 하나씩 나옵니다.

직접 하면: 벡터 DB를 골라서 호스팅하고, 인덱스 파라미터를 튜닝하고, 스케일링 전략을 세우고, 모니터링을 붙여야 합니다.

Schift가 하는 일: Rust로 만든 자체 엔진을 씁니다. p99 검색 레이턴시 300마이크로초 미만이에요. SQ8 양자화된 HNSW 인덱스를 기본으로 쓰고, 인덱스 파라미터는 데이터 규모에 맞게 자동 조정됩니다. 여러분은 벡터 DB가 뭔지 몰라도 됩니다.

5. 쿼리 강화 — 유저는 짧게 물어봅니다

자료가 DB에 들어갔고, 인덱스도 잘 만들어졌습니다. 이제 유저가 검색합니다.

“해지 방법”

4글자에요. 근데 실제 문서에는 “계약 해지 절차 및 위약금 산정 기준”이라고 적혀 있어요. 이 두 텍스트의 코사인 유사도는 낮습니다. 관련 문서가 검색 결과 7번째에 나오거나, 아예 안 나와요.

이걸 해결하는 방법이 두 가지 있습니다:

HyDE (Hypothetical Document Embeddings): LLM한테 “해지 방법에 대한 가상의 답변”을 생성하게 하고, 그 답변을 임베딩해서 검색합니다. 가상 답변이 실제 문서와 임베딩 공간에서 더 가깝거든요.

쿼리 확장: “해지 방법”을 “계약 해지 절차”, “서비스 해약 방법”, “구독 취소 프로세스” 같은 변형으로 확장해서 전부 검색합니다.

둘 다 LLM 호출 한 번이 추가되지만, recall이 확 올라가요.

직접 하면: HyDE 프롬프트를 설계하고, 쿼리 확장 로직을 짜고, 원래 쿼리와 확장 쿼리 결과를 합치는 로직을 만들어야 합니다.

Schift가 하는 일: 검색 API에 enhance: 'hyde' 또는 enhance: 'expand'를 넘기면 됩니다. 프롬프트 설계, 결과 병합 다 내장이에요.

6. 리랭킹 — 30개 중 진짜 5개를 고르는 것

벡터 검색으로 상위 30개를 가져왔습니다. 이 중 진짜 관련 있는 건 5~8개에요.

문제는 벡터 유사도만으로는 정확한 순위를 매기기 어렵다는 겁니다. 벡터 검색은 쿼리와 문서를 각각 따로 임베딩해서 비교하거든요. “대략 비슷한 것”을 찾는 건 잘하지만, “정확히 이 질문에 대한 답인가”를 판단하는 건 약해요.

리랭커는 쿼리와 문서를 쌍으로 받아서 관련도를 매깁니다. Cross-encoder 모델이 쿼리와 문서를 동시에 보니까 훨씬 정확해요.

1. 벡터 검색: top_k=30 (넉넉하게 가져오기)
2. 리랭커: 각 (쿼리, 문서) 쌍 점수 매기기
3. 상위 5개만 반환

이게 기존 RAG 파이프라인에서 가장 ROI가 높은 개선 포인트입니다. 리랭커 하나 붙이면 답변 품질이 눈에 띄게 올라가요.

직접 하면: 리랭킹 모델을 고르고, 서빙하고, 검색 파이프라인에 끼워 넣어야 합니다. 레이턴시 버짓도 관리해야 돼요.

Schift가 하는 일: rerank: true 한 줄이면 됩니다. Cross-encoder 리랭킹이 자동으로 붙어요.

7. 컨텍스트 조립 — LLM에 뭘 넘길 것인가

리랭킹까지 끝나면 상위 5개 청크가 남습니다. 이걸 LLM한테 넘겨서 답을 생성하면 되는데, 여기서도 신경 쓸 게 있어요.

청크 순서: 원본 문서 순서대로 넘길 건지, 관련도 순으로 넘길 건지
청크 겹침: 인접 청크가 같은 내용을 반복하면 중복 제거해야 합니다
컨텍스트 윈도우: 모델별로 토큰 한도가 다릅니다. 초과하면 잘려요
메타데이터: 출처, 페이지 번호, 섹션 제목을 같이 넘겨야 LLM이 인용할 수 있습니다

사소해 보이지만, 이걸 제대로 안 하면 LLM이 “문서에 따르면…”이라고 하면서 엉뚱한 내용을 인용합니다.

직접 하면: 컨텍스트 조립 로직을 짜고, 토큰 카운팅을 하고, 중복 제거 로직을 만들고, 메타데이터를 포맷팅해야 합니다.

Schift가 하는 일: 알아서 해줍니다. 청크 순서 최적화, 중복 제거, 토큰 한도 관리, 메타데이터 포맷팅까지 다 내장이에요. 여러분은 검색 결과를 받아서 LLM에 넘기면 됩니다.

8. 평가 — “잘 되는 것 같은데?”는 메트릭이 아닙니다

여기까지 다 만들었습니다. 검색이 되고, 답변이 나옵니다. 잘 되는 것 같아요.

근데 “잘 되는 것 같다”는 프로덕션 품질 기준이 아닙니다. 측정해야 돼요.

세 가지 메트릭이 중요합니다:

메트릭	뭘 측정하나
Faithfulness	답변이 검색된 문서에 근거하고 있는가? 헛소리 안 하는가?
Answer Relevancy	답변이 질문에 맞는 답인가?
Context Recall	검색이 정답이 들어있는 문서를 찾았는가?

이걸 QA 테스트셋 50~100개를 만들어서 자동으로 돌려야 합니다. 청킹 로직을 바꿨더니 한 쪽이 좋아지고 세 쪽이 나빠지는 일이 생기거든요. 측정 안 하면 모릅니다.

직접 하면: 테스트셋을 만들고, 평가 파이프라인을 짜고, CI에 붙이고, 결과를 시각화해야 합니다. RAGAS, DeepEval 같은 프레임워크를 가져다 쓰더라도 세팅이 필요해요.

Schift가 하는 일: /v1/eval/run API를 호출하면 됩니다. Faithfulness, relevancy, recall을 다 측정해줘요. 테스트셋을 넣으면 CI에서 자동으로 회귀 테스트를 돌릴 수 있습니다.

9. 모니터링 — 품질은 조용히 떨어집니다

Day 1: 검색 품질 좋습니다. Day 30: 고객이 문서 500개를 추가했습니다. 검색 품질이 15% 떨어졌어요.

아무도 몰랐습니다. 유저가 “답변이 이상한데요”라고 할 때까지.

문서가 추가되면 벡터 분포가 바뀝니다. 기존에 잘 검색되던 쿼리가 노이즈에 묻히기 시작해요. 이걸 감지하려면 MRR, nDCG, Hit@K 같은 검색 품질 메트릭을 주기적으로 측정하고, 임계값 아래로 떨어지면 알림을 받아야 합니다.

직접 하면: 모니터링 파이프라인을 만들고, 메트릭 수집 로직을 짜고, 대시보드를 만들고, 알림을 설정해야 합니다.

Schift가 하는 일: MRR, nDCG, Hit@K 드리프트 모니터링이 내장되어 있어요. 품질이 떨어지면 감지합니다.

10. 업데이트 — 문서는 바뀝니다

고객이 정책 문서를 업데이트했습니다. 이전 버전이 DB에 남아있으면 안 돼요.

전체를 다시 임베딩하면? 문서가 많으면 몇 시간이에요. 그 사이에 검색이 안 되거나, 이전 버전과 새 버전이 섞이거나.

직접 하면: 문서별 content hash를 관리하고, 변경분만 감지하고, 이전 벡터를 삭제하고 새 벡터를 넣는 incremental update 로직을 만들어야 합니다.

Schift가 하는 일: 같은 파일을 다시 올리면 content hash를 비교해서 바뀐 부분만 재처리합니다. 전체 재인덱싱 없이요. 이전 버전 벡터는 자동 정리됩니다.

이게 dirty work입니다

파싱, 청킹, 임베딩, 인덱싱, 쿼리 강화, 리랭킹, 컨텍스트 조립, 평가, 모니터링, 업데이트.

10개 레이어에요. 각각이 프로젝트이고, 각각에 edge case가 있고, 각각이 전체 품질에 영향을 줍니다.

자료를 넣으면 Schift가 이 10개를 다 해서 깔끔한 graph-vector DB로 만들어줍니다. 여러분은 검색하거나, agent를 연결하면 돼요.

import { Schift } from '@schift-io/sdk';

const schift = new Schift({ apiKey: 'sch_...' });

// 자료 넣기
await schift.bucket('docs').ingest('./company-handbook.pdf');

// 검색하기
const results = await schift.search('연차 신청 절차가 어떻게 되나요?');

import { Agent, RAG } from '@schift-io/sdk';

// Agent 연결하기
const agent = new Agent({
  name: 'support-bot',
  rag: new RAG({ bucket: 'docs' }),
  model: 'claude-sonnet-4-20250514',
});

const response = await agent.run('비밀번호 재설정은 어떻게 하나요?');

다른 것들이랑 뭐가 다른데

위에서 본 10개 레이어를 기준으로 비교하면 차이가 명확합니다.

vs. LangChain / CrewAI

Python입니다. 앱이 TypeScript면 언어 2개, 런타임 2개, 배포 파이프라인 2개가 돼요.

근데 언어 문제만이 아닙니다. LangChain은 오케스트레이션 프레임워크에요. 체인을 연결해주는 거지, dirty work를 해주는 게 아닙니다. PDF 파싱은 직접 붙여야 되고, 벡터 스토어는 직접 골라야 되고, 청킹 전략은 직접 짜야 돼요. 10개 레이어 중 LangChain이 해주는 건 “연결”이지 “처리”가 아닙니다.

Schift는 자료를 넣으면 처리된 DB가 나옵니다. 연결할 것 자체가 없어요.

vs. Vercel AI SDK

LLM 스트리밍은 진짜 잘합니다. 40개 넘는 모델 프로바이더를 깔끔하게 추상화해요. Next.js랑 궁합도 좋고요.

근데 AI SDK의 관심사는 “LLM 응답을 어떻게 잘 보여줄까”입니다. 자료를 DB로 만드는 건 스코프 밖이에요. 10개 레이어로 보면:

파싱? 없습니다. 직접 하세요.
청킹? 없습니다.
임베딩? 있긴 한데, 벡터 스토어 연결은 직접 해야 돼요.
인덱싱? 벡터 DB를 골라서 호스팅하세요.
쿼리 강화, 리랭킹? 없습니다.
평가, 모니터링? 없습니다.

AI SDK로 agent를 만들면 LLM 호출 부분은 깔끔한데, 데이터 파이프라인 전체는 직접 만들어야 합니다. Schift는 그 데이터 파이프라인이 제품이에요. 둘이 경쟁하는 게 아니라 레이어가 다릅니다. 같이 쓸 수도 있어요.

vs. Pinecone / Qdrant / Weaviate (벡터 DB)

벡터 DB는 10개 레이어 중 4번(인덱싱)입니다. 벡터를 저장하고 검색하는 건 잘해요.

근데 나머지 9개는요? PDF를 파싱해서 벡터 DB에 넣는 건 여러분 몫이에요. 청킹도, 임베딩도, 쿼리 강화도, 리랭킹도, 평가도, 모니터링도. 벡터 DB는 “벡터가 들어오면 잘 찾아준다”이고, Schift는 “자료가 들어오면 벡터까지 만들어서 잘 찾아준다”입니다.

Pinecone에 데이터를 넣으려면 이런 코드를 짜야 돼요:

// Pinecone: 직접 해야 하는 것
const text = await parsePDF(file);           // 1. 파싱
const chunks = chunkText(text);              // 2. 청킹
const vectors = await embed(chunks);         // 3. 임베딩
await pinecone.upsert(vectors);              // 4. 인덱싱
// 5~10번? 전부 직접 만드세요.

// Schift: 이게 끝
await schift.bucket('docs').ingest(file);

vs. Supabase (pgvector)

“우리 이미 Supabase 쓰고 있는데, pgvector 확장 켜면 벡터 검색 되지 않나요?”

됩니다. pgvector는 Postgres에 벡터 컬럼을 추가하고 유사도 검색을 할 수 있게 해줘요. 기존 DB에 벡터 검색을 붙일 수 있다는 건 진짜 장점입니다.

근데 pgvector는 10개 레이어 중 4번(인덱싱)의 일부에요. 그것도 범용 DB 위에 올린 벡터 인덱스라서 전용 벡터 엔진 대비 성능 한계가 있습니다. 100만 벡터 넘어가면 레이턴시가 눈에 띄게 올라가요.

더 큰 문제는 나머지 9개 레이어입니다. Supabase는 “데이터를 저장하고 쿼리하는 인프라”이고, Schift는 “자료를 넣으면 검색 가능한 DB로 만들어주는 파이프라인”이에요. 파싱, 청킹, 임베딩, 쿼리 강화, 리랭킹, 평가, 모니터링 — 전부 직접 만들어야 합니다.

Supabase가 “DB를 제공한다”면, Schift는 “DB에 넣을 수 있는 상태로 만들어준다”입니다. 역할이 다릅니다.

vs. AWS Bedrock Knowledge Bases / Azure AI Search

클라우드 벤더들의 managed RAG 서비스입니다. 자료를 넣으면 파싱, 청킹, 임베딩, 인덱싱을 어느 정도 해줘요. 가장 가까운 경쟁 포지션이에요.

근데 쓰면 이런 일이 생깁니다:

벤더 락인: AWS에서 시작하면 Azure로 못 옮겨요. 데이터 파이프라인이 해당 클라우드에 종속됩니다.
커스터마이징 한계: 청킹 전략을 바꾸고 싶은데 옵션이 “fixed size”랑 “semantic” 두 개에요. 에이전틱 청킹? 없습니다.
가격: 벡터 검색 쿼리당 과금이 은근히 비쌉니다. 스케일 나면 청구서에 놀라요.
TypeScript SDK?: 있긴 한데, “AI agent 프레임워크”가 아니라 “클라우드 서비스 SDK”에요. Agent, Tool, Memory 같은 프리미티브는 없습니다.
온프레 배포?: 대부분 관리형 전용이라 불가능해요.

Schift는 Cloud 기본에, Enterprise 계약자에게는 Docker Compose + Terraform 온프레 번들 + NDA 하 소스 코드 감리를 제공합니다. 청킹 전략도 3단계로 풀커스터마이징 가능하고, 공개 TypeScript 클라이언트 SDK + Use-case 템플릿으로 agent를 빠르게 얹을 수 있어요.

vs. OpenAI File Search / Gemini Grounding

OpenAI Assistants API의 File Search나 Gemini의 Grounding with Google Search. 파일을 올리면 알아서 검색해서 답해줍니다. 제일 간단해요.

근데 그게 함정입니다.

블랙박스: 청킹이 어떻게 되는지 모릅니다. 임베딩 모델이 뭔지 모릅니다. 리랭킹이 있는지도 모릅니다. “파일 올리면 알아서 됨”인데 “알아서”가 뭔지를 알 수가 없어요.
튜닝 불가: 검색 품질이 안 나와도 할 수 있는 게 없습니다. 청킹 전략을 바꾸거나, 쿼리 강화를 켜거나, 리랭킹 모델을 교체하거나 — 다 안 돼요. “잘 되면 좋고, 안 되면 어쩔 수 없고”입니다.
모델 종속: OpenAI File Search는 OpenAI 모델에서만 됩니다. Gemini Grounding은 Gemini에서만 되고요. 모델을 바꾸면 RAG 파이프라인도 같이 버려야 돼요.
데이터 통제: 파일이 OpenAI/Google 서버에 올라갑니다. 내부 문서를 올리는 게 부담인 조직이 많아요.
평가/모니터링: 없습니다. 검색 품질이 떨어져도 알 방법이 없어요.

프로토타입에는 최고입니다. 5분이면 돌아가요. 근데 프로덕션에서 “왜 이 질문에 엉뚱한 답이 나오지?”가 시작되면 손댈 곳이 없습니다. 블랙박스니까요.

Schift는 10개 레이어 각각을 제어할 수 있습니다. 청킹 전략을 바꿀 수 있고, 쿼리 강화를 켜고 끌 수 있고, 리랭킹 모델을 선택할 수 있고, 평가 메트릭으로 품질을 측정할 수 있어요. “알아서 해주는데 뭘 하는지 안다”가 차이입니다.

vs. 직접 만들기

위에서 본 10개 레이어를 하나씩 라이브러리 골라서 엮는 방식이에요. LlamaParse + LangChain + OpenAI Embeddings + Pinecone + Cohere Reranker + RAGAS… 돌아가긴 합니다.

근데 현실적으로 이런 일이 생겨요:

LlamaParse API가 바뀌면 파싱 코드 수정
임베딩 모델 업그레이드하면 전체 재인덱싱
Pinecone 가격이 오르면 벡터 DB 마이그레이션
리랭커 모델 서빙 인프라 관리
라이브러리 간 버전 충돌
각 레이어의 에러 핸들링과 재시도 로직

6개 서비스의 API 변경, 버전 업데이트, 장애를 다 추적해야 합니다. 그리고 이 조합이 잘 돌아가는지 테스트하는 것도 본인 몫이에요.

Schift는 이 10개를 하나의 제품으로 통합한 겁니다. 의존성 하나, API 하나, 장애 포인트 하나.

데이터는 여러분 겁니다

Enterprise 계약자에게는 온프레 배포 번들(Docker Compose + Terraform) + NDA 하 소스 감리가 제공됩니다. 직접 호스팅이 가능해요.
LLM API 키를 본인 거 쓰면 프롬프트와 응답이 프로바이더로 바로 갑니다.
문서는 조직별 격리 + 저장 시 암호화.
셀프호스팅이 진짜 된다는 게 보안팀이랑 대화할 때 확 달라집니다.

가격

Free 티어도 진짜로 만들고 테스트할 수 있을 만큼 줍니다 (25K 검색, 10 컬렉션, 100 페이지). 유료는 Starter 월 $59, Pro 월 $350. 연간 결제는 20% 할인, Wallet 충전은 +30% 보너스 크레딧. LLM 키를 직접 가져오면 (BYOK) LLM 비용은 프로바이더에 직접 결제합니다.

상세: schift.io/pricing

시작하기

npx create-schift@latest my-agent

템플릿 고르고. 문서 올리고. 질문하면 끝입니다.

SDK 문서: schift.io/docs. 프레임워크 소스는 GitHub에 공개되어 있어요.

자료를 넣으면 깔끔한 DB가 됩니다. 10개 레이어의 dirty work는 우리가 합니다. 그 위에 검색이든 agent든 올리면 돼요. 그게 Schift입니다.