OpenAI DevDay 2026, ChatGPT를 어시스턴트에서 에이전트 플랫폼으로 전환
OpenAI DevDay 2026에서는 20개가 넘는 발표가 나왔지만, 핵심 변화는 하나였다. OpenAI는 ChatGPT를 대화형 어시스턴트에서 지속형 에이전트 플랫폼으로 재정립했다.
이 구분은 개별 기능 하나하나보다 더 중요하다. 챗봇은 프롬프트를 기다렸다가 답변을 반환한다. 에이전트 시스템은 맥락을 유지하고, 도구를 사용하며, 작업을 조율하고, 장기 실행 작업 전반에 걸쳐 계속 활용될 수 있다.
OpenAI는 이러한 목표를 네 가지 연결된 계층으로 구성했다. 모델인 GPT-6.1 Sol, 에이전트 런타임인 dots, 워크스페이스인 ChatGPT Space와 Pages, 그리고 확장 기능인 plugins이다. 회의 앱과 개발자 성능 티어는 이 플랫폼의 범위를 넓혔다.
그 결과 OpenAI는 지식 노동을 위한 주요 인터페이스를 둘러싼 더 큰 경쟁에 뛰어들게 됐다. Microsoft, Google, Anthropic, 그리고 전문 업무용 소프트웨어 기업들은 각자의 모델, 도구, 파일, 조직 맥락 조합을 구축하고 있다.
OpenAI의 강점은 ChatGPT를 통한 배포력이다. 더 어려운 과제는 신뢰다. 지속형 에이전트는 채팅 어시스턴트보다 더 많은 맥락과 폭넓은 권한을 필요로 하며, 오류, 안전하지 않은 확장 기능, 불분명한 데이터 경계가 초래하는 결과도 커진다.
이 글은 발표된 제품과 그 이면의 더 큰 전략을 구분해 살펴본다. 이용 가능성 표기는 일반 제공, 단계적 출시, 프리뷰, 시연을 포함해 OpenAI가 각 항목을 설명한 방식을 따른다.
OpenAI DevDay 2026, ChatGPT를 중심으로 네 개의 계층 구축
이번 발표는 서로 무관한 ChatGPT 기능의 모음이 아니라 플랫폼 스택을 이룬다.

모델 계층은 GPT-6.1 Sol로 시작한다. OpenAI는 자사의 DevDay recap에 따르면 Sol을 고난도 추론 및 에이전트 워크로드를 위한 새로운 기반으로 소개했다.
더 강력한 모델만으로는 신뢰할 수 있는 에이전트를 만들 수 없다. 플랫폼에는 목표, 도구, 중간 작업을 관리하고 작업이 잘못됐을 때 복구할 수 있는 런타임도 필요하다.
그 역할을 맡은 것이 dots다. OpenAI는 dots를 하나의 고립된 상호작용을 처리하는 대신 여러 단계에 걸쳐 작업을 수행할 수 있는 에이전트 지향 시스템으로 포지셔닝했다.
ChatGPT Space와 Pages는 워크스페이스 계층을 구성한다. Space는 맥락과 협업을 위한 지속형 환경을 제공하고, Pages는 작업을 위한 지속적인 문서 공간을 제공한다.
Plugins는 확장 계층을 차지한다. 이는 시스템을 외부 애플리케이션 및 서비스와 연결해 에이전트가 OpenAI 자체 인터페이스를 넘어설 수 있게 한다.
회의 앱은 구체적인 업무 환경 시나리오를 제공한다. 회의는 실시간 대화, 기록, 의사 결정, 문서, 후속 작업, 권한을 결합하므로 지속형 에이전트에게 까다로운 시험대가 된다.
개발자 성능 티어는 운영 측면을 완성한다. 이는 OpenAI가 지연 시간, 처리량, 워크로드 관리를 부차적인 구현 세부 사항이 아닌 플랫폼 차원의 과제로 다루고 있음을 보여준다.
OpenAI의 event hub는 발표 내용을 하나의 개발자 서사 아래에 묶는다. 그러나 이 분류가 모든 구성 요소의 출시 상태나 성숙도가 같다는 뜻은 아니다.
라인업을 이해하는 가장 명확한 방법은 이용 가능성에 따라 구분하는 것이다.
일반 제공
일반 제공으로 설명된 기능은 문서화된 계정, 지역, 제품 한도 내에서 프로덕션용 서비스로 간주해야 한다.
일반 제공이 모든 고객에게 동일한 용량, 통합 액세스 또는 관리 제어 기능을 보장하는 것은 아니다.
단계적 출시
출시는 단계적으로 액세스가 확대된다는 의미다.
사용자는 모든 계정, 기기, 워크스페이스 또는 국가에서 즉시 사용할 수 있다고 가정해서는 안 된다.
프리뷰
프리뷰는 OpenAI가 기능의 동작이나 인터페이스를 완전히 확정하기 전에 개발자가 이를 평가할 수 있음을 의미한다.
프리뷰 API와 제품 인터페이스는 변경될 수 있으므로 중요한 배포 전에는 더 엄격한 테스트가 필요하다.
시연
시연은 OpenAI가 해당 행사를 위해 작동하는 시나리오를 구축했음을 보여준다.
이는 광범위한 이용 가능성, 프로덕션 신뢰성 또는 최종 상업 모델을 확정하는 것은 아니다.
전략적 서사가 실제 배포보다 빠르게 전개되기 때문에 이 구분은 필수적이다. OpenAI는 모든 계층이 모든 사용자에게 도달하기 전에 계층들이 어떻게 함께 작동하는지 보여줄 수 있다.
회사의 developer resources는 문서와 구현 세부 사항을 위한 실질적인 기준점이다. 개발자는 프로덕션 의존성을 설계하기 전에 그곳에서 각 기능을 확인해야 한다.
따라서 핵심은 ChatGPT에 버튼이 더 추가됐다는 데 있지 않다. OpenAI는 하나의 시스템이 업무를 이해하고, 그 맥락을 유지하고, 행동을 취하며, 결과를 제시하도록 만들려 한다.
GPT-6.1 Sol은 모델 계층이지, 에이전트 전체가 아니다
GPT-6.1 Sol은 플랫폼에 판단 능력을 제공한다는 점에서 중요하지만, 그 판단이 유용한 작업으로 이어질지는 주변 시스템에 달려 있다.

기존 채팅 제품은 대부분의 눈에 보이는 지능을 하나의 응답 안에 담는다. 사용자가 질문하면 모델이 이용 가능한 맥락을 처리하고, 대화가 끝나면 상호작용은 사실상 초기화된다.
에이전트 플랫폼에는 다른 요구 사항이 있다. 목표를 해석하고, 중간 작업을 식별하며, 도구를 선택하고, 결과를 모니터링하고, 언제 사람의 검토가 필요한지 판단해야 한다.
OpenAI는 GPT-6.1 Sol을 이처럼 더 까다로운 패턴을 지원하는 모델로 소개했다. 성능에 관한 주장은 독립적인 테스트를 통해 재현되기 전까지는 OpenAI의 주장으로 남는다.
벤치마크 결과 역시 운영 환경의 일부만 보여준다. 모델은 추론 테스트에서 높은 점수를 받을 수 있지만, 잘못된 도구 호출, 불완전한 맥락 또는 부정확한 가정으로 인해 실패할 수 있다.
에이전트가 검색, 문서 수정 또는 다른 서비스를 통한 소통을 할 수 있게 되면 이 차이는 더욱 분명해진다. 시스템이 행동할 수 있게 되는 순간, 유창한 오류는 운영상 오류가 된다.
OpenAI의 별도 safety addendum은 고장 난 검색 도구 시나리오를 통해 이러한 시스템 수준 문제를 부각한다. 중요한 교훈은 검색을 넘어선다.
에이전트는 자신이 의존하는 모든 구성 요소를 통제하지 못한다. 도구는 잘못된 형식의 정보를 반환하거나, 관련 결과를 누락하거나, 문서화된 인터페이스와 다르게 동작할 수 있다.
모델은 자신 있게 계속 진행하는 대신 이러한 실패를 인식해야 한다. 런타임은 진단 정보를 보존하고, 경계를 적용하며, 사용자에게 안전하게 돌아갈 경로를 제공해야 한다.
이 때문에 모델 비교만으로는 점점 충분한 정보를 얻기 어렵다. 이제 개발자는 전체 실행 경로를 평가해야 한다.
모델이 사용자의 실제 목표를 이해했는가?
올바른 도구를 선택했는가?
도구에는 필요한 권한만 전달됐는가?
시스템이 반환된 데이터를 검증했는가?
에이전트가 불확실성이나 실패를 인식했는가?
사용자가 중대한 행동을 실행 전에 검토할 수 있었는가?
플랫폼이 감사 추적을 보존했는가?
Sol은 이러한 주변 질문을 해결하지 못한 채 계획이나 추론을 개선할 수 있다. 실제 가치는 완전한 워크플로 안에서 측정된 성능에 달려 있다.
이는 개발자에게 새로운 평가 문제를 만든다. 장기 작업, 변화하는 맥락, 실패하는 도구, 상충하는 지시, 중단된 세션을 포괄하는 테스트가 필요하다.
유용한 사무 업무 벤치마크는 승인된 파일과 회의 메모를 바탕으로 에이전트에게 프로젝트 업데이트를 작성하게 할 수 있다. 테스트에는 중복 문서, 오래된 계획, 접근할 수 없는 출처 하나가 포함돼야 한다.
가장 강력한 시스템은 그저 매끄러운 문장을 생성하는 데 그치지 않는다. 충돌을 식별하고, 어떤 출처를 신뢰했는지 설명하며, 필요할 때만 액세스를 요청한다.
이 기준은 에이전트 품질의 초점을 유창함에서 벗어나게 한다. 시스템이 실제 정보 환경 안에서 제한된 의사 결정을 내릴 수 있는지를 측정한다.
개발자 성능 티어는 에이전트 워크로드가 균일하지 않기 때문에 이 모델 중심 계층에 부합한다. 계획, 검색, 도구 실행, 최종 생성은 서로 다른 지연 시간과 용량 수요를 만들 수 있다.
티어는 구체적인 가격을 논의하지 않더라도 비용 및 아키텍처 측면의 선택지를 제시한다. 더 빠른 서비스는 대화형 에이전트를 개선할 수 있는 반면, 백그라운드 작업은 다른 성능 특성을 수용할 수 있다.
팀은 작업에 맞는 라우팅 정책이 필요하다. 실시간 회의 어시스턴트는 야간 문서 종합 프로세스보다 더 엄격한 지연 시간 요구 사항을 가진다.
따라서 OpenAI DevDay 2026은 모델의 중요성을 높이는 동시에 모델만으로 충분하지 않음을 보여준다. Sol은 인지 능력을 제공하지만, 신뢰할 수 있는 에이전트성은 이를 둘러싼 시스템에서 나온다.
Dots, 응답을 지속형 작업으로 전환하다
Dots는 핵심적인 전환을 나타낸다. ChatGPT는 더 이상 답변만 하도록 설계되는 것이 아니라, 하나의 프로세스 전반에서 계속 작업하도록 설계되고 있다.

런타임은 작업을 계속 유지하는 조정 계층이다. 상태를 유지하고, 도구를 호출하며, 중간 결과를 추적하고, 각 단계 이후에 무엇이 일어날지를 결정한다.
이는 대화형 메모리와 다르다. 선호도를 기억하는 것은 유용하지만, 에이전트 런타임은 무엇을 시도했고, 무엇이 성공했으며, 무엇이 아직 해결되지 않았는지도 기억해야 한다.
지속성은 사용자가 제품과 맺는 관계를 바꾼다. 사용자는 반복되는 프롬프트를 통해 매번 모든 작업을 다시 구성할 필요가 없어진다.
실패 방식도 바뀐다. 잘못된 답변은 일반적으로 하나의 상호작용에 영향을 미치지만, 잘못된 지속형 가정은 이후의 모든 단계를 형성할 수 있다.
반복적인 제품 검토를 생각해 보자. 에이전트는 승인된 리서치를 수집하고, 고객 피드백을 요약하며, 현재 지표를 비교하고, 의사 결정 메모를 작성하고, 미해결 질문을 식별할 수 있다.
이 워크플로에는 지속적인 상태가 필요하다. 또한 에이전트가 관련 없는 프로젝트에서 비공개 자료를 가져오지 못하도록 하는 규칙도 필요하다.
Dots는 이러한 작업에 필요한 연속성을 제공하도록 설계된 것으로 보인다. OpenAI의 행사 자료는 이를 모델, 워크스페이스, 도구를 연결하는 조직의 일부로 설명한다.
전략적 압력은 AI를 하나의 애플리케이션 안의 기능으로 다루는 기업에 가해진다. 범용 에이전트 런타임은 하나의 인터페이스에 종속된 채 머무르지 않고 여러 애플리케이션의 활동을 조율할 수 있다.
Microsoft는 업무 환경 배포력과 조직 데이터를 통해 대응할 수 있다. Google은 에이전트를 Workspace 및 클라우드 서비스와 연결할 수 있다.
Anthropic은 모델 동작, 개발자 도구, 에이전트 지향 코딩 제품을 통해 경쟁할 수 있다. 전문 공급업체는 더 깊은 도메인 지식과 더 명확한 제어를 통해 좁은 워크플로를 방어할 수 있다.
이 경쟁은 단순히 ChatGPT와 다른 챗봇 간의 대결이 아니다. 고립된 애플리케이션 어시스턴트와 애플리케이션 경계를 넘어 작업을 조율하는 시스템 간의 경쟁이다.
OpenAI가 애플리케이션 계층을 없앤 것은 아니다. 대신 필요한 애플리케이션이 호출되기 전에 사용자가 의도를 표현하는 장소가 ChatGPT가 될 수 있는지를 묻고 있다.
이는 이전 플랫폼 전환과 유사한 압력을 만든다. 운영체제는 사용자가 하드웨어 세부 사항을 이해할 필요를 줄였고, 브라우저는 로컬에 설치된 소프트웨어에 대한 의존도를 낮췄다.
에이전트 런타임은 또 다른 종류의 복잡성을 감추는 것을 목표로 한다. 사용자는 결과를 제시하고, 플랫폼은 이를 추구하는 데 필요한 모델, 도구, 정보를 선택한다.
이 비유에는 한계가 있다. 기존 플랫폼은 대체로 결정론적 소프트웨어를 실행했지만, 에이전트는 모호한 요청을 해석하고 확률적 결과물을 생성한다.
브라우저는 페이지를 불러오거나 눈에 보이는 방식으로 실패한다. 에이전트는 설득력 있는 확신을 담아 결과를 제시하면서도 작업을 잘못 완료할 수 있다.
그 차이는 사람의 검토 지점을 핵심으로 만든다. 지속적인 작업이 보이지 않는 작업을 뜻해서는 안 되며, 특히 에이전트가 중요한 자료를 전송, 게시, 승인 또는 수정할 수 있다면 더욱 그렇다.
개발자는 어떤 작업을 자동으로 실행할 수 있고 어떤 작업에 확인이 필요한지 정의해야 한다. 이러한 정책은 단순한 기술적 가능성이 아니라 결과에 따라 결정되어야 한다.
승인된 프로젝트 문서를 읽는 일은 문서를 삭제하는 일보다 위험이 낮다. 메시지를 초안으로 작성하는 일은 외부 수신자에게 전송하는 일보다 위험이 낮다.
가장 신뢰할 수 있는 에이전트 런타임은 이러한 경계를 이해하기 쉽게 드러낼 것이다. 사용자는 에이전트가 무엇에 접근할 수 있는지, 무엇을 했는지, 무엇에 승인이 필요한지를 확인할 수 있어야 한다.
dots에는 우아한 복구 기능도 필요하다. 장기 실행 작업은 만료된 자격 증명, 사용할 수 없는 서비스, 모호한 문서, 실행 도중 변경되는 지시 사항에 부딪힌다.
처음부터 다시 시작하면 지속성의 가치를 상당 부분 잃게 된다. 아무런 검토 없이 계속 진행하면 오류가 누적된다.
신뢰할 수 있는 런타임에는 체크포인트, 재개 가능한 상태, 그리고 도구 활동에 대한 명확한 기록이 필요하다. OpenAI의 시연은 그 목적지를 가리키지만, 뒤이어 운영상의 증거가 제시되어야 한다.
다음 시험대는 dots가 세련된 무대 데모를 완성할 수 있는지가 아니다. 일반적인 장애 상황에서 개발자가 그 동작을 예측하고, 점검하고, 제한할 수 있는지다.
ChatGPT Space와 Pages가 워크스페이스 안에 컨텍스트를 담다
Space와 Pages는 ChatGPT를 대화 창에서 정보와 결과물이 함께 지속될 수 있는 공유 환경으로 옮겨 놓는다.
채팅은 본격적인 지식 업무에서 구조적 약점을 지닌다. 중요한 결정은 탐색적 질문, 수정, 복사한 텍스트, 버려진 아이디어 사이에 묻히게 된다.
워크스페이스는 다른 조직 단위를 제공한다. 최신 프롬프트를 경험의 중심으로 두는 대신, 파일, 참여자, 권한, 작업, 완성된 산출물을 중심으로 구성할 수 있다.
ChatGPT Space는 그 컨테이너를 제공하기 위한 것으로 보인다. Pages는 에이전트의 결과물이 지속 가능한 업무가 될 수 있도록 하는 문서 중심의 표면을 제공한다.
이 조합이 중요한 이유는 에이전트에 안정적인 컨텍스트가 필요하기 때문이다. 소스 자료, 가정, 최신 승인 결과가 서로 무관한 대화에 흩어져 있다면 작업의 일관성을 유지할 수 없다.
컨텍스트가 풍부한 오피스 에이전트는 여러 유형의 정보를 사용할 수 있다:
현재 계획을 정의하는 프로젝트 문서
새로운 결정을 기록하는 회의 녹취록
운영상 변경 사항을 담은 메시지
진행 상황을 측정하는 구조화된 데이터
승인된 결론을 보관하는 Pages
실행을 지원하는 연결된 애플리케이션
이 정보를 단순히 모으는 것만으로는 충분하지 않다. 시스템은 최신 소스와 오래된 소스, 권위 있는 기록과 비공식 논의를 구분해야 한다.
또한 경계를 존중해야 한다. 공유 Space가 모든 참여자나 플러그인에 연결된 모든 소스에 대한 접근 권한을 자동으로 부여해서는 안 된다.
지속적 컨텍스트는 여기서 제품의 강점이자 거버넌스 문제가 된다. 더 많은 컨텍스트는 관련성을 높이지만, 시스템이 노출하거나 오용할 수 있는 범위도 넓힌다.
지식 노동자는 연속성에서 먼저 이점을 체감할 것이다. 프로젝트 관리자는 매 세션마다 프로젝트의 용어, 이해관계자, 최근 결정을 다시 설명할 필요가 없어야 한다.
연구자는 소스, 미해결 질문, 이전 해석을 보존할 수 있어야 한다. 엔지니어는 작업을 관련 사양 및 기술 논의와 연결할 수 있어야 한다.
개인 지식 기반을 중심으로 구축된 제품은 이미 이러한 지속 가능한 컨텍스트 수요를 반영한다. OpenAI의 움직임은 같은 설계 문제를 더 광범위한 에이전트 플랫폼으로 가져온다.
Pages는 사용자가 에이전트 결과물을 검토하는 방식도 바꿀 수 있다. 지속 가능한 문서는 일시적인 응답으로는 어려운 편집, 댓글, 비교, 승인을 가능하게 한다.
이는 책임성에 중요하다. 팀은 에이전트의 최신 메시지를 최종 상태로 받아들이는 대신, Page를 검토 가능한 산출물로 다룰 수 있다.
해결되지 않은 문제는 Spaces가 충분한 출처 이력을 보존할지 여부다. 사용자는 어떤 소스가 결론에 영향을 미쳤는지, 그리고 해당 소스가 마지막으로 언제 변경됐는지 알아야 한다.
출처 이력이 없다면 지속적 컨텍스트는 오래된 오류를 보존할 수 있다. 기반 정책이나 프로젝트 결정이 바뀐 뒤에도 자신감 있는 요약이 오래 남아 있을 수 있다.
따라서 팀은 지속성을 자동적인 진실로 취급하지 말아야 한다. 지속 가능한 컨텍스트에는 유지 관리, 소스 우선순위, 접근 제어, 삭제 정책이 필요하다.
회의 앱은 유용한 스트레스 테스트를 제공한다. 회의는 결정으로 깔끔하게 연결되지 않는 발화의 흐름을 만들어 낸다.
참여자는 자신의 말을 정정하고, 기밀 사안을 논의하며, 담당자를 모호하게 남긴다. 녹취록은 발언을 보존할 수 있지만 최종 약속을 정확히 식별하지 못할 수 있다.
에이전트는 결정, 담당자, 후속 작업을 추출하는 데 도움을 줄 수 있다. 그러나 이러한 결과물은 참여자가 검토하기 전까지 제안으로 남아야 한다.
녹음 동의는 또 다른 경계를 만든다. 조직에는 기록이 언제 시작되는지, 누가 기록에 접근할 수 있는지, 자료가 얼마나 오래 보관되는지를 다루는 명확한 규칙이 필요하다.
회의 앱의 전략적 가치는 통화 이후에 일어나는 일에서 나온다. 메모는 Page를 업데이트하고, 프로젝트 Space에 정보를 제공하며, 승인된 후속 작업을 촉발할 수 있을 때 더 유용해진다.
그 연결고리는 위험도 집중시킨다. 하나의 전사 오류가 요약, 프로젝트 기록, 외부 조치로 이어질 수 있다.
따라서 OpenAI는 Spaces와 Pages가 숨겨진 컨텍스트를 숨겨진 권한으로 바꾸지 않으면서 연속성을 개선한다는 점을 입증해야 한다. 가장 뛰어난 워크스페이스 에이전트는 컨텍스트가 광범위하더라도 계속 점검 가능해야 한다.
플러그인 확장이 플랫폼 보안 문제를 다시 제기하다
플러그인은 에이전트 플랫폼의 확장성을 높이지만, 모든 확장은 또 하나의 신뢰 경계를 추가한다.
플러그인을 통해 외부 개발자는 서비스와 작업을 ChatGPT로 가져올 수 있다. 이를 통해 OpenAI가 모든 애플리케이션을 직접 구축하지 않아도 플랫폼은 더 많은 워크플로에서 유용해질 수 있다.
비즈니스적 함의는 크다. 사용자가 ChatGPT 안에서 작업을 시작한다면, 개발자는 에이전트가 매개하는 확장 계층 내 배치를 두고 경쟁할 수 있다.
이는 애플리케이션 마켓플레이스와 닮았지만 상호작용 모델은 다르다. 사용자가 매번 앱을 직접 선택하지 않을 수 있다.
에이전트는 요청에 가장 잘 맞는다고 판단한 확장을 선택할 수 있다. 그러면 발견 가능성은 플랫폼의 선택 로직, 권한 모델, 순위 규칙에 부분적으로 좌우된다.
초기 플랫폼 분석은 이 발표를 전통적 앱스토어 유통에 대한 도전으로 규정했다. 이 해석은 타당하지만, 도입은 아직 입증되지 않았다.
개발자는 어떤 방식으로 확장이 자격을 얻는지, 사용자가 어떻게 승인하는지, 플랫폼이 중복되는 기능을 어떻게 조정하는지 জানতে고 싶어 할 것이다.
또한 신원, 데이터 접근, 결과물 소유권, 관찰 가능성, 플랫폼에서의 제거에 관한 예측 가능한 규칙도 필요하다.
사용자에게 핵심 문제는 위임된 권한이다. 플러그인은 기본 모델만으로는 처리할 수 없는 정보를 받거나 작업을 수행할 수 있다.
권한은 가능한 한 좁고, 이해하기 쉬우며, 일시적이어야 한다. 캘린더 확장이 Space 내 모든 문서에 자동으로 접근할 필요는 없다.
플랫폼은 조회와 실행도 분리해야 한다. 에이전트가 계정을 읽을 수 있다고 해서 해당 계정을 변경할 권한까지 있다는 뜻은 아니다.
보안 검토는 악성 코드 이상을 다뤄야 한다. 정상적인 확장도 잘못된 데이터를 반환하거나, 지시를 오해하거나, 업데이트 뒤 동작을 변경할 수 있다.
프롬프트 인젝션도 여전히 우려 사항이다. 에이전트는 문서, 웹페이지, 메시지, 도구 응답에 삽입된 악의적 지시를 마주할 수 있다.
이러한 지시는 에이전트의 방향을 바꾸거나, 비공개 컨텍스트를 노출하거나, 승인되지 않은 조치를 유발하려 할 수 있다. 에이전트가 연결된 시스템 사이에서 정보를 이동할 때 위험은 커진다.
개발자에게는 여러 지점의 통제 수단이 필요하다:
확장이 반환하는 데이터 검증
외부 콘텐츠를 신뢰할 수 없는 입력으로 취급
자격 증명을 필요한 작업으로 제한
중대한 결과를 초래하는 작업에 확인 요구
도구 선택과 반환 결과 기록
민감한 워크스페이스 컨텍스트 격리
관련 없는 업무를 방해하지 않고 접근 권한 철회
OpenAI의 과제는 이러한 통제 수단을 사용하기 쉽게 만드는 것이다. 문서에만 존재하는 보안 설정은 일반 사용자를 보호하지 못한다.
회의 시나리오는 이 문제를 잘 보여 준다. 후속 작업 생성을 요청받은 플러그인은 제한 없는 회의 녹취록이 아니라 승인된 실행 항목을 받아야 한다.
영업 확장에는 전체 연락처 데이터베이스가 아니라 고객 기록 하나가 필요할 수 있다. 게시 도구에는 워크스페이스의 모든 Page가 아니라 초안 하나가 필요할 수 있다.
거버넌스는 조직에도 영향을 미친다. 관리자는 승인된 확장 목록, 중앙화된 정책, 감사 로그, 보존 설정, 사고 대응 절차를 원할 것이다.
에이전트가 규제 대상, 기밀 또는 고객 소유 정보를 처리할 때 개인의 동의가 조직 차원의 통제를 대체할 수는 없다.
OpenAI는 개방성과 검토 사이의 균형을 맞춰야 한다. 엄격한 관문 관리는 확장 시장을 늦출 수 있고, 느슨한 검토는 전체 플랫폼에 대한 신뢰를 훼손할 수 있다.
회사는 플랫폼 중립성도 설명해야 한다. 개발자는 OpenAI가 확장 활동을 활용해 자사 경쟁 서비스를 우대하지 않을 것이라는 확신이 필요하다.
사용자는 에이전트가 확장 사이에서 선택할 때 이를 볼 수 있어야 한다. 추천이 공개되지 않은 유통 결정이 되어서는 안 된다.
이러한 질문은 플러그인 이야기가 단순한 기능 성공으로 끝나는 것을 막는다. 확장은 권한 및 책임성 계층도 함께 확장될 때에만 기능을 넓힌다.
회의 앱이 에이전트 거버넌스를 미룰 수 없는 이유를 보여 주다
회의 앱은 여러 계층을 연결하기 때문에 설득력이 있으며, 바로 그 이유로 위험하다.
회의는 실시간 정보로 시작하지만, 그 가치는 이후에 무엇이 일어나는지에 달려 있다. 팀에는 정확한 기록, 명확한 결정, 배정된 업무, 기존 계획에 대한 업데이트가 필요하다.
에이전트는 이러한 단계를 연결할 수 있다. 모델은 대화를 해석하고, 런타임은 후속 작업을 추적하며, Space는 프로젝트 컨텍스트를 제공하고, 플러그인은 승인된 조치를 지원한다.
이는 OpenAI의 플랫폼 논지를 가장 명확하게 보여 주는 사례다. 하나의 모델이 더 나은 요약을 생성해서가 아니라 여러 계층이 협력하기 때문에 제품이 유용해진다.
그러나 회의에는 소프트웨어가 언제나 해결할 수 없는 모호함이 있다. 참여자는 조치를 승인하지 않은 채 제안할 수 있고, 기한을 수락하지 않은 채 논의할 수 있다.
시스템은 대화와 약속을 구분해야 한다. 그렇지 않으면 비공식 발언을 공식 기록이나 의도하지 않은 조치로 바꿀 수 있다.
지식 노동자는 세 단계에서 검토 통제를 기대해야 한다. 시스템이 무엇을 기록했는지, 무엇을 추론했는지, 무엇을 하겠다고 제안하는지를 검토해야 한다.
조직에는 명시적인 녹음 규칙도 필요하다. 참여자는 에이전트가 언제 존재하는지, 무엇을 보관하는지, 어떤 연결 시스템이 결과물을 받을 수 있는지를 이해해야 한다.
접근 권한은 회의의 실제 경계를 따라야 한다. 누군가를 한 번의 통화에 초대했다고 해서 그 사람에게 전체 지속적 Space에 대한 접근 권한을 부여해서는 안 된다.
이 원칙은 퇴장 이후에도 적용된다. 조직에는 필요한 업무 기록을 보존하면서 접근 권한을 제거할 수 있는 예측 가능한 방식이 필요하다.
공개적인 가격 비교가 없더라도 비용은 도입을 좌우할 것이다. 지속적인 에이전트는 모델 용량, 저장소, 검색, 도구 호출, 모니터링 리소스를 소비한다.
개발자는 어떤 컨텍스트를 활성 상태로 유지할지, 어떤 작업을 백그라운드에서 실행할지, 어떤 작업이 더 높은 성능을 정당화하는지 결정해야 한다.
무제한 컨텍스트가 자동으로 더 나은 것은 아니다. 관련 없는 정보는 처리 비용을 높이고 에이전트 판단의 정확성을 떨어뜨릴 수 있다.
좋은 시스템은 현재 작업에 필요한 정보만 검색합니다. 또한 추가 컨텍스트가 답변이나 작업에 실질적인 영향을 미쳤을 때 이를 사용자에게 보여줍니다.
이로써 모든 정보 경계를 허물지 않으면서 선택한 소스가 작업에 반영되도록 하는 knowledge blending의 실질적인 역할이 생깁니다.
거버넌스 팀은 광범위한 도입에 앞서 직접적인 질문을 던져야 합니다:
어떤 정보가 Space에 들어갈 수 있는가?
어떤 소스가 권위 있는 정보로 간주되는가?
관리자는 에이전트 활동을 점검할 수 있는가?
상충하는 지침은 어떻게 해결되는가?
어떤 작업에 사람의 승인이 필요한가?
사용자는 지속되는 컨텍스트를 어떻게 수정할 수 있는가?
플러그인의 권한이 해제되면 어떻게 되는가?
기록은 어떻게 내보내거나 삭제하는가?
OpenAI의 발표가 로컬 정책의 필요성을 없애지는 않습니다. 플랫폼은 제어 기능을 제공할 수 있지만, 각 조직은 그러한 제어 기능을 자사의 위험 요소에 어떻게 적용할지 결정해야 합니다.
부담은 개발자에게도 있습니다. 확장 기능은 하나의 명확한 기능에 필요한 최소 범위의 권한만 요청해야 합니다.
개발자는 모델, 도구, 소스 데이터가 각각 독립적으로 실패할 수 있다고 가정해야 합니다. 테스트는 하나의 이상적인 워크플로가 아니라 실패의 조합을 포괄해야 합니다.
부정확한 회의 요약을 작성하는 에이전트는 불편을 초래합니다. 그 요약을 사용해 시스템을 업데이트하거나 고객에게 연락하는 에이전트는 더 큰 사고를 초래합니다.
이 차이는 권한 수준을 결정해야 합니다. 작업이 되돌릴 수 없는 외부 영향에 가까워질수록 검토 요건은 더 강해져야 합니다.
따라서 OpenAI의 플랫폼 방향성은 제품 설계의 기준을 높입니다. 유능한 에이전트만으로는 충분하지 않습니다. 사용자는 작업 과정이 계속 보이는, 제어 가능한 에이전트를 필요로 합니다.
OpenAI DevDay 2026 이후의 전망
플랫폼 전략은 발표의 양이 아니라 제공 범위, 실제 에이전트 신뢰성, 개발자 채택을 통해 검증될 것입니다.
첫 번째 신호는 프리뷰와 시연에서 문서화된 액세스로의 전환입니다. OpenAI는 명확한 이용 자격, 지역별 제공 범위, 관리 제어 기능, 안정적인 인터페이스를 공개해야 합니다.
빠른 출시라면 회사가 작동하는 플랫폼을 구축했다는 주장을 강화할 것입니다. 시연과 실질적인 액세스 사이에 긴 공백이 생긴다면 그 주장은 약화될 것입니다.
사용자는 출시 과정에서도 제품들이 계속 연결되어 있는지 살펴봐야 합니다. 모델, 런타임, 워크스페이스, 플러그인 시스템은 액세스 규칙이나 출시 일정이 서로 엇갈린다면 가치가 떨어집니다.
두 번째 신호는 장기간 실행되는 에이전트 작업에 관한 프로덕션 증거입니다. 개발자에게는 벤치마크 점수와 다듬어진 예시를 넘어서는 측정치가 필요합니다.
유용한 증거에는 작업 완료율, 도구 선택 오류, 실패한 서비스로부터의 복구, 권한 위반, 사람의 개입 빈도 등이 포함됩니다.
여기서는 독립적인 테스트가 중요합니다. OpenAI는 의도한 동작을 설명할 수 있지만, 외부 개발자들이 낯선 환경 전반에서 플랫폼이 어떻게 작동하는지 보여줄 것입니다.
가장 유익한 실패 사례는 극적인 공격보다 일상적인 상황에서 발생할 것입니다. 오래된 파일, 중복 기록, 취소된 자격 증명, 모호한 지침은 매일 발생합니다.
dots가 안전하게 재개되고 자신의 상태를 설명한다면 런타임 전략은 신뢰를 얻게 됩니다. 개발자가 그 주변에 상태 관리 기능을 다시 구축해야 한다면 플랫폼의 이점은 줄어듭니다.
세 번째 신호는 개발자들이 사용자가 반복해서 선택하는 확장 기능을 구축하는지 여부입니다. 대규모 카탈로그만으로는 유의미한 채택을 거의 보여주지 못합니다.
반복 사용은 ChatGPT가 여러 애플리케이션에 걸친 업무의 신뢰할 수 있는 진입점이 될 수 있음을 보여줄 것입니다. 낮은 유지율은 사용자가 여전히 직접적이고 전문화된 인터페이스를 선호한다는 점을 시사할 것입니다.
플랫폼 정책도 이 결과에 영향을 미칠 것입니다. 개발자에게는 배포 규칙이 계속 이해하기 쉬울 것이며 액세스가 불투명한 선호에 좌우되지 않을 것이라는 확신이 필요합니다.
경쟁사의 대응도 중요합니다. Microsoft와 Google은 에이전트를 기존 업무용 제품군과 연결할 수 있으며, Anthropic은 신뢰할 수 있는 에이전트 동작과 개발자 신뢰에 집중할 수 있습니다.
독립적인 행사 개요는 경쟁 구도의 중심에 dots, Space, Sol을 배치합니다. 향후 몇 달은 이 이름들이 일관된 제품 시스템으로 자리 잡을지 보여줄 것입니다.
개발자에게 당면한 과제는 절제된 실험입니다. 범위가 제한된 워크플로 하나를 테스트하고, 허용된 소스를 정의하며, 중요한 결과를 초래하는 작업은 승인 절차 뒤에 두어야 합니다.
지식 근로자에게 핵심 질문은 지속성이 중요한 컨텍스트를 점검하기 어렵게 만들지 않으면서 반복적인 설명을 줄이는지 여부입니다.
엔터프라이즈 구매자는 기능과 함께 거버넌스를 평가해야 합니다. 권한 범위, 감사 가능성, 보존, 내보내기, 사고 대응은 핵심 플랫폼 기능입니다.
OpenAI DevDay 2026은 개별 구성 요소가 서로 다른 속도로 성숙하더라도 분명한 전략적 변화를 나타냅니다. ChatGPT는 지속적인 업무가 존재하고 실행될 수 있는 장소로 자리매김하고 있습니다.
결정적인 시험은 사용자가 그 장소에 실제 컨텍스트를 맡길 만큼 신뢰하는지 여부입니다. 유용한 에이전트는 도움을 줄 만큼 충분히 기억하고, 필요한 것에만 접근하며, 인간의 판단이 중요할 때 멈춰야 합니다.
출시 상태 표시, 실패 데이터, 확장 기능의 반복 사용을 지켜보십시오. 이러한 신호는 OpenAI가 에이전트 플랫폼을 구축했는지, 아니면 야심 찬 청사진을 제시했는지를 보여줄 것입니다.



