1. 프로젝트 개요
주제
인테리어 시공/수리/자재 구매를 하나의 플랫폼에서 해결할 수 있는 서비스
개발 인원 및 기간
4명, 2025-11 ~ 2025-12
기술 스택
| 구분 | 사용기술 |
|---|---|
| 프론트엔드 | React |
| 백엔드 | Spring Boot / Spring Security / JWT |
| 데이터베이스 | MariaDB / JPA / QueryDSL |
2. 역할 및 핵심 구현 기능
역할
- 커머스 및 결제 시스템 설계/구현
- 사용자 경험 중심의 견적 시스템 개발
- 통합 관리자 및 정산 시스템 전담
맡은 기능
- 대화형 견적 요청 시스템 :
- 사용자 집입 장벽을 낮추기 위해 자유 입력 대신 단계별 선택 구조로 로직 설계.
- 장바구니 및 결제 :
- 브랜드별 그룹화 : 묶음/개별 배송비를 자동으로 계산하도록 구현
- Toss Payments API 연동 : 안정적인 결제 승인/취소 프로세스 구축 및 결제 데이터 무결성 확보
- 관리자 시스템 :
- 데이터 시각화 : Chart.js를 활용해 매출 및 주문 현황을 한눈에 파악할 수 있는 대시보드 구현
- 정산 자동화 : 매일 0시, 주문/매칭 데이터를 기반으로 정산 테이블을 생성하는 로직 구현
3. 트러블 슈팅
1) 전문가 조회시 발생한 카디널리티 곱
문제 상황
전문가 목록을 조회하면서 매칭 건수와 리뷰 평점을 한 번에 가져오기 위해 Expert, Matching, Review 테이블을 조인하는 과정에서 카디널리티 곱이 발생했고, 매칭수와 평점도 기대하는 값보다 훨씬 높은 값이 나왔다.
원인 분석
- 카디널리티 곱 : 테이블 조인 시 관계가 1:N과 1:M으로 얽히면서 DB는 모든 가능한 조합을 행으로 생성한다.
- 집계 함수 : 중복된 행이 생성된 상태에서 집계 함수를 실행하게 된다면, 동일한 매칭 데이터가 리뷰 수만큼 중복 계산되어 기대하는 값과 다르게 나타난다.
해결 과정
-
프로젝트 중
나는 이 문제를 단순히 데이터 중복 문제로 받아들였기 때문에 Expert, Matching, Review에 해당하는 각각의 PK에 대한 중복제거를 하는 방향으로 해결하기로 했다.
countDistinct()를 각 PK에 적용시켜 데이터 중복 문제를 해결했지만, 프로젝트가 다 끝나고 정리하는 중, 이 방법이 카디널리티 곱을 해결하는 것이 아니고, 데이터가 많아지면 DB 성능이 좋지 않다는 것을 알게되었다. -
프로젝트 후
좋지 않은 방향으로 문제를 해결한 것 같아서 다른 방법이 있나 검색하던 중, 두 가지 방법을 알게 되었다.
1) 역정규화
전문가 테이블에 매칭수와 평점 컬럼을 추가해서 같이 관리하는 방법이다. 물론 매칭이 성사될 때와 리뷰가 작성될 때 매번 업데이트 해줘야 하지만, 목록을 조회하는 기능을 비교할 수 없을정도로 많이 사용하기 때문에 비용이 더 저렴하다고 생각했다.
2) 서브쿼리
서브쿼리를 사용해서 전문가별로 그룹화 하여 집계를 마치고 메인 테이블과 조인하는 방법이다. 역정규화 없이도 카디널리티 곱 현상을 차단할 수 있다.
2) 결제 시스템의 위변조 금액 방어
문제 상황
테스트 결제라고 해도 계좌에 잔액이 부족하면 결제가 안되는 줄 알고, 브라우저에서 개발자 도구를 통해 결제 금액을 수정한 상태로 결제를 진행해보니, 수정된 금액으로 결제가 되었다.
결제가 완료되어 주문이 들어간걸 테스트 하는 상황이었지만, 엄청 큰 취약점을 발견하게 되었다.
원인 분석
브라우저 메모리에 저장된 상태값을 그대로 API 요청 바디에 담아 전송하고 있었기 때문에, 서버에 위변조된 데이터가 전송이 되어 그대로 결제 금액으로 받아들여 결제가 되는 것이었다.
해결 과정
클라이언트에서 받은 최종 결제 금액을 믿지 않고, 서버쪽에서 최종 결제 금액을 다시 계산해서 산출하는 과정으로 구현을 했다.
3) 상품 리스트 다중 그룹화
문제 상황
장바구니 페이지에서 브랜드별로 상품을 보여주고, 각 브랜드의 배송 정책에 따라 배송비를 계산하여 화면에 표시해야 하는 복잡한 요구사항이 있었다.
- 브랜드별 구분
- 배송단위별 구분
원인 분석
우선 백엔드에서 브랜드별로 그룹화된 DTO 리스트를 전달해주어 기초 구조는 잡혀 있었다.
화면상에서 배송 단위에 따라 셀을 병합하고 배송비를 따로 계산하기에는 배송정책으로 나눠지지 않은 리스트 형태였다.
그리고 배송비는 고정이 아니라 수량 조절에 따라 실시간으로 변하는 상태가 있어야 했고 재 계산하는 로직이 필요했다.
해결 과정
브랜드별로 1차 그룹화를 백엔드에서 CartBrandDTO를 설계해서 브랜드의 정보, 배송비 정책, 해당 브랜드의 상품 목록을 묶어 프론트엔드에 전달했다.
전달받은 상품 목록을 렌더링 하기 전에 묶음/개별을 기준으로 다시 한번 그룹화 하는 로직을 구현했다.
reduce를 사용해 동일한 배송 정책을 가진 상품들을 배열로 묶어, 테이블 구성 시 rowSpan을 적용하여 셀을 병합했다.
4. 회고 및 개선 계획
회고
-
보안 의식
클라이언트의 데이터는 언제든 위변조될 수 있다는 사실을 체감했고, 시스템 안정성을 위해 서버에서 재검증 로직이 필수라는 원칙이 생겼다. -
실무적 변화
이미 완성된 구조에 복잡한 배송 정책이 추가되는 상황을 겪어서 고생했지만, 실무와 유사한 요구사항 변경을 경험한 것 같아서 긍정적으로 생각한다. -
개발 방향성
단순히 기능을 구현하기보다, 어떻게 하면 더 안전하고, 덜 복잡하고, 유지보수하기 편한 구조를 만들 수 있을까에 대한 고민이 생겼다.
개선 계획
- 조회 성능 최적화 : 전문가 목록 조회 시 발생하는 카디널리티 곱 문제를 해결하기 위해, 서브쿼리 활용이나 데이터 역정규화를 선택하여 데이터 중복을 차단
- 결제 검증 프로세스 : 클라이언트 전달 금액과 서버 재계산 금액이 일치하지 않을 때, 결제를 중단하고 추가적인 예외 처리 로직을 구현하여 보안 강화
- 동적 견적 시스템 : 프론트엔드에 하드코딩된 대화형 견적 질문들을 DB에 관리하여 사용자의 선택값에 따라 유연하게 다음 선택지가 제공되는 동적 시스템으로 전환
