Projects와 컨텍스트 파일로 '나를 아는 Claude' 만들기

진짜 생산성은 "다시 설명하지 않는 순간" 시작된다

Claude Cowork를 처음 쓸 때 많은 사람이 이런 식으로 일합니다. 매번 새 대화를 열고, 내가 누구인지 설명하고, 이 프로젝트가 무엇인지 설명하고, 어떤 톤을 원하는지 설명하고, 파일은 어디 있는지 또 설명합니다. 처음 한두 번은 괜찮습니다. 하지만 세 번째부터는 조금 억울해집니다. "아니, 우리 이제 좀 친해졌잖아?" 싶은데 Claude는 매번 처음 만난 사람처럼 굴기 때문입니다.

바로 여기서 Projects, 컨텍스트 파일, Project Instructions, Global Instructions가 힘을 발휘합니다. 이 네 가지를 잘 세팅하면 Cowork는 그때부터 단순히 말을 잘 듣는 도구가 아니라, 내 방식으로 일할 준비가 된 작업 환경이 됩니다.

지난 장에서 배운 것은 "한 번의 작업을 잘 맡기는 법"이었습니다. 이번 장의 핵심은 다릅니다. 매번 다시 설명하지 않게 만드는 법입니다. Cowork의 진짜 생산성은 이 지점에서 시작합니다.

그냥 폴더를 고르는 것과 Project를 만드는 것은 다르다

Cowork에서 폴더를 선택하면 Claude는 그 폴더 안의 파일을 읽고, 결과물을 다시 그곳에 저장할 수 있습니다. 이것만으로도 꽤 강력합니다. 하지만 반복적으로 같은 종류의 일을 할 생각이라면, 여기서 한 단계 더 가야 합니다. 바로 Project입니다.¹

Project는 쉽게 말해 Claude에게 주는 전용 책상입니다. 파일만 연결하는 것이 아니라, 이 프로젝트의 목적, 기본 규칙, 참고 자료, 반복되는 산출물 형태를 한곳에 묶어 둡니다. 그래서 같은 Project 안에서 다시 일을 시작하면, Claude는 "아, 여기는 주간 리포트 쓰는 곳이구나" 혹은 "여기는 고객 제안서 다듬는 곳이구나"라는 식으로 맥락을 잡고 출발할 수 있습니다.¹

반대로 폴더만 잠깐 선택해서 작업하면, 파일 접근은 되더라도 프로젝트 단위의 지속적인 설정과 작업 맥락은 훨씬 약합니다. 즉, 일회성 작업은 폴더만으로도 충분할 수 있지만, 반복 업무는 Project가 훨씬 유리합니다.²

이 차이를 사람에 비유하면 이해가 쉽습니다. 폴더만 고르는 방식은 "회의실에 잠깐 불러서 일 맡기기"에 가깝고, Project는 "내 팀 자리에 앉혀 놓고 계속 같이 일하기"에 가깝습니다.

폴더 구조부터 정리해야 Claude도 덜 헤맨다

Cowork는 똑똑하지만, 어수선한 책상 위에서는 사람도 일 못하듯 Claude도 맥락을 잡기 어려워집니다. 특히 처음부터 문서 전체, 바탕화면 전체, 다운로드 전체를 통째로 열어 주면 결과 품질보다 먼저 혼란이 찾아옵니다. 안전 문제도 있고, 작업 범위도 지나치게 넓어집니다.³

그래서 가장 먼저 해야 할 일은 전용 작업 폴더를 만드는 것입니다. 이름은 무엇이든 괜찮지만, 한눈에 "Claude와 같이 일하는 공간"임을 알 수 있으면 좋습니다.

예를 들면 이런 구조가 다루기 편합니다.

Claude-Cowork-Workspace/
├── 00_Context/
│   ├── about-me.md
│   ├── voice-and-style.md
│   └── working-rules.md
├── 10_Projects/
│   ├── weekly-report/
│   │   ├── brief.md
│   │   ├── references/
│   │   ├── templates/
│   │   ├── decision-log.md
│   │   └── 90_Output/
│   └── client-a/
└── 99_Scratch/

이 구조의 장점은 단순합니다.

• 00_Context에는 나에 대한 상시 정보를 넣습니다.

• 10_Projects에는 프로젝트별 작업 파일을 넣습니다.

• 99_Scratch에는 테스트용 초안이나 임시 파일을 넣습니다.

핵심 규칙은 하나만 기억하면 됩니다. 프로젝트 하나당 폴더 하나입니다. 그래야 Project를 만들 때도 깔끔하고, Claude도 어떤 파일이 어떤 일에 속하는지 쉽게 이해합니다.

프로젝트 폴더가 커져서 파일이 10개, 20개, 100개로 불어나면 Claude가 무엇부터 읽어야 할지 헷갈릴 수 있습니다. 그럴 때는 _MANIFEST.md 같은 안내 파일을 폴더 맨 위에 두고, "이 프로젝트의 기준 문서", "우선 읽을 파일", "무시해도 되는 보관 파일"을 적어 두면 훨씬 안정적입니다.⁵

컨텍스트 파일은 "자기소개"가 아니라 "작업 기준서"다

많은 사람이 컨텍스트 파일을 만들 때 실수하는 부분이 있습니다. 너무 멋지게 쓰려 한다는 점입니다. 하지만 Claude에게 필요한 것은 근사한 소개문이 아니라, 일할 때 참고할 기준입니다.

보통은 아래 세 파일이면 충분합니다.⁴

about-me.md: 나는 누구이고, 무엇을 중요하게 보는가

이 파일에는 이력서 전체가 들어갈 필요가 없습니다. Claude가 판단을 할 때 꼭 필요한 정보만 있으면 됩니다.

예를 들면 이런 내용이 좋습니다.

• 내 역할과 업종

• 주로 상대하는 독자나 고객

• 현재 가장 중요한 업무와 우선순위

• 좋은 결과물이라고 느끼는 기준

• 자주 쓰는 도구와 데이터 출처

좋은 about-me.md는 "나는 어떤 사람이다"를 길게 자랑하는 문서가 아니라, Claude가 어떤 방향으로 판단해야 하는지 알려 주는 문서입니다. 예를 들어 "나는 작은 SaaS 팀의 운영 리드이고, 빠른 공유용 문서와 실행 가능한 요약을 선호한다"라는 정보는 실제 출력물의 방향을 크게 바꿉니다.

voice-and-style.md: Claude가 나처럼 쓰게 만드는 파일

이 파일이 없으면 Claude는 대체로 무난하고 공손하고 약간은 기업 홍보팀 같은 문장을 쓰기 쉽습니다. 그것도 나쁘진 않지만, 대부분의 사람은 "이건 내가 쓴 것 같지 않은데?"라는 느낌을 받습니다.

여기에는 이런 내용을 넣으면 좋습니다.

• 선호하는 톤: 친근함, 간결함, 전문성의 정도

• 자주 쓰는 표현과 피하고 싶은 표현

• 문단 길이, 제목 스타일, 표 사용 습관

• 실제로 내가 쓴 좋은 문장 샘플 2~3개

• 절대 쓰지 않았으면 하는 말버릇

특히 중요한 것은 실제 샘플입니다. "따뜻하고 전문적으로 써 줘"보다, 내가 예전에 잘 쓴 문단 하나를 넣는 편이 훨씬 효과적입니다. Claude는 추상적인 형용사보다 구체적인 예시에서 더 잘 배웁니다.

working-rules.md: Claude가 어떻게 행동해야 하는지 정하는 파일

이 파일은 말 그대로 협업 규칙입니다. 내가 원하는 작업 방식, 승인 방식, 저장 방식이 여기에 들어갑니다.

예를 들면 이런 규칙이 유용합니다.

• 시작 전에 관련 파일을 먼저 읽을 것

• 모호하면 최대 3개까지 질문하고 시작할 것

• 삭제나 덮어쓰기는 반드시 확인받을 것

• 기본 산출물 형식은 .md 혹은 .docx로 할 것

• 결과는 항상 90_Output에 저장할 것

이 파일이 좋은 이유는, 매번 프롬프트 끝에 "그리고 삭제하지 말고, 먼저 계획 보여 주고, 저장은 output에 해 줘"를 다시 적지 않아도 되기 때문입니다. 즉, 작업할 때마다 반복하던 잔소리를 파일 하나로 고정하는 것입니다.

변하는 정보는 Instructions보다 파일에 둔다

여기서 아주 중요한 구분이 하나 있습니다. 자주 바뀌는 정보는 Instructions 칸에 넣기보다 파일로 관리하는 편이 좋습니다.¹

예를 들어 이런 것들입니다.

• 최근 결정 사항

• 프로젝트 진행 이력

• 고객이 바꿔 달라고 한 포인트

• 아직 확정되지 않은 가설

• 다음에 이어서 할 일

이런 정보는 decision-log.md, notes.md, status.md처럼 별도 파일에 두는 편이 낫습니다. 이유는 단순합니다. Instructions는 비교적 고정된 운영 규칙에 가깝고, 프로젝트의 변화 기록은 계속 업데이트되어야 하기 때문입니다.

한마디로 정리하면 이렇습니다.

• Instructions는 "항상 이렇게 행동해"를 적는 곳

• 파일은 "지금까지 이런 일이 있었어"를 적는 곳

이 둘을 섞어 두면 나중에 관리가 어려워집니다.

Project Instructions는 "이 프로젝트 안에서만" 통하는 규칙이다

Project를 만들면 프로젝트별로 Instructions를 넣을 수 있습니다. 이 공간은 매우 중요합니다. 왜냐하면 여기에는 "내가 어떤 사람인가"가 아니라, 이 프로젝트에서 Claude가 어떤 기준으로 일해야 하는가를 적기 때문입니다.¹

좋은 Project Instructions에는 보통 다음 요소가 들어갑니다.

• 이 프로젝트의 목적

• 주요 참고 파일과 우선 읽을 순서

• 기본 산출물 형식과 구조

• 독자와 톤

• 파일명 규칙과 저장 위치

• 추측 금지, 출처 표시, 확인 필요 처리 방식

예를 들어 주간 리포트 프로젝트라면 이렇게 적을 수 있습니다.

이 프로젝트는 팀 리더용 주간 운영 리포트를 만드는 공간이다.
작업 시작 전 brief.md, decision-log.md, templates/weekly-report-template.md를 먼저 읽는다.
기본 구조는 요약 → 핵심 수치 → 이슈 → 다음 액션이다.
숫자는 추정하지 말고, 불확실한 내용은 확인 필요로 표시한다.
결과는 90_Output/ 폴더에 YYYY-MM-DD_weekly-report_v1.md 형식으로 저장한다.

이 정도만 적어도 Claude는 훨씬 덜 헤맵니다. 중요한 것은 길이가 아니라 판단 기준이 분명한가입니다.

Project Instructions를 쓸 때 자주 하는 실수는 모든 걸 다 집어넣는 것입니다. 그러면 읽기도 어렵고, 나중에 손보기도 힘듭니다. 핵심만 남기세요. 이 프로젝트에서만 통하는 규칙만 적는 것이 좋습니다.

Global Instructions는 "어디서나 지켜야 하는 내 기본값"이다

반면 Global Instructions는 프로젝트를 가리지 않고 항상 적용되는 규칙입니다. 설정에서 한 번 넣어 두면 모든 Cowork 작업에 기본값처럼 따라옵니다.¹

여기에는 내 작업 습관 중에서도 거의 바뀌지 않는 것만 넣는 편이 좋습니다.

• 항상 먼저 질문하고 시작할지

• 삭제나 덮어쓰기 전 확인을 받을지

• 기본 문서 형식을 무엇으로 할지

• 응답을 간결하게 할지 자세하게 할지

• 추측한 사실을 쓰지 말고 모르면 모른다고 말할지

예를 들어 초보자에게는 아래처럼 짧게 시작하는 것을 권합니다.

모든 Cowork 작업에서 먼저 관련 컨텍스트 파일을 확인해 줘.
모호한 점이 있으면 실행 전에 질문해 줘.
삭제, 이동, 덮어쓰기는 내 확인 없이 하지 마.
기본 결과물은 간결한 markdown으로 작성해 줘.
사실이 불확실하면 추측하지 말고 확인 필요라고 표시해 줘.

Global Instructions는 일종의 운영체제 설정이고, Project Instructions는 앱별 설정이라고 생각하면 쉽습니다. 운영체제 설정에는 "항상 이런 방식으로 일해"를 넣고, 앱별 설정에는 "이 프로젝트에서는 이렇게 일해"를 넣는 셈입니다.

추천하는 실제 세팅 순서

처음부터 완벽하게 만들려고 하면 오히려 손이 안 갑니다. 아래 순서대로 하면 부담이 적습니다.

1. 전용 워크스페이스 폴더를 만든다.

2. 00_Context에 세 파일을 만든다.

3. 자주 반복할 업무 하나를 골라 프로젝트 폴더를 만든다.

4. 그 폴더를 바탕으로 Cowork에서 Project를 생성한다.

5. Project Instructions를 짧게 적는다.

6. Global Instructions에 공통 규칙을 넣는다.

7. 테스트 프롬프트로 확인한다.

테스트는 어렵지 않습니다. Project 안에서 이렇게 물어보면 됩니다.

이 프로젝트에서 내가 어떻게 일하는지, 네가 현재 이해한 내용을 짧게 요약해 줘.

공식 가이드도 비슷한 방식으로 현재 컨텍스트가 잘 읽히는지 점검해 보라고 권합니다.¹

이때 Claude의 요약이 엉뚱하면, 프롬프트를 더 길게 쓰기보다 컨텍스트 파일과 Instructions를 먼저 고치는 편이 낫습니다. 왜냐하면 문제의 원인이 대개 "이번 요청이 부족해서"가 아니라, "기본 설정이 비어 있어서"인 경우가 많기 때문입니다.

이렇게 해 두면 프롬프트가 짧아진다

세팅이 잘 된 뒤에는 프롬프트가 놀랄 만큼 짧아집니다.

처음 세팅이 없을 때는 이렇게 써야 합니다.

나는 작은 팀의 운영 담당자이고, 결과는 간단한 markdown 보고서면 좋겠고, 먼저 관련 파일을 읽고, 불확실하면 질문하고, 숫자는 추측하지 말고, 결과는 output에 저장해 줘. 그리고 팀 리더가 읽을 문서니까 길지 않게 써 줘.

하지만 세팅이 끝난 뒤에는 이렇게 줄어듭니다.

이번 주 자료를 반영해서 주간 리포트 업데이트해 줘.

왜 이렇게 되느냐 하면, 나머지 정보가 이미 Project와 컨텍스트 파일 안에 들어 있기 때문입니다. 바로 이 순간이 "나를 아는 Claude"가 만들어지는 순간입니다.

자주 하는 실수

처음 세팅할 때 많이 나오는 실수도 미리 알아 두면 좋습니다.

첫째, 폴더를 너무 넓게 잡는 것입니다. Documents 전체를 열어 주면 Claude가 뭘 읽어야 할지 몰라서 헤매고, 민감한 파일까지 범위 안에 들어올 수 있습니다.³

둘째, Instructions를 장편 소설처럼 쓰는 것입니다. 길다고 좋은 것이 아닙니다. 고정 규칙만 남기고, 바뀌는 정보는 파일로 빼야 합니다.¹

셋째, 프로젝트를 너무 크게 잡는 것입니다. "회사 전체 업무" 같은 거대한 Project 하나보다, "주간 리포트", "고객 A 제안서", "채용 공고 정리"처럼 목적이 분명한 Project 여러 개가 더 잘 작동합니다.

넷째, 좋은 결과가 나왔는데도 설정을 업데이트하지 않는 것입니다. Claude가 유독 잘한 결과물이 있다면 그 톤, 구조, 규칙을 컨텍스트 파일이나 템플릿 파일에 반영해야 합니다. 그래야 다음부터 우연이 아니라 기본값이 됩니다.

이 장의 핵심은 "기억"보다 "설정"이다

많은 사람이 AI에게 바라는 것은 기억력입니다. 물론 기억도 중요합니다. 하지만 실무에서는 기억보다 더 믿을 만한 것이 있습니다. 바로 좋은 기본 설정입니다.

Project는 Claude에게 일의 방을 만들어 주고, 컨텍스트 파일은 그 방의 벽에 붙은 안내문이 됩니다. Project Instructions는 그 방에서의 규칙이고, Global Instructions는 건물 전체의 운영 원칙입니다. 이 네 가지가 갖춰지면 Claude는 매번 새로 브리핑받는 인턴이 아니라, 이미 업무 방식을 이해한 동료처럼 움직이기 시작합니다.

결국 반복 설명 없는 환경은 거창한 자동화가 아닙니다. 내가 매번 말하던 것을, Claude가 항상 볼 수 있는 곳에 옮겨 두는 것입니다. 그 작업이 끝나면 프롬프트는 짧아지고, 결과는 빨라지고, 스트레스는 눈에 띄게 줄어듭니다.

한 문장 요약

Claude Cowork의 생산성은 프롬프트를 더 길게 쓰는 데서 나오지 않는다. Projects, 컨텍스트 파일, Project Instructions, Global Instructions로 "반복 설명 없는 작업 환경"을 만들어 두는 순간부터 진짜로 빨라진다.

참고

¹Claude Cowork 온보딩 가이드

²Claude Cowork Projects 설명

³폴더 선택과 Instructions 활용 가이드

⁴Claude Cowork 완전 가이드

⁵Cowork Context Kit