2026-08-14 — rabbit 작업 이력
소스 문서: 없음 — jay가 대화에 직접 붙여넣은 "오늘의 로보틱스·AI 항목 2"(LeRobot + SO-101) 브리핑에서 나온 작업. 전날의 로보틱스 트랙 첫 항목은 2026-08-13 이력의 "PoCs에 로보틱스/AI 트랙 첫 항목(NVIDIA Isaac GR00T) 추가" 참고.
PoC 카드 추가: LeRobot + SO-101 로봇팔 (로보틱스 트랙 2번째 항목)
Cause: jay가 데일리 브리핑 형식으로 "Hugging Face LeRobot 라이브러리 + SO-101 6DOF 로봇팔($100~130)" 항목을 PoCs에 추가하고 main에 반영해 달라고 요청.
Reasoning: 전날 추가한 isaac-groot(피지컬 AI의 "지도")와 명백히 이어지지만 별도 카드로 만들었다 — GR00T 카드는 클라우드 GPU에서 파운데이션 모델을 돌리는 단계별 계획이고, 이번 건은 그 스택의 최소 스케일 재현(노트북 + $100 하드웨어에서 모방학습 루프 한 바퀴)이라 검증 대상이 다르다. 카드를 "라이브러리·하드웨어 소개"가 아니라 해봐야 답이 나오는 질문 둘로 잡았다: ① 데이터셋 포맷이 표준화된 뒤 "데이터셋 로드 → 학습된 정책" 사이가 코드 몇 줄인가, ② 로봇 에피소드(관측 이미지 + 관절 상태 + 행동)가 LLM 텍스트 토큰 데이터셋과 무엇이 같고 다른가. 브리핑의 액션 아이템(구매 판단 보류, 시뮬레이션 먼저)은 그대로 howTo의 "시뮬레이션 우선, 하드웨어 나중" 순서로 반영. 신규 항목이라 status:"soon", date·href 없음 — Planned 기본값 규칙.
Change: lib/poc-cards.ts에 lerobot-so101 카드 추가(sub-2bit-local-llm 뒤, 참조 전용 블록 앞). 출처 URL은 기존 관례대로 howItWorks/howTo 끝에 평문("Source:"/"출처:")으로 첨부(github.com/huggingface/lerobot · huggingface.co/docs/lerobot/so101). pnpm docs:pocs로 docs/pocs.html·docs/topics/pocs-*.html 재생성 — docs/topics/pocs-lerobot-so101.html 신규 생성, 카드 수 32→33.
Result: npx tsc --noEmit 통과(exit 0). 생성 HTML 태그 짝·로컬 링크 전수 확인(누락 0건). 목록에서 PLANNED 8번으로 노출. docs/index.html(상위 6개 카드 섹션)은 변경 없음.
PoC 카드 상태 변경: "Stake concentration risk" → done
Cause: jay가 stake-concentration 카드를 done으로 올려 달라고 요청. 배경은 대화에서 정리한 2026-08-12 솔라나 라우팅 장애 — Teraswitch(AS20326)의 BGP 오설정으로 밸리데이터 약 90개가 33분간 오프라인, 스테이킹 28.83%가 delinquent가 되어 최종성 정지선(33.34%)의 86%까지 도달한 건.
Reasoning: 카드가 원래 계획한 "측정 파이프라인"(RPC → 엔드포인트 → ASN 매핑 → 허핀달 지수)은 아직 구현하지 않았지만, 이 항목이 답하려던 개념적 질문은 종결됐다고 판단 — 독립성의 진짜 단위는 밸리데이터 수가 아니라 ASN이다. 즉 oz-relayer 카드와 같은 성격의 완결(상시 구동 데모가 아니라 완결된 검토)이라 같은 패턴을 따랐다: // done (jay, …) 주석 + status + date. 프로젝트 규칙(.claude/CLAUDE.md)대로 date를 함께 넣어야 done 카드 중 최신으로 정렬되므로 2026-08-14(KST 확인) 지정. howTo가 "아직 범위 미정"으로 남아 있으면 done 상태와 모순이라 완료형 한 줄로 교체.
Change: lib/poc-cards.ts의 stake-concentration 카드 — status: "soon" → "done", date: "2026-08-14" 추가, done 사유 주석 추가, howTo/howToKo를 "Not yet scoped …" → "Mapping the correlated failure surface under a validator set …"로 교체. pnpm docs:pocs로 재생성.
Result: npx tsc --noEmit 통과(exit 0). 카드가 PLANNED 6번 → DONE 1번으로 이동(정렬 규칙대로 date 기준 최신), 페이저 링크도 자동 재연결. 생성 HTML 로컬 링크 누락 0건. docs/index.html의 div 짝 불일치(28/27)는 HEAD에도 동일하게 존재하는 기존 이슈로, 이번 변경과 무관. 남은 것: howItWorks/purpose 본문이 여전히 "에세이가 아니라 측정으로 계획했습니다"로 시작해 done 상태와 어긋난다 — 문안은 jay 판단이 필요해 이번엔 손대지 않음.
Stake concentration 카드 위치 정정: 1번 → 4번 (date 필드 제거)
Cause: 위 작업 직후 jay가 "1번이 아니라 4번으로 해달라"고 요청. done 묶음의 헤드라인으로 올리지 않겠다는 판단.
Reasoning: 위치는 sortDemoCards()가 status → date 내림차순으로만 결정하므로, 배열 순서를 손으로 바꿔도 효과가 없다. 4번(done 4장 중 마지막)에 두려면 date가 dvt의 2026-08-05보다 오래돼야 하는데, 실제 작업일은 08-12~08-14이라 그보다 이른 날짜는 전부 지어낸 값이 된다. 대신 lib/demo-cards.ts:53-55의 규칙을 이용했다 — date가 있는 카드가 date 없는 카드보다 앞에 온다. 즉 date를 비우면 날짜를 조작하지 않고도 done 묶음의 끝으로 내려간다. 프로젝트 규칙의 "done으로 바꿀 때 date를 채워라"는 새 done 카드를 맨 위로 띄우기 위한 조항이므로, 맨 위에 두지 않겠다는 이번 요청에서는 date를 비우는 것이 규칙의 의도와 어긋나지 않는다고 판단. 그 판단 근거를 카드 주석에 남겨 다음 편집자가 "규칙 위반"으로 오해하지 않게 했다.
Change: lib/poc-cards.ts의 stake-concentration에서 date: "2026-08-14" 줄 삭제, 삭제 이유를 주석으로 명시. pnpm docs:pocs 재생성.
Result: npx tsc --noEmit 통과. 순서가 agent(1) · oz-relayer(2) · dvt(3) · stake-concentration(4) · dsrv-portal(5)로 확정. 페이저도 "← 3. DVT / 5. Institutional custody →"로 재연결. 로컬 링크 누락 0건. 부수 발견: 이번 재생성에서 pocs-oz-relayer.html·pocs-stake-concentration.html의 이전-글 링크만 ../topics/pocs-*.html 형태로 나왔다(다른 파일은 모두 같은 디렉터리 상대경로). 경로는 정상 해석되어 깨지지 않지만 생성 스크립트의 일관성 문제로 보이며, scripts/generate-pocs-html.mjs 수정이 필요해 이번 범위에서는 제외.
리서치 세션: 커스터디 키관리 → 브릿지 사고 → 신원·증명 → 기관 정산 인프라
Cause: 위 카드 작업들 이후, jay와의 긴 대화가 코드 변경 없이 개념 정리 위주로 진행됐다. 시작은 "커스터디 관련 키 보관 기술"이었고, 거기서 이번 주 실제 사고 두 건과 기관 인프라 흐름으로 번졌다. 이 항목은 코드 산출물이 아니라 이 저장소의 카드들과 이어지는 판단 근거를 남기기 위한 기록이다.
Reasoning: 흩어진 주제처럼 보이지만 하나의 축으로 꿰인다 — "이 시스템이 독립적이라고 가정하는 것은 무엇이고, 실제로 독립적인가." 그 축을 기준으로 정리했다.
- 키 보관 기술의 층위 구분. KMS·HSM·MPC/TSS·TEE는 저장 계층이고 온체인 멀티시그(Safe)는 정책 계층이라 서로 대체재가 아니라 조합 대상이다. MPC와 SSS의 차이는 "운영 중 키가 재조립되는가"이며, TEE+MPC 조합(예: Privy)의 의미는 교차 당사자 담합(MPC가 막음)과 자기 인프라 내부자(TEE가 막음)가 서로 다른 위협 모델이라는 데 있다. TEE 실제 코드는 특수 암호 라이브러리가 아니라 (a) 격리 프로세스 패키징 + (b) attestation을 KMS 접근 정책의 조건으로 거는 것이 전부다.
- Coreum XRPL 브릿지 사고(8/09, 199,916 XRP/97분). 릴레이어가 입금 검증에서
tx.Destination == bridgeAddr를 확인하지 않고 메모 필드만 신뢰했다. XRPL은 무관하며 공격자의 트랜잭션은 전부 유효했다 — 버그는 오프체인 해석에만 있었다. 멀티시그가 못 막은 이유가 핵심: N개 릴레이어가 같은 바이너리를 돌리므로 정족수는 하나의 판단을 N번 복사한 것에 불과했다(상관 실패). 감시(Monitor)는 이벤트를 잡지만 침묵은 못 잡으므로, 외부 상태를 능동 조회해 자기 장부와 맞추는 대조(reconciliation)가 별도로 필요하다. - 솔라나 라우팅 장애(8/12). Teraswitch(AS20326)의 BGP 오설정으로 밸리데이터 약 90개가 33분간 오프라인, 지분 28.83%가 delinquent. 확정은 정상적으로 이뤄졌고(2/3 = 66.67% 대비 71.17% 잔존, 4.5%p 여유) 사고가 난 것이 아니라 여유가 얼마 없다는 사실이 측정된 사건이다.
stake-concentration카드의 개념적 질문이 여기서 종결됐다 — 독립성의 단위는 밸리데이터 수가 아니라 ASN이다. Coreum과 정확히 같은 형태의 실패(암호학은 정상, 독립성 가정이 틀림). - 신원·증명 계층(Privado ID / iden3 / VC / DID). DID는 대부분의 메서드에서 공개키가 아니라 포인터이며, 프록시 컨트랙트나 EIP-7702의 위임 지정자와 같은 구조다(안정된 식별자 + 교체 가능한 대상). iden3 State 컨트랙트에는 상태 루트 해시만 올라가고 실제 크리덴셜은 홀더 지갑에만 있다 — 검증자는 데이터를 받지 않고 ZK 머클 증명과 온체인 루트를 대조할 뿐이다. 폐기(revocation)가 성립하는 이유는 SMT가 비포함 증명을 지원하기 때문.
allowedIssuers: ["*"]는 실제 취약점이며(누구나 자기 발행자를 세워 자기에게 발급 가능), 그 형태가 Coreum의 누락된 연언지와 논리적으로 동일하다. iden3의 창업 동기가 2017년 카탈루냐 주민투표 차단이라는 점도 설계 결정들(홀더 기기 보관·해시만 온체인·키 교체 가능)을 설명한다. - 기관 정산 인프라. 한국(코스콤·전자증권법)은 법을 바꿔 분산원장을 법적 원본으로 격상했고, 일본(Canton·MUFG JGB Repo)은 법은 두고 체인을 정산 계층으로 붙이는 중이다. Fabric의 채널은 채널마다 별도 블록체인이라 프라이버시를 얻는 대신 채널 간 원자성을 잃고, Canton은 파티션 없이 계약 단위로 당사자를 지정해 그 트레이드오프를 피한다. 이는
cre-cloud카드의 "사설 원장이 진실, 체인은 정산 장소"와 같은 구조이며, 코스콤이 예고한 스테이블코인 STO 결제 PoC가 유통시장 단계에서 이 한계에 부딪힐 지점이다. - 롤업 파편화. 공유 시퀀서는 원자적 포함까지만 보장하고 원자적 실행은 보장하지 않으며(Espresso·Astria 모두 실행 제공 계획 없음), Astria는 롤업 채택 부족으로 2025-12 종료했다. 실무에서 실제로 쓰이는 것은 인텐트·솔버이고, 그 구조는 카드사와 동형이다(자본으로 시차를 메우고 스프레드로 보상받되 실패 위험을 떠안음). 즉 "나누면 원자성을 잃는다"는 제약을 이더리움도 피하지 못했고, 해법은 프로토콜이 아니라 자본을 가진 중개자 쪽에서 나왔다.
Change: 저장소 코드 변경 없음. 이 세션에서 시도했던 문서 작업(isaac-groot·buzz 카드 추가, pocs-dvt.html·math-3.html 손글 노트, 생성기의 prune 예외, 커리큘럼 Day 3 링크)은 jay 요청으로 전부 원복했고, 로컬 브랜치 9개도 삭제해 main만 남겼다(git checkout . + git branch -D). 되돌린 것 중 scripts/rtd-shell.mjs의 진척도 색상 작업(미커밋 상태였음)도 함께 사라졌음을 기록해 둔다.
Result: 작업 트리 clean, 브랜치 main 단독. 코드 산출물은 없지만 카드 세 장(stake-concentration·dvt·cre-cloud)의 서술을 뒷받침하는 근거와, 다음에 물어야 할 질문이 정리됐다 — "이 설계가 독립적이라고 가정하는 것은 무엇인가." dvt 카드에는 원문의 미해결 질문 넷 외에 이번 사고실험에서 나온 네 가지(상관된 가용성 실패·무임승차와 상호보험의 동일성·집계자 그리핑·지리적 편향)를 추가할 여지가 있으나, 카드 문안 수정은 하지 않았다.