초과수당·퇴직연금·근로소득세 계산기 3종 동시 출시

한 번에 계산기 3종을 밀어넣은 커밋이다. 연장·야간·휴일수당, DB·DC 퇴직연금, 근로소득세 단독 — 셋 다 노무/세무 도메인에서 꽤 계산식이 복잡한 영역이라 단순 UI 작업이 아니라 로직 설계에 시간이 꽤 들었다.

왜 이 세 가지를 묶었나

P2 우선순위로 묶인 이유가 있었다. 세 계산기 모두 "숫자 입력 → 법정 공식 → 결과 출력" 구조가 유사하고, 이미 만들어둔 공통 유틸 패턴을 그대로 활용할 수 있었기 때문이다. 인프라 세팅이나 라우팅 구조를 새로 뚫을 필요 없이 src/lib/에 계산 로직 모듈을 추가하고, src/pages/에 Astro 페이지를 붙이는 흐름이 이미 정착돼 있었다.

팀장 관점에서 이런 묶음 작업은 양날의 검이다. 개발 속도는 빠르지만, 세 가지를 한 커밋에 넣으면 코드리뷰할 때 집중도가 흐려진다. 이번엔 각 lib 파일이 완전히 독립된 도메인이라 리뷰어 입장에서 파일 단위로 끊어 볼 수 있었고, 그게 용납된 이유였다. 로직이 서로 얽혀 있었다면 커밋 분리를 강제했을 거다.

파일 구조와 각 모듈의 역할

src/pages/index.astro가 변경 파일에 들어있다는 게 포인트다. 계산기를 추가할 때마다 인덱스를 수동으로 업데이트해야 하는 구조인데, 이게 나중에 부채가 될 수 있다. 계산기가 10개, 20개로 늘어나면 페이지 파일 직접 열거 방식은 금방 번거로워진다. 지금은 감내하고 있지만, 어느 시점에 자동 생성 방식으로 전환할 기준점을 미리 팀 내부적으로 잡아두는 게 좋다.

세 도메인 각각의 계산 복잡도

초과수당(overtime)은 겉보기엔 단순해 보이지만 함정이 있다. 근로기준법 기준 가산율이 연장(50%), 야간(50%), 휴일(50%~100%)로 나뉘고, 중복 적용 케이스도 있어서 분기가 생각보다 많다. 시간 단가를 월급 기준으로 역산할 때 소정근로시간(통상 209시간)을 쓰는데, 이 숫자를 하드코딩하느냐 파라미터로 열어두느냐도 의사결정 포인트였다.

// overtime.ts 패턴 (개념 예시)
const hourlyWage = monthlySalary / STANDARD_HOURS; // 209시간
const overtimePay = hourlyWage * hours * 1.5;
const nightPay = hourlyWage * nightHours * 1.5;

퇴직연금(retirement-pension)은 DB형과 DC형의 계산 기준이 완전히 다르다. DB형은 퇴직 시점 평균임금 기준이고, DC형은 매년 임금 총액의 1/12를 적립하는 방식이다. 두 케이스를 같은 함수로 처리할지, 완전히 분리할지 고민했는데 분기 처리로 가되 인터페이스를 통일하는 방향으로 정리했다.

근로소득세는 간이세액표 기반이라 룩업 테이블 구현이 핵심이다. 부양가족 수 변수에 따라 세액이 달라지는 구조라 단순 공식 계산이 아니라 표 데이터를 어떻게 관리하느냐가 유지보수 난이도를 결정한다.

회고

이번 작업에서 다시 한번 느낀 건, lib 레이어와 page 레이어를 명확히 분리해두면 테스트 작성이 훨씬 쉬워진다는 점이다. src/lib/*.ts 파일들은 UI와 완전히 격리된 순수 계산 함수라서 입력값-결과값 단위테스트만 작성하면 된다. Astro 페이지까지 포함해서 통합 테스트를 돌리지 않아도 되니까 피드백 루프가 짧다.

반대로 주의할 점은, 법정 공식은 법 개정 시 일제히 업데이트가 필요하다는 특성이 있다. 가산율이나 세율 같은 상수를 코드 곳곳에 흩뿌려두면 나중에 찾아서 바꾸는 게 고역이 된다. 상수는 별도 파일이나 명명된 상수로 모아두는 습관이 이런 도메인에서 특히 중요하다.

다음 P2 배치에 어떤 계산기가 올라올지는 아직 미정이다.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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