스테이블코인 정책 엔진 구축 방법: 코드로서의 컴플라이언스 (Compliance as Code)

모든 스테이블코인 (Stablecoin) 제품을 구축하는 과정에는 컴플라이언스 (Compliance) 팀이 엔지니어링 팀이 대답할 수 없는 질문을 던지는 순간이 있습니다: "토요일 새벽 2시에 거래가 우리의 AML (자금세탁방지) 정책을 위반하면 어떻게 되나요?" 만약 답변이 "월요일에 누군가 검토합니다"라면, 그 아키텍처 (Architecture)는 잘못된 것입니다. 정책이 아니라, 아키텍처가 잘못된 것입니다.

코드로서의 컴플라이언스 (Compliance as code)는 이 문제를 해결하는 설계 원칙입니다. 문서에 존재하며 거래가 정산된 후 사람이 적용하는 정책 대신, 스테이블코인 정책 엔진 (Stablecoin policy engine)은 실행 전 모든 거래를 평가하고 승인, 거절, 보류 또는 단계별 검토 (Step-up review)로의 라우팅과 같이 결정론적 (Deterministic)인 결과를 강제합니다. 정책 엔진은 결제 의도 (Payment intent)와 거래 실행 (Transaction execution) 사이의 의사결정 권한을 갖게 됩니다.

이것은 추상적인 아키텍처 선호도가 아닙니다. GENIUS 법안, MiCA 및 그와 동등한 프레임워크 하에서, 규제 대상 스테이블코인 발행사는 적용 가능한 법률을 위반하는 거래를 수동 개입 없이 즉각적으로 차단, 동결 및 거부할 수 있는 기술적 역량을 유지해야 합니다. 정책 문서는 그 요구사항을 충족하지 못하지만, 정책 엔진은 충족합니다.

스테이블코인 정책 엔진이란 무엇인가?

스테이블코인 정책 엔진은 결제 의도와 거래 실행 사이에 위치하는 런타임 의사결정 계층 (Runtime decision layer)입니다. 이는 지출 한도, 거래 상대방 화이트리스트 (Allowlists), 승인 요구사항, 관할권 제약 등 정의된 규칙 세트에 따라 각 거래를 평가하고, 자금이 이동하기 전에 결정론적인 결과를 반환합니다.

핵심 단어는 '전(before)'입니다. 정산 후에 실행되는 정책 엔진은 정책 엔진이 아니라 감사 로그 (Audit log)입니다. 컴플라이언스 가치는 거래를 중단, 경로 재설정 또는 에스컬레이션 (Escalation)할 수 있는 시점에서 거래를 가로채는 것에서 나옵니다.

초기 스테이블코인 (Stablecoin) 결제 시스템은 가공되지 않은 블록체인 전송을 그대로 반영했습니다. 즉, 자금과 목적지만 있다면 전송이 가능했습니다. 2026년의 프로덕션 시스템은 제한된 전송(Constrained transfers) — 허용 목록 (Allowlists), 한도 (Limits), 조건부 결제 (Conditional settlement), 그리고 관할 구역 인식 라우팅 (Jurisdiction-aware routing) — 으로 전환되고 있습니다. 정책 엔진 (Policy engine)은 이러한 전환을 구체화하는 핵심 요소입니다.

4가지 핵심 통제 항목

1. 지출 한도 (Spending limits)
지출 한도는 가장 기본적인 정책 통제 수단입니다. 이는 특정 시간 범위 내에서 거래당, 일일, 거래 상대방당, 또는 지갑당 이동할 수 있는 가치의 양을 정의합니다.

class SpendingLimitPolicy:

    def __init__(self, per_tx_limit, daily_limit, counterparty_limit):
        self.per_tx_limit = per_tx_limit
        self.daily_limit = daily_limit
        self.counterparty_limit = counterparty_limit

    def evaluate(self, tx: Transaction, state: WalletState) -> PolicyDecision:
        if tx.amount > self.per_tx_limit:
            return PolicyDecision.DENY(
                reason="exceeds_per_tx_limit",
                limit=self.per_tx_limit,
                requested=tx.amount
            )
        if state.daily_volume + tx.amount > self.daily_limit:
            return PolicyDecision.HOLD(
                reason="daily_limit_breach",
                requires="step_up_approval"
            )
        if state.counterparty_volume[tx.to] + tx.amount > self.counterparty_limit:
            return PolicyDecision.HOLD(
                reason="counterparty_limit_breach",
                requires="manual_review"
            )
        return PolicyDecision.APPROVE()

여기서 중요한 설계 세부 사항은 다음과 같습니다: 한도는 전역적으로 하드코딩(Hardcoded)되는 것이 아니라, 지갑별, 제품별, 그리고 관할 구역(Jurisdiction)별로 설정 가능해야 합니다. 기업 재무 지갑과 소비자 급여 지갑은 서로 다른 리스크 프로필 (Risk profiles)에서 작동합니다. 단일한 글로벌 한도는 한쪽에는 너무 제한적이고, 다른 한쪽에는 너무 허용적일 수 있습니다.

2. 거래 상대방 허용 목록 (Counterparty allowlists)

거래 상대방 허용 목록 (Counterparty allowlists)은 지갑이 거래할 수 있도록 허용된 지갑 주소 또는 엔티티 식별자 (entity identifiers)를 정의합니다. 자금 집행 (treasury payouts) 및 B2B 결제 (B2B settlement)에서는 스크리닝 (screening)과 결합된 파트너 허용 목록이 표준적인 통제 수단입니다.

class CounterpartyPolicy:

def init(self, allowlist: set, blocklist: set, require_kyb: bool):

self.allowlist = allowlist

self.blocklist = blocklist

self.require_kyb = require_kyb

def evaluate(self, tx: Transaction, screening: ScreeningResult) -> PolicyDecision:

if tx.to in self.blocklist:

    return PolicyDecision.DENY(reason="blocklisted_counterparty")

if screening.sanctions_hit:

    return PolicyDecision.DENY(reason="sanctions_screening_hit")

if self.allowlist and tx.to not in self.allowlist:

    return PolicyDecision.DENY(reason="counterparty_not_allowlisted")

if self.require_kyb and not screening.kyb_verified:

    return PolicyDecision.HOLD(reason="kyb_required")

return PolicyDecision.APPROVE()

차단 목록 (blocklist)과 제재 스크리닝 (sanctions screening)은 타협할 수 없는 필수 사항입니다. 허용 목록 (allowlist)은 사용 사례에 따라 구성할 수 있습니다. 자금 집행 (treasury disbursements)은 일반적으로 폐쇄형 허용 목록 (closed allowlists)을 기반으로 운영되며, 소비자 급여 플랫폼 (consumer payroll platforms)은 스크리닝이 포함된 개방형 목록 (open lists)을 기반으로 운영됩니다.

3. M-of-N 승인 요구 사항

M-of-N 승인은 거래가 실행되기 전, 지정된 서명자 (signatories) N명 중 M명이 거래를 승인해야 함을 의미합니다. 이는 고액 송금, 자금 운영 (treasury operations), 그리고 직무 분리 (separation of duties)가 필요한 모든 흐름에서 가장 중요한 거버넌스 통제 (governance control)입니다.

class MultiSigPolicy:

def init(self, threshold_amount: float, required_approvals: int,

total_approvers: int):

self.threshold = threshold_amount

self.m = required_approvals

self.n = total_approvers

def evaluate(self, tx: Transaction,

approvals: list[Approval]) -> PolicyDecision:

if tx.amount < self.threshold:

    return PolicyDecision.APPROVE()

valid_approvals = [

    a for a in approvals

    if a.is_valid and a.approver in self.designated_approvers

]

if len(valid_approvals) >= self.m:

return PolicyDecision.APPROVE()

return PolicyDecision.HOLD(

reason="insufficient_approvals",

required=self.m,

received=len(valid_approvals),

pending=self.m - len(valid_approvals)

)

임계값(Threshold amount)은 핵심 설정 파라미터입니다. 임계값 미만의 트랜잭션은 자동 승인됩니다. 임계값을 초과하는 트랜잭션은 승인 워크플로우(Approval workflow)에 진입합니다. M-of-N 파라미터는 MiCA, GENIUS Act, 그리고 기관 거버넌스 프레임워크가 모두 요구하는 직무 분리(Separation of duties) 요건과 직접적으로 매핑됩니다.

4. 타임 락 (Time locks)
타임 락은 지정된 시간 전이나 마감 기한 이후에 트랜잭션이 실행되는 것을 방지합니다. 이는 결제 창(Settlement windows), 급여 지급 일정, 재무 재조정(Treasury rebalancing) 제약 조건, 그리고 규제적 보류(Regulatory holds)를 위해 사용됩니다.

class TimeLockPolicy:

Medium 앱 다운로드
def init(self, not_before: datetime, not_after: datetime = None,

settlement_window: tuple = None):

self.not_before = not_before

self.not_after = not_after

self.settlement_window = settlement_window

def evaluate(self, tx: Transaction,

current_time: datetime) -> PolicyDecision:

if current_time < self.not_before:

return PolicyDecision.HOLD(

reason="time_lock_active",

releases_at=self.not_before

)

if self.not_after and current_time > self.not_after:

return PolicyDecision.DENY(reason="transaction_expired")

if self.settlement_window:

window_start, window_end = self.settlement_window

if not (window_start <= current_time.hour < window_end):

return PolicyDecision.HOLD(

reason="outside_settlement_window",

next_window=window_start

)

return PolicyDecision.APPROVE()

정책 엔진 구성하기 (Composing the Policy Engine)
개별 통제 항목(Individual controls)은 정책이 아니라 빌딩 블록(Building blocks)입니다. 프로덕션 환경의 스테이블코인 정책 엔진은 트랜잭션이 진행되기 전 모든 통제 항목을 통과해야 하는 평가 체인(Evaluation chain)으로 이들을 구성합니다.

class PolicyEngine:

def init(self, policies: list[Policy]):

self.policies = policies

def evaluate(self, tx: Transaction,

decision: PolicyDecision

def evaluate(self, tx: Transaction,
context: TransactionContext) -> PolicyDecision:

decisions = []

for policy in self.policies:
decision = policy.evaluate(tx, context)
decisions.append(decision)

if decision.outcome == Outcome.DENY:
self._log_decision(tx, decision, context)
return decision

if decision.outcome == Outcome.HOLD:
self._create_approval_workflow(tx, decision, context)
return decision

final = PolicyDecision.APPROVE()
self._log_decision(tx, final, context)
return final

def _log_decision(self, tx, decision, context):

AuditLog.record(
tx_id=tx.id,
outcome=decision.outcome,
reason=decision.reason,

policy_version=self.version,

timestamp=context.timestamp,
evaluator=context.service_identity
)
The audit log는 선택 사항이 아닙니다. 모든 결정은 재현 가능하고, 설명 가능하며, 내보낼 수 있어야 합니다. 컴플라이언스 프로그램(compliance programme)을 검토하는 규제 기관들은 단순히 무엇이 승인되었는지뿐만 아니라 왜 승인되었는지 — 어떤 정책 버전이 활성화되었는지, 어떤 통제가 평가되었는지, 그리고 어떤 신원이 결정을 서명했는지를 보고 싶어 할 것입니다. 모든 결과(승인 포함)에 대해 _log_decision을 호출하는 것이 바로 그 증거 추적(evidence trail)을 생성합니다.

관할권 인식 라우팅 (Jurisdiction-Aware Routing)
2026년의 스테이블코인 정책 엔진은 단일 글로벌 정책으로 운영될 수 없습니다. 다양한 흐름에는 별도의 정책이 필요합니다: 지급(payouts) 대 고객 출금(customer withdrawals) 대 재무부동 자산 이동(treasury movements). UAE 발송자와 이집트 수령자 간의 거래는 싱가포르와 인도네시아 간의 거래보다 다른 관할권 제약 조건 하에서 운영됩니다. 정책 엔진은 평가하기 전에 어떤 정책이 적용되는지 해결해야 합니다.

class JurisdictionRouter:

def resolve_policy(self, tx: Transaction,
context: TransactionContext) -> PolicyEngine:

jurisdiction_pair = (
context.sender_jurisdiction,
context.receiver_jurisdiction
)
return self.policy_registry.get(
jurisdiction_pair,
default=self.policy_registry.get(“global_default”)
)

이것은 VARA, MAS, CBN, 그리고 MiCA를 동시에 충족하는 프로그래밍 가능한 컴플라이언스 (Programmable Compliance) 요구사항을 만족하는 아키텍처입니다. 모든 것을 해결하려는 하드코딩된 글로벌 정책이 아니라, 트랜잭션 컨텍스트 (Transaction Context)를 기반으로 런타임 (Runtime)에 결정되는 구성 가능한 정책들의 레지스트리 (Registry)입니다.

컴플라이언스로서의 코드 (Compliance as Code)와 문서로서의 컴플라이언스 (Compliance as Documentation)의 차이
정책 문서는 "$10,000 이상의 트랜잭션은 상급자의 승인이 필요함"이라고 명시합니다. 스테이블코인 정책 엔진은 이를 강제합니다. 문서는 무시되거나, 오해받거나, 대규모 환경에서 일관성 없게 적용될 수 있습니다. 엔진은 그럴 수 없습니다.

정책 엔진은 비즈니스 및 컴플라이언스 제약 조건을 실행 가능한 통제 수단 (Enforceable Controls)으로 변환하는 계층입니다. 이는 모든 트랜잭션에서 인간의 개입 없이 자동으로 이루어집니다. 이것이 규제 기관들이 점점 더 기대하고 있는 아키텍처적 전환입니다. 더 나은 문서가 아니라, 더 나은 인프라를 요구하고 있습니다.

Tresori의 정책 엔진은 이 아키텍처를 네이티브하게 구현합니다. 지출 한도 (Spending Limits), M-of-N 승인 (M-of-N Approvals), 거래 상대방 허용 목록 (Counterparty Allowlists), 타임 락 (Time Locks), 그리고 관할 구역 인식 라우팅 (Jurisdiction-aware Routing)이 모두 단일 API를 통해 구성 가능하며, Kap DLT를 통한 불변의 감사 로그 (Immutable Audit Logs)가 모든 트랜잭션에 대한 전체 결정 기록을 캡처합니다. 규제 검토를 통과하는 컴플라이언스 프로그램은 가장 훌륭한 정책 문서를 가진 프로그램이 아닙니다. 인프라가 정책을 자동으로 강제하고, 감사 추적 (Audit Trail)이 이를 증명하는 프로그램입니다.

자주 묻는 질문 (FAQs)

스테이블코인 정책 엔진이란 무엇인가요?

스테이블코인 정책 엔진은 실행 전, 구성 가능한 규칙(지출 한도, 거래 상대방 허용 목록, M-of-N 승인 요구사항, 타임 락 등)에 따라 모든 트랜잭션을 평가하는 런타임 결정 계층 (Runtime Decision Layer)입니다. 이는 승인 (Approve), 거부 (Deny), 보류 (Hold), 또는 단계적 인증 강화 (Step-up)와 같은 결정론적 결과 (Deterministic Outcome)를 반환합니다. 컴플라이언스의 가치는 트랜잭션을 사후에 검토하는 것이 아니라, 결제되기 전에 가로채어 처리하는 데서 옵니다.

스테이블코인을 위한 컴플라이언스로서의 코드 (Compliance as Code)란 무엇인가요?

컴플라이언스로서의 코드 (Compliance as Code)란 컴플라이언스 규칙을 모든 트랜잭션(Transaction)에서 자동으로 실행되는, 기계가 집행 가능한 정책(Policy)으로 인코딩하는 것을 의미합니다. 문서에 존재하며 수동으로 적용되는 정책 대신, 정책 엔진(Policy Engine)은 각 결제 의도(Payment Intent)를 실시간으로 평가하고 그 결과를 결정론적(Deterministically)으로 집행합니다. 이는 요청에 따라 트랜잭션을 차단하고 동결할 수 있는 기술적 통제(Technical Controls)를 의무화하는 GENIUS Act, MiCA 및 그와 유사한 프레임워크들이 요구하는 아키텍처입니다.

스테이블코인 정책 엔진의 핵심 통제 항목은 무엇인가요?