Google 스프레드시트를 앱 백엔드/API로 쓰는 Zero Sheets

 (zerosheets.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Zero Sheets는 Google Sheets를 RESTful JSON API로 바꿔, 별도 백엔드 없이 프로토타입·웹사이트·앱에서 데이터를 다루게 해주는 서비스임
  • 생성된 엔드포인트에 HTTP 요청을 보내 데이터를 조회·조작할 수 있고, 인증 방식과 사용할 시트도 설정 가능함
  • 시작 흐름은 시트 URL 붙여넣기, API 구성, 엔드포인트로 요청 전송의 3단계라 초기 연결 부담을 줄임
  • 스프레드시트를 클라이언트용 CMS처럼 활용해 실제 데이터로 아이디어를 테스트하는 용도에 초점을 맞춤
  • 요금제는 무료 1개 API·월 200요청부터 월 $4.99 Scout, 월 $19.99 Craft까지 있으며 공개 요금제는 읽기·쓰기·수정·삭제를 포함함

Google Sheets를 RESTful API로 전환

  • Google Sheets 스프레드시트를 RESTful API로 변환해 간단한 HTTP 요청으로 데이터를 조회하고 조작할 수 있게 함
  • 개발자가 프로토타입, 웹사이트, 앱을 빠르게 만들 때 쓰는 도구를 표방함
  • API 구성 단계에서 인증 방식, 사용할 시트, 기타 설정을 지정할 수 있음
  • 사용 흐름은 3단계로 정리됨
    • Google Spreadsheet URL을 대시보드에 복사해 붙여넣음
    • 새 API의 인증 방식과 사용할 시트 등을 설정함
    • 엔드포인트를 받은 뒤 HTTP 요청을 보냄

CMS처럼 쓰는 활용 방식과 요금제

  • 스프레드시트를 실제 데이터 저장소처럼 활용해 아이디어를 테스트하고, 클라이언트가 사용할 수 있는 CMS 역할을 맡길 수 있음
  • 자체 백엔드 패널을 만드는 것보다 저렴하고 빠르게 아이디어를 구현할 수 있다는 점을 내세움
  • 공개 요금제는 다음과 같음
    • Free: $0/월, 1 API, 무제한 시트 탭, 읽기·쓰기·수정·삭제, 월 200요청
    • Scout: $4.99/월, 무제한 API, 무제한 시트 탭, 읽기·쓰기·수정·삭제, 월 400요청, 24/7 지원
    • Craft: $19.99/월, 무제한 API, 무제한 시트 탭, 읽기·쓰기·수정·삭제, 월 2000요청, 24/7 지원
  • 맞춤형 요금제는 별도 문의로 제공함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 현대판 Excel 초보 함정을 조심해야 함. 80~90년대 많은 투자은행이 여기에 빠졌는데, 스프레드시트는 범용 계산 프레임워크로 훌륭해서 위험 관리, 가격 산정, 운영 기능까지 거대한 Excel 파일 더미 위에 올리게 됐음
    플러그인과 확장을 붙이면 정말 많은 일을 할 수 있지만, 결국 스프레드시트가 유지보수 불가능하고 내부를 파악하기 어려운 악몽이 되며, 핵심 업무 로직이 여러 사람의 개인 시트에 갇힘. 광범위한 변경은 어렵거나 불가능해지고, 일반 소프트웨어 프레임워크라면 쉬웠을 변경도 수많은 시트를 고쳐야 해서 위험과 확인 비용이 커짐

    • 게임 개발의 비주얼 스크립팅에서도 매우 비슷한 상황이 생김. 원래는 디자이너나 아티스트가 프로그래머를 부르지 않고 압력판을 밟으면 문이 열리는 정도의 작은 작업을 하게 하려는 도구지만, 결과물이 쉽게 통제 불능으로 커짐
      Unreal Engine 사례만 모아둔 사이트도 있음: https://blueprintsfromhell.tumblr.com/. 개인적으로는 좋은 리팩터링 지원이 해법이라고 봄. 프로그래머가 들어가서 전체를 새로 쓰지 않아도 “메서드 추출” 같은 방식으로 정리할 수 있어야 함
    • 항상 선택의 문제가 아님. 직장에서 정책을 준수하는 Python hello world를 실행할 수 있는 환경을 얻는 데만 각종 절차로 4시간쯤 걸렸음
      완전한 IDE나 pip 모듈은커녕 그냥 hello world였고, 그나마 지금까지는 나은 편이었음. 일부 금융사는 애초에 다른 선택지를 주지 않음. 사무직에게 Excel만 주고는 사람들이 Excel로 괴물을 만들었다고 놀라는 게 흔한 패턴임
    • 전적으로 동의함. 지금 다니는 회사는 10년 넘게 스프레드시트와 데이터베이스 쿼리 내보내기 파이프라인의 얽힌 구조를 리팩터링하지 않았고, 확장되지 않아서 지금 돈이 줄줄 새고 있음
      이런 문제는 전부 무너질 때까지 잘 드러나지 않음. 스프레드시트에서 동시에 작업하는 건 가장 위험한 일에 가깝기 때문에 모든 핵심 프로세스에 병목이 생김. 데이터 통합은 위험하고 오래 걸리며, 스프레드시트 간 일관성을 보장하기도 어려움. 더 일찍 적절한 도구로 옮겼다면 필요 없었을 코드로 계속 땜질하게 됨
    • “광범위한 변경이 어렵거나 불가능해진다”에 더해, 버전 관리가 없음
      스프레드시트를 RCS에 저장할 수는 있겠지만, 푸시하려는 변경이 의도한 내용인지 확인할 diff를 볼 수 있는가? 시간이 지나며 시스템이 어떻게 바뀌었는지 diff 이력을 검토할 수 있는가? 여러 사람이 변경하면 병합할 수 있는가? 실험용 작업 사본이라도 따로 있는가, 아니면 안전장치 없이 운영 사본을 직접 편집하는가?
    • 시트를 저장소로만 쓰는 건 괜찮을지도 모름. 다만 크기 제한이 어느 정도인지 궁금함

  • 재미있는 얘기임. 스타트업을 Loom으로 피벗하기 전에는 Opentest라는 사용자 테스트 회사였는데, 공동창업자들이 특정 사용자 테스트 요청자를 볼 수 있게 데이터베이스와 대시보드를 만들지 않고 그냥 전부 Google Sheets에 넣었음
    아주 좋았음. 다운타임이 없고, 접근이 열려 있고, 보는 사람과 편집자가 3명뿐이라 충돌도 없었음. 데이터베이스 업그레이드나 유지보수를 다룰 필요도 없었음. 이 결정을 자주 떠올리는데, 내가 배운 “좋은 엔지니어링 관행” 상당수가 진짜로 빠르고 실용적으로 움직이는 것이 어느 단계에서든 천재적인 돌파구가 될 수 있다는 사실에 비하면 빛이 바랜다고 느낌

    • 동의함. Google Sheets는 스타트업이나 작은 회사에서 빠르게 버티기 좋은 선택지임
      극소수만 수정하면 되는 여러 시스템 데이터에 써봤음. 약간의 신중한 코드와 캐싱만 있으면, 예를 들어 검증 후 S3에 동기화하는 방식으로 중요한 시스템 데이터의 CRUD 프런트엔드로 쉽게 쓸 수 있음. 임시 대시보드로도 좋고, API에 연결하거나 맞춤 Google Scripts 코드를 붙이면 비공개 API도 다룰 수 있음. 여러 뷰, 피벗 테이블, 쿼리, 조회를 포함한 꽤 큰 보고서를 일정에 맞춰 자동 갱신한 적도 있음. 맞춤 개발물이 Google Sheets보다 훨씬 좋아야 하는 건 맞지만, 더 빨리 만들 수는 없음. 더 크고 좋은 무언가가 필요해질 때쯤이면 요구사항도 더 선명해지고 개발 자원을 감당할 수 있는 상태가 되어 있을 것임
    • 대기업 소프트웨어 엔지니어지만, 내가 작업하는 여러 프로젝트의 기반이 Google Sheets임. 어떤 곳에서는 프런트엔드로, 다른 곳에서는 백엔드로 씀
      React나 Postgres 같은 단순한 엔지니어링 도구를 쓰는 데도 절차가 너무 많기 때문이기도 함
    • Google Sheets는 관리 UI가 내장된 관리형 NoSQL 데이터베이스로 볼 수도 있음
    • 한 방향 데이터 덤프만 가능하다면 좋은 아이디어로 들림. 문제는 일곱 개의 시트가 다른 프로세스들을 authoritative하게 제어해야 할 때 시작됨
      스프레드시트에 쓰는 사람은 사실상 어떤 변형도 할 수 있으므로 매우 쉽게 깨짐
    • 괜찮아 보이지만, 회사 데이터를 Google Sheets에 넣기 전에 먼저 허가를 받아야 함

  • 굳이 화려한 래핑이 필요하지 않음. https://script.google.com/만 열면 이미 Google의 여러 API에 접근할 수 있고, 시트를 Gmail로 이메일 보내기, 캘린더 변경, 페이지 생성, 폼 입력 처리 등에 통합할 수 있음
    문제는 실제 데이터베이스처럼 트랜잭션 기반 작업이 없다는 점임. 예를 들어 특정 리소스를 잠그고 싶을 때 실패할 수 있음

    • 이 사이트에서는 누군가 어떤 문제에 대해 단순한 해법을 만들 때마다, 다른 누군가가 이미 훨씬 복잡한 선택지가 있다고 말함

  • 아직 아무도 Spread API를 올리지 않은 게 의외임: https://spreadapi.roombelt.com/
    무료 Google Sheets / Apps Script이고, 시트에 붙여넣기만 하면 완전한 CRUD로 바꿔줌. 다만 속도 제한이 좀 있지만 완전히 무료임. 예전에 Sheets 기반 회사를 생각해본 적이 있는데, “돈을 낼 의향이 있는” 단계에 이르면 대체로 Sheets를 넘어서는 시점이기도 함. 제약 때문에 Sheets나 SpreadAPI에 머무르기보다 Turso, Cloudflare D1, Pocketbase로 옮기고 싶어짐

    • 내 작은 프로젝트가 유용하게 쓰인다니 정말 기쁨
      개선 아이디어나 PR은 언제든 여기로 올릴 수 있음: https://github.com/ziolko/spreadapi
    • 좋아 보임. 다만 한 요청에서 여러 줄 삽입조차 못 하는 것 같아서 꽤 제한적으로 보임
    • Spread API 속도 제한이 어떻게 되는지 궁금함. 사이트에서는 정보를 찾지 못했음

  • 비슷한 용도라면 PocketBase를 추천하고 싶음
    지난주 API 접근이 가능한 임의 데이터 저장소를 찾다가 Google Sheets 백엔드를 만들까 했는데, PocketBase는 쉽고 분당 60회 제한도 없었음. 저렴한 VPS에 CapRover로 배포하는 것도 아주 쉬웠음
    https://pocketbase.io/
    https://developers.google.com/sheets/api/limits

    • PocketBase에 한 표. 일반적인 데이터 수집에는 PocketBase를 쓰고, API로 CSV를 내보내 Google Sheet로 옮겨 보기와 편집에 사용함
      프로토타이핑과 실제 작업 처리에 아주 쉽고, Google Sheet를 백엔드로 쓰는 것도 좋지만 인증 같은 것이 필요했음
    • PocketBase를 살펴봤지만 어떻게 써야 하는지 잘 이해하지 못했음. SQLite도 알고 SQL도 잘하지만, 실제로 어떻게 사용해야 할지 감이 오지 않았음
    • 내 인프라는 확장성에 100% 초점을 맞추고 있어서 같이 일할 수 있을 것 같음. 비용만 나누면 됨
      연락처를 받을 수 있게 여기로 메시지를 보내주면 좋겠음: https://www.zerosheets.com/contact

  • 최근 AppsScript와 Google Sheets만 데이터베이스로 사용해 완전한 웹앱을 만들었고, 여기 https://thetechenabler.substack.com/i/142898781/making-a-sim...에 글을 썼으며 여기 https://github.com/eeue56/simple-link-aggregator에 공개했음
    새로운 경험이었고, 특히 비개발자가 쉽게 다룰 수 있는 데이터 저장소를 두면서 앞에는 서버 설정이 필요 없는 웹앱을 붙인다는 아이디어가 매력적이었음. 하지만 AppsScript는 이런 용도로 쓰기에는 너무 느려서 좋은 경험이 되기 어려움. Zerosheets는 좋아 보이고, 이 아이디어를 다시 보게 되면 더 살펴볼 생각임

    • “비개발자가 쉽게 다룰 수 있는 데이터 저장소에 웹앱을 붙이고 서버 설정은 필요 없게 하는 것”은 Airtable의 사용 사례 중 하나 아닌가?

  • 다음 사용자 스크립트 프로젝트 아이디어에 이런 것이 필요함. 개인 용도지만, 엄청나게 고통스러운 웹 UI로 성적표를 채워야 함
    데이터는 스프레드시트에 입력하는 편이 훨씬 쉬움. 예전에는 실제로 그렇게 했는데, 학교가 “더 쉽게” 만들겠다며 아주 기본적인 CRUD 웹앱의 끔찍한 패러디 같은 것을 도입했음. 그래서 스프레드시트에서 읽어 쓰기 불편한 웹 폼을 채우는 사용자 스크립트를 만들고 싶음. 아직 시작하지 못한 이유는 이전 사용자 스크립트 경험 블로그 글도 못 끝냈고, 인증 악몽이 두렵기 때문임. 사용자 스크립트 맥락에서는 더 쉬울 수도 더 어려울 수도 있는데, 웹 페이지 안에 있으니 거기서 일반 OAuth 흐름 같은 걸 할 수 있을지도 모름

    • Apps Script를 확인해봤는지 궁금함
    • Google Sheets를 쓴다면 일반적인 OAuth 흐름을 해야 할 것임. 대안으로 Excel을 쓰고 간단한 매크로로 자동화할 수도 있음
      개인적으로 가장 쉬운 방법은 스크립트의 복잡한 부분인 인증을 건너뛰고, 클립보드에서 값을 복사해 붙여넣은 뒤 데이터를 처리하는 것이라고 봄

  • 며칠 전 템플릿과 CMS 대안을 살펴보다가, 데이터·차트·시각화가 있는 기사를 발행하기 위한 NPR의 내부 도구 https://github.com/nprapps/dailygraphics-next를 발견했음
    거기에 Google Sheets를 CMS로 쓰는 방식이 포함돼 있어서 흥미로웠음

  • https://github.com/kellpossible/avalanche-report/에서 매우 비슷한 걸 했음. 데이터 입력 흐름을 빠르게 반복할 수 있어서 Google Sheets로 시작했음
    서버와 함께 쓰면 구성한 URL 쿼리를 IMAGE 함수에 넣어 맞춤형 차트와 다이어그램도 만들 수 있었음. 읽기는 로컬 SQLite 데이터베이스에 캐시함. 지금은 Google Sheets에서 벗어나는 중인데, 설정이 조금 번거롭고 우리 사용 사례에서는 사용자가 잘못된 필드를 편집하는 것을 완전히 막을 수 없기 때문임. 그래도 지금까지는 아주 잘 버텨줬고, 시작점으로는 누구에게나 강력히 추천할 만함

  • 예전에 레스토랑 웹사이트의 메뉴 페이지를 Google Sheet로 구동했음. 완벽했음
    레스토랑이 무언가 바뀔 때마다 스프레드시트를 업데이트하면 웹에 즉시 반영됐고, 뭔가 잘못 건드리면 되돌리면 됐음

    • 몇 주 전에 레스토랑에 정확히 같은 걸 설정했음. 단순하고 무료였음
      Apps Script가 업데이트 시 사이트를 빌드하도록 만들었고, 그래서 언제든 편집하면 재빌드가 트리거되어 정적 사이트로 다시 배포됐음
답변달기