개인용 AI 에이전트는 대체로 “내가 방금 요청한 일”을 잘 처리하면 만족도가 높다. 하지만 팀이 함께 쓰는 에이전트는 다르다. 누가 마지막으로 작업했는지, 어떤 정책으로 움직여야 하는지, 어떤 도구는 열려 있고 어떤 단계는 승인 전까지만 허용되는지까지 알아야 한다. 그래서 shared workspace agents라는 말이 중요해진다. 핵심은 여러 사람이 같은 에이전트를 쓴다는 사실이 아니라, 같은 업무 상태와 권한 경계를 공유하는 운영 구조가 필요하다는 점이다.
이 글은 메인 허브 글 에이전트 레디 업무 환경이란 무엇인가: 컨텍스트·제어 흐름·승인·MCP까지 한 번에 정리에서 다룬 첫 번째 층을 확장한 내용이다. 질문은 단순하다. 팀 문서, 작업 상태, 승인 이력, 도구 권한이 흩어져 있을 때 왜 공유 에이전트는 금방 흔들릴까? 그리고 이를 막으려면 워크스페이스 허브를 어떻게 설계해야 할까?
shared workspace agents가 개인용 에이전트와 다른 이유
개인용 에이전트는 사용자의 머릿속 맥락을 암묵적으로 기대해도 어느 정도 작동한다. 부족한 정보가 있으면 사용자가 바로 다시 설명하면 되기 때문이다. 반면 팀용 에이전트는 그 방식으로 운영할 수 없다. 사람이 바뀌고, 실행 시점이 분리되며, 승인 주체와 작성 주체가 다를 수 있기 때문이다.
그래서 공유 에이전트는 다음 네 가지를 외부 상태로 가져야 한다.
- 팀이 합의한 운영 규칙
- 현재 작업이 어느 단계에 있는지 보여 주는 상태
- 누가 승인할 수 있는지에 대한 권한 구조
- 어떤 도구가 언제 노출되는지에 대한 정책
이 중 하나라도 빠지면 에이전트는 개인의 편의 기능처럼 남는다. 예를 들어 블로그 발행 자동화에서 초안을 잘 써도, 이미 큐에 들어간 run을 다시 처리하거나 승인 없이 외부 발행을 시도하면 팀 단위 운영에는 바로 문제가 된다.
워크스페이스 허브는 문서 저장소가 아니라 상태 기준점이다
많은 팀이 워크스페이스를 단순히 문서 모음으로 이해한다. 하지만 공유 에이전트에게 더 중요한 것은 “여기가 기준 상태다”라고 말할 수 있는 장소다. 문서, 할 일, 최근 결정, 예외 규칙, 진행 중인 작업이 한 흐름으로 이어져야 에이전트도 일관된 판단을 할 수 있다.
실무적으로는 아래 세 종류의 정보가 한 허브에서 만나는 편이 좋다.
- 정책: 이 팀이 지키는 기본 제약과 승인 규칙
- 상태: 지금 어떤 작업이 어디까지 왔는지
- 근거: 왜 그 결정을 내렸는지 확인할 수 있는 링크와 이력
이렇게 보면 shared workspace agents는 단순한 채팅방 공유 기능이 아니다. 에이전트가 일을 이어받기 위한 업무 좌표계를 공유하는 구조다.
문서 공유보다 중요한 것은 권한 공유의 해상도다
공유 에이전트를 설계할 때 흔히 문서 접근성부터 챙기지만, 실제로 더 까다로운 것은 권한이다. 모든 팀원이 같은 문서를 보더라도 모든 팀원이 같은 액션을 승인하거나 실행할 필요는 없다. 오히려 이 경계가 흐리면 에이전트가 누구를 기준으로 행동해야 할지 모호해진다.
따라서 권한은 “접근 가능/불가능”의 이분법보다 단계별 해상도로 다루는 편이 낫다.
- 읽기 권한: 문서, 로그, 히스토리를 누구까지 볼 수 있는가
- 수정 권한: 초안, 워크플로, 설정 변경을 누가 만질 수 있는가
- 승인 권한: 외부 발행, 배포, 브랜치 반영 같은 고위험 액션을 누가 승인하는가
공유 에이전트는 이 권한 구조를 직접 이해하기보다, 허브가 그 구조를 반영한 상태를 읽는 방식이 더 안정적이다. 즉 에이전트에게 사람 조직도를 길게 설명하는 대신, “이 단계는 승인 대기”, “이 단계는 초안 작성 가능”처럼 상태로 번역해 주는 편이 좋다.
작업 상태를 남기지 않으면 공유가 아니라 중복 실행이 된다
팀용 에이전트에서 가장 흔한 실패는 누군가의 작업을 다른 누군가가 모르는 상태에서 다시 수행하는 것이다. 에이전트도 마찬가지다. 한 번 생성한 초안을 또 만들고, 이미 처리된 티켓을 다시 열고, 큐에 넣은 작업을 중복 enqueue하는 현상은 대부분 상태 기록 부족에서 나온다.
그래서 shared workspace agents에는 최소한 다음 상태가 남아야 한다.
- 현재 작업 ID 또는 run 식별자
- 마지막 처리 단계
- 대기 중인 승인 또는 외부 응답
- 이미 끝난 쓰기 작업 여부
이 네 가지가 있으면 사람도, 에이전트도 같은 질문에 같은 답을 찾기 쉬워진다. 반대로 채팅 로그만 남기면 누가 무엇을 했는지 읽어야 하고, 재개 비용이 커진다.
공유 에이전트는 도구를 공용으로 주기보다 역할별로 나눠야 한다
워크스페이스를 공유한다고 해서 도구까지 모두 공통으로 열어 두는 것은 좋은 기본값이 아니다. 공유 에이전트일수록 역할별 분리가 더 중요하다. 리서치 담당 에이전트, 초안 작성 에이전트, 발행 에이전트가 모두 같은 도구를 보면, 작업 경로는 더 흔들리고 승인 기준은 더 흐려진다.
가장 실용적인 시작점은 역할별 최소 세트다.
- 리서치 역할: 검색, 문서 조회, 기록 확인
- 작성 역할: 초안 생성, 제한된 수정, 내부 링크 정리
- 발행 역할: 파일 반영, 브랜치 생성 대기, 승인 직전 체크
이 구조는 최근 에이전트 허브형 워크스페이스 설계법: 승인, 도구, 맥락을 한곳에서 운영하는 기준과 MCP 도구 노출 최소화 가이드: 에이전트 허브에서 도구를 적게 보여줄수록 안정적인 이유에서 강조한 원칙과도 맞닿아 있다. 공유는 중앙화이지, 전면 개방이 아니다.
한국 팀이 바로 적용할 워크스페이스 공유 에이전트 체크리스트
- 에이전트가 읽을 팀 정책과 예외 규칙이 한곳에 정리되어 있는가.
- 현재 작업 상태가 채팅이 아니라 구조화된 필드나 문서로 남는가.
- 읽기, 수정, 승인 권한이 같은 사람에게 묶여 있지 않은가.
- 에이전트 역할별로 도구 노출 범위가 나뉘어 있는가.
- 사람이 바뀌어도 다음 담당자가 같은 상태를 바로 이해할 수 있는가.
- 승인 대기, 실패 재시도, 완료 상태가 같은 용어로 기록되는가.
shared workspace agents의 핵심은 “팀이 같이 쓰는 AI”가 아니다. 팀의 업무 상태를 누가 이어받아도 같은 기준으로 해석할 수 있게 만드는 운영 구조다. 이 구조가 없으면 공유 에이전트는 곧 채팅 사용자가 많은 개인 에이전트로 남는다. 반대로 허브, 권한, 상태를 먼저 정리하면 에이전트 수가 늘어도 팀의 통제력은 오히려 좋아진다.