태그로 보기
비즈니스 규칙
글 10편
Cedar는 누가 접근할 수 있는지를 증명합니다. 어떤 결정이 내려질지는 누가 증명하나요?
Cedar는 Lean과 automated reasoning으로 권한 정책에 formal verification을 붙였습니다. 같은 일을 비즈니스 결정에 해낸 상용 룰 엔진은 아직 없습니다. 가격과 자격 판정과 사기 규칙을 증명하는 쪽이 왜 더 어려운 문제인지, 그리고 LexQ가 지금 어디에 서 있는지 적습니다.
비즈니스 결정에 형식 검증이 필요한 이유
테스트와 시뮬레이션은 이미 받아본 입력만 놓고 답합니다. 아직 아무도 보내지 않은 입력은 답의 범위 밖입니다. 도달 불가능한 규칙, 조용한 충돌, 아무 규칙도 덮지 않는 공백이 그 차이 안에 있습니다. 이 차이는 표본이 아니라 증명으로만 메워집니다.
감사 추적의 문제: 어떤 규칙이 어떤 결정을 내렸는지 증명하기
막힌 이체 하나가 로그에 남기는 건 한 줄뿐입니다. 몇 달 뒤 감사관이 이유를 묻지만 git은 답하지 못합니다. 코드의 이력은 남겨도 결정의 이력은 남기지 않기 때문입니다. 제대로 된 결정 감사 추적이 무엇을 기록하고, 왜 불변이어야 하는지 설명합니다.
의사결정 운영 플랫폼이란 무엇이고, 언제 필요한가
가격, 자격 판정, 사기 탐지 같은 비즈니스 결정은 자주 바뀌지만 애플리케이션 코드에 묶여 있습니다. 의사결정 운영 플랫폼은 이 결정에 고유한 라이프사이클을 줍니다. 이 카테고리가 무엇이고, 언제 필요한지 설명합니다.
If-Else로 짜여진 가격 로직은 언젠가 무너집니다. 그 전에 해야 할 일
If-else 가격 로직을 리팩토링한다고 근본 문제가 풀리진 않습니다. 구조적인 답은 더 우아한 클래스 계층이 아니라, 규칙을 데이터로 분리하고 변경을 시뮬레이션하는 것입니다.
애플리케이션 코드 수정 없이 비즈니스 규칙을 바꾸는 방법
비즈니스 로직이 배포 파이프라인의 모든 무게를 함께 짊어질 이유는 없습니다. 규칙을 코드에서 분리하는 세 가지 방법과 각각이 무너지는 지점을 짚어봅니다.
하드코딩 vs 룰 엔진: 전환 시점은 언제인가
if-else로 잘 돌아가던 코드가 어느 순간 짐이 되는 순간이 있습니다. 하드코딩한 비즈니스 규칙이 부채가 되는 시점과 마이그레이션 방법을 정리했습니다.
우리 팀에 룰 엔진이 필요한 5가지 신호
모든 팀에 룰 엔진이 필요한 건 아닙니다. 하지만 이 패턴들이 익숙하다면, 이미 늦었을 수 있습니다.
GoRules vs Nected vs LexQ: 2026년 룰 엔진 선택 가이드
세 가지 모던 룰 엔진의 실질적 비교: 아키텍처, 시뮬레이션, 가격, AI 연동. 각 제품의 강점과 한계를 솔직하게 분석합니다.
시뮬레이션이 내장된 룰 엔진을 만든 이유
모든 규칙 변경은 도박입니다. 6년간 팀들이 눈감고 배포하는 걸 지켜봤고, 프로덕션에 반영하기 전에 영향을 확인할 수 있는 룰 엔진을 만들었습니다.