명확한 정책과 승인을 위한 휴가 요청 시스템 설계

대부분의 휴가 프로세스에서 망가지는 지점들

사람들은 휴가 요청이 회의 예약처럼 느껴지길 기대합니다: 날짜를 선택하고, 잔여 시간을 확인하고, 명확한 허가/거절을 받고, 필요한 모든 곳에 표시되는 것. 그렇게 작동하지 않으면 팀은 “그냥 메시지해”로 되돌아가고, 시스템은 신뢰할 수 있는 도구가 아니라 기록 보관 업무가 됩니다.

요청은 보통 전달 과정에서 막힙니다: 잘못된 관리자에게 가는 이메일 스레드, 아무도 업데이트하지 않는 스프레드시트, 나중에 감사할 수 없는 채팅 승인 등. 직원은 자신이 처리가 된 줄 알고, 관리자는 HR이 처리할 거라 생각하고, HR은 급여 처리 시점에 잔여 시간이 틀렸다는 사실을 알게 됩니다.

휴가 요청 시스템 설계의 실제 목표는 지루하지만 중요합니다: 정확한 잔액, 명확한 승인, 그리고 단일의 진실 소스. 잔액은 정확하지만 승인이 불명확하면 관리자는 "내가 이미 승인했나?"라고 계속 물을 것입니다. 승인이 완벽하지만 캘린더가 틀리면 팀은 여전히 이중 예약을 합니다.

네 그룹이 같은 워크플로를 필요로 하지만 목적은 다릅니다:

• 직원: 빠른 요청, 즉시 상태 확인, 기록에 남는다는 확신
• 관리자: 결정에 필요한 충분한 문맥과 함께 올바른 요청이 전달되는 것
• HR/급여: 정책이 일관되게 적용되고 급여 규칙과 맞는 잔액
• 비즈니스: 민감한 정보를 노출하지 않으면서 팀 가시성 확보

"읽을 수 있는 워크플로"란 단계를 보고 간단한 언어로 설명할 수 있다는 뜻입니다: 무엇이 요청을 트리거하는가, 누가 승인하는가, 거절 시 무엇이 일어나는가, 무엇이 기록(잔액, 상태, 캘린더)되는가. 빠르게 설명할 수 없다면 사람들은 우회할 것입니다.

AppMaster 같은 도구는 로직을 시각적이고 중앙화하여 정책 변경이 이메일과 예외의 미로로 변하는 것을 방지하는 데 도움이 됩니다.

필요한 기본 데이터(과도하게 구축하지 않기)

좋은 휴가 도구는 대부분 깔끔한 레코드 집합과 몇 가지 명확한 관계입니다. 기본을 잘 잡으면 정책과 승인 단계가 나중에 커져도 시스템 설계는 읽기 쉬운 상태로 유지됩니다.

한 분 안에 설명할 수 있는 핵심 객체 소수로 시작하세요:

• Employee(직원): 누가 휴가를 요청하는지(그리고 누가 그를 승인하는지)
• TimeOffRequest(휴가요청): 실제 요청(날짜, 유형, 상태)
• Policy(정책): 휴가 유형에 대한 규칙(PTO, 병가, 무급 등)
• Balance(잔액): 직원과 정책별 현재 사용 가능한 양
• Approval(승인): 요청에 연동된 결정과 코멘트

요청의 필드는 화려할 필요 없습니다. 구체적이어야 현실의 문제를 막습니다. 시작·종료 날짜/시간, 반일 여부, 요청 시 직원의 시간대, 짧은 사유, 필요 시 증빙 첨부(예: 진단서)는 보관하세요. 첨부는 선택 사항으로 두어 일반 PTO를 막지 않도록 합니다.

상태는 적고 예측 가능하게 유지하세요: draft(저장만 됨), submitted(제출), approved(승인), rejected(거절), canceled(취소). 정말 필요하지 않다면 “pending HR” 같은 추가 상태는 피하세요.

감사 추적(audit trail)을 빼먹지 마세요. 최소한 누가 언제 무엇을 변경했는지를 기록하면 분쟁에서 구해줍니다. 최소한 제출, 승인, 거절, 취소, 날짜 수정은 로그로 남기세요.

팀, 위치, 부서는 별도의 참조 데이터로 취급하세요. 직원은 이 그룹에 연결하고, 정책은 적용될 그룹에 연결하세요. 누군가가 사무실을 옮기면 개별 정책을 모두 바꾸는 대신 직원 레코드 하나만 업데이트하면 됩니다.

AppMaster로 구축한다면 각 객체를 먼저 단순하게 유지한 뒤 데이터가 안정되면 검증과 워크플로 단계를 추가하세요.

정책 규칙: 명확하고 테스트 가능하게 유지하기

좋은 정책은 일부러 지루합니다. 사람들은 클릭하기 전 결과를 예측할 수 있어야 합니다. 같은 요청이 어떤 주에는 승인되고 다음 주에는 거절되면 신뢰를 잃기 쉽습니다.

먼저 휴가 유형에 이름을 붙이고 각 유형에 대해 한 문장으로 설명하세요. 예: 휴가(PTO)는 계획된 부재, 병가는 예기치 않은 건강 관련 시간, 무급 휴가는 급여 없는 휴가, 육아휴직은 보통 특별한 날짜와 서류가 필요, 보상휴가는 추가 근무로 얻어 사용함.

자격 규칙은 법률 문서처럼 쓰지 말고 체크리스트처럼 읽히게 하세요. 누가 사용할 수 있는지(정규직, 파트타임, 계약직), 언제 시작되는지(수습 후, X일 후), 근속 여부에 따른 조건 등을 명시하세요. 예외가 있다면 각 예외를 별도의 규칙으로 작성하세요.

요청 규칙은 혼란이 시작되는 지점입니다. 통지 기간, 블랙아웃 날짜, 최소 허용 단위를 구체적으로 작성하세요. 예: “휴가는 비상 상황을 제외하고 영업일 기준 5일 전 제출”과 같이 테스트 가능한 문장으로 하세요. “일찍 제출하세요”는 불충분합니다.

이월과 만료 규칙은 한 문장으로 요약되게 하세요. 예: “최대 40시간까지 다음 해로 이월되며 3월 31일에 소멸.” 둘째 문장이 필요하다면 정책이 너무 복잡하다는 신호입니다.

정책 텍스트와 규칙 로직을 동기화하는 간단한 방법:

• 모든 규칙에 짧은 ID 부여(예: PTO-NOTICE-5D)
• 규칙 구성 옆에 평문 텍스트 저장
• 규칙별 승인/거절 사례 2~3개 추가(테스트용)
• 규칙 구성 변경 시 텍스트도 함께 변경(그 반대도 동일)

예: 수습 중인 직원이 내일 2시간 PTO를 요청하면 시스템은 다음 두 가지 이유로 차단해야 합니다: "PTO는 60일 이후 시작" 및 "PTO는 영업일 기준 5일 전 통지 필요". AppMaster로 만들면 이러한 메시지를 규칙 노드 근처에 두어 업데이트가 시간이 지나며 어긋나지 않게 하세요.

적립(Accrual) 계산: 혼란을 일으키는 패턴들

적립은 작은 규칙들이 모여 복잡해지기에 휴가 시스템에서 자주 엉키는 부분입니다. 목표는 화려한 계산이 아니라 HR과 직원이 잔액을 확인했을 때 기대하는 예측 가능한 결과입니다.

혼합된 적립 방식이 흔한 혼란 원인입니다. 어떤 회사는 급여 기간마다 시간 추가, 어떤 회사는 월별, 근무시간에 따라 적립, 어떤 회사는 고정 날짜에 연간 전체 지급. 문제는 "잔액"만 저장하고 "어떻게 획득했는지"를 잊어버릴 때 시작됩니다. 부여(grant), 적립(accrue), 조정(adjustment), 사용(usage) 같은 이벤트를 명확히 기록하세요.

부분적 비례(proration)도 함정입니다. 중간에 입사한 신입이나 파트타임에서 정규직으로 전환된 직원은 수동 스프레드시트 수정이 필요 없어야 합니다. 하나의 규칙을 정하고 일관되게 적용하세요. 예: 기간의 달 수로 비례 계산하거나 예정 근무시간으로 비례 계산 등. 선택한 내용을 문서로 남기고 모든 곳에 동일하게 인코딩하세요.

상한(cap)과 음수 잔액도 문제를 만듭니다. 이월이 허용되고 상한이 있다면 특정 시점(연말, 적립 기간 종료, 각 적립 후 등)에 상한을 적용하세요. 음수 잔액을 허용한다면 한도와 퇴사 시 처리 방식을 정의하세요.

반올림 규칙은 미묘한 누적 오차를 만듭니다. 분(minutes), 15분, 반나절 같은 한 수준의 반올림을 정하고 적립과 사용 모두에 일관되게 적용하세요. 적립은 분 단위인데 요청은 반나절 단위라면 직원들은 항상 시스템이 틀렸다고 느낍니다.

소급 요청 및 수정도 감사 로그가 필요합니다. 누군가 지난주에 대한 요청을 제출하면 시스템은 요청일로부터 다시 계산하고 변경을 기록해야 합니다.

대부분의 분쟁을 막는 간단한 체크리스트:

• 잔액 변경을 단일 숫자가 아닌 날짜별 거래(transaction)로 저장
• 정책 입력이 변경될 때 유효일자부터 재계산
• 캡과 반올림을 하나의 공용 함수에서 적용
• 수동 조정은 적립 로직과 분리
• 표시되는 모든 잔액에 대해 “기준일(as of date)” 항상 표시

AppMaster에서는 보통 이 구조가 Transactions 테이블과 요청 승인 또는 수정 시 잔액을 재계산하는 소규모 비즈니스 프로세스로 깔끔하게 매핑됩니다.

관리자 승인: 예외를 커버하는 간단한 라우팅

관리자 승인 워크플로는 한 가지 질문에 답해야 합니다: 누가 자신 있게 “승인”할 수 있는가? 모든 조직도 세부를 모델링하려고 하면 설계가 읽기 어렵고 고치기 더 어려워집니다.

기본 규칙 하나로 시작하세요: 직원의 직속 관리자가 승인. 그다음 리스크나 책임에 변화를 주는 예외만 추가하세요. 규칙의 순서를 명확히 해두면 설정을 뒤져보지 않고도 결과를 설명할 수 있습니다.

단일 단계 vs 다단계 승인

대부분 팀은 표준 PTO에 단일 승인 단계로 충분합니다. 급여, 컴플라이언스, 팀 커버리지에 영향을 주는 요청에만 단계 추가하세요.

일반적이고 읽기 쉬운 패턴:

• 단일 단계: 표준 PTO와 무급 휴가에 대해 관리자가 승인
• 이중 단계: 관리자 승인 후 HR이 문서나 정책을 점검하는 경우
• 두번째 승인자: 온콜 로테이션 같은 공유 커버리지에 영향이 있을 때 부서장 추가
• 자동 승인: 1~2시간 같은 저위험 요청이나 일정에 이미 사전 승인된 시간
• 관리자 없음: 관리자 불명확한 역할이나 계약직은 HR 전담 승인

위임, 거절, 재제출

승인은 관리자가 자리를 비웠을 때 깨집니다. 위임을 일급 규칙으로 만드세요. 관리자가 부재로 표시되면 위임자(delegate)로 라우팅하고, 위임자가 없으면 관리자의 상위 관리자나 HR로 대체하세요. 어떤 규칙이 승인자를 선택했는지 항상 로그에 남기세요.

거절과 수정이 시스템을 어지럽히는 지점입니다. 간단히 유지하세요: 거절은 이유를 필수로 하여 요청을 종료합니다. 직원이 날짜나 유형을 수정하면 재제출로 간주하고 라우팅을 처음부터 다시 실행하세요. 이렇게 하면 승인된 내용과 달라진 상태의 "반쪽 승인" 문제를 방지할 수 있습니다.

실용적 예: Alex가 3일 병가를 요청하면 시스템은 관리자로 라우팅하되, 정책상 HR 검토가 필요한 유형이면 관리자 승인 후 HR이 두 번째 단계로 받습니다. 관리자가 부재이면 위임자가 승인하고, 감사 로그에는 이유가 남습니다.

AppMaster로 구축할 때 라우팅 로직을 하나의 시각적 프로세스에 두고 소수의 규칙을 명확한 순서로 유지하면 나중에 누구나 읽고 유지보수하기 쉽습니다.

요청을 허용하기 전의 검증 규칙

좋은 검증은 특수 사례가 승인 단계로 누수되는 것을 막아 시스템을 읽기 쉽게 만듭니다. 설명하기 쉽고 테스트하기 쉬운 규칙을 목표로 하세요.

우선 예약 규칙부터 시작하세요. 겹침(overlap) 체크는 기존 승인된 휴가와 대기 중인 요청과의 충돌을 잡아야 합니다. 반일 처리는 날짜와 AM/PM 또는 시간 단위 같은 간단한 단위를 저장해 반일이 실수로 하루로 반올림되지 않게 하세요. 주말과 공휴일에 대해 차감할지 차단할지 결정하고 일관되게 처리하세요.

잔액 검사는 생각보다 까다롭습니다. 많은 팀은 제출 시 잔액을 검사(스팸성 요청 방지)하고 승인 시 다시 검사(적립이나 다른 승인으로 잔액이 변할 수 있음)합니다. 둘 다 한다면 어느 시점에서 실패했는지 사용자에게 보여주세요.

대부분 사례를 커버하는 깔끔한 검증 목록:

• 날짜 유효성(시작이 종료보다 이전, 동일한 시간대, 반일 선택 누락 없음)
• 기존 휴가와의 겹침 없음(반일 포함)
• 일수 계산에서 주말 및 공휴일 제외 여부(정책 기반)
• 특정 휴가 유형에 필요한 첨부 파일 존재 여부(예: 병가 진단서)
• 잔액 충분성(제출 시 체크, 승인 시 재체크)

팀 커버리지 체크는 도움이 되지만 필수 차단 대신 경고를 디폴트로 하세요. 예: "해당 날짜에 팀에 이미 두 명이 결석입니다. 그래도 제출하시겠습니까?"

오류 메시지는 공정하고 수정 가능한 내용으로 만드세요. 무엇이 실패했는지, 어디서, 어떻게 고치면 되는지 알려줘야 합니다. 예: "요청이 3월 12일(오후)에 승인된 PTO와 겹칩니다. 다른 시간을 선택하거나 기존 요청을 수정하세요."

AppMaster로 만들면 검증을 요청 폼 근처에 두고 승인 단계에서도 같은 검사를 재사용해 규칙이 흩어지지 않게 하세요.

단계별: 구축하고 유지하기 쉬운 읽기 좋은 워크플로

좋은 휴가 요청 시스템은 최고로 지루하게 느껴져야 합니다: 모든 요청이 같은 경로를 따르고 모든 결정에 단 하나의 명확한 이유가 있습니다. 읽기 쉽게 유지하는 가장 쉬운 방법은 정책 데이터(규칙이 무엇인지)와 워크플로 로직(사용자가 Submit를 눌렀을 때 무슨 일이 일어나는지)을 분리하는 것입니다.

다음은 나중에 휴가 유형을 더 추가해도 단순함을 유지할 수 있는 순서입니다:

• 모든 휴가 유형과 규칙을 한 곳에 둡니다(이름, 자격, 이월, 블랙아웃 기간). 여기에 적혀 있지 않으면 다른 곳에도 존재해서는 안 됩니다.
• 잔액을 단일 숫자가 아닌 타임라인으로 모델링하세요. 개시 잔액, 적립(earned), 사용(used), 조정(adjustments)을 저장해 어떤 날짜의 잔액도 설명할 수 있게 합니다.
• 요청 폼을 초기에 검증 절차와 함께 만드세요. 날짜, 반일, 겹침, 통지 기간, 시작일 기준으로 충분한 잔액 여부를 승인 전에 검사합니다.
• 승인 라우팅은 소수의 역할(직원, 직속 관리자, HR)로 처리하고 예외는 데이터로(예: “10일 이상이면 HR 검토 필요”) 관리하세요. 하드코딩은 피하세요.
• 캘린더 이벤트는 승인 후에만 생성하고, 요청이 변경되면 업데이트하거나 취소할 수 있는 동기화된 레코드로 취급하세요.

워크플로를 읽기 쉽게 유지하려면 각 결정을 사람도 읽을 수 있는 문장으로 기록하세요(예: "Rejected: overlaps existing approved leave"). AppMaster 같은 시각적 워크플로 도구를 쓰면 단계 이름을 사람이 읽는 방식으로 붙이세요.

출시 전 실제 시나리오로 테스트하세요: 소급 요청, 관리자가 자리에 없음, 연중 정책 변경, 승인 후 편집 등. 결과가 HR을 놀라게 한다면 규칙이 아직 충분히 명확하지 않은 것입니다.

캘린더 통합: 시간이 지나도 정확하게 유지되게 하기

캘린더는 한 가지 질문에 빠르게 답해야 합니다: 누가 언제 부재인지. 캘린더 이벤트를 전체 요청 레코드로 만들려고 하지 마세요. 스케줄링에 도움이 되는 최소한의 정보를 넣고 나머지는 HR 시스템 안에 두세요.

이벤트 내용은 일관되게 유지하세요. 기본값으로 "Out of office - Alex Kim" 같은 짧은 제목과 휴가 유형이 필요하면 덧붙이세요("PTO", "Sick" 등). 개인 정보 보호를 위해 세부사항은 최소화하세요. 많은 팀이 이벤트를 "Busy"로 표시하고 이유, 잔액, 노트는 요청 안에만 보관합니다.

캘린더 이벤트는 원본이 아니라 복사본으로 간주하기

모든 요청은 안정적인 내부 ID를 가져야 하고, 모든 캘린더 이벤트는 그 ID를 저장해야 합니다(예: 설명이나 커스텀 필드에). 이렇게 하면 요청이 변경될 때 올바른 이벤트를 안전하게 생성·업데이트·삭제할 수 있습니다.

상태 처리에서 시스템이 흔들립니다. 잠정 요청을 캘린더에 보일지 결정하세요. 보인다면 차이를 분명히 하세요(예: 제목 앞에 "Pending" 붙이기, 가용성 설정 다르게 하기). 승인되면 새 이벤트를 만들지 말고 같은 이벤트를 업데이트하세요. 요청이 취소되거나 거절된 후 가시화된 상태였다면 이벤트를 삭제해 캘린더에 거짓 정보가 남지 않게 하세요.

시간대와 특이한 날짜 처리

시간대는 반일·전일 휴가에서 가장 큰 문제를 일으킵니다. 시작과 종료를 직원의 로컬 시간대 기준 정확한 타임스탬프로 저장하고 요청에 그 시간대도 함께 저장하세요.

전일(all-day) 이벤트는 진짜 전일 휴가에만 사용하세요. 반일은 타임드 이벤트(예: 13:00-17:00)로 만들어 다른 시간대의 동료들도 올바른 겹침을 보게 하세요.

• 전일: 직원 시간대의 all-day 이벤트
• 반일: 시작·종료 타임스탬프가 있는 timed 이벤트
• 다일: all-day 이벤트 사용 가능하지만 종료일 포함/미포함 규칙을 확인하세요

캘린더 동기화 실패 시 숨기지 마세요. 작업을 큐에 넣고 백오프로 재시도하며 "캘린더 업데이트 실패" 상태와 수동 "동기화 재시도" 액션을 표시하세요. AppMaster 같은 도구에서는 보통 백그라운드 프로세스와 실패한 동기화 항목을 나열하는 관리자 화면으로 쉽게 관리할 수 있습니다.

흔한 실수와 피하는 법

대부분의 실패는 규칙이 시간이 지나며 조용히 커질 때 발생합니다. 시스템은 "작동"하지만 아무도 잔액을 신뢰하지 않고 모든 예외가 지원 티켓으로 이어집니다.

실수 1: 예외 속에 숨어 있는 적립 로직

적립이 신규 입사, 이월, 무급 휴가, 파트타임 등 많은 특수 사례로 나뉘면 직원은 잔액을 예측할 수 없습니다.

휴가 유형당 하나의 명확한 적립 모델을 유지하고 예외는 이름 있는 테스트 가능한 규칙으로 추가하세요. 몇몇 샘플 직원과 특정 날짜의 예상 잔액을 문서화하고 정책 변경 시 재검토하세요.

실수 2: 끝없이 갈라지는 승인 흐름

끝없이 분기되는 승인 플로우는 테스트하기 불가능해지고 관리자는 왜 요청이 다른 사람에게 갔는지 모릅니다.

안전한 패턴은:

• 하나의 기본 승인자(보통 직속 관리자)
• 단순 조건 기반의 선택적 두번째 승인자(HR 또는 부서장)
• 승인자가 부재일 때의 명확한 대체(위임자 또는 상위 관리자)
• 요청당 하나의 최종 상태(approved, rejected, canceled)

실수 3: 정책 텍스트와 계산을 한 필드에 섞음

정책 텍스트는 사람을 위한 것(무엇이 해당되는가, 누가 자격이 있는가), 수학 규칙은 시스템을 위한 것(비율, 상한, 반올림, 이월). 이 둘을 분리해 표현을 바꿔도 계산이 바뀌지 않게 하고 계산을 테스트하기 쉽게 하세요.

실수 4: 수정과 취소를 기록하지 않음

요청을 덮어쓰면 잔액 변경 뒤의 "왜"를 잃습니다.

누가 언제 무엇을 바꿨는지와 이전 값을 항상 기록하세요. AppMaster에서는 요청 히스토리 테이블과 Business Process의 상태 전환으로 쉽게 모델링할 수 있습니다.

실수 5: 시간대와 공휴일을 나중에 생각함

휴가는 날짜를 가로지르지만 승인과 캘린더 항목은 타임스탬프를 사용합니다. 단일 "정책 시간대"로 정규화하고 직원의 로컬 시간대도 저장하세요. 공휴일이 요청 일수에서 차감되는지 여부도 미리 결정하고 일관되게 적용하세요.

출시 전 빠른 체크리스트

모두에게 공개하기 전에 실제 직원, 관리자, HR 한 명씩과 짧은 점검을 실행하세요. 시스템이 단지 작동하는 것이 아니라 직관적으로 느껴지는지 확인하는 것이 목적입니다.

다음 체크리스트를 롤아웃의 통과/불합격 게이트로 사용하세요:

• 잔액 가시성: 직원이 오늘의 잔액과 승인된 향후 휴가가 잔액에 어떤 영향을 미칠지 볼 수 있는가.
• 정책 명확성: 모든 규칙(이월, 블랙아웃, 최소 통지, 반일 등)이 평문으로 적혀 있고 로직이 그 문장과 정확히 일치하는가.
• 도움 되는 검증: 요청이 차단될 때 사용자가 무엇을 변경해야 하는지(날짜, 휴가 유형, 시간, 첨부 누락 등)를 알려주는가.
• 관리자 준비성: 관리자가 하나의 화면에서 충분한 문맥(남은 잔액, 겹치는 팀 결석, 인수인계 메모)을 보고 바로 승인할 수 있는가.
• 캘린더와 감사: 승인·변경·취소 시 캘린더 이벤트가 생성되고 동기화되며, 모든 상태 변경이 누가 언제 했는지 기록되는가.

간단한 실제 테스트: 요청 하나를 만들고 승인, 날짜 편집, 취소를 해보세요. 어느 단계든 잘못된 잔액, 남아있는 캘린더 이벤트, 설명되지 않는 상태가 남는다면 출시 전에 고치세요.

AppMaster로 만든다면 각 단계를 사용자 액션 이름(Submit, Validate, Route to Manager, Update Balance, Create/Update Calendar, Log Event)으로 명명해 워크플로가 정책이 진화해도 명확하게 유지되도록 하세요.

예시 시나리오: 요청에서 캘린더 초대까지

신입 직원 Maya가 3월 10일에 입사했습니다. 시스템은 월별 적립을 지원하므로 Maya는 매달 1일에 PTO를 적립합니다. 4월 12일, 그녀는 다음 주 금요일에 의료 예약으로 3시간의 부분 휴가를 요청합니다.

각자 보는 내용은 다릅니다:

• 직원(Maya): 현재 잔액, 이 요청이 얼마나 사용할지, 음수가 될 경우 명확한 경고
• 관리자: 날짜, 시간, 인수인계 메모 등 간단한 요약과 승인/거절/위임 옵션
• HR: 계산에 사용된 정책, 감사 기록, 규칙 변경 시 재계산 방법

Maya가 요청을 제출하자 관리자는 휴가 중이라 시스템은 위임 설정을 확인하고 대리 관리자에게 라우팅합니다. 대리 관리자가 승인합니다.

승인 시 두 가지가 일어납니다: 요청은 사용된 정책 버전에 고정되고, 해당 날짜와 시간 창에 "Maya - PTO (3h)"라는 캘린더 이벤트가 생성됩니다. Maya는 즉시 "승인" 상태와 캘린더 상태 "추가됨"을 확인합니다.

6월에 HR이 연중 정책을 변경(예: 90일 후 적립률 증가)하면 잔액을 재계산해야 하지만 이미 승인된 과거 요청은 조용히 변경하면 안 됩니다. 시스템은 유효일자부터 현재 잔액을 재계산하고 전후 값을 감사 기록으로 남깁니다.

일주일 후 Maya가 날짜를 변경하면, 이미 승인된 상태였기 때문에 변경은 "변경 요청"으로 간주되어 다시 대리 관리자의 승인을 받습니다. 새 승인이 이루어지면 기존 캘린더 이벤트가 업데이트되고(같은 이벤트 ID), 중복 생성되지 않습니다.

이 흐름은 AppMaster에서 쉽게 모델링할 수 있습니다: 하나의 승인 경로, 하나의 위임 체크, 하나의 캘린더 생성/업데이트 단계, 정책 변경 시 HR이 실행할 수 있는 별도의 재계산 액션으로 구성하세요.

다음 단계: 첫 버전을 배포하고 안전하게 확장하기

가장 안전한 방법은 신뢰할 수 있는 작은 버전을 배포한 뒤 확장해 나가는 것입니다. 먼저 하나의 정책(예: PTO)과 하나의 승인 경로(직원 -> 관리자)로 시작하세요. 그것이 지루하고 신뢰할 만해지면 다음 정책 유형, 지역 또는 엣지 케이스를 추가하세요.

더 많은 규칙을 만들기 전에 진실의 원천(source of truth)이 어디인지 결정하세요. HR 시스템이 마스터라면 앱은 주로 검증, 승인 라우팅, 결과 동기화를 담당해야 합니다. 앱이 마스터라면 감사 로그를 명확히 하고 HR 데이터 변경(관리자 변경, 부서 이동, 퇴사일 등) 시 어떻게 처리할지 계획하세요.

실용적인 첫 출시 계획:

• 명확한 잔액과 단일 적립 규칙을 가진 하나의 휴가 유형 구현
• 하나의 관리자 승인 단계와 하나의 HR 오버라이드 경로 추가
• 승인된 휴가에 대해서만 간단한 캘린더 동기화 구현
• 정책 설정을 비기술 담당자가 읽을 수 있는 관리자 화면 유지
• 누가 언제 결석하는지에 대한 기본 리포팅 추가

변경마다 5~10개의 실제 테스트 케이스를 문서화하고 재실행하세요. 팀의 실제 사례를 사용하세요. 예: 목요일에 금요일 휴가 요청, 승인 후 요청 수정, 직원이 다른 시간대에서 관리자가 승인 등.

노코드로 빌드한다면 기능만큼 가시성이 중요합니다. AppMaster에서는 데이터 모델(휴가 유형, 잔액, 승인)과 승인 워크플로를 시각적 편집기에서 유지할 수 있어 HR과 운영팀이 시스템이 실제로 무엇을 하는지 검토하기 쉽습니다. 또한 정책이 진화할 때 지저분한 패치를 쌓지 않고 API로 캘린더 동기화 등을 노출하거나 소스 코드를 깔끔하게 재생성할 수 있습니다.

첫 버전이 안정되면 한 번에 하나의 축을 확장하세요: 정책 추가, 라우팅 규칙 추가, 그다음 통합 추가.