본문으로 건너뛰기
DEVKBS
작업 원장
015개인 서비스2024.06

TimeLog — 출퇴근 업무시간 계산기

시간을 다루면서 UTC를 제대로 이해하게 된 프로젝트

기간
2024.06
분류
웹앱
역할
기획·디자인·개발 단독
구성
1인
로그인 화면 보기

이용하려면 로그인이 필요합니다. 공개 주소에서는 로그인 화면까지 확인할 수 있습니다.

01개요

근태 기록을 직접 관리하고 싶어 만든 웹앱입니다. 출근·퇴근 버튼을 누르면 기록이 남고, 일간·주간·월간 업무시간이 자동으로 집계됩니다.

기능은 단순해 보이는데, 시간을 다루기 시작하면 정해야 할 게 많아집니다. 서버에 저장된 시각과 브라우저가 보여 주는 시각이 다르고, 자정을 넘긴 근무를 어느 날짜로 셀지, 주간 집계는 무슨 요일부터 시작할지도 정해야 합니다.

이 프로젝트에서 UTC를 처음 제대로 이해했습니다. 그전에는 막연히 표준 시간이라고만 알았는데, 저장은 UTC로 하고 표시할 때만 지역 시간으로 바꾸라는 말이 왜 나왔는지 직접 겪어 보고 알았습니다.

Prisma와 Supabase로 데이터베이스와 인증까지 직접 다뤄 본 것도 이 프로젝트에서 얻은 경험입니다.

02기술 결정

문제, 선택, 결과 순서로 적었습니다.

  1. 결정 01

    저장은 UTC, 표시는 지역 시간

    문제
    처음에는 로컬 시각을 그대로 저장했습니다. 서버 시간대와 브라우저 시간대가 다르면 같은 기록이 다른 날짜로 집계되는 일이 생겼습니다.
    선택
    모든 시각을 UTC로 저장하고, 화면에 그릴 때만 사용자 시간대로 변환하는 규칙을 세웠습니다. 날짜 경계 판단도 변환 후의 지역 시간을 기준으로 합니다.
    결과
    시간대가 달라도 집계가 흔들리지 않습니다. 서버가 다루는 시간과 사용자가 보는 시간을 나눠서 생각하게 된 것도 이때부터입니다.
  2. 결정 02

    집계 규칙을 코드보다 먼저 문장으로 정한다

    문제
    자정을 넘긴 근무, 주간의 시작 요일, 월 경계에 걸친 근무를 어떻게 셀지가 정해지지 않은 채 구현을 시작했더니 화면마다 다른 답이 나왔습니다.
    선택
    '퇴근 시각이 속한 날로 센다', '주는 월요일에 시작한다' 같은 규칙을 먼저 문장으로 적고, 그 문장을 함수 하나로 옮긴 뒤 화면들이 그 함수만 쓰게 했습니다.
    결과
    화면마다 다른 숫자가 나오는 문제가 사라졌습니다. 규칙을 바꿔야 할 때도 함수 하나만 보면 됐습니다.
  3. 결정 03

    프론트엔드 개발자가 데이터 계층까지 직접 다뤄 본다

    문제
    개인 프로젝트에서 백엔드를 붙이려면 인증·스키마·마이그레이션을 전부 다뤄야 합니다. 익숙하지 않은 영역이었습니다.
    선택
    Prisma로 스키마를 정의하고 Supabase로 인증과 데이터베이스를 붙였습니다. 서버 액션으로 데이터 변경을 처리해 API 계층을 따로 만들지 않았습니다.
    결과
    혼자서 데이터부터 화면까지 이어지는 흐름을 한 번 완성했습니다. 이후 회사 프로젝트에서 백엔드와 이야기할 때 서로의 제약을 더 잘 이해하게 됐습니다.

03주요 기능

  • 원클릭 출퇴근 기록

    버튼 하나로 출근·퇴근을 남깁니다. 기록 수정도 가능합니다.

  • 일·주·월 집계

    정해진 규칙에 따라 기간별 업무시간을 자동으로 계산.

  • 차트 시각화

    Chart.js로 근무 패턴을 그래프로 확인합니다.

  • 인증

    Supabase 인증으로 개인 기록을 계정별로 분리.

04화면

Desktop

  • 01

Mobile · 반응형

  • 01

05회고

시간은 만만해 보여도 다루기 까다로운 데이터입니다. UTC가 뭔지 아는 것과, 시간대 때문에 집계가 하루씩 밀리는 걸 직접 보는 건 전혀 다른 일이었습니다.

집계 규칙은 코드를 쓰기 전에 문장으로 먼저 적어 두는 편이 낫습니다. 구현하면서 정하면 화면마다 답이 조금씩 달라지고, 나중에는 뭐가 맞는지 만든 사람도 헷갈립니다.

MVP 상태에서 멈춰 있는 부분이 있어 계속 다듬을 예정입니다.