지갑이 앱 속으로 사라졌다

목적: 이 흐름의 본질은 "지갑이 쉬워졌다"가 아닙니다. 지갑의 책임이 애플리케이션 안으로 옮겨 간 것입니다. 이 PoC 는 사용자에게 출구가 있는지, 그리고 앱이 UI 가 암시하는 것 이상으로 행동할 수 있는지를 측정합니다. 임베디드 지갑과 패스키는 온보딩에서 시드 문구를 없앱니다. 하지만 수탁과 인가의 문제를 없애지는 않습니다 — 그 문제들은 복구, 내보내기, 추가 서명자, 애플리케이션 스택으로 제어되는 정책 속으로 옮겨 갑니다.

동작 방식: 임베디드 지갑으로 로그인부터 첫 트랜잭션까지 플로우 하나를 만들고, 기기 분실, 키 내보내기, MFA 복구, 범위가 제한된 앱 서명자를 시험합니다. UX 를 평가하기 전에 권한표부터 그립니다. ### PoC 임베디드 지갑으로 로그인→첫 트랜잭션을 만듭니다. 그다음 네 경로를 시험합니다: 새 기기, 인증수단 분실, 키 내보내기, 범위가 제한된 앱 서명자. 클릭 수를 비교하기 전에 권한표를 만듭니다. | 행위자 | 서명 가능? | 복구 가능? | 내보내기 가능? | | --- | --- | --- | --- | | 사용자 | 설정된 인증 아래에서 | 명시적으로 시험할 것 | 탈출구가 실재하는지 확인할 것 | | 앱 서명자 | 정책 안에서만 — 아니면 그 정책은 장식 | 불가 | 불가 | | 제공자 | 수탁·키 구조에 따라 다름 | 정확한 역할을 문서화할 것 | 정확한 역할을 문서화할 것 | 참고: [Privy 임베디드 지갑 개요](https://docs.privy.io/wallets/overview/embedded). ## 노트 — PoC 를 위한 배경 (2026-09-02) ### 임베디드 지갑이란 MetaMask 같은 일반 지갑은 *외부형*입니다: 사용자가 따로 설치하는 앱/확장 프로그램이 시드 문구를 보관하고, 웹사이트가 거기에 연결합니다. **임베디드 지갑**은 애플리케이션 안에 삽입됩니다. 이메일·구글·패스키로 로그인하면 앱이 백그라운드에서 실제 온체인 지갑을 조용히 만들어 줍니다 — 확장 프로그램도, 시드 문구 의식도, 눈에 보이는 "지갑" 개념 자체도 없습니다. 지갑이 전제조건이 아니라 구현 세부사항이 되고, 그래서 지금 소비자용 크립토 앱의 기본 온보딩 패턴이 됐습니다. 기술적 핵심은 개인키 전체를 한 곳에 두지 않는 것: **MPC**(키가 한 조각으로 존재한 적 없이 여러 당사자가 공동 서명) 또는 **Shamir 키 분할**(조각으로 나눠 서명 순간에만 잠깐 재조합). 서명은 격리된 환경 — 클라이언트의 샌드박스 iframe 이나 서버의 TEE — 에서 일어납니다. ### Privy 는 구체적으로 - **Shamir 3조각 모델** — *기기 조각*(브라우저/앱 저장소), *인증 조각*(Privy 보관, 로그인 후 제공), *복구 조각*. 셋 중 둘만 있으면 격리된 iframe 안에서 키가 잠깐 재조합되고, Privy 서버는 전체 키를 본 적이 없습니다. - **복구** — 복구 조각을 Privy 가 보관(기본 "자동" 모드)하거나 사용자가 통제(비밀번호 암호화, iCloud/Google Drive)합니다. 이 선택이 *곧* 수탁 결정 — 인증수단 분실 경로의 답이 여기 있습니다. - **내보내기** — Privy 가 호스팅하는 절차로 전체 개인키를 내보낼 수 있고, 이 기능의 노출 여부는 앱이 설정합니다. - **서버 지갑과 세션 서명자** — TEE 기반 서버 지갑, 그리고 정책 엔진이 붙은 범위 제한 서명자("이 서명자는 이 컨트랙트만, 이 금액까지만"). 네 번째 경로가 이것입니다. - **맥락** — 2025년 6월 Stripe 가 Privy 를 인수했습니다(스테이블코인 회사 Bridge 인수와 짝): 임베디드 지갑이 주류 결제 인프라가 되고 있다는 신호. Farcaster, Hyperliquid 가 사용 중입니다. 경쟁사 — Dynamic, Web3Auth, Magic, Turnkey, Coinbase Embedded Wallets, thirdweb — 의 차이가 정확히 권한표의 차원들입니다: 누가 어떤 조각을 쥐고, 복구가 어떻게 되고, 정책을 누가 바꾸는가. ### 네 경로가 각각 측정하는 것 1. **새 기기** — 새 기기에는 기기 조각이 없으므로 로그인에 Privy 서버의 참여가 필수입니다. 불편한 질문: Privy 가 다운되거나 나를 차단하면 서명이 가능한가? 예상 답: 사전에 내보내기를 하지 않았다면 불가능. Privy 는 *가용성 거부권*을 쥡니다 — 자산을 뺏을 수는 없지만 접근을 막을 수는 있습니다. 2. **인증수단 분실** — 복구야말로 진짜 수탁자가 드러나는 지점: 복구를 승인할 수 있는 자가 사실상 지갑을 가져갈 수 있습니다. 복구가 "지원팀에 이메일" 수준이라면 수탁 스토리는 마케팅보다 약한 겁니다. 3. **키 내보내기** — 비상구이자 셀프 커스터디 주장의 가장 강력한 증거. 존재 여부만이 아니라 마찰의 정도, 앱 개발자가 비활성화할 수 있는지, 내보낸 키가 완전한지(일반 지갑에서 같은 주소가 복원되는지)까지 시험합니다. 4. **범위 제한 앱 서명자** — 위임의 경계: 앱이 사용자 없이 무엇을 할 수 있고, 그 범위를 누가 나중에 넓힐 수 있는가? 개발자가 조용히 바꿀 수 있는 정책과 사용자가 재승인해야 하는 정책은 전혀 다른 물건입니다. ### 클릭 수보다 권한표가 먼저인 이유 클릭 수는 온보딩 마찰을 재고, 권한표는 신뢰 모델을 잽니다. UX 부터 비교하면 "2클릭이면 지갑 생성"이 여러 당사자가 자금에 손댈 수 있다는 사실을 가립니다. 확장된 권한표 — 행은 행위, 열은 주체, 각 칸은 *단독 가능 / 협조 필요 / 불가* 를 문서가 아니라 관찰로 채웁니다. 검증할 예상값: | 행위 | 사용자 | Privy | 앱 개발자 | | --- | --- | --- | --- | | 트랜잭션 서명 | 로그인 후 단독 | 협조 — 인증 조각 제공 | 서명자 정책 안에서만 | | 키 내보내기 | 노출돼 있다면 단독 | 협조 — 절차 호스팅 | 노출 차단 가능 — 검증 | | 복구 승인 | 복구 모드에 따라 다름 | 복구 조각의 기본 보관자 | 복구 모드를 선택 | | 서명자 추가/범위 지정 | 설정에 따른 동의 — 검증 | 정책 실행 | 주도 | | 정책 변경 | 재승인 필요? — 검증 | 집행 | 단독인 경우 많음 — 검증 | | 접근 차단 (가용성) | — | 인증 조각 거부권 | UI 제거 가능 | 가장 흥미로운 칸은 보통 "복구 승인"과 "정책 변경" — 권한이 앱 스택 쪽으로 조용히 집중되는 지점입니다. 시험할 예측: 앱 개발자는 사용자 생각보다 많은 권한을 쥐고, Privy 는 가용성 거부권을 쥔다. 둘 다 클릭 수 비교에는 나타나지 않습니다. ### 개발자가 곧 감사인이다 최종 사용자는 이 어떤 것도 보지 못합니다 — 그게 임베디드 지갑의 존재 이유이자 위험입니다. 도입자가 설정한 그대로가 사용자들이 조용히 물려받는 수탁 현실이 됩니다. 그리고 답들은 고정된 성질이 아니라 설정 선택입니다: "Privy 는 논커스터디얼"은 마케팅 문장이고, 같은 Privy SDK 로 만든 두 앱이 진짜로 다른 수탁 모델을 가질 수 있습니다. 문서는 설계를 설명할 뿐이므로 네 경로를 직접 실행합니다 — 미처 못 본 기본값, 실패하는 플로우, 지원팀 뒷문은 배포된 동작에서만 드러납니다. 권한표를 먼저 만드는 이유도 같습니다: UX 판단에 앞서 "누가 무엇을 할 수 있는가"를 관찰된 사실로 종이에 강제하는 산출물이기 때문입니다.