파일이 검색되는 데이터가 되기까지

인덱싱은 여섯 단계로 끝난다

업로드 → 바이트 추출 → 텍스트 정제 → 청킹 → 임베딩 → 적재 순서다. 각 단계의 결과가 다음 단계의 입력이 된다.

먼저 파일을 받아 스토리지에 올린다. 파일에서 바이트를 읽어 텍스트를 뽑고, 검색에 방해되는 부분을 정리한다. 이후 청킹과 임베딩을 거쳐 벡터 DB에 넣는다.

원본 파일은 따로 보관한다. 임베딩 모델을 바꾸면 벡터를 새로 만들어야 하기 때문이다. 원본이 없으면 다시 인덱싱할 수 없다.

DB에는 업로드, 청킹, 임베딩 같은 상태를 컬럼으로 기록한다. 어느 단계까지 끝났는지 관리하기 위해서다.

5주차의 개념 4단계를 구현으로 풀면 업로드·추출·정제가 앞에 붙는다. Document는 업로드+추출+정제, 나머지는 Chunking·Embedding·적재에 그대로 대응한다.

원본 파일 보관

임베딩 모델을 교체하면 벡터를 다시 만들어야 한다. 재인덱싱을 위해 원본 파일을 별도로 저장한다.

상태(Status) 컬럼

업로드·청킹·임베딩 등 진행 상태를 DB 컬럼에 기록한다. 단계별 처리를 관리하기 위해서다.

재인덱싱

원본에서 텍스트를 다시 뽑아 청크와 벡터를 새로 만드는 작업이다. 모델 교체 시 필요하다.

파일은 스토리지, 정보는 DB에 둔다

Supabase Storage는 S3와 호환되는 객체 스토리지다. 버킷에 파일을 모으고, 경로는 시스템이 만든 객체 키로 정한다.

파일명을 그대로 경로로 쓰면 한글과 특수문자에서 인코딩 문제가 생긴다. 그래서 유저 ID / 소스 ID 형태의 객체 키를 만들어 저장한다.

파일 자체는 스토리지에 두고, 파일의 정보는 DB 테이블에 둔다. 접근 권한은 RLS 정책으로 관리한다.

Supabase Storage

S3와 호환되는 객체 스토리지다. 원본 파일을 보관한다.

버킷(Bucket)

스토리지에서 파일을 모아 두는 단위다. 버킷 안에 객체가 쌓인다.

객체 키(Object Key)

유저 ID / 소스 ID 조합으로 만든 고유 경로다. 한글·특수문자로 인한 인코딩 문제를 피한다.

메타데이터 분리

파일 본체는 스토리지에, 파일 정보는 DB 테이블에 나눠 저장한다.

RLS(Row Level Security)

DB 행 단위로 접근 권한을 제한하는 정책이다. 사용자별로 볼 수 있는 데이터를 관리한다.

PDF에서 텍스트를 뽑고, 검색을 방해하는 것을 지운다

PDF는 레이아웃을 유지하지만 스캔본은 OCR이 필요하다. 뽑은 텍스트는 좌표 오류를 보정하고 머리말·꼬릿말을 지운다.

스캔한 PDF는 텍스트 정보가 없다. 이미지에서 글자를 읽는 OCR이 필요하다.

좌표를 기준으로 읽으면 줄 바꿈과 공백이 어긋난다. 보정하지 않으면 검색 품질이 떨어진다.

페이지마다 반복되는 머리말과 꼬릿말도 검색을 방해한다. 정제 단계에서 제거한다.

OCR

텍스트 정보가 없는 스캔 PDF에서 글자를 인식하는 기술이다. 상세 구현은 이번 범위에서 제외한다.

좌표 기반 추출 보정

PDF를 좌표로 읽으면 줄 바꿈·공백이 틀어질 수 있다. 추출 후 보정이 필요하다.

머리말·꼬릿말 제거

페이지마다 반복되는 문구를 지운다. 같은 문구가 모든 청크에 섞이면 검색 품질이 떨어진다.

구조를 지키며 자르고, 위치를 함께 저장한다

재귀적 분할은 문단 → 줄 → 단어 순으로 큰 구분자부터 적용한다. 청크에는 페이지·헤더 같은 위치 정보를 붙인다.

문단으로 먼저 나누고, 아직 크면 줄 단위로, 그래도 크면 단어 단위로 자른다. 문서 구조를 최대한 유지하면서 지정 크기 이하로 만드는 방법이다.

청크마다 몇 페이지, 어떤 헤더 아래에 있었는지 저장한다. 검색할 때 문맥을 파악하고 출처를 표시하기 좋다.

재귀적 분할은 5주차의 고정 크기·구조 기반 청킹을 구현하는 방법이다. 의미 기반 청킹은 임베딩 유사도로 경계를 잡는 별도 방식이다.

재귀적 분할(Recursive Splitting)

문단 → 줄 → 단어 순으로 구분자를 적용한다. 구조를 유지하며 지정 크기 이하로 나눈다.

청크 메타데이터

페이지, 헤더 등 청크의 위치 정보를 함께 저장한다. 문맥 파악과 출처 표시에 쓰인다.

Source

파일 하나를 나타내는 행이다. 원본 단위로 관리한다.

Chunk

Source를 잘게 나눈 조각을 관리한다. Source ID를 참조한다.

유사도만으로 찾으면 틀린 연도를 가져온다

벡터 검색은 의미만 따진다. 조건을 맞추려면 메타데이터 필터를 함께 걸어야 한다.

질문과 비슷한 문장이라도 작년 자료일 수 있다. year = 2026 같은 조건으로 검색 대상을 먼저 좁힌다.

데이터가 많아지면 검색이 느려진다. HNSW 같은 벡터 인덱스로 속도를 높이지만 메모리를 많이 쓴다.

삭제할 때는 DB와 스토리지를 함께 지워야 한다. 두 시스템이 따로 움직이므로 트랜잭션 개념을 고려한다.

메타데이터 필터링

벡터 검색에 SQL 조건을 결합한다. 연도·권한처럼 정확히 맞아야 하는 조건을 처리한다.

HNSW

벡터 검색 속도를 높이는 인덱스다. 메모리 사용량이 높다는 점을 감안해야 한다.

삭제 일관성

DB 행과 스토리지 객체를 함께 지워야 한다. 한쪽만 지우면 불일치가 남는다.