치과 연차관리 웹앱 개발 프론트엔드(上)

노션 기반 치과 경영관리 시스템 구축 ⑧ — 로그인도 서버도 없이, 화면부터 그리는 이유

1. 연차는 기록의 문제다

치과에서 연차는 대개 이렇게 돌아간다. 직원이 메신저로 “다음 주 화요일 연차 쓰겠습니다”를 보내고, 실장이 “네” 하고, 수첩이나 엑셀 한 칸에 날짜가 적힌다. 이 방식의 문제는 틀렸다는 데 있지 않다. 남지 않는다는 데 있다. 연말에 “제 연차 며칠 남았죠”라는 질문이 나오면 누구도 즉답하지 못하고, 퇴사자가 미사용 수당을 물으면 대화방을 거슬러 올라가며 날짜를 세야 한다.

연차 계산 자체는 어렵지 않다. 어려운 것은 발생과 신청과 승인과 사용이 각각 다른 곳에 흩어져 있다는 점이다. 연차관리 앱이 해결하는 것은 계산이 아니라 이 분산이다.

2. 계산기와 업무앱: 데이터는 어디에

앞선 회차에서 다룬 급여 시뮬레이터를 두고 프론트엔드 도구만으로 충분하다고 썼다. 그 근거는 데이터가 한 사람의 브라우저에서 시작해 그 안에서 끝나기 때문이었다. 계산하는 사람은 한 명이고, 결과를 누가 승인할 필요도, 어제 값이 오늘 남아 있어야 할 이유도 없다.

연차는 반대편에 있다. 직원이 신청한 것을 실장이 보고 원장이 확정하므로 최소 세 사람이 같은 데이터를 본다. 게다가 그 기록은 1년 내내 쌓였다가 퇴직 정산 때 다시 꺼내진다. 데이터가 사람을 건너다니고 시간을 건너가는 순간 계산기는 업무 앱이 되며, 업무 앱에 필요한 것은 수식이 아니라 상태다.

상태가 생기면 화면에는 신청, 1차 승인, 최종 승인, 반려, 시기변경 요청 같은 단계가 생기고, 각 단계에서 무엇이 보이고 무엇을 누를 수 있는지가 보는 사람마다 달라진다. 직원에게는 자기 연차만, 실장에게는 1차 결재함이, 원장에게는 전 직원 원장과 최종 결재가 열린다.

3. 입사일 기준과 회계연도 기준

연차 설계에서 가장 먼저 정해야 할 것은 기준이다. 입사일 기준은 근로기준법 원칙에 가장 충실하다. 각자의 입사일에 1년이 차면 15일이 생기고, 3년차부터 2년마다 1일씩 가산된다. 정확하지만 직원이 열 명이면 발생일도 열 개로 흩어져 관리자가 열 개의 달력을 따라다녀야 한다.

회계연도 기준은 전 직원의 연차를 1월 1일에 일괄 발생시킨다. 관리가 단순해지는 대신 중도 입사자는 첫해 비례 계산이 필요하고, 퇴직 시점에는 입사일 기준으로 계산한 일수보다 불리하지 않은지 반드시 비교해 정산해야 한다. 예시 화면 상단에 ‘회계연도 기준’이 상시 표시되는 것은 그래서다. 기준은 설정값이 아니라 전제이고, 전제는 화면에서 사라지면 안 된다.

4. 연차 원장: 다섯 숫자가 한 줄에 있어야

연차 원장은 이 앱의 중심이다. 한 사람당 한 줄에 유효 발생, 사용·확정, 대기, 잔여, 소멸 다섯 숫자가 놓인다. 이 중 ‘대기’를 별도 열로 분리한 것이 설계의 핵심이다.

결재가 끝나지 않은 신청을 잔여에서 빼지 않으면 직원은 이미 쓰기로 한 연차를 남은 것으로 착각한다. 반대로 그냥 빼버리면 반려 때 숫자가 조용히 되돌아간다. 그래서 대기는 잔여에서 차감하되 별도 열로 드러내고, 결재함의 각 건에도 ‘잔여 11일(대기 포함 차감)’처럼 괄호로 밝혔다. 숫자를 하나로 줄이는 것보다 그 숫자가 왜 그렇게 되었는지를 보이게 하는 편이 분쟁을 줄인다.

5. 청구·승인·사용, 2단계 결재와 대결, 시기 변경

흐름은 청구, 승인, 사용 세 단계이고 승인은 다시 실장의 1차 결재와 원장의 최종 결재로 나뉜다. 치과 규모에 결재 2단계는 과하다고 느낄 수 있으나, 실장이 진료 일정을 보고 거르고 원장이 인건비와 운영을 보고 확정하는 분업은 실제로 작동한다.

실장이 자리에 없을 때 결재가 멈추면 안 되므로 1차 대기 건을 원장이 곧바로 처리하는 대결 기능을 두었다. 그리고 승인과 반려 사이에 시기변경 요청 버튼을 넣었다. 근로기준법은 사업 운영에 막대한 지장이 있는 경우 사용자가 시기변경권을 행사할 수 있도록 하는데, 실무에서 이것은 대개 “그날은 어려우니 다른 날로 하자”는 구두 대화로 끝나고 기록되지 않는다. 버튼으로 만들어 두면 그 대화가 사유와 함께 기록으로 남는다.

6. 소진율: 분모의 정의가 지표의 전부다

대시보드의 평균 소진율 26%는 숫자 자체보다 계산식이 중요하다. 화면에는 소진율 = (사용·확정 + 결재 대기) ÷ 지금 유효한 발생일수라고 적어 두었다. 분자에 결재 대기를 넣은 이유는 앞 절과 같다.

분모를 연간 발생일수가 아니라 ‘지금 유효한 발생일수’로 둔 이유는 다르다. 입사 1년 미만 직원은 매월 개근할 때마다 1일씩 생긴다. 10월 기준으로 아직 발생하지도 않은 일수까지 분모에 넣으면 그 직원의 소진율은 구조적으로 낮게 나오고, 실제로는 잘 쓰고 있는데 안 쓰는 사람으로 분류된다. 지표가 사람을 오해하게 만들면 그 지표는 없는 편이 낫다.

7. 직원 명부: 역할 한 칸이 계산의 전제다

직원명부에는 14명이 있는데 대시보드의 대상 인원은 13명이다. 차이는 대표 원장이다. 대표는 근로자가 아니므로 연차 발생 대상에서 빠진다. 반대로 봉직의는 근로자이므로 포함된다. 같은 원장이라는 직책이라도 역할이 대표인지 아닌 지에 따라 전혀 다르게 처리되는 것이다.

직원명부 카드에 직역·부서·직급·직책과 별개로 역할 필드를 따로 둔 것은 그래서다. 화면 장식이 아니라 계산의 전제이고, 이 한 칸이 틀리면 연차 발생일수와 퇴직 정산이 함께 틀어진다.

직원 표시는 사진·이름·사번 세 요소로 고정했다. 수백 명 규모의 인사 시스템은 사번과 이름으로 충분하지만, 열 명 남짓한 치과에서는 사진이 가장 빠른 식별자다. 이번 주 연차자 영역에서 사진 두 장을 보는 것과 이름 두 줄을 읽는 것은 인지 속도가 다르다. 사번은 식별보다 순서를 드러내는 정보로 쓰여, 2015-001과 2025-013이 나란히 놓이면 근속 차이가 설명 없이 읽힌다.

8. 사용 촉진: 법이 정한 일정이 화면에

연차는 1년간 쓰지 않으면 소멸하고, 소멸한 연차는 원칙적으로 수당으로 지급해야 한다.

다만 사용자가 법이 정한 절차대로 사용촉진을 하면 보상 의무가 면제될 수 있다. 문제는 이 절차가 날짜에 묶여 있다는 점이다. 사용기간 만료 6개월 전을 기준으로 10일 이내에 미사용 일수를 알리고 사용 시기를 정해 통보하도록 서면으로 촉구하고, 직원이 10일 안에 통보하지 않으면 만료 2개월 전까지 사용자가 시기를 지정해 서면으로 통보해야 한다.

입사 1년 미만 직원의 연차는 일정이 또 다르다.

날짜 계산과 서면 통보가 동시에 걸린 절차라 수첩으로는 지키기 어렵다. 사용 촉진을 별도 탭으로 둔 이유가 여기에 있다. 화면이 일정을 기억하고 사람은 확인하고 보내기만 하면 된다.

9. 여기까지가 프론트엔드다

지금까지 본 네 화면은 아직 프로그램이 아니다. 브라우저에서 열리는 단일 HTML 파일이고 데이터는 그 브라우저 안에만 있다. 새로고침하면 처음으로 돌아가고 옆자리 컴퓨터에서 열면 다른 숫자가 나온다. 화면 상단에서 ‘보는 사람’을 바꾸는 선택 상자 역시 실제 로그인이 아니라 역할별 화면 차이를 설계 단계에서 확인하려고 둔 전환 장치다. 이 단계의 정확한 이름은 완성된 앱이 아니라 프론트엔드 설계용 HTML 아티팩트다.

그렇다면 왜 완성되지 않은 것을 먼저 만드는가.

화면을 먼저 그리면 필요한 데이터가 역으로 드러나기 때문이다. 연차 원장의 아홉 개 열은 그대로 테이블 컬럼 후보가 되고, 결재함의 1차 대기·최종 대기·승인·반려·시기 변경은 그대로 상태 값 목록이 되며, 역할마다 무엇이 보이고 무엇을 누를 수 있는지 정해둔 것은 그대로 권한 규칙의 초안이 된다.

데이터베이스부터 설계하면 쓰지 않을 필드를 만들게 되고, 화면부터 설계하면 보이지 않는 필드를 만들지 않게 된다.

전 직원이 각자의 계정으로 로그인해 쓰는 단계로 가려면 세 가지가 더 필요하다.

계정과 로그인을 다루는 인증, 신청과 승인 기록이 영구히 남는 데이터베이스, 누가 어느 줄을 읽고 쓸 수 있는지를 서버가 강제하는 권한 규칙이다.

특히 세 번째가 중요하다. 지금처럼 화면에서 숨기는 방식은 남의 연차 기록을 못 보게 막아주지 못한다.

필자는 이 셋을 한 번에 제공하는 Supabase에 데이터를 두고 Vercel이나 Cloudflare로 화면을 배포하는 조합을 쓸 계획이며, 다음 회차에서 그 백엔드 구축 과정을 다룬다.

10. 계산은 앱이, 확정은 사람이

백엔드가 붙어 제대로 된 앱이 되더라도 계산한 숫자가 그대로 확정되는 것은 아니다.

연말 소멸 예정 136.56일은 방치하면 그대로 수당 부담으로 바뀌는 숫자이고, 퇴직 정산은 회계연도 기준과 입사일 기준을 비교한 뒤에야 확정된다.

반차와 중도 입사자의 비례 발생처럼 예외가 모이는 자리일수록 사람의 확인이 필요하다. 결산·급여·보험청구와 마찬가지로 연차 역시 최종 확정은 담당자의 검토를 거쳐야 하는 영역이다.

좋은 연차관리 앱은 연차를 정확히 계산하는 프로그램이 아니라, 묻기 전에 답이 보이는 화면이다. 다만 그 화면이 혼자 열리는 파일에 머무는 한 그것은 아직 설계도다. 설계도를 건물로 바꾸는 일은 다음 회차에서 다룬다.