Google Sheets를 활용해 AWS Serverless로 초고속 REST API를 만든 방법
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article, I’ll keep the source link unchanged at the top and translate the rest into Korean while preserving all formatting, markdown, and code blocks.
소개
우리 모두 그런 경험이 있습니다: 프로토타입, 내부 도구, 혹은 NoCode 프로젝트를 위해 빠른 백엔드가 필요할 때. PostgreSQL이나 MongoDB를 설정하는 것이 과도하게 느껴져서 “그냥 Google Sheets를 데이터베이스로 쓰면 되겠지!” 라고 생각하게 됩니다.
그 생각은 Google Sheets API의 현실을 마주하기 전까지는 멋져 보이지만:
- 느리다 (요청당 보통 1–2 초 정도 소요).
- 요청 제한이 엄격하다 (사용자당 분당 약 60건).
- 고유한 쿼리 언어가 없다 (데이터 필터링이 번거롭다).
저는 Google Sheets의 간편함은 유지하면서 실제 백엔드 수준의 성능과 보안을 원했습니다. 그래서 이러한 문제들을 정확히 해결해 주는 SheetToJSON이라는 서버리스 래퍼를 만들었습니다.
아키텍처 스택
- 라우팅: AWS HTTP API Gateway
- 컴퓨팅: AWS Lambda (Node.js ARM64)
- 캐싱: Amazon S3
- 보안 및 인증: Amazon DynamoDB
- 수익화 및 게이트웨이: RapidAPI
Challenge 1: Beating the Rate Limits and Latency
Google Sheets API의 가장 큰 병목 현상은 응답 시간입니다. 이를 해결하기 위해 Amazon S3를 사용한 적극적인 캐싱 전략을 구현했습니다.
사용자가 GET 요청을 할 때(예: 제품 목록을 가져오는 경우), Lambda 함수는 먼저 해당 시트의 캐시된 .json 버전이 있는지 S3 버킷을 확인합니다.
- Cache Hit: 데이터가 밀리초 단위로 반환됩니다.
- Cache Miss: Lambda가 Google Sheets에서 데이터를 가져와 원시 JSON을 S3에 저장하고(5분 TTL), 응답을 반환합니다.
데이터를 최신 상태로 유지하기 위해 write‑through cache를 추가했습니다: POST, PATCH, DELETE 요청이 Google Sheets 업데이트하고 동시에 로컬 S3 캐시를 즉시 다시 씁니다. 그 결과 신선도를 희생하지 않으면서도 번개처럼 빠른 GET 요청을 얻을 수 있습니다.
Challenge 2: Smart Querying (No Database Engine)
Google Sheets에는 SQL 엔진이 없습니다. 사용자가 가격이 $50보다 높은 모든 제품을 찾고 싶다면 보통 전체 시트를 다운로드하고 클라이언트 측에서 필터링해야 합니다.
나는 Lambda 함수 안에 맞춤형 쿼리 엔진을 직접 구축했습니다. S3 캐시에서 읽을 때, API가 쿼리 매개변수를 가로채어 메모리 내에서 처리합니다:
// Example: GET /v1/SPREADSHEET_ID/Products?price=gt:50&sort=price:desc
// The API engine automatically parses:
// "gt:" (greater than)
// "lt:" (less than)
// "lk:" (like/contains)
// before returning the paginated payload.이렇게 하면 단순한 스프레드시트를 쿼리 가능한 NoSQL‑유사 데이터베이스로 변환할 수 있습니다.
Challenge 3: Multi‑Tenant Security (Preventing IDOR)
SaaS를 구축하고 있다면 보안이 최우선 과제입니다. API가 단일 Google Service Account를 사용해 시트를 읽기 때문에, 사용자 A가 사용자 B의 Spreadsheet ID를 추측해 데이터를 읽는 것을 무엇이 막을까요?
이 Insecure Direct Object Reference (IDOR)를 방지하기 위해 DynamoDB를 백엔드로 하는 필수 /register 단계를 추가했습니다.
- 사용자가 자신의 시트를 등록하면, API가
X‑RapidAPI‑UserID와spreadsheetId를 DynamoDB에 연결합니다. - 모든 CRUD 요청은 빠른 (
~15 ms) DynamoDB 조회를 수행합니다. - 요청한 사용자 ID가 시트 소유자 ID와 일치하지 않으면, API는 403 Forbidden을 반환합니다.
데이터 유출 제로.
결과: 개발자 경험 우선
통합을 가능한 한 원활하게 만들고 싶었기 때문에, Node.js와 PHP용 공식 SDK를 의존성 없이 공개했습니다.
Node.js 예시 (TypeScript로 완전 타입 지정)
import { SheetToJSON } from 'sheettojson-api';
const db = new SheetToJSON('YOUR_RAPIDAPI_KEY');
const response = await db.get('SPREADSHEET_ID', 'Products', {
limit: 10,
price: 'gt:50'
});
console.log(response.data);직접 사용해 보기!
AWS Serverless 아키텍처를 탐험하는 놀라운 여정이었습니다. NoCode 도구를 만들든, 빠른 프로토타입을 만들든, 즉시 사용할 백엔드가 필요하든, 한 번 사용해 보세요.
현재 캐싱 시스템과 쿼리 엔진에 대한 피드백을 찾고 있습니다. 댓글로 여러분의 의견을 알려 주세요! 👇