분석 산출물 예시

옵션 3단 → 5단 확장 영향 분석

착수 1~2주차에 이런 형태로 정리해 전달드립니다. 어디를 고쳐야 하고 무엇이 위험한지 먼저 드러내는 것이 목적입니다.

옵션 값은 상품 등록에서 정산까지 전 구간을 따라 흐릅니다. 한 곳이라도 3단 기준으로 처리되고 있으면 그 지점에서 끊깁니다. 그래서 먼저 옵션을 참조하는 모든 지점을 찾아냅니다.

점검 구간14

주문 전 구간

수정 필요9

구간

확인 필요3

구간

영향 없음2

구간

주문 프로세스 영향 구간

붉은색은 수정 필요, 노란색은 확인 필요

STEP 1

상품 등록수정

STEP 2

옵션 조합 생성수정

STEP 3

재고 관리수정

STEP 4

상품 상세수정

STEP 5

장바구니수정

STEP 6

주문서수정

STEP 7

결제 연동확인

STEP 8

주문 저장수정

STEP 9

주문 상세수정

STEP 10

취소·환불확인

STEP 11

입점사 정산수정

STEP 12

배송·송장확인

STEP 13

회원·쿠폰영향 없음

STEP 14

게시판·CS영향 없음

가장 놓치기 쉬운 곳은 정산입니다 — 입점사 정산은 옵션별 금액을 기준으로 계산되는 경우가 많습니다. 옵션 단수가 늘어났는데 정산 로직이 3단 기준으로 남아 있으면, 화면은 정상인데 입점사에게 지급되는 금액이 틀어집니다. 주문 화면만 보고 테스트하면 오픈 후에야 발견됩니다.

화면 영역별 수정 범위

쇼핑몰 · 내부 관리자 · 입점사 관리자 3개 영역

영역	화면	등급	내용
쇼핑몰	상품 상세 옵션 선택	높음	5단까지 순차 선택. 단계가 늘어나면 이탈이 생기므로 선택 방식을 함께 검토드리고 싶습니다
	장바구니 · 주문서	높음	옵션 표시 영역 확장, 긴 옵션명 줄바꿈 처리
	주문 내역 · 상세	중간	과거 3단 주문과 신규 5단 주문이 같은 화면에서 정상 표시
내부 관리자	상품 등록 · 옵션 설정	높음	5단 입력 UI. 조합 수가 급증하므로 일괄 입력·엑셀 업로드 방식 검토 필요
	재고 · 가격 관리	높음	조합별 재고·추가금액 관리. 목록이 길어져 검색·필터 필요
	주문 관리	중간	주문 목록·상세의 옵션 표시
입점사 관리자	상품 · 옵션 관리	높음	입점사가 직접 5단 옵션을 등록하는 경우 동일 적용
입점사 관리자	주문 · 정산	높음	정산 금액 산출에 옵션이 반영되는 방식 확인 필수

옵션 확장 방식은 크게 두 가지입니다. 어느 쪽이 맞는지는 실제 테이블과 코드를 봐야 판단할 수 있습니다. 착수 초기에 두 방식을 비교해 드리고 함께 정하는 것을 제안드립니다.

방식 A — 컬럼 추가

작업이 빠릅니다
기존 구조를 유지하고 opt4·opt5 컬럼만 추가

기존 코드 영향이 적습니다
3단까지 쓰는 기존 쿼리가 그대로 동작

과거 주문이 안전합니다
기존 행을 건드리지 않음

−

6단 요구 시 반복
나중에 같은 작업을 또 하게 됩니다

−

빈 컬럼이 늘어납니다
2단만 쓰는 상품도 5개 컬럼을 가짐

방식 B — 행 분리

단수 제한이 없어집니다
6단·7단도 구조 변경 없이 가능

구조가 정리됩니다
옵션을 별도 테이블에서 행으로 관리

−

손볼 범위가 넓습니다
옵션을 참조하는 모든 쿼리 수정 필요

−

기존 데이터 이관 필요
과거 주문의 옵션을 새 구조로 옮겨야 함

−

2개월에 부담
운영 중 시스템에는 위험이 큽니다

현 시점 의견

코드를 보기 전 판단이며, 분석 후 달라질 수 있습니다

// 방식 A — 컬럼 추가 (현재로서는 이쪽을 우선 검토)
product_option
  opt1_nm, opt1_val
  opt2_nm, opt2_val
  opt3_nm, opt3_val
+ opt4_nm, opt4_val   ← 추가
+ opt5_nm, opt5_val   ← 추가

order_item
  opt1_val, opt2_val, opt3_val
+ opt4_val, opt5_val  ← 추가 (기존 주문은 NULL)

// 조회 시 NULL인 단수는 건너뛰고 표시 → 과거 주문 그대로 유지

2개월 일정과 운영 중 시스템이라는 조건에서는 방식 A가 현실적이라고 봅니다. 방식 B는 구조적으로 낫지만 손볼 범위가 넓고 기존 데이터 이관이 따릅니다. 운영 중인 쇼핑몰에서 그 작업은 위험 대비 이득이 크지 않을 수 있습니다.

다만 실제 테이블이 이미 행 분리 구조라면 판단이 완전히 달라집니다. 그 경우 컬럼 추가 자체가 불가능하고, 단수 제한이 코드 쪽에만 있을 가능성이 높습니다. 그래서 분석 전에 확정하지 않겠습니다.

운영 중인 쇼핑몰이므로 3단 기준으로 쌓인 주문이 이미 있습니다. 구조를 바꾼 뒤에도 과거 주문이 정상 조회되고 정산·환불이 가능해야 합니다.

기존 주문 확인 항목

구조 변경 후 반드시 확인할 목록

확인 대상	위험도	확인 내용
주문 내역 조회	높음	과거 3단 주문이 목록·상세에서 옵션 누락 없이 표시되는가
진행 중 주문	높음	배포 시점에 결제는 됐는데 배송 전인 주문이 이후 단계로 정상 진행되는가
과거 주문 취소·환불	높음	3단 주문을 부분 취소할 때 금액이 정상 계산되는가
입점사 정산	높음	배포 전후 정산 금액이 동일하게 산출되는가. 배포 직전 정산 마감분과 대조
장바구니 잔여	중간	고객이 담아둔 기존 장바구니가 유지되는가
통계·매출 집계	중간	옵션별 매출 통계가 기존 기간과 이어지는가

진행 중 주문이 가장 위험합니다 — 배포 시점에 결제 완료 상태로 배송을 기다리는 주문이 반드시 있습니다. 구조가 바뀌면서 이 주문들이 다음 단계로 넘어가지 못하면 고객 클레임이 바로 발생합니다.

그래서 주문이 가장 적은 시간대에 배포하고, 배포 직후 진행 중 주문 몇 건을 직접 확인하는 절차를 넣겠습니다.

추가상품 버그 — 먼저 정리합니다

버그 수정과 옵션 확장을 동시에 하면 원인 구분이 안 됩니다

순서	작업	이유
1	재현 조건 정리	어떤 상품·어떤 옵션 조합에서 발생하는지 문서화. 현상만 보고 고치면 다른 경로에서 재발합니다
2	원인 파악 후 공유	고치기 전에 원인을 먼저 전달드려 확인받습니다
3	버그 수정 · 배포	옵션 확장 전에 먼저 안정화
4	옵션 확장 착수	안정된 상태 위에서 구조를 변경합니다

동시에 진행하면 문제가 생겼을 때 버그 수정 때문인지 옵션 확장 때문인지 가려낼 수 없습니다. 순서를 나누면 되돌릴 지점도 명확해집니다.

운영 중인 쇼핑몰이라 배포 자체가 매출 위험입니다. 옵션은 주문의 근간이라 잘못되면 주문이 안 들어가거나 금액이 틀어집니다.

단계적 배포 계획

한 번에 올리지 않고 나눠서 확인합니다

단계	내용	확인 후 다음
1	DB 구조 변경 — 컬럼 추가만. 기존 동작에 영향 없음	기존 주문 조회 정상 확인
2	관리자 화면 — 5단 옵션 등록 기능 반영. 고객 화면은 그대로	테스트 상품 등록 · 재고 설정
3	주문 프로세스 — 장바구니·주문서·주문 저장	테스트 계정으로 실주문 1건 완주
4	고객 화면 노출 — 5단 상품 공개	실제 주문 유입 확인
5	정산 확인 — 첫 정산 주기에 금액 대조	입점사 정산 금액 검증

각 단계마다 되돌릴 방법을 준비합니다 — DB 구조를 바꿀 때 기존 상태로 복구하는 절차를 함께 만들어 둡니다. 문제가 생겼을 때 원인을 찾는 동안 서비스가 멈추지 않도록 하는 것이 목적입니다.

오픈 전 완주 테스트

각 기능이 개별로 되는 것과 이어지는 것은 다릅니다

시나리오	확인
5단 옵션 상품 정상 주문	상품 등록 → 옵션 선택 → 장바구니 → 결제 → 주문 확인 → 배송 → 정산까지 한 번 완주
5단 상품 부분 취소	여러 옵션 상품 중 일부만 취소했을 때 금액과 재고가 정상 처리되는가
3단 기존 상품	기존 상품이 여전히 정상 주문되는가. 가장 중요한 확인
혼합 장바구니	3단 상품과 5단 상품을 함께 담아 한 번에 주문했을 때
재고 소진	5단 조합 중 하나의 재고가 0일 때 선택이 막히는가
입점사 정산 대조	5단 상품 주문의 정산 금액이 수기 계산과 일치하는가

3단 기존 상품 확인을 가장 중요하게 봅니다 — 새 기능이 동작하는 것보다 기존 매출이 끊기지 않는 것이 먼저입니다. 특수필름 상품은 아직 팔지 않고 있지만, 기존 상품은 지금도 팔리고 있습니다.

본 화면은 분석 산출물의 형태를 보여드리기 위한 예시이며, 표시된 구간 수와 위험도는 실제 코드를 분석한 결과가 아닙니다. 실제 내용은 착수 후 1~2주차 분석에서 확정됩니다.