지메일 하루 발송 한도 — 앱스 스크립트 할당량과 계정 전송 제한이 갈리는 자리

구글 스프레드시트와 스크립트로 메일을 자동 발송하다 보면 어느 날 갑자기 멈춰요. 그때 대부분 지메일 계정 한도를 검색하는데, 거기서 나온 숫자로는 원인이 안 맞아요.

결론부터 말하면 이래요. 자동화가 멈추는 곳은 계정 한도가 아니라 둘 중 더 낮은 쪽이에요. 그리고 소비자 계정에서는 그게 앱스 스크립트 쪽 일일 수신자 100이에요. 계정 문서에 적힌 500만 보고 있으면 왜 100에서 멈추는지 영영 못 찾아요.

다만 두 숫자를 나란히 놓을 때 단위를 먼저 맞춰야 해요. 100은 수신자 수이고 500은 메일 개수거든요. 이 한 줄이 이 글에서 가장 틀리기 쉬운 자리예요.

아래 숫자는 2026년 8월 14일에 구글 앱스 스크립트 공식 문서의 「Quotas for Google Services」(영문판과 한국어판을 모두 받아 대조), 구글 워크스페이스 관리자 고객센터의 「Google Workspace의 Gmail 전송 한도」, 지메일 고객센터의 「메일 주고받기 한도」 세 편을 직접 받아 확인했어요. 페이지 하단의 최종 업데이트 표기는 갈려 있었어요. 앱스 스크립트 문서 영문판과 워크스페이스 관리자 문서는 2026년 7월 22일 UTC였고, 앱스 스크립트 한국어판은 2026년 4월 23일 UTC였어요.

지메일 하루 발송 한도는 한 숫자가 아니에요

검색창에 넣으면 보통 500이나 2,000이 나와요. 둘 다 실재하는 값이지만, 스크립트로 보내는 메일에는 그 숫자 위에 한 층이 더 얹혀 있어요.

구글은 이 두 층을 다른 문서에서 관리해요. 하나는 개발자 문서의 할당량 표이고, 다른 하나는 고객센터의 전송 한도 안내예요. 그리고 워크스페이스 관리자 문서는 그 사실을 스스로 적어 두었어요.

Google Apps Script를 사용하는 경우 할당량이 다를 수 있습니다.

이 한 줄이 두 문서를 나란히 놓아야 하는 근거예요. 계정 한도 페이지가 자기 페이지만 보면 안 된다고 안내하고 있는 셈이거든요.

계정 한도만 보고 있으면 원인을 못 찾아요

증상을 먼저 정리해 볼게요. 스크립트가 예외를 뱉으며 멈췄는데, 지메일 웹에서 손으로 메일을 보내면 잘 나가요. 계정이 정지된 것도 아니고 오류 메시지도 계정 한도 이야기가 아니에요.

이 상태를 계정 한도로 설명하려고 하면 계속 어긋나요. 앱스 스크립트 문서가 이렇게 적거든요.

일부 기능에는 연결된 Google 제품의 추가 할당량이 있습니다. 제품의 Apps Script 서비스를 사용하면 연결된 모든 할당량 예비에 포함됩니다. 연결된 할당량에 도달하면 기능을 사용할 수 없게 됩니다.

즉 스크립트 발송은 두 개의 통장에서 동시에 빠져나가요. 앱스 스크립트 할당량과 지메일 쪽 한도를 함께 쓰고, 그중 하나만 바닥나도 기능이 멈춰요.

이 사이트의 구글 시트 CRM 자동화 7단계를 정리한 글에도 함정 항목으로 지메일 일일 발송 한도가 적혀 있어요. 거기 적힌 500과 2,000은 계정 층위의 값이라 그 글의 맥락에서는 맞는 숫자예요. 다만 스크립트로 짠 자동화라면 그 위에 얹힌 층을 하나 더 봐야 한다는 게 이 글의 자리예요.

앱스 스크립트 할당량과 계정 전송 한도를 한 표에 놓으면

두 층을 한 표에 놓아야 어디서 먼저 걸리는지가 보여요. 먼저 소비자 계정(gmail.com 주소)이에요.

출처: 구글 앱스 스크립트 「Quotas for Google Services」와 지메일 고객센터 「메일 주고받기 한도」, 2026년 8월 14일 조회

워크스페이스 계정은 숫자가 늘지만 구조는 같아요.

출처: 구글 앱스 스크립트 「Quotas for Google Services」와 워크스페이스 관리자 고객센터 「Google Workspace의 Gmail 전송 한도」, 2026년 8월 14일 조회

표를 두 층으로 나눠 보면 결론이 한 줄로 정리돼요. 수신자 수 기준으로는 거의 언제나 앱스 스크립트 쪽이 먼저 바닥나요. 계정 쪽 숫자는 손으로 보내는 메일까지 함께 세는 큰 통이라 스크립트 하나로는 잘 안 닿아요.

수신자 수와 메일 통수는 다른 단위예요

이 절이 이 글의 핵심이에요. 두 숫자를 같은 단위로 읽으면 계산이 통째로 어긋나거든요.

앱스 스크립트 문서의 표에서 이 행은 한국어판에 이렇게 적혀 있어요. 왼쪽부터 항목 이름, 소비자 계정 값, 워크스페이스 계정 값이에요.

일일 이메일 수신자 (예: MailApp 사용) | 100* / 일 | 1,500* / 일

수신자예요. 통수가 아니에요. 한 통을 서른 명에게 보내면 하루 몫에서 서른이 빠져요. 100통이 아니라 100명이라고 읽어야 맞아요. 숫자 뒤의 별표는 뒤에서 볼 무료 체험 계정 각주를 가리켜요.

반대로 지메일 고객센터 문서의 문장은 이래요.

한 개의 이메일을 500명이 넘는 수신자에게 전송하거나 하루에 이메일을 500개 넘게 전송하는 경우 이 메시지가 표시됩니다.

여기서는 500이 두 번 나오는데 뜻이 서로 달라요. 앞의 500은 한 통의 수신자 수이고, 뒤의 500은 하루 메일 개수예요. 같은 숫자를 두 단위로 쓰고 있으니 옮겨 적을 때 특히 조심할 자리예요.

한 통에 몰아 보내면 되지 않나요

여기서 자연스럽게 나오는 반문이 있어요. 수신자 기준이면 한 통에 최대한 많이 넣으면 되지 않느냐는 거죠.

두 겹으로 막혀 있어요. 첫째, 앞에서 본 대로 세는 단위가 수신자라 한 통에 몰아 넣어도 총량은 그대로 깎여요. 둘째, 앱스 스크립트 문서의 제한사항 표에 이 항목이 따로 있어요.

메일당 이메일 수신자 수 | 50 / 메시지 | 50 / 메시지

한 통에 넣을 수 있는 수신자가 50명이라, 몰아 보내는 방식은 여기서 먼저 걸려요. 두 칸에 같은 값이 적혀 있으니 워크스페이스로 바꿔도 달라지지 않아요.

워크스페이스 계정은 조건이 붙은 값이 있어요

워크스페이스로 올리면 수신자 한도가 100에서 1,500으로 적혀 있어요. 그런데 그 숫자에는 별표가 붙어 있고, 각주가 조건을 달아요.

무료 체험 계정에는 추가 한도가 적용됩니다. 무료 체험 계정을 유료 구독으로 변환하면 다음 두 조건을 모두 충족하는 경우 계정 한도가 자동으로 늘어납니다. 도메인의 누적 지불 금액이 미화 100달러 (또는 이에 상응하는 금액) 이상임. 지급 기준액 도달 후 60일 이상 경과됨.

즉 결제를 시작한 날에 바로 큰 숫자가 되는 게 아니에요. 누적 결제액과 경과 일수라는 조건 두 개가 함께 붙어요.

그런데 계정 쪽 문서는 같은 사안을 다른 숫자로 적어요. 워크스페이스 관리자 문서의 「유료 계정에서의 한도 확대」 절이에요.

무료 체험 계정을 유료 구독으로 변환하는 경우 도메인에서 누계 미화 100달러(또는 이에 상응하는 금액) 이상이 지불되면 계정의 전송 한도가 자동으로 늘어납니다. Google로부터 도메인을 구매한 경우 이 비용은 도메인 비용에 미화 100달러를 더한 금액입니다. 이 청구 기준액을 충족한 후 계정 전송 한도가 증가하기까지 최대 75일이 걸릴 수 있습니다.

두 자리가 갈려요. 첫째, 기준액이 늘 100달러는 아니에요. 구글에서 도메인을 산 경우에는 도메인 비용에 100달러를 더한 금액이에요. 둘째, 기간이 60일이 아니라 최대 75일이에요. 앞의 각주는 기준액 도달 후 60일 경과를 조건으로 적는데, 계정 쪽 문서는 기준액을 채운 뒤 한도가 올라가기까지 최대 75일이 걸릴 수 있다고 적어요. "100달러 넣고 60일 기다리면 올라간다"로 일정을 잡으면 보름이 더 걸릴 수 있고, 도메인을 구글에서 샀다면 기준액 자체가 어긋나요.

계정 쪽 문서는 무료 체험 계정을 다른 자리에서도 갈라 놔요. 사용자 계정당 일일 전송 제한이 2,000개인데, 이메일 대량 발송의 경우 1,500개이고 무료 체험 계정의 경우 500개로 갈려요. 대량 발송은 문서가 괄호로 "이전 명칭: 다중 전송"이라고 적어 둔 그 기능이에요.

한도를 안 넘었는데 멈추는 경우 — 트리거 실행 시간과 스크립트 실행 시간

메일을 몇 통 못 보냈는데도 실행이 끊긴다면 발송 쪽 숫자가 아니라 시간 쪽 숫자를 봐야 해요. 같은 문서의 다른 두 표에 나뉘어 있어요. 총 트리거 런타임은 현재 할당량 표에 있고, 나머지 네 줄은 현재 제한사항 표에 있어요.

출처: 구글 앱스 스크립트 「Quotas for Google Services」 — 총 트리거 런타임은 현재 할당량 표, 나머지 네 행은 현재 제한사항 표, 2026년 8월 14일 조회

여기서 갈리는 지점이 둘이에요. 스크립트 런타임 6분은 한 번의 실행이 얼마나 오래 도느냐이고, 총 트리거 런타임은 하루 동안 트리거로 돈 시간의 합이에요. 명단이 길어서 한 번에 다 돌리려고 하면 앞쪽에서 끊기고, 잘게 쪼개 자주 돌리면 뒤쪽이 먼저 차요.

문서는 한도에 닿았을 때의 동작도 적어 두었어요. 초과하면 스크립트가 예외를 던지고 실행이 멈추며, 어느 한도를 넘겼는지 또는 어떤 서비스를 너무 많이 호출했는지를 알리는 예외 메시지가 뜬다는 내용이에요. 실행이 조용히 사라지는 상황이 반복된다면 자동화가 조용히 멈추는 이유를 점검 항목으로 정리한 글의 순서를 함께 보면 도움이 돼요.

초기화 시점을 문서마다 다르게 적어요

"내일 되면 풀리나요"라는 질문의 답이 문서마다 달라요. 나란히 놓아 볼게요.

앱스 스크립트 문서는 이렇게 적어요.

할당량은 사용자당이며 첫 번째 요청 후 24시간 후에 재설정됩니다.

워크스페이스 관리자 문서는 이렇게 적고요.

일일 한도는 하루 중 특정 시간대가 아니라 24시간 동안 균등하게 적용됩니다.

두 문장은 같은 말이 아니에요. 앞은 재설정되는 시점을 말하고, 뒤는 한도가 걸리는 방식을 말해요. 그리고 지메일 고객센터 문서는 세 번째 문장을 적어요. 전송 제한 오류가 뜨면 1~24시간 후에 다시 보낼 수 있게 된다는 안내예요.

같은 워크스페이스 문서는 도입부에 한 문장을 더 적어 두었어요. 계정 층위에서 "언제 다시 보낼 수 있나"에 직접 답하는 자리예요.

이러한 한도 중 하나에 도달하면 최대 24시간 동안 새 메일을 보낼 수 없습니다. 하지만 Google Workspace 계정에 계속 액세스하여 이메일을 수신하고 다른 Google 서비스를 사용할 수는 있습니다. 정지 기간이 지나면 전송 한도가 재설정되어 사용자가 다시 메일을 보낼 수 있습니다.

즉 계정 층위에서 막히는 기간은 최대 24시간이고, 그동안에도 메일 수신과 다른 구글 서비스는 되고, 정지 기간이 지나면 전송 한도가 재설정돼요.

네 문장 모두 24라는 숫자를 쓰지만 기준점이 각각 달라요. 자정을 기준으로 초기화된다고 적은 문서는 셋 중 어디에도 없었어요.

계정 한도에 조용히 포함되는 메일이 있어요

내가 스크립트로 보낸 것만 세어지는 게 아니에요. 워크스페이스 관리자 문서가 사용자 한도 계산에 포함되는 메일을 세 가지로 열거해요.

• 사용자의 다른 주소 또는 별칭에서 전송된 메일
• 위임된 사용자가 보낸 메일
• 지메일의 부재중 자동응답으로 보낸 메일

자동화를 돌리는 계정에 부재중 자동응답이 켜져 있으면 그 응답들도 같은 칸을 써요. 반대 방향의 항목도 있어요. 같은 표는 다른 계정으로 자동 전달한 메일 10,000개가 일일 전송 제한에 포함되지 않는다고 적고, 자동 전달 메일 필터는 40개까지라고 적어요.

이 열거를 자동화 관점으로 옮기면 점검 항목이 하나 늘어요. 스크립트를 돌리는 계정이 평소에 사람이 쓰는 계정이라면, 그 사람이 손으로 보낸 메일과 자동응답까지 같은 칸을 나눠 쓰고 있는 셈이거든요. 발송 전용 계정을 따로 두는 구성이 자주 권장되는 이유가 여기에 있어요. 다만 스크립트를 여러 개로 나눠 짜도 앱스 스크립트 할당량은 사용자당이라, 한 사람이 같은 계정에서 돌리는 한 그 통장은 여전히 하나예요.

한 가지 더 있어요. 문서는 조직이 SMTP 릴레이 서비스를 쓰는 경우 다른 전송 한도가 적용된다고 안내해요. 이 글은 그 문서를 열지 않았으니 그쪽 숫자는 다루지 않을게요.

워크스페이스는 밖으로 나가는 메일에 칸이 하나 더 있어요

워크스페이스 계정을 쓰는 경우 수신자 칸이 하나가 아니에요. 관리자 문서의 전송 한도 표가 이렇게 나눠 놓았어요.

출처: 구글 워크스페이스 관리자 고객센터 「Google Workspace의 Gmail 전송 한도」, 2026년 8월 14일 조회

세는 방식도 문서가 직접 설명해 두었어요. 일일 총 수신자는 "이메일 주소(수신자)는 메일이 전송될 때마다 계산됨"이라 같은 사람에게 다섯 번 보내면 다섯으로 세어져요. 반면 일일 고유 수신자는 "각 이메일 주소(각 고유 수신자)는 하루에 한 번만 계산됨"이라 같은 사람에게 다섯 번 보내도 하나예요. 여기서 말하는 외부 수신자는 기본 도메인 밖의 주소이고 도메인 별칭과 대체 도메인까지 포함된다고 적혀 있어요.

그래서 조직 밖으로 나가는 자동 메일이라면 총량보다 외부 수신자 칸이 먼저 찰 수 있어요. 같은 명단이라도 안으로 보내느냐 밖으로 보내느냐에 따라 걸리는 자리가 달라지는 구조예요.

문서는 한도를 넘겼을 때의 상태도 한 줄로 적어요. 사용자가 전송 한도를 초과하면 계정이 정지될 수 있고, 정지된 계정을 다시 활성화하는 절차는 별도 문서로 안내한다는 내용이에요. 이 글에서는 그 별도 문서를 열지 않았으니 절차 자체는 다루지 않을게요.

남은 수신자 수를 직접 세어 볼 수 있어요

문서가 확인 방법을 세 가지 적어 두었어요.

첫째, 남은 이메일 할당량을 함수로 물어볼 수 있어요.

Logger.log(MailApp.getRemainingDailyQuota());

문서는 이 함수가 "하루 동안 보낼 수 있는 남은 이메일 수신자 수"를 확인하는 용도라고 적어요. 통수가 아니라 수신자 수라는 점이 여기서도 그대로예요.

둘째, 앱스 스크립트 대시보드의 실행 목록 페이지에서 각 실행의 상태를 볼 수 있어요. 문서는 완료, 실패, 실행 중 같은 상태가 표시되고, 실행 중 상태로 필터링하면 동시 실행 수를 확인할 수 있다고 안내해요.

셋째, 표준 구글 클라우드 프로젝트를 쓰는 경우에는 구글 클라우드 콘솔에서 서비스별 할당량과 API 사용량을 볼 수 있다고 적혀 있어요.

내 자동화는 어느 숫자에 먼저 걸리나 — 6단계 점검

순서대로 짚으면 대부분 갈려요.

1. 계정 유형부터 확인해요. gmail.com 주소인지, 워크스페이스 계정인지, 워크스페이스 무료 체험 상태인지에 따라 세 갈래로 갈려요.
2. 하루 명단의 수신자 수를 세어요. 통수가 아니라 주소 개수예요. 중복 주소도 보낼 때마다 세어진다고 계정 문서가 적어요.
3. 한 통에 몇 명씩 넣는지 봐요. 50을 넘기면 발송 자체가 안 돼요.
4. 첨부와 본문 크기를 봐요. 본문은 소비자 계정 200KB, 첨부는 전체 25MB예요.
5. 실행 시간을 봐요. 한 번 실행이 6분을 넘기는지, 하루 트리거 합이 90분에 닿는지 둘 다 봐야 해요.
6. 같은 계정에서 도는 다른 스크립트를 세어요. 할당량은 사용자당이라 스크립트를 나눠 짜도 통장은 하나예요.

같은 명단으로 재실행이 반복되면 수신자 수가 두 배로 빠져요. 재실행이 잦다면 같은 데이터를 중복 처리하지 않게 막는 방법을 정리한 글을 함께 보는 편이 좋아요.

이 글에서 확인하지 못한 것

솔직하게 남길게요.

첫째, 실제 계정에서의 실측이에요. 이 글은 문서 세 편의 표와 문장을 옮겨 온 것이지, 특정 계정에서 100번째 수신자에 정확히 멈추는지를 재 보지는 않았어요.

둘째, 함수가 보는 범위예요. 남은 할당량을 알려 주는 함수가 계정 쪽 전송 한도까지 반영하는지는 문서에 적혀 있지 않아요.

셋째, SMTP 릴레이 서비스의 한도예요. 워크스페이스 문서가 별도 문서로 안내하는데 이번에 그 페이지는 열지 않았어요.

넷째, 한국어 번역의 정확도예요. 지메일 고객센터 페이지 하단에는 "이 페이지에는 AI 기술을 사용하여 번역된 콘텐츠가 포함되어 있을 수 있으며, AI 번역에는 오류가 있을 수도 있습니다"라는 안내가 붙어 있어요. 그래서 앱스 스크립트 문서는 영문판과 한국어판을 모두 받아 숫자를 대조했고, 두 판본의 값은 같았어요. 다만 두 판본의 최종 업데이트 표기는 석 달 차이가 나요. 영문판이 2026년 7월 22일, 한국어판이 2026년 4월 23일이에요. 리비전이 다른데도 표의 값이 같았다는 것까지가 이 글이 확인한 전부이고, 왜 같은지는 페이지에서 확인할 방법이 없었어요.

다섯째, 다른 발송 경로예요. 여기서 다룬 것은 앱스 스크립트로 보내는 경우와 지메일 계정 자체의 한도까지예요. 다른 도구를 거쳐 보내는 경우의 숫자는 그 도구의 문서가 따로 정해요.

정리

• 자동 발송이 멈추는 곳은 계정 한도가 아니라 둘 중 더 낮은 쪽이에요. 소비자 계정에서는 앱스 스크립트의 일일 수신자 100이 먼저 걸려요.
• 100은 수신자 수, 500은 메일 개수예요. 단위가 달라서 한 통에 몰아 보내도 총량은 그대로 깎여요.
• 한 통의 수신자는 50명까지예요. 두 계정 유형이 같은 값이라 계정을 바꿔도 달라지지 않아요.
• 워크스페이스는 수신자 한도가 1,500 / 일로 적혀 있지만, 무료 체험에서 올라오는 경우에는 누적 100달러와 60일이라는 조건이 붙어요. 계정 쪽 문서는 같은 사안을 구글에서 산 도메인이면 도메인 비용 + 100달러, 반영까지 최대 75일로 적고요.
• 메일이 한 통도 안 나갔는데 멈춘다면 트리거 총 런타임(하루 90분 또는 6시간)과 스크립트 런타임(실행당 6분)을 보세요.
• 초기화 문장은 문서마다 달라요. 앱스 스크립트는 첫 요청 후 24시간, 워크스페이스는 24시간 동안 균등 적용이에요.
• 별칭·위임·부재중 자동응답으로 나간 메일도 계정 한도에 포함된다고 워크스페이스 문서가 적어요.
• 모든 숫자는 2026년 8월 14일 조회 시점의 값이에요. 구글이 예고 없이 바꿀 수 있다고 스스로 적어 두었어요.

지금 할 수 있는 가장 짧은 확인은 두 가지예요. 오늘 보낼 명단의 주소 개수를 세어 보고, 스크립트에서 남은 할당량을 한 번 찍어 보는 거예요. 이 두 숫자만 알아도 "왜 멈췄지" 대신 "어느 칸에서 걸렸지"로 질문이 바뀌어요.

함께 보면 좋은 글

• 구글 시트 CRM 자동화 7단계 — 계정 층위의 발송 한도를 함정 항목으로 다뤄요.
• 자동화가 조용히 멈추는 이유와 점검 항목 — 실행이 사라지는 상황을 순서로 좁혀요.
• 같은 데이터를 중복 처리하지 않게 막는 5가지 — 재실행으로 수신자 수가 두 배로 빠지는 문제를 다뤄요.

확인한 자료: 구글 앱스 스크립트 「Quotas for Google Services」(영문판·한국어판 각각 수신. 페이지 하단 최종 업데이트는 영문판 2026-07-22 UTC, 한국어판 2026-04-23 UTC), 구글 워크스페이스 관리자 고객센터 「Google Workspace의 Gmail 전송 한도」(최종 업데이트 2026-07-22 UTC), 지메일 고객센터 「메일 주고받기 한도」. 세 문서 모두 2026년 8월 14일에 직접 받아 표와 문장을 확인했어요.