배포 전에 바뀔 결정을 의사결정 재실행으로 세기
저장된 하루치 결정을 후보 버전에 다시 돌려, 규칙 변경이 실제 결정 몇 건을 바꾸는지 셉니다.
문제
한 마켓플레이스는 가입한 지 오래된 계정의 $50 이하 환불을 자동으로 승인하는데, 이 한도를 $75까지 올리려 합니다. 저장된 하루치 환불 결정을 $75 버전에 다시 돌려 보면, 그날 2,000건 가운데 검토로 갔던 407건이 자동 승인으로 바뀝니다. 자동 승인되지 않은 환불은 상담원이 검토하는데, 그날 검토 대기열은 1,176건에서 769건으로 줄고 자동 승인은 824건에서 1,231건으로 늘었을 것입니다.
한도를 올리자고 한 것은 이 대기열을 줄이고 싶은 지원팀입니다. 재무팀에게 407건은 아무도 확인하지 않고 자동으로 승인되는 환불이 그만큼 늘어난다는 뜻입니다.
같은 날을 지금 운영 중인 $50 버전에 돌리는 대조 실행에서는 바뀐 결정이 하나도 없었으므로, 407건은 단순히 한도 변경에 의한 것입니다. 배포가 있었던 날처럼 다른 버전이 내린 결정이 섞여 있었다면 대조 실행에서도 바뀐 결정이 나왔을 것입니다. 그날 실패한 호출이 있었어도 마찬가지입니다(엣지 케이스 참고).
환불 라우터가 보는 것은 셋입니다. 금액이 한도 이하인지, 가입한 지 30일 이상인지, 최근 90일 환불이 3건 미만인지입니다. 검사 하나하나는 골라 넣은 환불로 단위 테스트를 돌려 확인할 수 있지만, 그날 들어온 환불 중 몇 건이 $50 한도에서는 검토로 가고 $75 한도에서는 셋을 다 통과하는지는 테스트로 알 수 없습니다.
단순히 금액만 보고 비교하면 그날 두 한도 사이에 드는 환불은 473건인데, 지원팀에 알려 줄 건수는 왜 407건일까요?
단순한 접근
라우터가 아직 코드에 있다면 검사 셋을 담은 Java 메서드 하나이고, 새 한도가 미칠 영향은 보통 메서드를 하나 더 써서 그 수를 파악합니다.
public class RefundRouter {
static final BigDecimal LIMIT_USD = new BigDecimal("50.00");
static final int MIN_ACCOUNT_AGE_DAYS = 30;
static final int MAX_RECENT_REFUNDS = 3;
private final AccountRepository accounts;
private final RefundRepository refunds;
public Route route(RefundRequest req, Instant now) {
Account account = accounts.find(req.accountId());
long ageDays = Duration.between(account.createdAt(), now).toDays();
if (ageDays < MIN_ACCOUNT_AGE_DAYS) {
return Route.MANUAL_REVIEW;
}
Instant since = now.minus(Duration.ofDays(90));
if (refunds.countSince(req.accountId(), since) >= MAX_RECENT_REFUNDS) {
return Route.MANUAL_REVIEW;
}
if (req.amountUsd().compareTo(LIMIT_USD) <= 0) {
return Route.AUTO_APPROVE;
}
return Route.MANUAL_REVIEW;
}
// $75 제안의 크기: 하루치 환불 중 두 한도 사이에 드는 것
public long estimateMoved(LocalDate day, BigDecimal newLimitUsd) {
return refunds.findCreatedOn(day).stream()
.filter(r -> r.amountUsd().compareTo(LIMIT_USD) > 0)
.filter(r -> r.amountUsd().compareTo(newLimitUsd) <= 0)
.count();
}
}
2026-10-07의 환불 2,000건에 돌리면 estimateMoved는 473을 돌려줍니다. $50 초과 $75 이하인 환불의 건수입니다.
라우터의 검사 셋 가운데 금액 하나만 베껴 넣었기 때문에, 이 추정은 실제 변화보다 16% 큽니다. 실제 라우터는 다음 절에서 다룰 LexQ에서 돌고, LexQ가 환불마다 저장해 둔 입력값으로 세어 보면 473건 중 66건은 한도를 올려도 검토로 갑니다. 그중 53건은 가입 30일이 안 된 계정에서, 13건은 가입 30일 이상이지만 최근 90일에 환불을 3건 이상 받은 계정에서 왔습니다.
남은 두 검사까지 베끼려면 환불마다 요청이 들어온 순간의 입력을 되살려야 하는데, 코드에 있는 route 메서드는 그 순간의 now로 계정 일수와 최근 90일 환불 수를 계산하고 어디에도 남기지 않습니다. 계정과 환불의 생성 시각으로 두 값을 다시 계산할 수는 있습니다. 다만 그것은 과거 데이터를 상대로 route 메서드의 로직을 한 벌 더 짜는 일이고, 90일 환불 수에 판정 중인 그 환불이 들어가는지 같은 세부까지 route 메서드와 맞춰야 합니다.
코드에서는 route 메서드가 돌려준 경로도 기록되지 않으므로, estimateMoved는 그날 환불을 지금 코드가 모두 결정했다고 보고 셉니다. 정오에 route 메서드를 고치는 핫픽스가 나갔다면 오전 환불은 지금은 사라진 코드가 처리했는데도, 추정에는 그 차이가 드러나지 않습니다. route 메서드를 고칠 때마다 estimateMoved도 손으로 맞춰야 하는데, 두 메서드가 어긋나도 이를 잡아내는 테스트는 없습니다.
요청마다 입력값과 결정을 직접 기록해 두면 그 순간의 입력을 되살릴 일도 그날 어느 코드가 결정했는지 짐작할 일도 없어지고, 쿼리 하나로 같은 407건을 셀 수 있습니다. 그래도 그 쿼리는 실제로 배포될 규칙을 읽지 않습니다. 사람이 「한도를 $75까지 올린다」는 계획을 보고 조건을 다시 적은 것이라, 규칙을 고치다 낸 실수는 쿼리에 드러나지 않습니다. 한도를 올리면서 계정 일수 하한 30을 3으로 잘못 바꿨다고 해 보면, 쿼리는 여전히 407건입니다. 다음 절의 방법으로 그날 환불을 잘못 고친 규칙에 다시 돌려 보면 535건이 바뀌고, 그중에는 가입 3일 된 계정의 환불도 있습니다.
패턴 정의
의사결정 재실행(Decision Replay)은 저장된 운영 호출을 후보 버전에 다시 돌리고, 그 결과를 호출이 처리될 때 저장된 결정과 맞댑니다. 호출을 저장하는 곳은 실제 라우터가 도는 LexQ입니다. LexQ는 규칙을 대신 실행해 주는 호스팅 서비스이고, 환불 서비스는 환불마다 LexQ를 한 번 호출하면서 fact를 보냅니다. fact는 refundAmountUsd처럼 이름이 붙은 값입니다. 규칙이 하는 일은 액션이라고 부르는데, refundRoute에 AUTO_APPROVE를 쓰는 것이 그 예입니다. LexQ는 호출마다 받은 fact와 결정을 내린 규칙의 액션을 함께 저장합니다.
저장된 결정은 다시 계산하지 않고 그대로 재실행의 기준이 되며, 콘솔에는 「기준 (저장된 결정)」으로 표시됩니다. 윈도우 재실행은 정책 그룹 하나에 저장된 호출 가운데 한 기간의 것을 모아, 입력마다 후보 버전만 실행하고 액션이 기준과 달라진 호출을 셉니다. 기간은 시작일(--from)부터 종료일(--to)까지 하루 단위로 정합니다. 정책 그룹은 한 가지 결정에 쓰는 규칙과 그 버전들을 담는 단위입니다.
이 패턴은 환불 라우터처럼 이미 운영 호출을 받는 정책 그룹을 그 그룹의 새 버전으로 바꿀 때 좋습니다. 아직 운영에 나가지 않은 라우터에는 저장된 호출이 없어 다시 돌릴 것이 없으니, 요청 표본을 파일로 올려 대상 버전과 비교 기준 버전을 함께 돌리고 결과를 맞대는 변경 영향 시뮬레이션(Impact Simulation)으로 가늠할 수 있습니다(변경 영향 시뮬레이션으로 배포 전 규칙 변경 테스트하기). 후보 버전이 새 fact를 읽어야 하는 변경도 저장된 호출 어디에도 그 fact가 없으므로 맞지 않습니다.
LexQ에서 라우터는 정책 그룹 하나이고, 규칙은 둘입니다. 자동 승인 규칙은 검사 셋을 담아 fact refundRoute에 AUTO_APPROVE를 쓰고, 조건이 빈 catch-all은 모든 환불에 맞아 MANUAL_REVIEW를 씁니다. 이렇게 규칙이 쓰는 값도 fact입니다. 두 규칙은 상호 배타 그룹(Mutex Group) refund-route로 묶여 있어서, 둘 다 맞는 환불에서는 우선순위가 높은 규칙, 곧 목록에서 먼저 오는 규칙 하나만 선택되고 환불마다 경로가 하나로 정해집니다. v1이 $50 한도로 운영 중이고, 후보 버전 v2는 v1을 복제해 한도를 75로 올리고 규칙 이름도 그에 맞춰 바꾼 초안입니다.
{
"name": "Auto-approve: up to $75, established account",
"condition": {
"type": "GROUP",
"operator": "AND",
"children": [
{
"type": "SINGLE",
"field": "refundAmountUsd",
"operator": "LESS_THAN_OR_EQUAL",
"value": 75,
"valueType": "NUMBER"
},
{
"type": "SINGLE",
"field": "accountAgeDays",
"operator": "GREATER_THAN_OR_EQUAL",
"value": 30,
"valueType": "NUMBER"
},
{
"type": "SINGLE",
"field": "refundsLast90Days",
"operator": "LESS_THAN",
"value": 3,
"valueType": "NUMBER"
}
]
},
"actions": [
{
"type": "SET_FACT",
"parameters": { "targetVar": "refundRoute", "value": "AUTO_APPROVE" }
}
],
"mutexGroup": "refund-route",
"mutexMode": "EXCLUSIVE",
"mutexStrategy": "HIGHEST_PRIORITY",
"mutexLimit": 1,
"isEnabled": true
}
계정 일수와 최근 환불 수는 이제 환불 서비스가 환불이 들어온 시각에 계산해 fact로 보내고, LexQ는 그 값을 규칙이 내린 경로와 함께 호출에 저장합니다.
의사결정 재실행 전략
같은 하루를 두 번 재실행합니다. 첫 번째는 운영 버전 v1을 후보 버전 자리에 놓고 돌리는 대조 실행입니다. 2026-10-07을 이렇게 돌리면 2,000건 가운데 바뀐 결정이 0건입니다. 그날 저장된 호출을 모두 v1 규칙이 결정했고, 다시 돌려도 같은 액션이 나온다는 뜻입니다. 그래서 두 번째로 v2를 돌려 나온 수는 새 한도 하나의 몫으로 읽을 수 있습니다.
# 대조 실행: 운영 버전 v1
lexq replay start --version-id <v1-version-id> \
--from 2026-10-07 --to 2026-10-07 --max-records 5000
# 후보 실행: v2
lexq replay start --version-id <v2-version-id> \
--from 2026-10-07 --to 2026-10-07 --max-records 5000
--max-records를 그날 호출 2,000건보다 크게 잡은 것은, 이 옵션을 빼면 작업이 최근 1,000건만 재실행하기 때문입니다(엣지 케이스 참고).
v2는 다음 네 가지가 모두 맞아야 통과합니다.
- 대조 실행에서 바뀐 결정이 0건입니다
- 두 실행 모두
capped(기간 안의 호출이--max-records보다 많았다는 표시)가 아니고, 오류도 0건입니다 - 영향 범위는 후보 버전이 더하거나 없앤 액션을, 그 액션이 걸린 호출 수와 함께 보여 줍니다. LexQ 콘솔은 이 액션 한 줄 한 줄을 효과라고 부릅니다. 여기에
MANUAL_REVIEW제거와AUTO_APPROVE추가 한 쌍만, 같은 호출 수로 있어야 합니다. 한도를 올리면 승인은 늘기만 하므로, 다른 효과가 보이면 v2가 한도 말고도 무언가를 바꾼 것입니다 - 작업은 바뀐 호출 가운데 일부를 변경 샘플로 보여 줍니다. 하나씩 열어 보면 모두 $50 초과 $75 이하이고, 나머지 두 검사를 통과하는 계정에서 온 환불이어야 합니다
윈도우 재실행은 재실행한 레코드(저장된 호출 한 건) 수만큼 과금됩니다. 이번 확인은 두 실행을 합쳐 4,000건이었고, 그 절반이 대조 실행 몫입니다. 재실행한 결정은 작업 결과에만 남고 환불 서비스로는 가지 않아서, 하루를 다시 돌려도 지급되거나 검토 대기열에 들어가는 환불은 없습니다. 재실행한 호출은 실행 이력(운영 호출의 목록, 다음 재실행이 읽는 곳)에도 더해지지 않습니다. 그래서 다음 날 2026-10-07을 다시 돌려도 그날 호출은 2,000건 그대로입니다.
의사결정 트레이스 출력
호출마다 의사결정 트레이스가 함께 저장됩니다. 그 호출에서 규칙마다 어떤 결과가 났는지 적은 기록이고, 재실행은 기준을 여기서 읽습니다. v2 작업의 결과는 lexq replay get --id <job-id>로 받고, 아래는 그 가운데 건수와 영향 범위입니다.
{
"totalCount": 2000,
"processedCount": 2000,
"errorCount": 0,
"changedCount": 407,
"capped": false,
"summary": {
"recordsReplayed": 2000,
"recordsChanged": 407,
"determinism": "DETERMINISTIC",
"effectBlastRadius": [
{
"action": {
"type": "SET_FACT",
"parameters": { "targetVar": "refundRoute", "value": "MANUAL_REVIEW" }
},
"direction": "REMOVED",
"recordCount": 407
},
{
"action": {
"type": "SET_FACT",
"parameters": { "targetVar": "refundRoute", "value": "AUTO_APPROVE" }
},
"direction": "ADDED",
"recordCount": 407
}
]
},
"changedSamples": [ ... ]
}
totalCount는 작업이 재실행하려고 모은 호출 수입니다. 기간 안의 호출을 상한까지 셉니다.processedCount는 그중 재실행을 마친 수입니다changedCount는 저장된 결정과 v2 사이에 액션이 달라진 호출 수입니다capped는 기간 안의 호출이--max-records보다 많았는지를 알려 줍니다determinism은 v2가 같은 입력에 다른 답을 낼 수 있는지를 알려 줍니다. v2의 규칙은 요청의 fact 말고는 읽는 것이 없습니다effectBlastRadius는 영향 범위입니다. 생기거나 사라진 액션마다 그 영향을 받은 호출 수를 보여 주고, 콘솔에서는 효과 영향 범위 칸에 나옵니다changedSamples는 변경 샘플로, 바뀐 호출 가운데 일부가 들어갑니다. 샘플 하나는traceId와 그 호출의 효과 변경입니다
단건 재실행은 저장된 호출 하나만 골라 후보 버전으로 다시 돌립니다. 변경 샘플 가운데 하나인 $64.99 환불(가입 84일 된 계정, 최근 환불 없음)을 단건 재실행으로 열면 왜 바뀌었는지가 드러납니다.
lexq replay decision --trace-id 6bd369f9-dd46-410c-b5fa-b338b09c8a52 \
--version-id <v2-version-id>
{
"traceId": "6bd369f9-dd46-410c-b5fa-b338b09c8a52",
"decisionChanged": true,
"determinism": "DETERMINISTIC",
"effectChanges": [
{
"action": {
"type": "SET_FACT",
"parameters": { "targetVar": "refundRoute", "value": "MANUAL_REVIEW" }
},
"direction": "REMOVED"
},
{
"action": {
"type": "SET_FACT",
"parameters": { "targetVar": "refundRoute", "value": "AUTO_APPROVE" }
},
"direction": "ADDED"
}
],
"baselineFired": [
{ "ruleName": "Manual review: everything else", ... }
],
"candidateFired": [
{ "ruleName": "Auto-approve: up to $75, established account", ... }
]
}
baselineFired는 저장된 호출의 의사결정 트레이스에서 그대로 읽어 오고, 그 호출에서 이긴 규칙만 담습니다. 위 JSON에서는 catch-all입니다. 트레이스 전체(아래 그림)를 보면 $50 규칙은 NO_MATCH입니다. 금액 64.99에서 (refundAmountUsd <= 50)이 거짓이었고, 그래서 catch-all이 선택됐습니다(SELECTED). candidateFired는 지금 v2를 실행해 얻은 쪽입니다. 비교하는 것은 액션뿐입니다. 그래서 $50 이하 환불처럼 v1의 규칙도, 그 규칙을 복제해 이름을 바꾼 v2의 규칙도 똑같이 AUTO_APPROVE를 낸 호출은, 규칙 ID와 이름이 달라도 바뀐 결정으로 세지 않습니다.
엣지 케이스
--max-records를 주지 않으면 상한은 1,000건이고, 남는 쪽은 최근 호출입니다. 같은 날을 그렇게 돌리면 뒤쪽 1,000건만 재실행되어 capped 표시와 함께 184건이 바뀌었다고 나오는데, 이것을 하루 수치로 읽으면 실제 변화의 절반에도 못 미칩니다. 상한은 50,000건까지 올릴 수 있고, 그보다 많은 호출이 쌓인 기간은 짧은 기간 여러 개로 나눠 돌립니다.
2026-10-07~2026-10-08 기간은 v2 배포를 걸치므로 두 버전의 결정이 함께 들어 있습니다. 2026-10-08이 끝난 뒤 이 기간을 v2로 재실행하면 v2가 운영 중인데도 4,000건 가운데 407건이 바뀌었다고 나오는데, 이 407건은 모두 첫날 v1이 내린 결정입니다. 운영 버전이 v2이니 이 재실행이 곧 대조 실행이고, 이렇게 배포를 걸친 기간에서는 대조 실행이 0건이 되지 않습니다. $75 한도는 그대로 두고 다른 것을 바꾼 v3를 같은 이틀에 돌리면 v3 자신의 변경에 이 407건이 더해져 나옵니다. 기간은 조직 시간대의 하루 단위라서, 배포 전후로 트래픽이 있던 배포 당일에도 두 버전의 결정이 함께 들어 있습니다. v2 다음의 변경을 잴 때는 기간을 v2가 온전히 운영된 첫날인 2026-10-08부터 잡습니다.
환불 한 건은 평범한 호출 한 번이지만, 재실행은 저장된 호출 가운데 세 종류를 다르게 다룹니다. 여러 정책 그룹을 한 번에 평가하는 복합 실행은 기간에서 빠지고, 요청 여러 건을 한 번에 보내는 일괄 실행은 항목별 fact 없이 실행 이력에 한 줄만 남깁니다. 재실행은 이 한 줄을 fact 없이 돌리고, 그 결과를 일괄 실행에 담겨 있던 환불 전부의 경로와 맞댑니다. 이 그룹에서 fact 없이 발동하는 규칙은 catch-all뿐이라 그 결과는 MANUAL_REVIEW 하나입니다. 실패한 호출은 fact만 남기고 액션은 남기지 않았으므로, 후보 버전이 내는 액션은 모두 추가된 것으로 셉니다. 그래서 한 버전이 기간 전체를 결정했더라도 대조 실행은 일괄 실행과 실패한 호출을 바뀐 결정으로 셀 수 있습니다. 기간 안에 배포가 없는데도 대조 실행이 0이 아니면, 그 기간의 실행 이력에서 실패한 호출과 일괄 실행부터 찾습니다.
v2는 환불 서비스가 이미 보내는 fact 셋만 읽습니다. 후보 버전이 이를테면 지불 거절 횟수까지 읽는다면, 저장된 호출에 그 fact가 없어도 윈도우 재실행은 오류 없이 끝까지 돕니다. 없는 fact를 읽는 조건을 성립하지 않은 것으로 처리하므로, 규칙이 발동하지 않은 결과가 저장된 결정과 다르면 그대로 변경으로 셉니다. 단건 재실행은 같은 호출에서 오류를 내고 멈추니, 윈도우 재실행 전에 저장된 호출 하나를 단건 재실행해 보면 빠진 fact가 바로 드러납니다.
재무팀이 물을 407건의 금액 합계는 작업 결과에 없고, 변경 샘플의 금액도 트레이스를 하나씩 열어야 보입니다.
환불 한 건을 두고 분쟁이 생기면 호출 하나에 대한 질문이므로, 의사결정 트레이스 출력 절에서처럼 단건 재실행으로 답합니다. 실행 시점 봉인으로 구독 일할 계산 증명하기는 5월에 청구한 구독 요금 한 건에 분쟁이 나자, 지금 정책이라면 다르게 결정했을지를 7월 운영 버전으로 단건 재실행해 확인합니다.
운영 배포
v2는 A/B 테스트를 거치지 않고 배포 한 번으로 내보냅니다. 하루치 환불 전부에 후보 버전을 이미 돌려 봤고, 트래픽을 나누면 똑같은 $60 환불이 며칠 동안 서로 다른 경로로 가기 때문입니다. v2 배포의 메모에 두 재실행 작업의 ID와 건수를 적어 두면, $75 한도를 내보낸 근거가 배포 기록에 같이 남습니다.
1일차 v1 운영, 환불 2,000건 저장
대조 실행 (v1): 2,000건 중 0건 변경
후보 실행 (v2): 2,000건 중 407건 변경
v2 배포, 메모에 두 재실행 작업을 적음
2일차 하루 내내 v2 운영, 환불 2,000건 저장
3일차 2일차를 v1에 재실행: 2,000건 중 429건 변경
v2가 하루를 온전히 처리하고 나면 그 하루를 v1에 재실행합니다. 같은 도구를 반대 방향으로 쓰는 것이고, 기간 안에 배포가 없으니 v2가 내린 결정만 견주게 됩니다. 2026-10-08을 이렇게 돌리니 v2가 결정한 2,000건 가운데 429건(21%)이 AUTO_APPROVE 제거와 MANUAL_REVIEW 추가로 달라졌고, 재실행이 예측한 20%와 크게 다르지 않았습니다. 다음 둘 중 하나가 보이면 롤백합니다.
- 영향 범위에
AUTO_APPROVE제거와MANUAL_REVIEW추가 말고 다른 효과가 나옵니다. 배포한 규칙이 재실행한 규칙과 다르다는 뜻입니다. v2는 초안일 때 재실행했고, 초안은 발행하기 전까지 고칠 수 있습니다. 발행은 배포 앞에 따로 거치는 단계로, 버전의 규칙을 잠급니다 - 바뀐 비율이 재실행이 예측한 20%보다 크게 높아집니다. 새 한도 바로 아래 금액으로 들어오는 환불이 늘고 있다는 뜻입니다
2026-10-08에는 둘 다 보이지 않았으므로 v2를 그대로 둡니다. 롤백하면 그룹의 운영 버전이 다시 v1이 되고, 롤백도 배포 기록으로 따로 남습니다. 재실행은 규칙 실행에 걸린 시간을 재지 않습니다. 배포 뒤 환불 처리가 느려지면 핫 패스 규칙을 고칠지 규칙 성능 상세로 가늠하기에서처럼 규칙별 시간으로 경로 규칙 둘이 원인인지 확인합니다.
LexQ가 어떻게 동작하는지 playground에서 직접 확인해보세요.