핵심 정리

Project
  -> chats
  -> project instructions
  -> project knowledge

프로젝트 구조

Projects가 일반 대화보다 맥락 유지에 유리한 이유

Projects는 단순 폴더가 아니라 특정 주제나 업무 흐름을 위한 컨텍스트 묶음입니다. 관련 대화, 업로드 자료, project instructions, project knowledge를 한곳에 모아 두기 때문에 일반 대화보다 훨씬 안정적으로 맥락을 유지할 수 있습니다. 같은 주제로 여러 세션에 걸쳐 대화할 때 매번 배경 설명을 다시 쓰지 않아도 된다는 것이 핵심 이점입니다.

현재 Anthropic 도움말 기준으로 Projects는 유료 Claude 플랜에서 제공되며, Team/Enterprise에서는 공유 기능도 함께 다뤄집니다. 따라서 Projects를 설명할 때는 "일반 채팅보다 편하다"뿐 아니라 현재 계정이 유료 플랜인지, 팀 공유가 필요한지까지 같이 확인하는 편이 정확합니다.

project knowledge와 project instructions의 역할 차이

project knowledge는 자주 참조해야 하는 문서나 배경자료를 넣는 공간입니다. 제품 규칙, 팀 스타일, 용어집, 요구사항 문서처럼 매번 다시 설명하기 싫은 내용이 잘 맞습니다. project instructions는 Claude가 그 project 안에서 어떤 역할과 기준으로 답해야 하는지를 정하는 운영 규칙에 가깝습니다. 말투보다도 출력 형식, 검토 기준, 우선순위 같은 규칙을 넣는 편이 효과적입니다. 두 가지를 혼용하면 어떤 규칙이 어디에 있는지 파악하기 어려워집니다.

project knowledge
  -> 배경 문서
  -> 규칙 문서
  -> 반복 참조 자료

project instructions
  -> 답변 방식
  -> 출력 형식
  -> 우선순위와 역할

자료를 많이 넣는 것보다 정확히 넣는 것이 중요한 이유

너무 많은 자료를 무차별로 넣으면 오히려 중요한 기준이 흐려질 수 있습니다. project knowledge는 "반복해서 필요한 기준"만 넣는 것이 최적입니다. 한 번만 쓰고 마는 참고 자료, 이미 결론이 난 논의 기록, 현재 작업과 관련 없는 배경 문서는 project knowledge보다 개별 대화에서 그때그때 제공하는 편이 낫습니다.

Anthropic 도움말은 project knowledge가 커지면 RAG 기반으로 확장된다고 설명합니다. 다만 용량이 늘어난다고 해서 아무 문서나 계속 넣는 편이 좋은 것은 아닙니다. 검색 표면이 넓어질수록 현재 작업에서 정말 반복 참조하는 자료만 남기는 편이 여전히 중요합니다.

Projects를 주제별로 분리해야 하는 이유

하나의 Project에 관련 없는 업무를 너무 많이 넣으면 instructions와 knowledge가 충돌하거나 맥락이 뒤섞입니다. 문서 초안용, 강의 정리용, 제품 기획용처럼 목적을 분명히 나눠 Project를 만드는 쪽이 더 오래, 더 안정적으로 씁니다. 주제 경계를 명확히 하면 나중에 instructions를 업데이트하거나 knowledge를 정리할 때도 훨씬 편합니다.

언제 나눌까

주의할 점

❌ project instructions
- 회사 제품 소개 문서
- API 응답 예시 40개

❌ project knowledge
- 항상 표로 답해라
- 위험도부터 먼저 써라

이렇게 섞으면 Claude가 "무엇을 참조해야 하는지"와 "어떻게 답해야 하는지"를 구분하기 어려워집니다.