# DID에 관해 너무 많은 이야기

> Clean Markdown view of GeekNews topic #31460. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31460](https://news.hada.io/topic?id=31460)
- GeekNews Markdown: [https://news.hada.io/topic/31460.md](https://news.hada.io/topic/31460.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-15T20:02:10+09:00
- Updated: 2026-07-15T20:02:10+09:00
- Original source: [steveklabnik.com](https://steveklabnik.com/writing/too-many-words-about-dids/)
- Points: 1
- Comments: 1

## Topic Body

- Bluesky 계정은 특정 앱에 묶이지 않고 atproto 기반의 여러 앱에서 사용할 수 있으며, **DID(탈중앙 식별자)** 가 앱과 분리된 신원 확인 기반을 제공함
- DID는 `did:<method>:<identifier>` 형식이며, DID Document에 담긴 **공개 키와 PDS 위치**를 이용해 게시물 작성자와 계정의 연관성을 검증함
- `did:web`은 도메인의 `/.well-known/did.json`을 조회하는 단순한 방식이지만, **DNS·등록기관 의존성**과 웹 서버 중단, 문서 변경 반영 지연에 취약함
- Bluesky가 만든 `did:plc`는 ID를 특정 도메인에서 분리하고 `plc.directory`가 운영 부담을 맡지만, DNS 대신 **`plc.directory`를 신뢰**해야 하며 Bluesky에서는 블록체인 기반 DID 방식 등을 사용할 수 없음
- 사용자는 추가 키 등록과 키 순환, 자체 PDS 운영을 통해 Bluesky가 만든 키를 제거하고 **신원을 실질적으로 직접 통제**할 수 있으며, 복잡한 키 관리를 모두에게 강제하지 않고 원하는 사람에게 선택권을 제공함

---

### Bluesky 계정과 DID 기반 신원
- “Bluesky 계정”은 Bluesky에서만 쓰는 계정이 아니라 **ATmosphere의 여러 애플리케이션**에서 사용할 수 있는 계정임
- Bluesky와 다른 앱의 기반 프로토콜인 atproto는 사용자가 누구인지 나타내고 로그인이나 게시물 작성자를 확인하기 위해 **DID**를 사용함
- [W3C가 2022년에 표준화한 DID](https://www.w3.org/TR/did-1.0/)는 애플리케이션에서 신원의 기반으로 사용할 수 있는 탈중앙 식별자임
- DID의 탈중앙성은 단일 기관이 유효한 DID 유형을 결정하는 대신, 사용자가 자신의 신원을 검증할 **DID 메서드**를 선택할 수 있다는 데 있음
- 다만 애플리케이션이 모든 DID 메서드를 자동으로 처리하지는 못함
  - 메서드마다 지원 코드를 별도로 구현해야 함
  - 앱이 `foo` 메서드를 지원하지 않으면 `did:foo:1243`을 제시해도 해석할 수 없음

### DID와 DID Document
- 예시 DID `did:plc:3danwc67lo7obz2fmdg6jxcr`은 콜론으로 구분된 세 부분으로 구성됨
  - 스킴: `did`
  - 메서드: `plc`
  - 메서드별 식별자: `3danwc67lo7obz2fmdg6jxcr`
- DID를 사용하려면 이를 [DID Document](https://www.w3.org/TR/did-1.0/#dfn-did-documents)로 해석해야 함
- DID Document는 DID 주체나 위임자가 자신을 인증하고 해당 DID와의 연관성을 증명할 수 있도록 **암호학적 공개 키 등의 데이터**를 담음
- 예시 문서에는 신원 검증에 필요한 정보가 포함됨
  - `id`: DID 자체
  - `alsoKnownAs`: `at://steveklabnik.com`
  - `verificationMethod`: `Multikey` 유형과 `publicKeyMultibase`
  - `service`: `AtprotoPersonalDataServer` 유형의 **PDS 엔드포인트**
- 임의의 게시물이 특정 사용자가 작성했다고 주장할 때, 문서의 검증 정보를 이용해 해당 주장의 진위를 확인할 수 있음
- DID를 문서로 해석하는 절차는 메서드별 표준이 정함
  - `did:plc`는 PLC 표준을 따름
  - Bluesky가 지원하는 또 다른 방식인 `did:web`은 Web 방식으로 해석함

### `did:web`의 해석 방식
- `did:web`을 사용하는 사람은 매우 적지만 구조가 단순해 DID 해석 과정을 이해하기 쉬움
- Liz Fong-Jones의 `did:web:lizthegrey.com`은 메서드별 식별자인 `lizthegrey.com`을 다음 URL 템플릿에 넣어 해석함

```text
https://<id>/.well-known/did.json
```

- 해당 URL에서 받은 DID Document에는 다음 정보가 담김
  - `id`: `did:web:lizthegrey.com`
  - `alsoKnownAs`: `at://web.lizthegrey.com`, `did:plc:i4tfenpfog244rxry5uz4vtk`
  - `verificationMethod`: atproto용 **Multikey 공개 키**
  - `serviceEndpoint`: `https://pds.lizthegrey.com`

### `did:web`이 안고 있는 제약
- `did:web`은 **DNS와 도메인 등록기관**에 의존함
  - 등록기관이 도메인을 회수하면 DID 통제권도 잃음
  - 도메인을 더 이상 사용하지 않거나 만료 후 다른 사람이 구매해도 신원을 잃을 수 있음
  - 등록기관 계정이 해킹돼 도메인을 탈취당하는 경우도 마찬가지임
- DID Document를 제공하는 웹 서버를 계속 실행해야 하며, 서버가 중단되면 문서도 가져올 수 없음
- DID Document 변경 사실을 클라이언트에 즉시 알릴 방법도 없음
  - 애플리케이션이 오래된 문서를 계속 사용할 수 있음
  - 문서 갱신과 애플리케이션 반영 사이의 지연으로 최신 문서를 다시 가져올 때까지 일시적인 문제가 생길 수 있음

### `did:plc`가 바꾸는 신원 유지 방식
- Bluesky는 `did:web`의 문제를 줄이기 위해 [`did:plc`](https://web.plc.directory/spec/v0.1/did-plc)를 개발함
- `did:plc`는 전체 DID를 다음 URL 템플릿에 넣어 DID Document를 가져옴

```text
https://plc.directory/<did>
```

- URL을 조회한다는 점은 `did:web`과 같지만, 운영과 신원 유지 방식이 다름
  - DID가 특정 도메인에 묶이지 않아 `steveklabnik.com`을 만료시키고 `steve.klabnik.com`으로 옮겨도 **동일한 DID**를 유지할 수 있음
  - 웹 서버 운영은 사용자 대신 `plc.directory`가 맡으므로 운영 부담이 줄어듦
- 신뢰 대상 자체가 사라지는 것은 아님
  - `did:web`에서는 DNS와 도메인 등록기관을 신뢰해야 함
  - `did:plc`에서는 `plc.directory`가 ID를 빼앗지 않고 탈취당하지 않을 것이라고 신뢰해야 함
- DNS와 `plc.directory` 모두 신뢰할 수 없다고 보는 사용자는 블록체인 등으로 이름을 해석하는 다른 DID 메서드를 선택할 수 있음
- 그러나 Bluesky가 이런 메서드를 지원하지 않으므로 **Bluesky 애플리케이션에서는 사용할 수 없음**

### 접근성 문제와 새로운 DID 방식
- `did:web`을 직접 설정하려면 비전문 사용자에게 부담스러운 작업이 필요함
  - 도메인을 등록하고 지속적으로 비용을 지불해야 함
  - 웹 서버를 설정하고 DID Document용 JSON을 작성해야 함
  - 서버를 계속 가동해야 함
  - 개인 키를 저장하고 안전하게 관리해야 함
- 이 과정은 일반적인 웹 앱 가입보다 훨씬 복잡해, 비전문 사용자도 플랫폼을 이용하게 하려는 Bluesky의 목표와 맞지 않음
- `plc.directory`가 관련 작업을 관리하면 사용자가 이 단계를 직접 수행하지 않아도 됨
- [`did:webvh`](https://identity.foundation/didwebvh/v1.0/)는 `did:web`을 확장해 일부 단점을 보완하려는 방식으로 **1.0에 도달**했지만, 구체적인 명세까지 비교 대상에 포함되지는 않음

### Bluesky에서 신원을 직접 소유하는 방법
- 기본 설정에서는 Bluesky가 사용자의 키 쌍을 생성하고 **비밀 키에 접근**할 수 있으므로, 어떤 의미에서는 Bluesky가 신원을 소유한다고 볼 수 있음
- `did:plc`는 ID에 추가 키 쌍을 등록하고 서명 키를 순환할 수 있음
  - Bluesky가 생성한 키를 제거할 수 있음
  - 사용자가 직접 만든 키로 교체할 수 있음
- 키를 바꾸는 것만으로 Bluesky 인프라와 완전히 분리되지는 않음
  - PDS가 게시물에 서명하려면 사용자의 키를 사용해야 함
  - Bluesky 관리형 PDS를 사용하면 일반적으로 키가 Bluesky 인프라에 저장됨
- Bluesky와 신원을 분리하려면 **자체 PDS를 운영한 뒤 키를 순환**해야 함
  - 키가 사용자가 소유한 인프라에 저장됨
  - 이후 Bluesky는 해당 키를 통제하지 못함
- 대부분의 사용자가 자체 PDS와 키 관리를 선택하지 않더라도, 동기가 있는 사용자가 신원을 실질적으로 소유할 수 있다는 점은 중요한 설계 속성임
- 모든 사용자에게 직접 키 관리를 강제하기보다 원하는 사용자가 선택할 수 있게 하는 방식이 대부분의 사용자에게 적절함

## Comments



### Comment 61869

- Author: neo
- Created: 2026-07-15T20:02:11+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/86lwsv/too_many_words_about_dids) 
- plc.directory는 처음에는 Bluesky가 통제했지만, 현재 **스위스 비영리단체**로 독립하는 절차를 밟고 있음
- 솔직히 DID는 대형 기술 기업의 통합 인증(SSO)보다 나은 해법이다. 다만 `did:plc:`처럼 일반인도 쓸 수 있어야 하며, 비영리단체 소유라도 **중앙 기관을 완전히 신뢰**할지는 고민해야 함  
  Keybase를 재구현하면서 W3C DID와 W3C 검증 가능 자격증명(VC)을 지원하는 프로젝트를 개발 중이다. 인간임을 고유하면서도 비공개로 증명하고, 자신이 통제하는 **탈중앙화 신원**을 갖게 하는 것이 목표다
  - 혹시 **FOKS**를 개발 중인가, 아니면 다른 프로젝트인가?  
    https://foks.pub/
- 제목만 보고 [DID 명세](https://www.w3.org/TR/did-1.1/)로 연결될 줄 알았는데, 실제 글도 짧고 유익함
  - 글의 첫 번째 링크가 바로 **명세 링크**임
- 오늘 알게 된 사실: DID는 **Docker in Docker**가 아니었음
  - Docker in Docker를 DID로 읽을 수도 있다는 걸 처음 알았다. 늘 **DinD** 또는 더 헷갈리는 `dind`로 줄여 들었는데, 직장 내 관행인지 일반적인 표기인지는 모르겠음
  - **Direct Inward Dialing**을 뜻하는 것도 아님
- Bluesky를 사용하지 않는 독자를 위해 **PDS**가 무엇인지 정의해 줄 수 있나?
  - PDS는 **Personal Data Server**로, 게시물 같은 콘텐츠의 원본 서버를 뜻함
  - Bluesky/AT는 모든 사용자의 게시물을 단일 대형 데이터베이스에 넣는 대신, 각 사용자가 PDS라는 **개별 데이터 저장소**를 갖는 구조다. Bluesky가 제공하는 PDS를 쓰거나 직접 호스팅하거나 제3자 서비스를 이용할 수 있고, 계정 이력 전체를 유지한 채 PDS 사이를 투명하게 이전할 수도 있음  
    Mastodon의 인스턴스와는 같지 않으며, AT와 ActivityPub의 개념은 일대일로 깔끔하게 대응하지 않음
- `did:web`은 `.well-known` 서버를 호스팅해야 하고 데이터도 거의 정적이라면, 왜 TXT 레코드처럼 URL과 비슷하게 읽을 수 있고 캐시될 가능성이 높으며 우발적으로 중단될 가능성은 낮은 **DNS를 직접 사용**하지 않는가?  
  DNS 의존성과 `did.json` 갱신을 쉽게 감지할 수 없다는 문제는 남지만, 특정 도메인을 개인의 신원과 연결하려는 목적이라면 구성 요소를 최소화하고 DNS 기능에 직접 연결하는 편이 나아 보인다. 이 방식이 작동하지 않거나 현실적으로 어려운 이유가 있는지 궁금함
  - 알기로는 **TXT 레코드의 최대 크기가 255바이트**라서 DID 문서 전체를 담기 어려울 듯하다  
    다만 실제 제약은 조금 더 복잡함: https://news.ycombinator.com/item?id=38419272  
    `did:dns` 제안 또는 초안도 두 개 찾을 수 있음: https://danubetech.github.io/did-method-dns/ 및 https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-01