[20호] PM의 채용 공고가 바뀌었다

요즘 PM 채용 공고가 이상합니다. 같은 회사, 같은 직급인데 1년 전과는 분위기가 사뭇 달라졌습니다.

한 테크 회사의 시니어 PM JD를 살펴봤어요. 예전엔 아래와 같이 문구들이 대부분이었습니다.

그런데 최근 JD를 보면 이런 표현들이 자연스럽게 등장합니다.

"어라, 이거 PM 채용 공고 맞아?"
다시 뜯어 보니, 단순히 AI 관련 문구가 몇 줄 추가된 게 아닙니다. 회사가 PM에게 기대하는 역할 자체가 달라지고 있습니다. 이미 평생 회사를 찾은 분이 아니라면, 관심있는 주제 아닌가요? 👀

이번 호에서는 IT 회사의 달라진 JD를 읽어보며 가볍게 수다 떠는 시간 가져볼게요. ☕️

🔥 1. Amazon Ring — "Senior Product Manager, Builder"

공고 보기

Ring은 Amazon의 스마트 홈 보안·IoT 기기 전문 브랜드에요. 채용하는 PM의 직함 뒤에 요즘 심심찮게 빌더가 붙고 있어요.

이 포지션의 요구사항을 보면:

자격요건에는 아래와 같은 내용이 명시돼 있어요.

전통 PM의 JD랑 비교하면 'PRD 작성' 대신 '프로토타입 직접 빌드', 'Cross-functional Collaboration' 대신 'AI 코딩 툴로 직접 출시'가 먼저 보여요. 기존의 기획 중심 PM과는 궤를 달리하는, "AI 네이티브 Product Builder"를 찾는 공고입니다. 여기에 전통적인 PM 역량은 당연히 ‘기본 베이스’라고 명시하고 있네요. 

현재 실리콘밸리를 중심으로 빅테크 기업과 유망 스타트업들 사이에서 가장 뜨겁게 부상하고 있는 트렌드 중 하나가 바로 이 '프로덕트 빌더(Product Builder)' 혹은 'AI 빌더 PM'의 등장입니다.

지난해 12월 Lenny's Podcast에서 LinkedIn의 CPO 토머 코헨은 APM(Associate PM) 프로그램을 대신 프로덕트, 디자인, 엔지니어링을 아우르는 APB(Associate Product Builder) 프로그램으로 전환했다고 밝혔어요. 

APM은 Google, Meta, LinkedIn 같은 빅테크에서 10년 넘게 운영해온 신입 PM 사관학교 같은 거예요. 졸업생 중에서 프로덕트 리더들이 많이 나온 걸로 유명한, 실리콘밸리식 PM 입문 코스예요. LinkedIn은 기존 APM 프로그램 대신 "PM·디자이너· 엔지니어를 한 사람으로 뽑는"는 APB 프로그램을 시작했어요. 이력서는 없고, 제출물은 실제 사람들이 쓴 제품의 60초 데모 영상입니다.

APB 지원서 질문은 6개에요.

그리고 이것은 LinkedIn만의 이야기가 아니게 됐어요. Amazon의 Ring은 "Product Manager", "Senior Software Engineer" 같은 직함을 "Builder"로 바꾸는 작업을 진행 중이고요. Walmart도 "agent builder" 역할을 신설했는데, 기술직·비기술직 가릴 것 없이 내부에서 지원자를 채워 포지션을 모두 채웠다고 해요.

📋 2. Amazon Rufus — "Senior PM-Tech, GenAI"

공고 보기

이 공고는 아마존이 야심 차게 밀고 있는 AI 쇼핑 어시스턴트인 Rufus 팀의 테크 PM 공고입니다.

앞서 본 Ring 팀의 '빌더 PM'이 직접 코드를 짜서 프로토타입을 만드는 역할이었다면, 이 Rufus 공고는 "초대형 생성형 AI(GenAI) 시스템의 두뇌를 설계하는 PM"을 찾습니다.

이 PM의 핵심 임무는  'LLM-as-a-Judge(LLM판사)' 거버넌스입니다. AI가 AI를 평가하는 시스템 — 수백만 명이 쓰는 Rufus가 이상한 답변(환각)을 하지 않도록 품질 기준을 설계하고, 그 기준이 전 세계에서도 잘 작동하는지 관리하는 역할이에요.

일반 소프트웨어는 버그가 있으면 명확하게 '틀림'이지만, AI는 '틀리진 않은데 좋지 않은' 답변을 할 수 있어요. 그래서 '어떤 답변이 좋은 답변인지'의 기준 자체를 PM이 정의해야 합니다. 어떤 케이스가 정답 예시(golden set)인지, 어느 수준의 오류가 허용 가능한지, AI끼리 서로 품질을 평가하게 하는 기준(LLM-as-a-Judge)은 어떻게 설계할지 — 이 체계 전체를 Eval(Evaluation)이라고 부릅니다.

JD 안에는 'A day in the life' 섹션이 있어요. 이 PM의 실제 하루가 어떻게 생겼는지 적혀 있습니다.

PM인데 직접 코딩해서 에이전트를 만들고, 배포하고, 퇴근 전에 반려 결정까지 내립니다. '이 AI 기능, 잘 작동하고 있나?'를 측정하는 체계를 PM이 리드해야 하는 시대가 된 거예요.

🔍 3. Google — "Product Manager, Advertiser and Business Intelligence AI"

공고 보기

구글 매출의 대부분은 광고에서 나옵니다. 이 PM은 구글 광고 생태계 안에서 광고주들이 마주하는 '비즈니스 인텔리전스(BI)'와 '광고 데이터 분석' 영역에 최첨단 생성형 AI와 예측 AI 모델을 이식하는 임무를 맡습니다.

이 공고는 GenAI·Agentic AI·LLM 관련 PM 경험 1년이 입사 지원 필수 조건입니다.

해야하는 역할을 보면:

AI 기술을 이해하면서도, 그 기능이 광고주의 실제 의사결정에 녹아들도록 설계하는 기술과 비즈니스 사이의 통역사를 찾고 있네요.

구체적으로 그려보면 이렇습니다. 광고주 입장에서 구글 광고 대시보드를 열었을 때 "이 캠페인, 내일 예산 어떻게 조정해야 해요?"라는 질문에 AI가 자동으로 답해준다고 생각해볼게요. 이 기능을 만드는 PM은 두 가지를 동시에 알아야 합니다.

예측 모델이 어떤 피처를 보고 어떤 신뢰도로 추론하는지 — 그리고 그 결과를 본 광고주가 '아, 이 숫자 믿고 실제로 예산을 바꿔도 되겠다'는 확신이 생기는 UX가 무엇인지 말이지요.

🪄 4. Cursor (Anysphere) — "우리는 전통적인 PM을 뽑지 않는다"

공고 보기

AI 코드 에디터 Cursor를 만드는 회사(Anysphere)의 채용 공고입니다. 전통적인 PM을 뽑지 않는 것으로 유명하죠. 공고에는 이렇게 명시돼 있습니다.

Product Manager, Agent Harness, Product Manager, Cloud Agents. 직함에서 보이듯, 에이전트를 직접 만드는 PM을 찾고 있어요.

'fit'한 사람의 기준을 보면 더 명확합니다.

🤍 5. Anthropic — "이 제품을 매일 쓰지 않으면 지원하지 마세요"

공고 보기

Claude Code의 모델 성능을 PM이 직접 책임지는 역할이에요. 이 공고에는 이런 문장이 있어요.

그 '연결 조직'이 되기 위해 이 공고가 요구하는 것은 

마지막 요건이 특히 인상적이에요. '창의적인 해커 정신과 퍼즐 풀기를 즐기는 사람.' 이건 PM 공고에서 보기 어려운 표현이에요. Anthropic이 원하는 건 프로세스를 관리하는 PM이 아니라, 모델 자체를 깊이 이해하고 손을 쓰는 사람이라는 게 느껴집니다.

🦜 6. Duolingo — "JD엔 'AI'가 없는데, 지원서엔 있어요"

공고 보기

듀오링고의 Senior PM, Learning을 찾는 공고예요. 이 PM이 속하는 곳은 'Learning Pillar' — 언어 학습 자체를 만드는 팀이에요.  새로운 학습 방식을 계속 실험하고 출시하는 역할인데, JD에 명시한 자격 요건을 보면 이렇습니다.

이 공고에서 흥미로운 건 지원서에 있는 두 개의 필수 질문입니다.

JD 본문엔 'AI'라는 단어가 단 한 번도 등장하지 않아요. 그런데 지원서에서 이 두 질문을 필수로 묻는다는 건, 듀오링고가 AI를 기술 스택이 아니라 일하는 방식의 변화 자체로 보고 있다는 신호예요. 코드를 짜는 빌더가 아니더라도, 여기선 AI와 함께 일하는 방식을 직접 보여줄 수 있어야 합니다.

그래서, 지금 필요한 건?

이 공고들을 나란히 놓으면 변화가 보입니다.

다 합치면 PM에게 요구하는 게 갑자기 너무 많아진 것 같죠. 하지만 이 공고들을 '지금 당장 되어야 하는 기준'으로 읽을 필요는 없어요. PM의 모습이 어디를 향해 가고 있는지를 보여주는 흐름일 뿐입니다.

사실 PM이 된 이유를 떠올려보면 — 새로운 걸 만드는 게 재밌어서, 고객 경험이 바뀌는 걸 보는 게 즐거워서. 내가 만든 산출물이 실제 세상에 나오는게 뿌듯해서라는 분들이 많은데요. 어느 순간부터는 그 '만드는 재미'는 AI가 가져가고, 이해관계 조율·우선순위 싸움·불완전한 정보 속 의사결정만 PM 몫으로 남은 것 같기도 하죠.

그런 와중에 이 JD들이 말하는 것이 한 편으론 위안이 되기도 합니다. AI 덕분에 PM이 오히려 '오롯히 재미있게 만드는 역할'을 더 챙겨볼 수 있을 거에요.  그 방향으로 가보는 첫 발은 세 가지면 충분합니다.

① Eval 설계 감각 

AI 기능에는 pass/fail이 없어서, '이게 잘 되고 있는지'를 측정하는 방법 자체를 PM이 정의해야 합니다.

지금 당장 해볼 수 있는 건 내 제품에서 AI 기능 하나의 성공 기준을 직접 써보는 것이에요. Anthropic의 "Demystifying Evals for AI Agents"와 클로드와 함께라면 시작은 문제 없어요.

어떤 케이스가 golden set인지, 어떤 실패가 허용 가능한지 — 이걸 엔지니어보다 먼저 정의하는 PM이 아직은 많지 않대요.

② 직접 만들어본 경험 한 개

모든 JD에 공통으로 들어간 게 '프로토타입 직접 빌드 경험'이에요. 완성도가 아니라 방향이 중요합니다. 본인 업무의 불편한 점 하나를 클로드로 실제로 해결해보는 것 — 내부 대시보드, 데이터 취합 자동화, 보고서 생성기 같은 것. 이 경험이 쌓이면 엔지니어와 대화하는 언어가 달라집니다. Product Makers Note의 다양한 팁들을 활용해보세요!

③ AI 기능의 '출시 결정' 경험

AI 기능 출시를 앞두고 가장 어려웠던 게 '언제 충분히 좋은 거지?'였어요. QA는 통과했는데 오류율이 7%면 내보내야 하는지, 8%는 안 되는 건지 — 이 기준이 없으면 결정이 나지 않아요. 언제 충분히 좋은 건지, 어느 수준의 오류율이 허용 가능한지, 어떤 fallback을 설계할지 — 지금 AI 기능을 하나라도 다루고 있다면, 그 출시 기준을 문서화해두는 것만으로도 포트폴리오가 됩니다. 

우리가 둘러본 JD는 몇개월 후면 또 변해있을지도 몰라요. 여러가지 이정표들을 보시고 첫 발을 내딛어 보기로 해요. 결국은 미래 행동의 한 단면을 현실감 있게 만들어 대응할 수 있는 PM이 되기 위해서는 어디든 가볼 수 있는 곳까지 충분히 나아가봐야 하니까요.

📮 다음 호 예고

[21호] 예쁘게 쓴 문서, AI는 왜 못 읽을까?

헤딩 잡고 굵게 강조해서 “보기 좋게” 만든 문서, AI도 잘 읽을 수 있을까요?

알고 보니 사람이 잘 읽는 문서와 AI가 잘 읽는 문서는 원리가 다르더라고요. 사람은 여백과 행간의 맥락으로 읽고, AI는 명시적인 구조와 빠짐없는 맥락으로 읽거든요.

다음호에선 11호에서 다뤘던 UX 라이팅 후속편으로 이 둘을 비교해볼게요. 같은 내용을 어떻게 다르게 써야 하는지, 둘 다 만족시키는 글쓰기는 가능한지까지 경험담 기반으로 풀어봅니다.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.