[운영/배포] 베타 오픈 준비 체크리스트 - 인프라부터 UX까지

서비스 비즈니스 로직은 다 작성했고 베타 오픈 준비를 진행하면서, 이제 인프라 및 사용자들의 경험 부분에서 챙겨야 할 것들이 생각보다 많다는 걸 깨달았다. 이전 회사에서는 이미 돌아가는 서비스에 들어간 거라 배포 구조나 환경변수 분리 같은 건 그냥 있는 걸 사용했다. 근데 이번엔 처음부터 혼자 세팅해야 하니까 이전 회사 경험 떠올리면서 "오픈 전에 뭘 해야 하지?"라는 고민하게 됐다.

---

일단 이 정도는 필요하겠다 싶어서 정리해 봤다.

 

• 개발/운영 분리(dev/prod)
• GA4 트래킹
• 랜딩 페이지
• 에러 처리
• 법적 고지 페이지
• SEO/OG 태그
• 피드백 채널
• 에러 모니터링
• 부하 테스트
• 장애 대응 매뉴얼

여기서 우선순위를 나눠보면

 

필수 사항

없으면 오픈 자체가 불가능하거나, 오픈해도 금방 문제가 생기는 것들이다.

 

1. 개발/운영 서버 분리

개발할 때는 DB에 이상한 데이터 막 넣어보고, 코드 고치다가 서버 터뜨리기도 하고,, 근데 그 환경이 실제 유저가 쓰는 환경이랑 같다면 운영 관리가 안 된다. 이렇게 환경 분리가 안 된 채로 배포하면 내가 테스트하면서 쓰던 DB가 그대로 prod에 붙어있는 상황이 생길 수 있다. 막 넣어둔 테스트 데이터가 실제 유저한테 보인다거나, 실제 유저 데이터를 개발하면서 건드리게 된다거나 하는 일은 벌어지면 안된다!!

 

그래서 개발 서버와 운영서버를 분리하기 위해서 꼭 해야 할 작업은 아래와 같다.

• 환경변수 파일 분리
• DB 분리 (dev DB ↔ prod DB 절대 혼용 금지!!)
• API 키 분리 (특히 외부 서비스 연동)

추가적으로 챙기면 좋은 것들이다.

• 로그 레벨 분리 (dev는 상세하게, prod는 에러 위주로)
• 개발 환경에서만 쓰는 더미 데이터, 테스트 계정이 prod에 올라가지 않도록 주의
• PR을 활용해 배포 전 체크리스트 만들어두기

2. 커스텀 도메인 연결

배포 후 기본으로 제공되는 도메인이 있긴 하다. 근데 사용자한테 그 주소를 공유하면 신뢰도가 확 떨어진다. 가비아나 Cloudflare에서 연 1~2만 원대로 살 수 있고, DNS 설정만 해주면 연결은 어렵지 않다.

3. 랜딩 페이지

서비스가 뭔지 설명하는 페이지가 없으면 아무도 회원가입을 안 할 것이다.

• 이 서비스가 무엇인지 한 줄 요약
• 어떤 사람한테 필요한지
• 베타 버전 인지시키기

처음 방문한 사람이 5초 안에 "이게 나한테 필요한 서비스다"를 느끼게 만드는 게 목표이다.

4. 회원가입/로그인 플로우 확인

개발 환경에서 잘 됐다고 프로덕션에서도 잘 되는 건 아니다. 실제 배포 환경에서 처음부터 끝까지 직접 가입해봐야 한다. 당연한 말 같지만 이전 회사에서 QA 막판에 수정한 작업 하나 때문에 회원가입 로직이 꼬였던 경험이 있어서 꼭 넣었다.

5. 모바일 반응형

웹 서비스라 모바일 비율이 PC보다 낮겠지만, 그래도 링크 공유받고 모바일로 먼저 들어와 보는 사람들은 분명 있다. 첫인상에서 레이아웃이 완전히 깨져 보이면 그냥 이탈한다. 완벽한 대응은 나중에 해도 되는데, 기본적으로 깨지지 않는 정도는 베타 전에 잡아두는 게 좋다.

6. 에러 UI

서비스가 터졌을 때 흰 화면이나 에러 코드가 그대로 보이는 건 참사다. 사용자 입장에서는 "뭐지;;" 하고 바로 이탈한다. 크래시가 나더라도 "잠시 문제가 생겼어요, 다시 시도해 주세요" 같은 친화적인 메시지로 보여줘야 한다. React 기준으로는 Error Boundary를 루트에 하나 걸어두는 것만으로도 최소한의 방어가 된다.

7. 면책 고지

서비스 특성상 법적 고지가 필요하다. 베타는 넘어갈 수 있지만 정식 오픈 전엔 반드시 있어야 한다. 없으면 나중에 문제가 생겼을 때 아무런 방어막이 없다. 직접 쓰기 부담스러우면 AI로 초안 뽑고 다듬는 게 현실적이라고 생각한다.

 

권장 사항

없어도 서비스 오픈은 되는데, 있으면 확실히 좋다.

 

1. 배포 자동화 (CI/CD)

수동으로 배포하면 언젠가 실수가 생긴다. 테스트 안 된 코드가 올라가거나, 배포하다가 서비스가 잠깐 죽거나. GitHub Actions 기준으로 main 브랜치에 머지되면 자동으로 배포되게만 해둬도 훨씬 안정적이다. 혼자 운영할수록 이런 안전망이 더 필요하다.

2. GA4 트래킹

베타 때부터 데이터를 쌓아야 나중에 개선 근거가 생긴다. 어느 페이지에서 이탈하는지, 어떤 기능을 제일 많이 쓰는지.. 베타 유저 데이터가 가장 순수하다. 나중에 붙이면 그 이전 데이터는 영영 없는 거라 초기부터 달아두는 게 맞다고 생각한다.

3. 기본 SEO/OG 태그

카카오톡에서 링크 공유했을 때 기본 URL 링크가 보이는 게 아닌, 미리 보기가 뜨는 것만으로도 클릭률이 달라지는 경험을 해봤다. 서비스 홍보를 링크 공유로 시작한다면 이건 필수에 가깝다고 생각한다.

4. 피드백 채널

베타 유저는 피드백 줄 의향이 있는 사람들이라고 생각한다. 많은 불편함과 아이디어를 전달받을 기회로 그냥 두면 손해다. 카카오톡 오픈 채널 및 텔레그램 그룹 또는 구글 폼으로도 충분하다. 대부분의 유저는 불편하면 그냥 떠난다. 피드백을 직접 남겨주는 사람은 생각보다 훨씬 적다. 그러니 채널이라도 열어둬야 그 소수의 의견이라도 들을 수 있다. 유저 목소리를 직접 들을 수 있는 기회는 매우 감사하다!

 

그 외 약간 후순위

베타에서는 후순위지만 정식 오픈 전에 챙길 작업들이다.

 

• 부하 테스트: 유저가 몰렸을 때 서버가 버티는지 확인하는 작업이다. 베타 초기엔 트래픽이 많지 않아서 급하진 않지만 정식 오픈 전엔 한 번은 해봐야 할 것이다.
• 백업 정책: 서비스에서 가장 소중한 DB가 날아갔을 때 복구할 수 있는지의 문제다.
• 장애 대응 매뉴얼: 새벽에 서버가 터졌을 때 뭘 확인하고 어떻게 복구할지 정리해 두는 것으로 혼자라면 매우 매우 필수적이다.
• 에러 모니터링: 사용자는 에러가 나도 대부분 신고하지 않고 그냥 떠난다. Sentry로 에러 추적, Grafana로 서버 메트릭 시각화를 할 수 있다. 베타 초기엔 Sentry 무료 플랜으로 시작하고, 트래픽이 붙기 시작하면 Grafana까지 붙이면 좋을 것 같다.

 

마지막으로, 베타 오픈 준비하면서 직접 정리해봤는데, 본인만의 체크리스트가 있다면 댓글로 공유해주시면 감사합니다!! 😊