파트너 포털에 SUPPLIER·RESELLER 역할별 디자인 시스템 분리

파트너 포털에 SUPPLIER / RESELLER 두 가지 역할 전용 디자인 시스템을 새로 추가했다.

왜 role 별로 디자인을 나눠야 했나

파트너 포털은 단일 UI로 운영하기엔 사용자 맥락이 너무 달랐다. SUPPLIER는 상품/재고를 공급하는 쪽, RESELLER는 그걸 가져다 재판매하는 쪽이라 접근하는 메뉴 구조, 강조해야 할 정보 계층, 색상 톤까지 분리할 필요가 있었다.

처음에는 "어차피 비슷한 포털인데 CSS 클래스 몇 개 추가하면 되지 않냐"는 의견도 팀 내에 있었다. 하지만 실제로 두 역할의 사이드바 메뉴를 펼쳐놓고 보면 겹치는 항목보다 다른 항목이 많았고, 하나의 스타일시트 안에서 분기 처리를 계속 쌓다 보면 나중에 유지보수 지옥이 된다는 걸 이전 프로젝트에서 이미 경험했다. 그래서 이번엔 역할별 SCSS 파일을 아예 분리하는 방향으로 결정했다.

작업 내용

변경된 파일을 기준으로 정리하면 이렇다.

SCSS 구조는 pages/ 디렉터리 아래에 역할별 partial로 분리했다. 공통 변수나 믹스인은 건드리지 않고 각 파일이 독립적으로 토큰을 선언하는 방식을 택했다.

// _partner-portal-supplier.scss
$supplier-primary: #2c5f8a;
$supplier-sidebar-bg: #f0f4f8;

.portal-supplier {
  .sidebar-nav {
    background-color: $supplier-sidebar-bg;

    .nav-item.active {
      border-left: 3px solid $supplier-primary;
      color: $supplier-primary;
    }
  }
}

// _partner-portal-reseller.scss
$reseller-primary: #4a7c59;
$reseller-sidebar-bg: #f2f6f2;

.portal-reseller {
  .sidebar-nav {
    background-color: $reseller-sidebar-bg;

    .nav-item.active {
      border-left: 3px solid $reseller-primary;
      color: $reseller-primary;
    }
  }
}

JSP 사이드바 쪽에서는 role 값을 체크해서 루트 wrapper 클래스를 다르게 내려주는 방식으로 처리했다. 마크업 분기를 최소화하고 CSS 클래스 하나로 테마 전환이 되도록 설계한 게 포인트였다.

작업하면서 신경 쓴 것들

• 토큰 네이밍 일관성: supplier-*, reseller-* prefix를 엄격하게 유지했다. 나중에 다른 팀원이 파일을 열었을 때 이게 어느 역할의 스타일인지 바로 파악할 수 있어야 하니까.
• CSS 빌드 결과물 포함: apple.css도 같이 커밋한 건 의도적이다. 빌드 환경이 로컬마다 달라서 컴파일된 결과물을 소스 추적 대상에 포함시켜야 했던 프로젝트 특성상 어쩔 수 없는 선택이었음. 이상적으로는 CI에서 빌드 후 배포하는 구조가 맞지만, 프로젝트 셋업이 그렇지 않은 경우 결과물 커밋도 팀 컨벤션이 된다.
• 사이드바 JSP 수정 최소화: 마크업을 크게 건드리면 다른 기능 브랜치와 충돌이 생기기 쉽다. 최대한 클래스 추가 수준에서 처리하고 구조 변경은 배제했다.

회고

디자인 시스템을 추가하는 작업은 눈에 잘 띄지 않는다. 기능 개발처럼 "이게 됩니다" 하고 바로 보여줄 수 있는 게 아니라서, 팀 내에서 우선순위 조율할 때 설득이 필요한 작업이기도 하다. 그런데 이 기반이 없으면 이후 컴포넌트 작업마다 "이 스타일 어디 있죠?" / "이거 supplier 것 맞아요?" 같은 질문이 계속 반복된다. 결국 팀 속도를 잡아먹는 건 이런 정리 안 된 부분들이다.

JSP 환경에서 SCSS partial을 역할별로 나눠 관리하는 패턴이 정착되면, 나중에 새로운 role이 추가되더라도 _partner-portal-{role}.scss 하나 만들고 import 한 줄 추가하는 것으로 확장할 수 있다. 그 확장성을 지금 작업에서 미리 열어둔 셈이다.

다음엔 각 partial 안의 컴포넌트들을 좀 더 세분화해서 버튼, 뱃지, 테이블 등의 role별 variant도 체계화할 계획이 있다.