Orbit · 가이드 · Sentinel
Sentinel
운영 감시
단순 알림 시스템이 아닙니다. Field 흐름을 회사 규정·마감·패턴과 대조하여 증거 기반 운영 사건을 생성하고, 해결까지 추적합니다.
Section 01
한 장면 — 승인 없는 거래가 발생한 순간
어떤 감시 시스템이든 결국 하나의 질문으로 돌아옵니다: 놓치면 안 되는 것을 놓치고 있지 않은가? 개념 설명 전에, 한 장면부터 봅니다.
ERP에서 3,200만 원 규모 외주 발주가 등록된다. 승인 결재란: 비어 있음.
Sentinel이 Policy Dictionary를 조회한다 — "5백만 원 이상 외주 발주: 팀장+본부장 사전 승인 필수."
OrbitAlert 생성: 정책 위반 — 승인 누락 발주. 관련 증거(발주서, 정책 조항, 승인 로그 부재)가 자동 첨부된다.
OrbitSentinelIncident로 승격. 심각도: Critical. 담당자: 구매팀장·내부통제 담당자에게 전달.
구매팀장이 사건을 확인. 소급 승인 또는 발주 취소를 선택해야 한다.
Sentinel이 없는 회사라면 이 발주는 월말 정산 때, 혹은 외부 감사 때 발견됩니다. 2주 뒤 맥락이 사라진 상태에서 "왜 승인 없이 진행됐나?"를 소급 추적해야 합니다.
Sentinel이 있는 회사라면 위반이 발생한 바로 그 순간, 증거가 뜨겁게 살아 있을 때 사건이 열립니다. 원인·대응·재발 방지까지 한 흐름에서 처리됩니다.
핵심 차이: 기존 알림 시스템은 "무언가 일어났다"를 알려주고 끝납니다. Sentinel은 무엇이 어떤 규정에 위배되었는지, 증거는 무엇인지, 누가 해결해야 하는지를 하나의 사건 구조 안에 엮습니다.
Section 02
Sentinel이란 무엇인가
Sentinel은 Orbit의 운영 감시 레이어입니다. Field 위에서 흐르는 업무 이벤트를 실시간으로 읽으며, 회사가 정한 규정·마감·패턴과 대조합니다. 이탈이 감지되면 단순 노티가 아니라 증거 기반 운영 사건(OrbitSentinelIncident)을 만듭니다.
단순 모니터링 도구와 Sentinel의 차이:
| 구분 | 알림 시스템 | Sentinel |
|---|---|---|
| 출력 | 텍스트 알림 한 줄 | 증거·정책·맥락이 결합된 운영 사건 |
| 추적 | 읽음/안읽음 | Open → Investigating → Resolved 생애주기 |
| 근거 | 없음 (관찰자가 직접 조사) | 관련 문서·로그·정책 조항 자동 첨부 |
| 연결 | 독립 (사일로) | Field·Policy Dictionary·Authority와 연동 |
| 학습 | 없음 | 해결된 사건이 Memento로 축적, 재발 패턴 인식 |
Sentinel의 목표는 명확합니다: 놓치면 안 되는 운영 이탈을 잡아내고, 해결까지 추적하는 것.
감시는 처벌이 아닙니다. Sentinel은 사람을 감시하는 도구가 아닙니다. 업무 흐름이 회사가 합의한 기준에서 벗어났을 때 그 사실을 빠르게 드러내는 도구입니다. "누가 잘못했는가"가 아니라 "어떤 이탈이 있고, 어떻게 바로잡을 것인가"에 초점합니다.
핵심 모델 구조
OrbitAlert
Field 이벤트와 정책 규칙이 충돌할 때 생성되는 최초 신호. 아직 사건은 아니며, 노이즈 필터링 대상.
OrbitSentinelIncident
Alert가 검증을 통과하면 승격되는 공식 운영 사건. 심각도·담당자·증거·해결 기한이 배정된다.
ObligationPack
사건 해결을 위해 충족해야 할 의무 묶음. 소급 승인, 원인 보고서 제출, 재발 방지 조치 등의 체크리스트.
Alert에서 Incident로의 승격은 자동이 아닙니다. 증거 충분성과 정책 매칭 확실도를 4축(적합도, 정밀도, 일반화, 단순성)으로 평가한 뒤에만 사건이 열립니다. 불확실한 신호는 Conductor로 넘겨 사람의 판단을 받습니다.
Section 03
무엇을 감시하는가 — 4가지 감시 영역
Sentinel은 모든 것을 감시하지 않습니다. 감시 영역을 네 가지로 나누고, 각 영역마다 판단 기준이 다릅니다.
정책 위반
Policy Dictionary에 정의된 규칙 위배. 승인 누락, 금액 한도 초과, 금지 행위 등.
마감 리스크
Field 단계가 기한 대비 지연 예상. 잔여 시간과 평균 처리 속도 비교.
처리 지연
특정 단계에 비정상적으로 오래 머무름. 병목 발생, 담당자 부재, 의존성 차단.
반복 이상
동일 패턴의 이탈이 반복 발생. 구조적 문제 신호. Memento 기록 기반 감지.
| 감시 영역 | 입력 소스 | 판단 기준 | 결과 예시 |
|---|---|---|---|
| 정책 위반 | Field 이벤트 + Policy Dictionary | 규칙 조건 매칭 | "승인 없는 5천만 원 발주" |
| 마감 리스크 | Field 단계 상태 + 마감일 | 잔여 시간 < 예상 처리 시간 | "세무 신고 D-1인데 대사표 미완성" |
| 처리 지연 | Field 단계 체류 시간 | 평균 대비 2σ 이상 초과 | "계약 검토가 8일째 정체" |
| 반복 이상 | Memento 과거 사건 이력 | 동일 유형 사건 N회 반복 | "같은 팀에서 3개월 연속 매입 누락" |
4축 품질이 여기서도 적용됩니다. 적합도 — 실제 이탈인가? 정밀도 — 오탐은 아닌가? 일반화 — 다른 케이스에도 같은 규칙이 적용되는가? 단순성 — 사건 설명을 담당자가 즉시 이해하는가? 이 네 축의 균형이 맞아야 Sentinel이 노이즈가 아닌 신뢰를 만듭니다.
연결되는 Orbit 레이어
| 연결 대상 | 역할 |
|---|---|
| Field | 감시 대상. 업무 이벤트와 단계 상태를 제공한다. |
| Policy Dictionary | 위반 판단의 기준선. 어떤 규칙이 적용되는지 정한다. |
| Authority | 사건의 담당자와 에스컬레이션 경로를 결정한다. |
| Memento | 과거 사건 기록. 반복 패턴 감지와 해결 방법 참조의 근거. |
| Conductor | 불확실한 Alert를 사람의 판단 큐로 전달한다. |
Section 04
사건이 해결되기까지
사건은 열리는 것보다 닫히는 것이 더 중요합니다. Sentinel의 가치는 "알았다"에서 끝나지 않고 "해결했다"까지 추적하는 데 있습니다.
감지 (Detection)
Field 이벤트가 감시 규칙과 충돌. OrbitAlert 생성. 이 단계에서 노이즈 필터링과 증거 수집이 동시에 진행된다.
승격 (Escalation)
증거 충분성 확인 후 OrbitSentinelIncident로 승격. 심각도 배정(Critical/High/Medium/Low), Authority 기반 담당자 지정.
조사 (Investigation)
담당자가 사건을 확인하고 원인을 파악한다. Sentinel은 관련 과거 사건(Memento)과 유사 패턴을 참고 자료로 제공한다.
해결 (Resolution)
ObligationPack의 모든 의무가 충족되면 사건이 닫힌다. 소급 승인, 원인 보고서, 재발 방지 조치 등. 불완전 해결은 닫히지 않는다.
축적 (Accumulation)
해결된 사건은 Memento에 기록된다. 다음에 유사한 이탈이 감지되면 "지난번엔 이렇게 해결했다"는 참조가 자동으로 붙는다.
Sentinel 사건 대시보드
승인 누락 외주 발주 — 3,200만 원
Q1 부가세 신고 마감 리스크 — D-1 대사표 미완
계약 검토 8일 정체 — 법무팀 병목
매입 세금계산서 3개월 연속 누락 — 구조적 패턴
사건은 증거로 열리고, 의무로 닫힙니다. 알림은 "확인" 버튼 하나로 사라지지만, Sentinel의 사건은 ObligationPack이 충족되어야만 닫힙니다. 이 차이가 "알았지만 방치"를 구조적으로 방지합니다.
Sentinel은 회사의 운영 면역 체계입니다. 한 건의 이탈을 잡는 것에서 끝나지 않고, 해결된 사건이 축적되면서 같은 이탈에 더 빠르게 반응하고, 구조적 원인을 드러내며, 결국 이탈 자체가 줄어드는 순환을 만듭니다.