지금까지 ChatGPT를 사용하는 가장 익숙한 흐름은 이렇습니다.

사람이 질문
 ↓
AI가 답변
 ↓
대화 종료

그런데 2026년 9월 29일 OpenAI가 공개한 Dots는 출발점부터 다릅니다.

Dot에게는 한 번의 질문보다 지속해서 맡길 책임을 줍니다.

"이 프로젝트를 계속 추적해줘."
"매일 내 일정을 살펴보고 준비할 것을 알려줘."
"이 주제를 계속 조사하고 중요한 변화가 생기면 가져와줘."

그리고 Dot은 대화가 끝났다고 모든 일을 멈추지 않습니다.

OpenAI는 이를 always-on agent라고 설명합니다.

일반 ChatGPT와 무엇이 다른가요?

가장 단순하게 그리면 이렇습니다.

일반 ChatGPT

Message
  ↓
Reasoning
  ↓
Answer


Dot

Long-term goal
     ↓
Context + Memory
     ↓
Connected apps
     ↓
Cloud computer
     ↓
Scheduled / proactive work
     ↓
결과 정리
     ↓
필요할 때 사용자에게 질문
     ↺

Dot은 GPT-6 Astra를 기반으로 하며 자신의 cloud computer를 가질 수 있습니다.

연결한 앱의 정보를 읽고, 장기적인 맥락을 기억하며, scheduled task나 ongoing work를 계속 이어갈 수 있습니다.

핵심은 응답하는 AI가 아니라 책임을 유지하는 AI에 가깝다는 점입니다.

Persistent Agent에서 가장 중요한 것은 Memory만이 아닙니다

"계속 기억한다"는 설명만 보면 일반 memory 기능과 비슷해 보입니다.

하지만 실제 persistent agent에는 네 가지 축이 필요합니다.

1. Goal
   무엇을 계속 달성해야 하는가?

2. State
   지금 어디까지 진행했는가?

3. Tools
   무엇을 읽고 무엇을 실행할 수 있는가?

4. Permission
   어디까지 혼자 해도 되는가?

Dots는 이 네 가지를 제품 수준에서 묶으려는 시도입니다.

예를 들어 일정 관리 Dot이라면:

Goal
"중요한 일정을 놓치지 않는다"

State
"내일 발표가 있고 자료는 아직 미완성"

Tools
Calendar / files / connected apps

Permission
읽기는 자동
일정 변경은 승인 필요
외부 메시지는 승인 필요

처럼 역할을 나눌 수 있습니다.

Proactive Research는 "마음대로 행동"과 다릅니다

Dots가 흥미로운 이유 중 하나는 사용자가 매번 질문하지 않아도 필요한 정보를 먼저 찾을 수 있다는 점입니다.

OpenAI는 이를 proactive research라고 부릅니다.

하지만 launch 시점에는 여기에도 중요한 제한이 있습니다.

proactive research 도구는 직접:

  • 다른 사람에게 메시지를 보내거나
  • plugin을 통해 내용을 변경하거나
  • browser/computer를 제어

할 수 없습니다.

즉 개념적으로는:

백그라운드 조사
──────────────
읽기 + 정리 + private notes
        ↓
필요한 변화 발견
        ↓
사용자에게 가져옴
        ↓
행동은 별도 permission / approval

에 가깝습니다.

"항상 켜져 있다"와 "항상 마음대로 행동한다"는 전혀 다른 이야기입니다.

Approval이 Persistent Agent의 핵심 기능이 되는 이유

짧은 chat에서 실수하면 보통 답변 하나가 틀립니다.

Persistent Agent가 실수하면 실제 상태가 바뀔 수 있습니다.

잘못된 메일 전송
잘못된 일정 변경
잘못된 파일 수정
잘못된 구매

그래서 agent capability가 높아질수록 permission 설계가 중요해집니다.

Dots에는 Custom Rules를 통해 지원되는 action을 대략 다음처럼 나눌 수 있습니다.

Allow
혼자 실행 가능

Ask
실행 전에 사용자 승인 필요

Block
실행하지 않음

다만 Custom Rules가 모든 안전장치를 끌 수 있는 것은 아닙니다.

OpenAI는 core safety requirement와 별도의 Auto-review, proactive research 제한 등은 Custom Rules로 해제할 수 없다고 설명합니다.

자신의 컴퓨터까지 연결할 수 있습니다

Dot은 기본적으로 자신의 cloud computer를 사용합니다.

local computer 접근은 별도이며 기본으로 꺼져 있습니다.

사용자가 desktop app에서 컴퓨터를 연결하고 접근을 허용하면 Dot은 해당 컴퓨터의 파일이나 local browser가 필요한 작업을 수행할 수 있습니다.

구조를 나누면 이렇습니다.

                 ┌─ Cloud computer
Dot ─────────────┤
                 └─ Local computer (명시적으로 연결한 경우)

이 구분도 중요합니다.

"Dot을 만들었다"는 이유만으로 자동으로 내 로컬 PC 전체에 접근하는 구조는 아닙니다.

CodeBridge Mini Lab: 항상 켜져 있는 Agent의 권한표를 먼저 만들어보세요

실제 Dot을 만들기 전에도 설계 연습을 할 수 있습니다.

예를 들어 "개발 프로젝트 관리 Agent"를 만든다고 해보겠습니다.

먼저 가능한 행동을 적습니다.

GitHub issue 읽기
PR 상태 읽기
빌드 결과 읽기
새 issue 만들기
issue 닫기
PR merge
Slack 메시지 전송

그리고 분류합니다.

Action Allow Ask Block
Issue 읽기 ✓
Build 상태 확인 ✓
Issue 생성 ✓
PR merge ✓
Production 삭제 ✓

여기서 중요한 것은 Agent가 얼마나 똑똑한지가 아닙니다.

잘못됐을 때 피해가 큰 행동일수록 더 강한 제약을 둔다는 원칙입니다.

"Proactive"에는 평가 방식도 달라져야 합니다

일반 chatbot은 정답 여부를 보면 됩니다.

Persistent agent는 이것만으로 부족합니다.

정확한 정보를 찾았는가?
+
필요할 때만 사용자에게 알렸는가?
+
중복 알림이 없는가?
+
승인이 필요한 행동을 멋대로 하지 않았는가?
+
며칠 뒤에도 같은 목표를 유지하는가?

즉 accuracy에서 reliability와 policy adherence까지 평가 범위가 넓어집니다.

OpenAI의 GPT-6 Astra System Card도 Dots를 별도 harness로 보고, 장기간의 proactive work가 alignment에 어떤 영향을 주는지 별도 평가를 진행했다고 설명합니다.

Persistent Agent는 결국 작은 운영체계가 됩니다

Dot을 단순히 "ChatGPT에 캐릭터 하나 추가"라고 보면 구조가 잘 보이지 않습니다.

조금 더 기술적으로 보면:

Model
+
Memory
+
Apps
+
Computer
+
Scheduler
+
Rules
+
Approvals
+
Subagents
=
Persistent Agent

입니다.

이 중 하나라도 흔들리면 장기적으로 안정적으로 일하기 어렵습니다.

특히 작업 기간이 길어질수록 context 관리, checkpoint, permission, verification이 중요해집니다.

결론: Chatbot 다음 경쟁은 "누가 오래 책임질 수 있는가"일 수 있습니다

Dots가 보여주는 가장 큰 변화는 UI가 아닙니다.

기존 AI는 사람이 필요할 때 불러서 쓰는 도구였습니다.

Dots는 목표를 맡고 다음 대화 사이에도 상태를 유지하며 일하는 방향을 보여줍니다.

Chatbot
"지금 이것을 답해줘"

↓

Persistent Agent
"이 책임을 계속 맡아줘"

이 차이가 커질수록 좋은 프롬프트 하나보다 장기 목표, 권한, 검증, 기억, 반복 구조를 설계하는 능력이 더 중요해질 가능성이 큽니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

Persistent Agent를 만들 때 핵심은 "항상 켜두기"가 아니라 컨텍스트·하네스·루프·그래프와 권한을 설계해 오래 일해도 통제 가능한 구조를 만드는 것입니다. 이 구조를 단계별로 연습하고 싶다면 아래 강의가 가장 가깝습니다.