의사결정 재실행

의사결정 재실행이란?

의사결정 재실행(Decision Replay)은 trace ID로 특정한 실제 과거 실행을 가져와, 당시의 입력 fact 그대로 후보 버전에 재평가합니다. 저장된 결정이 기준(baseline)이며 절대 재평가하지 않습니다. 후보만 실행되고, 무엇도 두 번 발화하지 않습니다. 규칙 액션에는 애초에 밖으로 나가는 효과가 없습니다. 결과는 결정 diff입니다. 결정이 바뀌었는지, 양쪽에서 어떤 규칙이 발화했는지, 결과 효과가 어떻게 달라지는지를 담습니다.

드라이런 vs 변경 영향 시뮬레이션 vs 의사결정 재실행: 드라이런은 직접 입력한 fact를 평가합니다. 변경 영향 시뮬레이션은 데이터셋이나 실행 이력 구간을 대량으로 돌려 집계 통계를 냅니다. 의사결정 재실행은 셋 중 가장 구체적인 질문에 답합니다. 바로 이 프로덕션 결정이 새 버전에서는 어떻게 나왔을까?

언제 사용하나

수정 배포 전: 지난 화요일 어느 고객의 가격이 잘못 매겨졌습니다. 그 trace를 수정된 버전으로 재실행해서 이번에는 결정이 옳게 나오는지 확인합니다.
사고 분석: 의사결정 출처(Decision Provenance)로 결정이 왜 그렇게 났는지 먼저 파악하고, 재실행으로 수정을 검증합니다.
롤아웃 전 블라스트 반경(blast radius) 측정: 날짜 구간 전체를 후보 버전으로 재실행해서 과거 결정 중 몇 건이 바뀌는지 셉니다.

두 가지 모드

	단건 재실행	윈도우 재실행
범위	trace 1건	과거 실행의 날짜 구간
실행	동기	비동기 job (제출 후 폴링)
과금	무료 (TPS 스로틀만 적용)	재실행 레코드당 과금 (`REPLAY` 메트릭)
권한	Admin, User, Viewer, API 클라이언트	Viewer는 제출·취소 불가

단건 결정 재실행

콘솔

콘솔에서 의사결정 재실행을 열고, 과거 실행과 후보 버전을 선택해 실행합니다. diff 화면이 발화 규칙과 효과 변화를 나란히 보여줍니다.

CLI

lexq replay decision --trace-id <traceId> --version-id <candidateVersionId>

API

curl -X POST "https://api.lexq.io/api/v1/partners/replay/decisions" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "traceId": "8f3c1a2e-1d44-4c1b-9a3e-0f5b7c2d9e10",
    "candidateVersionId": "b2ba29d8-c5b2-400c-a6a1-26d3a5840f7c"
  }'

응답

{
  "result": "SUCCESS",
  "data": {
    "traceId": "8f3c1a2e-1d44-4c1b-9a3e-0f5b7c2d9e10",
    "decisionChanged": true,
    "determinism": "DETERMINISTIC",
    "effectChanges": [ "…" ],
    "baselineFired": [ "…" ],
    "candidateFired": [ "…" ]
  }
}

핵심은 decisionChanged입니다. baselineFired와 candidateFired는 양쪽에서 발화한 규칙 목록이고, effectChanges는 결과 효과의 차이를 담습니다. determinism은 후보 버전 자체의 속성으로, 동일한 입력에 항상 동일한 결정이 보장되는지를 나타냅니다.

trace를 원래 실행됐던 버전 그대로 재실행하면 반드시 decisionChanged: false가 나와야 합니다. 그렇지 않다면 그 버전은 비결정적이며, 그 버전이 만든 diff를 신뢰하기 전에 알아야 할 사실입니다.

윈도우 재실행: 블라스트 반경

윈도우 재실행은 날짜 구간의 모든 실행을 후보 버전으로 재평가해서, 결정이 몇 건 바뀌는지 측정합니다.

제출

lexq replay start --version-id <candidateVersionId> --from 2026-07-01 --to 2026-07-07 --max-records 1000

curl -X POST "https://api.lexq.io/api/v1/partners/replay/jobs" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "candidateVersionId": "b2ba29d8-c5b2-400c-a6a1-26d3a5840f7c",
    "from": "2026-07-01",
    "to": "2026-07-07",
    "maxRecords": 1000
  }'

폴링

lexq replay get --id <jobId>

job이 RUNNING인 동안 progress가 100까지 올라갑니다. COMPLETED가 되면 응답에 결정이 몇 건 바뀌었는지의 summary와 검토용 changedSamples가 담깁니다. 구간의 실행 수가 maxRecords를 넘으면 capped가 true로 표시됩니다. 이때의 결과는 전체가 아니라 표본입니다. lexq replay list는 job 이력을 보여주고, lexq replay cancel --id <jobId>는 PENDING·RUNNING 상태의 job을 협조적으로 취소합니다.

레코드 상한

항목	값
하드 캡	job당 50,000건
기본 표본(`maxRecords` 생략)	가장 최근 1,000건

위 예시의 1000은 이 기본값을 적어 둔 것이지 필수 인자가 아닙니다. 하드 캡을 넘는 maxRecords는 그 값으로 깎지 않고 400으로 거절합니다. 구간은 최신순(createdAt 내림차순)으로 읽습니다. 상한에 걸린 job은 구간 전체에 고루 퍼진 표본이 아니라 가장 최근 실행을 측정합니다. 응답의 capped가 true면 구간의 실행 수가 maxRecords보다 많았다는 뜻입니다.

윈도우 재실행은 REPLAY 메트릭으로 재실행 레코드당 과금됩니다. 두 모드 모두 엔진 밖으로 나가는 효과가 없습니다. 액션 프리미티브 3종은 fact를 읽고 쓸 뿐입니다.

trace는 그 버전이 존재하는 동안에만 재실행할 수 있습니다. LexQ의 감사 보존은 실행 기록이 있는 버전의 삭제를 거부하므로(AN-028), 보존이 활성화된 이후 생성된 모든 trace에서 이 조건은 항상 성립합니다.

다음 단계

의사결정 출처

결정 뒤의 규칙을 누가 작성하고 발행하고 배포했는지 추적합니다.

변경 영향 시뮬레이션

배포 전에 집계 통계 기반으로 대량 what-if 분석을 수행합니다.

시작하기

핵심 개념

기능

의사결정 재실행