구글 스프레드시트로 업무 앱, 쉬움 뒤에 숨은 책임
학교 현장에서 반복되는 업무 요청, 각종 신청서 취합, 간단한 장부 관리. 당신도 매번 비슷한 고민에 빠졌을 것이다. 전문 업체에 맡기자니 예산이 없고, 그렇다고 없는 기능을 만들자니 엄두가 나지 않는다. 그렇다면 구글 스프레드시트로 업무용 웹앱을 직접 만드는 방식은 어떨까? AI 도구의 도움을 받아 현실적인 대안이 된다. 하지만 쉬운 길 뒤에는 예상치 못한 난관과 책임이 도사린다.
구글 스프레드시트, 만능 데이터베이스는 아니다
우리에게 익숙한 구글 스프레드시트는 원래 표 계산 도구이다. 하지만 Google Apps Script와 결합하면 단순한 표를 넘어 데이터 저장, 조회, 수정 기능을 갖춘 간이 데이터베이스처럼 활용할 수 있다. 여기에 React나 HTML 기반 웹앱을 붙이면 사용자는 스프레드시트를 직접 보지 않고도 깔끔한 앱 화면에서 데이터를 처리한다. 이 구조는 전문 서버 구축 부담 없이 소규모 기관이나 개인 프로젝트에서 시작하기 좋다.
하지만 이 방식에는 명확한 한계가 존재한다. 구글 스프레드시트는 진정한 의미의 관계형 데이터베이스가 아니다. 데이터량이 늘어나면 필연적으로 느려지고, 복잡한 쿼리를 처리하지 못한다. 특히 민감 정보를 다룰 때는 법적, 보안적 문제가 불거진다. 처음부터 “쉽게 만든다”는 생각보다는 “망가지지 않게 만든다”는 관점으로 접근해야 한다. 앱이 수백, 수천 건의 데이터를 다룰 때 어떤 문제가 발생하는지는 직접 경험해본 사람만 안다.
표 1. 구글 스프레드시트 기반 앱의 장단점
| 구분 | 장점 | 단점 |
|---|---|---|
| 개발 | 낮은 초기 비용, 전문 개발 지식 없이 시작 가능, 빠른 구현 | 데이터 구조 복잡도 증가, 코드 안정성 확보 어려움 |
| 성능 | 소규모 데이터 처리 효율적 | 대규모 데이터 시 검색 및 로딩 속도 저하, Apps Script 호출 제한 |
| 보안 | Google Workspace 기본 보안 제공 | 민감 정보 처리 시 법적·보안적 검토 필수, 데이터 저장 지역 제한 |
| 확장성 | 초기 개발 용이 | 실제 데이터베이스 이전 시 구조 변경 부담, 기능 제한 |
AI 도구, 단순 코딩 보조 역할에 그치지 않는다
현재 AI 도구, 특히 챗GPT의 유료 구독은 단순한 코드 생성기를 넘어선다. 앱 개발 과정에서 코드를 작성하는 것보다 더 중요한 일이 있기 때문이다.
- 구현 계획 수립: 기능 누락 없이 전체 그림을 그린다.
- 문제 원인 분석: 코드가 꼬였을 때 원인을 파악한다.
- 검증 및 수정: 프로젝트 파일을 업로드해 오류를 찾고, 수정 프롬프트를 만든다.
- 구조적 안정성 확보: 전체 앱 구조가 무너지지 않았는지 확인한다.
챗GPT는 기획자이자 검수자 역할을 훌륭히 수행한다. 프로젝트 ZIP 파일, 빌드 로그, Git diff, 오류 메시지 등을 올려 검증받는 기능은 실로 강력하다. 물론 Claude Code도 뛰어나지만 사용량 제한이 따르고, Gemini 계열 도구는 대규모 코드 검토나 파일 업로드에서 불편함을 준다. 개인적인 경험으로는 챗GPT로 계획과 검증을 진행하고, Codex나 Claude Code로 실제 구현하는 방식이 가장 안정적이었다.
이러한 협업 구조는 AI에게 “앱 하나 만들어줘”라고 맡기는 방식과 본질적으로 다르다. 사람이 목적과 기준을 명확히 설정하고, AI는 이를 바탕으로 계획 수립, 구현, 검증의 과정을 돕는 구조다. 이는 단순한 도구 활용을 넘어, 인간과 AI의 공진화적 작업 흐름을 구축하는 일이다.
구현 계획, 화면보다 데이터 구조가 먼저다
앱 개발의 가장 중요한 단계는 코딩이 아니라 구현 계획 수립이다. 계획이 허술하면 나중에 기능을 추가할 때마다 앱 전체가 무너지는 경험을 한다. 특히 구글 스프레드시트를 데이터베이스로 쓸 때는 데이터 구조 설계가 핵심이다.
예를 들어, 전자결재 시스템을 만든다고 가정해보자. 단순히 “문서 제목, 작성자, 내용, 결재 상태”만 생각하면 오산이다. 실제 현장에서는 작성 부서, 결재자, 반려 사유, 수정 이력, 삭제 여부, 권한 분리 같은 더 많은 정보가 필요하다. 이런 요소들을 나중에 덧붙이면 앱 구조는 복잡해진다.
여기서 핵심적인 실무 팁이 나온다. 빈 구글 스프레드시트 링크를 챗GPT나 Codex에 제공하고, 앱에 필요한 시트와 컬럼 구조를 설계하게 한다. AI는 흔히 빠뜨리기 쉬운 고유 ID, 생성일, 수정일, 삭제 여부, 상태값, 로그 ID 같은 중요한 컬럼들을 제안한다. 나아가, Apps Script에서 한 번 실행하면 필요한 시트와 컬럼이 자동으로 생성되는 initializeSheets() 함수까지 만들어달라고 요청하는 것이 현명하다. 이 함수는 시트가 없으면 만들고, 컬럼이 누락되면 추가하되, 기존 데이터는 건드리지 않도록 설계한다.
이 방식은 단순히 편의성만을 위한 것이 아니다. 데이터 구조를 코드로 관리하기 때문에 유지보수가 용이하고, 나중에 실제 데이터베이스로 이전할 때 각 시트가 어떤 테이블 역할을 했는지 명확히 파악할 수 있다. 앱의 뼈대가 되는 데이터 구조는 화면 설계보다 우선해야 마땅하다.
데이터베이스 이전 가능성을 열어두는 설계
구글 스프레드시트의 장점은 쉬움이지만, 가장 큰 단점은 확장성의 한계이다. 처음에는 데이터가 몇백 건 수준이라 문제가 없다. 하지만 기관 업무는 데이터가 계속 쌓여 몇 달 만에 수천 건, 몇 년 안에 수만 건이 된다. 이때 스프레드시트를 데이터베이스처럼 계속 쓰면 다음과 같은 문제가 발생한다.
- 검색 및 대시보드 로딩 속도 저하
- Apps Script 호출 제한 또는 실행 시간 초과
- 동시 사용자 증가 시 저장 충돌 및 지연
바로 이 지점에서 낙관과 경계를 동시에 쥐어야 한다. 구글 스프레드시트로 시작하되, 나중에 실제 데이터베이스(Supabase, Firebase, PostgreSQL 등)로 이전하기 쉽게 설계해야 한다. 이를 위해서는 앱 전체에서 직접 Apps Script URL을 여러 곳에 하드코딩하는 대신, dataService, apiClient, repository 같은 데이터 접근 계층을 분리해야 한다. 앱 화면은 이 계층으로만 데이터를 요청하게 만든다.
이렇게 하면 지금은 구글 스프레드시트를 사용해도, 나중에 데이터베이스를 바꿀 때 앱 화면 전체를 갈아엎지 않아도 된다. 당장은 복잡해 보여도, 업무용 앱은 오래 쓸수록 이런 구조적 견고함이 결정적인 차이를 만든다.
대시보드와 검색, 요약과 효율성이 먼저다
AI에게 앱을 만들게 하면 종종 멋진 대시보드를 만들어내지만, 이것이 항상 좋은 것은 아니다. 대시보드에서 모든 데이터를 한 번에 불러오면 앱은 필연적으로 느려진다. 좋은 대시보드는 지금 당장 필요한 요약만 빠르게 보여주는 화면이다. 예를 들어, 전자결재 시스템 대시보드는 “내가 처리해야 할 결재 건수”, “오늘 새로 올라온 문서 수”, “반려된 문서 수”, “최근 5개 문서” 정도면 충분하다. 전체 문서 5,000건을 한 번에 보여줄 필요는 없다. 상세 검색 화면에서 필요한 조건으로 데이터를 불러오면 된다.
마찬가지로 검색 기능도 처음부터 넣어야 하지만, 무턱대고 전체 데이터를 매번 다 불러오게 설계해서는 안 된다. 검색 조건, 페이지네이션, 정렬 기준을 함께 설계해야 한다. 예를 들어 “한 번에 20개 또는 50개만 불러오기”, “검색어가 있을 때만 필터링하기”, “날짜 범위를 기본값으로 제한하기”와 같은 방식이다. 업무용 앱은 예쁜 것만큼이나 빠른 것이 중요하다. 특히 구글 스프레드시트를 데이터 저장소로 사용한다면 더욱 그렇다.
개인정보와 민감정보, 편리함 뒤의 경고
여기서 가장 중요한 주제가 등장한다. 바로 개인정보 및 민감정보 처리다. 구글 스프레드시트를 데이터베이스로 쓰는 방식은 편리하지만, 개인정보나 민감정보를 저장하는 순간 이야기가 180도 달라진다. 일부에서는 “유료 Google Workspace 계정으로 쓰면 개인정보 문제가 없다”고 단정하기도 하지만, 이는 매우 위험한 발상이다.
Google Workspace의 데이터 리전 기능은 주로 미국과 유럽연합 중심으로 제공된다. 한국 리전에만 데이터를 저장한다는 보장은 없다. 특히 공공기관이나 사회복지시설은 일반 회사보다 정보보안 기준이 훨씬 엄격하다. 클라이언트의 식별 가능한 정보, 건강 정보, 상담 내용, 서비스 이용 기록 같은 데이터를 외부 클라우드에 통합 저장하는 것은 신중한 판단이 필수다. CSAP 인증 여부도 중요하게 검토되어야 하며, 특정 Google Cloud 서비스가 CSAP 인증을 받았다고 해서, Google Workspace의 구글 스프레드시트 기반 앱이 곧바로 민감 정보 처리에 적합하다는 뜻은 절대 아니다. 서비스와 인증 범위는 엄격히 구분해야 한다.
따라서 이 방식으로 앱을 만들 때는 다음 원칙을 지키는 것이 안전하다.
- 가능하면 개인정보를 저장하지 않음.
- 꼭 필요한 경우에도 이름, 연락처, 주민등록번호 같은 식별 가능한 민감정보는 분리하고, 비식별 코드값을 사용함.
- 민감정보는 로컬 PC 또는 기관 내부 승인된 시스템에 저장함.
- 구글 스프레드시트에는 업무 상태, 문서 번호, 비식별 요약 정보만 저장함.
- 외부 클라우드에 민감정보를 저장해야 한다면, 개인정보 처리방침, 국외 이전, 처리위탁, 접근권한, 보관기간을 별도로 법률 전문가와 검토함.
이는 “기술적으로 가능하다”와 “기관에서 안전하게 써도 된다”가 다르다는 점을 명확히 인지해야 한다. 편리함이 윤리적, 법적 책임을 가볍게 만들지 않는다.
표 2. 구글 스프레드시트 기반 앱의 민감정보 처리 원칙
| 구분 | 안전한 용도 | 신중해야 할 용도 |
|---|---|---|
| 개인정보 | 비식별 업무 관리, 공지 확인, 물품 관리, 교육 신청 현황 | 상담일지 원문 저장, 주민등록번호/연락처 저장 |
| 민감정보 | 비식별 통계, 팀 업무 공유 | 장애/건강 정보 저장, 클라이언트 식별 정보, 사례 관리 기록 |
| 기관 유형 | 일반 기업의 비민감 내부 업무 | 공공/복지기관의 이용자 민감 정보 통합 관리 |
| 보안 기준 | 일반적인 내부 정보 보안 | CSAP 인증 등 엄격한 정보보안 기준 요구 |
앱 개발, 단계별로 작게 시작하고 AI로 검증한다
앱 개발은 바이브 코딩으로 “전자결재 시스템 만들어줘”라고 한 번에 요청해서는 성공하기 어렵다. 단계별로 작게 쪼개어 구현하고, 각 단계마다 AI의 검증을 거치는 것이 핵심이다.
- 챗GPT로 전체 구현 계획을 아주 상세하게 세운다.
- 빈 구글 스프레드시트를 만들고 링크를 준비한다.
- Codex나 Claude Code로 프로젝트 기본 구조부터 시작해 단계별 코딩을 진행한다. (시트/컬럼 자동 생성 초기화 코드, 목록 조회, 등록, 수정/삭제, 검색/필터/페이지네이션, 대시보드 등)
- 작성된 코드를 ZIP으로 압축해 챗GPT에 업로드하고 구조적 안정성, 잠재적 오류, 보안 위험 등을 검증받는다. 이는 빌드 실패, 타입 오류, 불필요한 함수, 더미 데이터 문제, 개인정보 노출 위험 등을 사전에 차단하는 과정이다.
- Google Apps Script 코드를 스프레드시트에 연결하고,
initializeSheets()함수를 실행해 초기 세팅을 완료한다. - Apps Script를 웹앱으로 배포하고 URL을 복사하여 앱 코드에 반영한다. 이때 URL은 환경변수나 설정 파일에서 관리한다.
- 실제 저장, 조회, 검색, 수정, 삭제 기능이 작동하는지 철저히 테스트한다. 특히 데이터가 프론트엔드에만 남아있는 것이 아니라 스프레드시트에 실제로 저장되는지 직접 확인하는 것이 중요하다.
- 어느 정도 작동하는 단계가 되면 Git 커밋으로 안전지점을 남긴다.
- 수정할 부분이 생기면 단순히 “이거 고쳐줘”가 아니라, 챗GPT에게 문제의 근본 원인(데이터 조회 구조, 페이지네이션, 캐싱 가능성 등)을 구조화하게 요청하고 수정 프롬프트를 생성한다.
- 최종 배포는 Cloudflare Pages나 Netlify 같은 정적 웹앱 호스팅 서비스를 활용한다. 배포 후에도 다시 한번 전체 기능을 테스트하여 환경변수 문제나 API 연결 실패 여부를 확인한다.
인간과 AI의 협업, 작게 시작하는 현명함
구글 스프레드시트를 데이터베이스로 활용하는 앱 개발은 작게 시작하기에 매우 현실적인 방식이다. 전문 개발자가 아니어도 시작할 수 있고, 서버 구축 없이 기관 내부 업무에 맞는 작은 앱을 빠르게 만들 수 있다. 특히 전자결재 시스템, 업무 요청 관리, 교육 신청 관리, 물품 관리처럼 개인정보 비중이 적고 업무 흐름이 명확한 앱은 충분히 시도해볼 만하다.
하지만 이 방식이 만능은 아니다. 구글 스프레드시트의 성능 한계와 Apps Script 사용량 제한, 그리고 무엇보다 개인정보 및 민감정보 처리와 관련된 법적, 윤리적 책임은 간과해서는 안 된다. 따라서 가장 좋은 접근은 다음과 같다.
- 처음에는 구글 스프레드시트로 작게 시작한다.
- 처음부터 데이터 구조와 검색 구조를 견고하게 설계한다.
- 시트와 컬럼은 AI에게 설계하게 하고, Apps Script로 자동 생성되게 만든다.
- 대시보드는 요약 정보 위주로 가볍게 만든다.
- 개인정보는 되도록 저장하지 않고, 필요한 경우 엄격하게 분리한다.
- 나중에 실제 데이터베이스로 옮길 수 있도록 데이터 접근 계층을 분리한다.
- 각 단계마다 챗GPT로 검증하고, Git 커밋으로 안전지점을 확보한다.
이처럼 인간이 목적과 기준을 정하고, AI가 계획, 구현, 검증을 돕는다면 복잡한 업무 자동화 도구도 훨씬 쉽게 만들 수 있다. 다만 개인정보와 민감정보만큼은 “될 것 같다”는 막연한 기대를 버리고, “문제가 없도록 설계했다”는 확신 수준까지 확인한 뒤 사용해야 한다. 당신의 현장 고민이 기술의 편리함과 책임감 있는 사용 사이에서 현명한 균형을 찾기를 바란다.