SLA 타이머와 에스컬레이션: 유지보수 가능한 워크플로우 모델링

시간 기반 규칙이 관리하기 어려워지는 이유

시간 기반 규칙은 보통 간단하게 시작합니다: “티켓에 2시간 동안 답장이 없으면 누군가에게 알린다.” 그러다 워크플로우가 커지고 팀이 예외를 더해 어느 순간 누가 어떻게 동작하는지 아무도 확신하지 못하게 됩니다. 이렇게 해서 SLA 타이머와 에스컬레이션은 미로가 됩니다.

움직이는 요소들의 이름을 분명히 정하면 도움이 됩니다.

**타이머(timer)**는 이벤트 이후 시작(또는 예약)되는 시계입니다(예: “티켓이 Waiting for Agent로 이동했을 때”). **에스컬레이션(escalation)**은 그 시계가 임계값에 도달했을 때 하는 일로, 리드에게 알리거나 우선순위를 바꾸거나 작업을 재할당하는 것 등이 있습니다. **브리치(breach)**는 "우리가 SLA를 놓쳤다"는 사실을 기록한 것으로, 보고·알림·후속 조치에 사용됩니다.

문제는 시간 로직이 앱 전반에 흩어질 때 나타납니다: “티켓 업데이트” 흐름 안의 몇 가지 검사, 야간 배치의 추가 검사, 특정 고객을 위한 일회성 규칙 등. 각 부분은 개별적으로는 그럴듯하지만 함께 모이면 놀라운 결과를 만듭니다.

일반적 증상:

• 동일한 시간 계산이 여러 흐름에 복사되어 수정이 모든 복사본에 반영되지 않습니다.
• 일시정지, 재개, 재할당, 상태 전환, 주말 vs 영업시간 같은 엣지 케이스가 빠집니다.
• 두 경로가 비슷한 타이머를 예약해 규칙이 두 번 발동합니다.
• 감사가 추측이 됩니다: “왜 이게 에스컬레이션됐나?”라고 묻는데 앱 전체를 읽어야 답을 찾을 수 있습니다.
• 작은 변경이 위험하게 느껴져 팀이 모델을 고치기보다 예외를 추가합니다.

목표는 예측 가능한 동작과 나중에 변경하기 쉬운 구조입니다: SLA 타이밍의 단일 진실 소스, 보고 가능한 명시적 브리치 상태, 그리고 시각적 로직을 뒤져야 하지 않는 에스컬레이션 단계.

실제로 필요한 SLA를 먼저 정의하세요

타이머를 만들기 전에 측정하려는 정확한 약속을 적으세요. 초기에 모든 시간을 한꺼번에 다루려다 보면 복잡해집니다.

일반적인 SLA 유형은 비슷하게 들리지만 측정하는 대상이 다릅니다:

• 최초 응답(First response): 사람이 보내는 첫 번째 의미 있는 답변까지의 시간.
• 해결(Resolution): 문제가 실제로 닫힐 때까지의 시간.
• 고객 대기(Waiting on customer): 차단되어 있는 동안은 계산하고 싶지 않은 시간.
• 내부 이관(Internal handoff): 특정 큐에 티켓이 머물 수 있는 시간.
• 재오픈 SLA(Reopen SLA): “닫힘” 상태가 다시 열렸을 때의 동작.

다음으로 ‘시간’이 무엇을 의미하는지 결정하세요. **달력 시간(calendar time)**은 24/7을 계산하고, **근무 시간(working time)**은 정의된 영업시간(예: 월-금 9-18)만 계산합니다. 실제로 근무 시간이 필요하지 않다면 초기에 피하세요. 휴일, 타임존, 부분 일수 같은 엣지 케이스를 추가합니다.

그다음 일시정지(pause)에 대해 구체적으로 정하세요. 일시정지는 단순히 “상태가 바뀌었다”가 아니라 소유권이 있는 규칙입니다. 누가 일시정지할 수 있나요(에이전트만, 시스템만, 고객 행동으로)? 어떤 상태들이 일시정지하나요(Waiting on Customer, On Hold, Pending Approval)? 무엇이 재개시키나요? 재개 시 남은 시간부터 이어가나요 아니면 타이머를 재시작하나요?

마지막으로 브리치가 제품 관점에서 무엇을 의미하는지 정의하세요. 브리치는 저장하고 쿼리할 수 있는 구체적 항목이어야 합니다. 예:

• 브리치 플래그(참/거짓)
• 브리치 타임스탬프(언제 기한을 놓쳤는지)
• 브리치 상태(Approaching, Breached, Resolved after breach)

예: “최초 응답 SLA 브리치”는 티켓에 Breached 상태를 설정하고 breached_at 타임스탬프와 에스컬레이션 레벨을 1로 설정하는 것을 의미할 수 있습니다.

SLA를 흩어진 조건이 아닌 명시적 상태로 모델링하세요

SLA 타이머와 에스컬레이션을 읽기 쉽도록 유지하려면 SLA를 작은 상태 기계(state machine)처럼 취급하세요. 진실(truth)이 작은 검사들(if now > due, 우선순위가 높음, 마지막 답장 비어있음 등)에 퍼져 있으면 시각적 로직이 빠르게 복잡해지고 작은 변경이 문제를 일으킵니다.

짧고 합의된 SLA 상태 집합으로 시작하세요. 많은 팀에 적합한 상태 예시는 다음과 같습니다:

• On track
• Warning
• Breached
• Paused
• Completed

단일 breached = true/false 플래그는 거의 충분하지 않습니다. 어떤 SLA가 브리치되었는지(최초 응답 vs 해결), 현재 일시정지인지, 이미 에스컬레이션을 했는지 같은 문맥이 필요합니다. 그 문맥이 없으면 사람들은 주석, 타임스탬프, 상태 이름에서 의미를 재파생하기 시작하고 로직이 취약해집니다.

상태를 명시적으로 만들고 그것을 설명하는 타임스탬프를 저장하세요. 그러면 결정은 단순해집니다: 평가기가 레코드를 읽고 다음 상태를 결정하면 나머지는 그 상태에 반응합니다.

함께 저장하면 유용한 필드:

• started_at 및 due_at (어떤 시계를 돌리고 있으며 언제 기한인가?)
• breached_at (언제 실제로 선을 넘었나?)
• paused_at 및 paused_reason (왜 시계가 멈췄나?)
• breach_reason (어떤 규칙이 브리치를 트리거했는지 설명)
• last_escalation_level (동일 레벨에 중복 알림을 보내지 않기 위해)

예: 티켓이 “Waiting on customer”로 이동하면 SLA 상태를 Paused로 설정하고 paused_reason = "waiting_on_customer"를 기록해 타이머를 중지하세요. 고객이 답장하면 재개하면서 새 started_at을 설정하거나 due_at을 재계산해 다시 시작하세요. 여러 조건을 찾아 헤맬 필요가 없습니다.

조직에 맞는 에스컬레이션 사다리를 설계하세요

에스컬레이션 사다리는 SLA 타이머가 임박하거나 브리치됐을 때 무엇을 할지에 대한 명확한 계획입니다. 실수는 조직도를 통째로 워크플로우에 복사하는 것입니다. 멈춘 항목을 다시 움직이게 할 수 있는 최소한의 단계 집합을 원합니다.

많은 팀이 사용하는 간단한 사다리: 담당 에이전트(Level 0)에게 먼저 알림을 보내고, 그다음 팀 리드(Level 1)를 끌어들이며, 마지막으로 매니저(Level 2)에게 갑니다. 이 방식은 실제로 작업을 할 수 있는 사람부터 시작하고 필요할 때만 권한을 올리기 때문에 효과적입니다.

워크플로우 에스컬레이션 규칙을 유지보수 가능하게 하려면 에스컬레이션 임계값을 하드코딩하지 말고 데이터로 저장하세요. 테이블이나 설정 객체에 넣어두면 정책이 바뀔 때 여러 워크플로우를 편집할 필요 없이 한 곳만 수정하면 됩니다(예: “첫 리마인더 30분 후”, “2시간 후 리드로 에스컬레이션”).

에스컬레이션을 유용하게, 소음은 줄이기

에스컬레이션이 너무 자주 발생하면 루머성 스팸이 됩니다. 각 단계가 목적을 갖도록 가드레일을 추가하세요:

• 재시도 규칙(예: Level 0에 한 번 더 재전송)
• 쿨다운 창(예: 알림 전송 후 60분 동안 추가 알림을 보내지 않음)
• 중지 조건(항목이 규정 준수 상태로 이동하면 향후 에스컬레이션 취소)
• 최대 레벨 설정(Level 2 이상은 사람의 수동 트리거가 있어야 함)

에스컬레이션 후 누가 소유하는지 결정하세요

알림만으로는 소유권이 불분명하면 멈춘 작업을 해결하지 못합니다. 티켓이 계속 에이전트에게 남는지, 리드에게 재할당되는지, 아니면 공유 큐로 가는지 소유권 규칙을 미리 정의하세요.

예: Level 1 에스컬레이션 후 팀 리드에게 재할당하고 원래 에이전트는 워처(watcher)로 두세요. 이렇게 하면 누가 다음에 조치해야 하는지 명확해지고 항목이 사람들 사이를 왔다 갔다 하는 것을 방지합니다.

유지보수 가능한 패턴: 이벤트, 평가기, 액션

SLA 타이머와 에스컬레이션을 유지보수 가능하게 유지하는 가장 쉬운 방법은 이를 이벤트, 평가기(evaluator), 액션의 세 부분으로 다루는 것입니다. 이렇게 하면 시간 로직이 “if time > X” 검사 수십 군데로 퍼지는 것을 막을 수 있습니다.

1) 이벤트: 무슨 일이 일어났는지 기록만 하세요

이벤트는 타이머 수학을 포함하면 안 됩니다. "무엇이 바뀌었나?"에 답해야지 "무엇을 해야 하나?"를 포함하면 안 됩니다. 일반적 이벤트 예시는 티켓 생성, 에이전트 답장, 고객 답장, 상태 변경, 수동 일시정지/재개 등입니다.

이런 사실을 타임스탬프와 상태 필드로 저장하세요(예: created_at, last_agent_reply_at, last_customer_reply_at, status, paused_at).

2) 평가기: 시간 계산과 상태 설정을 한 곳에서

모든 이벤트 이후와 정기 일정에서 실행되는 하나의 “SLA 평가기” 단계를 만드세요. 이 평가기가 due_at과 남은 시간을 계산하는 유일한 장소가 되게 하세요. 현재 사실을 읽고 기한을 재계산하여 sla_response_state나 sla_resolution_state 같은 명시적 SLA 상태 필드를 씁니다.

이곳에서 브리치 상태 모델링이 깔끔하게 유지됩니다: 평가기는 논리 숨김 대신 OK, AtRisk, Breached 같은 상태를 설정합니다.

3) 액션: 시간 계산이 아닌 상태 변경에 반응하세요

알림, 할당, 에스컬레이션은 상태가 변경될 때만 트리거되어야 합니다(예: OK -> AtRisk). 메시지 전송을 SLA 상태 업데이트와 분리해두면 계산 부분을 건드리지 않고도 누가 알림을 받는지 변경할 수 있습니다.

시각적 로직에서 타이머와 에스컬레이션을 단계별로 구축하기

유지보수 가능한 설정은 보통 이렇게 보입니다: 레코드의 몇 가지 필드, 작은 정책 테이블, 그리고 무엇을 할지 결정하는 하나의 평가기.

1) 시간 로직이 한 곳에 있도록 데이터 설정하기

SLA를 소유하는 엔티티(티켓, 주문, 요청)에 시작하세요. 명시적 타임스탬프와 하나의 “현재 SLA 상태” 필드를 추가하세요. 단순하고 예측 가능하게 유지합니다.

그다음 정책 테이블을 추가해 규칙을 설명하세요. 간단한 버전은 우선순위별(P1, P2, P3)로 한 행씩 두고 목표 분(target minutes)과 에스컬레이션 임계값(예: 80%에서 경고, 100%에서 브리치) 열을 두는 것입니다. 이렇게 하면 한 레코드 변경으로 정책을 바꿀 수 있고 여러 워크플로우를 편집할 필요가 없습니다.

2) 여러 타이머 대신 스케줄러 평가기 실행

각각의 타이머를 만들지 말고 정기적으로 항목을 확인하는 하나의 스케줄러 프로세스를 사용하세요(엄격한 SLA는 분 단위, 많은 팀은 5분 단위). 스케줄러는 하나의 평가기를 호출해 다음을 수행합니다:

• 아직 활성(닫히지 않은) 레코드를 선택
• "지금 vs 기한"을 계산해 다음 상태를 도출
• 다음 검사 시점을 계산(너무 자주 재검사하지 않기 위해)
• sla_state와 next_check_at을 기록

이렇게 하면 디버그할 대상이 많은 타이머가 아니라 하나의 평가기가 되어 이해하기 쉬워집니다.

3) 액션은 엣지 트리거로 만들기(변경 시에만)

평가기는 새 상태와 함께 그 상태가 변경되었는지 여부를 출력해야 합니다. 상태가 바뀔 때만 메시지나 작업을 발행하세요(예: ok -> warning, warning -> breached). 레코드가 한 시간 동안 breached 상태로 남아 있으면 매 분마다 알림을 보내고 싶지는 않을 것입니다.

실용적 패턴: sla_state와 last_escalation_level을 저장하고 새로 계산한 값과 비교한 뒤에 메시지(이메일/SMS/Telegram)를 보내거나 내부 작업을 생성하세요.

일시정지, 재개, 상태 변경 처리

일시정지는 시간 규칙이 보통 엉키는 지점입니다. 명확히 모델링하지 않으면 SLA가 멈췄어야 할 때 계속 돌거나, 누군가가 잘못된 상태를 클릭해 리셋될 수 있습니다.

간단한 규칙: 하나의 상태(또는 소수 상태)만 시계를 일시정지하게 하세요. 흔한 선택은 Waiting for customer입니다. 티켓이 그 상태로 들어가면 pause_started_at 타임스탬프를 저장하세요. 고객이 답장하고 상태를 벗어나면 pause_ended_at을 기록하고 해당 기간을 paused_total_seconds에 더하세요.

단일 누적 카운터만 두지 마세요. 각 일시정지 구간(start, end, 누가/무엇이 트리거했는지)을 캡처해 감사 추적을 남기세요. 나중에 누군가가 왜 케이스가 브리치됐는지 묻는다면 "고객 대기 때문에 19시간 머물렀다"는 것을 보여줄 수 있어야 합니다.

재할당과 일반 상태 변경은 시계를 재시작하면 안 됩니다. SLA 타임스탬프는 소유권 필드와 분리하세요. 예: sla_started_at과 sla_due_at은 생성 시(또는 SLA 정책 변경 시) 한 번 설정되고 재할당은 assignee_id만 업데이트합니다. 평가기는 이제 경과 시간을 이렇게 계산할 수 있습니다: now - sla_started_at - paused_total_seconds.

SLA 타이머와 에스컬레이션을 예측 가능하게 유지하는 규칙:

• 일시정지는 명시적 상태(예: Waiting for customer)에서만 발생하게 하세요, 소프트 플래그로 일시정지하지 마세요.
• 재개는 그 상태를 벗어날 때만 발생하게 하세요, 임의의 수신 메시지에 반응하지 마세요.
• 재할당으로 SLA를 리셋하지 마세요; 라우팅으로 취급하세요.
• 수동 오버라이드를 허용하되 이유가 필요하고 가능한 사람을 제한하세요.
• 모든 상태 변경과 일시정지 창을 로그로 남기세요.

예시 시나리오: 응답 및 해결 SLA가 있는 지원 티켓

설계 테스트 방법은 간단합니다. 최초 응답 30분, 전체 해결 8시간인 두 SLA를 가진 지원 티켓을 가정하세요. 로직이 화면과 버튼에 흩어지면 여기서 자주 깨집니다.

각 티켓이 다음을 저장한다고 가정합니다: state(New, InProgress, WaitingOnCustomer, Resolved), response_status(Pending, Warning, Breached, Met), resolution_status(Pending, Warning, Breached, Met), 그리고 created_at, first_agent_reply_at, resolved_at 같은 타임스탬프.

현실적인 타임라인 예:

• 09:00 티켓 생성(New). 응답 타이머와 해결 타이머 시작.
• 09:10 에이전트 A에게 할당(두 SLA 모두 Pending 상태 유지).
• 09:25 아직 에이전트 답장 없음. 응답이 25분에 Warning으로 전환.
• 09:40 여전히 답장 없음. 응답이 30분에 Breached로 전환.
• 09:45 에이전트가 답장. 응답은 Met로 변경(브리치였더라도 브리치 기록은 남김).
• 10:30 고객이 추가 정보를 보냄. 티켓이 InProgress로, 해결 타이머는 계속됨.
• 11:00 에이전트가 질문. 티켓이 WaitingOnCustomer로 가고 해결 타이머 일시정지.
• 14:00 고객이 응답. 티켓이 InProgress로 돌아오고 해결 타이머 재개.
• 16:30 티켓 해결. 총 활성 시간이 8시간 이하이면 resolution은 Met, 그렇지 않으면 Breached.

에스컬레이션은 상태 전이에 따라 하나의 명확한 체인으로 유지하세요. 예: 응답이 Warning이 되면 담당 에이전트에게 알림. Breached가 되면 팀 리드에게 알리고 우선순위를 올립니다.

각 단계에서 동일한 소규모 필드 집합을 업데이트해 이해하기 쉽게 하세요:

• response_status나 resolution_status를 Pending, Warning, Breached, Met으로 설정.
• *_warning_at 및 *_breach_at 타임스탬프를 한 번 쓰고 덮어쓰지 않음.
• escalation_level(0,1,2)을 증가시키고 escalated_to(Agent, Lead, Manager)를 설정.
• 누가 알림을 받았는지와 이벤트 타입을 sla_events 로그에 남김.
• 필요하면 UI와 리포트에 반영되도록 priority와 due_at을 설정.

핵심은 Warning과 Breached가 명시적 상태라는 점입니다. 데이터에서 볼 수 있고, 감사를 할 수 있으며, 나중에 숨겨진 타이머 체크를 찾느라 헤매지 않고 사다리를 변경할 수 있습니다.

흔한 함정과 회피 방법

SLA 로직은 흩어질 때 더러워집니다. 버튼 하나에 시간 검사를 넣고, 다른 곳에 조건부 알림을 두면 곧 아무도 왜 티켓이 에스컬레이션됐는지 설명하지 못합니다. SLA 타이머와 에스컬레이션을 작은 중앙 로직으로 유지해 모든 화면과 액션이 그것을 참조하게 하세요.

흔한 함정은 많은 곳에 시간 검사를 박는 것입니다(UI 화면, API 핸들러, 수동 액션). 해결책은 하나의 평가기에서 SLA 상태를 계산하고 결과를 레코드에 저장하는 것입니다. 화면은 상태를 읽기만 하고 스스로 계산하지 않아야 합니다.

다른 함정은 서로 다른 시계를 사용하는 타이머들입니다. 브라우저가 "생성 후 분 수"를 계산하고 백엔드가 서버 시간을 사용하면 슬립, 타임존, 섬광 변화에서 엣지 케이스가 생깁니다. 에스컬레이션을 트리거하는 모든 것에는 서버 시간을 사용하는 것이 좋습니다.

알림도 빠르게 소음이 될 수 있습니다. “매분 확인해서 늦었으면 보낸다”면 사람들이 매분 스팸을 받게 됩니다. 상태 전이에 메시지를 묶으세요: "warning sent", "escalated", "breached". 그러면 단계별로 한 번씩만 보내고 무슨 일이 있었는지 감사할 수 있습니다.

영업시간 로직은 또 다른 복잡성의 원천입니다. 모든 규칙에 각자 "주말이면..." 분기가 들어가면 업데이트가 괴로워집니다. 영업시간 수학을 한 함수(또는 공유 블록)로 모아 "지금까지 소비된 SLA 분"을 반환하게 하고 재사용하세요.

마지막으로 브리치를 다시 계산만 하지 마세요. 발생 순간을 저장하세요:

• 브리치를 처음 감지했을 때 breached_at을 저장하고 덮어쓰지 마세요.
• escalation_level과 last_escalated_at을 저장해 액션을 멱등하게 만드세요.
• 반복 알림을 방지하기 위해 notified_warning_at 같은 필드를 저장하세요.

예: 티켓이 10:07에 "Response SLA breached"가 됐으면 breached_at = 10:07을 저장하세요. 만약 재계산만 한다면 이후 상태 변경이나 일시정지/재개 버그로 브리치 시점이 10:42로 바뀔 수 있습니다. breached_at을 저장하면 보고와 사후조사가 일관됩니다.

유지보수 가능한 SLA 로직을 위한 빠른 체크리스트

타이머와 알림을 추가하기 전에 한 번 통독해 한 달 뒤에도 규칙을 읽기 쉽도록 만드세요.

• 모든 SLA에 명확한 경계가 있다. 시계를 시작하는 이벤트, 멈추는 이벤트, 일시정지 규칙, 브리치로 간주되는 기준을 적으세요. 시계를 시작하는 단일 이벤트를 못 가리키면 로직이 여기저기로 퍼집니다.
• 에스컬레이션은 사다리이지 알림의 더미가 아니다. 각 에스컬레이션 레벨에 대해 임계값(예: 30분, 2시간, 1일), 수신자, 쿨다운(스팸 방지), 최대 레벨을 정의하세요.
• 상태 변경은 문맥과 함께 기록된다. SLA 상태가 바뀔 때(Running, Paused, Breached, Resolved), 누가 트리거했는지, 언제 왜인지 저장하세요.
• 스케줄된 검사는 두 번 실행되어도 안전해야 한다. 평가기는 멱등적으로 설계해 같은 레코드에 대해 다시 실행되어도 중복 에스컬레이션이나 중복 메시지를 만들지 않아야 합니다.
• 알림은 원시 시간 계산이 아니라 전이에 의해 전송된다. "now - created_at > X"가 true라고 해서 보내지 말고 상태가 바뀔 때 전송하세요.

실용적 테스트: 거의 브리치될 티켓 하나를 골라 타임라인을 재생해 보세요. 각 상태 변경에서 무슨 일이 일어날지 전체 워크플로우를 읽지 않고 설명할 수 없다면 모델이 너무 흩어져 있는 것입니다.

다음 단계: 구현, 관찰, 그리고 다듬기

작은 유용한 조각부터 만드세요. 하나의 SLA(예: 최초 응답)와 하나의 에스컬레이션 레벨(예: 팀 리드에게 알림)부터 시작하면 종이 위의 완벽한 설계보다 일주일의 실제 사용에서 더 많은 것을 배웁니다.

임계값과 수신자는 로직이 아닌 데이터로 유지하세요. 분·시간, 영업시간 규칙, 알림 수신자, 어떤 큐가 케이스를 소유하는지 등을 테이블이나 설정 레코드에 넣으면 비즈니스가 숫자와 라우팅만 바꿔 워크플로우는 안정적으로 유지할 수 있습니다.

간단한 대시보드 뷰를 초기 단계에 계획하세요. 큰 분석 시스템이 필요 없고 현재 무슨 일이 일어나고 있는지(온트랙, 워닝, 브리치, 에스컬레이션)를 공유할 수 있는 화면이면 충분합니다.

노코드 워크플로우 앱에서 이 작업을 한다면 데이터, 로직, 정기 평가기를 하나의 곳에서 모델링할 수 있는 플랫폼을 고르는 것이 도움이 됩니다. 예를 들어 AppMaster (appmaster.io)는 데이터베이스 모델링, 시각적 비즈니스 프로세스, 프로덕션용 앱 생성을 지원해 “이벤트, 평가기, 액션” 패턴에 잘 맞습니다.

안전하게 다듬는 순서:

1. Level 1이 잘 작동하면 레벨을 하나만 더 추가하세요.
2. 한 개의 SLA에서 두 개(SLA 응답과 해결)로 확장하세요.
3. 일시정지/재개 규칙 추가(Waiting on customer, On hold).
4. 알림 정교화(중복 제거, 조용 시간, 올바른 수신자).
5. 주간 검토: 흐름을 다시 짜지 말고 데이터에서 임계값을 조정하세요.

작은 버전을 먼저 만들고 실제 피드백과 실제 티켓으로 키우세요.