Claude Cowork: 내가 첫날 알았더라면 좋았을 설정 가이드

나는 처음 Cowork를 사용할 때 거의 모든 사람이 저지르는 실수를 저질렀다.

나는 그것을 열고, 내 다운로드(Downloads) 폴더를 지정한 뒤, "이것 좀 정리해줘"라고 입력하고 기다렸다. 돌아온 결과는 괜찮았다. 나쁘지 않았다. 그냥 괜찮았다. "오, 신기한 기술이네"라고 생각하며 탭을 닫게 만드는 종류의 결과였지, "이걸 매일 사용해야겠어"라고 느끼게 만드는 결과는 아니었다.

문제는 Cowork가 아니었다. 문제는 내가 그것을 Claude Chat과 똑같이 사용했다는 점이다. 즉, 모호한 지시를 내리고 결과가 좋기를 바라는 방식이었는데, Cowork는 그런 상호작용 스타일을 위해 만들어진 것이 전혀 아니었다. Cowork는 대화보다는 위임 (delegation)에 더 가까운 무언가를 위해 만들어졌으며, 내가 그 차이를 이해하고 나자 내가 그것을 사용하는 모든 방식이 바뀌었다.

이것은 내가 오늘 다시 시작한다면 스스로에게 해줄 설정 방법이다.

첫째, 당신이 실제로 무엇으로 작업하고 있는지 이해하라

어떤 설정 팁을 주기 전에, 개별적인 설정보다 멘탈 모델 (mental model)이 더 중요하다.

Claude Chat은 반응형 (reactive)이다. 당신이 프롬프트 (prompt)를 입력하면 Claude가 스레드 (thread) 안에서 답변한다. 글쓰기, 요약, 아이디어 추론에 좋다. 하지만 작업이 많은 파일, 반복적인 단계, 또는 여러 도구에 걸친 동작에 의존하는 순간, 채팅 인터페이스는 한계를 드러내기 시작한다.

Claude Code는 그 반대편에 있다. 터미널 우선 (terminal-first)이며, 코드베이스 읽기, 명령 실행, 디버깅 (debugging), 테스트 작성과 같은 소프트웨어 엔지니어링 작업을 위해 구축되었다.

Cowork는 완전히 다른 위치에 자리 잡고 있다. 모든 것을 채팅 스레드로 가져오는 대신, 당신은 Claude를 작업이 이미 존재하는 워크스페이스 (workspace) — 로컬 폴더, 연결된 도구, 이메일, 캘린더, Slack, Google Drive — 로 지정한다. 이것은 상호작용을 프롬프팅 (prompting)에서 위임 (delegation)으로 변화시킨다. 목표는 "응답을 얻는 것"에서 "완성된 결과물을 정의하고, Cowork에 필요한 컨텍스트 (context)와 경계(boundaries)를 제공한 뒤, 실행하게 하는 것"으로 바뀐다.

그것이 중요한 전환이다. Chat은 작업 우선 (task-first)이다. 즉, 당신이 동작을 설명한다. Cowork는 출력 우선 (output-first)으로 작동할 때 더 효과적이다. 즉, 당신이 존재하기를 원하는 완성된 결과물을 설명하는 것이다.

설정 단계 1: 문서(Documents)나 바탕화면(Desktop)을 워크스페이스로 사용하지 마라

이것은 사소한 세부 사항처럼 들릴 수 있다. 하지만 그렇지 않다.

Cowork만을 위한 전용 프로젝트 폴더를 만드세요. 일반적인 Documents(문서)나 Desktop(바탕화면)의 혼란스러운 파일들 밖에 명확한 이름이 붙은 폴더를 만들고, Cowork가 오직 그 폴더에만 접근할 수 있도록 허용하며 나머지 모든 접근은 차단하세요.

이것이 중요한 이유: 모든 주요 워크플로우(Workflow)는 전용 폴더 접근 권한을 가진 자체 프로젝트 내에서 이루어져야 합니다. 그래야 여러 프로젝트를 동시에 실행할 때 컨텍스트 혼선(Context bleed)을 방지할 수 있습니다. 만약 Cowork가 당신의 바탕화면 전체를 볼 수 있다면, 그곳에 놓인 모든 관련 없는 파일들까지 추론 과정에 포함하게 되며, 이는 아무런 이득 없이 Cowork의 작업 난이도만 높이는 결과가 됩니다. 프로젝트당 깔끔하게 범위가 지정된(Scoped) 폴더를 사용하면 각 워크플로우가 정확히 필요한 것에만 집중할 수 있습니다.

설정 단계 2: 다른 무엇보다 먼저 전역 지침(Global Instructions)을 작성하라

이것은 가장 많이 건너뛰는 단계이며, 대부분의 사람들이 첫 Cowork 경험에서 실망감을 느끼는 이유이기도 합니다.

Cowork의 설정(Settings) 내부에는 전역 지침(Global instructions)을 입력하는 곳이 있습니다. 이는 단일 작업뿐만 아니라 당신이 수행하는 모든 작업에 적용되는 지속적인 컨텍스트(Persistent context)입니다. 여기서 톤(Tone), 출력 선호도(Output preferences), 제약 사항(Constraints)을 한 번만 설정하면, 매번 다시 설명할 필요가 없습니다.

진정으로 유용한 시작 템플릿은 다음과 같은 형태입니다:

톤(Tone): 직설적으로, 불필요한 서론은 생략할 것.
출력 형식(Output format): 내가 명시적으로 초안을 요청하지 않는 한, 초안 설명보다는 깔끔하게 완성된 결과물을 선호함.
파일 처리(File handling): 명시적인 확인 없이는 절대 아무것도 삭제하지 말 것.
불확실할 때: 추측하여 잘못된 출력을 내놓기보다, 하나의 명확한 질문을 던질 것.
되돌릴 수 없는 작업을 수행하기 전에는 항상 내가 무엇을 하려는지 미리 알려줄 것.

마지막 줄은 보이는 것보다 훨씬 중요합니다. 전역 가드레일(Guardrail) 프롬프트는 Cowork를 사소한 작업 이상의 용도로 사용할 때 의미 있게 더 안전하게 만들어 줍니다. 왜냐하면 샌드박스(Sandboxed) 환경의 Claude Code와 달리, Cowork는 당신의 실제 기기에서 당신의 실제 파일들을 가지고 작업하기 때문입니다.

설정 단계 3: 단순히 작업을 입력하지 말고 브리프(Brief)를 작성하라

다음은 나의 실망스러웠던 첫 경험을 해결해 준 실제적인 사고방식의 전환입니다.

채팅 스타일 (Chat-style) 프롬프팅은 다음과 같습니다: "이 파일들을 읽고 요약해줘." 이것은 하나의 작업 (Task)입니다. Claude Chat에서는 문제없이 작동합니다.

Cowork 스타일 프롬프팅은 완성된 결과물 (Deliverable)을 정의하는 방식입니다. 즉, 출력물이 어떤 모습이어야 하는지, 어떤 파일이나 소스를 참조해야 하는지, 명시적으로 범위에서 제외되는 것 (Out of scope)은 무엇인지, 그리고 실제로 "완료"되었다는 것이 무엇을 의미하는지를 정의합니다.

전형적인 '지저분한 폴더 정리'와 같은 작업을 예로 들면, 작업(Task)과 브리프(Brief)의 차이는 다음과 같습니다.

작업 스타일 (취약함): "내 다운로드 폴더를 정리해줘."

브리프 스타일 (효과적임):

목표: 내 다운로드 폴더를 깔끔한 구조로 정리할 것.

카테고리: 파일 유형별로 폴더를 분류 — 문서 (Documents), 이미지 (Images), 설치 프로그램 (Installers), 압축 파일 (Archives), 기타 (Other).

규칙:

• 2년 이상 되었고 열어보지 않은 모든 파일은 삭제하지 말고 "Archive — Review" 폴더로 이동할 것
• 절대 무엇도 즉시 삭제하지 말 것
• 실행하기 전에 계획을 먼저 보여줄 것
• 분류가 불확실한 파일은 추측하지 말고 표시(Flag)할 것

출력: 정리된 폴더 구조와 무엇이 어디로 이동했는지에 대한 짧은 요약.

브리프 스타일 버전은 작성하는 데 90초가 더 걸립니다. 하지만 이는 당신이 신뢰할 수 있는 결과와, 나중에 파일 하나하나를 다시 재확인해야 하는 결과 사이의 차이를 만듭니다.

설정 단계 4: 워크플로가 서로 섞이지 않도록 프로젝트(Projects)를 사용하라

만약 당신이 콘텐츠 조사와 이메일 분류처럼 한 가지 이상의 반복되는 업무에 Cowork를 사용하고 있다면, 두 가지를 동일한 프로젝트에서 실행하지 마세요.

각각 전용 폴더 접근 권한을 가진 별도의 프로젝트를 통해 작업을 격리(Task isolation)하는 것이 한 워크플로의 컨텍스트 (Context)가 다른 워크플로를 오염시키는 것을 방지하는 방법입니다. 당신의 콘텐츠 조사 프로젝트는 이메일 분류 설정에 대해 알 필요가 없으며, 이들을 분리해 두는 것은 각 프로젝트가 무관한 컨텍스트에 의해 희석되지 않고 각자의 특정 작업에 집중할 수 있게 해줍니다.

설정 단계 5: 다섯 개가 아니라, 하나의 예약된 작업부터 시작하라

기본 설정이 작동하기 시작하면, 모든 것을 한꺼번에 자동화하고 싶은 유혹이 생깁니다. 그 유혹을 뿌리치세요.

예약된 작업 (Scheduled tasks)은 진정으로 Cowork의 가장 유용한 기능 중 하나입니다. 주간 지표 요약, 월요일의 편지함 분류(inbox triage), 또는 Slack과 Drive에서 가져오는 금요일 상태 보고서와 같이, 한 번 설계해 두면 사용자가 다시 손댈 필요 없이 정해진 주기(cadence)에 따라 실행되는 반복적인 워크플로우 (workflows)를 의미합니다.

하지만 반드시 알아두어야 할 실제적인 기계적 세부 사항이 있습니다. 예약된 작업은 기기가 깨어 있을 때(on wake) 실행됩니다. 만약 작업 예정 시간에 기기가 절전 모드(asleep) 상태라면, 백그라운드에서 계속 실행되는 대신 해당 작업을 건너뛰고 다음 부팅 시에 다시 실행합니다. 만약 오전 6시에 보고서를 받기로 기대했는데 오전 6시에 노트북이 닫혀 있다면, 노트북을 열기 전까지는 보고서가 생성되지 않을 것입니다.

정확히 하나의 반복 작업으로 시작하세요. 무언가 잘못되더라도 아무것도 망가지지 않을 만큼 위험 부담이 적은 것, 예를 들어 재무 보고서가 아닌 주간 요약본 같은 것이 좋습니다. 다섯 개의 자동화된 워크플로우를 겹겹이 쌓아 올리기 전에, 그것이 실제로 어떻게 작동하는지 충분히 익히십시오.

Cowork이 아직 진정으로 잘하지 못하는 것들

판매를 위한 홍보가 아닌 정직한 가이드를 위해, 기대치를 설정할 수 있도록 몇 가지 사항을 알려드립니다:

실시간 응답성이 필요한 모든 것. 단계별 지연 시간 (latency)이 빠르게 누적되기 때문에, 즉각적인 상호작용이 필요한 작업에는 적합하지 않습니다.

안전장치 없는 되돌릴 수 없는 작업. Cowork에는 내장된 롤백 (rollback) 기능이 없습니다. 작업 지침 (brief)에 명시적인 승인 단계 (approval gates)를 구축하지 않은 채, 실제 운영 중인 재무 시스템, 운영 데이터베이스 (production databases), 또는 실수가 되돌릴 수 없는 그 어떤 것에도 접근 권한을 부여하지 마세요.

고정밀 창의적 실행. 계획과 구조를 잡는 데는 Claude를 사용하세요. 픽셀 단위의 정밀한 창의적 실행은 당분간 인간의 손에 맡겨두는 것이 좋습니다.

API나 MCP 브릿지가 없는 데스크톱 소프트웨어. 도구가 웹을 통해 접근할 수 없거나 MCP를 통해 연결되어 있지 않다면, Cowork은 해당 도구와 상호작용하는 데 진정으로 어려움을 겪습니다.

유지해야 할 사고 모델 (Mental Model)

이 전체 설정 가이드에서 단 하나의 아이디어만 얻어간다면, 그것은 바로 이것입니다: Cowork을 "글을 쓰는 비서"로 생각하는 것을 멈추십시오. 대신 "일을 하는 비서"로 생각하기 시작하십시오.

그 단 한 번의 관점 전환이 좌절감을 주는 첫 세션과, 결국 매일 의지하게 되는 도구 사이를 가르는 차이점입니다. 채팅 (Chat)은 질문에 답을 합니다. 하지만 Cowork은 결과물 (deliverables)을 완성합니다. 당신의 프롬프팅 (prompting) 스타일이 실제로 사용 중인 방식과 일치하게 되면, 경험은 완전히 달라집니다.

코딩, 리서치 (research), 생산성 (productivity) 등을 위한 검증된 75가지 Claude 프롬프트를 원하신다면:

👉 The Claude Playbook →