클로드 프로젝트 사용법, 자료 재사용부터 바뀐 지식 반영까지

클로드 프로젝트는 같은 업무에서 계속 쓸 자료와 지침을 저장해 두는 공간이다. 기존 채팅형 화면에서는 프로젝트를 만들고, 지식에 공통 자료를 올린 뒤, 지침을 저장하고 그 안에서 새 대화를 시작한다. 무료 계정도 프로젝트를 5개까지 만들 수 있으므로 반복 첨부를 줄이는 데부터 써 보면 된다.

같은 고객 소개서를 매번 올리고 같은 문체를 설명하고 있다면 프로젝트를 만들 이유가 있다. 문서 한 편을 요약하고 끝낼 일이라면 지금 대화에 파일을 붙이면 된다. 프로젝트에는 현재 기준으로 삼을 파일과 작업 방법을 정해 두면, 다음 대화에서 다시 설명할 일이 줄어든다.

기존형은 대화 목록, 새 베타는 한 대화와 작업 스레드로 구분한다

먼저 자기 화면을 구분한다. Anthropic의 11월 6일 프로젝트 안내에는 두 버전이 함께 나온다. 기존형은 자료와 지침을 공유하는 여러 채팅을 묶는다. 새 베타에서는 프로젝트의 한 대화에 일을 보내면 Claude가 작업별 스레드로 나눠 실행하고, 파일을 Library에 모은다.

새 버전은 Pro·Max·Ultra 중 일부 계정에 순차 제공되며 Team·Enterprise에는 아직 제공되지 않는다. 기존 프로젝트도 일부 계정부터 옮겨지고 있다. 공식 안내는 지침·파일·전체 대화 기록·예약 작업을 함께 옮긴다고 설명한다. 화면이 달라졌다는 이유로 빈 프로젝트를 다시 만들기 전에 기존 자료가 어디로 옮겨졌는지 살펴본다.

새 버전의 공식 사용법은 코드 외에도 계약 문서나 고객 문의 자료를 넣어 분석하는 작업을 다룬다. 처음에는 “이 자료에서 반복 문의 유형을 찾아 문서로 만들어 줘”처럼 작은 일 하나를 맡긴다. 결과 파일은 Library에서, 작업의 자세한 답은 해당 스레드 카드를 열어 읽는다. 여러 스레드가 동시에 일하면 구독 사용량도 빨리 줄므로, 첫 요청에 “동시에 실행할 작업은 두 개까지” 같은 범위를 정할 수 있다.

프로젝트 이름을 정한 뒤, 자료는 지식에 규칙은 지침에 넣는다

기존 채팅형에서는 왼쪽 Projects 또는 claude.ai/projects에서 시작한다. 다음은 공식 생성 순서를 고객 안내 업무에 적용한 예다.

1. + New Project를 누르고 ‘고객 도입 안내’처럼 업무가 드러나는 이름과 설명을 쓴다.
2. 프로젝트 지식 영역의 +에서 회사 소개·현행 서비스 조건·승인된 안내문 같은 공통 자료를 올린다.
3. Set project instructions에 답변 규칙을 쓰고 Save instructions로 저장한다.
4. 그 프로젝트 안에서 새 대화를 열고 이번 고객의 질문을 넣는다.

이름과 설명은 사람이 프로젝트를 구분하는 표시다. 공식 문서는 Claude가 이 두 항목을 보지 않는다고 밝힌다. ‘가격은 절대 추측하지 않기’처럼 반드시 적용할 내용은 프로젝트 지침에 쓴다. Team·Enterprise에서는 생성할 때 ‘비공개로 유지’와 ‘조직 전체와 공유’ 중 공개 범위도 고른다.

에이정의 실제 번역 프로젝트 예시는 지침을 저장하고 계약서 양식을 넣어, 번역 방향을 매번 입력하지 않고 작업하는 흐름을 보여 준다. 문서만 바뀌고 처리 기준은 같은 일에 프로젝트가 어울리는 이유다. 계정 전체의 말투와 프로젝트 규칙을 나누는 방법은 맞춤 지침·프로젝트·스킬 선택 가이드로 이어진다.

첫 답변은 출처 문서와 적용일을 붙여 받아 본다

처음에는 자료가 제대로 쓰였는지 쉽게 판단할 질문을 고른다. ‘우리 서비스의 장점을 써 줘’보다 ‘현재 지원하는 도입 방식과 지원하지 않는 방식을 나눠 달라’가 원문과 대조하기 쉽다. Fresh van Root의 장기 사용기에서도 확정 견적과 회의록을 올리고, 합의한 월 서비스 비용을 출처 파일과 함께 찾는 방식으로 프로젝트를 썼다.

다음 지침은 독자가 자기 업무에 맞춰 고쳐 쓸 예시다. 실제 고객 정보 대신 회사에서 사용을 허용한 자료로 시작한다.

이 프로젝트는 고객에게 서비스 도입 조건을 안내하는 데 쓴다.
프로젝트 지식의 현행 서비스 조건을 사실의 기준으로 삼는다.
답변 순서는 가능한 일, 제한 사항, 고객에게 더 물을 내용이다.
가격·일정·지원 범위에는 참고한 파일명과 해당 절을 적는다.
자료에 없는 조건은 추측하지 말고 '추가 확인 필요'로 남긴다.
예시 안내문은 문체만 참고하고 그 안의 고객명·금액은 재사용하지 않는다.

이어 첫 대화에서 작업을 요청한다.

프로젝트 지식의 '서비스조건_2026-11-06.pdf'를 읽고
아래 문의에 보낼 답장 초안을 만들어 줘.
문의: [이번 고객의 질문]
먼저 이 문서의 적용일과 이번 답변에 쓸 지원 범위를 짚어 줘.
답장 아래에는 조건별 근거 절과 원문 문장을 짧게 붙여 줘.

초안을 받으면 실제 PDF에서 적용일과 인용한 절을 연다. 답에 파일 이름이 붙었다는 사실만으로 그 내용까지 맞는 것은 아니다. 현재 지원하지 않는 기능을 가능하다고 썼다면 해당 절을 지정해 고친다. 안내문이 완성되면 편집할 파일 형식도 요청한다. “이 답장을 수정할 수 있는 DOCX로 만들어 줘”처럼 결과를 정하면 된다. 여러 파일로 보고서를 만드는 작업은 자료를 맡겨 보고서를 완성하는 가이드가 더 자세히 다룬다.

지식은 공통 원문, 메모리는 대화에서 이어지는 맥락이다

새 대화를 열어도 프로젝트 지식과 지침을 쓸 수 있다. 여기에 현재는 프로젝트 메모리와 유료 플랜의 과거 대화 검색도 더해진다. 따라서 “프로젝트 안의 다른 채팅은 전혀 알 수 없다”는 오래된 설명을 그대로 적용하면 현재 동작을 잘못 이해하게 된다.

현행 메모리 문서에 따르면 프로젝트 안에서는 해당 프로젝트의 메모리와 프로젝트 밖의 계정 메모리를 함께 쓴다. 다른 프로젝트의 메모리는 쓰지 않는다. 계정 메모리와 완전히 분리하려면 프로젝트 페이지의 Memory → Use account memory를 끈다. 유료 플랜은 과거 대화를 검색해 구체적인 내용을 찾을 수도 있으며, 프로젝트 안 검색은 그 프로젝트로 제한된다.

그렇다고 다른 대화의 모든 문장과 첨부파일이 새 채팅에 그대로 들어오는 것은 아니다. 지식에 넣지 않은 대화 맥락은 자동 공유되지 않는다는 생성 안내와, 필요한 이전 맥락을 기억하거나 찾아오는 메모리·검색은 구분한다. 상상대로AI가 Pro 계정에서 공개한 시험에서는 첫 대화에서 기억하라고 한 문구가 두 번째 새 대화에도 붙었다. 새 채팅에서 원하는 형식이 이어지는 데 편리하지만, 처음부터 다른 관점의 답을 받으려는 작업에서는 그 기억이 영향을 준다.

예를 들어 고객과 협의한 예외 지원 기간을 다음 대화에서 참고할 수는 있다. 하지만 그 기간을 모든 고객에게 적용할 새 규칙으로 정했다면 현행 서비스 조건을 고친다. 여러 대화의 업무 상태를 관리하던 사용자의 사례에서도 대화마다 생긴 결정을 하나의 최신 문서에 모으는 일이 문제였다. 고객별 대화를 더 길게 이어 가는 것만으로 공통 기준 문서를 관리하는 일이 없어지지는 않는다.

예전 협의나 개인 취향을 가져오지 않고 자료 자체로 답을 받고 싶다면 새 대화의 첫 메시지를 보내기 전에 + → Memory를 끈다. 이 대화는 메모리를 쓰거나 새 기억을 만들지 않는다. 이미 시작한 대화에서는 설정을 바꿀 수 없으므로 새 채팅을 연다. 메모리를 꺼도 프로젝트 지식·지침을 없앤 것은 아니며, 대화 검색 설정도 별개다. 관련 설정 전체는 기록을 남기면서 메모리를 끄는 방법에서 볼 수 있다.

자료가 바뀌면 현행 파일을 정하고, 적용일을 다시 읽게 한다

정책이나 상품 조건이 바뀌었다면 새 파일을 추가하는 데서 끝내지 않는다. 어떤 파일이 현재 답변의 기준인지 정하고 이전 버전의 역할도 명시한다. PC에서 고친 파일을 프로젝트에 다시 반영하지 않았다면, 업로드된 자료는 그대로 남아 있다.

1. 새 문서 이름과 첫 페이지에 버전·적용일을 넣는다. 예를 들어 서비스조건_2026-11-06.pdf처럼 구별한다.
2. 프로젝트의 지식 또는 Library에서 새 파일이 열리는지 본다. 이전 버전은 현행 답에 필요 없으면 빼고, 비교가 필요하면 ‘이전 조건 비교용’으로 구분한다.
3. ‘이 문서만 현재 기준으로 쓰고, 바뀐 지원 범위와 적용일을 원문과 함께 알려 달라’고 요청한다.
4. 답변에 예전 조건이 남으면 최신 파일의 절을 지정해 다시 읽게 한다. 긴 대화에서 옛 숫자를 계속 인용하면 새 대화에서 최신 문서로 시작한다.

새 대화를 여는 것은 이미 읽은 낡은 조건을 계속 따라가는 일을 줄이기 위한 방법이다. 파일을 넣기만 하면 모든 기존 답변이 새 내용으로 바뀐다는 뜻은 아니다. 대화에서 만든 예전 초안도 별도로 수정해야 한다.

가상 조건 두 개로 최신 자료가 쓰였는지 연습한다

회사 자료를 넣기 전이라면 아래 내용을 각각 도입조건_v1.txt와 도입조건_v2.txt로 저장해 연습할 수 있다. 실제 서비스 정책이 아닌 가상 자료다.

자료: 도입조건 v1
적용일: 2026-10-01
기본 제공: 이메일 지원
온라인 교육: 기본 제공하지 않음
고객별 별도 약정: 이 문서에 없음

자료: 도입조건 v2
적용일: 2026-11-06
기본 제공: 이메일 지원, 온라인 교육 1회
이 문서는 도입조건 v1을 대체함
고객별 별도 약정: 이 문서에 없음

두 파일을 올리고 ‘11월 6일 새 고객에게 기본 제공하는 지원을 v2만 근거로 써 줘’라고 요청한다. 답에는 이메일 지원과 온라인 교육 1회가 들어가야 한다. ‘온라인 교육 없음’이면 이전 조건이 답에 남은 것이고, ‘교육 3회’면 자료에 없는 조건이 더해진 것이다. 적용일과 원문을 함께 받아 보면 고칠 부분이 바로 나뉜다. 이 두 항목은 예시 자료에서 정한 기대 답이다.

실제 업무 문서로 돌아가서는 아래처럼 파일 이름과 고칠 범위를 지정한다.

현행 기준은 서비스조건_2026-11-06.pdf다.
이전 문서는 변경점 비교에만 사용해 줘.
최신 파일에서 적용일과 지원 범위를 찾아 짧게 인용한 뒤,
앞서 만든 답장 중 바뀐 조건이 들어 있는 문단만 수정해 줘.
고객별 예외와 전체 고객에게 적용되는 규칙을 구분해 줘.

프로젝트의 파일을 대화에서 직접 고칠 수 있는 화면이라면 수정 후 실제 파일을 열어 적용일과 바뀐 항목을 본다. 파일 수정 기능이 없는 기존형에서는 문서를 고쳐 다시 올린다. 새 베타의 Library와 기존형의 지식 업로드를 같은 절차라고 가정하지 않고, 저장된 최종 파일을 기준으로 작업을 이어 가면 된다.

프로젝트 파일은 30MB, 자료가 많으면 유료 RAG로 필요한 부분을 찾는다

파일 업로드 도움말은 프로젝트 파일 하나의 상한을 30MB로 안내한다. 파일 개수 자체는 제한하지 않지만 전체 내용에는 컨텍스트 한도가 적용된다. 일반 채팅 첨부의 파일당 500MB·채팅당 20개와는 다른 기준이다.

유료 Pro·Max·Ultra·Team·Enterprise에서는 프로젝트 자료가 컨텍스트 한도에 가까워지면 RAG가 자동으로 켜진다. RAG는 질문과 관련된 대목을 자료에서 찾아 답에 쓰는 방식이다. 공식 안내의 확장 규모는 최대 10배다. 사용자가 별도 설치하거나 켤 필요는 없다.

자료 전체를 매번 빠짐없이 읽는 방식과는 차이가 있다. 지원 조건을 묻는다면 파일명과 항목을 지정하고, 여러 파일을 전수 비교할 때는 파일별로 결과를 나눠 받는다. ‘모든 문서에서 예외를 찾아라’고 한 번 요청한 뒤 나온 몇 건을 전체 목록으로 받아들이면 누락을 찾기 어렵다.

자료가 많아졌다는 이유만으로 분류용 프로젝트를 끝없이 만들 필요는 없다. 같은 업무에서 함께 비교해야 할 자료는 모으되, 독립된 고객의 비공개 조건이나 전혀 다른 작업 규칙을 하나의 공통 기준에 섞지 않는다. 먼저 자주 쓰는 문서 몇 개로 답이 맞는지 본 뒤 범위를 넓히면 된다.

지식에 파일이 보이는데 실제로는 읽지 못하는 경우도 있다. Sonnet 4.5 웹 사용자의 과거 제보에서는 Markdown을 올린 뒤 새 대화와 새 프로젝트에서도 검색 결과가 비었고, TXT 변환도 해결하지 못했다. 이런 증상에서는 파일명만 바꾸는 작업을 반복하기보다 필요한 대목을 대화에 직접 붙여 현재 작업을 마치고, 실패한 파일과 오류를 지원팀에 전달하는 편이 낫다.

프로젝트 공유와 대화 공유는 따로 설정한다

기존 프로젝트를 조직 구성원과 공유하는 기능은 Team·Enterprise에서 제공한다. 공유 문서의 Can view는 자료와 지침을 보고 프로젝트에서 대화할 권한이고, Can edit는 지식·지침과 구성원 설정을 고칠 권한이다. 조직 관리자가 공유를 제한할 수도 있다.

여기서 Public은 조직 전체 공개다. 프로젝트를 공유해도 각자의 대화는 직접 공유하기 전까지 비공개로 남는다. 공통 업무 기준은 프로젝트에서 공유하고, 특정 대화의 검토가 필요하면 그 대화의 공유 범위를 별도로 정한다.

이미 진행하던 일반 채팅은 대화 이름 옆 메뉴의 Add to project로 옮길 수 있다. 옮긴 대화에만 있던 중요한 첨부자료를 앞으로 여러 채팅에서 쓰려면 지식에도 넣는다. 끝난 프로젝트는 보관할 수 있지만, 보관해도 공유 권한은 유지된다. 후임자에게 업무를 넘기거나 구성원의 접근을 끊을 때는 공유 설정에서 권한을 바꾼다.

보관한 프로젝트는 Projects의 보관된 프로젝트 목록에서 … → Unarchive로 다시 꺼낸다. 삭제하려면 먼저 보관을 해제한 뒤 프로젝트 메뉴의 Delete를 고른다. 단순히 목록을 정리할 때는 보관하고, 다시 쓰지 않을 자료를 지울 때는 삭제를 선택한다.

지금 시작할 때는 반복해서 첨부하던 기준 문서 하나와 작업 규칙부터 넣으면 된다. 첫 답에서 파일의 적용일과 근거 절이 맞으면 다음 업무에도 같은 프로젝트를 쓰고, 자료가 바뀌면 현행 파일부터 교체한다. 고객별 답장과 공통 기준을 나눠 두는 것이 프로젝트를 오래 써도 정리할 일이 쌓이지 않는 출발점이다.

자료 기준: 2026년 11월 6일 Anthropic 공식 문서와 공개 사용 사례를 대조했다. 요청문과 고객 안내 구성은 적용 예시이며, 로그인한 계정에서 직접 실행한 결과나 촬영 화면은 아니다.