Claude Cowork와 업무 에이전트 플랫폼 거버넌스 설계

에이전트의 진입점이 달라지면서 생긴 운영 과제

Anthropic은 2026년 1월 Claude Cowork를 macOS 리서치 프리뷰로 공개했다. 4월에는 macOS·Windows 정식 출시로 이어졌고, 7월에는 웹·모바일까지 범위가 넓어졌다. 같은 에이전트 엔진을 쓰더라도 Claude Code는 저장소에서 커밋을 만들고, Cowork는 문서 폴더와 업무 앱을 다루며 보고서와 스프레드시트를 만든다.

이 차이는 조직의 질문을 바꾼다. 에이전트를 도입할지보다, 어느 사용자 계층에 어떤 진입점을 제공할지 결정하는 일이 앞선다.

2025년까지 에이전트 구축은 대체로 개발자의 일이었다. API 키를 발급받고 SDK로 실행 루프를 구성하며, 도구 정의를 JSON 스키마로 작성하고 실행 환경을 샌드박싱해야 했다. 자동화 범위는 개발팀의 처리량에 묶였고, 업무를 가장 잘 아는 담당자는 요구사항을 전달하는 역할에 남기 쉬웠다.

Cowork에서는 사용자가 폴더를 선택하고 결과물을 자연어로 요청한다. Claude는 요청을 분석해 계획을 세우고 필요하면 하위 작업으로 나누며, Anthropic 서버의 격리 환경에서 코드와 셸 명령을 실행한다. 반복 업무는 한 번 서술해 두면 정해진 주기로 실행할 수 있고, Gmail·Google Drive·Notion·Slack·Microsoft 365·DocuSign·FactSet 등을 포함한 38종 이상의 커넥터를 연결할 수 있다.

자동화 작성자가 늘어나는 만큼 통제 지점은 약해질 수 있다. 개발자 중심 환경에서는 코드 리뷰와 배포 파이프라인이 통제 역할을 했지만, 현업 담당자가 개인 계정으로 커넥터를 연결하고 스케줄 작업을 만들면 같은 방식으로 관리하기 어렵다. Anthropic이 2026년에 조직·사용자 단위 지출 한도와 알림, 모델 기본값과 권한(엔터타이틀먼트), Compliance API·Admin API·Analytics API를 제공하고, 4월에는 샌드박싱·장기 세션·상태 관리·도구 실행·오류 복구·추적을 대행하는 Claude Managed Agents를 공개 베타로 선보인 배경도 여기에 있다. VentureBeat가 다음 엔터프라이즈 경쟁을 모델이 아니라 에이전트 컨트롤 플레인으로 본 이유와 맞닿아 있다.

사용자 영향 범위에 따라 진입점을 나눈다

사용자 계층과 진입점을 먼저 고정해야 한다. 실무에서는 다음과 같이 구분할 수 있다.

소비자 계층은 승인된 에이전트와 스킬을 사용하지만 새 자동화를 만들지는 않는다. 구성자 계층은 플랫폼 UI에서 스킬·커넥터·스케줄을 조합해 자신의 업무를 자동화하며 코드를 작성하지 않는다. 제작자 계층은 SDK와 MCP 서버를 구현해 여러 팀이 쓰는 공용 도구를 공급한다.

구분 기준은 기술 숙련도가 아니라 결과물이 미치는 범위다. 개인 폴더 안에서 끝나는 업무는 구성자 계층이 처리할 수 있다. 하지만 사내 시스템의 상태를 바꾸거나 외부로 결과가 나가는 작업이라면 제작자 계층이 만든 검증된 도구를 통과하게 해야 한다. 이 경계가 불명확하면 감사 범위만 계속 커진다.

⤢✕

플랫폼 UI와 SDK를 가르는 업무 특성

실행 빈도가 낮고 입력이 매번 달라지며 사람이 결과를 즉시 검토하는 업무에는 플랫폼 UI가 어울린다. 반대로 입력 스키마가 고정돼 있고 실행 빈도가 높으며, 결과가 다른 시스템의 입력으로 자동 전달되는 업무라면 SDK가 적합하다.

판단이 모호한 업무는 플랫폼에서 시작해 사용 데이터를 모으는 편이 낫다. 실행 횟수와 실패율이 임계치를 넘으면 코드 자산으로 승격한다. 처음부터 SDK로 구현하면 폐기율이 높아질 수 있고, 플랫폼에만 계속 두면 재현성과 테스트가 무너질 수 있다.

SDK는 오케스트레이션과 권한을 세밀하게 제어할 수 있고 자체 인프라에서도 실행할 수 있다. 대신 초기 구축과 유지보수 비용이 크며 변경에는 배포 주기가 수반된다. 플랫폼 UI는 아이디어를 동작으로 옮기는 시간이 짧아 시행착오 비용을 낮추지만, 분기·예외 처리·재시도 같은 제어 구조를 표현하는 데 한계가 있고 버전 관리와 테스트 자동화도 약하다. 개발 속도는 플랫폼이, 장기 유연성은 SDK가 우위라는 구도는 당분간 유지될 전망이다.

저코드 접근은 참여자를 크게 늘리지만 비용과 성능의 오버헤드를 없애지는 않는다. 범용 플랫폼은 필요 이상으로 넓은 컨텍스트를 모델에 넣고 도구 호출 횟수도 보수적으로 늘리는 경향이 있어, 직접 구현보다 같은 결과에 더 많은 토큰과 시간이 들 수 있다. 저빈도 업무에서는 사람 시간 절감에 묻히지만, 고빈도 업무에서는 비용으로 드러난다. 월 실행 횟수와 건당 비용을 곱한 값이 개발자 유지보수 공수를 넘는 시점이 코드로 옮길 시점이다.

표준 자산과 팀별 워크플로의 경계

Cowork 생태계에서는 커넥터가 연결을 맡고, 스킬이 명령을 담당하며, 워크플로가 실행 순서를 조정한다. 이 구분은 조직의 표준화 경계를 정하는 데도 쓸 수 있다.

조직이 중앙에서 관리할 대상은 커넥터 목록과 인증 방식, 사내 문서 서식·톤앤매너·보고서 템플릿·용어집 같은 전사 공통 스킬이다. 팀은 이 기반 위에서 업무별 워크플로를 조합한다. 표준 자산이 바뀌면 팀별 워크플로도 그 혜택을 받을 수 있지만, 팀마다 커넥터를 별도로 연결하면 자격 증명이 흩어져 회수가 어려워진다.

커스텀 확장은 화이트리스트로 관리한다. 허용되지 않은 커넥터나 외부 MCP 서버는 요청과 검토를 거치게 하고, 검토 대상에는 데이터 반출 범위, 쓰기 권한 여부, 로그 수집 가능 여부를 포함한다.

표준 기능은 플랫폼 업데이트의 이점을 자동으로 받고 인수인계가 쉬워 기술 부채가 거의 생기지 않는다. 커스텀 개발은 원하는 동작을 정확히 구현할 수 있지만, 플랫폼이 유사 기능을 기본 제공하면 중복 자산이 되어 부채로 바뀐다. 표준으로 80%를 충족할 수 있다면 표준을 사용하고 나머지 20%는 업무 절차를 조정하는 원칙이 유효하다. 규제나 계약 때문에 그 20%를 바꿀 수 없을 때만 커스텀 개발이 정당화된다.

읽기·쓰기 권한, 감사, 비용을 함께 다룬다

권한 설계에서는 읽기와 쓰기를 같은 승인 수준으로 취급하지 않아야 한다. 읽기 전용 커넥터는 계층 구분 없이 폭넓게 열 수 있지만, 쓰기 권한은 대상 시스템마다 별도 승인하고 기본은 거부로 둔다.

감사 로그는 플랫폼 콘솔에만 남겨서는 부족하다. Compliance API와 Admin API를 통해 사용량과 콘텐츠 접근 이력을 프로그래밍 방식으로 수집하고, 기존 SIEM이나 로그 파이프라인에 연결해야 한다. 콘솔 화면에 의존하는 감사는 보존 기간이 짧고 상관 분석이 어려워 사고 조사에 활용하기 힘들다.

비용 통제도 초기 설계에 포함한다. 조직·사용자 단위 지출 한도와 75%·90% 알림을 켜 두지 않으면, 스케줄 작업이 반복되면서 비용이 선형이 아니라 계단식으로 증가할 수 있다.

업무 유형으로 배포하고 지식을 자산화한다

배포 단위는 부서보다 업무 유형이 적합하다. 예를 들어 같은 재무팀에서도 월말 마감 대사는 입력이 고정된 고빈도 업무이므로 SDK 자산화가 유리하다. 반면 시장 조사 요약은 매번 입력이 달라지는 저빈도 업무라 플랫폼 UI가 적합하다.

도메인 지식은 프롬프트에 흩어두기보다 스킬과 프로젝트 지식 자산으로 외부화해 버전 관리한다. 지식이 대화 안에만 남아 있으면 담당자가 바뀔 때 함께 사라진다. 초기 도입 조직이 1년쯤 뒤에 공통으로 겪는 실패 유형이기도 하다.

플랫폼 워크플로를 코드로 올리는 경로와, 유지되지 않는 커스텀 자산을 표준으로 되돌리는 경로를 모두 문서화해야 한다. 승격할 때는 플랫폼 워크플로의 단계 정의와 스킬 문서를 명세로 삼아 SDK 구현을 만들고, 일정 기간 두 구현을 병행 운영하면서 산출물을 비교한다. 하향할 때는 유지보수 주체가 사라진 커스텀 도구를 표준 스킬 조합으로 바꾸고 폐기 일자를 정한다. 이런 경로가 없으면 조직에는 아무도 손대지 못하는 자동화가 누적된다.

도입 초기에 확인할 운영 조건

도입은 기존 자동화의 인벤토리부터 시작한다. 개인 계정으로 이미 실행 중인 자동화, 팀별 스크립트, 외부 SaaS에 포함된 AI 기능까지 목록으로 만들고, 각 항목의 소유자·접근 데이터·실행 주기·실패 시 영향도를 기록한다. 이 작업을 건너뛰면 기존 자동화와 신규 자동화가 중복되고, 같은 데이터를 서로 다른 경로로 변경하게 된다.

계층별 요구도 따로 확인한다. 소비자 계층에는 반복 수작업을, 구성자 계층에는 IT 요청으로 넘기기에는 작은 자동화 요구를, 제작자 계층에는 여러 팀이 반복 요청하는 공용 도구를 묻는다. 답변이 겹치는 지점이 표준 스킬의 우선 후보가 된다.

플랫폼 평가는 모델 성능보다 운영 조건에 초점을 맞춘다. 커넥터 커버리지, 감사 API 제공 여부, 권한 세분도, 지출 통제 수단, 온프레미스·VPC 실행 옵션, 데이터 처리 위치, 종료 시 자산 회수 가능성을 본다. 특히 스킬과 워크플로 정의를 내보낼 수 없는 플랫폼은 시간이 지날수록 전환 비용이 커진다.

파일럿은 성공 가능성이 높은 업무보다 측정 가능한 업무를 선택한다. 도입 전후의 소요 시간과 오류율을 비교할 수 있어야 확산 근거가 생긴다. 팀 교육은 사용법뿐 아니라 사용하지 말아야 할 상황을 다뤄야 한다. 검토 없이 결과물을 외부로 내보내는 관행은 사고로 이어질 수 있다. 산출물 검토 책임은 여전히 사람에게 있고, 민감 데이터는 승인된 커넥터로만 흘러야 한다는 점을 분명히 해야 한다.

정책 문서에는 커넥터 화이트리스트와 승인 절차, 계층별 허용 작업 범위, 산출물 검토 의무 기준, 사고 보고 경로를 포함한다. 모니터링 지표는 실행 성공률, 평균 소요 시간, 사용자당 비용, 승인 거부 건수를 기본으로 삼고, 급격한 변화가 발생한 스킬을 우선 점검 대상으로 식별한다.

기존 IT 관리 체계 안에 에이전트를 편입한다

커넥터와 MCP는 EAI·API 게이트웨이가 담당하던 시스템 통합 계층을 다시 드러낸다. 인터페이스 정의서와 연계 현황도는 기존 통합 관리 체계 안으로 넣어야 한다.

계층별 권한과 엔터타이틀먼트에는 IAM의 역할 기반 접근 통제(RBAC)와 직무 분리(SoD) 원칙을 적용할 수 있다. 개인 계정으로 연결한 커넥터는 계정 관리 통제를 우회하는 경로가 된다. 스킬과 워크플로 정의는 형상 항목으로 등록하고 Change Management 절차를 거쳐야 하며, 표준 스킬의 개정에는 영향도 분석과 회귀 검증이 따라야 한다.

2026년 이후에는 에이전트 플랫폼이 별도 관리 대상으로 남을지, 기존 ITSM·IAM·형상관리 체계에 흡수될지가 갈릴 것이다. 확산 속도를 통제 가능한 범위에 두려면 후자의 방향으로 설계해야 한다.