1. Doc가 아니다. Dot이다. 그리고 채팅 상대보다 ‘담당자’에 가깝다
이름부터 헷갈리기 쉽다. Doc가 아니라 Dot이다.
일반적인 ChatGPT는 질문을 받고, 생각하고, 답한 뒤 한 번 끝난다. Dot은 조금 다르다. OpenAI는 Dots를 GPT-6 Astra 기반의 always-on agent로 설명한다. 자체 클라우드 컴퓨터와 브라우저를 갖고, 연결된 앱을 사용하며, 지속적인 목표를 향해 계속 일할 수 있다.
즉 “질문에 답하는 AI”보다 “이 일을 맡고 있는 담당자”에 가깝다.
AI가 드디어 채팅창에서 담당표로 인사이동했다.
2. ‘24시간 가동’은 무한 반복문이 아니라 책임이 대화를 넘어 남는다는 뜻이다
여기서 오해하면 안 된다. 24시간 가동이라고 해서 CPU를 1초도 쉬지 않고 돌리는 무료 VPS라는 뜻은 아니다.
핵심은 연속성이다. Dot은 대화가 끝난 뒤에도 맡은 책임을 유지하고, 백그라운드 조사, 정기 확인, 연결된 정보원 점검, 예약된 작업을 이어갈 수 있다. OpenAI는 이런 배경 정보 탐색을 proactive research라고 부른다.
기존에는 사람이 일을 기억하고, AI를 다시 열고, 지난 맥락을 복원한 뒤 다시 지시해야 했다. Dot에서는 ‘담당자가 계속 그 일을 들고 있는’ 상태가 된다.
사람의 시간이 실제 작업보다 “지난번 어디까지 했지?”에서 녹는다는 점을 생각하면 꽤 큰 변화다.
3. 시작은 데스크톱, 그다음에는 모바일로 데려올 수 있다
첫 Dot은 ChatGPT 데스크톱 앱이나 PC 웹에서 만든다. 이름을 정하고, 목표를 주고, 필요한 앱을 연결하고, 무엇을 스스로 해도 되는지 정한다.
설정이 끝나면 모바일 앱에서 대화할 수 있다. 출생신고는 PC에서 하고, 그다음에는 휴대폰에 데리고 다니는 셈이다.
프로필에서는 진행 중, 예약됨, 완료됨 작업을 확인할 수 있고, 예약 작업의 빈도와 알림도 관리할 수 있다. 개인 PC 접근은 선택 사항이며, 기본적으로 Dot 자체의 별도 클라우드 컴퓨터가 있다.
따라서 집 PC를 밤새 켜둘 필요는 없다.
4. 사용량 조건은 매우 좋지만 ‘영구 완전 무제한’이라고 공식 발표한 것은 아니다
출시 시점에는 첫 Dot이 대상 Pro 및 Business Premium 플랜에 추가 비용 없이 포함된다. Enterprise 계열은 관리자가 켜는 베타다.
OpenAI는 Dot과의 대화가 일반 ChatGPT 사용 한도에 포함되지 않는다고 설명한다. 더 깊은 작업에는 별도 allowance가 있고, 출시 후 첫 한 달은 한도가 확대된다. 릴리스 노트에서는 첫 한 달 동안 대상 사용자의 Dots 사용량이 플랜 사용 한도에 계산되지 않는다고도 안내한다.
초기 사용자들 사이에서는 무거운 창작 작업을 밤새 돌렸는데 일반 사용량 표시가 거의 줄지 않았다는 경험담도 나온다. 출시 조건과는 맞아떨어지지만, 이것이 영구적인 무한 무료 컴퓨팅을 뜻하지는 않는다.
또 Dot이 Codex나 ChatGPT Work 작업을 만들거나 관리하면, 그 작업은 해당 서비스의 일반 사용량을 그대로 소비한다.
무한 뷔페는 아니다. 다만 전채가 지나치게 푸짐하다.
5. 가장 강력한 용도는 ‘정기 실행 작업의 보조원’일 수 있다
Scheduled Tasks는 일을 정시에 시작하는 데 강하다. 하지만 현실의 자동화는 시작보다 끝내기가 어렵다.
API가 잠깐 실패한다. 권한이 부족하다. 한 단계만 시간 초과된다. 일부 작업만 실패한다. 로그가 남고, blocker도 분류되고, 다음 행동도 기록된다.
그리고 아무도 그 다음 행동을 하지 않는다.
자동화의 고전이다.
여기에 Dot을 놓으면 역할이 깔끔해진다.
Scheduled Task는 정시에 작업을 시작한다. Dot은 결과가 끝날 때까지 책임진다.
PARTIAL, BLOCKED, HOLD, FAILED가 나오면 현재 상태를 다시 읽고, 마지막으로 확정된 지점에서 재개한다. 독립적으로 안전하게 할 수 있는 다른 작업은 계속한다. 원인이 코드라면 고치고, 필요할 때만 전문 코딩 에이전트에 넘긴 뒤 그 결과도 회수한다.
‘실패를 알리는 시스템’이 ‘실패한 일을 계속 들고 있는 담당자’로 바뀐다.
6. Dot·Scheduled Task·Codex는 현장감독·시계·수리팀으로 나누면 이해하기 쉽다
세 층으로 생각하면 간단하다.
Scheduled Task는 시계다. 정해진 시간이나 조건에서 작업을 시작한다.
Dot은 현장감독이다. 여러 run을 가로질러 상태를 유지하고, 미완료 작업을 찾고, 우선순위를 정하고, 단순 재시도보다 원인 수리로 나아가며, 최종 조건까지 추적한다.
Codex는 수리팀이다. 실제 코드 변경, 테스트, 리팩터링, 복잡한 구현이 필요할 때 부른다.
중요한 점은 “Codex 작업을 만들었다”가 완료가 아니라는 것이다.
Codex 시작 → 수정 → diff 확인 → 테스트 → 반영 → 재실행 → 실제 결과 확인.
여기까지 닫혀야 끝이다.
정비사를 불렀다고 공장장이 퇴근하면 안 된다.
7. 실패 대응은 보고서가 아니라 닫힌 루프여야 한다
상시 보조원에게 줄 지시에서 가장 중요한 것은 종료 조건이다.
나쁜 지시는 “실패하면 알려줘”다. 그러면 비싼 감시카메라가 된다.
좋은 지시는 “실패하면 현재 상태를 확인하고, 원인을 특정하고, 가장 작은 안전한 수리를 하고, 다시 검증하고, 미완료가 남아 있으면 계속한다. 코드 수정이 필요하면 코딩 에이전트에 위임하고 결과를 회수해 재검증한다. 지금 끝낼 수 없다면 정확한 체크포인트와 다음 행동을 저장해 다음 run에서 이어간다”다.
같은 실패가 반복되면 원래 Scheduled Task의 지시, 종료 조건, 참조 정보, 가정, 완료 판정도 고친다.
“원인 분류 완료”는 현장에서 “불의 종류를 알아냈습니다”와 같다.
좋다. 이제 꺼라.
8. 그렇다고 Dot에게 왕국의 전권을 줄 필요는 없다
Dots에는 권한 설정과 Custom Rules가 있다. 어떤 행동을 자동으로 할지, 사전승인이 필요한지, 매번 물어볼지, 인간에게 넘길지를 정할 수 있다.
또 proactive research는 일부러 제한되어 있다. 허용된 연결 정보를 읽고 비공개 메모를 만들 수는 있지만, 그 연구 도구가 직접 메시지를 보내거나 플러그인 내용을 바꾸거나 브라우저와 컴퓨터를 조작할 수는 없다. 실제 변경은 일반 권한·승인·안전 확인을 거친다.
이는 단점만이 아니다. 24시간 일하는 직원에게 24시간 운영 환경을 망가뜨릴 권한까지 줄 필요는 없다.
관측은 넓게, 중요한 변경 권한은 좁게 두는 편이 합리적이다.
9. 실제로 써보면 ‘센스 있다’는 말의 정체는 묻기 전에 답이 놓여 있는 것이다
Dot을 실제로 쓰기 시작하면 Scheduled Tasks 보조원 외에도 잘 맞는 역할이 보인다. 예전에는 사람이 기억해서 매번 물어보던 반복 확인을 먼저 해두는 일이다.
예를 들어 접근 수를 계속 확인하고, 상승하기 시작한 글의 추이를 그래프로 만들 수 있다. 거기서 끝나지 않고 “무슨 글이 올랐나”가 아니라 “오르는 글에는 어떤 공통점이 있나”까지 정리할 수 있다. 주제, 유입 경로, 언어, 공개 후 움직임, 내부 이동 같은 관찰 가능한 특징을 계속 분석하는 것이다.
운영 보수도 마찬가지다. Cloudflare나 GitHub 쪽에서 처리가 멈췄다면 상태를 확인하고, 원인을 좁히고, 허용된 범위에서 안전하게 고칠 수 있으면 수정한 뒤 완료까지 추적할 수 있다. 사람이 매번 “지금 어디서 막혔지?”, “접근 수는 어때?”, “어떤 글이 뜨고 있어?”라고 묻지 않아도 Dot을 열었을 때 조사나 수리가 이미 진행되어 있고 답이 놓여 있는 상태를 만들 수 있다.
이게 은근히 가장 강하다.
실제로는 접근 수를 보는 데서 끝나지도 않았다. Cloudflare 빌드를 진행하고, GitHub 상태를 관찰하고, 필요한 수정까지 처리했다. 즉 이상을 발견해서 보고만 하는 감시 역할이 아니라, 허용된 범위라면 직접 현장에 내려가 손을 움직인다.
여기까지 오면 그냥 “센스 있네”라는 말이 딱 맞다. 매번 세세하게 다시 지시하지 않아도 보고, 고치고, 확인하고, 다음으로 간다. ‘편리한 도구’가 아니라 ‘업무를 맡은 담당자’처럼 느껴지는 지점이다.
매번 AI에게 답을 가지러 가는 게 아니라, 담당자의 책상을 보러 갔더니 그래프와 원인 분석과 수리 결과가 이미 놓여 있는 것이다.
‘센스 있는 AI’라는 말은 추상적이지만 실무에서는 꽤 구체적이다. 내가 매번 기억해서 묻던 질문을 먼저 주워서 처리해준다.
결국 생산성의 핵심은 답변 속도보다 사람이 “이거 확인해야지”를 계속 기억해야 하는 부담을 줄이는 데 있을지도 모른다.
게다가 실제로는 관측만 하는 데서 끝나지 않았다. Cloudflare의 빌드 상태를 따라가고, GitHub 쪽 상태를 확인하고, 허용된 범위에서는 필요한 수정까지 진행했다. 즉 “문제를 찾았습니다”에서 멈추지 않고 “찾아서 처리했습니다”에 가까워진다.
여기까지 오면 “센스 있을 것 같다”가 아니라 “그냥 센스 있다”가 된다. 사람이 매번 대시보드와 저장소와 빌드 상태를 돌며 막힌 곳을 찾던 일이 담당자의 정기 업무로 넘어간다.
그러다 보면 AI에게 일을 시키는 감각보다, 이미 시스템을 보고 있던 담당자에게 결과를 확인하러 가는 감각에 가까워진다.
10. 결론: 마법은 ‘항상 켜져 있음’보다 ‘계속 책임지고 있음’에 있다
Dots의 핵심은 똑똑한 채팅창 하나가 더 생긴 것이 아니다.
사람이 자리를 비워도 작업의 맥락이 남고, 정기 작업과 연결 앱을 넘나들며, 이전 실패 지점에서 다시 이어갈 수 있다는 점이다.
따라서 단순한 대화 상대보다, 자주 실패하는 정기 처리의 상시 보조원, 미완료를 줍는 감독, 필요할 때만 코딩 전문가를 부르는 운영자로 쓰면 훨씬 강하다.
AI판 구두장이의 요정이다.
단, 아침에 신발이 만들어져 있다고 끝내지 말자. 발에 맞는지도 확인해야 한다.
보고가 아니라 완수다.
