Claude Code에 개발을 맡기고, Codex에 검토를 요청한 뒤, 조사 담당 에이전트의 자료를 다시 복사해 붙여 넣는다. 에이전트는 여러 개지만 대화와 결과물이 흩어져 있으면 사람이 계속 중간 전달자가 된다. OpenAgents Workspace는 이렇게 분산된 사람과 AI 에이전트를 하나의 협업 공간에 연결하려는 도구다.
여기서 말하는 OpenAgents는 openagents.org의 OpenAgents Workspace다. OpenAI Agents SDK나 비슷한 이름의 개인 비서·코딩 도구와는 다른 프로젝트다. 공식 유튜브 소개 영상과 웹 문서를 바탕으로 무엇을 연결하고, 어떻게 협업하며, 도입 전에 무엇을 확인해야 하는지 살펴보자.
OpenAgents Workspace는 새로운 AI 모델보다 ‘함께 일하는 공간’에 가깝다
공식 문서는 OpenAgents를 사람과 AI 에이전트가 같은 대화·파일·작업을 중심으로 협업하는 플랫폼으로 소개한다. 여러 에이전트를 한 화면에서 보는 것에 그치지 않고, 한 스레드에서 요청을 나누고 결과를 검토하는 데 초점이 있다.
Claude Code·Codex·OpenClaw처럼 이미 사용하는 에이전트를 연결할 수 있다. 각 에이전트의 실행 환경을 유지하면서, Workspace가 메시지와 공유 자료, 업무의 흐름을 연결하는 구조다. 모든 에이전트를 새로운 단일 모델로 바꾸는 제품은 아니다.
공식 소개 영상은 Claude Code가 코드를 작성하고, Codex가 그림을 넘기고, OpenClaw가 빌드를 살피는 협업 장면을 보여준다. 이는 제품의 사용 흐름을 설명하는 시연이며, 모든 작업이 같은 속도나 품질로 완료된다는 독립적인 성능 시험은 아니다.
영상은 2026년 8월의 Workspace 1.0 소개다. 현재 공식 제품 페이지는 v1.1을 안내하고 있으므로, 영상의 화면과 최신 기능 이름이 다를 수 있다. 이 글은 2026년 10월 28일 확인한 공식 문서를 함께 기준으로 삼았다.
Workspace와 Launcher는 같은 역할이 아니다
처음 살펴볼 때 가장 헷갈리기 쉬운 것은 협업 공간과 에이전트 실행 도구의 차이다.
Workspace: 대화와 자료, 진행 상황이 모이는 곳
Workspace는 브라우저에서 여는 협업 공간이다. 공식 안내에는 Threads, Files, Knowledge, Browser, Tasks, Workflows, Routines, Inbox 등의 기능이 소개돼 있다. 최신 v1.1 제품 페이지는 Issues와 공유·승인 제어도 강조한다.
사람이 요청을 남기고, 에이전트가 결과를 전달하고, 검토 담당자가 피드백을 남기는 자리가 Workspace다. 웹뿐 아니라 데스크톱과 모바일에서 접근하는 흐름도 제공한다.
Launcher: 에이전트를 실행하고 공간에 연결하는 쪽
Launcher는 내 컴퓨터에서 에이전트를 설치·설정·실행하고 Workspace에 연결하는 도구다. 원격 서버를 연결하는 CLI 방식도 안내된다. 로컬 파일을 다루는 에이전트가 필요하다면 어디서 실행되고 어떤 폴더에 접근할지 설정해야 한다.
반대로 공식 문서는 설치 없이 시작하는 Cloud Agent 경로도 소개한다. 따라서 Workspace를 사용하려면 모든 사람이 반드시 같은 데스크톱 앱부터 설치해야 하는 것은 아니다. 클라우드 에이전트로 시작할지, 내 PC나 서버의 에이전트를 연결할지를 먼저 정하면 구성이 명확해진다.
이 구분은 실행 지속성에도 중요하다. 휴대전화에서 Workspace에 접속할 수 있다고 해서 꺼진 노트북의 로컬 에이전트가 계속 일하는 것은 아니다. 장시간 작업하려면 연결한 컴퓨터·서버와 에이전트 프로세스, 모델 서비스가 계속 사용 가능해야 한다.
시작 흐름: 공간 만들기보다 ‘연결 후 첫 응답’까지 확인한다
최신 공식 시작 문서는 로그인 기반의 호스팅 서비스를 안내한다. 기본 흐름은 다음과 같다.
- 로그인하고 Workspace 열기: 공식 사이트에서 계정으로 들어가 자신의 작업 공간을 연다.
- 실행 위치 선택하기: Cloud Agent, 로컬 컴퓨터, 원격 서버 중 어디에서 에이전트를 실행할지 결정한다.
- 장치 또는 에이전트 연결하기: Connect Agent나 데스크톱의 연결 화면을 통해 필요한 절차를 진행한다.
- 인증과 모델 설정 완료하기: 연결한 에이전트의 제공자 로그인·API 설정을 확인한다.
- Threads에서 작은 요청 보내기: 실제 응답과 파일 접근·결과 전달까지 확인한다.
예를 들어 처음에는 민감하지 않은 문서 하나를 공유하고 “이 문서의 핵심과 확인이 필요한 항목을 나눠 달라”고 요청할 수 있다. 연결 상태가 온라인으로 보이는 것과 실제 모델 호출·파일 작업이 성공하는 것은 다르므로, 첫 결과를 확인하는 단계가 필요하다.
제품 README나 초기 영상에는 계정 없이 시작하는 설명이 남아 있을 수 있다. 이 글의 시작 순서는 현재 공식 온보딩 문서를 기준으로 한다. 설치한 버전이나 자체 호스팅 방식에 따라 인증 흐름이 다르면 해당 가이드를 확인해야 한다.
이 글을 작성하면서 사용자의 PC에 OpenAgents를 설치하거나 외부 Workspace를 생성·연결하지는 않았다. 공식 영상과 문서를 대조한 가이드이며, 별도 환경에서 설치를 재현한 사용기는 아니다.
Threads·Files·Knowledge: 대화와 자료를 연결하는 기본 단위
공식 문서에서 Threads는 사람과 에이전트가 함께 참여하는 지속적인 대화다. 에이전트가 스레드의 이전 내용을 참고하고, 다른 담당자의 결과를 이어받는 방식으로 설명된다.
@claude처럼 대상을 지정해 요청하거나, 여러 담당자에게 역할을 나눌 수 있다. 다만 실제 사용할 이름은 자신의 Workspace에 연결된 에이전트 목록에서 확인해야 한다. 이름만 입력했다고 존재하지 않는 에이전트가 자동으로 준비되는 것은 아니다.
자료는 용도에 따라 구분해 두는 편이 좋다.
- Threads: 진행 중인 요청, 질문, 판단과 결과 논의.
- Files: 업무에 필요한 문서와 에이전트가 생성한 산출물.
- Knowledge: 여러 대화에서 다시 사용할 프로젝트 배경·규칙·결정 사항.
- Inbox: 완료 알림이나 예약 작업 결과처럼 나중에 확인할 소식.
프로젝트의 최신 용어와 작성 기준을 Knowledge에 정리하고, 개별 과업의 초안을 Files로 주고받으면 매번 긴 설명을 붙이는 일을 줄일 수 있다. 다만 공유한 문서가 최신이고 정확한지는 별도로 관리해야 한다. 여러 에이전트가 같은 잘못된 자료를 참고하면 오류도 함께 확산될 수 있다.
공식 소개 영상은 팀원을 초대하고 사람과 에이전트가 같은 대화에서 일하는 흐름도 보여준다. 이는 사람이 빠지는 자동화보다, 필요한 순간에 사람이 판단을 보태는 협업 구조로 이해하는 편이 적절하다.
협업 방식은 ‘여러 명 호출’보다 역할과 순서를 정하는 문제다
공식 협업 문서에는 다음과 같은 모드가 소개된다.
- Dynamic: 메시지에 따라 다음에 응답할 에이전트를 라우터가 선택하는 방식.
- Master / sub-agents: 스레드의 리더가 요청을 받고 다른 담당자에게 나눠 맡기는 방식.
- Workflow: 저장한 단계에 따라 업무를 진행하는 방식.
최신 v1.1 제품 안내는 proactive·passive 응답 선택과 실행 담당자·검토 담당자의 역할 구분도 설명한다. 문서와 제품 화면의 용어가 다를 수 있으므로, 현재 버전의 스레드 설정을 확인하는 것이 좋다.
중요한 것은 모드 이름보다 실제 업무의 책임이다. 단순히 “다 같이 알아서 해줘”라고 요청하기보다 누가 초안을 만들고, 누가 어떤 기준으로 검토하며, 무엇을 사람에게 보고할지 정하는 편이 낫다.
예를 들어 개발 작업은 다음처럼 나눌 수 있다. 아래는 공식 데모를 그대로 재현한 결과가 아니라 적용 예시다.
- 실행 담당자가 변경 범위와 구현안을 제안한다.
- 검토 담당자가 요구사항·권한·오류 가능성을 확인한다.
- 실행 담당자가 승인된 범위만 수정하고 테스트 결과를 남긴다.
- 사람이 변경 내용과 미확인 항목을 검토한 뒤 병합·배포 여부를 결정한다.
에이전트끼리 긍정적인 답을 주고받았다는 사실은 검증 완료와 다르다. 최종 결과는 실제 변경 파일과 테스트 기록, 근거 문서로 확인해야 한다.
Tasks·Issues·Workflows·Routines는 무엇을 나눠 관리할까
대화만으로 업무를 관리하면 요청이 어디까지 진행됐는지 놓치기 쉽다. 공식 문서는 상태를 추적할 작업 보드, 단계형 자동화와 예약 실행을 별도로 안내한다.
Tasks와 Issues: 담당과 진행 상태 추적
소개 영상과 문서는 작업의 대기·진행·완료 상태를 보여준다. 최신 v1.1 안내의 Issues는 담당자·참여자·라벨·논의를 스레드와 자료에 연결하는 기능으로 소개된다.
이런 기능은 “대화에서 요청했다”와 “누가 끝까지 맡아 처리한다”를 구분하는 데 활용할 수 있다. 다만 완료 카드만 보고 실제 산출물이 존재하고 요구사항을 충족하는지 확인하는 절차를 생략해서는 안 된다.
Workflows: 반복할 업무의 단계 연결
Workflows는 여러 단계를 연결하는 자동화다. 공식 영상에는 에이전트의 초안, 사람의 검토, 다른 담당자의 후속 작업을 잇는 화면이 등장한다. 매번 같은 순서로 진행하는 보고서나 검토 업무에 적용할 수 있는 구조다.
자동화 단계에는 성공 경로만 두기보다 자료 부족·검토 반려·실행 실패 때 어디서 멈추고 누구에게 알려야 하는지도 정하는 것이 좋다.
Routines: 정해진 시점에 반복 실행
Routines는 정해진 일정에 작업을 실행하고 결과를 대화나 Inbox로 받는 기능이다. 예를 들어 평일마다 고객 피드백을 요약하거나, 정기적으로 자료를 확인하는 업무를 생각해 볼 수 있다.
영상의 ‘24/7’ 표현은 예약 실행의 방향을 보여주는 홍보 문구로 읽어야 한다. 실제 실행은 연결 상태·서버 가동·모델 한도·작업 설정에 영향을 받는다. 무한 무료 실행이나 중단 없는 운영이 보장된다는 뜻은 아니다.
연구·보고서 업무에는 어떻게 적용할 수 있을까
개발 외에도 자료 수집·검토·집필처럼 역할이 나뉘는 업무를 적용 대상으로 생각해 볼 수 있다. 다음은 이 글의 실무 제안이며, 해당 조직에서 효과를 검증한 사례는 아니다.
- 조사 담당: 공식 원문과 날짜, 인용 가능한 근거를 정리한다.
- 검토 담당: 출처 누락·오래된 자료·상충하는 수치를 확인한다.
- 집필 담당: 검토한 자료를 바탕으로 초안을 작성한다.
- 사람: 사실과 해석, 공개 가능한 범위를 확인하고 최종 승인한다.
Workspace에는 요청과 결과, 공유 자료를 모으고, 다음 업무에서도 쓸 작성 규칙은 Knowledge에 남길 수 있다. 이때 수집 담당의 요약을 원문으로 착각하지 않도록 출처 링크와 확인 범위를 함께 보관하는 것이 좋다.
처음부터 많은 에이전트를 연결하기보다, 초안 담당과 검토 담당처럼 작은 조합으로 시작해 전달 누락과 검토 시간을 확인하는 편이 현실적이다. 협업 도구가 추가될수록 사람이 이해해야 할 변경과 판단도 늘 수 있기 때문이다.
도입 전에 확인할 권한·데이터·비용
로컬 실행과 데이터의 로컬 보관은 다른 이야기다
공식 보안 안내는 로컬 에이전트의 코드 실행이 자신의 컴퓨터에서 이뤄진다고 설명한다. 동시에 호스팅 서버에는 메시지·에이전트 응답·관련 메타데이터가 저장된다고 안내한다. 사용자가 공유한 파일과 대화 내용도 서비스 이용 방식에 맞춰 검토해야 한다.
따라서 “에이전트가 로컬에서 실행된다”를 “모든 정보가 내 PC 밖으로 나가지 않는다”로 바꿔 읽으면 안 된다. 모델에 보낼 내용, Workspace에 올릴 자료, 외부 공유 대상을 구분해야 한다.
공식 메시징 문서는 대화의 공개 스냅샷 링크도 안내한다. 공유 링크를 만들기 전에는 비밀정보·고객 자료·내부 의사결정이 포함돼 있지 않은지 확인하는 편이 좋다.
팀 공유와 에이전트 실행 권한을 따로 확인한다
최신 v1.1 안내는 에이전트·장치의 기본 비공개와 접근 권한 부여, 에이전트 사용이나 행동에 대한 승인을 강조한다. 같은 Workspace에 초대했다고 모든 장치와 에이전트의 권한이 일괄 공유된다고 가정해서는 안 된다.
반대로 화면에서 접근 권한을 나눴다는 사실만으로 실행 중인 에이전트가 운영체제 수준에서 격리됐다고 볼 수도 없다. 연결한 런타임의 파일·셸 권한과 승인 정책까지 확인해야 한다. 지원 목록에 이름이 있는 에이전트도 일부는 Beta이거나 실제 모델 연동 검증이 진행 중이므로 동일한 검증 수준으로 취급하지 않는다.
무료 시작과 전체 운영비를 구분한다
공식 사이트는 무료로 시작할 수 있다고 안내하지만, 모델 API·기존 에이전트 구독·원격 서버·브라우저 등의 비용은 별도로 확인해야 한다. 클라우드 에이전트에 제공하는 키와 로컬 Launcher에서 사용하는 키의 처리 경로도 구분해서 검토한다.
오픈소스 플랫폼이라는 사실은 연결한 모든 모델과 외부 서비스까지 무료라는 뜻이 아니다. 반복 작업을 켜기 전에는 실행 빈도와 실패 시 재시도·알림 방식을 정해 두는 편이 좋다.
자체 호스팅도 외부 전송을 자동 차단하지 않는다
OpenAgents는 Apache 2.0 기반의 자체 호스팅을 안내한다. 협업 서버와 데이터를 자신의 인프라에서 관리하려는 조직이 검토할 수 있는 선택지다.
다만 서버를 직접 운영해도 외부 모델 API나 다른 외부 서비스를 사용하면 관련 정보가 전달될 수 있다. 자체 호스팅과 폐쇄망 운영, 모델의 로컬 실행을 같은 것으로 취급하지 말고 데이터 흐름을 따로 설계해야 한다.
어떤 경우에 검토할 만할까
여러 에이전트와 사람이 같은 자료를 보고, 초안과 검토를 주고받고, 반복 업무를 추적해야 한다면 OpenAgents Workspace의 구조를 살펴볼 만하다. 반대로 혼자 단순한 질문을 처리하거나 에이전트 한 개로 끝나는 업무라면 협업 플랫폼이 불필요한 관리 단계를 더할 수도 있다.
핵심 판단 기준은 연결 가능한 도구 수보다 자료와 결과가 덜 흩어지는지, 누가 무엇을 승인하는지 명확해지는지, 실제 산출물을 검증하기 쉬워지는지다. 작은 비공개 과업으로 시작해 이 조건을 확인한 뒤 적용 범위를 늘리는 것이 좋다.
함께 읽으면 좋은 글
FAQ
OpenAgents Workspace와 OpenAI Agents SDK는 같은 것인가요?
아니다. 이 글의 대상은 openagents.org의 협업 플랫폼이다. OpenAI Agents SDK와 이름이 비슷하지만 별도 프로젝트이며, 기존 에이전트들을 연결해 사람과 함께 일하는 공간에 초점을 둔다.
Workspace를 쓰려면 Launcher도 반드시 설치해야 하나요?
항상 그렇지는 않다. 공식 문서는 Cloud Agent로 시작하는 방법을 안내한다. 내 PC의 파일을 다루는 로컬 에이전트나 원격 장치를 연결하려면 Launcher·CLI 등 해당 연결 경로를 확인해야 한다.
PC를 꺼도 예약 작업은 계속 실행되나요?
꺼진 PC의 로컬 에이전트는 계속 실행될 수 없다. 예약을 유지하려면 에이전트가 실행되는 서버나 장치와 모델 서비스가 사용 가능해야 한다. Workspace에 접속 가능한 것과 에이전트가 가동 중인 것은 별개다.
자체 호스팅하면 모든 데이터가 외부로 나가지 않나요?
자동으로 그렇게 되지는 않는다. Workspace 서버를 직접 관리하는 것과 모델·외부 서비스에 전달되는 데이터를 통제하는 것은 다른 문제다. 사용하는 모델과 연결 도구까지 포함해 경로를 확인해야 한다.
참고자료
- OpenAgents 공식 Workspace 1.0 소개 영상
- OpenAgents Workspace 제품 안내
- 공식 개요: Workspace와 Launcher
- 공식 Workspace 시작 가이드
- 공식 Threads·파일·Knowledge 안내
- 공식 에이전트 협업·작업·예약 실행 안내
- 공식 보안·데이터 안내
- 공식 자체 호스팅 안내
- OpenAgents 공식 GitHub 저장소
본문 이미지는 공식 소개 영상의 기능과 시연을 설명·비평하기 위한 캡처다. 영상 시연과 최신 문서, 이 글의 적용 제안을 구분했다. 별도의 설치 재현·성능 시험·보안 감사를 완료했다는 뜻은 아니다.