n8n RAG 챗봇 만들기 — 구글드라이브 문서를 Gemini로 색인하고 답하기

n8n.io 공식 템플릿 마켓플레이스에 공개된 RAG 챗봇 워크플로우를 가져오면, 구글드라이브 폴더에 문서를 올리는 것만으로 Gemini와 Pinecone이 알아서 색인하고, 채팅창에 질문을 던지면 그 문서를 근거로 답이 돌아오는 사내 문서 챗봇을 만들 수 있습니다.

이 템플릿 하나로 보여줄 수 있는 것

면접에서 요즘 자주 나오는 질문 중 하나가 "RAG 써보셨어요?"입니다. 이 템플릿은 그 질문에 실제 사례로 답할 수 있게 해줍니다. "회사 문서를 구글드라이브에 올리면 자동으로 벡터DB에 색인되고, 채팅창에 질문하면 그 문서를 근거로 답하는 챗봇을 n8n으로 구성해봤습니다"라고 말할 수 있습니다.

문장 하나지만 안에 들어간 역량은 세 가지입니다.

• 문서 인덱싱 파이프라인 — 문서를 청크 단위로 쪼개고 임베딩으로 변환해 벡터DB에 저장하는 흐름을 구성한 경험
• 벡터 검색 기반 에이전트 — AI Agent가 벡터스토어를 도구로 호출해 질문과 관련된 내용만 골라 답하게 설계한 경험
• 대화 맥락 유지 — 메모리 노드를 붙여 이전 대화를 기억하는 챗봇을 구성한 경험

이 세 가지는 사내 위키 챗봇뿐 아니라 고객 문의 응답, 계약서 검색, 강의 자료 Q&A처럼 "문서를 근거로 답하는" 유형의 AI 기능 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 RAG chatbot for company documents using Google Drive and Gemini라는 이름으로 공개된 템플릿이고, 제작자는 Mihai Farcas입니다. 카테고리는 Internal Wiki와 AI RAG로 등록돼 있어서, 사내 문서를 찾아주는 위키형 챗봇을 만들 때 참고할 표준 사례로 자주 꼽힙니다.

공식 설명에 따르면 이 템플릿은 구글드라이브에 저장된 회사 문서를 근거로 직원 질문에 답하는 RAG(Retrieval Augmented Generation) 챗봇입니다. 새로 올라오거나 수정된 문서를 Pinecone 벡터DB에 자동으로 색인해두기 때문에, 문서가 바뀌어도 챗봇이 최신 내용을 따라갑니다. 임베딩과 답변 생성 모두 구글 Gemini를 사용합니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 구조 자체에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works"를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다. 이 템플릿은 사실 파이프라인이 두 개입니다. 문서를 색인하는 흐름과 질문에 답하는 흐름이 트리거만 다를 뿐, 하나의 캔버스 안에서 같은 Pinecone 벡터DB를 공유합니다.

• Trigger — Google Drive Trigger 두 개(새 파일 감지, 파일 업데이트 감지)가 색인 파이프라인을 시작하고, Chat Trigger가 질문 파이프라인을 시작합니다.
• Task — 색인 파이프라인은 파일 다운로드 → 문서 로드 → 청크 분할 → 임베딩 생성(text-embedding-004) → Pinecone 색인 순으로 돕니다. 질문 파이프라인은 AI Agent가 Vector Store Tool로 관련 청크를 검색하고, 검색 결과와 질문을 Gemini Chat Model(gemini-pro)에 넘겨 답을 만듭니다.
• Target — 색인 파이프라인의 결과물은 Pinecone 벡터DB이고, 질문 파이프라인의 결과물은 채팅창에 뜨는 답변입니다. Window Buffer Memory가 AI Agent에 붙어 있어서, 답변은 이전 대화 맥락도 함께 고려합니다.

만들기

공식 Setup 단계는 총 7개입니다. 순서는 그대로 두고 각 단계에서 무엇을 확인해야 하는지를 풀어씁니다.

1. 구글 클라우드 프로젝트와 Vertex AI API

구글 클라우드 콘솔에서 프로젝트를 하나 만들고, 그 프로젝트에서 Vertex AI API를 활성화합니다. 이 템플릿은 임베딩과 응답 생성에 Gemini를 쓰는데, Gemini 계열 API 상당수가 이 Vertex AI API 활성화를 전제로 동작합니다.

2. Google AI API 키 발급

Google AI Studio에서 API 키를 별도로 발급받습니다. 1번의 Vertex AI API 활성화와 이 키는 별개 절차라서, 하나만 해두고 나머지를 빠뜨리기 쉬운 지점입니다. 두 가지를 다 챙겨야 n8n에서 Google Gemini(PaLM) Api 크리덴셜이 정상 동작합니다.

3. Pinecone 계정과 인덱스 준비

Pinecone 웹사이트에서 계정을 만들고 대시보드에서 API 키를 확인합니다. 그다음 Pinecone 프로젝트 안에 인덱스를 하나 만드는데, 이름을 반드시 company-files로 맞춰야 합니다. 템플릿의 Pinecone Vector Store 노드가 이 이름을 그대로 참조하도록 구성돼 있어서, 이름이 다르면 색인도 검색도 되지 않습니다.

4. 구글드라이브 폴더 준비

구글드라이브에 회사 문서를 모아둘 전용 폴더를 하나 만듭니다. 이 폴더가 색인 파이프라인의 감시 대상이 됩니다.

5. n8n 크리덴셜 3종 연결

n8n에서 Google Drive OAuth2, Google Gemini(PaLM) Api, Pinecone API 세 가지 크리덴셜을 등록합니다. 서비스 세 곳의 인증 정보를 각각 연결하는 작업이라, 여기서 하나라도 빠지면 임포트 이후 노드마다 인증 에러를 만나게 됩니다.

6. 템플릿 임포트

템플릿 페이지에서 워크플로우를 자신의 n8n 인스턴스로 가져옵니다.

7. 폴더와 인덱스 이름 맞추기

임포트 직후에는 두 곳을 반드시 손봐야 합니다. 두 개의 Google Drive Trigger 노드 모두 4번에서 만든 폴더를 감시하도록 바꾸고, Pinecone Vector Store 노드가 3번에서 만든 인덱스를 가리키는지 확인합니다. 트리거 하나만 폴더를 바꾸고 나머지 하나를 놓치면, 새 파일은 색인되는데 수정된 파일은 반영이 안 되는 식으로 절반만 동작하게 됩니다.

주의할 점 · 제약

공식 문서에 적힌 제약을 그대로 옮기면 세 가지입니다.

• 서비스 세 곳에 걸친 설정 — 구글 클라우드(Vertex AI API), Google AI Studio, Pinecone까지 계정과 키를 각각 준비해야 합니다. 하나의 서비스로 끝나는 템플릿이 아니라서, 처음 설정에 들이는 시간이 다른 템플릿보다 깁니다.
• 인덱스 이름이 고정돼 있다 — Pinecone 인덱스 이름을 company-files로 맞추지 않으면 워크플로우를 그대로 가져와도 동작하지 않습니다. 이름을 바꾸고 싶다면 Pinecone Vector Store 노드 설정도 함께 바꿔야 합니다.
• 임베딩·응답 모델이 템플릿에 고정돼 있다 — 임베딩은 text-embedding-004, 응답 생성은 gemini-pro로 지정돼 있습니다. 다른 모델로 바꾸려면 해당 모델을 지원하는지 확인한 뒤 두 노드를 각각 수정해야 합니다.

포트폴리오·면접 포인트

포트폴리오에는 구글드라이브에 문서 하나를 올렸을 때 색인이 도는 과정과, 채팅창에 그 문서 내용을 물어봤을 때 답이 돌아오는 장면 두 개를 캡처해두면 됩니다. 문서를 하나만 넣지 말고 서로 내용이 겹치는 문서 두세 개를 넣어서, 챗봇이 어느 문서를 근거로 답했는지까지 보여주면 훨씬 설득력이 있습니다.

이력서에 자주 쓰는 표현인 "사내 문서 기반 RAG 챗봇 구축 경험" 뒤에는 보통 "어떤 벡터DB를 왜 썼는지" 같은 질문이 따라옵니다. 이 템플릿을 직접 만들어봤다면 "청크로 쪼갠 문서를 임베딩해 Pinecone에 저장하고, 질문이 들어오면 AI Agent가 그 벡터DB를 도구로 호출해 관련 청크만 찾아 답을 만드는 구조였다"고 구체적으로 답할 수 있습니다. 노드 이름을 나열하는 대신 색인과 검색이 왜 두 파이프라인으로 분리돼 있는지를 설명할 수 있으면, 템플릿을 그대로 가져다 쓴 사람과 구조를 이해한 사람이 갈립니다.

다음 액션

다음 편에서는 같은 마켓플레이스에 공개된 텔레그램 기반 개인 비서 템플릿을 다룹니다. 음성과 텍스트 입력을 각각 다른 경로로 처리하는 구조라, 이번 편에서 본 "트리거 두 개가 파이프라인 두 개를 나눠 맡는" 패턴을 한 번 더 다른 방식으로 보게 됩니다.