전체 학습지도: 결제 시스템에서 리스크 대시보드까지
도입
전체 학습지도는 64개 레슨을 한 번에 다 읽으라는 목록이 아니다. 이 강의의 역할은 학습자가 "지금 어디에 서 있고, 다음에 무엇을 배워야 하며, 최종 캡스톤에 어떤 부품을 모아야 하는가"를 판단하게 만드는 것이다.
이 커리큘럼은 Solidity 개발자와 스테이블코인 실무자를 기준으로 설계되어 있다. 중심축은 stablecoin checkout 시스템이다. 여기에 발행/상환, 서명 결제, 보안 테스트, CCTP와 L2, RWA, 계정추상화, 프라이버시, 비EVM, MEV와 리스테이킹을 필요한 순서로 붙인다.
처음부터 모든 트랙을 같은 깊이로 파고들 필요는 없다. checkout 기능을 만들 사람, 보안 리뷰를 맡은 사람, 운영 대시보드를 설계하는 사람, 새로운 체인이나 표준을 평가하는 사람의 우선순위는 다르다. 다만 어떤 경로를 고르더라도 캡스톤에서는 결제 흐름, 검증, 정산, 리스크 판단을 하나의 설계로 연결해야 한다.
학습 목표
- 트랙 간 의존 관계를 설명한다.
- 캡스톤 산출물의 구성 요소를 식별한다.
- 자신의 업무 관심사에 맞는 우선 트랙과 보류 트랙을 나눈다.
개념 설명
결제 시스템 기초
발행, 상환, 서명 결제, 상태머신을 먼저 연결한다.
보안과 테스트
권한, nonce, freeze, invariant를 테스트 질문으로 바꾼다.
체인과 제품 확장
CCTP, L2, RWA, 계정추상화, 프라이버시를 요구사항별로 붙인다.
설계로 통합
checkout 설계, 테스트, 정산, 위험 대시보드를 하나로 묶는다.
1. 커리큘럼은 결제 시스템을 중심으로 읽는다
스테이블코인은 토큰 컨트랙트만으로 끝나지 않는다. 실제 제품에서는 사용자 checkout, 서명, 결제 상태, 정산 DB, 크로스체인 이동, 운영 모니터링이 함께 움직인다. 따라서 이 학습지도는 단순 주제 모음이 아니라 결제 시스템을 만들기 위한 의존 관계로 읽어야 한다.
위 그림에서 Stablecoin Systems는 시작점이다. Security Testing은 그 위에 검증 관점을 얹는다. Cross-chain/L2는 결제가 한 체인에 머물지 않을 때의 위험을 다룬다. Labs/Capstone은 앞의 지식을 실제 설계 문서와 실습 결과로 묶는 단계다. RWA, 계정추상화, 프라이버시, 비EVM, 인프라는 제품 요구가 생겼을 때 확장하는 트랙이다.
2. 트랙별 완료 기준을 다르게 둔다
각 트랙은 읽는 목적이 다르다. 어떤 트랙은 코드로 확인해야 하고, 어떤 트랙은 비교표나 운영 체크리스트로 끝내도 된다. 아래 표는 원본 학습지도의 "큰 흐름"을 LMS 관점의 완료 기준으로 바꾼 것이다.
| 순서 | 트랙 | 먼저 얻어야 할 능력 | 완료 산출물 |
|---|---|---|---|
| 1 | Stablecoin Systems | 발행, 준비자산, 상환, 권한, 결제 상태를 하나의 시스템으로 설명 | checkout 상태 흐름 또는 시스템 구성도 |
| 2 | Security Testing | role, freeze, nonce, supply invariant를 테스트로 바꿈 | fuzz/invariant 테스트 목록 |
| 3 | Cross-chain/L2 | CCTP, bridge, L2 finality, DA 리스크를 비교 | cross-chain 결제 리스크 표 |
| 4 | RWA Tokenization | ERC-4626 share와 stablecoin balance의 차이를 설명 | NAV/redemption 체크리스트 |
| 5 | Account/Agent Payment | Paymaster, session key, x402 결제 흐름을 구분 | agent payment 권한 경계표 |
| 6 | Privacy/Non-EVM | ZK/FHE와 Move/Solana 상태 모델을 EVM과 비교 | privacy 또는 non-EVM 적용 판단표 |
| 7 | Infra/Radar | MEV/PBS, private orderflow, restaking/AVS의 운영 리스크를 설명 | 기술레이더 분류와 보류 사유 |
| 8 | Labs/Capstone | 앞 트랙의 판단을 하나의 설계로 묶음 | stablecoin checkout 캡스톤 문서 |
3. 우선순위는 네 개의 핵심 레슨에서 시작한다
원본 학습지도는 지금 당장 중요한 출발점으로 네 가지를 제시한다. LMS에서는 이를 다음과 같은 이유로 우선 배치한다.
| 우선 레슨 | 먼저 보는 이유 | 이어지는 레슨 |
|---|---|---|
| Stablecoin Systems: system map | 토큰, 발행자, 사용자, treasury, indexer의 관계를 잡는다 | issuance/redemption, payment state machine |
| Stablecoin Systems: signed payments | permit과 ERC-3009를 checkout UX 관점에서 구분한다 | permit checkout lab, ERC-3009 escrow lab |
| Security Testing: Foundry fuzz/invariant | 성공 케이스보다 깨지면 안 되는 조건을 먼저 세운다 | Slither/Echidna workflow, security review checklist |
| Labs: mock stablecoin lab | 개념을 코드와 테스트로 전환한다 | invariant testing lab, capstone |
이 네 개를 거치면 이후 CCTP, L2, RWA, x402, MEV/PBS, restaking/AVS가 왜 필요한지 판단하기 쉬워진다. 반대로 이 기초 없이 새 기술부터 보면 프로토콜 이름은 익숙해져도 결제 시스템 안에서 어디에 붙는지 설명하기 어렵다.
4. 시각자료는 복습용이 아니라 구조 확인용이다
시각자료 색인은 텍스트를 줄이기 위한 부록이 아니다. 결제 시스템은 actor, 상태, 이벤트, 권한, 외부 의존성이 얽히므로 그림으로 먼저 구조를 확인하면 이후 코드와 체크리스트가 빨리 이해된다.
| 범주 | 볼 그림 | 강의 중 확인할 질문 |
|---|---|---|
| 시스템 구조 | stablecoin product, payment state machine, reconciliation, risk dashboard | token contract 밖에 어떤 운영 레이어가 있는가? |
| 보안과 운영 | proxy upgrade, incident response | 누가 code를 바꿀 수 있고, 사고가 나면 무엇을 먼저 멈추는가? |
| 크로스체인과 계정 | cross-chain intent, CCIP/CCT, ERC-7579 account module | origin settlement와 destination execution을 어떻게 분리하는가? |
| 인프라와 레이더 | MEV/PBS, private orderflow, restaking/AVS, monthly radar | 새 기술을 지금 쓸지, PoC할지, 관찰할지, 보류할지 어떻게 정하는가? |
좋은 학습 순서는 그림을 보고 끝내는 것이 아니라, 그림에 빠진 실패 상태를 찾아내는 것이다. 예를 들어 payment state machine을 볼 때는 paid, delivered, settled가 왜 분리되는지 묻는다. reconciliation 그림을 볼 때는 onchain event와 내부 DB가 다를 때 어느 레이어에서 탐지하는지 확인한다.
강의 포인트
Adopt
Trial
Assess
Hold
| 관점 | 강의 중 확인할 질문 | 학습 후 남길 증거 |
|---|---|---|
| 의존 관계 | 어떤 트랙이 다른 트랙의 선행 조건인가? | Stablecoin, Security, Cross-chain, Labs의 연결을 말로 설명한다 |
| 캡스톤 | 최종 checkout 설계에 어떤 컴포넌트가 필요한가? | token, signature, state machine, test, indexer, dashboard를 포함한 목록을 만든다 |
| 우선순위 | 지금 내 업무에 당장 필요한 트랙은 무엇인가? | 우선 트랙 3개와 보류 트랙 2개를 표시한다 |
| 보류 기준 | 왜 어떤 주제는 지금 보류해도 되는가? | 보류 사유와 되돌아올 조건을 한 줄로 남긴다 |
실무 예시
checkout 제품을 만드는 팀을 예로 들어보자. 제품팀은 "사용자가 서명 한 번으로 결제하고, 운영자는 리스크가 높으면 route를 끌 수 있어야 한다"고 요구한다. 이 요구를 커리큘럼으로 바꾸면 다음 순서가 된다.
| 요구 | 필요한 트랙 | 남길 산출물 |
|---|---|---|
| 서명 한 번으로 결제 | Stablecoin Systems, Account/Agent Payment | permit과 ERC-3009 비교표, session key 제한 조건 |
| 결제 상태 추적 | Stablecoin Systems, Labs | payment state machine과 reconciliation 설계 |
| 잘못된 서명과 nonce 방지 | Security Testing | EIP-712/nonce 테스트 케이스 |
| 다른 체인에서 결제 | Cross-chain/L2 | CCTP와 bridge의 실패 상태 비교 |
| 운영자가 route 제한 | Infra/Radar, Security Testing | risk dashboard signal과 pause/freeze runbook |
이 예시에서 RWA나 프라이버시가 중요하지 않다는 뜻은 아니다. 다만 첫 checkout MVP에서는 핵심 결제 경로와 검증이 먼저다. RWA treasury나 selective disclosure가 요구사항에 들어오는 순간 해당 트랙을 다시 끌어오면 된다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 바로잡는 방법 |
|---|---|---|
| 전체 지도를 모든 주제의 요약본으로 읽는다 | 레슨을 많이 봤지만 checkout 설계에 무엇을 붙여야 할지 모른다 | 각 트랙을 캡스톤 컴포넌트와 연결한다 |
| 새 기술 트랙을 먼저 보면 더 앞서간다고 생각한다 | CCTP, intents, restaking이 제품 흐름과 분리된 키워드로 남는다 | Stablecoin Systems와 Security Testing을 먼저 기준점으로 둔다 |
| 시각자료는 시간이 남을 때 보는 부록이라고 생각한다 | 상태 전이와 운영 레이어를 텍스트로만 이해해 실패 상태를 놓친다 | 상태머신, reconciliation, dashboard 그림을 먼저 보고 질문을 만든다 |
| 보류 트랙은 안 배워도 되는 트랙이라고 생각한다 | 요구사항이 바뀌었을 때 다시 들어올 기준이 없다 | 보류 사유와 재진입 조건을 함께 기록한다 |
실습 과제
- 트랙 의존 관계 설명하기: Stablecoin Systems, Security Testing, Cross-chain/L2, Labs/Capstone이 어떤 순서로 연결되는지 5분 안에 설명한다.
- 개인 학습 경로 설계하기: checkout, 보안 리뷰, 운영 대시보드, 신기술 평가 중 하나를 목표로 잡고 우선 트랙 3개와 보류 트랙 2개를 표시한다.
- 캡스톤 컴포넌트 적기: 최종 stablecoin checkout 캡스톤에 들어갈 컴포넌트 6개 이상을 적고, 각 컴포넌트가 어느 트랙에서 나오는지 연결한다.
완료 기준
- 전체 코스 구조를 5분 안에 설명할 수 있다.
- 캡스톤에 들어갈 최소 6개 컴포넌트를 적었다.
- 각 트랙의 선행 조건을 확인했다.
- 자신의 우선 트랙과 보류 트랙을 구분했고, 보류 트랙으로 돌아올 조건을 정했다.
근거 자료
이 강의는 전체 트랙 구조와 시각 자료 목록을 참고해, 학습자가 코스 의존 관계와 캡스톤 연결 방식을 빠르게 파악하도록 재구성했다. 세부 파일 위치보다 중요한 것은 각 트랙이 최종 checkout 설계의 어느 부품으로 이어지는지 설명하는 것이다.