AI 검색시스템에 '무엇을' 넣을지 정하는 법

🤖 AI가 내 문서를 똑똑하게 찾아주는 시스템, 뭘 넣어야 할까?

요즘 ChatGPT나 Claude 같은 AI에게 "내 노트에서 이런 내용 찾아줘"라고 물어보고 싶어하는 분들이 많아졌어요. 특히 개발자나 지식 작업자들은 수백 개의 문서, 노트, 코드 파일을 가지고 있는데, 이걸 AI가 알아서 검색해주면 얼마나 좋을까요?

이런 시스템을 RAG(Retrieval-Augmented Generation, 검색 증강 생성)라고 부르는데, 핵심은 벡터 DB(Vector Database)라는 곳에 문서들을 저장해두는 겁니다. 그런데 여기서 가장 중요한 결정이 하나 있어요: "무엇을 넣을 것인가?"

모든 걸 다 넣으면 좋을 것 같지만, 실제로는 그렇지 않습니다. 잘못 넣으면 AI가 엉뚱한 답을 주거나, 정작 원하는 정보는 못 찾고 필요 없는 코드만 주구장창 보여줄 수 있거든요.

💡 실제로 어떻게 활용할 수 있을까?

시나리오 1: 개인 지식 관리

회사에서 몇 년 동안 쌓인 업무 노트가 수백 개 있다고 생각해보세요. "작년에 정리한 API 설계 원칙이 뭐였지?" 같은 질문을 AI에게 던지면, 관련 노트를 찾아서 요약해서 알려주는 거죠.

이때 벡터 DB에는 설계 원칙을 정리한 노트가 들어가야 합니다. 반면 실제 API 구현 코드는 넣지 않는 게 좋아요. 왜냐하면 "설계 원칙"을 물어본 사람에게 코드를 보여줘봤자 도움이 안 되거든요.

시나리오 2: 팀 온보딩 시스템

신입 개발자가 "이 프로젝트에서 사용자 인증은 어떻게 처리해?"라고 물어본다면? 이때는 인증 관련 코드와 문서를 모두 벡터 DB에 넣어야 합니다. 코드만으로는 "왜 이렇게 구현했는지" 알기 어렵고, 문서만으로는 "실제로 어떻게 동작하는지" 파악하기 어려우니까요.

🔍 벡터 DB가 뭔지부터 알아보자

벡터 DB에 문서를 넣는다는 건 의미 검색(semantic search)을 가능하게 만드는 거예요. 기존 검색과 뭐가 다른지 비교해볼게요:

검색 방식	예시 질문	찾는 방법
키워드 검색	"RAG"가 들어간 문서 찾기	정확히 "RAG"라는 단어가 있는 문서만 검색
의미 검색	"외부 지식을 AI에 주입하는 방법"	"RAG" 단어가 없어도 의미적으로 관련된 문서를 찾음

이 의미 검색을 위해 문서를 임베딩(embedding)이라는 숫자 벡터로 변환해서 저장하는 게 벡터 DB의 역할입니다.

📋 핵심 원칙: 질문 대상만 넣어라

"사용자가 자연어로 질문할 대상만 벡터 DB에 넣어라" - 이게 가장 중요한 원칙입니다.

왜 이 원칙이 중요한지 단계별로 설명해드릴게요.

1단계: 사용자의 질문 패턴 파악하기

이 단계를 하는 이유: 누가 무엇을 물어볼지 알아야 적절한 데이터를 준비할 수 있습니다.

먼저 실제로 시스템을 사용할 사람이 어떤 질문을 할지 생각해보세요:

• 지식 검색형 질문: "파이프라인 설계 원칙이 뭐였지?", "마케팅 전략 프레임워크 정리한 게 있나?"
• 코드 검색형 질문: "이 함수는 어디서 정의되었지?", "API 키를 어떻게 설정하지?"

이 두 질문 유형은 완전히 다른 검색 방식을 요구합니다.

2단계: 노이즈 방지 전략 수립하기

이 단계를 하는 이유: 잘못된 검색 결과가 나오면 사용자가 시스템을 신뢰하지 않게 됩니다.

노이즈가 생기는 대표적인 상황을 실제 예시로 보여드릴게요:

사용자: "파이프라인 설계 원칙에 대해 알려줘"
잘못된 결과: pipeline.py 코드 파일이 검색됨
문제: 사용자는 설계 원칙을 원했는데 구현 코드를 받음

이를 방지하려면 애초에 질문 의도와 맞지 않는 파일은 벡터 DB에서 제외해야 합니다.

3단계: 프로젝트별 맞춤 적용하기

이 단계를 하는 이유: 같은 원칙이라도 프로젝트 목적에 따라 구체적 적용 방법이 달라집니다.

⚠️ 자주 하는 실수들과 해결책

❌ 실수 1: "일단 다 넣고 나중에 필터링하자"

많은 분들이 "모든 파일을 넣고 나중에 AI가 알아서 걸러주겠지" 생각하시는데, 벡터 DB에서는 이게 쉽지 않습니다. 벡터 검색은 확률적 매칭이라서 정확한 필터링이 어려워요. 애초에 깨끗한 데이터를 넣는 게 훨씬 효과적입니다.

✅ 해결책: 포함/제외 기준을 먼저 정하고 선별적으로 넣으세요.

❌ 실수 2: "코드는 절대 넣으면 안 된다"

반대로 "코드는 무조건 제외"라고 생각하는 것도 잘못입니다. GitHub Copilot이나 Sourcegraph Cody 같은 도구들은 코드를 벡터 DB에 넣어서 "이 기능과 비슷한 코드가 어디 있지?" 같은 의미 검색을 훌륭하게 지원해요.

✅ 해결책: 목적에 따라 결정하세요. 핵심은 사용자가 코드에 대해 자연어로 질문하느냐입니다.

❌ 실수 3: 테스트 없이 시스템 구축

처음부터 완벽한 시스템을 만들려다 보면 실제 사용해보기 전까지 문제점을 발견하기 어려워요.

✅ 해결책: 소량의 데이터로 먼저 프로토타입을 만들고 실제 질문을 해보세요.

🎯 실제 적용 가이드

이제 실제로 여러분의 프로젝트에 적용할 때 따라할 수 있는 단계별 가이드를 제시할게요.

1단계: 질문 시나리오 작성하기

이 작업을 하는 이유: 구체적인 질문 예시가 있어야 포함/제외 기준을 명확하게 정할 수 있습니다.

예상되는 질문 10개 정도를 적어보세요:

예시 질문들:
• "API 호출 시 타임아웃 처리 방법은?"
• "지난달에 논의한 마케팅 전략이 뭐였지?"
• "React 컴포넌트 재사용 패턴 정리한 게 있나?"
• "GPU 메모리 최적화 관련 학습 내용은?"
• "고객 인터뷰에서 나온 주요 피드백이 뭐였지?"
• "데이터베이스 인덱스 설계 원칙 정리본 어디 있어?"
• "경쟁사 분석 결과를 요약해줘"
• "지난 분기 회고에서 개선할 점으로 뭘 얘기했지?"
• "프로젝트 위험 관리 체크리스트 있나?"
• "팀 내 코드 리뷰 가이드라인은 뭐야?"

2단계: 파일 타입별 분류하기

이 작업을 하는 이유: 파일 확장자나 디렉토리 패턴만으로도 1차 필터링을 할 수 있습니다.

포함 대상	제외 대상	판단 기준
*.md (마크다운 노트)	*.py, *.js (소스코드)	자연어 vs 프로그래밍 언어
*.txt (메모, 회의록)	*.json, *.yaml (설정)	사람이 읽는 글 vs 시스템 설정
docs/ (문서 디렉토리)	node_modules/ (의존성)	직접 작성한 내용 vs 외부 라이브러리
meeting-notes/ (회의록)	logs/ (시스템 로그)	인사이트 vs 단순 기록

3단계: 테스트와 검증하기

이 작업을 하는 이유: 실제로 써봐야 설계가 적절한지 알 수 있습니다.

소량의 데이터로 먼저 테스트해보세요:

1. 1단계에서 작성한 질문들을 실제로 검색해보기
2. 예상과 다른 결과가 나오면 원인 분석하기
3. 포함/제외 기준 재조정하기

예상 결과: 대부분의 질문에 대해 관련성 높은 문서 3-5개가 상위에 나와야 합니다. 만약 전혀 관련 없는 문서가 상위에 나오거나, 원하는 문서가 아예 검색되지 않으면 데이터 선별 기준을 다시 검토해보세요.

🚀 한 걸음 더: 실전 팁들

💡 팁 1: 문서 길이도 고려하기

너무 긴 문서는 청킹(chunking)해서 나누고, 너무 짧은 메모는 관련 문서와 합치는 게 검색 품질에 도움이 됩니다.

💡 팁 2: 메타데이터 활용하기

파일 생성 날짜, 태그, 작성자 등의 메타데이터를 함께 저장하면 "최근에 작성한" 같은 조건으로 검색 범위를 좁힐 수 있어요.

💡 팁 3: 사용자 피드백 수집하기

검색 결과에 대한 사용자의 만족도를 수집해서 시스템을 지속적으로 개선하세요. "이 결과가 도움이 되었나요?" 같은 간단한 피드백만으로도 큰 개선이 가능합니다.

🔗 마무리

RAG 시스템의 성능은 AI 모델의 성능보다도 "무엇을 넣느냐"에 더 크게 좌우됩니다. 복잡한 알고리즘보다는 명확한 설계 원칙이 더 중요해요.

"누가 무엇을 물어볼까?"라는 질문부터 시작해서, 사용자의 질문 의도에 맞는 데이터만 골라서 넣으세요. 그러면 훨씬 더 똑똑하고 신뢰할 수 있는 AI 검색 시스템을 만들 수 있을 거예요.

다음에는 실제로 벡터 DB를 구축하는 구체적인 방법에 대해서도 다뤄볼게요. 궁금한 점이 있으시면 댓글로 언제든 물어보세요! 😊

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.