기술레이더 운영법
도입
기술레이더는 "요즘 뜨는 것"을 모아두는 뉴스 목록이 아니다. stablecoin 개발자가 학습 시간과 제품 리스크를 관리하기 위한 판단판이다. 새로운 표준, wallet 기능, bridge, privacy 기술, hook, AVS가 나올 때마다 바로 채택하면 제품은 복잡해지고, 전부 무시하면 중요한 전환을 놓친다.
레이더의 역할은 선택을 언어화하는 것이다. 지금 써야 하는지, 작은 PoC가 필요한지, 관찰만 할지, 명확히 보류할지를 정하고 그 이유와 다음 검토일을 남긴다.
학습 목표
- 기술 변화 추적을 학습 backlog로 관리한다.
- adopt, trial, assess, hold 같은 판단 언어를 정한다.
개념 설명
기술 변화 추적을 학습 backlog로 관리한다.
공식 문서, PoC 결과, 실패 비용이 ring 변경 조건으로 연결되는가
기술레이더 운영법 이해 점검
레이더 stage 기준을 만들었다.
네 가지 stage
원본 문서의 분류를 LMS에서는 다음 운영 언어로 사용한다.
| Stage | 의미 | LMS/제품 행동 |
|---|---|---|
| 지금 쓸 것 | 업무에 바로 연결되고 tooling/source가 성숙하다. | 체크리스트, 실습, 코드 패턴에 편입한다. |
| PoC할 것 | 유망하지만 운영 리스크가 남아 있다. | 작은 spike나 lab을 만들고 실패 상태를 관찰한다. |
| 관찰할 것 | 방향은 중요하지만 채택 전이다. | 월 1회 공식 문서, adoption, breaking change를 확인한다. |
| 보류할 것 | 리스크/불확실성이 크거나 과장되어 있다. | 보류 이유와 재검토 조건을 기록한다. |
레이더 항목의 최소 형식
기술 항목은 이름만 적으면 학습 자료가 되지 않는다. 매 항목은 다음 필드를 가져야 한다.
| 필드 | 작성 기준 |
|---|---|
| Problem | stablecoin 결제, 발행, 정산, 보안 중 어떤 문제와 연결되는가 |
| Evidence | 공식 문서, 표준, whitepaper, production 사례 중 무엇을 확인했는가 |
| Change Surface | Solidity code, backend state machine, wallet UX, ops runbook 중 무엇이 바뀌는가 |
| Failure Cost | 사용자의 돈, merchant 정산, compliance, monitoring 중 무엇이 깨질 수 있는가 |
| Next Action | adopt, PoC, observe, hold에 맞는 다음 행동은 무엇인가 |
| Review Date | 언제 다시 볼 것인가 |
레이더 운영은 월 1회 회의가 아니라 작은 편집 루틴이다. 새 항목이 들어오면 바로 결론을 내리지 않고, 근거의 강도를 먼저 표시한다.
| Evidence level | 허용되는 근거 | 사용할 수 있는 결정 |
|---|---|---|
| L1 | EIP/ERC, 공식 문서, audit report, production docs | 지금 쓸 것 또는 PoC |
| L2 | 프로젝트 whitepaper, developer preview, testnet docs | PoC 또는 관찰 |
| L3 | 산업 리포트, 발표 자료, 블로그, 소셜 논의 | 관찰 |
| L4 | 출처가 불명확한 주장, vendor pitch만 존재 | 보류 |
같은 항목도 evidence level이 바뀌면 stage가 바뀔 수 있다. 예를 들어 "agent payment"는 산업 리포트만 보면 trend지만, x402처럼 request/response flow와 settlement requirement를 직접 실습할 수 있으면 PoC 항목이 된다.
코드로 확인하기
technology radar는 회의 메모가 아니라 의사결정 데이터다. 각 항목은 quadrant, ring, evidence, next action을 갖고 있어야 다음 달에 상태 변화를 추적할 수 있다.
운영radar item schema
{ "id": "cctp-v2", "name": "CCTP v2", "quadrant": "cross-chain", "ring": "trial", "confidence": "medium", "evidence": [ "official-doc-reviewed", "testnet-lab-completed" ], "nextAction": "run-settlement-latency-test"}ring은 관심도를 뜻하지 않는다. adopt, trial, assess, hold는 제품에 넣을 수 있는 준비도를 구분한다.
백엔드radar ring 변경 감지
type RadarItem = { id: string; ring: "adopt" | "trial" | "assess" | "hold"; confidence: "low" | "medium" | "high";};function detectRingChange(previous: RadarItem, current: RadarItem) { if (previous.ring === current.ring) return null; return { id: current.id, from: previous.ring, to: current.ring, requiresReview: current.confidence !== "high" };}radar 운영에서는 추가보다 변경이 중요하다. 항목이 trial에서 adopt로 올라갈 때 어떤 evidence가 늘었는지 남겨야 한다.
클라이언트레이더 필터를 학습 다음 행동으로 연결
type RadarFilter = { ring?: "adopt" | "trial" | "assess" | "hold"; quadrant?: "stablecoin" | "security" | "cross-chain" | "infra"; hasLab?: boolean;};function nextRadarAction(filter: RadarFilter) { if (filter.ring === "adopt" && filter.hasLab) return "connect_to_capstone"; if (filter.ring === "trial") return "run_small_lab"; if (filter.ring === "assess") return "collect_primary_sources"; return "write_hold_condition";}레이더 UI는 예쁜 목록이 아니라 학습 backlog다. 사용자가 trial 항목을 누르면 바로 PoC나 lab으로 이어져야 하고, hold 항목은 왜 보류인지 보여야 한다.
인덱서evidence coverage 리포트
select ring, count(*) as items, avg(evidence_count) as avg_evidencefrom radar_itemsgroup by ringorder by ring;월간 레이더가 감으로 흐르지 않으려면 ring별 evidence 수를 본다. adopt인데 evidence가 적은 항목은 결정 품질 문제가 있고, hold인데 unblock condition이 없으면 학습 backlog로 작동하지 않는다.
강의 포인트
기술레이더는 학습 순서를 통제하는 장치다. 예를 들어 ERC-3009는 checkout과 x402에 바로 연결되므로 지금 쓸 것에 가깝다. 반면 restaking yield를 reserve asset으로 넣는 아이디어는 매력적으로 보여도 slashing, liquidity, accounting risk가 커서 보류할 것에 둘 수 있다.
중요한 것은 stage가 평가가 아니라 작업 상태라는 점이다. 보류는 기술이 나쁘다는 뜻이 아니라 지금 제품의 실패 비용을 감당할 수 없다는 뜻이다. PoC는 도입 결정이 아니라 작은 실패를 안전하게 관찰하겠다는 뜻이다.
운영자는 레이더 항목을 다음 회의 전까지 방치하지 않는다. 항목별로 다음 행동이 없으면 stage가 있어도 학습 backlog로 작동하지 않는다.
| Stage | 다음 행동 예시 | 완료 증거 |
|---|---|---|
| 지금 쓸 것 | 체크리스트에 편입하고 관련 lab을 연결 | 레슨 링크, 테스트, runbook |
| PoC할 것 | 1-2일짜리 spike를 만들고 실패 상태를 기록 | PoC note, decision log |
| 관찰할 것 | 다음 review date와 확인할 공식 문서를 지정 | watched source, accessedAt |
| 보류할 것 | 보류 이유와 재검토 조건을 적는다 | hold memo, unblock condition |
실무 예시
새 항목 Uniswap v4 hooks를 레이더에 올린다고 가정한다.
| 필드 | 예시 |
|---|---|
| Problem | stablecoin swap route가 hook logic에 따라 revert, fee, accounting이 달라질 수 있다. |
| Evidence | Uniswap v4 hooks 공식 문서, OpenZeppelin hooks library 문서 |
| Change Surface | route selection, slippage policy, pool allowlist, simulation |
| Failure Cost | checkout failure, wrong settlement amount, unreviewed hook route |
| Stage | PoC |
| Next Action | hook pool route를 포함/제외한 swap simulation을 비교한다. |
| Review Date | 다음 월간 레이더 업데이트 |
이 형식으로 적으면 "흥미롭다"가 아니라 "어떤 실습을 만들 것인가"로 바로 이어진다.
레이더 항목 하나가 실제 강의로 들어오는 경로는 다음과 같다.
흔한 오해와 실패 시나리오
| 오해 | 실패 장면 | 바로잡는 기준 |
|---|---|---|
| 많이 언급되는 기술은 곧 채택해야 한다. | product state machine과 wallet support가 준비되지 않았는데 production에 넣는다. | evidence와 failure cost를 stage 결정에 포함한다. |
공식 문서가 있으면 바로 지금 쓸 것이다. | 표준은 있지만 wallet/library adoption이 부족해 UX가 깨진다. | tooling, 사례, 운영 실패 테스트까지 본다. |
| 보류 항목은 다시 볼 필요가 없다. | ecosystem이 성숙했는데 학습 backlog에 반영되지 않는다. | 보류 사유와 review date를 반드시 남긴다. |
| 레이더는 연구 문서다. | 학습과 실습으로 연결되지 않아 실제 역량이 늘지 않는다. | 각 항목에 다음 행동과 연결 레슨을 둔다. |
실습 과제
- 기술레이더 운영법 이해 점검: stage 정의표를 만들고, 각 stage에 맞는 evidence, next action, review date 규칙을 적는다.
- 기술레이더 운영법 적용 과제: 새 기술 항목 하나를 골라 Problem, Evidence, Change Surface, Failure Cost, Stage, Next Action, Review Date를 작성한다.
완료 기준
- 레이더 stage 기준을 제품/학습 행동과 연결해 만들었다.
- 출처와 검토일을 남겼다.
- 다음 행동을 lab, checklist, observe, hold 중 하나로 정의했다.
근거 자료
- 기술레이더 홈: 09-기술레이더/00-기술레이더-홈.md