지난달 자동 승인된 요청을 오늘 다시 조회했더니 화면에 ‘승인 불가’라고 표시됩니다. 지난달과 오늘의 규칙이 달라졌기 때문인데, 시스템이 현재 규칙으로 과거 요청을 다시 평가한 결과를 원래 결정처럼 보여준 것입니다. 담당자 입장에서는 당시 왜 승인됐는지 증명할 방법이 없어집니다.
업무 규칙은 코드처럼 버전과 적용 시점이 필요합니다. 자동 승인, 등급 분류, 할인 적용, 작업 배정은 같은 입력이라도 어느 규칙으로 언제 평가했는지에 따라 결과가 달라질 수 있습니다.
결정 결과와 결정 근거를 함께 저장한다
한 번의 결정에는 사건 ID, 평가에 사용한 입력 스냅샷, 규칙 세트 버전, 평가 시각, 결과, 적용된 규칙 또는 이유 코드가 필요합니다. 고객 이름처럼 민감한 값을 무분별하게 복제하지 않도록 입력 스냅샷은 재현에 필요한 항목만 보존합니다. 입력 데이터 자체가 뒤에 수정될 수 있다면 원본 레코드 ID만 저장하는 것은 충분하지 않습니다. 당시 평가한 값이나 불변 버전을 참조해야 합니다.
규칙을 코드에 넣든 결정표로 관리하든 원리는 같습니다. Camunda의 DMN 결정표 안내처럼 비즈니스와 개발팀이 함께 읽을 수 있는 규칙 표현을 쓰면 조건 누락과 우선순위 충돌을 발견하기 쉽습니다. 다만 결정표를 쓴다는 사실만으로 승인·배포·버전 통제가 자동으로 되는 것은 아닙니다.
‘언제부터’ 적용되는지도 버전의 일부다
새 규칙을 배포한 시각과 업무상 시행 시각이 다를 수 있습니다. 예를 들어 11월 요금 규칙을 10월에 미리 배포하되 11월 계약부터 적용할 수 있습니다. 한 시스템에는 두 시각을 구분해 저장해야 합니다. 고객이 요청한 시각, 계약 발효일, 실제 평가 시각 중 무엇을 기준으로 규칙을 고르는지도 명시합니다. 규칙의 ‘최신 버전’을 무조건 호출하면 진행 중인 오래된 업무가 중간에 다른 기준으로 평가될 수 있습니다.
Camunda의 리소스 바인딩 설명은 프로세스가 최신 규칙을 따라갈지 특정 버전에 고정할지 선택하는 운영 문제를 보여줍니다. 도구와 관계없이 장기 진행 업무의 버전 고정 원칙을 결정해야 합니다.
새 규칙을 과거 데이터에 시험해 볼 수는 있다
규칙 변경 전에 최근 요청을 새 규칙으로 재생해 결과 차이를 보면 예상치 못한 승인·반려 증가를 찾을 수 있습니다. 이때 결과는 ‘시뮬레이션’으로 저장하고 원래 결정을 덮어쓰지 않습니다. 실제 과거 계약까지 소급 적용해야 한다면 별도 승인, 대상 범위, 통지, 조정 결과를 기록합니다. 단순 코드 배포가 과거 업무 상태를 소리 없이 바꾸어서는 안 됩니다.
테스트에는 정상 사례만 넣지 않습니다. 경계 금액, 조건 누락, 서로 겹치는 규칙, 적용 기간 첫날과 마지막 날, 조직별 예외, 규칙에 해당하지 않는 사례를 포함합니다. 예외 규칙이 일반 규칙을 덮을 때 우선순위도 검증합니다. 결정표의 각 행이 최소 한 번은 테스트되도록 케이스를 준비하면 변경 검토가 쉬워집니다.
배포와 운영의 통제 지점
규칙 변경은 작성자와 승인자를 나누고 변경 이유, 영향받는 고객군, 시행 시각을 남깁니다. 배포 후에는 이전 규칙과 새 규칙의 결과 분포, 수동 예외 건수, 평가 실패를 관찰합니다. 여러 서비스가 같은 결과를 소비한다면 모두가 동일한 결정 ID와 규칙 버전을 전달받아야 합니다. 주문 서비스는 새 규칙, 보고서는 옛 규칙을 쓰는 불일치를 막는 데 중요합니다.
실무 체크리스트
- 결정에 사용한 입력과 규칙 버전을 저장한다.
- 배포 시각과 업무 시행 시각을 구분한다.
- 진행 중인 업무의 규칙 고정 원칙을 정한다.
- 과거 재생 결과를 원래 결정과 분리한다.
- 경계·예외·우선순위 테스트를 배포 전에 실행한다.
자동화의 가치는 빨리 결정하는 것만이 아닙니다. 나중에도 같은 조건으로 같은 결론을 재현하고, 규칙이 달라졌다면 언제 왜 달라졌는지 설명하는 것까지 포함합니다.
#업무규칙 #규칙버전관리 #결정엔진 #DMN #업무자동화 #재현가능성 #감사추적 #B2BSaaS #소급적용 #시스템설계
