Claude 프로젝트 파일 삭제하기

만약 당신이 Claude 앱에서 코드 외 작업 — 콘텐츠 전략, 제품 사양(product specs), 브랜드 가이드, 리서치 — 을 위해 Claude Projects를 사용하고 있다면, 이 글은 당신을 위한 것입니다.

제 프로젝트에는 다섯 개의 파일이 있었습니다. 전략 문서, 발행된 기사, 참고 자료들이었죠. Claude는 매 대화마다 그것들을 읽었습니다. 정리된 느낌이었고, 똑똑하게 느껴졌습니다.

그러고 나서 저는 그것들을 모두 삭제했습니다.

그 파일들이 나빠서가 아니었습니다. Claude Projects에는 인지하는 순간 당신을 미치게 만들 결함이 있기 때문입니다: Claude는 프로젝트 파일을 읽을 수는 있지만, 업데이트할 수는 없습니다. 읽기 전용(Read-only)입니다. 단 하나도 예외 없이 말이죠. 데스크톱 앱, 모바일 앱, 웹 — 무엇이든 상관없습니다. 어디서나 동일한 제한 사항입니다.

따라서 콘텐츠 전략, 사양서, 시간이 지남에 따라 변하는 참고 자료 등 진화하는 무언가를 가지고 있다면, 당신은 다음과 같은 루프에 갇히게 됩니다: 파일을 다운로드하고, 프로젝트에서 이전 버전을 수동으로 삭제하고, 새 버전을 다시 업로드합니다. 매. 번. 말이죠. 정말 가혹합니다. 모바일에서는 진심으로 고통스럽습니다.

저는 한 달 동안 우회 방법을 테스트했습니다. 세 가지 다른 접근 방식을 시도했습니다. 그중 하나는 문제를 해결했을 뿐만 아니라 — 편집 가능한 프로젝트 파일보다 오히려 _더 나은 아키텍처 (better architecture)_로 변모했습니다.

당연해 보이는 방법은 통하지 않았다

저의 첫 번째 본능은 모든 것을 Notion으로 옮기고 프로젝트 파일을 완전히 삭제하는 것이었습니다. 말이 되죠, 그렇지 않나요? Claude는 MCP를 통해 Notion에 접근할 수 있습니다. 페이지를 읽고, 편집하고, 새로운 데이터베이스 항목을 생성할 수 있습니다. 문제가 해결된 것이죠.

하지만 — 실제로는 그렇지 않았습니다.

프로젝트 파일이 없으면, Claude는 모든 대화를 맹목적인 (blind) 상태로 시작합니다. Notion에 어떤 페이지가 있는지, 데이터베이스 ID가 무엇인지, 구조가 어떻게 되어 있는지 알지 못합니다. 매번 당신의 전체 설정을 다시 설명해야 할 것입니다. "내 콘텐츠 허브(Content Hub)로 가서, 데이터베이스 ID는 cx532이고... ...라는 제목의 기사를 찾아봐..."

그것은 워크플로(workflow)가 아닙니다. 그것은 잡무입니다.

어떤 사람들은 대신 Claude Code와 함께 GitHub 저장소(repo)를 사용하는 것을 제안했습니다. 물론, 관리하려는 대상이 코드라면 그것은 아주 잘 작동합니다. 하지만 이것들은 코드 파일이 아닙니다. 이것들은 콘텐츠 전략, 브랜드 가이드, 아이디어 뱅크, 이미지가 포함된 참조 문서, 프로젝트 트래커입니다. 저장소는 이 모든 것을 소스 코드처럼 — 파일 트리 내의 가공되지 않은 텍스트(raw text)처럼 취급합니다. 서식도 없고, 인라인 이미지(inline images)도 없으며, 눈을 가늘게 뜨지 않고는 제대로 볼 수 없는 표(tables)뿐입니다.

Notion은 당신에게 앱을 제공합니다. 휴대폰, 노트북, 어디에서든 열 수 있으며, 당신의 문서(docs)는 문서처럼 보입니다. 표는 표처럼 보이고, 이미지는 바로 그 자리에 있습니다. 콘텐츠 캘린더를 확인하기 위해 터미널(terminal)을 열거나 git 명령어를 배울 필요가 없습니다. 모든 것이 개발자 도구에 속해야 하는 것은 아닙니다. 그리고 이 문서들을 다뤄야 하는 사람들 — PM, 디자이너, 콘텐츠 리드 — 이 브랜드 가이드를 업데이트하기 위해 버전 관리(version control)를 배울 필요는 없어야 합니다.

실제로 작동하는 방법: 모든 것이 어디에 있는지 알고 있는 단 하나의 파일

제가 최종적으로 도달한 방법은 다음과 같습니다 — 그리고 이것은 부끄러울 정도로 단순합니다.

단 하나의 마크다운(markdown) 파일. 당신의 Claude 프로젝트에 존재합니다. 길이는 아마 40줄 정도일 것입니다. 저는 제 파일을 OVERVIEW.md라고 불렀습니다.

이 파일은 실제 콘텐츠를 포함하지 않습니다. 그것은 지도입니다. 다른 건물에 보관 중인 책의 목차(table of contents)라고 생각하세요. 이 개요(overview) 파일은 Claude에게 다음과 같이 알려줍니다: Notion 허브는 여기에 있습니다. 데이터베이스 ID는 이것입니다. 어떤 속성(properties)들이 존재하는지 여기 있습니다. 무엇이 게시되었는지 여기 있습니다. 이 프로젝트를 위한 규칙과 가이드라인은 이것입니다.

그게 전부입니다.

Claude는 이 파일이 프로젝트 파일이기 때문에 모든 대화에서 자동으로 이 파일을 읽습니다. 즉시 지형을 파악합니다. 기사나 문서의 실제 콘텐츠가 필요할 때, Claude는 Notion에서 가져옵니다. 단 한 번의 도구 호출(tool call)로 몇 초면 충분합니다.

그리고 여기서 핵심은 — Claude가 다시 쓸 수 있다는 점입니다. 초안을 편집하나요? 상태를 업데이트하나요? 데이터베이스에 새로운 항목을 추가하나요? Claude는 그냥 해냅니다. Notion에서 말이죠. 콘텐츠가 실제로 존재하는 곳에서 말입니다.

프로젝트 파일은 가볍고 안정적으로 유지됩니다. Notion 데이터베이스는 최신 상태를 유지하며 편집 가능합니다. 이 둘은 함께 작동합니다.

Claude Code를 사용하는 엔지니어라면 이미 이 패턴을 알고 있을 것입니다. 이는 정확히 CLAUDE.md 파일이 코드베이스에서 수행하는 역할과 같습니다. Claude에게 "이 프로젝트는 이렇게 작동하며, 파일들은 여기에 위치합니다"라고 알려주는 작은 파일인 것이죠. 아키텍처는 동일하지만, 코드 이외의 작업에 적용하는 것뿐입니다. 그리고 프로젝트 파일과 달리, 이 설정은 Claude가 다시 쓸 수 있게 해줍니다. Notion은 완전히 편집 가능한 상태로 유지되는 반면, 개요 파일은 가볍고 읽기 전용(read-only) 상태로 유지됩니다.

이것이 생각보다 더 나은 이유

명백한 이점은 **편집 가능성 (editability)**입니다. 하지만 제가 예상하지 못했던 몇 가지 사항들이 더 있었습니다.

컨텍스트 윈도우 (context window)의 질식 현상이 멈춥니다. 제가 다섯 개의 프로젝트 파일을 로드했을 때(전체 기사 3개, 전략 문서 1개, 독립된 포스트 1개)를 생각해보면, Claude가 제 첫 메시지를 읽기도 전에 엄청난 양의 토큰 (tokens)이 소비되었습니다. 반면 개요 파일은 기껏해야 50줄 정도입니다. 나머지 모든 것은 필요할 때만 가져옵니다(on demand). 제 컨텍스트 윈도우는 _꽉 막힌 상태_에서 _숨 쉴 공간이 있는 상태_로 바뀌었습니다.

비대해지지 않고 확장됩니다. 프로젝트에 수십 개의 문서(사양서, 브리프, 회의록 등 무엇이든)가 있다고 가정해 봅시다. 매 대화마다 그 전체 텍스트를 로드할 필요는 없습니다. 하지만 참조하거나 업데이트하고 싶을 경우를 대비해, 그 문서들이 존재한다는 사실과 이름이 무엇인지, 어디에 위치하는지는 알아야 합니다. 개요 파일이 그 역할을 수행합니다. 새 문서를 추가하면 개요 파일은 몇 줄 늘어날 뿐입니다. 이전 방식은 어땠나요? 컨텍스트 윈도우가 몇 달 동안 건드리지도 않은 콘텐츠로 가득 찰 때까지 프로젝트 파일이 점점 더 많아질 뿐이었습니다.

버전 기록 (version history)이 무료로 제공됩니다. Notion은 모든 편집 사항을 추적합니다. 만약 Claude가 무언가를 잘못 작성한다면 — 기사 서론을 엉망으로 편집하거나 특정 섹션을 덮어쓴다면 — 이전 상태로 되돌릴 수 있습니다. 프로젝트 파일에는 그런 기능이 없습니다.

휴대폰에서도 작동합니다. 저는 SuperWhisper를 통해 Claude Desktop에서 모든 프롬프트를 음성으로 입력합니다. Notion 설정은 모바일에서도 동일하게 작동합니다. Claude가 개요(overview) 파일을 읽고, Notion에서 정보를 가져오고, 다시 기록합니다. 휴대폰의 파일 선택기(file picker)를 통해 파일을 다시 업로드할 필요가 없습니다. 이전의 워크플로우(workflow)는 정말 고통스러웠습니다.

직접 설정하는 방법

약 10분 정도 소요됩니다.

Claude 프로젝트에서 대화를 시작하고 Claude에게 Notion 허브 페이지를 만들라고 지시하세요. 이름을 지정하고, 필요한 데이터베이스 속성(database properties)—유형(type), 상태(status), 태그(tags), 날짜(dates) 등 프로젝트에 적합한 것들—을 알려주세요. 그런 다음 Claude에게 기존 프로젝트 파일의 내용을 Notion 페이지로 마이그레이션(migrate)하도록 합니다.

그다음 — 중요한 부분입니다 — Claude에게 개요(overview) 파일을 생성하게 하세요. 하나의 마크다운 (markdown) 파일입니다. 이 파일에는 Notion 페이지 URL, Claude가 새로운 항목을 생성할 수 있도록 하는 데이터베이스 ID (database ID), 각 페이지가 무엇인지에 대한 요약, 그리고 프로젝트를 위한 규칙이나 가이드라인이 포함되어야 합니다.

그 개요 파일을 다운로드하세요. Claude 프로젝트에 추가합니다. 다른 모든 프로젝트 파일은 삭제하세요. 이제 파일들은 Notion에 살고 있습니다.

끝입니다. 앞으로 진행되는 모든 대화에서 Claude는 개요를 읽고, 모든 것이 어디에 있는지 파악하며, 필요한 것을 가져오고, Notion에 직접 기록합니다.

더 큰 그림

이것은 사실 Notion에 관한 것이 아닙니다. 프로젝트 파일에 관한 것도, 심지어 Claude에 관한 것도 아닙니다.

이것은 제가 어디를 보든 계속해서 나타나는 하나의 패턴에 관한 것입니다. 최고의 AI 워크플로우 (workflows)는 AI에게 모든 정보를 미리 다 주는 방식이 아닙니다. AI에게 지도(map)를 주고, 필요한 것을 직접 찾아가게 하는 방식입니다.

_"여기에 무엇이 있고 어디에서 찾을 수 있는지"_를 알려주는 가벼운 파일 하나. 그것이 핵심입니다.

그리고 솔직히 말해서, 만약 Anthropic이 결국 Claude가 프로젝트 파일을 직접 편집할 수 있도록 허용하더라도, 이 설정은 여전히 승리합니다. 왜냐하면 분리(separation) — 프로젝트에는 안정적인 지도, Notion에는 살아있는 문서 — 가 시간이 지나며 변하는 모든 것에 대해 더 나은 아키텍처 (architecture)이기 때문입니다. 당신은 지속적인 컨텍스트 (persistent context)가 작고 안정적이기를 원하며, 작업 문서 (working documents)는 가장 유연성을 제공하는 곳 어디에나 있기를 원합니다.

영토가 변할 때마다 지도가 바뀔 필요는 없습니다.

저는 Amazon과 The New York Times에서 근무했던 5년 이상의 경력을 가진 소프트웨어 엔지니어입니다. 이것은 예측이 아니라, 현장에서 얻은 관찰 결과입니다.