클로드 산업 자동화를 이야기할 때 가장 먼저 바뀌는 것은 모델의 성능표가 아니라 자동화의 시작점입니다. 과거에는 사람이 어느 화면을 열고 어떤 버튼을 누를지 먼저 설계한 뒤, RPA나 API 워크플로우를 연결했습니다. 이제는 “이 문서들을 읽고 판단 기준에 맞는 보고서를 만들어 공유해 달라”는 결과 중심의 지시에서 자동화가 시작될 수 있습니다.
Anthropic은 Claude Code를 코드베이스를 읽고, 파일을 수정하고, 명령을 실행하고, 개발 도구와 연결하는 에이전트 도구로 설명합니다. 최근의 Claude Cowork는 같은 에이전트 구조를 터미널 밖의 지식 업무로 가져와 정리된 문서, 파일 정리, 리서치 결과, 스프레드시트와 프레젠테이션 같은 결과물을 만들도록 확장합니다. 이 글은 그 변화를 바탕으로 Claude가 어떤 자동화 제품과 겹치는지, 실제로 어떤 업무가 바뀌는지를 살펴봅니다.
이 흐름은 이미 Claude 4 에이전틱 코딩의 장기 작업 변화에서 보았던 개발 업무의 변화가 지식 업무로 확장되는 과정이기도 합니다.
기업 시스템 안에서 기록·권한·감사를 다루는 방식은 ServiceNow의 AI Control Tower와 업무 자동화와 비교하면 더 분명해집니다.
클라우드와 업무 데이터의 수직 통합이라는 관점에서는 Microsoft의 Azure·Copilot 전략도 함께 볼 수 있습니다.
이 글에서 말하는 “위협”은 기존 제품이 곧 사라진다는 뜻이 아닙니다. Claude가 비정형 입력을 읽고 계획을 세워 여러 도구를 호출하는 범위를 넓히면서, 기존 자동화 제품의 구축 방식·가격·차별화 지점이 압박받는다는 의미입니다. 글의 90%·95% 수치는 공개 벤치마크가 아니라 조건이 맞을 때의 필자 전망입니다.
자동화의 단위가 플로우에서 에이전트로 이동하다
Claude Code에서 Claude Cowork로
Claude Code의 핵심은 답변을 출력하는 채팅이 아니라 작업을 끝내는 루프입니다. 코드를 읽고, 여러 파일을 수정하고, 명령을 실행하고, 오류를 확인한 뒤 다음 행동을 정하는 과정이 하나의 세션에서 이어집니다. Claude Code 공식 문서는 MCP를 통해 Google Drive·Jira·Slack 같은 외부 도구와 자체 도구를 연결하고, 반복 작업을 예약할 수 있다고 설명합니다.
Claude Cowork는 이 구조를 비개발자에게 노출하는 제품입니다. 터미널 명령을 배워야 하는 대신 원하는 결과를 자연어로 설명하면, Claude가 파일과 커넥터를 읽고 여러 단계의 작업을 진행한 뒤 문서·스프레드시트·프레젠테이션 형태로 결과를 남깁니다. Cowork 안내에 따르면 Cowork는 Claude Code의 에이전트 구조를 코딩 밖의 지식 업무로 확장하고, 예약 작업과 프로젝트 단위의 파일·지침·기억을 제공합니다.
이 변화의 의미는 개발자가 자동화를 만든다는 전제가 약해진다는 데 있습니다. 개발자는 여전히 권한, 데이터 구조, 예외 처리, 배포를 설계해야 하지만, 업무 담당자는 “무엇을 언제 어떤 기준으로 처리할지”를 설명하는 것만으로 첫 번째 AI 워크플로우를 만들 수 있습니다.
두 방향의 도구 호출 루프
자동화는 한 방향으로만 흐르지 않습니다. 문서를 읽고 도구를 호출할 수도 있고, 도구에서 먼저 자료를 가져온 다음 문서를 만들 수도 있습니다.
- 문서에서 시작하는 루프: PDF·Word·스프레드시트·메일을 읽고, 내용을 요약·분류·정리한 뒤, Google Drive에 새 문서로 저장하거나 담당자에게 메일 초안을 만들고, 업무 시스템에 결과를 기록합니다.
- 도구에서 시작하는 루프: CRM·캘린더·Drive·Slack·내부 API에서 데이터를 가져오고, 여러 결과를 비교·요약한 뒤, 보고서·회의자료·후속 작업 목록을 만들거나 다시 다른 도구로 전달합니다.
Anthropic의 Google Workspace 커넥터 안내는 Gmail·Calendar·Drive를 연결해 검색하고, 문서를 만들고, 생성한 파일을 Drive에 저장하는 흐름을 설명합니다. 커넥터가 없을 때는 Cowork의 컴퓨터 사용 기능이 브라우저나 화면을 직접 조작할 수 있지만, 현재 연구 미리보기이며 커넥터보다 느리고 오류 가능성이 높습니다.
기존 RPA의 핀셋영역은 “컴퓨터의 어느 위치에서 어떤 데이터를 읽고, 어떤 도구에 어떤 형식으로 전송하거나 저장할 것인가”였습니다. 화면 좌표, 셀 위치, 파일명, 로그인 계정, 예외 화면을 모두 미리 정의해야 했기 때문입니다. LLM 에이전트는 이 중 일부를 문맥을 읽고 계획하는 문제로 바꾸지만, 반복성이 높은 업무와 엄격한 감사가 필요한 업무에서는 RPA와 API가 여전히 더 적합합니다.
클로드가 압박하는 자동화 제품 지도
Claude가 기존 제품을 모두 대체하는 것은 아닙니다. 다만 자동화의 첫 설계 단계에서 자연어로 목표를 설명하고, 비정형 문서를 읽고, 필요한 도구를 선택하는 일이 가능해지면서 아래 제품군과 겹치는 면적이 빠르게 커지고 있습니다.
| 영역 | 겹쳐지는 제품군 | Claude와 겹치는 지점 | 기존 제품이 여전히 강한 지점 |
|---|---|---|---|
| 화면·RPA 자동화 | UiPath Platform, Power Automate Desktop, Automation Anywhere, Blue Prism | 화면을 보고 파일을 열고 여러 단계를 수행하는 긴 꼬리 업무 | 결정적 실행, 무인 운영, 권한·감사·재시도, 대규모 로봇 관리 |
| 앱 연결·iPaaS | Zapier Agents, Make AI Agents, n8n, Workato | 자연어 지시로 여러 앱과 API를 연결하고 조건에 따라 다음 도구를 선택하는 작업 | 앱 카탈로그, 시각적 플로우, 실행 이력, 재시도, 운영자용 모니터링 |
| 문서 처리·IDP | Microsoft AI Builder, UiPath Document Understanding, ABBYY 계열 | PDF·Word·메일에서 내용을 읽고 분류·추출·요약하는 작업 | 고정 스키마, 필드별 신뢰도, 검증 큐, 대량 처리, 규정형 템플릿 |
| CRM·백오피스 | Salesforce Agentforce Operations, ServiceNow AI Agents | 이메일·문서·ERP·사람을 가로지르는 공급업체·계약·고객 업무 | CRM·ITSM 데이터와 권한, 프로세스 템플릿, 승인선, 책임 추적 |
| 기업용 업무 플랫폼 | Microsoft 365 Copilot·Workflows, Google Workspace·Gemini, Notion 계열 | 파일 요약, 회의자료·보고서 생성, 팀 지식 검색과 후속 작업 | 테넌트 보안, 계정·공유 권한, 조직 내 저장소와 기본 통합 |
제품 관점에서 가장 먼저 압박받는 것은 “간단한 자동화를 만들어 주는 구축 서비스”입니다. 과거에는 작은 팀이 이메일 수신, 파일 분류, 요약, 알림 전송을 연결하려면 iPaaS 화면에서 트리거와 액션을 하나씩 골라야 했습니다. 이제는 Claude가 목표와 데이터 위치를 이해하고 첫 설계를 만들 수 있으므로, 단순 연결의 가치가 낮아집니다.
반대로 기존 자동화 플랫폼은 Claude를 적으로만 보지 않습니다. UiPath는 에이전트·로봇·도구·사람을 하나의 제어 영역에서 묶는 방향으로 가고 있고, Microsoft는 에이전트가 판단하고 워크플로가 구조와 감사 기록을 맡는 결합을 설명합니다. 즉, 기존 제품의 다음 경쟁력은 “버튼을 대신 누르는 로봇”이 아니라 다양한 모델과 에이전트를 안전하게 배치하고 관찰하는 운영 체계가 됩니다.
이런 관점에서 보면 Claude는 RPA 자동화 제품 하나와 경쟁하는 것이 아니라 자동화 시장의 상단을 넓히는 촉매에 가깝습니다. RPA가 정해진 화면 작업을 담당하고, API가 시스템 사이의 안정적인 통로를 제공하며, LLM 에이전트가 비정형 입력을 해석하고 다음 행동을 계획하는 조합이 현실적인 구조입니다.
비개발자 업무의 90%가 자동화되는 조건
클라우드 저장소와 파일 형식이 업무의 기반이 된다
에이전트 자동화의 성패는 모델 하나보다 도구의 역할에 달려 있습니다.
- Google Drive·SharePoint·Dropbox 같은 클라우드 저장소는 파일을 공동으로 보관하고 공유하는 기준점이 됩니다.
- 동기화 폴더와 데스크톱 커넥터는 LLM이 로컬 파일에 접근해야 할 때 수동 업로드를 줄여 줍니다.
- Word·Excel·PowerPoint·PDF·TXT·Markdown 같은 문서 도구와 파서는 파일을 열고 구조를 읽는 입구입니다. HWP처럼 특정 지역에서 많이 쓰는 형식은 연결 도구가 실제 파싱을 지원하는지 별도로 확인해야 합니다.
- API·MCP·셸 스크립트는 결과를 다른 시스템으로 전송하거나 신규 파일을 생산하는 출구가 됩니다.
Claude는 이미 파일을 읽는 데서 멈추지 않고, 파일 생성·편집 기능을 통해 Excel·PowerPoint·Word·PDF 같은 결과물을 만들 수 있다고 안내합니다. 파일을 읽고 요약하는 모델과 파일을 생산·전송하는 도구가 하나의 대화 안에서 연결되면, 업무 담당자는 각 제품의 메뉴보다 처리할 목적과 승인 기준에 집중하게 됩니다.
마케팅 플랜과 정형 분석은 빠르게 자동화된다
마케팅 플랜을 예로 들면 시장 자료 수집, 경쟁사 목록화, 고객군 분류, 캠페인 가설 작성, 일정표와 예산 초안, 보고서와 발표자료 생성까지 이어지는 흐름이 있습니다. 사람이 해야 하는 것은 무엇을 조사할지와 어떤 제약을 지킬지를 정하는 일이고, 자료를 읽고 초안을 조립하는 대부분의 단계는 에이전트가 처리할 수 있습니다.
필자는 조건이 잘 정의된 마케팅 플랜의 문서 작성과 결과물 생성 과정은 약 90%까지 자동화될 수 있다고 봅니다. 다만 시장 수치가 최신인지, 경쟁사 정보가 사실인지, 예산과 법적 표현에 문제가 없는지는 사람이 확인해야 하므로 “캠페인 전체가 90% 자동 집행된다”는 뜻은 아닙니다.
정해진 포맷의 분석·요약·플랜·결과물 생산은 더 높은 자동화율을 기대할 수 있습니다. 입력 문서가 충분하고, 출력 형식이 정해져 있으며, 외부 시스템에 쓰기 전 승인 단계가 있다면 필자는 이 부분의 95% 이상을 자동화할 수 있다고 예상합니다. 이 수치는 회사·문서·권한 설계에 따라 크게 달라지는 조건부 추정입니다.
Claude Cowork의 예약 작업은 매일 메일·Slack·캘린더를 요약하거나, 매주 Drive 자료를 모아 보고서를 만드는 반복 업무를 제품 기능으로 끌어옵니다. 자동화의 단위가 “버튼을 누르는 일”에서 “매주 결과물을 납품하는 일”로 바뀌는 지점입니다.
산업의 다음 경쟁은 보안·거버넌스·판단이다
공공·법무·세무·부동산에서 일어날 변화
공공기관, 법무법인, 세무·회계, 부동산 컨설팅처럼 텍스트와 고급 정보를 많이 다루는 업종은 LLM의 이점을 크게 받을 수 있습니다. 과거 기록을 검색하고, 문서의 맥락을 비교하고, 신규 정책이나 의견서의 초안을 만들고, 정해진 양식으로 보고하는 업무가 많기 때문입니다. Microsoft AI Builder의 문서 처리 구조도 문서 수신·정보 추출·검토·결과 통보를 하나의 흐름으로 묶되, 예외는 사람이 확인하는 구조를 전제로 합니다.
다만 이런 조직은 외부 LLM을 바로 도입하기 어렵습니다. 개인정보·비공개 기록·법률상 비밀·국가 중요 정보가 포함될 수 있고, 누가 어떤 문서를 읽고 어떤 결정을 했는지 감사할 수 있어야 합니다. Cowork의 안전 가이드도 읽기 도구와 쓰기 도구의 위험이 다르고, 예약 작업·브라우저·커넥터가 서로 다른 서비스로 데이터를 전달할 수 있으므로 권한과 사람 검토를 맞춰야 한다고 설명합니다.
필자는 이 보안·법규제·감사 문제가 해결되는 조직에서는 현재 담당자가 수행하는 잡무의 상당 부분이 자동화될 것으로 봅니다. “담당자의 95%가 필요 없어진다”는 의미가 아니라, 현재 업무 시간의 95%를 차지하는 복사·검색·정리·문서화 중심의 반복 작업에서 해방되어 판단과 설계에 더 많은 시간을 쓰게 된다는 뜻입니다.
아이디어를 내는 사람과 문서를 만드는 사람의 역할이 갈라진다
과거 정책을 입안하거나 사업계획을 만들 때 담당자는 기록을 찾아 읽고, 여러 아이디어를 문서로 정리하고, 시안을 만들고, 보고서를 작성하느라 밤을 새우기도 했습니다. 앞으로는 과거 기록의 맥락을 찾아 비교하고, 여러 방향의 아이디어와 시안·보고서 초안을 만드는 일은 자동화될 가능성이 높습니다.
사람의 역할은 더 나은 방향성을 판단하고, 현실적인 제약을 반영하고, 결과물이 실제 현장에서 작동할지 검토하는 쪽으로 이동합니다. 즉, 아이디어가 없는 사람이 문서를 잘 만드는 능력보다, 많은 후보 중 어떤 방향을 선택할지 판단하고 빠르게 프로토타입을 검증하는 능력이 중요해집니다.
여기서 기존 RPA와 API가 사라지는 것은 아닙니다. 오히려 에이전트가 판단한 결과를 실제 시스템에 안전하게 반영하려면 API, 업무 규칙, 승인선, 감사 로그가 더 중요해집니다. 자동화 시장은 “LLM 하나로 끝내기”가 아니라 에이전트의 추론과 기존 시스템의 통제력을 결합하는 시장으로 재편될 가능성이 큽니다.
에이전트가 문서를 읽고 도구를 호출할 수 있다는 사실이 곧 업무를 무감독으로 맡겨도 된다는 뜻은 아닙니다. 문서 안의 악성 지시, 잘못된 권한, 오래된 데이터, API 오류, 환각이 실제 전송·삭제·정책 판단으로 이어질 수 있습니다. 민감한 업무는 읽기와 쓰기 권한을 나누고, 외부 전송과 최종 보고 전에 사람 승인 단계를 남겨야 합니다.
마무리
클로드가 산업지형을 바꾸는 핵심은 더 좋은 답변을 만드는 데 있지 않습니다.
- Claude Code가 개발자의 파일·명령·도구 작업을 에이전트 루프로 묶었습니다.
- Claude Cowork가 그 구조를 비개발자의 문서·파일·클라우드 업무로 확장했습니다.
- RPA·API·문서 처리·협업 제품은 사라지기보다 에이전트를 안전하게 운영하는 오케스트레이션 계층으로 이동하고 있습니다.
- 정형 업무의 자동화율은 높아지지만, 방향성 판단·책임·보안·최종 승인까지 자동화되는 것은 아닙니다.
이미 발 빠른 회사들은 도구를 하나씩 추가하는 대신 업무 흐름 자체를 AI 중심으로 다시 설계하고 있습니다. 여러분의 회사는 지금 어떤 업무를 사람이 직접 복사하고, 검색하고, 정리하고, 보고서로 옮기고 있습니까? 그 작업의 목적과 권한을 먼저 정의할 수 있다면, 자동화는 생각보다 가까이 와 있을 수 있습니다.
다음에는 클로드를 이용해 이런 실무적인 자동화 기법을 어떻게 사용하는지 알아보겠습니다. 궁금한 분들은 기대해 주세요.
댓글 없음:
댓글 쓰기