사내 운영 자동화 도구 허브 — PM이 직접 만든 딸깍 툴
매달 반복되는 정산·경시대회 집계 업무를 웹앱으로 딸깍 처리. PM이 직접 설계·개발해 사내 배포했고, 바이브코딩을 판단→실행 사이클로 내재화한 사례.
Context
B2B SaaS 에듀테크 PM 역할에는 기획 외에도 매달 반복되는 운영 업무가 상당량 포함됩니다. 사업소득 지급요청서 생성, KMM 경시대회 집계, 프린팅 정산, 파트너 정책 안내 등 종류는 다양하지만 공통점은 하나였습니다 — 매번 손으로 처리하지만 로직 자체는 정형화되어 있다는 것.
AI 코드 어시스턴트로 실제 사내에서 쓸 수 있는 웹 도구까지 빠르게 만들 수 있는 시점이 왔다고 판단했습니다. 이 판단을 시험한 프로젝트가 이 도구 허브입니다.
Problem
손으로 반복 처리해오던 두 업무의 부담을 정량으로 표현하면 다음과 같았습니다.
- 사업소득 지급요청서 — 매달 정산 raw 파일을 열어 규칙(추가금액 0 제외, 순번 재정렬, 지급요청자·소속·사유 고정 문구, 대상자 그룹 음영 등)에 맞춰 재작성. 1회 약 10분. 실수 시 정정 부담까지.
- KMM 경시대회 집계 — 회차별 raw 응시 데이터에 3단계 필터를 적용하고 학년별 평균·성적분포·참여 학원 명단을 뽑아 구글시트로 옮기는 작업. 1회 약 30분.
합치면 매달 반복되는 정형 업무에 상당한 시간이 잠식되었고, 무엇보다 사업소득 지급요청서는 주민번호·계좌번호 같은 PII 데이터를 다루기 때문에 실수·유출 리스크까지 지속적으로 관리 대상이었습니다.
Hypothesis & Decision
가설: "바이브코딩할 만한 거리"라고 판단되는 순간, 몸으로 반복하지 말고 즉시 웹 도구로 만든다.
이 원칙은 단순히 도구를 만드는 습관이 아니라, PM의 문제 인식 자체를 바꾸는 판단 프레임입니다. 실제로 다음 세 가지 결정을 뒷받침했습니다.
- 개인 프로젝트가 아니라 사내 인프라로 배포 — 개인 GitHub·개인 Vercel 대신 회사 팀(freewheelin-vibe) 아래에 배포. 팀원이 URL 하나로 즉시 사용 가능하도록. 소유권도 회사에 남기는 방향으로.
- PII는 브라우저에서만 처리 — 주민번호·계좌번호가 담긴 정산 파일은 서버로 전송하지 않고 브라우저 내부에서만 열고 다시 암호화. 백엔드 자체를 두지 않는 방식으로 유출 경로를 원천 차단.
- 확장 가능한 셸 구조 — 좌측 도구 목록 + 우측 표시 영역의 단순한 구조로 시작해, 도구가 늘어나도 새 페이지를 개별 파일로만 추가하면 되도록 설계. 다음 도구 시 진입 비용 최소화.
What I Did
1. 도구 ① — 사업소득 지급요청서 생성기
- 암호가 걸린 정산 raw 엑셀을 브라우저에서 열고, 프리윌린 지급요청서 양식으로 재구성해 같은 암호로 다시 잠근 뒤 다운로드
- 규칙 자동 반영 — 추가금액 0 행 제외, 순번 재정렬, 지급요청자·소속·사유 고정, 대상자 그룹별 연노랑 음영
- 보안 판단 — 파일 비밀번호 기본값 제거, 매번 수동 입력만 허용해 공개 URL 노출 시에도 문서 자체는 안전
2. 도구 ② — KMM 경시대회 집계기
- 회차별 응시 raw 엑셀 업로드 → 3단계 필터(시험유형·출제취소·테스트 학원명) → 학년별 평균·성적분포·참여 학원 명단 산출
- 구글시트와 역할 분담 — 도구는 D-code 명단만 뽑아 붙여넣기, 시트가 자동으로 누적·신규·재응시율 계산. 각 시스템의 강점을 살린 배치
- 실전 회복력 — 처음 사용한 라이브러리가 사내 보안 스캔에서 오탐되자 즉시 다른 라이브러리(ExcelJS)로 교체하고 결과 동일성 재검증. 사내 인프라 제약을 학습하며 안착
Outcome
- 사업소득 지급요청서 — 10분 → 1분 이내. 약 90% 시간 절감. 실수·정정 부담도 함께 소멸.
- KMM 경시대회 집계 — 30분 → 5분 이내. 약 83% 시간 절감. 회차마다 반복되는 필터·집계 로직에서 사람이 하는 부분은 결과 검토와 붙여넣기만 남음.
- 조직 자산화 — 회사 인프라에 배포되어 다른 팀원도 URL 하나로 사용 가능. 개인 결과물이 아니라 조직 자산으로 전환.
- PII 리스크 감소 — 주민번호·계좌번호가 서버를 거치지 않는 구조로, 도구 사용 자체가 문서 취급 리스크를 낮추는 방향으로 정렬됨.
What I Learned
- 바이브코딩은 도구가 아니라 판단 프레임이다. "AI로 코드를 짜는 것"이 아니라 "몸으로 할 것 vs 코드로 만들 것"을 즉시 가르는 사고 방식. 이 경계를 스스로 정의해두면 반복 업무가 도구로 흡수되는 속도가 극적으로 빨라집니다.
- 개인 자산이 아니라 조직 자산으로 만들 것. 같은 도구라도 개인 계정에 배포하면 이직 후 소멸되지만, 회사 인프라에 배포하면 팀에 남습니다. 도구를 만들 때부터 소유·확산 경로를 설계하면 개인 시간 절감이 팀 생산성으로 확장됩니다.
- 보안·인프라 제약을 초기부터 판단에 넣는다. PII 처리 방식·사내 보안 스캔 대응·접근통제까지 도구 설계 초기부터 고려해야 실제 배포가 가능합니다. "동작하는 도구"와 "회사에 두고 쓰는 도구" 사이엔 이 판단들이 있다는 것을 확인했습니다.
- 다음 도구의 진입 비용을 낮추는 구조가 곧 확장성이다. 첫 도구를 잘 만드는 것보다, 두 번째 도구를 얼마나 빨리 붙일 수 있는 셸을 만드는가가 장기 임팩트를 결정한다는 것을 배웠습니다.
활용한 시스템·도구
vibe-template (Vite + React + Tailwind + shadcn) · ExcelJS · officecrypto-tool · 회사 Vercel 팀(freewheelin-vibe) · 사내 배포 포털 · Notion · Jira — 코드는 AI 어시스턴트의 도움을 받아 직접 설계·구현하고 사내 인프라로 배포.