프로젝트 정책을 한곳에 모으기로 했다

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

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

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

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 전파와 인증서 발급 시간이 필요한 작업이라서 확인하는 데 대기 시간이 필요했다.

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

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

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

• BabyPaunch 웹사이트
  • 개인정보처리방침
  • 접근성 안내
• Laftel Mania
  • 개인정보처리방침

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

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

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

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

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

앞으로 새 프로젝트를 만들 때마다 같은 자리에 필요한 정책을 추가할 예정이다.

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의 인증서 상태를 먼저 확인해야 한다는 것도 배웠다.

당신은 여러 웹서비스가 함께 사용하는 정책 허브와 사용자 지정 도메인을 점검하는 웹 운영자입니다.

내가 제공한 사이트 정보와 공개 페이지를 확인하고 다음 항목을 점검해 주세요.

- 대표 도메인과 함께 사용할 보조 호스트의 DNS 연결
- HTTP에서 HTTPS로의 영구 리디렉션
- 공개할 모든 호스트 이름을 포함하는 유효한 HTTPS 인증서
- 호스팅 서비스의 사용자 지정 도메인과 HTTPS 강제 사용 상태
- 서비스와 문서 종류를 구분할 수 있는 일관된 정책 주소 구조
- 지원하는 각 언어의 정책 목록과 실제 문서 링크의 일치
- 서비스 유형과 대상 지역에 필요한 개인정보처리방침 및 정책 문서의 누락
- 각 정책의 최초 시행일, 변경일과 변경 이력 표시
- 모바일에서 긴 제목, 주소와 링크가 화면을 넘지 않는지

각 항목을 `정상`, `개선 필요`, `확인 불가`로 판정해 주세요.

문제가 있다면 원인, 수정할 DNS·호스팅·사이트 설정 또는 파일, 최소 수정안과 공개 사이트 검증 방법을 제시해 주세요.

정책 내용의 법적 적합성을 단정하지 말고 관할 지역과 서비스 특성에 따라 전문가 확인이 필요한 항목을 구분해 주세요.

아래 항목 중 본인 환경에 필요한 정보만 작성하고, 알 수 없는 항목은 비워 두세요.

사이트 주소: [정책 허브 주소]
사이트 관리 방식: [예: CMS, 프레임워크, 직접 작성한 HTML]
확인 가능한 자료: [예: 저장소 주소, 관리자 화면, 호스팅 설정]
DNS 제공자: [DNS 서비스]
등록할 서비스: [서비스 이름과 필요한 정책]
지원 언어: [지원할 언어]
서비스 대상 지역: [정책이 적용될 국가 또는 지역]

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