지난 게시물에서 마켓컬리의 개발적인 측면을 살펴봤었다.
2주동안 공부를 하면서 PM으로서 개발 지식을 어느정도 파악하고 어느 관점에서 봐야하는지 감을 잡을 수 있었다. 글의 구조를 바꾸고 싶어서 그대로 가져오지 않고 수정해서 다시 작성했다.
마켓컬리 사례로 프로덕트의 개발적인 측면 살펴보기 [코드스테이츠 PMB 10기]
1. 프로덕트에서 유저가 할 수 있는 행동은 무엇이 있을까? 마켓컬리의 주요 액터인 고객은 마켓컬리에 회원가입을 하고, 상품을 탐색하고, 상품을 장바구니에 담고, 주문을 한다. 이 중 로그인,
my-adventure-book.tistory.com
개요
지난 게시물과 비교했을 때 어떤 점을 개선했을까?
| 지난 게시물 | 이번 게시물 | |
| 1 | 플로우차트 - 로그인, 장바구니, 주문 |
플로우차트 + 실제 화면 흐름 - 로그인, 장바구니, 주문 |
| - 플로우차트 상에 크게 수정한 부분은 없다. - 페어분의 과제를 보고 실제 화면 흐름을 추가했다. 실제 화면 흐름을 보면서 글을 읽었을 때가 훨씬 플로우차트를 이해하는 데 도움이 되는 것 같아 추가했다. |
||
| 2 | UI, 클라이언트, 서버, DB의 기술 스택 서술 - 이커머스 서비스 - 데이터 서비스 - 물류 서비스 |
UI, 클라이언트, 서버, DB의 구조에 대해 설명 - 파악이 가능한 이커머스 서비스의 구조에 대한 설명 - 1번에서 작성한 [ 로그인] 과정을 예시로 한 설명 |
| - 비즈니스적 관점이 아닌 기술 스택에 대해만 서술했었다. - 1번에서 정리한 유저의 행동의 개발 구조를 분석했다. |
||
| 3 | (없음) | 마켓 컬리의 기술스택 |
| 지난 게시물의 2번 부분을 3번으로 가져왔다. | ||
1. 프로덕트에서 유저가 할 수 있는 행동은 무엇이 있을까?
유저가 보는 실제 화면의 흐름을 보면서 플로우차트를 그려보기
[ 로그인 화면 흐름과 플로우 차트 ]
1. 유저는 상품을 구매하기위해 로그인을 한다.
2~3. ID와 PW를 입력한다.
4. 로그인을 시도한다. 이때, ID나 PW가 입력되지 않거나 일치하는 회원정보가 없을 때 경고 메시지가 뜬다. 로그인이 완료되면 마이컬리 화면으로 돌아간다.
[ 장바구니 화면 흐름과 플로우 차트 ]
1. 유저는 상품 상세 페이지에서 제품 구매하기 버튼을 누른다.
2. 유저는 상품의 옵션/수량을 선택한다.
3. 장바구니 담기 버튼을 눌러 장바구니에 상품을 담는다.
1~3을 추가로 구매할 상품이 있을 때까지 반복한다.
[ 주문하기 화면 흐름과 플로우 차트 ]
1. 유저는 장바구니에서 결제할 상품을 선택한다.
2. 금액을 확인하고 주문하기 버튼을 누른다.
3. 주문자, 배송지, 쿠폰/적립금 정보를 입력한다.
4. 결제 진행 필수 항목에 동의를 체크한다. 체크가 안된 경우, 경고 메시지가 뜬다.
5. 결제하기 버튼을 눌러 결제화면으로 넘어간다.
6. 주문 완료
2. 프로덕트의 UI, 클라이언트, 서버, DB는
각각 어떻게 보이고 작동할까?
[ 로그인하기를 예시로 UI, Client, Server, DB 구조 뜯어보기 ]
- UI: 유저가 보는 시각적인 화면 자체로 생각하면 쉽다. 문구, 버튼의 색, 아이콘의 위치 등 설계도를 토대로 디자이너, 퍼블리셔가 이 부분을 작업한다.
- Client: 프론트 단을 의미한다. 유저가 입력해야 할 데이터가 입력되지 않았을 때 유저에게 경고 메시지를 띄어주는 등 유저에게 보이는 개발적인 부분을 담당한다.
- Sever: 데이터가 처리되는 부분이다. 유저가 로그인을 한다고 하면, 유저가 입력한 정보를 전달하고 DB에서 정보를 받아 유저가 정상적으로 로그인 처리가 되도록 한다.
- DB: 데이터가 저장되는 저장소이다. 관계형 DB의 경우 각각의 테이블로 이뤄져있으며 각 테이블들은 여러 참조 관계로 이뤄져있다. 예를 들면, 회원의 장바구니는 유저 아이디, 상품의 정보가 포함된다. 이때 각각의 테이블을 새로 생성할 경우 데이터가 복잡해진다. 그래서 테이블을 새로 만들지 않고, 장바구니 테이블과 회원 정보 테이블, 상품 정보 테이블에서 필요한 정보만 뽑아서(참조해서) 사용한다. (외래키 생성)
3. 마켓컬리의 기술 스택을 알아보자
마켓컬리의 블로그와 개발자 채용 공고를 참고해 서버는 AWS를 쓰고 있음을 짐작할 수 있었다.
마켓컬리의 블로그에 따르면, 마켓컬리는 이커머스 서비스, 물류 서비스, 데이터 서비스로 나눠져있다.
이커머스 서비스
소비자(회원)이 보는 화면을 보여주는 파트이다. 회원정보, 상품, 주문, 결제 등을 관리하고 있다.
- UI: Web / Mobile App를 통해 회원에게 보여진다.
- Client: Kotlin(안드), Swift(IOS) 언어로 앱을 활용하고 있고, 웹은 Vue.js를 사용하고 있다.
- Sever: Legacy PHP, Java/Spring Boot의 하이브리드 형태로 구성되어 있다.
- DB: AWS 클라우드로 이관을 마쳤다고 한다. 회원정보 DB, 상품 DB, 주문 DB, 결제 DB 등이 AWS 클라우드 상에 존재할 것으로 예상된다.
물류 서비스
이커머스 서비스를 통해 사용자가 결제를 완료하면 AWS Auroa DB에 주문이 생성된다. 해당 주문은 물류 서비스를 통해 물류 센터에 전달된다. SCM (Supply Chain Management), WMS (Warehouse Management System), TMS (Transport Management System)로 구성되어 있다고 한다.
- UI: Web 대시보드를 통해 관리자(직원)이 조회할 수 잇을 것으로 예상된다.
- Client: React.js, Vue.js를 사용해 개발한다.
- Server: Java/Spring만 사용한다.
- DB: 물류서비스 역시 AWS를 사용하고 있다. 이커머스 시스템의 주문 정보를 참조해 물류 DB를 관리하고 있을 것으로 예상된다.
데이터 서비스
이커머스와 물류서비스에서 발생하는 다양한 형태의 정형/비정형 데이터를 모아 분석하는 시스템이다. 딥러딩 기술을 도입해 고객 후기 자동 분류, 신선 식품 데이터 예측 발주 시스템, 상품 추천 등 사용자에게 최적화된 경험을 제공하기 위한 시스템이다.
- UI: AWS에서 제공하는 대시보드를 통해 데이터를 추출해 가공할 것으로 생각된다. 주사용자는 내부 직원이 될 것이다.
- Client: 프론트 단은 Keras를 활용하고 있으니 파이썬을 사용할 것이다.
- Server: AWS 클라우드에서 Keras(딥러닝 라이브러리)를 활용하고 있을 것으로 생각된다.
- DB: AWS 클라우드에서 물류시스템 DB와 이커머스 시스템 DB에서 생성된 정보를 참조해 활용하고 있을 것으로 예상된다.
채용 공고는 최근 공고이지만 기술스택을 보면서 참고했던 블로그는 2019년도 게시물이라 현재는 3가지 서비스 외에도 현재는 더 많은 서비스를 개발했을 것으로 예상된다.
마켓컬리 서비스 구조를 소개 합니다
helloworld.kurly.com
(추가)
개발 모집 공고가 열렸는데, 조직 구조를 보았을 때 서비스가 다양화 된건 맞는 것 같다. 각 플랫폼이 어떤 개발 구조로 이뤄졌는 다루는 글은 없었다.
'IT 이야기 > 내가 PM이라면' 카테고리의 다른 글
| 내가 무신사 PM이라면 좋아요 폴더부터 개선 할래 (1) | 2022.03.17 |
|---|---|
| 스크럼 가이드 살펴보기 (0) | 2022.03.15 |
| API가 도대체 뭔데? - API 쉽게 이해하기 (0) | 2022.03.10 |
| 앱의 형태 쉽게 이해하기 - 모바일 웹, 웹 앱, 하이브리드 앱, 네이티브 앱 (0) | 2022.03.08 |
| 웹 사이트의 구조 뜯어보기 - 집 꾸미기 (0) | 2022.03.07 |