Open Badges: 검증 가능한 증명을 뒷받침하는 열린 표준

이 표준은 증명을 세 부분으로 나눠요. 이렇게 나눈 게 처음 보이는 것보다 훨씬 똑똑해요. Issuer는 누가 발급하는지를 담아요. 이름, 웹사이트, 연락처예요. BadgeClass는 무엇을 주는지를 담아요. 증명의 제목, 설명, 기준, 이미지예요. 마지막으로 Assertion은 한 건의 수여 그 자체예요. 이 사람이 이 BadgeClass를 이 날짜에 받았다는 사실이에요.

덕분에 인증서 유형에 대한 설명은 한 번만 있으면 돼요. 20명에게 주든 2,000명에게 주든 마찬가지예요. 저희 시스템에서 나온 실제 Assertion은 이런 모습이에요. 토큰만 줄여 뒀어요.

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

두 가지는 한 번 더 볼 만해요. badge 필드는 주소일 뿐이에요. 그 주소에 BadgeClass가 놓여 있고, 그 BadgeClass가 다시 Issuer를 가리켜요. 검증 도구는 이렇게 사슬 전체를 따라가요. 그리고 recipient 자리에는 인증서 페이지의 주소가 들어가요. 이메일 주소는, 해시로 감춘 것조차, 어디에도 나오지 않아요. 그래서 이 공개 문서에는 직접적인 연락처가 담기지 않아요. 사람 이름은 연결된 인증서 페이지에 있어요. 인증서를 받을 때 본인이 직접 적어 넣은 그 자리예요.

규격에는 Assertion을 검증 가능하게 만드는 두 가지 길이 있어요. 서명형 배지에서는 문서 자체에 발급자의 암호화 서명이 들어가요. 그래서 스스로를 증명하지만, 발급자 쪽에서 키를 관리해야 해요. 호스팅형 배지에는 더 단순한 규칙이 통해요. Assertion은 자신의 id 주소에서 발급자를 통해 불러올 수 있는 동안 진짜예요. 그러면 검증은 그저 URL을 불러와 견주는 일이 돼요.

호스팅형 방식에는 과소평가된 장점이 하나 있어요. 깔끔한 취소예요. 발급자가 증명을 거둬들이면, 같은 주소가 그 순간부터 HTTP 상태 410과 함께 「revoked: true」라는 한 줄이 담긴 짧은 문서로 응답해요. 그래서 취소된 인증서라도 흔적 없이 조용히 사라지지 않아요. 같은 주소가 더는 유효하지 않다고 또렷하게 알려요. OneClickBadge에서도 이렇게 해요. 예를 들어 인증서가 실수로 두 번 발급됐을 때예요.

이 표준에는 거의 시적인 구석이 하나 있어요. 「베이킹」이에요. 대개 PNG인 배지 그래픽은 자신의 Assertion과 검증 주소를 이미지 파일 안에 직접 새겨 넣어요. 기술적으로는 openbadges라는 키워드가 붙은 iTXt 텍스트 블록이에요. 이미지는 그 뒤에도 겉보기엔 똑같지만, 검증 경로를 제 안에 품고 있어요. 파일을 검증 도구에 끌어다 놓으면 Assertion에 닿아요. 그 이미지가 다운로드와 채팅을 아무리 여러 번 거쳐 왔더라도요.

순서는 여전히 중요해요. 증명할 수 있는 건 호스팅형 Assertion뿐이에요. 이미지는 얼마든지 복사하고 바꿀 수 있지만, 증명 주소에서 나오는 응답은 오직 발급자만 통제해요.

여기서 여러 글에 떠도는 가장 흔한 오해를 정리할게요. LinkedIn은 Open Badge 메타데이터를 읽지 않아요. 배지 가져오기도, 자동 검증도, 검증된 배지를 위한 특별한 표시도 없어요. LinkedIn에 있는 건 프로필의 「라이선스 및 자격증」 영역이에요. 이름, 발급 기관, URL을 넣는 칸이 있어요. 그렇다고 LinkedIn이 무언가를 인증하거나 인정해 주는 건 아니에요.

그렇다고 이 표준이 LinkedIn에서 쓸모없는 건 아니에요. 오히려 반대예요. URL 칸에는 증명 주소가 들어가요. 프로필에서 「증명서 보기」를 누른 사람은 인증서 페이지에 닿고, 그 뒤에는 검증 가능한 Assertion이 있어요. 이 항목 자체는 받는 사람이 한 번의 클릭으로 채울 수 있게 미리 준비해 둘 수 있어요. 양식의 칸이 이미 채워진 채로요. 참가자 입장에서 이게 어떻게 보이는지는 프로필에 등록하는 방법 가이드에서 볼 수 있어요.

표준을 직접 구현하는 게 이득인 주최자는 거의 없어요. Issuer, BadgeClass, 그리고 Assertion 하나하나마다 늘 접근 가능한 엔드포인트가 필요하고, 거기에 취소 로직과 베이킹된 이미지까지 있어야 해요. 이벤트, 웨비나, 교육이라면 이미 완성된 길이 있어요. OneClickBadge에서 참가 인증서를 디자인하면, 발급되는 모든 인증서에 호스팅형 Assertion, 취소 방식, 그리고 이미지가 담긴 PDF가 자동으로 따라와요.

많은 참가자에게 나눠주는 일도 명단 업로드 없이 돌아가요. 이벤트가 끝난 뒤 공유하는 셀프 수령 링크로요. 하필 증명이라는 주제에서 이게 왜 개인정보 문제이기도 한지는 많은 참가자를 위한 인증서 페이지에 담겨 있어요.

3.0 버전은 표준을 W3C Verifiable Credentials 위로 옮겨요. 암호화 서명을 쓰고 받는 사람이 더 많이 통제하는 모델이에요. 대학 생태계나 오래 남는 교육 이력에는 이쪽이 맞는 방향이에요. 이벤트 참가라는 쓰임새에서는 호스팅형 2.0이 지금으로선 실용적인 자리예요. 흔히 쓰는 검증 도구가 모두 이해하고, 취소도 되고, 지갑이나 키를 관리할 사람도 필요 없어요. 그래서 저희는 호스팅형 2.0을 쓰면서 3.0은 느긋하게 지켜보고 있어요.