코딩 모르는 자동화 담당자가 이틀 만에 상담센터 행정 웹앱을 배포했어요 (바우처 웹앱 1편) — 중요한 건 코딩이 아니라 실무진의 일을 번역하는 것

상담센터 바우처 행정 웹앱 구축기 — 실무진과 실시간으로 핑퐁하면서, 가짜 데이터 프로토타입 5단계 → 진짜 DB 전환 → 배포까지

🎯 바쁘시면 이것만 읽어도 돼요

• 코딩 못 하는 자동화 담당 직원이 Claude Code로 상담센터 바우처 행정 웹앱을 만들었어요 — 첫날은 규칙 세팅, 둘째 날에 프로토타입 5단계 + 진짜 DB 전환 + 배포까지 갔어요

• 비결은 "한 번에 다 만들어줘"가 아니라, 가짜 데이터로 화면을 먼저 완성하고 DB는 나중에 갈아끼우는 순서였어요

• 제일 큰 고비는 코딩이 아니었어요 — 실무진의 업무를 제가 요약해서 AI한테 전달하는데, 그 요약이 현장과 달라서 화면 다 만든 뒤에 데이터 구조를 갈아엎었어요

👀 이런 분들께 도움돼요

• 동료·팀이 쓸 업무 도구를 대신 만들어주는 역할을 맡은 비개발자

• "AI한테 뭐라고 시켜야 할지"보다 "실무자한테 뭘 물어봐야 할지"가 막막한 분

• 프로토타입은 만들어봤는데 진짜 DB·로그인·권한으로 넘어가는 게 무서운 분

• 만들다가 구조가 틀렸다는 걸 알았을 때 갈아엎어야 하나 고민해본 분

😮 Before: 우리 센터 바우처 업무엔 '한눈에 보는 화면'이 없었어요

최근 클코를 배우다보니 상담센터에서 자동화를 맡게 되었어요. 상담이나 행정을 직접 보는 실무자는 아니지만 옆에서 본 바우처 업무는 손이 많이 갔어요 — 내담자마다 바우처를 등록하고, 상담사가 자필 제공기록지를 내고, 소장님이 확인해야 정산이 되고, 본인부담금 입금도 챙겨야 해요. 역할도 상담사·행정·회계·소장 넷으로 갈리고요. 이게 한 화면에 모이는 도구가 없어서, 누가 뭘 냈고 뭐가 빠졌는지는 결국 실무진이 기억해야 했어요. 그러다보니 누락도 많이 생겼고요.

✨ After: 4역할이 같이 쓰는 웹앱이 이틀 만에 URL로 나왔어요

로그인하면 역할별로 다른 메뉴가 보이고, 기록지 제출 → 소장 확인 → 정산 반영이 화면 안에서 흘러가는 웹앱이 됐어요. 첫날 워크스페이스 세팅, 둘째 날 프로토타입 5단계 → Supabase(진짜 DB) 전환 → Vercel 배포까지. 코드는 한 줄도 직접 안 썼어요. 대신 말을 정말 많이 했어요 — AI한테도, 실무진한테도요.

🛠️ 이 앱이 하는 것 (배경 30초)

• 내담자×바우처 단위로 등록을 관리해요 (기간·등급·담당 상담사)

• 상담사는 회기별 기록지 사진을 올리고, 소장은 확인 버튼으로 정산에 반영해요

• 본인부담금 입금은 회계·소장만 수정할 수 있고, 상담사는 본인 내담자만 보여요

• 미제출·미확인이 화면에서 바로 표시돼요 — "실무진이 기억하던 것"이 앱의 일이 됐어요

🔨 과정: 규칙 → 가짜 데이터 → 번역 오류 발각 → 진짜 DB

1️⃣ 첫날은 코딩 대신 규칙만 세웠어요

바로 "만들어줘" 하고 싶은 걸 참고, 첫날은 워크스페이스에 규칙 문서(CLAUDE.md)부터 만들게 했어요. 핵심 규칙은 세 개였어요 — 자격·금액·일자는 추정 금지, 불확실하면 나한테 질문할 것 / 개인정보는 로컬에만, git에 못 올라가게 차단 / 등록·제출의 최종 확정은 사람이 할 것. 내담자 정보를 다루는 앱이라 이 세 줄이 없으면 시작을 못 했어요. 하루를 썼는데, 이후 작업 내내 AI가 애매하면 멈추고 물어봤으니 본전은 충분히 뽑았어요.

2️⃣ 가짜 데이터로 화면을 먼저 다 만들었어요

둘째 날, 프로토타입을 5단계로 쪼개서 진행했어요 — 뼈대 → 데이터 모델·4역할 전환 → 배정 화면 → 일정·기록지 업로드 → 소장 확인·본인부담금. 이 단계에선 DB도 로그인도 없이 전부 가짜 데이터예요. 덕분에 "화면이 실제 업무랑 맞나"만 보면 됐고, 단계마다 제 눈으로 확인하고, 애매한 건 실무진한테 바로 물어보고, code-review를 시키고 저장(커밋)하고 넘어갔어요. 리뷰가 제가 못 봤을 타입 버그를 실제로 하나 잡아내기도 했고요.

3️⃣ 😲 하이라이트: "내담자 한 명 = 상담사 한 명" — 제 번역이 틀렸어요

본인부담금 화면까지 다 만들고 나서야 알았어요. 결과적으로 바우처를 두 개 받는 내담자 같은 상황이 생길 수 있다고 들었고 바우처마다 담당 상담사가 달라요. 그런데 앱은 제가 AI한테 처음 설명한 대로 "내담자에게 상담사 한 명"으로 짜여 있었어요. AI가 틀린 게 아니에요. 실무진의 업무를 AI한테 전달하는 중간에서, 제가 잘못 요약한 거예요.

화면을 다 만든 뒤라 고민했는데, 결국 데이터 구조를 통째로 갈아엎었어요 — 모든 관리 단위를 '내담자'에서 '내담자×바우처(등록)'로요. 사람 개발자한테 이걸 부탁했으면 며칠짜리 부탁이었을 텐데, AI는 갈아엎는 걸 무서워하지 않더라고요. 반나절 안에 화면들이 새 구조로 다시 맞춰졌어요.

비슷한 일이 한 번 더 있었어요. 등록여부(O/X) 관리 기능을 만들었는데, 소장님이 한마디 하셨어요 — "상담사 배정이 안 되면 일정 등록도 안 해요." 그 말 한마디에 기능을 통째로 뺐어요. 실무진의 한 문장이 제 기획 열 줄보다 정확했어요. 실시간으로 물어볼 수 있는 거리에 실무진이 있다는 게 이 프로젝트 최대의 자원이었어요.

4️⃣ 진짜 DB로 갈아끼우기 — 읽기부터, 권한은 맨 끝에

화면이 업무와 맞다는 확신이 생긴 뒤에야 Supabase(진짜 DB)로 넘어갔어요. 순서를 잘게 쪼갰어요 — ① 테이블 설계 ② 읽기만 DB로 전환(쓰기는 아직 가짜) ③ 진짜 로그인 ④ 쓰기 전환 ⑤ 역할별 권한을 서버에서 강제(RLS). 권한은 화면에서 숨기는 걸로 끝내지 않고, 검증 스크립트를 돌려서 "상담사 계정으론 진짜 본인 것만 보이는지"를 확인하고 통과시켰어요. 끝나고 Vercel로 배포해서 URL을 받았어요.

📊 결과

• 역할 4종(상담사·행정·회계·소장)별 메뉴·권한 분리, 권한은 서버 강제

• 중간에 데이터 모델 1회 전면 교체, 만든 기능 1개 드롭 — 둘 다 "실무진이 더 정확해서"

💡 효과적이었던 것

• 가짜 데이터로 먼저 완성한 것 — 화면과 업무가 맞는지부터 검증하고, DB는 나중에 갈아끼웠어요. 모델을 갈아엎는 대사건이 있었는데도 이 순서 덕에 피해가 화면 수정으로 끝났어요

• 단계마다 멈춰서 확인한 것 — 제 눈 검증 + 실무진 확인 + code-review + 커밋 세트. 어디서 틀어졌는지 항상 한 단계 안에서 찾을 수 있었어요

• 실무진 말을 스펙으로 쓴 것 — 소장님 한마디로 기능을 빼고, 실제 내담자 사례로 모델을 바꿨어요. 제가 정리한 요구사항보다 현장 문장이 셌어요

⚠️ 이런 건 아쉬웠어요

• 남의 업무를 받아 적는 건 생각보다 어려웠어요. 실무진은 당연해서 말하지 않는 게 많고, 저는 몰라서 묻지 못하는 게 많았어요. "바우처 2개 내담자" 같은 예외는 묻기 전엔 안 나와요

• 실제 데이터 몇 줄을 너무 늦게 봤어요. 처음부터 진짜 내담자 명단 몇 줄(가명으로라도)을 실무진한테 받아서 같이 봤으면, 그 예외를 화면 만들기 전에 발견했을 거예요

📋 따라하려면

1. 실무자를 인터뷰해서 업무를 역할별로 적어요 — "누가, 뭘 내고, 누가 확인하고, 뭐가 돈이 되나". 실무자가 당연해서 말 안 한 것이 진짜 스펙이에요

2. 시작 전에 규칙 3줄부터 만들어요 — 추정 금지 / 민감정보 로컬만 / 최종 확정은 사람

3. 가짜 데이터로 화면 먼저 — DB·로그인은 화면이 업무와 맞다는 확신이 든 다음에

4. 단계마다 직접 확인 + 실무진 확인 + code-review + 커밋, 세트로 묶어서 진행해요

5. 실제 데이터 샘플(가명) 몇 줄을 초반에 받아서 AI한테 보여줘요 — 예외 케이스가 모델을 결정해요

6. DB 전환은 읽기 → 로그인 → 쓰기 → 권한 순서로 쪼개요

내 다음 목표

• 진짜 데이터(내담자 200명, 2년치 기록)를 부어서 실운영에 들어가기 — 그리고 여기서 사건이 하나 터지는데, 그 이야기는 따로 한 편으로 할 예정.

• 현황 화면을 요약 패널에서 제대로 된 대시보드로 키우기

• 실무진이 보고 따라할 역할별 사용 가이드 만들기