MiCA 해설: 암호화폐 백서는 단순히 Gitbook이나 PDF 파일로만 되어서는 안 됩니다

'MiCA Decoded'는 Bitcoin.com News를 위해 LegalBison의 공동 창립자이자 대표이사인 아론 글라우버만(Aaron Glauberman), 빅토르 유스킨(Viktor Juskin), 사비르 알리예프(Sabir Alijev)가 공동 집필하는 12부작 주간 연재물입니다. LegalBison은 유럽 및 그 외 지역에서 암호화폐 및 핀테크 기업들에게 MiCA 라이선싱, CASP 및 VASP 신청, 규제 구조 설계에 대한 자문을 제공합니다.

MiCA에 따르면, 백서는 의무적인 법적 공시 문서입니다. 전통 금융에서 이와 가장 유사한 것은 마케팅 문서가 아닌 증권 투자설명서입니다. 이 규정은 누가 백서를 작성해야 하는지, 어떤 형식으로 작성해야 하는지, 어떤 식별 정보를 포함해야 하는지, 어떤 자동 검증 절차를 거쳐야 하는지, 그리고 특정 지정된 개인에게 책임이 귀속되는지를 규정하고 있습니다.

이러한 요소 중 하나라도 잘못되면, 문서가 아무리 잘 작성되었더라도 유럽 규제 당국의 관점에서는 존재하지 않는 것으로 간주됩니다. 이번 'MiCA 디코딩' 여섯 번째 편에서는 이것이 실제로 무엇을 의미하는지 하나하나 자세히 파헤쳐 보겠습니다.

오해: MiCA 백서는 그저 GitBook이나 PDF일 뿐이다

MiCA 백서는 공식 규제 제출 문서와 동등한 법적 효력을 지닙니다. 암호자산 백서의 양식, 형식 및 템플릿을 규정하는 유럽연합 집행위원회 시행규정(EU) 2024/2984는, 제출 주체나 장소에 관계없이 유럽증권시장감독청(ESMA)과 모든 EU 회원국의 국가 감독 당국이 제출된 모든 문서에 대해 동일한 자동 분석을 수행할 수 있도록 설계된 구조화된 디지털 형식으로 문서를 작성할 것을 요구합니다.

이러한 설계 선택의 법적 목적은 기술적 세부 사항보다 더 중요합니다. MiCA는 단일 시장 규정이므로, 제출물 간의 비교 가능성은 핵심적인 집행 수단입니다. 유럽에서 제출된 다른 모든 백서와 동일한 기계로 읽을 수 없는 백서는 그 내용이 무엇이든 규정을 준수하지 않는 것입니다. ESMA는 2025년 8월 5일, 규정 준수 백서에 포함되어야 할 내용을 정의하는 구조화된 프레임워크인 필수 분류 체계를 발표했습니다. 이 규정은 2025년 12월 23일부터 적용됩니다. 공시 의무는 관련 암호화폐 자산의 유형에 따라 다릅니다. MiCA는 세 가지 별개의 범주를 구분하며, 각 범주마다 고유한 백서 템플릿과 필드 요구 사항이 있습니다:

이 범주는 백서의 내용뿐만 아니라 백서 제출을 위한 전체 법적 절차를 결정합니다. 프로젝트는 선호도에 따라 적용될 범주를 선택할 수 없습니다. 자산의 특성이 이를 결정하며, 그에 따라 준비 의무가 따릅니다.

법적 의무 및 책임의 부담 주체

시장에 유통되는 대다수의 토큰(‘기타’ 암호화폐 자산, 즉 OTHR로 분류됨)의 경우, 의무가 토큰을 생성한 주체에게 자동으로 귀속되지는 않습니다. 이러한 자산에 대해 MiCA는 의무의 주체를 발행자나 거래 승인을 신청하는 자에게 부과하며, 이들은 원래 발행자와 일치할 수도 있고 그렇지 않을 수도 있는 정의된 역할입니다.

이러한 구분은 실질적인 결과를 초래합니다. 영국령 버진아일랜드, 케이맨 제도 또는 기타 역외 관할권에서 출시된 OTHR 범주에 속하는 프로젝트는 MiCA에 따라 제안자가 될 수 있으며, 법적 소재지를 유럽으로 이전할 필요 없이 백서 작성 의무를 직접 부담할 수 있습니다.

(참고: 이러한 구조적 유연성은 OTHR 토큰에만 엄격히 적용됩니다. 자산 연계 토큰(ART) 및 전자화폐 토큰(EMT)의 경우, 백서에 대한 법적 의무와 엄격한 민사 책임은 전적으로 승인된 EU 발행자에게 있으며 위임할 수 없습니다). 이 시리즈의 두 번째 편에서 살펴본 바와 같이, ESMA 등록 현황은 이것이 이미 표준 관행임을 확인해 줍니다. 독립적인 토큰 신고의 대다수는 EU 외부에 본사를 둔 기관에서 이루어지고 있습니다.

거래 플랫폼을 운영하는 CASP(암호자산 서비스 제공자)도 자체적으로 또는 프로젝트 팀과의 서면 계약을 통해 백서 관련 의무를 부담할 수 있습니다. 이는 법적 허점이나 행정적 편의가 아닙니다. CASP가 신고를 제출할 경우, 해당 공개 내용의 정확성과 완전성에 대한 법적 책임을 지게 됩니다. 백서에 오해의 소지가 있는 정보가 포함되어 있거나 규제 기준을 충족하지 못할 경우, 그 책임은 이를 제출한 주체에게 있습니다.

백서에 서명하는 사람은 그 책임을 소프트웨어 공급업체, 기술 통합업체 또는 법률 사무소에 전가할 수 없습니다. 내용에 대한 법적 검토와 기술적 타당성 확인은 별개의 두 가지 규정 준수 의무이며, 둘 다 제안자에게 귀속됩니다. 이것이 바로 대부분의 프로젝트가 과소평가하는 부분입니다.

제출을 시작하기 전에 반드시 존재해야 하는 두 가지 코드

규정을 준수하는 백서를 작성하기 위해서는 두 가지 필수 식별자가 선행되어야 합니다. 이 두 가지는 모두 MiCA보다 먼저 제정된 국제 표준에서 유래한 것입니다. 해당 규정은 이를 새로 만든 것이 아니라 의무화한 것입니다.

첫 번째는 법인 식별자(LEI)로, 법인에게 할당되고 GLEIF가 관리하는 글로벌 LEI 데이터베이스에 유지되는 ISO 17442 코드입니다. 이 코드의 사용 의무는 여러 규제 표준에 걸쳐 있습니다. 기록 보관 RTS(유럽연합 집행위원회 위임규정 EU 2025/1140) 제14조는 CASP가 고객에 대해 LEI 요건을 준수하도록 강제하는 반면, 반면 백서 분류 RTS(유럽연합 위임규정 EU 2025/421) 제3조는 모든 백서 작성자가 유효한 LEI 코드로 자신의 법인을 식별해야 한다고 엄격히 규정하고 있습니다. 아직 LEI를 보유하지 않은 법인의 경우, 백서 작성에 착수하기 전에 LEI 신청 절차를 완료해야 합니다.

두 번째는 디지털 토큰 식별자(DTI)로, 암호화폐 자산 자체를 식별하는 ISO 24165 코드이며 DTIF 레지스트리에 관리됩니다. 기록 보관 RTS 제15조 및 백서 분류 RTS(유럽연합 집행위원회 위임규정 EU 2025/421) 제3조는 DTI의 사용을 요구합니다. 새로운 토큰을 출시하는 모든 프로젝트의 핵심 사항은 다음과 같습니다. 레지스트리에 DTI가 아직 존재하지 않는 경우, 백서를 제출하기 전에 누군가가 DTI 생성을 요청해야 합니다. 중앙 집중식 발행자가 없고 기존 백서가 없는 자산을 CASP가 등록하는 경우, 플랫폼은 DTIF에서 직접 DTI를 조회하거나 요청할 책임이 있습니다.

출처: 암호화폐 자산용 DTIF 레지스트리 유효한 LEI 및 DTI가 포함되지 않은 백서는 인간 검토자가 확인하기 전에 자동 검증 단계에서 탈락합니다. 두 코드 모두 확보하지 못한 채 제출 단계에 도달한 프로젝트는 모든 절차를 처음부터 다시 시작해야 합니다.

자동화 게이트와 그 법적 의미

자동 검사에 실패한 백서는 국가 관할 당국의 어떤 심사관도 검토하지 않습니다. ESMA 분류 체계는 257개의 존재성 검사(필수 필드 존재 여부 확인)와 223개의 값 검사(필드 내용의 유효성 확인)를 정의합니다. "오류(Error)" 등급의 검사에 실패한 제출물은 기술적으로 무효입니다. 해당 문서는 다음 단계로 진행되지 않습니다.

이러한 구조가 갖는 법적 함의는 명확합니다. 기술적 유효성과 내용의 정확성은 동등하게 발행자의 책임입니다. 구조가 잘못되어 있어도 완벽하게 작성된 법적 공시 문서는 실패합니다. 구조적으로는 유효하지만 오해의 소지가 있는 내용을 담은 파일 역시 실패합니다. 단지 다른 단계에서, 다른 결과를 초래하며 실패할 뿐입니다.

여러 EU 회원국에서 토큰을 발행하는 프로젝트는 추가적인 장벽에 직면합니다. 백서의 각 언어 버전은 각각 별도로 구조화된 파일을 요구합니다. 모든 언어 버전은 단순히 번역된 것이 아니라 필드 수준에서 동일하게 구성되어야 하며, 내부적으로 일관성이 있어야 합니다. 원본의 구조를 반영하지 않는 번역은 언어적 정확성과 무관하게 기술적으로 규정 미준수입니다.

지속 가능성 공시 사항은 또 다른 제약 조건을 추가합니다. 분류 체계(taxonomy)는 에너지 소비량과 CO2 배출량에 대해 각각 kWh와 tCO2라는 특정 측정 단위를 의무화합니다. 이는 선택적인 환경 보고가 아닌 법적 공시 요건입니다. 다른 단위로 제출하거나 필드를 누락하면 검증 실패가 발생합니다.

이러한 모든 요건의 공통된 패턴은 동일합니다. 백서는 기계적으로 적용되는 표준을 따르는 법적 제출 서류입니다. 구조화된 전제 조건과 자동화된 게이트키핑이 포함된 규정 준수 프로세스가 아닌, 단순한 문서 작성 작업으로 접근하는 프로젝트는 인간 규제 당국에 도달하기도 전에 이러한 강제 적용을 마주하게 될 것입니다.

실무적 의미

암호화폐 백서를 단순히 설득을 위한 서술적 제안서(공개보다는 설득을 목적으로 작성된 문서)로 보는 일반적인 인식은, MiCA가 완전히 다른 성격의 문서로 대체해버린 기존 문서 유형을 묘사하는 것입니다.

MiCA 백서는 규정된 내용, 필수 식별자, 자동화된 국경 간 비교를 위해 설계된 구조화된 형식을 갖추고 있으며, 서명자에게 명시된 개인적 책임이 따르는 법적 문서입니다. 유럽 암호화폐 시장으로 진입하기 위한 관문은 바로 이 백서를 통과하는 것입니다. 이 제출 절차를 용어가 역사적으로 암시해 온 것이 아니라 법적으로 무엇인지 제대로 이해하는 프로젝트만이 자동화된 심사 단계에서 거절당하지 않을 것입니다.

핵심 요점:

• 백서는 마케팅 문서가 아닙니다. MiCA는 이 용어의 정의를 재정의했습니다. 전통 금융에서 가장 유사한 것은 증권 투자설명서이며, 동일한 법적 무게로 취급되어야 합니다.
• 세 가지 자산 범주, 세 가지 다른 경로. OTHR, ART, EMT는 각각 고유한 백서 요건과 상이한 승인 전제 조건을 갖습니다. 자산의 특성이 적용될 범주를 결정하며, 프로젝트 측이 선택할 수 없습니다.
• 책임은 제출자에게 따르지만, 규칙은 자산에 따라 달라집니다. 대다수의 토큰(OTHR)의 경우, 법적 의무는 토큰의 최초 창시자가 아니라 발행자 또는 거래 승인을 요청하는 사람에게 있습니다. CASP(거래소 운영자 등)가 OTHR 프로젝트를 대신해 백서를 작성하고 공개하기로 동의할 경우, 상당한 규제상 의무를 부담하게 되지만 책임을 전적으로 떠안는 것은 아닙니다. MiCA 제14조 제3항에 따르면, 거래 승인을 신청한 당사자가 CASP에 불완전하거나, 불공정하거나, 불명확하거나, 오해의 소지가 있는 정보를 제공한 경우, 해당 당사자가 법적 책임을 지게 됩니다. 서류 작업은 외주화할 수 있지만, 책임은 완전히 외주화할 수 없습니다.
• 자산 연계 토큰(ART) 및 전자화폐 토큰(EMT)의 경우, 백서에 대한 엄격한 민사 책임은 법인으로서의 승인된 발행자에게만 있는 것이 아니라, 명시적으로 그 행정, 경영 또는 감독 기구의 구성원들에게까지 확대됩니다. 이러한 책임을 제한하거나 배제하려는 어떠한 계약상 시도도 법적으로 무효입니다.
• LEI 및 DTI는 필수 요건입니다. 백서 작성에 착수하기 전에 두 식별자 모두 준비되어 있어야 합니다. 해당 자산에 대한 DTI가 존재하지 않는 경우, 다른 절차를 진행하기 전에 DTIF 등록 기관에 이를 요청해야 합니다.
• 자동 검증은 첫 번째 관문입니다. 사람이 파일을 검토하기 전에 257개의 존재 여부 검사와 223개의 값 검사가 수행됩니다. 오류 수준 검증에서 실패한 문서는 규제 당국에 전달되지 않습니다.
• 다국어 제출에는 숨겨진 기술적 의무가 따릅니다. 각 언어 버전은 원본과 동일하게 구성된 별도의 파일을 필요로 합니다. 필드 수준에서 원본 구조와 일치하지 않는 번역은 규정 미준수로 간주됩니다.
• 내용의 정확성과 기술적 타당성은 서로 별개의 의무입니다. 법률 검토는 전자를 다루고, 기술적 구조화는 후자를 다룹니다. 두 가지 모두 제출자의 책임이며, 어느 한쪽도 다른 쪽을 대체할 수 없습니다.

이 기사는 2026년 4월 LegalBison이 수행한 연구를 바탕으로 작성되었습니다. 본 내용은 정보 제공 목적으로만 작성되었으며, 법률 자문을 구성하지 않습니다.