"""
상태(state)와 라우터 노드에서 분류된 의도(intent)를 기반으로 경로를 지정합니다.

...

// 순수 정책 확인(Pure policy check). 에이전트와 오케스트레이터가 동일한(IDENTICAL) 규칙을 적용하도록 공유됩니다. 
// 사람이 읽을 수 있는 위반 사항 목록을 반환하며(빈 목록 = 허용됨), 이를 통해 오케스트레이터는 
// BUSINESS_RULE_VIOLATION 상세 정보에 넣을 수 있고 에이전트는 이를 대화로 전달할 수 있습니다.
...

모델에 구조화된 데이터(structured data)로 전달되는 거절은 하나의 _대화적(conversational)_ 이벤트가 됩니다: "아직 자금을 집행할 수 없습니다 — 약관에 동의하지 않으셨습니다." 반면, 예외(exception)로 소멸해버리는 거절은 중단된 채팅이 됩니다.

이 계층은 또한 **신원 접합부(identity seam)**이기도 합니다: `LOAN_MCP_AUTH_ENFORCED=true` 설정 시, 검증 가능한 토큰이 없으면 여정(journey) 자체가 시작되지 않으며, 유효한 토큰은 검증된 이메일로부터 확인된 _호출자 본인(caller's own)_의 당사자(party)와 해당 여정을 결합합니다. 실패 시 차단(Fail closed) 방식입니다:

## Ring 3 — 오케스트레이터의 게이트: 소유권, 당사자, 규칙

오케스트레이터의 REST 에지(edge)에 도달하는 모든 명령은 상태 머신(state machine)에 대한 질문이 던져지기도 전에 _순서대로_ 세 가지 게이트를 통과합니다:

1.  **소유권 (Ownership)** — 전달된 토큰은 _독립적으로 재검증(independently re-verified)_되며(loan-mcp와는 의도적으로 분리된 두 번째 구현체임), 토큰에서 유도된 당사자(party)는 조작 대상인 `customerRef`와 일치해야 합니다. 에러는 의도적으로 포괄적(coarse)으로 처리됩니다. 상세 정보는 로그로 전송되며, 공격자는 아무것도 알 수 없습니다.
2.  **당사자 게이트 (Party gate)** — 당사자는 반드시 존재해야 하며 활성 상태여야 합니다. 삭제된(암호학적으로 파기된, crypto-shredded) 당사자는 422를, 알 수 없는 당사자는 404를 반환합니다. 만약 party-api에 접속할 수 없는 경우, 게이트는 **503 — 실패 시 차단(fail closed)**을 반환하며, 결코 "문제가 없다고 가정"하지 않습니다.
3.  **규칙 게이트 (Rules gate)** — 권위 있는 정책 확인(Ring 1과 동일한 공유 함수)을 수행하며, 사람이 읽을 수 있는 위반 사항과 함께 422를 반환합니다.

트레이드오프(trade-off)는 명시적이며 이름이 지정되어 있습니다: `ORCH_AUTH_MODE`는 `off` / `verify-when-present` / `require` 모드로 실행됩니다. 구성 스택(compose stack)은 토큰이 없는 E2E(end-to-end) 및 내부 도구들이 계속 작동할 수 있도록 `verify-when-present`를 사용하지만, 실제 배포 환경에서는 `require`를 실행합니다. 핵심은 보안 태세(posture)가 미들웨어의 우연한 결과가 아니라, 설정에 따른 _결정(decision)_이라는 점입니다.

Ring 1과의 비대칭성에 주목하십시오: **신원(identity) 및 정책 의존성(policy dependencies)은 실패 시 차단(fail closed)되지만, 대화형 도우미(conversational helpers)는 실패 시 허용(fail open)됩니다.** 에이전트의 초안 확인(draft check)은 "오케스트레이터(orchestrator)가 생성 시 여전히 권위 있게 강제한다"는 점 덕분에 우아하게 성능이 저하(degrade gracefully)되지만, 오케스트레이터의 게이트는 결코 저하되지 않습니다. 그 뒤에는 아무것도 없기 때문입니다.

## Ring 4 — 순수 상태 머신(pure state machine): "이것이 발생해도 되는가"에 대한 유일한 권위

시스템의 핵심은 금욕적일 정도로 순수한 XState 머신입니다:

`disburse` 핸들러는 "계층적 거부(layered refusal)"가 실제로 어떻게 작동하는지 보여줍니다. 각 확인 단계는 고유한 상태 코드(status code)를 가지므로, 호출자는 정확히 _어느_ 링(ring)이 거부했는지 알 수 있습니다:

이 머신은 순수하며 아무것에도 의존하지 않기 때문에, 동일한 적법성 함수(legality function)가 **세 가지** 호출자에게 서비스를 제공합니다: 동기식 명령 핸들러(synchronous command handlers), SQS 백스톱(backstop)의 투영 적용기(projection applier, 이를 통해 순서가 잘못된 재생 이벤트가 적용되지 않고 _건너뛰어짐_), 그리고 상태를 건드리지 않고 분류기(classifier)에서 가드레일(guardrail)로 이어지는 정밀도(precision)를 측정할 수 있게 해주는 비변이(non-mutating) `/signal` 확인 엔드포인트입니다.

## Ring 5 — loans-api: 적법한 명령이라도 반복 실행 시 안전해야 함

가장 안쪽의 링은 그 위의 모든 단계가 실패했다고 가정합니다. 기록 시스템(system of record)은 모든 쓰기 작업을 멱등성 엔벨로프(idempotency envelope, 도메인 변경과 동일한 트랜잭션)로 감싸며, 관계형 벨트 앤 서스펜더스(relational belt-and-suspenders, 이중 안전장치) 확인을 추가합니다. 즉, 지급(disburse)되는 수락 건이 실제로 활성 시뮬레이션에 속해 있어야 합니다. 재시도되거나 중복된 명령은 기록된 응답을 재현할 뿐이며, 절대 두 번 쓰지 않습니다.

다섯 가지 고리 아래에는 내구성 (durability)이 자리 잡고 있습니다. 제어 기록 (Control Record)은 Postgres 상의 DBOS를 통해 영속화되며, **버전 비교 및 스왑 (version compare-and-swap, CAS)과 이벤트별 중복 제거 (per-event dedup)**를 통해 고도화됩니다. 버전-CAS의 상세 내용은 그 자체로 하나의 전쟁 이야기입니다. 과거의 CAS는 `state`를 키로 사용했는데, 재시뮬레이션은 자기 루프 (self-loop) — `simulated → simulated` — 이기 때문에 CAS가 오래된 행과 조용히 일치해 버리는 문제가 있었습니다. 단조로운 (Monotonic) `version`이 이를 해결했습니다. 만약 당신의 상태 머신 (state machine)에 자기 루프가 있다면, 상태 기반 CAS는 아직 만나지 못한 버그가 될 것입니다.

## 공격의 엔드 투 엔드 (end to end) 과정

다섯 가지 고리에 대한 전체 상세 내용 — 누가 무엇을, 어떤 순서로 확인하는지, 그리고 정상 경로 (happy path)와 거부 경로 (rejected path)가 어떻게 구성되는지 설명합니다:

[![Guardrails — five rings, outside-in, between the LLM and irreversible money movement](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fbttcgwc964zwcbzq1x5s.png)](https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fbttcgwc964zwcbzq1x5s.png)

창의적인 LLM, 호기심 많은 테스터, 혹은 직접적인 REST 호출과 같은 무언가가 여정이 여전히 `simulated` 상태인 동안 `disburse`를 시도하면 어떤 일이 발생할까요?

1. `canFire('simulated', DISBURSE)` → `false`. **아무것도 변경되지 않으며, loans-api는 호출되지 않습니다.**
2. 오케스트레이터 (orchestrator)는 RFC 9457 `application/problem+json` 형식으로 상태 코드 409, `STATE_TRANSITION`을 반환합니다.
3. loan-mcp는 이를 값으로서 그대로 전달합니다: `{"error": {code, status, title, …}}`.
4. 에이전트 (agent)는 코드를 읽고 대화하듯 설명합니다 — "먼저 약관을 검토해 봅시다."
5. 내구성 있는 상태 (Durable state)는 `simulated`로 유지되며, `acceptanceId`와 `disbursementId`는 null 상태로 남습니다.

이 경로의 모든 단계는 REST와 MCP 모두에 대해 E2E 테스트로 검증됩니다. 여기에는 MCP 도구 호출이 (에러를 던지는 대신) *해결 (resolves)* 된다는 점과 내구성 있는 기록이 건드려지지 않는다는 점이 포함됩니다. 공격을 시도하는 테스트가 없는 가드레일은 그저 희망 사항일 뿐입니다.

## 부드러운 외부 필터, 그리고 그것이 왜 부드러워도 되는가

5개의 고리 외부에는 모델 수준의 콘텐츠 필터링을 위한 Bedrock Guardrails 설정이라는 한 단계가 더 존재합니다. 이 설정의 거부 주제(deny-topics)는 유해 콘텐츠 필터 및 개인정보(PII) 마스킹과 더불어, _무허가 금융 자문_ ("이 대출금을 암호화폐에 넣어야 할까요?") 및 _대출 사기 및 회피_ ("자격을 갖추기 위해 소득을 어떻게 부풀릴 수 있을까요?")와 같이 특정 도메인에 특화되어 있습니다. 고객에게 보여지는 거절 문구는 단일 모듈 수준의 상수(constant)에 저장되므로, Bedrock으로 전송되는 가드레일 정의와 로컬 폴백(fallback) 메시지가 서로 어긋나는 일이 발생하지 않습니다.

내부의 다른 모든 요소와 달리, 이 필터는 오류 발생 시 _오픈 방식(fails open)_으로 작동합니다. 이는 이 필터가 권위 있는 제어 수단이 아니며, 결코 되어서도 안 되기 때문에 허용되는 방식입니다. 운영상의 참고 사항 하나는, 가드레일은 _이름(name)_을 통해 생성되거나 가져오기 때문에, 리포지토리(repo)에서의 정책 변경 사항은 가드레일이 재생성되거나 새 버전이 게시될 때만 기존 환경에 반영됩니다.

이것이 바로 고리 모델(ring model)의 진정한 교훈입니다. 내부의 고리들이 견고하기 때문에, 외부의 필터는 부드럽고 불완전해도 괜찮습니다. **되돌릴 수 없는 지점에 당신의 엄격함을 쏟으십시오.**

## 결론

5개의 고리는 단순히 중복을 위한 중복이 아닙니다. 각 고리는 서로 다른 비밀을 숨기고 있으며, 서로 다른 유형의 실수를 방지합니다: