[데이터 기반 상품기획·PM 부트캠프]MD와 플랫폼 PM의 역할,그리고 애자일 업무

1. 온라인 MD와 플랫폼 PM의 차이

온라인 MD와 플랫폼 PM은 모두 고객에게 가치를 제공하고 비즈니스 성과를 만드는 역할이다. 다만 주로 다루는 대상과 성과를 만드는 접근 방식에 차이가 있다.

 

① 온라인 MD

상품과 판매 조건을 기획하고 운영하며 판매 성과를 관리한다.

• 고객과 시장에 맞는 상품·브랜드 발굴
• 가격과 판매 조건 협의
• 프로모션 및 상품 구성 기획
• 매출·이익·재고 관리

② 플랫폼 PM

사용자와 운영자의 문제를 파악하고, 서비스의 기능과 정책을 개선한다.

• 사용자 문제와 서비스 개선 기회 발견
• 프로덕트 목표와 우선순위 설정
• 기능·정책·이용 흐름 기획
• 개발자·디자이너 등과 협업하고 성과 확인

구분	온라인 MD	플랫폼 PM
주요 대상	상품과 판매 운영	서비스 기능과 이용 과정
핵심 판단	어떤 상품을 어떤 조건으로 판매할 것인가	어떤 문제를 어떤 방식으로 해결할 것인가
성과 지표 예시	매출, 이익률, 재고 소진율	구매 전환율, 기능 이용률, 운영 효율

 

학습 내용 확장

두 직무의 역할은 완전히 분리되기보다 실제 업무에서 연결된다.

예를 들어 구매 전환율이 낮다면 MD는 상품의 가격과 구성, 설명을 살펴보고, PM은 옵션 선택이나 결제 과정의 불편을 확인할 수 있다. 같은 지표를 보더라도 검토하는 영역이 다르므로 함께 원인을 찾아야 한다.

직무를 이해할 때는 명칭만 보는 것보다 담당 업무, 의사결정 범위, 성과 기준을 함께 확인해야 한다.

2. 채용공고로 확인한 직무와 역량

파이브스페이스 AMD와 무신사 트렌드 상품·IP기획 PM 보조 공고를 비교하며, 실제 업무를 여섯 가지 역량과 연결해봤다.

파이브스페이스(아더에러) AMD 공고

신사 트렌드 상품·IP기획 PM 보조 공고

역량	업무에서 확인할 관점
문제 해결	어떤 문제를 발견하고 해결해야 하는가
커뮤니케이션	누구와 어떤 정보를 주고받아야 하는가
비즈니스	업무가 매출·수익·사업 목표에 어떻게 기여하는가
UX	고객이나 운영자의 불편을 어떻게 줄이는가
기술	어떤 시스템과 도구를 이해해야 하는가
데이터	어떤 자료와 지표로 판단하는가

 

역량을 분류할 때는 하나의 업무를 하나의 역량에만 대응시키기 어렵다. 예를 들어 데이터 관리 업무도 정확한 수치를 다루는 능력뿐 아니라, 오류를 발견하는 문제 해결 능력과 담당자 간 소통이 함께 필요하다.

 

내 경험과 연결

개발자로 일했던 경험은 기술 역량을 이해하는 기반이 된다. 기능을 구현하는 입장을 경험했기 때문에, 앞으로 기획 내용을 전달할 때도 요구사항과 구현 과정의 관계를 생각해볼 수 있다.

고객을 직접 응대했던 CS 경험은 고객의 표현을 듣고 불편을 파악하는 데 연결할 수 있다. 다만 개별 문의를 전체 고객의 문제로 일반화하기보다, 반복 여부와 데이터를 함께 확인하는 관점이 필요하다.

앞으로는 기존 경험을 단순히 경력으로 나열하기보다 어떤 상황에서 어떤 역량을 발휘했는지 구체적으로 정리해볼 필요가 있다.

3. 워터폴과 애자일

프로젝트 방법론은 목표와 자원, 일정 안에서 업무를 체계적으로 진행하기 위한 방식이다.

① 워터폴(Waterfall)

요구사항 정의, 설계, 개발, 테스트 등의 단계를 순서대로 진행하는 방식이다.

• 초기 요구사항과 계획을 구체적으로 수립
• 단계별 산출물과 진행 상황 관리
• 요구사항이 명확하고 변경이 적은 프로젝트에 적합
• 후반에 변경이 발생하면 앞선 작업의 수정 비용이 커질 수 있음

② 애자일(Agile)

짧은 주기로 결과물을 만들고, 피드백과 학습을 바탕으로 개선하는 접근 방식이다.

• 반복적이고 점진적인 개발
• 고객 및 팀원과의 지속적인 협력
• 변화에 따른 계획과 우선순위 조정
• 불확실성이 높고 피드백이 중요한 프로젝트에 적합

내 경험과 연결

개발자로 근무할 당시에는 워터폴 방식으로 업무를 진행했다. 이번 수업에서는 과거에 경험한 방식과 애자일을 비교하며, 프로젝트를 진행하는 방법이 하나만 있는 것은 아니라는 점을 정리할 수 있었다.

워터폴은 사전에 정의한 요구사항과 계획을 중심으로 진행하고, 애자일은 진행 중 얻은 피드백을 다음 작업에 반영하는 데 무게를 둔다.

어느 한쪽이 항상 우수한 것은 아니다. 요구사항의 명확성, 변경 가능성, 고객 피드백의 필요성에 따라 적합한 방식을 판단해야 한다.

4. MVP와 최소 실행 범위

MVP(Minimum Viable Product)는 고객에게 핵심 가치를 제공하고, 중요한 가설을 검증하기 위한 최소 기능 제품이다.

처음부터 모든 기능을 개발하기보다, 핵심 기능을 먼저 제공해 고객의 반응을 확인하고 이후 개발 방향을 결정한다.

 

① MVP의 목적

• 고객에게 실제로 필요한 제품인지 확인
• 핵심 기능이 고객의 문제를 해결하는지 검증
• 불필요한 개발에 드는 시간과 비용 감소
• 고객 반응을 바탕으로 개선 방향 설정

② MVP 적용 예시

맞춤 코디 추천 서비스를 만든다고 가정해보자.

완성된 서비스에는 옷 등록, AI 코디 추천, 날씨 연동, 코디 저장 등 다양한 기능이 포함될 수 있다. 하지만 먼저 확인할 것은 고객이 맞춤 코디 추천을 유용하게 느끼는가이다.

이를 확인하기 위해 고객이 옷 사진과 원하는 스타일을 보내면, 사람이 직접 코디를 추천해주는 간단한 서비스부터 시작할 수 있다.

구분	내용
검증할 가설	고객은 자신의 옷과 취향을 반영한 코디 추천을 유용하게 느낄 것이다
핵심 기능	고객 정보를 받아 맞춤 코디 제공
우선 제외할 기능	AI 자동화, 날씨 연동, 코디 저장
확인할 반응	추천 코디의 실제 활용 여부, 재이용 여부, 지불 의향

 

자동화 기능이 없더라도 고객은 맞춤 코디를 추천받는 핵심 가치를 경험할 수 있다. 반응을 확인한 뒤 자동화나 추가 기능의 필요성을 판단한다.

 

내 경험과 연결

개발자로 일했던 경험에 비춰보면, 전체 요구사항 중 일부 기능을 먼저 개발하는 것과 MVP는 구분할 필요가 있다.

일부 기능을 먼저 구현했더라도 고객 반응을 확인하지 않았다면, 개발 일정을 나눈 것일 수 있다. MVP는 무엇을 검증하려는지 정하고, 고객이 사용한 결과를 다음 의사결정에 반영하는 것이 중요하다.

 

학습 내용 확장

MVP의 ‘최소’는 완성도를 낮추거나 대충 만든다는 의미가 아니다. 고객이 핵심 가치를 경험하는 데 필요한 기능은 제대로 제공해야 한다.

앞으로 기능이나 서비스를 기획할 때는 다음 내용을 먼저 정리해보고 싶다.

• 해결하려는 고객 문제는 무엇인가?
• 가장 먼저 검증해야 할 가설은 무엇인가?
• 가설을 확인하는 데 필요한 최소 기능은 무엇인가?
• 어떤 고객 반응과 지표로 결과를 판단할 것인가?

5. 스크럼과 칸반을 통한 업무 관리

스크럼과 칸반은 애자일하게 일할 때 활용할 수 있는 대표적인 프레임워크와 관리 방식이다.

 

① 스크럼(Scrum)

스프린트라는 일정한 주기를 중심으로 목표를 설정하고, 결과와 협업 과정을 점검한다.

구성 요소	주요 내용
프로덕트 백로그	필요한 작업을 우선순위에 따라 관리
스프린트 플래닝	이번 스프린트의 목표와 수행할 작업 계획
데일리 스크럼	목표 대비 진행 상황과 장애 요인 점검
스프린트 리뷰	결과물을 확인하고 피드백 수집
스프린트 회고	협업 과정과 업무 방식의 개선점 도출

 

② 칸반(Kanban)

작업 상태를 시각화하고, 진행 중인 작업의 양과 흐름을 관리하는 방식이다.

• ‘할 일 → 진행 중 → 완료’ 등의 상태로 업무 표시
• 특정 단계에 작업이 쌓이는 병목 확인
• 진행 중인 작업을 제한해 업무 집중도 관리
• 운영 업무처럼 지속적으로 들어오는 작업 관리에 활용 가능

학습 내용 확장

업무를 세분화해 목록으로 만드는 것만으로는 우선순위가 명확해지지 않는다. 각 작업이 어떤 목표에 기여하는지 알아야 먼저 해야 할 일을 판단할 수 있다.

또한 결과물이 잘 만들어졌는지 확인하는 리뷰와, 팀의 일하는 방식을 개선하는 회고를 구분해야 한다. 결과뿐 아니라 과정도 점검해야 다음 작업의 효율을 높일 수 있다.

6. Jira 사용 경험을 다시 이해하기

Jira는 작업과 이슈를 기록하고, 우선순위와 진행 상태를 관리하는 협업 도구다. 스크럼과 칸반을 지원하지만, 활용 범위가 애자일에만 한정되는 것은 아니다.

 

내 경험과 연결

개발자로 일할 당시 Jira를 사용했지만, 프로젝트는 워터폴 방식으로 진행했다.

이 경험을 오늘 수업과 연결하면서 협업 도구와 업무 방법론은 구분해야 한다는 점을 정리할 수 있었다.

구분	의미
Jira	업무와 이슈를 관리하고 공유하는 도구
워터폴·애자일	프로젝트를 계획하고 실행하는 접근 방식
스크럼·칸반	업무를 구체적으로 운영하는 프레임워크와 관리 방식

 

같은 Jira를 사용해도 계획을 수립하는 방식, 피드백을 반영하는 시점, 우선순위를 조정하는 과정은 팀마다 다를 수 있다.

기존에 사용했던 도구를 익숙하게 다루는 것에서 나아가, 팀이 어떤 목적과 규칙으로 활용하는지 이해하는 것이 필요하다.

7. 오늘 강의에서 기억할 핵심 인사이트

1. 직무는 이름보다 실제 업무를 기준으로 이해해야 한다.

MD와 PM은 주로 다루는 대상이 다르지만, 고객 문제 해결과 비즈니스 성과라는 목표에서 연결된다. 채용공고에서도 담당 업무와 필요한 역량을 함께 살펴봐야 한다.

2. 해결책을 정하기 전에 문제와 검증 방법을 명확히 해야 한다.

기능을 만드는 것이 곧 문제 해결은 아니다. 고객이 겪는 불편의 원인을 확인하고, 필요한 범위부터 실행한 뒤 효과를 검토해야 한다.

3. 도구를 사용하는 것과 업무 방식을 이해하는 것은 다르다.

과거의 Jira 사용 경험을 통해 도구와 방법론의 차이를 연결할 수 있었다. 앞으로는 기능뿐 아니라 목표 공유와 우선순위 관리 방식도 함께 살펴보고 싶다.

4. 기존 경험을 새로운 직무의 관점에서 해석할 수 있다.

개발 경험은 기술과 구현 과정의 이해로, CS 경험은 고객의 불편을 듣고 파악하는 경험으로 연결할 수 있다. 여기에 비즈니스와 데이터 관점을 더해 판단의 근거를 넓혀가야 한다.