문서 RAG가 익숙해진 팀도 이미지, 스크린샷, 영상, 오디오가 섞이면 금방 흔들립니다. 검색 단위, 임베딩 차원, 메타데이터, 권한 처리, 근거 표시 방식이 모두 달라지기 때문입니다.
이 글은 새 기능 소개가 아니라 바로 써먹을 운영 절차에 초점을 맞춥니다. AI 기능은 데모가 쉬운 만큼 운영 실패도 쉽습니다. 특히 실무 개발자는 “어떤 모델이 좋다”보다 “어떤 입력을 넣고, 어떤 결과를 검증하고, 어디서 멈출지”가 더 중요합니다. 멀티모달 RAG 인덱싱을 적용할 때도 같은 원칙이 필요합니다.
처음부터 전사 자동화를 목표로 잡으면 실패 확률이 높습니다. 대신 반복 빈도가 높고, 실패했을 때 되돌리기 쉬우며, 성공 기준이 눈에 보이는 작업을 하나 고르는 게 좋습니다. 예를 들어 코드 리뷰 초안, 릴리스 노트 정리, 고객 문의 분류, 테스트 실패 로그 요약, 디자인 시안 비교처럼 사람의 최종 판단이 남는 작업이 안전한 출발점입니다.
작업을 고른 뒤에는 세 가지 질문에 답해야 합니다.
이 세 질문이 흐리면 프롬프트를 아무리 잘 써도 운영이 흔들립니다.
실무에서는 프롬프트보다 파이프라인이 중요합니다. 입력 단계에서는 모델에 넣을 수 있는 데이터와 넣으면 안 되는 데이터를 나눕니다. 처리 단계에서는 모델이 사용할 도구와 권한을 제한합니다. 검증 단계에서는 결과를 그대로 반영할지, 사람 승인 후 반영할지 정합니다. 기록 단계에서는 나중에 문제를 재현할 수 있도록 요청, 응답, 도구 호출, 승인 여부를 남깁니다.
이 구조를 간단한 표로 만들면 다음과 같습니다.
중요한 건 처음부터 완벽한 플랫폼을 만들 필요가 없다는 점입니다. 작은 JSON 로그와 체크리스트만 있어도 나중에 품질을 비교할 수 있습니다.
프롬프트가 길면 안전해질 것 같지만 꼭 그렇지는 않습니다. 실무에서는 장황한 배경보다 작업 계약이 선명해야 합니다. 좋은 프롬프트는 보통 네 부분으로 충분합니다.
예를 들어 “최근 장애 로그를 보고 원인을 찾아줘”보다 “최근 200줄 로그에서 결제 API 5xx 원인 후보를 3개로 줄이고, 각 후보별 확인 명령을 1개씩 제시해줘. 배포나 수정 명령은 제안하지 마”가 훨씬 낫습니다. 모델이 똑똑해져도 명령이 흐리면 결과는 흔들립니다.
멀티모달 RAG 인덱싱을 운영에 붙일 때는 품질 지표를 여러 층으로 봐야 합니다. 정답률이나 만족도만 보면 늦습니다. 더 중요한 것은 실패가 어떤 모양으로 나타나는지입니다. 같은 오답이라도 근거 없는 단정, 누락, 오래된 정보 재사용, 과도한 도구 호출, 권한 밖 제안은 서로 다른 문제입니다.
추천 지표는 다음과 같습니다.
이 지표를 1주만 모아도 어떤 작업이 자동화에 맞고 어떤 작업이 아직 이른지 보입니다.
가장 안전한 배포 순서는 읽기 전용, 초안 생성, 제한적 쓰기, 자동 실행 순서입니다. 읽기 전용에서는 문서 요약이나 로그 해석처럼 시스템 상태를 바꾸지 않는 작업만 맡깁니다. 초안 생성에서는 사람이 복사하거나 승인해야만 반영되게 합니다. 제한적 쓰기에서는 특정 폴더, 특정 필드, 특정 API만 허용합니다. 자동 실행은 마지막입니다.
이 순서를 지키면 제품팀과 개발팀이 싸우지 않습니다. 제품팀은 빠르게 사용자 가치를 확인할 수 있고, 개발팀은 사고 반경을 통제할 수 있습니다. 특히 초기에는 자동화율보다 “잘 멈추는 능력”을 더 높게 봐야 합니다.
첫 번째 실패는 컨텍스트 과다입니다. 관련 없는 문서까지 넣으면 모델은 그럴듯한 연결을 만들고, 사람은 왜 그런 결론이 나왔는지 찾기 어려워집니다. 해결책은 입력 문서를 줄이고, 모델에게 사용한 근거를 항목별로 쓰게 하는 것입니다.
두 번째 실패는 권한 과다입니다. 처음부터 쓰기 권한을 열면 잘못된 변경이 빠르게 퍼집니다. 해결책은 allowlist와 dry-run입니다. 모델이 먼저 계획을 내고, 시스템은 계획을 검사한 뒤 제한된 액션만 실행해야 합니다.
세 번째 실패는 비용 누수입니다. 긴 컨텍스트, 자동 재시도, 병렬 실행이 겹치면 비용이 조용히 커집니다. 해결책은 요청당 예산과 재시도 정책입니다. 실패하면 무조건 다시 돌리는 게 아니라 실패 유형별로 멈춰야 합니다.
처음 구현은 복잡할 필요가 없습니다. 백엔드에 작업 테이블 하나를 만들고, 각 요청에 task_id를 붙입니다. 요청 본문에는 목적, 입력 파일, 제한, 프롬프트 버전을 저장합니다. 응답에는 모델명, 토큰 또는 비용, 걸린 시간, 결과 요약, 검증 상태를 저장합니다. 사용자가 승인하면 approved_at과 approver를 남깁니다. 실패하면 error_type을 분류합니다.
이 정도만 해도 나중에 “왜 이 결과가 나왔는지”, “어떤 프롬프트 버전이 더 나았는지”, “어떤 사용자가 위험한 요청을 많이 하는지”를 볼 수 있습니다. 거창한 MLOps보다 이런 작은 기록이 먼저입니다.
멀티모달 RAG는 더 많은 파일을 넣는 문제가 아니라 검색 가능한 단위를 다시 정의하는 문제입니다. 처음부터 근거 표시와 권한 필터를 같이 설계해야 실무에서 신뢰할 수 있습니다.
출처: Google Developers Blog, Building with Gemini Embedding 2, https://developers.googleblog.com/en/building-with-gemini-embedding-2/
