제품 관리자가 스펙 작성에 AI를 사용해야 할까요?

첫 초안을 위해서라면 그렇습니다 — 몇 초 만에 백지를 없애줍니다. 위험은 거기서 멈추는 것입니다. 모델은 결함 있는 가정 위에 세워지고 요청하지 않은 범위로 부풀려진, 자신감 있고 그럴듯한 스펙을 기꺼이 만들어냅니다. PM의 역량은 초안에는 AI를 쓰되, 그 다음 모델이 할 수 없는 제품적 판단을 적용하는 것입니다 — 잘못된 전제를 잡아내고, 실제 사용자와 지표에 결과를 근거시킨 후에 누군가 그것을 실제로 구현하게 하는 것입니다.

PM의 탁월한 프롬프트 엔지니어링은 어떤 모습인가요?

모델이 실행되기 전에 문제, 제약, 성공 지표를 정확하게 정의합니다 — 그 정의 자체가 제품적 사고입니다 — 그런 다음 출력물을 결정이 아닌 출발점으로 다룹니다. 탁월한 PM은 모델에게 스스로의 가정을 표시하도록 요청하고, 조용히 틀린 전제를 잡아내며, 과도하게 추가된 범위를 걷어내고, 완성된 초안을 그대로 출시하는 대신 결과를 실제 사용자 행동에 연결합니다.

제품 관리자의 AI Fluency는 어떻게 평가하나요?

AI Sandbox에서 현실적인 제품 과제를 줍니다: 실제 문제, 실제 제약, 실제로 사용하는 AI 도구. 신호는 행동에 있습니다 — 후보자가 문제를 잘 정의하는지, 모델 초안의 결함 있는 가정을 잡아내는지, 결과를 사용자와 목표에 다시 연결하는지입니다. 깔끔한 문서를 생산할 수 있는지가 아닙니다 — 그 부분은 모델이 이미 해줍니다.

AI 도구를 금지하는 것이 PM 평가에 공정한 방법인가요?

아닙니다. AI를 금지하면 PM이 이미 떠나온 작업 방식을 시험하게 되어, 실제 업무 방식에 대해 아무것도 측정하지 못합니다. AI를 잘 사용하지 못하는 후보자와 잘 사용하는 후보자가 동일하게 보입니다. 정직한 시험은 후보자에게 도구를 주고 그 위에 어떤 판단을 얹는지 관찰하는 것입니다 — 첫 날부터 마주하게 될 상황과 동일하게.

PM이 AI 프롬프팅에서 가장 흔히 저지르는 실수는 무엇인가요?

세 가지가 반복됩니다. 초안 출시 — 잘 정돈된 문서를 잘 논증된 문서로 착각하는 것. 모호한 정의 — 문제 정의나 제약을 주지 않아 모델이 스스로 지어내고 PM이 그것을 물려받는 것. 그리고 기본값으로서의 범위 확장 — 실제 문제로 다시 좁히는 대신 모델이 과도하게 추가한 기능을 받아들이는 것. 각각은 출력물을 답이 아닌 첫 초안으로 다루지 않은 데서 비롯됩니다.

전체 글

채용 · July 21, 2026 · 8분 읽기

제품 관리자를 위한 프롬프트 엔지니어링

제품 관리자의 프롬프트 엔지니어링은 입력 요령이 아니라, 문제를 정확히 정의하고 모델의 결함 있는 가정을 잡아내며 불필요하게 추가된 범위를 걷어내는 일이다.

Jakir Patel 작성 · Founder, Hanzomon

← 채용의 다섯 가지 기둥: 평가가 실제로 측정하는 것의 일부

채용

제품 관리자를 채용한다면 이제 AI Fluency 질문은 피할 수 없습니다. PM은 몇 초 만에 모델로부터 스펙 초안, 우선순위 정리, 경쟁사 요약을 얻을 수 있고, 그것이 얼마나 완성된 것처럼 보이는지가 유혹적인 부분입니다. 그 완성도가 동시에 위험 요소입니다. 모델은 조용히 틀린 가정 위에 세워진, 자신감 있고 잘 정돈된 문서를 만들어내고, 그것을 쓰인 그대로 출시하는 PM은 이 직무가 실제로 존재하는 바로 그 한 가지를 외주로 넘긴 셈입니다. 이 가이드는 제품 관리자의 프롬프트 엔지니어링이 실제로 무엇을 의미하는지, 왜 그것이 타이핑 기술이 아닌 채용 신호인지, 그리고 어떻게 정직하게 평가할 수 있는지를 다룹니다. 이것은 우리의 역할별 프롬프트 엔지니어링 시리즈 중 제품 관리 편이며, AI Sandbox가 가장 명확하게 드러내는 것들 중 하나입니다.

AI Sandbox에서 PM은 실제 직무에서 사용하는 AI 도구로 실제 문제를 다룹니다 — 신호는 그 위에 얹힌 판단입니다: 잘못된 가정을 잡아내고 과도하게 추가된 범위를 걷어내는 것.

PM이 실제로 AI에 손을 뻗는 순간

제품 관리자의 프롬프트 엔지니어링은 하나의 과제가 아닙니다. 각각 고유한 실패 방식을 지닌 일상적인 동작들의 집합입니다. PM이 스펙과 PRD를 초안 작성하면 모델은 범위를 과도하게 부풀립니다. PM이 경쟁사 출시를 요약하면 모델은 존재하지 않는 기능을 지어냅니다. PM이 사용자 리서치 노트를 테마로 종합하면 모델은 가장 중요한 모순된 인용을 평균으로 덮어버립니다. PM이 우선순위를 초안 작성하면 모델은 그 배경에 있는 비즈니스 맥락을 전혀 파악하지 못한 채 자신감 있는 순위를 만들어냅니다. 모든 경우에서 모델은 기계적인 작업을 몇 초 만에 해내지만, PM이 잡아내야 할 오류를 조용히 포함시킵니다.

스펙 초안: 빠르지만 범위를 지어내고 데이터 모델을 가정하는 경향이 있음.
경쟁사 요약: 유창하지만 실제로 없는 기능과 수치를 확언하는 경향이 있음.
리서치 종합: 깔끔하지만 핵심 인사이트를 담은 이상값을 평균으로 지워버리는 경향이 있음.
우선순위 결정: 단호하지만 PM만이 아는 전략적 맥락에는 눈이 먼 상태.

공통점은 모델이 '잘 모르겠다'고 절대 말하지 않는 빠르고 자신감 있는 주니어라는 것입니다. PM의 역할은 모델을 타이핑으로 이기는 것이 아니라, 모델이 부족한 맥락을 공급하고 모델이 알 수 없는 부분을 불신하는 것입니다.

프롬프트 엔지니어링은 제품 역량이지 타이핑 요령이 아니다

프롬프트 엔지니어링을 구문 요령의 모음으로 보는 시각이 많습니다 — 마법의 문구, 역할극 서두, 형식 주문. PM에게 그 관점은 핵심을 완전히 놓칩니다. PM이 모델 주변에 더하는 가치는 표현 방식과 거의 무관하고, 판단력과 거의 모든 것이 관련됩니다. 어떤 문제를 해결할 가치가 있는지, 무엇을 남겨야 하는지, 그리고 그럴듯한 답이 실제로는 틀린 순간이 언제인지 아는 것. 이것은 AI 없이도 강한 PM과 약한 PM을 가르는 동일한 본능입니다. AI는 단지 위험 부담을 높일 뿐인데, 느슨한 사고를 드러냈던 마찰을 없애기 때문입니다. 모호한 브리프는 한때 빈 페이지를 낳았지만, 이제는 진척된 것처럼 보이는 완성된, 틀린 문서를 낳습니다.

정의가 곧 제품적 사고다

강력한 프롬프팅의 절반은 모델이 실행되기 전에 일어납니다: 문제, 제약, 성공 지표를 정확하게 정의하는 것. 그 정의는 프롬프트 요령이 아니라 — 명시적으로 표현된 제품적 사고 그 자체입니다. 모델에게 날카로운 문제 정의를 주면 유용한 초안을 돌려주고, '저장된 필터를 위한 스펙을 작성하라'고만 주면 빈틈을 일반적인 가정으로 메우고 당신이 그것을 물려받게 됩니다. 정의가 날카로울수록 초안은 더 유용해지고 나중에 풀어내야 할 가정은 줄어듭니다. 이것은 좋은 채용 공고 뒤에 있는 것과 동일한 규율입니다: 앞에 담는 명확함이 하류의 모든 것의 품질을 결정합니다.

나머지 절반은 초안으로 무엇을 하느냐입니다. 결함 있는 가정을 잡아내고, 모델이 과도하게 추가한 범위를 걷어내며, 모델이 만들어낸 그럴듯한 서사가 아닌 실제 사용자와 지표에 결과를 근거시키는 것. 그 조합 — 정확한 정의와 회의적 검토 — 이 PM 자리에서의 AI Fluency 모습이며, 4D 프레임워크에 직접 연결됩니다: 위임(Delegation, 무엇을 모델에 맡길지 아는 것), 기술(Description, 잘 정의하는 것), 분별(Discernment, 잘못된 것을 잡아내는 것), 성실(Diligence, 행동하기 전에 검증하는 것).

4D 프레임워크를 PM 자리에 적용하기

'AI를 잘 다룬다'는 것은 인터뷰에서 기준 삼기에 너무 모호하기 때문에, AI Fluency를 구성 요소로 분해하는 것이 도움이 됩니다. 4D 프레임워크는 그것을 네 가지 관찰 가능한 행동으로 나누고, 각각은 제품 업무에 명확하게 매핑됩니다. 위임(Delegation)은 애초에 모델에 무엇을 맡길지 아는 것입니다: 강한 PM은 루틴적인 초안 작성과 요약을 AI에 돌리고 판단이 필요한 부분은 본인이 담당하는 반면, 약한 PM은 모든 것을 수동으로 처리하거나 모델에게 맡겨서는 안 될 결정을 위임합니다. 기술(Description)은 이미 다룬 정의 능력 — 출력이 유용하도록 문제를 정확하게 표현하는 능력입니다.

분별(Discernment)은 PM에게 가장 중요한 근육입니다: 완성된 것처럼 보이는 초안을 읽으면서 성립하지 않는 가정, 지어낸 기능, 조용히 바뀐 지표를 발견하는 것. 성실(Diligence)은 행동하기 전에 검증하는 규율입니다 — 경쟁사 주장을 현실과 대조하고, 스펙의 전제를 실제 데이터 모델에 검증하며, 요약된 리서치 테마를 원본 노트와 확인하는 것. 후보자는 어떤 D에서는 강하고 다른 D에서는 공허할 수 있습니다. 흥미로운 신호는 네 가지 전반에 걸친 프로파일입니다.

위임(Delegation): 루틴 작업은 모델에 돌리고 판단이 필요한 부분은 직접 담당한다.
기술(Description): 문제, 제약, 성공 지표를 정확하게 정의한다.
분별(Discernment): 다른 사람들이 출시할 '틀렸지만 자신감 있는' 출력을 잡아낸다.
성실(Diligence): 행동하기 전에 주장을 현실과 대조해 검증한다.

실전 예제: 저장된 필터 스펙

저장된 필터 기능에 대한 한 페이지짜리 스펙을 요청해 보십시오. 약한 버전은 모호하게 요청하고 깔끔한 결과를 그대로 출시합니다. 강한 버전은 실제 문제, 까다로운 제약 — 스프린트 하나, 스키마 마이그레이션 없음 — 그리고 성공 지표를 명시한 다음 모델에게 자신의 가정을 표시하도록 요청합니다. 초안이 방금 배제한 마이그레이션을 요구하게 될 데이터 모델을 조용히 가정할 때, PM은 그것을 잡아내고 해법을 다시 빚어냅니다. 동일한 모델, 동일한 기능; 차이는 전적으로 프롬프트 양쪽에 있는 인간에게 있습니다.

Prompt

## TASK
Draft a one-page spec for saved search filters.

## CONTEXT
- Problem: power users re-apply the same 5 filters every day
- Constraint: ship in one sprint, no schema migration
- Success metric: % of searches that reuse a saved filter

## OUTPUT
Problem, non-goals, proposed solution, open questions.
Flag every assumption you make about our data model.

좋음: 문제와 제약을 정의하고, 빠른 초안을 위해 AI를 사용한 뒤, 잘못된 가정을 잡아내고 스펙을 실제 사용자와 지표에 연결한다.
약함: 제품적 판단 없이 마이그레이션까지 포함된 AI 생성 스펙을 그대로 출시한다.

강한 버전에서 표현 방식이 차지하는 비중이 얼마나 작은지 주목하십시오. 이것을 잘 해내는 후보자는 모델에게 더 좋은 주문을 거는 것이 아닙니다. 모델이 알 수 없었던 제약과 모델이 갖지 못하는 회의심을 가져오는 것입니다. 경쟁사 요약 과제나 리서치 종합 과제로 바꿔도 패턴은 동일합니다: AI가 그럴듯한 산출물을 만들어내고, PM이 더하는 가치는 모델이 부족했던 맥락이나 검증의 구체적인 부분입니다. 그래서 프롬프트 템플릿으로는 이것을 흉내 낼 수 없습니다. 템플릿은 쉬운 절반이고, 출력이 무엇을 틀렸는지에 대한 판단이 실제로 직무인 나머지 절반입니다.

함정은 그 완성도입니다. AI 생성 스펙은 완성된 것처럼 보여서 출시하고 싶어지게 만듭니다. 채용할 가치가 있는 PM은 완성된 듯 보이는 초안을 덜 회의적으로가 아니라 더 회의적으로 읽습니다 — 자신감 있으면서 틀린 것이 바로 모델의 전문 분야이기 때문입니다.

실제로 판을 바꾸는 모범 사례

정확하게 정의하라. 문제, 제약, 성공 지표를 앞단에 — 정의가 날카로울수록 초안은 더 유용해지고 풀어내야 할 일반적 가정은 줄어든다.
모델에게 가정을 표시하도록 요청하라. 조용히 틀린 전제가 잘 다듬어진 문서 속에 파묻히기 전에 드러나게 한다.
AI는 초안에 쓰되 결정에는 절대 쓰지 마라. 백지 공포증의 치료제이지, 사용자와 범위와 트레이드오프에 대한 판단을 대체하는 것이 아니다.
모든 주장을 현실에 근거시켜라. 모델이 만들어낸 그럴듯한 서사가 아니라, 실제 사용자 행동과 지표에 스펙을 다시 연결하라.
확장하지 말고 다듬어라. 첫 초안을 더 쌓아올릴 최솟값이 아니라 걷어낼 최댓값으로 다루어라.

흔한 실패 유형

초안 출시: 잘 정돈된 문서를 잘 논증된 문서로 착각하는 것.
모호한 정의: 문제 정의나 제약이 없어서 모델이 스스로 지어내고 — 당신이 그것을 물려받는다.
기본값으로서의 범위 확장: 실제 문제로 좁히는 대신 모델이 과도하게 추가한 기능을 받아들이는 것.
유창한 헛소리: PM이 직접 검증할 수 없는 영역에서 자신감 있는 답을 신뢰하는 것.

유창한 헛소리는 인터뷰에서 특히 주시해야 할 실패 유형입니다. 틀렸지만 자신감 있는 답을 발견하지 못하는 후보자는 모델의 오류를 속도를 붙여 전달하게 됩니다 — 그리고 직급이 높을수록 그 오류는 누군가 잡아내기 전에 더 멀리 퍼집니다.

인터뷰에서 주시할 신호들

라이브 과제를 실행할 수 없더라도 대화에서 동일한 행동을 탐색할 수 있습니다. 후보자에게 AI가 마지막으로 사용하지 않은 결과를 낸 경험을 이야기해달라고 요청하고, 도구에 대한 막연한 지지가 아닌 결함을 잡아낸 실제 이야기를 들어보십시오. 최근 프롬프트를 어떻게 정의했는지, 모델에게 가정을 드러내도록 요청했는지 물어보십시오. 요약이나 경쟁사 주장이 틀렸을 때 어떻게 했는지 물어보십시오. 핵심은 구체성입니다: 강한 PM은 자신이 잡아낸 정확한 가정과 그것이 왜 중요했는지를 설명하고, 약한 PM은 이제 모든 것이 얼마나 빨라졌는지를 이야기합니다. 회의심 없는 속도가 주시해야 할 답입니다 — 그것은 대개 오류가 출시되고 있다는 의미이기 때문입니다.

직급에 따라 기준이 달라지는 방식

기준은 직급과 함께 높아집니다. AI를 활용해 깔끔한 첫 초안을 만들고 멘토의 피드백으로 검토하는 주니어 PM은 일을 잘 하고 있는 것입니다. 시니어 PM은 별도의 요청 없이도 가정을 잡아낼 것이 기대되고, 어떤 모델 출력을 신뢰해도 되고 어떤 것은 도메인 전문가가 필요한지 알아야 하며, 팀 다운스트림이 모델의 추측이 아닌 명확성을 물려받도록 정의를 구성해야 합니다. 실패 유형도 함께 커집니다: 주니어의 미검토 초안은 리뷰 사이클 하나를 날리지만, 시니어의 유창하지만 틀린 전략 메모는 로드맵의 한 분기를 잘못 이끌 수 있습니다. 그래서 직급이 높아질수록 AI Fluency를 더 가볍게가 아니라 더 무겁게 가중해야 합니다.

제품 관리자의 프롬프트 엔지니어링을 평가하는 방법

케이스 스터디 슬라이드 덱은 누군가 모델 초안에서 결함 있는 가정을 잡아내는지를 알려주지 못하고, AI를 금지하는 것은 PM이 이미 떠나온 작업 방식을 시험하는 것입니다. 그래서 정직한 접근은 후보자에게 실제로 사용할 도구와 함께 현실적인 제품 과제를 주고 그 위에 얹는 판단을 관찰하는 것입니다. AI Sandbox 평가가 하는 것이 바로 이것으로, 문서가 아닌 행동을 채점합니다. 이것은 더 넓은 그림 안에 있습니다: AI Fluency는 인지, 도메인, 상황 판단, 행동 신호와 함께 완전한 평가의 다섯 기둥 중 하나로 우리가 다루는 다섯 가지 측정 가능한 차원 중 하나입니다.

PythonFastAPI · LLM APIs · SQLAlchemy*args / **kwargs → Q#1

AI Fluency가 어떻게 비교 가능한 점수로 이어지는지 구체적인 내용은 AI Fluency를 하나의 기둥으로 평가하는 방법을 참조하십시오. 프롬프트 엔지니어링이 더 넓은 역할에서 어떤 위치에 있는지 보려면 제품 관리자 채용 가이드를 읽거나, 전체 제품 관리자 평가가 무엇을 다루는지 살펴보십시오. 업무 샘플 과제가 왜 인터뷰보다 낫는지 이해하고 싶다면 역할에 맞춰진 평가가 구성되는 과정을 지켜보십시오.

AI는 모든 PM에게 빠른 첫 초안을 줍니다. 채용할 가치가 있는 사람은 그 초안을 사고의 끝이 아닌 시작으로 다룹니다 — 그리고 그 차이는 그들이 잡아내는 가정에서 드러납니다.

Prompt engineeringProduct managementAI fluencyAI Sandbox

작성자

Jakir Patel · Founder, Hanzomon

Building H-Evaluate — AI-native, quality-gated hiring assessments. Writes about assessment engineering, hiring integrity and compliance-first AI.