4부 12장. Projects — 반복 업무의 영구 자동화
AI를 쓸 때 가장 흔한 낭비는 질문을 못 해서가 아니다. 매번 처음부터 설명하는 데서 생긴다.
지난주에도 설명했고, 어제도 설명했고, 오늘도 또 설명한다. 우리 회사는 이런 톤을 쓰고, 이 보고서는 이런 형식이어야 하고, 이 숫자는 이렇게 해석해야 하며, 이 팀은 이런 걸 싫어한다고 말이다. 이렇게 일하면 Claude를 써도 결국 사람은 계속 같은 브리핑을 반복하는 관리자에 머문다.
반대로 Projects를 만드는 사람은 다르다. 그는 대화를 쌓는 것이 아니라 작업 환경을 만든다. 파일을 모으고, 지침을 정리하고, 관련 채팅을 한곳에 묶어 둔다. 그러면 다음 대화부터는 출발선이 달라진다. Claude가 매번 낯선 외주 인력이 아니라, 어느 정도 사정을 아는 팀원처럼 움직이기 시작한다.12
이 장의 핵심은 단순하다.
매번 설명하는 사람은 계속 초보다. 프로젝트를 만드는 사람이 생산성을 축적한다.
Projects는 채팅방이 아니라 작업대다
많은 사람이 Projects를 그저 "대화를 폴더에 넣는 기능" 정도로 생각한다. 하지만 실제로는 그보다 훨씬 중요하다. Project 안에는 프로젝트별 지식 자료와 지침을 넣을 수 있고, 그 안에서 시작하는 모든 채팅은 그 맥락을 공통으로 이어받는다.1
이 말은 곧 이런 뜻이다. 평소 일반 채팅에서는 "우리 회사는 B2B SaaS고, 독자는 팀장급이고, 말투는 단정하고, 보고서는 표 중심으로" 같은 설명을 매번 다시 해야 했다. 하지만 Project를 만들어 두면 이 설명이 기본값이 된다. 매번 같은 오리엔테이션을 하지 않아도 된다.2
그래서 Projects는 기억력 기능이라기보다 작업대에 가깝다. 공구가 늘 제자리에 있고, 자주 쓰는 재료가 서랍에 들어 있고, 작업 방법이 벽에 붙어 있는 책상 말이다. 좋은 작업대에서는 일의 속도가 빨라진다. 더 중요한 것은, 품질이 덜 흔들린다는 점이다.
왜 Projects가 반복 업무를 "영구 자동화"하는가
Projects는 스스로 시간을 맞춰 실행되는 스케줄러는 아니다. 알람시계보다는 잘 정리된 공방에 가깝다. 그런데도 반복 업무를 거의 자동화한 것처럼 느껴지는 이유가 있다.
첫째, 맥락을 재입력하는 비용이 사라진다. 둘째, 같은 형식의 산출물이 계속 비슷한 품질로 나온다. 셋째, 관련 채팅이 한 프로젝트 안에 남기 때문에 지난 판단과 표현을 쉽게 이어받을 수 있다.1
이 차이는 실무에서 엄청 크다. 예를 들어 주간 보고서를 생각해보자. 매주 필요한 일은 비슷하다. 회의록을 읽고, 핵심 성과를 정리하고, 리스크를 쓰고, 다음 액션을 정리한다. 그런데 일반 채팅으로 하면 매주 같은 설명을 반복한다. 반면 Project를 만들어 두면 Claude는 이미 보고서 예시, 팀 용어, KPI 정의, 금지 표현, 독자 수준을 알고 있다. 당신은 이번 주 데이터와 메모만 얹으면 된다.
그러니 Projects의 자동화는 버튼 자동화가 아니라 맥락 자동화다. 손이 아니라 설명을 줄여 준다. 실무자에게는 이쪽이 훨씬 오래 간다.
프로젝트를 이루는 세 가지 축
잘 만든 Project는 대개 세 가지가 분명하다.
지침: 이 프로젝트에서 Claude가 어떤 역할로, 어떤 기준으로 일해야 하는가
자료: 매번 참고해야 하는 문서, 예시, 템플릿, 기준표가 무엇인가
대화: 이 프로젝트 안에서 어떤 판단과 수정이 이미 이루어졌는가
이 셋 중 하나만 비어도 효과가 반쪽이 된다. 지침만 있고 자료가 없으면 공허한 원칙론이 된다. 자료만 있고 지침이 없으면 Claude가 무엇을 중요하게 봐야 할지 모른다. 대화가 축적되지 않으면 이전 결정이 자꾸 증발한다.
Projects를 만들 때는 이 세 가지를 한 번에 떠올리는 습관이 좋다. "무슨 파일을 올릴까?"만 생각하지 말고, "무슨 기준으로 읽게 할까?"와 "이후 대화는 어디에 쌓일까?"까지 같이 봐야 한다.
프로젝트 만들기: 이름보다 역할이 먼저다
Claude에서 Project를 만들면 그 안에 채팅을 시작하고, 프로젝트 지식 자료를 올리고, 프로젝트별 지침을 둘 수 있다. 이미 따로 진행하던 채팅도 나중에 Project로 옮길 수 있다.1
여기서 중요한 것은 이름을 멋지게 짓는 일이 아니다. 역할을 선명하게 정하는 일이다. 실무에서는 다음처럼 만드는 편이 좋다.
"마케팅팀 전체 업무"처럼 너무 넓게 잡지 말 것
"대표님 보고용 주간 보고서"처럼 독자와 산출물이 드러나게 만들 것
"채용공고 작성"과 "면접 평가 정리"처럼 서로 다른 판단 기준은 분리할 것
예를 들어 "브랜드 콘텐츠"라는 Project는 나쁘지 않지만 아직 조금 넓다. 반면 "링크드인 B2B 콘텐츠 제작"은 더 좋다. 독자, 채널, 결과물이 보이기 때문이다. Project는 범용 저장창고가 아니라 반복 업무용 전용 공구함이어야 한다.
프로젝트를 만든 뒤에는 오른쪽 지식 공간에 핵심 파일을 넣고, 프로젝트 지침을 적는다. 여기서 지침은 사실상 그 프로젝트의 시스템 프롬프트라고 생각하면 된다. 매번 다시 말하기 싫은 규칙은 여기에 써 두는 것이다.1
파일 업로드는 많이보다 정확하게
Project의 지식 공간에 자료를 올리면 그 자료는 해당 프로젝트의 모든 채팅에서 공통 맥락으로 활용된다.1 이 기능이 강력하다고 해서 자료를 무조건 많이 넣는 것은 좋지 않다. 서랍에 물건이 너무 많으면 찾는 데 오래 걸리는 것과 같다.
잘 들어가는 자료는 따로 있다.
최근에 실제로 사용한 우수 산출물 2~5개
형식 기준이 분명한 템플릿
용어 정의서, KPI 정의표, 제품 소개서 같은 기준 문서
하지 말아야 할 표현이나 금지 규칙을 적은 짧은 문서
반대로 잘 안 맞는 자료도 있다. 오래돼서 지금 방식과 맞지 않는 문서, 서로 충돌하는 예시, 목적이 다른 자료를 한꺼번에 넣는 경우다. 예를 들어 친근한 사내 공지 예시와 엄격한 대외 보도자료 예시를 같은 Project에 섞어 놓으면, Claude도 톤을 애매하게 섞기 쉽다.
핵심은 "많이 학습시킨다"가 아니라 "좋은 기준을 선별한다"다. AI는 무작정 많은 자료보다, 충돌 없는 기준을 더 잘 따른다.
프로젝트 지침은 길이보다 운영 원칙이 중요하다
초보자는 Project 지침을 장황하게 쓰는 경향이 있다. 회사 소개, 서비스 역사, 비전, 문화, 좋은 말들을 길게 붙인다. 물론 나쁘진 않다. 하지만 실제 산출물 품질을 바꾸는 것은 멋진 소개문보다 운영 원칙이다.
좋은 프로젝트 지침은 대개 이런 내용을 담는다.
Claude의 역할
주요 독자
기본 산출물 형식
반드시 지켜야 할 제약
불확실할 때 우선하는 판단 기준
예를 들어 주간 보고서 Project라면 이렇게 쓸 수 있다.
당신은 운영팀장의 보고서 보조 담당자다.
독자는 대표와 임원진이다.
산출물은 항상 "이번 주 핵심 성과 / 수치 변화 / 리스크 / 다음 주 액션" 순서를 따른다.
문장은 짧고 단정하게 쓴다. 과장 표현, 감탄 표현, 추측성 표현은 금지한다.
숫자가 없으면 성과처럼 쓰지 말고, 확인 필요 항목으로 표시한다.
회의 메모가 모호하면 임의 보완하지 말고 빈칸 후보나 확인 질문으로 처리한다.
이 정도면 충분히 강하다. 길게 세계관을 설명하는 것보다 훨씬 실무적이다.
그리고 지침에는 "무엇을 잘할지" 못지않게 "무엇을 하지 말지"를 넣는 것이 좋다. AI는 금지선이 보일 때 더 안정적으로 움직인다.
실무 사례: "주간 보고서 자동화" 프로젝트 구축
이제 가장 실전적인 예를 보자. 이름하여 "주간 보고서 자동화" Project다. 이건 거의 모든 팀이 바로 응용할 수 있다.
먼저 이 Project의 목적부터 분명히 한다. 목표는 매주 월요일 아침이나 금요일 저녁마다 30~60분씩 잡아먹던 보고서 초안 작업을 10분 안쪽으로 줄이는 것이다. 완전 무인 자동화가 아니라, 초안 생성과 형식 정리를 거의 반자동으로 만드는 것이 목적이다.
1단계. 프로젝트 범위를 좁힌다
프로젝트 이름은 "운영팀 주간 보고서"처럼 작게 잡는다. 회사 전체 보고 체계를 한 Project에 다 넣으려 하지 않는다. 한 Project에는 한 종류의 반복 산출물만 넣는 편이 훨씬 안정적이다.
2단계. 기준 파일을 넣는다
지식 공간에는 보통 다음 자료를 넣는다.
최근 3주치 실제 보고서
KPI 정의표
팀별 담당 업무 표
자주 쓰는 숫자 출처 안내 문서
보고서 템플릿 또는 예시
여기서 가장 중요한 자료는 "잘 쓴 예시"다. AI는 추상적인 설명보다 좋은 샘플에서 훨씬 빨리 감을 잡는다.
3단계. 프로젝트 지침을 쓴다
지침에는 보고서의 독자, 순서, 금지 표현, 숫자 처리 원칙을 넣는다. 특히 "확인되지 않은 내용은 단정하지 말 것" 같은 문장을 넣어 두면 환각성 문장을 줄이는 데 도움이 된다.
4단계. 입력 루틴을 정한다
매주 같은 순서로 자료를 넣는 습관을 만든다. 예를 들어 회의록, 주요 지표 캡처, 담당자 메모, 이슈 리스트를 넣고 이렇게 요청한다.
이번 주 자료를 바탕으로 운영팀 주간 보고서 초안을 작성해줘.
형식은 프로젝트 기본 템플릿을 따르고, 지난주 대비 변화가 드러나게 써줘.
숫자가 불명확한 항목은 억지로 메우지 말고 확인 필요로 표시해줘.
마지막에는 임원 확인이 필요한 이슈 3개를 따로 뽑아줘.
여기까지 오면 거의 끝이다. Claude는 이미 프로젝트 안에서 템플릿, 말투, 기준을 알고 있으니 이번 주 정보만 반영하면 된다.
5단계. 사람이 마지막 결재자 역할만 한다
초안을 받은 뒤에는 전체를 다시 쓰게 하지 말고 부분 수정만 시킨다. 예를 들어 "리스크 부분을 더 보수적으로", "성과 항목에서 숫자 없는 문장은 삭제", "대표 보고용으로 한 문장 더 짧게"처럼 좁혀서 요청한다.
이 과정을 두세 번 반복하면 놀라운 일이 생긴다. Project 자체가 점점 팀의 보고서 운영 매뉴얼처럼 변한다. 처음 몇 주는 세팅 비용이 있지만, 이후부터는 매주 시간을 벌어 준다. 이것이 생산성의 축적이다.
관련 채팅을 프로젝트 안으로 옮겨라
Projects를 잘 쓰는 사람은 새 채팅만 Project에서 시작하지 않는다. 이미 따로 진행하던 채팅도 적절한 프로젝트로 옮긴다. Claude는 독립 채팅을 나중에 Project로 이동시킬 수 있고, 필요하면 다시 제거하거나 다른 프로젝트로 옮길 수도 있다.1
이 기능이 왜 중요할까. 같은 주제의 대화가 프로젝트 안에 모이면, 이후 작업의 판단 맥락이 더 선명해지기 때문이다. 예를 들어 "이번 분기 운영 이슈 정리", "임원 피드백 반영", "보고서 톤 수정"이 모두 같은 Project 안에 들어 있으면, 다음 번 초안은 이전의 수정 방향을 더 자연스럽게 이어받는다.
특히 Team이나 Enterprise 환경에서 메모리 기능을 쓰는 경우에는, 어떤 채팅을 어느 Project 안에 두느냐가 프로젝트별 메모리 요약에도 영향을 준다. 다시 말해, 잡담이 섞인 채팅을 잘못 넣어 두면 프로젝트의 집중력이 흐려질 수 있다.1
그러니 원칙은 간단하다. 관련 없는 대화는 빼고, 계속 이어질 판단만 남겨라. Projects는 저장소가 아니라 편집된 맥락이어야 한다.
팀 공유 프로젝트 운영 노하우
Team 또는 Enterprise에서는 Project를 다른 구성원과 공유할 수 있다.1 이 기능은 편리하지만, 아무렇게나 열어 두면 곧 지저분해진다. 팀에서 운영할 때는 몇 가지 규칙이 필요하다.
첫째, 프로젝트 오너를 정하라. 모두가 조금씩 수정할 수는 있지만, 기준 파일과 지침의 최종 책임자는 한 명이어야 한다. 그래야 톤과 규칙이 흔들리지 않는다.
둘째, 지식 공간에는 "현재 기준"만 남겨라. 예전 템플릿과 새 템플릿을 함께 두면 팀원도 헷갈리고 Claude도 헷갈린다.
셋째, 공유 Project는 업무 단위로 나눠라. "영업팀 전체"보다는 "제안서 초안", "고객 반론 대응", "주간 파이프라인 리포트"처럼 쓰임새가 선명한 프로젝트가 좋다.
넷째, 잘 쓰는 프로젝트는 별표로 고정해 접근성을 높여라. 자주 여는 Project를 매번 찾는 것도 은근히 시간을 잡아먹는다.1
다섯째, 끝난 프로젝트는 지우기보다 보관하는 편이 낫다. Claude는 Project를 아카이브해 목록을 정리할 수 있다. 계절성 업무나 종료된 캠페인은 아카이브해 두면 나중에 비슷한 일을 할 때 아주 좋은 참고창고가 된다.1
좋은 공유 Project는 팀의 공통 감각을 저장한다. 결국 팀이 AI를 잘 쓰는 상태란, 누구 한 명만 프롬프트를 잘 쓰는 상태가 아니라 좋은 기준이 공유된 상태다.
Projects가 실패하는 다섯 가지 패턴
Projects는 좋아 보이는데 막상 써보면 별 효과가 없다고 느끼는 경우가 있다. 거의 늘 같은 이유다.
너무 넓게 만든다: 하나의 Project에 마케팅, 영업, 운영, 인사를 다 넣는다.
자료를 잡동사니처럼 올린다: 오래된 문서와 새 문서가 섞여 기준이 충돌한다.
지침이 모호하다: "전문적으로 잘 써줘" 같은 말만 있고 판단 기준이 없다.
대화를 정리하지 않는다: 관련 없는 채팅이 계속 쌓여 프로젝트 성격이 흐려진다.
초안을 그대로 납품한다: 사람이 마지막 검토를 안 해서 숫자와 뉘앙스 사고가 난다.
이 다섯 가지만 피하면 대부분의 Project는 금방 쓸 만해진다. 특히 첫 번째와 두 번째가 치명적이다. AI는 똑똑하지만, 뒤죽박죽인 서랍을 마법처럼 정리해 주지는 않는다.
Projects와 Artifacts를 함께 써야 진짜 강해진다
11장에서 본 Artifacts가 "결과물을 꺼내는 기능"이었다면, Projects는 "그 결과물이 계속 비슷하게 잘 나오게 만드는 작업 환경"이다. 둘은 경쟁 관계가 아니라 앞뒤 관계다.
Projects 없이 Artifacts만 쓰면, 눈에 보이는 결과물은 잘 나오지만 매번 다시 설명해야 한다. 반대로 Artifacts 없이 Projects만 쓰면, 맥락은 좋은데 최종 산출물이 대화창에 머물기 쉽다.
실무에서는 이렇게 연결하면 좋다. Project 안에서 자료와 지침을 축적하고, 그 맥락을 바탕으로 매주 보고서 초안을 만든 뒤, 최종 공유본은 Artifact 형태로 뽑는다. 그러면 앞단은 반복 가능해지고, 뒷단은 공유 가능해진다. 일종의 작은 생산 라인이 생기는 셈이다.
결국 Projects는 미래의 나를 위한 위임장이다
많은 사람이 AI를 쓸 때 매번 당장의 답만 받으려 한다. 물론 급할 때는 그게 맞다. 하지만 실무 생산성이 커지는 순간은 따로 있다. 오늘의 설명이 내일도 재사용될 때다.
Projects는 그 재사용성을 만든다. 파일, 지침, 관련 대화를 하나의 작업 단위로 묶어 두면, Claude는 점점 더 당신 팀에 맞는 방식으로 일한다.12
그러니 이렇게 생각해 보자. Project를 만든다는 것은 AI에게 일을 한 번 시키는 것이 아니다. 다음 주의 나, 다음 달의 팀원, 새로 합류한 동료까지 대신 도와줄 작업 환경을 미리 만들어 두는 일이다.
매번 설명하는 사람은 늘 바쁘다. 하지만 프로젝트를 만드는 사람은, 바쁜 와중에도 자기 생산성을 쌓아 간다.
그리고 실무에서는 대개 그런 사람이 끝까지 강하다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.