OpenAI Dots 설계 읽기: 항상 켜진 에이전트를 제품에 붙일 때 필요한 안전장치

요약: OpenAI가 Dots를 공개했다. Dots는 사용자의 목표와 선호를 학습하고, 연결된 앱과 자체 cloud computer를 사용해 장기 작업을 진행하는 항상 켜진 에이전트다. 개발자에게 중요한 질문은 “우리도 비슷한 에이전트를 만들 수 있나”가 아니라 “항상 켜진 에이전트에 필요한 권한, 승인, 관찰 가능성을 어떻게 설계할 것인가”다.

핵심 키워드: OpenAI Dots, always-on agent, AI 에이전트 권한 설계, agent approval, proactive AI

Dots가 말해주는 방향

OpenAI Dots는 단발성 챗봇보다 장기 실행 에이전트에 가깝다. 사용자의 앱에 연결되고, 자체 cloud computer와 browser를 가지고, Slack이나 Teams 같은 업무 채널에서도 대화하며, 사용자가 직접 지시하지 않아도 읽기 전용 범위에서 proactive research를 수행한다.

제품 설명에서 눈여겨볼 점은 기능보다 통제 구조다. OpenAI는 dot이 앱에 접근할 수 있지만, 중요한 작업은 approval을 거치고, custom rules로 허용·승인 필요·차단을 나눌 수 있으며, Activity View로 진행 상황을 볼 수 있다고 설명한다. saved password를 모델에 노출하지 않고 사용할 수 있다는 점도 언급한다.

이 구조는 에이전트 제품을 만드는 팀에게 좋은 힌트다. 사용자는 “알아서 해줘”를 원하지만, 동시에 “멋대로 하지 마”도 원한다. 이 둘을 동시에 만족시키려면 권한 모델이 먼저 있어야 한다.

항상 켜진 에이전트의 핵심 리스크

일반 챗봇은 사용자가 메시지를 보낼 때만 반응한다. 그래서 사고 범위가 비교적 작다. 반면 always-on agent는 사용자가 자는 동안에도 정보를 읽고, 작업을 이어가고, 알림을 보내고, 경우에 따라 외부 시스템에 쓰기를 시도할 수 있다.

리스크는 크게 네 가지다.

첫째, 과잉 행동이다. 사용자는 “회의 준비해줘”라고 했는데 에이전트가 참석자에게 메시지를 보내거나 캘린더를 바꿔버리면 문제가 된다.

둘째, 권한 누수다. Slack, Drive, Jira, Gmail을 모두 연결하면 에이전트는 조직의 많은 정보를 볼 수 있다. 프롬프트 인젝션이나 악성 문서가 들어오면 민감한 정보를 잘못 요약하거나 외부로 옮길 위험이 있다.

셋째, 장기 작업의 drift다. 처음 목표는 “자료 조사”였는데 중간에 잘못된 가정을 쌓아 엉뚱한 결과물을 만들 수 있다. 장기 실행일수록 중간 검문소가 필요하다.

넷째, 책임 불명확성이다. 에이전트가 보낸 메시지, 수정한 문서, 생성한 티켓의 책임이 누구에게 있는지 명확하지 않으면 조직에서 쓰기 어렵다.

제품에 붙일 권한 모델

항상 켜진 에이전트를 만들 때는 OAuth scope만으로는 부족하다. 앱 권한과 에이전트 행동 권한을 따로 봐야 한다.

권장하는 권한 단계는 다음과 같다.

• Read: 정보를 읽고 요약할 수 있음.
• Draft: 이메일, 문서, 티켓, 코드 변경안을 초안으로 만들 수 있음.
• Suggest: 사용자에게 실행 버튼이 있는 제안을 보낼 수 있음.
• Act with approval: 승인 후 외부 시스템에 쓸 수 있음.
• Act automatically: 사전에 허용된 낮은 위험 작업만 자동 실행.
• Blocked: 어떤 상황에서도 수행 금지.

중요한 점은 작업별로 단계를 다르게 둬야 한다는 것이다. “Jira 티켓 생성”은 자동 허용해도 될 수 있지만, “고객에게 이메일 발송”은 approval이 필요하다. “비밀번호 변경”이나 “결제 승인”은 아예 blocked로 둘 수 있다.

또한 custom rules는 자연어로만 저장하면 위험하다. 사용자에게는 자연어로 보여주더라도 내부적으로는 action type, target app, data class, risk level, approval requirement 같은 구조화된 정책으로 바꿔야 한다.

Activity View와 감사 로그 설계

Dots 설명에서 Activity View가 언급된 점은 중요하다. 장기 실행 에이전트는 결과물만 보여주면 신뢰를 얻기 어렵다. 사용자는 에이전트가 무엇을 읽었고, 어떤 판단을 했고, 어디서 멈췄는지 봐야 한다.

감사 로그에는 최소한 다음 항목이 필요하다.

• 작업 시작 시각과 트리거.
• 사용자가 준 원래 목표.
• 읽은 데이터 출처와 범위.
• 호출한 도구와 결과 요약.
• 승인 요청과 승인자.
• 외부 시스템에 쓴 변경 사항.
• 실패, 중단, 정책 차단 이유.

이 로그는 개발자 디버깅용만이 아니다. 사용자가 불안할 때 “무슨 일이 있었는지” 확인하는 제품 기능이다. 엔터프라이즈에서는 보안팀과 감사팀이 보는 근거가 된다.

Proactive research를 안전하게 만드는 방법

OpenAI는 사용자가 적극적으로 작업 중이 아닐 때 dot이 읽기 전용 도구로 proactive research를 할 수 있다고 설명한다. 이 패턴은 유용하지만, 제품 설계가 조금만 엉성해도 스팸이 된다.

좋은 proactive agent는 매번 말을 걸지 않는다. 의미 있는 변화가 있을 때만 알린다. 예를 들어 “경쟁사 가격 페이지가 바뀌었다”, “오늘 회의 전까지 읽어야 할 문서가 3개 있다”, “지난주부터 막힌 Jira 이슈가 배포 일정에 영향을 줄 가능성이 있다”처럼 행동 가능한 신호가 있어야 한다.

알림 기준은 다음처럼 설계할 수 있다.

• 사용자의 명시적 목표와 연결된 변화인가.
• 지금 알리지 않으면 손실이 생기는가.
• 사용자가 바로 선택할 수 있는 다음 행동이 있는가.
• 같은 유형의 알림을 최근에 이미 보냈는가.
• confidence가 낮으면 질문으로 바꿔야 하는가.

이 기준이 없으면 에이전트는 “도움이 될 수도 있는 정보”를 계속 던지게 된다. 사용자는 결국 알림을 꺼버린다.

개발팀이 MVP로 만들 때의 현실적인 범위

Dots 같은 제품을 처음부터 만들 필요는 없다. MVP는 한 도메인, 한 앱, 한 행동으로 좁혀야 한다. 예를 들어 “Jira와 Slack을 읽고, 진행 막힘 후보를 요약하며, 티켓 댓글 초안만 작성하는 에이전트” 정도가 현실적이다.

초기 범위 예시는 다음과 같다.

• 입력: Jira 이슈, Slack 스레드, GitHub PR.
• 행동: 요약, blocker 탐지, 댓글 초안 생성.
• 쓰기: 사용자 승인 후 Jira 댓글 작성.
• 금지: 담당자 변경, 일정 변경, 외부 메시지 발송.
• 로그: 읽은 링크, 생성한 초안, 승인 여부 저장.

이 정도만 잘 만들어도 팀은 가치를 느낄 수 있다. 반대로 처음부터 이메일, 캘린더, Slack, Drive, GitHub, 결제까지 붙이면 권한 설계와 QA가 감당되지 않는다.

실행 체크리스트

• 에이전트 행동을 Read, Draft, Suggest, Act with approval, Act automatically, Blocked로 나눈다.
• OAuth scope와 별개로 action-level policy를 만든다.
• 외부 발송, 결제, 권한 변경, 삭제는 기본적으로 approval 또는 blocked로 둔다.
• Activity View에 읽은 데이터, 도구 호출, 승인, 변경 사항을 남긴다.
• proactive 알림은 “지금 행동할 수 있는 변화”에만 제한한다.
• MVP는 한 도메인, 한 앱, 한 쓰기 행동으로 시작한다.
• 프롬프트 인젝션 대응을 위해 외부 문서 내용과 시스템 명령을 분리해 처리한다.