JAEKYUN KIM← BACK
Automation · B2B SaaS · EdTech

사내 운영 자동화 도구 허브 — PM이 직접 만든 딸깍 툴

매달 반복되는 정산·경시대회 집계 업무를 웹앱으로 딸깍 처리. PM이 직접 설계·개발해 사내 배포했고, 바이브코딩을 판단→실행 사이클로 내재화한 사례.

Role
Product Manager · 도구 설계·개발·사내 배포
Focus
Automation · B2B SaaS
Status
Draft
Problem

바이브코딩을 도구가 아닌 판단 프레임으로 내재화한 프로젝트. "몸으로 반복할 것"과 "코드로 딸깍 만들 것"의 경계를 스스로 판단하고 즉시 실행하는 사이클을 조직에 안착시켰습니다.

Approach
  1. 01개인 프로젝트가 아니라 사내 인프라로 배포 — 개인 GitHub·개인 Vercel 대신 회사 팀(freewheelin-vibe) 아래에 배포. 팀원이 URL 하나로 즉시 사용 가능하도록. 소유권도 회사에 남기는 방향으로.
  2. 02PII는 브라우저에서만 처리 — 주민번호·계좌번호가 담긴 정산 파일은 서버로 전송하지 않고 브라우저 내부에서만 열고 다시 암호화. 백엔드 자체를 두지 않는 방식으로 유출 경로를 원천 차단.
  3. 03확장 가능한 셸 구조 — 좌측 도구 목록 + 우측 표시 영역의 단순한 구조로 시작해, 도구가 늘어나도 새 페이지를 개별 파일로만 추가하면 되도록 설계. 다음 도구 시 진입 비용 최소화.
Results
Reflection

바이브코딩은 도구가 아니라 판단 프레임이다. "AI로 코드를 짜는 것"이 아니라 "몸으로 할 것 vs 코드로 만들 것"을 즉시 가르는 사고 방식. 이 경계를 스스로 정의해두면 반복 업무가 도구로 흡수되는 속도가 극적으로 빨라집니다.

개인 자산이 아니라 조직 자산으로 만들 것. 같은 도구라도 개인 계정에 배포하면 이직 후 소멸되지만, 회사 인프라에 배포하면 팀에 남습니다. 도구를 만들 때부터 소유·확산 경로를 설계하면 개인 시간 절감이 팀 생산성으로 확장됩니다.

보안·인프라 제약을 초기부터 판단에 넣는다. PII 처리 방식·사내 보안 스캔 대응·접근통제까지 도구 설계 초기부터 고려해야 실제 배포가 가능합니다. "동작하는 도구"와 "회사에 두고 쓰는 도구" 사이엔 이 판단들이 있다는 것을 확인했습니다.

← BACK TO WORK