OpenAI dots로 본 '상시 실행 에이전트'의 운영 설계 — 권한·승인·감사·비용

OpenAI가 9월 29일 DevDay 2026에서 dots를 공개했습니다. 사용자가 로그아웃해도 자기 클라우드 컴퓨터에서 계속 일하고, Slack·Teams로 일을 받고, 필요하면 먼저 다음 할 일을 제안하는 에이전트입니다.

기능 자체보다 중요한 것은 dots가 보여 주는 운영 모델의 변화입니다. 지금까지 기업이 다룬 AI는 대부분 "사람이 묻고, 답을 받고, 세션이 끝나는" 구조였습니다. 상시 실행 에이전트는 세션이 끝나도 상태가 남고, 사람이 보지 않는 시간에도 행동합니다. 이 차이 때문에 권한·승인·감사·비용을 처음부터 다시 설계해야 합니다.

이 글은 dots를 사례로 삼아 다음을 정리합니다.

1. dots가 무엇이고 무엇이 "상시 실행"을 가능하게 하는지
2. 상시 실행 에이전트에 필요한 네 가지 설계 축 — 권한, 승인과 멱등성, 기억과 데이터 거버넌스, 감사와 비용
3. dots를 쓸지 직접 만들지 판단하는 기준과 도입 체크리스트

이 글은 2026년 10월 4일 기준 공개 보도와 발표를 바탕으로 한 분석입니다. dots는 단계적으로 출시되는 중이라 기능·요금·지역 정책이 바뀔 수 있으니, 도입 전에는 OpenAI 공식 발표와 지원 문서를 확인하세요.

1. dots란 무엇인가

AI 업무 도구는 세 단계로 진화해 왔습니다.

dots는 3단계에 해당합니다. 보도된 내용을 정리하면 다음과 같습니다.

OpenAI가 소개한 사용 예시는 Slack에 언급된 버그를 조사하기, 설계 문서로 앱 만들기, 청구서를 만들어 승인 요청하기, 예산 편성 준비, 지원 종료되는 API에서 애플리케이션 옮기기 같은 것들입니다. 공통점은 며칠에 걸쳐 이어지고, 여러 시스템을 오가며, 중간에 사람의 판단이 필요한 일이라는 점입니다.

2. 구조: 무엇이 '상시 실행'을 가능하게 하나

발표 내용을 기준으로 dots의 동작을 그리면 다음과 같습니다.

기존 대화형 에이전트와 구조적으로 다른 점은 세 가지입니다.

① 세션과 실행이 분리됩니다. 사용자가 창을 닫아도 dot은 자기 컴퓨터에서 일합니다. 그래서 "지금 누가 지켜보고 있는가"를 전제로 한 통제가 통하지 않습니다.

② 에이전트가 일을 먼저 시작합니다. 선제 조사는 사용자가 묻지 않은 일을 에이전트가 발견하는 기능입니다. OpenAI가 이 단계를 읽기 전용으로 묶은 이유는 분명합니다. 스스로 일을 찾는 에이전트가 쓰기 권한까지 가지면 사고 범위를 예측할 수 없기 때문입니다.

③ 상태가 쌓입니다. 기억, 진행 중인 작업, 승인 대기 중인 행동이 계속 남습니다. 이 상태는 곧 관리해야 할 데이터이고, 장애나 재시작 이후에도 일관성을 지켜야 하는 대상입니다.

이 세 가지가 아래 네 가지 설계 축으로 이어집니다. dots를 쓰든 직접 만들든 똑같이 적용됩니다.

3. 설계 축 ①: 권한 — 사람 계정을 빌려 주지 않는다

상시 실행 에이전트를 도입할 때 가장 흔한 실수는 에이전트에게 사람의 계정과 권한을 그대로 넘기는 것입니다. 대화형 AI는 사람이 옆에서 지켜보니 큰 문제가 아니었지만, 상시 실행 에이전트는 사람이 없는 시간에 그 권한으로 행동합니다.

원칙은 네 가지입니다.

1. 전용 신원: 에이전트마다 별도의 서비스 계정을 둡니다. 감사 로그에 "김OO가 했다"가 아니라 "김OO의 에이전트가 했다"가 남아야 합니다.
2. 읽기와 쓰기 분리: dots가 선제 조사를 읽기 전용으로 묶은 것처럼, 조사·모니터링 권한과 변경·발송 권한을 별도로 부여합니다.
3. 최소 권한과 범위 제한: 메일 전체가 아니라 특정 라벨, 저장소 전체가 아니라 특정 경로처럼 범위를 좁힙니다.
4. 만료되는 자격증명: 장기 토큰 대신 짧은 수명의 토큰을 쓰고, 에이전트를 비활성화하면 즉시 회수되게 합니다.

dots의 4단계 행동 규칙은 사실상 행동별 권한 정책입니다. 직접 만든다면 다음처럼 선언적으로 관리하는 편이 좋습니다.

# agent-policy.yaml — 행동 유형별 실행 정책 (예시)
agent: finance-assistant
identity: svc-agent-finance-01        # 사람 계정이 아닌 전용 서비스 계정
credentials:
  ttl: 1h                             # 짧은 수명 토큰
actions:
  read.mail:          { mode: auto,     scope: "label:invoices" }
  read.erp.invoice:   { mode: auto }
  draft.invoice:      { mode: auto }
  send.invoice:       { mode: ask,      approvers: ["finance-lead"] }
  send.external_mail: { mode: ask }
  share.file.external: { mode: deny }    # 사람만 가능
  change.credentials: { mode: deny }
limits:
  max_actions_per_hour: 60
  max_cost_per_day_usd: 20

4. 설계 축 ②: 승인과 멱등성 — "기다리는 동안"을 설계한다

OpenAI가 든 예시 중 하나가 청구서입니다. 에이전트가 청구서를 만들고, 발송 전에 사람의 승인을 받습니다. 간단해 보이지만 상시 실행 환경에서는 승인 사이의 시간이 문제입니다.

이 흐름에서 지켜야 할 것은 세 가지입니다.

승인 대상을 고정합니다. 승인 요청 후 에이전트가 초안을 고치면, 승인자가 본 것과 실제로 나가는 것이 달라집니다. 승인은 특정 버전에 대해 이뤄져야 하고, 내용이 바뀌면 다시 승인을 받아야 합니다.

실행은 멱등하게 합니다. 상시 실행 에이전트는 재시작·타임아웃·재시도를 반드시 겪습니다. 발송·결제·티켓 생성 같은 외부 행동에는 행동마다 고유 ID를 붙여, 같은 행동이 두 번 실행되지 않게 해야 합니다.

def execute_approved(action_id: str) -> None:
    action = store.get(action_id)
    if action.status == "done":
        return                                  # 이미 실행됨 — 재시도해도 안전
    if action.approved_version != action.current_version:
        raise NeedsReapproval(action_id)        # 승인 후 내용이 바뀜
    erp.send_invoice(action.payload, idempotency_key=action_id)
    store.mark_done(action_id)

무엇을 "먼저 묻기"로 시작할지 정합니다. 처음부터 많은 행동을 자동으로 열어 두기보다, 다음 유형은 승인으로 시작하고 운영 데이터가 쌓이면 단계적으로 완화하는 편이 안전합니다.

5. 설계 축 ③: 기억과 데이터 거버넌스

dots는 대화가 바뀌어도 선호와 진행 중인 일을 기억하고, 사용자의 교정에서 배웁니다. 사용성 측면에서는 핵심 기능이지만, 거버넌스 측면에서는 개인정보와 업무 기밀이 계속 쌓이는 저장소가 하나 생긴다는 뜻입니다.

검토해야 할 질문은 다음과 같습니다.

• 무엇이 기억되는가: 고객 이름, 계약 금액, 내부 사정이 기억에 들어갈 수 있습니다. 기억을 사람이 열람·수정·삭제할 수 있어야 합니다.
• 얼마나 보존하는가: 기억에도 보존 기간과 삭제 정책이 필요합니다. 퇴사·업무 이동 때 에이전트의 기억을 어떻게 처리할지도 정해야 합니다.
• 어디까지 읽는가: 선제 조사는 읽기 전용이지만, 읽은 내용은 모델 컨텍스트와 기억으로 흘러 들어갑니다. 연결된 앱의 데이터는 RAG 색인과 같은 수준의 데이터 분류로 다뤄야 합니다. 민감 데이터는 에이전트가 읽기 전에 마스킹·토큰화하는 방안을 검토합니다.

그리고 메일과 문서를 읽는 에이전트는 그 자체로 공격 표면입니다. 외부에서 보낸 메일에 숨긴 지시가 에이전트의 행동을 바꾸는 간접 프롬프트 인젝션이 대표적입니다. 9월 말 OpenAI는 악성 지시가 에이전트의 출력을 타고 다음 작업으로 번지는 "자기복제 프롬프트 인젝션"을 내부 평가에서 확인했다고 공개했습니다(AI·IT 브리핑 제1호 참고). 상시 실행 에이전트에서는 다음이 필요합니다.

• 외부에서 들어온 콘텐츠(메일·웹·첨부)를 지시가 아닌 데이터로 취급하는 경계
• 에이전트가 만든 메모·기억·후속 작업도 다시 쓰기 전에 검사
• 외부 콘텐츠를 읽은 직후의 쓰기 행동은 승인 단계로 올리기

프롬프트 인젝션 방어 전반은 LLM 보안: 프롬프트 인젝션과 에이전트 보안에서, 기억과 컨텍스트 관리는 에이전트 메모리와 컴팩션에서 자세히 다뤘습니다.

6. 설계 축 ④: 감사와 비용

감사: "누가 시켰는가"를 복원할 수 있어야 한다

상시 실행 에이전트에서는 행동의 원인이 흐려집니다. 사용자가 지시한 일인지, 에이전트가 선제 조사로 시작한 일인지, 다른 에이전트가 위임한 일인지 구분되지 않으면 사고가 났을 때 책임을 가릴 수 없습니다.

행동마다 최소한 다음을 남겨야 합니다.

규제 흐름도 같은 방향입니다. 미 FTC는 9월 30일 OpenAI·Anthropic 등을 대상으로 자율형 AI 위험 조사에 착수했고, 미국 주요 AI 기업들은 내부 통제와 외부 검토를 담은 자율 협약에 서명했습니다(AI·IT 브리핑 제1호, 제2호). 기업 고객이 에이전트 공급사와 내부 운영에 요구할 증적도 결국 위 표의 항목들입니다. 수집·관측 체계는 AgentOps 관측성에서 다뤘습니다.

비용: 대화는 공짜여도 위임은 공짜가 아니다

보도에 따르면 dot과의 대화는 ChatGPT 사용량 한도에 포함되지 않지만, dot이 Codex나 ChatGPT Work에서 시작한 작업은 포함됩니다. 출시 첫 달은 사용 한도를 넉넉하게 주고, 이후 구체적인 사용 조건을 공개할 예정이라고 합니다.

상시 실행 에이전트의 비용은 사람이 지켜보지 않는 시간에 쌓인다는 점이 다릅니다. 다음 장치를 권합니다.

• 작업 단위 상한: 작업 하나가 쓸 수 있는 토큰·시간·도구 호출 수에 상한을 둡니다.
• 일·월 예산과 알림: 예산의 일정 비율에 도달하면 알리고, 상한에서는 "먼저 묻기"로 전환합니다.
• 모델 라우팅: 반복적인 에이전트 작업은 저가 모델로 보냅니다. 같은 DevDay에서 공개된 GPT‑6.1 Sol은 100만 토큰당 입력 2달러·출력 10달러로, Astra 대비 약 1/5 가격으로 소개됐습니다.
• 긴 컨텍스트 남용 방지: 컨텍스트 한도가 커져도 매번 전체 문서를 넣지 말고 선별 검색과 프롬프트 캐시를 씁니다.

7. dots를 쓸 것인가, 직접 만들 것인가

dots는 빠르게 도입할 수 있는 완성형 서비스입니다. 반면 기업의 핵심 업무에 들어가려면 데이터 위치, 사내 시스템 연동, 통제 수준에서 한계가 있습니다. 같은 DevDay에서 OpenAI는 관리형 세션·오케스트레이션·컨텍스트 압축·복구를 제공하는 Agents API 공개 베타도 발표한 것으로 보도됐습니다. 직접 구축은 이런 API나 다른 회사의 에이전트 플랫폼, 오픈소스 프레임워크를 조합하는 선택지입니다.

현실적인 답은 대부분 하이브리드입니다.

• 개인 업무 보조(메일 정리, 일정, 조사, 문서 초안)는 dots 같은 SaaS로 빠르게 효과를 봅니다.
• 사내 데이터와 업무 흐름에 깊이 들어가는 일(데이터 파이프라인 운영, 재무·고객 데이터 처리, 규제 대상 업무)은 직접 구축해 통제권을 확보합니다.
• 두 영역 모두 같은 권한·승인·감사 원칙을 적용해, 도구가 달라도 거버넌스는 하나로 유지합니다.

직접 구축할 때의 에이전트 아키텍처는 AI 에이전트 가이드와 Argus Agent 아키텍처, 거버넌스와 텔레메트리는 Argus Agent 거버넌스·텔레메트리에서 다뤘습니다.

8. 상시 실행 에이전트 도입 체크리스트

dots를 쓰든 직접 만들든, 운영에 넣기 전에 다음을 확인하세요.

• 에이전트마다 전용 신원(서비스 계정)이 있고, 소유자가 지정돼 있다
• 읽기와 쓰기 권한이 분리돼 있고, 범위가 최소로 제한돼 있다
• 자격증명은 짧은 수명이며, 에이전트 비활성화 시 즉시 회수된다
• 행동 유형별 정책(자동 / 먼저 묻기 / 사람이 직접)이 문서화돼 있다
• 승인은 특정 버전에 대해 이뤄지고, 외부 행동은 멱등하게 실행된다
• 기억의 열람·수정·삭제 방법과 보존 기간이 정해져 있다
• 연결된 앱의 데이터가 데이터 분류 체계에 포함되고, 민감 데이터 보호 방안이 있다
• 외부 콘텐츠를 읽은 뒤의 쓰기 행동에 대한 인젝션 방어 장치가 있다
• 행동마다 주체·트리거·근거·정책 판정·승인·결과가 기록된다
• 작업 단위 상한, 예산 알림, 모델 라우팅이 설정돼 있다
• 에이전트를 즉시 멈추는 방법(킬 스위치)과 사고 대응 절차가 있다

마치며

dots는 "AI에게 질문한다"에서 "AI에게 역할을 맡긴다"로 넘어가는 신호입니다. 역할을 맡긴다는 것은 사람이 보지 않는 시간의 행동까지 책임진다는 뜻이고, 그래서 상시 실행 에이전트의 경쟁력은 모델 성능만큼이나 권한·승인·감사·비용을 얼마나 잘 설계했는가에서 갈립니다.

같은 주에 OpenAI가 차기 모델을 안전성 평가 미달로 철회하고, 규제 기관이 자율형 AI 조사를 시작한 것도 우연이 아닙니다. 상시 실행 에이전트를 도입하려는 조직이라면, 도구를 고르기 전에 위 체크리스트부터 채워 보길 권합니다.

참고 자료

• OpenAI — Introducing dots · DevDay 2026 recap
• 9to5Google — OpenAI launches Dots, new 'always-on agents'
• Fello AI — OpenAI Dots and DevDay 2026
• BenchLM — OpenAI DevDay 2026 Announcements
• OpenAI Alignment — Self-replicating prompt injections