바이브코딩 웹앱 3편 - 구글시트에 운영 기록 남기기
웹앱에 데이터가 생기기 시작하면 데이터베이스부터 떠올리기 쉽다. 하지만 초기에는 누가 무엇을 만들었는지, 어떤 결과가 나왔는지 빠르게 확인하는 일이 더 중요할 때가 많다. 세븐핑거스의 sfs_apps Nblog Studio는 생성 패키지의 운영 이력을 Google Sheets에 남긴다. 작은 팀이 직접 열어 보고 수정 이력을 확인해야 하는 흐름이라면, 스프레드시트가 가벼운 기록 저장소 역할을 할 수 있다.
시트는 데이터 구조부터 정한다
스프레드시트에 값을 아무 순서로 쌓으면 나중에 검색과 점검이 어려워진다. Nblog Studio의 blog_packages 시트는 id, 생성 시각, 주제, 키워드, 제목, 태그, 점수, 선택 이유, 조사 요약, 이미지 수, 상태 같은 열을 둔다. 한 번 생성한 결과를 다시 확인할 때 제목만 찾는 대신, 어떤 입력에서 어떤 패키지가 나왔는지까지 볼 수 있다.
이 방식은 “한 행이 하나의 작업 기록”이라는 규칙이 명확할 때 특히 편하다. 상태 열로 초안·검토·완료를 구분하고, 고유 ID로 프런트의 상세 화면과 연결하면 된다. 데이터가 적을 때는 사람이 시트를 열어 필터를 걸어 보는 것만으로도 운영 상황을 파악할 수 있다. 다만 여러 사용자가 동시에 복잡한 관계 데이터를 수정하거나 권한 규칙이 많아지면 전문 데이터베이스가 더 적합하다.
서비스 계정은 브라우저에 두지 않는다
Google Sheets API를 코드에서 쓰려면 인증이 필요하다. sfs_apps는 서비스 계정 JSON과 시트 ID를 Cloudflare Worker 시크릿으로 보관하고, Worker가 Google 인증 토큰을 만든 뒤 Sheets API에 행을 추가한다. 대상 스프레드시트는 서비스 계정 이메일에 편집 권한을 따로 부여해야 한다. 이 권한이 빠지면 앱 화면은 정상처럼 보여도 저장 단계에서 실패할 수 있다.
서비스 계정 JSON을 프런트 번들에 넣는 것은 API 키를 노출하는 것과 마찬가지로 피해야 한다. 화면은 Worker에게 필요한 값만 보내고, Worker가 인증과 저장을 맡는다. 저장 실패를 단순히 숨기기보다, 사용자에게 실패 상태를 알려 주고 Worker 로그에서 권한·시트 ID·열 순서를 확인할 수 있게 해 두는 편이 운영에 유리하다.
스프레드시트가 맞는 범위
Google Sheets는 사람이 바로 열어 보는 운영 로그, 소규모 목록, 수동 검토가 섞인 흐름에 잘 맞는다. 반면 트랜잭션 처리, 복잡한 검색, 동시 수정 충돌, 민감한 개인정보를 대량으로 다루는 서비스의 주 데이터베이스로는 한계가 있다. 무료 티어 기반으로 시작하더라도 데이터량과 접근 권한이 늘면 DB 이전 기준을 미리 정해 두는 편이 좋다.
운영자 실전 노트
세븐핑거스(Seven Fingers Studio)는 Nblog Studio에서 생성 결과를 바로 공개하지 않고, blog_packages 시트에 패키지 이력을 남긴 뒤 사람이 검토한다. 이 구조에서는 시트의 열 이름과 Worker가 보내는 값 순서가 계약처럼 작동한다. 열을 바꾸는 날에는 테스트 기록 한 건을 먼저 저장해 보고, 조회 화면에서 같은 값이 읽히는지 확인하는 절차가 필요했다.
FAQ
Q. Google Sheets를 앱 데이터베이스로 계속 써도 되나요?
작고 단순한 운영 기록에는 실용적이다. 사용자 수와 동시 수정, 관계형 조회가 늘어나면 전용 데이터베이스로 옮길 시점을 검토해야 한다.
Q. 시트 공유는 누구에게 해야 하나요?
작업자가 아니라 Worker가 사용하는 서비스 계정 이메일에 필요한 최소 권한을 부여한다. 서비스 계정 JSON 파일 자체를 메일이나 프런트 저장소에 공유하면 안 된다.