앞에서 살펴본 것처럼 스마트 월렛에는 결제카드뿐 아니라 신분증, 자동차 키, 출입증, 티켓과 같은 다양한 정보가 들어오기 시작했다.

그렇다면 이런 정보들은 단순히 스마트폰 안에 파일처럼 저장되는 것일까?

그렇지 않다.

스마트 월렛을 이해할 때 가장 중요한 것은 Wallet을 데이터 저장 앱으로 보지 않는 것이다.

스마트 월렛의 핵심은 데이터를 많이 보관하는 것이 아니라,

누가 정보를 발급했고
누구의 정보이며
어떤 기기에 연결되어 있고
사용자가 실제 소유자인지 확인하고
필요한 순간에 누구에게 어떤 정보를 제시하며
상대방이 그것을 어떻게 검증하는가

라는 신뢰 구조(Trust Architecture)를 관리하는 데 있다.

1. 월렛은 데이터를 모아놓은 앱이 아니다

개념적으로 스마트 월렛은 다음과 같은 여러 계층이 결합되어 작동한다.

단, 여기에서 주의할 점이 있다.

모든 Wallet이 동일한 보안 구조를 사용하는 것은 아니다.

Apple, Google, Samsung은 각자의 하드웨어와 운영체제 구조에 따라 Secure Element, Secure Enclave, TEE, 하드웨어 기반 키 저장소, Knox Vault 등의 기술을 서로 다르게 사용한다.

예를 들어 Apple Pay에서는 결제용 Device Account Number가 Secure Element에 저장되며 iOS나 Apple 서버와 분리된다. Android의 Hardware-backed Keystore는 암호키를 기기에서 추출하기 어렵도록 설계되고, 키 사용 자체에 사용자 인증 조건을 걸 수도 있다. Samsung의 Knox Vault 역시 비밀번호, 생체정보, 암호키와 같은 민감 정보를 보호하기 위한 별도의 하드웨어 기반 보안 환경을 제공한다.

따라서 Wallet을 다음처럼 이해하는 것이 더 정확하다.

Wallet
≠
개인정보를 저장한 폴더

Wallet
=
Credential을 안전하게 보관하고
사용자를 인증하고
필요한 Credential을 제시하고
외부 기관과 신뢰를 연결하는 시스템

2. 핵심은 Credential이다

스마트 월렛을 이해하는 가장 중요한 단어가 Credential이다.

Credential은 단순한 개인정보와 다르다.

예를 들어 사용자의 이름이 홍길동
이라고 저장되어 있다고 해서 그것만으로 신원증명이 되는 것은 아니다.

누구든 문자열로 이름을 만들 수 있기 때문이다.

Credential에서는 중요한 것이 누가 그 사실을 확인했는가다.

예를 들어 정부가 발급한 디지털 운전면허증이라면 다음과 같은 의미를 갖는다.

Government
     │
     │ "이 사람은 홍길동이고
     │  이 운전 자격을 가지고 있다"
     ▼
Digital Credential

즉 Credential은 특정 기관이 어떤 사람이나 대상에 관한 사실을 주장하고, 이를 검증할 수 있도록 만든 디지털 증명정보다.

W3C의 Verifiable Credentials 모델에서도 Credential은 Issuer가 특정 주체에 대해 만든 하나 이상의 Claim을 포함하며, Verifiable Credential에는 누가 발급했는지와 데이터가 변경되지 않았음을 암호학적으로 검증하기 위한 메커니즘이 추가된다.

따라서 Credential에는 단순히 데이터만 있는 것이 아니다.

개념적으로 다음과 같은 요소가 함께 존재한다.

이 때문에 스마트 월렛에서 중요한 질문은
어떤 정보를 저장했는가?
보다
누가 그 정보를 증명했는가?
에 가깝다.

3. Credential은 어떻게 Wallet에 들어오는가

Credential이 Wallet에 들어오는 과정도 단순한 파일 다운로드와는 다르다.

일반적인 흐름은 다음과 같이 생각할 수 있다.

Issuer 확인 → 사용자 확인 → Credential 생성 → 사용자 또는 기기와 연결 →  Wallet에 Provisioning → 안전하게 저장

예를 들어 정부가 디지털 신분증을 발급한다고 가정해보자.

먼저 정부 또는 정부가 승인한 시스템이 사용자 신원을 확인한다.

USER → Identity Proofing → GOVERNMENT

신원이 확인되면 해당 사용자를 위한 Credential이 발급된다.

GOVERNMENT → Credential Issuance → DIGITAL WALLET

Google의 Digital Credentials Provisioning 구조에서도 Identity Provider가 사용자의 신원을 확인한 후 Android 기기의 Google Wallet에 Digital Credential을 제공하고 관리할 수 있도록 되어 있다.

Android의 보다 일반적인 Digital Credential 구조에서는 Credential Manager를 통해 발급자가 사용자가 선택한 Holder, 즉 Wallet 앱으로 Credential을 발급할 수 있는 구조도 제공한다. 따라서 Android에서 Digital Credential이 반드시 하나의 Wallet에만 종속되는 구조라고 보기는 어렵다.

여기서 중요한 개념이 Provisioning이다.

Provisioning은 단순히 데이터를 복사하는 것이 아니라,

Issuer가 발급한 Credential → 사용자 / Device와 연결 → Wallet에서 사용할 수 있는 상태로 등록

하는 과정이라고 이해하면 쉽다.

4. 생체인증은 Credential 자체가 아니다

스마트폰 Wallet을 사용할 때 Face ID, 지문, PIN 등을 사용하기 때문에 생체정보가 Credential이라고 생각하기 쉽다.

하지만 둘은 역할이 다르다.

Credential = 내가 무엇을 가지고 있는지 증명
Authentication = 지금 이것을 사용하는 사람이 정당한 사용자인지 확인

예를 들어 Wallet에 운전면허 Credential이 있다고 하자.

운전면허 Credential → "이 사용자는 운전면허를 가지고 있다"

하지만 스마트폰을 들고 있는 사람이 실제 소유자인지는 별도의 문제다.

그래서 Wallet은 Credential을 사용하기 전에
Face ID, Fingerprint, PIN, Passcode
등의 방법으로 사용자를 인증할 수 있다.

결제에서도 같은 원리가 적용된다.

Apple Pay는 결제 승인 과정에서 Secure Enclave와 Secure Element를 활용하며, 사용자의 인증과 실제 결제 Credential 처리를 분리한다.

Android Keystore 역시 암호키 자체를 애플리케이션으로 꺼내 사용하는 방식이 아니라, 키를 하드웨어에 유지한 채 암호 연산을 수행하고 특정 키를 사용할 때 사용자 인증을 요구하도록 제한할 수 있다.

따라서 생체인증의 역할을 매우 단순하게 표현하면 다음과 같다.

Credential → Secure Key → User Authentication → Permission to Use Credential

즉,

생체인증은 신분증 자체가 아니라, 신분증이나 결제 Credential을 사용할 권한을 확인하는 수단에 가깝다.

5. 결제에서는 Payment Tokenization이 사용된다

Payment Credential은 Digital ID Credential과 조금 다른 방식으로 작동한다.

스마트폰에 신용카드를 등록했다고 해서 실제 카드번호가 매번 가맹점에 그대로 전달되는 것은 아니다.

여기서 등장하는 것이 Payment Tokenization이다.

EMVCo는 Payment Tokenization을 카드의 Primary Account Number(PAN)를 다른 고유한 값으로 대체하는 기술로 정의한다. 또한 Payment Token은 어디에서 또는 어떤 조건에서 사용할 수 있는지 제한될 수 있다.

기본 구조는 다음과 같다.

Actual Card Number
       PAN
        │
        │ Tokenization
        ▼
Payment Token
        │
        ▼
Transaction

Apple Pay에서는 이 구조가 조금 더 구체적으로 나타난다.

카드를 Apple Wallet에 추가하는 과정에서 카드 발급사와 결제 네트워크가 참여하고, 해당 기기에서 사용할 수 있는 Device Account Number가 생성되어 Secure Element에 저장된다.

Apple에 따르면 이 Device Account Number는 Apple 서버에 저장되지 않으며 Secure Element 안에서 운영체제와 분리된다.

개념적인 카드 등록 과정은 다음과 같다.

USER
 │
 │ 카드 등록
 ▼
APPLE WALLET
 │
 ▼
CARD ISSUER / PAYMENT NETWORK
 │
 │ 카드 검증
 │ Token Provisioning
 ▼
DEVICE ACCOUNT NUMBER
 │
 ▼
SECURE ELEMENT

그리고 실제 결제에서는 다음과 같은 흐름이 만들어진다.

USER
 │
 │ Face ID / Touch ID / Passcode
 ▼
WALLET
 │
 ▼
SECURE ELEMENT
 │
 │ Payment Credential
 │ + Transaction-specific Security Data
 ▼
MERCHANT
 │
 ▼
PAYMENT NETWORK
 │
 ▼
CARD ISSUER
 │
 ▼
APPROVE / DECLINE

따라서 Wallet 결제에서 중요한 것은
카드번호를 보여주는 것
이 아니라,
카드 계정을 대신하는 Payment Credential을 이용해 안전하게 거래를 승인하는 것
이다.

6. Payment Tokenization과 Asset Tokenization은 완전히 다른 개념이다

여기에서 Token이라는 단어 때문에 혼동이 생긴다.

Payment Tokenization과 블록체인에서 이야기하는 Asset Tokenization은 목적이 다르다.

Payment Tokenization

Card PAN → Payment Token → Payment Transaction

목적:
민감한 결제정보를 보호하면서 기존 카드 결제망을 이용하는 것

EMV Payment Tokenisation의 핵심도 PAN을 다른 값으로 대체함으로써 모바일·온라인 결제에서 카드 데이터를 보호하는 데 있다.

반면 Asset Tokenization은 다음과 같은 개념이다.

Bond, Stock, Real Estate
Other Asset
      ↓
Digital Representation
      ↓
Token
      ↓
Digital / Blockchain Infrastructure

목적은
자산 또는 자산에 대한 권리를 디지털 형태로 표현하는 것이다.
따라서 같은 Token이라는 단어를 사용하지만 서로 다른 영역이다.

Payment Token = 결제정보 보호
Asset Token = 자산 또는 권리의 디지털 표현

Smart Wallet의 결제 구조를 설명할 때 이 둘을 구분하는 것이 중요하다.

7. Digital ID에서는 Issuer · Holder · Verifier가 핵심이다

Digital ID에서는 Payment Token과 다른 신뢰 구조가 등장한다.

W3C의 Verifiable Credentials 구조에서는 기본적으로 다음 세 역할을 구분한다.

Issuer, Holder, Verifier

Wallet을 중심으로 보면 다음과 같다.

ISSUER
정부 / 학교 / 기업
        │
        │ Credential 발급
        ▼
HOLDER
Digital Wallet
        │
        │ Credential 제시
        ▼
VERIFIER
은행 / 호텔 / 기업 / 서비스

여기서 각자의 역할은 명확하다.

Issuer

Credential을 발급하는 기관이다.

정부 → 운전면허 / 신분증
대학교 → 학위 / 학생증
기업 → 사원증 / 출입증

Issuer는

이 정보가 사실이다. 라고 증명하는 역할을 한다.

---

Holder

Credential을 보유하고 사용하는 주체다.

스마트폰 Wallet이 대표적인 Holder 역할을 할 수 있다.

Android의 Digital Credentials 문서에서도 Wallet을 Holder라고 설명하며, 하나의 사용자가 여러 Wallet을 가질 수 있는 구조를 전제로 하고 있다.

Verifier

Credential을 확인하려는 상대방이다.

예를 들어
은행, 호텔, 렌터카 회사, 온라인 서비스, 정부기관
등이 Verifier가 될 수 있다.

Verifier의 질문은 매우 단순하다.

이 정보는 진짜인가?

그러나 이것을 확인하기 위해서는 여러 검증이 필요하다.

8. Digital Credential을 사용할 때 실제로 일어나는 일

Digital ID의 전체 과정을 조금 더 자세히 보면 다음과 같다.

예를 들어 어떤 서비스가 사용자의 나이를 확인한다고 가정해보자.

먼저 서비스가 Credential을 요청한다.

VERIFIER
 │
 │ "나이를 확인할 수 있는
 │  Credential이 필요합니다"
 ▼
WALLET

Wallet은 요청에 대응할 수 있는 Credential을 찾는다.

WALLET
├── Driver's License
├── Digital ID
├── Student ID
└── Employee ID

그리고 사용자에게 어떤 정보를 제공할 것인지 확인하는 절차가 진행될 수 있다.

Verifier Request → Wallet → Credential 선택 → 사용자 확인 / 동의 → 
Credential Presentation

Google의 Credential Manager Verifier API 역시 애플리케이션이 Digital Credential을 요청하고 응답을 받은 뒤 이를 검증하는 흐름으로 구성되어 있다. Digital Credential은 정부 ID뿐 아니라 학위, 연령이나 주소 같은 속성을 증명하는 데도 사용할 수 있다.

Apple의 Verify with Wallet 역시 앱이 Apple Wallet에 저장된 정부 발급 ID의 정보를 요청하고, 사용자가 이를 승인하여 신원이나 연령 확인에 사용할 수 있도록 구성되어 있다. Apple은 Wallet에 ID가 추가되는 과정에서 발급기관이 ID의 진위와 사용자 소유 여부를 확인한다고 설명한다.

전체 흐름을 정리하면 다음과 같다.

이 과정이 바로 Digital Wallet이 단순 데이터베이스와 다른 이유다.

9. Verifier는 화면에 표시된 정보를 믿는 것이 아니다

여기서 매우 중요한 점이 있다.

Digital Credential의 목적은 Wallet 화면에

홍길동 1990년 1월 1일

이라고 표시되어 있기 때문에 그것을 믿게 만드는 것이 아니다.

화면은 얼마든지 위조할 수 있기 때문이다.

Verifier가 확인해야 하는 것은 그 데이터의 출처와 무결성이다.

개념적으로는 다음 질문을 확인해야 한다.

누가 발급했는가?
        ↓
신뢰할 수 있는 Issuer인가?

Credential이 변경되지 않았는가?
        ↓
Cryptographic Verification

현재 사용할 수 있는 Credential인가?
        ↓
Validity / Status

이 요청에 필요한 정보인가?
        ↓
Policy / Request Validation

W3C Verifiable Credentials는 바로 이러한 방식으로 발급자와 Credential의 무결성을 암호학적으로 확인할 수 있는 구조를 정의한다.

즉 Digital Credential에서 신뢰는 Wallet 화면
에서 만들어지는 것이 아니다.

Issuer → Cryptographic Proof → Credential → Verifier

라는 체인에서 만들어진다.

10. Wallet은 Issuer가 아니다

또 하나 구분해야 할 것이 있다.

Apple Wallet이나 Google Wallet에 정부 신분증이 들어 있다고 해서 Apple이나 Google이 그 신분증을 발급한 것은 아니다.

Wallet과 Issuer는 역할이 다르다.

Government
   │
   │ Credential Issuer
   ▼
Wallet
   │
   │ Holder / Presentation
   ▼
Service
   │
   │ Verifier

Wallet은 기본적으로 Credential을

받고, 저장하고, 보호하고, 선택하고, 제시하는

역할을 한다.

반면 Credential 내용의 사실성을 주장하는 것은 Issuer다.

이 구분은 스마트 월렛 구조를 이해하는 데 매우 중요하다.

11. Wallet Platform은 이 모든 과정을 연결한다

그렇다면 Apple, Google, Samsung과 같은 Wallet Platform의 역할은 무엇일까?

단순히 예쁜 카드 이미지를 화면에 보여주는 것이 아니다.

Wallet Platform은 여러 구성요소 사이를 연결한다.

개념적으로 보면 다음과 같다.

여기서 Wallet Platform의 중요한 역할은 서로 다른 기관이 만든 Credential을 사용자가 일관된 방식으로 사용할 수 있도록 연결하는 것이다.

Android에서도 Digital Credential 구조를 Issuer, Holder, Verifier로 나누고 있으며, Credential Manager를 통해 Credential을 발급하거나 Holder Wallet이 이를 관리·제시하고 Verifier가 요청하는 구조를 제공한다.

12. 결국 Smart Wallet은 ‘Trust Router’에 가깝다

여기까지 구조를 하나로 합치면 Smart Wallet의 역할이 보다 명확해진다.

사용자는 Wallet에 있는 정보를 그냥 꺼내 보여주는 것이 아니다.

그리고 실제 사용 순간에는 반대 방향의 요청이 발생한다.

Merchant,Bank,Hotel
Vehicle,Government Service
Online Service
        │
        │ Credential Request
        ▼
      Wallet
        │
        │ 사용자 확인
        ▼
 Credential Presentation
        │
        ▼
Verification

따라서 Smart Wallet을 가장 단순하게 정의하면

Credential Storage + Device Security + User Authentication + Credential Presentation + Issuer / Verifier Connection

으로 볼 수 있다.

하지만 이것을 한 문장으로 압축하면 더 분명하다.

Smart Wallet은 정보를 저장하는 앱이라기보다, 사용자와 발급기관 그리고 검증기관 사이에서 디지털 신뢰를 연결하는 인터페이스다.

그리고 이 구조를 이해하면 Wallet 안에

결제카드, 신분증, 운전면허, 자동차 키, 출입증, 티켓, 자격증명

처럼 서로 전혀 달라 보이는 것들이 왜 하나의 앱 안으로 모이고 있는지도 이해할 수 있다.

겉으로는 서로 다른 서비스지만 내부적으로는 상당 부분 같은 질문을 처리하기 때문이다.

누가 발급했는가?
        ↓
누구에게 발급했는가?
        ↓
어떻게 안전하게 보관할 것인가?
        ↓
사용자가 실제 소유자인가?
        ↓
어떤 정보를 사용할 것인가?
        ↓
누구에게 제시할 것인가?
        ↓
상대방은 어떻게 진위를 확인할 것인가?

이것이 Smart Wallet이 작동하는 기본 원리다.