Notice
Recent Posts
Recent Comments
Link
반응형
«   2026/07   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tags more
Archives
Today
Total
관리 메뉴

오늘도 공부

ChatGPT Sites 내부에선 어떻게 돌아갈까? 본문

AI/추천 오픈소스

ChatGPT Sites 내부에선 어떻게 돌아갈까?

행복한 수지아빠 2026. 7. 24. 15:03
반응형

ChatGPT의 Sites 기능은 단순히 HTML 파일을 만들어 다운로드해 주는 기능이 아닙니다. 대화에서 웹사이트를 기획하고 코드를 작성한 뒤, 빌드·버전 저장·호스팅·외부 URL 연결까지 처리하는 관리형 웹 배포 서비스에 가깝습니다.

핵심 구조를 먼저 한 문장으로 정리하면 다음과 같습니다.

ChatGPT의 Work VM은 웹사이트를 만드는 작업실이고, Sites는 완성된 소스와 빌드 산출물을 별도의 관리형 Worker 환경에 배포해 외부에서 접속할 수 있게 하는 서비스입니다.

따라서 작업에 사용한 VM이 종료되거나 정리되더라도, 이미 배포된 사이트는 별도의 운영 환경에서 계속 제공될 수 있습니다.

실제로 생성된 사이트도 로컬 작업 폴더가 정리된 후에도 Sites 서비스에 다음 정보가 남아 있었습니다.

  • 사이트 프로젝트 정보
  • 공개 주소
  • 공개 범위
  • Git 커밋 기준 소스 버전
  • 전체 소스 아카이브
  • 배포된 운영 버전
  • 사이트 대표 이미지
  • 접근 권한 설정

이 원리를 이해하려면 Work VM, Sites, Vinext, Vite, Cloudflare Worker의 역할을 분리해서 봐야 합니다.

1. ChatGPT Sites는 하나의 프로그램이 아니라 전체 배포 과정이다

Sites를 하나의 웹 프레임워크나 서버 프로그램으로 생각하면 구조가 혼란스러워집니다.

Sites는 대략 다음 기능을 하나로 묶은 서비스입니다.

  1. 사이트 프로젝트 생성
  2. 작업용 소스 코드 준비
  3. 이미지와 정적 파일 관리
  4. React·Next.js 코드 빌드
  5. Worker용 서버 코드 생성
  6. 빌드 산출물 검증
  7. 소스 버전 저장
  8. 운영 환경 배포
  9. chatgpt.site 주소 연결
  10. 공개·비공개 접근 권한 관리
  11. 환경변수와 API 키 관리
  12. 데이터베이스와 파일 저장소 연결

전체 흐름은 다음과 같습니다.

여기에서 Work VM은 최종 운영 서버가 아닙니다. 코드를 만들고 검사하는 임시 개발환경입니다.

운영 사이트는 Sites가 저장하고 배포한 별도의 버전으로 서비스됩니다.

2. Work VM은 웹사이트가 계속 실행되는 서버가 아니다

ChatGPT Work 환경에서 사이트를 만들면 /workspace/sites/... 같은 작업 경로에 소스 코드가 준비됩니다.

이번에 확인한 WMU 사이트도 다음 경로로 복원됐습니다.

/workspace/sites/wmu-global-ai-hub

이 폴더에는 일반적인 웹 프로젝트처럼 다음 파일들이 들어 있었습니다.

wmu-global-ai-hub/
├─ app/
│  ├─ page.tsx
│  ├─ layout.tsx
│  ├─ globals.css
│  └─ chatgpt-auth.ts
├─ public/
│  ├─ hero-women-network.png
│  └─ favicon.svg
├─ worker/
│  └─ index.ts
├─ build/
│  └─ sites-vite-plugin.ts
├─ scripts/
│  ├─ build-verified.sh
│  └─ validate-artifact.sh
├─ .openai/
│  └─ hosting.json
├─ vite.config.ts
└─ package.json

ChatGPT는 이 작업 폴더에서 다음 작업을 수행합니다.

  • React 컴포넌트 작성
  • CSS 디자인
  • 이미지 파일 배치
  • 모바일 반응형 적용
  • 버튼과 모달 같은 상호작용 구현
  • 빌드 실행
  • 빌드 산출물 검사
  • 배포할 소스 버전 확정

하지만 외부 사용자가 이 작업 폴더에 직접 접속하는 것은 아닙니다.

Work VM은 개발자 PC와 비슷하고, Sites 운영 환경은 Vercel·Cloudflare Workers 같은 배포 플랫폼과 비슷한 역할을 합니다.

3. VM이 정리됐는데 사이트가 남아 있었던 이유

이번 분석 과정에서 로컬 /workspace를 검색했을 때 처음에는 사이트 소스와 .openai/hosting.json이 발견되지 않았습니다.

이전 작업공간이 자동 정리된 상태였기 때문입니다. 그러나 Sites 서비스에는 WMU Global AI Hub 프로젝트가 남아 있었습니다.

확인된 원격 정보는 다음과 같습니다.

항목확인된 상태

프로젝트 WMU Global AI Hub
공개 주소 wmu-global-ai-hub.tommykim1981.chatgpt.site
공개 범위 Public
저장된 버전 1개
소스 기준 Git 커밋
소스 아카이브 약 3.3MB
커스텀 도메인 없음
운영 환경변수 없음
D1 데이터베이스 없음
R2 파일 저장소 없음

Sites가 저장한 원격 버전을 통해 사이트 체크아웃을 다시 복원할 수 있었습니다.

따라서 Sites에는 최소한 다음 세 가지 계층이 존재한다고 이해할 수 있습니다.

1. 로컬 작업본
   ChatGPT가 현재 수정하는 파일

2. 저장된 소스 버전
   특정 Git 커밋과 소스 아카이브

3. 운영 배포본
   외부 URL에서 서비스되는 실행 버전

이 세 가지는 서로 같아 보이지만 목적이 다릅니다.

로컬 작업본

현재 편집 중인 코드입니다. 아직 외부 사용자에게 공개되지 않은 변경사항이 포함될 수 있습니다.

저장된 소스 버전

특정 시점의 소스를 변경 불가능한 버전으로 저장한 것입니다. 나중에 복원하거나 배포 이력을 확인하는 기준이 됩니다.

운영 배포본

저장된 버전을 실제 운영 환경에서 실행하도록 배포한 결과입니다. 사용자가 브라우저에서 보는 것은 이 운영 배포본입니다.

4. .openai/hosting.json은 어떤 역할을 할까?

Sites 프로젝트에는 .openai/hosting.json이라는 파일이 있습니다.

WMU 사이트에서 확인된 형태는 다음과 같습니다.

{
  "d1": null,
  "project_id": "사이트 프로젝트 식별자",
  "r2": null
}

이 파일에 웹사이트 전체 설정이 들어 있는 것은 아닙니다. Sites 서비스와 로컬 소스 코드를 연결하는 프로젝트 표식에 가깝습니다.

각 필드의 의미는 다음과 같습니다.

필드역할

project_id 현재 코드가 어느 Sites 프로젝트에 속하는지 식별
d1 Sites가 연결한 D1 데이터베이스 바인딩
r2 Sites가 연결한 R2 파일 저장소 바인딩

현재 WMU 사이트는 랜딩 페이지이기 때문에 D1과 R2가 모두 null입니다.

데이터베이스나 업로드 기능을 추가하면 Sites가 해당 리소스를 만들고 논리적 바인딩을 이 파일과 연결할 수 있습니다.

중요한 점은 API 키나 비밀번호를 hosting.json에 넣지 않는다는 것입니다. 비밀정보는 Sites의 운영 환경변수 기능으로 관리해야 합니다.

5. 실제 사이트는 어떤 기술로 만들어졌을까?

NextJs로 만든 사이트의 package.json을 확인한 결과 주요 구성은 다음과 같았습니다.

기술역할

React 19 UI 컴포넌트 작성
Next.js 16 페이지와 서버 기능 구성
Vite 8 개발 서버와 프로덕션 빌드
Vinext Next.js 기능을 Vite·Worker 환경에 연결
Cloudflare Vite Plugin Worker 환경 빌드와 로컬 실행
Wrangler Cloudflare Worker 개발 도구
TypeScript 타입이 있는 JavaScript 개발
Tailwind CSS CSS 도구
Drizzle ORM D1 같은 SQL 데이터베이스 연결 준비

이 중에서 가장 낯선 기술은 Vinext입니다.

6. Vinext는 플랫폼이 아니라 호환 계층이다

Vinext는 호스팅 서비스나 클라우드 플랫폼 이름이 아닙니다.

Next.js 애플리케이션의 API와 실행 방식을 Vite 위에서 다시 구현해, Cloudflare Workers 같은 환경에서 실행할 수 있게 만드는 도구입니다.

Cloudflare의 공식 Vinext 저장소는 Vinext를 Next.js API 표면을 Vite 위에서 재구현하는 플러그인으로 설명합니다. App Router, Pages Router, React Server Components, Server Actions, Middleware, Route Handler, ISR과 정적 내보내기 등을 지원하며, Cloudflare Workers와 가장 깊게 통합됩니다. Cloudflare Vinext 공식 저장소

전체 관계는 다음과 같습니다.

Next.js 코드를 그대로 Cloudflare Worker에 넣는다고 자동으로 실행되지는 않습니다.

Next.js는 다음과 같은 자체 실행 규칙을 가지고 있기 때문입니다.

  • 파일 기반 라우팅
  • App Router
  • 서버 컴포넌트
  • 클라이언트 컴포넌트
  • Route Handler
  • 서버 렌더링
  • 데이터 캐시
  • 이미지 최적화
  • 서버 액션

Vinext는 이런 Next.js의 기능을 Vite 빌드와 Worker의 요청 처리 방식에 맞춰 연결합니다.

WMU 사이트의 vite.config.ts에는 실제로 다음 플러그인이 등록되어 있었습니다.

import vinext from "vinext";
import { defineConfig } from "vite";
import { sites } from "./build/sites-vite-plugin";

export default defineConfig({
  plugins: [
    vinext(),
    sites(),
  ],
});

여기서 각 플러그인의 역할은 다음과 같습니다.

vinext()
→ Next.js 호환 기능과 라우팅을 Vite 빌드에 연결

sites()
→ 빌드 산출물에 Sites 배포 메타데이터를 포함

cloudflare()
→ Worker 런타임과 바인딩을 Vite에 연결

7. 왜 Next.js인데 next build가 아니라 Vinext를 사용할까?

일반적인 Next.js 프로젝트는 다음 명령으로 빌드합니다.

next build

하지만 이 Sites 프로젝트는 다음과 같은 방식으로 빌드됩니다.

vinext build

Vinext 공식 설명에 따르면, Vinext는 next build 결과물을 가져와 변환하는 방식이 아니라 Next.js API를 Vite 위에서 다시 구현하는 방식입니다. Cloudflare Vinext 공식 저장소

즉, 개념적으로 다음과 같은 차이가 있습니다.

일반적인 Next.js 배포

Next.js 코드
→ next build
→ Node.js 또는 Vercel용 결과물

Sites에서 확인된 구조

Next.js 코드
→ Vinext
→ Vite
→ Cloudflare Worker 호환 결과물

이 방식의 장점은 개발자가 React와 Next.js 스타일로 사이트를 작성하면서도 최종 실행 환경을 Worker 구조로 만들 수 있다는 점입니다.

8. 빌드하면 어떤 산출물이 만들어질까?

WMU 사이트의 빌드 검증 스크립트는 최소한 다음 두 파일이 있어야 배포 가능한 산출물로 인정합니다.

dist/server/index.js
dist/.openai/hosting.json

각 파일의 역할은 다음과 같습니다.

dist/server/index.js

Worker에서 실행할 서버 코드입니다.

최종 모듈은 기본 내보내기 객체를 제공하고, 그 안에 호출 가능한 fetch() 함수가 있어야 합니다.

개념적인 형태는 다음과 같습니다.

export default {
  async fetch(request, env, ctx) {
    return new Response("Hello");
  }
};

dist/.openai/hosting.json

현재 빌드가 어느 Sites 프로젝트와 연결되는지 알려 주는 배포 메타데이터입니다.

정적 자산

이 외에도 다음 파일들이 빌드 산출물에 포함될 수 있습니다.

dist/
├─ server/
│  └─ index.js
├─ assets/
│  ├─ JavaScript 번들
│  ├─ CSS
│  ├─ 폰트
│  └─ 이미지
└─ .openai/
   ├─ hosting.json
   └─ drizzle/

Drizzle 데이터베이스 마이그레이션이 있다면 dist/.openai/drizzle/도 함께 포함됩니다.

9. Worker 서버 코드는 왜 필요할까?

사이트가 단순한 랜딩 페이지라면 HTML, CSS, JavaScript와 이미지만 있어도 충분해 보입니다. 그런데 Sites 프로젝트에는 왜 Worker 서버 코드가 포함될까요?

이유는 배포 형식을 정적 사이트로 제한하지 않고, 서버 렌더링과 백엔드 기능까지 처리할 수 있도록 만들기 위해서입니다.

Worker 서버 코드는 다음 기능을 담당할 수 있습니다.

  • 들어온 HTTP 요청 처리
  • URL별 페이지 라우팅
  • 서버 컴포넌트 실행
  • 서버 렌더링
  • API Route 실행
  • 로그인 사용자 확인
  • 환경변수 접근
  • 데이터베이스 조회
  • 파일 저장소 접근
  • 외부 API 호출
  • 이미지 최적화
  • 오류 처리

Cloudflare Workers에서는 외부 HTTP 요청이 fetch() 핸들러로 전달됩니다. 이 함수는 Request, 환경 바인딩인 env, 실행 컨텍스트인 ctx를 받아 Response를 반환합니다. Cloudflare Workers Fetch Handler 공식 문서

export default {
  async fetch(request, env, ctx) {
    return new Response("응답");
  },
};

WMU 사이트에서도 같은 형태를 확인할 수 있었습니다.

const worker = {
  async fetch(request, env, ctx) {
    return handler.fetch(request, env, ctx);
  },
};

export default worker;

여기서 handler는 Vinext가 제공하는 Next.js App Router 실행기입니다.

즉, Worker가 직접 모든 페이지를 구성하는 것이 아니라 Vinext의 핸들러에게 요청을 전달합니다.

10. 정적 파일과 Worker는 어떻게 함께 동작할까?

Sites의 배포물은 정적 자산과 서버 코드를 함께 포함할 수 있습니다.

배포 버전
├─ 정적 자산
│  ├─ 이미지
│  ├─ CSS
│  ├─ 브라우저 JavaScript
│  └─ 폰트
└─ Worker 서버
   ├─ 페이지 라우팅
   ├─ 서버 렌더링
   ├─ API
   └─ 외부 서비스 연동

Cloudflare Workers는 HTML, CSS, 이미지 같은 정적 자산을 Worker와 함께 배포할 수 있습니다. Cloudflare는 이런 정적 파일을 캐시하고 브라우저에 제공할 수 있다고 설명합니다. Cloudflare Workers Static Assets 공식 문서

Worker 코드에서는 env.ASSETS 바인딩을 통해 정적 파일을 직접 가져올 수도 있습니다.

return env.ASSETS.fetch(request);

Cloudflare 공식 문서에서도 Assets 바인딩을 사용해 env.ASSETS.fetch() 형태로 정적 자산을 가져올 수 있다고 설명합니다. Cloudflare Assets Binding 공식 문서

WMU 사이트에서는 이미지 최적화 경로가 들어오면 다음과 같은 처리를 합니다.

if (url.pathname === "/_vinext/image") {
  return handleImageOptimization(request, {
    fetchAsset: (path) =>
      env.ASSETS.fetch(
        new Request(new URL(path, request.url))
      ),
  });
}

일반적인 요청 흐름은 다음과 같습니다.

사이트가 대부분 정적이더라도 하나의 Worker 배포 안에서 정적 자산과 동적 요청을 통합해 처리할 수 있습니다.

11. 모든 페이지 요청이 Worker를 거쳐야 할까?

실제 라우팅 우선순위와 캐시 정책은 Sites의 비공개 배포 설정에 따라 달라질 수 있습니다.

개념적으로는 다음 두 방식이 가능합니다.

정적 자산 우선 처리

이미 생성된 CSS, JavaScript, 이미지 요청은 정적 자산 계층에서 바로 반환하고, 동적 요청만 Worker로 전달합니다.

정적 파일 요청 → CDN·Assets
동적 페이지 요청 → Worker
API 요청 → Worker

Worker가 요청을 분류

모든 요청이 Worker 진입점으로 전달되고, Worker가 정적 자산과 페이지 요청을 구분합니다.

모든 요청 → Worker → Assets 또는 서버 핸들러

WMU 프로젝트 소스에서는 Worker가 이미지 최적화 요청을 직접 분기하고, 나머지 요청은 Vinext 핸들러로 전달하는 것을 확인했습니다.

12. Sites는 백엔드도 만들 수 있을까?

가능합니다. Worker 서버 코드가 포함되는 가장 중요한 이유 중 하나입니다.

Sites에서 구현할 수 있는 백엔드 기능은 다음과 같습니다.

기능구현 방식

REST API Next.js Route Handler
폼 접수 POST /api/contact
외부 AI 호출 Worker에서 fetch()
회원별 페이지 로그인 헤더 확인 후 렌더링
게시물 저장 D1 데이터베이스
이미지 업로드 R2 저장소
결제 Webhook 공개 API 경로에서 수신
Telegram Webhook Telegram이 Sites API로 POST
이메일 발송 외부 이메일 API 호출
관리자 기능 인증 + D1
다국어 콘텐츠 URL·헤더·데이터에 따라 렌더링

예를 들어 문의 폼 API는 다음처럼 만들 수 있습니다.

export async function POST(request: Request) {
  const form = await request.json();

  if (!form.email || !form.message) {
    return Response.json(
      { error: "필수 항목이 없습니다." },
      { status: 400 },
    );
  }

  return Response.json({
    ok: true,
  });
}

브라우저에서는 다음 주소로 요청할 수 있습니다.

POST /api/contact

Sites가 배포된 후에는 다음과 같은 외부 주소가 됩니다.

POST https://사이트주소.chatgpt.site/api/contact

13. Worker에서 외부 API도 호출할 수 있을까?

Worker는 표준 fetch()를 이용해 외부 HTTP API를 호출할 수 있습니다. Cloudflare 공식 문서도 Workers 내부에서 Fetch API를 이용해 HTTP 리소스를 비동기로 가져올 수 있다고 설명합니다. Cloudflare Workers Fetch API 공식 문서

예를 들어 DeepSeek API를 호출하는 백엔드는 다음과 같은 구조로 만들 수 있습니다.

export async function POST(request: Request) {
  const { message } = await request.json();

  const response = await fetch(
    "https://api.deepseek.com/chat/completions",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.DEEPSEEK_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        model: "deepseek-v4-flash",
        messages: [
          {
            role: "user",
            content: message,
          },
        ],
      }),
    },
  );

  const result = await response.json();
  return Response.json(result);
}

이 구조를 이용하면 다음 기능을 만들 수 있습니다.

  • 웹사이트 AI 상담
  • 콘텐츠 자동 요약
  • 번역
  • 챗봇
  • 상품 설명 생성
  • 한국어 학습 피드백
  • 퀴즈 자동 생성
  • 관리자용 데이터 분석

다만 API 키를 브라우저 코드에 직접 넣으면 안 됩니다.

잘못된 구조
브라우저 → DeepSeek API
API 키가 사용자에게 노출될 수 있음

권장 구조
브라우저 → Sites Worker → DeepSeek API
API 키는 Worker 환경변수에서만 사용

14. API 키와 운영 환경변수는 어디에 저장할까?

사이트 소스에 API 키를 직접 작성하면 Git 기록과 빌드 산출물에 비밀정보가 남을 수 있습니다.

예를 들어 다음 코드는 피해야 합니다.

const apiKey = "실제 API 키";

Sites에는 운영용 환경변수를 별도로 등록하는 기능이 있습니다.

개념적인 구조는 다음과 같습니다.

환경변수는 일반 값과 비밀값으로 구분할 수 있습니다.

일반 환경변수
PUBLIC_SITE_NAME=WMU Global Hub

비밀 환경변수
DEEPSEEK_API_KEY=...
TELEGRAM_BOT_TOKEN=...

비밀값은 소스 코드나 hosting.json에 넣지 않고 Sites의 운영 설정에 보관해야 합니다.

WMU 사이트는 현재 외부 API를 사용하지 않기 때문에 운영 환경변수가 등록되어 있지 않았습니다.

15. D1 데이터베이스는 어떤 역할을 할까?

D1은 Cloudflare Workers에서 사용하는 서버리스 SQL 데이터베이스입니다. SQLite와 호환되는 방식으로 데이터를 저장하고 조회할 수 있습니다.

Cloudflare 공식 문서에 따르면 Worker는 D1 바인딩을 통해 SQL 쿼리를 실행할 수 있습니다. Cloudflare D1 Worker API 공식 문서

Sites에서 D1을 연결하면 다음 기능을 만들 수 있습니다.

  • 회원 프로필
  • 문의 내역
  • 게시판
  • 학습 진도
  • 퀴즈 문제와 답안
  • 포인트 내역
  • 예약 데이터
  • 상품 정보
  • 주문 상태
  • AI 대화 기록

Worker에서는 보통 다음과 같은 방식으로 접근합니다.

export default {
  async fetch(request, env) {
    const result = await env.DB
      .prepare("SELECT * FROM users WHERE id = ?")
      .bind("user-123")
      .first();

    return Response.json(result);
  },
};

Cloudflare는 바인딩을 통해 Worker가 D1 같은 플랫폼 리소스에 접근한다고 설명합니다. Cloudflare Workers Bindings 공식 문서

WMU 사이트의 설정에는 D1이 연결되어 있지 않았습니다.

{
  "d1": null
}

현재는 실제 회원·게시물·포인트 데이터를 저장하지 않는 소개용 사이트이기 때문입니다.

16. R2 파일 저장소는 어떤 역할을 할까?

R2는 이미지, 동영상, PDF, 첨부파일 같은 객체 파일을 저장하는 용도입니다.

Sites에 R2를 연결하면 다음 기능을 구현할 수 있습니다.

  • 회원 프로필 이미지
  • 강의 자료 업로드
  • PDF 교재 저장
  • 상품 이미지
  • 라이브커머스 영상
  • 사용자 제출 과제
  • AI 생성 이미지
  • 관리자 첨부파일

정적 이미지와 사용자 업로드 파일은 구분해야 합니다.

정적 이미지

사이트를 만들 때부터 프로젝트에 포함된 파일입니다.

public/hero-women-network.png

사이트를 다시 배포해야 이미지가 변경됩니다.

사용자 업로드 파일

사이트 운영 중 사용자가 올리는 파일입니다.

사용자 → Worker 업로드 API → R2 저장

사이트를 다시 빌드하지 않아도 파일을 추가하고 삭제할 수 있습니다.

WMU 사이트는 현재 R2를 사용하지 않습니다.

{
  "r2": null
}

17. ChatGPT 로그인도 사용할 수 있을까?

WMU 프로젝트에는 chatgpt-auth.ts라는 인증 보조 코드가 포함되어 있었습니다.

이 코드는 Sites 실행환경이 전달하는 인증 헤더를 읽어 사용자 이메일과 이름을 확인하는 구조입니다.

확인된 주요 헤더는 다음과 같았습니다.

oai-authenticated-user-email
oai-authenticated-user-full-name
oai-authenticated-user-full-name-encoding

개념적인 동작은 다음과 같습니다.

사이트 코드에서는 다음처럼 사용자를 확인할 수 있습니다.

const email = requestHeaders.get(
  "oai-authenticated-user-email"
);

인증되지 않은 사용자는 로그인 경로로 이동시킬 수 있습니다.

/signin-with-chatgpt

현재 WMU 사이트의 접근 모드는 Public이기 때문에 누구나 사이트를 열 수 있습니다. 다만 사이트 일부 기능만 로그인 사용자에게 제공하는 식으로 확장할 수 있습니다.

18. 공개 사이트와 비공개 사이트는 무엇이 다를까?

Sites는 프로젝트별로 접근 정책을 관리합니다.

현재 WMU 사이트는 공개 모드입니다.

access_mode: public

공개 사이트는 외부 사용자가 chatgpt.site 주소로 접속할 수 있습니다.

비공개 또는 제한된 사이트라면 특정 사용자나 그룹만 접근하도록 구성할 수 있습니다.

공개 사이트
→ 누구나 URL로 접속

제한된 사이트
→ 인증된 사용자만 접속

사용자 지정 접근
→ 허용된 사용자·그룹만 접속

접근 정책은 애플리케이션 코드와 별도로 Sites 배포 계층에서 관리됩니다.

이 차이는 중요합니다.

애플리케이션 코드에 로그인 페이지가 있어도 Sites 접근 정책이 Public이면 기본 사이트 주소 자체는 공개될 수 있습니다. 반대로 애플리케이션이 공개 페이지처럼 보여도 Sites 접근 정책이 제한적이면 허용된 사용자만 진입할 수 있습니다.

19. chatgpt.site 주소는 어떻게 연결될까?

Sites에서 프로젝트를 만들면 프로젝트별 슬러그를 기반으로 운영 URL이 만들어집니다.

WMU 사이트는 다음 주소를 사용합니다.

https://wmu-global-ai-hub.tommykim1981.chatgpt.site

주소 구성은 대략 다음처럼 이해할 수 있습니다.

프로젝트 슬러그
        +
사용자 또는 소유자 식별 영역
        +
chatgpt.site

Sites는 이 주소를 배포된 운영 버전과 연결합니다.

개발자가 직접 Nginx를 설정하거나 SSL 인증서를 설치할 필요가 없습니다.

[Inference] DNS, TLS 인증서, 라우팅과 배포 대상 연결은 Sites의 관리형 인프라에서 처리되는 것으로 보입니다.

20. 커스텀 도메인도 연결할 수 있을까?

Sites 서비스에는 프로젝트별 커스텀 도메인을 조회하고 관리하는 구조가 있습니다.

WMU 사이트에는 현재 커스텀 도메인이 연결되어 있지 않습니다.

Custom domains: 없음

따라서 현재는 기본 chatgpt.site 주소만 사용합니다.

커스텀 도메인이 지원되는 프로젝트라면 개념적으로 다음과 같이 연결할 수 있습니다.

기본 주소
wmu-global-ai-hub....chatgpt.site

사용자 도메인
www.example.com

두 주소가 동일한 Sites 프로젝트의 운영 배포본으로 연결되는 방식입니다.

구체적인 DNS 설정과 지원 범위는 Sites의 현재 도메인 연결 정책을 확인해야 합니다.

21. Sites 배포는 어떤 단계를 거칠까?

Sites 배포는 단순히 폴더를 서버에 복사하는 작업이 아닙니다.

확인된 프로젝트 구조를 기준으로 보면 다음 단계로 나뉩니다.

1단계: 소스 준비

React·Next.js 코드와 이미지, CSS, Worker 진입점, 배포 메타데이터를 준비합니다.

2단계: 로컬 빌드

Vinext가 Next.js 호환 기능을 해석하고 Vite가 Worker용 산출물을 만듭니다.

vinext build

3단계: 산출물 검증

프로젝트의 검증 스크립트는 다음 조건을 확인합니다.

dist/server/index.js가 존재하는가?
dist/.openai/hosting.json이 존재하는가?
서버 모듈이 ESM 형식인가?
기본 내보내기에 fetch()가 있는가?
hosting.json이 유효한 JSON인가?

검증 코드의 핵심은 다음과 같습니다.

const worker = await import(workerUrl.href);

if (
  !worker.default ||
  typeof worker.default.fetch !== "function"
) {
  throw new Error(
    "Worker 진입점이 올바르지 않습니다."
  );
}

4단계: 소스 커밋 저장

배포할 소스를 특정 Git 커밋으로 확정합니다.

5단계: 불변 버전 생성

해당 커밋과 소스 아카이브를 Sites의 저장된 버전으로 만듭니다.

6단계: 운영 배포

저장된 버전을 관리형 Worker 환경에 배포합니다.

7단계: 배포 상태 확인

배포 상태가 성공인지 실패인지 확인합니다.

pending
→ building
→ publishing
→ succeeded 또는 failed

8단계: 운영 URL 연결

성공한 운영 배포본을 사이트의 현재 공개 URL과 연결합니다.

22. 소스 저장과 배포는 왜 분리되어 있을까?

소스 버전과 운영 배포를 분리하면 같은 소스를 다시 배포하거나 이전 버전으로 돌아갈 수 있습니다.

예를 들어 버전 3에서 문제가 발생하면 이전에 저장된 버전 2를 다시 운영에 배포하는 구조를 만들 수 있습니다.

소스만 저장됐다고 외부에 공개되는 것도 아니고, 로컬 코드가 수정됐다고 운영 사이트가 즉시 바뀌는 것도 아닙니다.

운영 사이트가 바뀌려면 수정된 소스를 새 버전으로 저장하고 그 버전을 배포해야 합니다.

23. Sites와 일반 VPS는 무엇이 다를까?

가장 큰 차이는 서버 프로세스의 유지 방식입니다.

구분ChatGPT Sites일반 VPS

실행 방식 요청 기반 Worker 상시 실행 프로세스
서버 관리 관리형 사용자가 직접 관리
포트 개방 일반적으로 불필요 직접 설정
Nginx 설정 일반적으로 불필요 직접 구성
SSL 관리형 URL에 연결 직접 또는 인증서 자동화
정적 파일 Assets로 배포 디스크·Nginx 사용
API Worker 요청 처리 Node·Python 서버
데이터베이스 D1 등 바인딩 PostgreSQL·MySQL 직접 운영
파일 저장 R2 로컬 디스크·S3
장기 실행 데몬 부적합 적합
Telegram 폴링 부적합 적합
Telegram Webhook 적합 적합
OpenClaw Gateway 부적합 적합
일반 TCP 서버 부적합 적합

Sites는 웹 요청을 받아 짧게 처리하고 응답하는 서비스에 적합합니다.

반면 VPS는 프로세스를 계속 실행해야 하는 프로그램에 적합합니다.

24. 왜 Work VM에서는 Telegram 봇이 멈췄는데 Sites 웹사이트는 계속 열릴까?

앞서 Work VM에서 Hermes와 OpenClaw를 실행해 Telegram 봇을 연결했지만, 장기 실행 중 다음 오류가 확인됐습니다.

Network access to
https://api.telegram.org:443
was blocked by policy

Hermes나 OpenClaw의 프로그램 문제가 아니라 Work VM의 장기 실행 프로세스와 외부 네트워크 정책 때문이었습니다.

Telegram 폴링 봇은 다음 구조입니다.

이 프로그램은 다음 조건을 만족해야 합니다.

  • 프로세스가 계속 살아 있어야 함
  • Telegram 서버에 반복 접속해야 함
  • 네트워크 연결이 유지돼야 함
  • 메모리와 세션을 계속 유지해야 함

반면 Sites는 요청 기반입니다.

Worker가 24시간 하나의 프로세스로 실행되는 것이 아니라, 요청이 들어왔을 때 실행될 수 있는 코드로 배포됩니다.

그래서 Work VM이 없어도 운영 사이트가 계속 응답할 수 있습니다.

25. Telegram을 Sites와 연결하는 방법은 없을까?

OpenClaw 전체 Gateway를 Sites에 실행하는 방식은 적합하지 않습니다. 하지만 Telegram Webhook 방식의 경량 챗봇은 만들 수 있습니다.

폴링 방식

봇이 Telegram 서버에 계속 질문합니다.

새 메시지 있습니까?
새 메시지 있습니까?
새 메시지 있습니까?

장기 실행 프로세스가 필요합니다.

Webhook 방식

Telegram이 새 메시지가 생겼을 때 Sites API로 알려 줍니다.

Telegram
→ POST /api/telegram/webhook
→ Sites Worker

전체 구조는 다음과 같습니다.

이 방식은 Worker가 계속 실행될 필요가 없습니다.

Telegram이 메시지를 전달할 때만 Worker가 실행됩니다.

26. Telegram Webhook 백엔드는 어떻게 구성할까?

개념적인 API 경로는 다음과 같습니다.

POST /api/telegram/webhook

처리 순서는 다음과 같습니다.

  1. Telegram이 메시지 업데이트를 전송
  2. 요청이 Telegram에서 온 것인지 검증
  3. 메시지를 보낸 사용자 ID 확인
  4. 허용된 사용자만 처리
  5. 메시지 내용 추출
  6. DeepSeek API 호출
  7. 답변 내용 정리
  8. Telegram sendMessage API 호출
  9. Telegram에 HTTP 200 응답

간단한 코드 구조는 다음과 같습니다.

export async function POST(request: Request) {
  const update = await request.json();

  const message = update.message;
  if (!message?.text) {
    return Response.json({ ok: true });
  }

  const answer = await askDeepSeek(message.text);

  await sendTelegramMessage(
    message.chat.id,
    answer,
  );

  return Response.json({ ok: true });
}

DeepSeek 호출 함수는 다음과 같이 분리할 수 있습니다.

async function askDeepSeek(message: string) {
  const response = await fetch(
    "https://api.deepseek.com/chat/completions",
    {
      method: "POST",
      headers: {
        Authorization:
          `Bearer ${process.env.DEEPSEEK_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        model: "deepseek-v4-flash",
        messages: [
          {
            role: "system",
            content:
              "질문에 자연스러운 한국어로 답하세요.",
          },
          {
            role: "user",
            content: message,
          },
        ],
      }),
    },
  );

  const result = await response.json();
  return result.choices[0].message.content;
}

Telegram 발송 함수는 다음과 같습니다.

async function sendTelegramMessage(
  chatId: number,
  text: string,
) {
  await fetch(
    `https://api.telegram.org/bot${
      process.env.TELEGRAM_BOT_TOKEN
    }/sendMessage`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        chat_id: chatId,
        text,
      }),
    },
  );
}

비밀값은 Sites 운영 환경변수에 저장합니다.

DEEPSEEK_API_KEY
TELEGRAM_BOT_TOKEN
TELEGRAM_WEBHOOK_SECRET
ALLOWED_TELEGRAM_USER_ID

27. Sites에서 OpenClaw 전체를 실행하기 어려운 이유

OpenClaw는 단순한 API 함수가 아닙니다.

OpenClaw Gateway는 다음과 같은 상태를 계속 유지합니다.

  • Telegram·Discord 등 채널 연결
  • 세션
  • 대화 기록
  • 작업 큐
  • 도구 실행
  • 파일 접근
  • 장기 실행 작업
  • 백그라운드 이벤트
  • 주기적 작업
  • Gateway WebSocket

이런 프로그램은 일반적으로 다음 환경이 적합합니다.

  • AWS Lightsail
  • 일반 VPS
  • EC2
  • Docker 서버
  • Railway의 장기 실행 서비스
  • Fly.io VM
  • 집 PC
  • Mac mini
  • NAS

Sites의 Worker는 HTTP 요청을 받아 처리하는 백엔드에는 적합하지만, OpenClaw 전체 Gateway를 계속 실행하는 서버를 대체하는 용도는 아닙니다.

다만 OpenClaw의 일부 기능을 API 형태로 분리하면 Sites와 조합할 수 있습니다.

Sites
→ 사용자 화면과 Webhook

외부 VPS
→ OpenClaw Gateway

Sites와 VPS
→ HTTPS API로 연결

28. Worker 백엔드의 상태는 어디에 저장할까?

Worker 코드의 전역 변수나 메모리에 중요한 상태를 계속 보관하면 안 됩니다.

예를 들어 다음 구조는 신뢰하기 어렵습니다.

let userPoints = 0;

요청마다 실행 인스턴스가 달라지거나 재시작될 수 있기 때문입니다.

상태는 용도에 맞는 저장소에 넣어야 합니다.

데이터 유형적합한 저장소

회원·게시물·포인트 D1
이미지·PDF·동영상 R2
간단한 설정·캐시 KV
실시간 상태·동시성 Durable Objects
비밀 API 키 운영 환경변수
정적 사이트 이미지 프로젝트의 public/

WMU 사이트는 현재 실제 운영 데이터를 저장하지 않으므로 별도 저장소를 사용하지 않습니다.

29. 서버 렌더링은 무엇이며 왜 필요할까?

서버 렌더링은 브라우저에서 모든 화면을 만든 뒤 보여 주는 대신, 서버가 먼저 HTML을 만들어 반환하는 방식입니다.

서버 렌더링은 다음 상황에 유용합니다.

  • 로그인 사용자별 화면
  • 데이터베이스를 조회한 페이지
  • 검색엔진이 읽어야 하는 콘텐츠
  • 첫 화면을 빠르게 제공해야 하는 경우
  • API 키를 브라우저에 노출하지 않아야 하는 경우
  • 서버에서 권한을 검사해야 하는 경우

Vinext는 Next.js의 App Router와 React Server Components를 Worker 환경에서 실행할 수 있도록 연결합니다. Cloudflare Vinext 공식 저장소

30. 정적 사이트라면 Worker를 빼도 되지 않을까?

기술적으로 완전한 정적 사이트라면 HTML, CSS, JavaScript, 이미지만 배포하는 구조도 가능합니다.

하지만 Sites의 표준 프로젝트는 다음 이유로 Worker 형식을 기본으로 사용하는 것으로 보입니다.

  1. 정적 사이트와 동적 사이트를 같은 배포 규격으로 관리할 수 있음
  2. 나중에 API를 추가하기 쉬움
  3. 서버 렌더링 지원
  4. ChatGPT 인증 연결
  5. 이미지 최적화
  6. D1·R2 바인딩
  7. Next.js Route Handler 지원
  8. 공개·비공개 접근 정책 적용
  9. 동적 오류 페이지와 라우팅
  10. 외부 API 호출

즉, 지금은 정적인 랜딩 페이지라도 나중에 회원, 게시판, AI 챗봇, 문의 저장 기능을 붙일 수 있는 기반을 갖고 있습니다.

31. 현재 WMU 사이트는 정적 사이트인가, 동적 사이트인가?

정확히는 정적 콘텐츠 중심의 Worker 애플리케이션입니다.

콘텐츠 자체는 대부분 코드에 고정되어 있습니다.

const pillars = [
  {
    title: "배움이 가능성이 되는 곳",
    body: "AI 리터러시부터...",
  },
];

데이터베이스나 외부 API는 사용하지 않습니다.

하지만 다음 동적 기능은 브라우저 React 상태로 작동합니다.

  • 모바일 메뉴 열기
  • 핵심 서비스 탭 전환
  • 스토리 모달 열기와 닫기
  • 스크롤 이동
  • 반응형 레이아웃

배포 형식은 Worker이기 때문에 앞으로 서버 기능을 추가할 수 있습니다.

따라서 다음처럼 구분하는 것이 정확합니다.

콘텐츠 성격
→ 대부분 정적

브라우저 UI
→ 일부 동적

배포 방식
→ Worker 애플리케이션

현재 백엔드 데이터
→ 없음

백엔드 확장 가능성
→ 있음

32. 이미지 파일은 어디에 있고 어떻게 제공될까?

WMU 사이트의 메인 이미지는 다음 파일입니다.

public/hero-women-network.png

CSS에서는 다음처럼 참조합니다.

.hero-art {
  background-image:
    url("/hero-women-network.png");
}

빌드할 때 이 파일은 정적 Assets에 포함됩니다.

외부 사용자가 이미지를 요청하면 Sites의 배포 환경에서 해당 정적 자산을 반환합니다.

Next.js 이미지 최적화 경로를 사용하는 경우 Worker는 원본 이미지를 Assets에서 읽고 이미지 처리 기능을 거쳐 반환할 수도 있습니다.

현재 Worker 코드에는 다음 환경 바인딩이 정의돼 있습니다.

interface Env {
  ASSETS: Fetcher;
  DB: D1Database;
  IMAGES: {
    input(stream: ReadableStream): unknown;
  };
}

여기서 역할은 다음과 같습니다.

바인딩역할

ASSETS 정적 이미지·CSS·JS 파일 접근
DB D1 데이터베이스 접근
IMAGES 이미지 크기·포맷 최적화

현재 사이트에서 DB를 실제로 사용하는 것은 아니지만 표준 Worker 템플릿에는 연결 형태가 준비되어 있습니다.

33. Sites는 Cloudflare Pages와 같은 것일까?

완전히 같다고 단정할 수는 없습니다.

확인된 프로젝트는 다음 Cloudflare 기술을 사용합니다.

  • Cloudflare Vite Plugin
  • Wrangler
  • Worker fetch() 진입점
  • Static Assets 바인딩
  • 이미지 처리 바인딩
  • 선택적 D1
  • 선택적 R2
  • nodejs_compat 호환 플래그

따라서 Cloudflare Workers 호환 배포 구조인 것은 확인할 수 있습니다.

그러나 사용자의 개인 Cloudflare 계정에 직접 Worker가 생성됐다고 확인되지는 않았습니다. Sites가 자체적으로 관리하는 Cloudflare 기반 인프라에 배포하는 구조로 보는 것이 적절합니다.

사용자는 일반적으로 다음 작업을 직접 하지 않습니다.

  • Cloudflare 계정 연결
  • Wrangler 로그인
  • Worker 이름 생성
  • DNS 레코드 설정
  • TLS 인증서 설정
  • Assets 버킷 설정
  • D1 리소스 ID 직접 관리

이 부분을 Sites 서비스가 대신 관리합니다.

34. 배포한 사이트는 Work VM이 꺼져도 계속 동작할까?

확인된 WMU 사례에서는 로컬 작업공간이 없어졌는데도 Sites의 운영 URL과 원격 버전이 유지됐습니다.

따라서 이미 성공적으로 배포된 사이트의 운영은 Work VM 프로세스에 의존하지 않습니다.

다만 다음은 구분해야 합니다.

계속 동작하는 것

  • 이미 배포된 사이트
  • 정적 이미지와 CSS
  • Worker 페이지 응답
  • 배포된 API 경로
  • 연결된 D1·R2
  • 운영 환경변수
  • 공개 URL

Work VM이 다시 필요한 것

  • 소스 수정
  • 새 이미지 생성
  • 기능 추가
  • 디자인 변경
  • 새 버전 빌드
  • 새 배포 생성
  • 로컬 미리보기

사이트 수정이 필요하면 원격 저장 버전에서 소스를 다시 복원한 뒤 변경하고 새 버전을 배포할 수 있습니다.

35. Sites로 만들기 적합한 서비스

Sites는 다음과 같은 프로젝트에 잘 맞습니다.

콘텐츠와 소개 사이트

  • 회사 홈페이지
  • 브랜드 사이트
  • 행사 안내
  • 포트폴리오
  • 투자 소개
  • 제품 랜딩 페이지

데이터 기반 웹앱

  • 대시보드
  • 관리자 화면
  • 교육 플랫폼
  • 퀴즈 서비스
  • 게시판
  • 신청·접수 시스템
  • 포인트 관리

AI 기능이 포함된 사이트

  • AI 상담
  • 번역
  • 문서 요약
  • 콘텐츠 생성
  • 문제 생성
  • 학습 피드백
  • 이미지 분석 결과 표시

Webhook 기반 연동

  • Telegram 챗봇
  • 결제 결과 수신
  • GitHub 이벤트
  • 외부 서비스 알림
  • 폼 접수 후 이메일 전송

36. Sites에 적합하지 않은 서비스

다음 기능은 일반 VPS나 전용 백엔드가 더 적합합니다.

  • OpenClaw Gateway 전체 실행
  • Telegram 무한 폴링
  • 임의 포트의 TCP 서버
  • SSH 서버
  • 장기간 실행되는 Python 프로세스
  • 시스템 패키지를 계속 사용하는 데몬
  • 서버 로컬 디스크에 의존하는 프로그램
  • 장기 GPU 작업
  • 지속적인 WebSocket 서버 상태
  • Docker Compose 전체 스택

Cloudflare Workers 플랫폼 자체에는 Queues, Workflows, Durable Objects, Cron 같은 다양한 기능이 있지만, ChatGPT Sites가 그 기능을 모두 직접 노출한다고 확인된 것은 아닙니다. Sites에서 제공되는 실제 기능 범위 안에서 설계해야 합니다.

37. Sites를 이해하기 위한 가장 쉬운 비유

Sites를 식당으로 비유하면 다음과 같습니다.

Work VM은 주방 테스트 공간

  • 메뉴를 개발함
  • 재료를 준비함
  • 맛을 확인함
  • 접시 구성을 수정함

저장된 사이트 버전은 확정된 레시피

  • 특정 시점의 레시피를 보관함
  • 이전 레시피로 돌아갈 수 있음
  • 누가 무엇을 배포했는지 기준이 됨

Worker는 주문 처리 직원

  • 주문이 들어올 때 실행됨
  • 요청을 해석함
  • 정적 파일이나 서버 결과를 반환함
  • 필요한 경우 데이터베이스와 외부 API를 호출함

Assets는 미리 준비된 음식과 재료

  • CSS
  • JavaScript
  • 이미지
  • 폰트
  • 정적 HTML

D1은 주문·회원 장부

  • 회원
  • 게시물
  • 포인트
  • 신청 내역

R2는 창고

  • 이미지
  • PDF
  • 영상
  • 업로드 파일

chatgpt.site는 식당 주소

  • 외부 사용자가 찾아오는 공개 주소
  • 현재 운영 버전과 연결됨

38. 전체 구조를 한 장으로 정리하면

39. 자주 묻는 질문

ChatGPT가 만든 사이트는 VM 안에서 계속 실행되나요?

아닙니다. VM은 사이트를 만들고 빌드하는 작업환경입니다. 성공적으로 배포된 운영 사이트는 별도의 Sites 운영 환경에서 제공됩니다.

VM 폴더가 삭제되면 사이트도 없어지나요?

이번 WMU 사례에서는 로컬 폴더가 없어져도 원격 소스 버전과 운영 URL이 유지됐습니다. 원격 버전에서 체크아웃을 다시 복원할 수 있었습니다.

Sites는 정적 사이트만 만들 수 있나요?

아닙니다. 정적 자산과 Worker 서버 코드가 함께 배포될 수 있어 API, 서버 렌더링, 인증, 데이터베이스와 외부 API 호출을 구현할 수 있습니다.

Worker는 일반 Node.js 서버인가요?

아닙니다. 계속 실행되는 Node.js 프로세스가 아니라 HTTP 요청을 fetch() 핸들러로 처리하는 서버리스 런타임입니다.

백엔드 API를 만들 수 있나요?

가능합니다. Next.js Route Handler 또는 Worker 코드를 이용해 REST API와 Webhook을 만들 수 있습니다.

데이터베이스도 가능한가요?

Sites에서 D1 바인딩을 연결할 수 있는 구조가 확인됐습니다. 현재 WMU 사이트는 데이터베이스를 사용하지 않습니다.

이미지 업로드도 가능한가요?

R2 저장소를 연결하면 구현할 수 있는 구조입니다. 현재 WMU 사이트는 프로젝트에 포함된 정적 이미지만 사용합니다.

DeepSeek API를 연결할 수 있나요?

Worker의 fetch()로 외부 API를 호출하고, API 키를 Sites의 비밀 환경변수에 저장하는 구조로 구현할 수 있습니다.

Telegram 봇도 만들 수 있나요?

Webhook 방식의 Telegram 봇은 적합합니다. 반면 계속 실행되는 폴링 방식이나 OpenClaw 전체 Gateway는 Sites보다 VPS가 적합합니다.

Sites에 OpenClaw를 설치할 수 있나요?

OpenClaw의 전체 Gateway는 장기 실행 프로세스와 지속적인 채널 연결이 필요하므로 Worker 실행 모델과 맞지 않습니다. 일부 기능을 API 또는 Webhook으로 분리하는 방식은 가능합니다.

사용자의 Cloudflare 대시보드에서 Worker를 볼 수 있나요?

확인할 수 없습니다. 현재 프로젝트는 Cloudflare Worker 호환 기술을 사용하지만, 사용자의 개인 Cloudflare 계정에 직접 배포됐다는 정보는 확인되지 않았습니다. Sites가 관리하는 인프라에 배포되는 구조로 이해하는 것이 적절합니다.

40. 결론: Sites는 ‘코드 생성기’보다 ‘관리형 웹 배포 시스템’에 가깝다

ChatGPT Sites의 핵심은 예쁜 웹페이지 코드를 생성하는 데서 끝나지 않습니다.

사이트가 외부에서 실제로 작동하려면 다음 과정이 모두 필요합니다.

기획
→ 디자인
→ React·Next.js 구현
→ Vinext·Vite 빌드
→ Worker 산출물 생성
→ 정적 Assets 패키징
→ 산출물 검증
→ 소스 버전 저장
→ 운영 배포
→ 공개 URL 연결
→ 접근 정책 적용

Sites는 이 과정을 하나의 작업 흐름으로 묶습니다.

Work VM은 사이트를 만드는 공간이고, Vinext는 Next.js를 Vite·Worker 환경에 연결하며, Worker는 외부 요청을 처리합니다. 정적 파일은 Assets로 제공되고, 필요한 경우 D1·R2·환경변수·인증·외부 API를 연결할 수 있습니다.

따라서 Sites는 단순한 정적 홈페이지 제작 도구라기보다 다음에 더 가깝습니다.

React와 Next.js로 만든 프런트엔드와 Worker 백엔드를 빌드하고, 버전으로 저장하고, 관리형 주소와 권한을 붙여 외부에 배포하는 ChatGPT 내장형 풀스택 호스팅 시스템

다만 모든 서버 프로그램을 Sites에서 실행할 수 있는 것은 아닙니다. 웹 요청에 따라 실행되는 API와 Webhook에는 적합하지만, OpenClaw Gateway처럼 계속 살아 있어야 하는 프로그램은 VPS나 장기 실행 컨테이너가 필요합니다.

웹사이트, AI 상담, 교육 플랫폼, 신청 시스템, 관리자 페이지, Telegram Webhook처럼 요청 중심으로 동작하는 서비스라면 Sites의 구조를 활용할 수 있습니다. 반대로 지속적인 프로세스와 자유로운 서버 제어가 핵심이라면 일반 클라우드 서버를 선택해야 합니다.

반응형

'AI > 추천 오픈소스' 카테고리의 다른 글

AI가 ‘도구’가 아니라 ‘팀원’이 되는 회사 (Buzz)  (0) 2026.07.22
파라미터 대신 ‘작업의 지평선’을 확장한 AI 모델 Agents-A1  (0) 2026.07.21
범용 AI 프로젝트 하네스 설계 방법론  (0) 2026.07.20
pm-skills 분석  (1) 2026.07.20
로컬에서 AI로 전용 Gemma를 파인튜닝해보자 (Gemma Trainer)  (0) 2026.07.18
'AI/추천 오픈소스' Related Articles more