매출 요약 폰트 조정과 총합 메뉴 비활성화 처리

revenue_summary 폰트 조정은 처음엔 "그냥 숫자 크기 바꾸는 거 아니야?"처럼 보인다. 근데 막상 건드려보면 이게 단순 스타일 수정이 아니라는 걸 금방 알게 됨. 매출 요약 화면은 보통 여러 숫자를 한 뷰에 때려박는 구조라서, 하나의 폰트 사이즈가 바뀌면 그 옆 수치들과 시각적 위계가 달라지고, 컨테이너 높이가 밀리고, 반응형이 깨지는 경우까지 생긴다.

이번 작업은 SQL 파일 1개, 뷰/스타일 파일 1개 총 두 파일만 건드렸음. 변경 범위 자체는 작지만 두 파일이 건드리는 레이어가 완전히 달라서 따로 생각해야 했다.

revenue_summary 폰트 조정

매출 요약 같은 KPI 화면에서 폰트 사이즈는 단순 미관이 아니라 정보 위계의 문제임. 금액, 건수, 전환율처럼 성격이 다른 숫자들이 한 뷰에 공존할 때, 타이포그래피가 "이게 더 중요한 숫자야"라는 시그널을 주지 않으면 보는 사람이 매번 레이블을 읽어야 하는 인지 비용이 생긴다.

뷰 파일에서 font-size 값을 바꿀 때 신경 쓴 부분:

/* 변경 전 - 고정 px 값 */
.revenue-summary .total-amount {
  font-size: 24px;
}

/* 변경 후 - 상위 컨테이너 기준 상대 단위 */
.revenue-summary .total-amount {
  font-size: 1.5rem;
}

고정 px로 잡아두면 컨테이너 크기나 디바이스 배율이 달라질 때 레이아웃이 의도대로 안 나오는 경우가 있어서, 이 기회에 단위 정리도 같이 했음. 스타일 변경 후에는 같은 케이스를 1280, 1440, 1920 기준으로 확인하고 숫자가 잘려 보이는 구간 없는지 체크했다.

total-summary 메뉴 비활성화 SQL

메뉴 표시 여부를 코드에서 if 분기로 처리하지 않고 SQL로 관리하는 이유가 있다. 코드 레벨 분기는 배포가 필요하고, 잘못 건드리면 다른 메뉴에도 영향이 튈 수 있음. 반면 메뉴 활성/비활성을 DB에 플래그로 갖고 있으면 특정 환경이나 조건에 따라 런타임에서 제어가 가능하고, 롤백도 SQL 한 줄이면 끝난다.

이번 비활성화 SQL의 패턴은 대략 이런 형태:

-- total-summary 메뉴 비활성화
UPDATE menu_items
SET is_active = 0,
    updated_at = NOW()
WHERE menu_key = 'total-summary'
  AND menu_group = 'revenue';

-- 적용 확인
SELECT menu_key, menu_name, is_active
FROM menu_items
WHERE menu_group = 'revenue';

실제 파일은 이보다 조건이 더 있었지만 패턴 자체는 이렇다. 운영 적용 전에는 항상 개발 환경에서 먼저 돌려보고, SELECT로 영향 범위를 먼저 확인한 다음 UPDATE를 실행했음. 이런 DDL/DML 작업은 트랜잭션으로 묶어두면 실수했을 때 ROLLBACK이 가능해서 좋다.

총합 메뉴처럼 "지금 당장은 꺼두되 나중에 켤 수 있어야 하는" 케이스에는 DB 플래그 방식이 가장 낫다. 삭제가 아니라 비활성화라는 점이 포인트임.

작업 후기

금융/결제 도메인에서 일하다 보면 "숫자 하나"의 무게가 남다르다는 걸 반복해서 체감함. 매출 요약 화면은 특히 의사결정에 직접 붙는 뷰라서, 숫자가 0.1%라도 이상하면 "데이터 잘못된 거 아니야?"라는 신뢰 문제로 바로 이어진다. 이런 화면일수록 스타일 변경 전후 스크린샷 찍어두고, 같은 날짜 기준으로 숫자 cross-check 하는 습관이 필요하다.

작업 후기로 하나 더 남기자면, 이번 변경이 chore 커밋이라는 점. 사용자에게 직접 보이는 변화는 없지만, 이런 작업을 꾸준히 쌓지 않으면 나중에 한꺼번에 터진다. 폰트 상대 단위 정리 안 해두면 반응형 대응할 때마다 다시 손봐야 하고, 메뉴 제어 방식 안 통일해두면 나중에 누군가 비슷한 케이스에서 코드 레벨 분기를 또 만들게 됨.

당장 눈에 띄는 효과가 없어도 이런 작업을 챙기는 팀과 그냥 넘기는 팀의 차이는 6개월 뒤 레거시 청구서로 돌아온다. 그래서 기능 커밋이 아닌 것도 논리 단위로 쪼개서 커밋 메시지에 "왜" 바꿨는지를 적어두려고 하는 중이다. 나중에 git blame 찍어봤을 때 맥락이 있냐 없냐의 차이가 크다.