Claude Code가 출시된 지 1년 이상이 지났지만, 올해 들어 Claude Cowork라는 것이 등장했습니다. 'Claude Code와 무엇이 다른가?'라는 의문이 생겨 조사해 보았습니다.

2026년 시점, Anthropic의 "Claude를 사용하여 에이전트처럼 업무를 진행하는" 입구는 크게 두 가지로 나뉩니다.

Claude Code— 2024년 11월 출시된, 터미널에서 동작하는 코딩 에이전트 CLI -
Claude Cowork— 2026년 1월 출시된, 동일한 엔진을 Desktop GUI에 탑재한 지식 노동자(Knowledge Worker)용 제품

둘 다 내부 아키텍처(Claude Agent SDK / MCP / Skills / Subagent)가 거의 공통적이며, Anthropic 또한 "Cowork는 Claude Code를 비엔지니어용으로 갈아입힌 것"이라고 설명하고 있습니다. 인터뷰 기사에 따르면 Cowork는 소규모 팀이 단기간에 구축한 제품으로, 코드의 대부분은 Claude Code에 의해 작성되었습니다 (The New Stack 인터뷰).

"동일한 엔진"이라고 해도, 실제로 사용할 때는 UI / 상정 사용자 / 기능 액세스가 상당히 다르기 때문에, 양쪽을 모두 사용하는 사람일수록 "결국 어느 쪽으로 무엇을 해야 하는가"를 판단하기 어려워지기 쉽습니다 (저 또한 그 상황에 빠져 있었습니다). 본 기사에서는 Pro 플랜($20/월)에서도 접할 수 있는 범위를 중심으로, 양자를 나란히 정리합니다 (Pro 플랜 계약 시 양쪽 모두 사용 가능합니다).

• Claude Code와 Cowork를 모두 사용해 본 적이 있거나 사용하려는 사람

• 개인 개발에서 AI 에이전트의 역할 분담을 정리하고 싶은 사람

• "둘 다 계약 중이지만, 결국 어느 쪽으로 무엇을 해야 하는지"를 한 번쯤 언어화하고 싶은 사람

• 양자의 아키텍처적 공통점과 차이점

• 가격·배포·운용에서의 실무적인 주의사항

• Cowork의 "내용물" (Linux VM 샌드박스)이 운용에 효과적인 상황

• 개인 개발자 관점에서의 현실적인 활용 규칙

결론을 대략적으로 말하자면 **"git 내부나 코드 관리는 Code, 그 외에는 Cowork"**이며, 하고 싶은 일을 기준으로 Claude Code와 Claude Cowork에 역할을 부여하는 것이 좋습니다. 이유는 기사 후반부에서 자세히 다루겠지만, 첫 번째 이유는 양자를 동시에 같은 파일에서 작업하게 하면 캐시(Cache)·실행 취소(Undo)·git 충돌이 발생하기 때문입니다. 따라서 하나의 작업은 한쪽에서 완결 짓는 것이 사고를 줄이는 방법입니다.

이 점을 파악해 두면 혼란을 피할 수 있는 것이, 양자는 동일한 Agent SDK의 파생 제품이라는 점입니다. 구체적으로는 다음 6가지가 공통 기반으로서 양자에 탑재되어 있습니다.

• Claude 모델 (Opus / Sonnet / Haiku)
• Claude Agent SDK (구 Claude Code SDK의 명칭 변경)
• MCP (Model Context Protocol)
• Skills (SKILL.md + 동봉 리소스 패키지)
• Subagent / Task tool
• 플러그인 (Skill + MCP + Subagent를 하나로 묶은 배포 단위)

한쪽에서 작성한 스킬이나 플러그인은 공통 기반을 통해 다른 한쪽에서도 거의 그대로 동작합니다. "Skill을 작성한다" 또는 "MCP 서버를 추가한다" 수준의 투자는 중복되지 않는다는 점을 기억해 두면 좋습니다 (Anthropic 공식).

다만, UI 레이어와 "외부로 향하는 API"가 다르기 때문에 기능을 확장하는 방식이나 운용 패턴은 별개입니다.

이 부분이 양자의 체감 차이를 결정짓는 가장 큰 부분입니다.

claude 명령어로 실행하며, 터미널 상에서 대화 가능 - VS Code나 Cursor 등 IDE 확장 기능이 풍부

• 입력은 텍스트 + 슬래시 명령어 (/model, /permissions, /clear 등) - 상태나 컨텍스트는 작업 디렉토리의 CLAUDE.md / .claude/에 보유
• 정해진 타이밍에 삽입하고 싶은 처리의 확장은 hooks (Claude Code Docs / Hooks reference)를 사용할 수 있음 (settings.json에서 SessionStart / PreToolUse 등)

등에 Shell, LLM, HTTP를 심을 수 있음) - Git / Bash / Vim 사용자에게는 자연스럽게 익숙함

• macOS / Windows의 네이티브 앱으로 동작 (Windows는 2026-02-10에 Mac과 기능 패리티(Feature Parity)를 갖추어 일반 제공 예정)

• 입력은
  채팅 + Apple/Windows 스타일의 GUI 위젯 (태스크 리스트, Artifacts, AskUserQuestion의 선택지 버튼, request_cowork_directory를 통한 폴더 피커 등)

• 상태는
  마운트된 폴더 + Cowork 내의 Projects 폴더에 유지됨

• 플러그인 (Skill + MCP + Subagent를 하나로 통합) + Skills (개별) + scheduled tasks를 통한 확장 - "터미널? 그게 뭔가요?"라고 묻는 사용자에게 전달해도 바로 세팅이 완료됨

거칠게 말하자면, Claude Code는 "Shell + Markdown"에 가깝고, Cowork은 "App + Button"에 가깝습니다. 같은 일을 양쪽 모두에서 할 수 있는 경우가 많지만, 사용자가 익숙한 멘탈 모델(Mental Model)에 따라 전달했을 때의 초기 반응이 크게 달라집니다.

두 가지를 모두 사용해 보며 발견한 세부적인 차이점을 표로 정리했습니다.

"Claude Code에서만 가능한 것"은 hooks의 세밀한 제어와 직접 Bash를 다루는 계열의 작업이며, "Cowork에서만 가능한 것"은 Artifacts (나중에 열면 커넥터로부터 자동으로 데이터를 다시 가져오는 HTML 뷰)와 GUI 선택지 / 태스크 위젯, 그리고 scheduled tasks 정도입니다.

두 서비스는 동일한 Claude 플랜 위에 구축되어 있기 때문에, 계약은 하나로 거의 완결됩니다. Pro (월 $20, 연 결제 시 $17) 이상이라면 Claude Code와 Cowork을 모두 사용할 수 있는 것이 현재 시점(2026년 5월, claude.com/pricing 스냅샷)의 구성입니다.

최근 SNS에서 "Claude Code를 Pro 플랜에서 제외한다"는 테스트가 논란이 되었다가 철회된 적이 있었습니다. 향후 정세를 고려할 때, Pro 플랜에서의 Code 이용은 향후 정책(Tone)이 바뀔 가능성이 충분히 있습니다. 관심 있는 분들은 Claude 공식 Pricing 페이지에서 최신 구성을 확인하시기 바랍니다.

화면이나 기능만으로는 보기 어려운, 운영 단계에서 실제로 발생할 수 있는 일을 3가지만 꼽겠습니다.

• Claude Code: ~/.claude/settings.json + .claude/ 하위의 프로젝트 파일. **Plaintext로 평치(Flat)**되어 있으므로, 리포지토리에 커밋하지 않는 운영 규칙(.gitignore / direnv 등)이 필요함

/ OS의 키체인)을 직접 구성 -
Cowork: Cowork 내부의 설정 스토어(Setting Store)에 저장되며, GUI를 통해 등록한다. 실수로 Git에 올라가는 일은 없지만, 백업 및 이관 시 「어디에 무엇이 있는지」 파악하기 어렵다

동일한 MCP 서버를 양쪽 모두에서 사용한다면 두 곳에 동일한 시크릿(Secret)을 작성해야 합니다. 이는 현시점에서는 감수해야 할 부분입니다.

Claude Code: 기본적으로 Git을 통해 배포. Skill 폴더째로 commit → push 하여 타인에게 clone하게 합니다.
Cowork: 플러그인 마켓(공식 + 프라이빗 마켓)에서 설치할 수 있으므로, Skill 제작에 자신이 없는 사람도 Skill을 사용할 수 있습니다. 공유는 마켓을 경유하여 .plugin 파일로 패키지화하여 할 수 있습니다.

개발 중에는 Code로 작성하고 Git으로 돌리다가, 안정화되면 Cowork의 플러그인으로 만들어 팀에 배포하는 2단 로켓 방식으로 진행하는 것이 현실적입니다.

양쪽 모두 Claude 모델 본체는 Anthropic API로 전송되어 동작하므로, 그런 의미에서는 "로컬 AI"가 아닙니다. 차이점은 내 로컬 파일을 어디까지 읽느냐입니다:

Claude Code: 실행된 CWD(현재 작업 디렉토리) 하위만. 셸(Shell) 권한과 동일한 범위에서 동작하므로, .env 등의 민감한 정보가 읽힐 수 있다는 전제하에 다뤄야 함
Cowork: request_cowork_directory를 통해 명시적으로 마운트(Mount)한 폴더만 읽을 수 있음. 마운트하지 않은 디스크는 보이지 않음

보안 관점에서는 Cowork 쪽이 "읽히는 범위"가 물리적으로 제한되어 있는 만큼, 코드베이스를 벗어난 업무 작업에 적합합니다.

지금까지 "Cowork는 Claude Code를 비엔지니어용으로 갈아입힌 것"이라고 설명했지만, "같은 엔진"이 구현 레벨에서 어떻게 실현되고 있는지를 파악하면, 주의해야 할 점과 용도 구분(棲み分け)의 경계가 더욱 선명해집니다. 공개된 정보와 여러 리버스 엔지니어링(Reverse Engineering) 보고를 바탕으로, 현시점에서 파악된 실체를 정리합니다.

Anthropic 스스로가 **"Cowork는 Claude Code 에이전트 하네스(Agent Harness)를 Linux VM 내에서 구동하는 것이며, Apple Virtualization Framework 또는 Microsoft의 Host Compute System을 통한다"**라고 설명하고 있습니다. 즉 Cowork는 별개의 모델이 아니라, Claude Code CLI를 VM 내에서 실행하고 Claude Desktop이 오케스트레이션(Orchestration)하고 있을 뿐입니다. 실행 환경은 Ubuntu 22.04 LTS 풀 VM(Docker 컨테이너가 아닌 독자 커널 포함)이며, Apple Silicon Mac에서는 ARM64로 동작함이 리버스 엔지니어링을 통해 확인되었습니다(Windows 버전은 Hyper-V 상의 대응 아키텍처에서 동작).

공식 Help Center에도 다음과 같이 적혀 있습니다:

셸 명령과 Claude가 작성한 코드는 모두 전용 Linux VM 내에서 실행되며, 호스트 OS와는 플랫폼의 하이퍼바이저(Hypervisor)(macOS는 Apple Virtualization.framework, Windows는 Hyper-V)를 통해 분리됩니다. VM은 독자적인 네트워크 egress 필터링, syscall 제한, 세션 단위의 사용자 분리를 수행합니다.

계층 구조를 도식화하면 다음과 같은 이미지입니다.

호스트 → 하이퍼바이저 → Linux VM → Bubblewrap → Claude Code CLI 순으로, 4단계의 경계를 넘어야 비로소 Claude의 명령이 실행되는 구조입니다. Computer Use만은 이 계층의 바깥쪽, 즉 호스트 OS 위에서 직접 동작합니다.

단순한 VM 분리가 아니라, 하드웨어 레벨의 VM 분리에 더해 게스트(Guest) 내의 프로세스를 Bubblewrap (bwrap)으로 한 번 더 제약하는 이중 샌드박스(Sandbox) 구조로 되어 있습니다. 실무에서 마주하게 될 제한 사항은 다음 4가지입니다.

파일 가시 범위가 "마운트한 폴더만" — 호스트 폴더는 VirtioFS Bridge를 통해 /mnt/.virtiofs-root/

에 마운트되며, 선택한 폴더만 필요할 때 마운트됩니다. Cowork에 보여주지 않은 폴더는 VM 입장에서는 존재하지 않는 것으로 간주됩니다 -
네트워크는 allowlist 방식 — 의존성 설치는 허용하면서, 임의의 웹 액세스는 차단합니다. pip install이나 npm install은 통과하더라도, 알 수 없는 도메인으로의 egress(송신)는 허용되지 않습니다 -
VM 내에서 추가적인 seccomp / bubblewrap 적용 — syscall 레벨에서 rm -rf /와 같은 공격을 VM 내부에서 봉쇄합니다 -
세션마다 VM 상태가 클린함 — 각 Cowork 세션은 깨끗한 VM 상태로 시작되므로, 영속적인 멀웨어(Malware)가 세션 간에 살아남을 수 없습니다. 반대로 말하면 「세션을 넘나드는 환경 구축」이 어렵습니다

흥미로운 점은, Computer Use는 VM이 아니라 호스트(Host) 상에서 동작한다는 점입니다. Anthropic은 다음과 같이 명시하고 있습니다:

Computer use는 Cowork가 통상적인 파일 작업이나 명령 실행에 사용하는 가상 머신(VM) 외부에서 동작합니다. 즉, Claude는 격리된 샌드박스(Sandbox)가 아니라 실제 데스크톱과 앱을 조작하고 있습니다.

브라우저 조작이나 앱 클릭은 VM 내부에서는 물리적으로 불가능하므로 당연한 결과이지만, 이 지점은 보안 모델이 전환되는 경계선이므로 업무에 도입하기 전에 이해해 둘 가치가 있습니다.

VM 샌드박스를 전제로, 용도 구분은 더욱 구체적으로 할 수 있습니다.

Git 조작을 동반하는 자동화 작업 (코드 생성 → push, 뉴스 수집 → 리포지토리 업데이트 등) → Cowork가 아닌 Claude Code (로컬 WSL2)에서 실행하는 것이 합리적입니다. Cowork의 경우 git push의 egress가 allowlist에 의존하며, ~/.ssh를 마운트하지 않으면 SSH 키를 볼 수 없습니다. 호스트 권한 그대로 동작하는 Claude Code가 자동화 파이프라인을 구축하기에 더 용이합니다 -
Skill 개발 → Cowork 내 VM에서는 /mnt/skills/user/에 대한 쓰기가 세션을 넘어서 유지되지 않을 가능성이 있으므로, Claude Code로 로컬에 작성하는 것이 반복 작업 속도가 더 빠릅니다 -
특정 폴더 하위의 정리 작업 → 폴더만 마운트하면 완결되므로, Cowork의 제한이 오히려 안전장치로서 기능합니다

.docx / .pptx / .xlsx / .pdf를 Claude에게 생성시키게 하는 상황에서는 VM 경계의 효과를 가장 체감하기 쉽습니다. 결론부터 말하자면 **「바이너리 품질은 동일하지만, 생성까지의 마찰(Friction)이 완전히 다르다」**입니다.

Cowork (VM): 약 1,200개의 apt 패키지가 프리인스톨(Pre-installed)되어 있습니다. numpy / pandas / matplotlib / seaborn, Pillow / OpenCV, python-docx / python-pptx / openpyxl / reportlab, pikepdf / pypdf / pdfplumber, pytesseract 등을 처음부터 사용할 수 있습니다. 단, apt를 통한 시스템 패키지 추가는 불가능합니다 -
Claude Code (WSL2): 순수 호스트 환경이므로 pip install python-pptx openpyxl 등을 직접 설치해야 합니다 (한 번 설치하면 영구적으로 유지된다는 점이 장점입니다).

Cowork에는 .docx / .pptx / .xlsx / .pdf를 위한 빌트인 문서 스킬(Built-in Document Skills)이 「최적화된 상태로」 동봉되어 있어, 실제 포맷팅(Real formatting) 레벨에서 별도의 설정 없이(Out-of-the-box) 동작합니다. Claude Code에서도 생성할 수 있지만, Cowork가 「그대로 사용할 수 있는 완성도」가 더 높다는 것이 사실입니다.

다만 주의할 점은, Cowork의 표준 pptx / xlsx 스킬은 「단순히 깔끔한」 수준에서 멈춘다는 점입니다. md-to-pptx의 4가지 템플릿 전환이나 marp-slide-creator의 Obsidian 연동과 같은 자작 스킬의 묘미는 느낄 수 없으므로, 커스텀 요구사항이 많을수록 Claude Code 쪽으로 방향을 잡는 것이 결과적으로 더 빠릅니다.

이미 Skill 생태계를 구축하고 있다면, Office 파일 생성 플로우 전체로서는 Claude Code 쪽으로 맞춰두는 것이 일관성을 유지하기 좋습니다. Cowork은 "자작 Skill을 가져오지 않는, 그 자리에서 끝내는 단발성 작업"에 배정하는 것이 밸런스가 좋아 보입니다.

풀 VM (Full VM)이 아닌 스텁(Stub) + srt를 통한 샌드박스(Sandbox) 안을 포함하여, Linux용 Cowork 실행을 시도하는 커뮤니티 PR(@chukfinley)이 논의되고 있으며, WSL2 환경에서 네이티브하게 Cowork을 호출할 수 있는 날이 올 가능성도 있습니다 (공식 채택 여부는 별개의 문제입니다).

요점: Cowork의 "제한이 많다"고 느껴지는 동작은 대부분 VM 경계 + Bubblewrap + allowlist의 3단계 방어로 설명할 수 있습니다. 반대로 Claude Code의 로컬 직접 호출이 빠른 이유는 이 방어 계층을 그대로 통과하기 때문입니다. 보안과 속도의 트레이드오프 (Trade-off)를 이해한 상태에서, 작업마다 구분하여 사용하는 것이 사고를 최소화하는 가장 좋은 방법입니다.

"같은 일을 양쪽 모두 할 수 있다"고는 하지만, 익숙해지면 어느 쪽으로 기울지는 정해지게 됩니다. 실제 경험을 바탕으로 분류합니다.

Claude Code

• 기존 리포지토리 (Repository)의 코드 생성 및 수정
• pytest / cargo test 등을 루프로 돌리며 수행하는 디버깅 (Debugging)
• Git의 히스토리(History) 및 브랜치 (Branch) 조작을 동반하는 작업
• CI에 통합하는 계열의 자동화 (GitHub Actions과 궁합이 좋음)
• hooks를 통해 "커밋 전에 Lint 적용" 또는 "도구 호출 전에 허가 받기"를 설정하고 싶은 경우

Cowork

• 보고서 · 의사록 · 슬라이드 · 스프레드시트 작성
• 검색 → 요약 → 파일 저장의 "원스톱 (One-stop)" 지적 작업
• 비엔지니어 팀원에게 전달할 때
• "매일 아침 6시에 뉴스를 수집해서 Markdown으로 만들어줘"와 같은 정기 작업 (Scheduled job)
• 결과를 나중에 몇 번이고 다시 열어서 최신 상태로 보고 싶을 때 (Artifacts)

기타 / 테스트용

• 단발성 조사 및 브레인스토밍 (Wall-hitting)
• Skill / 플러그인 (Plugin) 프로토타이핑
• MCP 서버 동작 확인

이 부분은 익숙한 쪽에서 하는 것이 결국 가장 빠릅니다.

두 가지를 병행할 때, 미미하지만 효과가 있는 트러블(Trouble)이 있습니다.

• 같은 파일을 양쪽에서 열면 undo 전쟁이 일어납니다. Claude Code가 쓰고 Cowork에서도 열려 있다면, 한쪽의 "마지막 저장"으로 인해 다른 쪽의 편집 내용이 사라집니다. 1 파일 = 1 도구로 고정하는 것이 안전합니다.
• Skill 테스트는 한쪽에서만 가능한 경우가 있습니다. hooks를 전제로 한 Skill은 Claude Code 쪽에서만 올바르게 작동합니다. 반대로 AskUserQuestion이나 Artifacts를 호출하는 Skill은 Cowork 쪽에서만 동작 확인이 가능합니다.
• MCP 연결 정보의 스코프 (Scope)가 다릅니다. Claude Code는 ~/.claude/ 하위, Cowork은 Cowork 내부의 설정 스토어(Store)를 사용합니다. 같은 MCP 서버를 양쪽 모두에서 사용하려면 두 곳에 모두 등록해야 합니다.
• 예약 작업 (Scheduled tasks)은 Cowork 쪽에만 있습니다. 동일한 작업을 Claude Code에서 수행하려면 결국 OS의 cron / Task Scheduler로 넘겨야 합니다.
• Projects (Cowork)와 CLAUDE.md (Code)는 의외로 이중 관리 대상이 됩니다. 동일한 프로젝트를 두 UI 모두에서 다룬다면, Cowork의 Project 내에 CLAUDE.md를 두어 양쪽 모두에서 읽히도록 하는 것이 현실적인 해답입니다.

개인 개발에서 두 가지를 병행한다면, 개발 단계(Phase) × 결과물의 종류에 따라 선을 그으면 고민이 사라집니다. 필자의 운영 방식은 다음 표와 같이 수렴되었습니다.

거칠게 말하자면, "생각하기 · 읽기 · 정리하기"는 Cowork, "쓰기 · 실행하기"는 Claude Code입니다. 동일한 프로젝트 내에서도 개발 단계가 바뀌면 도구를 전환하는 것이 가장 원활합니다.

요구사항 정의와 결과물 리뷰는 Cowork에 집중합니다. md / pptx / xlsx가 도메인의 중심이 되므로, GUI로 파일을 열면서 상호작용할 수 있는 강점이 발휘됩니다.

설계 ~ 테스트는 Claude Code에 집중합니다. 파일 편집 · 테스트 실행 · Git 조작까지 호스트 권한으로 완결되며, pytest / npm test 루프에 올라타기 쉽습니다.

공유 자산 (Skill / MCP / CLAUDE.md)은 한곳에 집약하고, 다른 한쪽에서는 Read할 수 있는 위치에 두어 참조만 합니다. 이중 관리는 사고의 원인이 됩니다.

"어느 쪽으로 열 것인가"를 고민하는 시간이 거의 제로가 된 것이 가장 큰 효과였습니다. 통합하려고 애쓰지 말고 "영역 구분선"을 물리적으로 긋는 것이 요령입니다.

• Claude Code와 Cowork은 내용물 (Agent SDK / MCP / Skills)이 같으면서, UI와 상정 사용자만 다른 쌍둥이 제품입니다.
• Pro 구독 하나로 거의 모두 갖출 수 있으므로, 어느 것을 선택할지가 아니라 "어디서 무엇을 할지" 선을 긋는 것이 정답입니다.
• 병행 시의 사고(undo 전쟁 · MCP 이중 등록 · scheduled tasks의 불균형)만 주의한다면, 양쪽 모두 사용하는 운영은 충분히 현실적입니다.

Cowork는 출시된 지 얼마 되지 않았기 때문에, Claude Code에만 있는 hooks와 같은 세밀한 제어 기능은 앞으로 순차적으로 도입될 것이라고 보는 것이 타당합니다. 지금 미리 영역 구분선을 그어둔다면, 기능 차이가 좁혀진 후에도 운영 방식은 흔들리지 않을 것입니다.

• Claude Cowork — Anthropic 공식 제품 페이지
• Cowork: Claude Code power for knowledge work — Claude by Anthropic
• Use plugins in Claude Cowork — Claude Help Center
• Get started with Claude Cowork — Claude Help Center
• Plans & Pricing — Claude by Anthropic
• Hooks reference — Claude Code Docs
• Anthropic takes Claude Cowork out of preview and straight into the enterprise — The New Stack
• Anthropic Expands Claude's "Computer Agent" Tools Beyond Developers with Cowork Research Preview — ADTmag
• Anthropic Launches Projects Feature for Claude Cowork Desktop — Cyber Security News
• Claude Code Cheat Sheet 2026 — blakecrosley.com