챗GPT Sites에 Database 탭, 공지 없이 붙었다

문서 쪽에서도 같은 시기에 움직임이 있었다. 웹 아카이브에 남은 8월 10일 사본과 지금의 Sites 안내 문서를 나란히 놓고 보면, 사이트에 붙는 저장소 한도를 적은 표가 그 사이에 새로 들어갔다. D1 10GB, R2 고정 한도 없음. 데이터를 다루는 대목을 손보면서도 정작 그 데이터를 보여 주는 탭 이야기는 넣지 않았다.

챗GPT Sites는 어떤 기능인가

Sites는 챗GPT 안에서 웹사이트와 가벼운 앱을 만들어 그대로 호스팅까지 해 주는 기능이다. 6월 2일 코덱스(Codex)를 쓰는 비즈니스·엔터프라이즈 워크스페이스에 프리뷰로 먼저 열렸고, 7월 9일 챗GPT 릴리스 노트에 퍼블릭 베타로 올랐다. 오픈AI는 챗GPT를 떠나지 않고 작업이나 아이디어를 그대로 인터랙티브한 웹사이트로 바꾸는 기능이라고 설명했다. 대시보드, 신청 폼, 사내 트래커, 계산기처럼 규모가 크지 않은 페이지가 주 대상이다.

만들어진 사이트는 사이트이름.사용자이름.chatgpt.site 형태의 주소를 받는다. 가진 도메인이 있으면 DNS 레코드를 고쳐 연결할 수 있지만, 도메인 자체를 Sites가 대신 사거나 등록해 주지는 않는다. 기업용 워크스페이스는 출시 시점 기준으로 맞춤 도메인을 쓸 수 없다.

데이터를 다루는 부분이 이번 이야기의 배경이다. 공식 문서는 사이트에 붙는 저장소를 두 가지로 설명한다. 표 형태로 오래 남길 데이터를 담는 관계형 데이터베이스가 D1이고, 파일 원본을 담는 오브젝트 스토리지가 R2다. D1과 R2는 클라우드플레어(Cloudflare)가 같은 이름으로 파는 데이터베이스·오브젝트 스토리지 제품과 이름이 같다. 오픈AI 문서는 두 이름만 쓰고 어느 회사 것인지는 적지 않는다.

저장소	무엇을 담나	한도
D1	신청자 목록, 상태값, 로그 같은 표 형태 데이터	사이트당 10GB
R2	사진·PDF·영상 같은 파일 원본	고정 한도 없음

두 저장소는 역할이 갈린다. 사진을 올리면 원본 파일은 R2로 가고, D1에는 그 파일이 어디에 있는지(object_key)와 형식·용량·생성 시각이 한 행으로 적힌다. 앞의 1272167이 바로 그 행이다.

Database 탭에서 실제로 보이는 것

화면 제목은 Database, 그 아래 설명은 "View the data used by your live site"(운영 중인 사이트가 쓰는 데이터를 봅니다)다. 왼쪽에 연결 상태와 테이블 목록이 서고, 오른쪽에 고른 테이블의 컬럼과 행이 뜬다.

화면 요소	무엇을 알려 주나
Connected 표시	사이트와 데이터베이스가 붙어 있는지
TABLES 목록	이 사이트에 딸린 테이블 이름 전부
표 영역	컬럼 이름과 실제 행. 컬럼이 많으면 가로로 밀어 본다
Showing 1–6	지금 화면이 몇 번째부터 몇 번째 행인지
← → 버튼	다음·이전 행 묶음으로 이동
Refresh 버튼	지금 이 순간의 데이터를 다시 읽어 온다

확인된 화면에는 테이블이 둘 있었다. 하나는 id·title·owner·status·note·created_at·updated_at 일곱 컬럼에 여섯 행이 들어 있었고, 다른 하나는 id·title·object_key·content_type·size_bytes·created_at 컬럼에 사진 한 장의 메타데이터를 담고 있었다. 행 수가 적어도 표 아래에는 Showing 1–6과 페이지 이동 버튼이 그대로 달려 있다.

읽기만 된다

확인된 화면에는 셀을 고치거나 행을 더하고 지우는 버튼이 없다. 값을 바꾸려면 여전히 챗GPT에게 말해 사이트 코드를 고치거나, 사이트에 만들어 둔 입력 폼으로 데이터를 넣어야 한다. 지금 단계는 데이터베이스를 관리하는 화면이라기보다 살아 있는 데이터를 다시 확인하는 뷰어에 가깝다.

그래도 달라진 게 있다. 그동안 Sites로 폼이나 갤러리를 만들면, 데이터가 실제로 어떤 모양으로 쌓이는지는 화면에 뜬 결과로만 짐작해야 했다. 이제는 테이블과 컬럼을 눈으로 확인한 뒤 다음 요청을 넣을 수 있다.

어떻게 만드나

어디서 시작하나. 웹에서는 Work를 고른다. 데스크톱 앱에서는 ChatGPT를 고른 다음 Work로 들어가거나, Codex를 골라도 된다. 목록 화면 오른쪽 위 Create 버튼으로 새 사이트를 만들고, 이미 만든 사이트는 사이드바 Sites 목록에서 이름을 누르거나 오른쪽 「…」 메뉴에서 Settings를 골라 상세 화면으로 넘어간다. Database 탭은 그 상세 화면 상단에 있다.

단계별로 따라 하기.

앞의 다섯 단계는 헬프센터가 안내하는 순서 그대로다. 뒤의 네 단계는 이번에 붙은 탭까지 확인하는 과정이다.

1. 채팅 창에서 만들고 싶은 웹사이트를 챗GPT에게 설명한다. 프롬프트에 「웹사이트」라는 단어를 넣거나 @Sites를 멘션하면 Sites 작업으로 확실히 들어간다.
2. 쓸 재료를 함께 올린다. 문서가 드는 항목은 콘텐츠·파일·데이터·링크·제약 조건 다섯이다. 로고 파일, 그대로 들어갈 문구, 참고할 페이지 주소, 「모바일 한 화면에 들어와야 한다」 같은 조건을 이 단계에서 한꺼번에 준다. 이걸 건너뛰고 나중에 하나씩 고치면 왕복이 길어진다.
3. 데이터를 쌓아야 한다면 저장할 항목을 나열한다. 「신청자 이름·이메일·신청 시각을 데이터베이스에 저장하는 신청 페이지」처럼 적어 주면 챗GPT가 그에 맞는 테이블을 만들어 사이트에 붙인다.
4. 챗GPT가 만든 미리보기를 검토한다. 이 단계까지는 아직 아무도 볼 수 없다.
5. 공유하거나 게시할 준비가 될 때까지 수정을 요청한다. 문구·색·항목·동작을 말로 고친다.
6. 배포한다. 배포가 끝나면 이름.사용자이름.chatgpt.site 주소가 나온다.
7. 공개 범위를 정한다. 소유자와 관리자만, 지정한 사람이나 그룹, 워크스페이스 전체, 인터넷 전체 네 가지다. 마지막 항목은 기업용 워크스페이스에서는 관리자가 먼저 열어 줘야 쓸 수 있다.
8. 사이트에 실제로 데이터를 넣어 본다. 폼을 채워 제출하거나 사진을 올린다.
9. 사이트 상세 화면에서 Database 탭을 연다. 왼쪽에서 테이블을 고르고, 방금 넣은 값이 행으로 들어왔는지 확인한다. 안 보이면 오른쪽 위 Refresh를 누른다.

누가 쓸 수 있나. 무료와 Go 요금제에서는 쓸 수 없다. 비즈니스와 엔터프라이즈가 6월 2일 코덱스 프리뷰로 먼저 받았고, 7월 9일 퍼블릭 베타에서 Pro·Pro Lite·Edu가 열렸으며 Plus가 며칠 뒤 따라붙었다. 지역은 출시 때 EEA(유럽경제지역)·스위스·영국이 빠져 있었지만, 오픈AI 개발자 계정이 7월 20일 이 지역 플러스·프로 이용자에게도 열었다고 알렸다. 한국은 애초 제외 지역에 들어 있지 않았다.

항목	조건
요금제	무료·Go 제외한 유료 요금제 (퍼블릭 베타)
지역	출시 때 EEA·스위스·영국 제외 → 7월 20일 해당 지역 플러스·프로 개방
진입 경로	챗GPT 웹 Work · 데스크톱 앱 Work 또는 Codex
기업 워크스페이스	관리자가 생성·공개 권한을 따로 준다
방문자 확인	사이트에 챗GPT 계정 로그인을 붙일 수 있다
맞춤 도메인	가진 도메인을 DNS 로 연결, 기업용 워크스페이스는 출시 시점 제외

무엇을 해볼 수 있나. 사내 스터디 신청 페이지를 만들어 두면, 신청이 들어올 때마다 D1 테이블에 행이 쌓이고 Database 탭에서 몇 명이 신청했는지 바로 센다. 팀 사진 아카이브를 만들면 원본은 R2에, 파일 이름과 용량과 올린 시각은 D1에 남아서 어떤 파일이 얼마나 무거운지 표로 확인한다. 사이트에 챗GPT 로그인 기능을 붙이면 방문자의 이메일과 이름이 oai-authenticated-user-email·oai-authenticated-user-full-name 헤더로 넘어오므로, 누가 무엇을 남겼는지까지 테이블에 담아 둘 수 있다.

고치고, 공유하고, 내리는 법

만드는 것보다 자주 하게 되는 일이 고치는 일이다. 헬프센터 문서에 적힌 경로를 그대로 옮기면 이렇다.

고치기. 사이트를 만든 그 대화를 다시 열거나, 사이드바에서 Sites를 눌러 목록에서 해당 사이트를 찾아 편집 아이콘을 누른다. 작성창이 열리면 바꾸고 싶은 것을 말로 적는다 — 문서는 문구·레이아웃·데이터·스타일·링크·양식·인터랙티브 동작을 예로 든다. 바뀐 미리보기를 보고 더 고칠 게 있으면 다시 말한다.

저장과 배포는 다른 단계다. 운영 중인 사이트를 건드리지 않고 변경분만 확인하려면 먼저 버전을 저장하고, 검토가 끝난 뒤에만 배포한다. 이 두 단계를 붙여 생각하면 확인 안 된 화면이 그대로 라이브로 나간다.

공유 범위 바꾸기. 미리보기에서 공유를 누르고 「접근 권한이 있는 사용자」에서 고른다. 소유자와 워크스페이스 관리자 / 선택한 활성 사용자나 그룹 / 워크스페이스의 모든 사용자 / 인터넷상의 모든 사용자, 네 가지다. 기업용 워크스페이스에서 마지막 항목은 관리자가 공개 게시를 켜 둔 뒤에야 뜬다.

도메인 붙이기. 네 단계다.

1. 사이트 설정을 열고 「도메인 추가」를 누른다.
2. 루트 도메인이나 하위 도메인을 입력한다.
3. Sites가 알려 주는 DNS 레코드와 값을 복사해 도메인 제공업체(가비아·후이즈·클라우드플레어 등)에 그대로 추가한다.
4. 몇 분 기다린 뒤 Sites에서 도메인 상태를 새로 고친다.

내리기와 지우기. 사이드바에서 Sites를 열고 사이트 삭제를 누른다. 대화 상자에 사이트 슬러그를 손으로 입력해야 영구 삭제가 활성화된다. 공개만 막고 싶다면 삭제 대신 공유 범위를 소유자·관리자로 되돌리면 된다.

환경 변수와 시크릿. API 키처럼 코드나 프롬프트에 남기면 안 되는 값은 사이트 설정의 Environment variables에서 넣는다. 앞의 설정 화면에 「+ Add variable」과 「Nothing yet」이 보이는 자리가 그곳이다.

이미 만들어 둔 웹사이트를 옮길 수 있나

결론부터 적으면 「기존 사이트 가져오기」 버튼은 없다. 주소를 넣으면 통째로 빨아들이는 마이그레이션 기능도, 깃허브 저장소를 연결하는 항목도 문서에 없다.

대신 두 갈래가 있다. 하나는 코덱스가 다루는 기존 프로젝트를 Sites로 배포하는 길이다. Sites 프로젝트는 로컬 소스와 호스팅을 잇는 연결 정보를 .openai/hosting.json에 저장하고, 배포는 버전 저장과 배포 두 단계로 나뉜다. 공식 문서는 기존 프로젝트라면 배포를 요청하기 전에 그 프로젝트가 호환되는 배포 산출물을 낼 수 있는지 챗GPT에게 먼저 확인하라고 적어 두었다. 이 한 줄이 이 기능의 성격을 말해 준다 — 무엇이든 받아 주는 호스팅이 아니라 특정 형태만 받는 호스팅이다.

다른 하나는 현실적으로 더 자주 쓰게 될 길, 재료를 넘겨 다시 만드는 방식이다. 기존 페이지의 문구·이미지·구조를 붙여 넣거나 화면을 캡처해 주고 같은 것을 만들어 달라고 하면 된다. 도메인은 그대로 옮겨 붙일 수 있으니 방문자 입장에서는 주소가 유지된다.

무엇이 안 되는지는 문서가 뭉뚱그려 적었다. 일부 프레임워크, 사설 네트워크, 데이터베이스, 백그라운드 서비스, 호스팅 방식은 지원되지 않을 수 있다는 문장이 전부다. 실무 기준으로 옮기면 이렇게 갈린다.

이런 사이트	옮길 수 있나
정적인 소개·랜딩 페이지, 포트폴리오	재료를 주고 다시 만드는 쪽이 빠르다
폼·목록·대시보드처럼 데이터가 쌓이는 사내 도구	잘 맞는다. D1·R2가 그 자리를 채운다
워드프레스처럼 PHP·전용 DB·플러그인에 기댄 사이트	그대로는 안 된다. 기능을 골라 다시 만들어야 한다
사내망에서만 열리는 시스템에 붙는 페이지	사설 네트워크 미지원
주기적으로 도는 배치·백그라운드 작업	미지원

발행 전에 점검할 것

문서는 공개 직전 확인 목록도 따로 두었다. 사이트에 기밀 데이터가 들어 있지 않은지, 접근 설정이 의도한 범위와 맞는지, 워크스페이스 정책에 어긋나지 않는지, 그리고 개인정보를 수집하는 요소가 있다면 그것이 적절한지 살피라는 내용이다.

넘지 말아야 할 선도 명시돼 있다. 의료정보와 결제카드 정보는 처리할 수 없고, 13세 미만을 대상으로 하는 사이트도 안 된다. 전자상거래를 붙이려면 결제는 외부 결제 대행사를 써야 한다. 무엇보다 데이터 레지던시와 추론 레지던시를 지원하지 않는다 — 배포된 사이트, 사이트 코드, D1·R2 데이터와 파일 저장, 산출물, 로그가 전부 여기에 해당한다.

에디터의 시선

탭 하나가 늘어난 일을 크게 볼 이유는 이것이 오픈AI가 Sites를 어디로 끌고 가는지 보여 주기 때문이다. 만들고 배포하는 단계까지는 이미 대화로 끝난다. 남은 구멍은 배포한 다음이었다. 사이트가 살아 움직이기 시작하면 데이터가 쌓이는데, 그 데이터를 보려면 챗GPT 밖으로 나가야 했다. 이번 탭은 그 왕복을 없앴다. 순서를 보면 다음에 무엇이 올지도 대체로 읽힌다. 행 편집, 그다음이 내려받기나 SQL 조회다.

알리지 않고 붙였다는 점은 따로 봐야 한다. 오픈AI는 같은 화면의 Analytics 탭은 안내 문서에 경로까지 적어 두었고 개발자 계정으로 공개 테스트 소식까지 알렸다. Database 탭은 그 자리에 없다. 화면이 문서보다 앞서 가면 비용을 치르는 쪽은 이용자다. 사내 교육 자료와 업무 매뉴얼이 실제 화면과 어긋나고, 새 기능이 있는 줄 모르는 사람은 계속 예전 방식으로 일한다. 지금 Sites를 쓰고 있다면 문서를 기다리지 말고 사이트 상세 화면을 한 번 열어 보는 편이 빠르다.

러버블이나 비슷한 도구를 써 본 사람이라면 체감이 갈리는 지점을 알 것이다. 웹사이트를 만들어 주는 도구는 이미 여럿이고 첫 화면을 뽑는 속도는 다들 비슷하다. 갈리는 건 두 번째 주부터다. 신청자가 30명 들어왔을 때 그 목록을 어디서 보는지, 사진이 200장 쌓였을 때 무엇이 용량을 먹는지 확인할 자리가 있는지에서 도구의 수명이 결정된다. 챗GPT Sites는 그 자리를 이제 막 만들었고, 아직 읽기 전용이다.

국내 팀이 지금 해 볼 만한 것과 아직 이른 것은 나눠서 봐야 한다. 사내에서 도는 구글 폼 대체, 행사 신청 페이지, 부서용 트래커처럼 데이터가 수백 행 단위이고 사라져도 큰일이 나지 않는 것부터 옮기는 게 맞다. 반대로 고객 개인정보가 들어가는 서비스는 아직 이르다. 데이터가 어느 나라에 저장되는지 답해야 하는 조직이라면 레지던시 미지원 한 줄에서 걸린다.

읽기 전용으로 먼저 낸 선택도 그 자체로 신호다. 편집 기능을 붙이려면 권한과 이력, 잘못 지운 행을 되돌리는 문제까지 함께 풀어야 한다. 보여 주기만 하는 화면은 그중 어느 것도 필요 없어서 며칠이면 붙는다. 실무에서 가장 자주 필요한 동작이 「값을 고치는 것」이 아니라 「지금 몇 행 들어왔는지 보는 것」이라는 판단도 깔려 있다. 사내 신청 페이지를 운영해 보면 하루에 열어 보는 횟수와 실제로 값을 고치는 횟수의 차이가 크다.

돈과 시간이 새는 자리는 다른 데 있다. Sites로 만든 페이지는 만들기가 쉬워서 계속 늘어난다. 늘어난 사이트마다 D1 테이블이 붙고, 그 테이블은 누구도 정리하지 않는다. Database 탭이 생긴 지금이 사이트 목록을 한 번 훑고 쓰지 않는 것을 지울 시점이다. 삭제는 슬러그를 손으로 입력해야 끝나니, 지울 것과 남길 것을 먼저 종이에 적어 두고 시작하는 편이 낫다.

몇 주 안에 행 편집 기능이 붙는다. 뷰어를 만들어 놓고 편집을 오래 미루는 제품은 드물고, 이미 화면 구조가 편집을 전제로 짜여 있다. 표 오른쪽 끝까지 컬럼이 이어지고 하단에 페이지 이동이 달린 그리드는 값을 고치라고 만든 모양이다.