워크스페이스 에이전트 만들고 공유하기
왜 개인 자동화에서 멈추면 안 되나
섹션 제목: “왜 개인 자동화에서 멈추면 안 되나”앞 챕터까지의 스킬과 예약 작업은 결국 내 것이다. 내 워크스페이스에 설치되고, 내가 만든 프롬프트로 돈다. 그런데 조직에서 중요한 워크플로는 대개 혼자 하는 일이 아니다. 공유된 맥락, 사람 사이의 인계, 팀을 넘나드는 의사결정에 달려 있다.
워크스페이스 에이전트(workspace agents)는 이 지점을 겨냥한다. 공식 발표문의 표현을 빌리면, 팀이 복잡한 작업과 오래 걸리는 워크플로를 처리하는 공유 에이전트를 만들 수 있고, 그 에이전트는 조직이 정한 권한과 통제 안에서 동작한다. 한 번 만들어 ChatGPT나 Slack에서 함께 쓰고, 시간이 지나며 개선한다.
에이전트의 해부도
섹션 제목: “에이전트의 해부도”넓게 보면 에이전트는 세 가지 구성 요소로 작업을 수행하는 시스템이다. 트리거, 특화된 스킬을 포함할 수 있는 프로세스, 그리고 연결할 수 있는 도구나 시스템.
| 구성 요소 | 무엇인가 | 예시 |
|---|---|---|
| 트리거(trigger) | 에이전트를 시작시키는 것 | 일정(“매 평일 오전 9시”) 또는 수동 실행(“지금 실행”) |
| 프로세스와 스킬 | 기대한 방식으로 작업을 완료하기 위해 따르는 단계 | 입력 검토, 빠진 정보 확인, 결과물 초안 작성, 인계 또는 다음 동작 |
| 도구와 시스템 | 정보를 모으고, 허용되면 동작을 취하기 위해 쓸 수 있는 승인된 도구와 통합 | Slack, CRM, 사내 문서, 티켓 시스템, 공유 문서 |
에이전트가 맞는 일과 아닌 일
섹션 제목: “에이전트가 맞는 일과 아닌 일”에이전트가 가장 쓸모 있는 조건은 네 가지다.
- 반복적(repeatable): 같은 작업이 주기적으로 생긴다.
- 구조적(structured): 결과물의 형식이 분명하다. 그래서 잘하고 있는지 판단할 수 있다.
- 시간 기반 또는 이벤트 기반: 정해진 주기로 돌거나 이벤트로 촉발된다.
- 도구 기반(tool-based): 팀이 쓰는 시스템에서 읽거나 쓰는 일이 필요하다.
반대로 열린 사고, 브레인스토밍, 탐색적 글쓰기에는 일반 대화가 대체로 더 낫다. 특히 한 번만 하는 작업이라면 그렇다. 에이전트를 만드는 데 드는 시간이 회수되지 않는다.
결정적이지 않고 확률적이다
섹션 제목: “결정적이지 않고 확률적이다”과거에 만들어 본 API 워크플로와 에이전트는 다르다. 다른 도구의 전통적 워크플로는 흔히 결정적(deterministic) 이다. 각 단계가 명시적으로 정의되고, 로직을 바꾸지 않으면 시스템은 매번 같은 경로를 따른다.
에이전트는 더 확률적(probabilistic) 이다. 여전히 지시와 도구와 가드레일 안에서 동작하지만, 모델을 써서 맥락을 해석하고 범위 안에서 판단하며 작업을 진행하는 방식을 조정한다.
| 구분 | 결정적 워크플로 | 에이전트 |
|---|---|---|
| 경로 | 매번 같다 | 맥락에 따라 조정된다 |
| 예외 처리 | 미리 정의한 분기만 | 지시 범위 안에서 판단 |
| 바꾸는 방법 | 로직을 수정 | 지시와 가드레일을 수정 |
| 검증 방법 | 입력·출력 대조 | 여러 사례로 반복 테스트 |
이 차이의 실무적 의미: 테스트를 한 번만 하면 안 된다. 깔끔한 입력뿐 아니라 맥락이 빠지거나 모호한 지저분한 입력으로도 돌려 봐야 한다.
설계표: 다섯 칸으로 나눠 적기
섹션 제목: “설계표: 다섯 칸으로 나눠 적기”에이전트를 설계하는 좋은 방법은 사람에게 일을 넘길 때 확인하는 것들을 그대로 적어 보는 것이다. 무엇을 책임지는가, 언제 시작해야 하는가, 무엇이 멈추게 만드는가, 어떤 도구와 정보를 쓸 수 있는가, 어떤 절차를 따라야 하는가, 어떤 규칙 안에 있어야 하는가.
Academy가 제시한 세 가지 예시를 표로 옮기면 다음과 같다.
| 항목 | 마케팅 캠페인 요약 에이전트 | 제품 피드백 분류 에이전트 | 영업 파이프라인 요약 에이전트 |
|---|---|---|---|
| 목표(objective) | 캠페인 성과를 분석하고 최적화를 제안 | 새 제품 피드백을 요약해 올바른 담당자에게 전달 | 파이프라인 변화를 감시하고 위험과 기회를 강조 |
| 트리거(trigger) | 매주 월요일 오전 10시 | Slack의 폼 제출 | 매 평일 오전 8시 |
| 프로세스(process) | KPI 수집, 추세 파악, 요약 초안, 다음 단계 제안, 담당자 배정 | 피드백 검토, 관련 항목 묶기, 핵심 주제 요약, 후속 담당자 제안 | 파이프라인 검토, 위험 표시, 다음 단계 제안 |
| 도구(tools) | 분석 도구, 공유 요약 문서 | Slack, 티켓 시스템, 요약 문서 | CRM, 이메일 또는 Slack, 파이프라인 트래커 |
| 거버넌스(governance) | 제안은 초안으로. 예산 변경 전 승인 필요 | 초안 티켓 생성. 높은 우선순위는 에스컬레이션. 제출 전 승인 필요 | 통찰과 제안은 초안으로. 담당자에게 알림. 승인 없이 직접 연락 금지 |
마지막 행이 가장 중요하다. 어디서 멈추고 누구에게 넘길지를 정하지 않은 에이전트는 공유할 수 없다.
다섯 가지 워크플로 패턴
섹션 제목: “다섯 가지 워크플로 패턴”팀과 직무를 가로질러 반복적으로 나타나는 패턴이 있다. 도구와 데이터와 산출물은 달라도 밑에 깔린 패턴은 일정하다.
| 패턴 | 동작 방식 | 예시 |
|---|---|---|
| 브리핑(briefing) | 여러 곳에서 정보를 모아 압축해 의사결정 가능한 형태로 포장 | 영업: CRM·통화·Slack·뉴스로 계정 브리핑. 마케팅: 캠페인·경쟁사 요약. 임원: 일간 산업 브리프 |
| 분류와 라우팅(triage and routing) | 들어온 항목을 처리해 올바른 다음 단계로 보냄 | 지원: 피드백을 버그·기능 요청·후속으로 전환. IT/운영: Slack의 사내 요청을 긴급도로 분류. 채용: 인바운드 후보 선별 |
| 분석과 제안(analysis and recommendation) | 데이터나 근거를 해석해 관점을 세우고 첫 결과물로 만듦 | 재무: 예산 대비 실적 정합 후 메모 초안. 제품/리서치: 사용자 피드백 분석과 우선순위 제안. 구매: 견적 비교와 결정 매트릭스 |
| 콘텐츠 제작(content creation) | 콘텐츠를 만들거나 갱신한 뒤 특정 독자·채널에 맞게 조정 | 마케팅: 브리프를 캠페인 자산으로. 관리자: 메모를 온보딩 계획으로. 영업: 후속 메일, QBR 요약 |
| 계획과 조율(planning and coordination) | 목표를 예정된 작업과 시스템 갱신으로 전환 | PM: 작업 블록·미팅 예약·트래커 갱신. 이벤트: 오프사이트·등록·출장 조율. 어드민: 폼·알림·주문·예약 관리 |
각 패턴의 절차는 네 단계로 정리된다. 예를 들어 브리핑은 입력 수집 → 비교와 핵심 신호 추출 → 독자에 맞춘 요약 → 문서·메모·브리핑으로 공유다.
만드는 4단계
섹션 제목: “만드는 4단계”사이드바의 Agents 를 열고 팀이 자주 하는 워크플로를 설명하면, ChatGPT가 단계별로 안내해 에이전트로 바꿔 준다. 재무·영업·마케팅 등을 위한 템플릿으로 빠르게 시작할 수도 있다. 템플릿에는 내장 스킬과 추천 도구가 함께 들어 있다.
1) 평문으로 시작한다. 에이전트 빌더 대화에서 이 에이전트가 할 일, 성공한 결과가 어떤 모습인지, 따라야 할 제약을 설명한다. 빌더가 이를 단계가 정의된 명확한 워크플로로 번역해 주고, 대화에서 계속 다듬거나 워크플로와 지시를 직접 편집할 수 있다.
2) 도구와 커넥터를 고른다. 워크플로를 완료하는 데 쓸 수 있는 승인된 앱을 선택한다. 접근이 필요한 시스템을 말로 설명하면 빌더가 추가와 인증 과정을 안내한다.
3) 트리거를 정한다. 워크스페이스 에이전트의 트리거는 사람이 촉발하는 방식(누군가 무엇을 해 달라고 요청)이거나 일정으로 촉발되는 방식(정해진 시각에 실행)일 수 있다. 이것도 빌더 대화에서 평문으로 설정한다.
4) 가드레일을 넣는다. 경계, 필수 승인, 민감한 동작에 대한 사람 개입 체크포인트를 설정한다. 빌더 대화에 바로 적으면 빌더가 지시를 수정한다.
미리보기로 테스트하고 고치기
섹션 제목: “미리보기로 테스트하고 고치기”에이전트 만들기는 반복 과정으로 접근할 때 가장 잘 된다. 테스트하면서 대화를 통해 무슨 일이 일어났는지 이해하고, 문제를 찾고, 지시를 단계적으로 다듬는다.
현실적인 예시 몇 개로 시작하되, 깔끔한 요청과 지저분한 요청을 섞으세요. 맥락이 빠졌거나 모호한 요청까지 넣어야 에이전트가 어떻게 행동하는지, 어디에 더 명확한 지시나 가드레일이 필요한지 보인다.
첫 버전이 완벽하지 않은 것은 예상된 일이다. 개선하는 방법은 두 가지다.
| 방법 | 언제 쓰나 |
|---|---|
| 지시를 직접 수정 | 문제가 분명할 때. 단계를 명확히 하거나 출력 형식을 조정하거나 제약을 추가 |
| 자연어로 코칭 | 문제가 덜 분명할 때. 빌더 대화에서 무엇을 놓쳤는지 지적하거나 왜 그렇게 판단했는지 설명하게 해 지시의 빈틈을 드러낸다 |
바꾼 뒤에는 다시 테스트해서 반영됐는지 확인한다.
[프로젝트/업무명] 을 위한 에이전트를 만들려고 합니다.
목표: [예: 매주 캠페인 성과를 요약하고 최적화 제안을 초안으로 만든다]트리거: [예: 매주 월요일 오전 10시]프로세스: 1) [입력 수집] 2) [비교·분석] 3) [초안 작성] 4) [담당자 배정]필요한 도구: [예: 분석 도구, 공유 요약 문서]가드레일: 제안은 초안까지만. 예산이나 설정을 직접 바꾸지 않는다. 승인 없이 외부로 발송하지 않는다. 근거가 부족한 제안은 "검증 필요"로 표시한다.
먼저 워크플로 단계를 정리해서 보여 주고, 제가 말하지 않아 추측으로 채운 부분을 알려 주세요.처음 만든 에이전트는 바로 공유하지 말고, 실제 입력을 흉내 낸 저위험 사례로 경계가 지켜지는지 확인한다.
[에이전트 이름]의 미리보기 테스트를 준비해 주세요.
입력: [현실적인 예시 입력]확인할 점:- 사용하도록 지정한 [도구 또는 자료]만 참조하는가- 사실, 가정, 제안을 구분하는가- 정보가 부족하면 추측 대신 "확인 필요"로 남기는가- 외부 발송·레코드 변경·공유는 하지 않고 초안에서 멈추는가
결과와 함께 각 확인 항목의 통과 여부, 접근하지 못한 자료, 다음에 고칠 가드레일을 표로 보여 주세요.팀으로 확장하기
섹션 제목: “팀으로 확장하기”워크스페이스 에이전트는 공유되고 반복되는 작업을 위해 설계됐다. 에이전트를 공유하면 팀이 매번 절차를 다시 발명하는 대신 일관된 방식으로 작업을 완료한다.
공유할 때는 무엇을 위한 것인지 명시하세요. 설명에 처리하는 작업, 언제 쓰는지, 어떤 입력을 주어야 하는지, 어떤 결과물을 기대할 수 있는지를 넣는다. 공유 에이전트는 팀이 이미 이해하고 있는 구체적이고 반복되는 워크플로에 묶여 있을 때 가장 잘 동작한다. 예시 프롬프트 한두 개를 함께 넣으면 다른 사람이 시작하기 쉬워진다.
에이전트는 ChatGPT와 Slack에서 쓸 수 있다. Slack에 배치하면 요청이 들어오는 대로 받아 처리한다.
공유한 뒤에는 분석 정보로 사용 현황을 볼 수 있다. 완료한 실행 횟수와 사용 인원이 포함된다.
“에이전트를 만드는 데서 어려운 부분은 모델이 아니다. 통합, 메모리, 사용자 경험이다. 워크스페이스 에이전트가 그 작업을 압축해 줘서, 우리 세일즈 컨설턴트 한 명이 엔지니어링 팀 없이 Sales Opportunity 에이전트를 처음부터 끝까지 만들고 평가하고 개선했다. 계정을 조사하고, 통화 내용을 요약하고, 딜 브리프를 팀 Slack 방에 바로 올린다. 담당자들이 주당 5~6시간 쓰던 일이 이제 모든 딜에서 백그라운드로 자동 실행된다.”
Ankur Bhatt, AI Engineering, Rippling (출처: openai.com/index/introducing-workspace-agents-in-chatgpt)
통제와 관리자 권한
섹션 제목: “통제와 관리자 권한”에이전트에 일을 위임해도 통제권은 내게 남는다. 어떤 도구와 데이터를 쓸 수 있는지, 어떤 동작을 할 수 있는지, 언제 승인이 필요한지 내가 정한다. 스프레드시트 편집, 메일 발송, 캘린더 일정 추가처럼 민감한 단계에는 진행 전 허락을 받도록 요구할 수 있다.
조직 차원의 통제는 다음과 같다.
- 역할 기반 접근 제어(RBAC): 관리자가 누가 에이전트를 만들고 쓸 수 있는지, 그 에이전트가 어떤 도구·앱·동작에 접근할 수 있는지 통제한다.
- 감사 로그와 모니터링: 에이전트 활동을 추적하고 로그를 검토해 무엇을 했고 워크플로가 어떻게 실행됐는지 파악한다.
- 민감한 동작의 승인 게이트: 메시지 발송이나 레코드 갱신 전에 사람의 승인을 요구한다.
- 중앙 관리: 에이전트·권한·통합을 중앙 관리 콘솔에서 관리한다.
ChatGPT Enterprise와 Edu 관리자는 사용자 그룹이 접근할 수 있는 연결 도구와 동작을 통제할 수 있고, 누가 에이전트를 쓰고 만들고 공유할지 관리할 수 있다. 오해를 유발하는 외부 콘텐츠(프롬프트 인젝션 포함)를 만났을 때 에이전트가 지시에 맞게 동작하도록 돕는 내장 안전장치도 있다. Compliance API는 모든 에이전트의 구성·업데이트·실행에 대한 가시성을 제공하며, 관리자는 필요하면 에이전트를 정지시킬 수 있다.
가용성: 리서치 프리뷰이고 플랜 제약이 있다
워크스페이스 에이전트는 ChatGPT Business, Enterprise, Edu, Teachers 플랜에서 리서치 프리뷰로 제공된다. Enterprise와 Edu 플랜에서는 관리자가 역할 기반 통제로 에이전트 접근을 켤 수 있다. ChatGPT Enterprise에서 에이전트를 만들 수 있는 권한 자체가 워크스페이스 관리자의 통제 아래 있다.
발표 시점(2026년 4월 22일) 기준으로 워크스페이스 에이전트는 2026년 5월 6일까지 무료였고, 그 날짜부터 크레딧 기반 과금이 시작됐다. 기능은 플랜·플랫폼·지역· 롤아웃·워크스페이스 설정에 따라 다르므로 현재 조건은 관리자에게 확인하세요.
또한 워크스페이스 에이전트는 GPT의 발전형으로 소개됐다. 팀이 워크플로로 테스트하는 동안 GPT는 계속 제공된다고 안내돼 있다.
주의점
섹션 제목: “주의점”- 잘 만든 에이전트도 사람의 판단이 필요하다. 넓은 맥락, 작업의 중요도, 좋은 답이 어떤 모습인지는 대개 내가 안다.
- 남이 만든 에이전트는 저위험 요청부터. 무엇을 잘하도록 설계됐는지, 어떤 도구에 의존하는지, 어떤 결과물을 내는지 먼저 파악한다.
- 팀원의 권한을 확인하세요. 관리자가 RBAC로 커넥터와 기능 접근을 관리하므로, Slack이나 Gmail 같은 시스템을 쓰려면 팀원에게 알맞은 권한이 있어야 한다.
- 거버넌스 없이 공유하지 마세요. 어디서 멈추고 누구에게 에스컬레이션할지를 설명에 명시한다.
- 에이전트는 트리거, 프로세스(+스킬), 도구·시스템의 세 부분으로 이루어진다.
- 반복적·구조적·시간이나 이벤트 기반·도구 기반 업무에 맞고, 탐색적 작업에는 일반 대화가 낫다.
- 결정적 워크플로와 달리 확률적이므로 지저분한 입력까지 포함해 반복 테스트한다.
- 목표·트리거·프로세스·도구·거버넌스 다섯 칸으로 설계표를 먼저 채운다.
- 평문 설명 → 도구 선택 → 트리거 → 가드레일 순서로 만들고, 미리보기로 다듬어 공유한다.
- 관리자는 RBAC, 감사 로그, 승인 게이트, 중앙 관리로 통제한다.
여기까지 자동화 섹션이다. 다음 섹션에서는 만든 결과물을 팀이 실제로 쓸 수 있게 내보내는 Sites를 다룬다.
이해도 점검
섹션 제목: “이해도 점검”퀴즈를 불러오는 중…