Frontier Agent 리서치: OpenAI dots와 Meta Muse로 본 상시 동작형 에이전트¶
OpenAI dots와 Meta Muse를 기준으로 전용 컴퓨터, 상시 실행, 분리된 제어면을 갖춘 frontier agent의 구조를 정리하고 Agent 서비스 준비에 필요한 시사점을 도출합니다.
조사 기준일: 2026-09-30. 2026년 9월, OpenAI와 Meta는 거의 같은 시기에 대화형 비서를 넘어서는 개인 에이전트를 공개했다. Meta는 2026-09-08에 Muse를, OpenAI는 2026-09-29에 dots를 발표했다. 두 제품은 이름과 대상 사용자가 다르지만 구조는 놀라울 만큼 닮았다.
- 사용자마다 전용 클라우드 컴퓨터와 브라우저를 준다.
- 사용자가 앱을 닫아도 백그라운드에서 계속 일하고 먼저 말을 건다.
- 모델이 무엇을 하든 넘을 수 없는 분리된 제어면이 모든 행동을 검사한다.
이 리서치는 두 제품을 “frontier agent”라는 하나의 범주로 묶어 기술 구조를 해부하고, 우리가 Agent 서비스를 준비할 때 무엇을 설계해야 하는지를 정리한다. OpenAI는 dots를 “frontier intelligence that have your back”이라고 소개하고, Meta는 Muse를 “move with the frontier”하는 제품이라고 표현한다. 이 문서의 frontier agent는 이런 공개 표현에서 따온 분석용 용어이며 두 회사가 정의한 공식 제품 분류가 아니다.
30초 요약¶
| 질문 | 핵심 판단 |
|---|---|
| frontier agent는 무엇이 다른가 | 한 번의 요청에 답하는 챗봇이 아니라, 목표를 받아 자기 컴퓨터에서 계속 일하는 에이전트다. 실행 환경, 상시 실행, 기억, 연결, 제어면, 투명성 여섯 요소를 함께 갖춘다. |
| dots와 Muse의 공통점 | 사용자별 격리된 클라우드 컴퓨터, 선제적 백그라운드 작업, 모델에 비밀을 보여 주지 않는 자격 증명 처리, 에이전트가 끌 수 없는 별도 행동 검사, 활동 기록과 승인 UI. |
| 가장 큰 차이 | dots는 업무 협업(Slack·Teams, specialist dots, Microsoft Agent 365 연동 계획)을, Muse는 개인 생활(WhatsApp, 쇼핑, 일회용 카드)을 우선한다. Meta는 VM 내부 격리 구조를 커널 수준까지 공개했다. |
| 기술적 핵심 | 모델을 믿는 것이 아니라 모델이 공격받았다고 가정하는 시스템 설계다. 제안은 에이전트가, 허가는 에이전트 밖의 정책 엔진이 한다. |
| 우리에게 주는 시사점 | Azure에서는 Foundry hosted agent가 격리 실행·세션 상태·에이전트 신원을 제공하지만, 도구 승인의 집행과 egress 검사 같은 제어면은 우리가 설계해야 한다. |
Frontier agent의 여섯 구성 요소¶
두 제품의 공개 자료를 겹쳐 보면 다음 여섯 요소가 공통으로 나타난다. 이 분류는 이 리서치가 두 제품을 비교하려고 정리한 것이다.
| 구성 요소 | 무엇을 해결하는가 | dots | Muse |
|---|---|---|---|
| 전용 실행 환경 | 대화가 끝나도 작업을 이어 갈 장소 | dot마다 자체 클라우드 컴퓨터와 브라우저. OpenAI가 Linux OS와 Chrome을 관리 | 사용자별 persistent Linux VM(Muse Secure VM)과 전체 브라우저 |
| 상시 실행과 선제성 | 사용자가 묻기 전에 필요한 일을 발견 | 24/7 동작, 읽기 전용 도구로 “proactive research” | 일정·이벤트에 따라 계속 작업하고, 의미 있는 결과만 알림 |
| 연결 | 실제 업무가 있는 곳에 접근 | Plugin 생태계로 4,000개가 넘는 앱에 연결 | 이메일·캘린더·Instagram 등 connector, 필요하면 도구를 직접 작성 |
| 기억과 개인화 | 매번 설명하지 않아도 되는 협업 | 피드백으로 선호와 기준을 학습, dot별 context 초기화 가능 | 대화를 넘는 memory, 사용자가 읽고 고칠 수 있는 Memory 파일, Goals 탭 |
| 분리된 제어면 | 모델이 속거나 실수해도 피해를 제한 | Auto-review, 안전 모니터, secure sign-in | Sentinel, privsep worker, authd, tainted egress |
| 투명성과 통제 | 보이지 않는 작업을 신뢰할 근거 | Activity View, Custom Rules, 승인·반환 규칙 | 활동 로그, 승인 카드, 다양한 범위의 권한 부여 |
그림 1. 두 제품의 공개 설명을 바탕으로 이 리서치가 작성한 공통 참조 아키텍처. 특정 제품의 실제 배포 구조를 그대로 옮긴 것이 아니다.
dots와 Muse 비교¶
| 비교 축 | OpenAI dots | Meta Muse |
|---|---|---|
| 발표 | 2026-09-29, ChatGPT의 새 기능 | 2026-09-08, 독립 앱(모바일, Mac)과 WhatsApp |
| 모델 | GPT-6 Astra | Muse Spark 1.3(보안 블로그 기준) |
| 실행 환경 | dot별 클라우드 컴퓨터. 사용자가 허용하면 노트북에도 연결 | 사용자와 에이전트가 함께 쓰는 persistent Linux VM |
| 대화 채널 | ChatGPT(desktop, web, mobile), Slack, Teams, 음성 통화. 문자 메시지 예정 | Muse 앱, WhatsApp |
| 행동 검사 | 별도 안전 시스템 Auto-review가 계획된 단계를 지시, Custom Rules, 안전 요구 사항과 대조 | 호스트 쪽 Sentinel이 connector 행동과 모든 네트워크 egress의 유일한 허가 주체 |
| 자격 증명 | secure sign-in 중 모델을 일시 정지, 암호화된 credential service가 비밀번호 주입 | authd가 저장, 에이전트는 surrogate token만 보고 Sentinel이 네트워크 경계에서 실제 값으로 교체 |
| 조직 기능 | specialist dots: 조직이 부여한 신원·자격 증명·접근 권한, enterprise pilot | Muse for Small Business: 소상공인용 skill과 connector 모음 |
| 제공 범위 | Pro, Business Premium(eligible markets), Enterprise·Edu·Healthcare는 관리자 활성화 시 beta | 사용량 한도가 있는 무료, 유료 구독으로 확장 |
두 제품의 세부 구조는 각 자식 문서에서 다룬다.
- OpenAI dots 해부: 제품 구성, Auto-review와 행동 규칙, proactive research, specialist dots와 Microsoft Agent 365
- Meta Muse 해부: Muse Secure VM의 두 보안 도메인, Sentinel, tainted egress, 브라우저 sub-agent, 결제 보호
- Agent 서비스 준비: Azure 매핑: Foundry hosted agent, Entra Agent ID, Agent 365로 같은 구조를 구성할 때의 제공 범위와 직접 설계할 부분
Agent 서비스 준비 관점의 핵심 시사점¶
두 제품이 공개한 설계에서 우리 서비스에 바로 적용할 수 있는 원칙은 다섯 가지다.
- 제안과 허가를 분리한다. 모델이 다음 행동을 제안하면, 모델이 수정할 수 없는 위치의 정책 엔진이 허가·거부·사용자 확인 중 하나를 결정한다.
- 비밀은 모델 context에 넣지 않는다. 로그인과 토큰 주입은 모델을 멈추거나 경계 밖에서 대체하는 방식으로 처리한다.
- 선제 작업은 읽기 전용으로 시작한다. 백그라운드 조사는 쓰기 권한 없이 메모를 남기고, 실제 행동은 일반 승인 규칙을 다시 거친다.
- 승인 피로를 설계 대상으로 본다. 되돌리기 어려운 행동만 멈추고, 승인은 대상·범위·기간이 묶인 권한(capability)으로 발급한다.
- 보이지 않는 작업은 보이게 만든다. 활동 로그, 목표 화면, 편집 가능한 메모리가 신뢰의 근거가 된다.
Azure에서 이 원칙을 구현할 때 Foundry hosted agent는 세션별 VM 격리 sandbox, 지속 파일 시스템, 에이전트별 Microsoft Entra ID를 제공한다. Microsoft Agent 365는 조직 안의 에이전트를 관찰·통제·보호하는 관리 계층이다. 반면 행동 승인을 집행하는 정책 서비스와 egress 검사 계층은 플랫폼 기능만으로 완성되지 않는다. 자세한 대응 관계와 단계별 도입 순서는 Azure 매핑 문서에서 정리한다.
조사 범위와 한계¶
- 기준일은 2026-09-30이다. 두 제품은 출시 직후이며 기능, 요금, 제공 지역은 빠르게 바뀔 수 있다.
- 제품 동작과 보안 구조는 각 회사가 공개한 자료의 주장이다. 이 리서치는 두 제품을 직접 실행하거나 보안 주장을 독립적으로 검증하지 않았다.
- 모델 성능, 가격, 벤치마크 수치는 다루지 않는다. 언론 보도와 제3자 요약은 근거에서 제외하고 각 회사의 공식 페이지만 사용했다.
- Azure 기능은 Microsoft Learn 원문으로 확인했으며, preview 기능은 문서에 preview로 표시한다.
공식 출처¶
| 출처 | 이 페이지에서 사용한 범위 |
|---|---|
| Introducing dots | dots의 정의, GPT-6 Astra, 채널, specialist dots, 제공 범위 |
| How we build safety, security, and privacy into dots | Auto-review, secure sign-in, proactive research, 행동 규칙 |
| Muse 제품 페이지 | Muse Secure VM, connector, 승인과 감사 추적, 요금 방식 |
| How We Designed Muse | 대화 모델, 선제 메시지, 결정적 UI, Artifacts |
| How We Built Safety Into Muse | VM 내부 격리, Sentinel, 모델 이름, 결제 보호 |
| What are hosted agents? | Foundry hosted agent의 격리 모델과 에이전트 신원 |
| Overview of Microsoft Agent 365 | Agent 365의 observe, govern, secure 범위 |