How the OpenAI team uses ChatGPT Sites daily
원본 영상: How the OpenAI team uses ChatGPT Sites daily
채널: How I AI
개요
AI로 웹사이트를 만드는 일과 그 사이트를 일상에서 사용하는 일 사이에는 여러 단계가 있다. 업무 데이터를 연결하고, 동료와 공유하고, 다른 사람이 접속할 수 있도록 배포해야 한다. 이 대화에서 OpenAI의 Sites 제품 리드는 ChatGPT Sites가 이 과정을 어떻게 돕는지 실제 활용 사례로 설명한다.
첫 사례는 팀의 장애 대응 상황을 확인하는 업무 도구다. 이어 개인 음악 플레이리스트, 다른 사람이 방을 만들어 보탤 수 있는 던전 게임, 커뮤니티의 사이트 갤러리로 이야기가 확장된다. 진행자도 직접 만든 게임과 스케치 앱을 소개하며 AI가 창작 방식을 어떻게 바꾸고 있는지 이야기한다.
대화를 관통하는 생각은 소프트웨어를 반드시 오래 사용할 완성품으로만 만들 필요는 없다는 것이다. 팀의 업무 방식에 맞춰 계속 고쳐 쓸 수도 있고, 출장 기간에만 사용한 뒤 버릴 수도 있다. 이미 사용하는 도구와 앞으로 구현하려는 구상이 함께 등장하는 만큼, 각 사례의 현재 작동 방식도 함께 살펴볼 필요가 있다.
동료를 방해하지 않고 장애 상황을 파악하기
제품 리드가 처음 소개하는 것은 Sites 팀의 장애 대응 현황을 모아 보여주는 ‘인시던트 커맨드’ 사이트다. 제품 관리자로서 회의와 다른 업무를 병행하다 보면 장애 대응 과정을 계속 따라가기 어렵다. 그렇다고 담당자에게 수시로 상황을 물으면 문제를 해결하는 사람들의 집중을 끊게 된다. 이 사이트는 대응에 끼어들지 않으면서도 현재 상황을 파악하려는 필요에서 출발했다.
사이트는 진행 중인 장애의 타임라인과 대응 담당자, 참고할 절차를 연결한다. Slack에서 팀의 관련 정보를 가져오고, Notion에서는 런북과 대응 가이드를 불러온다. 더 자세한 내용이 필요하면 Notion의 원래 문서로 이동할 수 있다고 설명한다.
이 도구의 역할은 장애를 직접 해결하는 것보다 흩어진 업무 맥락을 한곳에서 확인하도록 돕는 데 있다. 현재 상황과 담당자, 대응 절차를 함께 볼 수 있으면 사람에게 반복해서 묻거나 여러 도구를 오가는 부담이 줄어든다.
제품 리드는 민감한 내용을 정리하고 시연용으로 사이트를 다시 만들었다고 밝힌다. 여기서 주목할 부분은 개별 장애의 내용보다 팀의 정보를 묶어 보는 방식이다.
같은 사이트를 각자의 데이터로 사용하기
제품 리드는 행사 당일 발표한 ‘plugins and sites’를 소개하며, 사이트 방문자가 자신에게 연결된 플러그인을 활용할 수 있다고 설명한다. 시연에서는 사용자가 로그인하고 연결을 승인한 뒤 Notion, Slack, 캘린더의 정보를 사용하는 흐름을 보여준다.
사이트는 승인된 Slack 채널 등의 정보를 바탕으로 사용자의 팀을 추정하고, 그 팀에 맞는 장애 대응 정보를 구성하도록 만들어졌다. 진행자가 같은 사이트를 다른 동료에게 공유하면 어떻게 되는지 묻자, 제품 리드는 사이트는 같아도 표시되는 데이터는 방문자에 따라 달라진다고 답한다. 같은 팀 동료는 비슷한 내용을 볼 수 있지만, Codex 팀이나 다른 팀의 방문자는 자신의 연결과 팀 맥락에 맞는 정보를 보게 된다는 설명이다.
이는 제작자가 보고 있던 데이터 사본을 배포하는 방식과 다르다. 공통된 인터페이스에 각 방문자가 승인한 연결의 데이터를 결합하는 것이다. 제품 리드는 역할과 책임에 따라 서로 다른 정보를 다루는 데이터팀이나 재무팀에서도 이런 방식이 유용할 수 있다고 본다.
연결 기능을 요청할 때는 업무의 목적부터 설명하기
진행자는 Sites를 정적인 문서나 프로토타입을 게시하는 공간으로 이해하기 쉽다고 말한다. HTML로 만든 제품 요구사항 문서나 발표 자료를 올리는 용도는 쉽게 떠올릴 수 있지만, 실제 업무 데이터를 가져오는 앱도 만들 수 있다는 점은 덜 드러났다는 것이다.
그렇다면 이런 사이트를 만들 때 어떤 요청을 해야 할까. 제품 리드는 Codex가 사용자의 의도를 이해하고 필요한 연결 방식을 판단할 수 있다고 설명한다. 예를 들어 Notion 문서를 가져와 캘린더와 교차 참조하는 웹사이트를 요청하고, 팀이 함께 사용할 도구라는 맥락을 덧붙이는 식이다. Codex는 플러그인 커넥터를 사용할지 질문하거나, 먼저 구성한 뒤 결과를 설명하고 피드백을 요청할 수 있다고 한다.
연결 방식을 명시하고 싶을 때 쓰는 표현으로는 “bring your own connector”와 “plugins in sites”를 든다. 핵심은 특정 문구를 외우는 것보다 방문자가 자신의 연결을 사용하는 사이트가 필요하다는 의도를 전달하는 데 있다.
그가 자주 사용하는 도구는 Slack, Notion, Google Drive, Google Calendar다. 어떤 연결을 선택할지는 팀이 실제로 어디에서 협업하는지에 따라 달라진다.
오래 쓰는 팀 도구와 잠깐 쓰는 개인 앱
제품 리드는 Sites의 활용 범위를 작은 프로토타입부터 본격적인 내부 도구까지 넓게 본다. 팀의 부재 일정 관리나 음악 공유처럼 구체적인 필요에 맞춰 만들고, 팀이 변하거나 필요한 기능이 늘어나면 사이트도 수정한다는 것이다.
그가 말하는 개인화는 기존 제품의 설정을 조금 바꾸는 데 그치지 않는다. 사람마다 생각하는 방식이 다르고 팀마다 협업 방식이 다르므로, 자신의 업무에 맞는 인터페이스를 직접 만들 수 있다는 설명이다.
출장용 캘린더는 이 생각을 잘 보여준다. 평소 사용하는 Google Calendar 화면 대신 특정 출장 주간에 필요한 방식으로 일정을 정리하고, 그 기간이 끝나면 사이트를 버릴 수도 있다. 오래 유지할 제품을 만드는 것뿐 아니라 지금 필요한 관점을 빠르게 구성하는 데도 의미가 있다는 이야기다.
Codex로 만든 소프트웨어를 실제로 배포하기
제품 리드는 Sites의 출발점을 Codex로 만든 소프트웨어를 올려둘 곳이 필요했다는 말로 설명한다. 로컬 컴퓨터에 웹사이트를 만드는 것만으로는 다른 사람이 사용할 수 없다. 배포와 운영 설정이 남아 있고, 사용자는 이 단계에서 어려움을 겪곤 했다는 것이다.
그의 설명에서 Codex는 사이트 제작을, Sites는 배포를 담당한다. 공동 편집자와 저장 기능도 지원하므로 활용 범위가 정적인 페이지 게시에만 머무르지 않는다고 덧붙인다.
사용자들은 이 기반을 플러그인 제작, 데이터 호스팅, 평가 실행에도 활용하기 시작했다. 제품 리드는 Sites에서 MCP 플러그인을 호스팅하고, 그렇게 만든 플러그인을 다시 사이트에서 사용하는 기능도 소개한다.
12:09 - Sites에서 MCP 플러그인을 호스팅하고 사이트에 활용하는 기능 소개
진행자는 지원 범위가 넓어질수록 어떤 작업을 Sites에서 처리하고 어떤 작업을 별도 클라우드에 배포할지 판단하는 일이 중요해질 것이라고 짚는다. 대화에서는 이를 제작 가능성이 커지면서 함께 등장하는 선택의 문제로 다룬다.
나만의 음악을 찾는 플레이리스트
개인적인 활용 사례는 가족이 함께 사용하는 음악 서비스에서 시작한다. 제품 리드는 아이들이 Spotify를 사용하면서 자신의 음악 경험이 어린이 콘텐츠 중심으로 바뀌었다고 말한다. 새로운 음악을 찾고 싶지만 직접 탐색할 시간은 부족했다.
그가 만든 ‘Heavy Rotation’은 Reddit에서 사람들이 공유하고 호응하는 음악을 찾아 플레이리스트로 만드는 사이트다. 원하는 방향을 마크다운 파일에 적으면서 모바일에서 편하게 사용할 수 있고 조작이 단순해야 한다는 요구를 담았다.
그는 이 작업에 computer use를 활용하고 정기적으로 실행되도록 자동화를 설정했다고 설명한다. 그렇게 만든 플레이리스트를 일하면서 듣는 방식이다.
진행자는 Spotify 플러그인이 음악을 검색하고 재생하는 구조로 이해했지만, 제품 리드는 이 사례에서 Spotify를 플레이어로 사용한다고 답한다. 자동화가 실행되려면 노트북을 켜 둬야 하며, 로컬 컴퓨터의 음악과 Apple Music을 참조할 수도 있다고 덧붙인다.
이 사례는 사이트, 음악 플레이어, 로컬 자동화를 결합한 개인 작업 방식이다. 자신이 원하는 음악을 발견할 경로를 따로 만들고, 그 결과를 사용하기 편한 인터페이스에 담았다는 점이 핵심이다.
게임을 공유하는 데서 함께 만드는 데로
게임 이야기에서 제품 리드가 관심을 두는 것은 다른 사람의 창작물이 모이는 커뮤니티다. 사이트를 만들면 URL로 공유할 수 있다. 그는 여기서 더 나아가 각자의 결과물이 하나의 공동 프로젝트로 이어질 수 있는지 실험한다.
소개한 던전 탐험 게임에서는 사용자가 직접 방을 만들 수 있다. 이를 위해 준비한 ‘DungeonSite’ 스킬에는 방의 크기, 플레이어와 조작 방식 등 새 방이 게임에 들어가기 위해 따라야 할 조건이 담긴다고 설명한다.
사용자는 스킬을 설치한 뒤 달 표면이나 화산처럼 원하는 공간을 요청할 수 있다. 제품 리드는 자신도 새로운 방을 만들었으며, 다음 던전으로 이어지게 할지 그 방에서 게임을 끝낼지 선택했다고 말한다.
그가 구상한 참여 방식은 사람들이 각자 만든 방을 공유하면 자신이 던전에 추가하는 것이다. 서로 방을 플레이하고, 어떤 방이 재미있는지 이야기하고, 그 결과를 다시 게임에 보태는 커뮤니티를 만들고 싶다는 설명이다.
진행자는 스킬이 새로운 참여 경로가 될 수 있다는 점에 주목한다. 앱 안에 마련된 편집기를 사용하는 대신, 스킬을 받아 Codex가 정해진 규칙에 맞는 콘텐츠를 만들게 할 수 있다. 앱을 사용하는 방법뿐 아니라 앱에 기여하는 방법도 스킬로 전달하는 셈이다.
방문 기록과 제작 참여 사이
진행자가 사람들이 실제로 방을 만들고 있는지 어떻게 알 수 있느냐고 묻자, 제품 리드는 당시 분석 기능이 방문과 트래픽 중심의 가벼운 수준이라고 답한다. 누가 스킬을 사용해 무엇을 만들고 있는지 개발자가 직접 알 수 있는 것은 아니라는 설명이다.
그가 선택한 방법은 Twitter의 해시태그와 멘션을 통한 자발적 공유다. 사람들이 자신이 만든 것을 알리고, 서로 플레이하고, 대화하면서 커뮤니티가 자라기를 바란다. 그는 이 과정 전체를 AI에 맡기기보다 직접 사람들을 만나고 싶다고 말한다.
이후 소개한 ‘Awesome Sites’ 갤러리도 같은 관심에서 출발한다. 커뮤니티에 사이트를 보내 달라고 요청해 여러 사례를 모았으며, 대화에서는 피아노와 게임, 시뮬레이션 세계 등이 등장한다. 하이데라바드 버스 노선을 살펴보는 사이트도 그중 하나다.
제품 리드는 다른 사람의 작품이 새로운 제작 아이디어로 이어질 수 있다고 본다. 낯선 도시의 철도 이용법을 안내하는 작은 사이트처럼 여행이나 일상의 구체적인 필요도 출발점이 될 수 있다는 것이다.
자연어로 바꾸는 게임 세계와 추론 연결 실험
진행자는 직접 만든 게임에서 떠오르는 요구를 빠르게 반영했던 경험을 소개한다. 캐릭터의 방에 이층 침대를 추가하고, 정원의 계절을 바꾸고, 수중 장면에 해파리를 넣거나 중력을 없애 사물을 떠다니게 했다는 것이다.
그는 이런 경험을 통해 생성형 인터페이스의 가능성을 넓게 본다. 사용자의 요청에 따라 업무용 양식이나 위젯을 바꾸는 데서 나아가 게임 세계 자체를 바꾸는 상호작용이 흥미롭다는 의견이다. 로컬에서 게임을 만들고 수정하는 과정에서, 요구를 자주 반영할수록 모델 사용량과 비용도 늘었다고 이야기한다.
제품 리드는 사용자의 추론을 사이트 안으로 가져오는 기능을 실험하고 있다고 답한다. 사이트 방문자가 AI에게 변경을 요청하거나, 게임을 하는 사람이 자신의 모델 사용 자원을 활용해 원하는 요소를 만드는 방향이다.
당시 소개한 사이트 위젯은 요청하면 ChatGPT로 돌아가는 단순한 형태였다. 시연 중 원하는 대로 작동하지 않는 상황도 나타났다. 사이트 안에서 사용자가 직접 추론을 활용하는 경험은 팀이 탐색 중인 방향으로 제시된다.
아이에게 일정한 사용 예산을 주고 게임 속 사물을 직접 요청하게 한다는 이야기도 나온다. 두 사람은 이를 새로운 놀이와 창작 방식의 가능성으로 상상한다.
빠른 응답이 창작의 흐름에 미치는 영향
진행자는 어린 시절 게임 개발자가 되고 싶었지만, 아이디어를 결과물로 옮기는 데 필요한 기술과 제작 역량의 문턱이 높았다고 회상한다. 최근 모델을 활용하면서 만들고 싶었던 것에 더 가까워졌다는 것이다.
또 다른 사례는 사람과 모델이 함께 그림을 그리는 스케치 앱이다. 사용자가 캔버스에 무언가를 그리면 모델이 새로운 요소를 더한다. 언덕에 달팽이를 추가하거나 얼굴을 열기구로 바꾸는 식이다. 완성된 결과를 한 번에 주문하기보다 번갈아 다음 단계를 만들어 가는 경험이다.
두 사람은 하나를 만들면 다음 아이디어가 계속 떠오른다는 데 공감한다. 특히 진행자는 응답 속도가 창작의 흐름에 영향을 준다고 말한다. 오래 기다리면 다른 일로 주의가 옮겨가지만, 결과가 빠르게 돌아오면 곧바로 다음 시도를 이어갈 수 있다는 설명이다.
그의 경험에서 속도는 작업 시간을 줄이는 요소이자 아이디어를 계속 발전시키게 하는 조건이다.
자신의 이름으로 말하는 일의 경계
대화 말미에는 AI에게 어디까지 행동을 맡길지에 관한 이야기가 나온다. 제품 리드는 조사와 글쓰기 지원에 AI를 자주 사용하지만, 자신의 의도와 다르게 행동하거나 자신을 대신해 이메일을 보내고 사람들과 대화하기 시작하면 중단을 요구한다고 말한다.
그가 지키려는 것은 자신의 목소리다. AI가 쓴 문장에서 영감을 받을 수는 있어도, 자신의 이름으로 보내는 이메일과 Slack 메시지는 자신이 책임지고 말하는 것이어야 한다는 태도다.
진행자도 커뮤니티 Slack에서 봇이 자신을 대신해 글을 쓰고 사람들이 반응했던 경험을 소개한다. 그는 다른 참여자들에게 그 메시지를 쓴 사람이 자신이 아니라는 점을 알렸다고 한다.
두 사람은 AI를 활용해 더 많은 도구와 작품을 만들면서도, 자신의 이름으로 타인과 소통하는 행동에는 경계를 둔다. 무엇을 만들 수 있는지와 어떤 행동을 맡길지는 이 대화에서 함께 다뤄지는 문제다.
출처
How I AI — How the OpenAI team uses ChatGPT Sites daily