올해 가장 까다로운 임원 회의를 준비하기 위해 사용한 프롬프트 — 상세 분석
The prompt I used to prep for the most contentious executive meeting I've had this year — full breakdown
핵심 요약
PMO 디렉터가 Claude를 활용해 임원 회의 전략을 수립하고 성공적으로 이끈 프롬프트 엔지니어링 사례.
- RACE 프롬프트 구조 — 역할, 행동, 맥락, 기대를 명확히 정의하여 AI로부터 실질적인 회의 전략을 도출함.
- 데이터 기반 의사결정 — 대시보드와 시뮬레이션을 통해 엔지니어링 역량과 비즈니스 가치를 시각화하여 설득력을 높임.
- 임원 대응 전략 — 회의 중 발생할 수 있는 반대 의견에 대비한 스크립트를 미리 작성하여 방어적인 태도를 피함.
- 업무 효율성 증대 — AI를 활용한 스캐폴딩으로 3일 걸릴 준비 과정을 90분으로 단축함.
저는 PMO 디렉터입니다. 지난주, 저는 엔지니어링 팀에 요구하는 모든 일을 다 할 수는 없다는 사실을 임원진과 제 상사에게 전달해야 하는 회의에 참석해야 했습니다.
그 회의는 시작 전부터 "분위기가 험악해질 것"이라는 예감이 들었습니다.
제가 회의에 들어가기 전 한 일은 다음과 같습니다.
준비 과정
저는 이미 데이터 측면에서 힘든 작업을 마쳤습니다. Microsoft Project 계획을 가져와 내보내기를 실행했고, Claude가 모든 활성 작업, 각 작업에 연결된 비즈니스 가치를 보여주는 대시보드를 구축하게 했습니다. 또한 임원들이 프로젝트를 켜고 끄면서 엔지니어링 역량이 실시간으로 어떻게 변하는지 확인할 수 있는 토글 시스템도 만들었습니다. 일정 위험에 대한 몬테카를로 시뮬레이션과 지연 시나리오까지 모두 포함했습니다.
하지만 데이터만으로는 이미 마음을 굳힌 사람들을 설득할 수 없습니다. 저에게는 회의 전략이 필요했습니다. 단순히 프레젠테이션뿐만 아니라, 회의에서 공격적으로 변하지 않도록 제 마음가짐도 다잡아야 했습니다.
그래서 저는 제 앱인 RACEprompt를 사용하여 구조화된 프롬프트를 만들었습니다. RACEprompt는 역할(Role) / 행동(Action) / 맥락(Context) / 기대(Expectation)를 중심으로 구축되어, AI에게 모호한 질문을 던지는 대신 무엇을 얻고자 하는지 실제로 고민하게 만듭니다. 제 앱임에도 불구하고, 프롬프트 작성 전에 "임원진으로부터 보통 어떤 유형의 응답을 받습니까?"와 같은 객관식 질문을 통해 "더 많은 자원이 필요합니다" 또는 "현재 자원으로 모두 실행할 수 있어야 합니다"와 같은 선택지를 제공해 준 점이 만족스러웠고, 덕분에 임원진을 위해 이 프롬프트를 구체적으로 구성하기 쉬웠습니다.
제가 실행한 프롬프트:
이 구조가 효과적이었던 이유
몇 가지 강조하고 싶은 점이 있습니다.
**역할(Role)**은 단순히 "당신은 PM입니다"가 아닙니다. 지속적인 도전 속에서도 평정심을 유지하는 것과 같은 문제의 구체적인 성격을 설명합니다. 그것이 결과물을 바꿉니다. 단순히 "당신은 PM입니다"라고만 하면 일반적인 PM 조언만 얻게 됩니다.
**맥락(Context)**이 핵심적인 역할을 합니다. 저는 모델에게 "모든 것을 다 하라"고 기본 설정하는 임원진이라는 회의실의 패턴을 알려주었습니다. 그 맥락이 Claude가 저에게 준 모든 반론 대응을 형성했습니다. 그것이 없었다면 일반적인 협상 팁만 얻었을 것입니다.
**기대(Expectation)**는 형식과 어조에 대해 명확합니다. "제약 사항에 대해 사과하지 말고 전략적 레버로 프레임화하십시오"라는 한 줄이 결과물의 전체적인 어조를 바꾸었습니다. 그것이 없었다면 기본값은 종종 방어적이거나 모호한 어조였을 것입니다.
결과물
완벽한 회의 스크립트를 얻었습니다. 5개의 섹션으로 구성되었습니다. 첫 번째 반박이 나오기 전에 회의실의 분위기를 전환하도록 설계된 언어로 시작하는 오프닝 프레임. 특정 데이터 호출 구조(제 수치를 넣을 자리 표시자 필드 포함)가 포함된 반론별 대응. 같은 반론이 5번째 반복될 때를 위한 세 가지 다른 스크립트(실제로 저항을 유발하는 원인에 따라 직접적인 방식, 이해관계 프레임 방식, 권한 명확화 방식)까지 준비되었습니다.
결과물이 처음부터 완벽했다고 주장하지는 않겠습니다. 저는 실제 프로젝트 이름, 실제 속도 데이터, 그리고 회의실에 대한 제 나름의 판단을 넣어 수정했습니다. 하지만 그런 스캐폴드가 있었기에 처음부터 3일 동안 만드는 대신 90분 만에 다듬을 수 있었습니다.
결과
완벽한 합의에 도달했습니다. 가장 어려운 결정들이 내려졌습니다. 임원진이 직접 프로젝트 우선순위를 낮추는 결정을 내렸고, 싸우지 않았습니다. 저는 서명된 계층 구조를 가지고 회의실을 나왔습니다.
프롬프트는 대부분의 사람이 건너뛰는 부분입니다. 사람들은 너무 모호하게 질문하거나, 자신이 실제로 어떤 종류의 결과물이 필요한지 생각하지 않고 모든 것을 쏟아붓습니다. RACE는 그런 규율을 강제합니다.


