구글 스프레드시트를 데이터베이스로 업무용 앱 만드는 방법: 전자결재·협업툴·복지기관 내부앱 개발 가이드

구글 스프레드시트로 앱을 만든다는 것은 무엇일까?

회사나 복지기관에서 업무를 하다 보면 생각보다 비슷한 요구가 자주 생깁니다.

• 전자결재 시스템이 필요합니다.

• 직원들이 함께 쓰는 업무 기록장이 필요합니다.

• 회의록, 상담일지, 물품관리, 교육 신청, 출퇴근 기록, 업무 요청 관리 같은 작은 협업 시스템이 필요합니다.

• 그런데 전문 개발사를 통해 시스템을 만들기에는 비용이 부담스럽고, 상용 그룹웨어를 쓰기에는 우리 기관의 업무 방식과 맞지 않는 경우가 많습니다.

이때 현실적인 대안 중 하나가 구글 스프레드시트를 데이터베이스처럼 활용해 간단한 웹앱을 만드는 방식입니다.

구글 스프레드시트는 원래 표 계산 도구입니다. 하지만 Google Apps Script를 함께 사용하면 단순한 표를 넘어, 데이터를 저장하고 불러오고 수정하는 간단한 업무용 데이터베이스처럼 사용할 수 있습니다. 여기에 React나 일반 HTML 기반 웹앱을 붙이면 사용자는 스프레드시트를 직접 보지 않고도, 별도의 앱 화면에서 데이터를 입력하고 조회할 수 있습니다.

쉽게 말하면 이런 구조입니다.

• 사용자는 웹앱 화면에서 입력합니다.

• 앱은 Google Apps Script로 데이터를 보냅니다.

• Google Apps Script는 구글 스프레드시트에 데이터를 저장합니다.

• 다시 앱은 스프레드시트 데이터를 불러와 목록, 검색 결과, 대시보드로 보여줍니다.

이 방식은 전문적인 서버나 데이터베이스를 처음부터 구축하지 않아도 되기 때문에, 소규모 회사나 복지기관, 교육기관, 개인 프로젝트에서 시작하기 좋습니다.

하지만 장점만 있는 것은 아닙니다. 구글 스프레드시트는 진짜 데이터베이스가 아니기 때문에, 데이터가 많아지면 느려질 수 있습니다. 개인정보나 민감정보를 다루는 경우에는 법적·보안적 검토가 필요합니다. 그래서 처음부터 “쉽게 만든다”보다 나중에 망가지지 않게 만든다는 관점이 중요합니다.

기본 전제: 최소한 하나의 유료 AI 구독은 있는 것이 좋다

이 방식은 무료 도구만으로도 어느 정도 가능합니다. 하지만 실제로 앱을 끝까지 만들고 수정하고 검증하려면, 개인적으로는 최소한 하나의 유료 AI 구독은 있는 것이 좋다고 생각합니다.

특히 현재 기준으로는 ChatGPT 유료 구독을 추천하는 이유는 단순히 코드를 만들어주기 때문이 아닙니다. 실제 개발 과정에서는 코드를 작성하는 것보다 더 중요한 일이 있습니다.

• 구현계획을 세워야 합니다.

• 기능을 빠뜨리지 않아야 합니다.

• 코드가 꼬였을 때 원인을 분석해야 합니다.

• 압축한 프로젝트 파일을 다시 업로드해서 검증해야 합니다.

• 수정 프롬프트를 다시 만들어야 합니다.

• 전체 구조가 무너지지 않았는지 확인해야 합니다.

이 과정에서 ChatGPT는 기획자이자 검수자 역할을 하기에 좋습니다. 특히 프로젝트 ZIP 파일, 빌드 로그, Git diff, 오류 메시지 등을 올려서 검증받을 수 있다는 점이 큽니다.

개인적인 경험으로는 Claude Code도 뛰어나지만 사용량 제한이 빠르게 걸리는 편이고, Gemini 계열 도구는 파일 업로드나 대규모 코드 검토 측면에서 불편한 경우가 있었습니다. 그래서 실제 개발 흐름에서는 ChatGPT로 계획과 검증을 하고, Codex나 Claude Code로 구현하는 방식이 가장 안정적이었습니다.

전체 개발 흐름 한눈에 보기

구글 스프레드시트를 데이터베이스로 사용하는 업무용 앱은 다음 순서로 만들면 안정적입니다.

기본적인 내용은 앞선 포스트를 참고하세요

1. ChatGPT로 전체 구현계획을 아주 상세하게 세웁니다.

2. 빈 구글 스프레드시트를 먼저 만들고 링크를 준비합니다.

3. Codex나 Claude Code로 단계별 코딩을 진행합니다.

4. 작성된 코드를 ZIP으로 압축해 ChatGPT에 업로드하고 검증받습니다.

5. Google Apps Script 코드를 스프레드시트에 연결합니다.

6. Apps Script 코드를 저장합니다.

7. Apps Script를 웹앱으로 배포하고 URL을 복사합니다.

8. 복사한 URL을 다시 앱 코드에 반영합니다.

9. 실제 저장, 조회, 검색, 수정, 삭제가 되는지 테스트합니다.

10. 중간 저장을 위해 Git 커밋을 남깁니다.

11. 수정할 부분을 반영하면서 2번부터 10번 과정을 반복합니다.

12. 최종적으로 Cloudflare Pages나 Netlify 등에 배포합니다.

이 흐름의 핵심은 한 번에 완성하려고 하지 않는 것입니다.

바이브 코딩을 하다 보면 “전자결재 시스템 만들어줘”라고 한 번에 요청하고 싶어집니다. 하지만 그렇게 만들면 처음에는 그럴듯하게 보이다가, 나중에 검색 기능을 붙이면 저장 기능이 깨지고, 결재 상태를 추가하면 대시보드가 느려지고, 권한 기능을 붙이면 기존 데이터 구조가 꼬이는 일이 자주 생깁니다.

그래서 처음부터 전체 구조를 잘 잡아야 합니다.

1단계: ChatGPT로 구현계획을 아주 자세히 세우기

가장 중요한 단계는 코딩이 아닙니다.
구현계획 수립입니다.

처음부터 계획을 대충 세우면 나중에 수정하다가 앱이 꼬입니다. 특히 구글 스프레드시트를 데이터베이스로 사용할 때는 데이터 구조가 매우 중요합니다.

어떤 시트가 필요한지, 각 시트에 어떤 컬럼이 들어가야 하는지, 각 데이터에 고유 ID를 어떻게 부여할 것인지, 수정·삭제 기록을 남길 것인지, 검색은 어떤 방식으로 할 것인지, 권한은 어떻게 나눌 것인지가 처음부터 정리되어 있어야 합니다.

예를 들어 전자결재 시스템을 만든다고 가정해보겠습니다.

처음에는 “문서 제목, 작성자, 내용, 결재 상태만 있으면 되지 않을까?”라고 생각하기 쉽습니다. 하지만 실제로 사용하다 보면 더 많은 정보가 필요합니다.

• 누가 작성했는지 알아야 합니다.

• 어느 부서 문서인지 알아야 합니다.

• 누가 결재자인지 알아야 합니다.

• 반려 사유를 남겨야 합니다.

• 결재 완료 후 수정 가능 여부를 정해야 합니다.

• 수정 이력을 남겨야 합니다.

• 문서가 삭제된 것인지, 숨김 처리된 것인지 구분해야 합니다.

• 관리자와 일반 사용자의 권한을 나눠야 합니다.

이런 부분을 나중에 하나씩 붙이면 앱 구조가 복잡해집니다. 그래서 처음 구현계획 단계에서 ChatGPT에게 단순 화면 설계만 요청하면 안 됩니다. 앱 구조, 데이터 구조, 스프레드시트 시트 구성, 컬럼 설계, Apps Script 초기화 코드까지 함께 요청하는 것이 좋습니다.

이때 중요한 실무 팁이 있습니다.

구글 스프레드시트를 데이터베이스로 사용할 때, 꼭 사람이 직접 시트 이름과 컬럼을 하나하나 만들 필요는 없습니다. 먼저 비어 있는 구글 스프레드시트를 하나 만들고, 그 링크를 ChatGPT나 Codex에게 제공한 뒤, 앱에 필요한 시트와 컬럼 구조를 설계하게 하면 됩니다.

예를 들어 전자결재 시스템이라면 AI가 다음과 같은 시트를 제안할 수 있습니다.

• Users

• Departments

• Documents

• ApprovalLines

• ApprovalLogs

• Attachments

• Settings

• AuditLogs

그리고 각 시트별 컬럼도 함께 설계할 수 있습니다.

예를 들어 Documents 시트에는 다음과 같은 컬럼이 필요할 수 있습니다.

• documentId

• title

• content

• authorId

• departmentId

• status

• currentApproverId

• createdAt

• updatedAt

• submittedAt

• completedAt

• isDeleted

ApprovalLogs 시트에는 다음과 같은 컬럼이 필요할 수 있습니다.

• logId

• documentId

• approverId

• action

• comment

• createdAt

이런 구조를 사람이 직접 만들 수도 있지만, AI에게 설계하게 하면 빠뜨리는 부분이 줄어듭니다. 특히 초보자의 경우 고유 ID, 생성일, 수정일, 삭제 여부, 상태값, 로그 ID 같은 중요한 컬럼을 빼먹기 쉽습니다.

더 좋은 방법은 여기서 한 단계 더 나아가는 것입니다.
AI에게 Apps Script에서 한 번 실행하면 필요한 시트와 컬럼이 자동으로 생성되는 초기화 함수까지 만들어달라고 요청하는 것입니다.

예를 들어 initializeSheets() 같은 함수를 만들 수 있습니다. 이 함수는 스프레드시트 안에 필요한 시트가 없으면 자동으로 만들고, 각 시트의 첫 번째 행에 헤더 컬럼을 입력합니다. 이미 시트가 있는 경우에는 중복 생성하지 않고, 누락된 컬럼만 추가하도록 만들 수 있습니다.

이렇게 해두면 앱을 새로 설치하거나 다른 기관에서 사용할 때도 훨씬 편합니다.

• 빈 스프레드시트를 하나 만듭니다.

• Apps Script 코드를 붙여 넣습니다.

• initializeSheets() 함수를 한 번 실행합니다.

• 필요한 시트와 컬럼이 자동으로 만들어집니다.

• 그다음 앱을 연결합니다.

이 방식은 단순히 편한 정도의 문제가 아닙니다. 데이터 구조를 코드로 관리할 수 있기 때문에, 나중에 유지보수하기가 훨씬 좋습니다. 또한 추후 실제 데이터베이스로 이전할 때도 각 시트가 어떤 테이블 역할을 했는지 명확하게 파악할 수 있습니다.

이 단계에서 사용할 수 있는 프롬프트는 다음과 같습니다.

구현계획 작성 프롬프트 예시

아래 조건을 바탕으로 Google Sheets를 데이터베이스처럼 사용하는 업무용 웹앱의 전체 구현계획을 작성해주세요.

앱 목적:
[예: 복지기관 내부 전자결재 시스템]

주요 사용자:
[예: 관리자, 팀장, 일반 직원]

기본 저장소:
이미 만들어 둔 빈 구글 스프레드시트를 데이터베이스로 사용할 예정입니다.

스프레드시트 링크:
[여기에 링크 입력]

중요 조건:

1. 처음부터 데이터 구조를 안정적으로 설계해주세요.

2. 앱에 필요한 시트 목록과 각 시트별 컬럼 구조를 제안해주세요.

3. 각 시트의 컬럼명, 데이터 타입, 필수 여부, 예시 값을 표로 정리해주세요.

4. Apps Script에서 한 번 실행하면 필요한 시트와 헤더 컬럼이 자동으로 생성되는 initializeSheets() 함수를 작성할 수 있도록 설계해주세요.

5. 이미 시트가 있으면 중복 생성하지 않고, 누락된 컬럼만 추가하는 방식으로 설계해주세요.

6. 기존 컬럼이나 실제 데이터는 함부로 삭제하지 않는 안전한 구조로 설계해주세요.

7. 나중에 Google Sheets에서 Supabase, Firebase, PostgreSQL 같은 실제 데이터베이스로 이전할 수 있도록 데이터 접근 계층을 분리하는 구조로 설계해주세요.

8. 웹앱뿐 아니라 추후 Android 앱, Windows exe 설치형 앱, Electron 앱으로 전환하기 쉬운 구조를 고려해주세요.

9. 대규모 데이터가 쌓일 수 있으므로 검색 기능, 페이지네이션, 필터링, 정렬 구조를 반드시 포함해주세요.

10. 대시보드는 한 번에 너무 많은 데이터를 보여주지 않게 설계해주세요.

11. 민감정보나 개인정보는 저장하지 않는 방향을 우선으로 설계해주세요.

12. 꼭 필요한 경우에도 식별정보와 업무기록을 분리하는 구조를 제안해주세요.

13. 각 단계별 구현 순서와 검증 체크리스트를 함께 작성해주세요.

14. Codex 또는 Claude Code에 입력할 수 있는 단계별 구현 프롬프트까지 작성해주세요.

15. 기존 기능을 깨지 않도록 단계별로 작게 구현하는 방식으로 제안해주세요.

이렇게 요청하면 단순히 “화면을 예쁘게 만들어주세요” 수준이 아니라, 앱의 뼈대가 되는 데이터 구조까지 함께 정리할 수 있습니다.

업무용 앱에서 가장 위험한 것은 화면이 못생긴 것이 아닙니다.
처음 데이터 구조가 잘못 잡혀서 나중에 기능을 추가할 때마다 앱이 무너지는 것입니다.

그래서 1단계에서는 화면보다 데이터 구조를 먼저 잡아야 합니다.

2단계: 처음부터 데이터베이스 이전 가능성을 열어두기

구글 스프레드시트의 가장 큰 장점은 쉽다는 것입니다.
하지만 가장 큰 단점은 무거워질 수 있다는 것입니다.

처음에는 데이터가 100건, 500건 정도라서 문제가 없습니다. 하지만 기관 업무는 시간이 지나면 데이터가 계속 쌓입니다. 전자결재, 업무 요청, 교육 신청, 물품 관리, 점검표 같은 데이터는 몇 달만 지나도 수천 건이 될 수 있습니다. 1년, 2년이 지나면 수만 건이 될 수도 있습니다.

이때 스프레드시트를 계속 데이터베이스처럼 쓰면 문제가 생깁니다.

• 검색이 느려질 수 있습니다.

• 대시보드 로딩이 느려질 수 있습니다.

• 전체 데이터를 한 번에 불러오면 앱이 멈춘 것처럼 보일 수 있습니다.

• Apps Script 호출 제한이나 실행 시간 제한에 걸릴 수 있습니다.
  동시 사용자가 많으면 저장 충돌이나 지연이 생길 수 있습니다.

• 그래서 처음부터 이렇게 요청해야 합니다.

“지금은 Google Sheets를 데이터베이스로 사용하지만, 나중에 실제 데이터베이스로 이전하기 쉽게 데이터 접근 계층을 분리해주세요.”

이 말이 중요합니다.

예를 들어 앱 전체에서 직접 Apps Script URL을 여러 곳에 흩뿌려 놓으면 나중에 데이터베이스를 바꾸기 어렵습니다. 대신 dataService, apiClient, repository 같은 계층을 만들고, 앱 화면은 그 계층을 통해서만 데이터를 요청하게 해야 합니다.

그러면 지금은 Google Sheets를 쓰더라도, 나중에 Supabase, Firebase, PostgreSQL 같은 실제 데이터베이스로 바꿀 때 화면 전체를 갈아엎지 않아도 됩니다.

처음에는 단순해 보여도, 업무용 앱은 오래 쓸수록 구조가 중요해집니다.

3단계: 검색 기능은 처음부터 넣어야 한다

스프레드시트 기반 앱에서 자주 빠지는 기능이 검색입니다.

처음 만들 때는 데이터가 적기 때문에 검색이 없어도 괜찮아 보입니다. 하지만 실제 기관 업무에서는 금방 문제가 됩니다.

• 전자결재 문서를 찾고 싶습니다.

• 특정 직원의 신청 내역을 찾고 싶습니다.

• 특정 날짜의 기록을 찾고 싶습니다.

• 처리 상태가 “대기중”인 문서만 보고 싶습니다.

• 제목, 작성자, 부서, 기간, 상태로 필터링하고 싶습니다.

이런 기능이 없으면 결국 사용자는 스프레드시트를 다시 열어 직접 Ctrl+F로 찾게 됩니다. 그러면 앱을 만든 의미가 줄어듭니다.

검색 기능은 나중에 붙이기보다 처음부터 구조에 넣는 것이 좋습니다.

단, 검색 기능을 만든다고 해서 전체 데이터를 매번 다 불러오면 안 됩니다. 데이터가 많아질수록 느려집니다. 따라서 검색 조건, 페이지네이션, 정렬 기준을 함께 설계해야 합니다.

예를 들어 다음과 같은 방식이 좋습니다.

• 한 번에 20개 또는 50개만 불러오기

• 검색어가 있을 때만 필터링하기

• 날짜 범위를 기본값으로 제한하기

• 완료된 오래된 문서는 기본 목록에서 숨기기

• 대시보드는 요약 숫자만 보여주기

• 상세 목록은 별도 화면에서 검색 조건에 따라 불러오기

업무용 앱은 예쁜 것만큼이나 빠른 것이 중요합니다. 특히 구글 스프레드시트를 데이터 저장소로 쓴다면 더더욱 그렇습니다.

4단계: 대시보드는 예쁘게 만들되, 너무 많은 데이터를 보여주지 말기

AI에게 앱을 만들게 하면 대시보드를 멋지게 만들어주는 경우가 많습니다. 카드도 있고, 차트도 있고, 최근 기록도 있고, 통계도 있고, 테이블도 들어갑니다.

처음 보면 좋아 보입니다. 하지만 문제는 데이터가 많아졌을 때입니다.

대시보드에서 모든 데이터를 한 번에 불러오면 앱은 필연적으로 느려집니다. 특히 구글 스프레드시트를 데이터베이스로 사용하는 경우에는 더 조심해야 합니다.

좋은 대시보드는 모든 데이터를 보여주는 화면이 아닙니다.
좋은 대시보드는 지금 당장 필요한 요약만 빠르게 보여주는 화면입니다.

예를 들어 전자결재 시스템이라면 대시보드에는 다음 정도만 보여주면 충분합니다.

• 내가 처리해야 할 결재 건수

• 오늘 새로 올라온 문서 수

• 반려된 문서 수

• 최근 5개 문서

• 상태별 요약 숫자

전체 문서 5,000건을 대시보드에 한 번에 보여줄 필요는 없습니다. 상세 검색 화면에서 필요한 조건으로 불러오면 됩니다.

처음부터 ChatGPT에게 이렇게 요청하는 것이 좋습니다.

“대시보드는 한 번에 전체 데이터를 불러오지 말고, 요약 API와 목록 API를 분리해주세요. 최근 데이터는 5개 또는 10개만 보여주고, 전체 목록은 검색 화면에서 페이지네이션으로 불러오게 해주세요.”

이 한 문장을 넣는 것만으로도 앱의 속도와 유지보수성이 크게 달라집니다.

5단계: 단계별 코딩은 Codex나 Claude Code를 추천

계획이 끝나면 이제 실제 구현 단계입니다.

개인적으로는 구현 도구로 Codex나 Claude Code를 추천합니다. 특히 업무용 앱처럼 안정성이 중요한 작업에서는 “창의적으로 새로 만드는 능력”보다 “기존 구조를 깨지 않고 차근차근 구현하는 능력”이 더 중요합니다.

Antigravity도 발전하고 있지만, 실제 사용 경험상 최신 Gemini 3.5 Flash High를 사용해도 의도를 정확히 이해하지 못하거나, 이미 정해둔 구조를 무시하고 다시 크게 바꾸는 경우가 있었습니다. 물론 프로젝트나 프롬프트 방식에 따라 다를 수 있지만, 안정적으로 내부 업무 앱을 만드는 상황에서는 Codex나 Claude Code가 더 편했습니다.

특히 Codex의 ChatGPT 5.5 Low 모드는 오히려 장점이 있었습니다. 너무 창의적으로 구조를 바꾸기보다, 지시한 범위 안에서 비교적 안정적으로 구현하는 느낌이 있었습니다. 사용량도 넉넉한 편이라 반복 수정이 필요한 앱 개발에 적합했습니다.

단계별 구현은 다음처럼 나누는 것이 좋습니다.

1단계: 프로젝트 기본 구조 만들기
2단계: 화면 라우팅과 레이아웃 만들기
3단계: 데이터 타입과 API 계층 만들기
4단계: Google Apps Script 연동 준비
5단계: 시트·컬럼 자동 생성 초기화 코드 구현
6단계: 목록 조회 기능 구현
7단계: 등록 기능 구현
8단계: 수정·삭제 기능 구현
9단계: 검색·필터·페이지네이션 구현
10단계: 대시보드 구현
11단계: 권한과 설정 기능 구현
12단계: 오류 처리와 로딩 처리 구현
13단계: 최종 빌드와 배포 준비

중요한 것은 한 번에 다 만들지 않는 것입니다. 한 단계가 끝날 때마다 검증해야 합니다.

6단계: 작성한 코드는 반드시 ChatGPT로 다시 검증하기

AI 코딩 도구가 “완료했습니다”라고 말해도 그대로 믿으면 안 됩니다.

실제로는 빌드가 실패할 수 있습니다.
타입 오류가 있을 수 있습니다.
사용하지 않는 함수가 남아 있을 수 있습니다.
저장 기능이 된다고 했지만 실제로는 더미 데이터일 수 있습니다.
Apps Script URL이 코드 곳곳에 하드코딩되어 있을 수 있습니다.
개인정보가 localStorage에 그대로 저장되고 있을 수 있습니다.
검색 기능이 있는 것처럼 보이지만 실제로는 전체 데이터를 불러온 뒤 프론트에서만 필터링할 수 있습니다.

그래서 각 단계가 끝날 때마다 프로젝트를 압축해서 ChatGPT에 넣고 검증받는 것이 좋습니다.

이때 필요한 자료는 다음과 같습니다.

• 프로젝트 ZIP 파일

• package.json

• src 폴더

• Apps Script 코드

• 빌드 로그

• git diff

• 오류 메시지

• 실제 테스트 화면 캡처

검증 요청은 이렇게 하면 됩니다.

코드 검증 프롬프트 예시

첨부한 ZIP 파일은 Google Sheets를 데이터베이스로 사용하는 업무용 웹앱입니다.

다음 기준으로 검증해주세요.

1. TypeScript 오류 가능성이 있는지 확인해주세요.

2. npm run build가 실패할 만한 부분이 있는지 확인해주세요.

3. Google Apps Script 연동 구조가 적절한지 확인해주세요.

4. 시트와 컬럼 자동 생성 초기화 함수가 안전하게 작성되어 있는지 확인해주세요.

5. 기존 데이터가 있는 시트를 덮어쓰거나 삭제할 위험이 없는지 확인해주세요.

6. 데이터 저장, 조회, 수정, 삭제 흐름이 실제로 작동할 구조인지 확인해주세요.

7. 더미 데이터만 있고 실제 저장이 안 되는 부분이 있는지 확인해주세요.

8. 검색 기능이 대규모 데이터에서 느려질 구조인지 확인해주세요.

9. 한 번에 전체 데이터를 불러오는 위험한 구조가 있는지 확인해주세요.

10. 나중에 실제 데이터베이스로 이전하기 어려운 구조인지 확인해주세요.

11. 개인정보나 민감정보 저장 측면에서 위험한 부분이 있는지 확인해주세요.

12. 수정이 필요한 부분은 Codex에 바로 입력할 수 있는 프롬프트로 작성해주세요.

이 검증 과정을 거치면 오류가 크게 줄어듭니다.

7단계: Google Apps Script 코드 입력하기

프론트엔드 앱이 준비되면 이제 구글 스프레드시트와 연결해야 합니다.

일반적인 방식은 다음과 같습니다.

1. 빈 구글 스프레드시트를 만듭니다.

2. Apps Script를 엽니다.

3. ChatGPT나 Codex가 만들어준 Apps Script 코드를 붙여 넣습니다.

4. initializeSheets() 함수를 먼저 실행해 필요한 시트와 컬럼을 생성합니다.

5. 저장 버튼을 누릅니다.

6. 필요한 권한을 승인합니다.

7. 웹앱으로 배포합니다.

8. 배포 URL을 복사합니다.

9. 프론트엔드 앱의 API URL에 반영합니다.

여기서 중요한 것은 Apps Script 코드에 데이터 저장·조회 함수만 넣는 것이 아니라, 초기 세팅 함수도 함께 넣는 것입니다.

예를 들어 initializeSheets() 함수를 만들어두면 처음 실행할 때 필요한 시트가 자동으로 생성되고 각 시트의 첫 번째 행에 헤더 컬럼이 입력됩니다. 이미 시트가 있는 경우에는 기존 데이터를 지우지 않고, 누락된 컬럼만 추가하도록 만들 수 있습니다.

다만 주의할 점도 있습니다.

이미 실제 데이터가 들어간 시트의 컬럼 순서를 함부로 바꾸면 기존 데이터가 꼬일 수 있습니다. 따라서 자동 생성 코드는 “없는 시트는 생성하고, 없는 컬럼은 추가하되, 기존 컬럼과 데이터는 삭제하지 않는 방식”으로 작성하는 것이 안전합니다.

이 부분은 AI에게 꼭 명확하게 요청해야 합니다.

8단계: Apps Script 저장, 배포, 링크 복사

Apps Script 코드를 입력했다면 저장 버튼을 누릅니다.

그다음 배포 메뉴에서 새 배포를 선택하고, 유형을 웹앱으로 설정합니다. 실행 권한과 접근 권한을 정한 뒤 배포하면 웹앱 URL이 생성됩니다.

이 URL이 프론트엔드 앱과 구글 스프레드시트를 연결하는 핵심 주소입니다.

문제는 이 URL을 프론트엔드 코드 어디에 넣어야 하는지 찾기 어렵다는 점입니다. 그래서 URL을 복사한 뒤 Codex에게 다시 제공하는 것이 편합니다.

예를 들어 이렇게 요청합니다.

“아래 Apps Script 배포 URL을 현재 앱의 API endpoint로 반영해주세요. 기존 기능은 변경하지 말고, 환경변수 또는 설정 파일에서 관리되도록 수정해주세요.”

가능하면 URL을 코드 여러 곳에 직접 넣지 말고 .env나 설정 파일에서 관리하게 하는 것이 좋습니다. 그래야 나중에 배포 URL이 바뀌어도 한 곳만 수정하면 됩니다.

9단계: 실제 작동 테스트

앱이 배포되었다고 끝이 아닙니다. 실제 테스트가 가장 중요합니다.

최소한 다음 항목은 반드시 확인해야 합니다.

• 새 데이터가 저장되는가?

• 저장된 데이터가 스프레드시트에 실제로 들어가는가?

• 앱을 새로고침해도 데이터가 유지되는가?

• 목록 조회가 되는가?

• 검색이 되는가?

• 수정이 되는가?

• 삭제 또는 비활성 처리가 되는가?

• 잘못 입력했을 때 오류 메시지가 나오는가?

• 로딩 중 표시가 나오는가?

• 모바일 화면에서도 사용할 수 있는가?

• 동시에 여러 명이 입력해도 문제가 없는가?

• 권한이 없는 사용자가 민감한 화면에 접근하지 못하는가?

• Apps Script URL이 외부에 노출되어도 위험하지 않은 구조인가?

특히 구글 스프레드시트 기반 앱은 저장이 되는 것처럼 보이지만 실제로는 프론트엔드 상태에만 남아 있는 경우가 있습니다. 반드시 스프레드시트를 직접 열어 데이터가 들어갔는지 확인해야 합니다.

10단계: 중간 저장을 위한 Git 커밋

어느 정도 작동하는 단계가 되면 반드시 Git 커밋을 남기는 것이 좋습니다.

바이브 코딩을 하다 보면 수정하다가 앱이 갑자기 망가질 수 있습니다. 특히 AI가 기존 구조를 크게 바꾸거나, 이전에 잘 되던 기능을 실수로 삭제하는 경우가 있습니다.

그래서 다음과 같은 기준으로 커밋을 남기는 것이 좋습니다.

• 기본 화면 구현 완료

• Google Sheets 연동 완료

• 시트·컬럼 자동 생성 기능 완료

• 저장 기능 완료

• 조회 기능 완료

• 검색 기능 완료

• 대시보드 구현 완료

• 배포 전 안정 버전

• 실제 테스트 완료 버전

중간에 커밋에 대한 명령어를 물어서 직접 하시거나 코덱스 등에게 방법을 안내해달라고 하시면 됩니다. 다만 필수는 아니니 너무 복잡하다고 생각하시면 안하셔도 괜찮습니다.

11단계: 수정 사항을 반영하며 반복하기

앱은 한 번에 완성되지 않습니다. 실제로 써보면 반드시 수정할 부분이 나옵니다.

• 버튼 위치가 불편할 수 있습니다.

• 검색 조건이 부족할 수 있습니다.

• 대시보드가 느릴 수 있습니다.

• 모바일에서 표가 깨질 수 있습니다.

• 관리자와 일반 직원 권한을 더 나눠야 할 수 있습니다.

• 결재선 구조를 바꿔야 할 수 있습니다.

이때 중요한 것은 바로 Codex에 “이거 고쳐줘”라고 하지 않는 것입니다. 먼저 ChatGPT에게 문제를 구조화하게 하는 것이 좋습니다.

예를 들어 이렇게 요청합니다.

“현재 앱을 테스트해보니 결재 문서가 많아질수록 대시보드 로딩이 느립니다. 이 문제를 단순히 땜질하지 말고, 데이터 조회 구조, 페이지네이션, 대시보드 요약 API, 캐싱 가능성까지 함께 검토해서 Codex에 입력할 수정 프롬프트를 작성해주세요.”

이렇게 하면 단순한 수정이 아니라 구조적인 수정으로 이어질 가능성이 높습니다.

12단계: 최종 배포는 Cloudflare Pages나 Netlify 활용

프론트엔드 앱은 Cloudflare Pages나 Netlify에 배포할 수 있습니다.

개인적으로 무료 또는 저비용으로 운영하려면 Cloudflare Pages가 좋은 선택입니다. 정적 웹앱을 배포하기 쉽고, 무료 플랜도 비교적 넉넉합니다. Netlify도 사용하기 쉽고, GitHub와 연결해 자동 배포하기 좋습니다.

일반적인 배포 흐름은 다음과 같습니다.

1. GitHub에 프로젝트를 올립니다.

2. Cloudflare Pages 또는 Netlify에 로그인합니다.

3. GitHub 저장소를 연결합니다.

4. 빌드 명령어를 설정합니다.

5. 출력 폴더를 설정합니다.

6. 환경변수에 Apps Script URL을 등록합니다.

7. 배포합니다.

8. 실제 URL에서 기능을 다시 테스트합니다.

Vite 기반 React 앱이라면 보통 빌드 명령어는 npm run build, 출력 폴더는 dist입니다.

배포 후에도 반드시 실제 저장, 조회, 검색, 수정 기능을 확인해야 합니다. 로컬에서는 되지만 배포 환경에서는 환경변수 문제로 API 연결이 실패하는 경우가 있기 때문입니다.

이런 방식으로 만들 수 있는 앱들

구글 스프레드시트와 Apps Script를 활용하면 생각보다 다양한 업무용 앱을 만들 수 있습니다.

예를 들면 다음과 같습니다.

• 전자결재 시스템

• 업무 요청 관리 시스템

• 회의록 관리 시스템

• 상담 예약 관리 시스템

• 교육 신청 관리 앱

• 기관 내부 공지 확인 앱

• 물품 대여 관리 시스템

• 차량 이용 신청 시스템

• 근무표 신청·변경 시스템

• 실습 기록 관리 시스템

• 후원 물품 관리 시스템

• 간단한 재고 관리 앱

• 프로그램 참여 신청 관리 앱

• 직원 업무일지 앱

특히 전자결재 시스템 같은 협업툴은 이 방식으로 비교적 쉽게 만들 수 있습니다. 처음부터 완전한 그룹웨어를 만들려고 하면 어렵지만, 우리 기관에서 실제로 필요한 결재 양식과 승인 흐름만 구현하면 충분히 실용적인 내부 도구가 됩니다.

하지만 개인정보와 민감정보는 매우 조심해야 한다

여기서 가장 중요한 주제가 있습니다. 바로 개인정보입니다.

구글 스프레드시트를 데이터베이스로 사용하는 방식은 편리하지만, 개인정보나 민감정보를 저장하는 순간 이야기가 달라집니다.

일부에서는 “유료 Google Workspace 계정으로 쓰면 개인정보 문제가 없다”고 말하기도 합니다. 하지만 그렇게 단정하면 위험합니다.

Google Workspace 유료 계정을 사용한다고 해서 모든 데이터가 한국에 저장되는 구조라고 보기는 어렵습니다. Google Workspace의 데이터 리전 기능은 기본적으로 미국과 유럽연합 중심으로 제공됩니다. 따라서 한국 리전에만 데이터를 저장하는 구조로 이해하면 안 됩니다.

또한 공공기관이나 보조금을 받는 사회복지시설은 일반 회사보다 정보보안 기준이 더 엄격하게 적용될 수 있습니다. 클라이언트의 식별 가능한 정보, 장애 정보, 건강 정보, 상담 내용, 서비스 이용 기록 같은 데이터를 외부 클라우드에 통합 저장하는 것은 신중하게 판단해야 합니다.

특히 공공·사회복지 영역에서는 CSAP 인증 여부도 중요하게 검토될 수 있습니다. Google Cloud 일부 IaaS/PaaS 서비스가 CSAP 인증을 받았다고 해서, Google Workspace의 구글 스프레드시트 기반 앱이 곧바로 민감정보 처리에 적합하다는 뜻은 아닙니다. 서비스와 인증 범위는 반드시 구분해야 합니다.

따라서 이 방식으로 앱을 만들 때는 다음 원칙을 지키는 것이 안전합니다.

1. 가능하면 개인정보를 저장하지 않습니다.

2. 꼭 필요한 경우에도 이름, 연락처, 주민등록번호, 장애 정보, 상담 내용 같은 식별 가능한 민감정보는 분리합니다.

3. 개인을 식별할 수 없는 코드값을 사용합니다.

4. 민감정보는 로컬 PC 또는 기관 내부 승인된 시스템에 저장합니다.

5. 구글 스프레드시트에는 업무 상태, 문서 번호, 비식별 요약 정보만 저장합니다.

6. 외부 클라우드에 저장해야 한다면 개인정보 처리방침, 국외 이전, 처리위탁, 접근권한, 보관기간을 별도로 검토합니다.

7. 공공·복지기관은 기관 내부 개인정보보호 담당자, 정보보안 담당자, 법률 전문가의 검토를 받는 것이 좋습니다.

이 부분은 “기술적으로 가능하다”와 “기관에서 안전하게 써도 된다”가 다르다는 점을 이해해야 합니다.

그래서 JJSS는 각자의 PC에 저장하는 방식을 선택했다

제가 만들고 있는 JJSS도 이 문제를 고려했습니다.

JJSS는 업무 지원을 위한 앱이지만, 모든 저장 정보를 외부 서버나 구글 스프레드시트에 통합 저장하는 방식으로 만들지 않았습니다. 대신 각자의 PC에 저장되도록 설계했습니다.

이 방식은 클라우드 기반 협업 기능에서는 불리할 수 있습니다. 하지만 개인정보와 민감정보를 다룰 가능성이 있는 앱에서는 오히려 더 안전한 선택일 수 있습니다.

특히 복지기관이나 교육기관처럼 민감한 이용자 정보를 다룰 수 있는 환경에서는, 무조건 클라우드에 모으는 것이 좋은 방향은 아닙니다. 기관의 보안 체계, 법적 책임, 데이터 보관 위치, 접근권한, 삭제 요청 대응까지 함께 고려해야 합니다.

그래서 구글 스프레드시트 기반 앱은 다음과 같이 쓰는 것이 가장 현실적이라고 생각합니다.

• 개인정보가 거의 없는 내부 업무 관리

• 결재 상태 관리

• 공지 확인

• 비식별 업무 요청

• 물품 관리

• 교육 신청 현황

• 단순 통계

• 팀 업무 공유

• 외부 민감정보가 없는 협업툴

반대로 다음 용도는 신중해야 합니다.

• 상담일지 원문 저장

• 장애·건강 정보 저장

• 주민등록번호 또는 연락처 저장

• 클라이언트 식별 정보 저장

• 민감한 사례관리 기록 저장

• 공공 보조사업 대상자 정보 통합 관리

이런 데이터는 구글 스프레드시트 기반 간이 앱보다, 기관이 승인한 보안 시스템이나 국내 인증 클라우드, 또는 로컬 저장 방식이 더 적절할 수 있습니다.

구글 스프레드시트 기반 앱을 만들 때 반드시 넣어야 할 기능

초보자가 앱을 만들 때 자주 빠뜨리는 기능들이 있습니다. 처음에는 없어도 될 것 같지만, 실제로 쓰기 시작하면 반드시 필요해집니다.

1. 검색 기능

대규모 데이터가 쌓이면 검색이 없으면 사용할 수 없습니다. 제목, 작성자, 상태, 날짜 범위, 부서, 키워드 검색은 처음부터 고려해야 합니다.

2. 페이지네이션

전체 데이터를 한 번에 불러오면 앱이 느려집니다. 20개, 50개 단위로 끊어서 불러오는 구조가 필요합니다.

3. 상태값 관리

전자결재라면 임시저장, 제출, 검토중, 승인, 반려, 완료 같은 상태값이 필요합니다. 상태값이 명확해야 검색과 통계가 쉬워집니다.

4. 고유 ID

행 번호만 믿으면 안 됩니다. 중간에 행이 삭제되거나 정렬되면 데이터가 꼬일 수 있습니다. 각 데이터에는 고유 ID를 부여해야 합니다.

5. 로그 기록

누가 언제 만들었고, 누가 수정했는지 기록해야 합니다. 업무용 앱에서는 나중에 문제가 생겼을 때 이력이 중요합니다.

6. 오류 메시지

저장 실패, 권한 없음, 네트워크 오류, Apps Script 오류를 사용자에게 명확하게 알려줘야 합니다.

7. 로딩 표시

구글 스프레드시트 기반 앱은 응답이 늦을 수 있습니다. 로딩 표시가 없으면 사용자는 앱이 멈췄다고 생각합니다.

8. 권한 구조

관리자, 일반 사용자, 승인자, 조회 전용 사용자를 구분해야 합니다.

9. 백업

스프레드시트는 실수로 삭제되거나 잘못 수정될 수 있습니다. 정기 백업 구조를 고려해야 합니다.

10. 초기화 함수

필요한 시트와 컬럼을 자동으로 생성하는 초기화 함수가 있으면 설치와 유지보수가 쉬워집니다. 특히 다른 기관이나 다른 계정에서 같은 앱을 다시 사용할 때 큰 도움이 됩니다.

11. 데이터 이전 구조

처음부터 나중에 실제 데이터베이스로 옮길 수 있도록 설계해야 합니다.

결론: 구글 스프레드시트 기반 앱은 “작게 시작하기”에 매우 좋다

구글 스프레드시트를 데이터베이스로 사용하는 앱 개발 방식은 매우 현실적입니다.

전문 개발자가 아니어도 시작할 수 있습니다.
서버를 직접 구축하지 않아도 됩니다.
기관 내부 업무에 맞춘 작은 앱을 빠르게 만들 수 있습니다.
ChatGPT, Codex, Claude Code 같은 AI 도구를 활용하면 개발 난이도도 크게 낮아집니다.

특히 전자결재 시스템, 업무 요청 관리, 교육 신청 관리, 물품 관리처럼 개인정보가 적고 업무 흐름이 명확한 앱은 충분히 시도해볼 만합니다.

하지만 이 방식은 만능이 아닙니다.

구글 스프레드시트는 진짜 데이터베이스가 아닙니다. 데이터가 많아지면 느려질 수 있습니다. Apps Script와 Sheets API에는 사용량 제한이 있습니다. 개인정보와 민감정보를 저장하는 경우에는 국외 이전, 처리위탁, 보안 인증, 기관 내부 규정까지 검토해야 합니다.

그래서 가장 좋은 접근은 이렇습니다.

처음에는 구글 스프레드시트로 작게 시작합니다.
처음부터 데이터 구조와 검색 구조를 잘 설계합니다.
시트와 컬럼은 AI에게 설계하게 하고, Apps Script로 자동 생성되게 만듭니다.
대시보드는 가볍게 만듭니다.
개인정보는 되도록 저장하지 않습니다.
나중에 실제 데이터베이스로 옮길 수 있게 구조를 분리합니다.
각 단계마다 ChatGPT로 검증하고, Git 커밋으로 안전지점을 남깁니다.

이렇게 하면 구글 스프레드시트 기반 앱은 단순한 임시 도구가 아니라, 회사나 복지기관에서 실제로 사용할 수 있는 실용적인 업무 자동화 도구가 될 수 있습니다.

중요한 것은 AI에게 “앱 하나 만들어줘”라고 맡기는 것이 아닙니다.
사람이 목적과 기준을 정하고, ChatGPT가 계획과 검증을 맡고, Codex나 Claude Code가 구현을 맡고, 다시 사람이 실제 사용성을 판단하는 구조를 만드는 것입니다.

이 방식으로 접근하면 복잡한 전자결재 시스템이나 내부 협업툴도 생각보다 훨씬 쉽게 만들 수 있습니다. 다만 개인정보와 민감정보만큼은 “될 것 같다”가 아니라 “문제가 없도록 설계했다”는 수준까지 확인한 뒤 사용해야 합니다.