Sites and the Next Generation of Web Apps

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Sites가 제시하는 차세대 웹 앱은 Codex로 만들고, 플러그인과 예약 작업으로 최신 상태를 유지하며, 사람과 에이전트가 함께 사용하는 개인화된 풀스택 앱이다.

📌 핵심 요점

1. Sites는 웹 호스팅을 넘어 앱 제작·배포·운영을 묶는다. 내부 도구의 배포 불편을 해결하려던 Codex 기반 프로토타입에서 출발했으며, 발표자는 800만 개 Sites를 호스팅하고 OpenAI 직원의 70% 이상이 직접 Sites를 만든다고 설명한다.
2. 스프레드시트와 자연어 요청으로 업무 앱을 만들 수 있다. 시연에서는 출시 일정표를 목록·보드·달력 보기, 제품별 필터, 문서 링크를 갖춘 출시 현황 앱으로 전환했다.
3. 플러그인·예약 작업·SQLite가 데이터 갱신을 연결한다. 외부 문서의 변경 내용을 주기적으로 가져와 데이터베이스에 반영하므로, 표시 데이터만 바뀔 때는 소스 수정이나 재배포가 필요하지 않다는 설명이다.
4. 로그인과 사용자별 커넥터가 개인화된 협업을 지원한다. 같은 사이트에서도 각자의 Linear 티켓을 보여주고 수정 내용을 원래 서비스에 저장하며, 편집자 권한과 맞춤 주석으로 앱 자체의 공동 수정도 돕는다.
5. WebMCP는 에이전트가 웹 앱의 도구를 호출해 행동하도록 연결한다. 선물 상자 시연에서는 Slack의 취향 정보를 활용해 상품을 추천하고, 화면을 갱신하며, 사람이 선택을 조정하는 흐름을 보여준다.

🧩 배경과 문제 정의

Sites의 출발점은 연구자를 위한 내부 웹 앱을 OpenAI 인프라에 배포하기 어렵다는 문제였다. John은 Codex에서 풀스택 앱을 직접 배포하는 프로토타입을 만들었고, 엔지니어에 이어 비엔지니어도 사용하면서 팀 구성과 제품 출시로 이어졌다고 설명한다.

발표는 이 제작 방식을 실제 업무 데이터와 연결한다. 출시 일정표는 전체 현황을 보기에는 편하지만 프로젝트별 세부 내용을 탐색하기 어렵고, 앱으로 바꾼 뒤에도 원본 문서의 변경을 반영해야 한다. 여기에 방문자별 데이터, 공동 편집, 에이전트의 앱 조작을 차례로 더하면서 차세대 웹 앱의 구성을 보여준다.

🕒 시간순 섹션별 상세정리

1. 내부 배포 문제에서 출발한 Sites

• Developer Experience 팀의 Katia와 Sites 리드 엔지니어 John이 발표를 시작한다. John은 내부 연구용 웹 앱의 배포 불편을 줄이기 위해 Codex에서 직접 배포하는 프로토타입을 만들었다고 보여준다. [00:51]
• 프로토타입이 비엔지니어까지 확산된 뒤 Sites로 출시됐으며, 발표자는 호스팅 중인 Sites가 800만 개이고 OpenAI 직원의 70% 이상이 직접 제작에 참여한다고 드러낸다. [01:22]
• 내부 도구, 대화형 발표, 스프레드시트 대체 UI, 프로토타입 등으로 쓰이며, 맥락·플러그인·에이전트 연결이 개인화와 협업을 돕는다고 보여준다. [02:10]

2. 출시 일정표를 업무 앱으로 바꾸는 요청

• 발표는 단일 프롬프트로 사이트를 만들고, 협업과 개인화를 추가한 뒤 에이전트가 사용하기 좋게 확장하는 순서로 진행된다. [02:23]
• 시연용 일정표에는 DevDay 출시 항목, 진행 상황, 관련 문서와 자산 링크가 있지만, 프로젝트별 세부 정보를 확인하기에는 불편하다고 보여준다. [03:06]
• Codex에 새 폴더에서 출시 현황 앱을 만들고 게시하도록 요청한다. 공유 UI 라이브러리, 주요 일정과 주의 항목, 제품별 필터, 목록·보드·달력 보기, 문서 접근을 요구한다. [03:47]

3. 플러그인과 예약 작업으로 최신 정보 유지

• 앱을 생성하는 동안, 시트에 연결된 출시 설명 문서를 활용해 매일 아침 사이트를 갱신하라는 요청을 추가한다. 이 과정에 플러그인과 예약 작업이 사용된다고 보여준다. [04:14]
• 플러그인은 커넥터와 스킬을 묶어 ChatGPT와 Codex가 외부 서비스 데이터에 접근하게 한다. Linear 작업 조회, Slack 검색, GitHub PR 댓글 작성이 예시로 드러난다. [04:55]
• 스레드에서 시간·일·주 단위 작업을 예약할 수 있고, 시연에서는 Google Drive 플러그인으로 관련 문서를 가져오도록 한다. [05:24]

4. 데이터베이스 갱신과 기본 비공개 인증

• Sites에 SQLite 데이터베이스가 포함돼 있어, 표시 데이터가 바뀔 때 예약 작업이 데이터베이스를 직접 갱신할 수 있다. 이 경우 소스 수정이나 재배포를 생략한다고 보여준다. [05:42]
• 발표 당일의 추가 기능으로 사이트와 예약 작업의 연결 및 관련 상황에서의 예약 제안을 보여준다. [05:53]
• 사이트는 기본적으로 비공개이며, Sign-in with ChatGPT로 방문자를 확인한 뒤 접근을 허용한다. 공개 사이트에는 익명 방문용 화면과 로그인 후 기능을 둘 수 있다고 보여준다. [06:43]

5. 방문자별 커넥터를 이용한 개인화

• 비공개 사이트에 로그인한 팀원이 자신의 ChatGPT 플러그인을 가져올 수 있게 됐다고 보여준다. Drive·Slack·Linear 및 내부 전용 커넥터가 예시다. [07:03]
• 같은 사이트라도 방문할 때 각자의 커넥터로 데이터를 가져오므로 서로 다른 개인 데이터를 볼 수 있다는 구조를 보여준다. [07:23]
• 기존 앱에 Linear 읽기·쓰기 연결을 추가해 각자에게 배정된 티켓을 관련 출시 항목과 함께 표시하고, 상태나 설명을 수정해 Linear에 저장하도록 요청한다. [08:01]

6. 생성 결과 확인과 공유·운영 설정

• 생성된 앱에서 출시 항목, 보드·달력 보기, 요청한 디자인 시스템을 확인한다. 발표자는 설명이 진행되는 몇 분 동안 앱이 만들어졌다고 드러낸다. [08:45]
• 특정 동료를 초대하고 편집자로 지정하는 과정을 보여준다. 편집자 권한이 있으면 워크스페이스에서 호스팅된 사이트에 업데이트를 반영할 수 있다고 보여준다. [09:57]
• 사이트에 연결된 예약 작업도 확인한다. 이 작업은 Drive 문서의 변경 내용을 바탕으로 매일 사이트를 갱신하도록 구성됐다. [10:23]

7. 사용자별 티켓 조회와 쓰기 작업 시연

• Katia의 화면에는 자신의 Linear 티켓이 나타나고, John이 같은 사이트를 열면 John에게 배정된 티켓이 표시된다. 접속 시 각자의 기존 ChatGPT 커넥터에서 데이터를 가져온다고 보여준다. [11:24]
• 이 연결에서는 별도의 외부 서비스 API 키나 API 문서 작업 없이 기존 커넥터를 활용할 수 있다고 보여준다. [11:43]
• John은 티켓 상태를 진행 중으로 변경하고 저장한다. 시연 화면에서 저장 완료를 확인한다. [12:07]

8. 맞춤 주석으로 공동 편집 지원

• 앱 내부 브라우저의 주석 기능으로 바꿀 요소를 지정할 수 있다. 새로 소개한 주석 확장은 개발자가 HTML에 맞춤 조작 항목과 추천 프롬프트를 넣어 편집 방법을 안내하는 기능이다. [13:08]
• John은 내장된 추천 프롬프트와 상태 표시 요소의 크기 선택지를 확인하고, 선택한 모양을 즉시 미리 본다. [13:52]
• 실제 변경 반영은 Codex에 요청하는 단계로 계속된다. 발표자는 이런 옵션을 HTML에 넣으면 다른 사람이 사이트 수정에 기여하기 쉬워진다고 보여준다. [14:29]

9. 외부 사용자용 선물 앱과 API 연결

• 내부 협업 앱에 이어 일반 인터넷 사용자를 위한 선물 상자 제작 앱을 보여준다. 카메라로 사진을 찍고 상자 디자인을 생성한다. [15:18]
• 디자인 생성에는 OpenAI 이미지 API가 사용된다. Sites의 환경 변수에 API 키 같은 비밀값을 추가할 수 있어 다른 외부 서비스도 연결할 수 있다고 보여준다. [15:36]
• 다음 단계는 상자에 넣을 상품 선택이다. 발표자는 카탈로그를 직접 탐색하는 대신 에이전트에 맡기는 흐름으로 전환한다. [15:59]

10. WebMCP로 취향에 맞는 상품 추천

• WebMCP를 에이전트가 사이트에 노출된 도구를 호출하도록 하는 새 브라우저 표준으로 보여준다. 지원 브라우저에서는 도구 실행으로 사용 중인 앱을 갱신할 수 있다고 보여준다. [16:21]
• 화면의 항목을 하나씩 클릭하는 방식과 달리 도구로 백엔드를 직접 조회할 수 있어, 용도에 따라 더 빠르고 저렴할 수 있다고 드러낸다. [16:54]
• Slack 대화에서 John의 취향을 찾아 카탈로그 상품을 추천하고 화면에 표시하도록 요청한다. 에이전트는 대화를 읽은 뒤 반려견 장난감 등을 추천한다. [17:48]

11. 사람이 추천을 조정하고 메시지를 완성

• 발표자는 추천 상품 일부를 직접 제거하며 약 100달러 이내로 구성하려고 한다. 같은 화면에서 사람과 에이전트가 선택을 이어가는 모습을 보여준다. [18:12]
• 상품을 장바구니에 넣은 뒤, 이전 대화를 바탕으로 개인화된 메시지를 작성하고 UI에 반영하도록 요청한다. [18:41]
• 사용자 에이전트가 알고 있는 맥락으로 앱에서 행동하도록 연결하는 방식을 설명한 뒤, 생성된 메시지를 확인하고 선물 상자를 확정한다. [19:09]

12. 사람과 에이전트를 위한 웹 앱으로 마무리

• 사용자가 자신의 에이전트와 함께 웹을 이용하는 흐름에 맞춰 앱을 설계하라고 제안한다. Sites 플러그인이 WebMCP 구현을 알고 있어 관련 상황에서 자동으로 추가될 것이라고 보여준다. [19:43]
• Sites를 자동 갱신되는 사이트이자 인증·데이터베이스·플러그인 데이터 접근을 갖추고 자동 확장하는 풀스택 앱으로 정리한다. [20:15]
• 맞춤 주석과 WebMCP를 활용해 사람과 에이전트가 앱에 기여하고 상호작용하기 쉽게 만들라는 제안으로 발표를 마친다. [20:33]

🧾 결론

• 발표의 중심은 웹페이지 생성에서 끝나지 않는다. 제작 이후의 데이터 갱신, 사용자 인증, 개인화, 공동 편집, 에이전트 실행을 하나의 앱 경험으로 연결한다.
• 개인화에는 두 경로가 등장한다. 사이트가 방문자의 기존 커넥터로 데이터를 가져오는 방식과, 사용자 에이전트가 자신의 맥락을 활용해 사이트의 도구를 실행하는 방식이다.
• 사람은 결과를 확인하고 선택을 조정하며, 에이전트는 데이터 조회와 앱 조작을 맡는다. 시연이 제시하는 차세대 웹은 이 협업을 화면 안에서 이어가는 구조다.

📈 투자·시사 포인트

• 업무 소프트웨어의 제작 단위가 팀별·개인별 맞춤 앱으로 넓어질 가능성을 보여준다. 발표에서 제시한 스프레드시트 대체와 내부 도구 사례는 이러한 수요를 살펴볼 출발점이다.
• 플랫폼을 평가할 때 생성 화면의 완성도와 함께 데이터 연결, 갱신 자동화, 인증, 공동 편집까지 확인필요가 있다. Sites는 이 기능들을 결합하는 방향을 제시한다.
• 에이전트가 호출할 도구와 사람이 사용할 화면을 함께 설계하는 역량이 중요해질 수 있다. WebMCP와 맞춤 주석은 각각 실행과 편집을 지원하는 접점으로 소개된다.
• 호스팅 수와 내부 사용률은 발표자가 제시한 채택 지표다. 매출, 유료 전환, 운영 비용, 수익성 자료가 없어 사업 성과나 투자 매력으로 바로 환산하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• 800만 개 Sites와 직원 70% 이상의 제작 참여는 발표 시점의 자체 제시 수치다. 활성 이용, 지속 사용, 유료 사용의 정의와 측정 기간은 설명되지 않는다.
• WebMCP가 화면 클릭 방식보다 빠르고 저렴할 수 있다고 설명하지만, 적용 조건이나 비교 실험 수치는 제공하지 않는다. 자동 확장의 처리 한도와 운영 비용도 확인되지 않는다.
• 기존 커넥터와 로그인으로 접근을 처리하는 흐름은 소개하지만, 세부 권한 범위, 데이터 저장·보존, 외부 서비스 쓰기 작업의 통제 방식은 충분히 다루지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 확인하는 업무용 시트 하나를 골라, 첫 화면에 필요한 정보·필터·보기 방식·문서 링크를 정리한다.
• 원본 문서와 갱신 주기를 지정해 예약 작업을 구성하고, 문서 변경이 앱 데이터에 반영되는지 확인한다.
• 서로 다른 두 사용자로 접속해 각자의 커넥터 데이터가 표시되는지, 수정 내용이 해당 서비스에 저장되는지 검증한다.
• 사이트 열람 권한과 앱 편집 권한을 구분하고, 공동 편집에 필요한 맞춤 주석과 미리보기 항목을 정한다.

❓ 열린 질문

• 사용자별 커넥터 데이터와 사이트의 공용 데이터베이스는 어떤 기준으로 분리되고 관리되는가?
• 예약 작업 실패, 원본 문서 간 충돌, 외부 서비스 쓰기 오류가 발생했을 때 어떻게 감지하고 복구하는가?
• WebMCP가 실제 업무에서 화면 클릭 방식보다 유리해지는 작업 규모와 비용 조건은 무엇인가?