OpenAI가 Codex를 개발자용 코딩 에이전트에서 더 넓은 업무 에이전트 플랫폼으로 확장하고 있습니다. 그중 눈에 띄는 기능이 Sites입니다.
Sites는 Codex가 만든 웹사이트, 웹앱, 게임을 OpenAI가 호스팅하는 URL로 저장하고 배포하고 공유할 수 있게 해주는 기능입니다. 기존 Codex가 코드 수정, PR, 로컬 파일 생성에 가까웠다면, Sites는 결과물을 팀이 바로 써볼 수 있는 내부 제품 형태로 포장합니다.
이 글은 작성 시점 2026-06-03 · OpenAI 발표 ↗, Codex Sites 문서 ↗, Codex 플랜 안내 ↗ 기준으로 정리했습니다.
Sites가 하는 일
Sites의 핵심은 단순합니다.
Codex에게 웹 기반 산출물을 만들라고 지시하면, Codex가 앱을 만들고, 빌드하고, 저장 가능한 버전으로 묶고, 필요하면 OpenAI 호스팅 URL로 배포한다.
예를 들어 이런 요청이 가능합니다.
@Sites 고객 리뷰 미팅용 페이지를 만들어줘.
최근 제품 업데이트, 열린 질문, 사용량 추이, 다음 액션을 한 화면에서 볼 수 있게 해줘.
워크스페이스 안에서만 접근 가능하게 배포해줘.또는 이런 내부 도구도 가능합니다.
- 운영팀 요청 관리 대시보드
- 제품 출시 허브
- 고객 계정 리뷰 페이지
- 재무 시나리오 플래너
- 팀용 크리에이티브 브리프 저장소
- 간단한 게임이나 인터랙티브 데모
중요한 점은 Sites가 단순히 HTML 파일을 하나 만들어주는 기능이 아니라는 것입니다. Codex가 만든 결과물을 호스팅 가능한 프로젝트로 관리하고, 저장된 버전과 실제 배포를 나눠 다룰 수 있습니다.
flowchart TB
Prompt["사용자 요청<br/>@Sites"] --> Build["Codex가 사이트 생성·수정"]
Build --> Check["빌드 검증"]
Check --> Save["배포 후보 버전 저장"]
Save --> Review["검토"]
Review --> Deploy["승인된 버전 배포"]
Deploy --> URL["OpenAI 호스팅 URL"]왜 중요한가
AI 에이전트가 문서나 코드를 만드는 것만으로는 부족한 순간이 많습니다. 팀이 실제로 써보려면 배포, 접근 제어, 데이터 저장, 링크 공유 같은 주변 작업이 필요합니다.
Sites는 이 사이를 줄입니다.
기존 흐름은 보통 이랬습니다.
- Codex가 코드나 HTML 초안을 만듭니다.
- 사용자가 로컬에서 실행해봅니다.
- Vercel, Netlify, Cloudflare 같은 배포 환경을 따로 잡습니다.
- 접근 제어와 환경 변수를 설정합니다.
- 팀에 URL을 공유합니다.
Sites는 이 과정을 Codex 안으로 끌어옵니다. 그래서 비개발자 팀도 “웹앱 형태의 산출물”을 더 쉽게 요청할 수 있습니다. OpenAI가 이번 발표에서 분석가, 마케터, 운영 담당자, 디자이너, 연구자, 투자팀 같은 비개발 직군을 강조한 이유도 여기에 있습니다.
저장과 배포가 분리된다
Codex Sites 문서에서 특히 중요한 부분은 저장된 버전과 배포된 버전을 구분한다는 점입니다.
Sites에는 두 단계가 있습니다.
| 단계 | 의미 |
|---|---|
| 저장된 버전 생성 | 빌드 가능한 배포 후보를 만들고 검토할 수 있게 둠 |
| 버전 배포 | 선택한 저장 버전을 프로덕션 URL로 공개 |
OpenAI 문서는 모든 Sites 배포 URL을 프로덕션 배포로 취급하라고 설명합니다. 즉 “잠깐 확인해보려고 배포”했다고 해도, 접근 권한이 맞으면 실제 사용자가 볼 수 있는 상태입니다.
그래서 안전한 흐름은 이렇습니다.
- Codex에게 사이트를 만들게 합니다.
- 빌드 검증을 요청합니다.
- 바로 배포하지 말고 저장된 버전으로 둡니다.
- 소스 변경, 데이터 처리, 접근 범위, secrets 설정을 확인합니다.
- 승인한 저장 버전만 배포합니다.
데이터 저장도 지원한다
Sites는 단순 정적 페이지뿐 아니라 상태를 기억하는 앱도 염두에 둡니다. 문서 기준으로 구조화된 데이터가 필요하면 D1, 파일 업로드가 필요하면 R2 같은 저장소를 붙일 수 있습니다.
대략 이렇게 생각하면 됩니다.
| 필요한 것 | Sites에서 요청할 방향 |
|---|---|
| 정적 랜딩 페이지 | 별도 영속 상태 없는 사이트 |
| 요청 목록, 진행 상태, 점수 | D1 같은 구조화 데이터 저장소 |
| 이미지, 문서, 오디오 업로드 | R2 같은 오브젝트 저장소 |
| 파일과 검색 가능한 메타데이터 | D1 + R2 조합 |
| 내부 사용자 식별 | 워크스페이스 인증 사용자 정보 활용 |
이 부분이 Sites를 단순한 “AI 홈페이지 생성기”와 다르게 만듭니다. 팀 내부에서 쓰는 작은 업무 앱이라면, 데이터 저장과 로그인까지 포함한 형태로 빠르게 만들 수 있습니다.
다만 모든 상태를 서버 저장소에 넣을 필요는 없습니다. 테마 선택, 접은 배너 같은 임시 UI 상태는 로컬 상태로 충분합니다. 반대로 요청 목록, 고객별 메모, 게임 점수처럼 사용자가 다시 방문했을 때 남아 있기를 기대하는 데이터는 영속 저장소가 필요합니다.
접근 제어
Sites는 워크스페이스 내부 공유를 기본 사용처로 봅니다. 새 사이트는 처음부터 넓게 공개하기보다, 소유자와 관리자만 볼 수 있는 상태로 시작해 검토 후 접근 범위를 넓히는 편이 안전합니다.
문서에 나온 접근 모드는 다음과 같습니다.
| 접근 모드 | 접근 가능한 사람 |
|---|---|
| 소유자와 관리자만 | 사이트 소유자와 워크스페이스 관리자 |
| 워크스페이스 전체 | 워크스페이스의 활성 사용자 전체 |
| 사용자 지정 | 특정 사용자 또는 워크스페이스 그룹 |
이건 내부 도구를 만들 때 꽤 중요합니다. 고객 데이터, 매출 계획, 미공개 출시 자료 같은 내용이 들어갈 수 있기 때문입니다. Codex가 사이트를 잘 만들어도, 접근 범위가 넓으면 사고가 납니다.
기존 Codex와 무엇이 다른가
기존 Codex의 중심은 개발 워크플로우였습니다. 코드베이스를 읽고, 수정하고, 테스트하고, PR이나 패치를 만드는 흐름입니다.
Sites는 여기에 “공유 가능한 실행 결과물”을 붙입니다.
| 구분 | 기존 Codex | Codex Sites |
|---|---|---|
| 중심 결과 | 코드 변경, 파일, diff, PR | 호스팅된 웹사이트·웹앱 URL |
| 주요 사용자 | 개발자 | 개발자 + 분석가, 운영팀, 마케터, 디자인팀 |
| 검토 단위 | 소스 diff와 테스트 결과 | 소스 diff + 저장 버전 + 배포 URL |
| 공유 방식 | 저장소, PR, 로컬 실행 | 워크스페이스 내부 URL |
| 적합한 작업 | 기능 구현, 리팩터링, 테스트 작성 | 대시보드, 내부 도구, 프로젝트 허브, 데모 |
이 차이는 작지 않습니다. Codex가 만든 결과를 “개발자가 이어받는 코드”로 볼지, “팀이 바로 쓰는 업무 화면”으로 볼지의 차이입니다.
블로그 운영에 적용해보면
이 블로그를 예로 들면, Sites는 글 자체를 쓰는 데보다 글을 운영하는 내부 도구에 더 잘 맞습니다.
예를 들어 이런 것들입니다.
- 주간 다이제스트 후보 뉴스 검토 UI
- 기존 글과 새 후보의 중복 여부 대시보드
- 발행 캘린더와 예약 글 상태판
- 태그별 콘텐츠 공백 분석 화면
- 초안 품질 체크리스트
지금은 Codex나 자동화 스크립트가 글 초안을 만들고, 사람이 파일을 확인한 뒤 블로그에 반영하는 방식입니다. 여기에 Sites를 붙이면 “이번 주 후보 20개 중 어떤 걸 글로 만들지”를 웹 UI에서 고르고, 선택한 항목을 바탕으로 초안 생성을 요청하는 식의 운영 화면을 만들 수 있습니다.
즉 Sites는 블로그 포스팅 자동화 자체보다, 포스팅 자동화를 관리하는 작은 편집실 도구에 가깝게 쓰는 편이 좋아 보입니다.
지금 쓸 때 체크할 것
작성 시점 기준으로 Sites는 프리뷰 기능입니다. ChatGPT Business 워크스페이스에서는 기본 활성화되어 있고, Enterprise 워크스페이스에서는 관리자가 RBAC나 Early Access 설정에서 켜야 합니다. Enterprise와 Edu 쪽 릴리스 노트에서는 워크스페이스 설정과 역할 기반 접근 제어를 통해 활성화와 접근을 관리한다고 설명합니다.
실제로 써보려면 다음을 확인하면 됩니다.
- 사용 중인 워크스페이스가 Sites 프리뷰 대상인지 확인합니다.
- Codex 앱에서 Sites 플러그인을 추가합니다.
- 새 스레드를 시작합니다.
- 프롬프트에
@Sites를 명시하고 원하는 사이트의 사용자, 핵심 경험, 필요한 데이터를 설명합니다. - 배포 전 빌드 검증과 저장된 버전 생성을 요청합니다.
- 접근 범위와 secrets 설정을 확인한 뒤 승인한 버전만 배포합니다.
마무리
Codex Sites는 “AI가 웹사이트를 만들어준다”보다 조금 더 큰 변화입니다. Codex가 만든 결과물이 문서나 코드 조각에 머무르지 않고, 팀이 URL로 접속해 바로 써볼 수 있는 내부 도구가 됩니다.
이 방향은 Codex가 개발자 도구를 넘어 업무 플랫폼으로 확장되고 있다는 신호입니다. 앞으로 에이전트의 경쟁력은 코드를 잘 쓰는 능력뿐 아니라, 결과물을 얼마나 빨리 검토 가능한 형태로 만들고, 안전하게 공유하고, 계속 업데이트할 수 있게 하느냐에 달릴 가능성이 큽니다.
Sites는 그 흐름을 꽤 노골적으로 보여주는 기능입니다. Codex가 이제 코드를 쓰는 에이전트에서, 작은 내부 제품을 만들어 배포하는 에이전트로 움직이고 있습니다.