이 자리가 왜 생겼을까요
공고의 회사 소개는 무신사페이먼츠가 무신사, 29CM, 솔드아웃 등에서 연간 약 5조 원 규모의 결제를 처리한다고 소개합니다. 팀 소개에 따르면 무신사는 2021년 간편 결제 수단 '무신사 페이'를 출시했고 무신사와 29CM 및 계열사의 결제 서비스 고도화를 위해 무신사페이먼츠를 설립했습니다. 이 공고는 그 법인의 결제서비스팀에서 결제와 취소, 환불 아키텍처 고도화, 승인·취소·매입·대사 운영, 카드사·PG사·간편결제 사업자 연동을 맡고 팀의 기술 방향까지 정하는 조직장을 요구합니다. 결제 정합성이 중요한 시스템의 기술 방향을 정해 본 경험이 있다면 선택한 구조와 포기한 대안을 사례로 서류에 쓸 수 있습니다.
무신사가 지금 어떤 사업에 집중하고 있는지는 무신사 채용 분석에서 이어서 볼 수 있습니다.
1하게 될 업무
Java/Kotlin 및 Spring 기반의 결제 도메인 백엔드 서비스를 설계·개발·운영합니다.
이렇게 볼 수 있어요
'설계·개발·운영'이 모두 적혀 있어 조직장도 코드를 놓지 않는 자리입니다. 팀 소개는 무신사와 29CM 및 계열사의 결제 서비스 고도화를 위해 무신사페이먼츠를 설립했다고 적었습니다.
결제, 취소, 환불 등 핵심 결제 프로세스의 아키텍처를 설계하고 고도화합니다.
이렇게 볼 수 있어요
취소와 환불이 결제 승인과 같은 수준의 아키텍처 설계 대상으로 적혀 있습니다. 같은 회사의 Purchase 공고가 주문 쪽 교환·환불 시스템을 맡으므로, 주문 쪽 클레임이 환불로 이어지는 흐름의 결제 쪽 끝단을 이 팀이 맡는 구조로 볼 수 있습니다.
결제 승인, 취소, 매입, 대사 등 트랜잭션 및 데이터 정합성이 중요한 프로세스를 안정적으로 운영합니다.
이렇게 볼 수 있어요
매입은 카드사에 승인 건의 청구를 요청하는 단계이고 대사는 내부 거래 내역과 카드사·PG의 정산 내역이 맞는지 맞춰 보는 단계입니다. 네 단계 모두 한 건이라도 틀리면 금액이 어긋나는 정합성 업무입니다.
MySQL 등 RDBMS 모델링과 쿼리 최적화를 수행하며, Redis와 Kafka/RabbitMQ 기반의 캐시 및 비동기 처리 구조를 설계합니다.
이렇게 볼 수 있어요
큐 도구로 Kafka와 RabbitMQ 두 계열 이름이 나옵니다. 결제처럼 중복 처리가 금액 오류가 되는 영역에서는 메시지를 두 번 받았을 때 어떻게 막았는지가 비동기 설계 경험의 핵심입니다.
카드사, PG사, 간편결제 사업자 등 외부 파트너와의 API 연동을 설계하고 결제 플랫폼 확장을 지원합니다.
이렇게 볼 수 있어요
연동 상대가 카드사, PG사, 간편결제 사업자 세 종류입니다. 외부 사업자의 장애나 지연이 내 결제 실패로 이어지는 구조라 타임아웃과 재시도 정책을 설계한 경험이 쓰입니다.
코드 및 설계 리뷰, 테스트 자동화, 리팩토링을 통해 기술 품질과 개발 생산성을 향상합니다.
이렇게 볼 수 있어요
업무가 승인, 취소, 매입, 대사를 정합성이 중요한 프로세스로 적은 만큼 테스트 자동화도 이 금액 경로에 먼저 쌓입니다. 결제 코드의 리팩토링은 금액 계산이 바뀌지 않았음을 테스트로 보인 뒤에 할 수 있어서, 어떤 테스트가 있었기에 구조를 바꿀 수 있었는지가 사례의 중심입니다. 우대의 코드 리뷰, 설계 리뷰, 리팩토링 문화 정착도 같은 항목을 팀 수준으로 넓힌 말입니다.
팀의 기술 방향을 수립하고 핵심 아키텍처 의사결정을 리드하며 유관 조직과의 기술 협업을 주도합니다.
이렇게 볼 수 있어요
Product Engineering Manager (Pricing) 공고는 업무에 팀원 채용, 성과 평가, 1:1 면담을 적었는데 이 공고 업무에는 이 세 가지가 없습니다. 조직 관련 항목은 '핵심 아키텍처 의사결정을 리드하며' 유관 조직과 기술 협업을 주도한다는 줄과 AI 기반 개발 방식을 조직에 만들어 간다는 줄이라, 사람 관리보다 기술 결정에 무게가 실린 조직장입니다. 직함이 매니저여도 아키텍처 결정을 이끈 사례와 유관 조직과 조율한 사례를 꺼내는 쪽이 업무와 맞습니다.
PM·디자이너 및 유관 조직과 함께 해결할 고객 문제와 우선순위를 정의하고, 모호한 요구는 측정 가능한 가설로 바꾸며, 출시 이후 지표로 성과를 확인해 다음 개선으로 연결합니다.
이렇게 볼 수 있어요
PE 소개의 협업 방식이 조직장 업무에도 같은 문장으로 들어 있습니다. 결제에서 고객 문제는 승인율, 결제 실패율, 이탈률 같은 값으로 확인됩니다.
AI 코딩 에이전트를 설계·구현·테스트·코드 리뷰·운영 전반에 활용하고, 그 경험을 팀과 나눠 개발 생산성과 품질을 높이는 AI 기반 개발 방식을 조직에 만들어 갑니다.
이렇게 볼 수 있어요
업무 문장은 AI 활용 경험을 팀과 나눠 AI 기반 개발 방식을 조직에 만들어 가라고 적어, 개인 사용을 넘어 팀이 쓰는 절차를 만드는 일까지 포함합니다. 결제 코드는 금액에 영향을 주므로 그 절차에는 AI가 쓴 코드를 통과시키는 테스트와 리뷰 기준이 필요합니다. Product Engineering Manager (Pricing) 공고 업무에도 활용 경험과 노하우를 팀에 공유하고 정착시키라는 같은 요구가 있습니다.
2자격 요건
12년 이상의 웹 서비스 또는 백엔드 개발 경험이 있어야 합니다.
이렇게 볼 수 있어요
'웹 서비스 또는 백엔드'라 풀스택이나 웹 서비스 경력도 12년에 함께 적을 수 있습니다. 같은 PEM 계열 Pricing 공고는 서비스 개발·운영 12년에 조직 관리 3년을 따로 적었습니다.
기술 리드 또는 엔지니어링 매니저 역할을 수행해 봐야 합니다.
이렇게 볼 수 있어요
기술 리드 경력과 엔지니어링 매니저 경력은 이 조건에 함께 적을 수 있습니다. Product Engineering Manager (Pricing) 공고는 같은 성격의 조건에 3년 이상이라는 기간을 붙였는데 이 공고는 기간 없이 역할 수행만 적었습니다. 업무가 팀의 기술 방향 수립과 핵심 아키텍처 결정을 이름으로 적은 만큼 그 결정을 이끈 사례를 꺼냅니다.
Java/Kotlin 및 Spring 기반 프로덕션 서비스를 설계·개발·운영해 봐야 합니다.
이렇게 볼 수 있어요
결제 도메인 백엔드라 프로덕션 운영 경험은 승인과 취소 요청이 실패하거나 지연됐을 때 중복 승인 없이 정상 상태로 돌린 장애 대응으로 보여 줍니다. Product Engineer (Purchase) 공고는 Java와 Spring만 적었고 이 공고는 Kotlin을 함께 적어, Kotlin 서비스를 운영한 경험도 이 조건에 함께 적을 수 있습니다.
트랜잭션 중심 시스템 또는 대규모 트래픽 서비스를 운영해 봐야 합니다.
이렇게 볼 수 있어요
트랜잭션 중심 시스템 경력과 대규모 트래픽 서비스 경력은 이 조건에 함께 적을 수 있습니다. 회사 소개는 무신사, 29CM, 솔드아웃 등에서 연간 약 5조 원 규모의 결제를 처리한다고 적었습니다. 업무도 승인, 취소, 매입, 대사를 정합성이 중요한 프로세스로 적어, 이 팀에서는 트랜잭션 경험이 더 직접 쓰입니다. 트랜잭션 경험은 승인과 취소가 서로 맞지 않는 건을 맞춘 방식으로, 트래픽 경험은 피크 처리량과 대응으로 적습니다.
REST API, RDBMS, 분산 시스템에 대한 실무 경험이 있어야 합니다.
이렇게 볼 수 있어요
세 항목 가운데 결제에서 설계 부담이 가장 큰 쪽은 분산 시스템입니다. 카드사나 PG에 보낸 승인 요청이 응답 지연으로 성공인지 실패인지 모르는 상태가 되면 상태 조회나 취소 요청으로 결과를 확정해야 하고, 같은 요청이 두 번 처리되지 않게 하는 설계가 필요합니다. 중복 요청을 막은 방식과 상태를 확정한 절차가 이 항목에 맞는 사례입니다.
구현에 머무르지 않고 고객 문제를 함께 정의하고 출시 이후의 지표로 결과를 확인하며 일해 와야 합니다.
이렇게 볼 수 있어요
결제의 고객 문제는 승인율, 결제 실패율, 이탈률처럼 지표로 확인되고, 업무의 '출시 이후 지표로 성과를 확인해' 항목이 같은 일을 말합니다.
기술적 의사결정을 트레이드오프와 함께 문서로 정리하고 비즈니스 맥락에서 설명할 수 있어야 합니다.
이렇게 볼 수 있어요
결제 설계의 결정은 재시도 정책이나 정합성 보장 수준처럼 대안이 분명해, 문서에 다른 선택지와의 비교를 남기기 쉽습니다.
AI 코딩 에이전트(Codex, Claude Code 등)를 실무에 적극 활용하고 그 결과물의 품질을 스스로 검증하고 책임질 수 있어야 합니다.
이렇게 볼 수 있어요
원문 괄호의 Codex, Claude Code는 '등'이 붙은 도구 예시이고 요건의 중심은 결과물의 품질을 스스로 검증하고 책임지는 쪽입니다. 지원 서류 안내가 AI로 푼 사례에 활용 방식과 결과, 검증 방법을 함께 적으라고 해서 세 가지를 한 사례로 묶는 틀이 이미 정해져 있습니다. 결제 서비스에서는 AI가 만든 변경을 어떤 테스트와 리뷰로 통과시켰는지가 검증 방법으로 쓰입니다.
3우대 사항
PG사, 핀테크 기업, 은행·카드사 등 금융/결제 도메인 조직에서 결제, 전자금융 서비스의 개발 또는 운영 경험을 우대합니다.
이렇게 볼 수 있어요
원문 열거가 PG사, 핀테크 기업, 은행, 카드사이고 경험은 '개발 또는 운영'입니다. 회사 소개에 따르면 연간 약 5조 원 규모의 결제를 처리하므로 비슷한 규모의 처리량을 다룬 경험은 숫자로 보여 줍니다.
Kafka/RabbitMQ 기반의 비동기·이벤트 아키텍처와 MSA·모듈화·고가용성 아키텍처를 설계·운영한 경험을 우대합니다.
이렇게 볼 수 있어요
이 우대의 비동기 아키텍처와 MSA·고가용성은 업무의 Redis·Kafka/RabbitMQ 구조 설계와 같은 영역입니다. 결제 시스템의 고가용성은 장애 시 결제가 중복되거나 유실되지 않게 한 방식으로 설명합니다.
AWS, Docker, Kubernetes 기반 서비스 운영 경험 또는 인프라 조직과의 협업 경험을 우대합니다.
이렇게 볼 수 있어요
AWS, Docker, Kubernetes 운영 경험과 인프라 조직과의 협업 경험은 이 우대에 함께 적을 수 있습니다. Product Engineer (Purchase) 공고는 우대에 AWS(EKS, Aurora, S3)를 서비스 이름까지 적었는데 이 공고는 서비스 이름 없이 세 기술만 적었고, 업무에도 인프라 운영 항목은 없습니다. 배포 파이프라인이나 용량 산정을 인프라 팀과 함께 정한 경험이 결제 서비스 운영에 가장 가까운 사례입니다.
장애 대응 체계 구축, 모니터링 고도화, 테스트 자동화, 배포 자동화 등 운영 성숙도를 향상시킨 경험, 코드 리뷰, 설계 리뷰, 리팩토링 문화 정착 등으로 팀의 엔지니어링 수준 향상에 기여한 경험을 우대합니다.
이렇게 볼 수 있어요
운영 성숙도는 장애 알림 체계, 장애 등급 기준, 장애 뒤 회고 문서처럼 팀이 장애를 다루는 절차의 수준을 말합니다. 결제 서비스는 장애가 곧 결제 실패로 나타나므로 이 절차를 만든 경험은 업무의 안정적 운영 항목과 이어집니다. 장애 대응 시간이나 배포 주기가 어떻게 달라졌는지 값을 적으면 체계를 만든 경험이 분명해집니다. 리뷰 문화는 업무의 코드·설계 리뷰 항목과 별개로 팀 수준에서 쌓은 기록으로 적습니다.
비즈니스 KPI를 기술로 개선하고 수치로 증명해 본 경험, 가설 수립, 실험, 데이터 검증을 거쳐 제품 의사결정에 참여해 본 경험을 우대합니다.
이렇게 볼 수 있어요
결제 승인율은 카드사의 거절, 우리 쪽 타임아웃, 입력 오류처럼 실패 원인이 다른 건이 섞여 있어서, 개선 경험은 어느 원인을 줄였는지 나눠 적어야 기술로 바꾼 부분이 드러납니다. 이 팀은 카드사, PG사, 간편결제 사업자와 연동하므로 연동 상대별 실패율 차이를 확인하고 재시도 정책이나 연동 순서를 바꿔 실패율이 달라진 경험이 이 우대에 맞습니다.
AI를 개발 프로세스에 도입해 팀 단위 생산성이나 품질을 개선한 경험, AI를 활용해 클라이언트 밖의 영역(서버 API, 데이터 파이프라인 등)까지 직접 문제를 풀어 본 경험을 우대합니다.
이렇게 볼 수 있어요
'클라이언트 밖의 영역'은 서버·웹·모바일 엔지니어가 한 직군으로 일하는 PE 소개에서 나온 표현이라 클라이언트 쪽 엔지니어에게 의미가 큰 문구입니다. 결제 백엔드 지원자에게 서버 API는 본업이므로 이 우대에서 남는 것은 AI 도입으로 팀 단위 생산성이나 품질이 바뀐 수치입니다. 업무가 AI 기반 개발 방식을 조직에 만들어 가는 일까지 적었으므로 조직장의 사례는 팀 단위 수치로 적는 쪽이 맞습니다.
4기타 사항
- 게시일 : 2026년 5월 12일
- 고용형태 : 정규직(수습 3개월)
- 근무지 : 무신사 성수 오피스
- 경력 조건 : 경력 12년 이상
- 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
쓰는 기술
공고 본문에 적힌 기술만 모은 목록입니다.
- Java
- Kotlin
- Spring
- MySQL
- Redis
- Kafka
- RabbitMQ
- AWS
- Docker
- Kubernetes
- Codex
- Claude Code
전형과 지원
무신사 정규직 공고는 기본적으로 인터뷰를 두 번 봅니다. 공고에 따라 3차 인터뷰나 커피챗처럼 단계가 하나씩 더 붙거나 1차 인터뷰를 두 번 보는 공고도 있으므로 지원할 공고의 전형 절차 항목을 따로 확인해야 합니다.
정규직은 인터뷰 두 번
분석 시점 정규직 117건을 전수로 보면 96건이 서류, 1차 인터뷰, 2차 인터뷰, 처우 협의, 최종합격으로 같습니다. 인터뷰가 한 번뿐인 전형은 계약직 7건에만 나타납니다. 지원 마감일이 없는 상시 지원이 대부분입니다.
공고마다 붙는 단계
분석 시점 개발과 머신러닝 직군 7건에는 Live Coding이나 System Design, 컬쳐핏, 기술과제가 붙습니다. 직군과 관계없이 6건에는 3차 커피챗이, 4건에는 과제 전형이 붙습니다. 그 뒤 분석한 신성장 마케팅 Lead (무신사 스탠다드)에도 3차 커피챗이 있고, 물류 Program Management Lead (무신사로지스틱스)는 서류 전형 다음에 커피챗이 있습니다. 통역 테스트나 중국어, 일본어 커뮤니케이션 역량 검증이 붙는 공고도 있습니다. Product Engineer (SCM Platform) 공고는 1차 인터뷰를 두 번 보고 처우 협의 단계를 적지 않았습니다.
이렇게 볼 수 있어요
분석 시점에 표준형이 아닌 공고는 117건 중 21건이었습니다. 일정을 잡기 전에 지원할 공고의 전형 절차 줄을 직접 읽어야 하고, 커피챗이 붙은 공고는 단계가 하나 더 있는 만큼 기간을 더 잡는 편이 좋습니다.
서류에 적으라고 안내한 것
공고 대부분이 지원 서류 안내에 같은 문장을 답니다. "왜 해당 문제를 해결해야 했는지, 어떤 전략을 세웠는지, 어떤 성과가 있었는지 등에 대한 문제 정의, 문제 해결, 성과에 대한 전반적인 내용을 담아주세요"와 "프로젝트별 기여도 표시"입니다.
이렇게 볼 수 있어요
회사가 서류의 구성을 사실상 지정한 셈입니다. 프로젝트마다 문제 정의와 해결, 성과가 다 있는지 세어 보면 그대로 자가 점검이 되고 기여도 표시는 빠뜨리기 쉬우니 따로 확인합니다.
근무 조건
선택적 근로 시간제를 운영하고 팀 협업을 위한 코어타임은 11시부터 16시까지입니다.
수습
FAQ는 신규 입사자(12개월 이상 계약직, 정규직)가 3개월 수습 기간 동안 수습 평가를 거치고, 수습 기간에도 100% 급여와 복지 혜택이 적용된다고 안내합니다.
이렇게 볼 수 있어요
수습 기간에 처우가 줄지는 않지만 입사 첫 3개월에 평가가 있습니다. 계약직이라도 계약 기간이 12개월 이상이면 같은 수습 규정이 적용됩니다.
이 공고만 다른 점
전형 절차에 서류 전형과 1차 인터뷰 사이 과제 전형이 있다고 적었습니다.
무신사 정규직 표준에는 없는 단계라 일정이 한 단계 늘어납니다. 과제의 주제와 형식은 적혀 있지 않고, 제출물이 1차 인터뷰 질문의 출발점이 될 수 있으므로 과제 안의 설계 결정을 문서로 설명할 수 있게 준비합니다.
지원 전 준비할 것
- 1
결제 정합성 사례 한 건
승인, 취소, 대사 가운데 정합성을 지킨 경험을 문제 정의, 선택한 방식, 결과 수치 순서로 적고 프로젝트별 기여도를 표기합니다.
- 2
기술 방향을 정한 결정 기록
팀의 기술 방향이나 아키텍처를 정한 결정 한두 건을 골라 대안과 트레이드오프를 문서로 정리합니다. 1차 인터뷰에서 끝까지 설명할 수 있는 내용만 고릅니다.
- 3
과제 전형 대비
서류 뒤에 과제 전형이 있어 설계와 구현을 모두 제출할 수 있도록 결제 승인과 취소 흐름 같은 상태 전이 문제를 직접 풀어 보는 연습을 해 봅니다. 과제 형식은 채용 문의 메일 recruit@musinsa.com 로 물어볼 수 있습니다.