'AI 프로덕트 빌더' 채용을 시도했다가 배운 것 — 강점 하나부터 시작하라

한 AI 네이티브 개발사가 올해 초 채용 공고를 전면 수정했다. 디자이너, 프런트엔드, 백엔드로 나누던 포지션을 모두 내리고 'AI 네이티브 프로덕트 빌더'라는 단일 포지션으로 채용을 시도한 것이다. 지원자는 꽤 들어왔고 면접도 수십 건 진행했지만 채용까지 이어진 사례는 없었다.

프로덕트 빌더란

프로덕트 빌더는 디자인부터 프런트엔드, 백엔드까지 수행하며 프로덕트를 직접 만드는 포지션이다. 비교 대상인 프로덕트 오너(PO)는 신사업 방향, 마케팅 예산, 개발 우선순위 같은 판단을 내리는 역할인데, 빌더는 여기에 구현 능력까지 더한 직무다.

이 회사는 프런트엔드팀과 백엔드팀으로 나뉘어 있고 인프라는 CTO가 자동화해 둔 상태였다. 이 환경에서 디자인·프런트·백엔드를 전부 해내는 사람이 그들이 생각한 빌더였다.

평가 기준 두 가지

바이브 코딩은 이제 방법론이다

이 회사 개발팀은 작년 12월부터 코드를 직접 보지 않는다. 바이브 코딩이 기본 방식이 됐다. 면접에서 멀티 모델 비교나 클로드 플러그인 활용법 같은 질문도 했는데, AI를 구조적으로 설계에 활용하는 지원자는 많지 않았다.

깊이 있는 도메인 경험

두 번째 기준은 분야를 가리지 않고 하나를 깊이 이해해 본 경험이 있느냐였다. 최근 합류한 AX 담당자가 이 케이스인데, 법인 영업에서 사내 ERP와 자동화를 직접 만든 이력을 가졌다. 다만 이런 인재는 이미 인하우스에서 대우받고 있어 시장에 잘 나오지 않는다.

왜 채용이 안 됐나

수십 건의 면접을 거치며 회사가 정의한 프로덕트 빌더와 시장이 생각하는 빌더의 기준이 꽤 다르다는 것이 드러났다. 기술 이해도로 봐야 할지 도메인 지식수준으로 봐야 할지도 모호했고, 면접관이 해당 도메인 전문가가 아닌 상황에서 깊이를 확인하기도 어려웠다.

바뀐 기준: 강점 기반 빌더

포지션이 사라진 것은 아니다. 내부에는 이미 디자인을 하면서 프런트·백엔드를 함께 하는 인력이 있다. 달라진 것은 채용 방식이다. '백엔드에 특화된 빌더', '디자인에 특화된 빌더'처럼 본인 강점이 하나 명확한 상태에서 범위를 확장하는 형태로 채용한다.

실제로 최근 디자이너 채용은 "프로덕트 빌더에 관심 있는 디자이너"로 공고를 올렸고, 입사 후 프런트·백엔드 지식을 습득할 환경을 제공할 계획이다. 실제 프로젝트에서 클라이언트가 아쉬워하는 것은 디자인 퀄리티보다 도메인 이해 부족인 경우가 더 많다는 판단이다. 개발이 AI로 어느 정도 쉬워졌으니 도메인 이해도와 커뮤니케이션 능력이 더 중요해졌다는 뜻이다.

직무별 차별화 전략

처음 AI 네이티브를 선언했을 때는 모두가 같은 직무로 일해야 한다고 생각했지만, 프로젝트를 거듭하며 생각이 바뀌었다. 각자의 강점을 파악하고 그것을 부각하는 도구로 AI를 활용해야 한다는 것이다.

• 프런트엔드 개발자: SEO, UX처럼 사용자 대면 영역을 깊이 공부
• 백엔드 개발자: API 명세서, 아키텍처 설계 같은 문서 역량까지 확장
• 디자이너: 목업 사이트를 스스로 만들 수 있는 수준이면 시장에서 유니크한 포지션 확보

코딩 테스트는 유지하되, 프로덕트에 대한 고민을 얼마나 하는 사람인지, 고객 관점에서 서비스를 보는 능력이 있는지를 더 집중적으로 평가할 계획이다.

마케터에게도 같은 구조가 온다

이 사례는 개발·디자인 직군의 이야기지만 구조는 마케팅에도 그대로 적용된다. 도구가 실행 난이도를 낮추면 조직은 '전부 다 하는 사람'을 찾고 싶어 하지만, 실제로 채용 가능한 형태는 '강점 하나가 뚜렷하고 인접 영역으로 확장 중인 사람'이다. 확장의 출발점이 없으면 범용성은 평범함으로 읽힌다.

커리어를 넓히는 태도의 사례는 "저는 손들고 하는 마케터예요" — 커리어를 넓힌 사람의 6가지 태도에서, 개인의 감각을 반복 가능한 절차로 만드는 방법은 기획자와 디자이너를 위한 'Skill' — 개인의 감각을 반복 가능한 절차로에서 볼 수 있다.