프로덕트 오너(PO)는 신사업의 방향을 결정하는 사람입니다. 마케팅 예산을 조정하고, 어떤 기능을 먼저 개발할지 판단하죠. 프로덕트 빌더는 여기에 구현 능력이 더해진 직무입니다.

저희 조직은 프런트팀과 백엔드팀으로 나뉘어 있고, 인프라는 CTO가 코드 기반으로 자동화해 뒀습니다. QA도 별도로 없습니다. 이 환경에서 디자인, 프런트, 백엔드를 전부 커버하는 사람. 그게 저희가 원했던 포지션이었습니다.

💡 "PO 역량에 구현 능력이 더해지면 성장 속도가 압도적으로 빨라진다."

저희 개발팀은 작년 12월부터 코드를 직접 보지 않습니다. 바이브 코딩이 기본 방식이 된 거죠. 면접에서 멀티 모델 비교, 클로드 플러그인 활용법 같은 질문을 했는데, AI를 설계 수준에서 활용한 지원자는 거의 없었습니다.

두 번째 기준은 도메인 경험의 깊이였습니다. 분야는 상관없고, 하나를 깊이있게 이해한 경험이 있느냐가 핵심이었죠. 최근 합류한 AX 담당 창언 님이 이 케이스에 해당됩니다. 법인 영업에서 사내 ERP와 자동화를 직접 만들었던 분인데, 이런 분은 시장에 잘 나오지 않습니다.

💡 "바이브 코딩은 더 이상 트렌드가 아니라 개발 방법론이다."

가장 큰 문제는 '프로덕트 빌더'라는 단어의 해석 차이였습니다. 저희가 정의한 빌더와 시장이 이해하는 빌더가 달랐습니다.

면접에서도 기준이 흔들렸습니다. 기술 이해도를 봐야 하는지, 도메인 지식을 봐야 하는지. 도메인 지식이라 해도 면접관인 제가 해당 분야 전문가가 아닌 상황에서 깊이를 어떻게 확인할지도 명확하지 않았습니다. 기준이 정리되지 않은 상태에서 채용을 계속 진행하는 건 서로 시간 낭비라는 판단이 들었습니다.

💡 "기준 없는 채용은 지원자한테도, 회사한테도 시간 낭비다."

프로덕트 빌더라는 포지션 자체를 없앤 건 아닙니다. 바뀐 건 채용 방식입니다. '백엔드에 특화된 빌더', '디자인에 특화된 빌더'처럼 본인의 강점이 하나는 명확한 상태에서 범위를 넓혀가는 형태로 전환했습니다.

또한 AI로 개발이 쉬워진 만큼, 도메인 이해도와 소통 능력이 채용의 핵심 기준이 되었습니다.

💡 "AI 시대의 채용 기준은 코딩 실력이 아니라 프로덕트를 보는 눈이다."