Claude Code와 Cowork을 병용하면 개발이 바뀐다 ── 보완 관계와 비동기 위임

이 기사의 실시 기록: Claude Code (CLI)와 Cowork (Claude 데스크톱 앱)의 병용 운용을 실제 작업에서 확립했다. 두 개를 나란히 세워두고, 로컬 파일(Local file)을 통해 연결하는 「cowork-cli-bridge」 프로토콜로 비동기적으로 분업시켜, /note-post 스킬 신설을 완료했다. Cowork이 스킬 설계 및 구현을 담당하고, CLI가 배포(Deploy)와 git 조작을 맡았다. 위임부터 완료까지 2분 47초(실측: cli-pending.md의 created_at → completed_at 차이. 인간이 CLI에 말을 거는 시간 포함).

Claude Code (CLI)와 Cowork (Claude 데스크톱 앱)은 동일한 Mac 상에서 동작하는 두 개의 독립된 세션입니다. 각각 「할 수 있는 것・할 수 없는 것」이 다르며, 로컬 파일을 매개로 비동기적으로 연계하는 「cowork-cli-bridge」 프로토콜로 조합하면, 어느 한쪽 단독으로는 막히는 태스크(배포, 브라우저 조작, 최신 리뷰)를 분업으로 완결할 수 있습니다. 실측 결과, Cowork이 스킬 설계를 담당하고 CLI가 배포와 git 조작을 맡은 위임이 2분 47초 만에 완료되었습니다 (인간이 CLI에 "pending 확인해줘"라고 말하는 시간 포함).

Claude Code (CLI)를 한동안 계속 사용하다 보면, 「이 세션은 문맥(Context)이 너무 쌓였다」라는 느낌이 들 때가 있습니다. 혹은 「이 태스크는 브라우저 조작이 필요하지만, CLI에서는 건드릴 수 없다」라는 벽에 부딪히기도 합니다.

그럴 때 「또 다른 Claude인 Cowork (Claude 데스크톱 앱)을 띄운다」라는 선택지가 생깁니다. Claude Code와 Cowork은 별개의 제품이며, 할 수 있는 것과 할 수 없는 것이 명확히 나누어져 있기 때문입니다.

Cowork (Claude 데스크톱 앱)과 Claude Code (CLI). 같은 Mac에서 돌아가는 두 개의 별개 계통 세션을 어떻게 연결하고 어떻게 나누어 쓸 것인가. 2026년 5월의 실운용을 통해 보여진 패턴을 정리합니다.

Cowork과 CLI는 「어느 쪽이 상위」가 아닌 보완 관계

먼저 오해를 풀어두겠습니다. Cowork과 CLI는 어느 한쪽이 다른 쪽의 「상위 호환」이 아닙니다. 각각 「할 수 있는 것」과 「할 수 없는 것」이 있습니다.

이 비대칭성이 두 가지를 조합하는 동기가 됩니다.

비교 축	Cowork	CLI (Claude Code)
파일 조작 (Read/Write/Edit)	워크스페이스 내는 자유	permissions 설정 범위 내에서 자유
~/.claude/로의 배포	불가 (샌드박스 제약)	가능
git 명령어 실행	불가	가능
브라우저 조작 (note/Zenn 공개 등)	특기	불가
...
(출처: ops/playbooks/cowork-cli-bridge.md, 2026-05-10 버전)

단적으로 말하자면:

• 「결과물의 내용을 만든다」 → 둘 다 가능 (리뷰는 Cowork이 유리)
• ~/.claude/ ・ .git/ ・ 스크립트 실행 → CLI 한정
• 브라우저 조작 → Cowork 한정
• 「이 세션, 선입견이 섞여 왔다」 → Cowork에 외부 리뷰를 요청

파일 하나로 위임할 수 있는 구조 「cowork-cli-bridge」

「두 개를 띄우는 건 번거롭지 않나?」라는 의문에 먼저 답하겠습니다.

위임 조작은 파일을 한 권 쓰는 것뿐입니다.

ops/active/cli-pending.md (또는 cowork-pending.md)라는 지시서 파일을 둡니다. 그것이 「메시지 큐(Message Queue)」가 됩니다.

파일의 구조

---
created_at: 2026-05-11 22:42:37
source: cowork
...

받는 쪽은 이 파일을 읽어 작업을 실행하고, frontmatter의 status를 pending에서 completed로 바꿔 씁니다.

포인트는 세 가지입니다.

• 외부 API를 거치지 않음: 로컬 파일을 버스(Bus)로 사용하기 때문에 지연(Latency)이 제로. git으로 이력도 남음
• 상태 관리는 심플한 4가지 상태: pending → in_progress → completed (또는 cancelled)

） -
삭제하지 않음: status(상태)를 다시 써서 완료를 기록한다. 나중에 "언제·누가·무엇을 완료했는지"를 추적할 수 있다.

이 설계를 나는 「cowork-cli-bridge」라고 부르고 있습니다 (내가 개인적으로 붙인 명칭이며, 공식 용어는 아닙니다). Playbook로서 ops/playbooks/cowork-cli-bridge.md에 구현되어 있습니다 (2026-05-10 업데이트).

/note-post

스킬 신설에 소요된 2분 47초

실례: "2~3분 만에 완료된다"라고 써도 실감이 나지 않을 것이라 생각합니다. 실례를 통해 살펴보겠습니다.

무엇을 했는가

note.com에 기사를 게시하는 절차를 Cowork에게 지시하는 /note-post 스킬을 신설했습니다.

• 설계·구현: Cowork (skill-dev 에이전트)가 담당
  • workspaces/skill-dev/note-post/SKILL.md (318행)를 신규 생성 (실측: wc -l)
  • 설계서 (551행) · 구현 보고서 (175행)도 동시에 작성
• 배포와 git 조작: Cowork의 샌드박스 (sandbox) 제약으로 인해 실행할 수 없으므로, CLI에 위임

위임의 시계열 (Timeline)

Cowork는 22:42:37에 cli-pending.md를 작성했습니다. 지시 내용은 3단계입니다:

• .git/index.lock 삭제 (이전 세션의 잔해)
• ~/.claude/commands/로 배치 (SKILL.md를 복사)
• git add / commit / push

CLI가 작업을 완료하고, completed_at: 2026-05-11 22:45:24를 기록했습니다.

경과 시간: 2분 47초 (cli-pending.md의 created_at → completed_at의 차이). 이 시간에는 내가 CLI 측 세션에 "pending을 봐"라고 말을 거는 조작과, CLI가 이를 읽고 실행에 착수하기까지의 대기 시간도 포함됩니다 (완전 자동화의 처리량 (throughput)이 아닙니다).

참고로, 배포된 ~/.claude/commands/note-post.md는 11869 bytes (실측: wc -c)입니다.

cli-pending.md는 이렇게 작성되어 있다

실제 "지시서에 무엇을 써야 할지 모르겠다"라는 의문에 답하기 위해, 이번에 사용한 실제 내용의 발췌본을 게재합니다 (frontmatter와 의뢰 도입부).

---
created_at: 2026-05-11 22:42:37
source: cowork
...

포인트는 "배경 설명 → 할 수 없었던 이유 → 구체적인 커맨드 (command)"의 3층 구성입니다. CLI는 이를 읽고 문맥을 파악하여 커맨드를 그대로 실행할 수 있습니다. 지시서의 입도(granularity)로는 "복사해서 붙여넣으면 바로 작동하는 커맨드"까지 쓰는 것이 기준입니다.

"왕복 오버헤드 (overhead)가 늘어나지 않는가"에 대한 답변

이 위임에 소요된 조작은 "Cowork가 파일을 1권 쓰는 것"뿐입니다. CLI가 다음에 그 파일을 읽고 작업을 실행합니다. CLI에 말을 거는 것("pending을 봐"라고 전달하는 것)은 인간이 수동으로 수행하는 수동 트리거 방식입니다. 자동 폴링 (polling)이 아닙니다.

2분 47초라는 수치는 Cowork가 지시 파일을 다 쓴 순간부터, CLI가 status를 completed로 다시 쓰는 것까지의 합계 경과 시간입니다. 이 안에는 내가 CLI에 "pending을 봐"라고 말을 거는 조작과, CLI가 이를 읽고 실행에 착수하기까지의 시간도 포함되어 있습니다. 완전 자동화의 벤치마크가 아니라, 인간이 트리거를 당긴다는 전제의 실운용 기록으로서 읽어주시기 바랍니다. 그럼에도 불구하고 "Cowork로 설계하면서, 적당한 타이밍에 CLI로 흘려보낸다"라는 비동기적인 사용감이 성립할 정도의 속도감은 됩니다.

Cowork를 신선한 컨텍스트를 가진 외부 리뷰어로 사용하기

Cowork와 CLI의 구분 사용에서 간과하기 쉬운 이점이 있습니다. 컨텍스트 (context)가 다르다는 점입니다.

CLI는 긴 세션이 쌓일수록 그 문맥에 끌려간 판단을 하기 쉬워집니다. "이것이 옳은 방향이다"라는 선입견이 쌓여갑니다.

Cowork는 세션마다 신선한 컨텍스트로 바라봅니다. 워크스페이스의 파일은 공유할 수 있으므로, "이 파일을 보면서 상담하고 싶다"라는 것이 성립합니다.

예를 들어보겠습니다. CLI가 집필 중인 Zenn Book의 두 번째 원고 구성을 "이대로 진행한다"라고 판단하고 있던 상황에서, Cowork에 외부 리뷰를 의뢰했습니다 (cowork-pending.md 경유). Cowork이 내린 결론은 "두 번째와 세 번째로 분권해야 한다"였습니다.

이는 CLI가 "당연하다"라고 생각했던 전제 자체를 무너뜨리는 지적이었습니다. 방향 전환을 이끌어낸 것은, 완전히 다른 컨텍스트(Context)에서 바라본 시각이었다고 생각합니다 (이는 저의 해석입니다).

이 "신선한 컨텍스트로 리뷰한다"라는 방식은, 이전에 ChatGPT나 Claude.ai의 채팅에 상담하던 목적과 유사합니다. 차이점은 워크스페이스(Workspace)를 공유할 수 있기 때문에 "말로 다시 설명해야 하는" 비용이 들지 않는다는 점입니다.

"같은 Mac에서 두 개의 Claude 세션"은 오버헤드인가

솔직히 말하면, 사용 초기에는 그렇게 느꼈습니다. "하나의 세션에서 전부 하는 편이 더 효율적이지 않을까"라는 감각입니다.

실제로 운용하며 알게 된 것은, 오버헤드(Overhead)보다 세션의 수명이 더 큰 영향을 미친다는 사실입니다.

CLI의 세션은 작업이 쌓일수록 컨텍스트(Context)가 비대해집니다. 오래 사용한 세션은 그만큼 많은 비용과 시간을 소비합니다. "어느 시점에서 세션을 분리한다"라는 선택지는 조만간 마주하게 됩니다.

cowork-cli-bridge는 그 분리 방법을 "파일 하나로 비동기적으로 전달한다"라는 메커니즘으로 만든 것입니다. 세션을 분리하는 비용을 낮춤으로써, "오래 사용할수록 무거워지는 하나의 세션"보다 토털 측면에서 가벼워지는 케이스가 생겨납니다.

아직 완전히 능숙하게 다룬다고는 할 수 없으며, 모든 작업에 적용하는 것도 아닙니다. 다만, ~/.claude/로의 배포나 브라우저 조작이 포함된 태스크에서는, 명확하게 "CLI와 Cowork으로 나눈다"라는 선택이 합리적이 됩니다.

cowork-cli-bridge를 사용해야 하는 상황 요약

• Cowork과 CLI는 "할 수 있는 일"이 다르다. 한쪽만으로는 막히는 태스크가 존재한다.
• cowork-cli-bridge 프로토콜: 로컬 파일을 메시지 큐(Message Queue)로 삼아 비동기적으로 위임한다. 위임 작업은 파일 하나를 쓰는 것뿐이다. 실측 결과 위임부터 완료까지 2분 47초(인간의 트리거 포함) 소요.
• Cowork은 "신선한 컨텍스트를 가진 외부 리뷰어"로서도 기능한다.
• 또한, 모바일과 데스크톱을 연결하는 상황에서는 "claude-bridge" (Google Drive 경유)를 구분해서 사용한다 (자세한 내용은 ops/playbooks/claude-bridge.md 참조).

구현은 모두 플레이북(Playbook, ops/playbooks/cowork-cli-bridge.md)에 정리해 두었습니다. 우선 cli-pending.md를 하나 작성해 보는 것만으로도 테스트할 수 있습니다. 지시서 작성법은 위의 실제 사례 발췌본을 참고해 주세요.

이 기사의 실전 사례를 한 권으로 정리했습니다.

이 기사는 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.

Discussion