Move, Sui, Aptos 비교
도입
Solidity 개발자가 비EVM 체인을 배울 때 가장 먼저 버려야 할 감각은 "토큰은 contract 안의 balance mapping"이라는 전제다. Move 계열에서는 자산, 소유권, 권한을 언어와 런타임 모델이 더 강하게 다룬다. 그래서 같은 stablecoin transfer라도 어떤 객체가 움직이는지, 어떤 resource가 권한을 증명하는지, 어떤 indexer가 잔고 변화를 읽는지가 달라진다.
이 레슨의 목적은 Sui와 Aptos의 문법을 외우는 것이 아니다. checkout, 환불, 발행/상환, freeze, 정산 대시보드를 설계할 때 EVM식 모델을 그대로 옮기면 어디서 깨지는지 판단하는 훈련을 한다.
학습 목표
- Move의 resource/capability 사고를 EVM과 비교한다.
- Sui와 Aptos의 객체/계정 모델 차이를 학습한다.
개념 설명
Move의 resource/capability 사고를 EVM과 비교한다.
숨길 데이터와 공개할 데이터가 분리되는가
Move resource 개념을 설명했다.
상태 모델이 곧 제품 모델
EVM에서는 contract address 하나가 code와 storage를 함께 들고 있고, ERC-20 잔고는 대개 mapping(address => uint256)로 표현된다. 반면 Move 계열에서는 자산과 권한이 resource, object, capability로 표현된다. Sui 공식 문서는 Sui가 object-centric global storage를 사용하고, transaction input을 고유 object ID로 명시해 병렬 실행 판단에 활용한다고 설명한다. 같은 Move 계열이어도 Sui는 object model을 전면에 두고, Aptos는 account 아래의 resource/module 모델과 Fungible Asset 표준을 중심으로 이해하는 편이 실무에 가깝다.
| 관점 | EVM/Solidity | Sui | Aptos |
|---|---|---|---|
| 상태 단위 | contract storage | object와 package | account 아래 resource/module |
| 자산 표현 | token contract의 balance mapping | coin/object와 capability | resource, object, Fungible Asset |
| 권한 표현 | msg.sender, role, signature | owner, shared object, treasury cap | signer, resource account, module authority |
| 병렬 실행 감각 | storage 접근 충돌을 실행 중 발견 | transaction input object로 충돌 예측 | account/resource 접근과 runtime 규칙 확인 |
| 업그레이드 검토 | proxy와 storage layout | package upgrade policy | module/account governance |
Move의 resource와 capability 감각
Move에서 resource는 복사와 삭제가 마음대로 되는 일반 데이터가 아니라, 소유와 이동 규칙이 중요한 값으로 다뤄진다. stablecoin 업무에서는 이 차이가 발행 권한과 회수 권한을 설계하는 방식으로 이어진다. EVM의 MINTER_ROLE을 찾는 대신, Sui에서는 treasury cap이나 package authority, Aptos에서는 module owner, resource account, FA metadata와 권한 구성을 확인해야 한다.
이 관점은 보안 리뷰에도 직접 연결된다. "누가 mint를 호출할 수 있는가"라는 질문은 "어떤 capability가 어디에 보관되어 있고, 어떤 transaction에서 사용되며, rotation과 revocation 절차가 있는가"로 바뀐다.
Sui와 Aptos를 나눠 읽는 기준
| 질문 | Sui에서 볼 것 | Aptos에서 볼 것 |
|---|---|---|
| stablecoin의 단위는 무엇인가 | coin object, shared/owned object, package | FA/Coin standard, resource, metadata |
| mint 권한은 어디 있는가 | treasury cap, package owner, governance object | module owner, resource account, capability 보관 위치 |
| freeze/denylist는 어떻게 구현되는가 | closed-loop token, deny list, permissioned asset pattern 지원 여부 | transfer/refreeze policy, FA hooks 또는 모듈 규칙 |
| 잔고와 event는 어디서 읽는가 | object transfer, coin balance indexer, RPC/GraphQL 지원 | account resource, indexer API, asset balance table |
| 사용자 지갑은 무엇을 보여주는가 | object 이동, sponsored transaction, multisig 표시 | FA metadata, account abstraction, sponsored transaction 표시 |
stablecoin checkout에 붙이면 달라지는 것
EVM에서 transferFrom(buyer, merchant, amount) 하나로 보던 기능을 Move 계열에 붙일 때는 다음 단위로 쪼개야 한다.
| 제품 질문 | 설계에 남길 답 |
|---|---|
| 결제 전 준비 | 사용자가 어떤 asset standard를 보유해야 하는가, 지갑이 그 자산을 표시하는가 |
| 결제 승인 | signature, capability, sponsored transaction 중 무엇이 사용자 행동인가 |
| 결제 실행 | object/resource 이동이 어떤 transaction input으로 표현되는가 |
| 실패 복구 | object ownership이 바뀌기 전/후 환불 경로가 다른가 |
| 정산 증거 | event, balance diff, object transfer 중 어떤 데이터를 회계 원장에 저장할 것인가 |
코드로 확인하기
Move 계열은 자산을 resource로 다루는 사고방식을 강제한다. EVM에서 mapping(address => balance)로 보던 모델을 resource 이동과 capability 권한으로 다시 읽어야 한다.
컨트랙트Move resource와 mint capability
module stablecoin::coin { struct MintCapability has key { treasury: address } public entry fun mint( cap: &MintCapability, recipient: address, amount: u64 ) { assert!(amount > 0, 1); coin::mint_to(recipient, amount, cap); }}Move에서는 capability를 가진 코드만 mint를 수행한다. 권한이 전역 modifier로 흩어지는 대신 resource 소유권으로 표현되는 점을 봐야 한다.
클라이언트object/resource 이동 전 검증
type MoveTransferIntent = { objectId: string; owner: string; recipient: string; amount: bigint; capabilityRequired: "mint" | "transfer" | "burn";};function validateMoveIntent(intent: MoveTransferIntent) { if (intent.owner === intent.recipient) return "self_transfer"; if (intent.amount <= 0n) return "zero_amount"; if (intent.capabilityRequired === "mint" && !intent.objectId) return "missing_capability"; return "ok";}비EVM 실습에서는 transaction hash보다 어떤 object와 capability가 움직였는지를 기록해야 한다.
강의 포인트
Sui와 Aptos를 비교할 때는 "Move라서 둘 다 비슷하다"로 끝내면 안 된다. Sui는 object input을 명시하는 모델이 제품 상태머신에 더 크게 영향을 주고, Aptos는 account/resource와 FA 표준의 지원 범위를 먼저 확인해야 한다. stablecoin 결제 제품에서는 asset standard, mint/freeze authority, indexer, wallet/custody 지원이 체인 선택의 핵심 근거가 된다.
강의 중에는 다음 순서로 사고한다.
- EVM의 contract storage 모델을 한 문장으로 정리한다.
- 같은 기능을 Sui object와 Aptos resource/account 모델로 다시 표현한다.
- 권한, event, indexer, custody 지원이 제품 체크리스트에서 어떻게 달라지는지 표시한다.
실무 예시
가상의 100 USDC checkout을 세 모델로 비교한다.
| 항목 | EVM | Sui | Aptos |
|---|---|---|---|
| 사용자가 보유한 것 | ERC-20 balance | coin object 또는 표준 asset | FA/Coin balance와 resource |
| 결제 권한 | allowance 또는 permit | object owner signature, sponsored transaction 가능성 | signer, sponsored transaction 가능성 |
| merchant 수령 확인 | Transfer event와 balance diff | object transfer/coin balance index | asset balance indexer와 transaction event |
| 환불 설계 | reverse transfer 또는 credit | object ownership과 coin split/merge 고려 | FA transfer와 account/resource 상태 확인 |
| 운영 리스크 | token contract별 구현 차이 | wallet/custody가 object와 asset standard를 지원해야 함 | FA/Coin 표준, indexer, SDK 버전 확인 필요 |
이 표는 캡스톤의 "체인별 결제 어댑터" 설계로 이어진다. 코드 포팅 전 단계에서 이 비교표가 없으면, 구현 후에 지갑 표시, settlement reconciliation, support ticket 처리에서 설계 누락이 드러난다.
흔한 오해와 실패 시나리오
| 오해 | 실패 장면 | 바로잡는 기준 |
|---|---|---|
| Move는 Solidity 문법만 바꾼 것이다. | ERC-20의 balance mapping 전제를 유지해 indexer와 환불 설계가 맞지 않는다. | 상태 단위, 자산 표현, 권한 보관 위치를 먼저 비교한다. |
| Sui와 Aptos는 둘 다 Move라서 같은 방식으로 붙이면 된다. | Sui object transfer와 Aptos FA balance를 같은 이벤트 모델로 수집해 정산 누락이 생긴다. | 체인별 asset standard와 indexer schema를 별도 계약으로 둔다. |
| 병렬 실행은 성능 이슈일 뿐 제품 설계와 무관하다. | shared object나 resource 접근 충돌 때문에 checkout retry가 증가한다. | transaction input, conflict 가능성, retry 정책을 adapter 설계에 포함한다. |
| issuer support만 있으면 바로 production 지원이 가능하다. | custody, compliance vendor, wallet display가 따라오지 않아 사용자가 결제 자산을 확인하지 못한다. | token standard와 product integration 지원을 같은 단계에서 검증한다. |
실습 과제
- Move, Sui, Aptos 비교 이해 점검: asset representation, permission, event, SDK 차이를 EVM/Sui/Aptos 비교표로 정리한다. 각 항목에 "확인 완료", "추가 리서치 필요", "지원 보류" 중 하나의 상태를 붙인다.
- Move, Sui, Aptos 비교 적용 과제: 동일한 stablecoin transfer 기능을 세 모델로 설계한다. 상태 단위, 권한, 이벤트/인덱싱, 환불 처리를 포함하고, 우리 checkout adapter에 필요한 인터페이스를 5개 이하의 메서드로 적는다.
완료 기준
- Move resource/capability가 EVM role model과 어떻게 다른지 설명했다.
- Sui object model과 Aptos account/resource model의 차이를 stablecoin 사례로 정리했다.
- 비EVM 도입 체크 항목에 asset standard, mint/freeze authority, indexer, wallet/custody 지원을 포함했다.
근거 자료
- 비EVM 학습맵: 07-비EVM/00-비EVM-학습맵.md
- Move Sui Aptos 비교: 07-비EVM/01-Move-Sui-Aptos-비교.md
- 비EVM 개발자 문서: 90-출처/원문-노트/비EVM-개발자-문서.md
- Sui Move Documentation: https://docs.sui.io/concepts/sui-move-concepts
- Aptos Move Book: https://aptos.dev/en/build/smart-contracts/book