GitHub Pages 개인정보처리방침은 앱을 출시하려는 1인 개발자가 별도 서버 없이 정책 문서를 공개할 때 쉽게 선택할 수 있는 방법입니다. 이 글에서는 GitHub Pages로 개인정보처리방침과 이용약관을 정적 페이지로 배포하는 흐름을 초보자 눈높이에서 정리합니다.
GitHub를 처음 접하면 보통 원격 저장소, 커밋, 푸시, 브랜치 정도만으로도 충분하다고 느낍니다. 실제로 내 프로젝트를 안전하게 백업하고, 다른 개발자의 작업물을 살펴보고, 필요한 코드를 참고하는 것만으로도 GitHub의 가치는 충분합니다. 그런데 GitHub는 저장소를 관리하는 서비스에 그치지 않습니다. 이슈와 프로젝트 보드, 코드 리뷰, 릴리스, 자동화, 패키지, 보안 점검, GitHub Actions, GitHub Pages처럼 개발 흐름 전체를 돕는 기능을 함께 제공합니다.
이번 글에서는 그 많은 기능을 한꺼번에 익히지 않습니다. 개인 서버를 직접 운영하지 않는 1인 개발자가 앱 출시 과정에서 자주 필요로 하는 두 문서, 개인정보처리방침과 이용약관을 GitHub Pages에 정적 페이지로 올리는 흐름만 살펴보겠습니다. 문서의 내용은 AI 코딩 도구의 도움을 받을 수 있지만, 법률 문서의 최종 검토와 책임까지 AI가 대신해 주는 것은 아닙니다.
GitHub의 기능은 저장소보다 많다
GitHub의 기본 단위는 저장소(repository)입니다. 저장소에는 소스 코드뿐 아니라 문서, 이미지, 설정 파일, 배포용 정적 파일도 들어갈 수 있습니다. 여기에 다음 기능이 연결됩니다.
- Issues: 버그, 개선점, 할 일을 기록하고 대화하는 공간
- Projects: 칸반 보드처럼 작업을 계획하고 진행 상태를 관리하는 공간
- Pull requests: 코드 변경을 검토하고 병합하는 협업 흐름
- Releases: 특정 버전의 앱과 변경 내역을 배포하는 기능
- Actions: 테스트, 빌드, 배포를 자동으로 실행하는 기능
- Pages: HTML, CSS, JavaScript 같은 정적 파일을 웹페이지로 공개하는 기능
이 중 GitHub Pages는 데이터베이스나 서버 프로그램이 필요한 서비스가 아닙니다. 저장소에 있는 파일을 웹서버처럼 제공하는 기능입니다. 그래서 문의 게시판이나 로그인 서버를 만들 수는 없지만, 내용이 자주 바뀌지 않는 개인정보처리방침, 이용약관, 앱 소개, 사용 설명서에는 잘 맞습니다.
GitHub Pages 개인정보처리방침을 두는 이유
앱 마켓이나 광고·분석 서비스에 앱을 등록할 때 정책 페이지 주소를 요구받는 경우가 있습니다. 이때 개인 서버를 빌리고 도메인과 SSL을 설정하는 방법도 있지만, 단순한 문서 두 장을 공개하기 위해 서버 전체를 운영하는 것은 1인 개발자에게 부담일 수 있습니다.
GitHub Pages를 사용하면 저장소에 privacy-policy.html과 terms-of-service.html을 올리고 배포 설정을 하는 것으로 시작할 수 있습니다. 주소는 보통 https://사용자이름.github.io/저장소이름/ 형태가 됩니다. 저장소 이름을 사용자이름.github.io로 만들면 사용자 사이트 형태의 주소도 사용할 수 있습니다. 나중에 원하는 도메인을 연결하는 것도 가능합니다.
다만 GitHub Pages는 정적 호스팅입니다. 사용자의 개인정보를 입력받아 저장하는 기능, 회원 가입, 문서 자동 생성, 관리자 화면을 GitHub Pages 안에서 처리하는 용도로 생각하면 안 됩니다. 정책 문서를 읽게 하는 공개 페이지로 범위를 한정하는 것이 좋습니다.
먼저 정책 문서를 준비한다
우리는 정책 문서를 처음부터 직접 작성하지 않습니다. 앱의 이름, 운영자 정보, 수집하는 개인정보, 수집 목적, 보관 기간, 제3자 제공 여부, 외부 서비스, 문의 방법을 정리해 AI 코딩 도구에게 초안을 요청할 수 있습니다. 중요한 것은 “앱에 실제로 있는 기능”을 빠짐없이 전달하는 일입니다.
예를 들어 로그인 기능이 없는데 회원 정보를 수집한다고 적거나, 실제로 사용하는 광고 SDK와 분석 SDK를 빼먹으면 문서와 앱의 동작이 어긋납니다. 앱 아이디어를 MVP로 줄이는 과정에서 기능 목록을 정리했다면 그 목록을 정책 문서 작성의 입력으로 활용할 수 있습니다. 외부 API와 백엔드를 사용하는 앱이라면 Supabase 앱 백엔드 글에서 다룬 데이터 흐름도 함께 확인하면 좋습니다.
AI가 만든 문서를 그대로 법률 자문으로 받아들이면 안 됩니다. 개인정보 보호 관련 법령과 앱 마켓 정책은 서비스 지역, 이용자, 수집 항목, 사업 형태에 따라 달라질 수 있습니다. AI는 초안 작성과 누락 확인에 유용하지만, 실제 배포 전에는 관련 전문가나 변호사에게 검토받는 것이 가장 안전합니다. 영세한 1인 개발자에게 AI가 큰 도움이 되는 것은 맞지만, “AI가 책임져 준다”는 뜻은 아닙니다.
GitHub Pages를 켜는 순서
문서 파일이 준비되었다면 GitHub 저장소에 올립니다. 가장 단순한 구조는 아래와 같습니다.
privacy-policy.html
terms-of-service.html
index.htmlCode language: CSS (css)저장소의 Settings → Pages로 이동한 뒤 Build and deployment에서 소스를 Deploy from a branch로 선택합니다. 문서가 올라간 브랜치와 폴더를 선택하고 저장하면 GitHub가 배포를 시작합니다. 잠시 후 Pages 화면에 공개 주소가 표시됩니다. 공식 안내는 GitHub Pages 빠른 시작 문서에서 확인할 수 있습니다.
이 과정을 직접 웹 화면에서 수행한다면 GitHub MCP나 별도의 키가 없어도 됩니다. 브라우저에서 파일을 만들고 커밋한 뒤 Pages를 켜면 됩니다. MCP는 이 작업을 AI 코딩 도구가 대신 수행하도록 연결할 때 필요합니다. 이 차이를 먼저 구분해야 불필요하게 토큰을 발급하지 않게 됩니다.
GitHub 키는 어디서 발급할까
AI 도구나 로컬의 GitHub MCP 서버를 PAT 방식으로 연결해야 한다면 GitHub의 Fine-grained personal access token 발급 페이지에서 키를 만들 수 있습니다. 예전의 classic token보다 fine-grained token을 우선 고려하는 편이 좋습니다. 특정 저장소만 선택하고, 필요한 권한만 부여할 수 있기 때문입니다.
정책 페이지만 올리는 작업이라면 다음 원칙을 지킵니다.
- Repository access에서 작업할 저장소만 선택합니다.
- 만료 기간은 필요한 만큼만 짧게 설정합니다.
- 파일을 읽고 쓰는 작업에는 보통 Repository permissions의 Contents 권한이 필요합니다.
- Pages 설정이나 배포를 API로 직접 제어할 때는 Pages 관련 권한이 추가로 필요할 수 있습니다.
- 사용하지 않는 Actions, Issues, Administration 권한까지 습관적으로 열지 않습니다.
발급된 토큰은 생성 직후 한 번만 확인할 수 있는 경우가 많습니다. 채팅창, 저장소 파일, 스크린샷, 블로그 본문에 붙여 넣지 말고 비밀번호 관리자 같은 안전한 곳에 바로 메모합니다. 이미 노출했다면 지우는 것만으로 충분하지 않습니다. GitHub 설정에서 해당 토큰을 즉시 폐기하고 새 토큰을 발급해야 합니다.
GitHub MCP와 /mcp는 어떻게 쓰나
MCP는 AI가 외부 서비스의 정보와 기능을 사용할 수 있도록 연결하는 표준입니다. GitHub MCP를 연결하면 AI가 저장소 파일을 읽고, 필요한 파일을 만들고, 커밋을 만들거나 변경 사항을 푸시하는 작업을 도구 호출로 수행할 수 있습니다. GitHub가 제공하는 공식 원격 MCP 서버는 github/github-mcp-server 저장소에서 안내합니다.
여기서 초보자가 자주 헷갈리는 부분이 있습니다. 공식 명칭은 GitHub MCP Server이고, Codex 설정에서 사용할 서버 이름은 github입니다. git MCP라는 이름의 별도 서버를 찾는 것이 아닙니다. 공식 원격 서버 주소는 https://api.githubcopilot.com/mcp/입니다. Codex에서 /mcp를 입력하는 것은 설치 명령이 아니라, 현재 연결된 github 서버와 사용할 수 있는 도구를 확인하는 명령입니다.
OpenAI Codex에서 공식 안내대로 연결하려면 환경 변수에 PAT를 저장한 뒤 다음처럼 등록합니다. 토큰 자체를 설정 파일에 직접 적지 않는 것이 핵심입니다.
codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT_TOKENCode language: JavaScript (javascript)그 다음 Codex를 다시 시작하고 /mcp에서 github 서버와 도구가 표시되는지 확인합니다. GitHub 공식 문서에는 다른 MCP 호스트에서 OAuth로 연결하는 방법도 안내되어 있지만, Codex에 적용하는 방법은 사용하는 Codex 버전의 공식 설치 안내를 우선 따라야 합니다. 연결 방식이 달라도 서버의 정확한 이름은 github, 제품명은 GitHub MCP Server입니다.
물론 이 과정을 모두 직접 외울 필요는 없습니다. Codex에게 “GitHub MCP를 설치해줘”라고 한마디만 요청해도 현재 환경에 맞는 설치 방법을 안내하고, 필요한 설정을 함께 진행해 줍니다. 다만 권한을 승인하거나 토큰을 입력하는 단계에서는 어떤 저장소에 어떤 권한을 허용하는지 직접 확인하세요. 편리한 설치와 안전한 권한 관리는 서로 다른 일입니다.
정책 페이지 배포를 부탁하는 프롬프트
연결을 마쳤다면 긴 설명보다 작업 범위와 확인 항목을 명확히 적는 편이 좋습니다. 다음 프롬프트는 처음 사용할 때 그대로 복사해도 되는 형태입니다.
이 프로젝트를 전체적으로 살펴보고 앱의 실제 기능과 데이터 흐름을 기준으로 개인정보처리방침과 이용약관 초안을 작성해 주세요. 두 문서를 정적 HTML 페이지로 만들고 GitHub 저장소에 커밋한 뒤 GitHub Pages로 배포해 주세요. 배포 전에 변경할 파일, 저장소, 브랜치, 공개될 개인정보 범위를 요약하고 제 확인을 받아 주세요. 배포가 끝나면 개인정보처리방침 URL과 이용약관 URL, 커밋 해시, 실제 배포 상태를 알려 주세요. 법률 자문이 아니라 초안이라는 점과 사람이 최종 검토해야 할 항목도 함께 표시해 주세요.
이 프롬프트에서 중요한 부분은 “바로 배포해 주세요”만 쓰지 않고, 먼저 변경 파일과 공개 범위를 보여 달라고 한 점입니다. GitHub MCP는 실제 저장소를 수정할 수 있는 연결이므로, 저장소 이름과 브랜치가 맞는지 확인하고 커밋·푸시 직전에 한 번 멈추게 하는 편이 좋습니다. 특히 정책 페이지에 실제 개인정보나 비밀 키가 들어가면 안 됩니다.
마무리
이번에 살펴본 방식은 “GitHub에 코드를 올리면 정책 문서도 무료로 인터넷에 공개할 수 있다”는 단순한 팁을 넘어, 작은 앱을 운영하는 방법에 가깝습니다. GitHub는 백업 저장소이면서 다른 사람의 작업물을 구경하는 보물상자이고, 동시에 정적 사이트와 자동화 도구를 제공하는 개발 플랫폼입니다.
물론 방법은 하나뿐이 아닙니다. 워드프레스에 페이지를 만드는 방법, 별도 서버를 빌리는 방법, 직접 서버를 운영하는 방법도 있습니다. 업데이트 빈도, 사용자 입력 여부, 도메인 필요성, 운영 비용에 따라 선택은 달라집니다. 중요한 것은 앱에 실제로 수집하는 정보를 정확히 문서화하고, 공개 주소를 오래 유지할 수 있는 위치에 두는 것입니다.
GitHub Pages는 그 출발점으로 충분히 간단합니다. 그리고 Codex나 Claude 같은 AI 도구와 GitHub MCP를 연결하면 문서 초안 작성부터 파일 생성, 커밋, 배포 확인까지의 반복 작업도 줄일 수 있습니다. 다만 편리함이 책임을 대신하지는 않습니다. AI를 활용하되, 법률 문서는 반드시 실제 서비스와 대조하고 필요하다면 변호사에게 검토를 받으세요.
답글 남기기