PM JD에 쓰지 말아야 할 문장들

좋은 PM 모시려다 JD에서 다 놓칩니다

안녕하세요, 채용 고민하는 HR 담당자입니다.

PM(Product Manager) 채용, 요즘 정말 쉽지 않죠? 지원자는 꽤 들어오는 것 같은데 막상 면접을 보면 우리 회사랑 핏이 안 맞는 경우가 많더라고요. 반대로, 정말 만나보고 싶은 인재는 서류조차 들어오지 않아 속상했던 경험, 다들 한 번쯤 있으실 겁니다.

저도 처음엔 단순히 "우리 회사가 덜 유명해서 그런가?", "연봉 조건이 안 맞나?" 하고 막연하게 생각했었어요. 그런데 주변 PM 지인들과 이야기를 나누다가 머리를 한 대 맞은 것 같은 충격을 받았습니다.

"그 회사 JD(Job Description) 봤는데, PM을 무슨 일정 관리 기계로 생각하는 것 같더라고요. 바로 뒤로가기 눌렀어요."

아차 싶더라고요. 우리는 정말 간절하게 좋은 PM을 찾고 있었는데, 정작 우리가 쓴 채용 공고(JD)가 그들을 밀어내고 있었다니요. 공고에 무심코 적은 한 문장, 한 단어가 지원자들에게는 "이 회사는 가면 고생하겠다", "전문성을 인정받기 어렵겠다"는 강력한 신호로 읽히고 있었던 겁니다.

특히 PM들은 직무 특성상 커뮤니케이션과 맥락 파악에 예민한 분들이잖아요. JD에 담긴 행간의 의미를 누구보다 빠르게 캐치합니다. 그래서 오늘은 제가 뼈아픈 시행착오 끝에 알게 된, PM 채용 공고에 절대 쓰지 말아야 할 표현들을 정리해 보려고 합니다. 혹시 우리 공고에도 이런 'Red Flag(위험 신호)'가 숨어 있지는 않은지, 한번 같이 점검해 보시면 좋겠습니다.

PM JD의 최악의 실수 1: 역할 오해형 (관리자 vs 리더)

가장 먼저 살펴볼 건, PM의 역할을 오해하게 만드는 표현들입니다. 흔히 "PM은 매니저니까 관리하면 되겠지?"라고 생각하기 쉬운데요, 이게 JD에 그대로 드러나면 정말 위험하더라고요.

대표적인 게 이런 문장입니다.

"개발팀을 리딩하고 전체 일정을 꼼꼼하게 관리합니다."

언뜻 보면 문제없어 보이죠? 하지만 현업 PM들이 보면 고개를 젓습니다. PM은 'Product'의 매니저지, 'People'의 매니저나 'Schedule'의 관리자가 아니거든요. 개발팀을 '리딩(Leading)'한다는 표현은 자칫 엔지니어링 매니저(EM)의 역할을 침범하는 것처럼 보일 수 있고, '일정을 관리한다'는 건 PM을 단순한 스케줄러로 격하시키는 느낌을 줍니다.

실제로 이런 공고를 본 지원자들은 이렇게 생각한다고 해요.

• "아, 여기 가면 개발자들 쪼는 역할만 하겠구나."
• "제품의 비전을 고민하는 게 아니라, 마감일 맞추는 데만 급급하겠네."

물론 일정을 챙기는 것도 PM의 업무 중 하나지만, 그게 주가 되어서는 곤란합니다. 대신 "제품의 로드맵을 수립하고, 개발팀과 협업하여 최선의 결과를 만들어냅니다" 정도로 표현하는 게 훨씬 전문적으로 보이더라고요. '관리'보다는 '협업'과 '방향성 제시'에 초점을 맞추는 거죠. 우리 회사가 PM을 단순 관리자가 아닌, 제품의 성장을 이끄는 리더로 대우하고 있다는 인상을 주는 게 중요합니다.

PM JD의 최악의 실수 2: 슈퍼맨 찾기형 (기술 스택 과몰입)

두 번째는 '기술 스택'에 대한 과도한 요구입니다. 채용 담당자 입장에선 당연히 기술도 잘 아는 PM이 오면 좋겠죠. 그래서 욕심을 부리다 보면 JD가 점점 개발자 채용 공고처럼 변해갑니다.

"Java, Spring 기반의 백엔드 개발 경험 필수" "직접 쿼리(SQL) 튜닝 및 데이터 아키텍처 설계 가능자"

이런 문구를 보면 PM 지원자들은 숨이 턱 막힙니다. "이 회사는 개발자를 뽑고 싶은데 이름만 PM이라고 붙인 건가?"라는 의구심이 들 수밖에 없죠. 물론 테크 PM이나 데이터 PM처럼 특수한 경우에는 필요할 수 있습니다. 하지만 일반적인 서비스 기획/PM 직군에서까지 이런 걸 요구하면, 정작 중요한 '문제 해결 능력'이나 '서비스 기획력'을 가진 인재들은 지원을 포기하게 됩니다.

더 큰 문제는 이런 요구가 "우리 회사는 개발팀과 PM의 R&R이 명확하지 않다"는 신호로 읽힐 수 있다는 점이에요. 기술적 의사결정은 엔지니어링 팀의 몫이고, PM은 '무엇을 왜 만들어야 하는지'를 정의하는 역할이니까요.

만약 기술적 이해도가 중요하다면, 구체적인 스택을 나열하기보다는 이렇게 표현해 보면 어떨까요?

• "개발팀과 기술적인 이슈에 대해 원활하게 소통할 수 있는 분"
• "데이터에 기반하여 논리적인 의사결정을 내릴 수 있는 분"

이 정도면 충분합니다. PM에게 필요한 건 코드를 짜는 능력이 아니라, 기술적 제약 사항을 이해하고 개발자와 '말이 통하는' 능력이니까요. 슈퍼맨을 찾으려다 평범하지만 훌륭한 인재를 놓치는 우를 범하지 않았으면 좋겠습니다.

PM JD의 최악의 실수 3: 수동적 인재상 (시키는 일 vs 주도적 문제해결)

세 번째는 PM의 핵심 역량인 '주도성(Ownership)'을 꺾어버리는 표현들입니다. 회사 입장에서는 유연하게 일할 사람이 필요해서 쓴 말이겠지만, 지원자 입장에서는 "여기선 내 생각대로 할 수 있는 게 없겠구나"라고 느끼게 만드는 문장들이죠.

"시키는 일에 거부감이 없고 유연하게 대처하시는 분" "대표님의 지시 사항을 빠르고 정확하게 이행할 분" "다양한 업무 보조 및 기타 회사에서 필요로 하는 일"

이런 문구, 정말 위험합니다. PM은 스스로 문제를 정의하고 해결책을 찾아나가는 사람입니다. 그런데 '시키는 일', '업무 보조' 같은 단어는 PM을 수동적인 실행가로 만들어버립니다. 특히 '탑다운(Top-down)' 문화가 강한 곳이라는 인상을 주기에 딱 좋죠. 능력 있고 야망 있는 PM일수록 이런 회사는 1순위로 거르게 됩니다.

대신 이렇게 바꿔보면 어떨까요?

• "주도적으로 문제를 발굴하고 해결책을 제시할 수 있는 분"
• "변화하는 상황 속에서도 우선순위를 판단하고 유연하게 대처할 수 있는 분"

같은 '유연함'을 이야기하더라도, 수동적인 태도가 아니라 능동적인 판단력을 강조하는 겁니다. "우리는 당신의 생각을 존중하고, 당신에게 권한을 줄 준비가 되어 있다"는 메시지를 던져야, 진짜 일 잘하는 PM들이 매력을 느낍니다.

S5. PM JD의 최악의 실수 4: 낡은 조직문화 (가족 같은 vs 프로페셔널)

마지막으로, 조직 문화를 설명할 때 흔히 쓰는 상투적인 표현들입니다. 특히 스타트업 JD에서 자주 보이는 그 단어, 다들 짐작하시죠?

"가족 같은 분위기에서 즐겁게 일하실 분" "회사와 함께 성장하며 헌신하실 분"

솔직히 말씀드리면, 요즘 구직자들 사이에서 '가족 같은 회사'는 '가(족) 족 같은 회사'라는 밈으로 조롱받곤 합니다. 공과 사의 구분이 모호하고, 야근이나 주말 근무 같은 개인의 희생을 당연하게 요구할 것 같다는 부정적인 인식이 강하게 박혀 있거든요. 프로페셔널함을 추구하는 PM들에게는 오히려 "체계가 없고 감정에 호소하는 조직"으로 비칠 수 있습니다.

우리가 강조해야 할 건 '끈끈한 정'이 아니라 '건강한 협업'입니다.

• "상호 존중을 바탕으로 치열하게 토론하는 문화"
• "자율과 책임을 중시하는 수평적인 업무 환경"
• "동료의 성장을 자극하고 돕는 러닝 메이트"

이런 표현들이 훨씬 세련되고 매력적이지 않나요? 억지로 친밀함을 강조하기보다, 일하는 방식과 동료에 대한 존중을 보여주는 게 요즘 인재들에게는 더 어필이 되더라고요.

제대로 된 PM JD를 위한 3가지 질문 (Why, Problem, Impact)

자, 그럼 이제 "무엇을 쓰지 말아야 할지"는 알았으니, "무엇을 써야 할지"가 고민되시죠? 좋은 JD는 단순히 업무 내용을 나열하는 게 아닙니다. 지원자가 이 글을 읽고 "아, 내가 저기에 가면 이런 일을 해볼 수 있겠구나!" 하고 가슴 뛰게 만들어야 하죠.

저는 JD를 쓸 때 딱 세 가지 질문을 먼저 던져봅니다.

1. Why (왜 이 포지션이 필요한가?): 단순히 "사람이 나가서", "일이 많아서"가 아닙니다. 회사의 비전 달성을 위해 이 자리가 왜 중요한지 맥락을 설명해 주세요.
2. Problem (어떤 문제를 해결해야 하는가?): "기획 업무 수행"보다는 "복잡한 결제 프로세스를 간소화하여 구매 전환율을 높이는 과제"처럼, 구체적인 미션을 제시하는 게 좋습니다.
3. Impact (어떤 임팩트를 낼 수 있는가?): 이 일을 잘해냈을 때 회사와 개인에게 어떤 성장이 있을지 보여주세요.

예를 들어볼까요?

• (Bad) 앱 서비스 기획 및 운영, 데이터 분석, 일정 관리
• (Good) Why: 100만 사용자가 매일 쓰는 서비스로 도약하기 위해, Problem: 사용자 이탈이 발생하는 구간을 찾아 개선하고, Impact: 고객의 생애 가치(LTV)를 극대화하는 여정을 함께합니다.

어떤가요? 같은 업무라도 훨씬 더 도전적이고 의미 있어 보이지 않나요? 이렇게 '맥락'을 담은 JD는 지원자에게 우리 회사가 일을 대하는 태도와 수준을 보여주는 가장 확실한 명함이 됩니다.

JD만으로는 부족한 '진짜 실력' 검증법

여기까지 공들여서 JD를 잘 썼다면, 분명 이전보다 훨씬 좋은 지원자들이 모일 겁니다. 하지만 여기서 끝이 아닙니다. 사실 HR 담당자로서 진짜 고민은 이때부터 시작되죠.

"글(JD)을 보고 온 지원자가, 진짜 글(이력서)만큼 일도 잘할까?"

특히 PM은 혼자 일하는 게 아니라 디자이너, 개발자, 사업팀 사이에서 조율하고 협업하는 역할이잖아요. JD나 이력서, 심지어 면접만으로는 이 사람의 '협업 태도'나 '커뮤니케이션 스킬'을 100% 파악하기가 정말 어렵더라고요. 말은 청산유수인데 막상 입사시키고 보면 독불장군이어서 팀 분위기를 망치는 경우도 종종 있었고요.

그래서 저는 JD 단계를 넘어 서류나 면접 전형에서 평판조회(레퍼런스 체크)를 꼭 챙기려고 하는 편입니다. 예전에는 임원급 채용 때나 알음알음 전화 돌려서 물어봤지만, 요즘은 실무자급 PM을 뽑을 때도 필수적으로 확인하게 되더라고요.

예전에는 평판조회가 대부분 사람 손을 거쳐 진행되다 보니 비용이나 부담이 만만치 않았습니다. 그런데 요즘은 스펙터처럼 온라인으로 레퍼런스 체크를 지원해주는 서비스들이 등장하면서, 예전보다 훨씬 현실적인 선택지가 된 것 같더라고요.

이전 동료들이 평가하는 "이 사람이 갈등을 해결하는 방식", "개발자와 소통할 때의 태도" 같은 구체적인 피드백을 받아보면, 면접장에서는 절대 알 수 없었던 '진짜 모습'이 보입니다. JD로 좋은 분들을 잘 모셔오는 것만큼이나, 우리 조직에 진짜 맞는 분인지 꼼꼼하게 확인하는 과정이 중요하다는 걸 매번 깨닫고 있습니다.

마무리: JD는 채용의 첫인상, 검증은 채용의 핵심

오늘은 PM 채용 공고(JD)에서 피해야 할 표현들과, 더 좋은 JD를 쓰기 위한 팁들을 나눠봤습니다.

JD는 지원자가 우리 회사를 처음 마주하는 '첫인상'입니다. 무심코 쓴 단어 하나가 회사의 이미지를 결정짓고, 좋은 인재의 발길을 돌리게 만들 수도 있다는 점, 꼭 기억해 주셨으면 해요. 오늘 말씀드린 'Red Flag' 표현들만 걷어내도, 훨씬 더 매력적이고 전문적인 공고가 될 거라 확신합니다.

그리고 그렇게 만난 소중한 지원자들을 놓치지 않도록, 면접과 평판조회 같은 검증 과정도 탄탄하게 설계하셔서 꼭 '핏'이 맞는 분과 함께하시길 바랍니다.

혹시 여러분의 회사 JD에는 어떤 표현들이 적혀 있나요? 이번 기회에 지원자의 눈으로 한번 쓱 훑어보시는 건 어떨까요? 작은 변화가 생각보다 큰 차이를 만들어낼지도 모르니까요.

오늘도 좋은 동료를 찾기 위해 고군분투하는 모든 HR 담당자분들을 응원합니다!