에포크 상수 오류로 깨진 시간 표시 수정

시간 계산의 기준점이 되는 epoch constants가 구 기준년도에 맞춰져 있었다. 2026년 환경으로 마이그레이션하면서 이 문제를 일괄 정리했다.

문제: 하드코딩된 시간 상수의 함정

seconds 라이브러리의 epoch constants들이 이전 연도 기준으로 정의되어 있었다. 이런 시간 계산 오류는 단순한 숫자 틀림이 아니라, 타이머, 카운다운, 만료 시간 표시 같은 사용자 노출 영역에 직결된다. 특히 실시간으로 변하는 시간을 UI에 표시하는 LiveTicker나 청구 작성 인터페이스(ClaimComposer)처럼 시간이 중요한 컴포넌트에서는 계산 오류가 즉시 눈에 띈다.

이런 오류는 보통 두 가지 이유로 생긴다. 하나는 시간 관련 상수를 어딘가 고정값으로 박아두고, 연도가 바뀌어도 신경 쓰지 않는 것. 또 하나는 개발 초기에 특정 연도를 가정하고 코딩했는데, 환경 변경을 반영하지 못하는 경우다. 둘 다 장기적으로 유지보수 부담이 된다.

수정 내용: 상수 갱신과 UI 개편의 동시 진행

이 커밋에서 눈여겨볼 점은 단순 상수 수정이 아니라, 버그 고정과 visual overhaul을 한 번에 처리했다는 것. 보통이라면 분리하기 쉬운 작업이지만, 시간 표시 오류가 여러 컴포넌트에 퍼져 있고, 각각의 UI도 다시 손을 볼 필요가 있었다면, 함께 처리하는 게 맞다. 오류를 고치면서 그 과정에서 "어? 이 컴포넌트의 스타일이 좀 이상한데" 하고 발견되는 것들을 바로 개선하는 게 현실이기도 하고.

설계: 시간 상수를 어떻게 관리할 것인가

epoch constants 같은 값들은 여러 관리 전략이 있다:

• 하드코딩: 가장 간단하지만, 연도 변경 때마다 코드를 수정해야 함
• 환경 변수: 배포 시마다 설정할 수 있지만, 로컬 개발과 실제 운영의 일관성이 깨질 수 있음
• 설정 파일/DB: 가장 유연하지만, 초기 로딩 오버헤드가 있을 수 있음
• 런타임 계산: 절대값(시스템 현재 연도)으로부터 도출하되, 성능에 영향이 없는 선에서

seconds.ts 같은 라이브러리는 정적 상수가 맞을 수 있지만, 주기적인 검토 체크리스트를 팀 내에 남기는 게 좋다. "매년 1월에 epoch 상수 검토", 또는 "새 환경 구축할 때마다 시간 기준 검증" 정도.

함께 개편된 컴포넌트들

LiveTicker와 ClaimComposer는 시간 표시가 핵심인 컴포넌트다. 하나는 실시간 카운트(업데이트 진행 상황), 다른 하나는 청구 항목의 유효기간이나 만료일 같은 정보를 보여준다. 이들 UI를 함께 개선하면서 globals.css에서 시간 표시 스타일을 통일했을 것 같다. 폰트, 색상, 간격 같은 기본 요소부터 시작해서, 카운트다운 숫자의 가독성, 만료 상태의 시각적 표현 등.

이렇게 버그 수정과 설계 개선이 섞여 가는 경우, 코드리뷰 때 다음을 체크했을 것이다:

• Epoch 계산이 정말 2026년 기준인지, 다른 연도 참조는 없는지
• UI 스타일 변경이 모든 관련 컴포넌트에 일관성 있게 적용되었는지
• package.json 변경이 다른 곳의 호환성을 깨뜨리지 않는지

전체적으로, 상수라는 "작아 보이는" 부분이 얼마나 많은 UI 컴포넌트와 연결되어 있는지를 다시 한 번 확인하는 계기였다.

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

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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