개발 slecs

자정에 쇼케이스 띄우고 대시보드 버그 잡다

목차

자정을 넘기면서도 손이 멈추질 않았다. 발단은 단순했다. 스튜디오의 라이브 프로덕트 쇼케이스 페이지를 드디어 퍼블릭으로 올리는 날이었는데, 막상 띄우고 나니 어드민 대시보드 쪽에서 "마지막 발행 -381분 전"이라는 황당한 숫자가 눈에 걸렸다. 그냥 넘길 수가 없었다.

두 개의 흐름이 동시에 돌아갔다

이 한 시간은 크게 두 축이 얽혀 있었다.

첫 번째 축 — 포트폴리오 쇼케이스 출범 및 인프라 연동
새 사이트를 단순히 index.html 올리고 끝내는 게 아니라, 제대로 관리 체계 안에 집어넣는 작업이 한 묶음이었다.

  • 사이트 기본 구조 (index.html, .gitignore) 생성
  • 스탯 수집 스크립트에 신규 도메인 PV/UV 트래킹 추가
  • 인벤토리 문서(sites-detail.md, 글로벌 CLAUDE 문서)에 등록

인벤토리 등록을 마지막에 하는 팀도 있는데, 우리는 반대다. 문서 없이 운영 들어가면 나중에 "이 사이트 어떻게 관리하던 거야?"가 반복된다. 그래서 출범하는 시점에 문서와 모니터링을 동시에 붙이는 게 루틴이 됐다.

두 번째 축 — 어드민 대시보드 UI 버그 및 위계 정리
쇼케이스 띄우다가 대시보드를 열었더니 문제가 보인 것이다.

음수 시간 버그: 왜 -381분이 나왔나

SitesTable.tsxdashboard-stats.ts를 뜯어보니 마지막 발행 시각을 계산할 때 타임존 오프셋이 이중으로 적용되고 있었다. 서버에서 이미 UTC 기준으로 내려온 값을 클라이언트 쪽 로직이 또 한 번 로컬 오프셋을 빼버리는 구조였다.

// 기존 흐름 (문제)
서버 응답: UTC timestamp
클라이언트: new Date(ts)  toLocaleString()  다시 diff 계산 (오프셋 이중 차감)

// 수정 후
서버에서 이미 상대 시간()으로 계산해 내려줌  클라이언트는 표시만

결과적으로 dashboard-stats.ts에서 상대 시간을 서버 사이드에서 계산하도록 책임을 옮겼고, SitesTable 컴포넌트와 page.tsx는 그 값을 받아 렌더링만 하게 정리했다.

사이드바 위계 정리

버그 잡는 김에 사이드바도 손봤다. 1차 메뉴와 2차 메뉴의 글자 크기와 패딩이 거의 같아서, 메뉴가 많아질수록 뎁스 구분이 안 됐다.

항목 수정 전 수정 후
1차 메뉴 폰트 14px 16px
1차 메뉴 패딩 2차와 동일 상하 패딩 추가
시각적 위계 불분명 명확하게 분리

작은 변화지만, 메뉴 10개 넘어가면서부터 체감이 달랐다. 총괄 입장에서 어드민을 직접 쓰는 사람이기도 하니까, 이런 디테일이 매일 쌓이면 피로도로 돌아온다.

자정 작업이 의외로 밀도 높은 이유

솔직히 자정 타임이 좋은 이유가 있다. 슬랙 알림도 없고, 배포 중에 다른 요청이 끼어들지 않는다. 쇼케이스 출범 → 대시보드 이상 발견 → 버그 수정 → 문서 등록까지 맥락을 끊기지 않고 한 흐름으로 밀어붙일 수 있었다. 결과적으로 새 사이트 하나가 모니터링, 문서, 어드민 UI 정비까지 달고 나온 셈이다. 내일 낮에 했다면 중간에 뭔가 끊겼을 거다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.