[도메인 특강] 이커머스 PM

이커머스 PM 특강을 들으며 — “PM적 사고”

오늘은 이커머스 도메인 PM 특강을 들었다.

 

특히 검색, 결제, 장애 대응과 관련된 나의 경험들이

PM의 역할과 연결되었다는 점이 인상 깊었다.

이번 글에서는 특강을 들으며 정리한 내용과, 내가 왜 검색/핀테크 PM에 흥미를 느끼게 되었는지 기록해보려고 한다.

---

커머스 PM은 어떤 영역으로 나뉠까?

강의에서는 커머스 PM을 크게 아래 4개의 영역으로 나누어 설명했다.

• 유저(User)
• 상품(Product)
• 거래(Transaction)
• 운영(Operation)

그리고 그 안에서 다시 세부 도메인으로 나뉜다.

 

예를 들면:

• 주문 / 클레임
• 홈 / 전시
• 회원 / 멤버십
• 검색
• 정산 / 결제

같은 영역들이다.

 

PM은 단순히 “기획자”가 아닌

서비스의 특정 흐름 전체를 책임지고,
사용자 경험과 비즈니스 목표 사이를 연결하는 역할에 가깝다.

---

왜 검색 PM에 관심이 갔을까

내가 가장 흥미를 느꼈던 영역은 검색(Search) PM이었다.

 

이유는 명확했다.

나는 이전에 ElasticSearch 기반 검색 개발을 직접 진행한 경험이 있다.

• 검색 정책 설정
• 검색어 처리
• 튜닝
• 검색 품질 개선

등을 직접 고민하고 구현했었다.

 

당시에는 개발 관점으로 접근했지만,
지금 돌아보면 사실상 이런 고민들을 계속 했던 셈이다.

• 어떤 검색 결과를 상단에 노출해야 사용자가 만족할까?
• 오타 허용 범위는 어디까지가 적절할까?
• 검색 정확도와 검색 속도 중 무엇을 우선해야 할까?

---

핀테크/결제 PM에도 흥미를 느낀 이유

결제/정산 영역 역시 굉장히 흥미로웠다.

나는 이전에 핀테크 관련 개발 경험이 있었다.

예를 들면:

• 온라인 비대면 카드 발급
• 카드사 전문 통신
• 거래 내역 연동
• 장바구니 및 결제 개발

등의 경험이다.

 

특히 카드사와의 통신은 단순 CRUD 개발과는 완전히 다른 영역이었다.

• 실패 케이스
• 예외 상황
• 응답 지연
• 거래 정합성

같은 요소들을 굉장히 민감하게 다뤄야 했다.

 

• “사용자는 어디서 이탈할까?”
• “결제 실패 경험을 어떻게 줄일 수 있을까?”
• “어떤 흐름이 사용자 신뢰를 높일까?”

같은 고민들을 하게 되었던 기억이 난다.

 

---

PM은 결국 KPI와 연결된 사람

강의에서 반복적으로 나왔던 키워드는 KPI였다.

PM은 단순히 기능을 만드는 사람이 아니라

“회사의 목표와 사용자의 행동을 연결하는 사람”

에 가까웠다.

 

예를 들면

• 구매 전환율 증가
• 재방문율 증가
• 체류시간 증가

같은 전사 KPI가 있으면,
PM은 거기서 액션 아이템을 도출한다.

• 홈 개편
• 검색 개선
• 결제 UX 개선
• 멤버십 강화

같은 방식으로 말이다.

 

그리고 그 과정은 대부분:

유저 데이터 분석
→ 문제 발견
→ 가설 수립
→ 테스트
→ 결과 측정

흐름으로 이어진다.

 

 

---

PM은 UI/UX를 얼마나 알아야 할까?

개인적으로 가장 궁금했던 부분 중 하나다.

“PM은 UI/UX를 얼마나 알아야 하지?”

PM은 디자이너처럼 디자인을 잘할 필요는 없지만,
UX에 대한 감각은 반드시 필요하다.

 

 

특히 인상 깊었던 건
레퍼런스를 정말 많이 봐야 한다는 이야기였다.

단순히 “예쁜 디자인”이 아니라,

• 왜 이 버튼은 여기에 있는지
• 왜 이 서비스는 이런 흐름을 선택했는지
• 어떤 UX가 전환율을 높이는지

를 분석하는 시각이 중요하다는 점이었다.

 

• 다양한 서비스 분석
• UX 패턴 정리
• 레퍼런스 아카이빙

위와 같은 습관을 가져야겠다는 생각이 들었다.

---

내가 경험했던 장애 대응 플로우를 돌아보며

강의를 들으면서 가장 크게 공감했던 건 장애 대응 이야기였다.

돌아보면 나는 장애 상황에서 항상 비슷한 흐름으로 움직였었다.

1. 우선 현황 파악

• 지금 바로 해결 가능한가?
• 해결까지 얼마나 걸리는가?
• 우회 가능한 방법은 있는가?

를 먼저 판단했다.

---

2. 빠른 의사결정 및 공유

그 다음은 오케스트레이팅이었다.

• 장애 발생 시각
• 영향 범위
• 예상 조치 시간
• 대응 방안
• 타 부서 협조 요청

등을 빠르게 정리하고 공유했다.

특히 느꼈던 건:

장애 상황에서는 “기술력”만큼
커뮤니케이션과 판단 속도가 중요하다는 점이었다.

---

3. 장애 해소 후 회고

장애가 끝난 뒤에는:

• 원인 분석
• 재발 방지 논의
• 우선순위 정리

를 진행했다.

하지만 개인적으로 항상 가장 중요하다고 생각했던 건 이것이었다.

“일단 사용자가 장애를 최대한 덜 겪게 만드는 것”

 

 

근본 원인 해결도 중요하지만,
장애 상황에서는 우선 사용자 경험 보호가 먼저라고 느꼈던 기억이 난다.

---

특강을 들으며 가장 크게 느낀 점

내가 개발자 겸 스쿼드 리더로 일할 당시

“내가 애매하게 이것저것 하는 건 아닐까?”

이렇게 하는게 맞는지 틀린지 확신이 없었고 정답을 알려주는 사람이 없었다.

다른 PM들은 어떻게 할까, 레퍼런스를 찾아봐도 겉핥기 식의 글 뿐이었다.

하지만 이 강의를 듣고 어느 정도의 확신이 생기고 안도감이 생겼다.

 

 

그리고 동시에,
내가 부족하다고 느꼈던 부분들도 다시 확인할 수 있었다.

특히

• 사람과의 커뮤니케이션
• 멘탈 관리
• 의견 조율 능력

같은 부분들.

결국 PM은 단순히 기능을 관리하는 직무가 아니라,
사람과 문제 사이에서 끊임없이 균형을 잡는 역할이라는 생각이 들었다.

 

아직 부족한 점은 많지만,
적어도 내가 어떤 방향에 흥미를 느끼고,
어떤 강점을 가지고 있는지는 조금 더 명확해진 시간이었다.