Ecommerce - 2

1. 개요.

1.1. 배경

• 온라인 쇼핑의 확산: 기업이 온라인 판매를 가능하게 하는 서비스.

• 커머스 기능의 다양성: 상품을 등록하고 판매하는 것 이외에도, 리뷰/결제 시스템/배송 추적/ 프로모션 등 당야한 부가 기능이 요구됨.

1.2. 프로젝트 목적

• 확장성과 유지보수성을 고려한 백엔드 시스템 설계 및 구현

• 주요 이커머스 기능(상품 관리, 결제, 배송, 회원/권한 관리 등)의 구조화.

• 실무 수준 이상의 설계 및 아키텍처 경험 축적

• 데이터 흐름(트랜잭션)의 이해 및 복잡도 높은 주문, 배송 관리 로직 구현 연습.

1.3. 프로젝트 기대 효과

• 전형적인 커머스 도메인에서 발생하는 데이터 모델링과 비즈니스 로직 설계 경험

• 도메인 주도 설계(DDD), MSA 등 다양한 아키텍처적 접근 가능.

• 실제 스타트업이나 기업에서 사용하는 결제 연동, 알림(이메일/문자), 외부 서비스 연동(택배사 API) 등의 기술적 연습.

• 테스트 자동화, CI/CD, 로그/모니터링 등 운영 단계의 프로세스 경험

2. 주요 기능

1. 회원/인증

   1. 회원가입, 로그인, 비밀번호 재설정 등

   2. OAuth, 소셜 로그인

2. 상품 관리

   1. 상품 등록/수정/삭제, 카테고리/태그 관리

   2. 재고 수량 관리 및 품절 처리 로직

3. 주문 및 결제

   1. 장바구니, 주문서 생성

   2. 결제 정보 처리

4. 배송 및 주문 추적

   1. 배송 상태 업데이트(운송장 번호, 배송사 연동)

   2. 고객에게 배송 정보 제공(알림, 트래킹 링크)

5. 리뷰 및 평점(Review & Rating)

   1. 구매자 리뷰 작성/조회

   2. 별점, 사진 첨부 등

6. 고객센터(문의/FAQ)

   1. 1:1 문의, FAQ, 공지사항

   2. 문의에 대한 관리자 답변

   3. 대화형 AI 도입

7. 프로모션 및 할인

   1. 할인 쿠폰, 이벤트 페이지

   2. 특정 조건(구매 금액, 회원 등급)에 따른 할인 적용

8. 관리자 기능

   1. 회원 관리, 통계 대시보드, 재고 관리

   2. 프로모션 등록, 운영 공지 등

3. 페르소나

3.1. 유저 - 김민수

개요:

• 모바일로 쇼핑을 자주 즐김

• 상품을 구매할때 가격 비교 및 할인 혜택을 꼼꼼히 살핌

니즈:

• 편리하고 빠른 결제: PC보다 모바일 중심으로 쇼핑을 하므로, 간편결제를 지원하고 배송지를 매번 입력하지 않아도 되길 원한다.

• 믿을 수 있는 정보: 상세한 상품 설명, 실착(사용) 후기, 별점 등이 잘 정리되어야 한다.

• 원활한 고객센터: 문제 발생 시 빠르게 문의하고, 신속한 답변을 받고 싶어 한다.

• 할인 혜택 및 이벤트: 쿠폰, 포인트 적립, 시즌별 이벤트 등에 관심이 많다.

시나리오

• 상품 검색 및 관심상품 담기

  • 김수연은 출퇴근 길에 스마트폰으로 패션 카테고리를 둘러본다.

  • 새로 나온 봄 재킷을 발견하고, 제품 상세 페이지에서 사진과 리뷰를 확인한 뒤 “장바구니” 혹은 “관심상품”에 담는다.

• 장바구니 확인 및 주문

  • 퇴근 후 집에서 장바구니를 열어 최근 담아 둔 상품을 확인한다.

  • 할인 쿠폰이 적용 가능한지 확인하고, 다른 상품과 함께 결제를 진행한다.

  • 결제 방법으로 간편결제를 선택하고, 적립 포인트를 일부 사용해 최종 금액을 낮춘다.

• 배송 추적 및 알림 수신

  • 결제가 완료되면, 배송 예정일과 운송장 번호를 확인한다.

  • 배송이 시작되면 푸시 알림(앱/문자)을 통해 현재 위치를 추적한다.

  • 배송 완료 후 사이트 내에 자동으로 리뷰 작성 페이지가 뜨고, 별점과 간단한 사용 후기를 작성한다.

• 문의/클레임 처리

  • 만약 배송 시 파손된 상품을 받거나, 다른 상품을 잘못 배송받았을 경우, 1:1 문의를 등록한다.

  • 빠른 답변과 교환/환불 처리를 원활하게 받으면 서비스에 대해 긍정적인 인상을 갖게 된다.

3.2. 관리자 - 김민지

개요:

• 플랫폼 운영팀 매니저

• 재고 관리, 마케팅, 고객 상담까지 모두 직접함

• 각종 통계 지표를 통한 의사 결정

니즈:

• 상품 등록/관리의 편의성: 사진, 상세설명, 가격 등을 쉽게 등록하고, 수시로 업데이트할 수 있어야 한다.

• 효율적인 재고 관리: 인기 상품은 재고가 빨리 소진되므로 실시간 재고 파악이 중요하다. 품절 시 자동 알림이 필요하다.

• 프로모션 기능: 할인 쿠폰, 이벤트 페이지 등을 통해 매출을 촉진하고 싶다.

• 주문·배송 연동: 주문이 들어오면 배송사 연동을 통해 자동으로 송장 발급이 이루어지면 업무 부담이 줄어든다.

• 시스템 안정성 관리: 트래픽이 급증해도 사이트가 멈추지 않도록 서버 상태, DB 부하 등을 상시 모니터링.

• 회원/셀러 관리: 악성 이용자 차단, 셀러 검수(부정 상품 등록 방지), 분쟁 해결 등에 주력.

• 통계 대시보드: 매출, 주문 현황, 취소·반품 건수, 인기 상품 순위 등 종합적인 데이터를 빠르게 파악하여 경영진에 보고.

• 정책 반영: 이벤트, 할인 정책, 시스템 공지 등을 손쉽게 반영하고 업데이트해야 함.

시나리오:

• 상품 등록 및 재고 설정

  • 박한영은 신규 출시한 귀걸이 시리즈를 등록하기 위해 관리자(셀러) 전용 페이지에 접속한다.

  • 제품 사진(고해상도)과 상세 설명(소재, 사이즈), 가격, 초기 재고 50개를 입력한다.

  • 등록 후 상품이 정상적으로 검색되는지, 카테고리가 올바른지 확인한다.

• 주문 모니터링 및 처리

  • 판매 시작 후, 하루에 여러 건의 주문이 들어온다.

  • ‘주문 관리’ 화면에서 결제 완료된 주문을 확인하고, 택배사 API를 통해 자동 송장 번호를 발급받는다.

  • 송장 번호가 확정되면 고객에게 발송되는 안내문구(메일/SMS)를 확인한다.

• 재고 부족 상황

  • 특정 귀걸이 모델이 SNS에서 인기를 끌면서 재고가 예상보다 빠르게 소진된다.

  • 관리자 화면에 ‘재고 부족 알림’이 뜨고, 김민지는 추가 생산·입고 일정을 조율한다.

  • 한편, 사이트에서는 자동으로 “품절” 상태를 표시하고, 고객이 원하면 ‘재입고 알림 신청’을 할 수 있도록 설정한다.

• 프로모션 운영

  • 주말 할인 이벤트를 기획하여, 특정 상품에 10% 쿠폰을 발행한다.

  • 셀러 관리 페이지에서 쿠폰 생성, 유효 기간, 적용 범위(핸드메이드 액세서리 카테고리)를 설정한다.

  • 프로모션 기간 동안 매출 통계를 실시간으로 확인한다.

• 종합 대시보드 확인

  • 오전 출근 후, 이정민은 관리자 페이지에서 전일 매출, 신규 회원 수, 반품 건수 등을 체크한다.

  • 만약 특정 셀러의 반품률이 급격히 상승했다면 해당 셀러에게 문의를 진행한다.

• 회원/게시물 관리

  • 고객이 게시판이나 리뷰에 부적절한(욕설, 광고) 내용을 작성한 경우, 관리자 권한으로 숨김 처리 또는 삭제한다.

  • 악성 셀러(허위 상품 등록, 배송 미처리 등)가 발견되면 해당 셀러 계정을 일시 정지하고 고객들에게 공지문을 발송한다.

• 주문·결제 모니터링

  • 특가 이벤트로 인해 결제 오류가 급증할 경우, PG(결제 대행사) 시스템 상태나 서버 트래픽을 우선 점검한다.

  • 필요 시 개발 팀에게 에러 로그를 전달해 긴급 패치 또는 서버 확장(스케일 아웃)을 요청한다.

• 정책 변경 및 공지

  • 시즌 프로모션 정책(예: “구매 금액 5만원 이상 무료 배송”)을 바꾸거나, 사이트 유지 보수를 위한 점검 시간 안내를 공지한다.

  • 필요한 경우, 이메일/SMS 푸시 기능을 통해 전 회원에게 알림을 발송한다.

3.3. 개발자 - 최원준

개요:

• 서버/DB/인프라 전반 담당

• 서비스 안정성 및 성능 최적화 방안을 모색함

니즈:

• 유지보수성: 새 기능을 추가해도 기존 코드가 무너지지 않도록 아키텍처와 테스트를 철저히 준비한다.

• 고성능 & 확장성: 이벤트 기간이나 프로모션 시 트래픽 급증을 대비, 서버와 DB 성능 튜닝, 로드밸런싱 등을 구현한다.

• 로그 & 모니터링: 서버 로그, 오류 모니터링 시스템(Sentry, Datadog 등)을 통한 실시간 에러 감시 및 빠른 대응.

시나리오:

• 성능 이슈 대응

  • 프로모션 시작 후, 주문 요청이 평소 대비 3배로 늘어나면서 DB 커넥션 폭주 현상이 발생한다.

  • 최민석은 빠르게 쿼리 로그를 확인하고, 인덱스 최적화 혹은 캐싱(Redis 등) 전략을 적용한다.

  • 필요 시 AWS 오토 스케일링 그룹 설정을 조정하여 서버 인스턴스를 늘린다.

• 결제 모듈 점검 및 오류 처리

  • PG(결제 대행사)와의 연동 과정에서 가끔 결제 승인 응답이 지연되는 문제가 발생한다.

  • 결제 상태가 불일치(사용자는 결제를 했는데 서버에는 실패로 기록)할 위험이 커지므로, 웹훅(Webhook) 및 재시도 로직을 구현한다.

  • 에러 발생 시 알림을 받도록 모니터링 시스템에 설정하고, 관리자에게 대응 방안을 공유한다.

• 배포 & CI/CD

  • 코드 리뷰가 완료되면 Jenkins/GitLab CI 등으로 자동 빌드 및 테스트를 수행한 뒤 스테이징 서버에 배포한다.

  • 스테이징 환경에서 QA 팀의 시나리오 테스트가 끝나면 프로덕션 서버에 무중단 배포(Blue-Green 혹은 Rolling Update)를 진행한다.

  • 배포 이후에는 주요 지표(에러율, 응답 시간)를 모니터링하여 안정성을 확인한다.

4. Use Case - 사용자

회원가입, 로그인, 사용자 관리

4.1. 회원가입

사용자가 사이트를 통해 상품을 구매하거나 장바구니를 이용하기 위해서는 회원가입 필요

1. 사용자는 회원가입 페이지에서 이메일, 비밀번호, 이름, 연락처 등을 입력한다.

2. 중복 이메일인지 확인

3. 중복이 아니면 해당 정보를 데이터베이스에 저장하고, 가입 완료 메시지를 전달한다.

4. 이메일 인증이나 SMS 인증이 있을 경우, 추가적으로 인증 절차를 진행한다.

• 이미 존재하는 이메일 확인

• 비밀번호 형식에 따른 에러 메시지

• 필수 정보 누락시 에러 처리

4.2. 로그인

가입된 사용자가 정상적으로 로그인하여 장바구니, 주문 등을 이용할 수 있도록 함.

1. 이메일, 비밀번호 입력으로 로그인 요청

2. 해당 이메일의 사용자 정보를 조회, 비밀번호 검증

3. 정상 인증시 JWT를 생성후 클라이언트로 전달

• 이메일 존재 여부와 비밀번호 불일치 에러 메시지

• 특정 횟수 이상 로그인 실패 시 잠금 처리

4.3. 사용자 정보 조회/수정

1. 로그인 후 사용자 마이페이지에 진입

2. 사용자 프로필(이름, 연락처, 주소, 이메일 수신 동의 등)을 확인하고 수정

3. 수정 요청 시 백엔드는 변경 가능한 항목을 업데이트하고 결과를 반환한다.

• 주소 등 형식 검증 실패 시 에러 메시지

• 업데이트 요청 시 권한 확인(본인 또는 관리자가 아닌 경우 불가)

5. Use Case - 상품

5.1. 상품 정보등록

관리자가 상품을 신규로 등록하는 프로세스

1. 관리자는 상품명, 가격, 재고 수량, 카테고리, 상세설명, 이미지 등의 정보를 입력한다.

2. 백엔드에서는 입력된 데이터를 검증 후 DB에 저장한다.

3. 성공 시 상품 상세 페이지로 링크 혹은 등록 완료 안내를 전달한다.

• 플수 필드(상품명, 가격, 카테고리 등) 누락되면 에러 메시지

• 중복된 상품 코드를 입력한 경우 에러 처리.

• 이미지 업로드 과정에서 발생할 수 있는 예외(파일 형식, 용량 제한 등).

5.2. 상품 정보 수정

기존에 등록된 상품의 가격/재고/설명 등을 변경

1. 관리자는 상품 수정 페이지에서 변경할 정보를 기입한다.

2. 백엔드는 DB에서 기존 데이터를 조회, 입력한 변경 사항을 적용한다.

3. 성공 시 수정 완료 메시지 반환.

• 조재하지 않는 상품 ID 요청시 에러

• 재고 등의 필드에 대한 유효성 검사 후 에러

5.3. 상품 목록 조회/검색

사용자나 관리자가 카테고리별, 키워드별로 상품을 검색하고 조회함.

1. 사용자가 카테고리 혹은 키워드를 입력하여 검색 요청

2. 검색 조건(카테고리, 가격 범위, 키워드 등)에 맞는 상품 리스트를 반환.

3. Pagination 처리

• 검색 결가가 없는 경우 빈 리스트 반환

• 잘못된 필터 조건 / SQL 인젝션 방어

6. Use Case - 장바구니

6.1. 장바구니 담기

사용자가 마음에 드는 상품을 일단 장바구니에 담아두는 기능

1. 사용자는상품 상세 페이지에서 장바구니 담기 버튼을 클릭

2. 백엔드는 사용자 식별 정보와 상품ID, 수량을 파라미터로 받아 장바구니 테이블에 저장

3. 장바구니에 이미 동일 상품이 있는 경우 수량을 합산/업데이트

4. 담기 완료 시 장바구니 페이지로 리다이렉트 또는 메시지 알림

• 재고 부족한 경우 담기 불가

• 인증되지 않은 사용자의 경우 임시 장바구니로 처리(쿠키)

6.2. 장바구니 조회

장바구니에 담긴 상품 목록, 수량, 금액 등을 확인

1. 사용자는 장바구니 페이지에 접속

2. 사용자 ID를 기반으로 장바구니 테이블의 상품 목록, 수량, 가격을 조회

3. 총 금액, 배송비 등을 함께 제공

• 장바구니 비어있을 시 빈목록 반환

6.3. 장바구니 수정/삭제

장바구니 상품 개수를 조정하거나 필요 없는 상품을 삭제

1. 사용자는 장바구니 내 특정 상품의 수량을 변경하거나, 제거 버튼을 클릭한다.

2. 장바구니 테이블에서 해당 상품 레코드를 업데이트 또는 삭제한다.

3. 수정/삭제 후 최신 장바구니 상태를 반환하여 재확인

• 수량이 0으로 설정됬을시 삭제 처리

• 이미 결제가 진행 중인 상품이면 예외 처리

7. Use Case - 주문서

7.1. 주문서 생성

장바구니에서 결제 단계를 시작할 때 주문서를 생성함

1. 사용자는 장바구니 페이지에서 구매하기 버튼 클릭

2. 장바구니 내 상품 목록과 사용자 정보를 확인

3. 배송지, 결제 방법 등을 입력 받고 주문 테이블에 레코드 생성

4. 주문 생성 완료 후 결제 페이지로 넘어간다.

• 재고가 부족한 상품이 있는 경우 주문 생성 불가. 재고가 부족한 상품만 제외하고 주문 확인

• 사용자 정보가 유효한지 확인

7.2. 결제

주문서가 생성된 후, 실제 결제를 완료하여 결제 정보를 기록

1. 결제 페이지에서 카드사/PG(대행사)에 정보를 보내 결제 승인 요청

2. 승인 성공 시 결제 완료 상태로 업데이트하고, 결제 정보를 주문 레코드에 저장.

3. 결제 실패 시 실패 사유 반환(카드 한도 초과, 오류 등)

• PG에서 승인 거절 시, 주문 상태를 결제 실패로 업데이트 후 사용자에게 알림

• 중복 결제, 혹은 금액 불일치 시 에러 처리

• 결제 도중 취소 시 주문 상태는 결제 전으로 유지하거나 결제 취소로 변경

8. Use Case - 배송

8.1. 배송 준비

결제 완료된 주문은 물류 창고나 배송 담당 부서에서 확인 후 송장 번호를 부여하고 배송을 시작함.

1. 결제 완료된 주문 상태를 배송 준비 중으로 변경

2. 배송사(택배사)의 API 또는 관리 화면에서 송장 번호를 생성/등록

3. 등록이 완료되면 주문 상태를 배송 중으로 업데이트하고 사용자에게 알림(이메일, SMS)

• 송장번호 유효성 확인

• 배송사 지원 여부 확인

8.2. 배송 진행 업데이트

택배사 API 또는 관리자가 수동으로 배송 단계를 업데이트하여 사용자가 확인할 수 있음

1. 시스템은 일정 간격으로 택배사 API 호출하여 배송 상태 조회

2. 새로운 상태가 확인되면 주문 테이블의 상태를 업데이트.

3. 상태 변경시 사용자에게 알림을 보냄

• 택배사 API 장애, 네트워크 오류로 인해 조회 실패 시 재시도

• 주문이 이미 배송 완료 상태인 경우 중복 업데이트 방지

8.3. 배송 완료

사용자가 상품을 수령하면 배송 완료 상태로 처리, 구매 확정

1. 택배사 상태가 배달 완료로 확인되면 주문 테이블 상태를 배송 완료로 업데이트

2. 사용자 확인 후, 반품/교환 기간 등을 고려하여 상태를 최종 확정으로 변경할 수 있음

• 사용자 미수령, 분실, 오배송 등 이슈 발생 시 클레임 처리

9. 리뷰 및 문의

9.1. 리뷰 작성

상품 구매자가 리뷰를 작성

1. 구매한 상품에 대해서만 리뷰 작성 가능(구매 이력 체크)

2. 작성된 리뷰 내용(별점, 텍스트, 이미지 등)을 백엔드에 전송

3. 리뷰 테이블을 저장하고 평균 평점을 업데이트

• 해당 주문이 아직 배송 완료가 아니면 리뷰 불가

• 리뷰 내용 필터링

9.2. 리뷰 조회

상품 상세 페이지에서 다른 사용자가 남긴 리뷰를 확인

1. 상품 ID를 기준으로 리뷰 테이블에서 리뷰 목록 조회

2. 최신순, 평점 순 등 정렬 기준 적용

• 리뷰가 없는 경우 빈 목록 반환

9.3. 1:1 문의(고객센터)

고객이 상품이나 배송, 결제 등 궁금한 점을 문의하고 관리자가 답변

1. 사용자는 1:1 문의 메뉴를 통해 문의 카테고리와 내용을 작성(상품/ 배송/ 환불 등)

2. 문의 테비르에 저장한 후, 관리자는 어드민 화면에서 확인 가능

3. 관리자가 답변 등록 시 사용자에게 알림(메일/문자)

• 로그인하지 않은 사용자는 1:1 문의를 작성할 수 없게 제한(또는 비로그인 문의 기능 별도)

• 악의적 스팸, 욕설 등 필터링

10. 관리자 기능

10.1. 회원 관리

1. 관리자 페이지에서 전체 회원 목록을 조회하고, 검색(이름, 이메일, 가입일자) 가능

2. 특정 회원을 선택해 정지 또는 권한 변경.

• 관리자 권한이 없는 계정이 접근하려고 하면 에러 메시지(접근 불가)

10.2. 재고 및 상품 통계

1. 재고 부족 상품 리스트 조회(품절 임박 상품)

2. 상품 판매 통계 확인(베스트 셀러, 최근 일주일 판매량 등)

3. 프로모션이나 이벤트 설정(특정 상품 할인, 쿠폰 발행)

10.3. 주문 관리

1. 전체 주문 목록을 조회. 상태(결제 완료, 배송 중, 배송 완료 등) 별도 필터.

2. 배송 이슈 발생 시 상태 변경 및 고객 안내

• 결제 취소/환불 절차 시 PG 연동 고려

• 반품/교환 처리가 배송 시스템과 어떻게 상호작용하는지 로직 정의 필요

11. 이벤트/프로모션

11.1. 쿠폰 발행

고객 유치를 위해 특정 조건에 쿠폰 제공(신규 회원, 특정 금액 이상 구매, 마지막 로그인 등)

1. 관리자 화면에서 쿠폰 생성 설정(할인 금액 또는 할인율, 유효 기간, 대상 조건)

2. 해당 조건을 만족하는 사용자 계정에 쿠폰 발행

3. 사용자는 결제 시 쿠폰 선택 가능

• 유효 기간이 지난 쿠폰 사용 불가 및 자동 삭제

• 중복 할인 규칙 설정(쿠폰 + 포인트 동시에 적용 가능 여부)

11.2. 이벤트 페이지

특정 테마(설날 등)로 이벤트 페이지를 만들어 할인 상품을 한눈에 볼 수 있음

1. 관리자는 이벤트 페이지에 포함할 상품, 할인율, 기간 등을 설정

2. 이벤트 테이블을 두고, 관련 상품과 매핑해 API로 제공

• 이벤트 기간이 끝나면 할인 적용 중단

• 이벤트 페이지가 정상적이 방법으로 호출됬는지 확인

12. 개략적인 서비스 규모 가정

12.1. 개요

해당 프로젝트는 토이 프로젝트 이상으로, 현업에서 사용할 수 있는 규모로 가정했습니다. 중소형 이커머스 플랫폼으로, MAU 10만명 달성이 가능하다고 가정했습니다.

12.2. 상세

1. 사용자 및 트래픽 규모

• 월간 활성 사용자(MAU): 10만 명

• 일간 활성 사용자(DAU): 3,000~5,000명(MAU 3~5%)

• 피크 타임 동시 접속자 수: 500~1,000명(이벤트/세일 등으로 트래픽 급증 대비 여유 있게 2,000명 가정)

2. 주문/결제 처리량

• 평일 일일 주문 건수: 300~500건

• 주말/이벤트 시 일일 주문 건수: 최대 1,500~2,000건

• 결제(트랜잭션) 처리 TPS: 초당 2~5건 이상의 결제 요청

3. 상품/카탈로그 규모

• 초기 등록 상품 수: 약 5,000~10,000개 (월 100~200개)

  • 최대 이미지 10장. 각 이미지는 고화질로, 약 1~5MB로 가정 (최대 약 500,000MB = 500GB)

• 리뷰 수: 상품 1개당 평균 3~5개, 인기 상품은 50~100개 리뷰 (월 1000~2000개)

  • 최대 이미지 10장 등록 가능. 각 이미지는 저화질로, 약 100~500kb로 가정 (최대 약 500,000,000KB = 500GB)

4. 데이터베이스(스토리지) 추정

1. 회원 테이블

   • 누적 가입자 수: 20만 명(활성 사용자는 10만 명 수준)

2. 주문/결제/배송 테이블

   • 연간 10만~15만 건의 주문이 발생(1년 기준).

   • 주문 당 평균 2~3개 상품을 구매한다고 가정 → 연간 주문 상세(오더 아이템) 테이블엔 20~45만 건 정도가 누적.

3. 리뷰/문의/고객센터 테이블

   • 리뷰 및 문의는 연간 수만~수십만 건.

   • 1:1 문의, FAQ, 공지사항 이력도 별도 테이블로 관리.

4. DB 용량

   • 주 데이터(회원, 주문, 상품, 리뷰)는 RDBMS(MySQL에 저장.

   • 이미지는 AWS S3 사용

5. 트래픽 처리/인프라 구상

1. 요청 분포

   • 읽기 요청(상품 조회, 검색, 리뷰 보기): 80~90%

   • 쓰기 요청(주문 생성, 결제, 리뷰 작성, 문의 등록): 10~20%

2. QPS(Queries Per Second)

   • 평시: 20~50 QPS

   • 이벤트 시: 100~200 QPS

3. 서버 인프라(Optional)

   • Web/API 서버: 2~3대 (Docker 컨테이너 기반). 오토스케일링 → 최대 5~6대

   • DB 서버: Master-Slave(혹은 Master-ReadReplica) 구성 1세트

   • Cache 서버(Redis): 세션 저장 및 인기상품 조회 캐싱

   • 로드밸런서(LB)

   • CDN

6. 배송 및 결제 연동

• 결제 모듈:

  • PG(이니시스, KG이니시스, 토스페이먼츠 등) 연동을 통해 카드/계좌이체/가상계좌 지원.

  • 월 5,000~6,000건의 결제 트랜잭션은 무리 없이 처리 가능.

• 배송사 연동:

  • 1~2개 주 배송사(예: CJ대한통운, 롯데택배) API 연동 + 택배사별 송장 번호 처리 로직.

  • 1일 300~2,000건 사이 배송 상태 업데이트.

7. 이벤트/프로모션 시나리오

• 월 1회 메이저 프로모션

  • 방문자·주문량이 평시 대비 2~3배 증가.

  • 3,000~5,000 DAU → 최대 1만 DAU 이상 단기적으로 상승.

8. 로그 및 모니터링

• 일일 로그 이벤트

• 모니터링 도구

13. 개발 순서

1. MVP

• 핵심 기능:

  1. 회원 (가입/로그인/인증),

  2. 상품 (등록/조회/장바구니/주문),

  3. 주문서 생성 (결제는 스텁/모의 처리 가능),

  4. 간단한 관리자(admin) 화면 (상품 관리, 주문 관리)

• 시간이 많이 걸리는 기능:

  • 리뷰/평점, 고객센터 등 추가 기능

  • 쿠폰/프로모션/포인트 등 복잡한 할인 로직

  • 택배사 배송 추적 API 연동

  • 실제 PG(결제 대행사) 연동

전략: 일단 결제 부분은 ‘모의 승인’ 로직만 구현해둔 뒤, 배송은 “배송 상태를 DB에서 수동/일정 시간 경과 업데이트” 정도로 간단히 처리. 이렇게 하면 e2e 흐름(가입→상품→주문→결제→배송)의 뼈대가 돌아가고, 나중에 실 결제 및 물류 API를 붙이는 식으로 단계적으로 확장.

---

2. 단계별 로드맵

1단계 기본 토대 구축 (약 2~3주)

1. 프로젝트 세팅 & 아키텍처 결정

   • 프레임워크: SpringBoot

   • DB 선정(MySQL) & ERD 1차 설계

   • 폴더 구조/코딩 컨벤션/CICD 기본 환경 셋업(GithubActions)

2. 회원(인증/인가) & 기본 관리자 계정

   • 회원가입, 로그인 (JWT)

   • 관리자 계정(슈퍼유저) 1개

3. 상품 도메인 / CRUD

   • 상품 테이블 설계 (상품명, 가격, 재고, 카테고리 등)

   • 관리자(혹은 API)에서 상품 등록/수정/삭제 가능

   • 사용자(일반 유저) 관점에서 상품 목록/상세 조회 가능

4. 장바구니 & 주문서(기본 구조)

   • 장바구니 테이블에 담기/조회/삭제 (캐시X)

   • 주문서 생성 로직(재고 체크, 사용자 정보 확인)

   • 결제 로직은 일단 ‘결제 성공’ 상태 반환”

결과: 이 단계가 끝나면 “회원가입 → 로그인 → 상품 보기 → 장바구니 담기 → 주문 생성 → (가짜 결제 완료) → 주문 완료”가 일단 돌아가는 상태.

---

2단계 결제(PG) 연동 + 기본 배송 로직 (약 3~4주)

1. 배송 상태 처리(1차)

   • 택배 API 연동전, 일단은 배송 상태를 Batch를 통해 일정 시간마다 업데이트 또는 판매자가 직접 업데이트 가능한 EndPoint 구현

     • 배송 준비 중 → 배송 중 → 배송 완료

2. 간단한 관리자 페이지(또는 API) 개선

   • 결제/주문 목록(최근 주문, 결제 상태, 배송 상태) 조회

   • 관리자 권한으로 주문 상태 변경, 상품 재고 수정, 결제 취소(부분 환불) 등 핵심 액션 가능

3. 프로모션/쿠폰 등 부가 기능

   • 간단한 쿠폰 발행 로직(쿠폰 코드, 만료일, 할인 금액/율)

   • 결제 시 쿠폰 적용 → 최종 결제 금액에서 할인.

   • 포인트 적립, 회원 등급 등은 우선순위에 따라 추후 확장.

4. 리뷰/문의(고객센터)

   • 시간이 허락한다면 리뷰(구매자만 가능), 문의/FAQ 게시판을 붙인다.

   • 관리자 페이지에서 리뷰/문의 관리(삭제, 답변) 가능하게.

결과: 연동을 제외한 대부분의 기능을 사용할 수 있음.

---

3단계 배송 API 연동 + 추가 기능(약 2~3주)

1. 택배사 API(물류) 연동

   • 송장 번호 발급, 배송 상태 조회 API를 붙인다.

   • (시간이 부족하면) 폴링(polling) 방식으로만 구현하고, Webhook(콜백) 방식은 추후 확장.

   • 배송 진행 상태를 일정 주기로 업데이트 & 사용자에게 노출.

2. 결제 모듈 구현

   • PG(카드 결제 등) 연동

   • 승인/취소/환불의 핵심 로직만 구현

   • 결제 실패/성공 콜백(Webhook) 처리, 주문 상태 업데이트 로직

결과: 어느 정도 실사용 가능한 이커머스 시스템 완성. 결제, 주문, 배송 추적, 프로모션, 고객 리뷰까지 일련의 흐름을 지원.

---

4단계 마무리 테스트 & 운영 (잔여 기간)

1. 통합 테스트, 부하 테스트

   • 가상의 부하(트래픽)에 대한 테스트 → 병목 지점(쿼리, API 응답) 확인.

2. 보안/인프라 점검

   • HTTPS 인증서 설정, JWT/세션 만료시간 관리, 비밀번호 해시 여부 등.

   • 로깅, 모니터링 셋업.

   • 장애 혹은 에러 발생 시 알림 설정.

3. 문서화 & 배포

   • API 스펙 정리 (Swagger)

   • 운영/배포 가이드(Optional)

---

3. 현실적인 최소 기능(MVP) vs. 확장 기능

기능	우선순위	구현 방식
회원가입/로그인	필수	JWT 인증(간단), 소셜 로그인은 후순위로 미룸
상품 CRUD	필수	관리자 페이지 or API로 등록/수정, 카테고리/이미지 추가 등 최소
장바구니	필수	Redis or DB, 수량 업데이트
주문 & 결제(Stub)	필수	“결제 성공” 가짜 응답으로 1차 구현, 결제금액 & 재고 체크
결제(PG 실제 연동)	2차	한 가지 결제수단(카드)만 먼저 붙이고, 가상계좌 등은 추후
배송 상태(수동)	필수	관리자에서 배송 준비 중→완료 정도만 수동 입력
배송 API(실제 연동)	2차	CJ대한통운 등 택배사 연동, 송장번호 자동 발급, 상태 업데이트
리뷰 & 평점	3차	배송 완료된 주문만 리뷰 가능, 관리자/사용자 인터페이스
프로모션/쿠폰	3차	간단한 쿠폰(코드, 만료일, 할인)부터 시작
고객센터(문의/FAQ)	3차	관리자 답변 기능, 알림(메일 or 사이트 내 알림)

---

5. 정리

• 3개월은 이커머스 전 기능을 완벽하게 구현하기엔 매우 타이트한 시간.

• 우선순위를 ‘핵심 거래 흐름(회원→상품→장바구니→주문→결제)’ 에 맞추고, 어려운 부분(실제 PG 연동, 배송 API)은 초반에 단순화(Mock)해서 전체 흐름을 잡아놓는 것이 중요.

• 이후 시간이 허락하면 결제/배송 API를 실제로 붙이고, 프로모션·할인·리뷰·고객센터 등 부가 기능을 넣는 식으로 단계별 확장.

• 결국 MVP → 실제 PG/배송 연동 → 부가 기능 순서가 가장 합리적이며, 각 단계가 끝날 때마다 배포/피드백/QA를 반복하면 3개월 내에 어느 정도 완성도 있는 서비스를 만들 수 있다.