ChatGPT Sites 프리뷰, Business 기본 활성화와 사내 앱 배포

AI 요약

• 무슨 일: OpenAI가 2026년 6월 2일 ChatGPT Sites 프리뷰를 공개했습니다.
  • Codex가 대시보드, 플래너, 리뷰 공간, 프로젝트 보드 같은 워크스페이스 내부 웹 앱을 만들고 URL로 공유합니다.
• 접근 경계: Help Center 기준 Business 워크스페이스는 기본 활성화, Enterprise는 Early Access 토글로 제공됩니다.
• 주의점: 작은 사내 앱이 티켓 큐를 줄일 수 있지만, 권한·감사·비활성화·베타 책임선을 먼저 정해야 합니다.
  • OpenAI Sites Terms는 Beta Service이며, OpenAI가 사이트를 비활성화할 수 있다고 명시합니다.

OpenAI가 2026년 6월 2일 공개한 Codex 업데이트에서 가장 조용하지만 실무적으로 큰 항목은 Sites입니다. 같은 발표에는 역할별 plugin, annotation, Codex 주간 사용자 500만 명, 비개발자 사용자 약 20% 같은 숫자가 함께 들어 있습니다. 그러나 Sites는 단순한 산출물 생성 기능이 아닙니다. Codex가 만든 결과물이 워크스페이스 내부 URL로 배포되는 순간, 비개발자의 작업은 문서 초안에서 작은 사내 앱으로 넘어갑니다.

OpenAI는 Sites를 Business와 Enterprise 고객 대상 프리뷰로 설명합니다. Codex가 아이디어, 분석, 계획을 받아 dashboard, planner, review workspace, project board, gallery, lightweight tool로 바꿀 수 있고, 현재는 워크스페이스 안의 누구에게나 URL로 공유할 수 있다는 설명입니다. 고객 리뷰용 페이지, 재무 모델 기반 scenario planner, 제품 출시 hub가 공식 예시입니다. 이 예시는 개발자에게 익숙한 “앱 빌드”보다 부서 업무에 가까운 언어입니다.

공식 Help Center의 접근 조건은 더 직접적입니다. ChatGPT Sites는 eligible Business and Enterprise workspaces에서 Codex plugin으로 제공됩니다. Business 워크스페이스는 기본 활성화이며, Enterprise 워크스페이스는 Early Access 섹션의 토글로 제공된다고 적혀 있습니다. 관리자는 Workspace settings > Permissions & Roles에서 Sites 토글을 켜거나 끌 수 있고, Workspace settings > Sites에서 이미 만들어진 사이트를 비활성화할 수 있습니다.

이 구조가 중요한 이유는 “비개발자가 웹 앱을 만든다”는 문장보다 배포 경계 때문입니다. 지금까지 많은 AI 업무 도구는 문서, 스프레드시트, 프레젠테이션, 코드 조각을 만들어 줬습니다. Sites는 그 결과물을 다른 사람이 접속하는 URL로 바꿉니다. URL이 생기면 사용자는 북마크하고, 회의에서 열고, 고객 계정 리뷰에 쓰고, 프로젝트 진행판처럼 다룹니다. 그 순간 산출물은 개인 메모가 아니라 조직의 작은 운영 표면이 됩니다.

OpenAI가 든 customer review 예시는 이 변화를 잘 보여줍니다. Codex에게 특정 고객 리뷰용 사이트를 만들라고 요청하면 관련 제품 업데이트, 열린 질문, 사용량 추이, 다음 단계를 담은 대화형 페이지를 만든다는 설명입니다. 이것은 영업 담당자가 문서를 작성하는 작업이면서, 동시에 고객 상태를 보는 작은 CRM 보조 화면입니다. 개발팀이 Salesforce 대시보드 요청을 받기 전, 세일즈 팀이 Codex로 임시 앱을 만들 수 있다는 뜻입니다.

재무 scenario planner 예시도 비슷합니다. OpenAI는 재무 모델에서 가정별 비교를 할 수 있는 사이트를 만들 수 있다고 설명합니다. 기존에는 스프레드시트 탭, PDF, 슬라이드가 회의 자료로 나뉘었습니다. Sites가 작동하면 임원은 URL 하나에서 가정, 수치, 차트, 코멘트를 함께 봅니다. 이 사용법은 생산성을 올릴 수 있지만, 승인되지 않은 수식, 오래된 데이터, 잘못된 민감도 분석이 같은 URL로 퍼질 위험도 같이 만듭니다.

제품 출시 hub는 더 조직적인 사례입니다. 출시 자료, 메시지, 마일스톤, 담당자, 의사결정 이력을 살아 있는 hub로 바꾸고, 세부 정보가 바뀌면 Codex에게 계속 업데이트를 맡길 수 있다는 설명입니다. 출시 관리자는 이 기능을 좋아할 가능성이 큽니다. 하지만 제품, 법무, 보안, 영업, 고객지원이 같은 URL을 참조한다면 “누가 마지막으로 바꿨는가”, “어떤 출처에서 가져왔는가”, “언제 공식 문서가 됐는가”를 남기는 방식이 필요합니다.

기존 devlery 글이 다룬 Codex 지식노동 보고서는 주간 사용자 500만 명과 비개발자 20%라는 채택 지표를 중심으로 했습니다. Sites는 그 다음 단계입니다. 비개발자가 보고서를 만드는 것과 비개발자가 워크스페이스 앱을 배포하는 것은 책임선이 다릅니다. 보고서는 틀리면 수정하거나 버릴 수 있습니다. 앱은 다른 사람이 반복해서 접속하고, 업무 판단에 쓰고, 내부 데이터와 연결될 수 있습니다.

따라서 개발팀이 봐야 할 첫 번째 항목은 인증입니다. OpenAI는 Sites가 Sign in with ChatGPT access를 사용하고, 만든 뒤 워크스페이스 내부 사용자에게 초대할 수 있다고 설명합니다. 이것은 공개 인터넷 배포와 다르지만, 무위험도 아닙니다. 워크스페이스 안에도 부서, 직급, 프로젝트, 고객 계정별 접근 경계가 있습니다. 모든 멤버가 볼 수 있는 URL과 특정 그룹만 볼 수 있는 URL은 전혀 다른 운영 단위입니다.

두 번째 항목은 관리자 접근입니다. Help Center는 admin과 owner가 멤버가 만든 모든 Sites에 기본 접근 권한을 가진다고 적습니다. 이 문장은 감사를 위해 중요합니다. 동시에 사용자에게는 “내가 만든 임시 분석 사이트를 관리자가 볼 수 있다”는 의미입니다. 기업은 Sites를 켜기 전에 사용자 교육에 이 사실을 넣어야 합니다. 개인 메모처럼 쓰면 안 되는 공간이고, 부서 내부 실험이라도 워크스페이스 관리 영역 안에 들어갑니다.

세 번째 항목은 비활성화입니다. 같은 문서는 Workspace settings > Sites에서 기존 사이트를 disable할 수 있다고 설명합니다. 사내 앱 도구에서 삭제와 비활성화는 작은 기능처럼 보이지만, 실제 운영에서는 핵심입니다. 잘못된 데이터가 들어간 재무 planner, 퇴사자가 만든 고객 리뷰 페이지, 만료된 출시 hub, 권한이 넓게 열린 프로젝트 board를 빠르게 내릴 수 있어야 합니다. Sites가 기본 활성화된 Business 워크스페이스에서는 이 화면을 누가 매일 보는지가 바로 운영 질문입니다.

네 번째 항목은 약관입니다. ChatGPT Sites Terms는 ChatGPT Sites를 Beta Service로 규정합니다. 또 사용자가 언제든 사이트를 제거하거나 unpublished 상태로 만들 수 있고, OpenAI도 Agreement 위반이나 위해 가능성이 있다고 판단하면 사이트를 삭제, 제거, 비공개, 비활성화할 수 있다고 적습니다. 베타 서비스라는 문구는 사내 운영 시스템으로 바로 격상하지 말라는 신호입니다. 고객 대응, 재무 판단, 규제 문서처럼 책임이 큰 업무에는 별도 검증과 백업 경로가 필요합니다.

다섯 번째 항목은 사용량입니다. Help Center는 Codex usage가 plan별 agentic usage limit에 포함되며, Codex, ChatGPT for Excel, Workspace Agents 사용량이 agentic usage로 계산된다고 설명합니다. Sites는 화면상으로는 작은 앱이지만, 생성과 수정, 데이터 분석, annotation 반복이 모두 에이전트 사용량을 씁니다. 부서별로 Sites를 만들기 시작하면 비용 논의는 “누가 ChatGPT를 많이 쓰는가”보다 “어떤 업무 앱이 계속 갱신되는가”로 바뀝니다.

OpenAI가 같이 공개한 역할별 plugin도 Sites와 맞물립니다. 제품 글은 여섯 개 role-specific plugin이 62개 앱과 110개 skill을 포함한다고 설명합니다. 데이터 분석 plugin은 Snowflake, Databricks Genie, Hex, Tableau 같은 도구를 언급하고, sales plugin은 Salesforce, HubSpot, Slack, Outreach, Clay, Rox, Actively를 예로 듭니다. 이런 plugin이 Sites와 결합되면, 데이터와 업무 도구에서 뽑은 맥락이 URL 형태의 앱으로 굳어질 수 있습니다.

이 지점에서 shadow IT 문제가 다시 나타납니다. 과거의 shadow IT는 부서가 SaaS를 몰래 구매하거나, 스프레드시트와 노코드 도구로 업무 시스템을 만든 형태였습니다. Sites는 그보다 빠릅니다. 프롬프트 하나로 고객 리뷰 앱을 만들고, annotation으로 차트와 문구를 고치고, URL을 팀에 공유합니다. 개발팀의 티켓 큐를 줄이는 장점은 분명하지만, 데이터 출처, 권한, 소유자, 만료일, 변경 이력이 없으면 같은 속도로 shadow app이 쌓입니다.

그렇다고 이 기능을 단순히 막는 답도 약합니다. 현업 부서가 매번 개발팀에 작은 대시보드, 비교표, 플래너, 계정 리뷰 페이지를 요청하면 병목이 생깁니다. Sites가 유용한 영역은 명확합니다. 일회성 고객 리뷰, 내부 워크숍, 출시 준비, 가정 비교, 교육 자료, 프로젝트 상태판처럼 빠른 조립과 짧은 수명이 맞는 업무입니다. 이 작업은 정식 제품 개발 프로세스에 태우면 느리고, 문서만으로 처리하면 상호작용이 부족합니다.

반대로 운영 시스템으로 쓰면 위험한 영역도 명확합니다. 고객 데이터 쓰기, 결제 승인, 인사 평가, 법무 검토 최종본, 재무 공시, 프로덕션 배포, 규제 제출은 Sites의 프리뷰 성격과 맞지 않습니다. 이런 업무에서 Sites를 쓴다면 초안, 비교, 준비 자료로 제한하고, 최종 기록과 승인 시스템은 별도로 유지해야 합니다. “Codex가 만든 사이트”와 “조직의 공식 시스템” 사이에 선을 긋는 문서가 필요합니다.

관리자가 당장 정할 수 있는 정책은 네 가지입니다. 첫째, Sites 생성 권한을 어느 역할에 줄지 정합니다. 둘째, 사이트 이름, 소유자, 부서, 만료일, 데이터 출처를 작성하게 합니다. 셋째, 고객·재무·보안 데이터를 포함한 사이트는 공유 전 검토를 요구합니다. 넷째, 일정 기간 활동이 없거나 소유자가 떠난 사이트를 비활성화하는 절차를 만듭니다. OpenAI가 제공하는 토글은 시작점이지 운영 정책 전체가 아닙니다.

개발팀에는 다른 기회도 있습니다. 반복적으로 만들어지는 Sites를 보면 어떤 내부 앱이 실제로 필요한지 알 수 있습니다. 세일즈 팀이 매주 계정 리뷰 사이트를 만들고, 재무 팀이 매월 scenario planner를 만들고, 제품 팀이 매 출시마다 launch hub를 만든다면, 그중 일부는 정식 시스템으로 승격할 가치가 있습니다. Sites는 요구사항 문서가 아니라 작동하는 프로토타입 로그가 됩니다.

보안팀은 프롬프트와 결과물만 볼 것이 아니라 공유 범위를 봐야 합니다. 내부 URL은 외부 공개보다 안전하지만, 모든 내부자가 봐도 되는 정보는 드뭅니다. 특히 role-specific plugin이 CRM, BI, 문서, 디자인 도구와 연결될 때 Sites는 여러 시스템의 정보를 한 화면에 합칩니다. 원래는 각 시스템의 권한 경계가 따로 있었는데, Codex가 만든 페이지가 그 경계를 재조합할 수 있습니다. 이 조합 권한을 어떻게 감사할지가 관건입니다.

경쟁 구도에서는 Microsoft와 Google, 노코드 앱 빌더가 함께 보입니다. Microsoft 365 Copilot은 Word, Excel, PowerPoint, SharePoint, Teams 안에서 업무 산출물과 에이전트 경험을 묶습니다. Google Workspace Gemini도 문서와 스프레드시트, 앱 스크립트, Gemini 기반 업무 흐름을 넓히고 있습니다. Replit, Lovable, Base44, Wix, Vercel 같은 도구는 이미 “프롬프트에서 앱” 영역을 밀고 있습니다. OpenAI의 차별점은 ChatGPT 워크스페이스와 Codex, plugin, annotation을 한 계정 경계 안에 묶는 방식입니다.

OpenAI가 Sites partner ecosystem 후보로 Vercel, Wix, Base44, Replit, Lovable, Figma, Webflow, Emergent를 언급한 것도 이 방향을 뒷받침합니다. 지금은 워크스페이스 내부 공유가 중심이지만, 파트너 생태계가 붙으면 “내부 실험용 사이트”와 “외부 고객용 앱” 사이의 경계가 더 복잡해질 수 있습니다. 기업은 프리뷰 단계부터 외부 배포 가능성이 생겼을 때 어떤 심사와 소유권 규칙을 적용할지 미리 정해야 합니다.

커뮤니티 반응은 아직 제한적입니다. 2026년 6월 3일 검색 기준 Hacker News와 GeekNews에서 ChatGPT Sites 자체를 크게 다룬 독립 토론은 확인하지 못했습니다. Techmeme 계열 요약에는 OpenAI가 Codex를 ChatGPT로 확장하고 shareable interactive Sites를 소개했다는 제목이 잡혔습니다. 아직은 사용자 경험보다 공식 발표와 관리 문서가 먼저 나온 상태입니다. 그래서 지금 읽어야 할 문서는 제품 글보다 Help Center와 Terms입니다.

이번 발표를 “OpenAI도 노코드 앱 빌더를 냈다”로만 읽으면 좁습니다. Sites는 비개발자가 작은 앱을 만드는 기능이지만, 더 큰 변화는 배포권의 이동입니다. 업무에 가장 가까운 사람이 직접 앱을 만들고, URL로 공유하고, Codex에게 계속 업데이트를 맡깁니다. 개발팀은 모든 요청을 구현하는 팀에서, 어떤 앱을 허용하고 어떤 앱을 정식 시스템으로 승격할지 판단하는 팀으로 이동합니다.

따라서 ChatGPT Business나 Enterprise 관리자는 기능 소개보다 설정 화면을 먼저 봐야 합니다. Business는 기본 활성화라는 문구가 있으므로, 이미 사용할 수 있는 사용자가 있을 수 있습니다. Enterprise는 Early Access 토글이지만, pilot을 시작하면 admin 접근, 비활성화 절차, 데이터 출처 표기, 만료 정책을 함께 넣어야 합니다. Sites는 편리한 프리뷰 기능이면서, 동시에 조직 안의 작은 앱이 얼마나 빨리 늘어날 수 있는지 보여주는 테스트입니다.

개발자에게 남는 질문은 간단합니다. “이 앱을 누가 만들었는가”보다 “이 앱이 어떤 데이터를 읽고, 누가 보고, 언제 내려가며, 언제 정식 시스템이 되는가”입니다. ChatGPT Sites는 Codex를 코딩 도구에서 업무 앱 생성 표면으로 한 칸 더 밀어냅니다. 그 다음 병목은 모델 성능보다 워크스페이스 거버넌스입니다.