Workspace Agents는 GPTs와 뭐가 다를까 2026 – 팀 권한·승인·로그 운영표

Posted on by

2026년 4월 22일 OpenAI가 ChatGPT에 workspace agents를 공개했어.

이게 딱 한 줄로 요약하면 이런 느낌이야.

“GPTs는 개인이 쓰기 좋은 똑똑한 템플릿이고, workspace agents는 팀이 굴리기 좋은 ‘업무 실행자’에 가깝다.”

근데… 이름만 보면 둘 다 그냥 “에이전트”잖아.

그래서 팀에선 이런 일이 벌어져.

“어차피 GPTs랑 비슷한 거면, 우리도 하나 만들어서 전사 공유하면 되지 않음?”

여기서부터 사고가 시작된다.

개인 도구를 팀 시스템으로 착각하는 순간, 권한과 승인과 로그가 너를 찾아온다.

그리고 그 친구들은 보통 밤에 찾아온다.

보통은 배포 3일차, 슬랙이 가장 바쁠 때, 그리고 누군가가 “자동으로 보내버리면 편할 듯”을 말한 직후.

오늘은 뉴스요약 말고, 운영 얘기만 할 거야.

팀 권한, 승인 게이트, 감사 로그, Slack/도구 연결, 그리고 “장기 실행/스케줄”까지.

직접 써본 후기는 아직 못 적는 부분이 있어.

나는 지금 이 글 쓰는 시점에 workspace agents를 직접 프로덕션에서 굴려본 건 아니거든.

그래서 UI 세부나 실제 설정 흐름 같은 건, 본문에서 공식 발표 기준 추정이라고 표시할게.

대신, OpenAI 공식 발표(2026-04-22)에서 말한 “무슨 문제를 풀려고 만든 건지”를 기준으로, 팀이 당장 쓸 수 있는 운영표로 정리해볼게.

도입부 요약(헤더 없이):

GPTs = 개인/소그룹에 유리한 “잘 만든 프롬프트+툴 구성”.

Workspace agents = 팀 운영을 전제로 한 “권한/승인/감사/스케줄/배포(예: Slack)까지 포함한 실행체”.

먼저, OpenAI가 ‘Workspace Agents’를 뭐라고 말했는지

공식 발표에서 OpenAI는 workspace agents를 이렇게 설명해.

  1. 팀이 공유해서 쓰는 에이전트
  2. 복잡한 작업과 장기 워크플로를 처리
  3. 조직이 설정한 권한/승인/가시성(감사/모니터링) 안에서 동작
  4. 스케줄로 돌리거나 Slack에 배치해서 “흐름 속에서” 일을 받게 할 수 있음

여기서 포인트는 “성능”이 아니야.

“운영”이야.

그리고 이 운영은, 그냥 체크박스 몇 개로 끝나는 게 아니라, 진짜로 팀 책임과 리스크를 바꿔.

GPTs vs Workspace Agents: 차이를 ‘기능’이 아니라 ‘운영 레이어’로 보면 선명해져

GPTs를 설명할 때 사람들이 자꾸 “프롬프트 템플릿”이라고만 부르는 이유가 있어.

실제로 많이들 그렇게 쓰니까.

근데 팀에서 문제 되는 건, GPTs 자체가 나쁘다기보다, 다음이 섞일 때야.

  1. 팀 데이터
  2. 팀 도구(슬랙, 티켓, 문서, 캘린더, CRM)
  3. “누가 승인했는지”가 중요한 액션(메시지 발송, 기록 수정, 일정 생성)
  4. 실행이 한 번으로 안 끝나는 장기 작업(매주/매일 돌리는 루틴)

이 네 개가 섞이면, 그 순간부터 “그냥 GPT 하나 공유”는 운영 부채가 된다.

workspace agents는 그 부채를 “제품 기능으로” 흡수하려는 움직임으로 보이더라.

(이건 내 해석인데, 공식 발표가 계속 governance/visibility/approval 쪽을 강조하는 걸 보면 방향이 보여.)

운영표 1: 누가 뭘 할 수 있나 (권한/RBAC)

팀에서 제일 먼저 터지는 질문:

“이거 누가 만들 수 있어?”

“누가 공유할 수 있어?”

“누가 실행할 수 있어?”

“누가 로그 볼 수 있어?”

이 질문이 문서로 정리돼 있으면, 도입은 쉬워져.

정리 안 돼 있으면, 도입은 ‘빠르게’ 될 수는 있는데, 나중에 ‘더 빠르게’ 무너져.

아래는 내가 추천하는 최소 RBAC 운영표야.

OpenAI Business 페이지는 workspace agents가 role-based access control을 제공하고, 누가 만들고 쓰는지, 어떤 툴/액션 접근이 가능한지 통제할 수 있다고 말해.

역할 만들기 수정/배포 실행 승인(Approve) 로그/감사 보기 추천 인원
Admin O O O O O 1~3
Agent Owner(업무 오너) O O O (업무에 따라) O(범위 제한) 업무당 1
Builder(제작자) O (제한) O X X 필요 시
Runner(사용자) X X O X X 다수
Approver(승인자) X X (선택) O (선택) 1~N
Auditor/Compliance X X X X O 1~N

여기서 핵심은 이거야.

“만드는 사람”과 “승인하는 사람”과 “감사하는 사람”을 가능하면 분리해.

다 같은 사람이면, 편하긴 한데, 그건 운영이 아니라 ‘개인 프로젝트’가 되거든.

운영표 2: 승인 게이트(Approval Gates) 설계

OpenAI는 민감 액션에 대해 “승인 게이트”를 강조해.

예를 들면 이런 것들.

  • 메시지 보내기
  • 기록 업데이트(스프레드시트/CRM 등)
  • 일정 추가

이건 “AI가 멍청할까봐”라기보다, “사람이 책임질 액션을 자동으로 저질러버릴까봐”가 더 크지.

승인 게이트는 꼭 이렇게 설계해.

  1. 승인 대상 액션을 명확히 분류
  2. 승인 요청에는 “무엇/왜/어디에/어떤 변경”이 들어가게 강제
  3. 승인 없이 실행되면 안 되는 액션은 반드시 막기
  4. 승인 지연/거절이 쌓일 때 운영자가 병목을 볼 수 있게 하기

내가 추천하는 승인 게이트 분류표:

액션 분류 예시 기본 정책 이유
읽기(Read) 문서 검색, 티켓 조회 자동 허용 리스크 낮음
요약/분석 보고서 초안, 주간 요약 자동 허용 결과는 사람이 최종 사용
“초안 생성” 쓰기 문서 초안, 답변 초안 자동 허용(저장 위치 제한) 초안은 되돌리기 쉬움
커뮤니케이션 발송 Slack DM, 이메일 발송 승인 필수 실수 1번이 평판/관계에 직격
레코드 변경 CRM 필드 수정, 티켓 상태 변경 승인 필수(혹은 제한적 자동) 데이터 무결성
돈/권한 관련 결제, 계정 권한 변경 승인+추가 정책 한 번이면 끝

여기서 “제한적 자동”은 뭐냐면, 예를 들면 이런 거야.

티켓 라벨 붙이기.

담당자 후보 추천하기.

스레드에 “정보 더 필요함” 코멘트 달기.

이런 건 자동으로 해도 팀에 도움이 돼.

근데 “상태를 Closed로 바꾸기”는 승인이 있어야 마음이 편하더라.

운영표 3: 로그/감사(감사 로그, 모니터링, Compliance API)

OpenAI Business 페이지는 workspace agents에 audit logs and monitoring이 있고, 공식 발표는 Compliance API로 에이전트의 구성/업데이트/실행(run)에 대한 가시성을 준다고 말해.

이 부분이 GPTs와 가장 “회사다움” 차이가 난다고 봐.

팀에서 로그는 2종류가 있어.

  1. 운영 로그(디버깅)
  2. 감사 로그(책임)

운영 로그는 “왜 실패했는지” 보는 거고, 감사 로그는 “누가/언제/무엇을” 했는지 보는 거야.

그리고 팀이 커질수록, 감사 로그가 더 중요해져.

“누가 승인했지?” 질문이 “언젠가”가 아니라 “매주” 나오거든.

추천 로그 스키마(너희 팀 내부 운영 기준):

항목 예시 꼭 필요? 이유
run_id 2026-04-23T09:00Z-abc O 추적 단위
agent_version v12 O 설정 바뀌면 결과가 달라짐
trigger schedule / Slack / manual O 재현성
input_summary “주간 KPI 보고” O 개인정보/민감정보 최소화
tools_used Jira, Slack O 연결 리스크
actions_attempted “post to #ops” O 실제 행위
approval_requested true/false O 통제 여부
approval_result approved/denied/timeout O 책임
output_location doc 링크 O 결과 확인
error_class auth / rate_limit O 운영
cost_signal credits_used(추정) (가능하면) 비용 폭주 감지

여기서 “cost_signal”은 아직 정확한 형태가 제품마다 다를 수 있어.

그래서 이 항목은 공식 발표 기준 추정이야.

근데 “비용 로깅” 자체는 무조건 필요해.

왜냐면 자동화는 성공하면 더 돌리고 싶어지고, 더 돌리면 더 비싸지거든.

GPTs가 “나쁜 선택”은 아니야: 둘을 이렇게 나눠 쓰면 된다

내 기준으로는 이렇게 구분해.

GPTs가 좋은 경우:

  • 개인 생산성(글 초안, 요약, 아이디어, 코드 스니펫)
  • 팀 공유가 있더라도 “읽기/초안” 중심
  • 실행 액션이 거의 없음
  • 로그/승인이 크게 필요 없는 영역

Workspace agents가 좋은 경우:

  • 팀 프로세스가 있고 반복이 많음
  • “실행”이 포함됨(툴 액션, 메시지, 업데이트)
  • 장기 실행(여러 단계)이나 스케줄 운영이 핵심
  • 관리자 통제(RBAC, 감사 로그, 승인 게이트)가 필요

즉, GPTs는 “개인용/경량 공유” 쪽이 강하고, workspace agents는 “팀 운영/거버넌스” 쪽이 강하다고 보는 게 이해가 쉬워.

공식 발표에서도 workspace agents를 “GPTs의 진화”라고 부르면서, 곧 GPTs를 workspace agents로 변환하기 쉽게 만들겠다고 말하더라.

이 말은 곧, 둘이 공존하다가 워크스페이스 레이어로 수렴할 가능성이 크다는 뜻이기도 해.

Slack/도구 연결: “편한 통로”이자 “사고 통로”

공식 발표는 workspace agents를 Slack에 배치(deploy)해서 요청을 바로 받게 할 수 있다고 말해.

이게 왜 중요하냐면, 업무는 “앱 안”이 아니라 “대화 흐름”에서 시작하거든.

근데 Slack 배치는, 좋은 점이랑 위험이 같이 와.

좋은 점:

  • 요청이 자연스럽게 들어옴
  • 팀이 채팅에서 바로 결과를 봄
  • 실행/승인도 흐름에서 이어질 수 있음

위험:

  • 권한이 섞이면, DM 한 줄로 큰 액션이 나갈 수 있음
  • 프롬프트 인젝션 같은 “외부 컨텐츠 속임수”가 섞이기 쉬움
  • 실수했을 때 전파가 빠름(슬랙은 팀의 확성기임)

OpenAI는 prompt injection 같은 공격에 대한 보호를 언급해.

근데 이건 “완벽히 막아준다”가 아니라, 운영자가 “위험한 경로를 닫을 수 있게” 만들어준다는 뉘앙스에 가까워.

그래서 Slack에 붙일 때는 승인 게이트랑 로그가 더 중요해져.

장기 실행/스케줄: 여기서부터는 ‘프롬프트’가 아니라 ‘운영’이 됨

OpenAI Business 페이지는 workspace agents가 스케줄로 반복 작업을 돌릴 수 있다고 말해.

그리고 공식 발표도 “계속 일하게 할 수 있다”는 걸 강조해.

스케줄이 들어오면, 바로 운영 포인트가 생겨.

  1. 실패했을 때 재시도 정책
  2. 중복 실행(같은 작업 두 번) 방지
  3. 결과 저장 위치(어디에 남기지?)
  4. 비용 폭주 방지(무한 루프를 막아야 함)

이건 사람도 똑같이 겪는 문제야.

주간 보고 자동화하려고 매주 금요일에 돌렸는데, 어느 날부터 데이터 소스가 바뀌어서 수치가 이상해졌다.

사람이면 눈치채고 “이번 주는 수동”으로 멈추는데, 자동화는 그런 거 없지.

계속 돌려.

조용히, 성실하게, 그리고 틀린 채로.

그래서 스케줄 에이전트 운영은 “정확도”보다 “멈출 줄 아는지”가 더 중요할 때가 많아.

워크플로 설계 예시 1: “주간 지표 보고” 에이전트

이건 공식 발표에서도 예시로 나오는 케이스랑 비슷해.

스케줄 기반으로 매주 반복.

근데 운영은 이렇게 잡아야 해.

흐름

  1. 금요일 17:00 트리거(스케줄)
  2. 데이터 수집(읽기 권한)
  3. 차트/표 생성(코드 실행 또는 문서 생성)
  4. 보고서 초안 작성

  5. ops 채널에 “초안 링크 + 요약” 게시(승인 게이트)

승인 포인트

  • 5번(게시)은 승인 필수

왜냐면…

초안이 이상하면 그건 단순한 오타가 아니라, 팀 전체의 판단을 흔들 수 있거든.

워크플로 설계 예시 2: “IT 요청 트리아지” 에이전트

공식 발표는 IT 티켓 라우팅/승인/정책 준수 같은 예시를 든다.

이런 건 진짜 팀 운영에 잘 맞아.

왜냐면 규칙이 존재하니까.

흐름

  1. Slack #it-requests로 요청 들어옴
  2. 템플릿 검사(필수 정보 있는지)
  3. 정책 위반/예외 여부 체크
  4. 티켓 생성(승인 게이트)
  5. 담당자 추천(자동)
  6. 요청자에게 “다음 액션” 안내(자동)

승인 포인트

  • 티켓 생성은 조직마다 다르지만,
    최소한 “특정 시스템 변경 티켓”은 승인 필수로 두는 걸 추천해.

실패 모드

  • 권한 없음(auth)
  • 필수 정보 누락(요청자가 템플릿 무시)
  • 정책 문서가 오래됨(에이전트가 구버전 기준으로 판단)

이 실패 모드가 “보이면” 괜찮아.

문제는 “안 보이는 상태로” 계속 돌 때야.

그래서 로그가 필요해.

워크플로 설계 예시 3: “Slack Q&A + 티켓 생성” 에이전트

공식 발표에 “제품 팀이 Slack에서 직원 질문에 답하고, 필요하면 티켓을 만든다”는 사례가 있어.

이건 체감 임팩트가 크지.

사람들이 매번 물어보는 것들.

VPN.

빌드 실패.

권한 요청.

온보딩.

그런데 여기서 운영 포인트:

질문에 답하는 건 자동으로 해도, 티켓 생성은 승인 게이트로 둬야 “남발”을 막을 수 있어.

티켓은 만들기 쉽고, 지우기는 어렵거든.

비용(크레딧) 얘기: 자동화는 ‘잘 되면’ 돈이 된다

공식 발표에 따르면 workspace agents는 2026년 5월 6일까지는 무료이고, 그 이후에는 credit 기반 과금이 시작된다고 되어 있어.

여기서 운영 팁 하나:

“무료 기간에 폭주시키는 건” 팀을 망치기 딱 좋아.

왜냐면 무료일 때 만든 습관이, 유료로 바뀌어도 계속 남아있거든.

그래서 무료 기간부터 이렇게 해.

  1. 스케줄 실행 횟수 제한
  2. Slack 트리거는 채널/키워드 제한
  3. 실행 시간 초과(타임아웃) 기준
  4. 툴 액션 허용 범위 좁게
  5. 월간 비용 상한선(조직 정책) 문서화

정확한 크레딧 단가나 계산식은, 내가 이 글 쓰는 시점에서 제품 상세에 따라 달라질 수 있어서 여기서는 추정하지 않을게.

그 대신, “비용을 측정할 수 있는 구조”부터 설계하자.

“언제 안 써도 되는지”가 제일 중요하다

TECHTAEK는 이 얘기 없으면 안 돼.

workspace agents가 멋있어 보이는 순간, 사람들은 거의 자동 반사로 이렇게 말해.

“우리도 다 에이전트로 바꾸자.”

아니야.

다 바꾸면, 너는 이제 개발자가 아니라, 에이전트 운영팀이 된다.

(축하한다. 이제 너도 회사의 회사가 됐다.)

아래 조건이면 그냥 GPTs가 더 나아.

  • 결과가 “초안”이면 충분한 작업
  • 툴 액션이 거의 없는 작업
  • 승인/감사 필요성이 낮은 작업
  • 스케줄 운영이 필요 없는 작업
  • 실패했을 때 피해가 작은 작업

아래 조건이면 workspace agents를 고민할 가치가 커.

  • 팀마다 반복되는 프로세스가 있고,
    그걸 문서로 정의할 수 있음
  • 승인 게이트가 필요한 액션이 있음
  • 로그/감사 요구가 있음(특히 Enterprise/Edu 느낌)
  • Slack 같은 “업무 흐름”에서 바로 처리하고 싶음
  • 장기 실행(멀티 스텝)이나 스케줄이 중요함

결론은 이거야.

워크스페이스 에이전트는 “기능”이 아니라 “조직 운영 선택”이야.

운영 체크리스트(30분 컷)

팀이 바로 쓸 수 있게 체크리스트로 줄게.

이거 30분만 해도, 도입 실패 확률이 눈에 띄게 떨어져.

  1. 에이전트의 “업무 범위”를 한 문장으로 정의했다
  2. 입력 채널(스케줄/Slack/수동)을 정했다
  3. 결과 저장 위치를 정했다(문서/티켓/스레드 링크)
  4. 승인 게이트가 필요한 액션을 분류했다
  5. 승인자가 누구인지 정했다(부재 시 대체 포함)
  6. 로그에 남길 최소 항목을 정했다(run_id, version, trigger, action, approval)
  7. 실패했을 때 멈추는 기준을 정했다(연속 실패 N회 등)
  8. 비용 시그널을 볼 대시보드/리포트 경로를 정했다
  9. “이거 GPTs로도 되나?”를 한 번 자문했다

여기서 9번이 제일 중요해.

대부분의 자동화 과잉은, 기술이 아니라 욕심 때문에 생기거든.

실수 TOP 5 (실전에서 터질 법한 것들)

1) 승인 게이트를 “나중에” 붙이겠다는 약속

나중은 안 와.

오면 이미 늦어.

첫 배포부터 붙여.

2) Slack에 바로 붙이고 싶어서 권한을 넓게 준다

권한은 넓히기 쉬운데, 좁히면 사람들 불편해한다.

그러니까 초반에는 좁게, 필요할 때 넓혀.

3) 로그를 “디버깅용”으로만 생각한다

팀에서 중요한 건 책임 로그야.

특히 승인/액션이 있는 자동화는 감사 로그 없으면 운영이 아니라 도박이 된다.

4) 스케줄 에이전트에 “중복 방지”가 없다

스케줄은 언젠가 겹친다.

시간대.

지연.

재시도.

다 겹쳐.

그래서 결과 저장은 idempotent하게(중복에 안전하게) 설계해야 해.

이건 제품 기능이 어느 정도 도와줘도, 업무 설계에서 한 번 더 막아야 한다.

(공식 발표 기준 추정: 제품이 중복 방지를 자동으로 완전히 처리해준다고 보긴 어려움)

5) 무료 기간에 “실험”이 아니라 “의존”을 만든다

무료는 실험해야지, 의존 만들면 안 돼.

의존이 생기면, 유료로 바뀌는 순간부터 팀이 비용에 끌려다닌다.

관련 글

FAQ

Q1. Workspace agents는 GPTs를 대체하는 거야?

공식 발표 기준으로는 “대체”라기보다 “진화 + 공존”에 가까워.

GPTs는 그대로 유지한다고 했고, 곧 GPTs를 workspace agents로 변환하기 쉽게 만들겠다고도 했어.

즉, 당분간은 둘 다 있을 가능성이 크고, 팀 운영이 필요해지면 workspace agents 쪽으로 이동하는 그림이야.

Q2. 어떤 플랜에서 쓸 수 있어?

공식 발표/Business 페이지 기준으로 ChatGPT Business, Enterprise, Edu, Teachers 플랜에서 research preview로 제공된다고 되어 있어.

Q3. “승인 게이트”는 어디에 걸어야 제일 효과적이야?

메시지 발송, 레코드 변경, 캘린더/권한/돈 관련 액션.

이 세 종류는 기본 승인으로 두는 걸 추천해.

초안 생성이나 읽기 작업은 자동으로 열어두는 게 팀 속도에 도움 돼.

Q4. Slack에 붙이면 제일 큰 리스크가 뭐야?

확산 속도.

실수 한 번이 “조용히” 끝나지 않을 수 있어.

그래서 Slack 배치는 권한 최소화 + 승인 게이트 + 감사 로그가 세트로 가야 해.

Q5. 장기 실행/스케줄이 들어가면 뭐가 달라져?

작업이 “요청-응답”에서 “운영-감시”로 바뀌어.

실패가 누적될 수 있고, 중복 실행이 발생할 수 있고, 비용이 눈덩이처럼 커질 수 있어.

그래서 스케줄은 멈춤 기준, 재시도 정책, 비용 시그널 이 세 가지를 먼저 박아두는 게 좋아.

Q6. “감사 로그”를 어느 수준까지 남겨야 해?

최소한 누가/언제/어떤 버전이/어떤 트리거로/어떤 액션을 했고/승인이 있었는지.

개인정보나 민감 데이터는 요약으로 줄이고, 원문은 내부 규정에 맞는 저장소로 관리하는 게 안전해.

Compliance API 같은 조직 가시성 도구를 언급하는 걸 보면, OpenAI도 “운영/감사 요구”를 제품 레벨에서 풀려는 방향이야.

Q7. 그럼 오늘 당장 팀에 도입하려면 1번 에이전트로 뭘 추천해?

“주간 지표 보고 초안”이나 “IT 요청 트리아지” 같은 반복 작업이면서 규칙이 명확한 것.

그리고 첫 버전은 ‘초안 + 승인’까지로만 가.

완전 자동 실행은, 팀이 로그/승인/실패 대응을 한 번이라도 겪은 뒤에 해도 늦지 않아.

공식 출처

아래는 이 글에서 사실 근거로 삼은 OpenAI 공식 페이지야.

  1. Introducing workspace agents in ChatGPT (2026-04-22)
  2. https://openai.com/index/introducing-workspace-agents-in-chatgpt/
  3. OpenAI Business: Workspace agents for business
  4. https://openai.com/business/workspace-agents/
  5. OpenAI Academy: Workspace agents (2026-04-22)
  6. https://openai.com/academy/workspace-agents/
  7. OpenAI Academy 홈
  8. https://openai.com/academy/

추가로, ChatGPT Business 워크스페이스/플랜 관련 기본 설명은 Help Center 문서들도 참고 가능해.