시뮬레이션이 내장된 룰 엔진을 만든 이유

기준값 하나 바꾸는 데 배포 파이프라인 전체가 움직입니다

백엔드 엔지니어로 6년을 일하면서 같은 장면을 수십 번 봤습니다. 기획자가 슬랙에 한 줄을 남깁니다. "할인 기준 금액을 10만원에서 7만5천원으로 낮춰주세요."

코드에서 고칠 곳은 상수 한 줄입니다. 그런데 그 한 줄을 바꾸려면 아래 절차를 전부 밟습니다.

1. 개발자가 PR을 올립니다
2. 다른 개발자가 리뷰합니다
3. QA가 테스트합니다 (할 수도 있고 안 할 수도 있습니다)
4. 스테이징에 배포합니다
5. 누군가 몇 건을 손으로 확인합니다
6. 프로덕션에 배포합니다
7. 모두가 숨을 죽입니다

일곱 단계 중 진짜 문제는 앞의 여섯 개가 아닙니다. 마지막 하나입니다. 어떤 일이 벌어질지 아무도 모릅니다.

할인 대상 고객이 얼마나 늘어날까요? 매출에는 어떤 영향이 있을까요? 마케팅팀이 지난주에 시작한 VIP 프로모션과 충돌하지는 않을까요? 제가 이렇게 물어봤을 때 돌아온 답은 어디서나 같았습니다. "프로덕션에서 확인하죠."

규칙은 코드 문제가 아닙니다

배포 절차를 줄이는 것으로는 이 상황이 풀리지 않습니다. 원인은 더 아래에 있습니다. 우리가 비즈니스 규칙을 줄곧 코드 문제로 다뤄 왔다는 것입니다.

할인 기준을 정하는 쪽도 비즈니스이고, 이제 바꾸자고 말하는 쪽도 비즈니스입니다. 그런데 그 기준이 적혀 있는 자리는 코드뿐입니다. Spring Boot 서비스 어딘가에 가격 규칙이 하드코딩되어 있습니다. 결정하는 곳과 적어 두는 곳이 따로 놉니다.

일단 코드에 박히고 나면 그 숫자를 바꾸는 일에 소프트웨어 개발 라이프사이클 전체가 딸려 옵니다. 브랜치를 따고, 리뷰를 받고, 테스트를 돌리고, 배포하고, 롤백 계획까지 세웁니다.

비즈니스는 PR이나 배포 파이프라인 단위로 생각하지 않습니다. 이렇게 말합니다. "고객이 VIP이고 장바구니가 10만원 이상이면 20% 할인해줘."

사고 단위가 어긋나 있으면 병목이 생깁니다. 모든 비즈니스 로직 변경에서 엔지니어링이 관문 노릇을 하게 되고, 바꾸기 전에 영향을 확인할 방법이 없으니 모든 변경이 위험을 안고 갑니다.

이 문제가 가장 자주 터지는 자리는 가격 로직입니다. 조건문으로 쌓아 올린 가격 규칙이 어떻게 무너지는지는 따로 정리해 뒀습니다.

내장 시뮬레이션이 실제로 하는 일

LexQ를 만들기 시작했을 때 룰 엔진 부분 자체는 어렵지 않았습니다. if-then 규칙을 정의하고 API로 실행하는 솔루션은 시장에 이미 많습니다.

배포 전에 영향을 확인하는 기능이 어디에도 없었습니다.

첫 번째로 만든 것이 드라이런입니다. 규칙을 작성한 다음 입력 하나를 넣어 바로 돌려봅니다. loyaltyTier=VIP, purchaseSubtotalUsd=100을 넣으면 어떤 규칙이 실행되는지, 어떤 규칙이 충돌 해소에 걸려 차단되는지, 최종 출력이 무엇인지 발행하기 전에 확인합니다.

두 번째가 변경 영향 시뮬레이션입니다. 최근 1만 건의 실제 실행 데이터를 새 규칙 버전으로 다시 돌리고, 두 결과를 나란히 놓고 봅니다.

• 매칭률 변화: 몇 건이 더 매칭되고 몇 건이 빠지는지
• 지표 변화량: 총 할인 금액이 얼마나 달라지는지
• 규칙별 통계: 어떤 규칙이 더 많이 매칭되고 어떤 규칙이 덜 매칭되는지

비즈니스 규칙을 위한 스테이징 환경이라고 생각하시면 됩니다. 다만 6개월 전에 누군가 작성해 둔 테스트 픽스처를 돌리는 게 아니라, 실제로 들어왔던 데이터를 그대로 돌립니다.

규칙 A/B 테스트

시뮬레이션은 어떤 일이 벌어질지 알려줍니다. A/B 테스트는 실제로 어떤 일이 벌어지는지 알려줍니다.

LexQ는 라이브 트래픽을 두 규칙 버전으로 나눕니다. 현재 규칙에 90%, 대상 버전에 10%. 실제 결과를 측정하고 이긴 쪽을 정식 버전으로 승격합니다. 애플리케이션 코드는 한 줄도 고치지 않습니다.

프론트엔드 기능에서는 이미 표준 관행입니다. SaaS 회사라면 어디든 UI를 A/B 테스트합니다. 그런데 비즈니스 로직을 같은 방식으로 검증하는 팀은 드뭅니다. 왜일까요?

대부분의 룰 엔진이 지원하지 않기 때문입니다. Drools나 OPA 같은 프레임워크에는 이 개념 자체가 없습니다. 직접 운영하는 엔진과 관리형 서비스가 실제로 어디서 갈리는지 뜯어보면 이 공백이 어디서 생겨났는지도 함께 보입니다.

아키텍처 결정

LexQ는 관리형 API입니다. 애플리케이션 안에 끼워 넣는 라이브러리가 아닙니다.

의도한 선택입니다. 규칙이 애플리케이션 코드 안에 있으면, 그것을 룰 엔진 라이브러리로 관리하더라도 규칙을 바꿀 때 애플리케이션을 다시 배포해야 합니다. 룰 엔진은 정의를 코드에서 떼어낼 수 있습니다. 하지만 배포는 여전히 붙어 있습니다.

LexQ는 셋을 모두 떼어냅니다. 정의, 실행, 배포입니다. 콘솔에서 규칙을 정의하고, 시뮬레이션으로 확인하고, 곧바로 배포합니다. 애플리케이션이 할 일은 API 호출뿐입니다.

curl -X POST https://api.lexq.io/api/v1/execution/groups/{groupId} \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "facts": {
      "loyaltyTier": "VIP",
      "purchaseSubtotalUsd": 100.00
    },
    "context": {}
  }'

응답에는 매칭된 규칙, 실행해야 할 액션, 그리고 디버깅을 위한 전체 트레이스가 담깁니다.

트레이스는 디버깅에만 쓰이지 않습니다. 몇 달이 지난 뒤에 그때 왜 그 결정이 나왔는지 설명해야 할 때도 같은 기록에서 출발합니다. 어떤 규칙이 그 결정을 내렸는지 근거를 대야 할 때 무엇이 필요한지는 따로 썼습니다.

누구에게 필요한가

시스템의 비즈니스 결정을 책임지는 엔지니어링 팀을 위한 도구입니다.

모두에게 필요하지는 않습니다. 비즈니스 규칙이 1년에 한 번 바뀌고 if문 몇 개로 관리된다면 룰 엔진은 필요 없습니다. 반대로 다음 네 가지 중 하나라도 해당된다면 이야기가 달라집니다.

• 비즈니스 규칙이 바뀔 때마다 코드를 배포합니다. 가격 기준, 자격 조건, 수수료 계산. 작은 수정 하나에도 엔지니어링 시간이 들어갑니다.
• 프로덕션에 가기 전까지 영향을 모릅니다. 무해해 보이던 규칙 변경이 수천 건의 트랜잭션을 건드린 적이 있습니다.
• 비즈니스 로직이 여러 서비스에 흩어져 있습니다. '진짜' 규칙은 슬랙 메시지와 스프레드시트에 남아 있고, 단일 진실 공급원은 어디에도 없습니다.
• 제품팀과 운영팀이 몇 분이면 끝날 변경을 몇 주씩 기다립니다. 백로그에 "이 기준값 바꿔주세요" 티켓이 쌓여 갑니다.

앞으로 만들 것

LexQ는 엔지니어링 팀을 위한 의사결정 운영 플랫폼입니다. 지금 쓸 수 있는 기능은 비주얼 규칙 빌더, Git 스타일 버저닝, 변경 영향 시뮬레이션, A/B 테스트, 그리고 AI 에이전트 연동을 위한 MCP 서버입니다.

시뮬레이션은 그중 한 축입니다. 전부는 아닙니다. 의사결정 운영 플랫폼이 어디까지 감당해야 하고 언제부터 필요해지는지는 별도로 정리했습니다.

지금 우선순위는 기능을 늘리는 것보다 첫 번째 고객들에게 제대로 맞추는 쪽입니다. 무료 플랜에 월 1,000회 실행이 포함되어 있습니다. 여러분의 워크플로우에 맞는지 확인하기에는 충분한 양입니다.

→ lexq.io에서 무료로 시작하기