구글 스프레드시트로 하던 업무, 웹앱으로 자동화하려면 어디서부터 시작할까요?

구글 폼으로 신청을 받고, 응답이 쌓인 스프레드시트를 열어 처리하는 업무를 생각해볼게요.

1. 구글 폼으로 신청을 받는다.
2. 스프레드시트에서 새 신청을 확인한다.
3. 입금 여부를 보고 셀 색깔을 바꾼다.
4. 확정된 신청자를 다른 시트에 복사한다.
5. 안내 이메일이나 문자를 보낸다.
6. 매주 신청자 수를 세어 보고한다.

처음에는 충분히 효율적입니다. 별도의 프로그램을 만들지 않아도 바로 시작할 수 있고, 열을 추가하거나 수식을 바꾸기도 쉬워요. Google Forms의 응답은 연결된 Google Sheets에 저장할 수도 있습니다.

그런데 신청이 늘어나면 담당자는 같은 정보를 여러 곳에 복사하고, 색깔과 메모의 의미를 기억하고, 다음에 해야 할 일을 놓치지 않으려 계속 시트를 확인하게 됩니다.

이럴 때 필요한 것은 스프레드시트를 닮은 화면을 새로 만드는 일이 아닙니다. 사람이 기억하고 판단하고 복사하던 업무 규칙을 정리한 뒤, 그중 반복 가능한 부분을 웹앱이 처리하게 만드는 일이에요.

이 글에서는 지금의 시트 업무를 어떤 순서로 분석하고, 어디까지 자동화할지 알아보겠습니다.

먼저 시트를 없애야 한다는 생각부터 내려놓으세요

스프레드시트는 나쁜 도구가 아닙니다. 소수의 담당자가 데이터를 직접 확인하고 수시로 구조를 바꾸는 업무에는 오히려 웹앱보다 편할 수 있어요.

다음과 같은 상황이라면 당장 웹앱을 만들 필요가 없습니다.

• 데이터를 확인하고 수정하는 사람이 한두 명입니다.
• 접수량이 많지 않고 누락이 생겨도 쉽게 발견할 수 있습니다.
• 업무 규칙이 매주 바뀌어 아직 정해진 흐름이 없습니다.
• 외부 사용자가 자신의 신청 상태를 확인할 필요가 없습니다.
• 간단한 수식과 필터만으로 업무가 끝납니다.

조금 더 자동화하고 싶어도 곧바로 웹앱으로 넘어갈 필요는 없어요. Google Apps Script를 사용하면 시트를 읽고 수정하거나, 폼이 제출되었을 때 코드를 실행하고, Gmail 같은 다른 Google 서비스와 연결할 수 있습니다.

예를 들어 새 응답이 들어오면 담당자에게 이메일을 보내는 정도라면 기존 시트에 Apps Script를 추가하는 것으로 충분할 수 있어요.

중요한 질문은 “웹앱이 더 최신 기술인가?”가 아닙니다.

지금 불편한 이유가 단순히 반복 작업 하나 때문인지, 아니면 여러 사람이 정해진 규칙에 따라 같은 데이터를 처리해야 하기 때문인지 확인해야 합니다.

웹앱을 고려할 신호가 있어요

아래 문제가 반복된다면 도구보다 업무 구조를 바꿀 시점일 수 있습니다.

• 같은 이름과 연락처를 여러 시트에 계속 복사합니다.
• 노란색은 확인 중, 초록색은 완료처럼 셀 색깔이 상태를 대신합니다.
• 담당자가 기억하고 있어야만 다음 단계가 진행됩니다.
• 누가 언제 어떤 값을 바꿨는지 확인하기 어렵습니다.
• 여러 사람이 수정하다 값이 덮어써지거나 중복 행이 생깁니다.
• 신청자는 자신의 처리 상태를 알기 위해 담당자에게 물어봐야 합니다.
• 일부 담당자에게 필요한 정보만 보여주기 어렵습니다.
• 주간 보고를 만들 때마다 필터를 걸고 숫자를 다시 셉니다.

이 문제들의 공통점은 시트의 행 개수가 많다는 데 있지 않습니다. 업무의 상태, 순서, 권한이 사람의 기억 속에만 있다는 것이 더 큰 문제예요.

웹앱은 이 규칙을 명시적으로 만들 수 있습니다. 접수 상태는 정해진 값으로 저장하고, 권한에 따라 화면을 다르게 보여주고, 상태가 바뀌면 알림을 보내고, 필요한 숫자를 자동으로 집계할 수 있어요.

화면보다 현재 업무 흐름을 먼저 그려보세요

자동화를 시작할 때 흔히 “신청 페이지와 관리자 페이지를 만들어줘”라고 AI에게 요청합니다. 하지만 화면만 먼저 만들면 지금 사용하던 시트가 브라우저 안으로 옮겨올 뿐이에요. 담당자는 여전히 값을 복사하고 다음 행동을 기억해야 할 수 있습니다.

먼저 현재 업무를 다음 다섯 단계로 적어보세요.

입력 → 저장 → 판단과 상태 변경 → 후속 행동 → 결과 확인

교육 신청 업무라면 이렇게 정리할 수 있습니다.

여기에 권한을 하나 더 확인해야 합니다. 신청자, 운영 담당자, 강사가 각각 어떤 정보를 보고 바꿀 수 있는지 적어보세요.

이 과정을 거치면 필요한 기능이 페이지 이름보다 구체적으로 보입니다.

시트의 요소는 웹앱에서 이렇게 바뀝니다

스프레드시트에서 하던 일을 웹앱의 구성 요소로 번역해보면 이해하기 쉬워요.

여기서 중요한 변화는 색깔과 위치가 아니라 데이터의 의미를 저장한다는 것입니다.

노란색 셀은 사람에게만 “확인 중”으로 보입니다. 웹앱은 색깔 대신 확인 중이라는 상태를 저장해요. 그러면 그 상태만 모아 볼 수도 있고, 일정 시간이 지나도 그대로인 신청을 찾아 담당자에게 알려줄 수도 있습니다.

신청 업무를 웹앱으로 바꾸면 어떻게 달라질까요?

앞의 교육 신청 사례를 가장 작은 웹앱으로 바꿔볼게요.

신청자가 입력 화면을 제출
→ 서버가 필수 정보와 형식을 확인
→ 데이터베이스에 접수 상태로 저장
→ 관리자 화면에 새 신청이 표시
→ 담당자가 확정으로 상태 변경
→ 확정 안내 이메일 또는 문자 발송
→ 대시보드의 확정 인원이 자동으로 변경

신청자는 자신에게 필요한 화면만 보고, 운영자는 전체 신청을 관리하는 화면을 사용합니다. 데이터베이스는 신청 정보를 보관하고, 서버는 상태를 바꿀 수 있는 조건과 알림을 실행할 시점을 판단해요.

웹앱의 각 부분이 맡는 역할은 다음과 같습니다.

• 화면: 신청자가 정보를 입력하고 담당자가 목록을 확인합니다.
• 서버: 입력값을 검사하고 상태 변경과 알림 규칙을 실행합니다.
• 데이터베이스: 신청, 상태, 처리 기록을 계속 보관합니다.
• 외부 서비스: 이메일, 문자, 결제 같은 작업을 처리합니다.

프론트엔드와 서버가 어떻게 연결되는지 더 알고 싶다면 웹 애플리케이션의 전체 구조를 함께 읽어보세요. 하나의 프로젝트에서 화면과 서버 기능을 함께 만들고 싶다면 Next.js가 무엇인지, 서버에서 사용할 데이터베이스를 고르는 중이라면 Supabase를 추천하는 이유도 참고할 수 있습니다.

모든 업무를 한 번에 자동화하지 마세요

시트에는 오랫동안 쌓인 예외와 임시 규칙이 많습니다. 이것을 처음부터 모두 웹앱에 넣으려 하면 기능이 빠르게 커지고, 실제 업무와 맞는지 확인하기도 어려워져요.

먼저 처음부터 끝까지 이어지는 한 줄의 흐름만 만드세요.

신청서 작성
→ DB 저장
→ 관리자 목록 확인
→ 상태 변경
→ 안내 메시지 한 번 발송

이 흐름이 실제 업무에서 제대로 작동하는지 확인한 다음 검색, 통계, 담당자 배정, 결제 연결 같은 기능을 추가하는 편이 좋습니다.

반대로 첫 버전부터 아래 기능을 모두 넣을 필요는 없어요.

• 복잡한 대시보드
• 모든 종류의 자동 알림
• 세분화된 관리자 등급
• 과거의 모든 시트 데이터 이전
• 발생할 수 있는 모든 예외 처리

다만 개인정보를 다루는데 로그인과 권한이 필요한 경우처럼, 안전한 운영에 필수인 기능은 처음부터 포함해야 합니다.

시트에서는 보이지 않던 규칙을 결정해야 해요

사람이 시트를 관리할 때는 애매한 값을 보고 알아서 수정할 수 있습니다. 웹앱은 어떤 값이 정상인지 미리 알려줘야 해요.

개발을 시작하기 전에 다음 항목을 정리하세요.

각 기록을 구분하는 고유한 ID

동명이인이 있거나 같은 사람이 두 번 신청할 수 있으므로 이름만으로 신청을 구분하면 안 됩니다. 신청마다 바뀌지 않는 고유한 번호가 필요해요.

허용할 상태와 변경 순서

접수, 확인 중, 확정, 취소처럼 상태를 정하고 어떤 상태에서 어디로 이동할 수 있는지 결정합니다. 취소된 신청을 다시 확정할 수 있는지도 정해야 해요.

필수값과 입력 형식

이름, 연락처, 이메일 중 무엇이 필수인지, 전화번호와 날짜는 어떤 형식으로 받을지 결정합니다. 입력 화면뿐 아니라 서버에서도 다시 확인해야 해요.

중복을 판단하는 기준

이메일이 같으면 같은 신청으로 볼지, 같은 프로그램에 같은 연락처로 두 번 신청하는 것만 막을지 정합니다.

권한

신청자가 볼 수 있는 정보, 일반 담당자가 수정할 수 있는 값, 관리자만 할 수 있는 작업을 구분합니다.

취소와 되돌리기

잘못 처리했을 때 기록을 삭제할지, 취소 상태로 남길지 결정합니다. 중요한 업무라면 누가 언제 상태를 바꿨는지도 기록하는 편이 좋아요.

이런 규칙은 데이터베이스 구조와 서버 기능에 반영됩니다. 스프레드시트와 데이터베이스의 차이가 궁금하다면 두 저장 방식의 비교를 확인해보세요.

기존 시트 데이터는 정리한 뒤 옮기세요

웹앱을 만들었다고 기존 시트의 모든 행을 그대로 가져올 필요는 없습니다. 오래된 테스트 행, 중복된 연락처, 제각각인 상태값까지 옮기면 새 시스템에서도 같은 문제가 이어집니다.

다음 순서로 준비해보세요.

1. 원본 시트를 복사해 백업합니다.
2. 실제로 필요한 열과 현재 사용하지 않는 열을 구분합니다.
3. 날짜, 전화번호, 상태값의 형식을 통일합니다.
4. 중복 행과 테스트 데이터를 표시합니다.
5. 각 기록을 구분할 고유한 ID를 준비합니다.
6. 일부 데이터만 먼저 가져와 결과를 확인합니다.
7. 원본 건수와 가져온 건수, 상태별 숫자를 비교합니다.
8. 언제부터 새 웹앱만 사용할지 전환 시점을 정합니다.

처음부터 모든 과거 자료가 필요하지 않을 수도 있어요. 진행 중인 신청만 웹앱으로 옮기고, 완료된 과거 자료는 조회용 시트로 보관하는 방법도 있습니다.

웹앱으로 전환한 뒤에도 보고서나 일회성 분석을 위해 데이터를 스프레드시트 파일로 내보내는 기능은 유용합니다. 웹앱을 만든다는 것이 스프레드시트를 완전히 금지한다는 뜻은 아니에요. 각 도구가 잘하는 역할을 나누는 것입니다.

바이브코딩으로 시작하는 순서

AI에게 바로 코드를 요청하기 전에 아래 순서대로 업무를 전달해보세요.

1. 현재 시트의 이름과 열 제목을 적습니다.
2. 누가 언제 어떤 값을 입력하고 수정하는지 설명합니다.
3. 색깔, 메모, 별도 시트가 의미하는 상태를 말로 바꿉니다.
4. 반복 복사, 알림, 집계 중 시간이 많이 들거나 실수가 잦은 일을 고릅니다.
5. 입력, 저장, 상태 변경, 알림이 이어지는 가장 작은 흐름을 정합니다.
6. 가짜 데이터로 처음부터 끝까지 테스트합니다.
7. 필요한 기존 데이터만 정리해 옮깁니다.
8. 짧은 기간 실제 업무와 비교한 뒤 전환합니다.

핵심 기능을 작은 단위로 구현하고 확인하는 방법은 바이브코딩 가이드 8장에서도 이어서 볼 수 있습니다.

AI에게 현재 업무 분석부터 요청해보세요

개인정보가 담긴 실제 시트를 그대로 AI에게 전달하지 마세요. 이름, 이메일, 전화번호, 결제 정보는 가짜 값으로 바꾸고, 열 제목과 몇 개의 익명 예시만 제공하는 편이 안전합니다.

먼저 코드를 만들지 않고 현재 흐름을 분석하게 해보세요.

구글 스프레드시트로 처리하던 업무를 웹앱으로 바꾸려고 해. 아직 코드는 작성하지 말고 현재 업무를 분석해줘. 시트 이름, 열 제목, 개인정보를 가짜 값으로 바꾼 예시 행을 제공할게. 입력, 저장 데이터, 상태, 사람이 판단하는 일, 반복 복사, 알림, 권한, 보고서로 나눠 정리해줘. 결과는 ‘현재 작업 / 필요한 이유 / 웹앱에서 맡을 기능 / 자동화 여부 / 사람이 계속 판단할 부분 / 주의할 위험’ 표로 보여줘.

분석 결과를 확인한 뒤 가장 작은 구현 범위를 요청합니다.

분석한 업무에서 신청서 제출부터 관리자 확인, 상태 변경, 안내 메시지 발송까지 하나의 흐름만 첫 버전으로 만들고 싶어. 필요한 사용자 화면, 관리자 화면, 데이터, 상태 변경 규칙, 서버 기능, 외부 서비스를 정리해줘. 로그인, 대시보드, 통계처럼 첫 흐름에 꼭 필요하지 않은 기능은 뒤로 미뤄줘. 코드를 작성하기 전에 구현 순서와 각 단계의 확인 방법부터 제안해줘.

AI가 자동화할 수 있다고 해서 모든 판단을 맡길 필요는 없습니다. 환불 승인, 예외 가격 결정, 민감한 고객 응대처럼 기준을 완전히 정하기 어려운 일은 사람이 최종 결정하고, 웹앱은 필요한 정보를 모으고 기록하는 역할만 맡길 수 있어요.

정리

• 스프레드시트는 소수의 담당자가 직접 데이터를 다루는 유연한 업무에 잘 맞습니다.
• 간단한 알림이나 반복 작업은 Google Apps Script만으로 해결할 수도 있습니다.
• 복사, 상태 확인, 권한, 알림, 집계가 사람의 기억에 의존하기 시작하면 웹앱을 고려할 수 있습니다.
• 화면부터 만들지 말고 입력 → 저장 → 상태 변경 → 후속 행동 → 결과 확인으로 현재 업무를 정리해야 합니다.
• 셀 색깔은 명시적인 상태로, 행 복사는 연결된 데이터로, 수동 알림은 상태 변경 뒤 실행되는 기능으로 바꿀 수 있습니다.
• 모든 기능을 한 번에 만들지 말고 처음부터 끝까지 이어지는 가장 작은 업무 흐름부터 구현하세요.
• 기존 시트 데이터는 정리하고 일부만 시험한 뒤 옮기며, 필요하면 보고와 분석에는 계속 스프레드시트를 활용할 수 있습니다.

웹앱 자동화의 목표는 시트를 없애는 것이 아닙니다. 사람이 다음 일을 기억하고 같은 정보를 옮기는 시간을 줄이고, 누구나 같은 규칙으로 업무를 처리하게 만드는 것입니다.