AI 코워커, 소프트웨어의 종말인가?
Anthropic이 공식 출시한 '로컬 자동화' 기능, 그 의미와 한계
최근 주요 소프트웨어 기업들의 주가가 큰 폭으로 출렁였습니다. 시장은 그 원인 중 하나로 앤스로픽(Anthropic)이 발표한 'Claude Coworker'를 지목했습니다. 'AI가 로컬 PC를 직접 제어한다', '코딩 없는 파일 자동화의 시대가 왔다'는 자극적인 헤드라인들이 쏟아졌고, 이는 곧 기존 소프트웨어들의 무용론으로 번졌습니다
기사를 읽으며 저는 묘한 기시감을 느꼈습니다.
"잠깐, 이거 내가 지난달에 만든 거 아닌가?"
맞습니다. 지난 글 "북2 9화, AI가 내 PC를 직접 다루기 시작했다"편의 주제였던, 제가 구축한 Local MCP Server가 바로 이 역할을 하고 있었으니까요. AI가 제 PC의 파일을 읽고, 터미널 명령어를 실행하고, 보고서를 만들어 이메일까지 보내는 그 모든 것들 말입니다.
그래서 오늘은 제가 직접 구축한 시스템과 Anthropic이 공식 출시한 Cowork를 나란히 놓고 비교해 보려 합니다. 무엇이 같고, 무엇이 다르며, 소프트웨어는 정말 없어질까요?
Cowork란 무엇인가:?
Claude Cowork는 Claude Desktop 앱에 내장된 로컬 자동화 탭입니다.
기존 Chat 탭에서는 메시지를 주고받는 대화형 인터페이스였다면, Cowork 탭에서는 "이 폴더 정리해줘", "이 데이터로 보고서 만들어줘"라고 태스크를 던지면 AI가 스스로 계획을 세우고, 실행하고, 결과물을 저장합니다.
코딩 지식이 없어도 됩니다. JSON 설정 파일을 만질 필요도 없습니다. 그저 폴더를 지정하고 원하는 결과를 말하면 끝입니다.
지난 글에서 제가 시연했던 두 가지 시나리오를 기억하시나요?
시나리오 1: "고객 A-tech의 12월 월간 보고서 PPT를 만들어줘" → CSV 읽기 → 템플릿 적용 → PPT 생성 → 이메일 전송
시나리오 2: "다운로드 폴더 정리해줘" → 파일 분석 → 네이밍 규칙 제안 → 승인 후 폴더 생성 및 분류
Cowork도 정확히 이 작업들을 수행할 수 있습니다. 제가 Docker 컨테이너를 띄우고, MCP 설정 파일을 작성하고, 도구들을 연결하느라 보냈던 그 작업을, Cowork는 탭 하나 클릭으로 해결합니다.
그렇다면 무엇이 다른가?
기술적으로는, 실행 환경의 차이: 호스트 vs 샌드박스
제가 구축한 Local MCP는 제 PC에서 직접 실행됩니다. 커맨드 툴(Commander Tools)가 터미널 명령어를 날리면, 그건 진짜 제 Windows 시스템에서 돌아가는 겁니다.
반면 Cowork는 격리된 가상 머신(VM) 안에서 실행됩니다. 애플의 가상화 프레임워크(VZVirtualMachine)를 사용해 별도의 Linux 환경을 부팅하고, 사용자가 지정한 폴더만 그 안에 마운트합니다. 그래서 현재 애플 OS에서만 작동되고, Window 에서는 작동되지 않습니다.
사용자 관점에서는, 제가 구축한 Local MCP는 제가 미리 설계 설정하고 연결해둬야 하고, 그리고 빠르고 정확합니다.
반면에, Cowork는 별도의 연결이 없어도 사람이 쓰는 메모장, 브라우저, 엑셀 창을 그대로 이용합니다. 범용성은 압도적이지만, 화면을 캡처하고 해석하는 과정에서 리소스 소모가 클수 있습니다.
Remote MCP는 여전히 대체 불가능한 '두뇌'입니다.
Cowork는 Local MCP의 상당 부분을 대체할 수 있지만, Remote MCP는 대체할 수 없습니다.
제가 구축한 Hybrid 아키텍처를 다시 떠올려 보겠습니다.
Claude가 제 화면에서 파일을 클릭할 순 있어도, 구글 클라우드(GCP) 너머에 있는 우리 회사의 Salesforce 데이터나 중앙 ERP의 보안 승인을 화면 캡처만으로 가져올 수는 없습니다.
결국 진정한 자동화는 제가 구축한 모델처럼, 중앙 자원을 가져오는 Remote MCP와 내 PC 내에서 작업을 수행하는 Local 실행부가 결합될 때 완성되리라 생각합니다.
소프트웨어는 정말 없어질까?
저는 지난 "북2 07화 머스크의 인터뷰, 노동의 종말 "편에서 이런 이야기를 한 적이 있습니다.
"앱(App)이 사라진다고요? 앱의 UI가 사라질 가능성은 있지만, 그렇다고 '소프트웨어(SW)' 자체가 사라지는 것은 아닙니다. 화려한 화면은 걷어내 지더라도, 그 안의 핵심 기능들은 여전히 존재합니다. 다만 사람이 손으로 터치하던 것을, 이제는 AI 에이전트가 API라는 '보이지 않는 손'을 통해 조작하게 될 수 있습니다."
위와 같이, 소프트웨어 회사가 망할 것이라는 우려에 대해 저는 조금 다른 견해를 가지고 있습니다.
과거에는 사용자가 소프트웨어를 쓰기 위해 '학습'해야 했습니다. 엑셀 함수를 외우고 포토샵 메뉴 위치를 익혔죠. 하지만 이제 소프트웨어는 AI라는 '통합 인터페이스' 아래로 숨게 될 수 있습니다.
우리가 엑셀을 켜지 않아도 AI가 백그라운드에서 엑셀 엔진을 써서 보고서를 만든다면, 그것은 엑셀의 종말일까요? 아닙니다. 오히려 소프트웨어가 '도구'에서 '엔진'으로 진화하는 과정일 것입니다. 다만, 사용자와 직접 만나지 못하는 소프트웨어 기업들은 브랜드 파워를 잃고 AI 에이전트의 '하청 서비스'로 전락할 위험은 분명히 존재합니다.
사실, 이런 시스템을 한 땀 한 땀 설계하고 구현하다 보면 문득 허탈함이 찾아오기도 합니다. 제가 한땀한땀 '보이지 않는 손(API)'을 연결하고 나면, 얼마 지나지 않아 빅테크 기업들이 그 기능을 제품화해서 내놓으니까요.
하지만 저는 믿습니다. 제품을 '사용하는 사람'과 직접 '설계해본 사람'의 깊이는 완전히 다르다는 것을요. 거대 기업이 표준화된 제품을 내놓기 전에 그 가치를 먼저 알아보고 직접 구현해본 경험은, 기술이 제품화되어 흔해진 세상에서도 나만의 독보적인 인사이트가 될수 있고, 새로운 기술을 선도한다는 자부심도 가질수 있죠.
그리고, 여전히 이 AI 기술은 끝을 알 수 없는 망막한 대양이며 그렇기에 우리가 항해하며 실험해야 할 영토는 여전히 무궁무진합니다.
다음 단계, 에이전트의 '고삐'를 쥐는 법
AI에게 내 PC의 핸들을 맡기는 것은 설렘만큼이나 두려운 일이기도 합니다.
"내가 잠든 사이 AI가 중요한 파일을 지우면 어쩌지?" 혹은 "잘못된 보고서를 고객에게 전송하면?"이라는 걱정은 당연한 것입니다.
진정한 자율화는 신뢰가 아닌 검증 위에서 완성됩니다. 그래서 다음 글에서는 AI가 자율적으로 진행한 모든 업무를 실시간으로 추적(Tracking)하고 모니터링하여, 혹시 모를 실수에 대비하는 '에이전트 로그(Log) 및 관제 대시보드' 구현 과정을 공유해 드리려 합니다.
AI의 '보이지 않는 손'이 어떻게 움직였는지 투명하게 들여다보는 법, 다음 차시에서 본격적으로 다뤄보겠습니다.