2026년 7월 11일 기준 OpenAI는 Workspace Agents를 ChatGPT Business, Enterprise, Edu, Teachers용 research preview로 안내합니다. 현재 도움말에는 템플릿과 프롬프트 기반 빌더, Preview, 앱, 파일, skills, custom MCP, ChatGPT와 Slack 채널, 스케줄, API 트리거, 공동 편집, 버전 기록, 분석, RBAC까지 포함됩니다.
기능이 많다는 사실은 첫날부터 넓은 권한을 줘야 한다는 뜻이 아닙니다. 좋은 첫 후보는 반복되는 내부 업무이고, 승인된 자료만 읽으며, 검토 가능한 초안을 만들고, 민감한 쓰기 전에 사람에게 멈출 수 있어야 합니다. 고객에게 직접 발송하거나 전체 메일함을 관리하거나 데이터베이스를 제한 없이 수정하는 업무는 첫 실험으로 적합하지 않습니다.
빌더를 열기 전에 접근 경로부터 확인하세요
공식 Workspace Agents 제품 페이지는 Business, Enterprise, Edu, Teachers를 대상 플랜으로 나열합니다. 실제 운영 기준은 Help Center입니다. ChatGPT 사이드바의 Agents에서 템플릿, 자연어 설명, 빈 빌더 중 하나를 선택하고 공개 전에 Preview에서 동작을 시험합니다.
| 확인할 질문 | 현재 경계 | 다음 행동 |
|---|---|---|
| Agents 메뉴가 보이지 않음 | 로그인한 workspace, 역할, 관리자 설정에 따라 표시가 달라질 수 있음 | 브라우저 문제를 찾기 전에 workspace와 RBAC 확인 |
| 개인 Pro에서 사용 가능 여부 | 공개 페이지는 워크스페이스 플랜을 명시하고 개인 Pro는 열거하지 않음 | 개인 구독 이름으로 기업 기능 권한을 추정하지 않기 |
| ChatGPT 밖에서 실행 가능 여부 | Slack, Schedule, API channel을 설정할 수 있음 | 각 경로를 별도의 인증·공개 범위·위험 결정으로 취급 |
| API가 답변도 반환하는지 | 현재 trigger는 실행을 큐에 넣지만 결과를 반환하지 않음 | 동기 응답이나 run ID polling을 전제로 설계하지 않기 |
| 현재 가격이 얼마인지 | 공개 제품 및 도움말 페이지에는 모든 workspace에 적용되는 안정적인 숫자 가격표가 없음 | 로그인한 workspace, 현재 공식 플랜, 계약 소유자에게 확인 |
2026년 5월 6일까지 무료라는 출시 당시 문구는 이미 만료됐습니다. 현재 예산의 근거로 사용할 수 없습니다. 도움말 예시에 앱 이름이 등장하는 것도 해당 connector와 action이 조직에 실제 활성화됐다는 증거가 아닙니다.
이 업무를 Workspace Agent로 만들 이유가 있는지 판단하세요
Workspace Agent는 업무가 반복되고, 팀이 공유하며, 시작 조건과 결과가 명확하고, 승인된 자료나 도구를 사용하며, 성공과 중지 기준을 설명할 수 있을 때 유용합니다. 지정 자료 기반 주간 브리프, 회의 기록에서 액션 후보 추출, 고객 인수인계 요약, 지식 문서 업데이트 제안은 비교적 안전한 첫 후보입니다.
한 번만 하는 탐색은 일반 ChatGPT가 더 간단합니다. 대화 패턴을 반복하는 정도라면 기존 GPT가 충분할 수 있습니다. 규칙이 완전히 고정된 처리라면 결정론적 자동화가 더 예측 가능하고 감사하기 쉽습니다. 새 제품 이름 때문에 옮기지 말고, 공유 실행, schedule, channel, tool, 팀 소유권, 승인, version history 중 어떤 기능이 실제 문제를 해결하는지 먼저 밝히세요.
후보 업무를 한 문장으로 표현할 수 없거나, 읽을 데이터 범위를 열거할 수 없거나, 첫 실행부터 되돌릴 수 없는 외부 행동이 필요하거나, 공유 자격 증명 소유자가 없거나, 실패 후 복구할 방법이 없다면 멈추세요. 먼저 ‘읽기-초안-사람 검토’로 업무를 축소해야 합니다.
첫 번째 안전한 Agent를 구축하는 순서
빌더에서는 다음 순서가 실용적입니다.
- 업무와 결과 소유자를 한 문장으로 정의합니다.
- 수동, 멘션, 시간, 이벤트, API 중 하나의 trigger를 선택합니다.
- 읽기를 허용할 문서, 앱, 데이터 범위를 정확히 적습니다.
- 결과를 요약, 권고, 체크리스트, 메시지 초안, 업데이트 제안 중 하나로 정합니다.
- 필요한 앱, 파일, skill, custom MCP만 추가합니다.
- Preview에서 정상 사례, 데이터 누락, 출처 충돌, 범위 밖 요청을 시험합니다.
- 발송, 편집, 게시, 삭제 같은 쓰기는 승인 상태로 둡니다.
- 성공 지표, stop rule, 자격 증명 소유자, 복구할 정상 version을 기록합니다.
좋은 instruction은 성격 묘사가 아니라 운영 계약에 가깝습니다. “매주 월요일 지정된 세 문서만 읽고, 근거를 붙인 위험 요약을 만들고, 빠진 정보를 표시하며, 담당자의 승인 전에는 Slack에 게시하지 않는다”처럼 trigger, source, output, citation, owner, write boundary가 들어가야 합니다. “고객 성공 업무를 자율적으로 처리하라”는 문장은 합격 기준도 중지 조건도 없습니다.
Preview에서는 보기 좋은 성공 사례만 반복하지 마세요. 권한이 없는 문서, 오래된 자료, 서로 충돌하는 두 출처, 허용 범위를 벗어난 수신자도 넣어 봐야 합니다. Agent가 추측으로 빈칸을 채우지 않고 부족함을 알리며 멈추는 능력이 긴 데모보다 중요합니다.
앱, skills, MCP, 채널은 권한 모델이 아닙니다
앱과 connector는 외부 시스템을 연결합니다. 파일은 안정적인 맥락을 제공합니다. skills는 반복 가능한 절차를 보존합니다. custom MCP는 특정 도구나 데이터 표면을 추가합니다. channel은 어디에서 호출할지를 정합니다. 어느 하나도 그 자체로 접근 제어나 승인 정책을 대신하지 못합니다.
앱 연결은 최종 사용자의 계정을 사용하거나 Agent-owned shared connection을 사용할 수 있습니다. 공유 연결에는 가능한 경우 service account를 쓰고 시스템 소유자를 지정하세요. 직원 개인 계정을 조직 인프라로 사용하면 사적 데이터, 이동, 퇴사, 권한 변경이 운영 위험이 됩니다.
쓰기 위험도 분리해야 합니다. 내부 초안을 만드는 것, 외부 메일을 보내는 것, 계약 파일을 고치는 것, 문서를 삭제하는 것, 고객 DB를 수정하는 것은 같은 행동이 아닙니다. 첫 배포에서는 민감한 action을 Always ask로 유지하고, 누가 승인하며 어디에 기록이 남는지 정하세요. 몇 번의 성공만으로 모든 쓰기를 한 번에 자동 승인으로 바꾸면 안 됩니다.
API trigger는 시작만 하고 답변은 돌려주지 않습니다
API channel을 사용하면 내부 시스템, 예약 작업, 지원 도구가 Workspace Agent 실행을 시작할 수 있습니다. ChatGPT Admin에서 Workspace Agents scope를 가진 access token을 만듭니다. 토큰은 브라우저나 공개 client에 넣지 말고 서버에만 보관하며, 호출 시스템의 권한도 Agent의 업무 범위만큼 좁혀야 합니다.
현재 설계를 좌우하는 제약은 응답 형태입니다. OpenAI 설명에 따르면 trigger는 실행을 큐에 넣고 202 Accepted를 반환하지만 response body가 없습니다. run ID도 없고, 이 trigger를 통해 Agent 결과를 다시 가져올 수도 없습니다. 따라서 결과나 효과가 다른 정해진 장소에 생기는 ‘fire and queue’ 업무에는 맞지만, 호출자가 즉시 답변을 표시해야 하는 API나 특정 run의 상태를 조회해야 하는 통합에는 맞지 않습니다.
| 필요한 사용 경험 | 현재 적합한 경로 | 중지 조건 |
|---|---|---|
| 동료가 실행하고 결과를 읽음 | ChatGPT | 여기서 안정되기 전에 다른 채널 추가 금지 |
| 팀 채널에서 호출하거나 받음 | Slack | shared auth, 좁은 audience, 쓰기 승인 없이는 공개 금지 |
| 시간에 따라 반복 | Schedule | 여러 번의 수동 Preview보다 먼저 켜지 않기 |
| 내부 시스템은 시작만 필요 | API trigger | 답변이나 run ID가 필요하면 채택하지 않기 |
202 응답만 성공 지표로 삼지 마세요. 이는 큐가 요청을 받아들였다는 뜻이지, 업무 결과가 정확하거나 외부 action이 완료됐거나 승인 절차를 통과했다는 증거가 아닙니다. 결과가 나타날 위치와 운영자가 실패를 확인할 방법을 별도로 정의해야 합니다.
Connector Action Constraints가 보호하지 못하는 것
Connector Action Constraints는 지원되는 action의 사용 방법을 좁힐 수 있습니다. 예를 들어 이메일 수신자를 특정 도메인으로 제한하거나 하나의 Google Doc만 대상으로 정할 수 있습니다. 유용한 방어선이지만, 허용된 action이 반환하는 모든 데이터를 자동 필터링하지는 않습니다.
따라서 자연어 instruction에 제한을 쓰는 것만으로 데이터 안전을 보장할 수 없습니다. 연결 계정 자체에 least privilege를 적용하고, connector scope를 좁히고, Agent audience를 제한하고, 쓰기를 승인하며, 합법적인 한 번의 호출이 실제로 어떤 필드를 반환하는지 확인해야 합니다. 메일, CRM, 인사, 재무, 고객 데이터는 반환 범위를 명시적인 테스트 항목으로 넣으세요.
Constraints는 다층 통제의 한 요소입니다. 빌더 instruction, workspace RBAC, 연결 시스템 권한, action constraint, 승인, log, 공유 대상이 함께 작동해야 의도한 경계에 가까워집니다.
공동 편집, Owner 권한, version rollback
Owner는 개인 또는 지원되는 workspace 그룹에 Can chat이나 Can edit를 부여할 수 있습니다. Editor는 공유 draft, instruction, 파일, skills, 지원 앱과 connector를 수정할 수 있습니다. 반면 공유 범위 변경, workspace 전체 배포, 삭제, channel 설정, 일부 연결 리소스는 Owner에게 남습니다.
multiplayer editing은 하나의 공유 draft를 뜻하지만 실시간 conflict-free merge를 뜻하지 않습니다. 다른 편집자가 먼저 저장하면 새로고침 과정에서 저장하지 않은 로컬 변경이 대체될 수 있습니다. 큰 변경은 담당 편집자를 조율하고 refresh 전에 내용을 복사하며, 게시 후에는 version history에서 차이를 확인하세요. 문제가 생기면 알려진 정상 version을 다시 게시하는 절차가 필요합니다.
넓게 배포하기 전에 세 가지 책임을 정하세요. workflow owner는 업무 가치와 성공 기준을 맡고, agent owner는 공유·게시·channel을 맡으며, system owner는 shared credential과 connector permission을 맡습니다. Analytics의 unique users와 runs는 채택 현황을 보여 주지만, 결과 품질 검토나 승인 감사, 사고 책임을 대신하지 않습니다.
Slack은 ChatGPT 검증 뒤에 추가하세요
Slack은 배포 channel이지 보안 모델이 아닙니다. Slack admin이 연결을 승인해야 할 수 있고, Agent의 모든 app connection은 shared authentication을 사용해야 합니다. 배포 전에 대상 workspace, channel 또는 user group, 응답 방식, 공유 계정 owner, 승인 필요한 action을 확정하세요.
처음에는 수동 mention으로 시험합니다. 고객 메시지는 초안으로 남기고, 파일이나 DB 변경에는 명시적 승인과 log를 요구하세요. 비공개 채널의 맥락이 Agent를 다른 그룹과 공유했다는 이유만으로 넓은 audience에 노출되지 않는지도 확인해야 합니다. Slack workspace를 바꿨을 때 재연결하는 절차도 운영 문서에 넣으세요.
가격과 가용성은 결정 시점에 다시 확인하세요
플랜, connector, action, limit, 비용은 변할 수 있습니다. 현재 공개 페이지는 Business, Enterprise, Edu, Teachers를 research preview 대상으로 유지하지만 모든 workspace에 적용되는 하나의 숫자 가격을 제공하지 않습니다. 고빈도 schedule, 여러 tool, 대규모 공유를 계획한다면 로그인한 workspace, 최신 공식 플랜, 고객 계약을 확인해야 합니다.
테스트 기록에는 workspace, 역할, 활성화된 apps, 인증 방식, trigger route, 승인 policy, 게시된 version을 남기세요. 같은 이름의 Agent라도 이 조건이 다르면 결과와 위험은 동일하지 않습니다.
확대 배포 전 체크리스트
대상 플랜과 역할, 하나의 trigger와 output, 최소 출처, 인증 owner, Preview 근거, 쓰기 승인, channel audience, log 위치, stop rule, 복구 version을 확인하세요. Schedule이나 넓은 공개 전에 현재 사용 조건과 비용도 다시 확인해야 합니다.
좋은 성공 지표는 연결한 시스템 수가 아닙니다. 반복 업무가 빨라지면서도 팀이 정보 출처, 권한, 승인, 실패 책임, 복구 방법을 설명할 수 있어야 합니다.
FAQ
개인 ChatGPT Pro에서 Workspace Agents를 사용할 수 있나요?
현재 공개 대상은 Business, Enterprise, Edu, Teachers이며 개인 Pro는 열거되지 않습니다. 개인 구독 이름이 아니라 로그인한 workspace와 역할을 확인하세요.
기존 GPT를 반드시 Workspace Agent로 바꿔야 하나요?
아닙니다. 공유 실행, tools, schedules, channels, 협업, governance에서 명확한 이점이 입증될 때까지 기존 GPT나 자동화를 fallback으로 유지할 수 있습니다.
같은 회사인데 누군가는 Agents가 보이고 누군가는 안 보이는 이유는 무엇인가요?
서로 다른 workspace에 있거나 RBAC 역할이 다를 수 있습니다. Enterprise에서는 관리자 활성화도 영향을 줍니다. Codex Workspace Agents plugin도 같은 RBAC를 사용하며 별도의 Codex-only toggle은 없습니다.
API trigger가 Agent 답변을 동기식으로 반환하나요?
현재는 아닙니다. 실행을 큐에 넣고 202 Accepted를 반환하지만 body, run ID, 결과 조회 기능은 제공하지 않습니다.
여러 사람이 하나의 Agent를 편집할 수 있나요?
Can edit와 그룹 공유를 사용할 수 있습니다. 하지만 동시 변경은 자동 merge되지 않고 일부 작업은 Owner 전용입니다. 큰 편집을 조율하고 version history를 rollback에 활용하세요.
Connector Action Constraints가 민감 데이터 반환도 차단하나요?
지원 action의 사용 방법을 제한하지만 허용된 action의 전체 반환 데이터를 필터링하지는 않습니다. least privilege, 좁은 scope, audience 통제, 승인, 데이터 검토가 함께 필요합니다.
첫 Agent로 어떤 업무가 적합한가요?
반복되고, 출처가 알려져 있고, 검토 가능한 초안을 만들며, 사람 owner와 간단한 rollback이 있는 내부 업무입니다. 외부 발송, 전체 메일, 되돌릴 수 없는 DB 쓰기부터 시작하지 마세요.
결론
Workspace Agents의 가치는 모든 일을 자율화하는 데 있지 않습니다. 팀의 반복 업무를 공유하고, 권한을 나누고, 검증하고, 실패 시 복구 가능한 실행으로 만드는 데 있습니다. 먼저 workspace와 역할을 확인하고, 하나의 좁은 업무를 Preview에서 안정화하며, 위험한 쓰기에는 승인을 유지하세요. ChatGPT 경로가 예측 가능하고 owner, log, stop rule, rollback이 준비된 뒤에만 Slack, schedule, API, 그룹 공유, 더 넓은 connector로 단계적으로 확장하는 것이 안전합니다.
