AI로 주간 소식지나 제품 안내문을 만들다 보면 같은 설명을 반복하게 된다. 독자는 누구인지, 어떤 표현을 피해야 하는지, 제품 이름을 어떻게 써야 하는지를 매번 입력한다. 이전 대화를 복사하는 것으로 버티다 보면 오래된 가격표나 폐기한 문구까지 함께 따라오기도 한다.
Claude Projects는 반복 업무에 필요한 자료와 지침을 묶어 두는 데 활용할 수 있다. 이 글에서는 매주 제품 소식지를 작성하는 상황을 예로 들어 작업실을 구성한다. 아래 파일 구성과 프롬프트는 편집팀의 제안이며, 실제 작성 결과나 성능 측정치는 아니다.
기능은 2026년 10월 4일 공식 문서 확인 기준이다. 공식 안내에는 새 Projects 베타도 소개돼 있지만, 여기서는 기존 Claude 채팅의 Projects를 다룬다. 문서에 따르면 기존 프로젝트는 계속 사용할 수 있고 무료 계정도 최대 5개까지 만들 수 있다. 공식 Projects 소개

본문의 작업 과정을 표현한 AI 생성 설명 이미지입니다.
자료, 규칙, 이번 요청을 나누면 관리가 쉬워진다
처음부터 긴 만능 프롬프트를 만들 필요는 없다. 무엇이 오래 유지되는 정보이고 무엇이 이번 작업에서만 필요한 정보인지 먼저 구분한다.
| 구분 | 소식지 작성 예시 | 둘 위치 |
|---|---|---|
| 반복해서 참조할 사실 | 제품 설명, 용어집, 현재 표기 기준 | 프로젝트 지식 |
| 항상 적용할 작성 규칙 | 독자 수준, 문체, 근거 없는 주장 처리 방식 | 프로젝트 지침 |
| 이번에만 필요한 재료 | 이번 주 변경 사항, 원문 링크, 분량, 마감 | 해당 작업의 채팅 |
이렇게 나누면 이번 주 행사 날짜를 바꾸기 위해 공통 지침을 고칠 필요가 없다. 반대로 모든 글에 적용할 표기 규칙을 일회성 대화에만 남기는 실수도 줄일 수 있다.
프로젝트를 만들고 최소한의 자료부터 넣는다
Claude Projects에서 새 프로젝트를 만든다. 이름은 “제품 소식지 편집”처럼 구체적으로 정하고, 지식 영역에 참고 문서를 추가한 뒤 프로젝트 지침을 저장한다. 지식 자료와 지침을 프로젝트 내 대화에서 활용할 수 있다는 것이 기본 구조다. 프로젝트 이름과 설명만으로 작성 규칙이 전달된다고 가정하지 말고 필요한 조건은 지침에 직접 쓴다. 공식 생성·관리 안내
시작할 때는 세 종류면 충분하다. 첫째는 제품의 현재 상태를 정리한 문서, 둘째는 용어와 표기 기준, 셋째는 잘 썼다고 판단한 기존 소식지 한두 편이다. 기존 글에는 “문체 참고용이며 현재 기능의 근거가 아님”이라고 표시하는 편이 좋다.
샘플 문서가 여러 개일 때는 좋은 이유도 함께 적는다. “첫 문단에서 사용자가 얻는 변화를 설명한다”, “주장 뒤에 근거를 붙인다”처럼 따라야 할 특징을 명시해야 예전 글의 사실까지 재사용하는 일을 줄일 수 있다.
그대로 응용할 수 있는 프로젝트 지침
지침은 좋은 문장을 써 달라는 주문보다 판단 기준에 가까워야 한다. 정보가 없거나 자료끼리 충돌할 때 어떻게 처리할지를 포함하면 검토하기 쉬운 초안을 얻는 데 도움이 된다.
역할: 비개발자 고객을 위한 제품 소식지 편집자.
목표: 독자가 무엇이 바뀌었고 어떻게 사용할지 이해하도록 작성한다.
작성 기준:
- 한국어 존댓말을 쓰고 낯선 용어는 처음 나올 때 짧게 설명한다.
- 첫 문단에는 사용자가 체감할 변화와 적용 대상을 쓴다.
- 기능, 일정, 가격, 수치는 제공된 근거가 있을 때만 확정적으로 쓴다.
- 기존 소식지는 문체만 참고하고 현재 사실의 근거로 사용하지 않는다.
- 자료가 충돌하면 임의로 선택하지 말고 충돌 항목을 먼저 알린다.
- 제공되지 않은 URL이나 고객 사례를 만들지 않는다.
출력:
1. 제목 후보 3개
2. 본문 초안
3. 주장별 근거 문서와 해당 항목
4. 게시 전에 사람이 확인할 질문
저장한 뒤에는 짧은 작업 하나로 확인한다. 처음부터 한 달치 콘텐츠를 맡기기보다 기능 하나의 안내문을 작성하게 하고, 없는 정보를 만들어 내는지와 용어집을 따르는지 살핀다. 지침은 한 번에 완성하는 문서가 아니라 반복해서 보완할 기준이다.
새 글마다 바뀌는 내용은 채팅에 짧게 전달한다
공통 지침을 마련했으면 개별 요청은 이번 작업의 차이만 설명하면 된다.
이번 작업: 아래 변경 메모를 고객용 소식지로 작성해 줘.
독자: 이 기능을 처음 접하는 기존 고객.
분량: 본문 800~1,000자.
이번 글의 근거: 이 채팅에 제공한 변경 메모와 승인된 제품 설명.
변경 메모:
[담당자가 확인한 변경 사항과 적용 대상, 사용 순서를 붙여 넣기]
작성을 시작하기 전에 빠진 필수 정보가 있는지 확인해 줘.
출시일이나 사용 조건이 없으면 임의로 채우지 마.
대괄호 부분은 실제 자료로 바꿔야 한다. 근거가 충분하지 않다면 먼저 질문 목록을 받는 것이 낫다. 빈칸을 남기는 결과가 매끄러운 추정보다 수정하기 쉽기 때문이다.
문장 다듬기와 사실 확인을 나눠 한다
초안이 나오면 먼저 원문과 대조할 사실을 추출하게 한다. 출시 날짜, 이용 대상, 사용 조건, 기능 범위를 별도 표로 보면 문장 속에 숨은 단정을 찾기 쉽다.
방금 초안에서 사실 확인이 필요한 문장을 추출해 줘.
문장 | 근거 문서와 항목 | 근거의 범위 | 수정이 필요한 이유로 정리해 줘.
특히 '모든', '자동으로', '항상', '무료'가 포함된 표현을 점검해 줘.
근거가 없으면 문장을 유지하지 말고 확인 질문으로 바꿔 줘.
이 결과 역시 AI의 검토 초안이다. 최종 판단은 원문을 열어 해야 한다. 사실 검토를 마친 뒤에 문장 길이, 반복 표현, 도입부를 다듬으면 읽기 좋은 문장에 가려진 오류를 놓칠 가능성을 줄일 수 있다.
반복 작업의 효과도 초안 생성 시간만으로 판단하지 않는 편이 좋다. 사람이 사실을 고치는 횟수, 표기 수정 횟수, 최종 승인까지 걸린 시간을 함께 기록하면 지침이 실제로 도움이 되는지 알 수 있다.
오래된 자료를 관리하는 규칙도 필요하다
제품 설명이 바뀌면 새 문서를 추가하는 것으로 끝내지 말고 기존 문서와의 관계를 표시한다. “현재 기준: 10월 운영안, 9월 운영안은 변경 이력 확인용”처럼 우선순위를 명확히 한다. 서로 다른 버전이 같은 권위의 참고 자료로 남아 있으면 어떤 문장을 채택해야 하는지 모호해진다.
대화에서 확정한 표기나 편집 원칙도 다음 글에 반드시 적용해야 한다면 지침 또는 기준 문서에 반영한다. 메모리의 상태와 관계없이 중요한 기준을 명시적으로 관리하는 운영 방식이다. 관련된 검토 문제는 AI 워크슬롭을 줄이는 방법에서도 다뤘다.
자주 묻는 질문
프로젝트마다 별도 모델을 학습시키는 것인가?
이 글에서 하는 작업은 참고 자료와 작성 지침을 제공하는 것이다. 별도의 모델 학습 절차를 진행하는 방식이 아니다.
참고 문서는 많을수록 좋은가?
현재 업무에 필요한 문서와 신뢰할 기준이 우선이다. 중복 문서나 오래된 초안은 정리하고, 샘플 글과 사실 확인용 자료의 용도를 구분하는 편이 좋다.
지난 채팅에서 고친 내용을 다음 글에도 적용하려면?
계속 지켜야 할 규칙은 프로젝트 지침이나 기준 문서에 반영한다. 대화 중의 수정과 상시 적용할 원칙을 구분하면 기준이 무엇인지 사람이 확인하기도 쉽다.
지침을 저장하면 검토 없이 게시해도 되는가?
지침은 초안의 기준을 제공할 뿐 사실을 보증하지 않는다. 수치, 날짜, 기능 범위와 외부 링크는 게시 전에 원문과 대조한다.
한눈에 정리
- 프로젝트 지식에는 참고 자료, 지침에는 반복 규칙을 둔다.
- 개별 채팅에는 이번 글의 주제와 변경 사항을 전달한다.
- 샘플 글의 문체와 현재 사실의 근거를 구분한다.
- 초안에서 사실 확인 항목을 추출한 뒤 문장을 다듬는다.
- 확정된 규칙과 최신 자료를 관리해야 다음 글에도 기준이 이어진다.