[AI Frontier] ChatGPT Sites를 직접 써보니, AI Design Studio 프로토타입 배포 경험

[AI Frontier]

ChatGPT에서 처음 보는 Sites 메뉴를 발견해 인터랙티브 웹사이트를 만들어봤습니다. 직접 사용해보니 가장 인상적인 지점은 화면 생성보다 아이디어를 공개 가능한 웹서비스로 옮기는 과정이었습니다.

필자가 @Sites로 제작한 ‘AI Design Studio’의 시작 화면.
제품 정보를 입력하고 프로토타입을 설계하는 과정을 입력·생성·미리보기·내보내기의 네 단계로 구성했습니다.
자료: 필자 제작 및 캡처.

ChatGPT에 접속했을 때 사이드바에서 낯선 ‘Sites’ 메뉴를 발견했습니다. 이름만 보고서는 텍스트와 이미지를 조합해 간단한 홈페이지를 만드는 기능이라고 생각했습니다. 실제로 어디까지 구현할 수 있는지 확인하기 위해 @Sites를 호출하고, ‘AI Design Studio’라는 인터랙티브 웹사이트를 제작해봤습니다.

목적은 상용 서비스를 곧바로 출시하는 것이 아니었습니다. 인공지능(Artificial Intelligence, AI) 디자인 서비스를 웹 형태로 구현할 수 있는지 확인하는 아이디어 검증용 프로토타입이었습니다. 제품 정보와 대상 사용자, 브랜드 조건을 입력하면 디자인 구조와 프로토타입 제작 흐름을 보여주는 서비스로 범위를 정했습니다.

첫 화면의 완성도도 예상보다 높았지만, 더 인상적이었던 부분은 배포 과정이었습니다. 별도의 호스팅 서비스를 준비하거나 파일을 다른 환경으로 옮기지 않고, 제작과 검토가 진행된 맥락 안에서 결과물을 사이트로 게시할 수 있었습니다. 아이디어와 실제 주소 사이에 있던 단계가 크게 줄어든 경험이었습니다.

직접 사용한 첫인상

ChatGPT Sites의 장점은 AI가 코드를 대신 작성해준다는 설명만으로는 부족합니다. 아이디어 설명, 화면 구현, 수정, 미리보기와 배포가 하나의 대화 흐름으로 연결된다는 점이 더 중요했습니다.

ChatGPT Sites란 무엇인가

챗GPT 사이트(ChatGPT Sites)는 사용자가 원하는 목적과 동작을 설명하면 웹사이트, 웹앱과 게임을 생성하고 호스팅할 수 있게 해주는 기능입니다. 사용자는 프롬프트에 웹사이트 제작을 요청하거나 @Sites를 지정해 작업을 시작할 수 있습니다.

제작 과정은 요구사항 설명, 첫 버전 검토, 수정 요청, 배포와 공유로 이어집니다. ChatGPT가 생성한 결과물을 비공개 미리보기로 확인하고, 문구·레이아웃·데이터·링크·양식·상호작용을 대화로 수정한 뒤 게시하는 방식입니다.

공식 문서에서 제시하는 활용 사례도 일반 회사 소개 홈페이지에 한정되지 않습니다. 프로젝트 추적기, 출시 일정표, 대시보드, 계산기, 내부 포털, 보고서와 프로토타입처럼 사용자가 정보를 입력하거나 결과를 조작하는 경량 웹앱이 주요 대상입니다.

단계	사용자가 하는 일	Sites가 연결하는 일
요구사항	대상 사용자, 목적, 필요한 기능과 제약조건을 설명	설명을 화면 구조와 웹 동작으로 변환
미리보기	화면, 문구와 핵심 사용자 흐름을 확인	실행 가능한 비공개 결과물 제공
수정	언어로 변경 내용과 기대 결과를 설명	코드와 자산을 수정해 새 버전 생성
배포	공유 범위와 결과를 확인한 뒤 게시	호스팅 주소와 접근 설정 제공

AI Design Studio에서 직접 확인한 강점

제가 만든 AI Design Studio는 제품 정보를 입력하면 디자인 방향, 화면 구조와 프로토타입 제작 흐름을 정리하는 서비스입니다. 시작 화면에는 개요, 빌더, 프로토타입, 내보내기와 품질 점검 메뉴가 배치됐습니다. 사용자 여정도 입력, 생성, 미리보기와 내보내기의 네 단계로 구분했습니다.

이 구성은 단순한 랜딩페이지와 다릅니다. 사용자가 정보를 읽는 데서 끝나지 않고 프로젝트 조건을 입력하고, 결과를 검토하며, 다음 단계로 이동하는 서비스 흐름을 갖고 있습니다. 머릿속의 아이디어가 문서가 아니라 조작 가능한 화면으로 바뀌었습니다.

AI Design Studio의 빌더 화면.
왼쪽에서 프로젝트와 브랜드 조건을 입력하고, 오른쪽에서 미리보기·명세·코드·품질 점검 결과를 확인하도록 구성했습니다. 자료: 필자 제작 및 캡처.

빌더 화면은 왼쪽 입력 영역과 오른쪽 결과 검토 영역으로 나뉩니다. 왼쪽에서는 제품명, 제품 설명, 대상 사용자, 산출물 유형, 브랜드 톤, 참고 스타일과 필수 요소를 입력합니다. 오른쪽에서는 미리보기, 명세, 코드와 품질 점검을 전환해 확인하도록 설계했습니다.

이 구조의 장점은 요구사항과 결과가 같은 화면에서 연결된다는 점입니다. 별도의 기획 문서를 전달하고 제작 결과를 기다리는 대신, 어떤 입력이 어떤 화면과 결과로 이어지는지 바로 검토할 수 있습니다. 아이디어 검증 단계에서는 이 차이가 큽니다.

직접 사용하며 확인한 장점

아이디어의 빠른 외부화: 설명에 머물던 서비스 개념을 화면과 사용자 흐름으로 확인할 수 있었습니다.
요구사항의 구조화: 대상 사용자, 브랜드 조건과 필수 요소를 입력 항목으로 분리할 수 있었습니다.
대화형 수정: 코드 위치를 직접 찾기보다 원하는 변화와 기대 결과를 언어로 설명할 수 있었습니다.
검토 화면의 통합: 미리보기, 명세, 코드와 품질 확인을 하나의 서비스 흐름 안에 배치할 수 있었습니다.
배포 단계의 축소: 별도의 호스팅 환경을 처음부터 구성하지 않고 실제 주소로 전환할 수 있었습니다.

확인된 범위와 한계

첨부 화면으로 확인되는 것은 인터페이스와 사용자 흐름이 구현된 프로토타입이라는 점입니다. 외부 AI 서비스 연동, 생성 품질, 데이터베이스 운영과 상용 서비스 수준의 백엔드까지 검증됐다는 뜻은 아닙니다.

왜 배포의 간편함이 더 크게 느껴졌나

프로토타입 제작에서 생각보다 많은 시간이 화면 제작 이후에 발생합니다. 로컬 환경에서는 정상적으로 보이지만 다른 사람에게 공유할 수 없거나, 호스팅 설정과 파일 업로드 과정에서 오류가 생기는 경우가 있습니다. 주소가 바뀔 때마다 피드백이 서로 다른 버전에 쌓이기도 합니다.

Sites에서는 제작 환경과 배포 환경이 분리되지 않았습니다. 검토가 끝난 결과물을 게시하면 호스팅된 주소가 생성되고, 공유 대상을 정할 수 있습니다. 사용자 지정 도메인이 지원되는 계정에서는 이미 보유한 도메인을 연결하는 것도 가능합니다.

플랫폼과 디지털 서비스를 기획·운영하면서 반복해서 확인한 것은 좋은 아이디어가 항상 실행 단계까지 도달하지는 않는다는 점이었습니다. 기획, 개발, 검수와 배포 사이에 담당자와 도구가 늘어날수록 작은 실험도 정식 프로젝트처럼 무거워집니다. Sites는 초기 검증 단계에서 이 간격을 줄였습니다.

배포 전 확인할 점

모든 배포 주소는 실제 운영 주소입니다. 수정본을 검토할 때는 먼저 버전을 저장하고, 공개할 준비가 끝난 뒤 배포해야 합니다. 공개 범위, 입력 양식, 로그인, 파일과 링크도 로그아웃된 브라우저에서 다시 확인하는 편이 안전합니다.

커뮤니티의 평가는 왜 엇갈렸나

직접 경험한 제작과 배포 과정은 간단했지만, 커뮤니티의 모든 사용자가 같은 평가를 내린 것은 아닙니다. 레딧 게시물을 살펴보면 만족과 불만이 기능 자체보다 어떤 작업에 적용했는지에 따라 갈리는 모습이 보입니다.

긍정적인 사례에서는 처음부터 MVP를 만들 때 @Sites가 전체 요구사항을 한꺼번에 해석하고 화면과 기능을 완성된 프로토타입 형태로 조립한다는 평가가 나왔습니다. 기존 코드를 세밀하게 수정하는 일보다 새로운 서비스를 처음부터 구성하는 작업에서 강점을 느꼈다는 의견입니다.

반대 사례도 있습니다. 기존 워드프레스 홈페이지를 Sites로 옮기려던 한 사용자는 간단한 문구 변경에도 파일 검토와 코드 실행 절차가 길게 이어졌다고 설명했습니다. 콘텐츠를 수시로 고치는 사이트에서는 콘텐츠 관리 시스템(Content Management System, CMS)의 편집 화면이 더 효율적일 수 있다는 뜻입니다.

공개 범위 설정도 혼란을 만들었습니다. 다른 브라우저에서 로그인을 요구받은 사용자가 공개 사이트를 만들 수 없는 것 아니냐고 질문했지만, 실제로는 공유 단계에서 인터넷 전체 공개를 선택하지 않은 사례였습니다. 공식 안내에서도 사이트의 공개 대상과 사이트 내부 인증 기능은 서로 다른 설정이라고 설명합니다.

적용 방식	초기 반응	실무 해석
새 MVP 제작	전체 구조가 빠르게 조립된다는 긍정 평가	Sites의 설계 목적과 비교적 잘 맞음
기존 홈페이지 이전	작은 문구 수정도 무겁고 오래 걸린다는 불만	잦은 콘텐츠 편집에는 CMS가 유리할 수 있음
인터넷 공개	로그인 요구와 공개 범위에 대한 혼란	게시 후 다른 브라우저에서 접근 상태를 확인해야 함

커뮤니티 반응을 읽는 기준

레딧 게시물은 초기 사용자가 어디에서 강점과 마찰을 느끼는지 확인하는 사례자료입니다. 전체 이용자의 만족도나 시장 채택률을 보여주는 정량 조사로 해석해서는 안 됩니다.

공개된 고품질 사이트는 무엇이 달랐나

OpenAI의 공식 쇼케이스를 보면 Sites와 Codex로 구현할 수 있는 결과물은 일반적인 홈페이지보다 넓습니다. 브라우저 게임, 전자상거래 화면, 창작 도구와 데이터 시각화처럼 사용자 행동과 상태 변화가 있는 사례가 다수 공개돼 있습니다.

공개 사례	형태	품질을 만든 조건	정보
Asterism	별 카드를 이용해 별자리를 만드는 브라우저 게임	게임 규칙, 반응형 화면, 키보드·터치 지원과 접근성 상태를 구체적으로 정의하고 브라우저 품질검사를 수행	프로젝트 보기
Glass Towers	투명한 입체 구조물을 쌓는 물리 기반 게임	시각효과, 물리 동작과 브라우저 성능을 함께 다룬 인터랙티브 구현	프로젝트 보기
Field Day	상품을 탐색하고 바구니를 구성하는 상점	홍보 화면에 그치지 않고 상품 선택과 장바구니 행동을 중심으로 설계	프로젝트 보기
Terrain Mixer	입체 지형, 등고선과 단면도를 함께 조절하는 창작 도구	하나의 설정값을 세 가지 시각화에 동기화하고 저장·초기화·반응형 상태를 검증	프로젝트 보기

공통점은 화려한 디자인만이 아닙니다. 사용자의 행동, 상태 변화, 오류 조건, 모바일 동작과 접근성 기준이 요구사항에 들어가 있습니다. 좋은 결과는 “멋진 사이트를 만들어 달라”는 요청보다 누가 무엇을 입력하고, 어떤 결과를 얻으며, 실패할 때 무엇을 보여줄지 정한 요청에서 나왔습니다.

이 사례들은 OpenAI가 선별한 결과물이므로 일반 사용자의 첫 시도와 동일하게 볼 수는 없습니다. 다만 Sites를 단순 홈페이지 생성기로만 평가할 때 놓치기 쉬운 상한은 보여줍니다. 핵심은 페이지 수가 아니라 작동하는 사용자 경험입니다.

어떤 아이디어부터 사이트로 만들어야 하나

ChatGPT Sites의 첫 프로젝트로 회사의 핵심 홈페이지나 대규모 업무 시스템을 선택할 필요는 없습니다. 실패 비용이 낮고, 핵심 사용자 행동을 한 문장으로 설명할 수 있으며, 짧은 기간 안에 반응을 확인할 수 있는 아이디어가 더 적합합니다.

판단 항목	기존 CMS가 유리한 경우	ChatGPT Sites가 유리한 경우
핵심 목적	기사, 블로그, 회사 정보와 검색 유입	프로토타입, 대시보드, 계산기와 내부 도구
수정 방식	문구와 이미지를 자주 직접 편집	기능과 사용자 흐름을 대화로 개선
주요 자산	콘텐츠와 분류체계	입력, 상태 변화와 결과 화면
검증 기준	게시 편의성과 검색 노출	과업 완료율, 수정 시간과 실제 사용 반응

프로토타입 제작 전 체크리스트

누가 사용할 사이트인지 한 문장으로 설명할 수 있는가?
사용자가 수행할 핵심 행동을 하나로 좁혔는가?
성공과 실패를 판단할 검증 기준이 있는가?
개인정보나 민감정보 없이 첫 실험을 진행할 수 있는가?
빈 상태, 오류와 미완료 상태까지 확인했는가?
배포 후 로그아웃 브라우저와 모바일에서 다시 시험했는가?

AI Design Studio를 만든 목적도 여기에 있었습니다. 처음부터 완성된 AI 디자인 플랫폼을 구축하기보다, 제품 정보와 브랜드 조건을 입력받는 서비스가 화면과 사용자 흐름으로 구현될 수 있는지를 확인했습니다. 이 범위에서는 Sites의 제작과 배포 방식이 유용했습니다.

앞으로 볼 지표는 첫 화면의 화려함이 아닙니다. 수정 요청부터 새 버전 배포까지 걸리는 시간, 비개발자가 반복 작업을 끝낼 수 있는지, 방문자가 핵심 과업을 완료하는지, 공개 설정 오류가 얼마나 발생하는지를 확인해야 합니다. Sites가 제공하는 방문자와 페이지뷰 분석도 출발점이 될 수 있지만, 프로토타입의 가치는 실제 과업 완료와 피드백에서 드러납니다.

Summary

낯선 Sites 메뉴에서 시작한 실험은 ‘AI Design Studio’라는 인터랙티브 웹사이트의 프로토타입으로 이어졌습니다. 직접 사용하며 확인한 가장 큰 장점은 아이디어 설명, 구현, 검토와 배포가 하나의 흐름 안에서 연결된다는 점이었습니다. 커뮤니티 평가는 용도에 따라 엇갈립니다. 새 MVP 제작에는 긍정적인 반응이 있지만, 기존 콘텐츠 사이트의 반복 편집에는 불편 사례도 있습니다. 첫 적용 대상은 핵심 홈페이지보다 작고 독립적인 프로토타입이어야 하며, 첫 화면보다 수정·배포와 실제 사용의 반복 비용을 측정해야 합니다.

FAQ

ChatGPT Sites에 대해 자주 묻는 질문

Q. ChatGPT Sites는 무엇을 만드는 기능인가요?

인터랙티브 웹사이트, 웹앱과 게임을 만들고 미리보기·수정·배포·공유하는 기능입니다. 대시보드, 계산기, 프로토타입과 내부 도구처럼 사용자의 행동이 포함된 프로젝트에 적합합니다.

Q. 코딩을 몰라도 사이트를 만들 수 있나요?

첫 버전은 자연어로 대상 사용자, 목적과 기능을 설명해 시작할 수 있습니다. 다만 동작 시험, 오류 검토, 접근 권한과 데이터 처리 책임까지 자동으로 해결되는 것은 아닙니다.

Q. 기존 홈페이지를 Sites로 옮기는 것이 좋은가요?

글과 이미지를 자주 수정하는 콘텐츠 중심 홈페이지라면 CMS가 더 편리할 수 있습니다. Sites는 기존 홈페이지의 단순 이전보다 새로운 프로토타입과 상호작용형 도구를 만들 때 장점이 분명합니다.

Q. 배포한 사이트는 누구나 볼 수 있나요?

인터넷 전체 공개를 선택한 사이트는 워크스페이스 계정 없이 접근할 수 있습니다. 다만 계정과 워크스페이스 설정에 따라 선택 가능한 공유 범위가 다르므로 게시 후 다른 브라우저에서 확인해야 합니다.

Q. ChatGPT Sites는 완성된 상용 서비스를 대체할 수 있나요?

범위가 작고 명확한 경량 앱과 프로토타입에는 적합하지만, 복잡한 인프라·실시간 외부 데이터·민감정보 처리가 필요한 서비스는 별도의 개발 프로젝트가 필요할 수 있습니다.

TERMINOLOGY

본문의 주요 용어

용어	뜻	실무자가 볼 지점
ChatGPT Sites	ChatGPT에서 웹사이트와 경량 앱을 만들고 호스팅하는 기능	생성뿐 아니라 미리보기, 수정, 배포와 접근 설정이 연결됨
MVP	핵심 가설을 검증하기 위한 최소기능제품	완성도보다 실제 사용 가능성과 반응을 먼저 확인함
PoC	개념검증(Proof of Concept, PoC)	상용 투자 전에 기술과 아이디어의 구현 가능성을 좁은 범위에서 시험함
CMS	웹 콘텐츠를 반복 관리하는 시스템	사이트 제작 도구와 일상적인 콘텐츠 운영 도구는 목적이 다름

이 블로그 검색