스테이블코인 실무 체크리스트
도입
체크리스트는 출시 직전에 읽는 장식 문서가 아니다. 스테이블코인 checkout을 운영하려면 token support, issuer 권한, compliance, 서명 결제, cross-chain, 정산, dashboard, 테스트가 모두 연결돼야 한다. 하나라도 빈칸이면 기능은 동작해도 운영은 실패할 수 있다.
이 강의에서는 원본 체크리스트를 출시 게이트로 바꾼다. 각 항목에는 owner, evidence, review cadence, blocker 여부가 붙어야 한다. "검토했다"가 아니라 "누가 어떤 근거로 언제 다시 확인할 것인지"까지 남기는 것이 목표다.
학습 목표
- 스테이블코인 도입 전 검토 항목을 제품 요구사항으로 바꾼다.
- 캡스톤에 필요한 결제, 운영, 리스크 항목을 선정한다.
- 체크리스트 항목마다 owner, evidence, review cadence, blocker 여부를 붙인다.
개념 설명
01
핵심 개념
- 스테이블코인 도입 전 검토 항목을 제품 요구사항으로 바꾼다.
- 캡스톤에 필요한 결제, 운영, 리스크 항목을 선정한다.
02
검증 지점
- 발행/상환과 결제 상태가 분리되는가
- 이벤트와 내부 원장이 대조되는가
- 핵심 체크 항목 15개를 작성했다.
03
실습 산출물
- Release gate 체크리스트 작성하기
- Checkout MVP Go/No-Go 판정하기
- 페그·유동성 위험이 표시되는가
1. 체크리스트를 release gate로 바꾼다
단순 체크박스는 시간이 지나면 의미가 없어진다. 실무 체크리스트는 아래 구조를 가져야 한다.
| 필드 | 의미 |
|---|---|
| Gate | Token support, payment, cross-chain 같은 검토 영역 |
| Check | 확인할 항목 |
| Owner | Product, Backend, Smart contract, Compliance, Finance, Ops 중 책임자 |
| Evidence | 공식 문서 URL, 테스트 결과, dashboard screenshot, runbook 링크 |
| Cadence | 출시 전 1회, 매 배포, 매일, 매월 등 재검토 주기 |
| Blocker | 실패 시 출시 차단인지 제한 출시인지 |
| Status | Green, Yellow, Red |
Status가 Red인 항목은 기능 구현이 끝났어도 출시를 막는다. Yellow는 한도 축소, 특정 chain 제외, manual review 같은 제한 출시 조건이 있어야 한다.
2. Token support gate
| Check | Owner | Evidence | Cadence | Blocker |
|---|---|---|---|---|
| chain ID와 token address가 공식 출처 기준으로 명시되어 있다. | Backend | Circle/Paxos/issuer docs, explorer link | 매 배포 전 | Yes |
| native token과 bridged/wrapped token을 구분한다. | Product/Backend | token registry, UI copy | 매 token 추가 시 | Yes |
| decimals, symbol, name을 하드코딩하지 않고 검증한다. | Backend | config validation test | 매 배포 | Yes |
| allowlisted token만 받는다. | Smart contract/Backend | allowlist test, route config | 매 배포 | Yes |
| token upgrade/migration 공지 대응 절차가 있다. | Ops | runbook, alert channel | 월 1회 | Yellow |
공식 주소 검증은 변동 가능성이 큰 항목이다. 예를 들어 USDC contract address는 Circle 개발자 문서에서 chain별로 확인해야 하고, 신규 chain이 추가될 때마다 source register를 갱신해야 한다.
3. Authority와 compliance gate
| Check | Owner | Evidence | Cadence | Blocker |
|---|---|---|---|---|
| mint, burn, freeze, pause, admin 권한이 분리되어 있다. | Smart contract | role matrix, deployment script | 배포 전 | Yes |
| 마지막 admin 제거가 불가능하다. | Smart contract | invariant/unit test | 배포 전 | Yes |
| role 변경 event를 indexer가 추적한다. | Backend/Ops | alert test, dashboard card | 매 배포 | Yes |
frozen 주소가 transfer, transferFrom, approve, permit, ERC-3009로 우회할 수 없다. | Security | integration test | 배포 전 | Yes |
| pause 상태에서 refund/emergency path 정책이 명확하다. | Product/Ops | incident runbook | 배포 전 | Yes |
권한 gate는 technical gate이면서 support gate다. 사용자가 서명한 뒤 주소가 freeze되거나 토큰이 paused되면 결제는 실패할 수 있다. 이 실패를 payment state와 support flow로 남겨야 한다.
4. Payment와 signed authorization gate
| Check | Owner | Evidence | Cadence | Blocker |
|---|---|---|---|---|
| payment ID와 invoice ID가 onchain/offchain에서 연결된다. | Backend | event schema, DB migration | 배포 전 | Yes |
Created, Signed, Submitted, Paid, Delivered, Settled, Refunded, Failed 상태가 있다. | Product/Backend | state machine diagram | 배포 전 | Yes |
| relayer가 제출하지 않을 때 사용자 대응이 있다. | Product/Ops | timeout copy, retry policy | 배포 전 | Yellow |
| 중복 결제와 중복 환불을 막는다. | Backend/Security | idempotency test | 배포 전 | Yes |
| service delivery와 payment settlement가 분리되어 있다. | Product/Finance | ledger policy | 배포 전 | Yes |
| EIP-712 domain separator가 chain ID와 verifying contract를 포함한다. | Smart contract | signature test | 배포 전 | Yes |
| permit deadline과 ERC-3009 valid window가 짧고 명확하다. | Security | test vector | 배포 전 | Yes |
| nonce 재사용 테스트가 있다. | Security | replay test | 배포 전 | Yes |
| typed data UI에서 spender/recipient/amount/token/chain을 보여준다. | Frontend/Product | screenshot, QA note | 배포 전 | Yellow |
| Permit2를 쓰면 allowance가 token contract가 아닌 Permit2 contract에 저장됨을 문서화한다. | Product/Security | user copy, risk note | 배포 전 | Yellow |
ERC-2612와 ERC-3009는 둘 다 서명 기반 UX를 돕지만 실패 조건이 다르다. Permit은 allowance를 만들고, ERC-3009는 transfer 자체를 승인한다. Checkout gate에서는 어떤 방식이 선택됐는지, 어떤 nonce와 deadline을 쓰는지 분명히 적어야 한다.
5. Cross-chain gate
| Check | Owner | Evidence | Cadence | Blocker |
|---|---|---|---|---|
| source chain과 destination chain 상태를 분리한다. | Backend/Product | cross-chain state table | 배포 전 | Yes |
| CCTP burn 후 mint 전 중간 상태를 사용자에게 보여준다. | Product/Frontend | pending UX screenshot | 배포 전 | Yellow |
| bridge token과 native token을 같은 asset으로 취급하지 않는다. | Backend/Product | asset registry | 배포 전 | Yes |
| chain finality와 confirmation 기준이 있다. | Backend/Ops | finality policy | 배포 전 | Yes |
| stuck transfer manual review가 있다. | Ops/Support | queue schema, runbook | 배포 전 | Yes |
Circle CCTP는 source burn, Circle attestation, destination mint를 거친다. 따라서 checkout 제품은 "전송 완료" 하나만 표시하지 말고 중간 상태와 stuck transfer 대응을 가져야 한다.
6. Test와 monitoring gate
| Check | Owner | Evidence | Cadence | Blocker |
|---|---|---|---|---|
| 권한 없는 mint/burn/freeze/pause 실패 | Smart contract | unit/integration test | CI | Yes |
| frozen account 모든 이동 경로 실패 | Security | transfer/approve/permit/ERC-3009 test | CI | Yes |
| totalSupply와 balances 합 일치 | Smart contract | invariant test | CI | Yes |
| authorization nonce 재사용 실패 | Security | replay test | CI | Yes |
| payment state double spend 방지 | Backend | state machine test | CI | Yes |
| refund idempotency | Backend/Finance | duplicate refund test | CI | Yes |
| CCTP double mint 방지 | Backend/Security | cross-chain simulator | CI 또는 release test | Yes |
| role/pause/freeze/upgrade event alert | Ops | dashboard alert test | 매 배포 | Yes |
| indexer lag와 settlement mismatch alert | Backend/Ops | dashboard card, runbook | 매일 | Yes |
테스트 gate는 "테스트가 있다"가 아니라 어떤 출시 위험을 막는지 보여줘야 한다. Solidity 보안 문서가 강조하는 것처럼 스마트컨트랙트는 토큰과 가치 있는 자산을 다루므로 경고와 실패 시나리오를 가볍게 보면 안 된다.
7. Go/No-Go 판정표
| 영역 | Green | Yellow | Red |
|---|---|---|---|
| Token support | 공식 주소와 chain policy 검증 완료 | 신규 chain은 한도 제한 | 주소/chain 출처 불명 |
| Authority/compliance | role, freeze, pause 테스트와 alert 완료 | 일부 support copy 미완성 | frozen account 우회 가능 |
| Payment | 상태머신과 idempotency 테스트 완료 | relayer retry UX 제한 | 중복 결제/환불 가능 |
| Signed authorization | domain, deadline, nonce 테스트 완료 | typed data copy 개선 필요 | replay 가능 또는 chain mismatch |
| Cross-chain | source/destination 상태와 stuck queue 완료 | 특정 route manual review | native/bridged 혼동 |
| Reconciliation/dashboard | mismatch queue와 threshold 완료 | 일부 KPI 수동 확인 | settlement mismatch 감지 불가 |
Red가 하나라도 있으면 출시하지 않는다. Yellow는 출시 범위와 한도를 명시해야 한다. 예를 들어 "Base USDC만 1,000달러 이하로 enable, CCTP route는 manual review"처럼 product policy로 바꿔야 한다.
8. Capstone 문서로 연결한다
최종 capstone은 stablecoin checkout 시스템을 설계하는 문서다. 이 체크리스트는 capstone의 마지막 장이 아니라 모든 장을 연결하는 검증표로 쓰인다.
| Capstone 장 | 체크리스트에서 재사용할 표 |
|---|---|
| 시스템 맵 | actor/layer/source register |
| 결제 UX | payment 상태머신과 signed authorization gate |
| Token support | chain/token registry와 native/bridged 구분 |
| Cross-chain | CCTP source/attestation/destination 상태표 |
| Risk dashboard | peg, liquidity, admin event, indexer lag, settlement mismatch KPI |
| Reconciliation | raw event, payment DB, settlement ledger 분리표 |
| Launch review | Go/No-Go 판정표 |
코드로 확인하기
위 설계 결정을 코드에서 확인한다. 상태, 서명, 원장 이동, 실패 처리가 어디에 놓이는지 따라 읽으면 앞의 모델이 실제 구현 경계로 내려온다.
운영체크리스트 항목 YAML — 단순 체크박스를 운영 가능한 행으로
모든 체크 항목에 owner, evidence, cadence, blocker 여부가 같이 들어가야 release gate가 작동한다.
# launch-checklist.yamlrelease: stablecoin-checkout-v1.0checklist: - id: token-registry description: Native USDC 주소 allowlist + decimals 검증 status: green evidence: - "test: TokenRegistry.t.sol::testAllowedAddressesOnly → PASS" - "source: developers.circle.com/stablecoins/usdc-contract-addresses (accessed 2026-05-14)" owner: backend-team cadence: monthly blocker_if_red: true - id: signed-payment-state description: permit 성공 / transferFrom 실패가 별도 상태로 표현됨 status: green evidence: - "test: SignedPayment.t.sol::testPermitSuccessTransferFailExposesAllowanceSet → PASS" owner: payments-team cadence: on-change blocker_if_red: true - id: cctp-stuck-handling description: Burned 1시간 이상 destination mint 안 됨 → manual review 큐 진입 status: yellow evidence: - "runbook: cctp-stuck.md (draft)" compensating_controls: - "단일 chain checkout 만 우선 출시" owner: payments-team cadence: weekly expires: 2026-07-01 - id: depeg-detection description: 5분 평균 페그 이탈 50bps 초과 시 신규 결제 차단 status: green evidence: - "sql: peg_deviation_5m_alert.sql" - "alert: pagerduty service-payments-depeg" owner: risk-team cadence: continuous blocker_if_red: truego_no_go: blocker_count_red: 0 yellow_with_owner_and_expiry: true policy: "red 0개 + yellow 항목 모두 owner/expiry 보유 시 GO"운영CI에서 체크리스트 검증 — TypeScript
launch-checklist.yaml 을 release PR 머지 조건으로 강제한다. 만료된 yellow도 자동 차단.
import { readFileSync } from "node:fs";import { parse } from "yaml";type ChecklistItem = { id: string; status: "red" | "yellow" | "green"; owner?: string; expires?: string; blocker_if_red?: boolean;};export function validateLaunchChecklist(path: string) { const packet = parse(readFileSync(path, "utf8")) as { checklist: ChecklistItem[] }; const errors: string[] = []; for (const item of packet.checklist) { if (item.status === "red" && item.blocker_if_red) { errors.push(`${item.id}: status=red blocks release`); } if (item.status === "yellow") { if (!item.owner) errors.push(`${item.id}: yellow without owner`); if (!item.expires) errors.push(`${item.id}: yellow without expiry`); else if (new Date(item.expires) < new Date()) { errors.push(`${item.id}: yellow expired ${item.expires}`); } } } if (errors.length) { console.error(errors.join("\n")); process.exit(1); } console.log(`OK — ${packet.checklist.length} items validated`);}운영Capstone 재사용 표 — Markdown 템플릿
캡스톤 설계 문서에 그대로 붙여 넣을 표 골격. 강의별 산출물이 칼럼별로 매핑된다.
## Stablecoin Checkout — Launch Packet| Capstone 장 | 출처 강의 | 산출물 | 상태 | Owner ||---|---|---|---|---|| 시스템 맵 | stablecoin-systems/01 | actor/layer/source register | green | backend || 결제 UX | stablecoin-systems/03, 04 | signed-payment + payment state machine | green | payments || Token support | stablecoin-systems/01, 10 | chain/token registry | green | backend || Cross-chain | stablecoin-systems/05 | CCTP burn/attest/mint table | yellow | payments || Risk dashboard | stablecoin-systems/12 | KPI catalog + thresholds | green | risk || Reconciliation | stablecoin-systems/12 | 3-tier ledger schema | green | indexer || Security review | security-testing/* | review packet yaml | green | security || Launch review | stablecoin-systems/13 | this checklist | yellow | release-manager |강의 포인트
| 관점 | 강의 중 확인할 질문 | 학습 후 남길 증거 |
|---|---|---|
| Gate 설계 | 단순 체크박스를 owner/evidence/cadence/blocker로 바꿨는가? | release gate 표 |
| 출시 판정 | Red와 Yellow 항목을 어떻게 처리할지 정했는가? | Go/No-Go 판정표 |
| Capstone 연결 | 앞선 강의 산출물을 하나의 설계 문서로 묶었는가? | capstone 목차와 재사용 표 |
| 운영 책임 | 출시 후 누가 어떤 주기로 다시 확인하는가? | review cadence와 owner |
실무 예시
운영상황: 팀이 Base USDC checkout MVP를 출시하려 한다. Smart contract 테스트는 통과했지만, CCTP stuck transfer queue가 아직 없고, typed data 화면에는 chain과 verifying contract가 표시되지 않는다.
| 항목 | 상태 | 판정 |
|---|---|---|
| Base USDC 공식 주소 검증 | Circle docs와 explorer 확인 완료 | Green |
| 결제 상태머신 | Created부터 Refunded까지 구현/테스트 완료 | Green |
| Typed data copy | amount/token은 보이나 chain/verifying contract 누락 | Yellow |
| CCTP stuck queue | 없음 | Red |
| settlement mismatch alert | dashboard card 있음 | Green |
이 경우 출시는 막는다. Red 항목인 stuck queue는 사용자의 돈이 source chain에서 burn된 뒤 destination mint가 지연될 때 support가 대응할 방법이 없다는 뜻이다. Yellow 항목은 제한 출시 조건이 될 수 있지만, Red 항목은 해결 전까지 Go가 아니다.
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| 체크리스트를 QA 마지막 단계로만 본다. | 각 항목은 설계 초기부터 owner와 evidence를 가져야 한다. |
| 테스트 통과가 곧 출시 가능이라고 본다. | 운영 queue, support copy, dashboard alert가 없으면 Red일 수 있다. |
| Yellow를 그냥 넘어간다. | Yellow는 제한 출시 조건과 후속 owner가 있어야 한다. |
| Capstone은 새 문서를 따로 쓰면 된다고 생각한다. | 앞선 강의의 표와 상태머신을 재사용해야 설계가 일관된다. |
실습 과제
- 운영Release gate 체크리스트 작성하기: Token support, authority/compliance, payment, signed authorization, cross-chain, testing/monitoring 영역별로 owner, evidence, review cadence, blocker 여부를 채운다.
- 운영Checkout MVP Go/No-Go 판정하기: USDC checkout MVP를 가정하고 각 gate의 status를 Green/Yellow/Red로 판정한 뒤 Red는 출시 차단, Yellow는 제한 출시 조건으로 정리한다.
- 운영Capstone 산출물 구조 만들기: 최종 capstone 문서에서 재사용할 시스템 맵, payment 상태머신, risk dashboard, reconciliation job, release gate 표 목차를 작성한다.
완료 기준
- 핵심 체크 항목 15개를 작성했다.
- 출시 차단 조건을 정했다.
- 캡스톤에서 재사용할 표 구조를 만들었다.
- Go/No-Go 판정표와 보류 항목 처리 방식을 정의했다.
근거 자료
- 스테이블코인 실무 체크리스트: 01-스테이블코인/07-스테이블코인-실무-체크리스트.md
- Circle USDC Contract Addresses: https://developers.circle.com/stablecoins/usdc-contract-addresses
- Circle CCTP Technical Guide: https://developers.circle.com/cctp/technical-guide/
- ERC-2612: Permit Extension for EIP-20 Signed Approvals: https://eips.ethereum.org/EIPS/eip-2612
- ERC-3009: Transfer With Authorization: https://eips.ethereum.org/EIPS/eip-3009
- Solidity Security Considerations: https://docs.solidity.org/en/latest/security-considerations.html