OpenAI Dots란? AI 에이전트 기능·이용 조건·업무 활용 가이드
AI 에이전트·판단 모델 시리즈 · Dots 편 | 확인 기준: 2026년 10월 6일
OpenAI Dots는 어떤 서비스인가?
Dots는 자기 클라우드 컴퓨터에서 목표를 향해 작업을 이어가는 OpenAI의 AI 에이전트 서비스입니다. dot은 개별 에이전트를 가리킵니다. 질문에 대한 한 번의 답변보다, 연결된 앱의 맥락을 참고하고 여러 단계의 프로젝트를 수행하는 데 초점을 둡니다. 이용 요금제·지역·계정별 순차 배포 조건은 따로 확인해야 합니다.
업무를 맡길 때마다 배경을 처음부터 설명하고 결과를 다른 도구로 옮기는 일이 번거로웠다면, Dots에서 주목할 부분은 작업의 연속성입니다. 이 글은 OpenAI 공식 발표와 도움말을 바탕으로 정리했습니다. 직접 측정한 성능 비교나 무인 운영 성공 사례를 제시하는 글은 아닙니다.
1. 새 모델 이름일까, 새 작업 방식일까?
Dots는 단일 모델의 별칭이 아닙니다. OpenAI는 2026년 9월 29일 출시 발표에서 GPT-6 Astra를 기반으로, 클라우드 컴퓨터·브라우저·연결 앱을 이용하는 상시 에이전트라고 소개했습니다. 사용자는 대화로 목표를 주고 진행 중에도 방향을 바꿀 수 있습니다. OpenAI Dots 공식 발표
가령 고객 의견을 조사하는 작업은 자료 읽기, 반복되는 요구 찾기, 개선안 작성, 결과 검토로 이어집니다. Dots가 제공하려는 경험은 이런 일을 매번 별도 대화로 나누지 않고 이어가는 것입니다. 실제로 가능한 작업은 연결한 도구와 허용한 권한에 달려 있습니다.
2. 누가 이용할 수 있나?
| 요금제·대상 | 공식 도움말의 안내 |
|---|---|
| Pro | EEA·스위스·영국을 제외한 지역에 순차 제공 |
| Business Premium | ChatGPT 지원 지역에서 제공 |
| Enterprise·Edu·Healthcare | 관리자가 베타를 활성화해야 사용 가능 |
| 18세 미만 | 현재 제공되지 않음 |
첫 dot은 Pro 또는 Business Premium 요금제에 추가 비용 없이 포함된다고 안내합니다. 그러나 대화를 할 수 있는 것과 모든 작업을 무제한 실행하는 것은 다릅니다. 깊이 있는 작업에는 별도 사용량 범위가 있습니다. Plus나 일반 Business를 위 요금제와 같은 것으로 읽으면 안 됩니다. 계정에 메뉴가 보이지 않으면 요금제, 지역, 조직 설정, 순차 배포 여부를 확인하세요. 시작하기 도움말, 연령·안전 안내
3. 처음 시작할 때의 순서
- 데스크톱에서 생성: ChatGPT 데스크톱 앱이나 데스크톱 웹의 안내를 따라 dot을 만듭니다. 도움말 기준 모바일에서 새 dot을 만드는 기능은 지원되지 않습니다.
- 필요한 앱만 연결: 첫 과제에 필요한 정보와 권한을 확인한 뒤 연결합니다.
- 결과와 승인 범위 지정: 원하는 산출물, 마감, 사용할 자료, 외부 발송 여부를 함께 설명합니다.
- 활동 확인: 진행 중·예약·완료 상태와 결과물을 확인하고 수정 기준을 알려줍니다.
위 순서는 공식 시작하기 문서를 바탕으로 정리했습니다. 계정 화면이나 제공 기능은 변경될 수 있습니다. 설정 및 활동 확인 방법
4. 업무를 맡기는 요청은 이렇게 구체화하자
다음은 편집부가 구성한 예시입니다. 실제로 실행한 결과나 성공 보장은 아닙니다.
“매주 월요일 오전 9시에 지난주 공개된 우리 업계의 공식 발표를 조사해줘. 중요한 변화 5개를 원문 링크·발표일·우리 업무에 미치는 영향으로 정리해줘. 근거가 불분명한 내용은 따로 표시하고, 외부에 보내지 말고 검토용 문서로 남겨줘.”
| 요청에 넣을 항목 | 빠졌을 때 생기는 문제 |
|---|---|
| 기간·출처 범위 | 오래된 정보나 원문 없는 요약이 섞임 |
| 완료 기준 | 조사 시도만으로 일이 끝났다고 오해 |
| 발송·게시 권한 | 초안 작성과 실제 외부 전달의 경계가 모호해짐 |
| 예외 처리 | 자료가 없거나 접근이 막혔을 때 같은 시도를 반복 |
이런 조건은 특정 에이전트에만 통하는 비법이 아니라, 위임할 일을 검증 가능한 단위로 만드는 작업 명세입니다. 첫 주에는 원문 5개를 직접 대조하고, 누락이나 날짜 오류가 얼마나 있었는지 기록하면 도입 효과를 판단하기 쉽습니다.
5. 백그라운드 조사와 실행 권한을 구분하자
Dots의 proactive research는 허용된 연결 자료를 읽고 유용한 변화를 찾는 활동입니다. 공식 FAQ는 이 조사 도구가 직접 다른 사람에게 메시지를 보내거나, 앱 내용을 변경하거나, 브라우저·컴퓨터를 제어하지 못한다고 설명합니다. 후속 행동은 일반 작업의 승인·안전 규칙을 따라야 합니다. 권한과 선제적 조사 안내
이를 ‘백그라운드에서는 어떤 작업도 할 수 없다’로 확대 해석할 필요도 없습니다. 사용자가 이미 맡긴 작업의 지속 실행과, 요청 전 유용한 정보를 찾는 조사 활동은 구분해야 합니다. 중요한 결과물은 실제 산출물과 변경 기록으로 확인하세요.
6. 내 컴퓨터와 기억은 어떻게 다루나?
기본 환경은 dot의 클라우드 컴퓨터입니다. 자신의 컴퓨터 접근은 선택 사항이며 처음에는 꺼져 있습니다. 로컬 파일이나 프로그램이 필요한 작업을 위해 연결할 때에는 접근 범위와 연결 해제 방법을 확인해야 합니다. 클라우드에서 일할 수 있다는 설명이 전원이 꺼진 로컬 PC까지 사용할 수 있다는 뜻은 아닙니다. 로컬 컴퓨터 연결 안내
개인정보 측면에서는 연결 해제와 기억 삭제를 구분하세요. 공식 FAQ에 따르면 플러그인 연결을 끊어도 이미 dot의 맥락에 들어온 정보가 자동으로 지워지는 것은 아닙니다. 현재는 개별 dot 기억을 직접 열람·수정·삭제하는 기능에 제한이 있고, dot의 맥락을 지우는 것과 별도 저장된 파일·ChatGPT 기억을 관리하는 것도 다릅니다. 기억·데이터 보관 FAQ
도식으로 보는 클라우드 작업과 내 컴퓨터의 경계
Dots를 이해할 때 먼저 나눌 것은 작업이 실행되는 곳과 자료가 있는 곳입니다. 클라우드에서 동작하는 에이전트라고 해서 꺼진 개인 컴퓨터의 모든 파일을 읽을 수 있는 것은 아닙니다. 반대로 클라우드에서 접근 가능한 자료만으로 끝나는 과제라면 개인 컴퓨터의 로컬 작업과는 다른 조건으로 생각할 수 있습니다.
기본 실행 환경과 로컬 접근은 별개입니다. 실제 작업의 의존성을 확인하는 개념도입니다.
도식은 연결 구조를 설명한 개념도입니다. 실제로 특정 작업이 기기를 꺼도 끝나는지 판단하려면 입력 파일, 실행 프로그램, 결과 저장 위치를 각각 확인해야 합니다. “매주 보고서를 작성하라”는 요청에 노트북 안의 파일이 필요하다면 그 의존성을 없애거나, 승인된 연결 환경에서 접근 가능한 자료로 바꾸어야 합니다. 클라우드 제품이라는 이유만으로 모든 작업의 상시 실행을 보장할 수는 없습니다.
실전 설계: 매주 읽을 만한 업계 변화 보고서 만들기
다음은 직접 실행한 제품 평가가 아닌 편집부의 업무 설계 예시입니다. 작은 팀이 매주 공식 발표를 확인해 서비스 기획에 참고한다고 가정하겠습니다. 검색 결과를 많이 모으는 것보다 “지난 보고서 이후 실제로 무엇이 바뀌었는가”에 답하는 것이 목표입니다.
매주 월요일 오전 9시, 한국 시간 기준으로 직전 월요일 00:00부터 일요일 23:59까지의 변화를 정리해줘. 내가 지정한 회사의 공식 발표·제품 도움말을 우선해줘. 발표일과 실제 적용일을 구분하고, 이전 보고서와 같은 내용이면 새 소식처럼 넣지 말아줘. 중요한 변화는 최대 5개로 정리하되 부족하면 개수를 채우지 마. 각 항목에 원문, 확인일, 우리 업무에 미치는 영향, 추가 확인 사항을 써줘. 접근 실패한 출처는 별도 목록에 남기고, 결과는 검토용 문서로만 작성해줘.
이 예시는 제품의 숨겨진 명령어가 아닙니다. 어떤 에이전트에게 일을 맡기더라도 필요한 명세입니다. 날짜가 없으면 오래된 발표가 섞이고, “최대 5개” 대신 “반드시 5개”라고 하면 가치가 낮은 항목으로 분량을 채우기 쉽습니다. 출처가 비어 있을 때도 문서가 만들어질 수 있으므로, 자료 확보 여부와 작성 완료 여부를 분리해야 합니다.
| 보고서 칸 | 좋은 결과의 조건 | 피해야 할 결과 |
|---|---|---|
| 무엇이 바뀌었나 | 이전 조건과 새 조건을 구체적으로 비교 | “혁신적인 기능 출시” 같은 평가만 적음 |
| 누가 쓸 수 있나 | 요금제·지역·관리자 설정을 구분 | 일부 계정의 기능을 모두 제공한다고 단정 |
| 언제 적용되나 | 발표일과 순차 배포·정식 적용일을 구분 | 발표 즉시 누구나 쓸 수 있다고 표현 |
| 왜 우리에게 중요한가 | 실제 업무 하나와 연결해 영향 설명 | 근거 없이 생산성·매출 향상을 수치로 약속 |
| 무엇이 불확실한가 | 접근 실패·미공개 조건·검증 안 된 부분 표시 | 정보 없음과 변화 없음을 같은 뜻으로 처리 |
예를 들어 어떤 서비스가 새 연결 기능을 발표했다면 “연결 기능이 생겼다”는 한 문장보다 우리 요금제에서 쓸 수 있는지, 읽기만 가능한지 쓰기도 가능한지, 관리자 설정이 필요한지를 확인하는 편이 유용합니다. 문서에서 확인되지 않는 조건은 추정으로 채우지 않고 담당자가 직접 볼 질문으로 남기면 됩니다.
완료·승인 대기·실패를 나누는 작업 흐름
자료 접근 실패 → 누락 명시 후 재조사. 승인 대기 → 승인 후 필요한 단계만 재개. 외부 실행 결과가 모호하면 중복 여부부터 확인합니다.
여기서 “재개”는 같은 작업을 무조건 처음부터 반복한다는 뜻이 아닙니다. 조사까지 끝났다면 조사 결과를 보존하고, 권한 때문에 저장을 못 했으면 저장 단계부터 확인합니다. 이미 외부에 게시했을 가능성이 있다면 해당 서비스의 실제 결과를 먼저 조회해야 합니다. 이처럼 상태를 구분하는 운영 설계는 Dots가 자동으로 모든 경우를 해결한다는 보장이 아니라, 사용자가 결과를 확인할 때의 기준입니다.
검색 결과가 없을 때 보고서에 남길 문장
“이번 주 변화가 없습니다”와 “공식 사이트 두 곳에 접근하지 못해 변화를 확인하지 못했습니다”는 전혀 다른 결과입니다. 첫 문장은 조사 범위 안에서 확인을 마쳤다는 의미이고, 두 번째는 조사 자체가 불완전하다는 의미입니다. 업무를 맡길 때 이 둘을 분리해 달라고 요청하면 그럴듯하지만 근거가 빈 보고서를 알아차리기 쉽습니다.
마찬가지로 “파일을 만들었습니다”는 결과물의 존재를 말할 뿐 내용의 정확성을 증명하지 않습니다. 실제 파일 링크가 열리는지, 중요한 항목마다 근거가 있는지, 이전 주 내용이 중복되지 않았는지를 확인해야 합니다. 점검 기준을 처음 요청에 넣으면 다음 회차에도 일관되게 비교할 수 있습니다.
기존 예약 자동화와 Dots 중 무엇을 선택할까?
| 업무 성격 | 편집부의 선택 기준 | 예시 |
|---|---|---|
| 조건과 출력이 항상 같음 | 규칙 기반 자동화부터 검토 | 정해진 필드를 다른 표로 복사 |
| 자료의 의미를 읽고 비교해야 함 | 에이전트 활용을 소규모 검증 | 새 발표와 기존 기능의 차이 설명 |
| 해석과 정확한 실행이 함께 필요 | 에이전트의 초안·판단과 검증된 실행 절차를 조합 | 업데이트 요약을 검토 후 지정 채널에 게시 |
이 표는 Dots의 성능 우열을 측정한 결과가 아닙니다. 반복 일정이 있다는 이유만으로 모든 일을 에이전트로 바꿀 필요는 없습니다. 자료 해석이 없는 단순 이동은 규칙이 명확한 방식으로 유지하고, 사람이 읽고 요약하느라 오래 걸리는 부분부터 에이전트를 적용하면 실패 원인도 좁히기 쉽습니다.
도입 효과는 “생성 시간 + 검토 시간 + 복구 시간”으로 계산
가령 보고서를 직접 만드는 데 60분이 들었고, 에이전트가 만든 뒤 확인에 20분·오류 수정에 15분이 들었다면 사람의 부담은 35분입니다. 이 수치는 계산 방법을 설명하는 가정으로 Dots의 실제 측정값이 아닙니다. 오류가 난 주의 복구 시간도 합쳐야 장기적인 가치를 판단할 수 있습니다.
평가표에는 원문이 없는 주장 수, 중복 항목 수, 누락된 중요한 변화, 결과물을 실제 업무에 쓴 여부를 기록해 보세요. 보고서가 길어졌다는 사실보다 읽은 사람이 의사결정을 할 수 있었는지가 더 중요합니다. 처음부터 다수의 업무를 연결하면 어느 조건이 품질에 영향을 주었는지 찾기 어려워집니다.
권한과 기록을 점검하는 세 가지 질문
첫째, 지금 연결한 계정으로 무엇을 읽을 수 있나? 허용된 자료 범위를 확인하고, 시험에 필요 없는 자료는 연결하지 않는 편이 좋습니다. 보고서 하나를 위해 조직 전체 자료가 필요한 것은 아닙니다.
둘째, 어떤 행동까지 맡겼나? 공개 자료 조사, 내부 문서 초안 작성, 외부 발송은 영향이 다릅니다. 공식 개인정보·안전 FAQ의 proactive research와 실제 실행 권한 구분을 바탕으로 작업 범위를 확인하세요. “알아서 해줘” 대신 저장 위치와 승인 지점을 적는 것이 도움이 됩니다.
셋째, 중단하거나 연결을 끊으면 무엇이 남나? 앞으로의 접근을 멈추는 일과 이미 만들어진 문서·대화 맥락을 정리하는 일은 다릅니다. 도입 전에 결과 저장 위치, 작업 중단 방법, 자료 정리 책임자를 정해두면 시험이 끝난 뒤에도 불필요한 데이터가 남는 문제를 줄일 수 있습니다.
도입 판단: 어떤 일부터 맡기면 좋을까?
편집부의 제안은 반복되면서 결과를 확인하기 쉬운 작업 하나부터 시작하는 것입니다. 주간 자료 정리나 검토용 문서 작성처럼 오류를 발견하고 고치기 쉬운 일을 고르세요. 단순히 생성된 문서 수보다, 사람이 다시 확인한 시간과 잘못된 내용을 수정한 횟수까지 합쳐 기존 방식과 비교하는 편이 현실적입니다.
OpenAI는 Dots에도 오류가 남을 수 있다고 명시합니다. 서비스의 가치는 ‘아무 확인 없이 맡겨도 된다’가 아니라, 확인 가능한 산출물을 꾸준히 가져와 사용자의 시간을 줄일 수 있는지에 달려 있습니다.
표지는 AI로 제작한 개념 일러스트이며 실제 Dots 화면이 아닙니다. 제공 조건은 확인 시점의 공식 문서를 기준으로 합니다.
[…] OpenAI Dots · TypeSafe Jev […]