왜 GS SHOP은 Broadleaf 과제를 냈을까
2019년 11월, GS SHOP 이직을 준비하던 시점에 Broadleaf Commerce 과제를 받았습니다. 제출 기한은 비교적 넉넉했지만, 커머스 도메인이 처음이었던 만큼 가능한 한 빨리 구조를 파악하고 제출해보자는 쪽으로 접근했습니다.
지금 돌아보면 이 과제는 단순히 API나 화면 하나를 만드는 테스트가 아니었습니다. Broadleaf Commerce라는 낯선 오픈소스 커머스 플랫폼을 빠르게 읽고, 로컬에서 실행해보고, Catalog, Customer & Orders, Inventory & Fulfillment, Admin, Product Browse & Search 같은 기본 축이 어디까지 이미 제공되는지 파악하고, 그 위에 필요한 기능을 어떤 방식으로 확장할 수 있는지까지 판단할 수 있는지를 보려는 과제였습니다.
입사 후 보니 실제로 Broadleaf/Breeze 계열 제품을 다뤄야 했기 때문에, 문서 해석 속도와 구조 이해 능력 자체가 곧 실무 적응력과 연결되는 상황이었습니다. 즉 과제는 선발 도구이면서 동시에 실무 예열이었습니다.
당시 제 입장에서도 이 과제는 꽤 명확한 신호였습니다. “새로운 도메인을 얼마나 빨리 따라잡을 수 있는가”, 그리고 “문서와 실행 환경만 보고 구조를 복원할 수 있는가”를 보는 테스트라면, 결국 입사 후에도 같은 방식으로 적응해야 할 가능성이 높다고 봤기 때문입니다.
왜 이런 과제가 필요했을까
제가 내린 해석은 단순합니다.
- 기존 커머스 플랫폼을 처음 보는 사람도 문서를 따라 구조를 복원할 수 있어야 했습니다.
- 실무에서는 새로운 기능 구현보다, 기존 구조를 이해하고 변경 포인트를 찾는 일이 먼저였습니다.
- Broadleaf/Breeze는 Broadleaf의 기본 커머스 도메인과 Breeze의 제품 특화 확장이 얽혀 있어서 단편적인 구현 능력보다 전체 구조 읽기 능력이 중요했습니다.
이 과제의 핵심은 “이 플랫폼을 제대로 이해했는가”에 있었습니다. 실제로 문서에는 Broadleaf 구조, 실행, Solr, Admin Controller, Entity, Permission, i18n Message 확장 구현이 정리되어 있었습니다. Broadleaf가 기본 제공하는 도메인 위에 Breeze 계열 요구사항을 어떤 식으로 얹을 수 있는지 설명하는 흐름이었고, 구현 결과보다 구조 파악 과정이 더 중요했던 이유입니다.
Broadleaf는 글로벌 기준으로 잘 설계된 커머스 플랫폼이었지만, 한국 커머스 운영 방식과는 바로 맞지 않는 부분도 분명히 있었습니다. 그래서 GS/Breeze 쪽에서는 기본 도메인을 처음부터 다시 만드는 것보다, 이미 제공되는 기본 축을 유지한 채 한국형 운영 요구와 정책을 수용하도록 커스터마이징하는 비중이 컸습니다. 이 점 때문에 Broadleaf를 이해하는 것과 Breeze 확장 지점을 읽는 일은 사실상 같은 문제였습니다.
즉 과제를 잘 해낸다는 건 단순히 과제 통과를 뜻하는 게 아니라, 이후 실제 제품 구조를 보고도 비슷한 속도로 적응할 수 있다는 신호에 가까웠습니다.
왜 커머스로 이동했는가
커머스로 이동한 이유도 분명했습니다. 더 큰 트래픽을 직접 다뤄보고 싶었고, GS에서 맡게 된 영역이 Nike 관련 서비스라 실제 트래픽 규모가 매우 컸습니다. 커머스는 처음 다루는 도메인이었지만, 그만큼 새로운 구조와 문제를 배우는 재미가 있을 것 같았고, 그래서 도전해보고 싶었습니다.
무엇보다도 이 도메인에 들어가면 경험의 폭이 넓어질 거라고 봤습니다. 로그인부터 시작해 상품 검색, 주문, 결제, 배송, 물류 연동, O2O까지 커머스 서비스가 실제로 맞닿는 문제를 한 흐름으로 경험할 수 있기 때문입니다. 이전까지 다루던 플랫폼 문제와는 다른 종류의 복합성이 있었고, 그 점이 오히려 매력적이었습니다.
이 과제는 그 출발점이었습니다. Broadleaf를 읽어낼 수 있느냐는 결국, 이후 Breeze 구조와 주문/재고/정산/운영 문제를 얼마나 빨리 따라잡을 수 있느냐와 연결됐습니다.
커머스 플랫폼은 상품, 재고, 주문, 정산, 관리자 기능, 운영 도구가 유기적으로 얽혀 있습니다. 그리고 Broadleaf Commerce는 그 중 상당 부분을 기본 도메인으로 이미 제공합니다. 그래서 “한 기능을 잘 만든다”보다 “기본 구조 위에 어디서부터 제품 특화 확장이 시작되는지 안다”가 훨씬 중요했습니다. Broadleaf 과제는 그 점을 정확히 겨냥하고 있었다고 봅니다.
지금 다시 보면 중요했던 기준
당시를 지금 기준으로 다시 정리하면, 이 과제를 통해 확인하고 싶었던 역량은 다음과 같았다고 봅니다.
- 문서와 데모만으로 전체 구조를 빠르게 그려내는 능력
- 로컬 실행과 로그를 통해 런타임 구조를 파악하는 능력
- 관리자, 도메인, 권한, 메시지 체계처럼 실제 확장 포인트를 찾아내는 능력
- 낯선 프레임워크를 실무 맥락에 연결해서 설명하는 능력
이런 기준으로 보면 Broadleaf Commerce 과제는 “과제”라기보다 “커머스 플랫폼 구조 해석 시험”에 가까웠습니다.
Series 1의 다음 글에서는 이 과제를 실제로 어떤 순서로 분석했는지 정리합니다: Broadleaf Commerce를 어떻게 분석했는가