최종 Launch Review Packet
도입
캡스톤의 마지막 산출물은 멋진 설명서가 아니라 launch review packet이다. reviewer는 이 packet을 보고 출시 가능 여부를 판단해야 한다. architecture map, simulator result, dashboard mock, security checklist, source register, regulatory gate가 따로 흩어져 있으면 결정을 내리기 어렵다.
이 강의는 학습자가 만든 모든 결과물을 하나로 묶는다. 통과, 조건부 통과, 보류 중 어떤 결정을 내릴지 evidence로 설명하고, 부족한 항목은 remediation lesson으로 되돌린다.
학습 목표
- DeFi capstone 제출물을 reviewer가 확인 가능한 packet으로 묶는다.
- security, oracle, liquidity, compliance, user communication gate를 모두 통과 조건으로 만든다.
- 통과, 조건부 통과, 보류 결정을 evidence 기반으로 남긴다.
개념 설명
DeFi capstone을 출시 가능한 설계로 볼 수 있는가?
critical gates pass and monitoring is live
minor dashboard or documentation gap remains
oracle, liquidation, admin, compliance gate 중 하나가 비어 있다
| Gate | 통과 기준 | Remediation |
|---|---|---|
| Oracle | stale/deviation guard 있음 | liquidation-oracle-engine |
| Liquidation | simulator와 queue policy 있음 | oracle-liquidation-simulator-lab |
| AMM | slippage/minOut/invariant 있음 | amm-invariants |
| Dashboard | alert owner와 action 있음 | risk-dashboard-lab |
| Compliance | jurisdiction/user/asset gate 있음 | regulatory-design-gates |
코드로 확인하기
export function reviewDecision(gates: Record<string, "pass" | "conditional" | "fail">) { const failed = Object.entries(gates).filter(([, status]) => status === "fail").map(([gate]) => gate); const conditional = Object.entries(gates).filter(([, status]) => status === "conditional").map(([gate]) => gate); if (failed.length > 0) return { decision: "hold", failed, conditional }; if (conditional.length > 0) return { decision: "conditional", failed, conditional }; return { decision: "pass", failed, conditional };}launch_review_packet: sections: - architecture_map - oracle_liquidation_simulator - risk_dashboard - invariant_test_summary - source_register - regulatory_gate decision: allowed: [pass, conditional, hold]코드는 review가 감상이 아니라 gate 상태의 결과가 되게 한다. YAML은 제출물이 빠졌을 때 reviewer가 바로 찾을 수 있게 한다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| Packet | 모든 산출물이 한곳에 있는가 | section checklist |
| Decision | 왜 pass/hold인가 | gate status |
| Remediation | 어디로 되돌아가야 하는가 | lesson link |
| Operations | 출시 후 누가 보는가 | owner and alert |
실무 예시
운영[CONTRACT] launch review에서 oracle gate가 비어 있다면 "나중에 붙이자"가 아니라 hold다. AMM invariant가 있고 UI도 좋아도, oracle이 stale price를 허용하면 lending과 liquidation 전체가 위험하다.
반대로 minor wording이나 dashboard layout만 남았다면 conditional로 둘 수 있다. 중요한 것은 decision이 사람의 느낌이 아니라 evidence와 gate 상태로 설명되어야 한다는 점이다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 교정 방식 |
|---|---|---|
| capstone은 제출하면 끝이다 | reviewer가 판단할 증거가 없다 | packet 형식을 강제한다 |
| 조건부 통과는 대충 통과다 | remediation이 사라진다 | due date와 owner를 붙인다 |
| compliance는 launch 후 확인한다 | 제한 사용자에게 노출될 수 있다 | launch gate에 포함한다 |
| source register는 부록이다 | live claim이 낡는다 | 재검증 정책을 넣는다 |
실습 과제
- Launch review packet 작성하기: architecture, simulator, dashboard, security checklist, regulatory gate를 하나의 packet으로 묶는다.
- Review decision log 작성하기: pass, conditional, hold 중 하나를 선택하고 evidence와 remediation을 붙인다.
완료 기준
- launch packet에 architecture, simulator, dashboard, risk register, source register를 포함했다.
- 각 gate에 pass/conditional/hold 결정 기준과 remediation lesson을 연결했다.
근거 자료
- 10 Regulation
- 11 Protocol Development