Apps Script를 비즈니스 로직 엔진으로 쓰기

자동화 워크플로우 시리즈 4/8

Google Sheets를 운영 데이터의 원천으로 두면 자연스럽게 Google Apps Script를 쓰게 된다.

폼 제출 이벤트를 받을 수 있고, 시트 데이터를 읽고 쓸 수 있으며, 외부 API도 호출할 수 있다.

이 정도면 작은 운영 자동화에서는 충분히 비즈니스 로직 엔진 역할을 할 수 있다.

하지만 Apps Script는 만능 백엔드가 아니다. 잘 맞는 역할과 넘기면 안 되는 역할을 구분해야 한다.

Apps Script가 자연스러운 위치

스프레드시트 중심의 업무에서 Apps Script는 데이터 가까이에 있다.

예를 들어 다음 작업을 하기에 좋다.

• 폼 제출 시 후처리
• 입력값 정리
• 상태값 업데이트
• 특정 조건의 행 필터링
• 운영자용 메뉴 추가
• 외부 API 호출
• JSON 데이터 생성
• 정기 동기화 실행

이런 작업은 시트 데이터를 중심으로 움직인다. 별도 서버에서 Google Sheets API를 호출하는 것보다 Apps Script가 더 단순할 수 있다.

비즈니스 로직 엔진이라는 표현

여기서 말하는 비즈니스 로직 엔진은 거창한 의미가 아니다.

업무 규칙을 실행하는 위치라는 뜻이다.

예를 들어 신청 관리 업무에는 이런 규칙이 있을 수 있다.

• 신청 기간 안에 들어온 데이터만 처리한다.
• 특정 상태의 신청만 공개 데이터에 포함한다.
• 내부 메모나 개인정보는 공개 데이터에서 제거한다.
• 운영자가 확정한 결과만 외부 화면에 노출한다.
• 동기화 시 최신 데이터와 백업 데이터를 함께 만든다.

이 규칙이 대부분 Sheets 데이터 주변에서 실행된다면 Apps Script가 적절한 위치가 될 수 있다.

Apps Script가 잘하는 일

Apps Script의 장점은 명확하다.

첫째, Google 도구와 붙어 있다.

Forms, Sheets, Drive, Gmail 같은 도구와 연결이 쉽다.

둘째, 운영자가 실행하기 쉽다.

시트 메뉴에 "동기화 실행" 같은 버튼을 만들 수 있다.

셋째, 트리거가 있다.

폼 제출, 시간 기반 실행, 수동 실행을 조합할 수 있다.

넷째, 서버를 운영하지 않아도 된다.

작은 자동화에서는 이 장점이 크다.

Apps Script의 한계

반대로 한계도 명확하다.

• 실행 시간 제한이 있다.
• 테스트 체계가 약하다.
• 로컬 개발 경험이 일반 백엔드보다 불편하다.
• 타입 안정성이 약하다.
• 대량 데이터 처리에 약하다.
• 배포와 버전 관리가 느슨해지기 쉽다.
• 복잡한 인증과 권한 모델을 다루기 어렵다.

그래서 Apps Script에 모든 것을 넣으면 안 된다.

시트 주변의 업무 로직은 Apps Script에 두되, 외부 제공 API, 파일 서빙, 공개 화면, 무거운 처리 등은 다른 계층으로 나누는 것이 좋다.

Apps Script와 AWS를 나누는 기준

일반적으로 이렇게 나눌 수 있다.

역할	적합한 위치
폼 제출 후 시트 정리	Apps Script
운영자가 수동으로 실행하는 동기화	Apps Script
시트 데이터를 JSON으로 변환	Apps Script 또는 Lambda
S3 저장	Lambda
공개 API 응답	Lambda/API Gateway
정적 화면 제공	S3/CloudFront
장시간 작업	Lambda 또는 별도 worker

Apps Script는 Google 쪽 업무 로직을 맡고, AWS는 데이터를 안정적으로 제공하는 역할을 맡는다.

외부 API 호출 시 주의할 점

Apps Script는 UrlFetchApp으로 외부 API를 호출할 수 있다.

이 기능을 사용하면 시트 데이터를 AWS API로 보낼 수 있다.

하지만 다음을 조심해야 한다.

• API endpoint를 문서화한다.
• 인증 방식이 노출되지 않게 한다.
• 실패 시 재시도 방법을 둔다.
• 응답 결과를 로그로 남긴다.
• 대량 데이터는 한 번에 보내지 않는다.
• 실행 시간 제한을 고려한다.

외부 API 호출은 자동화의 경계다.

이 경계에서 실패하면 Google 쪽 데이터와 AWS 쪽 데이터가 달라질 수 있다.

수동 실행 경로를 남기기

자동화라고 해서 모두 자동 trigger에만 의존하면 안 된다.

운영자가 수동으로 다시 동기화할 수 있는 경로가 필요하다.

예를 들어 시트 메뉴에 다음 기능을 둘 수 있다.

• 최신 데이터 동기화
• 공개 캘린더 생성
• 월별 스냅샷 생성
• 특정 기간 데이터 재생성
• 동기화 상태 확인

수동 실행 경로는 자동화 실패 시 복구 수단이 된다.

작은 운영 시스템에서는 이 수동 복구 경로가 매우 중요하다.

Apps Script를 문서화하는 법

Apps Script는 시트와 가까워서 문서화가 소홀해지기 쉽다.

하지만 다음은 반드시 남겨야 한다.

• 어떤 trigger가 있는가
• 어떤 함수가 수동 실행용인가
• 어떤 시트와 컬럼을 참조하는가
• 어떤 외부 API를 호출하는가
• 실패 시 어디서 로그를 보는가
• 실행 시간 제한에 걸릴 가능성이 있는가
• 배포 후 trigger를 다시 설정해야 하는가

Apps Script는 코드 저장소 밖에서 관리될 때가 많다. 그래서 문서가 없으면 다음 담당자가 찾기 어렵다.

언제 Lambda로 옮길까

Apps Script에서 시작한 로직도 커지면 옮겨야 한다.

다음 조건이 생기면 Lambda나 별도 백엔드를 검토한다.

• 실행 시간이 자주 제한에 걸린다.
• 테스트가 필요한 복잡한 알고리즘이 생긴다.
• 외부 API 호출이 많아진다.
• 보안상 Google 계정 권한에 묶이면 안 된다.
• 배포와 버전 관리가 중요해진다.
• 여러 시스템에서 같은 로직을 재사용해야 한다.

처음부터 옮길 필요는 없다.

하지만 옮겨야 할 신호는 알고 있어야 한다.

정리

Apps Script는 작은 운영 자동화에서 훌륭한 비즈니스 로직 엔진이 될 수 있다.

특히 데이터 원천이 Google Sheets이고, 업무 규칙이 시트 주변에서 실행된다면 자연스러운 선택이다.

하지만 역할을 좁혀야 한다.

Apps Script는 입력 후처리, 상태 관리, 동기화 트리거에 강하다.

외부 서빙, 보안 경계, 장시간 처리, 복잡한 테스트가 필요한 로직은 다른 계층으로 분리하는 것이 좋다.

좋은 자동화는 한 도구에 모든 것을 넣는 것이 아니라, 각 도구가 잘하는 일을 맡기는 구조다.

함께 볼 GitHub 저장소

• workflow-automation-samples