간단한 웹앱으로 업무 자동화

반복 업무 중에는 엑셀과 메신저로는 한계가 오는 일이 있습니다. 요청을 받고, 담당자를 정하고, 상태를 추적하는 일이 대표적입니다. 이 장에서는 한 장짜리 요구사항 문서(PRD)에서 시작해 데모를 만들고, 구글 시트에 데이터를 저장하고, 웹에 올려 운영하는 과정을 다룹니다.

언제 웹앱이 필요한가

웹앱을 만들기 전에 먼저 시트나 폼으로 충분하지 않은지 따져 봅니다. 다음 중 둘 이상이 해당할 때 웹앱을 고려합니다.

• 여러 사람이 같은 데이터를 동시에 입력하고, 각자 보는 화면이 달라야 한다.
• 입력할 때마다 상태가 바뀌고(접수, 처리 중, 완료), 그 상태를 한눈에 봐야 한다.
• 입력 규칙이 있어서 잘못된 값을 막아야 한다.
• 시트를 직접 열어 고치면 실수가 자주 난다.

입문 과정 3회차에서 반복 업무를 고르고 AI에게 맡기는 법을, 4회차에서 결과물을 웹에 올리고 링크로 공유하는 법을 익혔습니다. 이 장은 두 회차를 이어서, 저장과 운영까지 갖춘 작은 앱으로 넓히는 단계입니다. 회차별 실습 프롬프트는 액티전스 자료실에서 볼 수 있습니다.

가상의 예: 사내 요청 접수 앱

가상의 소규모 회사에서 총무 담당자 한 명이 사무용품 구매, 회의실 예약, 장비 수리 요청을 메신저와 구두로 받고 있다고 가정합니다. 요청이 누락되고, 누가 처리 중인지 모르고, 월말에 정리가 어렵습니다. 이 문제를 해결하는 요청 접수 앱의 요구사항은 아래와 같습니다.

• 직원은 요청 유형, 제목, 내용, 희망 날짜를 입력해 요청을 등록한다.
• 총무 담당자는 요청 목록을 보고 상태(접수, 처리 중, 완료, 보류)를 바꾸고 메모를 남긴다.
• 직원은 자기가 낸 요청의 상태를 볼 수 있다.
• 월말에 유형별 건수를 볼 수 있다.

기능이 많지 않은 이 정도 규모가 첫 웹앱으로 알맞습니다.

1단계. 한 장짜리 PRD 쓰기

PRD(Product Requirements Document)는 무엇을 만들지 적은 문서입니다. AI에게 앱을 만들게 할 때 PRD는 "빈칸을 AI가 추측하지 않게 하는 문서"입니다. 길게 쓸 필요는 없고, 다음 항목이 한 장에 들어가면 됩니다.

특히 "하지 않을 것"이 중요합니다. 로그인, 결제, 알림 문자 같은 기능은 처음에는 빼겠다고 적어 두면 AI가 범위를 넓히지 않습니다. 기능마다 "누르면 이렇게 된다"는 동작과, 완성됐다고 판단할 수 있는 확인 기준을 한 줄씩 붙입니다. 이 방식은 입문 과정 2회차에서 연습한 "버튼을 누르면 무엇이 일어나는지까지 말한다"와 같은 원리입니다.

PRD 작성을 도와주는 PRD 스킬이 있습니다(부록 B). 아이템 한 줄을 주면 필요한 항목을 추론해 채우고, 꼭 필요한 것만 객관식으로 물어 PRD 문서를 만들어 줍니다. 스킬을 쓰지 않더라도 실습의 프롬프트로 같은 효과를 낼 수 있습니다.

2단계. 데모부터 만들기

처음부터 실제 데이터와 로그인까지 붙이지 않고, 가짜 데이터로 돌아가는 데모를 먼저 만듭니다. 데모에서 확인할 것은 화면 흐름과 사용성입니다. 요청 등록, 목록 보기, 상태 변경, 월말 집계가 한 바퀴 돌아가는지 눌러 보며 확인합니다.

데모 단계가 있으면 좋은 이유는 세 가지입니다.

• 실제 개인정보를 쓰지 않고 시험할 수 있습니다.
• 동료에게 보여 주고 의견을 받기 쉽습니다. 말로 설명하는 것보다 눌러 보게 하는 것이 훨씬 빠릅니다.
• 로그인과 저장은 나중에 붙이면 되므로 첫 결과가 빨리 나옵니다.

원샷 프로토타이핑

액티전스 라이브러리에는 PRD 한 장으로 빈 폴더에서 배포까지 이어 가는 카드와 스킬이 있습니다. 라이브러리의 "원클릭 풀스택" 카드와 같은 내용을 스킬로 만든 것이 원샷 프로토타이핑 스킬입니다(부록 A, 부록 B). 카드의 흐름을 요약하면 다음과 같습니다.

1. 로그인 없이 모든 기능을 눌러 볼 수 있는 데모 빌드를 만든다.
2. 기능 초안이 통과하면 화면 디자인을 다듬는다.
3. 보안을 점검하고 강화한다.
4. 웹에 배포하고 실제 주소에서 동작을 확인한다.

저장소는 기본적으로 구글 시트이고, 이를 위한 구글 클라우드 설정(서비스 계정, 키, 시트 공유)까지 이 흐름에 포함되어 있습니다. 이 스킬은 "프로토타이핑"이라는 단어와 PRD가 모두 있을 때만 작동하도록 만들어져 있습니다. 카드는 사람의 확인 없이 끝까지 진행하는 성격이 강하므로, 처음에는 짧은 PRD로 시험하고 결과를 직접 확인하는 것이 좋습니다. 카드와 스킬의 전문은 프롬프트 라이브러리와 스킬 페이지에 있습니다.

풀스택 기능 구현

이미 만든 앱에 기능을 하나 더 붙일 때는 풀스택 기능 구현 스킬이 맞습니다. 데이터 저장, 서버 처리, 화면, 테스트를 기능 하나 단위로 함께 만듭니다. 예를 들어 요청 접수 앱에 "첨부 사진 올리기"를 추가하는 식입니다. 이 스킬은 "풀스택"과 "구현"이라는 단어가 모두 들어 있을 때 작동합니다. 새 앱을 처음 만들 때는 원샷 프로토타이핑을, 있는 앱에 기능을 더할 때는 풀스택 기능 구현을 씁니다.

여러 세션과 서브에이전트로 일을 나눠 맡기는 방법은 10장에서, 스킬을 설치하는 방법은 11장에서 다룹니다.

3단계. 구글 시트에 데이터 저장하기

데모가 마음에 들면 실제 저장소를 붙입니다. 첫 앱의 저장소로는 구글 시트가 적당합니다. 이미 아는 도구이고, 데이터를 사람이 직접 열어 볼 수 있으며, 별도의 데이터베이스를 배우지 않아도 됩니다. 동시에 많은 사용자가 쓰거나 데이터가 아주 많아지면 한계가 있으므로, 그때는 전문 데이터베이스로 옮기는 것을 AI와 함께 검토합니다.

데이터 3단계 사다리

데이터를 어디까지 앱에 연결할지는 세 단계로 나눠 판단합니다.

대부분의 업무 도구는 2단으로 충분합니다. 시트를 공개할 수 없거나 화면에서 데이터를 써야 할 때만 3단으로 올립니다. 어느 단계든 시트 한 장이 원본(단일 원본, SSOT, 7장)이고 화면은 그것을 비출 뿐입니다. 2단에는 한계가 두 가지 있습니다. 읽기만 되고, 게시 주소를 아는 사람은 누구나 볼 수 있습니다. 민감한 정보가 든 시트는 2단으로 게시하지 않습니다.

3단 연결의 원리와 설정

3단에서는 앱이 구글 시트에 직접 로그인하지 않습니다. 앱 전용의 "서비스 계정"이라는 로봇 계정을 만들고 그 계정에 시트를 공유합니다. 앱은 서비스 계정의 열쇠(키)로 시트를 읽고 씁니다. 설정은 목적 기준으로 네 가지입니다. 메뉴 이름은 자주 바뀌므로 공식 문서와 Claude의 안내를 대조합니다.

1. 클라우드 프로젝트를 만듭니다.
2. 구글 시트를 프로그램에서 쓸 수 있도록 해당 API(프로그램용 창구)를 켭니다.
3. 서비스 계정을 만들고 키를 받습니다.
4. 그 서비스 계정의 이메일 주소에 시트를 공유합니다.

막히면 지금 보는 화면을 설명하고 Claude에게 다음에 할 일을 묻습니다. 계정 생성과 키 발급은 사람이 직접 합니다.

시트 설계

• 시트 한 장에 한 종류의 데이터만 둡니다. 요청 접수 앱이라면 "요청" 시트 하나로 시작합니다.
• 첫 줄에 열 이름을 둡니다: 접수번호, 접수시각, 요청자, 유형, 제목, 내용, 희망일, 상태, 담당자 메모, 처리일.
• 상태는 정해진 값만 쓰도록 드롭다운으로 제한합니다.
• 행을 지우지 말고 상태로 관리합니다. 기록이 남아야 월말 집계와 이력 확인이 됩니다.
• 앱이 쓰는 시트와 사람이 보는 보고용 시트를 분리합니다. 사람이 앱 시트를 직접 고치다 열 순서를 바꾸면 앱이 멈춥니다.

비밀 값 다루기

서비스 계정 키, 시트 주소, 발송 서비스의 API 키는 모두 비밀 값입니다. 다음 규칙을 지킵니다.

• 채팅창에 붙여 넣지 않습니다. 대화 기록은 다른 곳에 남을 수 있습니다. 키가 필요하다면 "키 값은 환경 변수 파일에 직접 넣을 테니, 어떤 이름으로 읽도록 코드를 짜 달라"고 요청합니다.
• 코드 파일에 쓰지 않습니다. 값은 .env 같은 환경 변수 파일에 두고, 코드는 이름으로만 읽습니다. 특히 화면(브라우저)에서 실행되는 코드에 키를 넣으면 브라우저의 개발자 도구로 누구나 꺼내 볼 수 있으므로, 키는 서버 쪽 코드에서만 씁니다.
• 저장소에 올리지 않습니다. .env 파일은 Git이 무시하도록 .gitignore에 적습니다. 이미 올렸다면 키를 폐기하고 새로 발급받습니다. 파일에서 지우는 것만으로는 이력에 남기 때문입니다.
• 배포 서비스의 환경 변수 설정에 넣습니다. 배포된 앱이 읽는 값은 배포 서비스의 설정 화면에 입력합니다.
• 권한을 최소로 줍니다. 서비스 계정에는 해당 시트 하나만 공유하고, 필요한 권한만 줍니다.
• 키가 노출됐다고 의심되면 즉시 폐기합니다.

비밀번호·키를 입력하는 단계도 사람이 직접 합니다. Claude에게 시킬 일은 순서를 안내받고, 코드가 환경 변수를 올바르게 읽는지 확인하는 것입니다.

4단계. 웹에 배포하기

파일에서 주소로

앱을 만들고 나면 파일 상태로 둘지, 주소를 붙일지가 갈립니다.

파일로 끝난 도구는 만든 사람만 쓰고 조직에 남지 않습니다. 주소가 붙는 순간 내 도구가 우리 도구가 됩니다. 보통 코드는 저장소 서비스에 올려 원본과 이력을 보관하고, 호스팅 서비스가 주소를 붙이며 저장소가 바뀌면 자동으로 다시 배포합니다. 한 번 연결해 두면 "고쳐 줘" 한마디로 주소의 내용이 최신이 됩니다. 이 흐름은 20장에서 이어서 다룹니다.

주소에는 나만 볼 수 있는 것(localhost), 임시 주소, 정식 도메인의 구분이 있습니다. 6장의 "주소의 네 가지"에서 정리했습니다.

배포는 만든 앱을 인터넷의 서버에 올려 주소로 열 수 있게 하는 일입니다. 입문 과정 4회차에서 정적 파일을 올려 본 경험이 있다면, 이제는 서버 처리가 있는 앱을 올립니다. Vercel 같은 호스팅 서비스가 흔히 쓰이며, 구체적인 올리는 방법은 서비스 공식 문서(Vercel 문서)의 안내를 따릅니다. 서비스의 메뉴와 명령은 바뀌므로 AI가 알려 주는 메뉴 이름을 그대로 믿지 말고 공식 문서와 대조합니다.

배포 전 점검 목록입니다.

• 비밀 값이 코드나 저장소에 없는지 확인했다.
• 환경 변수를 배포 서비스에 입력했다.
• 데모 데이터가 아니라 실제 시트에 연결되는지 확인했다.
• 누가 이 주소로 접근할 수 있는지 정했다. 사내용이라면 주소만 알면 누구나 열 수 있는 상태가 되지 않도록 접근 제한 방법을 정했다.
• 이전 버전으로 되돌리는 방법을 알고 있다.

배포 후에는 로그인하지 않은 시크릿 창에서도 열어 보고, 내 기기가 아닌 다른 기기에서 열어 보고, 요청 하나를 실제로 등록한 뒤 시트에 들어갔는지 확인합니다. 이 확인 과정은 20장에서 더 자세히 다룹니다.

5단계. 운영하기

앱은 만든 날부터 운영이 시작됩니다. 작은 앱이라도 다음은 정해 둡니다.

• 담당자: 문제가 생기면 누가 고치는가.
• 백업: 시트의 복사본을 주기적으로 만들어 둔다.
• 권한 정리: 퇴사자나 담당이 바뀐 사람의 접근을 정기적으로 정리한다.
• 개인정보: 시트에 담긴 개인정보의 보관 기간을 정하고 지난 기록을 지운다.
• 변경 기록: 앱을 고칠 때마다 무엇을 왜 바꿨는지 짧게 남긴다. 세션 인계 문서(부록 B의 Session-Handoff 스킬)가 도움이 됩니다.
• 의견 수집: 사용자가 불편한 점을 적을 곳을 하나 둔다.

문제가 생기면 입문 과정 4회차에서 연습한 질문 틀처럼 오류 메시지와 상황을 그대로 AI에게 보여 주고 원인을 좁힙니다. 버그가 어렵다면 디버깅 스킬을 씁니다(부록 B). 앱이 중요한 업무를 맡게 되면 계획을 더 깊게 세우고 자가검증을 거치는 방식으로 넘어갑니다(19장).

실습

실습 1. 요청 접수 앱 PRD 쓰기

아래 프롬프트로 한 장짜리 PRD를 만듭니다. AI가 질문을 먼저 하게 해서 빈칸을 줄입니다.

나는 [직무]이고, 우리 팀의 [요청 접수 업무]를 웹앱으로 만들고 싶어. 아직 코드를 만들지 말고 먼저 한 장짜리 PRD를 써 줘.

[업무 설명]
- 지금은 [메신저/구두/메일]로 요청을 받고 있어
- 요청 유형은 [유형 목록]
- 처리하는 사람은 [몇 명, 역할]
- 불편한 점은 [누락, 진행 상황 모름, 월말 정리 어려움 등]

PRD 작성 전에 꼭 필요한 질문만 객관식 위주로 한 번에 하나씩 물어봐 줘. 답이 모이면 아래 항목으로 PRD를 써 줘.
1. 문제  2. 사용자와 역할  3. 성공 기준(측정 가능한 문장으로)  4. 하지 않을 것(최소 3개, 로그인·결제·알림 문자 포함 여부 판단)  5. 제약(개인정보, 사용 기기)  6. 화면별 기능(각 기능마다 누르면 무슨 일이 일어나는지와 확인 기준 한 줄)  7. 저장할 데이터 항목과 상태 값

내가 말하지 않은 사실은 지어내지 말고 "가정:"이라고 표시해 줘. 처음 버전은 로그인 없이 가짜 데이터로 동작하는 데모를 기준으로 써 줘.

실습 2. 데모 빌드 요청하기

PRD가 나오면 파일로 저장한 뒤 Claude Code 세션을 엽니다(9장).

작업 폴더의 PRD.md를 읽고 이 PRD의 데모를 만들어 줘.
- 로그인 없이 모든 기능을 눌러 볼 수 있어야 해.
- 데이터는 코드 안의 가짜 데이터로 시작하되, 나중에 구글 시트로 바꿀 수 있게 데이터를 읽고 쓰는 부분을 한 파일로 분리해 줘.
- PRD의 "하지 않을 것"은 만들지 마.
- 비밀 값은 코드에 쓰지 말고 환경 변수 이름만 정해 둬. 값은 내가 직접 넣을 거야.
- 끝나면 PRD의 확인 기준을 하나씩 어떻게 눌러 보면 되는지 단계별로 알려 줘.
먼저 만들 파일 목록과 계획을 보여 주고, 내가 확인하면 시작해 줘.

실습 3. 비밀 값 점검하기

이 프로젝트에 비밀 값이 코드나 저장소에 들어 있는지 점검해 줘. API 키, 서비스 계정 키, 비밀번호, 개인 이메일 주소가 파일에 직접 적혀 있는지 찾고, .env 파일이 .gitignore에 포함되어 있는지 확인해 줘. 발견한 것은 파일 이름과 위치만 알려 주고 값 자체는 출력하지 마.

선택 과제. 시트를 읽기 전용으로 게시해 화면에 비추기 (2단)

가상의 요청 목록 시트(개인정보가 없는 연습용 데이터)를 만들고 읽기 전용으로 게시합니다. 게시 방법은 구글 공식 안내를 따르고, 게시한 주소는 연습이 끝나면 게시를 중단합니다.

구글 시트를 읽기 전용으로 게시한 주소가 있어. 이 데이터를 읽어서 표로 보여 주는 화면만 만들어 줘. 쓰기 기능은 만들지 마. 시트 주소는 코드에 직접 쓰지 말고 환경 변수 이름으로 읽게 해 줘. 이 방식(2단)의 한계 두 가지도 마지막에 정리해 줘.

정리

• 웹앱은 여러 사람이 같은 데이터를 쓰고 상태를 추적해야 할 때 필요합니다. 시트나 폼으로 충분하면 거기서 멈춥니다.
• PRD는 문제, 사용자, 성공 기준, 하지 않을 것, 제약, 기능, 데이터를 한 장에 담고, "하지 않을 것"이 범위를 지켜 줍니다.
• 데모를 먼저 만들어 눌러 본 뒤 구글 시트 저장을 붙이고, 읽기 전용 게시(2단)로 충분한지 먼저 따져 봅니다. 새 앱은 원샷 프로토타이핑, 기존 앱의 기능 추가는 풀스택 기능 구현이 맞습니다.
• 서비스 계정 키와 API 키는 채팅에 붙여 넣지 않고, 코드에 쓰지 않고, 환경 변수로만 다루며, 새는 즉시 폐기합니다.
• 배포는 파일이 아니라 주소로 공유하는 일이며, 공식 문서를 따르고, 올린 뒤 다른 기기에서 실제 등록을 해 보며, 운영 담당자·백업·권한 정리·개인정보 보관 기간을 정합니다.