GAS 분 단위 트리거: 54초 루프의 한도와 중복 실행 방지
TECH INSIGHT / EXPLAINED
분마다 시작하는 트리거 안에서 54초를 반복 실행하면 거의 상시 동작하는 것처럼 보인다. 하지만 실제 설계의 제약은 6분짜리 1회 실행 한도보다 하루 총 실행 시간과 중복 실행이다. 시간을 채우기 전에 필요한 관측 주기부터 정해야 한다.
54초 루프의 하루 비용
가상의 거래 세션 390분에서 분마다 54초씩 실행하면 21,060초, 즉 351분(5.85시간)이다. 2026년 9월 공식 트리거 실행 예산은 개인 계정 90분/일, Google Workspace 6시간/일이다. 후자도 이 루프만으로 360분 중 351분을 사용해 여유가 9분뿐이다. 장외 상태 점검과 다른 스크립트, 느린 API 응답까지 고려하면 안정적인 여유라고 보기 어렵다.
20초로 줄여도 390×20/60=130분이어서 개인 계정 한도를 넘는다. 5초라면 32.5분이다. 실제 필요한 작업을 짧게 실행하고 끝내는 방식부터 검토한다. 수면 호출로 기다리는 시간도 실행 시간을 공짜로 없애 주지 않는다. 24시간 내내 54초 루프를 돌리는 가정은 하루 21.6시간을 요구한다.
6초 여백은 중복 방지 장치가 아니다
트리거는 정밀한 실시간 스케줄러가 아니다. API 지연과 실행 시작 편차가 있으므로 ‘매분 정확히 6초만 쉰다’거나 ‘초당 정확히 한 번’이라고 보장할 수 없다. 초 숫자가 바뀌었는지 검사하면 빠른 반복을 줄일 수 있지만 작업이 느려지면 초를 건너뛴다.
같은 작업의 겹침은 LockService 같은 실행 간 잠금으로 별도 제어한다. 잠금을 못 얻으면 그 주기를 건너뛰고 원인을 기록한다. 스크립트 전체 잠금은 모든 사용자 작업을 직렬화할 수 있으므로 사용자별 실행인지 공용 스케줄러인지에 맞게 범위를 선택한다. 잠금만으로 외부 주문의 정확히 한 번 처리가 완성되지는 않는다.
요청 상태·설치 상태·건강 상태를 분리한다
- 원하는 상태: 사용자가 활성화를 요청했는가.
- 설치 상태: 해당 생성자가 소유한 작업 트리거가 실제로 존재하는가.
- 건강 상태: 마지막 성공 시각과 마지막 오류는 무엇인가.
프로퍼티에 트리거 ID가 있다는 것은 과거에 저장했다는 뜻이다. 실행 성공의 증거가 아니다. 시작 요청은 잠금 안에서 기존 트리거와 기록을 대조한 뒤 필요한 경우에만 생성한다. Session에서 이메일이 항상 반환된다고 가정하지 말고 실행 권한과 배포 방식을 확인한다. 설치형 트리거는 생성자 권한으로 실행된다.
중지는 해당 작업을 대상으로 한다
활성화 상태를 먼저 끄고 저장한 ID와 처리 함수 이름에 맞는 트리거를 삭제한다. 이전 버전의 중복 트리거는 소유자와 함수 이름을 확인하여 정리한다. 프로젝트의 모든 트리거를 무조건 삭제하면 알림이나 백업 작업도 사라질 수 있다. 트리거 목록은 현재 사용자가 가진 범위라는 점도 반영한다.
이미 실행 중인 함수는 삭제만으로 취소되지 않으므로 새 외부 동작 직전에 상태를 다시 검사한다. ‘중지 요청’, ‘트리거 정리 완료’, ‘마지막 실행 종료’를 구분하면 화면이 실제보다 앞서 성공을 선언하지 않는다.
중간에 끊겨도 다음 실행이 복구할 수 있게 한다
외부 주문이 성공한 직후 기록 전에 실행이 종료될 수 있다고 가정한다. 주문 의도 ID와 처리 단계, 외부 주문 ID를 남기고 다음 실행은 미확인 주문부터 조회한다. 시간 초과나 네트워크 오류에서 정리 코드가 반드시 끝날 것이라고 기대하지 않는다.
휴장일과 장 시간은 거래소 시간대와 검증된 달력으로 판단한다. 마지막 성공 시각이 기준을 넘으면 UI와 독립 감시 경로에 표시하고 Apps Script 실행 기록·트리거 실패 알림을 확인한다. 초 단위의 연속 반응이 필수라면 이를 지원하는 실행 환경으로 옮기는 판단이 필요하다.
참고 자료
내용·예제 검토: 2026-09-29
댓글
댓글 쓰기