Google Forms를 입력 도구로 인정하기

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

운영 시스템을 만든다고 하면 입력 화면부터 직접 만들고 싶어진다.

회원 인증을 붙이고, 신청 폼을 만들고, 검증 로직을 넣고, 데이터베이스에 저장하고, 관리자 화면에서 조회하게 만드는 방식이다.

하지만 모든 입력 흐름에 직접 만든 화면이 필요한 것은 아니다.

특히 외부 사용자가 간단한 신청 정보를 제출하는 업무라면 Google Forms 같은 도구가 충분히 좋은 입력 도구가 될 수 있다.

문제 상황

외부 사용자가 특정 기간에 신청 정보를 제출해야 하는 업무가 있었다.

입력 항목은 정해져 있었고, 제출량은 폭발적으로 많지 않았다. 운영자는 제출된 내용을 확인하고, 이후 상태를 관리해야 했다.

이 상황에서 선택지는 두 가지였다.

첫 번째는 신청 화면을 직접 만드는 것이다.

두 번째는 Google Forms를 입력 도구로 사용하고, 이후 흐름을 자동화하는 것이다.

나는 두 번째 방향이 더 현실적이라고 봤다.

왜 직접 만들지 않았나

직접 만든 신청 화면에는 장점이 있다.

• UI를 원하는 대로 만들 수 있다.
• 검증 로직을 세밀하게 넣을 수 있다.
• 데이터베이스에 바로 저장할 수 있다.
• 로그인과 권한을 직접 통제할 수 있다.

하지만 그만큼 책임도 늘어난다.

• 입력 화면을 유지보수해야 한다.
• 모바일 대응을 해야 한다.
• 외부 사용자의 접근 문제를 처리해야 한다.
• 제출 실패와 중복 제출을 관리해야 한다.
• 스팸과 보안 이슈를 고려해야 한다.
• 운영자가 폼 항목을 바꾸고 싶을 때 개발 배포가 필요하다.

업무 규모가 작고 입력 항목이 자주 바뀐다면, 이 책임은 생각보다 크다.

Google Forms가 잘하는 것

Google Forms는 입력 수집에 강하다.

• 외부 사용자에게 링크만 전달하면 된다.
• 모바일에서도 기본 사용성이 괜찮다.
• 필수 입력과 기본 검증을 설정할 수 있다.
• 제출 결과가 자동으로 Sheets에 쌓인다.
• 운영자가 항목을 어느 정도 직접 수정할 수 있다.
• 별도 서버 없이 사용할 수 있다.

입력 도구로만 보면 꽤 강력하다.

중요한 것은 Forms에 모든 책임을 주지 않는 것이다.

Forms는 입력을 받는다.

상태 관리, 공개 데이터 생성, 내부 검토, 동기화는 다른 도구가 맡는다.

Google Forms의 한계

Forms에도 분명한 한계가 있다.

• 복잡한 조건부 검증이 어렵다.
• 신청 상태를 사용자별로 세밀하게 보여주기 어렵다.
• 외부 시스템과의 동기화는 별도 스크립트가 필요하다.
• 운영자용 관리 화면으로는 부족하다.
• 제출 후 수정 흐름이 복잡해질 수 있다.
• 권한 모델이 정교하지 않다.

그래서 Forms를 시스템 전체로 보면 안 된다.

Forms는 입력 계층이다.

그 뒤에 원천 데이터 저장소, 자동화 스크립트, 공개 API, 운영자 화면이 이어져야 한다.

입력과 상태 관리를 분리하기

가장 중요한 설계 원칙은 입력과 상태 관리를 분리하는 것이다.

Forms는 사용자가 제출한 원본 입력을 받는다.

운영 상태는 Sheets나 별도 시스템에서 관리한다.

예를 들어 다음처럼 나눌 수 있다.

단계	담당
신청 제출	Google Forms
원본 저장	Google Sheets
운영 상태 관리	Sheets 또는 운영 콘솔
자동 처리	Apps Script
화면 제공	API + 정적 페이지

이렇게 나누면 Forms의 한계를 다른 계층에서 보완할 수 있다.

운영자가 직접 바꿀 수 있는 장점

운영 업무에서는 입력 항목이 자주 바뀐다.

문구 하나, 선택지 하나, 안내 문장 하나를 바꾸기 위해 매번 개발 배포가 필요하면 업무 속도가 느려진다.

Google Forms를 쓰면 운영자가 어느 정도 직접 수정할 수 있다.

이것은 단순한 편의가 아니다. 운영 조직의 속도를 높이는 구조다.

물론 모든 변경을 자유롭게 두면 데이터 구조가 흔들릴 수 있다. 그래서 바꿔도 되는 항목과 바꾸면 안 되는 항목을 문서화해야 한다.

예를 들어 다음은 조심해야 한다.

• 응답 컬럼 순서
• 스크립트가 참조하는 질문 제목
• 필수 식별값
• 상태값으로 쓰는 선택지

운영자가 수정할 수 있는 범위와 개발자가 관리해야 하는 범위를 나눠야 한다.

제출 후 흐름을 설계하기

Forms를 쓰기로 했다면 제출 이후가 더 중요하다.

제출 후에는 보통 다음 흐름이 필요하다.

폼 제출
-> Sheets에 응답 기록
-> Apps Script trigger 실행
-> 데이터 검증 또는 가공
-> AWS API로 동기화
-> S3 JSON 저장
-> 운영자 화면 또는 공개 화면에 반영

Forms는 첫 단계만 담당한다.

자동화의 품질은 그 이후 흐름에서 결정된다.

사용자 경험에서 조심할 점

Forms는 간단하지만 제품처럼 세밀한 UX를 제공하지는 않는다.

그래서 다음을 보완해야 한다.

• 제출 완료 후 안내 문구를 명확히 쓴다.
• 신청 기간과 조건을 폼 상단에 분명히 적는다.
• 중복 제출 허용 여부를 정한다.
• 제출 후 확인 페이지를 별도로 제공할지 결정한다.
• 사용자가 자신의 신청 상태를 확인할 수 있는 경로를 제공한다.

입력은 Forms로 받더라도, 확인과 조회는 별도 페이지로 제공할 수 있다.

이렇게 하면 Forms의 단순함과 운영 시스템의 필요를 함께 만족시킬 수 있다.

언제 Forms를 쓰면 안 되는가

Forms가 항상 좋은 것은 아니다.

다음 조건이라면 직접 만든 입력 화면이나 전용 시스템을 검토해야 한다.

• 실시간 재고나 좌석 같은 강한 동시성 제어가 필요하다.
• 결제나 민감 정보 입력이 포함된다.
• 사용자별 로그인과 권한이 필수다.
• 입력 중 복잡한 계산이나 검증이 필요하다.
• 제출량이 매우 많고 성능 관리가 필요하다.
• 브랜드 경험이 중요한 공개 서비스다.

즉, Forms는 운영형 입력에는 적합하지만 제품 핵심 경험에는 부족할 수 있다.

정리

Google Forms를 입력 도구로 인정한다는 것은 대충 만든다는 뜻이 아니다.

입력 수집이라는 책임을 이미 검증된 도구에 맡기고, 개발 리소스는 그 이후의 자동화와 운영 흐름에 집중한다는 뜻이다.

좋은 기준은 이것이다.

• 입력 항목이 단순한가
• 외부 사용자가 쉽게 접근해야 하는가
• 운영자가 항목을 직접 바꿔야 하는가
• 제출 이후 처리 흐름을 별도로 설계할 수 있는가

이 조건을 만족한다면 Google Forms는 충분히 좋은 입력 계층이 될 수 있다.

함께 볼 GitHub 저장소

• workflow-automation-samples