새로운 채팅을 시작할 때마다 Claude는 다시 낯선 존재가 됩니다

당신은 코드베이스를 설명합니다. 스타일 가이드 (style guide)를 붙여넣습니다. 클라이언트, 제약 조건, 그리고 어쩔 수 없이 따라야 하는 단 하나의 레거시 결정 사항을 다시 설명합니다. 그러다 채팅이 길어지면 새로운 채팅을 시작하고, 이 모든 과정을 다시 반복합니다.

이러한 재브리핑 비용 (re-briefing tax)은 AI 어시스턴트가 동료가 아닌 데모처럼 느껴지는 큰 이유 중 하나입니다. Claude Projects는 이를 제거하기 위해 존재합니다. 지침 (instructions), 파일, 그리고 컨텍스트 (context)가 한곳에 머무는 워크스페이스로서, 그 안에서 이루어지는 모든 대화는 당신의 작업을 이미 알고 있는 상태에서 시작됩니다.

프로젝트 (Project)란 실제로 무엇인가

프로젝트는 세 가지를 하나로 묶습니다:

• 커스텀 지침 (Custom instructions): 프로젝트 내의 모든 채팅에 적용되는 지침.
• 프로젝트 지식 (Project knowledge): 한 번 업로드하면 되는 파일과 텍스트 (문서, 사양서, 스키마, 스타일 가이드 등).
• 공유된 컨텍스트 경계 (A shared context boundary): 프로젝트 내에서 시작하는 모든 대화는 당신이 아무것도 붙여넣지 않아도 해당 지침과 지식을 활용할 수 있습니다.

프로젝트는 단순히 긴 채팅이 아닙니다. 그것은 하나의 방입니다. 당신이 걸어 들어가면 참고 자료는 이미 선반 위에 놓여 있고, 규칙은 벽에 붙어 있으며, 각 대화는 별도의 책상과 같습니다. 한 책상에서 배운 내용이 다음 책상으로 이어지지는 않지만, 선반과 규칙은 공유됩니다.

지침을 소망이 아닌 직무 기술서처럼 작성하세요

가장 취약한 프로젝트는 "당신은 내 스타트업을 위한 유능한 어시스턴트입니다"와 같은 지침을 가지고 있습니다. 이는 Claude가 이미 가정하고 있는 것 외에 아무것도 알려주지 않습니다.

지침을 유능한 신입 사원을 위한 온보딩 (onboarding) 과정으로 취급하세요. 역할 (role), 제약 조건 (constraints), 그리고 출력 형태 (output shape)를 다루어야 합니다:

역할 (Role): 당신은 물류 앱을 위한 Django + Postgres API 유지보수를 돕습니다.
대상 (Audience): 우리 팀의 미드 레벨 백엔드 개발자들.
규칙 (Rules):
...

제약 조건은 격려보다 더 큰 역할을 합니다. "패키지를 추가하기 전에 먼저 물어보세요"라는 문구는 "똑똑하고 철저하게 행동하세요"라는 말보다 훨씬 더 많은 잘못된 출력을 방지합니다.

지식을 큐레이션하세요, 드라이브를 통째로 쏟아붓지 마세요

모든 것을 업로드하고 싶은 유혹이 들 것입니다. 하지만 참으세요. 프로젝트 지식은 모델에게 전달하는 신호(signal)이며, 노이즈(noise)는 그 신호를 희석시킵니다. 현재의 사양서(spec) 옆에 오래된 PRD(제품 요구 사항 문서)가 놓여 있으면, 모델은 두 문서가 모두 사실인 것처럼 인용하게 됩니다.

좋은 후보: 현재의 아키텍처 개요(architecture overview), API 스키마(API schema), 스타일 가이드(style guide), 도메인 용어 사전(glossary), "좋은" 출력의 대표적인 몇 가지 예시.
나쁜 후보: 전체 회의록 아카이브, 대체된 초안, 사실로서 다시 인용되는 것을 원치 않는 모든 것.

파일에 오래된 섹션이 있다면 업로드하기 전에 다듬으세요. 당신은 폴더를 백업하는 것이 아니라, 참조용 선반을 큐레이션(curating)하는 것입니다.

맵 파일(map file)을 추가하세요

작은 파일 하나가 빠르게 제 역할을 해냅니다. 바로 _START_HERE.md와 같이 다른 모든 파일이 무엇인지, 그리고 언제 그것을 신뢰해야 하는지를 알려주는 짧은 인덱스(index)입니다.

- architecture.md : 현재 시스템 설계. 신뢰할 수 있는 단일 원천(Source of truth).
- style-guide.md  : 코드 컨벤션(code conventions). 항상 적용할 것.
- glossary.md     : 도메인 용어 ("shipment"는 "order"와 다름).
...

이렇게 하면 Claude가 소스들을 단순히 평균 내는 대신 가중치를 두어 판단할 수 있는 방법을 제공하며, 당신 또한 프로젝트에 실제로 무엇이 들어있는지 인지하게 됩니다.

최신 상태를 유지하세요 (모두가 건너뛰는 단계)

프로젝트는 수동 메모리입니다. 스스로 업데이트되는 것은 아무것도 없습니다. 스키마(schema)는 변경되었는데 파일은 변경되지 않았다면, 이제 당신의 어시스턴트는 명백한 공백보다 훨씬 더 잡아내기 어려운 방식으로 자신 있게 틀린 답을 내놓을 것입니다.

작은 습관을 만드세요. 결정 사항이 변경되면 README를 업데이트하듯, 그 내용을 기록하는 단 하나의 파일을 업데이트하세요. 오래된 컨텍스트(context)는 컨텍스트가 없는 것보다 더 나쁩니다. 왜냐하면 그것이 권위 있는 정보인 것처럼 읽히기 때문입니다.

프로젝트의 약점

사용 방식을 변화시키기 때문에, 솔직한 한계를 밝힙니다:

• 실시간 지식 베이스(Live knowledge base)가 아닙니다. 프로젝트(Project)는 사용자가 마지막으로 업로드한 내용을 반영할 뿐, 저장소(Repo)의 현재 상태를 반영하지 않습니다. 매시간 변경되는 코드의 경우, 정보의 괴리(Drift)가 빠르게 발생합니다.
• 검색(Retrieval)은 정확하지 않습니다. 방대한 지식 세트는 선택적으로 참조되며, 매 메시지마다 처음부터 끝까지 정독하지 않습니다. 느슨하게 관련된 100개의 파일보다 집중된 10개의 파일이 더 효과적입니다.
• 범위(Scope)는 경계이지 두뇌가 아닙니다. 프로젝트 간에는 컨텍스트(Context)가 공유되지 않습니다. 이는 격리(Isolation) 측면에서는 좋지만, 각 프로젝트를 수동으로 관리해야 함을 의미합니다.
• 민감한 자료는 여전히 어딘가에 저장하는 자료입니다. 프로젝트 내의 고객 데이터와 비밀 정보(Secrets)는 다른 공유 작업 공간(Shared workspace)에 적용하는 것과 동일한 주의를 기울여야 합니다.

이러한 점들이 프로젝트의 유용성을 떨어뜨리는 것은 아닙니다. 다만, 프로젝트에 의존하기 전에 그 한계를 미리 알고 있어야 할 뿐입니다.

최소한의 시작점

하나의 거대한 프로젝트(Mega-Project)를 만드는 대신, 실제 도메인(하나의 코드베이스, 하나의 클라이언트, 하나의 책)당 하나의 프로젝트를 생성하세요. 시작할 때는 세 개의 파일, 즉 지도(Map), 아키텍처 또는 개요 문서(Architecture or overview doc), 그리고 스타일 가이드(Style guide)를 준비하세요. 그리고 10줄 정도의 실제 지침(Instructions)을 작성하세요. 그다음 채팅을 시작하여 Claude가 여전히 틀리는 부분을 관찰하고, 프롬프트(Prompt)를 수정하는 대신 파일을 수정하세요.

일주일 동안 그렇게 하면 패턴이 바뀝니다. 당신은 자기소개를 멈추게 되고, Claude는 당신이 멈췄던 지점부터 다시 시작하게 됩니다.

저는 AI를 채팅 장난감에서 작업 도구로 전환하는 것에 대해 글을 씁니다. 저는 실제 실습을 통해 Claude를 배우는 게임 기반 아카데미인 AGINE Academy 구축을 돕고 있습니다. 이는 독립적인 제품이며 Anthropic과 관련이 없습니다.