RAG 워크플로우로 나만의 지식 에이전트 만들기

똑똑한 AI보다 중요한 것은 '근거 있는 AI'다

AI를 처음 업무에 붙이면 누구나 비슷한 착각을 한다. "최신 모델을 쓰면 알아서 잘 답하겠지." 실제로는 반대에 가깝다. 모델이 아무리 좋아도 내 회사의 환불 정책, 지난주에 바뀐 가격표, 고객별 계약 조건, 내부 운영 매뉴얼을 모르면 그럴듯한 말로 빈칸을 채운다. 문제는 그 말투가 너무 자연스럽다는 것이다. 틀렸는데도 자신감이 넘친다.

1인 회사에서 이것은 단순한 품질 문제가 아니다. 잘못된 답변 하나가 고객 불만, 환불 요청, 신뢰 하락으로 이어질 수 있다. 당신이 잠든 사이 챗봇이 없는 정책을 만들어 고객에게 안내한다면, 자동화는 레버리지가 아니라 리스크가 된다.

그래서 비즈니스에 쓸 수 있는 AI의 기준은 "얼마나 똑똑한가"가 아니라 "무엇을 근거로 답하는가"다. RAG, 즉 검색 증강 생성은 이 문제를 해결하기 위한 가장 실용적인 구조다. 모델에게 모든 문서를 외우게 하는 대신, 질문이 들어올 때마다 관련 자료를 찾아서 그 자료를 근거로 답하게 만든다. n8n은 이 RAG 흐름에서 문서 수집, 분할, 임베딩, 벡터 저장, 검색, 답변 생성을 하나의 시각적 워크플로우로 엮을 수 있게 해준다.¹

RAG를 한 문장으로 말하면 이렇다.

사용자의 질문을 받으면, 내 문서에서 관련 근거를 먼저 찾고, 그 근거만 보고 답하게 만드는 방식이다.

이 장에서는 FAQ, Notion 문서, PDF, Google Drive 파일을 기반으로 지식 에이전트를 만든다. 목표는 단순한 챗봇이 아니다. 고객과 팀원이 질문했을 때 "아마도"가 아니라 "이 문서의 이 내용에 따르면"이라고 답하는 업무용 AI를 만드는 것이다.

RAG 파이프라인을 한 번에 이해하기

RAG는 어려운 이름을 갖고 있지만, 실제 흐름은 도서관 사서와 비슷하다. 사용자가 질문한다. 사서는 책 전체를 외우지 않는다. 대신 질문과 관련된 책장을 찾고, 필요한 페이지를 펼친 뒤, 그 내용을 바탕으로 설명한다. RAG의 핵심도 같다. LLM이 모든 것을 기억하게 하지 말고, 필요한 순간에 필요한 자료를 찾아 보여주는 것이다.

실전 RAG 파이프라인은 크게 두 개의 워크플로우로 나누는 것이 좋다. 하나는 지식베이스를 만드는 ingest 워크플로우이고, 다른 하나는 질문에 답하는 query 워크플로우다.

Ingest 워크플로우는 문서를 읽어 벡터 데이터베이스에 저장하는 과정이다. 이 과정은 보통 문서가 새로 추가되거나 수정될 때 실행된다. Query 워크플로우는 사용자의 질문이 들어올 때 실행된다. 질문을 벡터로 바꾸고, 벡터 데이터베이스에서 관련 문서 조각을 찾은 뒤, LLM에게 그 조각들을 근거로 답하게 만든다.

전체 흐름은 다음과 같다.

문서 수집
→ 텍스트 추출
→ 정제
→ 청크 분할
→ 임베딩 생성
→ 벡터 저장
→ 사용자 질문 수신
→ 질문 임베딩
→ 관련 청크 검색
→ 답변 생성
→ 출처와 함께 반환

여기서 처음 헷갈리는 단어가 '청크'와 '임베딩'이다. 청크는 긴 문서를 작은 조각으로 나눈 단위다. 예를 들어 20쪽짜리 환불 정책 PDF를 통째로 AI에게 넣는 대신, 500~1,000자 정도의 조각으로 나눈다. 임베딩은 이 조각의 의미를 숫자 배열로 바꾼 것이다. 컴퓨터는 "연간 플랜 환불 규정"이라는 문장의 의미를 사람처럼 읽지 못하므로, 의미가 비슷한 문장끼리 가까워지도록 숫자 좌표로 변환한다. 벡터 데이터베이스는 이 숫자 좌표를 저장하고, 질문과 가장 가까운 문서 조각을 빠르게 찾아준다.

중요한 점은 RAG가 LLM을 대체하는 기술이 아니라는 것이다. RAG는 LLM에게 좋은 자료를 건네는 방식이다. 검색이 나쁘면 답변도 나쁘다. 문서가 지저분하면 답변도 지저분하다. 그래서 좋은 RAG 시스템은 "프롬프트를 잘 쓰는 것"보다 "자료를 잘 준비하고 잘 찾는 것"에서 승부가 난다.

지식베이스로 무엇을 넣을 것인가

1인 회사의 지식베이스는 거창할 필요가 없다. 처음부터 사내 위키 전체를 넣으려고 하면 오히려 망한다. 작게 시작해야 한다. 고객이 반복해서 묻는 질문, 내가 매번 찾아보는 운영 규칙, 외주자에게 매번 설명하는 업무 기준부터 넣으면 된다.

RAG에 넣기 좋은 자료는 세 가지 조건을 만족한다. 첫째, 답변 근거로 쓰일 만큼 신뢰할 수 있어야 한다. 둘째, 문장으로 설명되어 있어야 한다. 셋째, 자주 바뀌더라도 업데이트 경로가 명확해야 한다.

초기 지식베이스 후보는 다음과 같다.

• 고객 FAQ, 환불 정책, 가격 정책, 기능 설명서

• Notion의 내부 운영 문서, SOP, 외주 가이드, 회의 노트

• PDF 제안서, 계약 안내서, 제품 매뉴얼, 강의 교안

• Google Drive에 쌓인 문서, 스프레드시트, 고객 안내 자료

• 고객 피드백, 리뷰, CS 티켓, 영업 상담 로그

다만 모든 자료를 한 벡터 저장소에 무작정 넣으면 안 된다. "고객에게 공개해도 되는 자료"와 "내부 직원만 볼 수 있는 자료"는 분리해야 한다. 같은 RAG 구조라도 고객용 챗봇과 내부 운영 비서는 권한이 달라야 한다. 고객에게 인사 평가 문서나 원가 계산표가 검색되면 안 된다.

따라서 처음 설계할 때 지식베이스를 최소한 세 구역으로 나누면 좋다. 공개 가능한 고객용 문서, 내부 운영 문서, 민감 데이터가 포함된 제한 문서다. n8n에서는 이 구분을 메타데이터로 넣고, query 워크플로우에서 사용자 유형에 따라 검색 필터를 걸 수 있다. "고객" 세션에서는 visibility = public인 청크만 검색하고, "내부 관리자" 세션에서는 visibility = internal까지 허용하는 식이다.

벡터 저장소 선택: Pinecone, Qdrant, Supabase Vector, pgvector

RAG에서 벡터 저장소는 검색 엔진의 심장이다. n8n은 Pinecone, Qdrant, Supabase, Postgres 기반 pgvector 등 여러 벡터 저장소와 연결할 수 있다.² 선택 기준은 "뭐가 제일 유명한가"가 아니라 "내 사업의 운영 방식에 맞는가"다.

Pinecone은 관리형 클라우드 벡터 데이터베이스다. 서버 운영을 신경 쓰기 싫고 빠르게 프로덕션에 올리고 싶을 때 좋다. 다만 장기적으로 데이터가 많아지면 비용 구조를 계속 확인해야 한다. Qdrant는 클라우드와 셀프호스팅을 모두 지원하는 선택지다. Docker로 직접 띄워 쓸 수 있어 데이터 통제권을 중시하는 팀에게 매력적이다. Supabase Vector는 Supabase의 Postgres 기반 환경에서 pgvector를 활용하는 방식으로 이해하면 쉽다. 이미 Supabase를 인증, DB, 스토리지로 쓰고 있다면 지식베이스까지 한곳에서 관리하기 좋다. 순수 Postgres pgvector는 Neon, 자체 Postgres, Supabase 같은 환경에서 벡터 검색을 구현하는 방식이다. SQL과 벡터 검색을 함께 다루고 싶을 때 강력하다.³

1인 창업자에게 현실적인 추천은 이렇다. 이미 Supabase를 쓰고 있다면 Supabase Vector로 시작하라. 문서량이 많지 않고 고객용 챗봇이나 내부 지식봇을 만드는 데 충분하다. 데이터 보안을 더 강하게 통제하고 싶고 Docker 운영에 익숙하다면 Qdrant가 좋다. 빠르게 안정적인 클라우드 서비스를 쓰고 싶다면 Pinecone이 편하다. 고객 데이터, 매출 데이터, 문서 메타데이터를 SQL로 함께 분석해야 한다면 pgvector 기반 Postgres가 장기적으로 유리하다.

이 선택은 영구적이지 않다. n8n에서는 벡터 저장소 노드를 교체하는 방식으로 구조를 바꿀 수 있다. 중요한 것은 처음부터 "완벽한 DB"를 고르는 것이 아니라, 임베딩 모델과 메타데이터 구조를 일관되게 관리하는 것이다. 임베딩 모델을 바꾸면 기존 벡터와 질문 벡터의 좌표계가 달라지므로 전체 문서를 다시 임베딩해야 한다. 이것은 RAG 운영에서 가장 자주 터지는 실수 중 하나다.

Ingest 워크플로우: 지식베이스를 자동으로 먹이는 구조

이제 n8n에서 첫 번째 워크플로우를 설계해보자. 이름은 KB Ingest - Documents to Vector Store 정도로 붙이면 된다. 이 워크플로우의 역할은 자료를 가져와 검색 가능한 형태로 저장하는 것이다.

핵심은 "문서가 바뀌면 벡터DB도 바뀌어야 한다"는 점이다. 예전 환불 정책이 남아 있으면 AI는 낡은 정책을 근거로 답한다. 그래서 ingest 워크플로우는 신규 문서 추가뿐 아니라 수정, 삭제까지 고려해야 한다. n8n의 회사 지식베이스 RAG 템플릿도 Google Drive 파일 변경을 감지하고, 새 파일과 업데이트 파일을 별도 흐름으로 처리해 Supabase 벡터 저장소를 동기화하는 구조를 제안한다.⁴

FAQ를 넣는 가장 단순한 방식

가장 쉬운 출발점은 FAQ다. Google Sheets나 Airtable에 question, answer, category, updated_at, visibility 컬럼을 만든다. FAQ는 구조가 단순하고 답변 품질을 바로 체감할 수 있어서 첫 RAG 실습에 적합하다.

n8n 흐름은 이렇게 만든다.

Schedule Trigger 또는 Manual Trigger
→ Google Sheets: FAQ 행 읽기
→ Set: question + answer를 하나의 content로 합치기
→ Code 또는 Set: metadata 구성
→ Embeddings 노드
→ Vector Store: Insert 또는 Upsert

FAQ는 청크 분할을 과하게 하지 않아도 된다. 질문과 답변 한 쌍이 이미 자연스러운 청크이기 때문이다. 대신 메타데이터가 중요하다. category = refund, source = faq_sheet, visibility = public 같은 값을 넣어두면 나중에 고객용 검색에서 공개 문서만 필터링할 수 있다.

Notion 문서를 넣는 방식

Notion은 1인 회사의 뇌에 가깝다. 아이디어, 운영 매뉴얼, 제품 기획, 외주 가이드가 모두 들어 있다. 하지만 Notion 문서를 그대로 넣으면 제목, 체크박스, 토글, 표가 섞여 검색 품질이 떨어질 수 있다.

Notion ingest 흐름은 다음처럼 설계한다.

Schedule Trigger
→ Notion: 특정 데이터베이스의 페이지 목록 가져오기
→ IF: last_edited_time이 마지막 동기화 이후인지 확인
→ Notion: 페이지 콘텐츠 가져오기
→ HTML/Markdown 형태를 텍스트로 정리
→ Recursive Character Text Splitter
→ Embeddings
→ Vector Store: 기존 page_id 청크 삭제 후 새 청크 삽입
→ DB 또는 Data Store: 마지막 동기화 시간 기록

여기서 중요한 것은 업데이트 방식이다. 문서가 수정되었을 때 기존 청크를 남겨둔 채 새 청크만 추가하면, 검색 결과에 오래된 내용과 새 내용이 함께 나온다. 그러면 AI는 둘 중 무엇이 최신인지 모른다. 가장 안전한 방식은 같은 document_id를 가진 기존 청크를 모두 삭제하고, 새로 분할한 청크를 다시 넣는 것이다.

PDF를 넣는 방식

PDF는 가장 흔하지만 가장 까다로운 자료다. 텍스트 PDF라면 n8n의 파일 추출 노드나 문서 로더로 처리할 수 있다. 스캔본 PDF라면 OCR, 즉 이미지에서 글자를 읽어내는 과정이 필요하다. OCR 품질이 낮으면 RAG 품질도 낮다. PDF의 표, 머리글, 바닥글, 페이지 번호가 섞이면 답변이 엉뚱해질 수 있다.

PDF ingest 흐름은 다음과 같다.

Form Trigger 또는 Google Drive Trigger
→ 파일 다운로드
→ Extract from File 또는 PDF 텍스트 추출
→ Code: 페이지 번호, 파일명, URL 메타데이터 추가
→ 텍스트 정제: 반복 머리글/바닥글 제거
→ Recursive Character Text Splitter
→ Embeddings
→ Vector Store 저장

PDF에서는 page_number 메타데이터가 특히 중요하다. 나중에 답변에 "출처: 환불정책.pdf p.3"처럼 표시할 수 있기 때문이다. 고객이나 팀원이 답변을 신뢰하려면 원문으로 돌아갈 수 있어야 한다.

Google Drive 파일을 넣는 방식

Google Drive는 실전에서 가장 많이 쓰는 지식베이스 출발점이다. 파일을 폴더에 넣기만 하면 자동으로 임베딩되도록 만들 수 있다. Neon의 n8n RAG 예제처럼 Google Drive 트리거로 특정 폴더의 새 파일을 감지하고, 파일을 다운로드한 뒤, 문서 로더와 텍스트 분할기를 거쳐 Postgres pgvector에 저장하는 구성이 가능하다.⁵

추천 구조는 폴더를 역할별로 나누는 것이다.

/knowledge-base/public
/knowledge-base/internal
/knowledge-base/private

Google Drive Trigger가 파일 경로를 읽고, 경로에 따라 visibility 메타데이터를 부여한다. /public에 있는 문서는 고객용 챗봇에서도 검색 가능하게 하고, /internal은 관리자용 봇에서만 검색하게 한다. /private은 기본적으로 검색 대상에서 제외하거나 별도 인증이 있는 워크플로우에서만 접근하게 한다.

이때 파일 변경 감지는 두 가지로 나누면 좋다. 새 파일이 들어오면 바로 임베딩하고, 기존 파일이 수정되면 같은 file_id의 청크를 삭제한 뒤 다시 임베딩한다. 파일이 삭제되었을 때는 벡터 저장소에서도 해당 file_id의 청크를 제거해야 한다. 삭제 이벤트까지 자동화하지 않으면, Drive에서는 지웠는데 AI는 계속 답하는 기묘한 일이 생긴다.

Query 워크플로우: 질문을 근거 있는 답변으로 바꾸기

두 번째 워크플로우는 사용자의 질문을 받는 흐름이다. 이름은 KB Query - Knowledge Agent 정도가 좋다. 이 워크플로우는 웹챗, Slack, Telegram, 이메일, 고객센터 위젯 등 어디에서든 시작할 수 있다. n8n의 Chat Trigger를 쓰면 테스트용 챗 인터페이스를 빠르게 만들 수 있고, AI Agent 노드에 Vector Store Tool을 붙이면 에이전트가 필요할 때 지식베이스를 검색하게 할 수 있다.⁶

기본 흐름은 다음과 같다.

Chat Trigger 또는 Webhook
→ Set: user_id, role, question 정리
→ AI Agent
   ├─ Chat Model
   ├─ Memory
   └─ Vector Store Tool
→ 답변 후처리
→ 사용자에게 반환
→ 질문/답변/출처/점수 로그 저장

여기서 Vector Store Tool의 설명이 매우 중요하다. AI Agent는 도구 이름과 설명을 보고 언제 이 도구를 써야 할지 판단한다. n8n의 Vector Store Question Answer Tool 문서도 데이터 이름과 설명이 에이전트용 도구 설명을 구성하는 데 쓰인다고 설명한다.⁷

나쁜 도구 설명은 이렇다.

knowledge 검색 도구

좋은 도구 설명은 이렇다.

회사 정책, 제품 기능, 가격, 환불 규정, 고객 FAQ에 대한 질문에 답할 때 사용하는 지식베이스 검색 도구입니다. 고객 계정의 개인 데이터가 아니라 일반 문서와 공개 가능한 운영 문서를 찾을 때 사용하세요.

도구 설명은 에이전트에게 붙이는 라벨이 아니다. 검색 행동을 결정하는 작은 프롬프트다. 설명이 모호하면 에이전트가 검색하지 않아도 될 때 검색하고, 검색해야 할 때 검색하지 않는다.

출처가 포함된 답변 만들기

업무용 RAG에서 답변만큼 중요한 것이 출처다. 출처가 없는 답변은 결국 "AI가 그렇게 말했다"에 머문다. 출처가 있으면 "이 문서의 이 부분을 근거로 답했다"가 된다. 고객지원, 세일즈, 내부 운영에서 이 차이는 크다.

답변 생성 프롬프트에는 다음 규칙을 넣는다.

당신은 회사 지식베이스를 기반으로 답하는 지원 에이전트입니다.
반드시 검색된 문서 내용만 근거로 답하세요.
검색 결과에 없는 내용은 추측하지 마세요.
답변 마지막에 사용한 출처를 문서명 또는 URL로 표시하세요.
서로 충돌하는 문서가 있으면 최신 updated_at 값을 우선하고, 충돌 사실을 알려주세요.
근거가 부족하면 "제공된 문서에서는 확인할 수 없습니다"라고 답하세요.

출처를 표시하려면 ingest 단계에서 메타데이터를 잘 넣어야 한다. 최소한 source_type, source_title, source_url, document_id, updated_at은 넣어두자. PDF라면 page_number, Notion이라면 page_url, Google Drive라면 webViewLink가 있으면 좋다.

답변 형식은 너무 복잡하게 만들 필요가 없다.

답변:
연간 플랜은 결제 후 14일 이내에 사용량이 특정 기준 이하인 경우 환불 요청이 가능합니다. 다만 프로모션 코드가 적용된 계약은 별도 조건이 적용될 수 있습니다.

근거:
- 환불정책.pdf, p.3
- 고객 FAQ, "연간 플랜 환불"

처음에는 이 정도면 충분하다. 나중에 고객용 챗봇에서는 출처를 접어두고 "자세히 보기" 링크로 보여줄 수 있고, 내부 운영봇에서는 출처를 더 자세히 보여주면 된다.

n8n에서 만드는 실전 설계도

이제 두 워크플로우를 실제 노드 관점에서 정리해보자. 여기서는 Supabase Vector를 기준으로 설명하지만, Pinecone이나 Qdrant를 써도 구조는 거의 같다.

워크플로우 A: Knowledge Ingest

첫 번째 워크플로우는 문서가 들어오면 지식베이스에 저장한다.

1. Trigger
   - Google Drive Trigger, Notion Schedule, Form Trigger 중 선택

2. Load
   - Google Drive Download
   - Notion Get Page
   - Google Sheets Read
   - PDF Extract

3. Normalize
   - Set 또는 Code 노드로 텍스트 필드 통일
   - content, document_id, source_title, source_url, updated_at 생성

4. Clean
   - 불필요한 공백, 반복 문구, 페이지 머리글 제거
   - 너무 짧은 조각 제거

5. Delete Old Chunks
   - 같은 document_id를 가진 기존 청크 삭제

6. Split
   - Recursive Character Text Splitter
   - chunk size 700~1,200자, overlap 100~200자부터 시작

7. Embed
   - OpenAI, Gemini, Cohere, Ollama 등 임베딩 노드

8. Store
   - Supabase Vector Store, Qdrant, Pinecone, Postgres PGVector
   - content와 metadata 함께 저장

9. Log
   - 처리 파일 수, 청크 수, 실패 파일, 실행 시간 기록

여기서 5번의 기존 청크 삭제는 귀찮아 보여도 반드시 넣어야 한다. 업데이트된 파일을 새로 넣기만 하면 검색 결과에 과거 내용이 남는다. RAG에서 오래된 정보는 없는 정보보다 더 위험하다. 없는 정보는 "모른다"고 답하게 만들 수 있지만, 오래된 정보는 자신 있게 틀리게 만든다.

워크플로우 B: Knowledge Query

두 번째 워크플로우는 질문을 답변으로 바꾼다.

1. Chat Trigger 또는 Webhook
   - 사용자의 질문 수신

2. User Context
   - user_id, role, plan, channel 정리
   - public/internal/private 검색 범위 결정

3. AI Agent
   - Chat Model 연결
   - Memory 연결
   - Vector Store Tool 연결

4. Vector Search
   - top_k 4~6부터 시작
   - similarity threshold 적용
   - visibility, category, updated_at 필터 적용

5. Answer Generation
   - 검색 결과만 근거로 답변
   - 출처 포함
   - 모르는 질문은 거절

6. Post-processing
   - Markdown 정리
   - 출처 링크 변환
   - 민감정보 마스킹

7. Logging
   - question, answer, sources, scores, user feedback 저장

처음에는 AI Agent에 Vector Store Tool을 붙이는 방식이 가장 편하다. 에이전트가 질문을 보고 검색 도구를 호출한다. 다만 검색을 반드시 해야 하는 업무라면 에이전트 판단에 맡기지 말고, 질문이 들어오면 무조건 벡터 검색을 먼저 실행한 뒤 그 결과를 LLM에 넘기는 구조도 좋다. 고객지원처럼 근거가 중요한 영역에서는 "검색 우선" 구조가 더 안전하다.

FAQ, 문서, 고객 데이터를 함께 쓰는 방법

처음 RAG는 FAQ나 문서 검색으로 충분하다. 하지만 사업이 커질수록 질문은 복잡해진다.

"제 플랜에서는 이 기능을 쓸 수 있나요?"

이 질문에 답하려면 두 종류의 정보가 필요하다. 기능별 제공 플랜이 적힌 일반 문서와, 질문한 고객의 현재 플랜 정보다. 일반 RAG는 전자를 잘한다. 고객별 데이터 조회는 CRM이나 DB 조회가 필요하다. 이때부터 RAG는 에이전트 구조로 진화한다.

n8n에서는 AI Agent에 여러 도구를 붙일 수 있다. 하나는 search_knowledge_base라는 벡터 검색 도구이고, 다른 하나는 get_customer_profile이라는 고객 DB 조회 도구다. 질문이 일반 정책이면 지식베이스만 검색한다. 고객 계정과 관련되면 고객 DB를 조회한다. 복합 질문이면 둘 다 사용한다. 이런 구조는 단순 RAG보다 한 단계 높은 Agentic RAG에 가깝다.

하지만 이 장에서는 욕심을 내지 말자. 먼저 문서 기반 지식 에이전트를 안정적으로 만들고, 다음 단계에서 고객 DB, 결제 데이터, CRM을 붙이면 된다. 자동화는 한 번에 복잡해질수록 실패 지점도 늘어난다. 좋은 시스템은 작게 시작해서 견고하게 확장된다.

RAG 정확도를 높이는 7가지 패턴

RAG가 기대보다 못한 답을 할 때 대부분은 모델 문제가 아니다. 검색 문제, 청크 문제, 메타데이터 문제, 프롬프트 문제다. 다음 패턴을 적용하면 답변 품질이 눈에 띄게 좋아진다.

1. 청크는 작지도 크지도 않게 나눈다

청크가 너무 작으면 문맥이 사라진다. "환불 가능"이라는 문장만 검색되고, 어떤 조건에서 가능한지 빠질 수 있다. 청크가 너무 크면 검색은 되었지만 필요 없는 내용이 너무 많이 섞여 모델이 핵심을 놓친다.

일반 문서는 700~1,200자, 겹침은 100~200자에서 시작하자. 영어 기준 토큰으로 설계하는 자료도 많지만, 한국어 문서는 글자 수 기준으로 먼저 잡고 테스트해도 충분하다. 법률, 정책, 계약 문서는 문단 단위가 중요하므로 의미 단위가 깨지지 않게 Recursive Character Text Splitter를 쓰는 것이 좋다.

2. 메타데이터를 답변 품질의 일부로 본다

메타데이터는 장식이 아니다. 검색 품질과 권한 제어의 핵심이다. 최소한 다음 필드는 넣어두자.

• document_id, chunk_id, source_title, source_url

• source_type, category, visibility, language

• created_at, updated_at, version, page_number

메타데이터가 있으면 "고객 공개 문서만 검색", "최근 6개월 문서 우선", "환불 카테고리만 검색" 같은 제어가 가능하다. 벡터 검색이 의미 기반이라면, 메타데이터 필터는 업무 규칙 기반이다. 둘을 함께 써야 실전 시스템이 된다.

3. Top-K는 많다고 좋은 것이 아니다

검색 결과를 많이 넣으면 답변이 더 좋아질 것 같지만, 실제로는 잡음이 늘어난다. 처음에는 top_k를 4~6으로 시작하자. 문서가 짧고 정확하면 3도 충분하다. 질문이 복잡하고 여러 문서를 비교해야 하면 8~10까지 늘릴 수 있다. 단, 늘릴수록 비용과 응답 시간이 증가하고, 모델이 엉뚱한 근거를 섞을 가능성도 커진다.

4. 유사도 임계치를 둔다

검색 결과가 약한데도 억지로 답하게 만들면 환각이 생긴다. 벡터 검색 결과에는 보통 유사도 점수나 거리 값이 있다. 일정 기준보다 낮으면 "관련 문서를 찾지 못했다"고 답하게 해야 한다.

임계치는 데이터와 DB마다 다르므로 절대값을 외우기보다 테스트셋으로 잡아야 한다. 자주 들어오는 질문 30개를 만들고, 기대 문서가 검색되는지 확인한다. 관련 없는 질문 10개도 넣어서 시스템이 제대로 거절하는지 본다. RAG의 품질은 좋은 답변뿐 아니라 좋은 거절에서도 드러난다.

5. 재랭킹을 추가한다

벡터 검색은 1차 후보를 찾는 데 강하지만, 최종 순서를 항상 완벽하게 맞히지는 못한다. 재랭킹은 검색된 후보를 한 번 더 평가해 질문과 더 잘 맞는 순서로 재정렬하는 과정이다. n8n의 일부 고급 RAG 템플릿은 벡터 검색 뒤에 Cohere 같은 재랭커를 붙여 관련성이 높은 결과를 우선하게 만든다.⁸

처음부터 필수는 아니다. 하지만 문서가 1,000개를 넘거나, 비슷한 정책 문서가 많거나, 답변 정확도가 중요한 고객지원 시스템이라면 재랭킹을 고려하자. 검색 후보를 top 10으로 가져온 뒤 재랭커로 top 3만 LLM에 넘기는 식이다.

6. "모른다"는 답변을 설계한다

AI에게 "모르면 모른다고 하라"고 한 줄 쓰는 것만으로는 부족하다. 거절 조건을 구체적으로 줘야 한다.

다음 경우에는 답변을 생성하지 말고 확인 불가라고 말하세요.
1. 검색 결과가 비어 있는 경우
2. 검색 결과의 유사도 점수가 기준보다 낮은 경우
3. 검색 결과끼리 서로 충돌하는데 최신 문서를 판단할 수 없는 경우
4. 질문이 법률, 세무, 의료 조언처럼 전문가 판단이 필요한 경우
5. 사용자의 개인 계정 정보가 필요한데 인증된 고객 데이터가 없는 경우

좋은 지식 에이전트는 모든 질문에 답하지 않는다. 답할 수 있는 것과 답하면 안 되는 것을 구분한다. 이것이 프로덕션 자동화의 품격이다.

7. 질문과 답변 로그로 계속 개선한다

RAG는 한 번 만들고 끝나는 시스템이 아니다. 실제 사용자가 어떤 질문을 하는지 봐야 한다. 검색 실패 질문, 답변 불만족 질문, 사람이 다시 답변한 질문을 모으면 지식베이스가 어디에서 비어 있는지 보인다.

로그에는 최소한 질문, 최종 답변, 검색된 문서 ID, 유사도 점수, 사용자 피드백을 저장하자. 고객이 "도움이 됐나요?"에 아니요를 눌렀다면 그 질문은 개선 후보가 된다. 1인 회사에서는 이 로그가 곧 콘텐츠 기획, FAQ 개선, 제품 문서 개선의 재료가 된다.

RAG가 자주 실패하는 지점

실패를 미리 알면 절반은 피할 수 있다. RAG가 이상한 답을 할 때는 다음 순서로 확인하자.

첫째, 문서가 실제로 벡터 저장소에 들어갔는지 확인한다. ingest 워크플로우가 성공했다고 생각했는데, PDF 텍스트 추출이 비어 있거나, 임베딩 저장이 실패한 경우가 있다.

둘째, 질문과 문서가 같은 임베딩 모델로 처리되었는지 확인한다. 문서를 OpenAI 임베딩으로 넣고 질문을 다른 모델로 임베딩하면 검색 품질이 크게 떨어진다. 벡터 공간이 다르기 때문이다.

셋째, 청크가 너무 이상하게 잘리지 않았는지 본다. 표가 깨졌거나, 문장 중간이 잘렸거나, 제목과 본문이 분리되면 검색 결과가 약해진다.

넷째, 메타데이터 필터가 너무 강하지 않은지 확인한다. visibility = public 필터를 걸었는데 모든 문서가 Public처럼 대문자로 들어가 있으면 검색 결과가 0개가 된다.

다섯째, 프롬프트가 검색 결과보다 모델의 일반 지식을 우선하게 만들고 있지 않은지 본다. "친절하게 답하세요"만 있고 "검색된 근거만 사용하세요"가 없으면 모델은 다시 추측하기 시작한다.

1인 회사용 지식 에이전트 운영 원칙

RAG 지식 에이전트는 고객지원 봇으로만 쓰기 아깝다. 잘 만들면 회사 전체의 기억 장치가 된다. 외주자 온보딩, 내부 의사결정, 콘텐츠 제작, 제품 운영, 영업 응대에 모두 쓸 수 있다.

하지만 운영 원칙이 없으면 금방 어지러워진다. 1인 회사에서는 다음 세 가지를 지키면 된다.

첫째, 문서의 원천을 하나로 정한다. 같은 정책이 Notion, Google Docs, PDF에 각각 다른 버전으로 존재하면 AI도 헷갈리고 사람도 헷갈린다. 원본 문서 위치를 정하고, 나머지는 링크로 연결하자.

둘째, 공개 범위를 문서 단위로 관리한다. 고객용, 내부용, 비공개를 섞지 말자. 처음부터 visibility 메타데이터를 넣어야 나중에 권한 제어를 쉽게 붙일 수 있다.

셋째, 답변 로그를 문서 개선 루프로 연결한다. AI가 답하지 못한 질문은 "AI의 실패"가 아니라 "문서화되지 않은 업무 지식"이다. 그 질문을 FAQ나 운영 문서에 추가하면 다음부터는 자동으로 답할 수 있다. 이렇게 RAG는 단순 챗봇이 아니라 회사의 지식 정리 습관을 만드는 장치가 된다.

작은 지식봇에서 회사의 두 번째 뇌로

처음 만드는 RAG 워크플로우는 소박할 것이다. FAQ 30개, 정책 문서 몇 개, Google Drive 폴더 하나. 그러나 이 작은 구조가 제대로 작동하기 시작하면 당신의 일하는 방식이 바뀐다.

고객이 반복 질문을 해도 매번 새로 쓰지 않는다. 외주자가 업무 기준을 물어도 같은 설명을 반복하지 않는다. 콘텐츠를 만들 때도 과거 메모와 제품 문서를 뒤지느라 시간을 쓰지 않는다. 지식 에이전트가 먼저 찾아주고, 당신은 판단하고 다듬는다.

이 장의 핵심은 기술 이름이 아니다. RAG, 임베딩, 벡터DB 같은 단어보다 중요한 것은 "AI가 내 자료를 근거로 일하게 만든다"는 관점이다. 1인 회사의 자동화는 시간을 줄이는 데서 시작하지만, 결국 기억을 시스템화하는 단계로 간다. 회사가 커지지 않아도 회사의 지식은 커진다. 그 지식을 사람이 머릿속에만 들고 있으면 병목이 되고, RAG 워크플로우에 연결하면 레버리지가 된다.

다음 장에서는 이 지식 에이전트를 더 넓은 도구 생태계와 연결한다. n8n이 만든 자동화와 Claude, Cursor 같은 AI 도구를 MCP로 묶으면, 지식 에이전트는 단순히 답하는 존재를 넘어 실제 업무 도구를 호출하는 운영 에이전트로 확장된다.

참고

¹RAG in n8n

²n8n Vector Store Tool integrations

³Build an AI-powered knowledge base chatbot using n8n and Neon Postgres

⁴Company knowledge base agent (RAG)

⁵Build an AI-powered knowledge base chatbot using n8n and Neon Postgres

⁶Build a custom knowledge RAG chatbot using n8n

⁷Vector Store Question Answer Tool 노드

⁸Build an All-Source Knowledge Assistant with Claude, RAG, Perplexity, and Drive