| Released | 2026-04 (research preview) |
|---|---|
| Developed by | OpenAI |
| Type | Tool |
| Aliases | workspace agents, ChatGPT workspace agents |
| Related | Codex (OpenAI), 컴퓨터 사용 (에이전트), 역할 기반 접근 통제 (RBAC), 가디언 에이전트, Linear |
무엇인가
워크스페이스 에이전트는 ChatGPT 안에서 회사나 팀이 함께 쓰는 AI 도우미다. 한 사람이 한 번 만들어 두면 동료 모두가 같은 도우미를 꺼내 쓸 수 있고, 정해 둔 시간에 알아서 깨어나 일을 시작하기도 한다.
평소 쓰는 ChatGPT가 1인용 스마트 비서라면, 워크스페이스 에이전트는 회사 전체가 공유하는 자동 직원에 가깝다.
일반 ChatGPT와 무엇이 다른가
세 가지 차이가 핵심이다.
공유
한 사람이 만들면 워크스페이스 디렉터리에 올라가고, 동료가 자기 ChatGPT에서 그대로 꺼내 쓴다. 누가 만들었는지, 누가 수정할 수 있는지가 함께 표시된다.
연결
Slack, [[linear]], Google Drive 같은 회사 도구와 묶일 수 있다. 그래서 단순히 글을 써 주는 것을 넘어 채널을 읽고, 이슈를 만들고, 문서를 가져오는 일이 가능해진다.
스케줄과 백그라운드
사용자가 채팅창을 열지 않아도 매일 아침 9시에 깨어나 어제 트래픽을 정리하는 식의 일이 가능하다. 사람이 묻기 전에 먼저 일하는 비서다.
어떻게 쓰는가
- 만든다: 자연어로 "매일 아침 Slack #incidents 채널을 요약해서 나에게 DM 보내줘" 처럼 적는다.
- 연결한다: 어떤 외부 서비스를 건드릴 수 있는지 권한을 골라준다.
- 공유한다: 같은 워크스페이스 동료에게 사용·수정 권한을 열어준다.
- 돌린다: 채팅에서 부르거나, 스케줄대로 자동으로 도는 것을 기다린다.
왜 새로운가
지금까지 ChatGPT는 사람이 켰다 껐다 하는 도구였다. 워크스페이스 에이전트는 회사 안에 늘 머물러 있는 동료처럼 행동한다. [[codex]]가 코딩 작업을 클라우드에서 백그라운드로 돌리는 것과 같은 발상을, 사무 업무 전반으로 옮긴 셈이다.
무엇을 조심해야 하는가
공유되고 권한이 강해진 만큼, 누가 무엇을 할 수 있는지 통제하는 장치가 함께 따라온다. 회사 입장에서는 [[role-based-access-control]] 같은 권한 모델, 그리고 어떤 에이전트가 어떤 일을 했는지 추적하는 기록이 필수다. 처음에는 읽기만 하는 단순한 에이전트로 시작해 점차 쓰기 권한을 늘려가는 쪽이 안전하다.
어디서 쓸 수 있는가
2026년 4월 현재 ChatGPT Business / Enterprise / Edu / Teachers 플랜에서 리서치 프리뷰로 풀려 있다. Plus나 개인 Pro 계정에는 아직 노출되지 않는다.
빌더
관리자 또는 권한 있는 멤버가 워크스페이스 빌더에 들어가 자연어로 세 가지를 정의한다.
- 역할 프롬프트: 에이전트의 페르소나와 책임 범위.
- 커넥터 화이트리스트: 호출을 허용할 외부 도구.
- 트리거: 호출 방식과 자동 실행 조건.
빌더 자체는 기존 GPT 빌더 흐름을 확장한 형태라서, GPT를 만들어 본 사람은 곧장 적응할 수 있다.
커넥터
공식 통합으로 Slack, [[linear]], Google Drive, Outlook, GitHub 같은 SaaS가 묶인다. 인증은 OAuth, 토큰은 워크스페이스 단위 금고에 보관된다. 자체 도구가 필요하면 MCP 서버 또는 함수 호출 스펙으로 붙일 수 있다.
트리거 종류
- on-demand: 동료가 ChatGPT에서 직접 호출.
- on-schedule: cron 풍 표현으로 "매일 아침 9시", "매주 월요일" 같은 정기 실행.
- on-event: 특정 Slack 메시지 키워드, 새 Linear 이슈, 새 PR 등 외부 신호.
스케줄·이벤트 실행은 [[codex]] 가 코드 작업을 돌리는 것과 같은 클라우드 하니스 위에서 진행되며, 결과는 호출자의 inbox 또는 지정 Slack 채널로 회신된다.
거버넌스 레이어
- [[role-based-access-control]]: 보기·실행·수정을 역할 단위로 분리.
- 승인 게이트: 외부 시스템에 쓰기 작업이 있을 때 사람 승인 단계를 끼워 넣는 옵션.
- 감사 로그: 모든 LLM 호출과 도구 호출이 관리자 콘솔에 남는다.
- 검증 단계: 위험도가 높은 행동은 [[guardian-agent]] 패턴처럼 별도 검증 에이전트가 가로채는 구성을 선택할 수 있다.
실전 패턴
- 온콜 다이제스트: Slack #alerts → 매일 아침 어제 인시던트 요약을 온콜 채널에 게시.
- PR 디스패처: GitHub 새 PR → 코드 영역에 따라 리뷰어를 멘션.
- 고객 응답 초안: Zendesk 티켓 → 응답 초안을 만들어 사람 검수 큐로 보냄.
- 주간 메트릭 리포트: BI 도구에서 숫자를 끌어와 슬랙으로 매주 월요일 자동 리포트.
도입 시 주의
- 리서치 프리뷰라 SLA가 없고 동작·UI가 바뀔 수 있다.
- 1초 이내 응답이 필요한 사용자 대면 워크플로에는 부적합하다. 백오피스 자동화에 가깝다.
- 쓰기 권한을 한꺼번에 풀지 말고, 읽기 → 초안 작성 → 사람 승인 후 쓰기 순서로 단계 전개하는 편이 안전하다.
- 권한이 있는 멤버가 만든 에이전트가 다른 멤버의 데이터를 만질 수 있는지 격리 정책을 미리 정해 두어야 한다.
시스템 구성
워크스페이스 에이전트는 OpenAI가 동시에 발표한 두 갈래 — ChatGPT 측의 멀티 사용자 에이전트 런타임과 [[codex]] 의 백그라운드 코드 실행 환경 — 을 같은 인프라 줄기 위에서 운영한다. 두 발표가 한 시점에 나온 이유는 하니스가 분리돼 있지 않기 때문이다.
핵심 컴포넌트:
- Agent Definition: 자연어 시스템 프롬프트, 허용 커넥터 화이트리스트, 트리거 명세를 묶은 선언적 객체.
- Connector Layer: OAuth 기반 외부 SaaS 통합. 워크스페이스 단위 토큰 금고와 권한 스코프 관리.
- Scheduler / Event Bus: 시간 트리거와 외부 이벤트를 받아 격리 실행 환경을 띄우는 컨트롤 플레인.
- Governance Plane: [[role-based-access-control]], 감사 로그, 승인 게이트, 정책 엔진.
실행 모델
호출은 (a) 인터랙티브 채팅, (b) 스케줄, (c) 외부 이벤트 중 하나로 도착한다. 도착 시 워크스페이스 단위 quota·정책 검사를 통과하면 격리된 컨테이너에서 LLM 호출 + 도구 호출 루프를 돌린다. 산출물은 호출자 inbox 또는 연결 채널로 회신되며, 모든 단계가 감사 스트림에 동시 기록된다.
비결정성은 LLM 추론에서 매 단계 들어오기 때문에, 워크플로 엔진이 가지는 "동일 입력 → 동일 출력" 보장을 그대로 옮겨 놓을 수는 없다. 따라서 회귀 테스트는 결과 동등성보다는 산출물의 검증 가능한 속성(스키마 일치, 정책 위반 여부)을 검사하는 형태로 가야 한다.
안전 장치
워크스페이스 에이전트는 일반 ChatGPT보다 외부 부작용 면적이 훨씬 넓다. OpenAI는 이를 네 단계로 좁힌다.
- 연결 시점 동의: 커넥터 부착 시 요구되는 OAuth 스코프를 명시적으로 표시.
- 실행 시점 검증: 위험 등급이 높은 도구 호출은 [[guardian-agent]] 패턴으로 별도 검증 에이전트가 가로챔.
- 사후 감사: 모든 LLM 호출 + 도구 호출이 관리자 콘솔에 노출되며 보존 기간이 정책으로 잡힘.
- 정책 레이어: [[constitutional-ai]] 식 규칙 기반 거절을 워크스페이스 단위 정책으로 얹어, 동일 모델이라도 워크스페이스마다 허용 범위가 달라지도록 함.
[[computer-use]] 와의 관계
[[computer-use]] 는 가상 브라우저·데스크톱을 직접 조작하는 능력 자체이고, 워크스페이스 에이전트는 그 능력을 멀티 사용자 거버넌스 레이어 안에서 제품으로 노출하는 layer 다. 워크스페이스 에이전트가 공식 API가 없는 SaaS에 손을 뻗을 때 내부적으로 [[computer-use]] 가 동원될 수 있고, 이 경우 시각 기반 액션의 비결정성이 한 단계 더해진다.
기존 자동화와의 차이
Zapier·n8n 같은 기존 워크플로 엔진이 결정적 룰 기반 "트리거 → 액션" 그래프라면, 워크스페이스 에이전트는 매 단계에 LLM 추론을 끼워 넣는 형태다. 비정형 입력을 흡수하는 능력은 크게 늘지만, 결정성·재현성·테스트 용이성은 떨어진다. 운영 관점에서는 두 패러다임 사이의 어느 지점이 ROI가 좋은지가 도입 의사결정의 핵심이 된다.
열린 문제
- 격리(isolation): 한 멤버가 만든 에이전트가 다른 멤버의 자원에 접근할 때의 권한 모델. "누구의 권한으로 실행되는가" 가 스케줄·이벤트 트리거에서 흐려질 위험.
- 회귀 테스트: 비결정 행동에 대한 검증 가능한 불변식 정의가 아직 표준화돼 있지 않음.
- 장기 메모리와의 결합: [[chronicle]] 같은 장기 컨텍스트 시스템과 묶이면 권한 누수 면적이 시간축으로 늘어남.
- 규제 산업 도입: HIPAA·금융권 감사 요건 아래에서의 감사 로그 보존·암호화·접근 통제 충분성 검증.
- 비용 구조: 백그라운드 자동 호출이 늘어날수록 사용자 직접 호출 모델과 다른 비용 곡선이 만들어지며, 이를 워크스페이스 단위로 예산화하는 표준이 아직 정착 전.