앞으로도 계속 새로운 프로젝트를 만들 생각이다.

프로젝트가 하나씩 늘어나면 외부에 공개해야 하는 문서도 함께 늘어난다.

개인정보처리방침, 이용약관, 계정 삭제 안내, 데이터 삭제 안내, 접근성 안내

Chrome 확장 프로그램과 웹 서비스가 요구하는 내용도 서로 다를 수 있다.

프로젝트마다 별도의 정책 사이트를 만드는 방법도 있지만, 같은 연락처와 운영 주체를 여러 곳에서 반복해서 관리하고 싶지는 않았다.

그러다 이런 생각이 들었다.

모든 프로젝트 정책을 한곳에서 관리하는 건 어떨까?

내 홈페이지를 정책 허브로 사용하기

마침 babypaunch.github.io를 블로그와 프로젝트 홈페이지로 관리하기 시작했다. 이곳에 정책 페이지를 함께 두면 새로운 사이트를 계속 만들지 않아도 된다.(무엇보다 무료니까, 얼마나 좋은가?!)

중요한 것은 모든 프로젝트에 같은 정책을 적용하는 것이 아니다. 홈페이지는 공통 입구로 사용하되, 정책 내용은 프로젝트별로 분리하기로 했다.

회원가입이나 결제가 없는 작은 프로젝트는 개인정보처리방침 하나면 충분할 수 있다. 반대로 로그인, 서버 저장 또는 구독이 있는 프로젝트라면 이용약관과 데이터 삭제 안내가 더 필요할 수 있다. 각 프로젝트의 실제 기능에 맞는 문서만 두는 방식이다.

한곳에서 관리하면 정책의 위치와 변경 이력을 찾기 쉽다는 장점이 있다. 반면 기능이 바뀔 때 정책도 함께 고쳐야 한다는 책임은 사라지지 않는다. 여러 프로젝트가 같은 홈페이지를 사용하는 만큼 도메인과 배포 상태를 꾸준히 관리해야 한다.

GitHub 주소 대신 내 도메인 연결하기

GitHub Pages 기본 주소만으로도 정책을 공개할 수 있다. 하지만 앞으로 Chrome Web Store나 Google OAuth 같은 외부 시스템에 반복해서 제출할 주소라면 내가 소유한 도메인이 더 적합하다고 생각했다.

그래서 babypaunch.com을 구매해 GitHub Pages에 연결했다. 도메인 구매는 Cloudflare가 싸게 느껴졌다. 나중에 호스팅 방식을 바꾸더라도 도메인은 그대로 유지할 수 있고, 모든 프로젝트에서 같은 공식 주소를 사용할 수 있다.

GitHub Pages에서 루트 도메인과 www 주소를 정상적으로 사용하려면 Cloudflare DNS에 A 레코드 네 개와 CNAME 하나를 등록해야 했다.

네 개의 A 레코드는 babypaunch.com을 GitHub Pages 서버에 연결하고, CNAME은 www.babypaunch.com을 기본 GitHub Pages 주소에 연결한다. Cloudflare 프록시는 사용하지 않고 모두 DNS 전용으로 설정했다.

HTTP 연결은 먼저 완료됐고 HTTPS는 DNS 전파와 인증서 발급 시간이 필요한 작업이라서 확인하는 데 대기 시간이 필요했다.

문서 종류보다 프로젝트를 먼저 보여주기

처음 정책 페이지에는 접근성 안내와 개인정보처리방침이 한 목록에 섞여 있었다. 문서가 몇 개 없을 때는 괜찮았지만, 프로젝트가 늘어나면 어느 정책이 어디에 적용되는지 알기 어려워질 것 같았다.

그래서 정책 페이지를 프로젝트별 카드로 나눴다.

주소도 같은 규칙으로 정리했다.

/policies/프로젝트/문서/
/en/policies/프로젝트/문서/

새 프로젝트가 생기면 프로젝트 정보와 필요한 정책 문서를 추가하면 된다. 한국어와 영어 페이지도 같은 구조를 사용한다.

이 방식의 가장 큰 장점은 확장하기 쉽다는 점이다. 어떤 프로젝트에 정책이 더 필요해져도 그 프로젝트 아래에 문서를 추가하면 된다. 정책을 찾는 사람도 먼저 프로젝트를 고른 뒤 관련 문서만 볼 수 있다.

단점도 있다. 모든 정책이 한 도메인에 모여 있기 때문에 도메인 갱신이나 사이트 배포에 문제가 생기면 여러 프로젝트가 함께 영향을 받는다. 그래서 통합 관리가 편한 만큼 이 홈페이지를 오래 유지할 책임도 커졌다.(공짜니까 죽기 전까지 사용해 줄 테다.)

지금은 BabyPaunch 웹사이트와 Laftel Mania만 등록되어 있다. 앞으로 새 프로젝트를 만들 때마다 같은 자리에 필요한 정책을 추가할 예정이다.

2026년 8월 28일 추가 업데이트: HTTPS 연결 완료

24시간 이상 기다렸지만 HTTPS 인증서는 자동으로 만들어지지 않았다. DNS 레코드는 GitHub Pages 권장값으로 정상 연결되어 있었고, 문제는 GitHub Pages의 인증서 발급 작업이 실패한 상태로 남아 있던 것이었다.

GitHub Pages 설정에서 사용자 지정 도메인을 제거한 뒤 잠시 기다렸다가 babypaunch.com을 다시 등록해 인증서 발급을 처음부터 시작했다. 새 인증서에 babypaunch.com과 www.babypaunch.com이 모두 포함된 것을 확인한 다음 HTTPS 강제 사용을 켰다.

이제 HTTP 주소는 HTTPS로 자동 이동하고, 루트 도메인과 www 주소 모두 암호화된 연결로 접속된다. 기다리는 것만으로 해결되지 않을 때는 DNS를 계속 바꾸기보다 GitHub Pages의 인증서 상태를 먼저 확인해야 한다는 것도 배웠다.

한 줄 요약: 프로젝트가 늘어난 뒤 정리하는 대신, 내 GitHub Pages를 모든 프로젝트가 함께 사용할 정책 허브로 만들었다.