실제 마감일을 위한 워크플로의 비즈니스 캘린더

실제 비즈니스 캘린더가 없으면 마감일이 깨지는 이유

마감일은 분명해 보이지만 실제 근무 시간이 개입하면 달라집니다. 워크플로는 “8시간 내 응답”이나 “내일 정오까지 승인”이라고 말할 수 있지만, 단순한 타이머는 모든 시간을 똑같이 셉니다. 밤 시간, 주말, 공휴일, 사무실 휴무까지 사람들이 언제나 일할 수 있는 것처럼 계산합니다.

바로 그럴 때 비즈니스 캘린더가 필요합니다. 타이머를 실제 팀이 일할 수 있는 시간에 맞는 현실적인 마감일로 바꿔줍니다.

예를 들어 지원 티켓을 생각해보세요. 금요일 오후 4시 30분에 도착한 티켓에 4시간 SLA가 있으면, 기본 타이머는 같은 저녁에 지연으로 표시할 수 있습니다. 하지만 팀이 평일 오전 9시부터 오후 6시까지만 일한다면 금요일에는 실제로 90분(작업 시간)만 지났습니다. 나머지 시간은 월요일로 이월되어야 합니다.

영업팀도 동일한 문제를 겪습니다. 리드가 라우팅 컷오프 이후에 들어왔는데 워크플로가 같은 날 후속 조치 큐로 밀어 넣으면, 프로세스는 빠르게 보이지만 실제로는 팀이 이미 오프라인이라 약속한 응답 시간을 지킬 수 없습니다.

승인 절차도 같은 이유로 깨집니다. 관리자가 공휴일 전날에 구매 요청을 받았고 워크플로가 24시간을 준다면, 그 타이머는 사무실이 닫힌 동안 만료될 수 있습니다. 시스템은 기한을 넘겼다고 표시하지만 실제로는 누구도 공정하게 조치할 기회를 갖지 못했습니다.

대부분의 잘못된 마감일은 몇 가지 규칙이 빠졌기 때문입니다. 워크플로가 주말을 일반 근무일처럼 처리하거나 공휴일을 무시하거나 지역별 근무시간을 고려하지 않거나 일일 마감(컷오프)을 잊어버리면 마감일 계산이 처음부터 잘못됩니다.

그 결과 업무가 곳곳에서 늘어납니다. 팀은 지연을 설명하고 티켓을 무효화하거나 수동으로 마감일을 수정하며 자동화를 신뢰하지 않게 됩니다.

해결책은 간단합니다: 마감일은 시계 시간이 아니라 사무실 근무 시간을 반영해야 합니다. 근무일, 공휴일, 근무시간, 컷오프 시간이 워크플로에 반영되면 마감일은 사람들이 실제로 믿고 따를 수 있는 것이 됩니다.

가장 중요한 캘린더 규칙들

워크플로가 실제 마감일을 제공하려면 캘린더가 사람들의 실제 근무 방식과 일치해야 합니다. 시스템이 모든 시간을 똑같이 계산하면 아무도 없는 날과 시간에 작업을 약속하게 됩니다.

근무일과 공휴일부터 시작하세요

첫 번째 규칙은 기본적이지만 필수적입니다. 어떤 날을 정상 근무일로 볼지 정의하고 어떤 날은 제외할지 정하세요. 많은 팀은 월요일부터 금요일까지를 근무일로 보지만, 모든 부서가 그렇진 않습니다. 지원팀은 주 7일 근무할 수 있고, 재무팀은 그렇지 않을 수 있습니다.

이 단계를 건너뛰면 단순한 이틀짜리 승인도 일요일 마감으로 잡힐 수 있습니다.

공휴일도 똑같이 중요합니다. 한 사무소에서 프로세스를 설계하고 여러 사무소가 사용하면 놓치기 쉽습니다. 연례 전사 휴무, 재고 조사일, 연말 폐쇄 등 회사 차원의 휴무도 마찬가지로 고려해야 합니다.

관리와 유지보수를 쉽게 하려면 공휴일 유형을 분리해 두는 것이 도움이 됩니다. 공휴일, 지역 사무소 공휴일, 전사적 폐쇄일, 일회성 폐쇄일을 섞어두면 각 팀마다 달라질 때 관리가 번거로워집니다.

근무시간, 컷오프 시간, 시간대도 정의하세요

영업일이 곧 24시간을 뜻하진 않습니다. 지역 근무시간은 워크플로가 실제로 작업이 가능한 시간을 알려줍니다. 영업은 오전 9시~오후 6시, 지원은 더 긴 시간을 커버할 수 있고 재무는 오후 5시에 처리 를 종료할 수 있습니다. 팀마다 다른 캘린더가 필요한 경우가 많습니다.

컷오프 시간은 같은 날 처리가 중요한 경우 특히 중요합니다. 승인 요청이 오후 4시 45분에 도착했는데 컷오프가 오후 4시 30분이면, 워크플로는 이를 다음 영업일의 작업으로 처리해야 합니다. 이 규칙이 없으면 시스템은 빠르게 보이지만 현실적으로 불가능한 마감일을 만들어냅니다.

시간대도 흔히 빠지는 요소입니다. 뉴욕에서 생성된 요청을 베를린에서 승인한다면 단일 시계만 따를 수 없습니다. 보통 해당 작업을 담당하는 팀의 로컬 시간이 그 단계의 기준이 되어야 합니다. 제출한 사람의 시간대가 아니라 담당 팀의 시간대를 기준으로 삼는 경우가 많습니다.

이 규칙들이 분명해지면 SLA 추적은 더 정확해지고 신뢰하기 쉬워집니다.

단계별 설정 방법

소프트웨어가 아니라 사람에서부터 시작하세요. 캘린더 규칙은 각 팀의 실제 근무 방식과 일치해야만 효과가 있습니다.

지원팀은 주말에 일할 수 있습니다. 재무팀은 월~금만 일할 수 있습니다. 법무팀은 오후 4시 이후 검토를 중단할 수 있습니다. 모든 팀이 같은 일정표를 쓰면 마감일은 처음부터 잘못됩니다.

1. 각 팀의 일정 매핑하기

워크플로에 관여하는 모든 그룹을 나열하고 시간에 영향을 주는 차이점을 기록하세요. 가장 중요한 것은 실제 차이점입니다. 보통 근무일, 시간대, 특정 요일의 단축 근무, 지역 공휴일, 컷오프 시간이 해당됩니다.

그 다음 스케줄 패턴별로 캘린더를 하나씩 만드세요. 보통 모든 사람마다 별도 캘린더를 만들 필요는 없습니다.

2. 근무시간과 휴무 정의하기

각 캘린더의 근무 시작·종료 시간을 정의하고, 마감일 계산에 영향을 주는 예정된 휴무도 포함하세요.

그다음 공휴일, 회사 폐쇄일, 사무실별 폐쇄일을 추가하세요. 많은 마감일 오류는 여기서 시작합니다. 워크플로가 공휴일을 무시하면 실제로 아무도 없는 날에 같은 날 처리를 약속하게 됩니다.

플랫폼에서 비즈니스 캘린더를 직접 지원하면 해당 스케줄 논리를 프로세스를 시작하는 양식이나 요청뿐 아니라 실제 워크플로 단계에 연결하세요.

3. 컷오프 시간 추가하기

컷오프 시간은 현실적으로 불가능한 늦은 시간의 마감일을 막아줍니다. 재무가 1영업일 검토를 약속할 때 오후 4시 55분에 들어온 요청을 오전 10시에 들어온 요청처럼 취급하면 안 됩니다.

실용적인 규칙은 간단합니다: 컷오프 이후에는 시계가 다음 유효한 영업 기간에서 시작합니다.

4. 실제 날짜로 테스트하기

라이브로 적용하기 전에 샘플 케이스를 워크플로에 돌려보세요. 평일, 금요일 오후, 공휴일, 공휴일 전날을 테스트하세요.

예를 들어 요청이 금요일 오후 5시 30분에 도착했고 월요일이 지역 공휴일이라면 해당 사무실의 근무시간 기준으로 마감일은 화요일로 밀려야 합니다. 그렇지 않다면 런칭 전에 캘린더를 더 손봐야 합니다.

작은 테스트 세트로도 나중에 발생할 수많은 수동 수정 작업을 줄일 수 있습니다.

워크플로에서 캘린더 논리가 위치해야 할 곳

시간이 의사결정에 영향을 주는 곳 어디에나 캘린더 규칙을 두어야 합니다. 규칙이 끝에만 붙어 있으면 프로세스는 문서상으로는 맞아 보이지만 실제 마감일을 놓치게 됩니다.

첫 번째는 타이머 자체입니다. 워크플로는 밤·주말·공휴일을 활동 시간으로 계산하는 대신 해당 시간대 밖에서는 일시중지해야 합니다. 예를 들어 승인 타이머가 오후 4시 45분에 시작되고 사무실이 오후 5시에 닫힌다면 그날은 15분만 카운트되어야 합니다.

다음은 업무 라우팅입니다. 작업은 종종 다른 근무일정을 가진 팀 간에 이동합니다. 금요일 늦게 한 지역에서 생성된 요청이 이미 오프라인인 다른 팀의 큐로 가면 안 됩니다.

알림도 캘린더 논리가 필요합니다. 오전 2시나 지역 공휴일에 보내진 알림은 놓치기 쉽고 혼란을 일으킵니다. 더 나은 규칙은 메시지를 보류하고 다음 유효한 근무 시간에 발송하는 것입니다.

에스컬레이션도 동일하게 다뤄야 합니다. 케이스에 4시간 응답 목표가 있다면 이는 할당된 캘린더 기준의 4근무시간을 뜻하지 단순 시계 4시간이 아닙니다.

주요 체크포인트는 보통 다음과 같습니다:

• 작업이나 승인 타이머가 시작될 때
• 다른 팀이나 사무실로 작업을 라우팅하기 전
• 알림이나 리마인더를 보내기 전
• 연체 작업을 에스컬레이션하기 전

시간 기반 단계마다 유용한 질문은 간단합니다: 이 시간이 그 작업을 담당한 사람이나 팀의 근무 시간인가?

AppMaster 같은 시각적 도구에서는 이런 규칙을 프로세스 단계, 타이머, 알림과 가깝게 두는 것이 도움이 됩니다. 캘린더 논리가 결정이 일어나는 곳에 있을 때 마감일은 현실에 더 가깝게 유지됩니다.

SLA의 간단한 예

기본 SLA 예시는 차이를 분명히 보여줍니다. 고객이 금요일 오후 5시 30분에 지원 요청을 보냈다고 합시다. 지원팀은 월금 오전 9시오후 6시에 일하고, 회사는 신규 요청에 대해 오후 5시 컷오프를 둡니다.

그 컷오프가 모든 것을 바꿉니다. 사무실이 아직 열려있더라도 요청은 새로운 작업이 카운트되기 시작하는 지점을 지나 도착한 것입니다. 따라서 2시간 SLA는 금요일 저녁에 시작되지 않습니다. 다음 영업 개시 시점인 월요일 오전 9시에 시작합니다.

일정

• 요청 수신: 금요일 오후 5시 30분
• 근무시간: 월금 오전 9시오후 6시
• 같은 날 처리 컷오프: 오후 5시
• SLA 목표: 2 근무시간
• 실제 마감일: 월요일 오전 11시

반면 단순 시계 시간으로 2시간을 더하면 마감일은 금요일 오후 7시 30분으로 설정됩니다. 정확해 보이지만 팀의 실제 근무 방식과 맞지 않습니다.

이것이 캘린더 시간과 비즈니스 시간의 차이입니다. 캘린더 시간은 시계의 모든 시간을 계산합니다. 비즈니스 시간은 팀이 실제로 작업할 수 있는 시간만 계산합니다.

마감일을 정하기 전에 워크플로는 세 가지를 확인해야 합니다: 요청이 근무시간에 도착했는가, 컷오프 이전에 도착했는가, 그리고 이후 시간이 근무일에 해당하는가. 이 중 하나라도 실패하면 타이머는 다음 유효한 영업 시간까지 대기해야 합니다.

이렇게 하면 위반 경고가 공정해지고 고객에게 약속한 시간도 현실적이 됩니다.

잘못된 마감일을 만드는 흔한 실수들

워크플로는 다이어그램상으로는 괜찮아 보여도 매일 잘못된 마감일을 만들 수 있습니다. 흔한 문제는 시스템이 기계처럼 시간을 계산하는 반면 비즈니스는 지역 일정과 예외에 따라 움직인다는 점을 무시하는 것입니다.

가장 큰 실수 중 하나는 모든 팀에 하나의 캘린더만 사용하는 것입니다. 보기에는 깔끔하지만 지원이 주말에 일하고 재무가 일찍 마감하며 운영이 다른 휴일 목록을 따를 때 금방 깨집니다. 모든 단계가 같은 스케줄을 쓰면 어떤 작업은 늦은 것으로 보이고 어떤 작업은 이미 에스컬레이션되어야 할 때 정상이 됩니다.

또 다른 흔한 실수는 지역 공휴일을 무시하는 것입니다. 회사는 하나의 프로세스를 가질 수 있지만 그 안의 사람들은 여러 사무실에 분산되어 있을 수 있습니다. 요청이 런던에서 두바이로, 다시 뉴욕으로 이동하면 단일 공휴일 스케줄은 지역 폐쇄를 놓쳐 가짜 SLA 위반을 만들어냅니다.

시간대 문제도 서버 시간을 로컬 비즈니스 시간이 아니라 기준으로 쓰면 문제가 됩니다. 현지 시간으로 오후 4시 30분에 제출된 요청이 서버 시간으로는 다음 날 작업으로 처리될 수 있습니다. 반대의 경우도 생깁니다: 자동화 시계가 팀의 시계와 맞지 않으면 작업이 너무 일찍 연체로 표시될 수 있습니다.

컷오프 시간은 사소한 디테일로 여겨지기 쉽지만 영향은 큽니다. 요청이 “같은 영업일”에 처리된다고 해도 오후 5시 이후 도착한 요청은 다음 영업일부터 카운트되어야 한다는 규칙이 없으면 늦은 시간 제출물은 불가능한 마감일을 받게 되고 사람들은 시스템을 신뢰하지 않게 됩니다.

또 다른 쉬운 실수는 일정이 바뀐 후 재테스트를 잊는 것입니다. 근무시간이 바뀌고 팀이 반일 근무를 추가하며 공휴일 정책이 바뀝니다. 워크플로가 이 변화에 따라가지 않으면 마감일 오류는 다시 나타납니다.

노코드 플랫폼에서 이 작업을 구축 중이라면 캘린더 규칙을 사소한 설정이 아니라 핵심 비즈니스 로직으로 취급하세요. 출시 전 금요일 저녁 요청, 지역 공휴일, 시간대 간 핸드오프 같은 현실적인 테스트 몇 가지가 보통 취약점을 먼저 드러냅니다.

출시 전에 빠르게 점검할 항목

기본 테스트를 통과해도 캘린더 규칙이 잘못되면 첫날부터 실패할 수 있습니다. 배포 전에 자주 깨지는 케이스들을 테스트하세요.

정상 근무시간에 완전히 들어오는 요청 하나로 시작하세요. 그런 다음 근무 종료 직전 시작되는 요청을 테스트하세요. 그다음 주말을 넘기는 케이스, 공휴일에 도착한 케이스, 최소 두 개 이상의 시간대를 넘나드는 케이스를 테스트하세요.

짧은 사전 출시 체크리스트는 충분합니다:

• 정상 근무시간 내 완전한 테스트 하나
• 마감 직전의 테스트 하나
• 주말을 넘기는 테스트 하나
• 공휴일 테스트 하나
• 두 사무실 또는 시간대를 넘는 테스트 하나

가능하면 예상 마감 시간을 수작업으로 계산한 값과 시스템이 보여주는 마감 시간을 비교하세요. 작은 수동 확인으로 사용자가 발견하기 전에 잘못된 캘린더 규칙을 잡아낼 수 있습니다.

AppMaster에서 워크플로를 만드는 경우 각 캘린더 규칙을 전체 프로세스에 연결하기 전에 별도의 단계로 테스트하면 타이머, 라우팅 논리, 알림 규칙 중 어디에 문제가 있는지 찾기 쉬워집니다.

실무 적용을 위한 다음 단계

우선 이미 마감일을 놓치거나 급하게 처리하거나 혼란스러운 핸드오프가 발생하는 하나의 워크플로부터 시작하세요. 지원 큐, 승인 흐름, SLA가 있는 요청 프로세스가 대개 가장 적합합니다.

모든 일정 규칙을 한꺼번에 고치려 하지 마세요. 하나의 워크플로만으로도 실제 비즈니스 캘린더의 가치를 증명하기에 충분합니다.

먼저 규칙을 평이한 문장으로 작성하세요. 단순히 "근무시간 사용"이라고 적는 대신 무슨 의미인지 상세히 쓰세요: 어떤 요일을 근무일로 보는지, 근무시간은 언제인지, 컷오프는 언제 적용되는지, 어떤 공휴일이 시계를 멈추는지, 어떤 사무실이 다른 일정을 따르는지. 많은 마감일 문제는 처음엔 기술적이라기보다 서로 다른 팀이 서로 다른 규칙을 가정했기 때문에 발생합니다.

규칙이 명확해지면 개발자 없이도 사람들이 업데이트할 수 있는 도구로 옮기세요. 이것이 팀들이 내부 프로세스에 AppMaster 같은 플랫폼을 사용하는 이유 중 하나입니다. 노코드 애플리케이션으로 사무실 캘린더를 저장하고 워크플로에 비즈니스 규칙을 적용하며 승인 시스템, 관리자 패널, 지원 큐, 고객 포털 같은 내부 도구를 지원할 수 있습니다.

첫 버전은 테스트하기 쉽게 유지하세요. 실제 예시 몇 개를 워크플로에 돌려보며 팀장이 수작업으로 기대할 결과와 시스템의 마감일이 일치하는지 확인하고 조정하세요.

목표는 단순합니다: 마감일은 시계 시간이 아니라 실제 근무 시간을 반영해야 합니다.