OpenAI Dots를 24시간 돌아가는 개인용/팀용 자율 에이전트 조직으로 설계하는 방법

한 줄 요약

기존 AI가 사람이 프롬프트를 넣을 때만 움직이는 도구였다면, Dots는 각 에이전트에게 클라우드 컴퓨터·브라우저·파일·메모리·스케줄러를 주고, 역할을 나눠 24/7 지속적으로 일하게 만드는 구조라는 이야기입니다.

---

1. Dots가 무엇인가

글에서 설명하는 Dots의 핵심은 단순 채팅봇이 아니라 상시 실행되는 클라우드 에이전트입니다.

각 Dot은 독립적으로 다음 환경을 가진다고 설명합니다.

• 전용 클라우드 컴퓨터
• 브라우저
• 터미널
• 파일 시스템
• 지속 메모리
• 예약 실행 스케줄러
• 외부 서비스 연결
• 다른 에이전트에게 작업 위임

즉,

내 PC를 꺼도 → 클라우드에서 계속 업무 수행

이라는 개념입니다.

기존 방식:

사람 → ChatGPT → 답변 → 사람이 복사/실행

Dots 방식:

사람 → 목표 설정 → Dot이 조사/실행/위임 → 사람은 검토/승인

---

2. 가장 중요한 설계 원칙: “범용 비서”를 만들지 말 것

글에서 가장 강조하는 부분입니다.

나쁜 예:

General Assistant
“내 업무를 도와줘.”

좋은 예:

경쟁사 조사 담당
고객 리드 조사 담당
GitHub 이슈 분석 담당
콘텐츠 제작 담당
운영 리포트 담당

각 Dot은 한 가지 명확한 책임을 가져야 합니다.

Dot을 만들 때 5가지 조건

1. Specific Goal
   • 하나의 명확한 업무 영역
2. Dedicated Sources
   • 사용할 데이터/문서/서비스 지정
3. Distinct Working Style
   • 결과 형식과 작업 방법 정의
4. Strict Approval Boundary
   • 어디까지 자동으로 하고 어디서 인간 승인을 받을지 결정
5. Cadence / Trigger
   • 언제 작동할지 정의
   • 예: 매일 오전 8시
   • GitHub Issue 생성 시
   • 회의 종료 시

---

3. Description이 사실상 에이전트의 “직무 계약서”

Dot을 만들 때 Description을 아주 중요하게 봅니다.

예:

Name: Vance
Role: Operations Coordinator

Responsibility:
제품 출시 준비 상태를 점검한다.

Rules:
1. 모든 사실에는 출처를 표시한다.
2. 자료가 충돌하면 충돌 사실을 보고한다.
3. 외부 메시지 발송은 인간 승인 후 실행한다.

핵심은:

일시적인 작업은 채팅에 넣고
영구적인 규칙은 Description에 넣는다.

이 Description이 많아지면 결국 AI 조직도가 됩니다.

---

4. Cloud Browser가 핵심

Dots의 강력한 기능 중 하나로 소개되는 것이 지속되는 브라우저 세션입니다.

예를 들어:

• Jira
• Linear
• Stripe
• Salesforce
• GitHub
• 사내 관리자 페이지

등에 로그인하면 로그인 세션을 계속 유지합니다.

흐름:

Dot Cloud Browser 실행
↓
사람이 로그인
↓
2FA 인증
↓
Return Control
↓
Dot이 이후 해당 사이트를 사용

이후 노트북을 꺼도 Dot이 계속 접근할 수 있다는 구조입니다.

다만 글에서도 중요한 점을 하나 짚습니다.

서비스를 연결했다고 자동으로 일을 시작하는 것은 아닙니다.

Connection = 접근 권한

Schedule / Trigger = 업무 지시

입니다.

---

5. Multi-Agent 구조

이 글에서 가장 흥미로운 부분입니다.

여러 Dot을 만들고 하나를 Chief of Staff, 즉 총괄 에이전트로 두는 구조입니다.

예:

사용자
  ↓
Vance
Chief of Staff
  ↓
 ├─ Mara : 리드 조사
 ├─ Cole : 아웃리치
 ├─ Rina : 콘텐츠
 └─ Owen : 데이터 분석

사용자는 Vance하고만 대화합니다.

예를 들어:

이번 주 신규 SaaS 고객 후보 30개 조사하고
제안서까지 만들어줘.

라고 하면

Vance
 ↓
Mara → 기업 조사
 ↓
Cole → 연락 문안 작성
 ↓
Rina → 제안 자료 제작
 ↓
Owen → 예상 매출 분석
 ↓
Vance → 결과 통합

이런 구조입니다.

---

6. Context Isolation

멀티에이전트에서 중요한 문제 중 하나가 컨텍스트 오염입니다.

모든 에이전트가 전체 대화를 공유하면:

• 토큰 증가
• 응답 지연
• 불필요한 정보 혼입
• 환각 증가

문제가 발생합니다.

그래서 글에서는 이런 구조를 권장합니다.

Chief Agent
   ↓
필요한 정보만 Worker에게 전달
   ↓
Worker 작업
   ↓
구조화된 결과만 반환

예:

Vance
↓
Mara에게 전달

기업 20개 조사
필드:
company
industry
employee_count
hiring_signal
source

↓
Mara 결과 반환
↓
Vance가 통합

전체 대화 기록을 넘기지 않는다는 것이 핵심입니다.

---

7. 24/7 Agent의 핵심은 Schedule + Event Trigger

진짜 자율 에이전트가 되려면 사용자가 Enter를 누르지 않아도 움직여야 합니다.

예:

Schedule

매일 오전 08:30

CRM 확인
↓
고객 상태 변화 분석
↓
경쟁사 뉴스 조사
↓
Slack에 리포트 작성

Event Trigger

GitHub Issue 생성
↓
Dot 실행
↓
문제 분석
↓
Codex에게 수정 요청
↓
PR 생성

즉,

TIME
EVENT
WEBHOOK
QUEUE

등이 에이전트를 깨우는 구조입니다.

---

8. 가장 중요한 안전 원칙

글에서는 이를 Reversibility Law라고 부릅니다.

정리하면:

자동 실행 가능

• 읽기
• 검색
• 분석
• 요약
• 초안 작성

인간 승인 필요

• 이메일 발송
• 고객 메시지 발송
• DB 삭제/수정
• 결제
• 구매
• 코드 배포
• production merge

즉:

READ
ANALYZE
DRAFT

→ 자동

WRITE
SEND
DELETE
PAY
PUBLISH

→ 승인 필요

이 구조가 실무에서는 매우 중요합니다.

---

9. Kill Switch도 필요

에이전트가 잘못 행동할 때 즉시 중단할 수 있어야 합니다.

글에서는 3가지 중단 지점을 이야기합니다.

① Main Agent Pause

현재 메인 작업 중지

② Worker Activity Stop

하위 에이전트 작업 중단

③ Scheduled Job Disable

예약 작업 중지

특히 중요한 점:

메인 에이전트를 멈춰도 예약 작업이 계속 실행될 수 있다.

그래서 운영 중지 시:

Agent
Worker
Schedule

3개를 모두 확인해야 한다는 내용입니다.

---

10. 모델을 역할별로 나누라는 전략

글은 모델 비용을 줄이기 위해 역할별 모델 라우팅을 제안합니다.

Astra

고난도 판단용

예:

• Chief of Staff
• 전략
• 복잡한 의사결정
• 최종 결과 검수

Sol

대량 처리용

예:

• 문서 요약
• 데이터 분류
• 웹 조사
• 일일 리포트
• 코드 리팩터링

Astra Ultrafast

속도가 중요한 개발 작업

예:

• Codex
• 코드 생성
• 반복 개발

결국 이런 구조입니다.

쉬운 일
↓
저렴한 모델

어려운 일
↓
고성능 모델

이 방식은 Jev에서 이야기했던 Decision Routing 구조와도 상당히 비슷합니다.

---

11. Space를 조직의 “공용 기억”으로 사용

멀티에이전트가 채팅만 사용하면 정보가 흩어집니다.

그래서 글에서는 ChatGPT Space/Pages 같은 공간을 Single Source of Truth로 사용합니다.

예:

Project Space

Launch Brief
Pricing
Product Specs
Decisions
Open Issues
Approved Claims

Dots는 여기서 자료를 읽고 작업합니다.

새로운 결정이 나오면:

기존 문서
↓
Dot 수정 제안
↓
사람 승인
↓
최신 버전 업데이트

이렇게 프로젝트 지식을 유지합니다.

---

12. Codex와 연결하면 개발 조직도 자동화 가능

예를 들어:

GitHub Issue
↓
Monitoring Dot
↓
Codex Cloud
↓
버그 재현
↓
테스트 코드 작성
↓
코드 수정
↓
테스트 실행
↓
PR 생성
↓
사람 리뷰

개발자가 직접

git pull
branch
debug
test
push
PR

하는 반복 작업을 줄이는 구조입니다.

---

13. 4가지 실제 Agent 조직

Blueprint 1

Autonomous Launch Coordinator

제품 출시 관리 에이전트

연결:

• Google Docs
• Slack
• Linear

작업:

커밋
고객 피드백
blocker
↓
분석
↓
Launch Report

외부 메시지는 승인 필요.

---

Blueprint 2

Continuous Lead Intelligence

영업 리드 탐색 에이전트

연결:

• 웹브라우저
• LinkedIn
• 회사 채용 페이지
• Google Sheets

24시간:

회사 탐색
↓
채용 정보
↓
조직 변화
↓
담당자 조사
↓
Outreach Draft

자동 이메일 발송은 하지 않습니다.

---

Blueprint 3

Security & Dependency Auditor

개발 보안 에이전트

연결:

• GitHub
• Codex

작업:

PR
↓
dependency 검사
↓
보안 취약점 검사
↓
secret 검사
↓
patch 작성
↓
PR

merge는 인간 승인.

---

Blueprint 4

Meeting Follow-Up Agent

회의 관리 에이전트

연결:

• Teams
• Meeting Transcript
• Notion

작업:

회의 종료
↓
Transcript
↓
Decision 추출
↓
Action Item
↓
담당자
↓
후속 이메일 Draft

---

결국 이 글의 진짜 핵심

이 글은 Dots 기능 소개처럼 보이지만 실제로는 AI 조직 설계 방법론에 가깝습니다.

기존 AI:

사람
↓
AI
↓
답변

Agent 시대:

사람
↓
Chief Agent
↓
────────────
Research Agent
Coding Agent
Data Agent
Content Agent
Operations Agent
────────────
↓
공통 Workspace
↓
Human Approval

그리고 운영을 가능하게 하는 핵심 6요소가 있습니다.

요소역할

Role	에이전트 책임
Tools	사용할 서비스
Memory	지속적인 지식
Trigger	실행 시점
Delegation	다른 Agent에게 작업 위임
Approval	인간 승인 경계

---

한 문장으로 다시 표현하면

AI에게 질문하는 시대에서, AI 조직에 일을 맡기는 시대로 이동하고 있다는 이야기입니다.

그리고 가장 현실적으로 가져갈 부분은 **“Dot 하나를 똑똑하게 만드는 것보다, 역할·권한·트리거·승인 경계를 잘 나눈 여러 에이전트 조직을 설계하는 것이 중요하다”**는 점입니다.