전체 글

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

제품 관리자를 위한 프롬프트 엔지니어링: AI가 초안을 쓰고, 판단이 결정한다

PM은 AI로부터 몇 초 만에 스펙 초안을 받을 수 있다 — 위험은 그것을 그대로 출시하는 것이다. 핵심 역량은 문제를 잘 정의한 다음, 결함이 있는 가정을 잡아내고 과도하게 추가된 범위를 덜어내는 것이다. 실전 예제와 평가 방법을 담은 실용 가이드다.

Jakir Patel 작성 · Founder, Hanzomon

공유

The five pillars of a hire: what great assessments actually measure의 일부

채용
목차

제품 관리자는 스펙 초안, 우선순위 정리, 경쟁사 요약을 AI로부터 몇 초 만에 얻을 수 있다. 매혹적인 부분은 그것이 얼마나 완성된 것처럼 보이는가이고, 위험한 부분도 바로 그 점이다. 모델은 조용히 틀린 가정 위에 세워진, 자신감 있고 잘 정돈된 문서를 만들어낸다 — 그리고 그것을 쓰인 그대로 출시하는 PM은 이 직무가 실제로 존재하는 바로 그 한 가지를 외주로 넘긴 셈이다. 이것은 우리의 역할별 프롬프트 엔지니어링 시리즈 중 제품 관리 편이며, AI 샌드박스가 가장 명확하게 드러내는 것들 중 하나다.

AI 샌드박스에서 PM은 AI 도구로 실제 제품 문제를 다룬다 — 그리고 신호는 그 위에 얹힌 판단이다: 잘못된 가정을 잡아내고 과도하게 추가된 범위를 덜어내는 것.

문제 정의가 곧 제품적 사고다

강력한 PM 프롬프팅의 절반은 모델이 실행되기 전에 일어난다: 문제, 제약, 성공 지표를 정확하게 정의하는 것이다. 그 정의는 프롬프트 요령이 아니라 — 명시적으로 표현된 제품적 사고 그 자체다. 모델에게 날카로운 문제 정의를 주면 유용한 초안을 돌려주고, '저장된 필터를 위한 스펙을 작성하라'고만 주면 일반적인 가정으로 빈틈을 메운다. 나머지 절반은 그 초안으로 무엇을 하느냐다: 결함 있는 가정을 잡아내고, 모델이 과도하게 추가한 범위를 덜어내고, 그것을 실제 사용자와 지표에 근거시키는 것. 그것이 PM 자리에서의 AI 유창성이다.

실전 예제

저장된 필터 기능에 대한 한 페이지짜리 스펙을 요청해 보라. 약한 버전은 모호하게 요청하고 깔끔한 결과를 그대로 출시한다. 강한 버전은 실제 문제, 까다로운 제약(스프린트 하나, 스키마 마이그레이션 없음), 그리고 성공 지표를 명시한다 — 그런 다음 모델에게 자신의 가정을 표시하도록 요청한다. 초안이 방금 배제한 마이그레이션을 요구하게 될 데이터 모델을 조용히 가정할 때, 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는 초안에 쓰되 결정에는 결코 쓰지 마라. 그것은 백지 공포증의 치료제이지, 사용자와 범위와 트레이드오프에 대한 판단을 대체하는 것이 아니다.
  • 모든 주장을 현실에 근거시켜라. 모델이 만들어낸 그럴듯한 서사가 아니라, 실제 사용자 행동과 지표에 스펙을 다시 연결하라.

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

흔한 실패 유형

  • 초안 출시: 잘 정돈된 문서를 잘 논증된 문서로 착각하는 것.
  • 모호한 정의: 문제 정의나 제약이 없어서 모델이 스스로 지어내고 — 당신은 그것을 물려받는다.
  • 기본값으로서의 범위 확장: 실제 문제로 덜어내는 대신 모델이 과도하게 추가한 기능을 받아들이는 것.

우리가 평가하는 방법

케이스 스터디 슬라이드 덱은 누군가 AI 초안에서 결함 있는 가정을 잡아내는지를 알려주지 못하고, AI를 금지하는 것은 PM이 이미 떠나온 작업 방식을 시험하는 것이다. 후보자에게 실제로 사용할 도구와 함께 현실적인 제품 과제를 주고 그 위에 얹는 판단을 지켜본다 — 그것이 바로 AI 샌드박스 평가가 하는 일이며, AI 유창성이 하나의 기둥으로 채점되는 방식이다. 전체 제품 관리자 평가가 무엇을 다루는지, 왜 이것이 AI 네이티브 채용에서 정직한 시험인지 살펴보거나, 역할에 맞춰진 평가가 구성되는 과정을 지켜보라.

PythonFastAPI · LLM APIs · SQLAlchemy*args / **kwargs → Q#1
AI는 모든 PM에게 빠른 첫 초안을 준다. 채용할 가치가 있는 사람은 그 초안을 사고의 끝이 아니라 시작으로 다룬다 — 그리고 그 차이는 그들이 잡아내는 가정에서 드러난다.
Prompt engineeringProduct managementAI fluencyAI Sandbox
J

작성자

Jakir Patel · Founder, Hanzomon

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

자주 묻는 질문

PM이 스펙을 쓰는 데 AI를 사용해야 하는가?

빠른 첫 초안을 위해서라면 그렇다 — 백지를 치워준다. 위험은 거기서 멈추는 것이다. 모델은 결함 있는 가정 위에 세워지고 원치 않던 범위로 덧대어진, 자신감 있고 그럴듯한 스펙을 기꺼이 만들어낸다. PM의 역량은 초안에는 AI를 쓰되 그다음 모델이 할 수 없는 제품적 판단을 적용하는 것이다.

강력한 PM 프롬프팅은 어떤 모습인가?

그것은 문제, 제약, 성공 지표를 명확하게 정의하고 — 그 정의 자체가 제품적 사고다 — 그런 다음 출력을 출발점으로 다룬다. 강한 PM은 잘못된 가정을 잡아내고, 과도하게 추가된 범위를 덜어내며, 초안을 쓰인 그대로 출시하는 대신 결과를 실제 사용자와 지표에 근거시킨다.

이것은 어떻게 평가되는가?

AI 샌드박스에서의 현실적인 제품 과제로: 실제 문제, 실제 제약, 사용 가능한 AI 도구. 신호는 후보자가 문제를 잘 정의하는지, AI 초안에서 결함 있는 가정을 잡아내는지, 결과를 사용자와 목표에 다시 연결하는지다 — 깔끔한 문서를 생성할 수 있는지가 아니다.

관련 글

직접 채용 공고로 확인하세요

얼리 액세스 대기자 명단에 등록하고 H-Evaluate가 실제 직무의 평가를 생성하는 과정을 확인하세요.

직접 채용 공고로 확인하세요