길리랩blog

DID·SSI·VC로 설계하는 분산 신원 관리

DID, SSI, Verifiable Credentials를 중심으로 분산 신원 체계의 구성, 발급·검증·철회 흐름과 운영 고려사항을 정리한다.

2026-08-14 · 최초 발행 2025-10-31

중앙 IdP 밖에서 신원을 검증하는 방식

분산 신원 체계는 신원 데이터를 하나의 중앙 IdP에 집중하는 대신, 이용자가 지갑에 키와 자격증명을 보관하고 필요한 순간에 제시하도록 구성한다. 이 구조에서 DID(Decentralized Identifier), SSI(Self-Sovereign Identity), VC(Verifiable Credentials)는 각각 식별자, 신원 관리 방식, 검증 가능한 자격증명이라는 역할을 맡는다.

DID는 블록체인이나 분산원장에 앵커링할 수 있는 탈중앙 식별자다. DID Document에는 공개키, 인증 수단, 서비스 엔드포인트가 정의되며, DID Method마다 등록과 해결 규칙이 다르다. 예를 들어 did:ion, did:ethr, did:key는 서로 다른 방식으로 동작한다. DID Resolver는 DID를 DID Document로 매핑한다.

SSI는 이용자가 자신의 신원정보를 중심적으로 통제하는 패러다임이다. 키와 자격증명은 신원 지갑에 보관하고, 공유는 이용자 동의를 바탕으로 이뤄진다. 발행자(Issuer), 보관자(Holder), 검증자(Verifier)가 역할을 나누는 삼자 모델은 상호운용 체계를 위한 기반이 된다.

VC는 발행자가 디지털 서명한 자격증명 데이터 구조다. JSON-LD VC와 JWT VC 형식을 사용할 수 있으며, 선택적 공개, 상태·철회 관리, ZKP 기반 프라이버시 강화 증명을 지원한다.

신원 체계를 구성하는 운영 지점

DID 레지스트리와 리졸버는 원장에 기록된 DID 상태를 조회하고 검증한다. 이 계층은 캐싱과 가용성을 고려해야 하며, 특정 DID Method에 잠기는 위험도 있다. DID Resolution 스펙을 따르는 이유도 여기에 있다.

지갑은 개인키 보관, 서명, 백업, 복구를 담당한다. 모바일이나 브라우저 지갑을 비수탁형으로 운영할지 수탁형으로 운영할지 결정해야 하며, 키 로테이션과 Social recovery, MPC/HSM 기반 분실 복구, 생체 인증 연계도 설계 대상이다.

발행·보관·검증 역할 사이의 메시지 흐름에는 OIDC4VCI/OIDC4VP, DIDComm v2 같은 전송 및 상호운용 프로토콜을 적용할 수 있다. 프레젠테이션 요청과 응답의 범위, 필요한 속성, 정책을 명확히 정의해야 한다.

자격증명 표현 방식도 선택이 필요하다. JSON-LD의 Linked Data Proofs, BBS+와 JWT의 SD-JWT는 생태계, 성능, ZKP 지원 수준에서 차이가 있다. 검증에는 필요한 속성만 내보내는 선택적 공개와, 여러 제시를 연결하기 어렵게 하는 비연결성(unlinkability)을 함께 고려한다.

철회 상태는 Status List 2021/2023 같은 오프체인 대규모 철회 목록으로 관리할 수 있다. 오프라인 검증에 유리하지만, 발급·철회 트랜잭션의 일관성과 상태 전파 지연을 감안해 검증자 캐시 갱신 전략을 마련해야 한다.

발급부터 검증 결과까지의 연결

⤢✕Verifier(검증자)Holder(지갑)DID Registry/BlockchainIssuer(발행자)Verifier(검증자)Holder(지갑)DID Registry/BlockchainIssuer(발행자)DID 등록/갱신VC 발급제시·검증alt[서명 불일치 또는 철회됨][유효]DID 생성/등록(공개키 앵커링)1DID Document 확인2프레젠테이션 요청(VP 요청 스펙, 스코프)3자격 발급 요청 또는 사전 발급된 VC 보유4VC 서명 발급(JSON-LD/JWT)5VP 제출(선택적 공개/ZKP 포함)6Issuer DID 해석·키 획득7상태 엔드포인트/리스트로 철회 확인8검증 결과(수락/거절)9실패 사유 반환(서명/만료/철회)10접근 승인/온보딩 완료11

VC 발급에는 발급자 DID와 키, 스키마, 수취인 DID, 속성, 만료·상태 정책이 들어간다. 발급자는 VC를 생성하고 서명한 뒤, 필요하다면 상태 레지스트리를 업데이트하고 보관자 지갑으로 전달한다. 결과물은 서명된 VC와 status URL, bitstring index 등의 상태 핸들이다. DID 문서의 최신성, 서명 키의 유효성, 상태 레지스트리 커밋 순서는 일관성 관점에서 확인해야 한다.

제시 단계에서 검증자는 요구 속성과 정책을 담은 프레젠테이션 요청을 보내고, 보관자는 선택적 공개 또는 ZKP를 포함한 VP를 구성해 전송한다. 검증자는 서명, 만료, 철회 상태, 발행자 신뢰도를 확인한 후 승인 또는 거절 결과와 근거 로그를 남긴다. DID 해석 실패, 키 로테이션 미반영, 상태 리스트 미동기화에는 재시도와 캐시 무효화 전략이 필요하다.

철회와 갱신은 철회 사유와 대상 VC의 상태 인덱스를 입력으로 삼는다. Status List 2021/2023의 상태 비트맵을 바꾸거나 온체인 이벤트를 기록하고, 최신 상태 리스트와 타임스탬프·서명이 포함된 증빙을 제공한다. eventual consistency를 전제로 검증자 캐시 TTL과 Etag를 활용하고, 강제 재검증 API도 제공할 수 있다.

중앙집중형 신원 관리와의 차이

항목 중앙집중 신원 SSI/VC 기반 분산 신원
성능 단일 IdP TPS 최적화가 용이하나 단일 장애점이 존재한다. 검증은 로컬 암호 검증 중심으로 이뤄지며 고TPS를 지원한다. 원장 조회는 캐시로 흡수한다.
확장성 수직 확장 중심이며 테넌시 분리가 필요하다. 오프체인 VC와 오프라인 검증을 통해 수평 확장이 가능하다.
일관성 강한 일관성과 중앙 정책의 즉시 반영이 가능하다. eventual consistency를 전제로 상태 리스트 전파 지연을 고려해야 한다.
안정성 IdP 장애가 광범위한 영향으로 이어질 수 있다. 원장·상태 캐시 다중화와 지갑 분산으로 내결함성을 높일 수 있다.
운영 편의 중앙 통제와 모니터링이 쉽다. 지갑, 원장, 상태 인프라, 신뢰 프레임워크의 운영 복잡성이 커진다.

신원 확인이 필요한 업무의 적용 범위

금융에서는 비대면 계좌개설과 대출 온보딩에 재사용 가능한 eKYC 자격증명을 도입할 수 있다. 거래소와 핀테크 사이에서 상호 검증 가능한 VC를 교환하고, AML/CTF 규정 준수를 자동화하는 흐름도 대상이 된다.

공공·모빌리티 영역에서는 디지털 운전면허와 주민 서비스 접근, 통행권과 출입증에 VC를 적용할 수 있다. 오프라인 검증을 지원하고 국경·공항 신원 확인이나 모바일 여권 시범 적용까지 연결할 수 있으나, 최신 규제와 표준의 정합성 확인이 필요하다.

기업 환경에서는 직원 자격과 역할을 이용해 RBAC에서 ABAC로 접근 제어를 고도화하고, 공급망 파트너 인증을 자동화할 수 있다. 교육·자격증 VC는 온보딩과 감사 비용 절감에도 활용된다.

헬스케어에서는 예방접종·의료 자격 VC를 발급하고, 데이터 주권과 동의 기반 공유를 강화할 수 있다. ZKP를 활용한 프라이버시 보호형 제시는 필요한 속성만 노출하는 방식이다.

보안성과 사용성 사이의 선택

키와 지갑은 HSM/TEE, 키 로테이션, Social recovery, Shamir/MPC 기반 복구 정책을 중심으로 보호한다. 보안을 강화할수록 사용자 경험이 달라질 수 있고, 비수탁형의 자율성과 수탁형의 편의성도 함께 비교해야 한다.

프라이버시 측면에서는 선택적 공개, BBS+/SD-JWT, 최소 데이터 공유 원칙이 기준이 된다. ZKP를 도입하면 계산 복잡도와 지갑 성능에 영향을 줄 수 있으며, 표준과 도구의 성숙도 차이도 남는다.

원장 선택은 퍼블릭 체인과 컨소시엄 체인의 적합성, DID Method 다변화, 신뢰 프레임워크와 정책 문서화를 함께 평가하는 문제다. 가스비와 거래 최종성, 개방성과 검증 가능성, 메소드 잠김 위험이 맞물린다.

eKYC, 데이터 보호법, 전자서명법 준수와 철회·감사 추적 가능성도 운영 요건이다. 익명성과 프라이버시는 규제 보고 요구사항과 충돌할 수 있으므로 최신 규제 변화의 모니터링이 필요하다.

DIDKit CLI로 VC 발급과 검증하기

전제조건

  • macOS/Linux, didkit v0.3+ 설치 필요
    • macOS: brew install spruceid/tap/didkit
    • 또는 Rust: cargo install didkit
  • jq, openssl 사용 가능 환경

키와 DID를 생성한다.

didkit generate-ed25519-key > issuer.key.jwk
didkit key-to-did key -k issuer.key.jwk > issuer.did
cat issuer.did

VC 템플릿 credential.json은 다음과 같이 준비한다.

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "id": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "type": ["VerifiableCredential", "KYCStatement"],
  "issuer": "REPLACE_WITH_ISSUER_DID",
  "issuanceDate": "2025-01-01T00:00:00Z",
  "expirationDate": "2026-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkholderExample",
    "kyc": { "ageOver": 19, "residency": "KR" }
  }
}

발급자 DID를 템플릿에 반영한 뒤 서명된 VC를 생성한다.

ISSUER_DID=$(cat issuer.did)
jq --arg iss "$ISSUER_DID" '.issuer=$iss' credential.json > credential.issuing.json

didkit vc-issue-credential \
  -k issuer.key.jwk \
  -p proofPurpose="assertionMethod" \
  -p verificationMethod="$(didkit key-to-verification-method -k issuer.key.jwk key)" \
  < credential.issuing.json > credential.signed.json

cat credential.signed.json | jq .

검증은 생성된 자격증명을 입력으로 실행한다.

didkit vc-verify-credential < credential.signed.json
# 결과: { "checks": ["proof"], "warnings": [], "errors": [] }

JSON-LD VC 기준 예시이며, JWT VC를 사용할 때는 didkit vc-issue-credential -f jwt 옵션을 활용할 수 있다. 상태·철회(Status List)를 확인하려면 별도의 상태 엔드포인트를 운영해야 하며, 네트워크와 정책에 따라 최신 정보를 확인해야 한다.

도입 시 기대할 수 있는 변화

재사용 가능한 VC는 KYC와 온보딩 자동화, 수작업 검증 감소에 활용할 수 있다. PoC 기준 인증 처리 시간 단축 사례가 다수 있으나 도메인별 편차가 존재한다.

최소 데이터 공유와 암호 검증은 위변조 방지와 데이터 유출 면적 축소에 기여한다. 오프체인 검증은 고TPS 환경을 지원하고 조직 간 신뢰 연계를 확장하기 쉽게 만든다. 발행·제시·철회 이력을 추적할 수 있어 감사와 컴플라이언스 대응도 효율화할 수 있다.

DID·SSI·VC를 도입할 때는 한정된 스키마와 프로토콜로 파일럿을 시작하고, 상태·철회 인프라를 연계한 뒤 전사 거버넌스로 확장하는 흐름을 고려할 수 있다.

분산 신원DIDSSIVC블록체인