문서를 붙여 넣을까, RAG를 만들까

먼저 붙여 넣기부터

자료가 짧고 대상이 분명하면 필요한 부분을 질문과 함께 직접 넣습니다. 공고문에서 신청 자격, 제출 서류, 마감일 부분을 붙여 넣고 “이 내용으로 안내문을 작성해 줘”라고 요청하는 방식입니다.

이 방법의 장점은 준비가 없다는 것입니다. 데이터베이스도 색인도 필요 없습니다. 그리고 모델에 무엇이 들어갔는지 내가 정확히 압니다.

앱의 파일 첨부 기능은 조금 다릅니다. 첨부한 파일 전체를 모델에 넣는지, 일부만 검색해서 넣는지는 앱마다 다릅니다. 답이 이상하면 첨부한 문서의 해당 부분을 직접 복사해 넣고 다시 물어봅니다. 결과가 달라지면 앱이 그 부분을 모델에 전달하지 않았다는 뜻입니다.

붙여 넣기가 막히는 지점

한계	설명
길이	모델이 한 번에 읽을 수 있는 양(컨텍스트 길이)이 정해져 있습니다. 로컬 모델은 PC 메모리에 따라 이 길이를 넉넉히 쓰기 어렵습니다
반복	질문할 때마다 같은 문서를 다시 넣어야 합니다. 길수록 응답이 느려집니다
갱신	문서가 바뀌면 어느 대화에 어느 버전을 넣었는지 관리하기 어렵습니다
선택	문서가 많아지면 어느 문서를 넣어야 할지 사람이 먼저 찾아야 합니다

마지막 줄이 RAG가 필요한 이유입니다. 문서가 많아지면 답을 만드는 모델보다 먼저 질문과 관련된 근거를 골라 주는 검색이 필요합니다.

문서가 길 때 쓸 수 있는 중간 방법도 있습니다. 사용자가 필요한 절을 지정하거나, 목차나 문서 번호로 필요한 부분만 읽어 넣는 것입니다. 검색 프로그램 없이 사람이 범위를 좁히는 방식입니다.

규모로 정하는 기준

강의에서 쓰는 어림 기준입니다. 숫자는 경계선이 아니라 출발점입니다.

문서 규모	먼저 써 볼 방법
몇 건	직접 붙여 넣기
100건 이하	단순 키워드 검색
100~500건	BM25 같은 순위 있는 키워드 검색
500건 이상	키워드 검색에 임베딩 검색을 더함
수천 건 이상	벡터 데이터베이스 검토

부서 하나의 규정, 업무 편람, 최근 1년 보고서를 모두 합치면 보통 수백 건입니다. 텍스트로 뽑으면 책 한 권 분량 정도입니다. 이 규모에서는 벡터 데이터베이스가 없어서 못 하는 일이 거의 없습니다. 간단한 검색으로 시작하고, 실제로 놓치는 질문이 생길 때 다음 단계를 더합니다.

긴 컨텍스트 모델을 쓸 수 있다면

온라인 모델 가운데에는 한 번에 책 여러 권 분량을 읽는 것도 있습니다. 이런 모델을 쓸 수 있는 환경이라면 문서 수십 건을 검색 없이 통째로 넣는 것도 선택지입니다. 검색 품질을 걱정할 필요가 없고, 모델이 관련 부분을 골라 답합니다.

다만 두 가지를 확인합니다.

• 문서가 외부 서버로 전송됩니다. 내부 자료라면 보낼 수 있는 자료인지 먼저 확인합니다.
• 길게 넣는다고 정확해지는 것은 아닙니다. 오래된 버전과 새 버전이 함께 들어가면 모델이 어느 쪽을 따를지 알 수 없습니다.

현실적인 조합은 둘을 섞는 것입니다. 키워드 검색으로 문서 5건 정도를 고르고, 그 5건은 조각내지 않고 통째로 넣습니다. 검색은 후보를 좁히는 데 쓰고, 세부 내용은 모델이 전체 맥락을 보고 찾게 합니다.

로컬 모델은 사정이 다릅니다. 컨텍스트 길이를 늘리면 메모리를 더 쓰고 속도가 느려집니다. 그래서 로컬에서는 검색으로 조각을 잘 고르는 일이 더 중요합니다. PC 사양과 모델 크기의 관계는 내 PC 사양으로 돌릴 수 있는 모델 고르기를 참고하세요.

질문 유형으로 정하는 기준

문서 수만큼 중요한 것이 질문의 종류입니다. 모든 질문을 문서 검색으로 풀려고 하면 맞지 않는 경우가 생깁니다.

질문 유형	맞는 방법
기관 기본 정보, 고정된 안내 문구	지침(시스템 프롬프트)에 적어 둠
짧은 매뉴얼 한두 개	파일을 그대로 넣음
총액, 평균, 기간별 통계	표를 데이터베이스에 넣고 SQL로 조회
정확한 규정명, 조문 번호, 계약 번호	키워드 검색(BM25)
표현이 다른 비슷한 내용	임베딩 검색
최신 공지, 새 소식	RSS나 API로 가져옴
숫자와 그 원인을 함께 묻는 질문	SQL 조회와 문서 검색을 함께

“작년 교육 예산 총액이 얼마야”는 문서 조각을 찾아서 풀 문제가 아닙니다. 엑셀 표를 데이터베이스에 넣고 합계를 계산한 뒤, 그 결과를 모델에 넘겨 문장으로 만들게 합니다. 문서로 답하는 경로와 숫자를 계산하는 경로를 나누면 출처와 계산을 각각 확인할 수 있습니다.

같은 질문을 네 가지로 풀어 보기

질문은 “A사업의 제출 서류는 무엇인가”입니다. 정답 근거는 공고문 3쪽에 있다고 가정합니다.

구성	방법	맞는 상황
A	공고문 3쪽 텍스트를 직접 넣음	문서가 몇 건뿐일 때
B	공고문을 미리 항목별 JSON으로 정리해 두고 해당 항목을 읽어 넣음	같은 질문이 반복될 때
C	표나 데이터베이스에 넣고 조건으로 조회	여러 사업을 비교할 때
D	검색으로 관련 조각을 찾아 넣음	문서가 많고 질문이 다양할 때

B와 C는 문서를 미리 구조화하는 방식입니다. 반복 질문을 빠르게 처리하지만, 원문이 바뀌면 다시 추출해야 합니다. 그리고 미리 뽑지 않은 항목은 답할 수 없습니다. “이 사업에서 가장 큰 운영상 문제는 무엇이었나” 같은 질문은 원문을 검색해야 풀립니다. 그래서 구조화한 자료와 원문을 함께 보관합니다.

정리

1. 문서가 몇 건이면 붙여 넣습니다.
2. 수십~수백 건이면 키워드 검색으로 고른 뒤 넣습니다.
3. 표현 차이 때문에 놓치는 질문이 확인되면 임베딩 검색을 더합니다.
4. 숫자 집계는 문서 검색이 아니라 표 조회로 풉니다.

각 단계에서 실제로 놓치는 질문이 생길 때 다음 기술을 더하는 순서가 좋습니다. 처음부터 전부 갖추려고 하면 시작이 늦어지고, 어느 부분이 효과가 있었는지도 알 수 없습니다.

다음에 읽을 글

• 임베딩이란 무엇인가
• 키워드 검색, 의미 검색, 하이브리드 검색
• RAG, 긴 컨텍스트, 파인튜닝, LLM Wiki 비교