지메일 라벨링, 드라이브 폴더 정리, 첨부파일 저장까지 “규칙+AI 에이전트”로 자동화하는 방법을 한 번에 정리했습니다. 보안·권한·오탐 대응까지 실무 기준으로 설명합니다.
매일 엑셀 반복 작업에 시달리던 실무자 A씨는 메일함이 곧 업무의 “진짜 할 일 목록”이었습니다. 견적서, 계약서, 세금계산서, 인보이스, 내부 결재 요청이 모두 지메일로 들어오고, 첨부파일은 드라이브에 쌓이는데 정리 규칙이 사람마다 달라 파일을 찾는 데만 하루 30분씩 소모되었습니다. AI를 써보려 했지만 “어디까지 자동화해도 안전한가”, “잘못 분류되면 누가 책임지나” 같은 현실 문제가 발목을 잡았습니다.
AI 서비스 도입을 고민하는 기획자 B씨의 고민도 비슷합니다. 고객지원 메일을 유형별로 분류해 담당자에게 할당하고, 첨부 증빙을 자동 저장하며, 케이스별 템플릿 답장을 초안으로 만들고 싶었습니다. 그러나 지메일/드라이브 권한 모델, 감사 로그, 개인정보(PII) 처리, 그리고 모델의 환각(hallucination) 가능성을 고려하면 “그냥 LLM 붙이기”로는 운영이 불가능했습니다.
- 오늘의 AI 기술 인사이트 핵심 포인트 3가지: “규칙 기반 분기 + 에이전트 판단”의 하이브리드가 오탐/보안 리스크를 가장 낮춘다.
- 오늘의 AI 기술 인사이트 핵심 포인트 3가지: Google Workspace는 Apps Script/Drive API/Gmail API로 워크플로우를 만들고, LLM은 ‘분류·요약·추출’ 같은 제한된 역할로 넣는 것이 안정적이다.
- 오늘의 AI 기술 인사이트 핵심 포인트 3가지: 운영 단계에서 필수는 감사 로그, 권한 최소화(least privilege), 오분류 격리(Quarantine) 폴더, 재학습 없이도 개선 가능한 룰/프롬프트 버전관리다.
1) “지메일·드라이브 자동분류”를 에이전트로 구축할 때의 정답 구조
인공지능 인사이트 에디토리얼 팀의 분석 결과, 지메일·드라이브 자동분류는 3계층으로 나누면 성공 확률이 높습니다.
계층 A: 결정적(Deterministic) 규칙
발신자 도메인, 특정 수신 주소(예: invoices@), 제목 패턴([견적], [세금계산서]), 첨부파일 확장자(pdf, xlsx), 메일 헤더 등 “명확한 신호”는 먼저 규칙으로 처리합니다. 이 단계에서 전체 트래픽의 40~70%를 안정적으로 소화할 수 있습니다.
계층 B: 에이전트(LLM) 판단이 필요한 구간
규칙만으로는 애매한 케이스(예: “결제 관련 문의”, “계약 변경 요청”, “증빙 요청”)는 LLM에게 “분류/요약/필드 추출”만 시킵니다. 이때도 최종 실행(라벨 적용, 드라이브 이동, 공유)은 규칙 엔진이 수행하고, LLM은 결정 보조 역할에 머물게 해야 운영 리스크가 낮습니다.
계층 C: 안전장치(Quarantine + 승인)
신뢰 점수가 낮거나(모델의 분류 확신이 낮음), 민감 키워드(주민번호, 계좌번호, 의료정보 등)가 감지되거나, 외부 발신 + 링크/실행파일이 포함된 경우는 격리 폴더로 보내고 사람이 승인하는 흐름을 둡니다.
💡 인공지능 인사이드 팁: “AI가 라벨을 직접 붙이는 구조”보다 “AI는 분류 결과(JSON)만 반환하고, 라벨/이동은 코드가 수행”하는 구조가 감사(감사로그/재현성)와 오탐 복구에 압도적으로 유리합니다.
2) 구현 옵션 3가지: Apps Script vs Make/Zapier vs 자체 서버(Cloud Run)
구글워크스페이스에서 에이전트를 연동하는 방식은 크게 3개로 나뉩니다. 팀의 보안 요구와 운영 여건에 따라 선택이 달라집니다.
| 옵션 | 장점 | 단점 | 추천 팀 | 대략 비용(2026 기준 관행) |
|---|---|---|---|---|
| Google Apps Script(GAS) | 구현 속도 빠름, Workspace와 결합 쉬움, 간단한 트리거 | 실행 시간/쿼터 제약, 대규모 처리·큐잉에 약함 | 소규모~중간 규모, “먼저 돌아가게”가 목표 | GAS 자체는 무료 범위 가능 + LLM API 사용량 |
| Make/Zapier 등 iPaaS | 비개발자도 구성, 커넥터 풍부, 운영 UI 편함 | 민감 데이터 외부 전송 이슈, 복잡 로직 한계, 비용 증가 | 프로토타입/마케팅·운영팀 자동화 | 월 구독(작업량 기반) + LLM API |
| Cloud Run/Functions + Pub/Sub | 확장성/격리/감사/재시도/큐 처리 최적, 보안 제어 용이 | 구축 난이도 높음, DevOps 필요 | 중견~엔터프라이즈, SLA/감사 필수 | 실행/트래픽 기반 + LLM API + 로깅 |
이 글에서는 “가장 빠르게 실무에 붙는 조합”으로 Apps Script + Gmail API/Drive API + LLM API 기준의 구축 절차를 설명하고, 확장 시 Cloud Run으로 옮기는 경로까지 제시합니다.
3) 목표 정의: “자동분류”의 범위를 문서로 고정해야 한다
자동분류는 기술보다 “정책”이 먼저입니다. 실제 운영에서 가장 많이 터지는 문제는 코드 버그가 아니라 분류 기준의 흔들림입니다. 다음 5가지를 먼저 문서로 고정하는 것이 필수입니다.
- 분류 카테고리: 예) 견적/계약/세금/결제/지원/채용/스팸/기타
- 라벨 정책: 지메일 라벨명, 중복 라벨 허용 여부, 우선순위(결제 > 계약 > 견적 등)
- 드라이브 저장 정책: 폴더 구조(연도/거래처/문서유형), 파일명 규칙, 중복 처리(해시/타임스탬프)
- 공유·권한: 저장 폴더의 소유자(개인 vs 공유드라이브), 열람자 그룹, 외부 공유 금지 여부
- 예외 처리: 신뢰도 낮음, 민감정보 포함, 외부 링크 포함, 실행파일 포함 시 격리/승인
💡 인공지능 인사이드 팁: 분류 정책을 “프롬프트로만” 관리하면 팀이 커질수록 분쟁이 납니다. 카테고리 정의와 예시(긍정/부정 샘플)를 스프레드시트나 YAML로 버전관리하고, 프롬프트는 그 정의를 참조하는 방식이 유지보수에 유리합니다.
4) 아키텍처 설계: 지메일 → 분류 → 드라이브 저장 → 라벨/알림
권장 워크플로우는 다음과 같습니다.
- 지메일에서 신규 메일 탐지(시간 기반 트리거 또는 Gmail push notification)
- 1차 규칙(발신자/제목/수신주소/첨부 확장자)으로 즉시 분류 가능한지 판단
- 애매하면 LLM 호출: 메일 본문/제목/첨부파일 텍스트(가능한 경우)를 입력으로 분류 JSON 생성
- 신뢰도/민감도 체크 후 실행:
- 지메일 라벨 적용/이동(보관처리 등)
- 첨부파일을 드라이브 폴더에 저장
- 스프레드시트(또는 DB)에 처리 로그 기록
- 필요 시 Chat/메일로 담당자 알림
- 오분류/예외는 Quarantine 라벨+폴더로 보내고 검토 큐에 쌓기
🔗 Gmail Push Notifications 공식 가이드
5) Apps Script로 구현하기: 최소 기능 MVP 절차(실무용)
아래는 “일단 돌아가는” MVP 구현 순서입니다. 이후 단계에서 보안과 확장성을 강화합니다.
5-1. 준비물
- Google Workspace 계정(가능하면 테스트용 OU 또는 테스트 계정)
- Google Drive 내 공유드라이브(권장) 또는 팀 폴더
- LLM API 키(OpenAI, Google, Azure OpenAI 중 택1)
- 분류 정책 시트(카테고리/폴더/라벨 매핑표)
5-2. 라벨/폴더/매핑 테이블 만들기
먼저 지메일 라벨과 드라이브 폴더를 “사람이 읽을 수 있는 규칙”으로 고정합니다. 예시는 아래와 같습니다.
| 카테고리 | 지메일 라벨 | 드라이브 저장 경로(예시) | 담당자 알림 | 격리 조건(예시) |
|---|---|---|---|---|
| 세금계산서 | ops/tax | /SharedDrive/Accounting/Tax/2026/ | 회계팀 | 계좌번호·주민번호 감지 시 격리 |
| 계약 | biz/contract | /SharedDrive/Legal/Contracts/2026/ | 법무/사업 | 외부 링크 포함 + 첨부 없음이면 격리 |
| 고객지원 | cs/ticket | /SharedDrive/CS/Tickets/2026/ | CS팀 | 욕설/위협 키워드 시 우선 알림 |
| 기타(미분류) | triage/review | /SharedDrive/Triage/Review/ | 오너(1명) | 기본 격리함 |
5-3. 트리거: “신규 메일 처리”를 안전하게 시작하기
Apps Script에서는 보통 시간 기반 트리거(예: 5분마다)를 먼저 추천합니다. Gmail push는 실시간성이 좋지만, 초기에는 인증/만료/재구독 이슈가 있어 운영 난이도가 올라갑니다.
- 시간 기반 트리거로 최근 N분 메일만 조회
- 중복 처리 방지: messageId를 PropertiesService 또는 시트에 기록
- 처리 실패 시 재시도: “실패 큐” 시트에 쌓고 별도 트리거로 재처리
5-4. 1차 규칙 엔진(LLM 호출 줄이기)
비용과 안정성을 위해 LLM 호출은 최소화합니다. 예를 들어 다음 조건은 규칙으로 바로 처리합니다.
- from: @cardcompany.com AND has:attachment → “결제/명세”
- subject contains “세금계산서” OR “invoice” → “세금계산서”
- to: invoices@yourdomain → “회계”
- 첨부가 .exe/.js/.scr 등 실행 가능 파일 → 즉시 격리
5-5. LLM(에이전트) 호출 설계: 입력은 최소, 출력은 구조화(JSON)
최신 공식 기술 문서와 실무 사례를 종합하면, 메일 자동분류에서 가장 중요한 것은 “구조화된 출력”입니다. 자유서술형 답을 받으면 후처리가 흔들리고, 오탐 복구가 어려워집니다. 따라서 아래처럼 JSON 스키마를 강제합니다.
권장 출력 스키마(예시)
- category: string (예: tax, contract, cs, quote, payment, hr, spam, other)
- confidence: number (0~1)
- drive_folder_key: string (매핑표 키)
- summary_ko: string (2~3문장)
- extracted_fields: object (예: 회사명, 금액, 날짜, 문서번호)
- risk_flags: array (예: pii_suspected, external_link, executable_attachment)
실무에서는 “에이전트”라는 이름을 쓰더라도, 이 단계는 사실상 “분류기+추출기”로 제한하는 편이 낫습니다. 실행(라벨 적용, 파일 이동, 공유)은 다음 단계에서 코드가 담당합니다.
5-6. 드라이브 저장: 첨부파일을 폴더 규칙대로 저장
핵심은 세 가지입니다.
- 파일명 표준화: YYYYMMDD_거래처_문서유형_원본파일명
- 중복 방지: messageId+attachmentId로 키 생성 또는 파일 해시(가능 시)
- 권한 일관성: 개인 내 드라이브가 아니라 공유드라이브 사용(퇴사/권한변경 대응)
5-7. 지메일 라벨링 및 후속 액션
라벨 적용 후에는 운영팀이 “메일함을 다시 열어도” 업무가 이어지도록 다음을 함께 저장하는 것이 좋습니다.
- 처리 로그(스프레드시트): messageId, 분류, confidence, 저장 경로, 처리 시간
- 검토 링크: 해당 지메일 스레드 URL, 드라이브 파일 URL
- 담당자 알림: Google Chat webhook 또는 이메일
6) “오분류”가 터졌을 때를 대비한 운영 설계(현업에서 제일 중요)
자동분류의 성패는 정확도 자체보다 오분류가 발생해도 피해를 제한하고 빠르게 복구할 수 있는가에 달려 있습니다.
6-1. Quarantine 라벨/폴더는 필수
- confidence가 임계값(예: 0.75) 미만이면 자동 실행 금지
- 민감 키워드 탐지 시 무조건 격리(정규식+룰 기반)
- 외부 발신 + 링크 포함 + “결제/보안” 키워드 조합은 피싱 가능성으로 격리
6-2. 감사 로그/재현성: “왜 이렇게 분류했는지” 남겨야 한다
다음 항목은 최소로 로그에 남기는 것이 좋습니다.
- 사용한 분류 정책 버전
- 프롬프트 템플릿 버전(또는 해시)
- 모델/엔드포인트명, temperature 등 주요 파라미터
- LLM 응답 원문(민감정보 마스킹 후) 또는 JSON 결과
- 최종 실행 액션(라벨, 폴더, 파일ID)
6-3. 개인정보/기밀 문서 처리: 최소 권한과 데이터 최소화를 적용
최근 공개된 기업 보안 가이드라인들을 살펴보면, 메일 자동화에서 가장 흔한 사고는 “필요 이상으로 메일 본문 전체를 외부 API로 보내는” 경우입니다. 권장 방식은 다음과 같습니다.
- LLM에는 제목+요약된 본문(앞 N자)만 전달하고, 첨부는 가능하면 텍스트 추출 후 최소 범위만 전달
- 사내 정책상 외부 전송이 어려우면: 모델을 사내/전용 테넌트로(예: Azure OpenAI, 또는 Google Cloud 내 격리) 검토
- Drive 저장 폴더의 권한은 그룹 기반으로 고정(개인 공유 금지)
🔗 Google Cloud Security 공식 페이지
7) 에이전트 품질을 높이는 프롬프트/룰 설계(분류 정확도보다 “일관성”)
메일 자동분류는 창의성이 필요하지 않습니다. 중요한 것은 “같은 입력이면 같은 출력”이 가능한 일관성입니다. 이를 위해 다음 전략이 자주 쓰입니다.
- 카테고리 수를 처음부터 너무 늘리지 않기(7~12개 선)
- 카테고리별 대표 예시 3~5개를 프롬프트에 포함(단, 개인정보 제거)
- 분류 근거를 길게 쓰게 하지 말고, risk_flags와 extracted_fields로만 판단 근거를 남기기
- ‘기타(other)’를 적극 사용하고 검토 큐로 보내기(과잉 자동화를 막는 장치)
8) 성능/비용 현실 계산: “LLM 호출 수”가 비용의 전부다
현업에서는 “한 달에 메일이 몇 통 오고, 그중 몇 %가 LLM을 타는지”만 계산해도 예산이 잡힙니다. 아래는 실무에서 바로 쓰는 비교 프레임입니다.
| 항목 | 기존(수동) | 규칙만 자동화 | 규칙+에이전트(권장) |
|---|---|---|---|
| 분류 처리시간(메일 1통) | 1~3분(사람 편차 큼) | 5~15초 | 10~40초(LLM 호출 포함) |
| 정확도/일관성 | 담당자별 편차 | 규칙 범위에서는 매우 높음 | 애매한 케이스까지 커버하되, 격리/승인으로 안전성 확보 |
| 운영 리스크 | 누락/지연 | 규칙 누락 시 미분류 | 오분류 가능성 존재 → Quarantine/로그로 통제 |
| 비용 구조 | 인건비(반복 업무) | 거의 0 + 유지보수 | LLM API 사용량 + 유지보수(정책/로그/보안) |
9) 확장 설계: Cloud Run으로 옮길 타이밍과 체크리스트
Apps Script MVP가 잘 돌아가도, 아래 조건 중 2개 이상에 해당하면 Cloud Run/Functions로 이전을 고려하는 것이 일반적입니다.
- 메일 처리량 증가로 트리거 지연이 잦다
- 재시도/큐/부분 실패 처리가 복잡해졌다
- 조직 보안팀이 키 관리(KMS), VPC, 전용 네트워크 경계를 요구한다
- 감사/컴플라이언스(로그 보관, 접근통제, 승인 플로우)가 강화됐다
Cloud Run 기반 권장 구성은 다음입니다: Gmail push → Pub/Sub → Cloud Run(분류 서비스) → Drive 저장 → Firestore/BigQuery 로그 → Chat 알림. 이 구조는 재처리, 확장, 비용 최적화에 유리합니다.
10) 실무 체크리스트: 배포 전 30분 점검
- 권한 최소화: 스크립트/서비스 계정이 필요한 스코프만 갖는가
- 민감정보 대응: 격리 조건이 동작하는가(테스트 메일로 검증)
- 중복 처리 방지: messageId 기반 idempotency가 있는가
- 폴더/파일명 규칙: 사람이 봐도 찾을 수 있는가
- 오분류 복구: 라벨 되돌리기, 드라이브 이동 되돌리기 절차가 문서화되어 있는가
- 로그: 누가/언제/무엇을/왜 처리했는지 남는가
- 비용: LLM 호출 비율(%)을 추적하는가
