Breeze Commerce를 빠르게 이해할 때 먼저 봐야 했던 것들
Broadleaf를 과제로 먼저 살펴본 뒤, 실제 적응 단계에서는 Breeze Commerce가 Broadleaf 위에서 무엇을 그대로 쓰고 무엇을 확장하는지를 빨리 파악해야 했습니다. 이 시점부터는 프레임워크 일반론보다 Broadleaf가 이미 제공하는 기본 도메인과 Breeze의 제품 특화 구조 사이의 경계를 보는 일이 더 중요해졌습니다.
실제로 적응 범위도 넓었습니다. 로그인부터 상품 검색, 주문, 결제, 배송, 물류 연동, O2O까지 서비스 흐름이 이어져 있었기 때문에, 특정 화면이나 API만 이해해서는 전체를 따라잡기 어려웠습니다. 그래서 Breeze를 읽을 때도 한 기능이 아니라 커머스 흐름 전체 안에서 어디에 놓이는지를 먼저 보게 됐습니다.
무엇을 먼저 봤는가
실제 적응 과정에서 도움이 된 건 화면보다 데이터와 운영 구조였습니다. 아래 세 가지를 먼저 보면 전체 그림이 빨리 잡혔습니다.
- 상품을 어떤 축으로 들고 있는가
- 재고를 어디서 관리하고 어떤 타이밍에 차감하는가
- fulfillment location과 제품 특화 정책이 주문 흐름에서 어떤 역할을 하는가
여기에 관리자 URL 패턴과 엔티티 구조를 보면, 운영 화면과 도메인 모델이 어떻게 연결되는지도 함께 보였습니다.
즉 Breeze를 이해하는 일은 “화면을 몇 개 클릭해본다”보다 “무엇이 핵심 데이터이고, 그 데이터가 어떤 흐름을 타는가”를 먼저 잡는 일에 가까웠습니다.
데이터 구조가 왜 중요했는가
SKU, SKU inventory, fulfillment location 관련 대용량 SQL 덤프는 Broadleaf 기본 도메인과 Breeze 확장이 어디서 갈라지는지를 보여주는 강한 증거입니다. 데이터를 그대로 보는 것이 목적은 아니었지만, SKU와 inventory는 Broadleaf의 중심 도메인으로, fulfillment location 같은 구조는 Breeze 확장 맥락으로 읽을 수 있었고, 그 경계를 보면 서비스의 중심 모델과 확장 지점이 무엇인지 훨씬 빠르게 읽을 수 있었습니다.
여기에 검색 축도 같이 봐야 했습니다. Broadleaf는 공홈에서도 Product Browse & Search를 기본 플랫폼 역량으로 설명하고 있고, 실제 과제 문서에도 SolrStarter와 standalone Solr 구성이 등장합니다. 당시에도 카탈로그 인덱싱을 맞추면서 유의어, 유사어 사전을 등록하고 검색 품질을 조정했던 기억이 남아 있습니다. 즉 Search는 부가 기능이 아니라 Catalog와 함께 봐야 하는 기본 축이었습니다.
Broadleaf core를 그대로 쓰는 부분과 Breeze가 확장해서 얹은 부분을 구분해보는 것도 중요했습니다. Broadleaf는 검색하면 바로 나올 만큼 큰 오픈소스 커머스 플랫폼이고, 유료 라이선스 버전도 존재합니다. 그래서 프레임워크를 “다 안다”는 상태보다, 이미 제공되는 기본 도메인을 어디까지 활용하고 어느 지점부터 제품 특화 구조가 시작되는지를 파악하는 편이 실제 실무에 더 도움이 됐습니다.
특히 글로벌 기준으로 설계된 플랫폼이라 한국 커머스 운영 방식과는 바로 맞지 않는 부분이 있었습니다. 그래서 Breeze를 이해한다는 건 Broadleaf 위에 한국형 운영 요구와 정책이 어디서부터 얹히는지를 이해하는 일이기도 했습니다.
이 구분이 중요한 이유는 문제의 책임 경계를 나누는 데도 도움이 되기 때문입니다. 공통 프레임워크 특성인지, 제품 특화 로직 때문인지 구분할 수 있어야 어디를 먼저 봐야 할지 결정하기 쉬워집니다.
이런 과제가 실제로 있었다
입사 후에는 단순히 구조를 이해하는 데서 끝나는 게 아니라, 실제로 플랫폼을 어떻게 개선할 것인가에 대한 과제가 계속 따라왔습니다. 예를 들어 Breeze 플랫폼 고도화 맥락에서는 Framework 업그레이드, DB 고도화, Cache 고도화, 주문 안정화, 주문/빌링 성능 개선, API 서버 마이크로서비스화, Solr 및 재고 차감 성능 개선 같은 항목들이 실제 과제로 놓여 있었습니다.
이런 과제가 있었다는 사실 자체가 중요했습니다. 단순히 “어떤 테이블이 있는가”를 아는 수준이 아니라, “이 구조에서 실제로 어디가 아프고 왜 이 부분을 개선하려고 하는가”를 같이 봐야 했기 때문입니다. 특히 주문 안정화 설명에서 재고 row 집중, read only DB, queue, cache/no-sql 전략이 등장하는 부분은 이후 주문/재고 시리즈의 전제가 됩니다.
빠르게 적응할 때 유효했던 순서
지금 기준으로 다시 정리하면, Breeze를 빠르게 이해할 때 유효했던 순서는 이렇습니다.
- Broadleaf가 제공하는 기본 커머스 구조를 먼저 파악한다.
- 상품, 주문, 재고처럼 이미 제공되는 핵심 도메인을 먼저 본다.
- 그 위에 Breeze가 확장한 fulfillment, 관리자, 운영 지점을 구분해 본다.
- 운영 계획 문서를 읽고 병목과 개선 포인트를 함께 본다.
이 순서를 거치면 “Breeze가 Broadleaf 위에 어떤 식으로 얹혀 있는가”가 훨씬 빨리 보입니다.
결국 적응 초기에 가장 중요했던 건 모든 세부사항을 아는 것이 아니라, 구조를 잃지 않는 것이었습니다. 상품, 재고, fulfillment, 관리자 구조, 운영 계획이라는 다섯 축만 유지해도 이후 세부 기능은 훨씬 빨리 따라잡을 수 있었습니다.
다음 글에서는 이 구조 위에서 실제로 어떤 지점들이 반복적인 커스터마이징 포인트로 보였는지 정리합니다: Broadleaf/Breeze 커스터마이징 포인트 정리