챗봇의 다음 화면은
‘항상 켜진 에이전트’다
OpenAI DevDay 2026에서 공개된 dots, GPT‑6.1 Sol, ChatGPT Space, 컴퓨터 사용형 Agents API는 생성형 AI의 경쟁축을 ‘더 똑똑한 답변’에서 ‘지속적으로 일을 맡고, 도구를 쓰고, 사람의 승인을 기다리는 운영 체계’로 옮기고 있다. 중요한 질문은 이제 모델이 무엇을 아느냐가 아니라, 어디까지 맡길 수 있고 어떤 경계에서 사람이 다시 통제권을 잡느냐다.
9월 29일 열린 OpenAI DevDay 2026은 20개가 넘는 주요 발표를 묶어 공개했다. 표면적으로는 모델, 코딩 도구, 협업 공간, API, 보안 제품이 한꺼번에 등장한 대형 제품 행사다. 그러나 발표를 기능 목록으로만 읽으면 가장 중요한 변화를 놓치기 쉽다. 공통 분모는 ‘지속성’이다. 한 번 질문하고 한 번 답을 받는 세션형 AI가 아니라, 목표와 맥락을 이어받아 여러 작업을 병렬로 처리하고, 필요한 시점에 사람에게 질문하거나 승인을 요청하며, 클라우드의 도구와 연결된 시스템 안에서 일을 계속하는 AI가 전면으로 나왔다.1
그 중심에 ‘dots’가 있다. OpenAI는 dots를 GPT‑6 Astra 기반의 항상 켜진 에이전트로 설명한다. 각 dot은 자체 클라우드 컴퓨터를 사용하고, 연결된 앱과 브라우저를 통해 여러 프로젝트를 진행하며, ChatGPT뿐 아니라 Slack과 Microsoft Teams에서도 대화할 수 있도록 설계됐다. 사용자가 자리를 비운 동안에도 ‘proactive research’ 형태로 읽기 전용 연결 앱을 살피며 다음에 도움이 될 만한 정보를 찾아둘 수 있다. 다만 이 백그라운드 탐색은 메시지 전송이나 앱 변경, 브라우저·컴퓨터 제어를 하지 못하도록 제한된 읽기 전용 도구를 사용한다고 회사는 설명한다.2
이 변화는 생성형 AI의 사용법을 바꾼다. 지금까지 사용자는 프롬프트를 입력하고 결과를 검토한 뒤 다음 프롬프트를 던지는 ‘호출자’였다. 상시형 에이전트가 실제로 정착하면 사용자는 점점 ‘업무 설계자’와 ‘승인자’가 된다. 무엇을 목표로 삼을지, 어떤 데이터와 앱에 접근시킬지, 어떤 행동은 자동화하고 어떤 행동은 반드시 승인을 받게 할지, 문제가 생겼을 때 어디서 중단하고 되돌릴지를 설계하는 일이 프롬프트 문장 자체보다 중요해진다.
‘잘 대답하는 AI’에서 ‘일을 끝내는 AI’로
FROM RESPONSE QUALITY TO WORK COMPLETION초기 생성형 AI 경쟁은 거의 모든 지표가 답변 품질에 맞춰져 있었다. 벤치마크 점수, 코딩 정확도, 수학 문제 해결률, 사실성, 이미지 품질이 제품 경쟁력을 설명했다. 그러나 에이전트가 도구를 호출하고 실제 환경에서 여러 단계를 수행하기 시작하면 성공의 정의가 달라진다. 첫 단계에서 맞는 답을 내놓는 것보다 마지막 단계까지 오류 없이 마치고, 중간 실패를 감지하고, 필요한 경우 사람에게 개입을 요청하고, 결과를 재현할 수 있는지가 더 중요해진다.
dots의 공식 예시는 이 방향을 노골적으로 보여준다. 개발자에게 들어온 고객 피드백을 모아 반복적인 요구를 찾고 작은 개선과 버그 수정 범위를 정해 테스트한 뒤 리뷰 가능한 변경 묶음을 가져오거나, 제품 출시 범위가 바뀌면 관련 자료와 계획을 다시 정리하고, 과학자의 새 데이터가 들어오면 분석을 다시 돌려 논문의 그림과 설명을 업데이트하는 식이다. 각 사례에서 중요한 것은 ‘한 번의 생성’이 아니라 변화가 생길 때마다 같은 목표를 지속적으로 추적한다는 점이다.2
프롬프트 → 답변
사용자가 매 단계 호출하고 결과를 다음 입력으로 넘기는 방식. 맥락 유지와 단계 연결을 사람이 담당한다.
목표 → 실행 계획
에이전트가 도구와 작업을 조합하고 여러 하위 과제를 병렬로 진행하며 상태를 관리한다.
승인 → 감사 가능성
권한 경계, 사람의 승인, 행동 로그, 실패 복구가 제품 신뢰도를 결정하는 핵심 지표가 된다.
dots의 ‘클라우드 컴퓨터’가 바꾸는 권한의 의미
AGENT IDENTITY, PERMISSIONS AND CONTROL상시 실행형 에이전트가 기존 챗봇과 결정적으로 다른 지점은 모델이 외부 세계에 손을 뻗는 방식이다. OpenAI는 각 dot이 자체 클라우드 컴퓨터와 브라우저를 사용하며, 사용자가 명시적으로 허용하면 다른 장치나 노트북에도 연결할 수 있다고 설명한다. 지원되는 웹사이트 로그인에서는 저장된 비밀번호를 모델에 노출하지 않은 채 사용할 수 있도록 설계했다고 밝힌다. 이는 편리함을 높이지만, 동시에 ‘누가 어떤 권한으로 어떤 행동을 했는가’라는 전통적 IT 보안 질문을 AI 제품의 중심으로 끌어온다.2
사람 직원에게 회사 계정을 발급할 때는 직무에 필요한 최소 권한을 부여하고, 퇴사나 부서 이동 때 권한을 회수하며, 주요 시스템 접근을 기록한다. 에이전트도 같은 원칙을 적용해야 한다. 오히려 더 엄격해야 할 수 있다. 사람은 하루에 수십 번 클릭하지만 에이전트는 매우 짧은 시간에 수백 번의 호출을 할 수 있고, 여러 시스템을 동시에 연결할 수 있기 때문이다. 작은 설정 오류가 반복 실행될 경우 피해 범위가 빠르게 커질 수 있다.
백그라운드는 기본적으로 읽기 전용
OpenAI 설명상 사용자가 직접 작업시키지 않는 동안의 proactive research는 연결된 앱에서 읽기 전용 도구를 사용한다. 메시지를 보내거나 앱 내용을 바꾸거나 브라우저를 제어할 수 없도록 범위를 제한한다.
행동 전에 검토와 승인
Custom Rules와 auto-review를 통해 특정 행동을 허용·승인 필요·차단으로 나눌 수 있고, 비밀번호 변경처럼 민감한 작업은 사용자가 직접 수행해야 한다. 결과가 중요한 업무는 여전히 사람 검토가 필요하다.
여기서 눈여겨볼 것은 ‘AI 안전’의 무게중심이 대화 필터에서 행동 거버넌스로 이동한다는 점이다. 위험한 문장을 막는 것만으로는 충분하지 않다. 어떤 앱에 접속했는지, 어떤 파일을 읽었는지, 어떤 데이터가 외부로 나갔는지, 어떤 결정을 자동으로 실행했는지를 추적해야 한다. 에이전트 운영 화면이 앞으로는 채팅 기록보다 활동 로그와 승인 큐, 권한 그래프, 복구 버튼을 더 크게 보여주게 될 가능성이 높은 이유다.
GPT‑6.1 Sol: ‘최고 성능’보다 중요한 비용 곡선
PRICE-PER-WORK, NOT JUST PRICE-PER-TOKEN에이전트가 장시간 실행될수록 모델 가격은 제품 경험의 핵심 변수로 올라온다. 한 번의 짧은 질의에서는 토큰 단가 차이가 작아 보여도, 여러 도구를 호출하고 중간 결과를 읽고 계획을 수정하는 에이전트 작업은 입력·출력·컨텍스트 사용량이 크게 늘어난다. OpenAI가 DevDay에서 GPT‑6.1 Sol을 별도로 강조한 이유도 여기에 있다. 공식 API 문서는 이 모델을 복잡한 코딩·컴퓨터 사용·전문 업무에서 Astra에 가까운 성능을 더 낮은 비용으로 제공하는 모델로 설명한다.3
공식 모델 사양이 말하는 전략
GPT‑6.1 Sol은 105만 토큰 컨텍스트 창, 최대 12만8000 토큰 출력, low부터 max까지의 추론 강도, 웹 검색·파일 검색·컴퓨터 사용·MCP 등 다양한 도구를 지원한다. 표준 API 가격은 입력 100만 토큰당 2달러, 출력 10달러이며 캐시된 입력은 0.10달러로 제시돼 있다.
이 사양에서 눈에 띄는 것은 단순히 가격이 싸다는 점이 아니다. 모델이 웹 검색, 파일 검색, 코드 실행, 컴퓨터 사용 같은 도구를 한 API 흐름 안에서 이용하도록 설계되면서 ‘모델 호출 비용’과 ‘업무 수행 비용’을 같은 설계 문제로 묶었다는 점이다. 더 어려운 단계에서는 높은 추론 강도를 쓰고, 단순 분류나 확인 단계에서는 낮은 강도를 쓰며, 반복되는 긴 프롬프트는 캐시를 활용하는 방식으로 전체 비용을 조절할 수 있다.
따라서 기업이 실제로 비교해야 할 것은 토큰 가격표만이 아니다. 같은 고객 문의 1만 건을 처리할 때 몇 건을 사람에게 넘기는지, 도구 호출이 몇 번 발생하는지, 재시도가 얼마나 필요한지, 오류 한 건을 복구하는 데 사람이 몇 분을 쓰는지를 함께 봐야 한다. 고성능 모델이 비싸도 실패율이 크게 낮다면 총비용이 더 낮을 수 있고, 반대로 값싼 모델을 과도하게 재시도하면 최종 비용과 지연시간이 커질 수 있다. 에이전트 시대의 ‘가격 대비 성능’은 업무 완료 단위로 재정의될 필요가 있다.
Agents API와 Codex: 개발도 ‘작업 큐’ 중심으로
SOFTWARE ENGINEERING BECOMES ORCHESTRATIONDevDay 발표에서 개발자용 변화도 같은 방향을 가리킨다. OpenAI는 Agents API에 컴퓨터 사용 기능을 추가하고, 멀티 에이전트, 도구 검색, 도구 호출, 컨텍스트 압축 등을 관리형 인프라 형태로 제공한다고 설명했다. 개발자가 직접 브라우저 자동화, 장기 실행 상태 저장, 도구 연결, 여러 하위 에이전트의 협업 구조를 처음부터 구현하기보다, 애플리케이션이 목표와 권한·도구를 정의하면 실행 인프라는 플랫폼이 맡는 구조다.1
Codex도 단순한 코드 생성 보조 도구에서 지속 실행형 개발 작업자로 이동하고 있다. 공식 요약에 따르면 클라우드에서 프로젝트를 실행하고, 여러 작업을 동시에 위임·추적하며, 코드 리뷰와 보안 스캔을 백그라운드에서 수행하는 기능이 확대됐다. 특히 Codex Security Cloud는 전체 GitHub 저장소를 주문형 또는 일정 기반으로 검사하고, 새로운 커밋을 계속 확인하며, 중복 탐지를 정리하고 수정안을 준비하는 흐름을 제시한다. 개발자의 노트북이 닫혀 있어도 클라우드에서 작업이 이어지는 방식은 ‘개발 도구’와 ‘운영 서비스’의 경계를 흐린다.1
일을 작은 결과 단위로 나눈다
기능 구현, 테스트, 문서 갱신, 보안 점검처럼 각각 독립적으로 검증 가능한 단위로 나눠 병렬 위임한다.
중간 과정을 읽을 수 있어야 한다
에이전트가 어떤 파일과 도구를 사용했고 왜 계획을 바꿨는지 추적할 수 있어야 실패 원인을 찾고 반복 작업을 개선할 수 있다.
완료의 기준을 자동 검증한다
테스트 통과, 정적 분석, 권한 범위, 변경 크기, 배포 전 체크리스트처럼 결과물의 품질 기준을 기계적으로 확인하는 장치가 필요하다.
되돌리기 어려운 행동은 사람이 잡는다
운영 배포, 데이터 삭제, 고객 공지, 결제·계약처럼 영향이 큰 단계는 사람 승인과 별도 감사 기록을 남기는 편이 안전하다.
ChatGPT Space: 파일 보관함이 ‘공동 작업면’으로 변한다
SHARED CONTEXT BECOMES PRODUCT INFRASTRUCTURE에이전트가 혼자 똑똑해도 팀의 맥락을 공유하지 못하면 실제 업무에서는 한계가 크다. OpenAI가 DevDay와 함께 내놓은 ChatGPT Space는 이 문제를 정면으로 겨냥한다. Help Center 설명에 따르면 Space는 파일과 페이지를 위한 공간이며 기존 Library를 대체한다. Pages는 다른 페이지 안에 구성할 수 있는 편집 가능한 문서이고, 사람들과 함께 공유해 협업할 수 있다. 공유된 콘텐츠 위에서 각 구성원은 자신의 ChatGPT 에이전트를 사용해 작업할 수 있다.5
이 구조는 협업 소프트웨어의 기본 단위를 ‘파일’에서 ‘맥락’으로 옮긴다. 지금의 협업 툴은 문서, 채팅, 프로젝트 보드, 저장소가 각각 분리돼 있고 사람은 링크를 오가며 배경 정보를 다시 설명한다. Space형 제품이 제대로 작동하면 문서의 최신 상태, 의사결정의 이유, 담당자, 관련 파일, 반복 업무를 AI가 같은 작업면에서 읽고 활용할 수 있다. 사람에게는 문서 검색 시간이 줄고, 에이전트에게는 매번 긴 프롬프트로 상황을 재설명할 필요가 줄어든다.
다만 공유 맥락이 커질수록 데이터 경계도 더 세밀해야 한다. Help Center는 페이지별 공유와 보기·편집 권한을 관리할 수 있고, 관리형 워크스페이스에서는 조직의 공유 정책이 적용된다고 설명한다. 팀에 참여했다고 개인 채팅이나 앱 연결이 자동으로 공유되는 것은 아니다. 이런 경계는 사소해 보이지만 매우 중요하다. 에이전트가 조직의 문서를 광범위하게 읽을 수 있는 환경에서는 ‘누가 볼 수 있나’가 곧 ‘어떤 에이전트가 추론 재료로 사용할 수 있나’가 되기 때문이다.
Decisions API가 보여주는 또 하나의 방향: 자유로운 생성보다 ‘제한된 선택’
BOUNDING THE ACTION SPACE모든 업무를 자유 형식 에이전트에게 맡기는 것이 최선은 아니다. 금융, 물류, 고객지원, 콘텐츠 정책, 보안 대응처럼 실제 시스템을 움직이는 결정은 가능한 선택지를 미리 제한하는 편이 훨씬 관리하기 쉽다. DevDay에서 공개된 Decisions API가 흥미로운 이유다. OpenAI는 사용자가 정의한 질문과 유한한 선택지에 Luna의 지능을 집중해, 텍스트나 이미지 맥락을 바탕으로 분류·라우팅·다음 행동 선택에 쓸 답을 반환하는 방식이라고 설명했다. 공개 당시에는 제한된 프리뷰였고 더 넓은 출시가 뒤따를 예정이라고 안내했다.1
이는 에이전트 설계의 중요한 원칙을 드러낸다. 자동화 수준을 높이는 것과 행동 공간을 넓히는 것은 같은 말이 아니다. 오히려 신뢰도가 필요한 시스템일수록 모델에게 자유를 덜 주고, 입력 형식과 가능한 출력, 호출 가능한 도구, 승인 조건을 좁게 정의한 뒤 그 안에서 높은 자동화를 구현하는 것이 현실적이다. ‘자율성’은 무제한 권한이 아니라 명확한 경계 안에서 사람이 매번 지시하지 않아도 움직이는 능력으로 정의하는 편이 맞다.
에이전트 제품의 진짜 혁신은 AI에게 더 많은 자유를 주는 데 있지 않다. 어디까지 자동으로 움직여도 되는지를 사람이 기계적으로 정의할 수 있게 만드는 것에 있다.
안전 평가는 더 무거워졌다: GPT‑6.1 Sol의 ‘Critical’ 분류를 읽는 법
CAPABILITY RISK IS NOT THE SAME AS EVERYDAY FAILURE RATE강력한 도구 사용 능력은 편리함과 위험을 동시에 키운다. OpenAI의 GPT‑6.1 Sol 시스템 카드 부록은 이 모델을 자사 Preparedness Framework에서 사이버보안 능력은 ‘Critical’, 생물·화학 관련 능력은 ‘High’로 취급하고 있으며 GPT‑6 Astra와 같은 안전장치 스택을 적용한다고 밝힌다.4 이 표현은 일반 사용에서 모델이 곧바로 위험한 행동을 한다는 뜻이 아니다. 특정 고위험 능력 영역에서 잠재적 역량이 높다고 평가돼 더 강한 완화 조치가 필요하다는 회사 내부 프레임워크상의 분류다.
이 점을 과장하거나 축소해서는 안 된다. ‘Critical’이라는 단어만 떼어 공포를 키우는 것도 부정확하고, 안전장치가 있으니 문제가 해결됐다고 보는 것도 성급하다. 에이전트는 모델의 출력이 실제 행동으로 연결되기 때문에 오류의 비용이 대화형 AI보다 커질 수 있다. 예를 들어 잘못된 요약은 사람이 읽고 바로잡을 수 있지만, 잘못된 자동화가 고객에게 메일을 보내거나 저장소 설정을 바꾸거나 외부 시스템에 데이터를 전달하면 복구 비용이 커진다.
권한 과다 부여
업무에 필요하지 않은 시스템과 데이터까지 접근 가능하면 작은 판단 오류가 훨씬 넓은 범위로 확산될 수 있다.
프롬프트 인젝션
웹페이지나 문서 속 악성 지시를 에이전트가 신뢰할 경우 원래 목표와 다른 행동을 할 수 있어 외부 콘텐츠 격리가 중요하다.
조용한 누적 오류
장기간 반복 작업에서는 작은 분류 오류나 데이터 누락이 매일 누적돼 뒤늦게 발견될 수 있다. 주기적 샘플 검토가 필요하다.
감사 불가능성
무엇을 보고 어떤 도구를 사용했는지 기록이 없다면 사고 후 원인을 재구성할 수 없다. 실행 로그는 선택 기능이 아니라 운영 자산이다.
10월 4일 로이터 보도에서 샘 올트먼은 AI의 이익이 일부 위험을 감수할 만할 정도로 크다고 강조하며 폭넓은 접근성과 비교적 가벼운 규제 접근을 지지하는 취지의 발언을 했다. 같은 보도는 Anthropic의 다리오 아모데이가 더 신중한 속도 조절 필요성을 강조해 온 것과 대비했다.7 이 논쟁은 에이전트가 실제 시스템과 연결될수록 더 구체적인 문제로 바뀐다. ‘개발을 멈출 것인가’라는 큰 질문뿐 아니라, 누가 어떤 권한을 갖고 어떤 업무를 자동화할 것인지가 매일의 제품 설계와 기업 정책에서 결정되기 때문이다.
기업의 구매 기준도 바뀐다: 좌석 수보다 ‘완료된 업무’
FROM SOFTWARE SEATS TO OUTCOME CAPACITY전통적인 SaaS는 좌석당 월 구독료가 가장 이해하기 쉬운 가격 단위였다. 그러나 상시형 에이전트는 한 명의 사용자가 여러 에이전트를 운영하거나, 하나의 에이전트가 여러 팀의 업무를 처리하는 구조를 만들 수 있다. 이때 단순 좌석 수는 실제 사용량과 비용을 설명하지 못한다. OpenAI도 dots 소개에서 첫 dot을 일부 요금제에 포함하고, 향후 더 많은 dot을 추가하거나 각 dot의 속도와 월간 작업량을 확장하는 방향을 언급했다.2
이 모델이 일반화되면 소프트웨어 구매 담당자는 ‘직원 100명에게 몇 좌석을 살까’보다 ‘한 달에 몇 건의 분석·개발·고객지원·보고서 업무를 자동 처리할까’를 따지게 된다. 에이전트가 사람의 일을 완전히 대체한다는 단순한 의미가 아니다. 오히려 사람의 역할이 예외 처리, 목표 정의, 품질 기준 설정, 최종 승인으로 이동하면서 동일한 인원으로 처리할 수 있는 업무량이 늘어나는 구조에 가깝다.
완료율과 사람 개입률
에이전트가 시작한 업무 중 몇 퍼센트가 사람의 추가 지시 없이 완료됐는지, 어떤 단계에서 승인이나 수정이 필요했는지를 측정해야 한다.
업무 한 건당 총비용
모델 토큰, 도구 호출, 클라우드 실행, 외부 SaaS 사용, 사람 검토 시간을 모두 합친 비용을 봐야 공급자와 모델을 제대로 비교할 수 있다.
오류의 심각도와 복구시간
모든 오류를 같은 숫자로 세지 말고, 고객 영향·데이터 손실·보안 위험·되돌리기 난이도에 따라 등급을 나눠야 한다.
감사 로그와 설명 가능성
결과만 남기는 자동화보다 어떤 자료와 권한을 사용해 결정했는지 재구성 가능한 자동화가 규제 산업과 대기업에서 더 높은 가치를 갖는다.
한국 기업이 바로 확인해야 할 세 가지
KOREA DEPLOYMENT CHECK국내 기업 입장에서는 ‘최신 모델을 쓸 것인가’보다 어떤 업무부터 에이전트화할지 정하는 순서가 중요하다. 특히 제조, 금융, 의료, 공공, 대기업 그룹웨어처럼 개인정보와 영업비밀이 많은 환경에서는 파일 접근·외부 전송·계정 권한·데이터 위치 조건을 먼저 검토해야 한다. GPT‑6.1 Sol의 공식 모델 페이지는 현재 US와 EU 데이터 레지던시 지원을 명시하고 있다. 이것이 곧 한국에서 사용할 수 없다는 뜻은 아니지만, 국내 규제 산업이 요구하는 데이터 처리 위치와 계약 조건을 자동으로 충족한다는 뜻도 아니다.3
읽기 전용 업무부터
시장 모니터링, 문서 요약, 코드 리뷰 초안, 내부 자료 분류처럼 되돌리기 쉽고 외부 행동이 없는 업무로 신뢰도를 측정한다.
에이전트 전용 권한
개인 직원 계정을 공유하기보다 에이전트 전용 자격증명과 최소 권한을 부여해 사고 범위와 감사 대상을 명확히 한다.
대외 행동은 승인
메일 발송, 게시, 배포, 결제, 계약, 데이터 삭제처럼 되돌리기 어려운 단계에는 사람 승인을 기본으로 둔다.
또한 한국어 성능만 보고 도입 여부를 판단해서는 안 된다. 실제 운영에서는 사내 문서 형식, 전자결재, 그룹웨어, ERP, 보안 솔루션과의 연결이 더 큰 장애물이 될 수 있다. 반대로 이 연결층이 안정적으로 구축되면 모델이 한두 단계 향상되는 것보다 훨씬 큰 생산성 차이를 만들 수도 있다. 에이전트 시대에는 ‘우리 회사의 데이터와 도구를 안전하게 연결하는 능력’ 자체가 중요한 디지털 자산이 된다.
제품 인터페이스도 달라진다: 채팅창보다 ‘작업 관제판’
THE UI SHIFTS FROM CONVERSATION TO OPERATIONS상시형 에이전트가 보편화되면 AI 서비스의 화면도 변할 수밖에 없다. 사용자가 매 순간 대화하지 않는다면 가장 중요한 화면은 입력창이 아니다. 현재 무엇을 하고 있는지, 어디서 막혔는지, 어떤 승인을 기다리는지, 비용이 얼마나 들었는지, 결과물은 어디에 저장됐는지를 한눈에 보여주는 관제판이 중심이 된다. OpenAI가 dots에서 Activity View와 승인 흐름을 강조하는 것도 이런 맥락으로 볼 수 있다.2
이때 좋은 인터페이스는 AI의 자율성을 과시하는 화면이 아니라 사람의 판단 부담을 줄이는 화면이어야 한다. 승인 요청이 너무 잦으면 사용자는 결국 모든 알림을 무시하게 되고, 너무 적으면 중요한 행동이 자동으로 통과할 수 있다. 따라서 위험도와 확신도에 따라 승인 정책을 다르게 하고, 여러 에이전트가 같은 사안을 중복으로 처리하지 않도록 우선순위와 소유권을 명확히 해야 한다.
기업용 AI가 메신저, 문서, 브라우저, 개발환경, CRM, ERP로 확장될수록 ‘AI가 어디에 있나’라는 질문도 의미가 약해진다. 하나의 앱 안에 갇힌 기능이 아니라 각 업무 표면에서 호출되는 공통 실행 계층이 되기 때문이다. OpenAI가 dots를 ChatGPT, Slack, Teams에서 이어서 사용할 수 있다고 설명하고, DevDay에서 ChatGPT를 사람과 에이전트가 협업하는 공유 표면으로 강조한 것도 이 흐름을 보여준다.12
아직 남은 불확실성: 기술보다 운영 문화가 더 느릴 수 있다
WHAT IS STILL UNPROVEN큰 방향이 선명하다고 해서 상시형 에이전트가 곧바로 모든 조직의 표준이 된다는 뜻은 아니다. 첫째, 장시간 작업의 신뢰성은 짧은 벤치마크보다 검증하기 어렵다. 에이전트는 수십 단계 동안 아주 작은 판단을 이어가는데 한 번의 오류가 후속 단계에 누적될 수 있다. 둘째, 업무의 상당수는 문서화되지 않은 암묵지와 인간관계, 조직 정치, 책임 소재에 의존한다. 이런 요소는 데이터로 연결한다고 자동으로 해결되지 않는다.
셋째, ‘항상 켜짐’은 생산성뿐 아니라 관리 피로를 만들 수 있다. 여러 에이전트가 동시에 질문과 승인 요청을 보내면 사람은 새로운 종류의 알림 과부하를 겪게 된다. 넷째, 외부 SaaS와 브라우저에 연결되는 자동화는 공급망 보안과 서비스 변경에 민감하다. 오늘 잘 작동하던 페이지 구조와 권한 정책이 내일 바뀌면 자동화가 멈추거나 예상하지 못한 행동을 할 수 있다. 에이전트 운영은 소프트웨어 배포처럼 지속적인 관찰과 유지보수를 필요로 한다.
마지막으로 제품 출시 상태 자체도 유동적이다. dots는 9월 29일 발표 당시 eligible markets의 Pro 및 Business Premium 사용자에게 순차 출시되고, Enterprise·Edu·Healthcare에서는 관리자가 활성화할 수 있는 베타 형태로 안내됐다. ChatGPT Space 관련 기능 역시 Help Center에서 점진적 롤아웃 중이라고 명시한다.25 따라서 특정 기능이 모든 계정과 지역에서 즉시 동일하게 보일 것이라고 단정해서는 안 된다.
독자가 궁금해할 핵심 질문
dots는 그냥 더 강한 챗봇인가?
차이는 지속성과 행동 범위다. OpenAI 설명상 dots는 자체 클라우드 컴퓨터를 사용하고 여러 프로젝트를 이어서 진행하며 연결된 앱과 브라우저를 활용한다. 사용자가 직접 대화하지 않는 시간에도 제한된 읽기 전용 방식으로 정보를 탐색할 수 있어 일반적인 세션형 챗봇보다 운영형 에이전트에 가깝다.
에이전트가 마음대로 메일을 보내거나 파일을 바꿀 수 있나?
공식 설명은 권한과 승인 규칙을 강조한다. 백그라운드 proactive research는 읽기 전용 도구로 제한되고, 행동은 기존 앱 권한과 Custom Rules, auto-review를 거친다. 다만 실제 연결 범위는 사용자가 부여한 권한과 제품 설정에 따라 달라지므로 최소 권한 원칙이 중요하다.
GPT‑6.1 Sol이 GPT‑6 Astra를 대체하나?
OpenAI는 Sol을 복잡한 업무에서 Astra에 가까운 성능을 더 낮은 비용으로 제공하는 모델로 포지셔닝한다. 최고 성능이 필요한 작업은 Astra, 반복적으로 많이 실행해야 하는 복잡한 작업은 Sol처럼 용도와 비용에 따라 선택하는 구조에 가깝다.
한국 기업은 바로 도입해도 되나?
기능 실험은 가능하지만 민감한 데이터와 실제 시스템 행동이 포함된 업무는 별도 검토가 필요하다. 계정 권한, 데이터 저장·처리 위치, 외부 SaaS 연결, 감사 로그, 승인 정책, 장애 복구 절차를 먼저 정하고 읽기 전용 저위험 업무에서 시작하는 편이 안전하다.
이 변화가 일자리를 곧바로 대체한다는 뜻인가?
현재 공개된 제품 구조만으로 즉각적인 대규모 대체를 단정하기 어렵다. 더 직접적인 변화는 업무의 분해 방식이다. 반복 단계는 에이전트에 위임하고 사람은 목표 설정, 예외 처리, 품질 판단, 책임이 큰 의사결정에 더 집중하는 형태가 먼저 확산될 가능성이 크다.
주요 출처
- OpenAI, DevDay 2026 Recap — 2026년 9월 29일 발표 내용과 Codex·Decisions API·Agents API 등 공식 요약.
- OpenAI, Introducing dots — dots의 클라우드 컴퓨터, 권한, proactive research, 승인, 출시 대상에 대한 공식 설명.
- OpenAI API, GPT‑6.1 Sol model page 및 API Changelog — 컨텍스트, 출력 한도, 가격, 도구 지원, 데이터 레지던시.
- OpenAI Deployment Safety Hub, GPT‑6.1 Sol System Card Addendum — Preparedness Framework 분류와 안전장치 설명.
- OpenAI Help Center, ChatGPT Space: sharing, data, and controls — Space·Pages·공유 권한·점진적 출시 안내.
- Reuters, 2026년 9월 29일 — DevDay의 상시형 에이전트 및 기업용 AI 경쟁 맥락.
- Reuters, 2026년 10월 4일 — AI 위험 수용과 규제 속도를 둘러싼 업계 논쟁.
- Axios, 2026년 9월 29일 — DevDay 주요 발표의 외부 보도와 산업적 의미.
댓글
댓글 쓰기