탈중앙화 신원(DID/VC)의 구조와 작동 방식

Written by 정혜교, 한서영(이화체인 16기)

1. 왜 탈중앙화 신원(DID/VC) 시스템에 주목해야 하는가?

웹 2.0 신원 체계의 형성

디지털 전환이 가속화되면서 대부분의 사회적·경제적 상호작용은 물리적 공간에서 온라인 공간으로 이동했다. 이 과정에서 신원(Identity)은 디지털 생태계에 접근하기 위한 핵심 인프라가 되었다.

초기 인터넷에는 독립적인 신원 계층이 존재하지 않았기 때문에, 각 웹사이트는 사용자 이름과 비밀번호를 자체적으로 저장·관리하는 구조를 채택했다. 그러나 서비스 수가 증가하면서 사용자는 수많은 계정을 직접 관리해야 했고, 기업은 대규모 사용자 데이터를 보관해야 하는 부담을 떠안게 되었다.

이러한 문제를 해결하기 위해 등장한 것이 연합 신원(Federated Identity)과 소셜 로그인이다. 구글, 메타, 애플과 같은 대형 플랫폼이 신원 제공자(IdP) 역할을 수행하면서 사용자는 하나의 계정으로 여러 서비스를 이용할 수 있게 되었다. 그러나 이러한 구조는 편의성을 제공하는 동시에 특정 플랫폼에 대한 의존을 강화하는 결과를 낳았다.

중앙집중형 신원 증명의 한계

① 보안적 취약성 웹 2.0 신원 체계의 가장 근본적인 문제는 신원 정보가 중앙 서버에 집중되어 있다는 점이다. 이러한 중앙집중형 구조는 단일 장애 지점(Single Point of Failure)을 내포하며, 중앙 서버가 침해될 경우 대규모 개인정보 유출로 이어질 수 있다. 여기에 비밀번호 재사용 문제까지 더해지면, 하나의 계정 침해가 여러 서비스로 연쇄 확산되는 위험도 발생한다.

② 데이터 주권의 상실 중앙집중형 신원 구조에서 플랫폼은 단순한 서비스 제공자를 넘어 신원 관리자로 기능한다. 사용자 인증 과정에서 생성되는 로그인 기록과 이용 데이터는 플랫폼에 축적되며, 이는 플랫폼의 고도화된 데이터 분석과 수익화로 이어진다.

그 결과 사용자는 자신의 신원 데이터를 실질적으로 통제하기 어렵다. 정보의 수집·이용·제공 여부는 플랫폼 정책에 좌우되며, 동의 철회나 데이터 수정 역시 제한적인 절차 안에서만 가능하다. 이처럼 데이터 통제권은 중앙 플랫폼에 집중되며, 사용자의 데이터 주권은 약화된다.

탈중앙화 신원의 등장

결론적으로 웹 2.0 기반 신원 구조는 사용자 편의성을 크게 향상시켰지만, 동시에 보안 취약성과 데이터 주권 상실이라는 구조적 문제를 내포하고 있다.

이러한 한계를 극복하기 위한 대안으로 제시된 개념이 자기주권신원(Self-Sovereign Identity), 즉 탈중앙화 신원(Decentralized Identity)이다. 두 구조의 핵심적인 차이는 신원에 대한 통제권이 누구에게 귀속되는가에 있다. 중앙집중형 모델에서는 기관이 신원을 생성·보관·관리하고, 사용자는 인증을 요청하는 위치에 머무른다. 반면 탈중앙화 신원 모델에서는 사용자가 자신의 신원을 직접 보유하며, 필요한 정보만을 선택적으로 제시하고 증명할 수 있다.

DID/VC의 활용 가능성

DID는 다양한 환경에서 활용될 수 있다. 예를 들어, 온라인 거래에서는 상품의 진품 여부나 소유권 이전 기록을 Verifiable Credential(VC) 형태로 발급하여 거래 이력을 검증 가능한 방식으로 관리할 수 있다. VC의 개념과 구조는 이후 장에서 자세히 살펴본다.

또한 기업 환경에서는 교육 이수, 수상 내역, 업무 성과와 같은 정보를 VC 형태의 자격증명으로 발급해 개인이 직접 보유할 수 있다. 이러한 자격증명은 조직 내부 기록에 머무르지 않고 개인용 경력 포트폴리오로 활용될 수 있다.

국내 활용 사례

한국에서는 DID 기반 모바일 신분증 및 모바일 운전면허증이 도입되어 운영되고 있으며, 일부 가상자산 거래소에서는 DID 기반 인증 기술을 고객확인 절차에 활용하고 있다. 또한 모바일 신분증의 법적 근거가 마련되면서 향후 공공 및 민간 영역 전반에서 DID 기반 신원 인증의 활용 범위가 확대될 것으로 전망된다.

2. DID란 무엇인가

DID(Decentralized Identifier)란?

DID(Decentralized Identifier)는 중앙 등록 기관 없이도 전 세계적으로 사용할 수 있는 고유하고 지속적인 식별자다. 개인이나 조직이 다른 사람, 기관, 시스템과 상호작용할 때 자신이 누구인지 증명하거나, 자신이 통제하는 대상(디바이스, 자격증명 등)에 대한 통제권을 증명하는 데 활용된다.

여기서 중요한 특징은 다음과 같다.

• 개인이 식별자의 생성을 직접 통제할 수 있다
• 식별자의 지속성을 보장하기 위해 특정 중앙 기관에 의존하지 않는다.
• 신원 증명 과정에서 공개할 정보의 범위를 스스로 결정할 수 있다.

DID의 설계 원칙

DID는 탈중앙화를 핵심 원칙으로 한다. 신원 인프라가 특정 기관이나 단일 시스템에 종속되지 않도록 설계되었으며, 프라이버시 보호를 중요한 가치로 삼는다. 사용자는 정보 공개 범위를 스스로 통제할 수 있어야 하며, 다음과 같은 원칙이 적용된다.

• 최소 공개 (minimal disclosure)
• 선택적 공개 (selective disclosure)
• 점진적 공개 (progressive disclosure)

또한 DID 시스템은 암호학적 증명(예: 디지털 서명)을 통해 신원 통제권을 검증할 수 있도록 설계되어 있다. 이를 통해 단순한 사칭이나 자격 증명의 위조를 어렵게 만든다.

DID의 구성요소

DID 시스템은 여러 구성 요소가 유기적으로 연결되어 작동한다.

• DID Subject: DID에 의해 식별되는 대상 자체를 의미한다. 이는 사람, 조직, 디바이스, 혹은 디지털·물리적 객체 등 다양한 개체가 될 수 있다.
• DID: 특정 DID Subject를 지칭하는 전 세계적으로 고유한 식별자다.
• DID Document: 해당 DID와 연결된 메타데이터 문서로, 검증 방법, 서비스 정보, 통제 구조 등을 포함한다.
• DID Controller: DID Document를 관리할 권한을 가진 주체로, 일반적으로 관련 암호학적 키를 보유한다.
• DID URL: DID의 확장 형태로, 문서 내 특정 리소스를 구체적으로 참조할 수 있다.
• Verifiable Data Registry(VDR): DID와 DID Document의 상태를 기록하고 참조할 수 있도록 지원하는 인프라. 보통 분산 원장 구조를 활용한다.

이처럼 DID 시스템은 식별 대상, 식별자, 문서, 통제 주체, 참조 방식, 그리고 이를 기록·해석하는 인프라가 결합된 구조로 이루어져 있다.

3. DID Resolution과 서명 검증 과정

DID는 단순한 문자열이 아니라, 해석(resolve) 과정을 통해 해당 DID Document를 조회할 수 있는 식별자다.

예를 들어 did:example:123이라는 DID가 존재한다고 가정하자. 이 DID를 resolve하면, 해당 식별자에 대응되는 DID Document가 반환된다.

DID Document에는 해당 DID의 신원 및 검증 구조를 설명하는 정보가 포함된다. 대표적으로 다음과 같은 요소들이 기록된다.

• verificationMethod: 공개키 등 암호학적 검증에 사용되는 키 정보
• authentication: DID Controller가 인증에 사용할 수 있는 키 참조
• assertionMethod: 서명된 주장(credential 등)에 사용되는 키 참조
• service: 관련 서비스 엔드포인트
• controller: 해당 DID를 관리할 권한을 가진 주체

검증자(Verifier)는 DID Document에 기록된 공개키를 활용해, 특정 DID로 서명된 데이터가 실제 해당 DID Controller에 의해 생성되었는지를 암호학적으로 검증할 수 있다.

4. Verifiable Credential(VC)이란 무엇인가

VC의 등장 배경

DID는 강력한 식별자다. 중앙 기관 없이 생성되고, 암호학적 키로 소유권을 증명하며, 블록체인 기반 레지스트리를 통해 신뢰를 보장한다. 그러나 DID는 “이 엔티티가 존재한다”는 사실은 증명할 수 있지만, “이 엔티티가 특정 자격을 갖추고 있다”는 사실까지는 증명하지 못한다.

예를 들어 다음과 같이 설명할 수 있다. 디지털 신원은 기존에도 중앙화된 방식으로 관리되어 왔다. 졸업증명서는 대학 서버에, 자격증은 국가 기관 DB에, 재직증명서는 회사 HR 시스템에 저장된다. 이러한 자격증명을 검증하려면 해당 기관에 직접 조회해야 하며, 그 과정에서 개인정보가 불필요하게 노출되거나 검증 완료까지 수 일이 걸리기도 한다.

Verifiable Credential(VC)은 이러한 문제를 해결하기 위해 등장했다. W3C가 표준화한 VC는 암호학적 서명으로 위변조를 방지하고, DID를 기반으로 발급자와 소지자를 식별하며, 중앙 기관 조회 없이 즉시 검증 가능한 디지털 자격증명이다.

VC 시스템의 구조 — Issuer, Holder, Verifier

https://cheqd.io/ssi/

VC 시스템은 세 주체가 상호작용하는 신뢰 삼각형(Trust Triangle) 구조로 작동한다.

• Issuer(발급자)는 자격증명을 생성하고 서명하는 주체다. 대학, 정부 기관, 병원, 기업 등 신뢰할 수 있는 기관이 해당한다. Issuer는 자신의 DID와 개인키로 VC에 서명하며, 이 서명은 클레임 내용에 대한 기관의 보증을 의미한다.
• Holder(소지자)는 VC를 발급받아 보관하고 필요할 때 제시하는 주체다. 개인 사용자가 해당하며, VC는 사용자의 디지털 지갑(wallet)에 저장된다. Holder는 VC를 그대로 제시할 수도 있고, ZKP를 활용해 일부 클레임만 선택적으로 공개할 수도 있다.
• Verifier(검증자)는 Holder가 제시한 VC를 검증하는 주체다. 서비스 제공자, 고용주, 금융 기관 등이 해당한다. Verifier는 Issuer의 DID를 VDR(Verifiable Data Registry)에서 조회해 서명 유효성을 확인하고, VC 내용이 변조되지 않았음을 암호학적으로 검증한다.

이 구조의 핵심은 세 주체 사이에 직접적인 실시간 통신이 반드시 필요하지 않다는 점이다. Issuer가 오프라인 상태이더라도 Verifier는 블록체인에 기록된 공개키만으로 서명의 유효성을 검증할 수 있다.

VC의 흐름 — Issuance → Storage → Presentation → Verification

① Issuance (발급) Issuer는 Holder의 DID를 subject로 지정하고, 클레임을 포함한 VC를 생성한다. 이후 Issuer의 개인키로 이 VC에 디지털 서명을 적용한 뒤 Holder에게 전달한다. Issuer의 공개키는 VDR에 등록된 DID Document에 공개되어 있어, 누구든지 이를 서명 유효성 검증에 활용할 수 있다.

② Storage (저장) Holder는 수신한 VC를 디지털 지갑에 저장한다. 지갑은 모바일 어플리케이션, 브라우저 확장, 하드웨어 보안 모듈(HSM) 등 다양한 형태로 구현된다. 중요한 점은 VC가 중앙 서버가 아닌 Holder의 장치에 직접 저장된다는 점이다. 이 구조는 플랫폼 종속성을 제거하고, 서버 해킹으로 인한 대규모 데이터 유출 가능성을 구조적으로 차단한다.

③ Presentation (제시) Holder가 Verifier에게 자격증명을 제시할 때는 원본 VC를 그대로 전달하거나 Verifiable Presentation(VP) 형태로 패키징해 제출한다. VP는 하나 이상의 VC를 묶어 Holder가 직접 서명한 제출 패키지다. VP에 Holder의 서명이 포함되기 때문에, 이미 사용된 VP를 재사용하는 재전송 공격(replay attack)을 방어할 수 있다.

④ Verification (검증) Verifier는 세 단계에 걸쳐 검증을 수행한다.

1. 먼저 Issuer의 DID를 VDR에서 조회해 DID Document의 공개키를 확보한다.
2. 다음으로 해당 공개키로 VC의 디지털 서명을 검증해 위변조 여부를 확인한다.
3. 마지막으로 VC의 유효기간과 폐기 상태(revocation status)를 확인한다

세 단계를 모두 통과하면 해당 자격증명은 신뢰할 수 있는 것으로 판단된다.

선택적 공개와 ZKP

https://medium.com/gopax/영지식-증명의-이해와-활용-사례-315165f77790

VC의 핵심 기능 중 하나는 선택적 공개(Selective Disclosure)다. 일반적으로 자격증명을 제시할 때는 VC 전체를 공개해야 한다. 그런데 실제 검증 상황에서는 모든 정보가 항상 필요한 것은 아니다. 예를 들어, 성인 인증이 목적이라면 정확한 생년월일보다 “만 19세 이상인가”라는 사실만으로도 충분하다.

이를 가능하게 하는 기술이 영지식증명(Zero-Knowledge Proof, ZKP)이다.

ZKP는 어떤 명제가 참임을 증명하되, 그 명제를 참으로 만드는 실제 값은 공개하지 않는 암호학적 기법이다. VC 맥락에서는 특정 클레임 값이 어떤 조건을 만족한다는 사실만 증명하고, 실제 클레임 값은 숨길 수 있다.

BBS+ 서명을 활용한 선택적 공개에서는 Issuer가 각 클레임 항목에 대해 독립적으로 서명을 적용한다. Holder는 전체 클레임 중 원하는 항목만 선택해, 선택하지 않은 항목이 존재한다는 사실조차 드러내지 않으면서 파생 증명(derived proof)을 생성할 수 있다. Verifier는 이 파생 증명만으로 선택된 클레임이 유효한 VC에서 비롯되었는지를 검증한다.

Hyperledger AnonCreds에서 활용하는 CL(Camenisch-Lysyanskaya) 서명 기반 ZKP에서는 “나이 ≥ 19”와 같은 범위 증명(range proof)도 가능하다. 이 방식은 실제 나이 값을 공개하지 않고도 조건 충족 여부만을 수학적으로 증명할 수 있게 한다.

ZKP는 VC 시스템에서 프라이버시 보호의 핵심 메커니즘으로 작동한다. 증명은 하되 최소한의 정보만 공개한다는 원칙을 기술적으로 구현한 것이다.

5. VC의 장점

자기주권적 통제

기존 디지털 신원 시스템에서 개인은 자신의 자격증명을 사실상 소유하지 못했다. 졸업증명서는 대학 서버에, 건강보험 이력은 보험사 DB에, 직장 경력은 HR 플랫폼에 각각 흩어져 있었다. 사용자가 이를 필요로 할 때마다 해당 기관에 요청해야 했고, 기관이 서비스를 중단하거나 정책을 변경하면 접근 자체가 불가능해지는 구조였다.

VC는 이러한 구조를 바꾼다. 발급된 VC는 Holder의 디지털 지갑에 저장되며, Issuer는 한 번 발급한 이후 해당 자격증명에 대한 통제권을 갖지 않는다. Holder는 자신이 원하는 시점에, 원하는 Verifier에게, 원하는 정보만 선택해 제시할 수 있다. 이것이 자기주권 신원(Self-Sovereign Identity, SSI)의 핵심이다.

SSI는 신원 데이터의 소유권을 개인에게 돌려주는 개념이다. 플랫폼이 신원을 관리하던 구조에서 벗어나, 개인이 직접 신원을 관리하는 구조로의 전환을 의미한다.

중앙 DB 해킹 리스크의 구조적 제거

지난 2025년에 국내 대기업에서 대규모 개인정보 유출 및 해킹 사고가 잇따라 발생하였다. 이러한 사고들의 공통점은 수많은 사람의 자격증명 데이터가 하나의 중앙 서버에 집중되어 있었다는 것이다.

공격자 입장에서 중앙화된 DB는 단 한 번의 침입으로 수천만 건의 데이터를 확보할 수 있는 고가치 타깃이다. 보안 투자를 강화하더라도, 중앙 집중 구조가 가진 고밀도 위험(high-value target risk)은 본질적으로 해소되지 않는다.

VC는 이 문제를 구조적으로 제거한다. 자격증명이 개인의 지갑에 분산 저장되므로 단일 실패 지점(single point of failure)이 존재하지 않는다. VDR에는 공개키와 DID Document와 같은 공개 정보만 기록되기 때문에, 해당 데이터가 노출되더라도 개인정보 유출로 이어지지 않는다. 특정 개인의 지갑이 침해되더라도 피해는 그 개인에게 국한된다.

즉시 암호학적 검증

기존 자격증명 검증 방식은 신뢰의 중계(trust relay)에 의존해 왔다. Verifier는 자격증명의 진위를 확인하을 위해 발급 기관에 문의하고, 회신을 기다려야 했다. 이 과정은 시간이 오래 걸리고, 발급 기관의 가용성(availability)에 의존하며, 검증 과정에서 Holder의 정보가 제3자에게 추가로 노출된다.

VC는 이러한 의존성을 제거한다. 검증에 필요한 모든 정보(Issuer의 공개키, 서명 알고리즘, 유효성 조건)가 VC와 DID Document에 포함되어 있기 때문다. Verifier는 Issuer에게 별도로 문의하지 않고도 바로 독립적으로 서명을 검증할 수 있다.

또한 공개키가 사전에 캐시되어 있다면 오프라인 환경에서도 검증이 가능하다. 이는 실시간 API 호출에 의존하는 기존의 검증 방식과 근본적으로 다른 신뢰 모델을 제공한다.

선택적 공개로 프라이버시를 설계한다

기존 자격증명 제시 방식에서는 과도한 정보 공개가 구조적으로 강제됐다. 성인 인증 하나를 위해 이름, 생년월일, 주소, 주민등록번호 앞자리가 모두 노출되는 식이다. Verifier가 실제로 필요로 하는 정보는 “성인인가”라는 단 하나의 사실임에도 불구하고.

VC와 ZKP의 결합은 이러한 과잉 공개를 해결한다. Holder는 VC에서 공개할 클레임만 선택하거나, 실제 값 대신 특정 조건을 충족한다는 여부만을 증명하는 ZKP를 생성할 수 있다.

이러한 접근 방식을 프라이버시 바이 디자인(Privacy by Design)이라 한다. 사후적인 보안 조치가 아니라 설계 단계부터 최소 정보 공개 원칙(data minimization)을 내재화하는 방식이다. 이러한 설계 철학은 GDPR을 비롯한 개인정보 보호 규제가 요구하는 방향과도 일치한다.

또한 VC는 연결 불가능성(unlinkability)도 지원한다. 동일한 VC를 매 제시마다 반복적으로 사용하면, Verifier들이 공모해 사용자의 행동 패턴을 추적할 수 있다. 그러나 ZKP 기반 구현에서는 동일한 VC로부터 매번 다른 파생 증명을 생성할 수 있어, 서로 다른 Verifier가 동일 Holder의 행위를 연결하지 못하도록 설계할 수 있다.

6. 하지만 이 구조는 완벽한가?

지금까지 살펴본 DID와 VC의 구조는 기존 중앙화 신원 시스템이 가진 근본적인 한계를 상당 부분 해결한다. 신원의 주권은 개인에게 돌아오고, 단일 실패 지점은 사라지며, 검증은 암호학적으로 보장된다. 설계만 놓고 보면 이 시스템은 거의 완벽해 보인다.

그러나 암호학적으로 견고한 구조가 현실 세계에서도 안전하다는 의미는 아니다.

구조의 강점이 곧 공격 표면이 된다

DID와 VC 시스템의 신뢰 기반은 암호학적 키다. 그런데 바로 이 키가 동시에 가장 취약한 지점이기도 하다. Holder의 개인키가 탈취된다면 공격자는 해당 DID의 완전한 통제권을 획득한다. 기존 중앙화 시스템에서는 서버 측에서 세션을 강제 종료하거나 비밀번호를 초기화하는 방식으로 대응할 수 있었지만, 탈중앙화 구조에서는 개인키 탈취에 즉각 개입할 중앙 관리자가 존재하지 않는다.

Issuer 역시 공격에서 자유롭지 않다. VC의 신뢰는 궁극적으로 Issuer의 신뢰성에 기반한다. 만약 악의적인 행위자가 Issuer로 등록되거나 합법적인 Issuer의 키가 침해된다면, 위조된 자격증명이 암호학적으로 유효한 것처럼 보일 수 있다. 즉, 서명 자체는 완벽하지만 그 서명이 가리키는 사실 자체가 거짓인 상황이 발생할 수 있다.

Verifier도 예외가 아니다. DID Resolution 과정 (즉, Verifier가 VDR에서 Issuer의 DID Document를 조회하는 단계)에는 DNS 하이재킹, 캐시 포이즈닝, 중간자 공격(MITM) 등의 위협이 잠재한다. Resolution 결과가 조작된다면 Verifier는 공격자의 공개키를 Issuer의 것으로 오인하고, 위조된 VC를 정상으로 판단할 수 있다.

탈중앙화는 책임의 분산이기도 하다

중앙화 시스템의 단점으로 지적되던 요소들(중앙 관리자의 존재, 단일 통제 지점, 개입 가능한 권한 구조 등)은 역설적으로 보안 사고 발생 시 복구를 가능하게 하는 장치이기도 했다. 탈중앙화 구조에서는 이러한 복구 레버가 상당 부분 제거된다. 대신 키 관리·신뢰 검증·폐기 처리 등의 책임이 각 참여 주체에게 분산된다. 그 결과, 시스템 전체의 보안 수준이 가장 약한 주체의 보안 수준에 의해 결정될 수 있다.

다음 아티클에서는 DID/VC 구조에서 실제로 어떤 지점이 공격 표면이 될 수 있는지 분석하고, 각 위협에 대한 대응 전략을 구체적으로 살펴본다.

참고 자료

• W3C Verifiable Credentials Data Model
• DID와 SSI 그리고 VC, VP에 대한 개념 정리
• TTA 주간기술동향 — DID 기반 자기주권 신원
• https://cheqd.io/ssi/
• https://json-ld.org/
• https://xangle.io/research/detail/1612
• https://www.dock.io/post/centralized-id-federated-id-decentralized-id-whats-the-difference
• https://www.identity.org/centralized-vs-decentralized-identity-management/
• https://www.arcblock.io/blog/en/decentralized-identity-stop-data-breaches-now
• https://www.w3.org/TR/did-1.0/