우리 팀에 룰 엔진이 필요한 5가지 신호

룰 엔진이 필요 없을 수도 있습니다

먼저 이것부터. 비즈니스 로직이 1년에 한 번 바뀌고, if문 하나로 끝나는 수준이라면 룰 엔진은 과합니다.

그런데 아래 내용을 읽으면서 "아 우리 팀 얘기인데" 싶다면, 아마 이미 필요한 상태일 겁니다.

1. 규칙 하나 바꾸는 데 배포를 해야 한다

가장 뚜렷한 신호입니다. 기획자가 할인 기준을 10만원에서 7만5천원으로 바꿔달라고 합니다.

그러면 개발자가 코드를 열고, 값을 찾고, PR 올리고, 리뷰 받고, 스테이징에 올리고, 확인하고, 프로덕션에 배포합니다. 여기까지 며칠. 길면 몇 주.

실제로 바뀐 건? 숫자 하나.

새 기능을 만드는 것도 아닌데 배포까지 해야 한다면, 뭔가 구조가 잘못된 겁니다. 비즈니스 규칙은 비즈니스 속도에 맞춰 바뀌어야 하는데, 코드 배포는 개발 일정에 묶여 있습니다. 이 두 속도는 원래 안 맞습니다.

룰 엔진은 이 둘을 분리합니다. 규칙은 바로 바꾸고, 코드는 건드리지 않습니다.

2. 배포하고 나서야 문제를 안다

가격 규칙을 바꿨습니다. 별거 아닌 것 같았습니다. 프로덕션에 나갔습니다. 세 시간 뒤, 고객 문의가 밀려옵니다. 할인받아야 할 사람이 못 받고 있거나, 받으면 안 되는 사람이 받고 있습니다.

문제는 규칙을 바꾼 게 아니라, 바꾸기 전에 확인할 방법이 없었다는 겁니다. "이 규칙을 적용하면 지난주 거래 1만 건은 어떻게 됐을까?" 이런 질문을 던질 수 있는 환경이 없었습니다.

여기서 일반적인 룰 엔진과 시뮬레이션이 있는 룰 엔진의 차이가 갈립니다. 대부분은 규칙 정의와 실행까지만 해줍니다. 실제 데이터로 영향을 미리 확인해주는 건 거의 없습니다.

"별거 아닌" 규칙 변경 때문에 사고가 난 적이 있다면, 이게 그 신호입니다.

3. 비즈니스 로직이 여기저기 흩어져 있다

가격 규칙이 어디에 있나요? 결제 서비스? 프로모션 서비스? 공통 모듈? 아니면 누군가 메신저로 공유한 엑셀 파일?

이렇게 흩어져 있으면 전체 그림을 아는 사람이 없습니다. 결제 쪽에서 VIP 할인 20%를 적용했는데, 프로모션 쪽에서 그걸 모르고 할인을 또 겹칩니다. 결과: 고객이 20%가 아니라 40% 할인을 받습니다.

룰 엔진을 쓰면 모든 규칙이 한 곳에 모입니다. 여러 규칙이 동시에 해당될 때 어떤 걸 적용할지도 명확하게 정할 수 있습니다.

4. 30분이면 되는 일을 몇 주째 기다린다

이건 조직 차원의 신호입니다. 기획자한테 "이 숫자 좀 바꿔주세요", "이 조건 하나 추가해주세요" 같은 요청이 쌓여 있습니다. 개발자가 실제로 손대면 30분이면 끝납니다.

그런데 현실은 다릅니다. 이번 스프린트에 넣어야 하고, 다른 작업이랑 순서를 정해야 하고, 코드 리뷰도 받아야 하고, 배포 일정도 잡아야 합니다. 그러다 보면 몇 주가 지나갑니다.

그사이에 뭐가 벌어지냐면 — 월요일에 시작하기로 한 프로모션이 다음 주에나 켜집니다. 이번 분기 안에 바꿔야 하는 규정 관련 규칙이 다른 개발 작업 때문에 밀립니다.

룰 엔진은 이런 종류의 변경에서 개발팀이 매번 끼어들 필요를 없애줍니다. 기획팀이나 운영팀이 직접 바꾸거나, 최소한 개발자가 배포 없이 콘솔에서 몇 분 만에 처리할 수 있습니다.

5. if-else가 아무도 못 건드리는 상태가 됐다

모든 코드베이스에 하나쯤 있습니다. 조건문이 끝없이 중첩된 800줄짜리 메서드. 아무도 건드리고 싶어 하지 않는 그 파일입니다.

버그 고칠 때마다 분기가 하나씩 추가됩니다. 예외 상황이 생길 때마다 조건이 늘어납니다. 처음 만든 사람은 2년 전에 퇴사했습니다. 주석은 현실과 다릅니다. 테스트는 절반 정도만 커버합니다.

비즈니스 규칙이 코드 안에서 계속 자라면 이렇게 됩니다. 로직이 코드에 엉켜붙어서, 고치려면 다른 데가 깨질 수 있습니다. 전체 흐름을 완벽히 아는 사람이 없으니까요. 그래서 시간이 갈수록 코드는 나빠지고, 팀은 고치는 대신 피해 다닙니다.

규칙을 룰 엔진으로 빼낸다고 복잡함이 사라지지는 않습니다. 하지만 두 가지가 달라집니다. 규칙이 한눈에 보이고(조건, 우선순위 포함), 주변 코드를 건드리지 않고도 바꿀 수 있게 됩니다.

룰 엔진이 해결 못 하는 것

룰 엔진은 잘못된 비즈니스 로직을 고쳐주지 않습니다. 가격 체계 자체가 잘못됐다면, 룰 엔진에 옮겨봤자 잘못된 게 더 잘 보일 뿐입니다.

조직 문제도 고쳐주지 않습니다. 규칙을 어떻게 정해야 하는지 아무도 합의를 못 하는 상황이라면, 문제는 개발이 아니라 의사결정입니다.

룰 엔진이 해결하는 건 이겁니다 — "이 규칙 바꾸기로 했다"에서 "프로덕션에 반영됐다"까지 걸리는 시간. 이게 며칠이나 몇 주라면, 룰 엔진이 몇 분으로 줄여줍니다.

3개 이상 해당된다면

모든 룰 엔진을 비교할 필요 없습니다. 배포 전에 변경을 검증할 수 있는 것부터 시작하세요. 진짜 위험은 거기에 있으니까요.

LexQ는 시뮬레이션이 내장된 룰 엔진입니다. 규칙을 비주얼로 만들고, 실제 데이터로 테스트하고, 확신이 생겼을 때 배포하세요. 무료 플랜에 월 1,000회 실행이 포함됩니다.

→ lexq.io에서 시작하기 → 시뮬레이션이 왜 중요한지 → 룰 엔진 비교: GoRules vs Nected vs LexQ