비EVM 실무 체크리스트
도입
비EVM 체인을 지원할지 결정할 때 "개발자가 익숙하지 않다"는 말은 판단 근거가 되기 어렵다. 실무 판단은 더 구체적이어야 한다. 해당 체인의 token standard가 무엇인지, 공식 issuer가 있는지, wallet과 custody가 지원하는지, indexer가 정산에 필요한 데이터를 안정적으로 주는지, compliance vendor가 주소와 transaction을 해석할 수 있는지 확인해야 한다.
이 레슨은 앞의 Move/Sui/Aptos, Solana account model, Token-2022 레슨을 하나의 Go/No-Go packet으로 묶는다. 캡스톤에서는 모든 체인을 다 지원하는 것이 목표가 아니라, 지원 범위와 제외 범위를 설명 가능한 기준으로 정하는 것이 목표다.
학습 목표
- 비EVM 체인 도입을 SDK, wallet, token, monitoring 기준으로 검토한다.
- 캡스톤에서 비EVM 지원을 보류하거나 제한하는 근거를 만든다.
개념 설명
비EVM 체인 도입을 SDK, wallet, token, monitoring 기준으로 검토한다.
체인별 ownership 모델을 오해하지 않는가
비EVM 실무 체크리스트 이해 점검
체크 항목 12개를 작성했다.
Go/No-Go packet의 구조
비EVM 도입 평가는 체크박스만 채우면 끝나는 문서가 아니다. 제품, 보안, 운영, compliance, support가 같은 결론을 볼 수 있도록 다음 다섯 장으로 만든다.
| 장 | 포함할 내용 | 결론 형태 |
|---|---|---|
| Chain model | account/resource/object model, finality, transaction assembly | EVM adapter와 달라지는 부분 |
| Token support | issuer, mint/contract address, standard, extension, decimals | allowlist와 unsupported feature |
| Integration | wallet, custody, on-ramp, SDK, local test, explorer | production 가능/보류 |
| Operations | indexer, monitoring, reconciliation, incident response | 필요한 dashboard와 runbook |
| Compliance | KYT vendor, freeze/denylist, disclosure, admin authority | 정책 검토 필요 여부 |
기본 체크리스트
| 영역 | 확인 항목 | 실패하면 생기는 일 |
|---|---|---|
| Token | official issuer support, mint/contract allowlist | 가짜 자산 또는 wrapped asset을 받는다. |
| Amount | decimals, display amount, fee/net amount | invoice와 정산 금액이 어긋난다. |
| Special feature | fee, hook, pause, freeze, confidential transfer | 지갑/SDK는 전송 성공처럼 보이지만 실제 정책이 깨진다. |
| Wallet | user wallet, multisig, sponsored transaction 표시 | 사용자가 승인 내용을 이해하지 못한다. |
| Custody | custodian 입출금, freeze, memo/tag 지원 | 기관 고객이 입출금을 처리하지 못한다. |
| Indexer | balance diff, event/log, object transfer | dashboard와 회계 원장이 누락된다. |
| Monitoring | RPC health, finality, retry, stuck tx | 운영자가 장애 범위를 파악하지 못한다. |
| Compliance | KYT vendor, sanctions screening, audit evidence | alert와 manual review가 체인별로 끊긴다. |
Solana 추가 체크
Solana는 account list가 제품 입력 검증 목록이 된다. SPL Token과 Token-2022를 구분하고, token account owner와 mint authority를 나눠 봐야 한다.
| 항목 | 체크 질문 |
|---|---|
| Program ID | mint가 legacy SPL Token인지 Token-2022인지 구분했는가 |
| ATA | source/destination ATA가 없을 때 누가 생성하고 비용을 내는가 |
| Authority | mint authority, freeze authority, permanent delegate가 누구인가 |
| Transfer Hook | extra account list와 hook failure UX를 준비했는가 |
| Transfer Fee | invoice amount와 net received amount를 분리했는가 |
| Confidential Transfer | auditor/reconciliation path와 현재 availability를 확인했는가 |
Move/Sui/Aptos 추가 체크
Move 계열은 token contract 주소 하나를 allowlist하는 방식만으로 부족할 수 있다. asset standard, object/resource ownership, capability 보관 위치를 함께 봐야 한다.
| 항목 | 체크 질문 |
|---|---|
| Asset model | coin/object/resource 중 무엇을 결제 단위로 보는가 |
| Authority | treasury cap, resource account, module owner를 누가 통제하는가 |
| Upgrade | package/module upgrade 권한과 정책이 있는가 |
| Refund | object/resource ownership이 결제 취소와 환불 경로를 바꾸는가 |
| Indexer | object transfer, coin balance, account resource 변화를 안정적으로 읽는가 |
| Wallet | sponsored transaction, multisig, asset metadata 표시가 충분한가 |
코드로 확인하기
비EVM 체크리스트는 "새 체인도 지원한다"는 선언을 검증 가능한 항목으로 바꿔야 한다. chain별 account model, finality, token extension, indexer 경계가 모두 다르기 때문이다.
운영비EVM 지원 매트릭스
non_evm_support_matrix: solana: account_model_reviewed: true token2022_extensions_indexed: true pda_seed_documented: true sui: object_ownership_reviewed: true capability_model_reviewed: true event_indexer_ready: false aptos: resource_model_reviewed: true coin_store_reconciliation_ready: falsematrix는 미지원 항목을 숨기지 않는다. false인 항목은 학습자에게 "다음 실습에서 채울 부분"으로 남긴다.
백엔드chain별 준비도 점수 계산
type ChainReadiness = Record<string, Record<string, boolean>>;function readinessScore(matrix: ChainReadiness) { return Object.fromEntries( Object.entries(matrix).map(([chain, checks]) => { const values = Object.values(checks); const passed = values.filter(Boolean).length; return [chain, Math.round((passed / values.length) * 100)]; }) );}이 점수는 지원 여부를 단순 yes/no로 보여주지 않는다. capstone에서는 낮은 점수의 chain을 production path에서 제외하고 lab path로만 남긴다.
강의 포인트
좋은 체크리스트는 "지원 가능"이라는 결론보다 "어느 범위까지 지원하는가"를 더 분명하게 만든다. 예를 들어 Solana USDC를 지원하더라도 Token-2022 Transfer Hook 자산은 manual review로 보내거나, Confidential Transfer는 roadmap-only로 둘 수 있다. Sui/Aptos도 issuer support는 가능하지만 custody나 indexer가 부족하면 beta 제한으로 시작해야 한다.
체크리스트의 최종 문장은 다음 세 가지 중 하나여야 한다.
| 결론 | 의미 | 후속 행동 |
|---|---|---|
| Go | production checkout에 넣을 수 있다. | allowlist, monitoring, support 문서 작성 |
| Limited Go | 특정 wallet, custody, asset만 제한 지원한다. | UI badge, manual fallback, SLA 제한 |
| No-Go | 지금은 지원하지 않는다. | 보류 사유와 재검토 조건 기록 |
실무 예시
비EVM chain adoption scorecard는 다음처럼 작성한다.
| 기준 | 점수 | 증거 | 결론 |
|---|---|---|---|
| Official stablecoin issuer | 3/3 | issuer 문서와 mint allowlist 확인 | Go |
| Wallet coverage | 2/3 | 주요 wallet 2개 지원, hardware wallet 제한 | Limited Go |
| Custody support | 1/3 | 입금은 가능, program extension 일부 미지원 | Manual review |
| Indexing/reconciliation | 2/3 | balance diff 가능, extension decoding 추가 필요 | Limited Go |
| Compliance/KYT | 1/3 | vendor coverage beta | No-Go risk |
| Developer tooling | 2/3 | SDK와 local test 가능, simulation 문서 보강 필요 | Limited Go |
이 점수표만으로 결론을 내리지는 않는다. 낮은 점수가 customer impact로 이어지는지, manual process로 막을 수 있는지, support team이 설명 가능한지를 함께 판단한다.
흔한 오해와 실패 시나리오
| 오해 | 실패 장면 | 바로잡는 기준 |
|---|---|---|
| 체인 지원은 RPC와 SDK가 있으면 끝난다. | wallet/custody가 지원하지 않아 실제 사용자가 입출금을 못 한다. | product integration 항목을 token support와 같은 비중으로 평가한다. |
| issuer support가 있으면 모든 token variant를 받을 수 있다. | extension, wrapped asset, wrong mint를 구분하지 못해 정산 사고가 난다. | chain별 mint/contract allowlist와 extension policy를 둔다. |
| monitoring은 나중에 붙이면 된다. | account model 차이 때문에 실패 원인을 분류하지 못한다. | launch 전 failure taxonomy와 dashboard field를 정의한다. |
| No-Go는 실패다. | 준비되지 않은 chain을 억지로 열어 support와 compliance 비용이 폭증한다. | No-Go는 재검토 조건을 남기는 정상적인 제품 결정이다. |
실습 과제
- 비EVM 실무 체크리스트 이해 점검: SDK maturity, wallet coverage, token support, explorer, monitoring, custody, compliance를 평가한다. 각 항목에 증거 링크 또는 내부 근거 문서를 붙이고
Go,Limited Go,No-Go중 하나를 표시한다. - 비EVM 실무 체크리스트 적용 과제: 비EVM 체인 하나를 선택해 checkout 지원 Go/No-Go 보고서를 작성한다. 지원 범위와 제외 범위, 보류 사유, 재검토 조건, 필요한 dashboard field를 포함한다.
완료 기준
- token, product integration, Solana, Move/Sui/Aptos 항목을 포함해 체크 항목 12개 이상을 작성했다.
- 지원 범위와 제외 범위를
Go,Limited Go,No-Go중 하나로 결정했다. - 보류 사유와 재검토 조건을 캡스톤 문서에 남겼다.
근거 자료
- 비EVM 실무 체크리스트: 07-비EVM/03-비EVM-실무-체크리스트.md
- Solana Accounts Documentation: https://solana.com/docs/core/accounts
- Solana Token Extensions Documentation: https://solana.com/docs/tokens/extensions
- Sui Move Documentation: https://docs.sui.io/concepts/sui-move-concepts