다음 휴가 신청 전에 휴가 규칙을 정하는 방법

불편한 것은 신청서가 아닙니다

휴가 신청이 어려워지는 순간은 사장이 신청이 들어온 자리에서 유급인지 무급인지, 며칠인지, 이 직원에게 권리가 있는지를 새로 결정해야 할 때입니다. 합리적인 예외 하나가 아무도 볼 수 없는 기준으로 바뀝니다.

질문은 “오늘은 얼마나 유연하게 할까?”가 아니라 “오늘 전에 합의한 어떤 규칙을 적용할까?”여야 합니다.

운영의 핵심은 분명합니다. 한눈에 안 보이니 대충 유도리로 처리한다 — 그리고 그 유도리는 늘 사장이 원하는 방향으로 굽는다. 가리킬 기록이 없으니 직원은 따지지 않는다. 그냥 그만둔다. 규칙은 대화를 개인 감정이 되기 전에 양쪽이 읽을 수 있게 합니다.

설정 순서

1. 휴가 유형을 이름 붙입니다. 연차와 무급휴가, 사유가 있는 휴무를 나눕니다. “쉬는 시간”은 법률·급여상 같은 종류가 아닙니다.
2. 규칙의 입력값을 정합니다. 부여 일수, 주기 또는 적용일, 입사일을 기준으로 할지 결정합니다. 캡처된 규칙 화면에는 일수와 시작일 선택이 보이고, 다른 화면에는 직원 설정이나 입사일 확인이 아직 필요하다는 안내가 보입니다.
3. 앱 밖의 기준을 먼저 확인합니다. 근로계약, 관할 노동법, 단시간 근로자, 이월과 유급 처리 여부를 확인한 뒤 저장합니다. 화면의 “매년 1월 1일부터 12일”은 입력 상태일 뿐, 모든 직원에게 적법하다는 증거가 아닙니다.
4. 다음 신청에 같은 규칙을 적용합니다. 관리자는 승인 여부와 매장 운영 가능 여부를 따로 판단합니다. 규칙은 권리 확인을 돕지만 배치 계획을 대신하지 않습니다.

제품에서 실제로 하는 일

캡처된 Leave Setting 화면에서 Annual Leave는 “Paid · Deducts balance”로, 규칙 행은 “No rule — Tap to set one up”으로 보입니다. 이를 열면 “Every year”, “12 days”, “From Jan 1” 같은 기본값이 보이는 규칙 폼으로 이동합니다. 머릿속의 판단을 함께 볼 수 있는 설정으로 옮기는 구체적인 자리입니다.

혜택은 조건부입니다. 입력값이 맞고 저장 동작을 테스트했다면, 사장은 채팅을 다시 뒤지지 않고 같은 규칙을 가리킬 수 있습니다. 이 화면은 규칙의 입력값을 보여주지만 서버 저장, 권한, 적용일 검증, 최종 부여 결과까지 확인해 주지는 않습니다.

서로 다른 일을 섞지 마세요

규칙 화면은 법률 자문이 아니고, 표시된 규칙이 승인 결정을 대신하지도 않습니다. 다만 결정을 확인할 수 있게 합니다.

결과를 확인하세요

규칙을 저장한 뒤 직원 한 명의 입사일, 예상 부여량, 다음 부여일을 적어 둡니다. 문서화한 시점에 설정과 잔여일 또는 상태를 다시 엽니다. 다르면 조용히 기록을 덮지 말고 설정을 멈춘 뒤 담당 전문가나 제품 검토를 요청하세요.

이렇게 해야 사장의 기억이 반복 가능한 운영으로 바뀝니다. 직원은 같은 규칙을 묻고, 관리자는 신청을 처리하고, 예외만 사장에게 올라옵니다. 판단을 없애는 것이 아니라 기분에 따라 기준이 바뀌는 일을 멈추는 것입니다.

정책 변경이 과거 신청을 다시 쓰지 않도록 버전을 붙이세요

휴가 유형의 이름은 같아도 의미는 바뀔 수 있습니다. 자격, 발생 방식, 이월, 사전 통지, 증빙, 승인 조건에 버전과 시행일을 붙이세요. 새 버전이 적용된 뒤에도 이미 판단한 신청에는 당시 사용한 기준이 남아야 합니다. 그렇지 않으면 이전 결정을 설명할 수 없게 됩니다. 현재 설정은 맞아 보여도 매니저가 그때 적용한 설정과는 다를 수 있기 때문입니다.

적용 전에 재직자를 새 기준으로 어떻게 옮길지도 정합니다. 기존 잔액을 보존할지, 공개한 방식으로 전환할지, 개별 확인할지 문장으로 남기고 설정값 변경이 이 정책 질문에 몰래 답하게 두지 마세요. 한 사람에게만 다른 처리가 필요하면 공통 정의를 보이지 않게 바꾸지 말고 날짜, 승인자, 이유가 있는 예외로 기록합니다. 같은 사례가 되풀이되면 이후 시점부터 정책을 개정하고 영향을 받는 사람에게 새 버전을 알립니다.

사장에게 돌아오는 이익은 모든 사례를 억지로 같게 만들지 않으면서도 일관성을 확보하는 것입니다. 매니저는 어느 기준으로 판단해야 하는지 알고, 직원은 이름이 있는 버전을 근거로 불일치를 제기할 수 있으며, 나중의 수정도 첫 판단의 근거를 지우지 않습니다. 현지 법, 계약, 이미 발생한 권리가 전환 방식을 제한할 수 있는 경우에는 노무·법률 책임자의 검토가 필요합니다.

사람과 날짜의 경계를 두 번째 검토자와 시험하세요

실제 신청을 받기 전에 작은 사례 묶음을 실행하세요. 입사일이나 자격 상태가 다른 직원 두 명 이상, 시행일 바로 전 날짜, 시행일 당일, 그 이후 날짜를 포함합니다. 잔액이 부족한 건과 기간 경계를 걸치는 신청도 하나씩 넣으세요. 각 결과에는 입력값, 적용돼야 할 버전, 예상 판단, 그 판단을 설명하는 조항을 기록합니다. 이것은 먼저 정책을 검증하는 일이며 앱이 적법성을 결정한다고 가정하는 시험이 아닙니다.

설정을 만들지 않은 매니저가 문서와 보이는 값만으로 같은 사례를 다시 판단하게 합니다. 답이 다르면 문구가 모호한지, 값이 틀렸는지, 화면에 필수 조건이 빠졌는지, 제품 밖 절차가 누락됐는지 분류한 뒤 수정하세요. 정책의 빈틈을 직원 잔액 수정으로 덮으면 결함만 숨게 됩니다.

첫 실제 주기가 끝나면 승인, 거절, 수정 신청을 하나씩 표본으로 고릅니다. 원래 입력, 적용 버전, 판단 이유, 승인자, 사후 정정이 서로 구분되고 미래 시행 정책이 이전 신청에 영향을 주지 않았을 때만 회귀 검사를 통과시킵니다. Storebase는 앞서 근거가 확인된 설정과 휴가 기록 단계를 지원할 수 있지만, 정책의 유효성, 전환 방식, 관리자 판단, 대체 인력, 급여 영향은 사업장이 맡아야 합니다.