Gemini Gem ‘동적 컨텍스트’로 지식베이스 동기화하는 법
동적 컨텍스트(동기화되는 지식 베이스)란, Gemini의 커스텀 AI인 ‘Gem’이 구글 문서 같은 외부 문서를 “지식 원천”으로 붙잡고 있다가 사용자가 질문할 때마다 그 문서를 근거로 답해주는 방식입니다. 핵심은 프롬프트에 매번 자료를 붙여 넣는 게 아니라, 지식이 문서에 남아 업데이트되면 답변도 함께 최신화될 수 있다는 점이에요.1
이 글에서는 “Gem을 만들고 → 문서를 연결하고 → 답변 규칙을 걸고 → 운영까지 안정화”하는 흐름으로, 처음 하는 분도 따라 할 수 있게 튜토리얼 형태로 정리해 보겠습니다.
동적 컨텍스트란? “프롬프트 복붙 지옥”을 끝내는 방식
예전에는 팀의 정책 문서나 FAQ를 AI에게 시키려면, 질문할 때마다 관련 내용을 복사해서 붙여 넣는 일이 많았습니다. 그런데 이렇게 하면 자료가 조금만 바뀌어도 프롬프트를 다시 손봐야 하고, 버전이 섞이면 답이 흔들리기 쉽습니다.
동적 컨텍스트는 발상을 바꿉니다. “AI가 똑똑해지게 만들기”보다 “AI가 참고할 교과서를 고정하기”에 가깝습니다. 지식은 문서(구글 문서/드라이브)에 두고, Gem은 그 문서를 읽어 설명만 잘하는 역할을 맡습니다.1
이 구조가 좋은 이유는 단순합니다. 지식과 대화 로직이 분리되니까 운영 레버가 ‘프롬프트 엔지니어링’에서 ‘문서 관리’로 바뀝니다. 비개발자도 문서만 고치면 AI가 최신 답을 내놓을 수 있죠.
Gem 만들기: “첨부 문서 기반으로만 답하기” 규칙부터 박자 맞추기
먼저 Gemini에서 새 Gem을 만듭니다. 여기서 중요한 건 기능 버튼보다 ‘지시문(Instruction)’입니다. 문서를 연결해도, Gem이 마음대로 아는 척하면 동적 컨텍스트의 장점이 반감되거든요.
지시문에는 이런 방향이 들어가면 좋습니다. “반드시 연결된 문서를 근거로 답하라”, “문서에 없으면 모른다고 말하라”, “필요하면 문서의 어느 섹션을 봐야 하는지 안내하라” 같은 원칙이요. 이렇게 해두면 환각을 줄이고, 사용자도 “이 AI는 어디까지 아는지”를 빠르게 파악합니다.1
한 문장으로 요약하면 이겁니다. Gem의 성격을 ‘박학다식한 친구’가 아니라 ‘정확한 안내 데스크’로 세팅하는 단계입니다.
Knowledge에 구글 드라이브 문서 연결하기: 지식의 “단일 진실원” 만들기
다음은 Gem 설정의 ‘Knowledge’ 영역에서 구글 드라이브 문서를 연결하는 단계입니다.1 여기서 문서가 곧 지식베이스가 됩니다. 팀이 같은 Gem을 쓰더라도 답변 근거가 한 문서로 고정되니, 정보가 흩어지지 않는 “단일 진실원(Source of Truth)”이 생깁니다.
이 방식은 내부 FAQ나 고객지원 시나리오에서 특히 강력합니다. 예를 들어 운영팀이 구글 문서로 정책을 관리하고, 상담팀은 Gem에게 질문만 하면 됩니다. “문서 최신 버전이 뭐였지?” 같은 대화가 확 줄어듭니다.
그리고 중요한 포인트 하나. 문서 접근 권한이 곧 보안 정책이 됩니다. 문서가 공유되어 있으면 Gem의 답변을 통해 민감 정보가 노출될 수 있으니, 공유 범위와 권한 관리는 ‘옵션’이 아니라 ‘설계’로 봐야 합니다.1
미니 데모: 문서에 Q&A를 추가하면, Gem 답이 바로 바뀐다
튜토리얼 데모에서 특히 인상적인 장면은 “물고기 가격”처럼 간단한 Q&A를 문서에 적어두고 Gem에게 물었을 때, Gem이 그대로 가격을 반환하는 부분입니다(예: “$15.20”).1
더 재미있는 건 그 다음입니다. 문서에 새로운 질문/답을 “추가”만 했는데도, Gem을 다시 만들거나 설정을 손대지 않아도 곧바로 새 항목을 참고해 답하는 모습이 시연됩니다.1
이게 왜 중요하냐면, 운영 현장에서는 “AI를 개선하는 작업”보다 “정보를 업데이트하는 작업”이 훨씬 더 자주 발생하기 때문입니다. 동적 컨텍스트는 그 반복 작업을 문서 편집으로 바꿔버립니다. 심지어 Gem은 문서의 문장을 그대로 복사만 하는 게 아니라, 더 읽기 쉬운 형태로 정리해서 말해줄 수도 있습니다.1
현업 운영 팁: 문서가 커질수록 ‘구조’가 실력이다
처음엔 문서 한 장으로도 잘 됩니다. 하지만 Q&A가 쌓이면 Gem이 어떤 내용을 근거로 잡을지(검색/근거 선택 품질)가 체감 성능을 좌우합니다. 그래서 문서 구조가 곧 성능 튜닝 포인트가 됩니다.1
예를 들어 Q&A를 섹션별로 나누고, 제목을 질문 형태로 통일하고, 표를 써서 “질문 | 답변 | 마지막 업데이트 | 담당자”처럼 정리하면 검색이 안정됩니다. “업데이트 규칙(언제, 누가, 어떤 기준으로 고치는지)”을 문서 상단에 적어두는 것도 좋습니다. 이건 AI를 위한 규칙이면서 동시에 팀을 위한 규칙이 되거든요.
또 하나는 ‘모른다고 말하기’ 정책입니다. 문서 기반으로만 답하도록 제한하면 정확성은 올라가지만, 문서에 없는 질문을 받았을 때의 UX가 어색해질 수 있습니다. 그래서 “관련 섹션이 없으니 담당 부서/문서 링크를 안내한다” 같은 출구 전략을 함께 설계해두면 실제 사용성이 좋아집니다.1
(확장 아이디어) API로도 “외부 문서 기반 답변” 흐름을 만들 수 있다
Gem의 동적 컨텍스트가 “노코드로 지식 동기화”를 열어줬다면, 개발자 관점에서는 Gemini API의 외부 파일 URL 지원이 비슷한 방향의 확장을 가능하게 합니다. 예를 들어 Google Docs/Sheets/Slides를 export URL(PDF)로 만들어 모델 입력으로 바로 전달하는 패턴이 소개되어 있어요.2
즉, 운영팀은 Gem으로 빠르게 시작하고, 규모가 커지면 API로 워크플로우에 붙이는 식의 단계적 확장이 가능합니다. “처음부터 거대한 RAG 시스템”을 만들지 않아도, 작은 성공을 쌓아 갈 수 있는 선택지가 생긴 셈이죠.
시사점: 동적 컨텍스트의 본질은 “AI 세팅”이 아니라 “문서 운영”입니다. Gem을 잘 만드는 사람은 프롬프트 장인이기보다, 최신 문서를 깔끔하게 유지하는 편집장에 가깝습니다.
지금 팀에 FAQ가 흩어져 있다면, 오늘 할 일은 모델 비교가 아니라 문서 하나를 “단일 진실원”으로 정하는 것입니다. 그다음 Gem을 연결해 보세요. 질문이 들어올수록 문서가 다듬어지고, 문서가 다듬어질수록 답변 품질이 오르는 선순환을 금방 체감하게 될 겁니다.
참고
2Seamless Integration of Google Workspace and Gemini API via External URLs - DEV Community