구글 스프레드시트 자동화 오류: Apps Script 트리거를 놓치지 않는 운영법

구글 스프레드시트 자동화가 조용히 멈추는 일을 막으려면, 트리거를 만드는 것만으로는 부족합니다. 실행 계정과 한도를 먼저 확인하고, 실패 알림을 받을 사람을 정한 뒤, 실행 기록에서 원인을 찾고 재실행하는 절차까지 문서로 남겨야 합니다. 이 네 가지가 있어야 자동화가 담당자의 개인 작업을 넘어 팀의 업무가 됩니다.

자동화는 실행 계정부터 정해야 한다

Apps Script의 설치형 트리거는 만든 사람의 계정 권한으로 실행됩니다. 동료가 스프레드시트를 열거나 폼을 제출해도 트리거가 보낸 메일과 접근 권한은 트리거 생성자 기준입니다.[1] 담당자가 퇴사하거나 계정이 정지되면 자동화가 멈출 수 있는 이유입니다.

처음 만들 때 아래 항목을 문서 첫 장에 적어 두세요.

• 자동화 소유 계정과 실제 업무 담당자
• 연결된 스프레드시트, 폼, 드라이브 폴더
• 트리거 종류와 실행 주기
• 메일·캘린더·외부 API처럼 자동화가 사용하는 권한
• 담당자 부재 때 확인할 대체 관리자

개인 계정으로 시험했다면 운영 전환 시점에 조직이 관리하는 계정으로 다시 만들고, 새 계정의 권한으로 실제 한 번 실행해 보는 편이 안전합니다. 기존 트리거의 이름만 바꾸는 것으로 실행 주체가 바뀌지는 않습니다.

정상 완료를 확인할 기준을 한 줄로 만든다

"오류가 없었다"는 성공 기준이 아닙니다. 주문 행을 읽어 송장을 만드는 자동화라면, 마지막 행에 완료 상태가 기록됐는지, 생성 파일이 지정 폴더에 있는지, 같은 주문이 두 번 처리되지 않았는지를 확인해야 합니다.

완료 기록은 원본 데이터와 같은 곳에 무리하게 섞지 않아도 됩니다. 별도 실행 시트나 로그 저장소에 작업 ID, 시작·종료 시각, 성공 여부, 재실행 여부만 남겨도 운영 판단이 빨라집니다. 고객 이름, 연락처, 주문 메모 같은 개인정보는 로그에 복사하지 마세요.

실패 알림과 실행 기록을 함께 본다

설치형 트리거가 실패하면 실행 화면에 오류가 바로 나타나지 않습니다. Google은 트리거 실패 요약을 이메일로 보내며, 알림의 링크나 Apps Script 편집기 왼쪽 Executions 메뉴에서 실패한 실행과 오류 메시지를 확인하도록 안내합니다.[1]

실행 기록을 볼 때는 다음 순서가 실용적입니다.

1. 실패한 시각과 트리거 이름을 확인합니다.
2. 같은 시각에 원본 시트나 폼 구조가 바뀌었는지 봅니다.
3. 실행 기록을 Failed와 Timed out 상태로 좁힙니다.[3]
4. 오류가 난 행이나 파일만 다시 처리할 수 있는지 확인합니다.
5. 수정 뒤에는 샘플 한 건으로 실행하고 결과 기록까지 확인합니다.

Apps Script는 실행 로그, Cloud Logging, Error Reporting을 제공합니다. 간단한 개발 확인에는 실행 로그를 쓸 수 있고, 여러 사용자가 의존하는 운영 자동화라면 표준 Google Cloud 프로젝트와 Cloud Logging을 연결해 로그를 더 오래 조회하고 필터링할 수 있습니다.[3]

이메일 알림 한 통을 받는 것과 복구가 가능한 것은 다릅니다. 누가 확인하고, 어디서 원인을 찾고, 어느 범위까지 다시 실행할지를 정해야 복구 절차가 완성됩니다.

한도 초과를 코드 오류와 구분한다

Apps Script와 연결된 Google 서비스에는 일일 할당량과 실행 제한이 있습니다. 한도를 넘으면 실행이 예외와 함께 중단되며, 할당량은 사용자별로 적용되고 사전 고지 없이 바뀔 수 있습니다.[2] 어제까지 되던 자동화가 오늘부터 멈췄다고 해서 코드가 반드시 바뀐 것은 아닙니다.

아래 징후가 보이면 처리량과 주기를 먼저 확인하세요.

• 특정 시간대에 실패가 몰린다.
• 소량 테스트는 성공하지만 전체 처리에서 멈춘다.
• 같은 계정이 여러 자동화를 동시에 돌린다.
• 메일 발송, 파일 생성, 외부 요청이 갑자기 늘었다.

한 번에 모든 행을 처리하지 말고 작업을 작은 묶음으로 나누면 실패 범위를 줄일 수 있습니다. 다음 실행에서 이어갈 마지막 처리 위치를 저장하고, 같은 작업 ID는 건너뛰도록 만들어야 중복 발송과 중복 파일 생성을 피할 수 있습니다.

function shouldProcess(jobId, processedIds) {
  return jobId && !processedIds.has(jobId);
}

이 코드는 개념을 보여 주는 예시입니다. 실제 구현에서는 처리 상태를 읽고 쓰는 과정이 겹치지 않도록 잠금과 실패 시 상태 복구도 함께 설계해야 합니다.

월 1회 복구 연습으로 자동화를 운영 자산으로 만든다

자동화는 정상 실행 횟수보다 실패했을 때의 복구 시간으로 품질이 드러납니다. 월 1회 아래 절차를 실제로 해보면 담당자만 아는 설정을 찾을 수 있습니다.

• [ ] 대체 관리자가 Apps Script 프로젝트와 원본 파일에 접근한다.
• [ ] 최근 실패·시간 초과 실행을 조회한다.
• [ ] 테스트 데이터 한 건을 넣고 결과를 확인한다.
• [ ] 중복 처리 없이 재실행할 수 있는지 점검한다.
• [ ] 트리거 소유 계정과 알림 수신자를 최신 상태로 고친다.
• [ ] 현재 처리량이 공식 할당량에 가까운지 확인한다.

여러 스프레드시트 자동화를 운영 중인데 소유권, 실패 알림, 재실행 기준이 흩어져 있다면 업무 자동화 설계 단계에서 공통 운영표부터 만드는 편이 좋습니다. 새 기능을 더하기 전에 멈춘 작업을 발견하고 복구하는 길을 한 장으로 정리하면 됩니다.