스테이블코인 규제: MiCA와 GENIUS를 읽는 법
도입
이 강의는 법률 자문이 아니다. 목표는 개발자가 규제 문서를 읽을 때 "어떤 제품 요구사항으로 바뀌는가"를 추적하는 법을 배우는 것이다. 스테이블코인 규제는 발행자 허가, 준비자산, 상환권, AML/CFT, sanctions, reporting, 사고 대응 같은 항목을 다루며, 이 항목들은 token support, onboarding, freeze, redemption UX, audit log, dashboard로 내려온다.
MiCA와 GENIUS는 서로 다른 관할권의 규제 프레임워크다. EU의 MiCA는 ART와 EMT 발행자, 기술 기준, redemption plan, supervision을 중심으로 읽어야 한다. 미국의 GENIUS Act는 payment stablecoin issuer 체계와 Treasury rulemaking을 중심으로 읽어야 한다. 같은 "stablecoin regulation"이라도 제품 질문은 다르게 나온다.
2026-05-14 기준으로 확인한 공식 자료를 사용한다. 규제 문서는 시간 의존성이 높으므로 강의의 결론은 "최종 법률 판단"이 아니라 "출처, 상태, 접근일, 제품 영향, 재확인 주기를 남기는 방법"이다. 실제 제품 출시는 jurisdiction별 법무/컴플라이언스 검토가 필요하다.
학습 목표
- 규제 요구사항을 제품 요구사항으로 번역한다.
- 변동 가능한 규정 정보에 출처와 접근일을 붙인다.
- issuer 의무와 checkout product 의무를 구분해 질문 목록을 만든다.
개념 설명
핵심 가정 오류
발행/상환과 결제 상태가 분리되는가
운영 상태 누락
이벤트와 내부 원장이 대조되는가
학습 산출물 미흡
규제 문서를 제품 질문으로 번역하기
1. 규제 문서는 상태부터 확인한다
규제 자료를 읽을 때 첫 질문은 내용이 아니라 상태다. 법률인지, proposed rule인지, final guideline인지, consultation인지에 따라 제품에 반영하는 방식이 달라진다.
| 확인 항목 | 질문 | 제품 문서에 남길 값 |
|---|---|---|
| 관할권 | EU, US, 특정 state 중 어디인가? | jurisdiction |
| 문서 상태 | 법률, proposed rule, final guideline, consultation 중 무엇인가? | documentStatus |
| 적용 대상 | issuer, CASP, wallet, payment app, merchant 중 누구인가? | appliesTo |
| 적용일/의견기한 | 언제부터 적용되거나 언제 다시 바뀔 수 있는가? | effectiveDate, commentDeadline |
| 제품 영향 | onboarding, reserve, redemption, freeze, reporting 중 무엇에 영향이 있는가? | productImpact |
| 재확인 주기 | 다음 확인은 언제인가? | nextReviewAt |
이 표를 두지 않으면 "GENIUS에서 이렇게 한다더라", "MiCA는 이런 걸 요구한다더라" 같은 문장만 남는다. 강의자료에서는 규제 사실을 제품 요구사항으로 바꾸기 전에 문서 상태를 먼저 기록한다.
2. 개발자가 규제를 봐야 하는 이유
규제는 스마트컨트랙트 코드와 직접 연결된다. Issuer authorization은 누가 mint, burn, freeze를 할 수 있는지에 반영된다. Reserve requirement는 발행량, 상환, treasury reporting에 연결된다. Redemption rule은 withdrawal UX와 support flow에 영향을 준다. AML/sanctions requirement는 blacklist, freeze, KYT workflow로 들어온다. Jurisdiction 차이는 chain support와 사용자 접근 제한에 영향을 준다.
| 규제 요구 성격 | 코드/운영 반영 |
|---|---|
| 권한 있는 issuer | minter, burner, freezer, admin role 검토 |
| reserve와 liquidity | reserve disclosure link, dashboard signal, route disable 기준 |
| redemption | withdrawal 상태, support SLA, redemption plan |
| AML/CFT와 sanctions | onboarding, KYT, sanctions screening, freeze queue |
| reporting와 audit | event log, audit trail, reconciliation export |
| jurisdiction scope | user eligibility, supported jurisdiction, product disclosure |
3. MiCA는 ART/EMT와 발행자 의무부터 읽는다
EBA의 MiCA 페이지는 asset-referenced token(ART)과 e-money token(EMT) 발행자가 EU에서 관련 authorisation을 보유해야 한다고 설명한다. 또한 EBA는 reserve liquidity, own funds, stress testing, reporting, redemption plans, non-EU currency means-of-exchange 같은 technical standards와 guidelines를 관리한다. EBA의 redemption plan guidelines는 2025-02-10 적용일과 compliance deadline을 갖는 final material로 표시된다.
MiCA를 개발자가 읽을 때는 "우리 토큰이 정확히 어떤 법적 분류인가"를 직접 단정하지 않는다. 대신 법무가 판단해야 할 질문과 제품이 준비해야 할 상태를 분리한다.
- EU 사용자를 받는가?
- token이 EMT인지 ART인지 분류가 필요한가?
- issuer가 EU authorisation을 갖고 있는가?
- redemption/complaint/support flow가 필요한가?
- non-EU currency stablecoin의 means-of-exchange 제한을 모니터링해야 하는가?
- issuer가 significant ART/EMT로 분류될 가능성이 있는가?
- reserve, liquidity stress testing, recovery/redemption plan 관련 dashboard 신호가 필요한가?
4. GENIUS는 제정 상태와 rulemaking 상태를 나눠 읽는다
미국 Treasury는 2025-07-18에 GENIUS Act 제정 관련 발표를 냈다. 2026-04-01에는 state-level regulatory regimes가 federal framework와 substantially similar한지 판단하는 broad-based principles 관련 NPRM을 발표했다. 해당 발표에 따르면 총 발행액이 100억 달러 이하인 payment stablecoin issuer는 일정 조건에서 state-level regime을 선택할 수 있다. 2026-04-08에는 FinCEN과 OFAC가 GENIUS Act의 illicit finance 관련 proposed rule을 냈고, Treasury는 PPSI를 Bank Secrecy Act 목적상 financial institution으로 취급해 AML obligations와 sanctions compliance program을 부과하는 방향이라고 설명한다.
개발자 관점에서는 freeze/blacklist만 보면 부족하다. Onboarding, transaction monitoring, sanctions screening, audit log, suspicious activity escalation, issuer status check가 product workflow로 내려온다. 다만 proposed rule 단계인 내용은 최종 규칙처럼 단정하지 않고, source register에 상태와 다음 확인일을 남긴다.
GENIUS 관련 체크:
- issuer가 permitted payment stablecoin issuer인지 확인해야 하는가?
- reserve asset과 redemption requirement가 product disclosure에 들어가는가?
- state/federal regime 차이가 token support 정책에 영향을 주는가?
- illicit finance monitoring과 transaction screening을 어떻게 반영할 것인가?
- PPSI/issuer 의무가 우리 product의 KYT, freeze, support, reporting workflow에 어떤 영향을 주는가?
- proposed rule 단계인 항목과 이미 법률로 제정된 항목을 문서에서 구분했는가?
5. 규제를 제품 요구사항으로 번역한다
| 규제 문장 유형 | 제품 요구사항으로 바꾸는 질문 |
|---|---|
| issuer authorisation | 이 token을 지원하기 전에 issuer status를 어디서 확인하는가? |
| reserve/liquidity | reserve disclosure link, 갱신 주기, route disable threshold가 필요한가? |
| redemption right/plan | 사용자가 상환 가능성, 지연, support flow를 어디서 확인하는가? |
| AML/CFT | onboarding, transaction monitoring, suspicious activity escalation을 어디에 넣는가? |
| sanctions compliance | freeze/blacklist, KYT queue, manual review 상태가 필요한가? |
| state/federal regime | 특정 issuer/token을 state regime 기준으로 허용할지 법무 검토가 필요한가? |
| non-EU currency stablecoin | EU 사용자의 means-of-exchange 제한 모니터링이 필요한가? |
| reporting/audit | event log, admin action, reconciliation export 보존 기간이 필요한가? |
6. source register가 없으면 규제 레슨은 금방 낡는다
규제 레슨에는 반드시 source register가 있어야 한다. 아래 필드를 최소 기준으로 둔다.
| 필드 | 예시 |
|---|---|
jurisdiction | EU, US |
sourceTitle | EBA ART/EMT MiCA page, Treasury GENIUS NPRM |
sourceUrl | 공식 URL |
documentStatus | final guideline, proposed rule, press release |
publishedAt | 문서 발행일 |
accessedAt | 2026-05-14 |
productImpact | redemption, AML, issuer status, reporting |
owner | legal, compliance, product, engineering |
nextReviewAt | 월간 또는 rulemaking deadline 전 |
코드로 확인하기
위 설계 결정을 코드에서 확인한다. 상태, 서명, 원장 이동, 실패 처리가 어디에 놓이는지 따라 읽으면 앞의 모델이 실제 구현 경계로 내려온다.
백엔드규제 source register — TypeScript 데이터 모델
규제 문서는 발행일·접근일·상태가 같이 박혀야 stale 위험을 줄일 수 있다. 단순 URL 목록은 시간 지나면 신뢰도가 사라진다.
export type RegulationStatus = | "proposed-rule" | "final-rule" | "guideline" | "press-release" | "industry-letter";export type RegulationRef = { id: string; // e.g. "mica-emt-eba-2024" jurisdiction: "EU" | "US" | "UK" | "JP" | "KR" | "SG"; sourceTitle: string; sourceUrl: string; documentStatus: RegulationStatus; publishedAt: string; // ISO date accessedAt: string; // ISO date — 매월 갱신 productImpact: Array<"onboarding" | "redemption" | "kyt" | "reporting" | "issuer-status">; owner: "legal" | "compliance" | "product" | "engineering"; nextReviewAt: string; legalReviewRequired: boolean;};export const REGULATIONS: RegulationRef[] = [ { id: "mica-emt-eba-2024", jurisdiction: "EU", sourceTitle: "EBA: Asset-referenced and e-money tokens under MiCA", sourceUrl: "https://www.eba.europa.eu/...", documentStatus: "guideline", publishedAt: "2024-06-30", accessedAt: "2026-05-14", productImpact: ["issuer-status", "redemption", "reporting"], owner: "legal", nextReviewAt: "2026-08-14", legalReviewRequired: true }];백엔드Jurisdiction 기반 결제 가드 — pseudo policy engine
사용자 KYC 결과와 규제 register를 결합해 어떤 결제 경로가 허용되는지 결정. 개발자가 임의 판단하지 않도록
legalReviewRequired === true항목은 차단한다.
export type CheckoutContext = { payerJurisdiction: "EU" | "US" | "UK" | "JP" | "KR" | "SG" | "OTHER"; merchantJurisdiction: "EU" | "US" | "UK" | "JP" | "KR" | "SG" | "OTHER"; stablecoinIssuer: "circle-usdc" | "circle-eurc" | "paypal-pyusd" | "maker-dai";};export type PolicyDecision = | { kind: "allow" } | { kind: "block"; reason: string; rule: string } | { kind: "manual-review"; reason: string; rule: string };export function evaluatePaymentPolicy(ctx: CheckoutContext): PolicyDecision { // 예시 정책 — 실제 정책은 legal 팀과 함께 작성, 코드에 박힌 정책은 단순 게이트 if (ctx.payerJurisdiction === "EU" && ctx.stablecoinIssuer === "paypal-pyusd") { return { kind: "manual-review", reason: "EU payer + non-MiCA stablecoin — legal review required", rule: "mica-emt-eba-2024" }; } if (ctx.payerJurisdiction === "OTHER") { return { kind: "block", reason: "Unsupported jurisdiction", rule: "internal-jurisdiction-list" }; } return { kind: "allow" };}운영규제 갱신 점검 cron — 90일 이상 stale 알림
source register의 accessedAt 이 만료되면 자동으로 owner 에게 ticket 생성.
import { REGULATIONS } from "./regulations";const STALE_DAYS = 90;export function findStaleRegulations(now = new Date()) { return REGULATIONS.filter((r) => { const accessed = new Date(r.accessedAt); const days = (now.getTime() - accessed.getTime()) / 86_400_000; return days > STALE_DAYS; });}// cron: 매일 09:00export async function dailyRegulationCheck() { const stale = findStaleRegulations(); for (const r of stale) { await createTicket({ assignee: r.owner, title: `[regulation-stale] ${r.id} accessed ${r.accessedAt}`, priority: r.documentStatus === "final-rule" ? "high" : "medium", body: `재확인 필요: ${r.sourceUrl}\n제품 영향: ${r.productImpact.join(", ")}` }); }}강의 포인트
| 관점 | 강의 중 확인할 질문 | 학습 후 남길 증거 |
|---|---|---|
| 문서 상태 | 이 자료는 법률, proposed rule, final guideline 중 무엇인가? | documentStatus와 accessedAt |
| 적용 단위 | issuer 의무인가, checkout product 의무인가? | issuer/product/legal/ops 질문 분리표 |
| 제품 영향 | 어떤 workflow가 바뀌는가? | onboarding, redemption, KYT, reporting 영향 목록 |
| 운영 갱신 | 언제 다시 확인할 것인가? | source register와 nextReviewAt |
| 법무 경계 | 개발자가 단정하면 안 되는 판단은 무엇인가? | legal review required 항목 |
실무 예시
백엔드[OPS] USDC checkout 서비스를 EU와 US 사용자에게 제공하려는 팀을 가정한다. 개발팀은 "USDC를 받으면 된다"가 아니라 아래 질문을 제품 launch checklist에 넣어야 한다.
| 영역 | 질문 | 담당 |
|---|---|---|
| Token support | 이 stablecoin issuer는 해당 관할권에서 어떤 상태인가? | Legal/Compliance |
| User access | EU/US 사용자를 동일하게 받을 수 있는가? | Legal/Product |
| Redemption | 사용자가 상환 지연이나 제한을 어디서 확인하는가? | Product/Ops |
| Reserve disclosure | reserve/attestation link를 dashboard에 넣을 것인가? | Product/Ops |
| KYT/sanctions | 의심 거래, sanctioned address, manual review를 어떻게 처리하는가? | Compliance/Engineering |
| Audit log | freeze, route disable, manual review action을 얼마나 보관하는가? | Engineering/Ops |
| Source review | MiCA/GENIUS 자료를 언제 다시 확인하는가? | Compliance/Product |
이 표는 변호사를 대체하지 않는다. 다만 법무 검토 전에 개발팀이 어떤 정보를 준비해야 하는지 명확히 만든다. 특히 issuer 의무와 checkout product 의무를 섞지 않아야 한다. Issuer가 해야 할 reserve reporting을 우리 product가 직접 수행한다고 쓰면 안 되고, product가 확인해야 할 disclosure link와 user-facing status를 분리해야 한다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 바로잡는 방법 |
|---|---|---|
| 규제는 법무만 보면 된다고 생각한다 | 제품에 redemption 상태, KYT queue, audit log가 빠진다 | 규제 요구를 workflow와 데이터 필드로 번역한다 |
| proposed rule을 final rule처럼 단정한다 | 제품 문서가 확정되지 않은 요구사항을 고정 사실로 적는다 | documentStatus와 nextReviewAt을 둔다 |
| issuer 의무를 checkout product 의무로 착각한다 | reserve reporting을 product가 직접 보증하는 것처럼 표시한다 | issuer disclosure와 product 확인/표시 의무를 분리한다 |
| 관할권 차이를 token address allowlist만으로 처리한다 | EU/US 사용자 접근, issuer status, state/federal regime 차이를 놓친다 | jurisdiction-aware launch checklist를 둔다 |
| AML/sanctions를 freeze 함수 하나로 본다 | onboarding, transaction monitoring, suspicious activity escalation이 빠진다 | KYT, screening, manual review, audit trail을 workflow로 둔다 |
실습 과제
- 운영규제 문서를 제품 질문으로 번역하기: MiCA와 GENIUS 자료에서 authorisation, reserve, redemption, AML/sanctions, reporting 항목을 골라 제품/법무/운영 질문으로 나눈다.
- 백엔드regulatory source register 만들기: 관할권, 문서명, 상태, 발행일, 접근일, 다음 확인일, 제품 영향, 담당자 필드를 가진 출처 관리표를 작성한다.
- 운영[BACKEND] checkout 출시 전 규제 질문 10개 작성하기: EU 사용자 지원, US payment stablecoin 지원, redemption 안내, KYT/sanctions, issuer status 확인을 포함해 출시 전 확인 질문 10개를 만든다.
완료 기준
- 규제 문서의 상태를 구분했다.
- 제품 요구사항으로 바꾼 질문 목록을 만들었다.
- 출처 갱신 주기를 정했다.
- MiCA와 GENIUS의 적용 단위를 제품, 법무, 운영 질문으로 나눴다.
근거 자료
- 스테이블코인 규제 MiCA GENIUS: 01-스테이블코인/06-스테이블코인-규제-MiCA-GENIUS.md
- 스테이블코인 규제 GENIUS MiCA: 90-출처/원문-노트/스테이블코인-규제-GENIUS-MiCA.md
- EBA: Asset-referenced and e-money tokens under MiCA: https://www.eba.europa.eu/regulation-and-policy/asset-referenced-and-e-money-tokens-mica
- EBA: Guidelines on redemption plans under MiCAR: https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/asset-referenced-and-e-money-tokens-micar-4?version=2024
- U.S. Treasury: GENIUS Act enactment statement: https://home.treasury.gov/news/press-releases/sb0197
- U.S. Treasury: GENIUS Act state-level regulatory regimes NPRM: https://home.treasury.gov/news/press-releases/sb0428
- U.S. Treasury: GENIUS Act illicit finance proposed rule: https://home.treasury.gov/news/press-releases/sb0435