최근 OpenAI가 ChatGPT에 Sites라는 신규 기능을 공개했다. 채팅으로 요청만 하면 웹사이트나 경량 웹앱을 만들어 URL로 바로 공유할 수 있다는 게 핵심 홍보 포인트다. 일부 유튜브 콘텐츠에서는 이 기능이 마치 기존 홈페이지 제작·호스팅 체계를 통째로 대체할 것처럼 소개하기도 한다. 하지만 OpenAI의 공식 문서와 실제 기술 구조를 뜯어보면, 이야기는 조금 더 복잡하고 훨씬 제한적이다.

① Sites는 정확히 무엇인가

Sites는 2026년 7월 9일 ChatGPT Work 안에 공개 베타로 출시됐다. 대화창에 원하는 사이트를 설명하면 ChatGPT가 HTML, CSS, JavaScript로 결과물을 생성하고, 그 결과물을 OpenAI 인프라(정확히는 Cloudflare와의 협업 인프라)에 호스팅해 URL로 즉시 공유하는 방식이다.

기술적으로 이 결과물은 클라이언트 사이드 웹앱이다. 즉 방문자의 브라우저 안에서 대부분의 로직이 실행되는 구조이고, 별도의 서버 프로세스를 사용자가 직접 띄우는 개념이 아니다. 다만 완전한 정적 페이지에 머무르지 않도록, Cloudflare의 서버리스 인프라인 D1(관계형 데이터베이스)과 R2(오브젝트 스토리지)를 옵션으로 연결할 수 있게 되어 있다.

D1과 R2란 무엇인가

둘 다 OpenAI가 아니라 Cloudflare가 만든 서버리스 인프라 제품이다. D1은 SQLite 기반의 관리형 데이터베이스로, 사용자가 서버를 임차해 직접 설치·운영하는 대신 API 호출하듯 사용하는 방식이다. R2는 AWS S3와 유사한 오브젝트 스토리지로, 이미지나 문서 같은 파일을 저장하는 공간이다. 두 서비스 모두 “내가 소유하고 관리하는 인프라”가 아니라 “빌려서 호출해 쓰는 관리형 서비스”라는 점이 워드프레스의 MySQL·파일시스템과 근본적으로 다르다.

② 역량과 한계를 명확히 정리하면

③ 워드프레스가 설치되지 않는다는 것의 실질적 의미

Sites에서 워드프레스가 안 된다는 사실은 단순한 기능 부재 이상의 의미를 갖는다. 워드프레스는 사용자가 서버 한 대를 통째로 할당받아 Apache/Nginx, PHP, MySQL을 자유롭게 설치·설정하는 것을 전제로 한다. Sites는 애초에 이런 구조 자체를 제공하지 않는다 — 사용자에게 서버 OS 접근 권한을 주는 게 아니라, 정해진 런타임 안에서 코드를 실행시켜주는 “관리형 실행 환경”이기 때문이다.

이 차이는 결국 콘텐츠 발행 워크플로우의 부재로 이어진다. 워드프레스는 관리자가 에디터에서 글을 쓰고, 카테고리·태그를 지정하고, 미디어 라이브러리에서 이미지를 관리하고, SEO·백업·보안 플러그인을 자유롭게 조합하는 생태계가 20년 넘게 쌓여 있다. Sites는 이런 걸 대체하는 게 아니라, “채팅으로 요청하면 페이지 하나가 생성되는” 훨씬 단순한 워크플로우다. 매일 새 글을 발행하고 아카이브를 관리해야 하는 블로그·미디어형 사이트에는 애초에 맞지 않는 구조다.

④ 왜 지금은 게임체인저가 될 수 없는가

일부 유튜브 콘텐츠는 Sites를 마치 “이제 누구나 코드 없이 완전한 홈페이지를 운영할 수 있게 됐다”는 식으로 소개한다. 하지만 다음 네 가지 이유에서 이는 상당히 과장된 해석이다.

1) OpenAI 스스로 “경량(lightweight)”이라고 규정한다

공식 소개 자료는 Sites를 “focused websites and lightweight apps”로 명시하며, 일부 프로젝트는 여전히 다른 도구나 더 큰 엔지니어링 노력이 필요할 수 있다고 스스로 밝히고 있다. 범용 CMS 대체를 목표로 하지 않는다는 뜻이다.

2) 공식 사용 예시 자체가 콘텐츠 사이트가 아니다

OpenAI가 제시하는 사용 사례는 대시보드, 프로젝트 트래커, 런치 캘린더, 프로토타입, 내부 포털, 인터랙티브 리포트 등 업무 산출물에 집중되어 있다. 회사 홈페이지, 블로그, 세무 콘텐츠 사이트처럼 “지속적으로 콘텐츠를 발행하고 방문자를 유입시키는” 용도의 사례는 거의 등장하지 않는다.

3) 접근 권한 자체가 아직 제한적이다

Business·Enterprise·Pro 등 유료 플랜 중심으로 단계적 롤아웃 중이며, Free·Go 플랜은 제외되어 있다. EEA, 스위스, 영국 등 일부 지역에서는 아예 이용할 수 없다. “누구나 쓸 수 있는” 범용 도구라 하기엔 아직 접근성 자체가 좁다.

4) 데이터 레지던시 미지원 — 실무 사이트에 치명적

공식 문서는 배포된 사이트, 사이트 코드, D1/R2 데이터·파일 저장소, 아티팩트, 로그 전체에 걸쳐 데이터/추론 레지던시를 지원하지 않는다고 명시한다. 고객 정보나 예약 데이터를 다루는 실무 사이트라면 이는 가볍게 넘길 수 없는 제약이다.

정리하면, Sites는 “정적 랜딩페이지 관리 화면에서 한 단계 발전해 D1·R2로 약간의 DB·파일 기능을 곁들인 경량 웹앱 빌더”라는 평가가 현재 공개된 문서 기준으로 정확하다. 이는 분명 유용한 진전이지만, 워드프레스가 대표하는 전통적인 CMS·호스팅 생태계를 대체할 수준의 역량과는 거리가 있다.

⑤ 워드프레스 vs 챗GPT Sites, 무엇이 다른가

항목	워드프레스 + 전통적 호스팅	챗GPT Sites
설치 방식	서버 임차 후 직접 설치	채팅으로 요청 → 자동 생성·배포
데이터베이스	MySQL/MariaDB 직접 운영	Cloudflare D1 (서버리스, 관리형)
파일 저장	서버 디스크/NAS/S3 등 자유 선택	Cloudflare R2 (관리형)
콘텐츠 관리 UX	에디터·미디어 라이브러리·리비전 관리	대화 기반 재요청 방식, 전용 CMS UX 없음
확장성	플러그인 생태계로 사실상 무제한	런타임이 지원하는 범위 내로 제한
적합 용도	블로그, 미디어, 쇼핑몰, 커뮤니티 등 전방위	대시보드, 트래커, 계산기 등 업무용 경량 도구
비용 구조	도메인+호스팅비, 규모에 따라 조정 가능	ChatGPT 유료 플랜에 포함, 별도 세부 과금 불명확

⑥ 착시현상인가, 체급이 다른 진짜 기능인가

여기서 한 가지는 짚고 넘어갈 필요가 있다. D1·R2 연동은 눈속임이 아니다. 브라우저에서 D1을 호출하면 실제로 데이터가 저장되고 조회되는, 분명히 작동하는 기능이다. 다만 그 “작동”의 범위가 단순 CRUD(생성·조회·수정·삭제) API 호출 몇 번에 그친다는 게 핵심이다. 워드프레스처럼 서버 사이드에서 권한 체크, 여러 테이블 조인, 트랜잭션 처리, 백그라운드 스케줄러, 외부 시스템과의 실시간 연동 같은 복잡한 로직을 수행하는 것과는 애초에 체급이 다르다.

즉 “가짜 서버 기능처럼 보이게 하는 착시”라기보다는, 진짜 엔진이긴 하지만 배기량이 확연히 작은 엔진이라고 이해하는 게 더 정확하다. 그리고 그 작은 배기량 안에서 구현 가능한 것들 — 대시보드, 캘린더, 계산기 — 만 공식 사용 예시로 제시되어 있는 것도 결국 이 구조적 한계를 그대로 반영한 결과다.

고급세단 vs 경차

이 관계를 자동차에 비유하면 이해가 빠르다. 워드프레스 + 전통적 호스팅이 옵션이 풍부한 고급세단이라면, 챗GPT Sites는 옵션이 거의 없고 출력도 약한 경차에 해당한다. 경차가 나쁜 차라서가 아니라,애초에 설계된 목적과 체급이 다른 것이다.

구분	고급세단 · 워드프레스+전통호스팅	경차 · 챗GPT Sites
엔진	직접 튜닝 가능한 대배기량 서버(자체 DB·백엔드)	제조사가 정해준 소형 서버리스 엔진(D1·R2)
옵션 확장	플러그인 = 애프터마켓 부품 무한 장착	옵션 자체가 제조사 스펙 안에 고정
정비·유지보수	어디서든 수리 가능한 범용 정비 생태계	제조사(OpenAI) 직영 서비스센터만 가능
주행 성격	장거리·고속 주행에도 안정적	짧고 가벼운 시내 이동에 최적화
적합 목적	모든 용도를 커버하는 범용차	특정 목적(짧은 이동)엔 오히려 더 효율적

⑦ 그렇다면 이 기능을 어디에 쓰는 게 합리적인가

Sites의 강점은 “빠르게 만들어서 팀 내부에서 바로 쓰는” 시나리오에 있다. 다음과 같은 경우라면 오히려 전통적 방식보다 효율적일 수 있다.

• 내부용 대시보드·현황판 — 예: 오늘 상담 예약 현황, 담당자별 처리 건수 같은 소규모 내부 도구
• 일회성 계산기·시뮬레이터 — 세금 계산기 같은 단순 로직 + 입력폼 조합
• 단기 이벤트 페이지 — 특정 캠페인이나 설명회용 랜딩페이지, 신청 폼 수집
• 프로토타입 검증 — 정식 개발 전, 아이디어를 빠르게 시각화해 팀에 공유

반대로 다음과 같은 경우라면 아직은 적합하지 않다.

• 지속적으로 콘텐츠를 발행하는 회사 블로그·세무 콘텐츠 사이트
• 고객 개인정보·상담 이력 등 민감 데이터를 다루는 CRM·업무 시스템
• SEO, 방문자 통계, 다양한 마케팅 플러그인이 필요한 대외 홍보 사이트
• 이미 안정적으로 운영 중인 Node.js/PHP 기반 시스템의 이관 대상

⑧ 그럼에도 전통적 방식이 여전히 최강인 이유

도메인을 사고, 웹호스팅(또는 서버)을 임차하고, 워드프레스나 원하는 웹앱을 직접 설치해 운영하는 전통적인 방식은 여전히 기능적으로나 관리 측면에서나 가장 강력하고 유연한 선택지다. 이유는 명확하다.

• 완전한 통제권 — 서버, 데이터베이스, 파일, 도메인 DNS까지 모든 계층을 직접 소유하고 결정할 수 있다. 특정 플랫폼의 정책 변경이나 서비스 종료 리스크에서 자유롭다.
• 검증된 생태계 — 워드프레스는 전 세계 웹사이트의 상당수를 차지할 만큼 플러그인·테마·보안 도구·커뮤니티 지식이 방대하게 축적되어 있다.
• 확장의 자유도 — Node.js 상시 프로세스, 배치 작업, 외부 API 연동, 커스텀 인증 체계 등 무엇이든 서버 단에서 원하는 대로 구현할 수 있다. 실제로 새솔CRM처럼 홈택스 자동화, 알림톡, 전자서명 같은 복잡한 업무 로직을 갖춘 시스템은 이런 자유도 없이는 애초에 성립하지 않는다.
• 데이터 주권 — 데이터가 정확히 어느 서버, 어느 지역에 저장되는지 스스로 정할 수 있다. 개인정보나 세무 자료처럼 민감한 데이터를 다룰 때 이는 선택이 아니라 필수 요건이다.
• 장기 안정성 — 베타 서비스의 정책 변경, 요금제 변경, 기능 축소 리스크 없이 수년 단위로 안정적인 운영 계획을 세울 수 있다.

결국 Sites 같은 AI 기반 사이트 빌더는 “빠르게 무언가를 만들어 공유하는” 새로운 도구 하나가 추가된 것으로 보는 게 정확하다. 회사의 대외 홈페이지, 콘텐츠 발행 채널, 고객 데이터를 다루는 업무 시스템의 근간은 당분간 계속 도메인·호스팅·워드프레스(또는 자체 웹앱) 조합이 맡게 될 가능성이 높다.