공급사 포털 브랜드·카테고리 화면 버그 수정

supplier-portal의 my-brands, my-categories 화면에서 버그 여러 개가 겹쳐 있었다. 디자인 품질 저하, 메뉴 활성화 오류, 아이콘 깨짐 - 하나씩 떼어놓으면 사소해 보이지만, 공급사 담당자가 매일 로그인해서 첫 번째로 보는 화면이라 방치하면 신뢰가 조용히 깎인다. 변경 파일은 내부 클래스 2개, SQL 매퍼 2개, 뷰/스타일 2개. 숫자만 보면 작은 패치지만 각 레이어가 실제로 어떻게 얽혀 있었는지 정리해 두려고 쓴다.

버그가 여러 레이어에 걸쳐 있을 때

내부 포털 특성상 화면 하나가 단독으로 존재하지 않는다. SQL 집계 결과가 내부 클래스를 통해 가공되고, 뷰 템플릿이 그 값을 받아 렌더링하면서 스타일이 입혀지고, 프론트 스크립트가 메뉴 활성화 상태를 다시 판단한다. 어느 한 계층에서 엣지 케이스가 빠지면 그 아래 계층은 전부 잘못된 입력으로 돌아간다.

이번에 SQL 매퍼 2개를 수정한 이유가 거기 있다. 기존 쿼리에서 특정 조건이 누락되거나 집계 방식이 의도와 달랐고, 그 결과가 내부 클래스에서 보정 없이 그대로 내려가니까 화면에서 숫자가 틀리거나 특정 케이스에서 빈 결과가 반환됐다. SQL만 고쳐도 화면이 깨진 것처럼 보이던 증상이 절반은 사라졌다.

집계 쿼리에서 자주 빠지는 패턴을 예시로 들면 이런 것들이다:

-- 문제: NULL 값이 SUM에서 0으로 처리되지 않아 집계가 의도와 다름
SELECT brand_id, SUM(item_count) AS total
FROM brand_items
GROUP BY brand_id

-- 수정: COALESCE로 NULL 방어, 필요한 경우 WHERE 조건 명시
SELECT brand_id, SUM(COALESCE(item_count, 0)) AS total
FROM brand_items
WHERE status != 'DELETED'
GROUP BY brand_id

이런 수정은 "틀렸다"기보다 "특정 상태의 데이터가 들어왔을 때 예상과 다르게 동작"하는 케이스다. 정상 데이터로만 테스트했을 때는 안 보이다가 실제 운영 데이터에서 드러나는 전형적인 엣지 케이스.

내부 클래스 2개는 그 SQL 결과를 받아서 도메인 객체로 변환하는 레이어였다. 쿼리 결과가 null이거나 비어 있을 때 처리 분기가 빠져 있어서 런타임에 NPE 또는 잘못된 상태값이 뷰에 넘어갔다. 이 부분을 방어적으로 수정했다.

화면 레이어 버그 - 메뉴 활성화와 아이콘

SQL/클래스 레이어와 별개로 뷰·스타일·프론트 스크립트에서 따로 버그가 있었다.

메뉴 활성화 오류는 SPA가 아닌 서버사이드 렌더링 방식에서 자주 나타난다. 현재 URL과 메뉴 항목을 매칭하는 로직이 경로 패턴을 정확히 커버하지 못하면 my-brands 화면에 있어도 다른 메뉴가 활성화되거나 아무것도 활성화되지 않는다. 공급사 입장에서는 "내가 지금 어디 있지?" 하는 맥락을 잃는 UX 버그다.

아이콘 깨짐은 CSS 클래스 오타, 아이콘 폰트 로드 순서, 또는 특정 브라우저에서 font-face 렌더링 타이밍 문제로 발생하는 경우가 많다. 이번 케이스에서는 CSS 클래스 참조가 잘못되어 있었고 해당 스타일 파일을 수정해서 해결했다.

레이어별로 어떤 파일이 어떤 역할을 했는지 정리하면:

버그 수정 방식 - 증상이 아니라 원인

단순히 화면에서 이상한 부분만 틀어막는 방식으로는 같은 버그가 다른 경로로 반드시 돌아온다. 이번 작업에서도 my-brands와 my-categories가 비슷한 구조로 되어 있어서 한쪽에서 발견된 패턴을 다른 쪽에서도 확인하고 함께 수정했다.

수정 전에 챙기는 것들:

• 같은 SQL 패턴 또는 같은 내부 클래스를 참조하는 다른 화면이 있는지 검색
• 수정이 기존 정상 케이스를 건드리지 않는지 - 특히 집계 쿼리는 WHERE 조건 하나가 전체 숫자를 바꿔버린다
• 관련 화면의 숫자와 cross-check. 합산이 맞아야 하는 지점이 있다면 직접 비교

검증은 수정 후 버그 재현 시나리오를 그대로 다시 실행해서 정상 동작을 눈으로 확인했고, 숫자가 관련된 부분은 인접 화면과 값을 비교했다. 테스트 코드가 없는 레거시 영역일수록 수작업 검증의 기준을 명확히 잡아놓지 않으면 "됐겠지"로 넘어가기 쉽다.

사내 서비스라고 해서 기준을 낮게 잡을 이유가 없다. 공급사 포털처럼 실제 데이터를 다루는 화면은 숫자 하나가 틀리면 담당자가 잘못된 판단을 내리고, 그게 신뢰 문제로 이어진다. 특히 브랜드/카테고리 관리는 상품 노출 범위와 직결되는 경우가 많아서 더 그렇다.

커밋은 논리적으로 독립된 단위로 쪼개는 습관을 유지 중이다. SQL 수정, 클래스 수정, 뷰 수정을 한 커밋에 뭉쳐버리면 나중에 어느 변경에서 회귀가 생겼는지 추적하기 어렵다. 메시지도 "CSS 클래스 수정"보다 "my-brands 아이콘 깨짐 - 잘못된 CSS 클래스 참조 수정"처럼 맥락을 남겨두면 3개월 뒤 git blame 할 때 본인이 고맙다.