챗GPT Sites 공개 베타, 사이트는 되고 결제는 금지
챗GPT에 “우리 동아리 일정을 보여 주는 사이트 만들어 줘”라고 말했는데, 잠시 뒤 누구나 열어 볼 수 있는 진짜 주소가 생긴다면 어떨까. 그 사이트에 쌓인 데이터는 어디에 저장되고, 누가 볼 수 있고, 돈은 얼마나 나갈까. 오픈AI가 챗GPT Sites(사이트) 를 공개 베타로 내놓은 뒤 이런 질문이 한꺼번에 쏟아졌다. 해커뉴스에서는 10월 3일 아침 기준 173점에 댓글 200개가 달렸다.
이 글은 세 부류를 위해 썼다. 코딩은 잘 모르지만 내 사이트를 하나 갖고 싶은 사람, 이미 코딩 에이전트로 만든 프로젝트를 어디에 올릴지 고민하는 개발자, 그리고 “챗GPT가 사이트까지 만들어 준다”는 말이 어디까지 사실인지 궁금한 사람이다. 어려운 용어는 처음 나올 때 풀어 쓴다.
근거는 오픈AI가 공개한 공식 문서다. Sites 사용 문서와 요금 문서를 직접 읽고 정리했다. 챗GPT Sites의 공식 소개 페이지(chatgpt.com)는 접속이 막혀 있어서 열어 보지 못했고, 그 내용을 옮긴 한국어 요약 기사로는 숫자나 조건을 확인하지 않았다. 그리고 이 글은 문서를 읽고 정리한 것이지, 직접 사이트를 올려 본 후기가 아니다. 그 점을 글 내내 구분한다.
챗GPT Sites는 뭘 해 주는 기능인가
공식 문서의 첫 설명을 풀면 이렇다. 챗GPT가 웹사이트·웹 앱·게임을 만들고, 호스팅하고, 고치고, 공유까지 해 주는 기능이다. 호스팅이란 만든 사이트를 인터넷에 올려 두고 주소로 열리게 해 주는 일을 말한다. 보통은 서버를 빌리고 도메인을 사고 배포 설정을 해야 하는데, Sites는 그 과정을 별도 배포 도구 없이 챗GPT 안에서 끝내 준다는 게 문서의 설명이다.
시작하는 방법은 두 가지다.
- 프롬프트에 “website(웹사이트)“라는 단어를 넣는다.
@Sites를 멘션해서 Sites 흐름을 직접 부른다.
공식 문서가 안내하는 흐름은 네 단계다.
- 사이트를 설명한다. 누가 쓰는지, 목적이 뭔지, 어떤 동작이 필요한지, 어떤 정보를 써야 하는지 말한다.
- 결과를 검토한다. 만들어진 내용과 동작을 보고, 의도한 정보를 쓰는지, 데이터를 예상대로 다루는지 확인한다.
- 고친다. 바꾸고 싶은 걸 말한다. 스크린샷이나 파일을 붙여 맥락을 줄 수 있다.
- 관리하고 공유한다. Sites 화면으로 돌아와 다시 열고 고치고, 준비가 되면 누가 방문할 수 있는지 정한 뒤 링크를 나눈다.
문서가 든 프롬프트 예시도 눈여겨볼 만하다. 하나는 “운영팀이 요청을 올리고, 담당자를 보고, 상태를 바꾸고, 목록을 걸러 볼 수 있는 프로젝트 요청 대시보드를 만들어 줘. 워크스페이스 계정으로 로그인하게 하고 요청 데이터는 방문 사이에 저장해 줘”다. 또 하나는 이미 있는 프로젝트를 두고 “이 프로젝트를 Sites로 배포해 줘. 호환되는지 확인하고, 필요한 수정을 하고, 배포 주소를 알려 줘”라고 시키는 방식이다. 세 번째는 게임에 점수와 아바타 업로드를 붙이면서 “방문 사이에 점수와 아바타를 유지해 줘”라고 요청하는 예다.
어디서 쓰는지도 갈린다. 챗GPT 데스크톱 앱과 웹(더 보기 > Sites 또는 chatgpt.com/sites)에서는 Sites를 만들고 관리하는 화면이 있다. 반면 코덱스 CLI와 IDE 확장에는 Sites 전용 관리 화면이 없다. 문서는 그 두 곳을 “로컬 프로젝트를 고치고 시험하는 용도”로만 쓰라고 안내한다.
쓸 수 있는 사람은 챗GPT Plus·Pro·Business·Enterprise·Edu 요금제다. 무료 요금제는 목록에 없다. 이 기능은 공개 베타이고, 요금제·지역·워크스페이스 설정에 따라 쓸 수 있는 범위가 다르다.
게시하는 순간 그 주소가 곧 실서비스다
초심자가 제일 먼저 알아야 할 문장이 문서 앞쪽에 있다. “Sites의 모든 배포 주소는 프로덕션 배포다.” 프로덕션이란 연습장이 아니라 실제 방문자가 쓰는 진짜 환경을 뜻한다. 말로 시켜서 만든 사이트라도, 배포하는 순간 그 주소는 연습용 시안이 아니라 진짜 서비스다.
그러면 공개 전에 확인하는 방법은 뭘까. 문서는 “배포하지 말고 버전만 저장해 달라”고 챗GPT에게 시키라고 안내한다. 데스크톱 앱이나 코덱스 환경에서 로컬 프로젝트로 만들 때는 게시가 두 단계로 나뉜다.
| 단계 | 하는 일 | 언제 쓰나 |
|---|---|---|
| 버전 저장 | 배포할 수 있는 빌드를 만든다. 로컬 프로젝트면 그 빌드에 쓴 Git 커밋과 이어 둔다 | 검토할 후보를 만들 때 |
| 버전 배포 | 저장한 버전을 게시하고, 성공하면 실서비스 주소를 알려 준다 | 지정한 대상이 열어 봐도 될 때만 |
저장해 둔 버전 목록을 보여 달라고 하거나, 이전 배포 후보가 뭐였는지 물어볼 수도 있다. 웹에서 만든 사이트라면 미리보기 화면에서 Edit를 눌러 “웹사이트 수정 내용을 설명하세요” 칸에 바꿀 점을 적는다. 필요하면 스크린샷이나 파일을 붙인다. 게시한 뒤에도 돌아와서 고치고 업데이트를 다시 게시할 수 있다.
반대 방향도 알아 둘 만하다. 지운 사이트는 되살릴 수 없다. 문서가 안내하는 삭제 절차는 Sites 화면에서 사이트를 찾아 “Delete site”를 누르고, 사이트의 슬러그(주소에 들어가는 이름)를 직접 입력한 뒤 “Permanently delete(영구 삭제)“를 누르는 것이다. 지우지 않고 접근만 막고 싶다면 공유 설정에서 나 혼자 또는 선택한 사람으로 줄이고, 이전 대상이 더는 열지 못하는지 직접 확인하라고 한다.
새 사이트는 처음엔 나와 관리자만 열 수 있다
공개가 기본값이 아니라는 점은 안심이 된다. 문서에 따르면 새 사이트는 처음에 소유자와 워크스페이스 관리자만 열 수 있다. 워크스페이스는 회사나 팀 단위의 챗GPT 계정 묶음이다. 문서는 내용·데이터 처리·예상 독자를 검토하는 동안 접근을 좁게 유지하라고 권한다.
요금제와 워크스페이스 설정에 따라 고를 수 있는 공유 범위는 다섯 가지다.
- 소유자와 워크스페이스 관리자만
- 선택한 활성 사용자나 그룹(지원되는 경우)
- 초대한 외부 열람자(외부 초대가 열려 있는 경우)
- 워크스페이스 전원(지원되는 경우)
- 인터넷의 누구나(공개 게시가 켜져 있을 때만)
Enterprise 워크스페이스에서는 공개 게시가 기본으로 꺼져 있고, 관리자가 켜야 한다. 외부 초대를 허용하는 권한도 공개 게시 권한과 따로 관리된다. Business 워크스페이스에는 외부 초대용 별도 스위치가 없고, Sites가 켜져 있고 그 기능이 계정에 열려 있어야 한다.
회사 밖 사람에게 보여 주고 싶지만 인터넷에 풀고 싶지는 않다면 외부 초대를 쓴다. 이 기능은 Plus·Pro·Business·Enterprise 사용자에게 순차적으로 풀리는 중이라고 문서가 밝혔다. 절차는 이렇다.
- 내가 소유한 사이트에서 Share를 누른다.
- 접근 대상을 Only those invited(초대받은 사람만) 로 둔다.
- 열람자의 이메일을 입력하고 대상을 고른다.
- 열람자 권한(Viewer)을 확인하고 Invite를 누른다.
- 저장된 접근 목록에 그 사람이 있는지 확인하고, 초대받은 그 계정으로 로그인해 열라고 알려 준다.
외부 열람자는 사이트를 열어 쓸 수 있지만 워크스페이스 멤버도 편집자도 아니라서 고치거나 게시하지 못한다. 한 사람의 초대를 지워도 공개·워크스페이스 전원·그룹 공유로 이미 열려 있는 접근은 그대로 남는다. 접근을 막으려면 남은 공유 설정도 같이 살펴야 한다. 또 사이트의 공유 범위와, 사이트 안에 직접 넣은 로그인 기능은 서로 다른 설정이다. 공개 사이트는 챗GPT 워크스페이스 접근 없이도 열린다.
챗GPT Sites에서 데이터를 저장하려면 D1과 R2를 고른다
사이트가 방문자의 점수나 신청서, 올린 사진을 기억해야 한다면 저장소가 필요하다. 문서는 챗GPT에게 무엇을 저장해야 하는지 말해 줘야 알맞은 사이트 형태를 고를 수 있다고 안내한다. 대응표는 이렇다.
| 필요한 것 | Sites에 요청할 것 |
|---|---|
| 글 위주의 사이트·랜딩 페이지 | 지속되는 앱 상태가 필요하지 않다면 상태 없는 사이트 |
| 저장된 기록, 사용자 진행 상황, 게임 점수 | D1, 구조화된 데이터를 오래 저장하는 관계형 데이터베이스 |
| 이미지·문서·오디오·영상 같은 업로드 | R2, 파일을 담는 객체 저장소 |
| 검색할 수 있는 정보가 붙은 업로드 파일 | 정보는 D1에, 파일 내용은 R2에 |
| 현재 워크스페이스 사용자의 신원이 필요한 내부 사이트 | 워크스페이스 인증 신원 |
| 공개 로그인이나 외부 인증 서비스 | 인증이 켜진 사이트 |
D1은 표(행과 열) 형태로 데이터를 저장하는 데이터베이스이고, R2는 사진이나 PDF 같은 파일을 통째로 보관하는 곳이다. 한도는 문서에 숫자로 나와 있다. 사이트마다 D1 저장 용량은 10GB, R2는 고정 한도가 없다고 한다.
문서가 같이 준 조언도 실용적이다. 테마 선택이나 닫은 배너처럼 잠깐 쓰고 마는 상태에는 저장소를 요청하지 마라. 반대로 사람들이 사이트가 기억해 주길 기대하는 제품 데이터에는 요청해야 한다. 저장소를 괜히 붙이면 한도만 잡아먹는다.
로컬 프로젝트를 Sites에 올릴 때는 프로젝트 폴더에 .openai/hosting.json이 생긴다. 호스팅 프로젝트와 로컬 소스를 잇는 파일이다. 문서의 예시는 이렇다.
{
"project_id": "<project-id>",
"d1": "DB",
"r2": null
}이 예는 관계형 데이터베이스는 DB라는 이름으로 쓰고 파일 저장소는 안 쓰는 사이트다. 막 만든 로컬 시작 프로젝트에는 project_id가 없을 수 있고, Sites가 호스팅 프로젝트를 만들면서 채운다.
참고로 문서는 D1·R2가 어느 회사의 제품인지는 적지 않았다. 다만 이 이름은 클라우드플레어의 데이터베이스·저장소 제품 이름과 같다. 그래서 같은 계열일 거라고 짐작할 수는 있지만, 그건 이름이 겹친다는 사실에서 나온 추측이지 문서가 확인해 준 내용이 아니다.
무엇이 안 되는지도 정해져 있다. HTTP, HTTPS, 웹소켓(WebSocket, 서버와 계속 연결해 두고 실시간으로 주고받는 방식)은 지원하고, 날것의 인바운드·아웃바운드 TCP 연결은 지원하지 않는다. 일부 프레임워크, 사설망, 데이터베이스, 백그라운드 서비스, 호스팅 방식도 지원하지 않는다고 하니, 이미 만든 프로젝트라면 올리기 전에 호환되는지 챗GPT에게 먼저 확인시키는 편이 안전하다. 실시간 채팅 같은 것을 만든다면 Cloudflare Durable Objects WebSocket Hibernation 글처럼 웹소켓이 어떻게 요금에 영향을 주는지도 따로 살펴 두면 좋다. 지금 Sites 문서에는 웹소켓 사용량 요금이 따로 적혀 있지 않다.
방문자 로그인과 내 앱 연결은 이렇게 된다
공개 사이트라도 일부 기능은 “누구인지” 알아야 한다. 저장된 진행 상황을 이어서 보여 주거나, 사람마다 다른 화면을 보여 주는 경우다. 문서는 Sign in with ChatGPT(챗GPT로 로그인) 를 선택으로 붙일 수 있다고 안내한다. 사이트는 로그인하지 않은 방문자에게도 계속 열려 있고, 로그인한 사람에게만 개인화된 기능이 열리는 구조다.
붙이는 방법도 프롬프트 한 줄이다. “이 공개 사이트에 챗GPT 로그인을 붙여 줘. 로그인하지 않은 방문자에게도 사이트는 열어 두고, 로그아웃 상태에서는 로그인 버튼을 보여 줘. 로그인하면 전체 이름이 있으면 이름으로, 없으면 이메일로 인사해 주고, 권한 판단은 서버 코드에 둬.” 이 방식이 돌아가는 원리는 이렇다.
- 로그인과 로그아웃 경로는 플랫폼이 제공한다. 사이트에서는
/signin-with-chatgpt와/signout-with-chatgpt링크를 걸면 된다. - 방문자가 로그인하면 서버로 가는 요청 헤더에 신원이 실려 온다. 이메일은
oai-authenticated-user-email, 이름은oai-authenticated-user-full-name에 담기고, 이름은 비어 있을 수 있으니 없으면 이메일로 대신하라는 주의가 붙어 있다. - 권한 판단은 서버 코드에서 하라고 문서가 강조한다. 화면에서만 가리면 우회된다.
직접 인증 서비스를 붙이고 싶다면 방법이 다르다. 문서의 대응표대로 “공개 로그인이나 외부 인증 서비스가 필요하면 인증이 켜진 사이트”를 요청하게 된다. 외부 인증 쪽 비용 구조가 궁금하다면 Auth0·Clerk 없이 패스키로 인증 비용을 줄이는 방법과 비교해 볼 만하다.
두 번째로 눈에 띄는 기능은 플러그인 연결이다. 사이트를 보는 사람이 자기가 연결한 앱의 데이터를 사이트에 불러오는 방식이다. 문서의 예는 이슈 대시보드다. 내가 보면 내게 배정된 이슈가, 동료가 보면 동료에게 배정된 이슈가 뜬다. 방문자는 챗GPT로 로그인하고, 어떤 연결 계정을 얼마나 허용할지 직접 고른다.
조건이 까다롭다. 이 기능은 기능이 켜진 워크스페이스에서, 그 워크스페이스에만 공개된 사이트에서만 쓸 수 있다. 사이트를 공유했다고 해서 제작자의 연결 계정 접근권이 같이 넘어가지는 않는다. 사이트는 방문자가 허용한 앱의 정보만 받는다. 방문자가 허용하지 않아도 사이트를 계속 쓸 수는 있지만, 그 연결이 필요한 기능은 동작하지 않는다. 앱에 값을 써 넣는 기능은 따로 켜야 하고, 방문자의 동의와 명시적인 행동이 있어야 한다.
한 가지 더, 방문 통계는 기본으로 제공된다. 분석 화면에서 순 방문자 수와 페이지 뷰, 그리고 기간별 변화를 본다. 날짜 범위와 단위는 바꿀 수 있다. 분석용 코드를 따로 붙일 필요가 없다. 다만 Enterprise 워크스페이스가 소유한 사이트에는 아직 제공되지 않는다.
주소와 도메인은 어디까지 바꿀 수 있나
처음 주소는 챗GPT가 정해 준다. 이 주소는 바꿀 수 있고(제공되는 곳에 한해), 문서가 정한 규칙은 이렇다.
- 이름은 5글자 이상이어야 한다.
- 소문자로 시작하고, 소문자·숫자·하이픈 한 개씩만 쓴다.
- 하이픈으로 끝나거나 하이픈이 연달아 올 수는 없다.
주소를 바꿔도 새 배포가 만들어지지는 않는다. 예전 주소는 새 주소로 자동 연결되고, 그 안의 경로와 쿼리도 그대로 따라간다. 이미 링크를 뿌린 뒤에 이름을 바꿔도 깨지지 않는다는 뜻이다.
내 도메인이 있다면 사용자 지정 도메인을 연결할 수 있다. 최상위 도메인(apex)이나 서브도메인 모두 되고, 순서는 사이트 설정에서 Add domain을 누르고, 도메인 이름을 넣고, 챗GPT가 알려 주는 DNS 레코드와 값을 도메인 업체 설정에 옮겨 넣은 뒤, 몇 분 기다려 상태를 새로 고치는 것이다. DNS는 도메인 이름을 서버 주소와 이어 주는 설정이다. 문서는 Sites가 도메인을 대신 사 주지는 않는다고 분명히 했고, DNS 레코드를 직접 바꿀 수 있어야 한다고 했다. Enterprise 워크스페이스에서는 출시 시점에 사용자 지정 도메인이 지원되지 않는다.
사이트가 외부 서비스의 키 같은 비밀 값을 써야 한다면 사이트 설정에서 환경 변수와 비밀 값을 넣는다. 문서의 당부는 프롬프트, 첨부 파일, 사이트 내용에 비밀 값을 넣지 말라는 것이다. 로컬 프로젝트라면 .openai/hosting.json에도 넣지 않는다. 값을 바꾼 뒤에는 챗GPT에게 승인된 저장 버전을 다시 배포해 달라고 해야 다음 배포부터 새 값을 쓴다.
같이 고치는 사람은 데이터도 읽는다
팀으로 쓰면 편집자를 둘 수 있다. 같은 워크스페이스의 활성 멤버를 소유자가 편집자로 초대하는 구조다. 방법은 사이트의 Share에서 멤버를 먼저 방문자로 추가하고, 그다음 Can view를 Can edit으로 바꾸는 것이다. 편집자의 Sites 화면에는 “Shared with you(나와 공유됨)” 항목으로 뜬다.
여기서 문서가 가장 신경 쓴 경고가 나온다. 편집자는 사이트의 실제(라이브) 데이터베이스 데이터를 읽을 수 있다. 그래서 “사이트의 코드와 데이터를 맡겨도 되는 사람만 초대하라”고 한다. 방문자 신청서나 고객 정보가 쌓이는 사이트라면 편집자 권한이 곧 그 정보에 대한 접근권이다.
편집자가 할 수 있는 일과 못 하는 일은 구분되어 있다.
| 편집자가 할 수 있는 것 | 편집자가 할 수 없는 것 |
|---|---|
| 사이트 수정 | 사이트의 공개 대상 변경 |
| 버전 저장 | 다른 사람 초대·삭제 |
| 소유자가 첫 게시를 한 뒤 업데이트 게시 | 설정·분석 관리 |
| 이전 버전으로 복원 | |
| 소유권 이전 | |
| 첫 게시 (소유자만 가능) |
외부 열람자는 편집할 수 없고, 편집자 접근은 방문자 접근과 별개다. 방문자를 편집자로 올려도 사이트의 공개 대상 설정은 바뀌지 않는다.
못 하는 것: 결제, 건강 정보, 어린이 대상
챗GPT Sites에서 하면 안 되는 일도 문서에 한 문단으로 정리돼 있다. 아래는 문서가 쓰지 말라고 한 용도다.
- 보호 대상 건강 정보(Protected Health Information)나 결제 카드 데이터를 처리하는 일
- 13세 미만(또는 해당 지역의 디지털 동의 연령 미만)을 대상으로 하는 일
- 금융 거래를 가능하게 하는 일
- 악성코드 배포, 피싱, 사람이나 조직 사칭, 그 밖의 오픈AI 정책 위반
이 목록을 그대로 읽으면, 결제를 받는 쇼핑몰이나 예약 결제 사이트는 지금 Sites의 대상이 아니다. 어디까지가 “금융 거래를 가능하게 하는” 것인지는 문서가 자세히 풀어 주지 않았다. 후원 링크를 거는 정도도 해당하는지는 문서만으로 알 수 없으니, 결제와 닿는 사이트를 만들려면 도움말 센터에 적힌 최신 정책부터 확인해야 한다. 이 글의 제목에서 “결제는 금지”라고 쓴 것도 문서의 사용 금지 목록을 그대로 줄인 것이다.
그 밖의 한계도 있다. 출시 시점에 데이터 거주지(data residency)와 추론 거주지(inference residency)는 지원하지 않는다. 배포된 사이트, 사이트 코드, D1·R2에 저장된 데이터와 파일, 생성된 산출물, 로그가 전부 해당한다. 국가별로 데이터를 어디에 둬야 하는 규정이 있는 사업이라면 지금은 맞지 않는다는 뜻이다. 개인정보를 모으거나 처리하는 사이트라면 해당 개인정보 보호 법령은 만든 사람이 지켜야 한다. 문서가 사이트를 공유하기 전에 확인하라고 한 목록도 그대로 챙겨 둘 만하다.
- 내용, 생성된 글과 이미지, 링크, 올라온 파일, 양식, 동작 확인
- 기밀 정보·비밀 값·권리 없는 제3자 콘텐츠가 노출되지 않는지
- 공유할 대상의 눈높이로 접근과 로그인 동작을 시험
- 개인 정보를 모으는 기능이 있으면 모으고 공유할지 먼저 판단
- 가장 좁은 공유 범위를 고르고, 공유 후에는 대상이 실제로 열리는지 확인
요금은 따로 없고, 한도는 숫자가 없다
가격 항목 “Sites는 얼마인가?“의 답은 한 문단이다. 공개 베타 동안 해당되는 챗GPT 요금제에 포함돼 있다. 이용 가능 여부는 요금제, 지역, 워크스페이스 설정에 따라 다르다. 따로 얹는 요금은 문서에 없다.
대신 사용 한도가 있다. 사용 문서는 요금제별 한도가 모든 사이트에 걸쳐 적용되고, 챗GPT가 현재 한도를 보여 주며 한도에 가까워지면 알려 준다고 한다. 한도에 닿으면 막히는 것은 세 가지다.
- 새 사이트 만들기
- 저장 공간 추가
- 사용량 많은 사이트를 계속 공개 상태로 두기
반대로 이미 만든 사이트를 고치고 관리하는 일은 한도에 닿아도 계속할 수 있다.
문서에 없는 것도 분명히 적어 둔다. 한도의 구체적인 숫자(월 사이트 수, 방문자 수, 요청 수 같은 것)는 어디에도 적혀 있지 않았다. 공개 베타가 끝난 뒤 요금이 어떻게 되는지도 밝혀지지 않았다. “공개 베타 동안”이라는 단서가 가격 문장 안에 들어 있다는 점은 기억해 둘 만하다. 지금 내가 만든 사이트에 사람이 몰려도 어디서 막힐지, 한도에 닿으면 무엇이 먼저 끊기는지는 직접 써 보기 전에는 알 수 없다.
에이전트가 만든 앱이 늘어나는 신호는 데이터베이스 쪽에서도 나왔다
비슷한 시기에 같은 흐름을 가리키는 소식이 하나 더 있었다. 10월 2일 Supabase가 블로그에서 Turso 인수를 발표했다. Supabase는 이 글에서 AI 에이전트가 프로토타입, 대시보드, 앱을 만드는 데 쓸 데이터베이스를 수백만 개씩 만들고 있고, 자사는 이미 매주 100만 개가 넘는 데이터베이스를 만든다고 밝혔다. Turso는 SQLite를 Rust로 다시 짜서 서버 한 대가 데이터베이스 수백만 개를 필요할 때만 불러와 쓰는 구조를 만든 회사다.
두 소식에 직접 연결 고리가 있다는 증거는 없다. Sites 문서에는 Turso도 Supabase도 나오지 않는다. 그래도 방향은 같다. 사람이 아니라 에이전트가 사이트와 데이터베이스를 만드는 일이 이미 일상 규모가 됐다는 것이다. 그렇다면 만들어진 사이트의 접근 범위, 저장된 데이터, 한도를 사람이 관리하는 일이 더 중요해진다. 에이전트가 일을 크게 벌였을 때 생기는 사고가 궁금하다면 AI에 사업을 맡겼더니 낯선 사람에게 청구서를 보낸 사례도 같이 읽어 볼 만하다.
오늘 해볼 것: 열어 두기 전에 다섯 가지를 정한다
챗GPT Sites는 지금 직접 써 볼 수 있는 사람이라면 가볍게 시험해 볼 만하다. 다만 첫 사이트에서 사고를 줄이는 순서가 있다.
- 첫 사이트는 데이터 없는 걸로 만든다. 계산기나 소개 페이지처럼 저장이 필요 없는 사이트로 시작하면 D1·R2 한도와 개인정보 문제를 피할 수 있다.
- 배포하기 전에 “저장만” 시킨다. 모든 배포 주소가 곧 실서비스다. “버전만 저장하고 배포는 하지 마”라고 말하고 미리보기부터 본다.
- 공유 범위는 가장 좁은 데서 시작한다. 새 사이트는 소유자와 관리자만 열 수 있는 상태다. 친구나 팀에 보여 주려면 초대받은 사람만, 그다음 워크스페이스 전원, 마지막으로 공개 순서로 넓힌다.
- 이미 만든 프로젝트가 있다면 호환부터 묻는다. “이 프로젝트를 Sites로 배포해 줘. 호환되는지 확인하고 필요한 수정을 알려 줘”처럼 요청하면 지원하지 않는 프레임워크나 서비스를 미리 걸러 준다.
- 돈과 건강 정보는 처음부터 넣지 않는다. 결제를 받거나 카드·건강 정보를 다루는 사이트는 문서의 사용 금지 목록과 겹친다.
챗GPT Sites는 아직 공개 베타다. 요금제와 지역에 따라 되는 기능이 다르고, 한도 숫자는 문서에 없다. 한 번에 중요한 서비스를 옮기기보다 연습용 사이트 하나로 접근 설정, 저장, 한도 알림이 실제로 어떻게 동작하는지 눈으로 확인하는 쪽이 맞다.
출처: OpenAI — Sites (ChatGPT 사용자 문서) · OpenAI — ChatGPT 요금 문서 · Supabase 블로그 — Supabase is acquiring Turso