지메일·시트 자동견적 워크플로우 구축

지메일 문의 메일을 읽고 → 견적 정보를 추출해 시트에 적재 → 자동으로 견적서 초안을 회신까지. 구글워크스페이스 AI와 Apps Script로 “반복 견적 업무”를 엔드투엔드 자동화하는 방법을 정리했습니다.

매일 견적 문의가 쏟아지면, 업무의 본질은 ‘가격 설계’가 아니라 ‘복붙과 확인’으로 바뀌기 쉽습니다. 인공지능 인사이트 에디토리얼 팀의 분석 결과, 2026년 기준 실무에서 가장 ROI가 빠르게 나오는 AI 자동화는 “이메일 기반 반복 프로세스(접수→추출→정리→회신)”입니다. 특히 구글워크스페이스를 쓰는 조직이라면 지메일·구글시트·구글드라이브·Apps Script 조합만으로도 꽤 높은 수준의 자동화를 구축할 수 있습니다.

• 오늘의 AI 기술 인사이트 핵심 포인트 3가지: 지메일 견적 문의를 “구조화 데이터”로 바꾸는 설계가 성패를 좌우한다
• 오늘의 AI 기술 인사이트 핵심 포인트 3가지: Apps Script는 오케스트레이션(트리거/권한/감사로그)에 강하고, LLM은 추출/요약/초안에 강하다
• 오늘의 AI 기술 인사이트 핵심 포인트 3가지: 자동 회신은 “검증 게이트(룰+휴먼 승인)”를 넣어야 비용·리스크를 동시에 낮춘다

가상 사례로 시작해보겠습니다. 매일 엑셀 반복 작업에 시달리던 실무자 A씨는 지메일로 들어오는 “견적 요청”을 읽고, 고객명/회사/요청 수량/납기/특이사항을 시트에 옮긴 뒤, 이전 견적 템플릿을 복사해 가격을 맞추고 회신하는 일을 하루 2~3시간씩 반복했습니다. A씨가 진짜로 집중해야 할 일(마진 검토, 공급가 변동 반영, 고객 세그먼트별 정책)은 늘 뒤로 밀렸습니다.

이 글은 A씨 같은 실무자가 “메일 접수부터 시트 적재, 견적 초안 생성, 회신(또는 승인 후 발송)”까지 이어지는 자동견적 워크플로우를 구글워크스페이스 AI와 Apps Script로 구현하는 실전 설계를 제공합니다. 단순 예제가 아니라, 운영에서 터지는 문제(중복 처리, 오탐 추출, 권한/감사, 비용 통제, 개인정보 처리)를 전제로 설명합니다.

1) 전체 아키텍처: “지메일 → 추출 → 시트 적재 → 견적 생성 → 회신”을 분리하라

자동견적 워크플로우는 한 번에 “메일 읽고 답장 보내기”로 뭉쳐 만들면 빠르게 만들 수 있지만, 운영 단계에서 디버깅이 매우 어려워집니다. 최신 공식 기술 문서와 현업 패턴을 종합하면, 안정적인 자동화는 다음 5단을 분리하는 것이 좋습니다.

1. 수집(ingest): 지메일에서 특정 조건(라벨/검색쿼리/보낸사람/제목 패턴)으로 메일을 가져오기
2. 정규화(normalize): 본문/첨부/서명/스레드 히스토리 제거, 텍스트 길이 제한
3. 추출(extract): LLM 또는 룰 기반으로 견적 필드를 구조화(JSON)하기
4. 저장(store): 구글시트에 적재 + 중복 방지 키 생성 + 감사 로그 남기기
5. 행동(act): 견적 초안 생성(문장/표/템플릿) + 자동 발송/승인 후 발송

💡 인공지능 인사이드 팁: “추출(extract)”과 “초안 작성(draft)”을 같은 프롬프트/같은 호출로 합치면, 모델이 필드를 꾸며내는 순간(환각) 검증이 거의 불가능해집니다. 먼저 JSON 추출만 하고, 그 JSON을 다시 입력으로 넣어 초안을 생성하는 2단 호출이 운영 안정성이 훨씬 좋습니다.

2) 어떤 기능을 ‘AI’로, 어떤 기능을 ‘Apps Script’로? 역할 분담이 핵심

구글워크스페이스 AI(예: Gemini 계열) 또는 외부 LLM(OpenAI 등)을 붙일 때, 모든 걸 AI에게 맡기면 간단해 보이지만 비용/재현성/감사(누가 어떤 근거로 발송했는지)에서 문제가 생깁니다. 반대로 룰만으로 처리하면 예외 케이스 때문에 사람이 계속 개입해야 합니다. 실무에서 가장 효율적인 분담은 아래와 같습니다.

업무 단계	권장 담당	이유	실패 시 리스크
메일 필터링/라벨링/중복 방지	Apps Script + Gmail 라벨/쿼리	결정적(Deterministic)이어야 함, 재실행 가능	중복 견적/중복 발송
요청 정보 추출(회사/품목/수량/납기)	LLM(구글/외부) + JSON 스키마	비정형 메일 텍스트의 강점	오추출로 잘못된 견적
가격 계산(단가표/할인 규칙/마진)	구글시트 수식 또는 Apps Script 룰	감사/재현/정책 준수	마진 붕괴, 정책 위반
견적서 문장/메일 초안 작성	LLM	톤/문장/요약 최적화	부정확한 표현, 과도한 약속
최종 발송	초기엔 ‘승인 후 발송’ 권장	리스크 통제, 조직 학습	잘못된 고객/금액 발송

즉, AI는 “사람이 읽고 이해하던 부분(메일 해석, 초안 작성)”을 맡기고, Apps Script/시트는 “정책과 규칙(가격, 검증, 기록)”을 맡기는 쪽이 운영 난이도가 낮습니다.

3) 준비물 체크리스트: 권한, 시트 스키마, 라벨 전략

구현에 앞서 다음을 먼저 정해야 합니다. 이 단계가 빈약하면 자동화가 돌아가도 결과물이 쌓이지 않거나, 나중에 정리 비용이 폭증합니다.

3-1) 지메일 라벨/쿼리 설계

권장 패턴은 “인박스 전체를 읽지 않고”, 특정 라벨만 처리하는 방식입니다.

• 라벨 예: QUOTE/NEW, QUOTE/PROCESSED, QUOTE/NEEDS_REVIEW, QUOTE/FAILED
• 필터 예: 제목에 “견적”, “quotation”, “quote” 포함 또는 특정 문의 폼 발신 주소

3-2) 구글시트 스키마(컬럼) 설계

시트는 “원문 보관 + 추출 결과 + 계산 결과 + 발송 상태”를 한 줄에 담는 형태가 운영에 유리합니다.

컬럼	예시	설명
request_id	2026-03-02-7f3a	중복 방지 키(스레드ID+메시지ID 해시 등)
gmail_thread_id	18c9f0…	추적/회신 스레드 연결
from_email	buyer@company.com	회신 주소
company / name	ABC상사 / 홍길동	추출 필드
items_json	[{sku:”A1″,qty:10},…]	품목/수량 구조화 데이터
due_date	2026-03-15	납기/요청일
price_table_version	v2026.03	단가표 버전(감사/재현)
quoted_total	1,350,000	계산 결과
draft_email	(긴 텍스트)	LLM이 작성한 회신 초안
status	NEEDS_REVIEW / SENT	발송 상태

3-3) 개인정보/민감정보 처리 원칙

최근 발표된 가이드라인과 기업 컴플라이언스 관행을 보면, 견적 문의에는 개인 연락처/주소/계약 조건 등 민감한 정보가 섞이기 쉽습니다. 따라서 LLM 호출 전 “최소한의 데이터만 전달”하는 것이 기본입니다. 예: 전화번호, 주민번호 형태 패턴 마스킹, 불필요한 스레드 히스토리 제거, 첨부파일은 해시만 저장 후 별도 승인 시에만 분석.

🔗 Google Apps Script 공식 문서 바로가기

🔗 Gmail API 공식 문서 바로가기

🧾 팀즈·아웃룩 업무흐름 자동화

4) 구현 1단계: 지메일에서 “견적 요청”만 안전하게 수집하기

Apps Script에서 GmailApp을 쓰면 빠르게 만들 수 있지만, 대규모/정교한 제어가 필요하면 Gmail API(Advanced Google Services)도 고려합니다. 이 글에서는 가장 접근성이 좋은 GmailApp 기반 흐름을 먼저 제시합니다.

4-1) 트리거 전략: 시간 기반 배치가 운영에 유리

메일 도착 즉시 처리(이벤트 기반)를 흉내 내는 방식도 가능하지만, 운영에서는 “5분/10분마다 배치”가 안정적입니다. 이유는 다음과 같습니다.

• 일시적인 LLM API 오류 시 재시도/롤백이 쉬움
• 동시성 이슈(중복 실행) 통제가 쉬움
• 감사 로그를 배치 단위로 남기기 쉬움

4-2) Gmail 검색 쿼리 예시

예: QUOTE/NEW 라벨이 있고, 읽지 않은 메일만 대상으로 한다면:

label:QUOTE/NEW is:unread newer_than:7d

메일을 가져오면 다음을 즉시 수행하는 것이 좋습니다.

• 처리 시작 시점에 임시 라벨(예: QUOTE/IN_PROGRESS) 부여
• 처리 성공 시 QUOTE/PROCESSED로 이동
• 추출 불확실/필드 누락 시 QUOTE/NEEDS_REVIEW
• 예외 발생 시 QUOTE/FAILED + 오류 메시지 기록

💡 인공지능 인사이드 팁: 중복 방지를 “시트에 있는 request_id 검사”만으로 해결하면, 트리거가 겹칠 때(동시에 2번 실행) 레이스 컨디션이 납니다. Apps Script의 LockService로 락을 잡고, 처리 단위를 ‘스레드ID+메시지ID’로 고정하는 방식이 재발을 크게 줄입니다.

5) 구현 2단계: LLM으로 견적 필드를 JSON으로 추출(환각 방지 설계)

핵심은 “자유 서술”이 아니라 “스키마 강제”입니다. 최신 LLM 활용 패턴을 살펴보면, 운영용 추출은 다음 3가지를 지키는 편이 안전합니다.

• JSON 스키마(또는 엄격한 키 목록) 강제
• 불확실하면 null/unknown을 허용(억지로 채우지 않기)
• 근거 텍스트(원문 발췌) 함께 반환하여 검증 가능하게 하기

예시 스키마(개념):

• company, contact_name, contact_email
• items: [{description, sku, qty, unit, options}]
• delivery_date, destination, notes
• confidence: 0~1
• evidence: {field: “원문 일부”}

LLM 호출은 2가지 루트 중 하나를 선택합니다.

• 루트 A: 구글워크스페이스 내 AI(조직 정책상 외부 반출이 어려운 경우)
• 루트 B: 외부 LLM API(OpenAI 등, 비용/성능/기능 유연성이 필요한 경우)

🔗 OpenAI API 공식 문서 바로가기

🔗 Google AI for Developers (Gemini) 공식 문서 바로가기

중요한 점은 “어떤 모델을 쓰느냐”보다 “어떤 검증 게이트를 두느냐”입니다. 예를 들어 confidence가 0.75 미만이거나, qty가 없거나, 품목이 3개 이상인데 sku 매칭이 50% 미만이면 자동 발송을 막고 NEEDS_REVIEW로 보냅니다.

6) 구현 3단계: 구글시트에서 가격 계산(정책/재현성 중심)

가격 계산은 AI가 잘하는 영역이 아닙니다. 단가표(원가/공급가), 고객 등급별 할인, 최소 마진, 부가세/배송비, 유효기간 같은 룰은 “감사 가능하고 재현 가능”해야 합니다.

권장 구현:

• 단가표 시트를 별도 탭으로 두고, sku 기준 VLOOKUP/XLOOKUP 또는 Apps Script로 매칭
• 할인 정책은 “정책 테이블”로 분리(고객 등급, 수량 구간, 기간)
• 견적 결과에 price_table_version과 policy_version을 반드시 기록

6-1) AI 도입 전/후 업무 효율 비교(현실적인 기대치)

인공지능 인사이트 에디토리얼 팀이 다양한 자동화 프로젝트에서 관찰한 평균적인 변화는 아래와 같습니다(조직 성숙도에 따라 편차가 큼).

업무 단계	기존(수동)	AI+Apps Script 도입 후	비고
메일 읽고 핵심정보 정리	3~8분/건	10~40초/건(검토 포함)	비정형 문의일수록 개선 폭 큼
시트 입력/정리	2~5분/건	0분(자동 적재)	스키마가 고정일 때 효과 최대
견적 초안 작성	4~10분/건	30~90초/건	톤/문장 표준화 효과
오류/누락으로 인한 재문의 대응	빈번	감소(근거/evidence 기반)	추출 품질과 검증 게이트에 좌우

7) 구현 4단계: 견적 회신 자동화(초기엔 “승인 후 발송”이 정답)

자동 회신은 가장 위험한 단계입니다. 금액/납기/조건이 잘못 나가면 신뢰 손상으로 직결됩니다. 따라서 운영 1~2개월은 아래 중 하나를 권장합니다.

• 모드 1: 드래프트만 생성 → 사람이 검토 후 전송
• 모드 2: 조건부 자동 발송 (confidence 높고, 정책 룰 통과, 특정 고객군만)

Apps Script로는 다음이 가능합니다.

• GmailApp.createDraft()로 초안 생성 후 라벨링
• 검토용으로 구글챗/이메일로 내부 알림 전송
• 승인 플래그(status=APPROVED)일 때만 sendEmail

회신 템플릿은 “변수형 문장” + “표준 주의 문구”로 구성하는 편이 안전합니다.

• 예: 유효기간, 납기 확정 조건, 재고 변동 가능성, 세금/배송 조건
• 과도한 확정 표현(“무조건 가능합니다”, “확정 납기”)은 금지 룰로 차단

8) 성능/비용 관점: 구글워크스페이스 AI vs 외부 LLM, 무엇을 선택할까?

2026년 기준, 많은 조직이 “내부 데이터 반출 최소화”와 “비용 예측 가능성” 때문에 워크스페이스 내 AI를 선호합니다. 반면 특정한 추출 품질, 구조화 강제, 도구 호출, 세밀한 모델 선택이 필요하면 외부 LLM API가 유리할 수 있습니다. 아래는 의사결정에 도움이 되는 비교 관점입니다(가격은 플랜/지역/정책에 따라 변동되므로 공식 페이지를 반드시 확인).

비교 항목	구글워크스페이스 AI(조직 내)	외부 LLM API(OpenAI 등)	권장 상황
데이터 거버넌스	조직 정책/관리 콘솔로 통제 용이	별도 계약/보안 설정 필요	내부 규정이 엄격한 기업
기능 유연성	제품 범위 내 기능 중심	모델 선택/응답 형식/고급 기능 유연	정교한 추출/검증 로직 필요
비용 예측	좌석/플랜 기반인 경우 예측 쉬움	토큰 기반으로 변동(통제 가능)	메일량 변동 큰 조직은 모니터링 필수
구현 난이도	워크스페이스 안에서 단순화 가능	API 키/프록시/로깅 등 설계 필요	초기 PoC는 내부, 고도화는 외부 혼합도 가능

9) 운영에서 반드시 터지는 이슈 7가지와 대응 체크리스트

실무에서는 “만들기”보다 “망가지지 않게 운영하기”가 더 어렵습니다. 다음 이슈는 거의 필수로 발생합니다.

9-1) 중복 처리(같은 메일을 여러 번 견적)

• 대응: request_id(스레드ID+메시지ID) 저장, LockService 사용, 처리 후 라벨 이동

9-2) 첨부파일/이미지에만 정보가 있는 문의

• 대응: 초기에는 첨부파일은 “검토 필요”로 라우팅, OCR/문서 파싱은 2단계로 확장

9-3) 모델 환각으로 없는 품목/수량 생성

• 대응: “unknown 허용” + evidence 필드 필수 + sku 매칭 실패 시 자동 발송 금지

9-4) 장문 스레드에서 과거 대화까지 섞여 추출 오류

• 대응: 최신 메시지 본문만 추출, “On … wrote:” 이후 제거, 서명/고지문 제거

9-5) 비용 폭증(메일 폭주/재시도 루프)

• 대응: 일/시간당 처리량 제한, 실패 재시도 횟수 제한, 캐시(같은 본문 해시 재호출 금지)

9-6) 권한 이슈(공유 드라이브/공용메일함/대리발송)

• 대응: 서비스 계정/도메인 위임이 필요한지 검토, 발송 From 정책을 사전에 합의

9-7) 감사/컴플라이언스(누가 어떤 근거로 보냈는지)

• 대응: 원문 해시, 추출 JSON, 정책 버전, 발송자(자동/승인자), 타임스탬프를 시트에 남기기

10) 최소 동작(MVP) 구성 예시: 2일 안에 만드는 현실적인 범위

“완벽한 자동견적”을 목표로 하면 실패합니다. 2일 MVP는 다음 범위가 현실적입니다.

• QUOTE/NEW 라벨 메일만 배치로 읽기
• 본문 텍스트 정리 후 LLM으로 JSON 추출(회사/연락처/품목 설명/수량/납기/메모)
• 시트에 적재 + 단가표 sku 자동 매칭은 ‘가능한 것만’
• 견적 메일 초안을 드래프트로만 생성(자동 발송 금지)
• NEEDS_REVIEW 라벨링/상태값으로 사람이 처리할 큐를 명확히

그 다음 2~4주에 걸쳐 다음을 고도화합니다.

• 첨부파일(OCR/문서 파싱) 단계적 도입
• 고객 등급/할인 정책 테이블화
• 조건부 자동 발송(특정 고객군, 단일 품목, 고신뢰)부터 확장
• 실패/재시도/모니터링(로그 시트, 에러 알림) 강화

🔗 Google Workspace Developers 공식 가이드 바로가기

🔗 Google Workspace Apps Script 샘플(GitHub) 바로가기

🧾 팀즈·아웃룩 업무흐름 자동화

11) 마무리: 자동견적의 본질은 “속도”가 아니라 “신뢰 가능한 반복”

AI를 붙이면 견적 회신 속도는 빨라집니다. 하지만 실무에서 더 큰 가치는 “담당자가 바뀌어도 동일한 품질로 반복되는 프로세스”가 생기는 데 있습니다. 인공지능 인사이트 에디토리얼 팀의 결론은 간단합니다. LLM은 텍스트를 구조화하고 초안을 만드는 엔진으로, Apps Script와 시트는 정책과 기록을 지키는 뼈대로 두면, 견적 업무는 충분히 자동화 가능하면서도 위험을 관리할 수 있습니다.