Google Sheets를 Source of Truth로 둘 수 있는 조건

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

스프레드시트를 데이터 원천으로 쓴다고 하면 불안하게 들릴 수 있다.

개발자 입장에서는 데이터베이스가 더 자연스럽다. 스키마가 있고, 권한이 있고, 쿼리가 있고, 트랜잭션도 있다.

하지만 모든 운영 자동화에 RDB가 필요한 것은 아니다.

특정 조건에서는 Google Sheets가 Source of Truth, 즉 원천 데이터 저장소 역할을 할 수 있다.

중요한 것은 스프레드시트를 무작정 쓰는 것이 아니라, 어떤 조건에서 가능한지 명확히 아는 것이다.

Source of Truth란 무엇인가

Source of Truth는 같은 정보가 여러 곳에 있을 때 "원본으로 인정하는 곳"이다.

운영 자동화에서는 데이터가 여러 곳에 복제될 수 있다.

• 폼 응답
• 스프레드시트
• S3 JSON
• 운영자 화면
• 공개 페이지
• 월별 백업 파일

이때 어디를 원본으로 볼지 정해야 한다.

원본이 명확하지 않으면 문제가 생긴다.

화면에 보이는 JSON을 수정했는데 다음 동기화 때 덮어써질 수 있다. 공개 페이지의 데이터가 틀렸는데 어디를 고쳐야 할지 모를 수도 있다.

Sheets가 원천이 될 수 있었던 이유

스프레드시트를 Source of Truth로 둘 수 있는 조건은 대략 이렇다.

• 데이터 양이 많지 않다.
• 입력 이후 사람이 검토해야 한다.
• 운영자가 직접 상태를 확인하고 수정해야 한다.
• 복잡한 검색이나 조인이 필요하지 않다.
• 강한 동시성 제어가 필요하지 않다.
• 외부 화면은 읽기 전용 캐시 데이터를 보면 된다.

이 조건에서는 RDB를 추가하는 것이 오히려 복잡도를 높일 수 있다.

데이터베이스를 만들면 스키마, 마이그레이션, 관리자 화면, 권한, 백업, 운영 책임이 생긴다.

반면 Sheets는 운영자가 이미 데이터를 보는 곳이고, 간단한 수정과 검토가 쉽다.

Sheets를 원천으로 둘 때의 구조

일반적인 흐름은 다음과 같다.

여기서 중요한 점은 S3 JSON이 원본이 아니라는 것이다.

S3 JSON은 화면 제공을 위한 읽기 모델이다.

원본 수정은 Sheets에서 한다.

이 원칙이 흔들리면 데이터가 꼬인다.

RDB를 쓰지 않는 것이 설계 결정인 이유

RDB를 쓰지 않는 것은 단순히 비용을 아끼는 선택이 아니다.

그 자체로 설계 결정이다.

예를 들어 이런 판단이 필요하다.

• 이 데이터에 트랜잭션이 필요한가
• 여러 사용자가 동시에 수정하는가
• 복잡한 조회 조건이 필요한가
• 데이터 크기가 얼마나 커질 것인가
• 운영자가 DB보다 Sheets에서 일하는 것이 더 자연스러운가
• 외부 공개 화면은 실시간 원본이 필요한가, 캐시로 충분한가

이 질문에 답한 뒤에야 "Sheets로 충분하다"고 말할 수 있다.

Sheets의 장점

Sheets를 원천으로 두면 장점이 있다.

첫째, 운영자가 바로 이해할 수 있다.

데이터베이스 테이블보다 스프레드시트는 비개발자에게 친숙하다.

둘째, 수동 보정이 쉽다.

운영 업무에는 예외가 많다. 특정 신청을 확인하고 상태를 바꾸거나, 메모를 남기거나, 임시로 값을 보정해야 할 때가 있다.

셋째, 업무 흐름과 데이터가 가까이 있다.

폼 응답, 운영 검토, 상태 변경이 같은 공간에서 일어난다.

넷째, 초기 구축 비용이 낮다.

별도 관리자 화면을 만들지 않아도 기본적인 조회와 수정이 가능하다.

Sheets의 한계

하지만 한계도 분명하다.

• 스키마 강제가 약하다.
• 컬럼명이 바뀌면 스크립트가 깨질 수 있다.
• 동시 수정 충돌 관리가 어렵다.
• 대량 데이터 처리에 적합하지 않다.
• 권한 모델이 세밀하지 않다.
• 테스트와 배포 체계가 약하다.
• 변경 이력은 있지만 애플리케이션 수준의 감사 로그와는 다르다.

그래서 Sheets를 원천으로 쓴다면 문서화가 중요하다.

어떤 컬럼은 바꾸면 안 되는지, 어떤 상태값이 유효한지, 어떤 시트가 원본인지 명확히 적어야 한다.

S3 JSON으로 읽기 모델 만들기

Sheets를 원천으로 두더라도 화면이 매번 Sheets를 직접 읽게 할 필요는 없다.

대신 자동화 스크립트가 데이터를 가공해 S3 JSON으로 저장한다.

예시:

console-data-bucket/
├── latest/data.json
├── monthly/data-YYYY-MM.json
├── public/calendar-YYYY-MM.json
└── audit/YYYY-MM/YYYY-MM-DD/sync-HHMMSS.json

이 구조에는 역할이 있다.

• latest: 운영자 화면이 빠르게 읽는 최신 데이터
• monthly: 월별 조회나 기록 보존용 스냅샷
• public: 개인정보를 제거한 공개용 데이터
• audit: 문제가 생겼을 때 되돌아볼 백업

원천은 Sheets지만, 서비스 화면은 읽기 좋은 형태의 JSON을 본다.

언제 DB로 옮겨야 하는가

Sheets로 시작했더라도 영원히 유지해야 하는 것은 아니다.

다음 조건이 생기면 DB 전환을 검토해야 한다.

• 데이터가 수만 건 이상으로 커진다.
• 여러 사용자가 동시에 자주 수정한다.
• 상태 변경 이력을 엄격히 남겨야 한다.
• 복잡한 검색과 필터가 필요하다.
• 권한이 사용자별로 달라진다.
• 외부 API가 원천 데이터를 직접 수정해야 한다.
• 성능 문제가 반복된다.

좋은 설계는 처음부터 큰 DB를 쓰는 것이 아니라, 전환 조건을 알고 시작하는 것이다.

정리

Google Sheets는 항상 임시 도구가 아니다.

조건이 맞으면 Source of Truth가 될 수 있다.

다만 조건이 중요하다.

• 데이터 규모가 작다.
• 사람이 검토해야 한다.
• 운영자가 직접 수정하는 것이 자연스럽다.
• 복잡한 동시성이나 권한이 필요하지 않다.
• 화면 제공은 캐시된 JSON으로 충분하다.

이 조건에서는 RDB를 추가하지 않는 것이 더 단순하고 운영하기 쉬운 선택일 수 있다.

중요한 것은 원천과 캐시를 구분하는 것이다.

Sheets가 원천이고, S3 JSON은 읽기 모델이다.

이 경계만 명확하면 스프레드시트 기반 자동화도 충분히 실무적인 구조가 될 수 있다.

함께 볼 GitHub 저장소

• workflow-automation-samples