프롬프트 가이드
Claude로 프로젝트 제안서 작성하는 방법
승인되는 제안서는 구체적이다. 무시되는 제안서는 모호하다.
Anthropic의 Claude는 대략적인 프로젝트 아이디어를 문제 정의, 범위, 일정, 그리고 이해관계자가 실제로 승인을 하게 만드는 구체적인 세부 사항을 갖춘 구조화된 제안서로 바꾸는 데 능숙합니다. Claude가 모르는 것은 당신의 예산, 팀의 실제 역량, 조직의 내부 사정이며, 알려주지 않으면 "X에 대한 프로젝트 제안서를 써줘"라는 요청은 어느 회사에나 적용될 만큼 일반적인 결과를 내놓기 마련입니다. 해결책은 신경 쓰는 프로젝트 매니저라면 어차피 사용할 실제 제약 조건을 Claude에게 주는 것입니다: 제안서가 누구를 위한 것인지, 실제로 가진 것이 무엇인지, 그 사람에게 필요한 결정이 무엇인지입니다.
Claude에게 프로젝트 제안서를 작성시키려면 해결하려는 문제, 제안서가 누구를 위한 것이고 그들에게 필요한 결정이 무엇인지, 실제 제약 조건(팀 규모, 대략적인 일정, 예산 범위)을 알려주고, 문제 정의, 제안하는 접근법, 범위, 일정, 성공 지표로 초안을 구성하라고 지시하세요. 이미 가진 배경 자료, 이전 제안서, 메모를 붙여넣고, 구체적인 계획으로 만들기에 너무 모호한 부분을 Claude가 표시하게 하세요.
게시일
무료 레슨 · 계정 필요 없음Claude 만나기왜 Claude인가?6분무료 레슨 시작하기핵심 요약
- 제안서가 누구를 위한 것이고 그들에게 어떤 결정을 요구하는지 말하세요. 당신의 팀이 계획을 세우는 데 쓸 제안서와 임원에게 예산 승인을 요청하는 제안서는 다르게 읽힙니다.
- Claude에게 실제 제약 조건을 주세요: 팀 규모, 대략적인 일정, 예산 범위. 지어낸 제약 조건으로 만든 계획은 실제 숫자를 아는 사람이 읽는 순간 다시 써야 합니다.
- 작업 설명만이 아니라 성공 지표를 구체적으로 요청하세요. 성공했는지 어떻게 알 수 있는지 말하지 않는 제안서는 승인받기 더 어렵고 나중에 확인하기도 더 어렵습니다.
- 이미 가진 배경 자료를 붙여넣으세요: 이전 제안서, 회의 메모, 대략적인 개요. Claude는 당신이 준 것을 정리하고 다듬지만, 당신의 구체적인 프로젝트 뒤에 있는 맥락을 지어낼 수는 없습니다.
- 보내기 전에 특히 범위 섹션을 자세히 읽으세요. 실제 의도보다 모호하거나 넓은 범위는 제안서가 나중에 문제를 일으키는 가장 흔한 이유입니다.
복사해서 붙여넣기
오늘 바로 쓸 수 있는 프롬프트
대략적인 아이디어로 첫 완전한 초안 작성
[프로젝트 아이디어를 한두 문장으로 설명]을 제안하고 싶습니다. 이것은 [제안서가 누구를 위한 것이고 그들에게 필요한 결정]을 위한 것입니다. 실제로 가진 것은 다음과 같습니다: 팀 규모 [규모], 일정은 대략 [기간], 예산은 대략 [범위, 또는 '아직 미정']. 문제 정의, 제안하는 접근법, 범위(명시적으로 범위 밖인 것 포함), 대략적인 일정, 성공 지표를 포함한 제안서 초안을 작성해주세요. 제가 충분한 세부 사항을 주지 않아서 추측해야 했던 부분은 표시해주세요.
예산처럼 아직 모르는 것에 대해 솔직한 것이 공백을 채우려고 숫자를 지어내는 것보다 더 유용한 초안을 만듭니다.
정리되지 않은 브레인스토밍을 문제 정의로 바꾸기
해결하고 싶은 문제에 대한 정리되지 않은 거친 메모가 있습니다: [메모 붙여넣기]. 이것을 왜 중요한지, 누가 영향을 받는지 설명하는, 두세 문장짜리 간결한 문제 정의로 바꿔주세요. 아직 해결책은 설명하지 마세요. 해결책을 제안하기 전에 문제를 명확하게 정의하고 싶습니다.
문제 정의를 해결책과 분리해두세요. 바로 해결책으로 넘어가는 제안서는 아직 해결할 문제가 있다고 확신하지 못한 독자를 잃는 경우가 많습니다.
범위 정의하기, 범위 밖인 것 포함
제가 제안하는 프로젝트는 다음과 같습니다: [설명]. 이 프로젝트가 포함할 것과 포함하지 않을 것을 명확히 밝히는 범위 섹션을 작성해주세요. 명시적으로 범위 밖으로 표시된 구체적인 항목을 최소 세 개 포함해주세요. 제안서가 제 의도보다 더 넓게 해석되는 것을 피하고 싶습니다.
범위 밖인 것을 명시적으로 나열하는 것이 나중에 가장 많은 혼란을 막는 제안서 부분인 경우가 많습니다.
보내기 전에 제안서 강도 테스트하기
이 제안서 초안을 승인 여부를 결정하는 이해관계자처럼 읽어주세요: [초안 붙여넣기]. 이것을 승인하기 전에 어떤 질문이 있을까요? 일정, 범위, 성공 지표 중 어디가 비현실적이거나 불명확해 보이나요? 무엇이 틀렸는지만이 아니라 무엇이 빠졌는지 구체적으로 말해주세요.
이것은 초기 초안 단계보다 제안서를 보내기 직전 최종 확인으로 사용하는 것이 가장 효과적입니다.
다른 대상에 맞춰 제안서 어조 조정하기
이것은 제 팀을 위해 작성한 프로젝트 제안서입니다: [초안 붙여넣기]. 예산을 승인해야 하는 임원 대상으로 다시 써주세요: 비즈니스 사례와 비용으로 시작하고, 기술적 세부 사항은 짧게 유지하고, 구현 세부 사항은 마지막에 부록 섹션으로 옮겨주세요.
같은 프로젝트라도 누가 읽고 그 사람이 무엇을 결정해야 하는지에 따라 두 가지 다른 버전이 필요한 경우가 많습니다.
구조
제안서 프롬프트에 필요한 다섯 가지
이 다섯 가지 요소가 모호한 아이디어를 이해관계자가 실제로 행동할 수 있는 것으로 바꿉니다.
해결책 이전의 문제 정의
해결책을 설명하기 전에 문제와 그것이 왜 중요한지 밝히세요. 아직 문제가 있다고 확신하지 못한 독자는 그에 대한 제안된 해결책을 심각하게 받아들이지 않습니다.
명시적으로 범위 밖인 것을 포함한 범위
프로젝트가 무엇을 할지, 그리고 그만큼 중요한, 무엇을 하지 않을지 말하세요. 범위가 정의되지 않은 제안서는 각자의 머릿속에서 그들이 추측한 의미로 커지는 경향이 있습니다.
지어낸 것이 아닌 실제 제약 조건
일부가 아직 불확실하더라도 실제 팀 규모, 대략적인 일정, 예산 범위를 Claude에게 주세요. 지어낸 숫자로 만든 계획은 실제 숫자가 나오는 순간 다시 만들어야 합니다.
명확하게 밝힌 성공 지표
프로젝트가 성공했는지 어떻게 알 수 있을지 말하세요. 성공 지표가 없는 제안서는 확신을 갖고 승인하기 더 어렵고, 그래도 승인된다면 6개월 후 확인하기 더 어렵습니다.
독자를 알기
같은 프로젝트도 다른 대상에게는 다른 제안서가 필요하다
자신의 팀이 계획을 세우도록 작성한 제안서와 임원의 예산 승인을 받기 위해 작성한 제안서는 같은 프로젝트를 설명하더라도 다른 역할을 합니다. 팀 버전은 독자가 이미 관심을 가지고 있기 때문에 구현 세부 사항을 깊이 다룰 수 있습니다. 임원 버전은 그것이 그 독자가 실제로 내려야 하는 결정이기 때문에 비즈니스 사례와 비용으로 시작해야 하며, 불필요한 세부 사항은 당신이 요청하는 결정을 지연시킬 뿐입니다.
누가 읽고 그 사람에게 어떤 결정이 필요한지 Claude에게 명확히 말하세요. "이것은 제 팀이 다음 분기를 계획하기 위한 것"과 "이것은 기술적 세부 사항을 모르는 부사장의 예산 승인이 필요"는 같은 프로젝트라도 Claude를 두 개의 다른 초안으로 이끌며, 대상을 미리 명시하면 한 버전을 쓰고 나중에 실제 독자에게 맞지 않다는 것을 발견하는 일을 피할 수 있습니다.
두 버전이 정말 모두 필요하다면, 둘 다 처음부터 쓰는 것보다 먼저 자세한 팀 버전을 쓴 다음 Claude에게 임원 대상으로 조정해달라고 요청하는 것이 보통 더 빠릅니다. 기본 사실은 바뀌지 않습니다. 무엇을 강조하고 무엇을 부록으로 옮길지만 바뀝니다.
흔한 실수
제안서가 승인되지 않고 막히게 하는 것
이런 공백들이 합리적인 아이디어를 응답 없이 방치되는 제안서로 바꿉니다.
실제 의도보다 넓은 범위
범위 밖인 것을 명시하지 않으면 독자는 자신의 가정으로 그 공백을 채우는데, 보통 당신이 제안하려던 것보다 더 넓습니다. 이 프로젝트가 포함하지 않을 것을 명확히 말하세요.
독자가 내려야 할 결정이 명시되지 않음
실제로 무엇을 요청하는지, 승인, 예산, 인력, 시작 승인인지 말하지 않는 제안서는 독자가 어떤 응답을 해야 하는지 모르게 만듭니다.
실제 제약 조건 대신 지어낸 숫자
당신이 제공하지 않아서 Claude가 추측한 일정이나 예산은 허구임에도 자신 있게 들리고, 실제 숫자를 아는 사람은 제안서가 현실과 맞지 않는다는 것을 알아챕니다.
나중에 성공했는지 알 방법이 없음
성공 지표가 없는 제안서는 확신을 갖고 승인하기 어렵고, 그래도 승인되면 6개월 후 프로젝트가 성과를 냈는지 확인할 합의된 방법이 없습니다.
이미 가진 것 활용하기
처음부터 시작하지 말고 배경 자료를 붙여넣으세요
비슷한 것에 대한 이전 제안서, 문제에 대한 거친 회의 메모, 또는 반쯖 완성된 개요가 있다면, 기억으로 프로젝트를 새로 설명하는 대신 그것을 붙여넣으세요. Claude는 한 문장짜리 설명으로 당신의 실제 프로젝트의 구체적인 맥락, 역사, 제약 조건을 지어내는 것보다 이미 가진 자료를 정리하고 다듬는 것을 훨씬 더 신뢰할 수 있게 할 수 있습니다.
이것은 특히 문제 정의에 중요합니다. 문제가 회의에서, 고객의 불만에서, 또는 비슷한 것에 대한 이전의 실패한 시도에서 나왔다면, 그 맥락은 프롬프트에 속합니다. 현재의 요약만으로 만든 문제 정의는 문제를 실제적이고 해결할 가치가 있게 만든 구체적인 세부 사항을 잃는 경우가 많습니다.
제약 조건에도 같은 것이 적용됩니다. 조직에 이미 표준 제안서 템플릿, 이런 종류의 프로젝트에 대한 일반적인 예산 범위, 또는 평소의 일정 관행이 있다면, 일반적인 구조에 맡기지 말고 Claude에게 직접 주세요. 조직이 이런 종류의 문서를 보기를 기대하는 방식에 이미 맞는 제안서는 다른 곳의 템플릿처럼 읽히는 제안서보다 더 진지하게 받아들여집니다.
조직에서 승인된 제안서를 비공식적이더라도 계속 폴더에 모아두고, 가능할 때 성공한 제안서를 자신의 초안 옆에 붙여두는 것이 도움이 됩니다. Claude는 특정한 격식 수준, 긴 문단보다 짧은 문단을 선호하는 경향, 위험 완화부터 시작하는 습관처럼 보통 통과되는 패턴을 파악해서, 범용적인 구조에 의존하는 대신 지금 쓰고 있는 초안에 같은 패턴을 적용할 수 있습니다.
보내기 전에
제안서가 독자에게 가기 전에 확인할 것
범위 섹션을 먼저 읽고 그것이 실제로 하려는 것을 정확히 설명하는지, 더도 덜도 아니게 자문하세요. 이것은 실제 의도보다 모호하거나 넓을 경우 나중에 문제를 일으킬 가능성이 가장 높은 섹션입니다. 프로젝트가 진행되면 모두가 그것을 다시 가리키는 지점이 되기 때문입니다.
모든 숫자를 현실과 대조하세요: 일정, 팀 규모, 예산. 자신 있게 들리지만 추측한 숫자에 기반한 계획은 솔직한 "일정 아직 미확정"보다 더 나쁩니다. 전자는 누군가 읽는 순간 약속으로 취급되기 때문입니다.
여기의 구조는 강력한 초안을 빠르게 만들어주지만, 조직과 독자가 이 구체적인 제안서에 실제로 필요로 하는 것에 대한 판단은 보내기 전까지 여전히 당신의 몫입니다.
명확한 제안서는 읽힌다. 모호한 제안서는 무시된다.
이 구조는 이후의 모든 제안서에 재사용할 수 있습니다. Nightschool AI의 무료 레슨은 범위와 대상에 관한 판단을 포함해 Claude와 함께하는 실제 업무 글쓰기 작업을 다룹니다.
자주 묻는 질문
Claude가 제안서를 작성하기 전에 알려줘야 할 가장 중요한 것은 무엇인가요?
제안서가 누구를 위한 것이고 그들에게 어떤 결정을 요구하는지입니다. 당신의 팀이 계획을 세우는 데 쓸 제안서와 임원에게 예산 승인을 요청하는 제안서는 같은 프로젝트라도 다른 틀이 필요합니다.
아직 예산 숫자가 없다면 Claude에게 숫자를 줘야 하나요?
아니요. Claude가 숫자를 추측하게 하는 대신 예산이 아직 확정되지 않았다고 말하세요. 자신 있게 들리는 지어낸 숫자는 실제 숫자를 아는 사람이 보는 순간 약속으로 취급됩니다.
제안서에 범위 밖인 것을 명시하는 섹션이 왜 필요한가요?
그것이 없으면 독자는 프로젝트가 포함하는 것에 대해 자신의 가정으로 공백을 채우는데, 보통 실제 의도보다 더 넓습니다. 제외되는 것을 명시하면 그런 쏠림을 방지합니다.
제 팀과 임원 모두에게 효과적인 제안서는 어떻게 작성하나요?
먼저 팀을 위한 자세한 버전을 작성한 다음, Claude에게 임원 독자용으로 조정해달라고 요청하세요: 비즈니스 사례와 비용으로 시작하고, 기술적 세부 사항을 줄이고, 구현 세부 사항을 부록으로 옮기세요.
처음부터 시작하는 대신 이전 제안서나 회의 메모를 사용할 수 있나요?
네, 그렇게 해야 합니다. 이미 가진 배경 자료를 붙여넣으세요. Claude는 처음부터 당신의 프로젝트의 구체적인 맥락을 지어내는 것보다 실제 자료를 정리하고 다듬는 것을 훨씬 더 잘합니다.
제안서에 성공 지표가 왜 필요한가요?
성공을 측정하는 명시된 방법이 없으면 제안서는 확신을 갖고 승인하기 어렵고, 나중에 프로젝트가 약속한 것을 실제로 이루었는지 확인할 합의된 방법이 없습니다.
이해관계자에게 보내기 전에 초안을 어떻게 확인해야 하나요?
Claude에게 이해관계자처럼 읽고 승인하기 전에 가질 질문을 나열하도록 요청하세요. 그런 다음 보내기 전에 초안의 각 숫자를 실제 제약 조건과 따로 대조하세요.
조직에 이미 표준 제안서 템플릿이 있다면 어떻게 하나요?
초안을 일반적인 구조에 맡기지 말고 그것을 Claude에게 직접 주세요. 조직이 기대하는 형식에 이미 맞는 제안서는 그렇지 않은 제안서보다 더 진지하게 받아들여집니다.
승인되는 제안서는 실제 제약 조건에서 시작된다
이 구조는 매번 재사용할 수 있습니다. 추측 대신 솔직한 숫자를 주는 것이 한 번 제대로 익혀둘 가치가 있는 부분입니다.