Google Apps Script 백엔드: 작은 자동화의 실행 예산과 운영 경계
TECH INSIGHT / EXPLAINED
주문 엔진을 만들기 전에, 시세를 정기적으로 읽고 설정을 보관하는 작은 백엔드부터 만들어 볼 수 있다. Google Apps Script는 이 실험의 진입 비용을 낮춰 준다. 다만 분 단위로 실행되는 작업과 계속 살아 있는 서버는 운영 방식이 다르다.
기존 사용 화면과 소개 이미지
기존 글에 담았던 사용 화면과 소개 이미지를 함께 보며 구조와 동작을 확인할 수 있습니다.
세 가지 책임을 분리한다
웹 앱은 설정 조회와 변경 요청을 받고, 시간 기반 트리거는 짧은 주기 작업을 수행하며, Properties Service는 작은 설정과 마지막 처리 상태를 저장한다. 먼저 시세 조회와 상태 표시만 연결하고, 주문 기능은 인증·중복 방지·오류 복구를 검증한 뒤 별도로 추가한다.
웹 앱의 실행 주체를 배포자와 접속자 중 무엇으로 정했는지 기록한다. 설치형 트리거는 이를 만든 계정의 권한으로 실행된다. 따라서 User Properties가 자동으로 고객별 저장소가 된다고 가정하면 안 된다. 공용 배포에서 고객을 구분하려면 인증된 사용자와 저장소의 소유자를 서버에서 연결해야 한다.
무료 여부보다 하루 실행 예산을 먼저 계산한다
2026년 9월 확인한 공식 할당량에서 일반 스크립트의 1회 실행 한도는 개인 계정과 Google Workspace 모두 6분이다. 트리거의 하루 총 실행 시간은 각각 90분과 6시간이다. 계정별 조건과 할당량은 바뀔 수 있으므로 배포 전 공식 표를 확인한다.
예를 들어 거래 시간 390분 동안 분마다 5초를 실행하면 총 1,950초, 즉 32.5분이다. 같은 작업을 온종일 1,440회 실행하면 120분이므로 개인 계정의 90분 예산을 넘는다. 한 번 실행이 짧다는 사실만으로 24시간 운영을 판단할 수 없다.
한 주기에 시세 2회와 잔고 1회를 요청한다면 390회 실행의 기본 요청 수는 1,170회다. 인증 갱신·재시도·다른 스크립트의 사용량도 추가한다. 증권사 자체 호출 제한은 Apps Script 할당량과 별도로 지켜야 한다.
시작과 중지는 상태 전환이다
- 시작 요청을 인증하고, LockService로 중복 시작을 직렬화한다. 기존 트리거의 실제 존재를 확인한 뒤 필요한 경우에만 만든다.
- 트리거 ID, 처리 함수 이름, 활성화 상태를 함께 기록한다. ID가 저장되어 있다는 사실은 최근 작업 성공의 증거가 아니다.
- 중지 시 활성화 상태를 먼저 끄고 이 봇에 해당하는 트리거만 삭제한다. 프로젝트의 모든 트리거를 지우면 다른 작업까지 멈춘다.
- 실행 중인 작업은 새 주문 직전에 활성화 상태를 다시 확인한다. 트리거 삭제는 진행 중인 실행 취소나 보유 자산 청산을 뜻하지 않는다.
API 경계에서 확인할 것
doPost는 요청을 받는 입구일 뿐이다. 동작 이름 허용 목록, 본문 크기와 JSON 형식, 사용자 권한을 검사하고 설정 저장과 시작 요청을 구분한다. 웹 앱 URL을 알고 있다는 이유만으로 조작을 허용하지 않는다. 실제 브라우저에서 로그인·리디렉션·교차 출처 요청을 확인해야 하며, fetch가 리디렉션을 따라간다는 사실만으로 연동이 검증되지는 않는다.
접근 토큰은 날짜가 아니라 제공자의 만료 정보에 따라 갱신한다. 만료 시각보다 여유를 두고, 동시에 여러 실행이 갱신하지 않게 잠금을 둔다. HTTP 상태와 응답 필드를 확인하고 토큰 값을 로그에 남기지 않는다.
운영 가능한 상태를 보여 준다
화면에는 활성화 여부와 별개로 마지막 성공 시각, 마지막 오류, 최근 처리 항목을 표시한다. Apps Script 실행 기록과 설치형 트리거의 실패 알림도 확인한다. 시세가 오래됐거나 인증 갱신에 실패했다면 새 주문을 멈추고 운영자가 상태를 확인할 수 있어야 한다. 초 단위 응답이나 연속 연결이 필수라면 다른 실행 환경을 검토한다.
참고 자료
내용·예제 검토: 2026-09-29
댓글
댓글 쓰기