AI로 만든 서비스는 화면이 빠르게 완성되기 때문에 “이제 공개하면 되겠다”는 느낌도 빨리 옵니다. 하지만 실제 런칭에서 사고가 나는 부분은 화면보다 계정, 데이터, 결제, 복구, 운영입니다.
아래 20개 항목은 대기업 수준의 체크리스트가 아닙니다. 소규모 웹서비스가 최소한의 운영 책임을 갖기 위해 필요한 기준입니다.
A. 소유권과 기본 계정
1. 도메인이 회사 또는 대표 계정 소유인가
외주사나 개발자 개인 계정으로 도메인을 구매하지 않습니다. 자동 갱신, 결제수단, 복구 이메일도 회사가 관리해야 합니다.
2. Git 저장소가 회사 계정에 있는가
개발자 개인 저장소만 존재한다면 인수인계 위험이 큽니다. 회사 조직/계정에 저장소를 두고 최소 2명이 접근 가능하도록 합니다.
3. 클라우드·DB 계정도 회사 소유인가
서버를 누가 “만들었는지”보다 누가 “로그인해서 관리할 수 있는지”가 중요합니다.
B. 배포와 네트워크
4. 운영 URL이 고정되어 있는가
임시 preview URL이 아니라 실제 서비스 주소를 정합니다.
5. HTTPS가 정상인가
브라우저 자물쇠만 보지 말고 API, 이미지, 외부 리소스에 HTTP가 섞여 mixed content가 발생하지 않는지 확인합니다.
6. 재배포 방법이 문서화되어 있는가
새 코드가 어느 브랜치에서 어떤 과정을 거쳐 배포되는지 적어둡니다.
C. 데이터
7. 운영 DB와 개발 DB가 분리되어 있는가
개발 중 테스트 데이터 삭제가 운영 데이터에 영향을 주지 않아야 합니다.
8. 백업이 존재하는가
“자동 백업 옵션을 켰다”에서 끝내지 말고 최근 백업 시점과 보존 기간을 확인합니다.
9. 복구 방법을 한 번은 테스트했는가
백업은 복구할 수 있어야 의미가 있습니다. 적은 데이터라도 별도 환경에 복원해 봅니다.
10. 개인정보를 꼭 필요한 만큼만 저장하는가
가입 시 필요하지 않은 생년월일, 주소, 주민번호 등은 수집하지 않습니다. 수집 목적과 보관 기간도 검토합니다.
D. 인증과 권한
11. 관리자 URL만 숨겨 놓은 것이 아닌가
관리자 API는 서버에서 실제 권한을 확인해야 합니다.
12. 비밀번호 재설정과 계정 탈퇴가 동작하는가
가입만 만들고 계정 관리 흐름을 빼먹기 쉽습니다.
13. Secret Key가 노출되지 않았는가
브라우저 JavaScript, Git, 공개 로그에 결제·AI·DB Secret이 포함되지 않았는지 점검합니다.
E. 결제·주문
14. 성공뿐 아니라 실패 결제를 테스트했는가
카드 실패, 사용자가 중간에 닫은 경우, 승인 API 실패를 확인합니다.
15. 주문 상태가 서버에서 관리되는가
프론트 화면의 “결제 성공”만으로 서비스를 지급하지 않습니다.
16. 취소/환불 시 내부 데이터도 함께 갱신되는가
PG에서 취소하고 우리 DB는 결제완료로 남으면 운영 사고가 납니다.
F. 운영
17. 최소 관리자 화면이 있는가
사용자, 핵심 데이터, 주문/문의 등을 검색하고 상태를 수정할 수 있어야 합니다.
18. 오류 로그를 볼 수 있는가
고객이 “안 돼요”라고 했을 때 시간, 사용자, 요청, 오류를 추적할 수 있어야 합니다. 민감정보는 로그에 남기지 않습니다.
19. 문의 채널과 장애 대응 방법이 있는가
고객센터 번호까지는 아니어도 이메일·문의폼·채팅 중 하나는 있어야 합니다. 내부적으로 누가 답하는지도 정합니다.
20. 개인정보처리방침·이용약관 등 필요한 고지를 확인했는가
서비스가 어떤 데이터를 수집하고 제3자 서비스를 이용하는지에 따라 필요한 문서가 달라질 수 있습니다. 복붙한 약관을 그대로 쓰기보다 실제 서비스 흐름과 맞는지 검토해야 합니다.
런칭 전 1시간 Smoke Test
오픈 직전에는 개발자 화면이 아니라 새 고객처럼 테스트합니다.
- 시크릿 브라우저로 접속
- 신규 가입
- 이메일/소셜 인증
- 핵심 기능 사용
- 결제 또는 예약
- 관리자에서 결과 확인
- 고객 화면에서 결과 재확인
- 로그아웃/재로그인
- 모바일 접속
- 문의하기
이 10단계를 한 사람이 아니라 팀원 두 명 이상이 각각 해보는 것이 좋습니다.
런칭 당일 변경 금지 규칙
오픈 직전에 “이왕이면 이것도”를 넣는 순간 위험이 커집니다. 런칭 24시간 전부터는 치명적 버그가 아니면 새 기능을 넣지 않는 것이 좋습니다.
대신 해야 할 일:
- 데이터 백업 확인
- 배포 버전 태그/커밋 기록
- 장애 시 되돌릴 버전 확인
- 핵심 계정 로그인 확인
- 결제 테스트 1회
출시 후 첫 7일에 볼 것
런칭은 끝이 아니라 운영 데이터가 처음 생기는 시점입니다.
- 가입 실패율
- 핵심 기능 완료율
- 결제 실패
- 오류 로그 상위 항목
- 고객 문의 유형
- 모바일 이탈
- 관리자에서 수작업이 많이 생기는 지점
사용자 요청을 모두 기능으로 만들기보다 반복해서 나타나는 문제를 먼저 수정합니다.
정리
AI 서비스의 런칭 품질은 기능 개수보다 실패했을 때 복구 가능한가, 데이터를 잃지 않는가, 운영자가 상황을 볼 수 있는가로 판단하는 편이 현실적입니다.
완주 관점의 핵심: 20개를 완벽하게 만드는 것이 아니라, 위험도가 높은 항목이 비어 있지 않은지 확인하고 작은 서비스에 맞는 최소 운영 기준을 만드는 것입니다.
체크리스트를 실제 팀에서 쓰는 방법
20개 항목을 문서에 적어두는 것만으로는 부족합니다. 런칭 3~5일 전에 한 번, 런칭 전날 한 번, 런칭 직후 한 번 다시 확인하는 방식이 좋습니다. 각 항목에는 반드시 담당자 / 상태 / 확인일 / 증거 링크를 붙이세요.
예를 들어 “백업 확인”의 상태를 단순히 완료라고 쓰지 말고, 최근 자동 백업 2026-09-18 / 복구 테스트 DB 생성 완료 / 담당 Richard처럼 기록합니다. 그래야 “누군가 확인했을 것”이라는 상태를 피할 수 있습니다.
권장 상태 값
- 미확인
- 확인 중
- 완료
- 조건부 완료
- 런칭 후 처리
- 런칭 차단
특히 런칭 차단 항목은 명확해야 합니다. 결제 데이터가 잘못 저장되거나 관리자 권한이 뚫려 있는 문제는 UI 깨짐과 같은 우선순위로 다뤄서는 안 됩니다.
런칭을 막아야 하는 문제와 나중에 고쳐도 되는 문제
반드시 런칭 전에 막아야 하는 것
- 로그인 없이 다른 사용자 데이터 접근 가능
- 결제 금액과 주문 금액 불일치
- 운영 DB가 개발 DB와 혼용
- Secret Key 노출
- 고객 데이터 삭제 후 복구 수단 없음
- 관리자 권한 우회 가능
- 핵심 거래가 중간에 실패하고 상태가 불명확
런칭 후 개선해도 되는 것
- 일부 애니메이션 부자연스러움
- 관리자 차트 부족
- 마이너 브라우저에서 여백 문제
- 통계 다운로드 기능 없음
- 검색 필터 옵션이 적음
이 구분을 하지 않으면 팀은 중요한 위험보다 눈에 잘 보이는 UI 문제를 먼저 고치게 됩니다.
런칭 당일 운영 Room을 만들어라
작은 팀이라도 오픈 당일에는 Slack 채널 하나를 별도로 만드는 것이 좋습니다.
채널에 고정할 정보:
- 현재 운영 URL
- 배포된 Git commit
- 장애 시 롤백할 이전 commit
- 주요 관리자 URL
- 서버/DB 상태 페이지
- 고객 문의 채널
- 담당자 연락 순서
첫 24시간 동안은 모든 이슈를 이 채널에 모읍니다. 카카오톡, 개인 DM, 전화로 흩어지면 동일 문제가 여러 번 처리됩니다.
런칭 1주 후 반드시 하는 회고
첫 주가 끝나면 기능 요구보다 운영 데이터를 먼저 봅니다.
- 가장 많이 실패한 사용자 단계는 어디인가
- 운영자가 수동으로 처리한 업무는 무엇인가
- 고객이 가장 많이 질문한 것은 무엇인가
- 로그로 원인을 찾기 어려웠던 사고는 무엇인가
- 다음 배포 전에 자동화해야 할 운영 작업은 무엇인가
이 회고에서 나온 내용이 실제 v1.1의 우선순위가 되어야 합니다. 대표의 새 아이디어보다 실제 고객과 운영에서 반복된 문제가 먼저입니다.