Apps Script 무료 한도: 메일 40건이 수신자 120명을 쓰는 계산

주문이 하루 40건 들어오고 고객 한 명과 담당자 두 명에게 매번 확인 메일을 보낸다고 가정하겠습니다. 가상 계산 예시이며 고객 사용량이나 납품 결과가 아닙니다.

40 × 3 = 120의 수신자 사용량을 계획합니다. 같은 담당자에게 반복 발송해도 하루 고유 주소 두 개로 계산하지 않습니다.

이는 필요한 예산입니다. 소비자 계정의 하루 100명 한도로는 계획 전체를 같은 일일 한도 구간에 처리할 수 없습니다.

담당자 메일을 묶으면 무엇이 달라지나

고객 확인은 건마다 남기되 담당자 보고는 하루 한 번 요약하면 어떨까요? 고객에게 40번, 담당자 두 명에게 요약 한 번씩 보내므로 계획 사용량은 42입니다.

가상 흐름	계산	계획 수신자 사용량
주문마다 고객·담당자 발송	40 × 3	120
고객 확인 + 담당자 일일 요약	40 + 2	42

담당자 알림을 늦춰도 되는 업무라야 두 번째 방식을 쓸 수 있습니다. 긴급 승인이나 출고처럼 즉시 알아야 하는 업무까지 묶으면 더 큰 문제가 생깁니다.

42는 재시도와 다른 자동화의 발송을 넣기 전의 계획입니다. 참조·숨은참조도 포함해 각 발송의 수신자 사용량을 계산합니다.

현재 한도에서 계획이 걸리는 지점

수치는 2026년 10월 14일 Google 공식 한도 문서에서 확인했습니다. 일반 Apps ScriptApps Script 앱스 스크립트 구글 시트·메일·드라이브 일을 자동으로 처리하게 하는 구글의 무료 도구.눌러서 용어 설명서 보기 → 기준이며 계정 상태와 연결 서비스에는 추가 제한이 있습니다.

항목	소비자 계정	Google WorkspaceWorkspace 워크스페이스 회사나 학원이 월 요금을 내고 쓰는 구글 업무용 계정 서비스.눌러서 용어 설명서 보기 →
하루 메일 수신자	100	1,500
한 메시지 수신자	50	50
하루 트리거트리거 trigger 정해 둔 시각이나 일이 생기면 프로그램을 자동으로 실행하는 설정.눌러서 용어 설명서 보기 → 총 실행시간	90분	6시간
한 번의 실행시간	6분	6분

한도는 사용자별입니다. 같은 사용자의 다른 자동화도 고려해야 하며, 일일 한도는 첫 요청 뒤 24시간 기준으로 재설정됩니다.

자정이 됐다는 이유로 다시 100명을 보낼 수 있다고 가정하지 마세요. 한도는 변경될 수 있으므로 운영 전 공식 문서와 실제 계정 상태를 다시 확인합니다.

발송 없이 남은 수신자 한도 확인하기

Apps Script 편집기에서 다음 함수를 실행하면 발송 없이 현재 남은 한도와 가상 계획값을 로그로그 log 프로그램이 언제 무엇을 했는지 차례로 남긴 기록.눌러서 용어 설명서 보기 →에 남깁니다. 이 글에서는 실제 Google 계정에서의 실행·발송을 검증했다고 주장하지 않습니다.

function inspectMailBudget() {
  const plannedRecipients = 40 + 2;
  console.log({ plannedRecipients, remaining: MailApp.getRemainingDailyQuota() });
}

MailApp 공식 설명의 반환값은 현재 실행에서 확인한 남은 수신자 수입니다. 다른 실행이 발송할 수 있으므로 예약이나 발송 성공 보장으로 쓰면 안 됩니다.

계획보다 여유가 있어도 발송에는 별도 오류 처리가 필요합니다. 조회값, 발송 시도, 완료 여부를 구분해 기록해야 차이를 설명할 수 있습니다.

하루 합계가 작아도 한 번의 실행은 실패한다

하루 열 번, 매번 7분이 필요하다고 가정하면 합계는 70분입니다. 트리거 일일 제한보다 작아도 한 번의 6분 제한을 먼저 넘습니다.

나눠 실행하려면 마지막 처리 항목을 저장해야 합니다. 처음부터 다시 실행하면 앞에서 보낸 확인 메일도 다시 보낼 수 있습니다.

분할 크기는 실제 실행 로그로 정합니다. 같은 행 수라도 첨부파일과 외부 응답시간이 다르므로, 여기의 7분은 측정 결과가 아닌 설명용 가정입니다.

중단 뒤에는 전체 재실행보다 결과 구분이 먼저

요청 ID, 시도 시각, 처리 단계, 완료 수와 오류를 기록합니다. 메일 주소나 본문을 모두 로그에 복제할 필요는 없습니다.

아래는 가상 실행 기록입니다. 결과가 불확실한 한 건은 아직 보내지 않은 대기 27건과 다릅니다.

{"run_id":"example-001","completed":12,"uncertain":1,"pending":27,"status":"paused"}

상태	복구 작업
완료 확인	재발송 대상에서 제외
결과 불확실	확인 가능한 발송 기록과 대조; 확인 수단이 없으면 불확실 상태 유지 후 담당자가 재발송 결정
대기	한도 확인 뒤 이어서 처리

발송과 완료 기록 저장은 원자적 작업이 아닐 수 있습니다. 잠금만으로 중간 장애나 중복 발송이 사라지지는 않습니다.

MailApp에는 발송 이력을 조회하는 메서드가 없습니다. 여기의 완료는 발송 호출 성공을 기록한 상태이지 수신자 도착 확인이 아닙니다.

입력을 재전송해도 요청 ID는 유지합니다. 새 ID를 만들면 이전 시도와 연결하기 어렵습니다.

구독을 바꾸기 전에 정할 세 가지

• 담당자 알림을 묶어도 업무가 유지되면 요약 발송을 검토합니다.
• 기다려도 되는 작업은 대기 상태와 다음 처리 시점을 보여 줍니다.
• 처리 기한을 지킬 수 없으면 계정 한도와 별도 시스템을 함께 검토합니다.

계산표에는 다른 스크립트의 발송, 실패 재시도, 월말 집중 작업도 추가합니다. 하루 평균만 보면 특정 날의 한도 초과를 놓칠 수 있습니다.

한도를 확인하는 주체와 실패를 처리할 담당자도 정해야 합니다. 사용자를 바꾸거나 소유권을 넘긴 뒤에는 기존 계정의 사용량 가정을 그대로 가져가지 않습니다.

무료 운영 여부는 도구 이름으로 정해지지 않습니다. 계산표와 실행 로그를 들고 한 개 업무 흐름의 구현 범위를 정하면 즉시 처리와 대기의 경계를 먼저 명확히 할 수 있습니다.