오픈AI, 팀이 자체적으로 작업할 수 있는 커스텀 봇 개발 허용

OpenAI가 Business, Enterprise, Edu, Teachers 플랜 사용자를 대상으로 ChatGPT 내에서 동작하는 클라우드 기반 "workspace" 에이전트를 공개했다. 이 에이전트는 단순 질의응답을 넘어 실제 업무를 자율적으로 수행하는 형태로, 내부적으로는 LLM을 코어로 하되 브라우저 자동화, API 호출, 외부 도구 연동(Slack, Gmail 등)을 결합한 툴 유즈(tool-use) 기반 아키텍처로 구성된다. 사용자는 자연어로 목표(goal)와 작업 흐름을 정의하고, 에이전트는 계획 수립(planning) → 도구 호출(action) → 관찰(observation) → 재계획(re-planning)의 ReAct 루프를 반복하며 웹에서 제품 피드백을 수집해 Slack으로 리포트를 보내거나, Gmail에서 세일즈 팔로업 메일 초안을 작성하는 식의 복합 태스크를 처리한다. 클라우드 기반이라는 점이 핵심인데, 이는 로컬 브라우저가 필요했던 기존 Operator류 에이전트와 달리 서버 측 가상 환경에서 장시간 실행되는 백그라운드 워크로드로 에이전트를 운영할 수 있음을 의미한다.

개발자 입장에서 이 변화는 "AI 애플리케이션" 개발 패러다임이 챗봇/코파일럿에서 자율 에이전트 오케스트레이션으로 빠르게 이동하고 있음을 보여주는 신호다. 특히 OpenClaw(前 Clawdbot/Moltbot)의 바이럴과 그 창립자 Peter Steinberger의 OpenAI 합류 사실은, 시장이 "대답하는 AI"보다 "실행하는 AI"에 훨씬 더 큰 가치를 부여하고 있으며 OpenAI 역시 이 방향에 인재와 자원을 집중 투입하고 있음을 시사한다. 실무적으로는 사내 CRM 업데이트, 로그 분석 후 Jira 티켓 생성, 경쟁사 모니터링 리포트 생성 같은 반복 업무를 커스텀 에이전트로 대체할 수 있으며, 이는 RPA와 LLM의 경계가 사실상 사라지는 지점으로 해석된다. 한국의 엔지니어링 조직도 Notion, Jira, Slack, Gmail 등 SaaS 중심 워크플로우를 운영 중이라면 단순한 프롬프트 자동화 이상의 ROI를 기대할 수 있다.

개발자가 당장 점검해야 할 포인트는 세 가지다. 첫째, **보안과 권한 경계**다. 에이전트가 Gmail 초안 작성, Slack 메시지 발송, 웹 자동화 같은 실제 사이드이펙트를 수반하는 액션을 수행하므로, OAuth 스코프를 최소 권한 원칙(PoLP)으로 제한하고 "send"가 아닌 "draft" 단계에서 human-in-the-loop 승인 게이트를 넣는 설계가 필수다. 프롬프트 인젝션을 통한 권한 탈취(웹 페이지에 숨겨진 지시문으로 에이전트를 하이재킹하는 공격 벡터)도 이미 보고되어 있어, 신뢰할 수 없는 소스의 콘텐츠와 도구 호출을 분리하는 격리 구조가 필요하다. 둘째, **관찰 가능성(observability)**이다. 자율 에이전트는 실패 모드가 비결정적이므로 LangSmith, Langfuse, OpenTelemetry GenAI Semantic Conventions 같은 추적 도구로 각 스텝의 입력/출력/도구 호출을 기록해야 디버깅과 회귀 테스트가 가능하다.

셋째, **벤더 종속성과 아키텍처 선택**이다. OpenAI의 workspace 에이전트는 폐쇄형 플랫폼 위에서 동작하므로, 민감 데이터 처리나 온프레미스 요구가 있는 조직이라면 동일한 기능을 LangGraph, CrewAI, AutoGen 같은 오픈소스 프레임워크 + Claude/Gemini 같은 대체 LLM 조합으로 구현하는 하이브리드 전략을 검토할 필요가 있다. 또한 에이전트 간 표준 통신 프로토콜로 부상 중인 MCP(Model Context Protocol)와 Agent2Agent 스펙을 지금 학습해두면, 특정 벤더의 에이전트 스토어에 갇히지 않고 포터블한 툴 서버를 구축할 수 있다. 단기적으로는 "내 팀의 가장 지루한 반복 업무 하나"를 파일럿으로 잡아 평가셋을 구축하고, 정확도·비용·latency·실패율을 수치화한 뒤 확장 여부를 판단하는 접근이 현실적이다.