198. 비즈니스 룰 엔진 (BRE, Business Rule Engine)

⚠️ 이 문서는 "VIP 고객이면 10% 할인해 줘라" 같은 수시로 바뀌는 회사의 영업 정책(Business Rule)을 자바(Java) 소스코드 안에 딱딱하게 하드코딩해 두어 마케팅 이벤트 때마다 개발자가 밤새워 코드를 고치고 서버를 껐다 켜야 했던 끔찍한 병목을 없애기 위해, 이런 '조건-결과(If-Then) 정책'들만 쏙 뽑아내어 별도의 통제소(엔진)에 모아두고, 현업 마케터가 브라우저(UI)에서 마우스로 할인율을 바꾸면 즉시 운영 서버에 실시간으로 반영되는 '비즈니스 룰 엔진(BRE)' 아키텍처를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 소스코드에서 비즈니스 로직(If-Then 규칙)만 핀셋으로 적출하여 외부로 빼낸 독립적인 심판관(엔진)이다. 코딩(IT의 영역)과 비즈니스 정책(현업의 영역)을 완벽하게 분리(Decoupling)하는 엔터프라이즈 아키텍처의 꽃이다.
  2. 가치: 내일 아침 9시부터 '골드 회원 무료 배송' 이벤트를 시작하고 싶은데, 개발팀에 요청하면 소스 수정하고 배포하는 데 3일이 걸린다. BRE를 도입하면 마케터가 퇴근길에 스마트폰으로 룰을 수정(저장)하는 즉시 내일 9시에 이벤트가 자동 릴리스되는 타임투마켓(Time-to-Market) 혁명이 일어난다.
  3. 기술 체계: 현업 사용자가 룰을 짜는 친숙한 **저작 도구(Rule Authoring UI)**와, 그 룰을 저장하는 룰 저장소(Repository), 그리고 애플리케이션이 결제할 때마다 룰 저장소를 찔러서 할인율 결괏값을 받아가는 초고속 **룰 실행 엔진(Inference Engine)**으로 구성된다.

Ⅰ. 하드코딩의 늪: 개발자와 현업의 영원한 싸움

규칙이 바뀔 때마다 서버를 재부팅해야 하는 것은 죄악이다.

  1. 스파게티 코드가 된 정책 (Hard-coding):
    • 보험 회사의 보험료 산출 코드를 보자.
    • if (나이 > 60 && 직업 == "위험직군") { 보험료 = 기본급 * 1.5; } else if ...
    • 이런 수천 줄의 if 문이 백엔드 코드 깊숙한 곳에 박혀있다.
  2. 변경의 고통 (IT 병목 현상):
    • 다음 달부터 정부 규제가 바뀌어 "65세 이상"으로 기준을 올려야 한다.
    • 현업 부서는 개발팀에 수정을 요청한다. 개발자는 수만 줄의 소스코드를 열어 혹시 다른 곳이 망가질까 덜덜 떨며 숫자 60을 65로 고치고, 테스트(QA)를 거쳐, 고객이 없는 새벽 2시에 서버를 내리고 업데이트(배포)한다. 이 간단한 숫자 하나 바꾸는 데 꼬박 1주일이 버려진다.

📢 섹션 요약 비유: 백화점 정문에 "VIP는 오늘 무료 주차"라는 팻말을 세우고 싶습니다. 그런데 이 팻말이 콘크리트 벽(소스코드)에 글씨가 조각(하드코딩)되어 있습니다. 내일 "VVIP만 무료 주차"로 정책을 바꾸려면, 인부(개발자)를 불러서 콘크리트를 다 부수고 다시 시멘트를 발라 조각해야 하는 끔찍하게 뻣뻣하고 느린 시스템입니다.

Ⅱ. BRE의 등장: 룰의 독립과 현업의 권력 쟁취

시멘트 벽을 부수고 디지털 전광판으로 바꿨다.

  1. 로직의 분리 (Separation of Concerns):
    • 개발자는 더 이상 Java 코드 안에 if (나이 > 60)이라는 숫자를 쓰지 않는다.
    • 대신 코드를 이렇게 짠다. 할인율 = BRE_엔진에게_물어보기(고객나이, 고객등급)
    • 앱 서버는 단지 고객 정보를 룰 엔진(BRE) 서버로 휙 던져주고 대답만 기다릴 뿐이다.
  2. BRMS (Business Rule Management System):
    • 현업(보험계리사, 마케터)은 개발자를 거치지 않고, 브라우저를 열어 BRE 관리자 화면(UI)에 접속한다. 엑셀처럼 생긴 화면에서 마우스로 [조건: 나이 > 65] [결과: 할증 1.5배] 라고 직접 타이핑하고 저장 버튼을 누른다.
    • 저장이 완료되는 0.1초 뒤부터, 앱 서버가 할인율을 물어보면 BRE 엔진은 즉시 새로 바뀐 65세 기준의 결과를 뱉어내어 서비스에 실시간으로 적용해 버린다. (서버 재부팅/배포 0회)
  3. 추론 엔진 (Inference Engine)의 속도:
    • BRE는 단순히 if 문을 수천 개 뭉쳐놓은 게 아니다. 수만 개의 룰이 거미줄처럼 얽혀있어도 Rete 알고리즘 같은 초고속 수학 엔진을 통해 "이 고객에게 해당하는 룰이 뭐지?"를 밀리초(ms) 단위로 완벽하게 스캔해 정답을 찾아낸다.

📢 섹션 요약 비유: 백화점 정문의 콘크리트 팻말을 철거하고, 중앙 통제실과 연결된 '스마트 LED 전광판(BRE)'을 달아놨습니다. 이제 백화점 매니저(현업)가 개발자를 부를 필요 없이, 자기 사무실 태블릿(BRMS UI)에서 "눈 오는 날 20% 할인!"이라고 타이핑만 치면 전광판 글씨가 0.1초 만에 실시간으로 바뀌며 전 층의 결제 포스기가 새 할인율로 계산을 시작하는 궁극의 시스템 분업입니다.

Ⅲ. 적용 도메인과 현대 아키텍처에서의 위상

모든 곳에 BRE를 쓸 필요는 없다. 돈이 되는 복잡한 곳에 꽂아라.

  1. 어디에 써야 하는가? (Sweet Spot):
    • 금융/보험: 대출 한도 승인 심사, 신용카드 부정 사용(FDS) 탐지 시스템 (매일 사기 패턴 룰이 바뀜)
    • 유통/커머스: 쿠폰 발급, 등급별 할인 프로모션, 장바구니 배송비 계산
    • 공통점은 "정책이 수시로, 아주 자주 바뀌며, 그 규칙이 수십~수백 가지로 복잡하게 얽혀있는 비즈니스"라는 것이다.
  2. 오버헤드의 경계 (Trade-off):
    • 단순한 웹사이트 로그인 로직에 BRE를 도입하면 배보다 배꼽이 커진다. 앱 서버가 BRE 서버와 통신(API 호출)하느라 불필요한 네트워크 지연(Latency)이 발생하기 때문이다.
  3. 오픈소스와 상용 솔루션:
    • 자바 진영에서는 Red Hat이 인수한 **Drools(드로스)**가 전 세계 오픈소스 BRE 시장을 사실상 천하 통일했다. 대형 은행들은 IBM ODM이나 FICO 같은 값비싼 상용 룰 엔진을 쓴다.

📢 섹션 요약 비유: 직원들의 밥값을 계산하는 단순한 일(변하지 않는 규칙)은 굳이 비싼 외부 회계 법인(BRE)에 물어볼 필요 없이 직접 엑셀로 짜는 게(하드코딩) 빠릅니다. 하지만 하루가 다르게 세법이 바뀌는 복잡한 연말정산(할인 프로모션, 대출 심사)은 앱 서버가 직접 풀려다간 머리가 터지니, 전용 세무사(BRE 엔진)에게 서류를 던져주고 깔끔한 결괏값만 받아오는 것이 가장 지혜로운 기업 시스템 구조입니다.