OpenAI DevDay 후기: Sites와 Plugins로 만들어 보고 싶은 것

평소 Claude, Codex, Grok bot 등 여러 AI를 사용한다. 새로운 기능을 직접 써보는 데에도 관심이 많지만, 도구를 고를 때는 지금 하려는 일에 얼마나 잘 맞는지를 먼저 생각한다. 작업에 따라 더 편하고 좋은 결과를 주는 AI가 달라, 필요에 맞게 골라 쓰는 편이다.

최근에는 SNS에서 OpenAI 모델에 대한 부정적인 평가를 자주 접했다. 평소 사용하는 도구에 관한 이야기인 만큼 신경이 쓰였다. 2026년 10월 22일 서울에서 열린 OpenAI DevDay Exchange에 참석할 때도 기대와 함께 약간의 걱정이 있었다.

행사에서 특히 눈에 들어온 것은 Sites와 Plugins였다. 이름은 알고 있었지만, 로그인과 데이터베이스를 갖춘 앱을 만들고 외부 도구까지 연결하는 모습을 보니 활용해 보고 싶은 일이 떠올랐다. 사용자가 이미 쓰는 도구를 연결하고, 필요한 정보를 모아 보여 주는 서비스도 그중 하나였다.

행사장에 선 일정판은 메인 스테이지와 브레이크아웃 스테이지를 두 줄로 나누고, 세션 제목을 영어와 한국어로 함께 적어 두었다. 무대에 오른 슬라이드도 모두 한국어로 옮겨져 있었다. 에이전트에게 주는 스킬 프롬프트까지. 객석에서는 휴대폰을 들어 슬라이드를 찍는 사람이 많았고, 나도 그중 하나였다.

Sites, 만들어 보고 싶은 것이 생겼다

Sites는 ChatGPT와 Codex에서 웹사이트와 앱을 만들고, 호스팅하고, 공유하는 기능이다. 발표에서는 로그인과 데이터베이스, 플러그인을 연결해 웹 앱을 만드는 과정을 보여 줬다. 무대의 ‘ChatGPT 사이트’ 슬라이드에는 풀스택 웹 앱, 인증과 데이터베이스, 플러그인을 통한 개인 설정, 사람과 에이전트 모두에게 최적화됨, 이렇게 네 줄이 적혀 있었다.

이 기능을 어디에 쓸 수 있을지 생각하다 보면 행사 운영 페이지 같은 예가 떠오른다. 일정과 안내만 올릴 때는 간단한 페이지로 충분하다. 신청 내역을 받고 준비 상황까지 공유하려면 데이터를 저장하고, 운영진과 참가자에게 보여 줄 내용을 구분해야 한다. 발표를 보며 관심이 갔던 것도 이렇게 실제 운영에 필요한 기능을 갖춰 가는 과정이었다.

로그인과 도구 연결을 함께 보니 이미 ChatGPT를 쓰는 사람들을 위한 앱도 떠올랐다. Sign in with ChatGPT로 로그인한 뒤, 사용자가 연결한 플러그인을 활용해 필요한 정보를 보여 주는 앱이다. 프로젝트를 관리하는 사람에게는 진행 상황을, 자료를 조사하는 사람에게는 새로 확인할 문서를 보여 주면 어떨까 싶었다.

이 앱은 발표 내용을 바탕으로 떠올린 활용 아이디어다. 실제로 만들려면 어떤 플러그인에 접근할 수 있고 어떤 동의를 받아야 하는지 확인해야 한다. 로그인만으로 플러그인이나 대화 기록을 모두 가져올 수는 없으며, ChatGPT 로그인과 구독 사용량 공유도 별개다.

아직 구체적인 제품을 정한 것은 아니다. 다만 사용자가 이미 쓰는 도구를 연결해 필요한 정보를 모아 주는 서비스라면 만들어 볼 만하겠다는 생각이 들었다.

Plugins, 흩어진 도구를 한곳에서

사용자에게 필요한 정보를 보여 주려면 그 정보가 있는 곳에 접근할 수 있어야 한다. 업무 자료만 해도 회의록은 문서에, 진행 상황은 이슈 관리 도구에, 논의는 메신저에 흩어져 있다. AI에게 일을 맡길 때마다 이 자료를 모아 전달하는 것도 일이다.

Plugins는 ChatGPT와 Codex에서 이런 외부 도구를 쓰도록 연결해 준다. 플러그인 안에는 서비스에 연결하는 도구뿐 아니라 작업 절차를 담은 스킬, 화면과 자료도 들어갈 수 있다. MCP는 이 가운데 외부 도구와 데이터를 연결하는 표준이다.

회의록과 이슈 관리 도구를 함께 읽을 수 있다면 ‘회의에서 결정했는데 아직 작업으로 등록되지 않은 일이 있나?’ 하고 물으면 된다. 여러 화면을 오가며 대조하던 일을 맡기는 셈이다. 정리한 내용을 Sites에 보여 주면, 필요할 때 다시 찾아볼 수도 있다.

연결한 도구의 결과를 다루는 화면 확장도 여러 형태였다. 키노트 슬라이드는 2026년의 새로운 통합 지점으로 사이드바와 사이드패널, 컴포저, 파일 뷰어를 꼽았다. 사이드바에서 앱을 열거나, 대화 옆 패널에서 결과를 확인하고, 파일을 전용 화면에서 편집하는 식이다.

Plugins 세션의 라이브 데모는 그중 사이드패널을 썼다. 채팅 옆에 열린 포스터 편집기에는 ‘THIS IS OUR GAME’이라고 적힌 포스터가 떠 있었다. 결과를 읽은 뒤 바로 수정해야 하는 작업이라면 이런 화면이 편하겠다는 생각이 들었다.

플러그인을 만드는 개발자 쪽으로는 발표자가 생성 도구와 초기 설정 안내, 제출한 뒤 피드백을 받아 고치는 절차를 설명했다. 흐름 슬라이드에서는 플러그인을 올리면 자동 피드백이 먼저 오고, 제출하면 검토를 거쳐 게시됐다. 기능 구현부터 사용자가 처음 연결하는 과정까지 함께 다루는 모습이었다.

변화가 생기면 시작하는 작업

도구를 연결한 뒤에도 사람이 매번 확인을 요청해야 한다면 반복 작업은 남는다. MCP Events는 외부 서비스에 변화가 생겼을 때 작업을 시작하도록 연결하는 기능이다. 새 문의가 들어오면 내용을 분류하고 관련 자료를 찾아 답변 초안을 만드는 식으로 활용할 수 있다. 이벤트 지원 여부는 서비스와 실행 환경에 따라 확인해야 한다.

Sites 세션의 흐름 슬라이드 한 장은 플러그인과 예약 작업, 데이터베이스, 사이트를 한 줄로 이었다. 예약 작업으로 자료를 정리해 데이터베이스에 저장하고 사이트에 보여 주는 흐름으로, 플러그인으로 자료를 가져오는 일부터 화면을 갱신하는 일까지 연결한 것이다. 매번 정보를 모아 보고서를 고치는 업무에 활용하면 수고를 덜 수 있겠다고 느꼈다.

Codex, 일을 나누고 결과를 맞추는 법

Codex의 ‘What Comes After Loops?’ 세션에서는 여러 에이전트가 일을 나누는 방법을 다뤘다. 코드 구현을 맡은 에이전트와 테스트나 주변 영향을 살피는 에이전트를 나누는 식이다.

에이전트는 목표를 받아 도구를 사용하며 작업을 진행한다. 이 과정에서는 모델의 판단 외에도 지시사항과 작업 기록을 관리하고, 도구를 실행해 결과를 돌려주는 장치가 필요하다. 발표에서 말한 ‘하네스’는 이런 실행 환경을 뜻한다. 무대의 ‘코덱스 하네스’ 도식에서는 요청에 지시와 설정, 대화 기록, 도구 결과가 붙어 Responses API를 거쳐 모델로 들어갔고, 압축과 샌드박스도 칸을 하나씩 차지하고 있었다.

발표에서는 자료 분류 같은 지원 업무에 Luna를, 구현 등 핵심 작업에 Sol을, 어려운 설계 선택을 검토하는 조언 역할에 Astra를 배치했다. 일의 성격에 따라 모델을 나눈 예시이며, 고정된 규칙은 아니다. 모델 선택에는 비용도 영향을 준다. GPT-6.1 Sol의 공식 소개에서도 에이전트 작업의 성능과 비용을 함께 강조한다.

역할을 나눠도 작업이 겹칠 수는 있다. 두 에이전트가 같은 파일을 고치거나 서로 다른 전제로 구현하면 결과를 합칠 때 문제가 생긴다. 그래서 발표에서는 담당 범위와 결과물을 정하고, 계획이 바뀌거나 작업이 막히면 서로 알리는 방법도 설명했다. 매니저 에이전트 하나가 하위 에이전트에게 일을 나눠 주는 구도와 두 에이전트가 짝을 이루는 페어 프로그래밍 구도를 도식으로 보여 줬고, ‘Coordinate’와 ‘Manager’ 스킬 프롬프트는 한국어로 옮긴 채 화면에 그대로 올렸다.

이때 목표와 완료 조건, 현재 상태를 기록해 두면 누가 어디까지 했는지 파악하기 쉽다. 슬라이드의 agent.md는 에이전트에게 작업 기록을 하나만 두게 하고, 압축이나 인계를 거친 뒤에는 그 기록부터 읽고 움직이게 했다. 각자의 작업이 끝난 뒤 전체가 제대로 동작하는지 확인할 역할도 필요하다.

무대에 오른 예시 프롬프트는 리뷰를 기다리는 PR마다 채팅을 하나씩 열어 검토하고, 진행을 막는 문제만 사람에게 보고하게 하는 내용이었다. 이런 내용을 내 일에 맞춰 Codex에 요청한다면 다음처럼 적을 수 있다.

로그인 오류의 원인을 먼저 조사해 줘. 작업을 나누는 편이 좋다면 구현과 테스트·영향 검토를 나눠 맡아 줘. 같은 파일을 고쳐야 하면 조율하고, 마지막에는 변경 이유와 검증 결과, 확인하지 못한 점을 정리해 줘.

이 역할 분담은 개발 외의 작업에도 적용할 수 있다. 글을 쓸 때 자료 조사, 주장 검토, 문장 편집을 나누는 식이다. 마지막에는 각자의 결과를 모아 한 편의 글로 완성할 편집 역할을 두면 된다.

말로 요청하고, 보면서 고치기

음성과 이미지 생성 세션에서는 요청을 주고받는 방식에 관심이 갔다. 발표자 한 사람은 연단에, 다른 한 사람은 무대 반대편에 서서 진행했고, 목차는 ‘Live API 자연스럽게 대화하기’, ‘Decisions API 말로 앱 움직이기’, ‘이미지 생성 대화에 이미지 더하기’ 세 줄이었다. 말로 조건을 바꾸고, 화면에서 결과를 확인한 뒤 다시 고치는 과정을 생각해 볼 수 있었다.

GPT-Live는 개발자가 서비스에 실시간 음성 기능을 넣을 때 사용하는 API다. 대화하는 동안 자료를 조회하거나 도구를 실행할 수 있다. ‘아까 이야기한 조건으로 다시 찾아줘’라고 말하면 앱이 정보를 조회해 답하는 식이다.

음성 요청에 따라 화면도 바꾸려면 어떤 동작을 할지 골라야 한다. Decisions API는 개발자가 정해 둔 선택지 중 하나를 고르거나 확률과 점수로 판단을 받는 데 쓰인다. ‘다음 상품 보여줘’에는 화면을 넘기고, 설명을 요청하면 현재 화면을 유지하도록 구분할 수 있다. 그 판단을 받아 실제로 동작하는 코드는 앱에서 구현한다.

이미지 생성 데모에서는 대화를 처리하는 모델과 이미지를 만드는 모델을 연결했다. ‘이미지가 월에 표시되기까지’ 슬라이드를 보면 GPT-6.1 Sol이 앱의 요청을 처리하고, 이미지 생성 도구 image_generation을 거쳐 GPT Image 2.5 Flare가 그림을 만들어 이미지 월로 보낸다. 마지막 슬라이드 ‘직접 만들어 보세요’는 QR 코드 네 개였고, 객석의 휴대폰이 다시 올라갔다.

이런 기능을 함께 활용한다면 포스터 시안을 보며 ‘배경은 그대로 두고 색만 조금 차분하게 바꿔줘’라고 말하는 앱도 생각해 볼 수 있다. 다만 이미지가 나올 때까지 무엇을 보여 줄지, 사용자가 도중에 말을 바꾸면 진행 중인 작업을 어떻게 처리할지도 정해야 한다. 요청부터 수정까지 끊기지 않고 이어지게 하는 일은 앱이 챙겨야 할 몫이다.

서비스에 에이전트를 넣으려면

앞서 살펴본 도구들을 서비스에 연결해 긴 작업을 맡기려면, 요청 이후의 진행 상황도 관리해야 한다. Agents API는 Codex의 실행 환경을 바탕으로 에이전트를 만드는 API로, 여러 단계의 작업에 필요한 세션과 도구 실행, 긴 맥락의 정리, 작업 복구 등을 다룬다. 이 세션은 브레이크아웃 스테이지에서 Sites 세션과 같은 시간에 열려 직접 듣지는 못했고, 아래는 발표 자료와 문서로 본 내용이다.

오류 보고를 받으면 로그를 조사하고 코드에서 원인을 찾아 수정안을 만드는 사내 도구가 한 예다. 조사를 마쳤는지, 수정 중인지, 어느 환경에서 실행하는지 알아야 다음 단계를 진행하거나 중단된 작업을 복구할 수 있다. Agents API는 이런 관리 작업 중 일부를 맡아 준다.

저장소의 보안 문제를 다루는 Codex Security도 같은 무대에서 발표됐다. 문서에 따르면 연결된 저장소에서 발견한 문제의 근거를 검토하고 Codex로 수정을 시작할 수 있으며, 설정과 작업 방식에 따라 초안 PR까지 이어진다. 문제가 실제로 발생하는 조건과 수정 결과는 개발자가 검토해야 한다.

컴퓨터를 닫은 뒤에도 이어지는 작업

작업을 오래 맡겨 두려면 실행할 장소도 중요해진다. 개인 컴퓨터를 계속 켜 두기 어렵거나, 다음 날 이어서 확인해야 하는 경우가 있기 때문이다.

Cloud에서는 필요한 자료와 접근 권한을 연결한 클라우드 환경에서 작업을 실행한다. 개인 컴퓨터가 잠들어도 계속 진행할 수 있다. 다만 로컬 작업이 자동으로 옮겨 가는 것은 아니므로 실행 환경을 따로 준비해야 한다.

반복해서 확인할 일에는 Dots가 눈에 들어왔다. 글로벌 DevDay에서 공개된 Dots는 자신의 클라우드 컴퓨터와 연결된 도구를 사용해 지속적으로 일을 맡는 형태다. 정기적으로 확인할 자료와 원하는 결과를 정해 두고 작업을 맡길 수 있다.

작업을 이어 갈 때는 실행 환경 외에 참고 자료와 이전 결과도 필요하다. Space와 Pages에는 이런 자료를 모아 둔다. 다음 작업에서 배경을 처음부터 다시 설명하는 부담을 줄이는 데 도움이 된다.

실행할 장소가 필요한지, 반복 확인을 맡기고 싶은지, 자료를 한곳에 모으고 싶은지에 따라 먼저 써볼 기능이 달라진다. 각 기능을 따로 이해하고 나니 매번 자료를 모아 보고서를 고치던 일이나 회의록과 이슈를 대조하던 일이 어느 기능에 걸리는지 보였다. 기능마다 지원하는 앱과 요금제, 워크스페이스 설정이 달라서 발표 화면과 내 화면이 같지는 않을 것이다.

여러 AI를 쓰는 사람으로서

새로운 AI가 나올 때마다 반갑다가도 언제 다 써보나 싶다. 비교와 평가도 쉴 새 없이 이어진다. 여러 제품을 써보는 입장에서는 선택지가 많아 즐거우면서도, 어느 쪽 이야기에 귀를 기울여야 할지 혼란스러울 때가 있다.

행사에 갈 때 마음에 걸렸던 모델 평도 그런 이야기 중 하나였다. 그런데 하루를 보내고 남은 것은 모델 논쟁이 아니라 모델 둘레에 붙은 제품들이었다. 직접 써보면 작업에 따라 더 손이 가는 제품이 생긴다. 답변의 품질뿐 아니라 자료를 연결하는 방법, 결과를 확인하고 고치는 방식도 사용감에 영향을 준다. 좋은 모델이 많아질수록 이런 차이도 제품을 고르는 이유가 될 것 같다.

이번 행사에서 본 Sites와 Plugins가 그랬다. 로그인과 데이터베이스를 갖춘 앱에 외부 도구를 연결하는 모습을 보니, ChatGPT 사용자가 자기 자료를 활용할 서비스를 만들어 볼 수 있겠다는 생각이 들었다. 서로 다른 자료와 도구를 쓰는 사람들도 각자 필요한 방식으로 활용할 수 있도록 기능을 넓혀 가는 모습이었다.

이날 본 기능들이 실제로 얼마나 잘 맞을지는 직접 써봐야 한다. 앞으로도 여러 AI를 실험하겠지만, 당분간은 Sites와 Plugins를 더 살펴보며 사람들에게 도움이 될 도구를 만들어 보고 싶다.