AI 도구 · 2026년 7월 10일 · 약 6분

ChatGPT Sites 사용법: 내부 프로젝트 트래커와 보고서 사이트를 안전하게 만드는 방법

ChatGPT Sites 공개 베타로 내부 프로젝트 현황판, 보고서, 간단한 웹앱을 만드는 흐름을 초보자 기준으로 정리했다. 저장, 검토, 배포, 공개 범위 설정을 어떤 순서로 확인하면 안전한지 살펴본다.

• ChatGPT Sites
• ChatGPT Work
• OpenAI Sites
• AI 업무 자동화
• 프로젝트 트래커
• 보고서 사이트
• 웹앱 만들기

출처: OpenAI ChatGPT Sites Docs

ChatGPT Sites가 2026년 7월 9일 공개 베타로 발표되면서, 내부 프로젝트 현황판이나 보고서 사이트를 ChatGPT 안에서 바로 만들어볼 수 있게 됐습니다. 아이디어를 설명하면 대시보드, 프로젝트 트래커, 출시 일정표, 프로토타입, 내부 포털, 보고서 형태의 가벼운 웹앱으로 이어질 수 있어요. 다만 공개 URL을 만들기 전에는 저장, 검토, 접근 권한 확인을 먼저 거치는 흐름을 잡아두는 게 안전합니다.

초보자라면 “멋진 사이트를 만들어줘”라고 시작하기보다 “누가 보고, 무엇을 입력하고, 어떤 정보가 저장되어야 하는지”를 먼저 적어보세요. 이 글에서는 팀 프로젝트 트래커를 예로 들어 ChatGPT Sites를 업무용으로 쓰는 기본 흐름을 정리합니다.

핵심 키워드

• ChatGPT Sites 사용법
• 내부 프로젝트 트래커 만들기
• ChatGPT Work 웹앱 만들기
• OpenAI Sites 배포
• 업무 보고서 사이트 만들기
• D1 데이터 저장
• R2 파일 업로드
• Sites 공유 권한

공식 자료에서 확인한 내용

• OpenAI Sites 개발자 가이드는 Sites가 public beta이며, 플랜과 지역, 워크스페이스 설정에 따라 이용 가능 범위가 달라질 수 있다고 안내합니다.
• OpenAI Help Center의 ChatGPT Sites 문서는 생성, 미리보기, 게시, 공유, 베타 한도, 지원되지 않는 사용 사례를 설명합니다.
• OpenAI ChatGPT release notes는 2026년 7월 9일 ChatGPT Sites 공개 베타와 ChatGPT Work 흐름에서 Sites를 만드는 방법을 안내했습니다.

ChatGPT Sites로 만들 수 있는 것

ChatGPT Sites는 ChatGPT 안에서 작업 아이디어를 인터랙티브 웹사이트나 가벼운 앱으로 바꾸는 기능입니다. 예를 들어 팀별 업무 현황판, 고객 리포트 페이지, 출시 캘린더, 사내 자료 포털, 간단한 프로토타입처럼 반복해서 열어보고 공유해야 하는 화면에 잘 맞습니다.

시작 경로는 환경에 따라 다릅니다. 웹에서는 ChatGPT Work에서 만들 수 있고, 데스크톱 앱에서는 Work 또는 Codex 흐름에서 시작할 수 있습니다. 저장과 배포 관리는 ChatGPT 웹 또는 데스크톱 앱에서 확인하는 방식으로 이해하면 쉽습니다.

먼저 확인할 이용 가능 조건

2026년 7월 9일 공개된 OpenAI 안내 기준으로 Sites는 공개 베타이며, 계정 플랜, 지역, rollout, 워크스페이스 설정에 따라 보이는 범위가 다를 수 있습니다. Paid plans 중 Free와 Go는 대상이 아니고, Pro, Pro Lite, Enterprise, Edu가 먼저 받으며 Plus와 Business는 며칠에 걸쳐 이어집니다. 출시 시점에는 EEA, 스위스, 영국에서 Sites가 제공되지 않습니다.

Business 워크스페이스에서는 Sites가 기본 활성화되며, Enterprise에서는 관리자가 역할 기반 접근 제어로 켜야 합니다. Enterprise의 공개 배포는 기본적으로 꺼져 있으므로, 회사 계정에서 외부 공유가 필요하다면 먼저 워크스페이스 관리자 설정을 확인하세요.

베타 한도와 데이터 위치도 확인한다

공개 베타에서는 플랜별 한도가 적용됩니다. 한도에 가까워지면 ChatGPT가 알려주며, 한도에 도달하면 새 Site를 만들거나 저장소를 추가하거나 사용량이 높은 공개 Site를 계속 공개 상태로 유지하는 데 제한이 생길 수 있습니다. 기존 Site를 편집하고 관리하는 일은 계속 가능하다고 안내돼 있습니다.

또 하나 중요한 점은 데이터 residency와 inference residency입니다. Help Center는 출시 시점에 배포된 Site, Site 코드, D1/R2 데이터와 파일 저장소, artifacts, logs에 대해 데이터 residency 또는 inference residency를 지원하지 않는다고 설명합니다. 규제가 강한 회사 자료라면 이 조건을 먼저 확인해야 합니다.

프로젝트 트래커를 만들 때 쓸 기본 프롬프트

아래 템플릿은 그대로 복사한 뒤 대괄호 부분만 바꾸면 됩니다. 처음에는 기능을 많이 넣기보다 입력, 목록, 상태 변경, 필터, 권한처럼 꼭 필요한 흐름을 분명하게 적는 것이 좋습니다.

복사해서 쓰는 첫 요청 템플릿

• [팀 이름]이 사용할 내부 프로젝트 트래커 사이트를 만들어줘. 사용자는 프로젝트를 등록하고, 담당자, 마감일, 상태, 우선순위, 다음 액션을 볼 수 있어야 해.
• 목록에서는 상태와 담당자로 필터링할 수 있게 해줘. 각 프로젝트 상세 화면에는 최근 업데이트와 리스크 메모를 남길 수 있게 해줘.
• 이 사이트는 [나만 보기 / 초대한 사람만 / 워크스페이스 내부]로 먼저 검토하고 싶어. 바로 공개 배포하지 말고 검토 가능한 버전을 먼저 저장해줘.
• 프로젝트 데이터는 방문할 때마다 유지되어야 하므로 durable structured data가 필요해. 지원되는 플랜, 워크스페이스, 런타임에서 D1을 쓸 수 있는지 확인해줘.
• 비밀 키, 고객 개인정보, 내부 계약 금액 같은 민감한 정보는 예시 데이터에 넣지 말고, 필요한 환경 변수는 Sites 설정에서 관리할 수 있게 안내해줘.

바꿔 넣을 부분

• [팀 이름]: 예를 들어 마케팅팀, 제품팀, 운영팀처럼 실제 사용자를 적습니다.
• [나만 보기 / 초대한 사람만 / 워크스페이스 내부]: 처음에는 가장 좁은 범위가 안전합니다.
• 상태 값: 예정, 진행 중, 검토 중, 완료처럼 팀에서 실제로 쓰는 단어로 바꿉니다.
• 필수 필드: 담당자, 마감일, 우선순위, 리스크, 다음 액션 중 정말 필요한 항목만 남깁니다.
• 저장 조건: 방문 뒤에도 남아야 하는 데이터와 단순 화면 상태를 구분합니다.

안전한 제작 순서

1단계: 설명하기

• 대상 사용자, 목적, 필요한 화면, 저장해야 할 정보, 공유 범위를 한 번에 적습니다.
• “프로젝트 관리 앱”처럼 넓게 말하기보다 “운영팀이 주간 프로젝트 상태를 확인하는 트래커”처럼 씁니다.
• 회사 내부 자료를 예시로 넣어야 한다면 실제 고객명이나 비밀 값을 빼고 샘플 데이터로 바꿔 넣습니다.

2단계: 검토하기

• 생성된 사이트의 화면, 입력 폼, 필터, 상태 변경 흐름을 직접 눌러봅니다.
• 프로젝트 데이터가 의도대로 남아야 하는 경우 D1 같은 durable structured data가 필요한지 확인합니다.
• 문서, 이미지, 오디오, 영상처럼 업로드 파일이 필요한 경우 R2 같은 파일 저장 구성이 필요한지 확인합니다.

3단계: 다듬기

• “상태 필터를 상단에 고정해줘”, “마감일 지난 항목을 별도 섹션으로 보여줘”처럼 화면 단위로 수정 요청합니다.
• 보고서용 사이트라면 “이번 주 변경 사항, 막힌 일, 다음 액션을 한 화면에 요약해줘”처럼 읽는 사람의 결정을 돕는 구조로 바꿉니다.
• 시각 자료나 기존 보고서 파일이 있으면 첨부해 참고하게 할 수 있습니다.

4단계: 저장하고 공유하기

• Sites 배포 URL은 프로덕션 배포로 취급됩니다. 외부에 보여주기 전에는 먼저 저장된 버전으로 검토하세요.
• 검토가 끝나기 전에는 owner와 workspace admin, selected users처럼 좁은 공유 범위를 선택합니다.
• 공유 옵션은 계정과 워크스페이스 설정에 따라 selected users, workspace, anyone on the internet 등으로 달라질 수 있습니다.
• 공유는 방문 권한을 주는 것이며 방문자가 사이트를 편집할 수 있게 만드는 의미는 아닙니다.

데이터 저장과 로그인은 이렇게 요청하기

프로젝트 트래커는 단순한 소개 페이지와 달리 데이터가 남아야 합니다. OpenAI 문서 기준으로 저장된 기록, 사용자 진행 상황, 점수처럼 구조화된 데이터가 필요하면 D1을 요청하고, 이미지나 문서 업로드가 필요하면 R2를 요청하는 식으로 구분하면 됩니다. 다만 아래 옵션은 지원되는 플랜, 워크스페이스, 런타임에서만 쓸 수 있습니다.

비밀 값은 프롬프트에 넣지 않기

API 키, 비밀번호, 토큰, 고객별 비밀 URL은 프롬프트, 첨부 파일, 사이트 본문에 넣지 않는 것이 원칙입니다. Sites에서 필요한 환경 변수와 시크릿은 Sites 설정에서 관리하고, 로컬 개발용 .env 파일에도 실제 비밀 값을 커밋하지 않는 흐름이 안전합니다.

민감한 정보를 다룰 때 요청 문장

• 이 사이트에는 실제 API 키를 넣지 말고, 필요한 키 이름만 환경 변수로 참조해줘.
• 프롬프트와 예시 데이터에는 고객 실명, 계약 금액, 개인 연락처를 포함하지 말아줘.
• 배포 전 사이트 화면에서 비밀 값이나 내부 전용 문서명이 노출되는지 확인할 수 있게 점검 목록을 만들어줘.
• 환경 변수나 시크릿을 바꾼 뒤에는 승인된 저장 버전을 다시 배포하는 흐름으로 안내해줘.

처음부터 만들면 안 되는 사이트

ChatGPT Sites는 가벼운 웹 경험을 빠르게 만들기 위한 기능입니다. OpenAI Help Center는 Sites가 Protected Health Information, 결제카드 데이터, 금융 거래, malware, phishing, 사람이나 조직 사칭, 13세 미만 또는 적용되는 디지털 동의 연령 미만 아동 대상 서비스에 쓰이면 안 된다고 안내합니다.

업무용으로 시작하기 좋은 범위

• 팀 내부 프로젝트 트래커
• 주간 보고서 사이트
• 출시 일정표
• 회의 액션 아이템 보드
• 샘플 데이터로 만든 프로토타입

초보자가 자주 하는 실수

피해야 할 실수와 쉬운 해결법

• 바로 공개 링크로 배포하기: Sites 배포 URL은 실제 운영 URL로 봐야 합니다. 먼저 저장된 버전으로 검토한 뒤 공유 범위를 넓히세요.
• 저장 기능을 말하지 않기: “프로젝트가 다음 방문에도 남아야 한다”고 적어야 D1 같은 데이터 저장 구성을 요청할 수 있습니다.
• 업로드 파일과 목록 데이터를 섞어 말하기: 파일은 R2, 파일 설명이나 태그 같은 구조화 데이터는 D1처럼 나누어 요청하세요.
• 권한을 나중에 생각하기: 내부 트래커라면 처음 요청부터 “워크스페이스 사용자만” 또는 “초대한 사람만” 같은 접근 범위를 넣는 편이 좋습니다.
• 민감한 예시 데이터를 그대로 붙여넣기: 실제 고객명, 토큰, 계약 조건은 샘플 값으로 바꾼 뒤 입력하세요.

보고서 사이트로 확장하는 프롬프트

프로젝트 트래커가 어느 정도 정리되면, 같은 데이터를 바탕으로 주간 보고서 사이트를 만들 수 있습니다. 핵심은 “읽는 사람이 무엇을 결정해야 하는지”를 알려주는 것입니다.

주간 보고서 사이트 템플릿

• 현재 프로젝트 트래커 데이터를 바탕으로 주간 보고서 사이트를 만들어줘.
• 첫 화면에는 이번 주 완료된 일, 지연 중인 일, 새 리스크, 다음 주 우선순위를 요약해줘.
• 각 프로젝트는 상태, 담당자, 마감일, 다음 액션을 표로 보여줘.
• 임원 보고용으로 읽기 쉽게 만들되, 내부 검토 전에는 공개 배포하지 말고 저장된 버전만 만들어줘.
• 공유 범위는 [워크스페이스 내부 / 초대한 사람만]으로 제한해줘.

한 줄 결론

ChatGPT Sites는 “설명 → 검토 → 수정 → 저장 → 배포와 공유” 순서를 지킬 때 업무용으로 쓰기 좋습니다. 프로젝트 트래커처럼 데이터가 남는 사이트라면 D1, 파일 업로드가 있으면 R2, 내부 사용자 확인이 필요하면 workspace-auth identity까지 요청에 포함해보세요. 공개 링크는 마지막 단계입니다.