OpenAI가 9월 29일 DevDay에서 dot을 발표했습니다. GPT-6 Astra를 기반으로 구동되는 ChatGPT 내 상시 가동(always-on) 에이전트로, 각자 전용 클라우드 컴퓨터와 브라우저를 갖추고 있으며 ChatGPT뿐 아니라 Slack과 Teams에서도 연결할 수 있습니다. 이미 코딩 에이전트를 도입해 활용 중인 팀에게 가장 중요한 문장은 OpenAI의 발표문 상단에 적혀 있습니다. “오늘부터 첫 번째 기본 dot을 시작해 이름을 붙이고 자신만의 에이전트로 맞춤 설정할 수 있습니다. 앞으로는 여러 dot이 팀을 이루어 사용자를 대신해 협업하는 모습을 그리고 있습니다.” 즉, dot은 한 사람을 위한 개인 에이전트로 시작합니다. 여러 dot으로 구성된 팀은 향후 나아갈 방향일 뿐, 이번 출시의 본모습은 아닙니다.
이러한 출시 순서는 합리적이지만, 이미 첫 에이전트 단계를 넘어선 팀에게는 공백을 남깁니다. OpenAI가 제시한 개발자 활용 예시를 보면, dot은 고객 피드백을 모니터링하고 작은 수정 사항을 직접 빌드 및 테스트한 뒤 “검토 가능한 완성된 PR”을 가져옵니다. 만약 동일한 팀이 공유 서버에서는 Claude Code를 실행하고 두 대의 노트북에서는 Codex를 구동하고 있다면, 동일한 리뷰어에게 전달되는 풀 리퀘스트 생성처가 하나 더 늘어난 셈입니다. 이제 핵심 질문은 더 이상 '어떤 에이전트가 가장 똑똑한가'가 아닙니다. '어떤 에이전트가 무슨 작업을 맡고 있는지', '무엇이 완료되었는지', 그리고 '사람의 확인을 기다리는 작업이 무엇인지'가 중요해집니다.
TL;DR
OpenAI dot은 매우 강력한 개인용 에이전트입니다. 상시 가동되며, 자체 클라우드 컴퓨터에서 작업하고, 플러그인을 통해 4,000개 이상의 앱과 연동됩니다. 또한 Custom Rules, Activity View, 자동 검토(auto-review), 그리고 실행을 일시 중지하거나 중단할 수 있는 모니터링 기능의 제어를 받습니다. OpenAI 생태계 안에서 개인이 반복 업무를 처리할 때는 dot이 훨씬 간단한 해결책입니다. 하지만 여러 벤더의 에이전트를 함께 운용하는 팀에게는 여전히 단일 보드가 필요합니다. 각 에이전트가 Task의 Assignee(담당자)로 지정되고, 진행 상태가 팀 전체에 투명하게 공개되며, 결과물이 검토를 위해 돌아오고, 최종적으로 사람이 작업을 승인하는 공간 말입니다. 이 둘은 서로 다른 계층이며 상호 보완적으로 쌓아 올릴 수 있습니다.
OpenAI의 dot이란 무엇인가
OpenAI dot은 GPT-6 Astra 기반의 상시 가동형 ChatGPT 에이전트로, 사용자가 다른 업무로 바쁜 와중에도 전용 클라우드 컴퓨터에서 사용자의 목표를 향해 작업을 수행합니다. dot에 이름을 붙이고 앱을 연결한 후 데스크톱, 웹, 모바일의 ChatGPT는 물론 Slack, Teams, 음성 통화를 통해 대화할 수 있으며, 문자 메시지 지원도 곧 추가될 예정입니다. 피드백을 통해 사용자의 선호도를 학습하고, 여러 프로젝트를 동시에 진행하는 도중에도 새 프로젝트를 맡을 수 있으며, 진행 상황이나 질문, 사용자 결정이 필요한 사항을 메시지로 전달합니다.
dot이 일반적인 챗봇 어시스턴트와 차별화되는 지점은 크게 두 가지입니다. 첫 번째는 컴퓨터입니다. dot은 독립적인 브라우저와 클라우드 컴퓨터를 갖추고 있어 사용자가 언제든 해당 컴퓨터를 열어 작업 내용을 확인할 수 있으며, 필요 시 사용자의 노트북을 사용하도록 권한을 부여할 수도 있습니다. 두 번째는 주도성(initiative)입니다. 사용자가 직접 상호작용하고 있지 않을 때도 dot은 OpenAI가 '능동적 조사(proactive research)'라 부르는 작업을 수행합니다. 이때 읽기 전용으로 제한된 도구를 통해 연결된 앱을 탐색하므로, 정보를 조회할 수는 있지만 메시지를 보내거나 앱 콘텐츠를 수정하거나 사용자의 브라우저 및 컴퓨터를 임의로 제어하지는 못합니다.
| 항목 | OpenAI 공식 내용 |
|---|---|
| 모델 | GPT-6 Astra |
| 작업 환경 | 자체 클라우드 컴퓨터 및 브라우저 (사용자가 허용한 경우에만 사용자 노트북 사용) |
| 지원 앱 | ChatGPT 플러그인을 통해 4,000개 이상 지원 |
| 접근 채널 | ChatGPT(데스크톱, 웹, 모바일), Slack, Teams, 음성 통화 (문자 메시지 지원 예정) |
| 지원 플랜 | 지원 대상 지역의 Pro 및 Business Premium에 순차 배포. Enterprise, Edu, Healthcare는 관리자가 활성화 시 베타 제공(기본값은 비활성화) |
| 사용량 | 첫 번째 dot 기본 포함. dot과의 대화는 ChatGPT 사용량 한도에 반영되지 않으나, Codex 또는 ChatGPT Work에서 시작한 작업은 한도에 포함됨 |
| Specialist dots | 특정 엔터프라이즈 파일럿 전용: 자체 신원, 자격 증명, IT 부서에서 프로비저닝한 하드웨어, 핵심 시스템(systems of record)과의 연동 제공 |
| Microsoft 연동 | Agent 365 거버넌스 및 보안 제어 기능과 Specialist dots의 통합 작업 진행 중 |
Specialist dots는 조직 단위의 버전이며, OpenAI는 둘의 차이를 명확히 구분합니다. “개인용 dot은 사용자를 대신해 작업하며, specialist dots는 조직 내에서 전담 업무를 맡습니다.” 기업은 각 specialist dot에 고유한 신원, 자격 증명, 필요한 시스템 접근 권한을 부여하며, OpenAI 엔지니어들이 해당 조직과 협력하여 책임 범위와 도구, 그리고 “사람이 작업 결과를 검토하고 승인하는 방식”을 정의합니다. 바로 이 마지막 문장에 주목할 필요가 있습니다.
“내 dot이 무엇을 할 수 있는가”에 답하는 제어 기능들
dot은 세심하게 설계된 권한 모델을 탑재하고 출시됩니다. 내장된 규칙이 dot이 단독으로 실행할 작업과 승인을 구할 작업을 판단합니다. Custom Rules를 통해 특정 작업을 허용하거나, 승인을 요구하거나, 차단할 수 있습니다. 자동 검토(auto-review) 기능은 계정에 영향을 주거나 정보를 공유할 수 있는 작업을 사용자의 지침 및 규칙과 대조하여 점검하며, 비밀번호 변경과 같은 민감한 작업은 항상 사람의 손에 맡겨집니다. Activity View에서는 백그라운드 작업을 포함한 진행 상황을 확인하고 작업 방향을 전환할 수 있습니다. 또한 OpenAI의 모니터링 시스템이 안전 문제를 감지하면 dot의 작업을 일시 중지하거나 중단시킬 수 있습니다.
이는 개인용 에이전트에 딱 맞는 제어 장치들이며, OpenAI 역시 2인칭 관점(여러분의 앱, 여러분의 규칙, 여러분의 승인)으로 이를 설명합니다. OpenAI의 자체 권고 사항도 이와 일맥상통합니다. “dot 역시 실수를 저지를 수 있으므로 중요한 작업은 반드시 직접 검토하세요.”
팀 차원에서는 이보다 한 단계 더 높은 수준의 동일한 요구가 발생합니다. 이제 질문은 '내 dot이 무엇을 할 수 있는가'가 아니라 '이 프로젝트의 모든 에이전트가 지금 무엇을 하고 있으며, 최종 승인자는 누구인가'가 됩니다. OpenAI 역시 그 해답의 일부가 에이전트 외부에 존재해야 함을 이미 인식하고 있습니다. Microsoft와의 협업 목표로 기업이 “이미 사용 중인 Microsoft 도구를 통해 dot을 관리할 수 있도록 하는 것”을 꼽은 것만 봐도 알 수 있습니다. 관리 계층은 에이전트보다 상위에 위치하며, 칸반과 같은 프로젝트 보드 또한 바로 그 계층에 자리 잡습니다.
팀 리드가 여전히 던지게 되는 질문들
규모가 작은 프로덕트 팀을 떠올려 보세요. 한 엔지니어는 dot을 쓰고 있고, 공유 서버에서는 Claude Code가 실행 중이며, 두 대의 노트북에서는 Codex가 돌아가고 있고, Gemini는 문서를 작성합니다. 각 에이전트는 저마다 제 몫을 훌륭히 해냅니다. 하지만 월요일 주간 회의를 가득 채우는 질문들은 특정 에이전트 하나에 국한된 것이 아닙니다.
| 팀 리드가 던지는 질문 | dot이 제공하는 것 | 보드가 더해주는 가치 |
|---|---|---|
| 결제 버그는 누가 작업 중인가요? | dot 소유자가 dot에게 직접 묻거나 Activity View를 통해 확인 | 어떤 Runtime에서 실행되든 모든 Task에 사람, Agent, Crew 등 Assignee가 명확히 표시됨 |
| 어젯밤에 무엇이 완료되었고, 무엇이 실패했나요? | 소유자에게 전달된 진행 메시지, 백그라운드 작업을 볼 수 있는 Activity View | Space에 속한 누구나 열어볼 수 있는 보드에서 각 Task의 실행 상태(대기 중, 실행 중, 완료됨, 실패함, 취소됨)를 확인 가능 |
| 사람의 피드백을 기다리고 있는 작업은 무엇인가요? | Custom Rules에 따른 승인 요청, 소유자에게 전송된 질문 및 결정 사항 | '사람의 답변 대기(Waiting for human reply)' 및 '사람의 검토 대기(Waiting for human review)' 항목이 담당자의 Inbox로 라우팅됨 |
| Claude Code와 Codex가 동일한 큐에서 작업을 가져올 수 있나요? | dot은 GPT-6 Astra 기반으로 실행되며 Codex에서 작업을 시작할 수 있음 | 연결된 Computer에서 Claude Code, Codex, Gemini, OpenCode 등 지원되는 모든 Runtime 활용 가능 |
| 에이전트가 접근할 수 있는 영역은 어디까지인가요? | Custom Rules, 자동 검토(auto-review), 읽기 전용 능동적 조사 | 에이전트 지침(Agent instructions), 연결된 저장소, 격리된 worktree, Computer 가시성 제어. Backlog에 Task를 할당해도 실행이 바로 시작되지 않음 |
| 결과물은 누가 최종 승인하나요? | 소유자가 중요 작업을 직접 검토 | Task 내에서 Agent 옆에 담당자가 함께 지정되며, 승인은 팀 전체가 볼 수 있는 상태 변경으로 기록됨 |
우측 열이 의미하는 것은 더 똑똑한 에이전트가 아닙니다. 바로 에이전트를 둘러싼 '기록 시스템'입니다. Sharkly는 Claude Code, Codex 또는 기타 실행 도구를 대체하는 것이 아니라, 팀이 이미 사용 중인 도구들 주위에 공유 Task, Computer, 컨텍스트, 제어, 검토 계층을 더해줍니다. 4가지 역할이 각자의 임무를 수행합니다. Agent는 작업 처리 방식을 정의하고, Computer는 호스트 환경을 제공하며, Runtime은 세션을 실행하고, Task는 공유 기록으로 남습니다. 진행 상황, 추적 이벤트, 최종 결과가 모두 Task로 다시 수집되므로, 4개의 개별 비공개 스레드를 뒤질 필요 없이 보드 하나에서 “어젯밤 무슨 일이 있었는가”에 대한 답을 얻을 수 있습니다.
어떤 벤더의 도구를 사용하든 이 원칙은 동일합니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 설정하고, 권한을 부여하며, 결과를 최종 승인합니다. 에이전트 작업에 대한 인간의 책임(Human ownership of agent work)에서는 왜 후자의 역할을 에이전트에게 넘길 수 없는지 설명하며, 에이전트 팀(agentic teams)에서는 여러 사람이 하나의 보드를 공유할 때 무엇이 달라지는지를 다룹니다.
dot이 더 적합한 경우와 보드가 필요한 경우
업무가 개인 한 명에게 속하고, 반복적이며, ChatGPT, Slack, Teams 및 플러그인으로 연결된 앱 내에서 이루어질 때는 dot을 사용하는 것이 좋습니다. 범위에 따라 유동적으로 바뀌는 런칭 계획, 새 데이터가 들어올 때마다 다시 실행하는 분석, 누군가 깜빡하고 보내지 않은 인보이스 처리 등이 대표적입니다. 이미 Pro나 Business Premium 요금제를 구독 중이고 에이전트 작업이 대부분 개인 업무라면, dot은 여기서 소개하는 그 어떤 방식보다 설정이 간편하며 보드가 전혀 필요 없을 수도 있습니다. 또한 dot은 어시스턴트와 팀원의 경계를 허뭅니다. 팀원처럼 사용자가 지켜보고 있지 않을 때도 업무를 수행하지만, 오직 한 사람에게만 보고하기 때문입니다.
반면 업무가 공유되는 환경이라면 보드를 사용해야 합니다. 여러 사람이 여러 에이전트에게 작업을 할당하고, 다양한 벤더의 Runtime을 사용하며, 요청서를 직접 작성하지 않은 리뷰어가 검토하고, 개별 대화 스레드보다 오래 보존되어야 하는 Task별 히스토리가 필요한 경우입니다. 이는 차세대 최고의 에이전트가 계속 등장하더라도 기존 워크플로우를 그대로 유지하고자 할 때 특히 결정적인 역할을 합니다. 오늘날에는 dot의 Astra, 서버의 Claude Code, 노트북의 Codex가 최적의 조합일 수 있습니다. 하지만 다음 분기에는 라인업이 또 달라질 수 있으며, 그때마다 팀의 협업 보드를 새로 구축할 수는 없습니다.
이 둘은 상호 보완적으로 함께 사용할 수 있습니다. dot이 생성한 풀 리퀘스트가 Sharkly와 연동된 GitHub 저장소에 올라오고, 그 제목이나 본문 또는 브랜치명에 Task ID가 포함되어 있다면 Sharkly의 GitHub 연동 기능이 이를 해당 Task와 자동으로 연결합니다. Slack에서 대화하는 dot은 서로를 대체할 필요 없이 자체 Slack 봇을 갖춘 Sharkly Agent와 나란히 공존할 수 있습니다. 또한 보드 자체에서 GPT-6 Astra를 활용하고 싶다면 다른 모든 모델과 마찬가지로 Computer 위의 Runtime을 통해 구동할 수 있습니다. Agent는 Runtime의 기본 모델을 따르기 때문입니다. 구체적인 설정 방법은 Sharkly에서 GPT-6 Astra 에이전트 실행하기에 안내되어 있습니다.
요청받지 않아도 스스로 행동하는 에이전트와 관련해 이번 DevDay에서 발표된 것이 dot뿐만은 아닙니다. DevDay 요약에 소개된 MCP Events와 팀 작업(team tasks) 역시 이벤트 기반 워크플로우에 동일한 개념을 적용한 사례입니다. 관련된 글인 프로젝트 보드를 모니터링하는 ChatGPT에서는 이벤트가 전달된 후 무엇을 생성해야 하는지에 대해 다룹니다.
모든 AI 기업은 자사의 에이전트만을 관리하길 바랍니다. Sharkly는 여러분 자신의 에이전트들을 관리할 수 있게 해줍니다. 특정 생태계 하나에 얽매이지 않고 다양한 코딩 에이전트를 계속해서 병용하고자 한다면, 바로 그것이 Sharkly가 해결하기 위해 만들어진 문제입니다.
