메인 콘텐츠로 건너뛰기
아래의 모든 용어는 LexQ의 API 응답, 콘솔 UI, 문서에서 사용되는 정식 명칭입니다.

정책 엔진

관련 정책 규칙들의 최상위 컨테이너입니다. 각 그룹은 고유한 우선순위, 활성화 모드, 배포 생명주기를 가집니다. 하나의 그룹에 여러 버전이 있을 수 있지만, 동시에 라이브 상태인 버전은 하나뿐입니다.
특정 시점의 정책 그룹 내 규칙들의 불변 스냅샷입니다.생명주기: DRAFTACTIVEARCHIVED
  • DRAFT: 편집 가능. 규칙을 추가, 수정, 삭제할 수 있습니다.
  • ACTIVE: 발행되어 잠금. 더 이상 수정할 수 없습니다. 배포 준비 완료.
  • ARCHIVED: 새 버전으로 대체됨. 읽기 전용 기록.
  • EXPIRED: effectiveTo 날짜를 지남. 스케줄러가 자동 전환.
조건과 하나 이상의 액션으로 구성된 개별 규칙입니다. 조건이 true로 평가되면 해당 액션이 실행됩니다. 규칙은 버전 내에서 우선순위 순서로 정렬됩니다 (0 = 최우선).
규칙이 주어진 요청에 적용되는지 결정하는 boolean 표현식입니다. 조건은 EQUALS, GREATER_THAN, CONTAINS, IN 등의 연산자를 사용하여 입력 팩트를 평가합니다. AND / OR 논리 연산자로 그룹을 중첩할 수 있습니다.
규칙의 조건이 충족될 때 실행되는 작업입니다. 내장 액션 타입: DISCOUNT, POINT, COUPON_ISSUE, BLOCK, NOTIFICATION, WEBHOOK, SET_FACT, ADD_TAG.

팩트와 스키마

실행 시 정책 엔진에 전달되는 단일 입력 데이터 필드입니다. 예: payment_amount, user_id, email. 팩트는 조건이 평가하고 액션이 사용하는 원시 데이터입니다.
팩트의 스키마 정의 — 키, 표시 이름, 데이터 타입, 필수 여부. 콘솔의 관리 → 팩트 정의에서 관리합니다. 시스템 팩트(예: payment_amount, user_id)는 계정 생성 시 자동 등록되며 삭제할 수 없습니다.
계정 생성 즉시 모든 테넌트에 등록되는 7개의 기본 팩트: user_id, payment_amount, phone_number, email, device_token, user_tags, total_point. 삭제할 수 없습니다.

배포 생명주기

버전을 DRAFT에서 ACTIVE로 전환합니다. 발행되면 버전이 잠기며 규칙과 설정을 수정할 수 없습니다. 발행만으로는 라이브 트래픽이 라우팅되지 않습니다. 별도의 배포 단계가 필요합니다.
ACTIVE 버전을 라이브 상태로 승격합니다. 배포 후 해당 버전이 프로덕션 트래픽을 수신하고 처리합니다. 정책 그룹당 하나의 버전만 라이브일 수 있습니다.
정책 그룹에서 라이브 버전을 제거합니다. 새 버전이 배포될 때까지 해당 그룹의 트래픽이 처리되지 않습니다.
정책 그룹을 이전에 배포된 버전으로 되돌립니다. 감사 목적으로 새로운 배포 레코드가 생성됩니다.

테스트와 분석

특정 정책 버전에 대한 단일 요청 테스트 실행입니다. 라이브 트래픽, 사용량 할당량, 실행 로그에 영향을 주지 않습니다. 외부 연동 호출은 기본적으로 모킹되지만, mockExternalCalls 파라미터로 활성화할 수 있습니다.
데이터셋(과거 또는 수동)을 정책 버전에 대해 일괄 테스트합니다. 매칭률, 규칙 통계, 베이스라인 버전과의 지표 비교를 생성합니다. 시뮬레이션 중 연동 호출은 항상 모킹됩니다.
API 호출로 트리거되는 라이브 정책 평가입니다. 각 실행은 고유 트레이스 ID와 함께 기록되며 실행 트레이스와 의사결정 트레이스를 포함합니다.
각 규칙의 조건 매칭 여부와 평가된 표현식을 보여주는 규칙별 기록입니다. 모든 실행의 감사 추적의 일부입니다.
각 규칙의 최종 선택 결과를 보여주는 규칙별 기록입니다 — 선택됨, Mutex에 의해 차단됨, 우선순위에서 밀림 등. 결정 이유를 설명하는 사유 코드를 포함합니다.
요청의 일정 비율을 대체 정책 버전으로 라우팅하는 트래픽 분할 메커니즘입니다. 실제 트래픽으로 프로덕션에서 버전 성능을 비교하는 데 사용됩니다.

규칙 실행 제어

버전 내 충돌 해결 메커니즘입니다. 동일한 mutexGroup 키를 공유하는 규칙들이 실행 경쟁을 합니다. mutexModeEXCLUSIVE이면 설정된 전략에 따라 승리한 규칙만 실행됩니다.
동일 Mutex 그룹에서 여러 규칙이 매칭될 때 승자를 결정합니다:
  • FIRST_MATCH: 우선순위 순서에서 첫 번째 매칭 규칙이 승리.
  • HIGHEST_PRIORITY: 우선순위 번호가 가장 낮은 규칙이 승리.
  • MAX_BENEFIT: 가장 높은 출력 값을 생성하는 규칙이 승리.
EXCLUSIVE 모드에서 mutexLimit은 Mutex 그룹 내에서 실행할 수 있는 규칙의 최대 수를 제어합니다 (기본값: 1).

결제와 인프라

플랜의 기본 할당량(API 실행 또는 시뮬레이션)을 초과한 사용량입니다. 초과분은 플랜에 정의된 건당 요율로 과금됩니다.
테넌트가 플랜의 최대 TPS(초당 트랜잭션)를 초과하여 거부된 요청입니다. HTTP 429 Too Many Requests를 반환합니다.
청구서와 세금 문서에 사용되는 사업자 정보 — 회사명, 사업자번호, 대표자, 주소.
내부 오류 발생 시 엔진이 요청을 차단하지 않고 통과시키는 복원력 정책입니다. Pro 플랜에서 사용 가능합니다.
정책 액션이 사용하는 외부 서비스(알림, 포인트, 쿠폰 등)와의 연결입니다. 6종: WEBHOOK, COUPON, POINT, NOTIFICATION, CRM, MESSENGER.

마케팅 → 제품 용어 매핑

LexQ 웹사이트에서 사용하는 일부 용어는 콘솔 및 API 용어와 다릅니다.
마케팅 용어제품 용어비고
비주얼 규칙 빌더규칙 편집 탭콘솔의 규칙 편집 인터페이스
충돌 해결 엔진Mutex 그룹Mutex 전략을 통한 규칙 충돌 처리
전체 감사 추적실행 트레이스 + 의사결정 트레이스실행별 결합된 트레이스 데이터
Git 스타일 버저닝정책 버전Draft → Publish → Deploy 생명주기
배포 전 시뮬레이션배치 시뮬레이션 / 드라이런배치 또는 단일 요청 테스트
즉시 배포 파이프라인라이브 배포원클릭 배포 + A/B 분할 옵션