DOI, 디지털 객체에 영구 식별자를 부여하는 방법
DOI 체계의 식별자 구조와 해석 인프라, 등록기관의 역할을 정리하고 학술출판·연구데이터·소프트웨어 아카이브에서 실제로 쓰이는 방식을 설명한다.
2026-08-13 · 최초 발행 2025-11-26
DOI란 무엇인가
디지털 학술 생태계에서 논문·데이터셋·소프트웨어 같은 연구 산출물은 저장 위치가 바뀌는 일이 흔하다. DOI(Digital Object Identifier)는 이런 객체에 위치와 무관한 영구 식별자를 부여하는 체계로, ISO 26324 표준을 기반으로 한다. 식별자는 10.prefix/suffix 형식을 따르며(예: 10.1234/abcd-2025), prefix는 등록기관이나 소속을 가리키고 suffix는 리소스 하나를 구분한다.
핵심 설계는 식별자 자체의 지속성과 실제 위치 해석을 분리한 데 있다. 대상 파일의 위치가 바뀌어도 DOI 자체는 바뀌지 않고, doi.org 리졸버와 Handle System이 최신 랜딩 페이지로 연결해준다. 이 해석 과정을 실제로 수행하고 메타데이터 스키마 검증·등록·갱신을 담당하는 곳이 Crossref·DataCite 같은 등록 대행기관(Registration Agency)이다.
콘텐츠 발행자가 메타데이터(제목·저자·발행처·URL·라이선스 등)를 등록기관에 제출하면 스키마 검증을 거쳐 DOI가 발급되고, Handle System에 레코드가 생성된 뒤 doi.org 리졸버에 동기화된다. 이용자나 크롤러가 https://doi.org/10.xxxx/yyy 형태의 링크에 접근하면 이 리졸버가 최신 랜딩 페이지로 요청을 넘긴다. 랜딩 페이지가 404 등의 오류를 반환하면 운영자 알림이나 자동 모니터링이 발동해 URL 교체나 메타데이터 갱신으로 이어진다.
식별자 구조와 해석 인프라
prefix/suffix로 나뉜 구조는 조직별 관리와 리소스별 고유성을 동시에 만족시키도록 설계됐다. 등록기관 레벨에서 유효성 검증이 내장돼 있어 충돌을 방지하고, 위치와 무관한 식별자 설계 덕분에 링크가 끊기거나(link rot) 콘텐츠가 사라지는(content drift) 위험이 줄어든다.
해석 인프라는 Handle System 기반의 분산 해석과 doi.org의 글로벌 리졸버로 구성된다. DNS·HTTPS 캐시로 가용성을 최적화하고, 대용량 트래픽에는 Anycast·프록시 구조로 대응하며 장애 시 대체 경로를 둔다.
메타데이터 거버넌스와 세분화 전략
DOI는 Crossref·DataCite 스키마를 따르며 필수·권고 필드를 구분하고 스키마 버전을 관리한다. ORCID·ROR·Grant ID 같은 다른 식별자와 연계할 수 있고, DOI Foundation과 등록기관의 정책에 따라 변경 이력, 정정(Correction), 철회(Retraction) 모델을 지원한다.
세분화(granularity) 정책도 도입 시 결정해야 할 부분이다. 아티클·챕터·피겨·데이터 파일 단위로 DOI를 나눌 수 있고, 버전마다 새 DOI를 부여할지(버전 DOI) 하나의 DOI를 유지할지(버전리스 DOI)를 선택한다. 정정판이나 보정 데이터 같은 파생물은 IsSupplementTo 같은 RelationType 메타데이터로 원본과의 관계를 추적한다. 과도한 세분화는 관리 복잡도를 높이고, 반대로 지나치게 세분화하지 않으면 인용·재현성이 떨어지므로 도메인 특성에 맞는 granularity 정책 설계가 필요하다.
운영 측면에서는 메타데이터 업데이트 API, 이벤트 데이터(Webhooks), 클릭스루·해석 통계를 제공하며, SLA 준수와 메타데이터 품질 점검 리포트로 감사 가능성을 확보한다.
DOI와 유사 식별 체계 비교
| 항목 | DOI | URL | Handle | ARK | ISBN |
|---|---|---|---|---|---|
| 성능(해석 지연) | 낮은 지연, 글로벌 캐시 | 가변, 호스트 의존 | 낮은 지연 | 가변, 구현 의존 | 무관(해석 미제공) |
| 확장성 | 매우 높음, 분산 RA | 도메인/인프라 의존 | 높음 | 높음 | 부여는 높음, 해석 없음 |
| 일관성(메타데이터) | 강함, 표준 스키마 | 약함 | 중간 | 중간 | 서지 중심, 제한적 |
| 안정성(링크 지속) | 높음, 위치 독립 | 낮음, 링크 부패 빈번 | 중간 | 중간~높음 | 식별은 지속, URL 연결 부재 |
| 운영 편의 | RA 지원, 도구 풍부 | 간단하나 유지 부담 | 기술 전문성 필요 | 정책 수립 필요 | 발급 용이, 디지털 연계 약함 |
구체적인 지표와 가용성 수치는 운영 환경에 따라 달라진다.
실무에서 DOI를 쓰는 방식
학술 출판사·저널은 투고가 확정되면 레이아웃을 생산하고 메타데이터를 생성해 Crossref에 등록한 뒤 DOI를 반영·배포하는 순서로 움직인다. 운영 시에는 최종 랜딩 페이지 URL을 유지하고, 정정·철회가 발생하면 상태 메타데이터를 갱신하며, 참고문헌에 DOI를 우선 표시한다.
연구데이터 저장소나 대학 도서관은 데이터를 패키징한 뒤 DataCite 스키마에 매핑해 DOI를 발급하고, 버전·하위 파일 간 관계를 설정한다. 라이선스와 거버넌스를 명시하고, 장기 보존 정책에 따라 스토리지를 마이그레이션할 때는 URL만 교체한다.
소프트웨어·코드 아카이브는 GitHub와 Zenodo를 연동해 릴리스 태그마다 버전 DOI를 자동 발급하고, CITATION.cff 같은 소프트웨어 인용 모범사례와 연계한다. 메이저 릴리스마다 버전 DOI를 발급하되, 프로젝트 루트에는 개념 DOI(concept DOI)를 병행해 제공한다.
도입할 때 고려할 것
랜딩 페이지의 지속 가능성부터 확보해야 한다. HTTP 200을 유지하고, 메타태그에 DOI·메타데이터를 노출하며, 콘텐츠를 교체할 때는 리디렉션을 관리한다. ORCID·ROR·Grant ID 같은 외부 식별자를 연계하고 참고문헌에는 https://doi.org/… 형태로 표준화된 DOI를 표기한다. 해석 실패를 감지하고 URL 교체를 자동화하며 메타데이터 결측 필드를 주기적으로 보완하는 모니터링 체계도 필요하다.
다만 발급·유지에는 비용과 조직적 프로세스가 따른다. RA 정책을 준수하려면 운영 규율이 필요하고, 대상 범위·세분화·버전 정책을 먼저 정의한 뒤 등록기관 계정을 만들고 테스트 샌드박스에서 스키마를 검증하는 순서로 진행하는 편이 안전하다. CMS나 리포지터리에 메타데이터·등록 API를 연동하고 배포 파이프라인에 DOI 발급 단계를 넣은 다음에는, 주기적인 링크 체크와 실패 시 자동 티켓 생성, 변경 이력 리포트 검토로 운영을 이어간다.