파트너 포탈 헤더에 파트너 정보 칩 추가

파트너 포탈 헤더에 파트너명, 코드, 레벨 세 가지 정보를 칩 형태로 표시하는 기능을 추가했다. 파일은 뷰/스타일 3개. 숫자만 보면 작아 보이지만 쿼리 레벨부터 손댔기 때문에 실제 작업량은 그것보다 훨씬 컸음.

왜 헤더에 파트너 정보가 필요했나

파트너 포탈은 외부 파트너사가 직접 접속해서 자신의 데이터를 조회하는 공간이다. 그런데 기존 헤더에는 로그인한 사용자 이름 정도만 표시됐고, 어떤 파트너 계정으로 접속 중인지 한눈에 확인할 방법이 없었음.

이게 사소해 보일 수 있는데, 실제로는 꽤 불편한 상황을 만든다. 파트너 담당자가 여러 계정을 관리하는 경우 지금 어떤 파트너 컨텍스트에 있는지 매번 설정 페이지를 뒤져야 했고, CS 문의가 들어왔을 때 내부 운영팀도 "이 사람이 어떤 레벨의 파트너인지" 바로 파악하기 어려웠다. 작은 UX 문제처럼 보이지만 반복되면 신뢰 문제로 번진다.

그래서 헤더 고정 영역에 파트너명 / 파트너코드 / 레벨 세 가지를 칩으로 박기로 했다. 단순 텍스트가 아니라 칩 형태로 배지처럼 표시하면 시각적으로 구분이 명확하고, 나중에 레벨별 색상 구분 같은 확장도 자연스럽게 붙일 수 있음.

구현: 쿼리부터 화면까지

UI 변경인데 왜 쿼리 레벨부터 건드렸냐면, 기존 세션 정보에 파트너코드와 레벨이 없었기 때문이다. 파트너명은 있었는데 코드는 로그인 이후 세션에 올라오지 않고 있었고, 레벨은 아예 화면에 노출된 적이 없는 필드였음.

그래서 흐름을 다시 짰다.

로그인 시 세션 적재 쿼리
  └─ partner_name, partner_code, partner_level 추가 SELECT
         └─ HttpSession 에 set
                └─ 헤더 JSP 에서 EL 로 꺼내 렌더링

세션에 한 번 올려두면 매 요청마다 DB를 치지 않아도 된다. 헤더는 모든 페이지에서 렌더링되기 때문에 매번 쿼리를 날리는 구조는 부담이 컸을 것임. 대신 세션 값이 stale해질 수 있는 케이스(파트너 정보가 관리자에 의해 변경되는 경우)는 별도로 처리가 필요한 상황인데, 현재 운영 패턴상 실시간 갱신보다 세션 재발급(재로그인) 쪽이 현실적이라 판단했다.

프론트는 JSP + EL 조합으로 단순하게 뺐음. AJAX로 따로 때리는 구조는 고려했다가 제외했다. 헤더 칩이 비동기로 늦게 뜨는 게 오히려 어색하고, 데이터 자체가 세션에 이미 있으니 굳이 추가 왕복을 만들 이유가 없었음.

<span class="partner-chip partner-chip--code">${sessionScope.partnerCode}</span>
<span class="partner-chip partner-chip--level">${sessionScope.partnerLevel}</span>

스타일은 기존 디자인 시스템 변수를 최대한 재활용했고, 레벨 값에 따라 클래스를 다르게 붙일 수 있도록 여지를 남겼다.

권한 인터셉터 쪽도 확인이 필요했다. 포탈 내 모든 요청에는 파트너 권한 체크가 걸려 있는데, 새로 세션에 추가한 필드가 인터셉터 로직에서 예상치 못한 방식으로 읽히거나 누락되면 인증 오류로 빠질 수 있기 때문. 실제로 테스트 과정에서 세션 키 이름이 기존 다른 필드와 충돌할 뻔한 케이스가 있었음. 미리 잡아서 다행이었다.

이 작업에서 다시 확인한 것들

파트너 포탈 같은 외부 접점 화면은 숫자 하나, 레이블 하나가 신뢰와 직결된다. 내부 어드민은 "대충 맞는 것 같으면 넘어가자"는 판단이 가능한 경우도 있지만, 파트너가 자기 데이터를 들여다보는 화면에서 파트너코드가 틀리거나 레벨 표기가 이상하면 바로 CS로 연결됨. 금융/결제 도메인에서 일하면서 계속 체감하는 부분인데, 정합성은 나중에 고치는 것보다 처음부터 맞추는 게 총 비용이 압도적으로 낮다.

이번 작업에서도 구현하면서 체크한 포인트들을 정리하면 이렇다.

NULL/빈 값 방어를 먼저 설계하고 코딩하는 습관이 이 도메인에서 특히 중요함. 개발 환경 데이터는 항상 깔끔한데 운영에 올라가면 10년 전 레거시 데이터에서 예상 못 한 케이스가 튀어나온다. "이 필드는 당연히 있겠지"라는 가정이 제일 위험함.

커밋은 뷰 구조 변경, 세션 필드 추가, 스타일 분리 이렇게 세 단위로 쪼갰다. 하나의 커밋에 몰아넣으면 나중에 문제가 생겼을 때 어느 변경이 원인인지 추적하기가 너무 힘들어짐. 특히 세션 관련 변경은 영향 범위가 넓어서 단독 커밋으로 분리하는 게 낫다고 판단했음. 메시지도 "헤더에 칩 추가"보다 "파트너 세션 필드 확장으로 헤더 정보 표시 가능하게" 쪽으로 썼다. 석 달 뒤에 git log 볼 미래의 나를 위해서.