[무신사] Product Manager (Core Catalog) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 팀무신사 통합 카탈로그의 고도화 방향을 수립하고, 플랫폼 전반의 상품 운영 기반을 강화하는 제품 로드맵과 우선순위를 관리합니다.

  이렇게 볼 수 있어요

  Product Engineer (Catalog)는 같은 Core Catalog 조직이 29CM, 솔드아웃, 글로벌로 확장한 상품 데이터를 OCMP 철학으로 공통화하는 통합 카탈로그 플랫폼을 만든다고 적었습니다. 이 공고 업무는 엔지니어링을 협업 조직으로 적어, 이 PM이 정하는 로드맵을 함께 실행하는 상대가 그 엔지니어링 조직일 수 있습니다. 우선순위는 무신사, 29CM, 글로벌의 요구가 부딪힐 때 정하는 일이라 무엇을 먼저 하고 무엇을 미뤘는지가 사례의 중심이 됩니다.

• 카테고리·속성·옵션의 표준 체계를 정의하고 멀티 플랫폼 환경(무신사, 29CM, 글로벌)에 일관되게 적용해 상품 데이터의 정확도와 정합성을 확보합니다.

  이렇게 볼 수 있어요

  팀 소개는 같은 상품이 플랫폼마다 다른 기준으로 관리되면 운영 복잡도와 품질 리스크가 커진다고 적었습니다. 표준 체계는 플랫폼마다 달리 부르던 속성과 옵션을 한 기준으로 묶는 일입니다. 표준을 정한 뒤 속성 값이 플랫폼 사이에서 일치하는 비율이 어떻게 달라졌는지를 쓸 수 있습니다.

• AI 기반 속성 자동화, 검수, 그룹핑 같은 데이터 품질 고도화 과제를 설계하고 Fill-rate, Accuracy 등 핵심 지표로 관리합니다.

  이렇게 볼 수 있어요

  Fill-rate는 속성이 채워진 상품의 비율이고 Accuracy는 채워진 값이 맞는 비율입니다. 자동 채움을 늘리면 앞의 값은 오르는 대신 뒤의 값이 흔들릴 수 있어, 두 지표를 함께 관리한 경험이 이 업무와 이어집니다. 우대 사항의 GMV·CVR 같은 비즈니스 지표는 그 위의 단계입니다.

• ZOZO, Tmall 등 글로벌 오픈마켓과의 상품 데이터 연동 구조를 설계하고 다국어·다국가 상품 요구사항에 대응하는 카탈로그 확장 체계를 수립합니다.

  이렇게 볼 수 있어요

  팀 소개는 파트너가 한 번 등록하면 여러 해외 채널에서 팔 수 있는 구조를 만든다고 적었습니다. Program Manager (글로벌 커머스) 공고는 같은 연동 채널인 조조타운과 티몰 글로벌의 입점 파트너 프로그램과 채널별 상품 연동 현황을 맡습니다. 데이터 구조는 이 공고가, 채널 운영은 그 공고가 다룹니다. 채널마다 규격이 다른 카테고리 체계를 매핑한 경험이 있다면 매핑 규칙의 수가 연동 규모를 보여 줍니다.

• 반복적이고 수기로 진행되는 업무를 분석해 자동화 과제로 전환하고, 운영 효율과 품질 개선 효과를 지표 기반으로 증명합니다.

  이렇게 볼 수 있어요

  어떤 수기 업무인지는 공고가 적지 않았지만, 팀 소개에 파트너와 내부 운영자가 상품을 등록하고 관리할 때 혼선을 겪는다는 설명이 있어 운영자의 반복 검수와 파트너의 등록 수정이 후보입니다. 자동화 전후의 건당 처리 시간을 나란히 적으면 지표 기반 증명이 됩니다.

• 엔지니어링, 데이터, 운영 조직과 협업해 사용 사례(Use Case) 중심으로 문제를 정의하고, 단계적 출시로 제품 적용과 확산을 주도합니다.

  이렇게 볼 수 있어요

  사용 사례 중심의 단계적 출시는 큰 과제를 파트너 등록, 운영자 검수, 검색 노출 같은 사용 장면으로 나눠 한 번에 하나씩 내보내는 방식입니다. 속성 체계 개편처럼 한꺼번에 내면 위험한 과제를 장면별로 쪼갠 사례가 있다면 쪼갠 기준과 출시 순서가 이 방식의 핵심입니다.

2자격 요건

• 데이터 기반 제품(카탈로그, 백오피스, 운영 툴, 정책 시스템 등)을 기획부터 출시, 운영, 개선까지 end-to-end로 책임진 경험을 요구합니다.

  이렇게 볼 수 있어요

  Product Manager (PDP/캠페인/콘텐츠) 공고는 홈, 검색, 카테고리, PDP 같은 고객 탐색 지면의 문제 해결을 요건으로 들었습니다. 이 공고는 카탈로그, 백오피스, 운영 툴, 정책 시스템을 예로 들고 연차 숫자는 적지 않았습니다. 같은 PM 직함이라도 이 공고에서 보여 줄 것은 고객 화면 밖에서 만든 제품을 어디까지 책임졌는지입니다. 소비자 앱 중심 PM 경력이라면 백오피스나 운영 툴을 맡았던 프로젝트를 따로 적고, 기획부터 운영까지 맡은 구간을 구분해 씁니다.

• 공통 기준(정의, 정책, 데이터 모델 등)을 수립하고 이해관계자와 조율해 실제 조직과 시스템에 적용하고 확산시킨 경험을 요구합니다.

  이렇게 볼 수 있어요

  이 팀의 공통 기준은 무신사, 29CM, 솔드아웃이 각자 쓰던 상품 기준을 하나로 모으는 것이라, 확산의 상대는 플랫폼마다 따로 있던 운영 조직과 상품을 등록하는 파트너입니다. 새 기준을 정하는 일보다 기존 기준을 쓰던 조직이 옮겨 오게 하는 과정에서 부딪히는 요구가 더 큰 부담이 되는 경우가 많습니다. 정의서 하나와 그 기준을 실제로 따르게 된 조직 수, 옮겨 오며 부딪힌 요구를 함께 적습니다.

• 복잡한 운영 문제를 구조화하고 표준화·자동화 가능한 단위로 나눠 제품 요구사항으로 전환할 수 있는 역량을 요구합니다.

  이렇게 볼 수 있어요

  요건의 '표준화·자동화 가능한 단위'는 업무의 AI 속성 자동화와 Accuracy 관리로 이어지는 구분입니다. 표준화는 옵션 이름 통일이나 카테고리 매핑처럼 규칙으로 정하는 쪽입니다. 자동화는 예컨대 상품명과 이미지에서 속성을 채우는 일처럼 AI에 맡기는 쪽이고, 사람이 끝까지 판단할 부분은 Accuracy를 점검하는 검수입니다. 문제를 이렇게 세 갈래로 나눠 요구사항으로 옮긴 문서가 있다면 나눈 기준과 검수로 남긴 부분을 함께 적습니다.

• 엔지니어링과 데이터 조직과 협업하며 데이터 흐름, 정합성, 품질 관점에서 요구사항을 명확히 정의할 수 있는 역량을 요구합니다.

  이렇게 볼 수 있어요

  정합성은 시스템 사이에서 같은 상품의 값이 일치하는지를 가리킵니다. 이 팀의 데이터는 파트너의 한 번 등록에서 시작해 무신사, 29CM, 솔드아웃과 ZOZO, Tmall까지 가므로, 정합성 요구사항은 한 시스템 안의 값이 맞는가보다 등록한 값이 나가는 길마다 같은 뜻으로 남는가에 가깝습니다. 요구사항 문서에 이 흐름을 어디까지 그렸고 도착 지점마다 다른 규격을 어떻게 처리했는지가 사례가 됩니다.

• 우선순위가 충돌하는 상황에서 합리적인 기준을 수립하고 의사결정을 이끌어낼 수 있는 커뮤니케이션과 조율 역량을 요구합니다.

  이렇게 볼 수 있어요

  이 팀의 요구는 무신사, 29CM, 글로벌 세 플랫폼과 파트너, 내부 운영자 쪽에서 동시에 들어옵니다. 충돌한 요구 둘과 우선순위를 정한 기준, 밀린 쪽에 설명한 방식을 한 사례로 설명할 수 있어야 합니다.

3우대 사항

• 상품 데이터 품질 문제를 AI·자동화로 해결하고 GMV·CVR 등 비즈니스 지표로 임팩트를 증명한 경험을 우대합니다.

  이렇게 볼 수 있어요

  이 우대의 GMV·CVR은 업무의 Fill-rate, Accuracy보다 한 단계 위의 지표입니다. 팀 소개에는 상품 정보가 고객의 탐색, 검색, 결제 경험을 돕는 방식을 고민한다는 문장이 있습니다. 속성이 채워진 뒤 검색 클릭이나 전환이 달라졌다면 그 변화를 이 우대의 사례로 꺼낼 수 있습니다.

• 상품 도메인 핵심 엔티티(카테고리·속성·옵션)를 모델링하고 시스템 간 데이터 흐름을 고려해 확장 가능한 구조로 설계한 경험을 우대합니다.

  이렇게 볼 수 있어요

  카테고리마다 필요한 속성이 다르고(신발은 사이즈를 mm로, 의류는 S, M, L로 받는 식) 옵션은 색상과 사이즈 조합이 재고 단위가 되기 때문에, 세 엔티티를 어떻게 이어 설계하느냐에 따라 새 채널이 붙을 때 고칠 범위가 달라집니다. 업무의 표준 체계 정의와 같은 대상이므로, 채널 추가 때 바꾸지 않아도 됐던 부분을 적으면 확장 가능한 구조의 실체를 보여 줍니다.

• 글로벌 오픈마켓 연동, 다국어·다국가 상품 기준 설계 등 외부 채널 확장 과제를 주도한 경험을 우대합니다.

  이렇게 볼 수 있어요

  ZOZO는 일본, Tmall은 중국 마켓이라 같은 상품이라도 사이즈 표기와 필수 속성 항목, 언어가 나라마다 다릅니다. 우대의 '다국어·다국가 상품 기준 설계'는 이 차이를 한 기준 안에 담는 일이어서, 마켓마다 달랐던 항목이 무엇이었고 어느 것을 공통 기준으로 올리고 어느 것을 채널 쪽 변환으로 남겼는지를 연동한 마켓 이름과 함께 씁니다.

• Amplitude·Databricks·SQL 등 데이터 도구로 문제, 해결책, 성공 지표를 스스로 정의하고 검증한 경험을 우대합니다.

  이렇게 볼 수 있어요

  Product Manager (PDP/캠페인/콘텐츠)도 SQL, Amplitude, Databricks를 우대로 적었습니다. 이 공고는 도구 이름보다 문제와 해결책, 성공 지표를 스스로 정의하고 검증했는지를 묻습니다. Databricks는 대규모 데이터를 SQL로 조회하는 데이터 플랫폼이라, 카탈로그 품질을 직접 조회해 확인한 경험이 이 항목에 가깝습니다.

4기타 사항

• 게시일 : 2026년 7월 1일
• 고용형태 : 정규직(수습 3개월)
• 근무지 : 무신사 성수 오피스
• 경력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• Amplitude
• Databricks
• SQL

전형과 지원

무신사 정규직 공고는 기본적으로 인터뷰를 두 번 봅니다. 공고에 따라 3차 인터뷰나 커피챗처럼 단계가 하나씩 더 붙거나 1차 인터뷰를 두 번 보는 공고도 있으므로 지원할 공고의 전형 절차 항목을 따로 확인해야 합니다.

지원 전 준비할 것

1. 1

   플랫폼 사이 상품 기준을 하나로 맞춘 사례 고르기

   여러 서비스나 채널에서 다르게 관리하던 카테고리와 속성을 한 기준으로 묶은 경험을 고르고, 묶은 대상의 수와 일치율의 변화를 정리합니다.

2. 2

   데이터 품질 지표를 두 개 함께 적기

   채워진 비율과 맞는 비율처럼 서로 흔들리는 두 지표를 함께 관리한 사례를 준비합니다. 자동화를 도입했다면 두 값이 각각 어떻게 달라졌는지 적습니다.

3. 3

   수기 업무를 자동화 과제로 바꾼 사례 준비하기

   자동화 전 건당 처리 시간과 후의 시간을 나란히 적고, 사람이 계속 판단해야 했던 부분이 무엇이었는지도 씁니다.

4. 4

   데이터 도구 경험을 문제와 검증으로 풀어 쓰기

   우대 사항이 도구 이름과 함께 문제, 해결책, 성공 지표를 스스로 정의했는지를 묻습니다. 도구별로 어떤 질문에 썼고 무엇을 확인했는지 한 줄씩 적습니다.