Breeze Commerce의 상품·재고·운영 구조 파악

Broadleaf를 먼저 살펴본 뒤에는 Breeze Commerce가 그 위에 어떤 기능을 확장했는지 확인했습니다. 로그인부터 상품 검색, 주문·결제, 배송과 물류, O2O까지 이어져 있어 특정 화면 하나만으로 전체 구조를 이해하기는 어려웠습니다.

당시에는 상품과 재고, 출고 거점의 관계를 먼저 보고 관리자와 주문 처리 흐름을 연결해 가는 방식이 도움이 됐습니다.

상품과 재고의 관계

상품을 판매하는 단위인 SKU와 재고, 출고 거점의 연결을 살펴봤습니다. 같은 상품이어도 어느 위치의 재고를 사용할 수 있는지에 따라 주문 처리와 매장 수령 방식이 달라질 수 있었습니다.

SQL 자료에서 SKU와 재고, 출고 거점이 어떻게 연결되어 있는지 확인했습니다. 테이블 이름만 익히기보다 주문이 어느 위치의 재고를 사용하는지 따라가며 읽었습니다.

기본 기능과 제품별 확장

Broadleaf가 제공하는 기본 도메인과 Breeze에서 확장한 부분을 구분해야 했습니다. 문제를 조사하거나 코드를 바꿀 때 공통 프레임워크의 처리인지 제품별 정책인지에 따라 확인할 코드가 달랐기 때문입니다.

관리자 화면의 URL과 엔티티 구조도 함께 봤습니다. 화면에서 수정한 값이 어떤 도메인에 저장되고, 주문이나 검색 쪽에서 어떻게 사용되는지 따라가는 데 도움이 됐습니다.

카탈로그와 검색

상품의 저장 구조 외에 검색에 반영되는 과정도 살펴봤습니다. 당시 자료에는 Solr 구성과 카탈로그 인덱싱 작업이 남아 있었고, 유의어·유사어 사전을 등록해 검색을 조정했던 경험도 있었습니다.

상품 데이터가 존재하는 것과 사용자가 검색해서 찾을 수 있는 것은 별도로 확인해야 했습니다. 검색 결과가 다르면 카탈로그 데이터와 인덱스 반영, 검색 조건을 함께 봐야 했습니다.

운영 자료를 함께 본 이유

고도화 계획에는 DB와 캐시, 주문·결제 성능, API 분리, 재고 차감 등의 작업이 있었습니다. 구조를 파악한 뒤에는 이런 항목이 어느 부분의 문제를 해결하려던 것인지 연결해서 봤습니다.

재고 행에 요청이 몰리는 문제나 큐·캐시를 이용한 처리 방안도 이 맥락에 있었습니다. 자료에 개선안이 있다는 사실과 실제 적용을 마쳤다는 것은 구분해야 하지만, 당시 팀이 어려워하던 부분을 이해하는 데는 도움이 됐습니다.

이 구조를 파악한 뒤에는 주문 안정화를 위한 재고 처리를 더 살펴봤습니다.