DeFi 캡스톤 아키텍처
도입
DeFi 강의를 많이 읽어도 마지막에 하나의 시스템으로 그리지 못하면 실무 학습이 끝나지 않는다. 캡스톤은 AMM 계산기, lending health factor, oracle adapter, liquidation bot, risk dashboard를 별도 과제로 남기지 않고 하나의 protocol 설계 문서로 묶는 작업이다.
이 강의는 구현을 시작하기 전 architecture map을 만든다. 어떤 component가 어떤 상태를 만들고, 어떤 event가 indexer로 들어가고, 어떤 계산이 backend에서 일어나며, 어떤 warning이 client에 표시되고, 어떤 alert가 operations로 가는지 보여줘야 한다.
학습 목표
- AMM, lending, oracle, liquidation, dashboard가 연결된 DeFi product architecture를 그린다.
- 계약, 백엔드, 인덱서, 클라이언트, 운영 계층의 책임을 나눈다.
- 최종 산출물에 들어갈 evidence package를 정의한다.
개념 설명
01
CONTRACT
- AMM pool
- lending pool
- liquidation entrypoint
02
ORACLE
- Chainlink adapter
- TWAP guard
- staleness policy
03
INDEXER
- reserve snapshots
- health factor snapshots
- liquidation events
04
BACKEND/CLIENT
- risk score
- user warning
- action gating
05
OPS
- dashboard
- alert
- pause matrix
- incident runbook
| Component | 책임 | evidence |
|---|---|---|
| AMM pool | swap과 reserve update | invariant and slippage tests |
| Lending pool | collateral, debt, HF | health factor snapshots |
| Oracle adapter | price validation | freshness and deviation logs |
| Liquidation bot | solvency protection | candidate queue and execution report |
| Risk dashboard | 운영 의사결정 | alerts and owner |
코드로 확인하기
export type EvidenceArtifact = { component: string; invariant: string; monitor: string; owner: "CONTRACT" | "BACKEND" | "INDEXER" | "CLIENT" | "OPS";};capstone_package: required: - architecture_map - invariant_test_report - oracle_adapter_spec - liquidation_simulation - risk_dashboard_mock - launch_gate코드와 YAML은 캡스톤이 문서만이 아니라 제출물 묶음이라는 점을 명확히 한다. 각 artifact는 나중에 관리자 리뷰 대상이 된다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| Boundary | 어디까지 contract가 책임지는가 | component map |
| Data | 어떤 event와 snapshot이 필요한가 | index schema |
| Risk | 어떤 threshold가 action을 바꾸는가 | dashboard rule |
| Review | 무엇을 제출하면 통과인가 | evidence checklist |
실무 예시
운영[BACKEND] 팀이 DeFi lending MVP를 만들었다. contract만 보고 출시하면 health factor UI, liquidation bot, oracle staleness alert가 빠질 수 있다. 캡스톤 architecture는 이런 빈틈을 미리 드러낸다.
최종 산출물은 "좋은 설명"이 아니라 reviewer가 확인할 수 있는 evidence package다. 코드, 계산, dashboard, runbook이 서로 같은 상태명을 써야 한다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 교정 방식 |
|---|---|---|
| capstone은 발표 자료다 | 실행 가능한 검증 산출물이 없다 | evidence package를 요구한다 |
| contract가 핵심이다 | oracle, indexer, ops가 빠진다 | 6계층 architecture를 쓴다 |
| dashboard는 나중에 만든다 | 위험을 운영에서 못 본다 | launch gate에 포함한다 |
| 상태명은 자유롭다 | support와 indexer가 다른 말을 쓴다 | shared state vocabulary를 둔다 |
실습 과제
- DeFi architecture map 작성하기: AMM, lending, oracle, liquidation bot, indexer, dashboard를 연결한 architecture map을 만든다.
- Evidence package 정의하기: 각 component에 필요한 source, test, alert, runbook 산출물을 정의한다.
완료 기준
- 최소 6개 component와 8개 edge를 가진 DeFi architecture map을 만들었다.
- 각 component에 실패 상태, owner, evidence artifact를 붙였다.
근거 자료
- 11 Protocol Development
- 09 Risk and Security