바이브코딩으로 MVP를 출시했다면, 첫날 점검할 운영 항목 6개
금요일 밤에 MVP를 공개했는데, 월요일 아침 고객이 “다른 사람 데이터가 보인다”고 연락한다면 무엇부터 해야 할까요? 기능을 빨리 만든 속도와 운영할 준비는 별개의 문제입니다. 첫날에는 기능 추가보다 접근 권한, 복구, 오류 감지, 비용 제한, 고객 연락 경로를 먼저 고정해야 합니다.
처음에는 세 묶음만 기억하면 됩니다
운영 항목을 길게 나열하면 실행하지 못합니다. 첫 주에는 지킬 것, 발견할 것, 설명할 것으로 나누면 빠르게 확인할 수 있습니다.
1. 지킬 것: 비밀키와 사용자 데이터
- 결제 비밀키와 서비스 역할 키가 브라우저 코드에 들어가 있지 않은지 확인합니다.
- 테스트 계정 두 개로 서로의 주문·문서·파일이 보이지 않는지 직접 시험합니다.
- 개발 환경과 운영 환경의 키와 데이터베이스를 분리합니다.
- 관리자 계정에는 다중 인증을 켭니다.
로그인은 출입문이고 권한은 방마다 달린 자물쇠입니다. 로그인한 사용자라도 자신의 데이터만 읽고 바꿀 수 있는지 확인해야 합니다.
2. 발견할 것: 오류와 비용 급증
고객이 알려주기 전에 가입, 로그인, 결제, 핵심 작업 실패를 알 수 있어야 합니다. 모든 경고를 즉시 받기보다 고객 행동이 멈추는 오류만 긴급 알림으로 올리세요.
- 치명적 오류는 즉시, 반복 경고는 하루 한 번 묶어서 확인
- 로그에는 개인정보와 비밀키를 남기지 않기
- AI API·메일 발송·파일 저장에 일일·월간 사용량 알림 설정
- 한 사용자나 IP의 짧은 시간 내 반복 호출 제한
3. 설명할 것: 복구와 고객 안내
백업이 있다는 표시보다 실제로 복원해 본 날짜가 중요합니다. 빈 테스트 환경에 데이터를 되돌려 로그인과 주요 조회가 되는지 확인하세요. 데이터베이스와 파일 저장소가 따로 백업되는지도 봐야 합니다.
장애가 나면 원인을 완벽히 설명할 때까지 기다리지 마세요. 영향 범위, 임시 대응, 다음 안내 시점을 먼저 알리고, 배포 날짜와 변경 내용을 짧게 남겨야 합니다.
공개 직후 20분 점검
- 5분: 새 계정으로 가입·로그인·핵심 작업을 끝까지 실행합니다.
- 5분: 두 계정 사이의 데이터가 섞이지 않는지 확인합니다.
- 5분: 방금 만든 오류가 알림과 로그에서 식별되는지 봅니다.
- 5분: 비용 알림과 고객 문의 주소가 실제 화면에서 보이는지 확인합니다.
운영 기준 하나가 기능 하나보다 먼저입니다
오늘 새 기능을 하나 더 만들기 전에 테스트 계정 두 개, 복원 시험 한 번, 비용 알림 한 개, 문의 주소 한 줄을 완성해 보세요. 네 가지가 갖춰지면 MVP는 공개된 데모에서 운영 가능한 서비스로 한 걸음 이동합니다.
권한 테스트, 백업·복원, 주간 운영 루프를 포함한 전체 체크리스트는 오피셜메일 원문에서 확인할 수 있습니다.
전체 운영 체크리스트 보기
댓글
댓글 쓰기