Claude Projects 사용법: 자료와 지침을 정리하는 실용적인 방법

핵심 요약: Claude Projects는 한 주제의 자료와 지침을 모아 관련 대화에서 활용할 때 유용합니다. 파일을 많이 넣는 것보다 기준 자료를 분명히 정하고, 오래된 파일과 현재 파일을 구별하는 일이 먼저입니다. 이 글의 파일 이름과 질문은 자료 관리 방법을 설명하기 위해 만든 예시입니다.

1. 프로젝트를 나눌 기준 정하기

공식 안내에 따르면 프로젝트 지식에 올린 자료는 그 프로젝트의 여러 대화에서 문맥으로 사용됩니다. 프로젝트 지침도 관련 대화에 적용할 수 있습니다. 반면 개별 대화의 모든 내용이 곧바로 다른 대화의 기준 자료가 된다고 생각해서는 안 됩니다. 자세한 동작은 Projects 공식 안내를 확인하세요.

프로젝트는 “모든 업무”처럼 넓게 잡기보다 “초보자용 윈도우 글”, “팀 공지 문안”, “제품 설명 정리”처럼 같은 자료와 말투를 반복해서 쓰는 단위로 나누세요. 주제가 달라도 기준 문서와 검토 방식이 같다면 함께 두어도 되지만, 서로 다른 독자나 규칙이 자주 충돌한다면 분리하는 편이 관리하기 쉽습니다.

2. 업로드하기 전에 자료 목록부터 만들기

파일 이름에 내용과 기준 날짜가 드러나게 적으세요. “자료.pdf” 세 개보다 “설치안내_2026-10-01.pdf”, “용어표_검토본.txt”, “글작성규칙_현재.md”가 구분하기 좋습니다. 날짜는 문서 발행일인지, 내가 저장한 날인지 목록에서 설명해야 합니다. 날짜가 최신이라는 이유만으로 내용이 공식 기준이 되는 것은 아닙니다.

자료	용도	관리 메모
용어표_검토본.txt	표기 통일	검토한 용어만 포함
설치안내_현재.pdf	설치 절차 확인	원문 주소와 확인일 기록
독자질문_익명.txt	글 주제 선정	이름과 계정 정보 제거

이 표는 권장 폴더 구조가 아니라 사람이 자료를 점검하기 위한 목록입니다. 출처 URL, 문서 제목, 사용 범위, 폐기할 이전 버전까지 함께 기록하면 AI 답변을 검토할 때 다시 원문을 찾기 쉽습니다. 스캔 상태가 나쁘거나 누락된 페이지가 있는 파일은 업로드 전에 표시해 두세요.

3. 프로젝트 지침은 판단할 수 있는 문장으로 쓰기

“좋은 글을 써 줘” 대신 답을 보고 지켰는지 판단할 수 있는 규칙을 적어 보세요. 지침은 편집 방식과 독자 수준을 설명하는 데 쓰고, 매번 바뀌는 글의 주제나 날짜는 개별 대화에 넣는 방식이 이해하기 쉽습니다.

대상 독자: AI 도구를 처음 쓰는 한국어 사용자.
문체: 짧은 문장과 일상적인 표현을 사용한다.
자료: 제공한 문서에서 확인된 사실과 제안 예시를 구분한다.
검토: 기능·조건·날짜 주장에는 확인할 원문 위치를 붙인다.
금지: 없는 사용 후기, 실행 결과, 수치, 고객 사례를 만들지 않는다.
불명확한 내용: '자료에서 확인되지 않음'으로 표시한다.

이 지침은 작성 방향을 정하는 예시입니다. 실제 정확성을 보장하는 설정은 아니므로, 파일의 최신 여부와 결과의 근거는 사람이 검토해야 합니다. 지침끼리 모순되는지도 확인하세요. “무조건 짧게”와 “모든 단계 상세 설명”을 동시에 적었다면 독자에게 필요한 단계는 자세히, 배경 설명은 짧게처럼 우선순위를 바꾸면 됩니다.

4. 첫 질문에서 자료를 제대로 찾았는지 점검하기

처음부터 완성된 글을 요청하지 말고 기준 자료 목록을 정리하게 해 보세요. “설치 안내에 사용할 문서를 찾고, 제목·기준 날짜·설치 대상 운영체제·확인되지 않은 항목을 표로 보여 줘”라고 요청할 수 있습니다. 답에 실제 업로드한 문서가 있는지, 날짜가 문서에서 나온 것인지 먼저 비교합니다.

자료가 맞으면 작업을 진행하고, 틀리면 새 글을 만드는 단계로 넘어가기 전에 바로잡으세요. 최종 답에서는 어떤 문서를 썼는지와 어느 부분이 제안인지 구분하도록 요청하면 검토 시간을 줄이는 데 도움이 될 수 있습니다. 이는 정리 절차에 대한 제안이며, 처리 속도나 정확도 개선을 측정한 결과는 아닙니다.

5. 자료를 바꿀 때 이전 답도 함께 점검하기

공식 문서가 바뀌면 새 파일을 추가하는 것으로 끝내지 말고, 이전 버전이 기준으로 남아 있는지 확인하세요. “현재 기준 자료는 A이며 B는 참고용”이라는 설명을 명확히 하거나, 불필요한 파일을 정리합니다. 파일 이용 조건과 처리 방식은 업로드 공식 안내에서 다시 확인할 수 있습니다.

기존 글에 들어간 설치 명령, 지원 조건, 버튼 이름처럼 변하기 쉬운 부분을 목록으로 남겨 두세요. 자료 업데이트 때 그 목록을 대조하면 어떤 글을 다시 확인해야 할지 결정하기 쉽습니다. 프로젝트에 자료를 모았다는 사실과 블로그 글이 최신이라는 사실은 각각 따로 확인해야 합니다.

6. 일반 대화·프로젝트 지식·지침을 선택하는 기준

자료를 어디에 놓을지 고를 때는 “다음 대화에서도 원문을 같은 기준으로 쓸 것인가?”를 먼저 생각하세요. 한 번만 문장을 고치는 자료와 여러 글에서 반복할 용어표를 같은 방식으로 관리할 필요는 없습니다. 프로젝트 지식은 공통 자료, 지침은 작업 방법이라는 역할로 나누면 이해하기 쉽습니다.

넣으려는 내용	권장 사용 위치	구체적인 이유
오늘만 다듬을 공지	개별 대화의 자료	다음 글의 공통 근거가 아님
여러 글에 쓸 검토된 용어표	프로젝트 지식	표기 근거를 반복 참조
독자 수준과 문체	프로젝트 지침	어떤 방식으로 답할지 규정
이번 글의 분량과 주제	개별 질문	작업마다 바뀌는 요청
이전 대화에서 정한 운영 원칙	검토 후 기준 문서에 반영	요약된 기억과 원문 근거를 구별

프로젝트 메모리와 프로젝트 지식은 구별해서 확인하세요. 이를 사용한다고 대화 전체가 문서 원문처럼 그대로 공유되는 것으로 이해해서는 안 됩니다. 꼭 지켜야 할 기준 날짜, 승인된 표현, 확정된 결정은 사람이 검토한 자료로 정리하면 이후 답의 근거를 찾기 쉽습니다.

7. 가상 기술 블로그 프로젝트를 준비하는 예시

다음은 초보자용 기술 글을 작성하는 가상의 프로젝트입니다. 특정 업체의 내부 자료나 실제 운영 기록이 아닙니다. 프로젝트에 무엇을 넣을지 설명하기 위해 짧은 기준 문서를 직접 구성했습니다.

[독자와 편집 기준.md]
독자: Windows에서 파일과 폴더를 다룰 수 있는 초보자.
목표: 기능 소개 뒤에 자료 준비와 실행 후 확인을 설명한다.
표기: PowerShell은 영문 그대로 적는다.
예시: 실제 경험이 아니면 가상 예시라고 표시한다.
가격·이용 조건: 공식 원문과 확인일이 있어야 사실로 쓴다.

[자료 목록.txt]
S1: 공식 설치 안내 / 제목 / 원문 URL / 확인일
S2: 공식 파일 업로드 안내 / 제목 / 원문 URL / 확인일
S3: 독자 질문 모음 / 익명화 완료 / 외부 공개 범위 확인

문서 ID인 S1·S2는 이 예시에서 사람이 붙인 이름입니다. Claude의 특별한 명령어나 자동 추적 기능이 아닙니다. 원문을 나누어 관리할 때 파일 이름과 출처 ID가 연결되도록 쓰면 질문에서 “S1의 설치 조건”처럼 특정할 수 있습니다. ID만 주고 해당 자료를 제공하지 않으면 내용이 전달되지 않습니다.

1. 기준 문서에 개인정보와 비밀값이 없는지 읽습니다.
2. 출처 목록에서 URL과 저장한 문서 제목이 같은지 비교합니다.
3. 기준 자료를 프로젝트 지식에 추가하고 작업 지침은 별도로 적습니다.
4. 첫 대화에서 실제 읽을 수 있는 자료 목록과 누락된 파일을 묻습니다.
5. 답의 파일 이름과 기준 날짜를 자료 목록과 대조한 뒤 글 작성을 시작합니다.

자료 목록에는 “확인일”과 “발행일”을 따로 두세요. 오늘 저장한 오래된 안내를 최신 발행 문서라고 쓰는 실수를 줄일 수 있습니다. 안내가 개정되면 같은 파일 이름으로 덮어쓸지 새 버전으로 남길지 정하고, 이전 버전의 참고 목적도 명시합니다.

8. 서로 다른 자료가 충돌할 때 해결하는 방법

가상의 파일 A에는 “공지 문의는 이메일로 받는다”, 파일 B에는 “새 문의는 게시판으로 받는다”가 적혀 있다고 가정해 보겠습니다. AI에게 “알아서 최신 것을 골라”라고 요청하기 전에 적용 시작일과 문서의 승인 상태를 비교해야 합니다. 날짜가 늦은 파일이 초안이라면 기존 확정 문서보다 우선한다고 단정할 수 없습니다.

자료 A와 B의 문의 경로가 서로 다릅니다.
파일을 수정하지 말고 아래 표를 먼저 작성하세요.
- 파일명 / 문서 상태 / 적용 시작일 / 해당 원문 위치
- 일치하는 규칙 / 충돌하는 규칙
원문에 상태나 날짜가 없으면 '미확인'으로 표시하세요.
임의로 우선순위를 만들지 말고 내가 결정해야 할 질문을 남기세요.
내가 현재 기준을 선택한 뒤에만 공지 초안을 작성하세요.

검토 항목	가상 자료에서 찾은 내용	다음 조치
A의 상태	확정 문서라고 표시	실제 적용 여부 확인
B의 상태	초안이라고 표시	승인 전 사실로 사용하지 않기
B의 적용 시작일	원문에 없음	담당자가 일정 결정

이 표는 작성자가 만든 판단 예시입니다. 실제 프로젝트에서 이런 충돌이 발견되었다는 뜻은 아닙니다. 원칙을 정한 뒤에는 “현재 문의 경로는 A를 따른다. B는 승인 전 참고 자료”를 기준 문서에 반영하고, 다음 대화에서도 그 문서를 참조하도록 요청할 수 있습니다.

9. 자료 확인부터 글 초안까지 이어지는 질문 묶음

[1단계: 자료 확인]
이번 글은 파일 업로드 방법 안내입니다.
프로젝트 지식에서 관련 자료를 찾고,
문서 제목 / 확인일 / 지원 조건 / 원문 위치를 정리하세요.
가격과 모델 비교는 이번 범위에서 제외하세요.

[2단계: 설명 설계]
확인한 자료만으로 초보자가 따라 할 순서를 제안하세요.
자료 준비, 기능 선택, 결과 검토, 문제 해결로 나누세요.
공식 사실과 작성자가 제안하는 예시는 표시를 달리하세요.

[3단계: 초안 작성]
내가 검토한 순서를 바탕으로 글을 작성하세요.
아직 확인하지 못한 조건은 본문에서 단정하지 마세요.
새로 추가한 사실이 있다면 그 근거를 별도 목록으로 보여 주세요.

단계를 나눈 이유는 매번 같은 일을 세 번 시키려는 것이 아닙니다. 출처를 잘못 골랐거나 독자 수준을 잘못 잡았을 때 긴 원고를 모두 다시 쓰지 않도록 중간 판단을 남기는 방식입니다. 자료 선택과 구조가 이미 확정되어 있다면 이를 한 질문으로 합쳐도 됩니다.

자료 관리에서 막힐 때 보내는 후속 요청

• 옛 자료를 사용함: “이전 설치 안내는 참고용입니다. 현재 기준 파일을 지정했으니 그 파일의 조건으로 설치 절만 다시 쓰세요.”
• 출처가 불명확함: “각 사실 뒤에 사용한 파일명과 원문 소제목을 표시하세요. 찾지 못한 문장은 미확인으로 옮기세요.”
• 지침을 내용으로 오해함: “편집 지침의 예시 문장은 제품 사실이 아닙니다. 기능 설명의 근거는 출처 자료에서만 가져오세요.”

완성 글과 자료 목록을 함께 검토하면 다음 갱신의 출발점이 생깁니다. 용어표 수정만 필요한지, 설치 조건이 바뀌어 설명 자체를 다시 써야 하는지도 구분할 수 있습니다.

자주 묻는 질문과 실수 해결

다른 대화에서 한 말을 기억하나요? 프로젝트 지식과 개별 대화 내용을 같은 것으로 취급하지 말고, 반복해서 사용할 결정 사항은 기준 자료로 정리하세요. 프로젝트 메모리가 켜져 있으면 해당 프로젝트의 대화 요약을 활용할 수 있지만, 업로드한 원문을 공통 자료로 사용하는 프로젝트 지식과는 별개입니다. 원문에 없는 답이 나오면요? 사용한 파일과 근거 문단을 요청한 뒤 직접 열어 대조하세요. 프로젝트 이름만으로 목적이 전달되나요? 작업 목적과 응답 규칙은 지침이나 질문에 직접 적는 편이 분명합니다.

공식 출처와 확인일

• How can I create and manage projects?
• Upload files to Claude

공식 문서 확인일: 2026년 10월 3일. 화면과 제공 조건은 이후 바뀔 수 있습니다.