개인 개발 홈페이지는 Cloudflare+GitHub에서. AI로 업데이트하는 정적 사이트를 만드는 방법과 요금

개인으로 앱을 만들면 앱 본체 개발 이외에도 사업 소개나 지원을 위한 홈페이지가 필요합니다.

SANGE Studio에서도 D-U-N-S 번호를 받기 위한 준비와 앱 소개 페이지를 준비하기 위해 웹사이트가 필요했습니다. 가능한 한 비용을 들이지 않고 일상적인 관리에도 시간을 할 수 없는 구성으로 하고 싶다. 따라서 선택사항이 되는 것은 Cloudflare에서 정적 사이트를 게시하고 GitHub에서 파일을 관리하는 방법입니다.

기사를 업데이트할 때 AI에 HTML을 만들거나 수정하도록 도와주고 인간이 내용과 표시를 확인한 다음 공개합니다. 개인 규모의 사업 사이트라면, 이 구성으로 충분한 장면은 많다고 생각하고 있습니다.

이 기사에서는 선택한 이유부터 공개 절차, 비용까지 설명합니다. 요금・사양은 2026년 10월 27일 확인 시점의 정보입니다.

1. D-U-N-S 번호 취득과 앱 소개를 계기로 사이트 준비

D-U-N-S 번호는 기업과 기업을 식별하는 9자리 숫자입니다. Google Play 조직 계정을 만드는 경우 원칙적으로 이 번호가 필요합니다.

Google Play는 조직 계정의 등록 정보로 D-U-N-S 번호 외에도 '조직 웹사이트'를 요청합니다. [1]

여기는 혼동하기 쉬운 곳입니다. Google Play가 웹사이트를 요청하고 모든 D-U-N-S 번호를 신청할 때 사이트가 일률적으로 필수라는 것은 또 다른 이야기입니다. D-U-N-S 번호를 신청할 때 필요한 정보는 이용할 창구 안내를 확인하시기 바랍니다.

어쨌든, 사업의 실태를 설명할 수 있는 페이지와, 앱의 소개·지원 페이지는, 이후의 운영에서도 도움이 됩니다. 먼저 다음 내용을 준비하면 작게 시작할 수 있습니다.

사이트를 준비하면 심사에 다닌다는 뜻이 아닙니다. 게재하는 정보는, 실제의 사업이나 신청 내용과 정합시키는 것이 중요합니다.

2. 비용과 관리의 번거로움을 억제한다면, 정적 사이트가 후보가 된다

홈페이지를 갖기 위해 반드시 임대 서버를 계약하거나 WordPress를 설치할 필요는 없습니다.

Cloudflare Pages는 HTML, 이미지 등을 게시할 수 있는 서비스입니다. 무료 플랜에서 사용할 수 있으며 서비스가 제공하는 ○○.pages.dev라는 URL에서도 공개할 수 있습니다. [2]

GitHub는 사이트의 파일과 변경 내역을 관리하는 장소로 활용합니다. 언제 어디를 고쳤는지 확인할 수 있으며 문제가 있으면 과거의 상태로 되돌리기 위한 단서도 남길 수 있습니다.

역할을 정리하면 다음과 같습니다.

Cloudflare가 유일한 최저 서비스는 아닙니다. 마찬가지로 무료로 사용할 수있는 서비스가 있습니다. 게다가 개인개발의 소개 사이트를 저비용으로 시작한다는 목적에 맞는 옵션입니다.

1. AI+인간기사 · HTML 작성 및 확인
2. GitHub파일 및 변경 내역 관리
3. GitHub Actions승인된 변경사항 게시 처리
4. Cloudflare PagesHTML · 이미지를 독자에게 전달

GitHub에서 관리하고 Actions에서 공개. 독자에게 페이지를 전달하는 것은 Cloudflare Pages입니다.

3. 정적 호스팅과 CMS의 차이

정적 호스팅은 사전에 만든 HTML과 이미지를 그대로 뷰어에게 전달하는 방법입니다.

CMS는 기사 및 이미지를 관리하고 업데이트하기 쉽게 만드는 방법입니다. WordPress가 대표적인 예입니다. 관리 화면에서 기사를 쓰고 공개 날짜와 시간을 설정하는 등의 조작을 할 수 있습니다.

엄밀히 말하면 이 두 가지는 대의어가 아닙니다. CMS에서 기사를 관리하고 완성된 페이지를 정적 사이트로 전달하는 구성도 있습니다. 여기에서는 알기 쉽게 HTML을 GitHub로 관리하는 구성과 일반적인 WordPress를 스스로 설치·운용하는 구성을 비교합니다.

HTML은 페이지의 구조를 설명하는 파일입니다. 기존에는 기사를 추가할 때마다 코드를 만지는 것이 정적 사이트의 부담이 되기 쉬운 부분이었습니다. AI에 그 작업을 도와주면 선택하기 쉬워집니다.

4. 취약성에 대한 대응과 AI의 진화를 감안하면, 공개하는 구조를 작게 하고 싶다

웹사이트는 게시 끝이 아닙니다. 사용하는 소프트웨어에 취약점이 발견되면 업데이트 및 확인이 필요합니다. WordPress의 공식 자료에서도 본체・플러그인등의 갱신이나 권한・인증의 관리가 설명되어 있습니다. [3]

개인개발에서는, 그 보수에 사용할 수 있는 시간이 한정되어 있습니다. 사업 소개와 앱 소개가 중심이라면, 열람시에 움직이는 프로그램이나 데이터베이스, 일반 공개된 기사 편집용 로그인 화면을, 스스로 운용할 필요를 줄이고 싶다고 생각했습니다.

순수한 정적 파일 전송으로 좁히면 이러한 부분을 노리는 공격의 입구를 줄일 수 있습니다. 하지만 정적 사이트에서도 GitHub 및 Cloudflare 계정이 탈취되거나 악성 자바스크립트가 오염되면 피해를 입을 수 있습니다. 안전성은 구성과 운영 모두에서 결정됩니다.

내가 정적 사이트를 선택하고 싶은 이유는 '최근 취약점은 모두 CMS 때문'이 아닙니다. 필요한 기능에 대해 관리하는 기능을 줄일 수 있기 때문에입니다.

또한 AI가 HTML과 CSS를 만드는 데 도움이 되었으며 파일을 직접 편집하는 부담도 낮아졌습니다. 보안 구성을 단순화하면서 업데이트 수고를 줄일 수 있습니다. 이 조합이 개인 규모에서는 매력입니다.

5. 기사는 AI로 HTML화하고 인간이 확인한 후 공개한다

가정하는 업데이트 흐름은 다음 6단계입니다.

1. 기사의 테마, 전하고 싶은 내용, 체험을 정리한다.
2. AI에 기존 디자인에 맞춘 기사 페이지의 작성을 의뢰한다.
3. GitHub에 변경안을 등록한다.
4. 인간이 문장·근거·화면 표시·변경 내용을 확인한다.
5. 확인된 변경사항을 공개용 main 브랜치로 가져옵니다.
6. GitHub Actions가 Cloudflare Pages에 게시합니다.

GitHub상에서 변경안을 확인하는 구조를 「풀 요청」, 확인한 변경을 받아들이는 조작을 「병합」이라고 부릅니다. 혼자 운영하는 경우에도 작성과 공개 사이에 확인하는 단계를 둘 수 있습니다.

AI에 대한 요청은 예를 들어 다음과 같이 구현됩니다.

기존 기사 페이지를 참고하여 이 원고를 HTML화하십시오. 제목, 표, 참고 링크를 정리하고 스마트폰에서도 읽을 수 있도록 해 주세요. 기사 목록과 사이트맵도 업데이트하세요. 원고에 없는 체험담이나 숫자는 추가하지 않고, 확인이 필요한 기술은 지적해 주세요.

게시하기 전에 문장의 정확성, 스마트폰 보기, 링크 대상, 이미지 권리, 개인 정보 및 비밀 정보의 혼입을 확인합니다. AI의 리뷰도 보조에 사용할 수 있습니다만, AI끼리 확인시키는 것만으로 정확성이 보증되는 것은 아닙니다.

기사가 늘어나면 Markdown에서 본문을 작성하여 HTML을 생성하는 메커니즘으로 옮길 수도 있습니다. 처음부터 큰 구조를 만들지 않고, 갱신이 부담이 된 단계에서 도입하면 좋다고 생각하고 있습니다.

1. 1. 원고 준비 전달하고 싶은 내용을 정리
2. 2. AI로 HTML화기존 디자인에 맞추기
3. 3. 인간이 확인문장·근거·표시를 확인
4. 4. main에 반영Actions가 Pages에 게시

AI에 의한 작성과 공개 사이에, 인간이 내용·표시를 확인하는 단계를 둡니다.

6. 공개 예약 및 편집 기능이 필요하면 서비스 추가

정적 사이트에서는 HTML에 미래의 날짜를 쓰면 공개 예약이 되지 않습니다. 파일을 업로드하면 기사 목록에 올려놓지 않아도 URL에서 볼 수 있습니다.

예약 공개가 필요하면 공개 일시를 관리할 수 있는 헤드리스 CMS나 예약 배포에 대응하는 서비스 등을 검토합니다. 헤드리스 CMS는 기사의 관리 기능을 제공하고 페이지의 외형이나 전달과는 분리하여 사용할 수 있는 CMS입니다.

이 경우, 지정 날짜와 시간이 될 때까지 기사를 공개 파일에 포함시키지 않고 지정 시간의 공개 처리와 조합해야 합니다. 비공개 문서가 미리보기 또는 공개 리포지토리에 노출되지 않는지 확인합니다.

GitHub Actions를 정기적으로 실행하는 방법도 있지만, 실행이 지연될 수 있으므로 엄격한 시간 보증이 필요한 용도에는 적합하지 않습니다. [8]

여러 사람의 편집, 승인, 이미지 관리 및 예약 게시가 일상적으로 필요한 경우 CMS의 가치가 커집니다. 필요한 편집 기능이 늘어날 때 구성을 검토하는 정책입니다.

7. Cloudflare 등록부터 웹페이지 공개까지

여기에서는 Cloudflare Pages의 'Direct Upload'를 사용하여 GitHub Actions에서 게시하는 방법을 소개합니다. Cloudflare 공식은 이 조합의 단계를 제공합니다. [4]

Cloudflare에는 Workers Static Assets이라는 정적 전송 옵션도 있지만 이 문서의 설정 및 명령은 Pages용입니다. 화면 이름은 변경될 수 있으므로 서비스 이름과 설정 내용을 확인하면서 진행하십시오.

1단계: Cloudflare 및 GitHub 계정 만들기

Cloudflare 및 GitHub에서 계정을 만들고 이메일 인증을 완료합니다. 둘 다 다중 요소 인증을 설정합니다.

우선 무료 플랜으로 시작할 수 있습니다. 기존의 고유 도메인이 있는 경우에도 공개 확인은 Pages에서 제공하는 URL로 시작됩니다.

2단계: 고유 도메인 가져오기

고유 도메인은 example.com과 같이 직접 가져오고 계속 사용하는 웹의 이름입니다. 사이트 파일을 저장하는 Cloudflare Pages와 별도로 계약합니다. 자체 도메인을 취득하는 데는 비용이 들고, 취득 후에도 계속 이용하려면 갱신 요금이 필요합니다. 무료 pages.dev에서도 공개할 수 있습니다만, 사업 사이트로서 계속 이용한다면, 옥호에 맞는 독자 도메인을 준비하면 안내하기 쉬워집니다. 이미 가지고 있다면 새로운 취득이 필요하지 않습니다.

검색 대상에는 Cloudflare Registrar 및 타사 도메인 등록 서비스가 있습니다. Cloudflare에서 함께 관리하고 싶다면 다음과 같은 방법으로 얻을 수 있습니다. [11]

1. Cloudflare에 로그인하고 Domain Registration(도메인 등록)에서 Register Domains(도메인 등록)를 엽니다.
2. 원하는 도메인 이름을 검색하여 검색할 수 있는 후보를 확인합니다. 야호에 가깝고 짧고 입력하기 쉬운 이름을 선택합니다.
3. 취득 요금・계약 연수・다음 번 갱신일을 확인합니다. 초년도의 저렴뿐만 아니라 갱신 요금, 세금, 결제 통화도 포함하여 비교합니다.
4. 등록자의 이름, 주소, 전화번호, 이메일 주소를 정확하게 입력하여 결제 방법을 등록합니다. Cloudflare의 등록자 정보는 ASCII 문자로의 입력이 필요하기 때문에, 일본어의 성명·주소는 로마자 등으로 입력합니다.
5. 약관과 지불 금액을 확인하고 구매를 확인합니다.
6. 등록 확인 이메일을 확인하고 요청한 이메일 주소 인증을 완료합니다. 자동 갱신 설정 및 결제 방법 만료일도 확인합니다.

Cloudflare Registrar에서 취득한 도메인은 Cloudflare의 네임 서버를 이용합니다. 취득 후 타사 DNS의 네임서버로 자유롭게 전환할 수 있는 서비스가 아닙니다. 또한 원하는 도메인 끝을 다루지 않은 경우 해당 타사 서비스에서 검색합니다. [11]

도메인만 검색하면 웹페이지가 표시되지 않습니다. 나중에 Pages에 사이트를 게시하고 8단계에서 자체 도메인과 연결합니다. 다른 회사에서 취득한 경우에도 도메인 등록 대상을 Cloudflare로 이전하지 않고 Pages와 함께 사용할 수 있습니다.

도메인 계약에는 해당 도메인의 사서함이 반드시 포함되는 것은 아닙니다. info@example.com 등으로 메일을 보내고 받으려면 메일 서비스를 별도로 고려하십시오.

3단계: GitHub에 리포지토리 만들기

리포지토리는 사이트의 파일과 변경 내역을 포함하는 저장 위치입니다. GitHub의 "New repository"에서 예를 들어 sange-studio-web이라는 이름으로 만듭니다.

비공개 원고를 다루면 Private를 선택하면 쉽게 관리할 수 있습니다. 그러나 비공개 리포지토리에서도 게시 폴더에 넣은 파일은 사이트로 전송됩니다.

게시할 파일만 public 폴더에 넣습니다. 예를 들어 public/index.html을 맨 위 페이지, public/apps/index.html을 앱 목록, public/privacy/index.html을 개인 정보 보호 정책으로 만듭니다. 이렇게 하면 원고나 설정 파일을 실수로 사이트에 전달하는 범위를 좁힐 수 있습니다.

처음에는 public/index.html만으로도 괜찮습니다. AI에 사업 소개 페이지를 작성하게 하고, 수중의 브라우저로 표시를 확인합니다.

4단계: Cloudflare Pages 프로젝트 만들기

Cloudflare 관리 화면에서 Workers & Pages에서 애플리케이션 생성으로 이동하여 Pages 파일 업로드(Direct Upload)를 선택합니다. 프로젝트 이름을 결정하고 public 폴더의 내용을 업로드하여 처음 게시합니다. [5]

이 시점에서 표시되는 https:// 프로젝트 이름.pages.dev로 이동하여 톱 페이지를 확인합니다. 프로젝트 이름과 Account ID는 다음 설정에서 사용됩니다.

Direct Upload로 만든 프로젝트는 나중에 Git 연동형으로 전환할 수 없습니다. 전환하려면 새 프로젝트를 만들어야 합니다. [5]

5단계: 게시용 API 토큰 만들기

API 토큰은 GitHub Actions에서 Cloudflare로 게시하기 위한 자격 증명입니다.

Cloudflare의 API Tokens 화면에서 사용자 지정 토큰을 만들고 권한에 Account → Cloudflare Pages → Edit를 설정합니다. 대상 계정도 필요한 계정으로 좁힙니다. [4]

작성한 토큰은 HTML이나 GitHub 파일에 직접 쓰지 않습니다.

6단계: GitHub의 Secrets에 자격 증명 등록

GitHub의 리포지토리에서 Settings → Secrets and variables → Actions를 열고 다음 두 가지를 Repository secrets로 추가합니다.

Secrets는 공개 처리에 사용하는 자격 증명을 저장하는 기능입니다. [4]

7단계: GitHub Actions의 공개 설정 추가

리포지토리에 .github/workflows/deploy.yml을 만들고 다음 내용을 저장합니다. your-pages-project를 자신의 Pages 프로젝트 이름으로 바꿉니다.

name: Deploy website

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: production-website
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Check entry page
        run: test -f public/index.html

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=your-pages-project --branch=main

공식 예제를 토대로 main 업데이트 시에만 게시하는 최소 구성을 사용합니다. [4] HTML 생성 처리가 없으므로 빌드 설정이 필요하지 않습니다. 이 예의 체크는 톱 페이지의 존재 확인만이므로, 내용이나 표시의 리뷰는 별도 실시합니다.

처음에는 Pages 측의 프로덕션 브랜치가 main 인지 확인하십시오. main에 설정 파일을 반영한 후 GitHub의 'Actions'에서 실행 결과를 검토하고 성공한 후 사이트를 엽니다.

위는 가독성을 선호하는 버전 태그 지정입니다. 지속적인 운영에서는 Action을 확인된 커밋 SHA에 고정하고 업데이트를 검토하면 공개 경로 관리를 강화할 수 있습니다.

8단계: 검색한 고유 도메인을 Pages로 설정

Pages 프로젝트의 "Custom domains → Set up a domain"에서 사용할 도메인을 추가합니다. [6]

Cloudflare Registrar에서 취득한 도메인은 Cloudflare의 DNS를 이용하는 상태입니다. 타사에서 얻은 example.com과 같은 루트 도메인을 사용하는 경우 해당 도메인을 Cloudflare에 추가하고 등록자의 관리 화면에 지정된 이름 서버로 변경합니다. 기존 메일을 사용하는 경우 변경하기 전에 MX 및 TXT와 같은 DNS 레코드도 인계합니다.

www.example.com과 같은 하위 도메인은 외부 DNS 서비스에 CNAME을 설정하는 방법도 있습니다. 둘 다 DNS 레코드를 추가하는 것만으로는 안되며 먼저 페이지의 Custom domains와 연결해야 합니다. [6]

활성화 후에는 HTTPS로 열고 이미지, 링크, 스마트폰 표시가 올바른지 확인합니다. 자신의 도메인을 공식 URL로 만들려면 canonical 또는 Sitemap URL도 일치합니다.

더 적은 설정으로 시작하는 방법도 있습니다.

GitHub Actions에서 공개 제어가 필요하지 않은 경우 Pages에서 GitHub 리포지토리를 직접 연결하는 것이 더 적습니다. Pages 만들기 화면에서 Git 저장소 가져오기를 선택하고 프로덕션 분기를 main, 프레임워크를 만들고, 빌드 명령을 exit 0, 출력 대상을 public 로 설정하는 구성입니다. [9]

이 방법을 사용하면 GitHub에 대한 변경 사항을 Cloudflare가 감지하고 게시하므로 공개 API 토큰 및 Actions 설정을 생략할 수 있습니다. Actions 방식과 직접 연계 방식의 자동 공개를 동시에 움직일 필요는 없습니다.

1. 고유 도메인예: example.com
2. DNS 설정도메인 연결 대상 지정
3. 페이지 설정Custom domains에서 연결
4. 사이트 보기HTTPS에서 게시 확인

도메인 검색 및 페이지 게시는 별도의 작업입니다. DNS 설정을 Pages 측과 연결합니다.

8. 요금은 얼마인가요?

이 문서에서와 같이 HTML, CSS, 이미지를 제공하는 소규모 사이트라면 호스팅 및 파일 관리가 월 0엔부터 시작됩니다.

Cloudflare는 Pages의 요청 수와 대역을 무제한으로 안내하고 있습니다만, 파일수 등의 제한이나 이용 조건은 있습니다. 무료 플랜의 Git 연계 빌드는 월 500회, 파일 수는 최대 20,000입니다. GitHub Actions에서 처리하고 Direct Upload하는 경우 Cloudflare 측의 빌드 프레임과 GitHub 측의 실행 프레임을 구별하여 생각합니다. [2][7]

GitHub Actions는 공개 리포지토리의 표준 GitHub 호스트 러너라면 실행 시간이 무료입니다. 비공개 리포지토리는 무료 테두리를 초과합니다. 대형 러너나 보존 용량 등은 별도 조건입니다. [10]

예를 들어, 비공개 리포지토리에서 한 번 3분의 게시 처리를 월 30회 실행하면 총 90분입니다. 다른 용도로 프레임을 다 사용하지 않고 저장 용량 등도 프레임 내라면 월 2,000 분에 들어갑니다.

자체 도메인이 이미 있는 경우 사이트 추가로 도메인을 새로 가져올 비용이 필요하지 않습니다. 하지만 기존 도메인의 업데이트 비용은 계속 걸립니다. 독자 도메인의 가격은 초년도의 할인만으로 판단하지 않고, 갱신시의 금액도 확인해 주세요.

또한 API, 데이터베이스, Pages Functions 등을 추가한 경우의 비용은 이 정적 사이트의 견적에는 포함하지 않습니다.

개인개발에서는 운영을 계속할 수 있는 구성을 선택

비즈니스 소개, 앱 소개, 지원, 소수로 업데이트하는 블로그. 이러한 용도라면 Cloudflare와 GitHub에서 정적 사이트를 운영하는 방법은 강력한 옵션입니다.

AI에게 페이지의 작성이나 수정을 돕고, 인간이 확인해, 승인한 내용을 자동 공개한다. 필요한 편집 기능이 늘어나면 그 단계에서 CMS나 외부 서비스를 더한다.

SANGE Studio와 같은 개인 규모의 운영에서는 앱 개발에 걸리는 시간을 확보하면서 비즈니스 정보를 계속 전달되는 구성을 선택하고 싶습니다.

참고 자료

1. Google Play Console 계정을 만드는 데 필요한 정보
2. Cloudflare Pages 제품 안내
3. WordPress 공식: Hardening WordPress
4. Cloudflare 공식: Direct Upload와 CI 연동
5. Cloudflare 공식: Direct Upload
6. Cloudflare 공식: Custom domains
7. Cloudflare Pages 제한
8. GitHub 공식: schedule 이벤트
9. Cloudflare 공식: Static HTML
10. GitHub Actions 요금 및 무료 테두리
11. Cloudflare 공식: 새 도메인 등록