Skip to main content
아래의 모든 용어는 LexQ의 API 응답, 콘솔 UI, 문서에서 사용되는 정식 명칭입니다.

​
정책 엔진

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

​
팩트와 스키마

실행 시 정책 엔진에 전달되는 단일 입력 데이터 필드입니다. 예: user_id, customer_tier, order_total. 팩트는 조건이 평가하고 액션이 사용하는 원시 데이터입니다.
팩트의 스키마 정의 — 키, 표시 이름, 데이터 타입, 필수 여부. 콘솔의 관리 → 팩트 정의에서 관리합니다. 2개의 팩트(user_id, user_tags)가 편의를 위해 계정 생성 시 미리 등록되어 있으며, 다른 팩트와 동일하게 수정·삭제할 수 있습니다.
계정 생성 즉시 모든 테넌트에 등록되는 2개의 팩트: user_id, user_tags. 편의를 위해 제공되는 팩트로, 특별히 보호되지 않으며 일반 커스텀 팩트와 동일하게 이름 변경·타입 변경·삭제가 가능합니다. 그 외 모든 팩트(예: customer_tier, order_total)는 사용자가 팩트 정의에서 등록합니다.
규칙의 조건이나 액션에서 참조되지만 팩트 정의가 없는 팩트 키입니다. LexQ는 규칙 저장 시마다 이를 감지하여 추론된 타입과 제안된 이름을 함께 보고하며, 저장·발행·배포를 막지 않습니다.미등록 팩트는 실행 시 값이 전달되면 정상 동작합니다. 등록하면 타입 검증, 콘솔 자동완성, requirements analyzer 집계가 추가됩니다. lexq facts unregistered 또는 lexq_facts_unregistered MCP 도구로 목록을 확인하세요.
응답의 generatedVariables에 노출되는 변수 — 입력 팩트에 없었지만 액션 실행 결과로 생성된 값들입니다. {key}__delta 명명 규칙을 따르는 액션별 변화량 키도 포함합니다:
  • {refVar}__delta — MUTATE_FACT의 부호 포함 순변화량 (mutated - original).
  • {targetVar}__delta — INCREMENT_FACT의 0 이상 증분량.
한 룰에서 여러 액션이 같은 팩트를 변경하면 __delta는 누적 변화량을 보고합니다. 액션별 스냅샷은 audit drill-down용으로 executionTraces에 보관됩니다.

​
배포 생명주기

버전을 DRAFT에서 ACTIVE로 전환합니다. 발행되면 버전이 잠기며 규칙과 설정을 수정할 수 없습니다. 발행만으로는 라이브 트래픽이 라우팅되지 않습니다. 별도의 배포 단계가 필요합니다.
ACTIVE 버전을 라이브 상태로 승격합니다. 배포 후 해당 버전이 프로덕션 트래픽을 수신하고 처리합니다. 정책 그룹당 하나의 버전만 라이브일 수 있습니다.
정책 그룹에서 라이브 버전을 제거합니다. 새 버전이 배포될 때까지 해당 그룹의 트래픽이 처리되지 않습니다.
정책 그룹을 이전에 배포된 버전으로 되돌립니다. 감사 목적으로 새로운 배포 레코드가 생성됩니다.
유효 시작일이 미래인 발행됨 버전을 등록해 해당 시각에 자동으로 배포하는 기능입니다. 예약 시점에 스냅샷 해시를 봉인하고 실행 시점에 재검증하며, 수동 배포나 A/B 테스트 시작 등 충돌 행위가 발생하면 대기 중 예약이 자동으로 취소됩니다.

​
테스트와 분석

특정 정책 버전에 대한 단일 요청 테스트 실행입니다. 라이브 트래픽, 사용량 할당량, 실행 로그에 영향을 주지 않습니다. 외부 연동 호출은 기본적으로 모킹됩니다. mockExternalCalls를 false로 설정하면 실제 호출을 수행합니다.
데이터셋(과거 또는 수동)을 정책 버전에 대해 일괄 테스트합니다. 매칭률, 규칙 통계, 베이스라인 버전과의 지표 비교를 생성합니다. 시뮬레이션 중 연동 호출은 항상 모킹됩니다.
과거 실행 하나의 입력 팩트 그대로를 후보 버전에 재평가해 결정 diff를 만듭니다. 결정이 바뀌었는지, 양쪽에서 어떤 룰이 발화했는지, 효과가 어떻게 달라지는지. 저장된 결정이 기준이며 절대 재평가하지 않습니다. 외부 효과는 항상 모킹됩니다. 윈도우 재실행은 이를 날짜 구간으로 확장해 블라스트 반경, 즉 과거 결정 중 몇 건이 바뀌는지를 측정합니다.
API 호출로 트리거되는 라이브 정책 평가입니다. 각 실행은 고유 트레이스 ID와 함께 기록되며 실행 트레이스와 의사결정 트레이스를 포함합니다.
각 규칙의 조건 매칭 여부, 평가된 표현식, 규칙이 본 입력 팩트, 생성된 액션을 보여주는 규칙별 기록입니다. 모든 실행의 감사 추적의 일부입니다.
각 규칙의 최종 선택 결과를 두 분류 필드로 기록합니다:
  • status — SELECTED, NO_MATCH, NOT_SELECTED, BLOCKED, ERROR.
  • reasonCode — 해당 status 안에서의 구체적 사유 (예: FINAL_WINNER, CONDITION_MISMATCH, MUTEX_PRIORITY_LOST, GROUP_LIMIT_REACHED, ACTION_ERROR).
status × reasonCode 전체 매핑은 정책 규칙 — Decision Trace를 참조하세요.
요청의 일정 비율을 대체 정책 버전으로 라우팅하는 트래픽 분할 메커니즘입니다. 실제 트래픽으로 프로덕션에서 버전 성능을 비교하는 데 사용됩니다.

​
감사와 출처

하나의 결정에 봉인된 이력입니다. 결정 결과, 룰별 결정적 사유, 입력 팩트(PII 마스킹), 룰 스냅샷 지문, 그리고 작성·발행·배포의 책임 사슬. 기록 시점에 봉인되며, 사후에 재구성되지 않습니다.
PII로 지정된 팩트는 모든 읽기 표면에서 ••••••로 마스킹되어 도착하고, maskedKeys가 그 목록을 알려줍니다. 표시 레이어 전용 정책입니다. 엔진은 항상 실제 값으로 평가합니다.
마스킹된 값을 보는, 감사되는 콘솔 전용 행위입니다. 값이 보이기 전에 감사 행이 먼저 커밋되며(write-then-reveal), API 키는 403으로 거부됩니다.
모든 열람의 append-only 메타데이터 기록입니다. 누가, 어느 trace의, 어떤 팩트를, 언제 열람했는지. 값은 절대 저장하지 않습니다. 열람 권한보다 넓은 역할이 조회할 수 있고, 주기적 열람 기록 점검을 위해 API로 수집할 수 있습니다.

​
규칙 실행 제어

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

​
결제와 인프라

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

​
마케팅 → 제품 용어 매핑

LexQ 웹사이트에서 사용하는 일부 용어는 콘솔 및 API 용어와 다릅니다.