뿡야의 IT 기록

온라인에서 “내가 누구인지”를 증명하는 일은 로그인보다 넓은 문제다.

우리는 온라인에서 여러 종류의 증명을 요구받는다.

서비스에 로그인할 때는 계정의 주인임을 증명한다. 금융 서비스를 이용할 때는 실제 신원을 확인한다. 학생 할인을 받을 때는 재학 여부를, 연령 제한 서비스를 이용할 때는 나이 조건을 충족하는지 증명한다.

모두 비슷해 보이지만 확인하려는 내용은 다르다.

계정을 통제한다는 사실, 현실의 특정 인물이라는 사실, 어떤 자격을 갖췄다는 사실은 각각 별도의 주장이다.

디지털 신원을 이해하려면 이 차이부터 살펴볼 필요가 있다. 이 글에서는 기본 개념을 정리한 뒤 DID, 검증 가능한 자격증명, 디지털 지갑, 유럽의 eIDAS 2.0이 어떻게 연결되는지 알아본다.

1. 디지털 신원이란 무엇일까?

디지털 신원은 온라인 환경에서 어떤 주체를 구분하고, 그 주체에 관한 정보를 표현하는 데 사용된다.

사람을 예로 들면 다음과 같은 정보가 관련될 수 있다.

• 서비스 안에서 사용하는 계정 식별자
• 이름이나 생년월일 같은 속성
• 재학·재직·면허 보유 여부
• 계정과 연결된 인증 수단

모든 서비스가 이 정보를 전부 필요로 하는 것은 아니다.

익명 게시판에서는 같은 계정이 다시 방문했는지만 확인하면 될 수 있다. 반면 면허가 필요한 서비스를 제공한다면 사용자가 유효한 자격을 갖췄는지 확인해야 한다.

NIST의 디지털 신원 지침도 신원확인, 인증, 연합 신원을 구분하고, 서비스의 위험에 맞는 보증 수준을 선택하도록 설명한다. 이 지침은 미국 정부 정보시스템을 주된 대상으로 하지만 개념을 구분하는 데 유용하다. NIST SP 800-63-4

중요한 설계 질문은 다음과 같다.

이 서비스는 사용자의 무엇을, 어느 정도 확실하게 알아야 할까?

2. 식별·신원확인·인증·인가는 서로 다르다

한국어에서는 여러 과정을 모두 ‘인증’이라고 부르는 경우가 많다. 하지만 시스템을 설계할 때는 구분하는 편이 정확하다.

위 표는 개념을 이해하기 위한 구분이다. 실제 제품의 용어와 절차는 다를 수 있다.

신원확인: 증거와 사람을 연결하는 과정

신분증 이미지 한 장을 받았다고 신원확인이 완료되지는 않는다.

신청자가 주장하는 신원을 구분하고, 제출된 증거가 유효한지 확인하며, 신청자가 그 증거의 정당한 소유자인지도 연결해야 한다.

NIST는 이를 resolution, validation, verification으로 나누어 설명한다. 문서가 진짜인지 확인하는 일과 그 문서를 제출한 사람이 실제 주인인지 확인하는 일은 별개다. NIST SP 800-63A-4

인증: 등록된 인증 수단의 통제를 확인하는 과정

로그인 인증에서는 비밀번호, 보안키, 패스키 등 계정에 연결된 인증 수단을 확인한다.

여기서 인증이 강력하더라도, 최초에 계정과 현실의 인물을 연결하는 절차가 약했다면 그 문제가 자동으로 해결되지는 않는다. 반대로 처음 신원을 철저히 확인했어도 로그인 수단이 탈취되면 계정이 악용될 수 있다. NIST SP 800-63B-4

예를 들어 실명확인을 하지 않는 서비스에서 패스키로 계정을 만들 수 있다. 패스키는 안전한 계정 접근을 지원하지만, 그 계정의 실명까지 새로 증명하는 것은 아니다.

인가: 인증 이후에도 남는 판단

직원 계정으로 로그인했다고 모든 회사 문서에 접근할 수 있는 것은 아니다.

직원이라는 사실과 급여 정보를 열람할 권한은 구분해야 한다. 따라서 시스템에는 신원과 인증 결과를 바탕으로 접근 권한을 결정하는 정책이 필요하다.

3. 디지털 신원은 어떻게 전달될까?

신원정보를 다루는 구조는 하나만 존재하지 않는다. 다음 세 가지 방식으로 나누어 보면 이해하기 쉽다.

서비스가 직접 관리하는 방식

서비스가 계정과 인증 수단을 직접 관리한다.

사용자 → 서비스 로그인 → 서비스가 인증

다른 신원 제공자의 인증 결과를 사용하는 방식

사용자가 외부 신원 제공자에서 인증하고, 서비스는 그 결과를 받아들인다.

사용자 → 신원 제공자에서 인증
                    ↓
             서비스가 결과 수신

이런 연합 신원 구조에서 널리 쓰이는 기술이 OpenID Connect, 즉 OIDC다. OIDC는 OAuth 2.0을 기반으로 사용자 인증과 사용자 관련 주장인 클레임을 전달하는 규격이다.

다만 OIDC를 사용한다는 사실만으로 법적 실명이 확인됐다는 뜻은 아니다. 전달된 정보와 신원 제공자의 확인 절차를 함께 봐야 한다. OpenID Connect Core

사용자가 자격증명을 보관하고 제출하는 방식

발급기관이 만든 자격증명을 사용자가 보관하고, 필요한 서비스에 제시한다.

발급기관 → 사용자에게 자격증명 발급
                        ↓
                 사용자가 서비스에 제출

이 구조를 이해하는 데 필요한 개념이 검증 가능한 자격증명과 디지털 지갑이다.

세 방식은 실제 서비스에서 함께 사용될 수도 있다. 지갑으로 자격을 제출한 뒤 서비스 계정에 연결하고, 이후에는 패스키로 로그인하는 구성을 생각할 수 있다.

4. DID는 무엇을 해결할까?

DID는 Decentralized Identifier, 분산 식별자를 뜻한다.

형태는 다음과 같다.

did:example:123456789abcdefghi

설명용 예시이며, 세 부분으로 구성된다.

did : method : method-specific identifier

여기서 메서드는 식별자를 생성하고 해석하는 구체적인 방식을 정한다.

DID는 DID 문서와 연결되며, 문서에는 공개키 등 검증에 필요한 정보나 서비스 엔드포인트가 포함될 수 있다. 이를 통해 식별자와 관련된 암호학적 증명을 확인할 수 있다. W3C DID Core

DID를 만들었다고 실명이 증명되지는 않는다

어떤 사람이 DID를 만들고 관련 키로 서명했다고 가정하자.

그 증명으로 확인할 수 있는 것은 해당 식별자에 연결된 키를 통제한다는 사실이다. 이름, 학위, 재직 여부 같은 현실의 속성은 별도의 근거가 필요하다.

또한 DID 표준은 특정 블록체인을 필수로 요구하지 않는다. 저장·해석·키 변경·복구 방식은 메서드에 따라 달라진다. 식별자의 통제를 분산하는 것과 자격을 판단하는 기관의 역할을 없애는 것도 서로 다른 문제다. W3C DID Core

5. VC는 ‘누가 무엇을 증명했는지’를 표현한다

VC는 Verifiable Credential, 검증 가능한 자격증명이다.

발급기관의 주장을 기계가 처리하고 암호학적으로 검증할 수 있도록 표현한다. 예를 들어 대학은 어떤 사람이 해당 대학의 졸업생이라고 증명할 수 있다.

W3C의 VC 모델에는 세 가지 주요 역할이 있다.

보유자와 자격증명의 대상은 이 예시에서는 같지만, 항상 같아야 하는 것은 아니다. W3C VC Data Model 2.0

서명이 맞아도 내용까지 자동으로 참이 되지는 않는다

누구나 자신이 만든 문서에 서명할 수 있다. 따라서 서명 검증에 성공했다는 사실만으로 그 발급자가 대학이거나 면허 발급 권한을 가진 기관이라고 판단할 수는 없다.

검증자는 발급자를 신뢰할 근거와 해당 자격을 발급할 권한을 확인해야 한다. 적용되는 유효기간·상태 정보와 서비스 정책도 함께 검토해야 한다.

W3C 표준도 검증 가능성이 내부 주장의 진실성을 뜻하지 않는다고 명시한다. 암호학적 검증과 업무상 신뢰 판단이 함께 필요하다. W3C VC의 신뢰 모델

6. 디지털 지갑은 어떤 역할을 할까?

디지털 신원 지갑은 자격증명을 보관하고 제출하는 사용자 인터페이스가 될 수 있다.

학교에서 받은 재학 증명, 기관에서 받은 자격 증명 등을 보관하고, 서비스가 요청한 정보를 확인한 뒤 제출하는 방식이다. 교육·고용 등 다양한 활용 사례가 W3C 문서에도 정리돼 있다. W3C VC Use Cases

단순히 문서 이미지를 저장하는 것보다 중요한 기능은 요청과 제출의 맥락을 처리하는 일이다.

예를 들어 학생 할인 서비스라면 다음 흐름을 설계할 수 있다.

서비스: 학생 자격 증명 요청
           ↓
지갑: 요청 기관과 제출할 정보 표시
           ↓
사용자: 제출 내용 확인
           ↓
지갑: 요청에 맞는 증명 제출
           ↓
서비스: 검증 후 할인 정책 적용

이는 이해를 위한 예시다. 구체적인 절차는 지갑과 자격증명 형식에 따라 달라진다.

자격증명과 제출 프로토콜도 구분해야 한다

문서 형식을 정했다고 안전한 제출 절차까지 완성되는 것은 아니다.

검증 요청의 대상, 제출받을 서비스, 일회성 값인 nonce 등을 적절히 연결해야 과거 응답을 재사용하는 공격 등을 방어할 수 있다. OpenID for Verifiable Presentations는 이런 자격증명 요청·제출을 다루는 프로토콜이다. OpenID4VP 1.0

복사한 파일이나 캡처 화면을 보여주는 것과, 현재 요청에 연결된 증명을 제출하는 것은 다르다.

7. 개인정보를 덜 공개하면서 증명할 수 있을까?

서비스에 필요한 정보가 “특정 연령 이상인가?”라면 전체 생년월일과 주소까지 전달할 필요는 없을 수 있다.

학생 할인도 이름·학번·학과를 모두 수집하기보다 유효한 학생 자격만 확인하는 방향을 고려할 수 있다.

이때 구분해야 할 개념이 있다.

선택적 공개와 조건 충족 증명은 기술적으로 같은 기능이 아니다. 예를 들어 발급기관이 처음부터 ‘특정 연령 이상’이라는 속성을 발급하는 방법과, 생년월일을 숨긴 채 계산 결과를 증명하는 방법은 다르다.

또한 VC나 지갑이라는 이름만으로 이런 기능이 자동 제공되지는 않는다. 사용하는 형식과 암호 기술, 발급·제출 방식에 맞춰 구현해야 한다.

개인정보 보호를 설계할 때는 공개하는 항목뿐 아니라 반복 사용되는 식별자와 제출 메타데이터도 살펴봐야 한다. W3C 역시 데이터 최소화와 정보의 결합을 통한 추적 위험을 다룬다. W3C VC 개인정보 보호 고려사항

8. eIDAS 2.0은 기술을 제도적 신뢰와 연결한다

DID와 VC가 기술적 구성 요소라면, eIDAS 2.0은 전자 신원과 신뢰서비스에 관한 유럽의 법적·제도적 체계다.

일반적으로 eIDAS 2.0이라고 부르는 개정 체계는 기존 eIDAS를 확장하며, 핵심 요소 중 하나로 European Digital Identity Wallet, EUDI Wallet을 도입한다.

목표는 회원국이 제공하는 디지털 신원을 바탕으로 국경을 넘는 공공·민간 서비스 이용과 속성 증명을 지원하는 것이다. EU 집행위원회: EUDI Regulation

하나의 유럽 계정으로 통합하는 구상일까?

EU 집행위원회는 각국의 디지털 신원을 하나로 대체하는 것이 목적은 아니라고 설명한다. 회원국의 신원 체계를 바탕으로 지갑의 기능과 상호운용성을 확장하는 접근이다.

사용자 이용은 자발적이라는 원칙도 중요하다. EU 집행위원회 공식 Q&A

도입 일정은 어떻게 봐야 할까?

2026년 10월 16일 기준, EU 집행위원회는 회원국이 2026년 말까지 지갑을 제공하도록 하는 일정을 안내한다. 이 일정만으로 모든 국가와 민간 서비스가 이미 동일한 수준으로 운영 중이라고 판단해서는 안 된다. EU 공식 도입 일정

또한 DID 구현이나 W3C VC 형식을 사용한다는 사실만으로 eIDAS의 법적 효력이 자동으로 부여되지는 않는다. 기술 규격 준수와 법적 요건 충족은 각각 확인해야 한다.

9. 전체 구조를 한 번에 연결해 보기

지금까지의 개념은 다음처럼 배치할 수 있다.

이 표는 구성 요소의 역할을 구분한 것이다. 모든 디지털 신원 시스템이 DID나 VC를 반드시 사용해야 한다는 뜻은 아니다.

예를 들어 대학이 학생 자격을 발급하는 서비스를 설계한다면 다음 질문이 이어진다.

1. 대학은 어떤 근거로 학생을 확인하는가?
2. 발급받는 지갑을 학생과 어떻게 연결하는가?
3. 할인 서비스는 그 대학을 왜 신뢰하는가?
4. 졸업이나 휴학 이후의 자격 변화를 어떻게 반영하는가?
5. 제출 과정에서 불필요한 개인정보가 노출되지 않는가?
6. 휴대전화를 잃었을 때 어떻게 복구하는가?

형식과 서명이 올바른지만으로 답할 수 없는 문제들이다.

10. 개발자가 실제로 설계해야 하는 부분

디지털 신원 기능을 구현할 때는 다음 세 가지를 먼저 구체화하면 좋다.

무엇을 확인할 것인가?

실명이 필요한지, 같은 계정인지 확인하면 되는지, 특정 자격만 있으면 되는지 정한다.

학생 할인 기능에 금융 서비스와 같은 수준의 정보를 요구해야 하는지는 따로 검토할 문제다.

누구의 증명을 인정할 것인가?

허용할 발급기관과 자격의 범위, 유효기간, 상태 확인 정책을 정한다.

같은 형식의 문서를 읽을 수 있어도 발급기관의 의미와 신뢰 기준이 다르면 상호운용이 완성되지 않는다.

실패와 복구를 어떻게 처리할 것인가?

정상적인 발급·제출 흐름과 함께 운영 시나리오를 설계한다.

• 기기 분실과 인증 수단 변경
• 자격 만료·철회·재발급
• 상태 조회 서비스 장애
• 잘못 발급된 정보의 정정
• 스마트폰 사용이 어려운 사람의 대체 경로

특히 복구 과정이 기존 통제보다 약하면 공격자가 그 경로를 이용할 수 있다. 신원확인과 인증을 설계할 때부터 복구와 예외 처리를 함께 고려해야 한다. NIST 인증 수단 생애주기 지침

디지털 신원 시스템의 품질은 필요한 사실을 얼마나 적절하게 증명하고, 그 증명을 안전하게 사용하며, 문제가 생겼을 때 회복할 수 있는지에서 드러난다.

참고 자료

• NIST — Digital Identity Guidelines
• W3C — Decentralized Identifiers v1.0
• W3C — Verifiable Credentials Data Model v2.0
• OpenID Foundation — OpenID for Verifiable Presentations 1.0
• European Commission — European Digital Identity Regulation