베타 런치를 위한 Sentry·Waitlist·문서 준비 완료

6주차 끝, 베타 런치 준비를 선언하는 커밋을 머지했다.

한 커밋에 Sentry 설정, Waitlist 연동, README 문서화가 한꺼번에 들어온 걸 보면 "이제 외부에 열겠다"는 선언에 가까운 작업이었다. 기능 개발이 아니라 운영 가능한 상태로 올리는 작업 — 이런 커밋이 팀 입장에서 오히려 더 중요할 때가 많다.

왜 이 세 가지를 한 번에 묶었나

기능은 이미 있었다. 문제는 "배포했을 때 무슨 일이 일어나는지 볼 수 있느냐"였다.

베타 런치 준비를 점검할 때 내가 항상 보는 체크리스트가 있다.

• 에러가 터졌을 때 우리가 먼저 알 수 있는가?
• 유저가 접근할 수 있는 진입점(Waitlist)이 있는가?
• 신규 팀원이나 외부 기여자가 프로젝트를 이해할 수 있는가?

Sentry, Waitlist, README — 각각이 딱 이 세 질문의 답이었다. 개별 PR로 쪼갤 수도 있었지만, 이 셋이 묶여야 "런치 레디"라는 상태가 완성된다고 봤기 때문에 하나의 맥락으로 묶었다. 코드리뷰 때도 "이게 왜 한 커밋이야"라는 코멘트가 나올 수 있는데, 이런 경우엔 상태 전환을 단위로 커밋을 묶는 게 맞다고 생각한다.

Sentry 설정 — client / server / edge 세 파일의 의미

변경 파일을 보면 sentry.client.config.ts, sentry.server.config.ts, sentry.edge.config.ts 세 파일이 모두 들어가 있다.

apps/web/
├── sentry.client.config.ts   # 브라우저에서 실행되는 에러 캡처
├── sentry.server.config.ts   # Node.js 런타임 (SSR, API Route)
├── sentry.edge.config.ts     # Edge Runtime (Middleware, Edge API)
└── next.config.js            # Sentry 플러그인 바인딩

Next.js 앱에서 Sentry를 붙일 때 이 세 진입점을 놓치는 경우가 생각보다 많다. 특히 Edge Runtime을 빼먹으면, Middleware 쪽에서 터지는 에러는 아예 잡히지 않는다. next.config.js에는 @sentry/nextjs의 withSentryConfig 래퍼가 들어가서 빌드 타임에 소스맵 업로드와 번들 설정을 처리한다.

세 파일을 따로 두는 이유는 런타임마다 사용할 수 있는 API가 다르고, 샘플링 비율이나 integrations 설정도 환경별로 달리 가져가야 하기 때문이다. 예를 들어 Edge에선 Node.js 전용 integration을 쓸 수 없다.

// sentry.edge.config.ts 패턴 예시
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1, // Edge는 호출량이 많으므로 낮게
});

팀에서 Sentry를 처음 붙이는 경우라면, DSN을 환경변수로만 관리하고 .env.local에 절대 커밋하지 않는 것, 그리고 SENTRY_AUTH_TOKEN은 CI/CD 시크릿으로만 다루는 것 — 이 두 가지를 코드리뷰 체크리스트에 넣어두면 좋다.

README와 Waitlist — 개발 외적 런치 준비

README.md 업데이트는 커밋 메시지에서 "docs"로 표현됐는데, 베타 런치 시점의 README는 단순 문서가 아니다. 새 팀원이 온보딩하는 입구이기도 하고, 외부에서 프로젝트를 처음 보는 사람의 첫인상이기도 하다. 이 시점에 README를 정리하지 않으면 런치 이후에 "이거 어떻게 실행해요?"라는 질문이 계속 들어온다 — 경험담이다.

Waitlist는 아직 전체 공개 전에 관심 있는 사용자를 모아두는 장치다. 베타 단계에서 Waitlist 없이 바로 열면 감당하기 어려운 트래픽이 오거나, 반대로 피드백을 줄 수 있는 초기 유저 풀이 확보되지 않는다. 어느 쪽이든 리스크가 있다. Waitlist를 먼저 여는 건 "우리가 준비되는 속도에 맞춰 유저를 들여보내겠다"는 컨트롤이다.

6주 스프린트의 끝, 런치 레디란 무엇인가

Week 6라는 태깅이 눈에 띈다. 6주 동안 쌓아온 결과물이 이 커밋 하나로 "외부에 보여줄 수 있는 상태"가 됐다는 선언이다.

팀 리딩 입장에서 "런치 레디"를 판단할 때 내가 보는 기준은 이렇다.

• 관측 가능성: 에러와 이상 징후를 실시간으로 볼 수 있는가 (→ Sentry)
• 진입 제어: 유저 유입을 제어할 수 있는가 (→ Waitlist)
• 지식 외재화: 팀 외부도 이 프로젝트를 이해할 수 있는가 (→ README)
• 롤백 가능성: 문제가 생겼을 때 빠르게 되돌릴 수 있는가

마지막 항목이 이번 커밋엔 명시적으로 안 보이지만, 앞의 세 가지가 갖춰졌다는 건 그 자체로 팀의 대응 속도를 높여준다. Sentry 알림이 오는 시점부터 우리는 유저보다 먼저 문제를 알 수 있다.

6주의 결과물을 이 세 줄짜리 커밋 메시지가 담고 있다. 그게 좋은 커밋이라고 생각한다.

끝.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.