DATABASE

RAG를 위한 데이터 준비: 범위·요건 분석부터 전처리·피처 설계까지

teinam 2026-09-27updated 09-28 10 MIN

시리즈 · 1. 데이터 범위·요건·전처리·피처 · 2. 평가 데이터셋과 품질 평가

사내 운영 문서를 검색하는 챗봇을 만든다고 생각해 봅시다. 사용자가 “야간에 DB 장애가 나면 어디에 먼저 알려야 하나요?”라고 물었습니다. 검색 결과에는 개정 전 대응 지침과 현재 지침이 함께 나오고, 정작 당직 연락 절차가 있는 PDF의 표는 텍스트로 제대로 추출되지 않았습니다. 모델이 매끄러운 문장을 만들어도 이 상태에서는 올바른 답을 기대하기 어렵습니다.

앞선 글에서는 벡터 DB 제품과 AWS의 벡터 검색 서비스를 비교했습니다. 이번에는 저장소에 넣을 데이터를 어떻게 준비하고, 그 데이터로 만든 서비스가 제대로 동작하는지 어떻게 확인할지 두 편으로 나눠 살펴봅니다. 데이터 범위·유형 분석 → 요건 정의 → 피처 설계 → 학습·평가 데이터셋 확보라는 흐름을 바탕으로, 문서 검색과 RAG에 필요한 작업을 구체화합니다. 이 글은 데이터 범위·요건·전처리·피처 설계까지 다루고, 평가 데이터셋과 평가 방법은 다음 글에서 다룹니다.

이 글의 조사 기준일은 2026년 9월 27일입니다. 도입부의 챗봇 사례와 표의 업무 상황은 설명을 위해 만든 가상 예시이며, 용량 수치는 계산 예시입니다. 실제 서비스의 성능을 측정한 결과는 아닙니다.

1. 검색 문서와 학습·평가 데이터는 어떻게 다를까요

프로젝트에서 “데이터셋을 만든다”고 할 때 가리키는 일부터 구분해야 합니다. 검색할 원본 문서를 준비하는 일, 모델을 학습시키는 일, 결과를 평가하는 일은 목적이 다릅니다.

구분	담는 내용	사용하는 시점	확인할 사항
검색 문서 집합(corpus)	업무 문서, 청크, 출처, 문서 버전, 접근 권한	사용자의 질문에 필요한 근거를 검색할 때	근거의 정확성·최신성·검색 가능 여부
학습 데이터셋	질문·답변, 관련 문서 쌍, 선호도 등 학습 목적에 맞는 예제	생성 모델·임베딩 모델·재순위화 모델을 실제로 학습할 때	학습 대상과 입력·출력 형식
평가 데이터셋	질문, 기대 동작, 정답 근거, 참고 답변, 채점 기준	검색·생성 결과를 비교할 때	평가 기준의 정확성·대표성·독립성

이미 학습된 임베딩 모델과 LLM을 사용하는 일반적인 RAG는 별도의 모델 학습 없이 구성할 수 있습니다. 문서를 벡터로 변환해 색인하는 작업이 곧 LLM의 파라미터를 학습시키는 것은 아닙니다. RAG는 검색한 외부 자료를 질문과 함께 모델에 전달하는 방식이며, 필요에 따라 모델 학습을 추가할 수 있습니다.¹

검색 문서는 색인 경로로 들어가고, 질문은 검색과 답변 생성 경로를 거칩니다.

질문·답변(QA) 데이터도 사용 목적에 따라 역할이 달라집니다. 같은 형식의 QA를 파인튜닝에 넣으면 학습 데이터이고, 생성 결과를 채점하는 기준으로 쓰면 평가 데이터입니다. 평가용 정답을 서비스의 프롬프트 예제나 학습 자료에 넣은 뒤 같은 문항으로 성능을 재면, 새로운 질문에 얼마나 잘 답하는지 제대로 평가하기 어렵습니다.²

따라서 시작할 때는 “학습 데이터 몇 만 건이 필요하다”보다 어떤 질문에 답할 것이며, 어떤 문서를 근거로 답하고, 무엇을 맞히면 성공으로 볼 것인지부터 정하는 편이 좋습니다.

2. 데이터 범위와 규모는 어떻게 조사할까요

먼저 시스템과 업무 영역을 나누고, 각 영역의 데이터 유형과 건수를 조사합니다. 이 목록이 수집 범위와 일정·인력 산정의 출발점이 됩니다. RAG 프로젝트에서는 여기에 수집 경로, 갱신 방식, 문서 소유자와 권한을 함께 적으면 실제 구현으로 연결하기 쉽습니다.

다음은 운영 문서 챗봇을 위한 조사표 예시입니다.

데이터 소스	형식·수량 단위	수집 경로·갱신·권한	먼저 확인할 내용
사내 Wiki	HTML, 문서 수	API·내보내기, 수시 개정, 팀별 권한	승인본, 첨부 자료, 문서 이력
업무 지침	HWP·DOCX, 파일·페이지 수	승인 문서 저장소, 개정 승인 시 갱신	제목 계층, 각주, 적용 시점
장애 티켓	JSON·RDB, 티켓·행 수	API·읽기 전용 조회, 계속 추가·수정	해결 여부, 중복 티켓, 개인정보
제품 매뉴얼	PDF, 파일·페이지 수	파일 저장소, 제품 버전별 개정	스캔 여부, 표, 다단 편집
교육 자료	PPT, 파일·슬라이드 수	문서 저장소, 교육 과정별 갱신	도형·그림 속 글자, 발표자 노트
운영 현황	RDB, 테이블·행 수	조회 API·SQL, 현재 상태가 중요	문서 검색으로 답할지 직접 조회할지

파일 수와 페이지 수, 테이블 수와 행 수는 서로 다른 단위입니다. PDF 300개라는 숫자만으로 OCR과 표 추출의 작업량을 알 수 없고, RDB 테이블 20개라는 숫자만으로 검색할 레코드 수를 알 수 없습니다. 업무 범위에 포함되는 데이터인지 담당자와 합의한 뒤, 유형별 대표 자료를 실제로 열어 수집·변환 가능성을 확인해야 합니다.

Microsoft의 RAG 준비 가이드도 업무 분류, 파일 형식, 보안 제약, 문서 구조를 함께 조사하도록 안내합니다. 파일 안의 이미지와 표, 문서에 연결된 외부 자료도 조사 대상입니다.³

파일 수를 벡터 수로 바꿔 봐야 합니다

청크마다 벡터를 하나씩 만든다면 예상 벡터 수는 다음과 같이 계산할 수 있습니다.

예상 벡터 수 = 문서 수 × 문서당 평균 청크 수
벡터 값의 크기 = 벡터 수 × 차원 수 × 차원당 바이트 수

예를 들어 문서 10,000개가 평균 12개 청크로 나뉘고, 청크마다 1,024차원 float32 벡터 하나를 만든다고 가정해 보겠습니다. 벡터는 120,000개이고, 벡터 값만 491,520,000바이트, 즉 491.52MB(468.75MiB)입니다.

이 값에는 원문, 메타데이터, 인덱스 구조, 복제본, 백업이 들어 있지 않습니다. 이미지와 본문에 벡터를 각각 만들면 벡터 수도 달라집니다. 먼저 대표 자료에서 청크 수를 측정하고, 그 결과로 전체 용량을 추정해야 합니다. 초기 적재량과 별개로 하루에 추가·수정·삭제되는 양도 조사표에 남깁니다.

3. 데이터 요건은 검증할 수 있게 적습니다

요건은 데이터 변환, 서비스, 보안, 품질로 나눌 수 있습니다. “잘 변환한다”, “정확하게 답한다”처럼 해석이 갈리는 문장을 실제로 확인할 수 있는 조건으로 바꾸는 것이 좋습니다. 아래 표는 네 범주에 들어 있는 입력·출력, 성능, 최신성을 따로 떼어 일곱 범주로 나눈 예시입니다.

범주	요건 예시	확인 방법
데이터 변환	제목·절·표·각주의 관계를 보존하고 원본 위치를 추적할 수 있다	대표 문서의 추출 결과를 원문과 대조
서비스	답변에 근거 문서와 위치를 표시하고, 근거가 없으면 부족한 정보를 안내한다	출처 링크·인용 구절·응답 형식 검사
입력·출력	지원할 입력이 텍스트인지 이미지까지인지, 답변 길이와 형식을 정의한다	입력 유형별 사례와 기대 출력 비교
보안	로그인한 사용자가 읽을 수 있는 자료만 검색·답변에 사용한다	서로 다른 권한의 계정으로 동일 질문 실행
품질	필수 사실과 조건을 맞히고, 근거에 없는 절차를 만들지 않는다	고정된 평가 문항과 채점표로 확인
성능	검색 시간, 첫 토큰까지의 시간, 답변 완료 시간을 구분한다	부하 조건과 함께 지연 분포 측정
최신성	문서 개정·삭제·권한 변경을 합의된 시간 안에 반영한다	원천 변경부터 실제 검색 반영까지 측정

“응답 시간 2초 이내”라고만 적으면 첫 토큰이 나오는 시점인지, 답변이 끝나는 시점인지 알 수 없습니다. 평균인지 p95인지에 따라서도 뜻이 달라집니다. p95는 측정한 요청의 약 95%가 해당 시간 안에 끝났다는 뜻입니다.⁴ 동시 요청 수, 입력·출력 길이, 캐시 사용 조건과 함께 목표를 적어야 같은 조건에서 확인할 수 있습니다.

“정확도 90% 이상”도 마찬가지입니다. 어떤 문항을 몇 개 평가했는지, 완전 정답과 부분 정답을 어떻게 나눴는지, 답하면 안 되는 질문을 어떻게 채점했는지도 함께 적어야 합니다. 다음 글에서 다룰 검색 Recall과 답변 정확성을 하나의 정확도라는 이름으로 합치지 않는 것이 좋습니다.

암호화와 접근 권한은 각각 확인해야 합니다

저장 데이터를 암호화해도, 검색 시스템이 다른 팀의 문서를 가져와 LLM에 전달하면 권한 문제가 남습니다. 문서 권한을 청크에 연결하고, 서버가 확인한 사용자·그룹 정보로 검색 결과를 제한해야 합니다. Azure AI Search의 보안 필터도 호출자 신원과 문서에 저장한 권한 정보를 비교하는 방식입니다.⁵

질문·답변 기록의 보관 범위와 열람 권한도 정해야 합니다. 원문에서 개인정보를 가렸더라도 검색 로그, 평가 데이터, 답변 기록에 같은 정보가 남을 수 있기 때문입니다. 외부 OCR·임베딩·LLM 서비스에 전달할 수 있는 자료인지도 수집 단계에서 확인할 항목입니다.³

4. 전처리는 무엇을 지우고 무엇을 남길까요

문서를 Markdown으로 바꾸거나 특수문자를 제거했다고 해서 검색에 적합한 데이터가 되는 것은 아닙니다. 전처리의 목표는 답에 필요한 의미와 근거 위치를 보존하는 것입니다.

주석·목차·특수문자 제거 같은 전처리 규칙은 문서의 성격에 따라 적용해야 합니다. 예를 들어 max_connections의 밑줄이나 >=의 비교 기호를 없애면 기술 문서의 의미가 바뀝니다. 본문 아래의 각주에 적용 제외 조건이 적혀 있다면 각주도 답의 근거입니다. Microsoft의 준비 가이드 역시 각주·주석·머리말 등을 일괄 삭제하기보다 관련성이 있는지 판단하도록 설명합니다.³

대상	보존할 내용	잘못 처리했을 때 생기는 문제
제목·절	제목 계층, 현재 절의 상위 문맥	“예외 사항”이 어떤 절차의 예외인지 알 수 없음
표	행·열 머리글, 단위, 병합 셀의 관계	숫자는 남지만 어떤 조건의 값인지 사라짐
그림·도표	원본 위치, 캡션, 필요한 주변 설명	이미지 설명만으로 원문을 확인할 수 없음
코드·명령어	공백, 기호, 식별자, 버전 조건	명령의 의미나 실행 조건이 달라짐
각주·주석	적용 범위와 예외를 설명하는 내용	본문만 읽고 조건을 빠뜨린 답변 생성
링크	원본 식별자와 해석 가능한 경로	문서를 옮기면 인용 링크가 깨짐

표를 HTML이나 Markdown으로 바꿀 때도 변환 후 관계가 남는지 확인해야 합니다. 긴 표를 나눈다면 각 조각에서 열 머리글과 단위를 알 수 있게 합니다. 이미지 설명을 LLM으로 생성했다면 원본에서 추출한 텍스트와 생성한 설명을 구분해 두어야 합니다. 그래야 설명에 오류가 생겼을 때 되짚을 수 있습니다.⁶

전처리된 텍스트만 남기기보다 원본과 그 위치 정보를 함께 보관하는 편이 좋습니다. 원본 문서 ID, 문서 버전, 페이지·절·문자 범위 등을 연결해 두면 청크를 다시 나누거나 파서를 바꿀 때도 이전 결과와 대조할 수 있습니다.

청크 크기는 평가 질문으로 결정합니다

작은 청크는 문맥을 놓칠 수 있고, 큰 청크는 무관한 내용과 토큰 비용을 늘릴 수 있습니다. 어떤 크기가 적절한지는 문서 구조와 질문에 따라 다릅니다.⁶

예를 들어 “야간 장애의 최초 연락 대상”을 답하려면 짧은 절 하나로 충분할 수 있습니다. “장애 등급별 보고 대상과 보고 기한”을 비교하려면 표 전체나 여러 절이 필요할 수 있습니다. 분할 방식을 비교할 대표 질문을 먼저 만들고, 필요한 근거가 검색·재순위화·컨텍스트 구성 뒤에도 남는지 보면서 분할 방식을 비교합니다.

청크 길이는 사용할 모델의 토큰 제한에 맞춰 확인합니다. “500글자”와 “500토큰”을 같은 것으로 다루지 않습니다. 검색할 후보 수와 LLM에 최종 전달할 청크 수도 따로 정합니다. 검색 후보를 많이 가져왔다고 그 내용을 모두 모델에 넣어야 하는 것은 아닙니다.

5. 피처 설계는 RAG에서 어떻게 달라질까요

피처 설계(feature engineering)는 중요한 피처를 선택하고, 새 피처를 만들고, 모델이 사용할 형태로 변환하는 작업입니다. 데이터 엔지니어링이 수집·처리·저장의 흐름을 만든다면, 피처 설계는 그 데이터에서 모델에 필요한 표현을 만드는 작업으로 볼 수 있습니다.

일반적인 머신러닝에서는 상관관계나 모델의 중요도로 피처를 고르거나, 날짜에서 요일을 만들고, 수치에 스케일링·로그 변환을 적용할 수 있습니다. 피처 선택은 모델의 정확도나 계산 성능을 개선하기 위해 사용하는 방법이며, 효과는 데이터와 모델에 따라 확인해야 합니다.⁷

문서 RAG에서는 이를 다음과 같이 적용할 수 있습니다. 아래 표는 정형 데이터의 피처 기법을 그대로 옮긴 규칙이 아니라, 검색 설계에 맞춰 바꾼 예시입니다.

작업	문서 RAG에서의 예시	확인할 사항
선택	제목·본문·제품 버전 중 검색에 쓸 내용을 정함	답에 필요한 조건을 제외하지 않았는가
생성	상위 절 제목, 업무 분류, 제품 식별자를 청크에 연결	원문에서 온 값인지 추론한 값인지 구분하는가
변환	본문을 임베딩하고 날짜·버전을 필터 가능한 값으로 정리	질문·문서의 표현과 필터 타입이 일관적인가

의미 검색에 넣을 본문과 정확하게 비교해야 하는 메타데이터도 나눕니다. 제품 버전, 적용일, 문서 상태, 테넌트와 접근 권한은 문장에만 섞어 넣기보다 명시적인 필드로 관리할 수 있습니다. 특히 접근 권한은 LLM이 추측해서 만든 업무 분류로 결정하지 않고 원천 권한 체계와 연결해야 합니다.⁵

청크마다 원본 위치·본문·메타데이터를 담아 벡터 DB의 저장·벡터·필터 필드에 나눠 넣습니다.

임베딩 차원을 일반 열처럼 지우면 안 됩니다

기존 임베딩 벡터의 일부 차원을 임의로 버리는 것을 일반적인 피처 선택과 동일하게 보면 안 됩니다. 보통의 밀집 임베딩은 정해진 차원으로 출력됩니다. Matryoshka처럼 차원을 줄여도 유용하도록 학습한 모델이 있지만, 그 경우에도 지원하는 방법과 검색 품질을 확인해야 합니다.⁸

질문과 문서는 호환되는 벡터 공간에 있어야 합니다. 짧은 질문으로 긴 문서를 찾는 비대칭 검색에서는 모델에 따라 질문용·문서용 인코딩 경로와 프롬프트가 다를 수 있습니다. Sentence Transformers도 이러한 구분을 안내합니다.⁹

스케일러나 차원 축소처럼 데이터에서 변환 규칙을 학습한다면 최종 평가 데이터를 그 학습에 포함하지 않습니다. scikit-learn은 피처 선택·스케일링·PCA 등의 전처리도 데이터 누수를 일으킬 수 있다고 설명합니다.²

정리

벡터 DB를 위한 데이터 준비는 파일을 변환하고 임베딩을 만드는 것보다 범위가 넓습니다. 어떤 업무를 지원할지 정하고, 답의 근거가 되는 자료를 찾아 구조·출처·버전·권한을 보존해야 합니다. 모델을 학습할 데이터와 서비스의 품질을 평가할 데이터도 구분해야 합니다.

평가 데이터셋을 만들고 검색 품질과 답변 품질을 나눠 평가하는 방법은 다음 글에서 이어집니다.

참고 자료

AWS — What is Retrieval-Augmented Generation?. 외부 자료 검색과 프롬프트 보강, 모델 재학습 없이 구성하는 RAG의 역할. ↩
scikit-learn — Common Pitfalls and Recommended Practices. 전처리의 일관성, 학습·평가 분리, 피처 선택·스케일링·PCA에서의 데이터 누수. ↩ ↩²
Microsoft — Develop a RAG Solution: Preparation Phase. 문서 유형·구조·권한 분석, 질문·근거·답변의 연결, 독립적인 합성 질문 생성과 전문가 검토. ↩ ↩² ↩³
Amazon CloudWatch — Statistics Definitions. 평균과 백분위수, p95의 정의. ↩
Microsoft — Document-Level Access Control. 호출자 신원에 따른 검색 제한, 청크 권한 메타데이터, 원천 권한 변경과 인덱스 동기화의 경계. ↩ ↩²
Microsoft — Develop a RAG Solution: Chunking Phase. 문서 구조와 이미지·표 처리, 청크 크기의 절충, 전처리 결과와 분할 전략 비교. ↩ ↩²
scikit-learn — Feature Selection. 피처 선택의 목적과 방법. ↩
Sentence Transformers — Matryoshka Embeddings. 차원 축소를 고려한 임베딩 학습과 일반 임베딩의 구분. ↩
Sentence Transformers — Semantic Search. 질문·문서의 벡터 공간, 대칭·비대칭 검색, 인코딩 경로, ANN의 recall·속도 절충. ↩

Comments