정적 사이트는 업로드되는 순간 바로 공개 웹에 내보내도 되는 상태가 아닐 때가 많습니다.
클라이언트 미리보기에는 아직 임시 문구가 남아 있을 수 있습니다. 포트폴리오 케이스 스터디는 특정 채용 담당자에게만 보여주고 싶을 수 있습니다. 내부 문서는 팀에는 필요하지만 검색 결과에 나오면 곤란할 수 있습니다. 출시 페이지는 최종 도메인을 공개하기 전에 이해관계자의 확인이 필요할 수 있습니다.
이럴 때 비밀번호 보호가 유용합니다. 이것은 완전한 ID 시스템이 아닙니다. 정적 콘텐츠를 보여주기 전에 공유 비밀번호로 한 번 막는 가벼운 게이트입니다.
비밀번호 보호가 잘 맞는 경우
정적 사이트는 공개 전 비공개 중간 단계를 거치는 경우가 많습니다. 사이트는 만들어졌고, 파일도 있고, 링크도 열립니다. 하지만 아직 보는 사람은 제한하고 싶습니다.
| 사용 사례 | 비밀번호 게이트가 도움이 되는 이유 |
|---|---|
| 클라이언트 리뷰 | 공개 출시 전에 이해관계자가 실제 URL을 확인할 수 있습니다. |
| 내부 문서 | 팀 전용 노트, 핸드북, 프로젝트 페이지를 전체 공개하지 않고 공유합니다. |
| 비공개 포트폴리오 | 선택한 케이스 스터디만 채용 담당자, 고객, 면접관에게 보낼 수 있습니다. |
| 학생 또는 팀 프로젝트 | 그룹이 공개 유지 범위를 정하기 전에 평가자가 프로젝트를 열 수 있습니다. |
| 캠페인 준비 | 문구, 추적 링크, 에셋, 모바일 레이아웃을 홍보 전에 점검합니다. |
| PDF 또는 자료 묶음 | 정적 페이지 하나로 문서, 파일, 참고 자료를 접근 단계 뒤에 둘 수 있습니다. |
목표는 작정하고 공격하는 사람을 막는 것이 아닙니다. 작업이 검토, 수정, 승인되는 동안 의도치 않게 공개로 퍼지는 것을 줄이는 것입니다.
비밀번호 게이트, noindex, 전체 인증의 차이
이들은 서로 다른 도구입니다. 같은 것으로 다루면 잘못된 기대가 생깁니다.
| 도구 | 하는 일 | 하지 않는 일 |
|---|---|---|
| 비밀번호 보호 | 사이트를 제공하기 전에 공유 비밀번호로 일반 접근을 막습니다. | 사용자 계정, 역할, 감사 로그, SSO를 만들지 않습니다. |
noindex | 검색엔진에 페이지를 검색 결과에 표시하지 말라고 요청합니다. | URL을 아는 사람이 페이지를 여는 것은 막지 않습니다. |
robots.txt | 크롤러에게 경로 관련 공개 지침을 제공합니다. | 공개 파일이므로 보호 수단으로 보면 안 됩니다. |
| 전체 앱 인증 | 사용자, 세션, 권한, ID 흐름을 관리합니다. | 정적 호스팅만으로는 부족하고 앱 로직이 필요합니다. |
| 네트워크 접근 제어 | ID 제공자, 기기, IP, 조직 정책으로 접근을 제한합니다. | 대부분의 클라이언트 미리보기에는 과합니다. |
Google은 noindex를 색인 제어로 설명합니다. 검색 결과에 나오지 않게 하는 데는 도움이 되지만 접근 보호는 아닙니다. Cloudflare Access와 Vercel Deployment Protection은 반대쪽 끝에 있는 더 강한 접근 제어입니다. 단순한 비밀번호 게이트는 그 중간에 있습니다.
홈페이지만이 아니라 정적 경험 전체를 보호하기
정적 사이트는 index.html 하나가 아닙니다.
홈페이지만 보호되고 이미지, 스크립트, PDF, deep link가 공개되어 있으면 미리보기는 여전히 노출될 수 있습니다. 유용한 보호는 게시된 경험 앞에 있어야 하며, 페이지를 의미 있게 만드는 파일까지 포함해야 합니다.
보호된 링크를 공유하기 전에 확인할 경로:
| 경로 유형 | 확인할 것 |
|---|---|
| 홈페이지 | 첫 방문에서 비밀번호 화면이 나오는지 확인합니다. |
| Deep links | 프로젝트 페이지, 문서, 캠페인 하위 경로도 접근을 요구하는지 봅니다. |
| 에셋 | 이미지, PDF, 스크립트, 다운로드가 obvious direct link로 열리지 않는지 확인합니다. |
| 폼 | 폼이 있다면 접근 후 정상 동작하는지 테스트합니다. |
| 오류 페이지 | 404나 fallback이 민감한 문구나 파일명을 드러내지 않아야 합니다. |
포트폴리오와 클라이언트 작업에서는 특히 중요합니다. 홈페이지를 가려도 공개 전 스크린샷이 /assets/client-redesign-final.png에서 열리면 의미가 약합니다.
적절한 비밀번호 운영 방식 정하기
공유 비밀번호는 운영이 간단합니다. 그래도 규칙이 필요합니다.
| 상황 | 실무 습관 |
|---|---|
| 짧은 리뷰 한 번 | 강한 공유 비밀번호를 쓰고 리뷰 후 변경합니다. |
| 여러 클라이언트 팀 | 대상이 섞이면 안 된다면 프로젝트나 리뷰 링크를 분리합니다. |
| 링크가 너무 넓게 전달됨 | 비밀번호를 바꾸고 새 비밀번호를 필요한 사람에게만 보냅니다. |
| 프로젝트가 공개됨 | 최종 승인과 도메인 공개 후 보호를 끕니다. |
| 작업이 계속 민감함 | 공개 페이지는 정보를 가리고, 상세 내용은 승인된 사람에게만 공유합니다. |
클라이언트 미리보기에 쉽게 맞힐 수 있는 농담 같은 비밀번호를 쓰지 마세요. 충분히 긴 값을 쓰고, 작업의 민감도에 맞는 채널로 공유해야 합니다.
비밀번호 보호만으로 부족한 경우
비밀번호 보호는 가벼워서 유용합니다. 그 가벼움이 한계이기도 합니다.
다음이 필요하다면 앱 인증 모델이 필요합니다.
- 개인별 계정 또는 초대.
- 사용자별 다른 권한.
- Google Workspace, Microsoft Entra, Okta 같은 ID 제공자를 통한 SSO.
- 누가 무엇을 봤는지 보여주는 감사 로그.
- 법적, 계약상, 컴플라이언스 접근 요구사항.
- 전체 비밀번호를 바꾸지 않고 한 사람만 접근 해제.
- 민감한 고객 데이터, 결제 데이터, 의료 데이터, 규제 대상 기록.
정적 미리보기에는 공유 비밀번호가 적절한 수준의 제어인 경우가 많습니다. 고객 포털, 내부 시스템, 규제 워크플로에는 충분하지 않습니다.
보호된 정적 미리보기에서 흔한 실수
대부분의 문제는 작은 운영 실수에서 나옵니다.
| 실수 | 더 나은 방식 |
|---|---|
| 보호를 켜기 전에 링크 전송 | 먼저 게이트를 켜고 private window에서 테스트합니다. |
| Deep link 누락 | 프로젝트 페이지, 문서, 에셋, PDF를 직접 열어 봅니다. |
| 같은 비밀번호를 계속 사용 | 리뷰, 출시, 실수로 전달된 뒤에는 변경합니다. |
noindex를 privacy로 취급 | noindex는 검색 제어이지 접근 제어가 아닙니다. |
| 기밀 세부사항 게시 | 이름, 지표, 스크린샷, 내부 경로를 업로드 전에 가립니다. |
| 출시 후 게이트를 그대로 둠 | 최종 사이트를 공개, 보호, 분리 중 무엇으로 둘지 결정합니다. |
보호된 미리보기라도 공개 사이트와 같은 콘텐츠 검토가 필요합니다. 비밀번호는 우발적 노출을 줄일 뿐, 부주의한 게시를 안전하게 만들지는 않습니다.
정적 배포 흐름에 넣기
비밀번호 보호는 배포 흐름의 일부일 때 가장 다루기 쉽습니다.
실무 흐름:
- 정적 사이트를 build하거나 export합니다.
- 폴더, ZIP, HTML 출력, framework build, 포트폴리오, PDF 포함 페이지를 업로드합니다.
- 미리보기를 공유하기 전에 비밀번호 보호를 켭니다.
- 리뷰어에게 링크와 비밀번호를 보냅니다.
- 문구, 파일, 모바일 레이아웃, 에셋을 수정합니다.
- 대상이 바뀌면 비밀번호를 변경합니다.
- 최종 공개 결정 시 보호를 끄거나 유지합니다.
이렇게 하면 리뷰가 실제 사이트에 가까운 상태에서 진행됩니다. 리뷰어는 나중에 공개 버전이 사용할 같은 route, asset, responsive behavior를 확인합니다.
DeployPages에서의 처리
DeployPages는 정적 게시를 중심으로 만들어졌기 때문에, 비밀번호 보호도 백엔드 인증이 아니라 정적 미리보기와 비공개 공유를 위한 기능입니다.
정적 폴더, ZIP, HTML 프로젝트, 포트폴리오, 문서 export, AI 생성 사이트, PDF 에셋을 포함한 페이지를 게시한 뒤, 현재 workspace plan에 포함되어 있다면 프로젝트 컨트롤에서 비밀번호 보호를 켤 수 있습니다. 방문자는 게시된 사이트를 보기 전에 프로젝트 비밀번호를 입력해야 합니다. 같은 프로젝트에서 분석, 커스텀 도메인, 즉시 롤백, CLI 배포도 사용할 수 있습니다.
흐름은 단순합니다. 사이트를 업로드하고, 리뷰 중에는 보호하고, 최종 버전을 계속 비공개로 둘지 공개 도메인으로 옮길지 결정하면 됩니다.
공유 전 체크리스트
비밀번호로 보호된 정적 사이트를 보내기 전에:
- private browser window에서 링크를 열고 비밀번호 화면이 나오는지 확인합니다.
- 홈페이지뿐 아니라 deep link를 테스트합니다.
- 중요한 PDF, 이미지, 스크립트, 다운로드 direct link를 시도합니다.
- 기밀 이름, 내부 지표, 내부 댓글, 임시 경로를 제거합니다.
- 강한 공유 비밀번호를 쓰고 팀이 바꿀 수 있는 곳에 관리합니다.
- 작업이 민감하다면 링크와 비밀번호를 분리해 공유합니다.
- 보호를 언제 제거, 변경, 유지할지 정합니다.
- 검토된 버전을 교체하기 전에 rollback 경로를 유지합니다.
비밀번호 보호는 정적 사이트를 복잡하게 만들기 위한 것이 아닙니다. 작업이 평가, 수정, 승인되는 비공개 단계를 덜 위험하게 만들기 위한 것입니다.