Apps Script에서 S3로 직접 쓰지 않은 이유

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

Google Apps Script에서 AWS S3로 파일을 직접 업로드할 수도 있다.

이론적으로는 가능하다. AWS Signature Version 4 서명을 직접 만들고, S3 PUT 요청을 보내면 된다.

하지만 운영 자동화에서는 "가능하다"와 "좋은 선택이다"가 다르다.

나는 Apps Script가 S3에 직접 쓰는 방식보다, API Gateway와 Lambda를 경유해 S3 저장을 위임하는 구조가 더 낫다고 봤다.

문제 상황

스프레드시트의 데이터를 가공해 JSON 파일로 저장해야 했다.

이 JSON은 운영자 화면과 공개 페이지에서 읽을 데이터였다.

구조는 단순해 보인다.

Sheets
-> Apps Script
-> S3 JSON
-> Console/Public page

여기서 선택지는 두 가지다.

첫 번째는 Apps Script가 S3에 직접 업로드하는 것이다.

두 번째는 Apps Script가 API를 호출하고, Lambda가 S3에 업로드하는 것이다.

최종적으로 두 번째 방식을 선택했다.

직접 업로드 방식

직접 업로드 방식은 중간 계층이 적다.

장점은 단순해 보인다는 것이다.

• API Gateway가 필요 없다.
• Lambda가 필요 없다.
• Script가 바로 파일을 저장한다.

하지만 실제 구현은 생각보다 단순하지 않다.

S3에 직접 쓰려면 AWS 요청 서명이 필요하다. Apps Script 환경에서 Signature v4를 직접 구현하고, 자격증명을 관리하고, 오류 응답을 처리해야 한다.

운영 자동화의 중심 로직이 "신청 데이터를 어떻게 가공할까"가 아니라 "AWS 서명을 어떻게 만들까"로 옮겨가게 된다.

API Gateway + Lambda 경유 방식

경유 방식은 한 계층이 추가된다.

처음에는 복잡해 보일 수 있다.

하지만 책임이 나뉜다.

Apps Script는 데이터를 준비하고 API를 호출한다.

API Gateway는 외부 호출의 입구가 된다.

Lambda는 AWS 내부 권한으로 S3에 파일을 쓴다.

S3 자격증명은 Apps Script에 들어가지 않는다.

자격증명을 어디에 둘 것인가

가장 큰 이유는 자격증명이다.

Apps Script에 AWS Access Key와 Secret Key를 넣으면 관리 지점이 애매해진다.

• 누가 볼 수 있는가
• 권한 범위는 어디까지인가
• 로그나 복사본에 노출될 가능성은 없는가
• 여러 사람이 Script를 수정할 때 안전한가

반면 Lambda에 IAM Role을 부여하면 구조가 단순해진다.

Lambda는 필요한 S3 bucket에만 쓰기 권한을 가진다.

Apps Script는 AWS 자격증명을 알 필요가 없다.

외부 도구와 AWS 사이에 API 경계를 두는 것이 보안상 더 낫다.

비즈니스 로직과 인프라 권한 분리

Apps Script가 해야 할 일은 업무 데이터 준비다.

• 시트에서 필요한 행을 읽는다.
• 상태값을 기준으로 필터링한다.
• 공개용 데이터에서 민감한 정보를 제거한다.
• 동기화 API로 보낸다.

Lambda가 해야 할 일은 AWS 내부 작업이다.

• 요청 데이터를 검증한다.
• JSON 파일을 저장한다.
• 최신 데이터와 백업 데이터를 나눠 쓴다.
• 필요한 응답을 반환한다.

이렇게 나누면 각 계층의 책임이 명확해진다.

Apps Script가 AWS 세부 구현을 몰라도 된다.

Lambda가 Google Sheets의 UI나 운영자 메뉴를 몰라도 된다.

실패 처리도 쉬워진다

API를 경유하면 실패 지점이 명확해진다.

Apps Script 입장에서는 API 호출이 성공했는지 실패했는지만 보면 된다.

Lambda는 S3 저장 중 발생한 오류를 CloudWatch Logs에 남길 수 있다.

API Gateway는 호출 로그와 상태 코드를 남길 수 있다.

직접 S3 업로드 방식에서는 오류 처리와 로깅을 Apps Script 안에 더 많이 구현해야 한다.

작은 자동화에서는 로깅과 재시도 구조가 단순한 편이 좋다.

데이터 검증 위치

API Gateway와 Lambda를 두면 데이터 검증 위치도 생긴다.

예를 들어 Lambda에서 다음을 확인할 수 있다.

• 필수 필드가 있는가
• 공개용 데이터에 민감한 필드가 남아 있지 않은가
• 월 정보가 올바른 형식인가
• 파일 경로가 허용된 패턴인가
• 요청 크기가 과하지 않은가

Apps Script에서도 검증할 수 있지만, 외부에서 들어오는 요청의 최종 방어선은 AWS 쪽에 있는 편이 좋다.

비용과 복잡도

API Gateway와 Lambda를 추가하면 비용이 생긴다.

하지만 작은 운영 자동화에서는 호출량이 많지 않다면 비용은 매우 낮다.

대신 얻는 것이 있다.

• AWS 자격증명 보호
• S3 권한의 최소화
• 호출 로그
• 에러 추적
• 요청 검증
• 추후 클라이언트 확장 가능성

이 정도 이점이면 경유 계층을 둘 만하다.

언제 직접 업로드가 괜찮을까

직접 업로드가 항상 나쁜 것은 아니다.

다음 조건이라면 검토할 수 있다.

• 완전히 개인용 자동화다.
• 자격증명 관리 위험이 낮다.
• 업로드 대상이 임시 bucket이다.
• 실패해도 운영 영향이 거의 없다.
• AWS 서명 구현을 이미 검증했다.

하지만 여러 사람이 쓰는 운영 업무라면 API 경계를 두는 편이 안전하다.

정리

Apps Script에서 S3로 직접 쓰지 않은 이유는 기술적으로 불가능해서가 아니다.

책임과 권한을 분리하기 위해서다.

Apps Script는 Google Workspace 주변의 업무 로직을 맡는다.

Lambda는 AWS 내부 권한으로 S3 저장을 맡는다.

API Gateway는 그 사이의 경계가 된다.

운영 자동화에서 좋은 구조는 가장 짧은 경로가 아니라, 실패했을 때 추적 가능하고 권한이 안전하게 나뉜 경로다.

함께 볼 GitHub 저장소

• workflow-automation-samples