Open Badge v2 vs v3 완벽 정리: 오늘 어떤 스펙을 써야 할까요?

2026년에 자격 인증 프로그램을 구축하다 보면, 조사를 시작한 지 한 시간도 안 돼서 이 질문과 마주치게 돼요. Open Badge v2.0을 발급해야 할까요, 아니면 더 새로운 v3.0을 발급해야 할까요? 솔직한 답은 “당신의 자격증을 누가 읽어야 하느냐에 달려 있다”예요 — 하지만 금요일까지 결정을 내려야 하는 입장이라면 이 답으로는 충분하지 않죠. 그러니 두 스펙 사이에 실제로 뭐가 달라졌는지, 오늘 누가 뭘 지원하는지, 그리고 지금 대부분의 발급자가 어떤 걸 선택해야 하는지 하나씩 짚어볼게요.

Open Badge v2.0이 실제로 무엇인가요

Open Badge v2.0은 1EdTech(예전 이름은 IMS Global)가 만든 스펙으로, 2017년부터 디지털 배지 생태계의 근간이 되어 왔어요. JSON-LD 위에 만들어졌고, 서로 연결된 세 가지 객체를 중심으로 구조화되어 있어요.

• IssuerOrg — 누가 이 자격증을 발급했는지 (이름, URL, 이메일, 로고)
• BadgeClass — 자격증 유형 자체 (이름, 설명, 기준, 이미지)
• Assertion — 특정 수신자에게 부여된 구체적인 수여 기록 (수신자 신원, issuedOn 날짜, 증빙, 검증 방식)

수신자의 Assertion은 BadgeClass를 가리키고, BadgeClass는 다시 IssuerOrg를 가리켜요. 검증은 두 가지 방식으로 이뤄져요. hosted(검증자가 안정적인 URL에서 실시간으로 Assertion JSON을 가져와서 해당 도메인을 신뢰하는 방식)와 signed(Assertion에 JWS 서명이 담겨 있고, 검증자가 발급자가 공개한 공개 키로 이를 대조하는 방식)예요. badges.ninja를 포함한 대부분의 플랫폼은 기본값으로 hosted 검증을 쓰고 signed는 선택 옵션으로 제공해요. hosted가 구현하기 더 간단하고, 사람이 눈으로 확인하기도 더 쉽기 때문이에요.

GET /awards/{id} 호출로 받을 법한, 축약된 v2.0 Assertion 예시를 볼게요.

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://badges.ninja/certify-badge/award/9f2a1c...",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "a1b2c3",
    "identity": "sha256$8f14e45..."
  },
  "badge": "https://badges.ninja/certify-badge/badge/7d3e...",
  "issuedOn": "2026-08-01T00:00:00Z",
  "verification": { "type": "hosted" }
}

이 구조 덕분에 v2.0이 사실상의 표준이 됐어요. 반나절이면 구현할 수 있을 만큼 단순하고, 배지 데이터를 다루는 거의 모든 소비자가 당연히 기대하는 형태이기도 해요.

v2.0의 hosted 검증 vs signed 검증

v2.0 내부에 있는 이 두 검증 모드의 차이를 이해해 둘 필요가 있어요. 사람들이 “v2.0은 v3.0보다 덜 안전하다”라는 얘기와 “hosted 검증은 signed 검증보다 덜 안전하다”라는 얘기를 자주 혼동하기 때문이에요. 이 둘은 서로 다른 축의 이야기예요.

• Hosted — verification.type이 "hosted"이고, Assertion의 id는 실시간으로 접근 가능한 URL이에요. 검증자는 이 URL을 가져와서 응답이 일치하는지 확인하고, 신뢰는 해당 도메인을 통제한다는 사실에서 나와요(예를 들어 badges.ninja/certify-badge/award/...에 게시할 수 있는 건 badges.ninja뿐이에요). 사람이 링크를 클릭하기만 하면 되기 때문에, 소비자 대상 검증 페이지 대부분이 이 방식을 써요.
• Signed — verification.type이 "signed"이고, Assertion은 payload 전체에 대한 JWS 서명을 담거나 참조해요. 검증자는 발급자의 공개 키를 해석해서, 어떤 URL이든 접근 가능한지와 무관하게 서명을 검증해요. 이건 DID 계층만 빠졌을 뿐, 정신적으로는 v3.0 모델에 더 가까워요.

Node에서 최소한의 signed 검증 코드는 이런 모습이에요.

import { jwtVerify, importJWK } from 'jose';

const publicKey = await importJWK(issuerJwk, 'RS256');
const { payload } = await jwtVerify(assertionJws, publicKey);
// payload now contains the verified Assertion claims

API가 유지보수로 오프라인이 된 뒤에도 자격증이 계속 검증 가능하길 원하는 프로그램이라면, DID를 도입하지 않아도 signed 방식의 v2.0만으로 v3.0이 주는 내구성 이점의 대부분을 얻을 수 있어요.

Open Badge v3.0은 무엇을 바꾸나요

Open Badge v3.0은 W3C Verifiable Credentials(VC) Data Model 위에서 다시 쓰인 것으로, v2.0의 JSON-LD 형태를 점진적으로 업데이트한 게 아니에요. 실무에서 중요한 차이는 다음과 같아요.

• 기본적으로 암호화 서명을 적용해요. 모든 v3.0 자격증은 서명된 VC예요 — “hosted, URL을 신뢰하는” 대체 방식은 존재하지 않아요. 검증은 항상 수학적이며, 도메인 기반이 아니에요.
• DID 기반 발급자 신원. URL과 이메일을 가진 IssuerOrg 객체 대신, 발급자는 탈중앙화 식별자(DID)로 식별되고, 이 DID는 공개 키 문서로 해석돼요.
• Comprehensive Learner Record(CLR) 2.0과의 정렬. v3.0은 CLR과 상호운용되도록 설계돼서, 하나의 자격증이 성취 데이터에 더해 CLR 소비자가 기대하는 구조화된 성적 증명서 수준의 세부 정보(역량, 평가 결과, 과목/학기 맥락)까지 담을 수 있어요.
• 디지털 지갑 호환성. v3.0 자격증은 표준 W3C VC이기 때문에, 운전면허증이나 예방접종 증명서처럼 웹 페이지에 표시되는 데 그치지 않고 신원 지갑 안에 보관될 수 있어요.

요약하면, v2.0은 “사람이나 간단한 스크립트가 이 자격증을 검증할 수 있는가”라는 질문에 답하고, v3.0은 “이 자격증이 지갑, DID, 공식 학습 기록 같은 더 넓은 검증 가능 자격증 생태계와 상호운용될 수 있는가”라는 질문에 답해요.

나란히 비교하기

기존 인프라가 여전히 v2.0에서 돌아가는 이유

이 부분이 대부분의 프로그램에서 결정을 좌우해요. 수신자가 실제로 자격증을 보여주고 싶어 하는 곳은 여전히 v2.0을 기대해요. LinkedIn의 Add to Profile 흐름, Credly, Badgr, 그리고 대부분의 지원자 추적 시스템(ATS) 연동은 v2.0의 Assertion/BadgeClass 구조를 파싱해요. 목표가 “수신자가 이걸 LinkedIn에 올리고 채용 담당자가 클릭해서 검증할 수 있는 것”이라면, v2.0은 어쩔 수 없이 갇혀 있는 낡은 포맷이 아니라 지금 생태계가 실제로 쓰는 언어예요.

이 같은 긴장 관계를 수신자 관점에서 LinkedIn Skill Assessments vs Open Badges에서도 다룬 적이 있어요 — 배지의 가치는 채용 담당자와 동료들이 이미 보고 있는 곳에 얼마나 쉽게 녹아드는지에 크게 좌우되는데, 오늘날 그건 압도적으로 v2.0 형태의 인프라예요.

v3.0이 정말로 중요해지는 경우

v3.0은 그냥 유행이 아니에요 — 특정 프로그램에는 실질적인 문제를 해결해줘요.

• CLR 의무를 지는 대학과 발급자. 공식 성적 증명 시스템과 나란히 발급하고 있거나, 주/지역 교육 기관이 CLR 2.0 호환 출력을 요구한다면, v3.0에 내장된 정렬 기능 덕분에 v2.0 Assertion에 CLR 필드를 억지로 끼워 넣지 않아도 돼요.
• 디지털 지갑 저장을 목표로 하는 프로그램. 수신자가 웹 페이지에 표시하는 것만으로는 부족하고 지갑 앱에 자격증을 보관해야 한다면, 그 자리에서 네이티브로 동작하는 건 오직 W3C VC, 즉 v3.0뿐이에요.
• DID 기반 신뢰를 활용한 발급자 간 자격증 교환. 발급자 신원이 “이 URL을 신뢰하라”가 아니라 암호학적으로 이식 가능해야 하는 네트워크를 구축하거나 거기에 합류하는 상황이라면, DID가 올바른 기본 요소예요.

2026년 기준으로 교육 프로그램, 부트캠프, 직무 개발 발급자에게 이런 사례는 흔하지 않아요. 이런 경우는 CLR이나 W3C VC를 명시적으로 요구하는, 규제 준수나 상호운용성 요구사항을 가진 기관에서 흔하죠.

축약된 v3.0 자격증을 보면, 근본적인 성취 데이터가 개념적으로 같은 수여라 해도 겉모습이 얼마나 다른지 알 수 있어요.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "did:web:issuer.example.edu" },
  "credentialSubject": {
    "type": "AchievementSubject",
    "achievement": { "type": "Achievement", "name": "Developer Associate" }
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022" }
}

issuer 필드가 URL이 아니라 DID라는 점, 그리고 문서 전체가 verification 포인터 대신 proof 블록을 담고 있다는 점에 주목하세요. 이게 바로 앞서 말한 DID 해석과 VC 서명 도구예요 — 진짜 엔지니어링 작업이고, 아직 아무도 그걸 소비하지 않는다면 헛수고가 되는 작업이기도 해요.

짚고 넘어갈 만한 흔한 오해들

• “v3.0이 더 안전하다.” 꼭 그런 건 아니에요 — signed v2.0과 v3.0 둘 다 암호학적 검증에 의존해요. v3.0의 강점은 표준화된 신원(DID)과 지갑 상호운용성이지, signed v2.0 대비 보안이 업그레이드된 게 아니에요.
• “v2.0은 폐기됐다.” 아니에요. 1EdTech는 두 스펙을 모두 유지 관리하고 있고, 발급자들이 실제로 매일 쓰는 플랫폼과 연동이 참조하는 버전은 여전히 v2.0이에요.
• “프로그램 전체에서 하나만 골라야 한다.” 그렇지 않아요. 발급자가 일반 용도로 v2.0을 공개하면서, 그걸 요구하는 특정 파트너 연동을 위해 v3.0 출력을 추가하는 걸 막는 건 아무것도 없어요 — 근본적인 수여 데이터는 바뀌지 않고, 표현 방식만 달라져요.

마이그레이션 경로 (그리고 영원히 하나만 고를 필요가 없는 이유)

거의 모든 발급자에게 현실적인 방법은 이거예요. 지금은 v2.0을 출시하고, 특정 다운스트림 소비자가 실제로 요구할 때 v3.0을 대체가 아니라 추가로 취급하세요. 이 방식이 매끄럽게 작동하는 이유가 몇 가지 있어요.

1. 나중에 v3.0 지원을 추가할 때도 BadgeClass와 Assertion의 ID를 바꿀 필요가 없어요 — 기존 수신자의 자격증을 마이그레이션하는 게 아니라, 같은 근본적인 수여에 대해 형태가 다른 두 번째 표현을 추가하는 것뿐이니까요.
2. v2.0만 이해하는 검증자들은 예전과 똑같이 계속 잘 작동해요.
3. 구체적인 요구사항이 생기기도 전에 DID 인프라와 VC 서명 파이프라인을 구축하는 일을 피할 수 있어요.

이건 저희가 badges.ninja 내부에서 쓰는 것과 똑같은 논리예요. 모든 수여는 Open Badge v2.0 형태로 나가요 — JSON-LD, 안정적인 /certify-badge/award/{guid} URL에서의 hosted 검증, 그리고 처음부터 바로 쓸 수 있는 LinkedIn Add to Profile 지원까지요. 발급자들이 실제로 요구받는 내용의 압도적 다수를 커버하기 때문이에요. 나중에 프로그램이 특정 기관 파트너를 위해 v3.0/CLR 출력을 필요로 하게 되면, 그건 이미 작동하는 v2.0 파이프라인 위에 범위가 한정된 추가 작업이지, 다시 쓰는 작업이 아니에요.

이런 순서로 진행하면 좀 더 눈에 안 띄는 위험도 피할 수 있어요. 파트너가 실제로 어떤 DID 방식을 기대하는지 알기도 전에 DID 인프라에 먼저 발을 담그는 위험 말이에요. VC 생태계는 아직 하나의 DID 방식으로 수렴하지 않았어요 — did:web, did:key, 그리고 원장에 고정된 방식들이 모두 실제로 쓰이고 있고, 파일럿 파트너를 위해 잘못된 걸 고르면 나중에 발급자 신원 작업을 다시 해야 해요. 이름이 명시된 요구사항이 나올 때까지 기다리면, 아무것도 만들기 전에 실제로 어떤 방식이 필요한지 알 수 있어요.

여러분의 프로그램을 위한 빠른 점검

v3.0에 엔지니어링 시간을 쓰기 전에, 이 세 가지 질문을 스스로에게 던져보세요.

• 고용주의 ATS, 자격 발급 기관, 파트너 기관 등 여러분의 자격증을 소비하는 누군가가 CLR 2.0이나 W3C VC 출력을 명시적으로 요구하나요? 아니라면, v2.0으로 충분해요.
• 수신자가 웹 프로필이나 LinkedIn뿐만 아니라 디지털 지갑 앱에 이 자격증을 보관해야 하나요? 아니라면, v2.0으로 충분해요.
• URL 기반 hosted 검증만으로는 정말 부족한, 발급자 간 신뢰 인프라를 구축하고 있나요? 아니라면, v2.0으로 충분해요.

세 번 모두 “아니요”라고 답했다면, 2026년에 v2.0을 출시한다고 해서 뒤처진 게 아니에요 — 오히려 실제로 그걸 소비하는 생태계에 스펙을 맞추고 있는 거예요. 특정 파트너나 규제 요구사항이 “v3가 더 새로우니까”라는 막연한 느낌이 아니라 v3.0을 이름으로 콕 집어 요구할 때, 그때 다시 이 질문을 검토하면 돼요.

배지 검증 데이터가 더 오래되고 표준화되지 않은 자격증 포맷에 비해 어떤 강점이 있는지 더 알고 싶다면, 검증과 이식성 측면의 트레이드오프를 다른 각도에서 다룬 Blockchain Certificates vs Open Badges를 확인해보세요.

---

첫 검증 가능한 자격증을 발급할 준비가 되셨나요? badges.ninja에서 무료로 시작하기 — 비주얼 디자이너, 공개 검증 페이지, PDF 인증서, Open Badge v2.0 출력까지 모두 제공해요. 신용카드는 필요 없어요.