한 줄 요약: 구글 앱스 스크립트는 함수 하나와 배포 한 번으로 인터넷에서 부를 수 있는 주소를 만들어 줍니다. 다만 실행 한 번은 최대 6분이고 하루 호출량에도 한도가 있으며, 이 수치는 예고 없이 바뀔 수 있다고 공식 문서가 밝히고 있어서 개인 도구와 가끔 도는 자동 작업에 맞는 방식입니다.
서버를 빌리지 않고 주소 하나를 얻고 싶을 때 구글 앱스 스크립트를 썼습니다. 코드를 붙여넣고 배포하면 인터넷에서 부를 수 있는 주소가 나옵니다. 이 글은 그 과정을 순서대로 정리하고, 공식 문서에 적힌 한도와 주의점을 표로 묶었습니다.
공식 출처: Apps Script — Web Apps, Apps Script — Quotas for Google Services (확인: 2026-10-09), Google Workspace — Apps Script 소개 (확인: 2026-10-18)
어떤 일에 맞나
구글 Workspace의 공식 제품 소개는 Apps Script를 Workspace와 연결하고 작업을 자동화하며 기능을 넓히는 로우코드 플랫폼으로 설명합니다. Gmail 계정만 있으면 쓸 수 있고 유료 Workspace 구독이 꼭 필요하지는 않다고 안내하며, HTML·CSS·JavaScript로 만들 수 있고 100개가 넘는 구글 서비스와 연결된다고 소개합니다.
- 인증키를 감춰야 할 때 — 키를 여기 두고 결과만 돌려줍니다.
- 가끔 도는 자동 작업 — 정해진 시각에 실행하는 트리거 기능이 들어 있습니다.
- 구글 문서·시트와 엮이는 일 — 같은 계정 안이라 연결이 쉽습니다.
반대로 빠른 응답이 계속 필요한 서비스에는 안 맞습니다. 처음 부를 때 뜨는 데 시간이 걸린다고 느꼈고, 하루 실행량에 한도가 있습니다. 공식 문서는 이 한도를 테스트에 참고하라는 성격으로 소개하며, 한도는 폐지·축소·변경될 수 있다고 적어 두었습니다. 그래서 사업의 핵심 기능을 전적으로 얹는 용도로는 권하기 어렵습니다.
웹 앱이 되려면 갖춰야 할 조건
공식 웹 앱 문서는 스크립트가 웹 앱으로 배포되려면 두 가지를 만족해야 한다고 설명합니다. 첫째, doGet 또는 doPost 함수가 있어야 합니다. 둘째, 그 함수가 HTML 서비스의 HtmlOutput 객체나 콘텐츠 서비스의 TextOutput 객체를 돌려줘야 합니다. 주소를 브라우저로 열거나 프로그램이 GET 요청을 보내면 doGet이, POST 요청을 보내면 doPost가 실행됩니다.
두 함수는 e라는 이벤트 매개변수를 받습니다. e.parameter는 주소 뒤에 붙은 값을 키와 값 쌍으로 담고, 같은 이름이 여러 번 오면 첫 값만 돌려줍니다. 여러 값을 모두 받고 싶으면 e.parameters를 씁니다. POST 본문은 e.postData.contents에 글자로 들어옵니다. 문서에는 c와 sid라는 이름이 시스템 예약어라서 주소 매개변수나 POST 본문에 쓰면 405 응답과 “요청한 파일이 없다”는 오류가 날 수 있다는 경고도 있습니다. 직접 만든 값의 이름을 정할 때 이 두 가지는 피해야 합니다.
해 보는 순서
- 새 프로젝트를 만듭니다. 구글 계정만 있으면 됩니다.
doGet이라는 이름의 함수를 만듭니다. 이 이름이어야 웹 요청을 받습니다.- 오른쪽 위 배포 > 새 배포에서 유형을 ‘웹 앱’으로 고릅니다. 공식 문서의 순서가 이렇고, 여기서 실행 사용자와 접근 범위를 정합니다.
- 주소가 나옵니다. 브라우저에 붙여 넣어 결과가 오는지 확인합니다.
배포 전에 동작만 먼저 보고 싶다면 ‘배포 테스트’를 쓸 수 있습니다. 문서에 따르면 이때 나오는 주소는 /dev로 끝나고, 스크립트 편집 권한이 있는 사람만 열 수 있으며, 항상 가장 최근에 저장한 코드를 실행합니다. 개발 중 시험용이지 남에게 알려 줄 주소가 아닙니다.
설정 두 개가 핵심
배포할 때 묻는 두 가지가 동작을 완전히 바꿉니다.
- 실행 사용자 — ‘나’로 두면 접속자가 누구든 스크립트 소유자인 내 권한으로 돕니다. 그래야 내가 저장해 둔 키를 꺼내 쓸 수 있습니다. 반대로 접속한 사용자 권한으로 실행하도록 두면 접속자 본인 권한으로 돌고, 접속자는 권한 동의 화면에서 스크립트 소유자의 이메일을 보게 됩니다.
- 액세스 권한 — 웹페이지에서 부르려면 누구나 접근할 수 있는 쪽으로 바꿔야 합니다. 이걸 안 바꾸면 방문자에게는 안 됩니다. 배포 화면에 표시되는 선택지의 정확한 문구와 기본값은 이 글이 인용한 공식 문서에는 나와 있지 않습니다. 배포 화면에 표시된 문구를 읽고 고르시기 바랍니다.
‘나’로 실행하는 배포에 대해 공식 문서가 특별히 강조하는 문장이 하나 있습니다. ScriptApp.getOAuthToken으로 얻은 OAuth 토큰은 다른 애플리케이션이 내 데이터에 접근하는 데 쓰일 수 있으니 클라이언트로는 절대 보내지 말라는 내용입니다. 응답에 무엇을 담을지 정할 때 꼭 기억해 둘 부분입니다.
키는 코드에 적지 않는다
중요한 부분입니다. 키를 코드에 그대로 적으면 코드를 남에게 보여줄 수 없게 됩니다. 대신 스크립트 속성이라는 저장 공간에 두고 꺼내 씁니다. 공식 속성 문서는 스크립트 속성을 해당 스크립트나 웹 앱을 쓰는 모든 사용자가 함께 쓰는 앱 전체 설정 저장소로 소개하고, 외부 데이터베이스의 계정 정보 같은 개발자 설정을 넣는 용도를 예로 듭니다. 프로젝트 설정 화면에서 최대 50개까지 직접 넣을 수도 있다고 합니다.
// 코드에는 이 줄만 남습니다. 키 값은 안 보입니다.
var key = PropertiesService.getScriptProperties()
.getProperty('MY_API_KEY');다만 속성에 넣어 두었다고 해서 응답으로 내보내도 된다는 뜻은 아닙니다. 응답에는 필요한 결과만 담고, 키 자체나 키가 들어 있는 원본 응답은 그대로 돌려주지 않는 것이 안전합니다.
OWASP의 비밀 정보 관리 치트시트도 소스 코드에 비밀 값을 평문으로 넣어 두는 관행을 문제로 꼽고, 로그에 비밀 값을 남기지 않도록 하며, 노출된 키는 즉시 폐기하고 새 키로 교체하라고 안내합니다. 스크립트 속성에 두는 방식과 응답에 키를 섞지 않는 습관이 같은 원칙에서 나온 것입니다.
쓰면서 걸린 것
처음 실행할 때 권한 승인을 거칩니다. “확인되지 않은 앱”이라는 경고가 나오는데, 직접 만든 스크립트라 정상입니다. 공식 OAuth 클라이언트 확인 문서에 따르면 민감한 권한 범위를 요청하는 프로젝트가 확인을 받지 않았고 소유자와 사용자가 같은 Workspace 도메인이 아니면 이 화면이 나타나며, 확인되지 않은 사용자 수에도 상한이 있습니다. 같은 도메인 안에서 쓰면 확인이 필요 없다고 합니다. 다만 무슨 권한을 요구하는지는 꼭 읽어 보세요. 제 경우는 “외부 서비스에 연결” 하나였습니다.
저장 결과를 담는 공간에 크기 제한이 있습니다. 큰 데이터는 조각으로 나눠 넣어야 합니다. 공식 한도 표에서 속성 값 하나는 9KB, 속성 저장소 하나의 전체 용량은 500KB입니다.
배포 주소는 공개됩니다. 키는 가려지지만 주소는 누구나 부를 수 있습니다.
공식 문서의 한도 표
아래 수치는 모두 공식 한도 문서에 2026-10-09 기준으로 적힌 값입니다. 문서는 한도가 개인 계정(gmail.com 등)과 Google Workspace 계정에 따라 다르고, 사용자별로 적용되며, 첫 요청 뒤 24시간이 지나면 초기화된다고 설명합니다.
| 항목 | 개인 계정 | Workspace 계정 | 이 글 맥락에서의 뜻 |
|---|---|---|---|
| 스크립트 실행 시간 | 실행 1회당 6분 | 실행 1회당 6분 | 오래 걸리는 작업은 나눠야 합니다. |
| 외부 주소 호출(URL Fetch) | 하루 20,000회 | 하루 100,000회 | 다른 서비스의 API를 중계할 때 닿는 한도입니다. |
| 트리거 총 실행 시간 | 하루 90분 | 하루 6시간 | 정해진 시각에 도는 자동 작업의 합계입니다. |
| 속성 읽기·쓰기 | 하루 50,000회 | 하루 500,000회 | 키를 꺼내 쓰는 횟수도 포함됩니다. |
| 속성 값 하나의 크기 | 9KB | 9KB | 큰 데이터는 속성에 넣기 어렵습니다. |
| 동시 실행(사용자당) | 30개 | 30개 | 한꺼번에 몰리는 요청의 상한입니다. |
한도를 넘으면 스크립트가 예외를 던지고 실행이 멈춥니다. 문서에 예시로 나온 메시지는 “Service invoked too many times”, “Service using too much computer time for one day” 같은 형태입니다. 특히 트리거로 도는 스크립트는 수동 실행보다 하루 한도가 낮아서 시간 합계 오류가 가장 자주 난다고 설명합니다. 사용량을 점검하는 방법으로는 Apps Script 대시보드의 ‘내 실행’ 화면과, 남은 메일 수신자 수를 알려 주는 MailApp.getRemainingDailyQuota()가 안내되어 있습니다.
한계
실행 시간과 하루 호출량에 한도가 있습니다. 개인 블로그 정도면 넉넉하지만, 방문자가 많아지면 부딪힙니다. 저는 아직 한도에 걸려 본 적이 없어서 실제로 어떻게 표시되는지는 모릅니다. 위 예외 메시지는 공식 문서에 적힌 예시일 뿐 제가 화면에서 본 것이 아닙니다.
수정했는데 반영이 안 될 때: 막힘 3가지와 해결
웹 앱을 처음 배포하면 코드를 고쳤는데 주소의 결과는 그대로인 상황을 만나기 쉽습니다. 공식 배포 문서가 설명하는 구조로 풀면 원인이 보입니다. 아래 표는 문서 내용을 막히는 지점별로 다시 묶은 것으로, 해결 순서는 이 글에서 정리한 것입니다.
| 막힌 모습 | 원인으로 볼 수 있는 것 | 해 볼 일 |
|---|---|---|
| 고친 코드가 배포 주소에 안 나옵니다. | 배포(versioned deployment)는 특정 버전에 묶여 있어서, 코드를 저장해도 이미 만든 배포는 그대로입니다. | 새 버전을 만든 뒤 배포 관리에서 기존 배포를 새 버전으로 바꿉니다. 문서에 따르면 이렇게 하면 주소는 그대로 유지됩니다. |
| 테스트 주소(/dev)로는 되는데 공개 주소는 안 됩니다. | /dev는 항상 최신 저장본을 실행하고 편집 권한자만 열 수 있습니다. 공개 주소는 버전이 고정되어 있습니다. | 두 주소를 구분해서 시험하고, 다른 사람에게는 공개 주소만 알립니다. |
| 주소 매개변수가 있는데 405 오류가 납니다. | 매개변수 이름에 예약어 c나 sid를 썼을 가능성이 있습니다. | 다른 이름으로 바꿔 다시 호출합니다. |
배포 문서는 또 하나를 분명히 구분합니다. 현재 코드를 따라가는 헤드 배포는 테스트용이고, 여러 사람이 쓰는 용도로는 반드시 특정 버전에 연결된 배포를 쓰라는 것입니다. 이 글에서 만드는 주소를 다른 사람의 페이지에 연결해 둘 거라면 이 구분이 가장 중요합니다.
한 번 더 확인할 기준
주소 하나를 만든다고 해서 누구나 호출해도 되는 것은 아닙니다. 요청을 받는 쪽에서 어떤 입력을 허용할지 정하고, 예상하지 않은 값은 거절하는 규칙을 먼저 만들면 나중의 수정이 줄어듭니다.
| 확인할 것 | 왜 보는가 | 바로 해 볼 일 |
|---|---|---|
| 출처와 날짜 | 같은 말도 기준 시점이 다르면 뜻이 달라집니다. | 원문과 마지막 갱신일을 함께 적습니다. |
| 내 작업과의 거리 | 일반적인 설명이 내 상황에 그대로 맞지는 않습니다. | 작은 예시 하나로 먼저 시험합니다. |
| 되돌릴 방법 | 편리한 선택도 실수하면 비용이 생깁니다. | 원본·설정·결과를 구분해 둡니다. |
테스트는 이렇게 나눠서 합니다
브라우저에서 한 번 열리는지만 보지 말고, 값이 없는 요청·틀린 형식·짧은 시간에 여러 번 들어온 요청도 따로 확인합니다. 정상 응답과 오류 응답의 모양을 정해 두면 연결하는 쪽도 덜 헷갈립니다. 응답을 JSON으로 돌려줄 때는 공식 예시처럼 ContentService.createTextOutput(...).setMimeType(ContentService.MimeType.JSON) 형태를 쓰면 받는 쪽이 글자로 다시 해석하지 않아도 됩니다.
작게 해 보는 예시
처음부터 중요한 일을 맡기지 않는 편이 좋습니다. 입력은 짧게 정하고, 기대한 결과와 실제 결과를 나란히 적습니다. 예를 들어 ?username=jsmith&age=21처럼 값 두 개를 붙여 호출하고, 응답에 그 값이 그대로 돌아오는지만 먼저 봅니다. 공식 문서의 예시도 이 방식으로 e 객체 전체를 되돌려 보여 줍니다. 여기서 차이가 나면 도구가 틀렸다기보다 내가 세운 조건이 모호했을 가능성도 같이 살펴볼 수 있습니다.
그다음에는 예외 하나를 일부러 넣어 봅니다. 빈칸, 오래된 날짜, 예상과 다른 형식처럼 현실에서 자주 만나는 조건입니다. 정상적인 경우만 통과한 방법은 다음 단계에서 쉽게 흔들립니다.
기록을 남기면 달라지는 점
새 방법을 쓴 날에는 “무엇을 넣었고 무엇이 나왔는지”를 두세 줄로 남겨 보세요. 날짜, 배포 버전 번호, 기대한 결과, 실제 결과, 다음에 고칠 한 가지면 충분합니다. 공식 문서에서 한도 같은 수치는 예고 없이 바뀔 수 있다고 하니, 어느 날짜에 확인한 값인지도 함께 적어 두면 나중에 비교하기 쉽습니다.
| 단계 | 확인하는 질문 | 다음 행동 |
|---|---|---|
| 1. 목표 | 무엇을 줄이거나 알아내려는가 | 한 문장으로 적습니다. |
| 2. 표본 | 작은 사례에서 같은 결과가 나오는가 | 입력과 결과를 보관합니다. |
| 3. 예외 | 모르는 값이나 실패는 어떻게 보이는가 | 멈춤·알림·재확인 중 하나를 정합니다. |
| 4. 적용 | 사람에게 영향을 주는 부분이 있는가 | 확인 단계를 남긴 뒤 범위를 넓힙니다. |
짧은 점검표
- 목적을 한 문장으로 적었는가 — 필요한 기능과 멋있어 보이는 기능을 구분합니다.
- 작은 범위에서 확인했는가 — 처음부터 중요한 자료나 많은 사람에게 적용하지 않습니다.
- 바뀔 수 있는 부분을 표시했는가 — 요금·정책·지원 범위는 공식 안내를 다시 확인합니다.
- 결과를 사람이 읽어 봤는가 — 자동으로 나온 값도 맥락과 예외를 마지막에 확인합니다.
- 키가 응답에 섞이지 않았는가 — 응답에 담긴 값을 한 번 눈으로 훑어봅니다.
업데이트
이 글은 공식 웹 앱·배포·속성·한도·OAuth 확인 문서(2026-10-09 기준)의 내용을 바탕으로 합니다. 이 시점에 문서에 표시된 갱신일은 웹 앱·한도·속성·OAuth 확인 문서가 2026-09-03, 배포 문서가 2026-09-15입니다. 한도와 정책은 바뀔 수 있으니 실제 적용 전에 최신 안내를 확인하세요.
확인 자료
- Apps Script — Web Apps (확인: 2026-10-09)
- Apps Script — Quotas for Google Services (확인: 2026-10-09)
- Apps Script — Deployments (확인: 2026-10-09)
- Apps Script — Properties Service (확인: 2026-10-09)
- Apps Script — OAuth client verification (확인: 2026-10-09)
- Google Workspace — Apps Script 소개 (확인: 2026-10-18)
- OWASP — Secrets Management Cheat Sheet (확인: 2026-10-18)