Apps Script 트리거 자동화, 시간 예약 전에 실패 로그부터 설계하는 법

트리거를 만드는 법보다 중요한 것은 실패했을 때 누가 보고, 어디서 확인하고, 어떻게 재실행할지입니다. Apps Script 트리거 자동화를 운영 기준으로 정리했습니다.

Apps Script 트리거 자동화를 검색했다면 아마 스프레드시트 정리, 메일 발송, 폼 응답 처리, 보고서 갱신을 매번 손으로 누르지 않게 만들고 싶을 것입니다. 하지만 실제 손실은 “트리거를 못 만들어서”보다, 권한 승인 계정이 퇴사했거나 6분 실행 제한에 걸렸거나 실패 알림을 아무도 보지 못해서 자동화가 조용히 멈출 때 더 크게 납니다.

결론은 단순합니다. 시간 예약 버튼을 누르기 전에 1. 실행 계정과 OAuth 범위를 정하고 2. 실패 알림과 실행 로그 위치를 팀이 볼 수 있게 만들고 3. LockService와 재시도 기준으로 중복 실행을 막은 뒤 트리거를 켜야 합니다.

출처 역할 이 글에서 쓰는 근거 편집상 한계
분석 대상 원문 Google Apps Script 설치형 트리거 문서: 설치형 트리거의 실행 계정, 제한, 실패 알림, 수동/프로그래밍 관리 개별 회사의 Workspace 보안 정책까지 대신 판단하지 않는다.
공식 확인 자료 Apps Script 할당량 문서, Logging 문서, LockService 문서, Authorization Scopes 문서 할당량은 Google이 예고 없이 바꿀 수 있으므로 발행 후 운영 전 재확인이 필요하다.
운영 판단 업무 자동화에서는 트리거 생성보다 실패 탐지, 권한 최소화, 소유권 유지, 중복 실행 방지가 먼저라는 편집자 판단 조직 규모, 관리자 권한, 보안 정책에 따라 선택지가 달라진다.
내부 연결 숏폼 자동화 가이드, 숏폼 수익 리스크 관리 스프레드시트·메일 자동화가 콘텐츠 운영 자동화로 확장되는 경우에만 이어 읽을 가치가 크다.

참고한 공식·신뢰 자료

아래 자료를 기준으로 사실 관계와 한계를 대조했습니다. 광고·제휴 링크가 아니라 본문 검수에 사용한 참고 자료입니다.

  • 설치형 트리거는 더 강력하지만 공식 문서상 만든 사람의 계정으로 실행된다. 그래서 개인 계정에 묶인 자동화는 운영 리스크가 된다.
  • Apps Script는 1회 실행 시간, 일일 트리거 실행 시간, 동시 실행 수, 트리거 수 제한을 가진다. 긴 작업은 한 번에 끝내는 설계보다 쪼개서 이어 하는 설계가 안전하다.
  • 실패는 화면에 바로 뜨지 않을 수 있다. 실패 알림 메일, Apps Script Executions, Cloud Logging 확인 순서를 먼저 정해야 한다.
  • 중복 실행은 “가끔 두 번 돈다”가 아니라 데이터 중복, 메일 중복 발송, API 할당량 낭비로 이어진다. 공유 리소스를 수정한다면 LockService를 기본값으로 본다.
  • 서비스 계정은 일반 설치형 트리거의 만능 대체재가 아니다. Google Cloud API 호출, Workspace 관리자 권한, 도메인 위임 같은 조건이 맞을 때만 별도 검토한다.

Apps Script 트리거 자동화는 예약 버튼보다 무엇을 먼저 봐야 할까?

먼저 확인할 결론은 이렇습니다. 트리거 종류를 고르기 전에 실패했을 때 누가 알림을 받고 어떤 계정 권한으로 실행되며 어디까지 실행되면 성공으로 볼지를 정해야 합니다.

공식 문서 기준으로 설치형 트리거는 단순 트리거보다 유연하고 권한이 필요한 서비스도 호출할 수 있습니다. 동시에 제한도 있습니다. 읽기 전용으로 열린 파일에서는 실행되지 않을 수 있고 스크립트 실행이나 API 요청이 다시 트리거를 일으키지 않는 제한이 있으며 설치형 트리거는 만든 사람의 계정으로 실행됩니다.

편집자 판단은 여기서 시작합니다. 개인 작업이면 “매일 오전 9시 실행”만으로 충분할 수 있습니다. 팀 업무라면 “오전 9시에 실행”보다 “실패했을 때 담당자가 같은 날 알 수 있는가”가 먼저입니다.

지금 놓치면 자동화가 멈춰도 아무도 모르는 비용이 생긴다

Apps Script 트리거 자동화의 가장 흔한 착각은 한 번 켜면 계속 같은 조건으로 돈다고 믿는 것입니다. 실제로는 권한, 할당량, 데이터 양, 외부 API 응답, 문서 소유권, 동시 실행 상태가 바뀝니다.

공식 할당량 문서는 Apps Script 서비스가 일일 할당량과 제한을 가지며 초과하면 예외가 발생하고 실행이 멈춘다고 설명합니다. 예를 들어 2026년 6월 27일 확인 기준으로 스크립트 1회 실행 제한은 6분, 트리거 총 실행 시간은 소비자 계정 90분/일, Google Workspace 계정 6시간/일로 안내되어 있습니다. 또한 사용자당 스크립트당 트리거 수 제한도 있습니다.

이 숫자를 외우는 것이 목표는 아닙니다. 목표는 자동화 설계서에 “하루 처리량이 늘면 어느 지점에서 멈출 수 있는지”를 적는 것입니다. 스프레드시트 100행에서 성공한 코드는 1만 행에서 시간 제한에 걸릴 수 있고 테스트 계정에서 보낸 메일은 실제 고객 리스트에서 발송 할당량에 걸릴 수 있습니다.

트리거를 잘못 고르면 어디에서 손실이 나나?

시간 기반 트리거는 정해진 간격으로 실행하기 좋지만 이전 실행이 늦어졌을 때 다음 실행과 겹칠 수 있습니다. 폼 제출 트리거는 응답 직후 처리하기 좋지만 처리 코드가 실패하면 사용자는 이미 제출을 끝낸 뒤입니다. 문서 열기·수정 트리거는 협업 흐름에 붙이기 좋지만 만든 사람의 계정과 편집 권한 관계를 이해하지 못하면 책임 소재가 흐려집니다.

상황 먼저 고를 기준 잘못 고르면 생기는 손실
매일 보고서 갱신 시간 기반 트리거 + 실패 알림 확인 보고서가 어제 데이터로 남아도 팀이 모를 수 있다.
폼 응답 후 메일 발송 폼 제출 트리거 + 중복 발송 방지 키 동일 응답에 메일이 두 번 가거나 실패 응답이 누락된다.
시트 행 대량 정리 배치 처리 + 실행 시간 분할 6분 제한 근처에서 일부 행만 처리되고 멈춘다.
팀 공용 자동화 공유 드라이브·소유권·관리 계정 검토 담당자 퇴사 후 수정·재승인·로그 확인이 막힌다.

내 업무에는 시간 기반, 이벤트 기반, 수동 재실행 중 무엇이 맞을까?

선택 기준은 기능명이 아니라 실패 비용입니다. 실패해도 다음 실행 때 회복되는 작업은 시간 기반 트리거가 맞습니다. 실패하면 고객 안내, 결제, 계약, 제출 확인에 영향을 주는 작업은 이벤트 기반으로 처리하되 별도 재처리 큐를 둬야 합니다. 한 번의 실행이 오래 걸리는 작업은 수동 재실행 버튼이나 상태 컬럼을 함께 설계하는 편이 안전합니다.

  • 정시성이 중요하면 시간 기반 트리거를 쓰되, 실행 시작·종료·처리 건수를 로그로 남긴다.
  • 사용자 행동 직후 처리가 중요하면 이벤트 기반 트리거를 쓰되, 중복 처리 여부를 응답 ID나 행 ID로 확인한다.
  • 데이터 양이 계속 늘면 한 번에 모든 행을 처리하지 말고 상태값 기준으로 나눠 처리한다.
  • 팀 운영이면 개인 Gmail 계정이 아니라 조직이 통제할 수 있는 소유권, 공유 드라이브, 관리자 정책을 먼저 확인한다.

불확실한 점도 분리해야 합니다. Google 문서는 설치형 트리거가 만든 사람 계정으로 실행된다고 설명하지만 회사별 재인증 정책, 계정 정지 처리, 관리자 보안 예외는 조직 설정에 따라 달라질 수 있습니다. 그래서 “비밀번호를 바꾸면 반드시 재승인”처럼 단정하지 말고 운영 전 테스트 계정으로 권한 변경·계정 비활성화 시나리오를 확인해야 합니다.

Apps Script 트리거 자동화는 어떤 순서로 켜야 안전할까?

  1. 실행 함수부터 분리합니다. 트리거가 직접 긴 로직을 품지 않게 하고 `runDailyReport`, `processFormSubmit`처럼 목적이 보이는 함수로 시작합니다.
  2. OAuth 범위를 확인합니다. Apps Script Overview의 Project OAuth Scopes에서 실제 요청 범위를 보고 공개 앱·웹앱·애드온처럼 범위 통제가 필요한 경우 `appsscript.json`의 `oauthScopes`에 필요한 URL 범위만 명시합니다. 예를 들어 읽기만 필요하면 쓰기 권한이 포함된 범위보다 `spreadsheets.readonly`처럼 좁은 범위를 검토합니다.
  3. 처리 기준을 기록합니다. 시작 시간, 종료 시간, 처리 건수, 건너뛴 건수, 실패 건수를 `console.log()`나 구조화 로그로 남깁니다.
  4. 중복 실행을 막습니다. 공유 시트나 공용 상태값을 수정한다면 LockService로 동시에 같은 구간이 실행되지 않게 합니다.
  5. 실패 알림 수신자를 정합니다. 설치형 트리거 실패 알림 메일만 믿지 말고 담당자가 Apps Script의 Executions와 Cloud Logging을 볼 수 있는지 확인합니다.
  6. 작은 범위로 켭니다. 전체 데이터가 아니라 테스트 시트, 일부 행, 낮은 빈도로 시작한 뒤 처리량을 올립니다.

이 순서는 트리거 만들기를 늦추기 위한 절차가 아닙니다. 자동화가 실제 업무 데이터에 닿기 전에 멈춤, 중복, 권한 오류를 눈에 보이게 만드는 순서입니다.

켜기 직전에 무엇을 마지막으로 점검해야 하나?

  • 이 트리거는 어느 계정이 만들고 그 계정이 퇴사·정지·권한 변경될 때 누가 인수하는가?
  • 실패 알림 메일을 받는 사람이 실제 운영 담당자인가?
  • Apps Script의 Executions에서 Failed, Timed out 상태를 확인하는 사람이 정해져 있는가?
  • 하루 처리량이 할당량을 넘을 가능성이 있는가?
  • 동일 데이터가 두 번 처리되면 어떤 손실이 생기는가?
  • 로그에 이메일 주소, 고객명, 민감한 원문 같은 개인정보를 남기고 있지 않은가?
  • 수동 재실행 시 이미 처리된 행을 건너뛰는 기준이 있는가?

공식 Logging 문서는 개인정보를 로그에 남기지 않는 것이 좋은 관행이라고 설명합니다. 편집자 판단으로는 업무 자동화 로그에는 원문 데이터보다 추적 키, 처리 단계, 건수, 오류 코드만 남기는 편이 안전합니다.

실패 알림은 즉시 대응, Cloud Logging은 사후 추적에 나눠 써야 한다

앞 단계의 실패 알림은 “오늘 멈췄는지”를 보는 장치입니다. 반면 Cloud Logging과 Executions는 “왜 멈췄는지”를 추적하는 장치입니다. 이 둘을 같은 역할로 쓰면 운영자가 알림 메일만 보고 원인을 놓치거나, 로그만 쌓아 두고 당일 장애를 놓칩니다.

공식 문서에 따르면 설치형 트리거가 실패하면 화면에 바로 오류가 뜨지 않을 수 있으며 Apps Script는 실패 요약 메일을 보냅니다. 프로젝트 안에서는 Executions에서 실패와 시간 초과 실행을 필터링할 수 있고 표준 Google Cloud 프로젝트를 연결한 경우 Cloud Console에서 더 자세한 로그 필터링이 가능합니다.

중복 실행 방지는 별도의 문제입니다. LockService는 여러 사용자나 프로세스가 같은 공유 리소스를 동시에 수정할 때 충돌을 막는 데 쓰입니다. 예를 들어 폼 응답 처리 함수가 같은 행을 업데이트하거나, 시간 기반 트리거가 아직 끝나기 전에 다음 실행이 시작될 수 있다면 LockService로 임계 구간을 보호해야 합니다.

팀에서 막히는 질문은 기능보다 권한과 소유권에서 나온다

결제 직전인데 무료 Apps Script만으로 충분할까?

무료냐 유료냐보다 먼저 봐야 할 것은 실행량과 책임 범위입니다. 소규모 내부 보고서, 개인 시트 정리, 낮은 빈도의 알림은 Apps Script로 시작할 수 있습니다. 하지만 실행 시간이 길고 외부 API가 많고 장애 알림·재처리·권한 감사가 필요하다면 별도 서버, Google Cloud Functions, Workflows 같은 선택지를 비교해야 합니다. 이 글은 “Apps Script로 무조건 충분하다”가 아니라 “Apps Script로 시작할 때 어디까지 운영 설계를 해야 하는가”를 설명합니다.

퇴사자 계정이 만든 트리거는 서비스 계정으로 바꾸면 해결될까?

일반적인 설치형 트리거 운영 해법처럼 서비스 계정을 말하면 위험합니다. 공식 문서상 서비스 계정은 Apps Script에서 API를 호출할 때 특정 조건에서 사용할 수 있고 Google Cloud 프로젝트, API 활성화, 관리자 권한, 키 관리, 경우에 따라 Workspace 도메인 위임이 필요합니다. 팀 자동화의 1차 선택지는 보통 소유권 이관, 공유 드라이브 배치, 관리 가능한 조직 계정으로 트리거 재생성, 담당자 교체 절차 문서화입니다. 서비스 계정은 Google Cloud API 중심 자동화와 관리자 통제 조건이 맞을 때 별도 보안 검토로 다루는 편이 안전합니다.

보안팀이 광범위한 권한을 거부하면 자동화를 포기해야 할까?

바로 포기할 필요는 없습니다. 먼저 `appsscript.json`에서 명시 범위를 줄일 수 있는지 확인하고 읽기 전용 범위로 가능한 작업과 쓰기 권한이 필요한 작업을 분리합니다. 그래도 제한 범위로 불가능하다면 자동화 범위를 줄이거나, 승인된 Google Cloud 프로젝트와 관리자 검토 절차로 옮기는 것이 맞습니다. “권한 경고를 그냥 통과하라”는 식의 운영은 팀 도입 단계에서 오래 가지 않습니다.

다음에는 어떤 자동화를 읽어야 손실을 줄일 수 있을까?

Apps Script 트리거 자동화는 스프레드시트, Gmail, Forms 같은 내부 업무에서 시작하지만 같은 원리가 콘텐츠 운영 자동화로 확장됩니다. 예를 들어 시트에 쌓인 아이디어를 숏폼 제작 일정으로 보내거나, 메일 알림을 콘텐츠 승인 흐름으로 바꾸는 순간 실패 로그와 중복 실행 방지는 콘텐츠 운영 리스크가 됩니다.

지금 상태 지금 읽지 않으면 생기는 비용 읽으면 해결되는 문제
스프레드시트·메일 자동화를 콘텐츠 운영으로 넓히려는 경우 자동화는 돌아가지만 콘텐츠 제작 순서와 승인 흐름이 따로 놀 수 있다. 숏폼 자동화 가이드에서 기획, 제작, 발행 흐름을 한 번에 묶는 기준을 확인한다.
짧은 영상 제작을 반복 업무처럼 만들고 싶은 경우 30초 콘텐츠를 빨리 만들 수는 있어도 품질 점검과 재사용 기준이 빠질 수 있다. AI 30초 숏폼 워크플로에서 아이디어를 짧은 제작 루프로 바꾸는 순서를 본다.
자동화가 수익·광고·외주 운영과 연결되는 경우 자동 발행, 중복 업로드, 근거 없는 수익 기대가 운영 리스크로 커질 수 있다. 숏폼 수익 리스크 관리에서 자동화 이후의 정책·수익·운영 리스크를 점검한다.

정리하면, Apps Script 트리거 자동화의 첫 단계는 트리거 생성이 아니라 실패를 볼 수 있게 만드는 것입니다. 권한, 실행 시간, 실패 알림, 중복 실행, 로그 확인을 먼저 설계하면 자동화는 “편한 버튼”이 아니라 팀이 믿고 맡길 수 있는 업무 흐름이 됩니다.

공유하기

이 글이 유용했다면 팀 채널, 개인 메모, SNS에 저장해두세요.

X 공유링크 열기

다음 글

다음에 읽을 글

검색 유입 개선 다음 경로