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

이 자리가 왜 생겼을까요

1하게 될 업무

• 주문·결제 핵심 시스템을 설계하고 개발합니다. 장바구니부터 결제, 주문 완료까지의 전 과정을 책임지는 시스템을 설계하고 개선하며, 하루 수십만 건의 대용량 트래픽과 다양한 예외 상황을 고려해 높은 신뢰도의 시스템을 운영하고, 다양한 결제 수단 및 외부 시스템과 실시간으로 연동되는 주문 흐름을 처리합니다.

  이렇게 볼 수 있어요

  결제 수단과 외부 시스템 연동이 실시간으로 이뤄져 한 곳이 느려지거나 응답이 늦을 때 주문 상태를 일관되게 유지하는 일이 설계 과제입니다. 타임아웃 뒤 중복 결제나 유실을 막은 방식이 이 업무와 맞는 경험입니다. 조직 소개에 따르면 이 시스템은 하루 30만 건, 분당 최대 1.5만 건의 주문을 처리합니다.

• 배송 정책·도메인을 설계하고 물류 시스템과 연동합니다. 배송 방식·옵션·배송비 정책을 설계하고, 트래킹 시스템 연동으로 주문 이후의 배송 흐름과 상태를 관리하며 주문·클레임 도메인과 연결하고, WMS와 국내외 배송사 등 외부 물류 시스템과 연동하며, 무신사와 29CM 및 국내/글로벌 통합 배송 데이터 모델을 설계합니다.

  이렇게 볼 수 있어요

  배송 방식, 옵션, 배송비를 정책으로 설계하고 WMS와 배송사에 연동한다는 것은 주문 이후의 상태가 외부 시스템의 이벤트로 바뀐다는 뜻입니다. 같은 회사의 Product Engineer (SCM Platform) 공고가 발주와 입고 쪽 물류 연동을 맡고, 이 팀은 주문 이후 배송 흐름을 플랫폼 관점에서 맡습니다.

• 클레임(교환·환불) 시스템을 설계하고 개발합니다. 각종 할인과 결제수단이 얽힌 주문의 교환·환불을 정확하게 처리하는 시스템을 구축하고, 플랫폼·국가별로 다른 클레임 정책을 통합 관리하는 구조를 설계하며, 클레임 도메인 시스템의 확장성과 독립성을 높이는 설계를 도입하고, 무신사와 29CM 및 국내/글로벌을 포괄하는 통합 데이터 모델을 설계하고 데이터 마이그레이션을 계획하고 실행합니다.

  이렇게 볼 수 있어요

  쿠폰, 포인트, 카드 결제가 섞인 주문의 환불은 어느 수단으로 얼마를 돌려줄지 정하는 계산이 핵심입니다. 통합 데이터 모델 마이그레이션은 두 플랫폼의 정책을 한 구조로 옮기는 일이어서 이행 중 옛 구조와 새 구조가 함께 돌아가는 기간이 생길 수 있습니다.

• 고객의 실제 사용 흐름과 잠재 이슈까지 고려한 사용자 중심의 주문·클레임 경험을 만들어 갑니다.

  이렇게 볼 수 있어요

  이 항목은 시스템 구조가 아니라 고객이 접수 화면에서 겪는 흐름을 말합니다. 쿠폰, 포인트, 카드가 섞인 주문은 환불 예정 금액이 결제 금액과 달라 보여 고객 문의로 이어질 수 있어서, 접수 단계에서 막히거나 문의가 몰린 구간을 로그와 문의 건수로 찾아 고친 경험이 사례가 됩니다. PE 소개가 '고객 경험과 지표가 실제로 바뀌었는지까지 확인합니다'라고 적은 일이 이 항목의 모습입니다.

• 주문·클레임 도메인의 복잡한 문제를 기술적으로 정의하고 설계 레벨에서 해결합니다. 대용량 트래픽을 처리하는 기존 시스템을 안정적으로 운영하면서 차세대 구매 플랫폼으로의 전환을 이끌고, 아키텍처 리뷰·기술 토론·장애 회고에 참여하며, PM·디자이너 및 유관 조직과 함께 고객 문제와 우선순위를 정의하고 모호한 요구를 측정 가능한 가설로 바꾸고 출시 이후 지표로 성과를 확인합니다.

  이렇게 볼 수 있어요

  조직 소개는 '서로 다른 수십 개의 정책과 요구사항이 충돌하는 복잡성' 속에서 하나의 시스템을 만든다고 적었고 이 업무는 그 전환을 기존 시스템 운영과 함께 하라고 합니다. 하루 30만 건을 처리하는 운영 중에 구조를 바꾸므로 새 설계가 정책 충돌을 풀었는지는 장애 회고와 아키텍처 리뷰에서 다시 확인됩니다. 전환 중 장애를 회고하고 설계를 고친 경험이 이 항목에 맞는 사례입니다.

• 동료와의 코드 리뷰와 테스트 코드 작성으로 코드 품질을 유지하고, 주도적으로 설계하고 실험하는 문화 속에서 기술 세션 등으로 팀 전체의 역량을 높이는 데 기여합니다.

  이렇게 볼 수 있어요

  이 항목은 개인 구현이 아니라 팀이 품질을 유지하는 방식을 묻고, 원문이 '주도적으로 설계하고 실험하는 문화'라는 말로 설계 단계의 참여도 함께 적었습니다. 주문과 클레임 코드는 쿠폰, 포인트, 결제수단 조합마다 계산 결과가 달라져서 조합을 테스트 케이스로 남겼는지를 리뷰에서 먼저 확인하게 됩니다. 기술 세션은 그 케이스를 팀에 나누는 자리로 쓸 수 있습니다. 세션 주제와 참여 인원을 함께 적으면 기여의 크기가 보입니다.

• 반복되는 이슈와 수작업을 자동화하려고 AI 도구를 적극 활용하고, 최신 AI 기술을 탐색하며, AI 코딩 에이전트를 설계·구현·테스트·코드 리뷰·운영 전반에 활용하고 그 경험을 팀과 나눠 AI 기반 개발 방식을 조직에 만들어 갑니다.

  이렇게 볼 수 있어요

  기술 스택 목록에는 Codex, Claude Code 같은 코딩 에이전트가 Java, Kafka와 같은 줄에 올라 있어 AI 활용도 팀 개발 환경의 일부입니다. 스택은 팀 환경에 따라 달라질 수 있다는 단서와 함께 '특정 도구의 사용 경험보다 문제에 맞는 기술을 선택하고 조직에 정착시키는 역량을 중요하게 봅니다'라는 문장이 따라옵니다. 그래서 도구 이름보다 선택한 이유와 팀에 정착시킨 과정이 사례의 중심입니다. 업무는 설계부터 운영까지 전 구간에 쓰고 그 경험을 팀과 나누는 것까지 포함합니다.

2자격 요건

• 10년 이상의 Java 및 Spring 기반 백엔드 개발 경험과 역량을 보유해야 합니다.

  이렇게 볼 수 있어요

  원문은 '경험과 역량'을 함께 적었고 공고 머리의 경력도 10년 이상입니다. 같은 PE 계열의 Catalog 공고는 머리가 5년 이상이고 자격 요건이 10년 이상이라 표기가 달랐는데, 이 공고는 둘 다 10년 이상으로 같습니다.

• 대용량 트래픽 환경에서 안정적인 시스템 설계와 운영 경험이 필요합니다.

  이렇게 볼 수 있어요

  조직 소개의 하루 30만 건, 분당 최대 1.5만 건이 이 요건이 말하는 대용량의 규모감입니다. 경험한 시스템의 처리량과 피크 때 병목을 찾은 사례를 숫자와 함께 쓰면 규모감이 전달됩니다.

• JPA(Hibernate) 등 ORM 사용에 능숙하고, 대용량 데이터를 고려한 데이터베이스 설계와 SQL 튜닝 경험이 필요합니다.

  이렇게 볼 수 있어요

  조직 소개가 50억 건이 넘는 데이터를 기반으로 한다고 적어 '대용량 데이터를 고려한' 설계는 테이블 크기 문제를 포함합니다. 주문과 클레임 데이터는 이력이 계속 쌓이고 조회가 많습니다. JPA 같은 ORM 때문에 화면 하나에 쿼리가 수십 번 나가는 문제(N+1)를 실행 계획으로 확인해 고친 경험과 오래된 데이터를 나누거나 옮긴 경험이 이 요건과 맞습니다.

• 복잡한 비즈니스 요구사항을 이해하고 도메인 모델로 구체화해 객체지향적으로 설계할 수 있어야 합니다.

  이렇게 볼 수 있어요

  클레임 도메인은 할인, 결제수단, 정책 조합이 늘어 규칙이 서비스 코드에 흩어지기 쉽습니다. 업무의 확장성과 독립성을 높이는 설계는 그 규칙을 도메인 모델 안에 모으는 일이어서, 규칙이 늘었을 때 구조를 어떻게 지켰는지를 사례로 꺼냅니다.

• 클라우드 환경 또는 Kubernetes 기반 개발·운영 경험이 필요합니다.

  이렇게 볼 수 있어요

  원문은 필수 조건을 클라우드 환경 또는 Kubernetes로 적고 AWS는 우대에서 EKS, Aurora, S3로 따로 적었습니다. 클라우드 경력과 Kubernetes 경력은 이 조건에 함께 적을 수 있고 AWS 외 클라우드 경력도 이 조건에 적을 수 있습니다. 개발과 운영이 한 줄에 있어 코드를 쓴 사람이 배포와 운영 지표까지 맡는 방식을 전제합니다.

• 다양한 직군과 협업하며 논리적 커뮤니케이션과 문제 해결을 주도한 경험, 구현에 머무르지 않고 고객 문제를 함께 정의하고 출시 이후의 지표로 결과를 확인하며 일해 온 경험이 필요합니다.

  이렇게 볼 수 있어요

  PE는 PM·디자이너와 문제 정리나 프로토타입으로 논의를 먼저 시작하는 직군이라 이 두 요건은 업무의 모호한 요구를 가설로 바꾸는 항목과 같은 줄에 있습니다. 출시 뒤 지표를 확인해 다음 개선으로 이은 경험은 지표 이름과 개선 전후 값으로 보여 줍니다.

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

  이렇게 볼 수 있어요

  이 팀의 결정은 무신사와 29CM, 국내와 해외 정책이 충돌할 때 어느 정책을 통합 모델에 넣고 어느 정책을 플랫폼별로 남길지처럼 사업 쪽 설명이 따라붙는 선택입니다. 그래서 '비즈니스 맥락에서 설명'은 사업 담당자에게 선택의 비용을 말하는 일입니다. 두 안을 비교해 고른 이유를 남긴 설계 문서를 면접에서 꺼내 설명하게 됩니다. 업무에 아키텍처 리뷰와 기술 토론이 있어 이런 설계 문서는 입사 뒤 리뷰에서 함께 보는 자료이기도 합니다.

• AI 기반 도구로 개발 생산성과 문제 해결 역량을 강화한 경험, AI 코딩 에이전트(Codex, Claude Code 등)를 실무에 활용하고 결과물의 품질을 스스로 검증하고 책임질 수 있는 역량이 필요합니다.

  이렇게 볼 수 있어요

  AI 도구 항목과 코딩 에이전트 항목이 따로 있어 하나는 생산성을 높인 경험, 다른 하나는 결과물을 스스로 검증하고 책임진 경험을 묻습니다. 지원 서류 안내가 AI로 푼 사례의 활용 방식과 결과, 검증 방법을 적어 달라고 한 것과 같은 구분입니다.

3우대 사항

• 주문·배송·클레임 시스템 등 커머스 도메인 백엔드 개발 경험, 또는 외부 시스템(물류·트래킹·결제 등) 연동 경험을 우대합니다.

  이렇게 볼 수 있어요

  커머스 도메인 백엔드 경험과 물류, 트래킹, 결제 같은 외부 시스템 연동 경험은 이 우대에 함께 적을 수 있습니다. 결제 연동 경험은 클레임에서 바로 쓰이는데 교환·환불의 마지막 단계가 결제수단별 취소와 환불 호출이기 때문입니다. 물류 연동은 업무의 WMS와 국내외 배송사 연동과 같은 종류의 경험입니다.

• 복잡하게 얽힌 레거시 시스템을 분석·개선하거나 마이그레이션한 경험, 도메인 주도 설계(DDD)에 대한 이해와 프로젝트 적용 경험을 우대합니다.

  이렇게 볼 수 있어요

  조직 소개가 파편화된 정책을 통합한다고 적었으므로 레거시 분석은 두 플랫폼 코드에 흩어진 주문, 배송, 클레임 정책을 찾아 하나의 데이터 모델에 어떻게 옮길지 정하는 일에 쓰입니다. DDD는 그 정책들을 클레임 도메인 안에 모아 다른 도메인과 독립적으로 바꿀 수 있게 하는 설계와 연결됩니다. 마이그레이션 사례는 옛 구조와 새 구조를 함께 돌리던 기간을 어떻게 닫았는지가 중심입니다.

• Kafka 등 메시지 큐를 활용한 비동기·이벤트 기반 시스템 설계·개발 경험, AWS(EKS, Aurora, S3 등) 기반 클라우드 환경에서 서비스 개발·운영 경험을 우대합니다.

  이렇게 볼 수 있어요

  스택의 Kafka가 이 우대의 도구입니다. 주문 이후 배송과 클레임 상태가 외부 시스템의 이벤트로 바뀌는 구조라 이벤트 순서와 중복 처리를 다룬 경험이 쓰입니다. AWS 우대에는 EKS, Aurora, S3 세 서비스 이름이 나옵니다.

• 팀 내 기술 문화, 리뷰 문화, 협업 문화를 개선하는 데 기여한 경험을 우대합니다.

  이렇게 볼 수 있어요

  원문은 기술 문화, 리뷰 문화, 협업 문화를 따로 적었습니다. 리뷰 문화는 업무의 코드 리뷰와 관련되고 협업 문화는 PE 소개가 '짧은 문제 정리나 프로토타입으로' PM·디자이너와 논의를 먼저 시작한다고 쓴 방식에서 나온 항목입니다. 문화를 바꾼 경험은 리뷰 소요 시간이나 논의 시작 시점처럼 달라진 값과 함께 적을 수 있습니다.

• AI 기반 기술을 실무 시스템에 적용한 경험, AI를 개발 프로세스에 도입해 팀 단위 생산성이나 품질을 개선한 경험, AI를 활용해 클라이언트 밖의 영역(서버 API, 데이터 파이프라인 등)까지 직접 문제를 풀어 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  세 항목은 AI 사용이 시스템 적용, 팀 단위 개선, 서버 쪽 문제 해결로 넓어지는 순서입니다. '클라이언트 밖의 영역'은 서버·웹·모바일이 하나의 직군인 PE 소개에서 나온 표현이어서 백엔드 자리에서는 서버 쪽 경험이 이미 전제입니다.

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

  이렇게 볼 수 있어요

  주문과 클레임 시스템이 직접 움직이는 값은 장바구니에서 주문 완료까지의 이탈, 결제 실패로 끝난 주문의 비율, 클레임 접수부터 환불 완료까지 걸린 시간입니다. KPI를 기술로 바꾼 경험을 가설, 실험, 데이터 검증의 순서로 쓰는 것이 우대가 요구하는 틀이고, 업무 항목도 출시 이후 지표 확인으로 같은 순서를 적었습니다.

4기타 사항

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

쓰는 기술

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

• Java
• Spring
• JPA
• QueryDSL
• MySQL
• Redis
• Kafka
• Kubernetes
• Docker
• Codex
• Claude Code

전형과 지원

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

지원 전 준비할 것

1. 1

   주문·결제 안정성 사례 한 건

   처리량, 피크 때 병목, 예외 상황 처리 방식을 한 사례로 적고 프로젝트별 기여도를 표기합니다. 공고의 작성 팁이 문제 정의, 해결, 성과를 담으라고 안내합니다.

2. 2

   통합과 마이그레이션 경험 정리

   정책이나 데이터 모델을 하나로 합친 프로젝트에서 이행 순서와 이중 운영 기간, 정합성을 확인한 방법을 순서대로 정리합니다.

3. 3

   AI 사례와 영역 밖 문제

   지원 서류 안내가 요청한 사례 두 가지를 한 건씩 고릅니다. AI로 문제를 푼 사례는 활용 방식, 결과, 검증 방법을 함께 정리합니다. 다른 하나는 전문 영역 밖으로 문제를 넓혀 푼 경험입니다.