[무신사] Technical Program Manager (Infra) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 클라우드 인프라, 컨테이너 플랫폼(Kubernetes), 네트워크, 데이터 스토어, 옵저버빌리티, CI/CD 등 인프라 영역의 기술 프로그램을 기획하고 성공 기준·범위·리소스·일정을 정의합니다.

  이렇게 볼 수 있어요

  이 포지션은 직접 구축하는 엔지니어가 아니라 프로그램의 성공 기준과 범위를 정하는 역할입니다. 같은 회사의 Cloud Engineer (Foundation Platform) 공고는 AWS와 EKS를 직접 운영하는 일을 맡고, 이 공고는 그런 작업이 여러 조직에서 같은 기준으로 진행되도록 계획을 세웁니다.

• 공통 솔루션과 인프라 기술 표준을 수립하고, 조직별 채택 현황과 예외 사항을 관리해 전사적으로 확산하고 정착시킵니다.

  이렇게 볼 수 있어요

  표준을 만드는 데서 끝나지 않고 조직별 채택 현황과 예외까지 관리합니다. 표준을 받아들이지 않던 팀을 어떻게 설득했고 예외를 어떤 기준으로 허용했는지가 면접 이야깃거리가 됩니다.

• 서비스 마이그레이션, 레거시 인프라 정리(Deprecation), 비용 최적화, 표준 도구 도입 등 여러 조직이 연계된 인프라 이니셔티브를 리드합니다.

  이렇게 볼 수 있어요

  이 업무는 조직 소개가 문제로 든 중복 투자와 운영 비용 증가를 직접 다룹니다. 마이그레이션이나 정리 작업을 이끈 경험은 옮긴 서비스 수와 줄어든 비용을 숫자로 써야 규모가 분명합니다.

• 트래픽 기반 자동화 검증 체계(Harness Engineering) 등 인프라 선결 과제와 크로스 팀 의존성이 높은 프로그램의 의사결정 구조를 수립하고 리스크를 관리합니다. 프로그램의 일정, 자원, 의존 관계를 관리하며 잠재적인 병목과 리스크를 선제적으로 식별해 해소합니다.

  이렇게 볼 수 있어요

  여러 팀의 일정이 서로 묶인 프로그램이 대상입니다. 누가 무엇을 결정하는지부터 정하고 병목을 미리 찾아 푼 경험이 있다면 그 프로그램의 의존 관계를 그림으로 설명할 수 있게 준비합니다.

• 아키텍처 리뷰, 모의 장애 훈련 등 운영 우수성(Operational Excellence) 프로그램을 SRE 및 아키텍트 조직과 함께 운영합니다.

  이렇게 볼 수 있어요

  우대 사항의 인시던트 관리와 모의 장애 경험이 이 업무에 그대로 쓰입니다. 훈련을 기획해 봤다면 시나리오와 훈련 뒤 바뀐 점까지 말할 수 있어야 합니다.

• 단기 실행 계획과 장기 인프라 로드맵의 정렬을 유지하고, Weekly Flash 등 정기적인 진척 상황, 리스크, 주요 의사결정 공유로 프로그램의 가시성을 확보합니다.

  이렇게 볼 수 있어요

  진척을 공유하는 형식이 Weekly Flash라는 이름으로 적혀 있습니다. 정기 보고를 직접 운영했다면 무엇을 담았고 그 보고를 보고 누가 어떤 결정을 내렸는지 설명합니다.

• 엔지니어링 생산성과 운영 효율성을 높이기 위한 도구와 프로세스 개선을 주도합니다.

  이렇게 볼 수 있어요

  프로그램 관리 외에 개발 조직이 쓰는 도구와 절차를 고치는 일도 맡습니다. 도입한 도구가 배포 시간이나 운영 부담을 얼마나 줄였는지 숫자가 있어야 이 업무를 설명하는 말에 무게가 실립니다.

2자격 요건

• 컴퓨터공학, 소프트웨어공학 등 관련 전공 학사 학위 이상을 보유했거나 이에 상응하는 경력이 있어야 합니다.

  이렇게 볼 수 있어요

  같은 회사 인프라 공고인 Cloud Engineer (Foundation Platform), DBA (Foundation Platform), FinOps Engineer의 자격 요건에는 학위 조건이 없고 이 공고에만 관련 전공 학사 또는 상응 경력이 있습니다. 직접 구축하기보다 여러 엔지니어링 조직의 기술 결정을 조율하는 자리라 그 바탕이 되는 기술 이해를 학위나 경력으로 확인하려는 것으로 보입니다. 전공이 다르다면 기술 직무에서 일한 기간과 맡은 시스템을 구체적으로 적습니다.

• 소프트웨어 엔지니어, 인프라/SRE 엔지니어, 시스템 아키텍트 등 기술 직무 경험을 포함해 총 7년 이상의 경력과 5년 이상의 기술 프로그램 또는 프로젝트 관리 경험을 요구합니다.

  이렇게 볼 수 있어요

  개발과 인프라 운영을 합친 7년은 같은 회사 Cloud Engineer (Foundation Platform) 공고에도 있는 조건입니다. 이 자리에는 거기에 기술 프로그램 또는 프로젝트 관리 5년이 따로 붙었습니다. 엔지니어로 일하며 마이그레이션이나 표준 도입 프로젝트를 이끈 기간은 기술 직무 경험이면서 프로젝트 관리 경험이기도 합니다. 그 기간은 두 조건에 함께 적을 수 있습니다. 경력마다 엔지니어로 일했는지, 관리 업무를 맡았는지, 둘 다였는지 역할을 밝히면 두 조건과 각각 맞춰 볼 수 있습니다.

• 클라우드 인프라(AWS 등), Kubernetes, 네트워크, 데이터 스토어, 옵저버빌리티, CI/CD 등 인프라·플랫폼 엔지니어링에 대한 실무 이해도가 필요합니다.

  이렇게 볼 수 있어요

  업무에 나온 인프라 영역이 자격 요건에 그대로 반복됩니다. 영역마다 직접 다뤄 본 것과 프로그램으로만 관리한 것을 구분해 두면 면접 질문에 정확히 답할 수 있습니다.

• 기술 표준 또는 공통 솔루션을 수립하고 여러 조직에 확산·정착시킨 경험을 요구합니다.

  이렇게 볼 수 있어요

  조직 소개는 조직별로 인프라 구성과 솔루션 선택이 분산되면서 표준의 부재와 중복 투자가 쌓였다고 밝혔습니다. 채용 사이트에 따르면 분석 시점 제품·디자인·데이터·엔지니어링 인력은 약 600명이었습니다. 이 규모에서 정착은 표준 문서를 내는 데서 끝나지 않고 각 조직이 실제로 옮겨 오고 옛 방식이 정리되는 것까지를 뜻합니다. 표준을 만든 경험에 더해 채택한 조직 수와 정착까지 걸린 기간, 옛 방식을 걷어 낸 방법을 함께 써야 이 조건에 대한 답이 됩니다.

• 서비스 마이그레이션, 대규모 인프라 전환 등 여러 팀이 연계된 기술 프로그램을 리드한 경험이 필요합니다.

  이렇게 볼 수 있어요

  업무에는 서비스 마이그레이션과 레거시 정리(Deprecation)처럼 여러 조직이 연계된 이니셔티브를 리드하는 일이 있습니다. 이런 전환을 리드한다는 것은 서비스 팀마다 다른 전환 일정과 롤백 기준을 정하고 옛 인프라를 끄는 시점까지 책임지는 일입니다. 맡았던 프로그램마다 참여 팀 수, 기간, 전환 규모를 한 줄로 요약하고 그 가운데 직접 정한 결정을 덧붙이면 참여와 리드의 차이가 보입니다.

• 시스템의 확장성, 안정성, 비용 효율성을 종합적으로 고려해 기술적 트레이드오프를 판단할 수 있는 분석력을 요구합니다.

  이렇게 볼 수 있어요

  세 가지가 부딪친 결정을 내려 본 경험을 묻습니다. 비용을 줄이면서 안정성을 어디까지 지켰는지 같은 구체적 결정이 하나 있으면 면접에서 이 요건에 답하기 쉽습니다.

• 복수의 프로그램을 동시에 관리하고 잠재적인 리스크를 선제적으로 식별·관리할 수 있는 Program Management 역량을 봅니다.

  이렇게 볼 수 있어요

  업무는 크로스 팀 의존성이 높은 프로그램의 일정·자원·의존 관계를 관리하고 Weekly Flash로 진척과 리스크를 공유하는 일입니다. 여러 프로그램을 함께 맡았던 경험이 있다면 팀 사이의 의존 관계에서 병목을 미리 찾아낸 사례가 이 역량을 업무의 말로 설명해 줍니다.

• 기술 및 비기술 이해관계자와 명확하게 소통하고 다양한 의견을 조율해 합의를 이끌어 낼 수 있어야 하며, 빠르게 변화하는 환경에서도 명확한 방향을 설정하고 실행해 결과를 만들어 낼 수 있어야 합니다.

  이렇게 볼 수 있어요

  같은 회사 FinOps Engineer 공고는 기술 조직·재무 조직과의 소통을 자격 요건으로 둡니다. 이 자리가 리드하는 비용 최적화 이니셔티브도 재무 쪽과 숫자를 맞춰야 할 수 있습니다. 업무의 Weekly Flash처럼 진척과 리스크, 주요 의사결정을 정기적으로 공유하는 방식이 합의와 방향 재설정을 함께 다루는 수단입니다. 기술을 모르는 이해관계자에게 인프라 결정을 설명해 합의를 끌어낸 사례와, 계획이 바뀐 상황에서 방향을 다시 정해 끝낸 사례를 하나씩 준비합니다.

3우대 사항

• SRE, 인프라, 플랫폼 엔지니어링 조직에서의 실무 경험이 있거나 개발자 출신이면 우대합니다.

  이렇게 볼 수 있어요

  업무에는 SRE·아키텍트 조직과 함께 아키텍처 리뷰와 모의 장애 훈련을 운영하는 일이 있습니다. 리뷰 자리에서 설계의 위험을 직접 묻고 판단하려면 엔지니어로 일해 본 경험이 필요합니다. 직접 운영해 본 시스템이 있다면 프로그램 관리 경력과 나눠 적어 엔지니어로 일한 기간과 다룬 시스템이 따로 보이게 할 수 있습니다.

• IaC(Terraform 등), GitOps, 배포 전략(Canary/Blue-Green) 등 현대적인 인프라 운영 방식에 대한 이해도가 높으면 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 Cloud Engineer 공고도 Terraform 기반 IaC와 GitOps 도입 경험을 적었습니다. 배포 전략을 바꾼 프로그램을 이끌었다면 적용 순서를 어떻게 정했는지 설명할 수 있어야 합니다.

• FinOps 관점에서 클라우드 비용을 최적화한 경험을 우대합니다.

  이렇게 볼 수 있어요

  FinOps Engineer 공고가 무신사에 따로 있고, 그 자리는 전사 클라우드 비용 최적화를 'Tech 기반 TPM 역할'로 전담합니다. 이 공고는 비용 최적화를 마이그레이션·레거시 정리와 함께 이끄는 이니셔티브 가운데 하나로 둡니다. 레거시 인프라를 끄면 비용이 함께 줄어드는 경우가 많습니다. 그래서 두 일을 한 프로그램으로 묶어 본 경험이 이 우대와 업무를 함께 설명합니다. 줄인 비용은 금액이나 비율로 밝힙니다.

• 인시던트 관리, 모의 장애, 장애 예방 체계 등을 구축하거나 운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  인시던트 관리와 모의 장애는 이 포지션이 SRE·아키텍트 조직과 함께 운영하는 운영 우수성 프로그램에 들어 있습니다. 운영해 본 체계의 이름과 주기, 그 뒤 줄어든 장애 수가 있으면 설득력이 생깁니다.

• 대규모 이커머스 또는 높은 트래픽을 처리하는 서비스 환경에서 근무한 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 Cloud Engineer (Foundation Platform) 공고는 대형 이벤트와 시즌성 트래픽 급증에 대비한 사전 프로비저닝 자동화를 업무로 적었습니다. 이런 환경에서는 마이그레이션이나 표준 전환 시점을 무진장 같은 대형 행사 일정을 피해 잡는 경우가 많습니다. 트래픽 큰 서비스에서 전환을 이끌어 본 경험이 그대로 쓰입니다. 이 우대는 업종과 트래픽 규모 가운데 하나를 봅니다. 커머스가 아니어도 트래픽이 큰 서비스였다면 그 규모를 숫자로 적어 비교할 수 있게 합니다.

• PMP, Scrum Master 등 관련 자격증 보유를 우대합니다.

  이렇게 볼 수 있어요

  PMP는 범위·일정·리스크를 계획 중심으로 관리하는 방식과 애자일·하이브리드 방식을 함께 다룹니다. Scrum Master는 짧은 주기로 팀의 작업을 조율하는 스크럼 방식의 자격입니다. 업무에 장기 인프라 로드맵과 단기 실행 계획을 함께 맞추는 일이 있어 계획 중심 관리와 짧은 주기의 조율이 모두 쓰일 수 있습니다. 보유했다면 취득 연도와 함께 자격 항목에 적고, 실제 프로그램에서 그 방식을 어떻게 썼는지 한 줄 덧붙일 수 있습니다.

4기타 사항

• 게시일 : 2026년 9월 10일
• 고용형태 : 정규직(수습 3개월)
• 근무지 : 무신사 성수 오피스
• 경력 조건 : 경력 7년 이상
• 학력 조건 : 컴퓨터공학, 소프트웨어공학 등 관련 전공 학사 학위 이상 또는 이에 상응하는 경력

쓰는 기술

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

• AWS
• Kubernetes
• CI/CD
• Terraform
• GitOps

전형과 지원

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

지원 전 준비할 것

1. 1

   기술 경력과 관리 경험 정리하기

   자격 요건이 총 경력 7년과 기술 프로그램 또는 프로젝트 관리 5년을 따로 요구합니다. 경력마다 맡은 역할을 밝혀 두세요. 엔지니어로 일하며 프로젝트를 이끈 경험이 있다면 그 범위와 기간도 구체적으로 적어 둡니다.

2. 2

   표준 확산 사례를 채택 숫자로

   기술 표준이나 공통 솔루션을 만들어 퍼뜨린 사례 하나를 골라 대상 팀 수, 채택까지 걸린 기간, 예외로 남긴 팀과 그 이유를 표 하나로 만듭니다.

3. 3

   작성 팁대로 문제 정의부터

   공고의 이력서 작성 팁은 왜 그 문제를 해결해야 했는지, 어떤 전략을 세웠는지, 어떤 성과가 있었는지와 프로젝트별 기여도 표시를 요청합니다. 1차 면접에서 깊이 있는 대화를 나눌 수 있도록 본인이 잘 아는 프로그램 위주로 구성합니다.