[무신사] Product Engineer (SCM Platform) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• SKU 마스터와 기준정보 플랫폼을 개발합니다. 전사 단일 SKU 마스터(SSoT)를 설계·운영하며 플랫폼별로 나뉜 상품·옵션·바코드 식별 체계를 통합하고, 커머스 유형(1P/2P/PB/3P)별 소유권을 모델링해 기준정보 배포 인터페이스를 설계하며, 주문·물류·카탈로그·ERP 연동을 고려한 확장 가능한 기준정보 아키텍처를 설계합니다. 팀과 팀원의 기술적 성장을 주도합니다.

  이렇게 볼 수 있어요

  SSoT는 Single Source of Truth의 약자로 전사에서 하나의 값만 정답으로 두는 구조입니다. 업무 문장에는 3P가 더해져 있어 판매 유형이 늘어나는 것을 전제로 소유권 모델을 짜야 합니다. 업무에는 팀과 팀원의 기술적 성장 주도도 적혀 있어, 이 포지션은 구현과 함께 팀 단위 리드 역할도 맡습니다.

• 발주·입고 프로세스를 개발합니다. 구매요청(PR)부터 발주(PO)까지의 워크플로우와 매입예산(OTB) 검증 시스템을 구축하고, 파트너의 입고 신청부터 ASN 등록, 물류센터 입고 지시와 실적 반영까지의 파이프라인을 개발하며, 레거시 ERP(SAP) 연동 인터페이스를 개발하고 자체 시스템으로의 단계적 전환(디커플링)을 설계합니다.

  이렇게 볼 수 있어요

  OTB는 발주 전에 매입 예산 한도를 시스템이 확인하는 장치이고, ASN은 파트너가 보내는 입고 예정 정보입니다. SAP 디커플링은 기능을 한 번에 옮기지 않고 단계적으로 옮기는 설계여서, SAP와 새 시스템이 함께 돌 때 데이터 정합성을 지킨 경험이 쓰입니다. 같은 회사의 SAP Engineer (MM) 공고는 팀무신사 ERP의 개발과 운영을 맡는 조직이 SAP MM(구매·자재·재고)을 다룬다고 적어, 이 팀이 연동할 레거시 ERP를 운영하는 쪽일 가능성이 큽니다.

• 재고와 소유권 전환 시스템을 개발합니다. 상품·물리 단위·보관 위치를 기준으로 재고 모델을 설계하고 모든 재고 변동에 감사 추적(Audit Trail)을 구현하며, 위탁(2P)에서 매입(1P)으로의 소유권 전환 과정에서 물류·주문 시스템을 연계하는 End-to-End 오케스트레이션을 설계합니다.

  이렇게 볼 수 있어요

  위탁에서 매입으로 소유권이 바뀌면 같은 물건의 재고 주체와 정산이 바뀌므로 물류와 주문 시스템이 같은 시점에 맞춰야 합니다. 모든 재고 변동에 감사 추적을 구현한다는 항목은 재고 차이가 생겼을 때 변동 이력을 거슬러 갈 수 있게 하는 장치입니다.

• PM·디자이너 및 유관 조직과 함께 해결할 고객 문제와 우선순위를 정의하고, 모호한 요구는 측정 가능한 가설로 바꾸며, 출시 이후 지표로 성과를 확인해 다음 개선으로 연결합니다.

  이렇게 볼 수 있어요

  이 팀의 시스템은 내부 운영 도구여서 문제를 겪는 고객이 MD, 물류센터 운영자, 파트너일 수 있습니다. 지표도 입고 처리 시간이나 재고 불일치 건수 같은 운영 값이 됩니다.

• AI 코딩 에이전트를 설계·구현·테스트·코드 리뷰·운영 전반에 활용하고, 그 경험을 팀과 나눠 개발 생산성과 품질을 높이는 AI 기반 개발 방식을 조직에 만들어 갑니다.

  이렇게 볼 수 있어요

  기술 스택 목록의 마지막 줄에 Codex와 Claude Code 같은 코딩 에이전트가 AI 개발 도구로 적혀 있습니다. 재고와 발주처럼 규칙이 많은 코드에서 에이전트가 만든 결과를 어떻게 검증했는지가 이 업무의 질문입니다.

2자격 요건

• 8년 이상의 백엔드 개발 경험을 보유하며, 복잡한 비즈니스 로직을 코드와 아키텍처로 구조화할 수 있어야 합니다.

  이렇게 볼 수 있어요

  공고 머리의 경력도 8년 이상입니다. 같은 PE 계열의 Retention은 7년, Partner Ads & Growth는 5년, Catalog는 10년 이상을 요구합니다. 재고와 발주는 규칙이 많은 도메인이라 복잡한 비즈니스 로직을 구조화한 사례는 규칙의 개수와 상태 전이로 설명하면 전달됩니다.

• Java/Kotlin 및 Spring 기반의 실무 역량이 탄탄하고, 대규모 트래픽 환경을 경험해 본 분이어야 합니다.

  이렇게 볼 수 있어요

  스택에 Kafka와 RabbitMQ가 함께 있어 재고 변동이 메시지로 전파되는 구조가 전제입니다. 대규모 트래픽 경험은 이런 이벤트 처리량으로도 쓸 수 있습니다.

• 도메인의 복잡도를 이해하고 객체 지향적인 설계와 클린 코드를 지향해야 합니다.

  이렇게 볼 수 있어요

  SKU, 재고, 소유권처럼 규칙이 많은 도메인이어서 객체 지향 설계는 재고 상태 전이 규칙을 코드에 어떻게 담았는지로 드러납니다. 소유권 전환 같은 상태 변화를 모델링한 경험이 맞습니다.

• 비즈니스 목표를 달성하기 위해 기술적 의사결정을 주도하고 리딩해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  이 팀의 기술적 의사결정은 SAP를 어떻게 걷어 내느냐에 걸려 있습니다. 업무가 SAP 연동 인터페이스 개발과 자체 시스템으로의 단계적 전환(디커플링) 설계를 함께 적고, 위탁에서 매입으로 소유권이 바뀔 때 물류와 주문 시스템을 연계하는 설계도 맡깁니다. 어떤 기능을 먼저 옮기고 무엇을 남길지 정한 기준과, 그 순서를 다른 팀에 설명해 합의를 끌어낸 과정을 꺼낼 수 있습니다.

• CI/CD 기반의 배포 자동화와 안정적인 서비스 운영 프로세스에 대한 경험과 이해가 필요합니다.

  이렇게 볼 수 있어요

  스택에 Terraform과 Datadog, Prometheus, Grafana가 올라 있어 인프라와 모니터링을 개발자가 함께 다루는 팀입니다. 배포 자동화와 운영 프로세스 경험은 이 도구들을 직접 쓴 범위로 밝힙니다.

• 구현에 머무르지 않고 고객 문제를 함께 정의하고, 출시 이후의 지표로 결과를 확인하며 일해 온 경험이 필요합니다.

  이렇게 볼 수 있어요

  PM·디자이너와 함께 문제를 정의하는 PE 방식이 이 항목에 있습니다. 재고와 발주 시스템에서는 MD나 물류 운영자가 겪는 작업 지연이 고객 문제이므로 내부 사용자의 문제를 지표로 확인한 경험도 이 요건과 이어집니다.

• 기술적 의사결정을 트레이드오프와 함께 문서로 정리하고 비즈니스 맥락에서 설명할 수 있어야 합니다.

  이렇게 볼 수 있어요

  1차 인터뷰가 Architecture Design으로 진행되므로 문서에 남긴 트레이드오프는 설계 질문에서 다시 설명하게 됩니다.

• AI 코딩 에이전트(Codex, Claude Code 등)를 실무에 적극 활용하고 그 결과물의 품질을 스스로 검증하고 책임질 수 있어야 합니다.

  이렇게 볼 수 있어요

  Codex와 Claude Code가 기술 스택에 이름으로 올라 있습니다. 결과물 품질을 스스로 검증하고 책임진다는 말은 지원 서류 안내가 AI 활용 방식, 결과, 검증 방법을 적어 달라고 요청한 것과 같은 말입니다.

3우대 사항

• 레거시 시스템을 점진적으로 개선하거나 MSA로 전환하는 과정을 주도하고 성공적으로 안착시킨 경험을 우대합니다.

  이렇게 볼 수 있어요

  이 팀에서 레거시는 SAP입니다. 업무가 SAP 연동 인터페이스를 개발하면서 자체 시스템으로 단계적으로 옮기는 디커플링을 설계하는 일을 적었습니다. 기존 시스템을 멈추지 않고 기능을 하나씩 떼어 낸 MSA 전환 경험이라면 나눈 서비스 수와 전환 중 두 시스템의 데이터 정합성을 지킨 방식을 적습니다.

• 기술적 문제를 글로 정리하고 공유하는 테크니컬 라이팅과 코드 리뷰 문화를 즐기는 분을 우대합니다.

  이렇게 볼 수 있어요

  단일 SKU 체계처럼 설계 판단이 여러 시스템에 영향을 주는 팀이라 설계 문서의 비중이 큽니다. 공고는 회사 소개에 무신사 테크 블로그 링크를 달았으므로 공개된 글이 있다면 링크로 낼 수 있습니다.

• 물류/커머스 도메인에 대한 깊은 이해나 구축 경험을 우대합니다.

  이렇게 볼 수 있어요

  발주, 입고, ASN, 재고가 모두 물류 용어라 물류센터 입고 프로세스나 WMS 연동을 구축한 경험이 직접 쓰입니다. 같은 회사의 Product Engineer (Purchase) 공고는 주문 이후 배송 쪽을 WMS 연동으로 적었고, 이 팀은 그보다 앞의 공급 흐름을 맡습니다.

• 비즈니스 KPI를 기술로 개선하고 수치로 증명해 본 경험, 가설 수립, 실험, 데이터 검증을 거쳐 제품 의사결정에 참여해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  파트너와 물류센터가 쓰는 운영 시스템은 사용자 수가 적어 트래픽을 나눠 돌리는 A/B 실험이 어렵습니다. 그래서 가설 검증 경험은 한 물류센터나 한 커머스 유형에 먼저 적용한 전후 비교로도 적을 수 있습니다. 재고 정확도나 입고 처리 시간처럼 이 팀 시스템이 직접 바꾸는 값을 개선 전후 숫자로 보여 주는 사례가 맞습니다.

• AI를 개발 프로세스에 도입해 팀 단위 생산성이나 품질을 개선한 경험을 우대합니다.

  이렇게 볼 수 있어요

  필수 항목은 개인이 AI 코딩 에이전트를 쓰고 결과를 스스로 검증하는 일이고, 이 우대는 그 방식을 팀 단위로 넓힌 경험입니다. 업무도 에이전트를 설계부터 운영까지 쓰고 'AI 기반 개발 방식을 조직에 만들어 갑니다'라고 적었습니다. 리뷰 시간이나 결함 수 같은 팀 단위 수치와 함께 팀원이 같은 방식을 쓰게 된 경로를 함께 적습니다.

• AI를 활용해 클라이언트 밖의 영역(서버 API, 데이터 파이프라인 등)까지 직접 문제를 풀어 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  소개가 서버, 웹, 모바일 엔지니어를 Product Engineer 한 직군으로 묶는 만큼, 클라이언트 밖이라는 말은 백엔드 지원자에게는 서버 API와 데이터 파이프라인이 이미 본업의 범위라는 뜻입니다. 지원 서류 안내가 따로 '전문 영역 밖으로 문제를 넓혀 풀어 본 경험'을 적어 달라고 한 것이 같은 질문입니다. 화면이나 앱 코드까지 AI로 풀어 본 경험이나 재고와 발주 데이터를 AI로 분석한 경험을 꺼냅니다.

4기타 사항

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

쓰는 기술

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

• Java
• Kotlin
• Spring Boot
• Spring Cloud
• JPA
• Hibernate
• AWS
• Kubernetes
• Terraform
• MySQL
• Redis
• PostgreSQL
• Kafka
• RabbitMQ
• Datadog
• Prometheus
• Grafana
• Codex
• Claude Code

전형과 지원

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

지원 전 준비할 것

1. 1

   재고·기준정보 통합 사례 한 건

   여러 시스템의 상품이나 재고 데이터를 하나로 합친 프로젝트를 문제 정의, 해결 전략, 성과 순서로 적고 프로젝트별 기여도를 표기합니다.

2. 2

   Live Coding과 설계 연습 따로

   1차 인터뷰 두 번이 Live Coding과 Architecture Design으로 진행되므로 재고 차감이나 상태 전이를 코드로 푸는 연습과 소유권 전환을 포함한 재고 모델을 그려 보는 연습을 구분해 준비합니다.

3. 3

   AI 활용 사례를 검증까지

   AI로 푼 문제의 활용 방식과 결과, 검증 방법을 적고 전문 영역 밖으로 넓혀 푼 경험도 함께 정리합니다.