Skip to content
SaaS ERP SaaS ERP Docs

구현 업데이트: 게이트는 NEXT_PUBLIC_ZUPLO_API_URL (또는 NEXT_PUBLIC_TRIAL_GATEWAY_CONFIGURED=1) 에 의존합니다. 동일 출처 /api/trial/* Pages 프록시·NEXT_PUBLIC_TRIAL_USE_SAME_ORIGIN 는 제거되었습니다. 아래 §1.2 표는 과거 로직 참고용 — 현재는 trial-page-free-email-zuplo-layout-plan §2 와 trial-gateway.ts 를 기준으로 하세요.

0. 범위

1. 증상 ① — 노란 배너: “Email verification isn’t available on this site yet…“

1.1 UI·코드 매핑 (현행)

  • 문구는 TRIAL_EMAIL_GATEWAY_NOT_CONFIGURED_COPY (apps/www/lib/trial-gateway.ts).
  • TrialEmailGate는 isTrialEmailGatewayConfigured() === false 일 때만 해당 알림을 띄운다 (apps/www/components/trial/TrialEmailGate.tsx).

1.2 isTrialEmailGatewayConfigured() 가 false가 되는 조건 (현행)

조건결과
NEXT_PUBLIC_TRIAL_GATEWAY_CONFIGURED=1항상 true
NEXT_PUBLIC_ZUPLO_API_URL 비어 있음 (빌드)false (모든 호스트·SSR 동일)
Zuplo URL이 빌드에 있음true

1.3 프로덕션에서도 배너가 남는 경우 — 점검 가설

  1. 배포된 www 번들이 구버전

    • 게이트 “동일 출처만으로 구성됨” 판단이 들어가기 이전 빌드가 pregoi.com에 올라가 있을 수 있다.
    • 조치: 최신 main 기준으로 pages:build:www 산출물이 프로덕션 브랜치/프로덕션 배포에 반영됐는지 확인, CDN 캐시 무효화·배포 이력 대조.

  2. 빌드 시 NODE_ENV가 production이 아닌 산출물

    • 비정상적인 파이프라인으로 정적 HTML이 “개발 모드” 값을 포함하면 SSR 구간에서 gatewayReady가 false일 수 있다.
    • 조치: CI 로그·next build 출력·번들 내 process.env.NODE_ENV 치환 여부 확인.

  3. 호스트 판별 예외 (드묾)

    • 사용자 환경이 일반 브라우저 주소창이 아닌 경우(iframe, 인앱 브라우저, 프록시 도메인) hostname이 예상과 다를 수 있다.
    • 조치: 재현 시 window.location.hostname 로그(내부 디버그 빌드) 또는 지원 티켓으로 수집.

  4. API 실패와 혼동

    • 같은 문구는 mapTrialGatewayClientError에서 NEXT_PUBLIC_ZUPLO_API_URL 문자열이 포함된 에러에도 매핑된다.
    • 이 경우 배너가 아니라 요청 실패 후 빨간 에러 텍스트일 수 있으나, 카피가 동일해 증상 ①과 혼동 가능.
    • 조치: 네트워크 탭에서 Zuplo로 가는 POST .../api/trial/email/check 성공/실패, 응답 본문 구분.

1.4 운영에서 확인

  • Build 변수: NEXT_PUBLIC_ZUPLO_API_URL 필수 (/trial Zuplo 직접 호출).
  • Network: 요청이 Zuplo 베이스로 나가는지, CORS·200 응답인지 확인.

2. 증상 ③ — Work email 입력 불가

2.1 UI·코드 매핑 (현행)

  • 입력 필드에 disabled={!gatewayReady} 가 걸려 있다 (TrialEmailGate).
  • 따라서 증상 ①과 동일한 원인이면 gatewayReady === false → 입력·Continue 모두 비활성이 된다.

2.2 기획 원칙

  • 게이트가 “미구성”일 때 필드를 막는 것은 의도된 안전 장치이나, 프로덕션 pregoi.com에서는 구성이 되어 있다고 판단되어야 하므로, 증상 ① 해결과 동일 스프린트에서 검증한다.
  • (선택) 제품 정책: “미구성”일 때도 입력은 허용하고 전송 시에만 안내하는 방식은 UX 개선 후보이나, 스팸·혼란과 트레이드오프이므로 별도 결정이 필요하다.

3. 증상 ② — 첫 뷰포트에서 하단 푸터(footer)가 보임

3.1 요구(재확인)

  • PC·모바일 모두 스크롤 없이 첫 화면에 푸터가 보이지 않게 — 푸터는 스크롤 후 노출.

3.2 현행 레이아웃 (TrialPageClient)

  • 루트: min-h-[100dvh] flex column.
  • main: min-h-[calc(100dvh-4.5rem)] + flex-1 + 세로 중앙 정렬.
  • 4.5rem은 헤더 높이 추정치이며, 실제 헤더 + 쿠키 배너 + 모바일 safe-area 합보다 작으면, main이 뷰포트를 덜 채워 푸터가 한 화면 안에 들어오는 현상이 남을 수 있다.

3.3 설계 방향 (구현 시)

항목제안
헤더 높이고정 rem 대신 CSS 변수·scroll-margin·실측 후 min-h-[calc(100dvh-var(--trial-header-offset))] 등으로 조정
쿠키 배너배너가 있을 때만 추가 오프셋(레이아웃 시프트 최소화)
높이 단위100dvh / 100svh / min-h-screen 조합을 모바일 주소창 시나리오별로 재검토
main 내부justify-center로 카드가 세로 중앙에 있으면 시각적으로 “아래가 비어” 푸터가 더 잘 보일 수 있음 → 상단 정렬 + 적당한 pt 또는 최소 높이만 보장 등 브랜드에 맞는 조정
검증뷰포트 375×812, 390×844, 1280×720, 1920×1080 + 쿠키 배너 on/off 스크린샷 회귀

3.4 관련 문서

4. 통합 검증 체크리스트 (구현·배포 후)

  • 프로덕션 www 번들이 최신인지(배포 ID·커밋 SHA).
  • GET /trial 로드 직후 노란 배너 미표시, Work email 포커스·입력 가능.
  • POST /api/trial/email/check 200 (Functions ZUPLO_API_URL 설정됨).
  • 대표 뷰포트에서 푸터가 첫 화면에 보이지 않음(또는 합의된 디자인 기준 충족).

5. 관련 문서

Help