Broadleaf/Breeze 커스터마이징 포인트 정리
커머스 플랫폼에 적응하기 시작한 뒤에는 단순히 구조를 이해하는 것보다, Broadleaf가 기본적으로 제공하는 영역과 Breeze가 실제로 확장한 영역을 빨리 구분해야 했습니다. Broadleaf/Breeze를 보면서 반복적으로 느낀 건, 커스터마이징 포인트가 생각보다 일관된 축으로 나타난다는 점이었습니다.
무엇을 커스터마이징 포인트로 봤는가
Broadleaf Commerce 과제 문서를 다시 보면 Admin Controller, Entity, Permission, MessageSource 확장이 이미 한 세트처럼 묶여 등장합니다. Broadleaf가 상품/주문/재고/관리자 같은 기본 도메인을 제공하고, 실무에서는 그 위에 제품 특화 구조를 얹는 방식이었기 때문에 실제 적응 단계에서도 비슷했습니다.
여기서 중요한 점은 Broadleaf가 글로벌 기준의 플랫폼이라는 것입니다. 기본 축은 잘 갖춰져 있었지만 한국 커머스 운영 방식과 바로 맞지 않는 부분이 있었고, 그래서 실제 제품에서는 Catalog, Customer & Orders, Inventory & Fulfillment, Admin, Search 축 각각에 한국형 요구를 수용하는 커스터마이징이 많이 들어갔습니다. Breeze를 읽는다는 건 결국 그 차이를 읽는 일이기도 했습니다.
- 화면을 하나 추가하더라도 결국 admin 쪽 section과 controller를 열어야 했고
- 도메인 모델을 건드리면 entity와 persistence layer가 따라왔고
- 운영 가능한 기능으로 만들려면 권한과 로그, 배치, 외부 연동까지 함께 봐야 했습니다
즉 커스터마이징 포인트는 단순히 코드를 어디에 추가하느냐의 문제가 아니었습니다. 기존 구조에 맞게 어떻게 붙이고, 운영 가능한 상태로 만들고, 다른 모듈과 충돌 없이 확장하느냐가 더 중요했습니다.
처음 커머스 플랫폼을 다룰 때 흔히 빠지는 오해는 “기능이 추가되면 끝”이라고 보는 것입니다. 실제로는 기능이 관리자 UI에 보이고, 권한이 연결되고, 로그가 남고, 운영자가 다룰 수 있는 상태가 되어야 비로소 실무 기능이 됩니다.
반복적으로 나타난 네 가지 지점
1. Admin 확장
관리자 기능을 붙일 때는 보통 섹션, 컨트롤러, 화면 접근 구조를 먼저 봐야 했습니다. 관리자 화면은 실제 운영자가 쓰는 기능이기 때문에, 단순한 UI 추가보다 권한과 화면 노출까지 세트로 봐야 했습니다.
2. 도메인 확장
Entity, DAO, Query, 연관 관계는 거의 항상 같이 움직였습니다. Broadleaf가 기본적으로 가진 상품/주문/재고 모델 위에 제품 특화 구조가 얹히는 지점은 결국 도메인 모델이 바뀌는 지점이기도 했습니다.
그래서 커스터마이징은 화면 변경보다 모델 변경이 먼저인 경우가 많았습니다. 화면은 모델의 결과일 뿐이고, 실제 제약과 정책은 대부분 도메인 구조 안에 숨어 있기 때문입니다.
3. 권한과 운영 가능성
기능이 동작하는 것과 운영 가능한 것은 다릅니다. 권한이 붙어야 하고, 로그가 남아야 하고, 필요하면 배치나 운영 도구와도 연결돼야 했습니다. 예를 들어 어드민 중복 접속을 제어하거나, 보안과 운영 편의 때문에 Redis 기반으로 세션 상태를 관리하고, 문제 상황에서는 런타임 중 로그 레벨을 조정해 진단 강도를 높이는 식의 장치가 실제로 필요했습니다.
4. 외부 연동
실무에서는 내부 구조만 예쁘게 맞춘다고 끝나지 않았습니다. 외부 연동, 인수인계 문서, 테스트 흔적을 보면 실제로는 운영 시스템과 연결되는 경계가 커스터마이징의 핵심인 경우가 많았습니다.
지금 다시 보면 중요한 관점
Broadleaf/Breeze를 다룰 때 유효했던 질문은 다음과 같습니다.
- 이 기능은 admin을 어디서 열어야 하는가
- 데이터 모델은 어느 레이어에 얹어야 하는가
- 권한과 로그는 같이 설계되었는가
- 운영자가 실제로 다룰 수 있는 형태인가
- 외부 연동과 테스트까지 고려되어 있는가
이 관점은 이후 주문 안정화, 운영 로그, 세션 관리, 배치 스케줄러 같은 주제로 자연스럽게 이어집니다.
돌아보면 Broadleaf/Breeze 커스터마이징 포인트를 읽어내는 능력은 이후 다른 문제를 푸는 기본기가 됐습니다. 주문 안정화도, 운영 도구화도, 대량 이벤트 대응도 결국은 기존 구조 위에 어떤 식으로 안전하게 개입할 것인가의 문제였기 때문입니다.
Series 1은 여기서 끝나고, 다음 시리즈에서는 재고가 중심이 되는 주문 안정화와 성능 문제로 넘어갑니다: 주문 안정화를 위해 재고 처리 구조를 어떻게 봤는가