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

아무도 말하지 않는 문제

백엔드 엔지니어로 6년간 일하면서 수십 번은 본 장면이 있습니다. 기획자가 와서 말합니다. "할인 기준 금액을 10만원에서 7만5천원으로 바꿔야 해요."

간단해 보이죠? 하지만 실제로 벌어지는 일은 이렇습니다:

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

마지막 단계 — 숨을 죽이는 것 — 이것이 진짜 문제입니다. 어떤 일이 벌어질지 아무도 모릅니다. 할인 대상 고객이 얼마나 늘어나는지? 매출 영향은? 마케팅팀이 지난주에 시작한 VIP 프로모션과 충돌하지는 않는지?

답은 항상 같습니다: "프로덕션에서 확인하죠."

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

더 근본적인 문제는, 우리가 비즈니스 규칙을 코드 문제로 취급해왔다는 것입니다. 비즈니스 규칙은 코드 문제가 아닙니다. 코드 안에 살고 있을 뿐인 비즈니스 문제입니다.

가격 규칙이 Spring Boot 서비스에 하드코딩되어 있으면, 그걸 바꾸려면 소프트웨어 개발 전체 라이프사이클을 거쳐야 합니다. 하지만 비즈니스는 PR이나 배포 파이프라인으로 생각하지 않습니다. "고객이 VIP이고 장바구니가 10만원 이상이면 20% 할인해줘" — 이렇게 생각합니다.

이 불일치가 병목을 만듭니다. 모든 비즈니스 로직 변경에 엔지니어링이 게이트키퍼가 됩니다. 그리고 영향도를 미리 볼 방법이 없으니, 모든 변경은 리스크를 동반합니다.

"내장 시뮬레이션"이 실제로 의미하는 것

LexQ를 만들기 시작했을 때, 룰 엔진 부분은 어렵지 않았습니다. if-then 규칙을 정의하고 API로 실행하는 솔루션은 이미 많습니다. 어디에도 없었던 건 배포 전에 영향을 확인하는 기능이었습니다.

시뮬레이션이 실제로 어떻게 동작하는지 설명드리겠습니다:

드라이런 — 규칙을 작성한 후, 단일 입력으로 테스트합니다: "customer_tier=VIP, cart_total=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: sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"facts": {"customer_tier": "VIP", "cart_total": 100}}'

응답은 어떤 규칙이 매칭되었는지, 어떤 액션을 실행해야 하는지, 디버깅을 위한 전체 트레이스를 알려줍니다.

누구를 위한 것인가

LexQ가 모두에게 필요한 것은 아닙니다. 비즈니스 규칙이 1년에 한 번 바뀌고 if문 몇 개로 관리할 수 있다면, 룰 엔진은 필요 없습니다.

하지만 다음 중 하나라도 해당된다면, 아마 필요하실 것입니다:

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

앞으로 만들 것

LexQ는 핵심 기능과 함께 오늘 라이브입니다: 비주얼 규칙 빌더, Git 스타일 버저닝, 배포 전 시뮬레이션, A/B 테스트, 그리고 AI 에이전트 연동을 위한 55개 도구 MCP 서버.

확장하기 전에 첫 번째 고객들에게 제대로 맞추는 데 집중하고 있습니다. 시도해보고 싶으시다면, 무료 플랜에 월 1,000회 실행이 포함되어 있습니다 — 워크플로우에 맞는지 검증하기에 충분합니다.

→ lexq.io에서 무료로 시작하기 → docs.lexq.io에서 문서 읽기 → GitHub에서 CLI & MCP 서버