스테이블코인 조례가 공식 통과됨에 따라, 홍콩 금융관리국(HKMA)은 2025년 5월 26일 "허가받은 스테이블코인 발행자 감독 지침 초안"을 발표하여 국내 스테이블코인 생태계의 안정성, 보안성 및 규정 준수를 보장하고자 했습니다. 이 지침은 허가받은 스테이블코인 발행자가 지속적으로 준수해야 하는 규제 요건과 운영 기준을 자세히 설명합니다.

최근 점점 더 많은 기관들이 스마트 계약의 규정 준수 구현에 대해 SlowMist 보안팀에 자문을 구하고 있습니다. 발행자가 규정을 준수하는 스마트 계약 시스템을 더 잘 이해하고 구축할 수 있도록, 저희는 "홍콩 스테이블코인 발행자를 위한 스마트 계약 구현 가이드"를 특별히 발간하여 홍콩 스테이블코인 생태계의 건전한 발전을 위한 명확한 기술적 지침과 실질적인 제안을 제공합니다.

1부 인프라 및 규정 준수 전략

이 섹션은 스테이블코인 시스템의 고수준 아키텍처 기반을 구축하는 것을 목표로 합니다. 이러한 아키텍처 결정은 전적으로 홍콩 금융관리국(HKMA) 프레임워크의 가장 기본적인 요구 사항에 따라 이루어집니다. 여기에서 내린 선택은 전체 구현 경로를 결정하며, 설계 초기 단계부터 규정 준수가 기술 스택에 깊이 내재되도록 보장합니다.

1. 기반 분산원장 선택

규제 지침

라이선스 보유자는 사용하는 기반 분산원장기술(DLT)의 견고성을 평가해야 합니다. 이 평가에는 보안 인프라, 일반적인 공격(예: 51% 공격)에 대한 복원력, 거래 확정성 보장, 그리고 합의 ^알고리즘 의 신뢰성이 포함됩니다.

SlowMist 기술 설명

이는 단순한 기술 선호도의 선택이 아니라 핵심적인 규정 준수 과제입니다. 기반 블록체인 선정은 공식적인 실사를 거쳐야 하며, 규제 검토 시 충분한 근거를 제시하기 위해 전체 평가 과정을 상세히 기록해야 합니다. 기반 원장 선정 과정은 실제로 전체 스테이블코인 시스템의 보안과 안정성을 좌우합니다.

홍콩 금융감독청(HKMA)이 원장 견고성을 강조하는 것은 발행자에게 검증되지 않았거나, 과도하게 중앙집중화되었거나, 보안성이 의심스러운 새로운 블록체인을 채택하지 않도록 권고하는 것과 같습니다. 블록체인의 보안성과 안정성을 입증하는 책임은 전적으로 발행자에게 있습니다. 만약 발행자가 보안성이 널리 검증되지 않은 체인을 선택할 경우, 추가적인 보상 통제를 설계하고 구현해야 합니다.

구현 가이드

• 성숙한 퍼블릭 체인 우선 : 이더리움이나 아비트럼과 같이 성숙하고 보안성이 높은 퍼블릭 블록체인을 우선적으로 고려하는 것이 좋습니다. 이러한 네트워크는 검증된 복원력, 대규모 검증 노드 네트워크, 그리고 지속적인 공개 감독을 통해 고유한 장점을 가지고 있습니다. 높은 공격 비용(경제적 보안)은 51% 공격 방어 및 거래 완결성 보장과 관련된 규제 당국의 우려에 직접적으로 대응할 수 있습니다.

• 대안에 대한 엄격한 평가: 컨소시엄 체인이나 다른 유형의 분산원장을 고려하는 경우 SlowMist 보안 감사와 같은 엄격하고 정량화 가능한 비교 분석을 수행하여 해당 보안 표준이 주류 공개 체인보다 낮지 않거나 더 뛰어나지 않음을 입증해야 합니다.

• 위험 평가 문서: 평가 보고서는 일반적인 공격에 대한 저항 능력, 합의 알고리즘의 유형, 그리고 코드 결함, 취약점, 취약점 악용 및 기타 ^위협 과 관련된 위험을 포괄적으로 다루고, 이러한 위험이 스테이블코인의 발행, 상환 및 일상 운영에 잠재적으로 어떤 영향을 미칠 수 있는지 자세히 분석해야 합니다. 이 문서는 규제 기관에 기술 선택의 신중함을 입증하는 핵심 문서입니다.

2. 핵심 토큰 표준 및 규제 기능 확장

규제 지침

규제 문서는 특정 토큰 표준(예: ERC-20)을 명시하지 않습니다. 그러나 해당 문서는 채굴, 소각, 업그레이드, 일시 중지, 재개, 동결, 블랙리스트 및 화이트리스트 ^작업 등 일련의 핵심 관리 기능 구현을 요구합니다.

SlowMist 기술 설명

홍콩 금융관리국(HKMA)은 실제로 ERC-20 표준을 훨씬 뛰어넘는 기능을 갖춘 "규제 강화" 토큰 표준을 정의했습니다. 이 표준은 기본적인 토큰 유통 기능뿐만 아니라 운영 보안, 권한 제어 가능성, 그리고 위험 추적성까지 강조합니다. 규정 준수 요건을 충족하는 동시에 보안을 극대화하기 위해 가장 효율적이고 안전한 개발 경로는 널리 감사되고 커뮤니티에서 인정하는 표준 라이브러리(예: OpenZeppelin)를 채택하고 이를 기반으로 기능을 확장하는 것입니다.

구현 가이드

• 기본 표준 : ERC-20은 토큰의 동질성과 더 넓은 생태계에서의 상호 운용성을 보장하기 위한 기본 표준으로 채택되었습니다.

• 기능 확장: 규제 요구 사항을 충족하려면 다음 기능 모듈을 통합해야 합니다.

• 일시 중지 가능: 모든 토큰 활동의 전역 일시 중지 및 재개 기능을 구현하는 데 사용됩니다. 이는 주요 보안 사고에 대응하는 핵심 도구입니다.

• Mintable: 이는 허가받은 발행자가 통제된 프로세스를 통해 새로운 토큰을 발행하고 발행된 토큰의 양이 충분한 법적 통화 준비 자산과 엄격히 일치하도록 보장해야 한다는 요구 사항을 구현하는 데 사용됩니다.

• Burnable: 토큰 파기 기능을 제공합니다. 특정 구현에서는 사용자가 직접 토큰을 파기하는 대신, 권한에 따라 이 기능이 엄격하게 제어됩니다.

• 동결 가능: 특정 계정(의심스러운 거래에 연루된 계정 등)의 토큰 전송 기능을 일시 중단하는 데 사용됩니다.

• 허용 목록: 추가적인 보안 조치를 구현하는 데 사용되며, 핵심 작업(새로 생성된 ^토큰 수신 등)에 참여하기 위해 충분한 조사와 승인을 통과한 주소만 허용합니다.

• 블랙리스트: 불법 활동(자금세탁, 사기 등)에 연루된 주소에 대한 거래 금지를 시행하여 토큰 송수신을 금지하는 데 사용됩니다. 블랙리스트 관리는 의심스러운 거래를 실시간으로 모니터링하기 위해 AML/CFT 시스템과 연동되어야 합니다.

• 접근 제어: 이는 정교한 역할 기반 권한 관리 시스템을 구현하는 기반입니다. 모든 관리 기능은 업무 분리 요건을 충족하기 위해 이 모듈을 통해 제어되어야 합니다 ^.

3. 주요 준수 모드: 블랙리스트 및 화이트리스트 선택

규제 지침

지속적인 모니터링과 관련하여 자금세탁방지/테러자금조달방지(AML/CFT) 협의문서는 "제재받거나 불법 활동과 관련된 것으로 확인된 지갑 주소를 블랙리스트에 올리는 것"이나 더 엄격한 "스테이블코인 보유자의 지갑 주소를 화이트리스트에 올리거나 폐쇄 루프 모델을 도입하는 것"을 포함한 다양한 조치를 제안합니다 ^.6 .

SlowMist 기술 설명

이는 스테이블코인의 규정 준수 운영에 대한 개방성, 실용성, 복잡성을 직접적으로 결정하는 전체 시스템 아키텍처에서 가장 중요한 결정 지점입니다.

• 블랙리스트 모드 : "기본 개방" 모드입니다. 모든 주소는 기본적으로 자유롭게 거래할 수 있으며, 명확하게 식별되어 온체인 블랙리스트에 추가된 주소만 거래가 제한됩니다.

• 화이트리스트 모드: 기본적으로 닫혀 있는 폐쇄형 루프 모드입니다. 발급자가 명시적으로 조사하고 승인하여 온체인 화이트리스트에 추가하지 않는 한, 어떤 주소도 토큰을 보유하거나 받을 수 없습니다.

화이트리스트 모델은 AML(자금세탁방지) 통제 기능을 제공하지만, 광범위하게 사용되도록 설계된 스테이블코인의 경우 엄격한 화이트리스트 시스템 때문에 스테이블코인은 사전에 심사를 거친 참여자 사이에서만 유통될 수 있으므로 유연한 디지털 화폐라기보다는 폐쇄형 은행 원장 시스템에 더 가깝습니다.

따라서 규제 기관이 명시적으로 언급한 블랙리스트 모델은 규제 기관이 요구하는 강력한 오프체인 분석 도구와 결합되어 더욱 균형 잡힌 솔루션을 구성합니다. 규제 요건을 충족할 뿐만 아니라 자산의 실용성도 유지합니다.

설계 측면에서, 시스템은 업그레이드가 가능하도록 구축하거나 두 모드를 동시에 구현할 수 있으므로, 향후 규정이 강화되거나 비즈니스 모델이 변경될 때 원활하게 전환하거나 허용 목록 모드로 전환할 수 있습니다.

구현 가이드

• 블랙리스트 모드(기본 권장 솔루션) :

• 장점: 실용성이 더 높고 광범위한 분산 금융(DeFi) 생태계와 원활하게 상호 운용할 수 있어 사용자에게 낮은 사용 임계값과 더 원활한 경험을 제공합니다.

• 단점: 규정 준수는 불법 주소를 신속하게 감지하고 차단하기 위한 강력하고 실시간적인 오프체인 모니터링 및 분석 기능에 크게 의존합니다.

• 구현 방법: 스마트 계약의 전달 함수에 논리 검사를 추가하여 거래의 발신자(보내는 사람)와 수신자(받는 사람) 주소가 블랙리스트에 기록되지 않도록 합니다.

• 화이트리스트 모드

• 장점: AML/CFT 통제의 최고 수준을 제공하여 시정보다는 예방을 실현합니다.

• 단점 : 스테이블코인의 다양성과 도입성이 크게 제한되고, 화이트리스트를 관리하는 데 막대한 운영 비용이 발생하며, 널리 수용되는 교환 수단이 되기 어려울 수 있습니다.

• 구현 방법: 스마트 계약의 전달 함수에 로직 검사를 추가하여 거래의 발신자(from)와 수신자(to) 주소가 모두 허용 목록에 포함되어야 하도록 합니다. 운영 편의성을 높이기 위해 운영을 위한 전용 웹 사용자 백엔드 시스템을 개발하는 것이 좋습니다.

2부 스마트 계약 구현

이 섹션에서는 스마트 계약의 핵심 기능에 대한 자세한 청사진을 제공하고, 복잡한 규제 요구 사항을 특정 코드 수준 논리, 보안 모델 및 운영 프로토콜로 변환합니다.

1. 정교한 접근 제어 시스템 설계

규제 지침

고위험 작업은 "단일 당사자가 관련 작업을 단독으로 실행할 수 없도록(예: 다중 서명 프로토콜을 통해)" 설계되어야 합니다. ^7. 다양한 작업에 대한 책임은 적절하게 분리되어야 합니다.

SlowMist 기술 설명

즉, 강력한 역할 기반 접근 제어 시스템(RBAC)이 필수적입니다. 단일 "소유자" 또는 "관리자" 개인 키는 어떤 형태로든 준수되지 않습니다.

구현 가이드

다중 서명 지갑으로 관리되는 여러 기관 또는 직원에게 명확한 역할을 정의하고 할당하여 업무 분리를 달성하고 단일 장애점 또는 공모 위험을 최소화해야 합니다 ^.8 각 역할은 특정 기능으로 제한되어야 하며, 모든 작업은 다중 서명 인증을 요구하고, 단일 직원이 동시에 여러 고위험 역할을 수행하지 않도록 해야 합니다. 모든 작업은 기록되어야 하며 매년 제3자 감사를 받아야 합니다. 권한 할당은 관리자 또는 이사회의 감독을 받습니다.

• MINTER_ROLE: 스테이블코인의 주조 작업을 처리하는 책임, 유효한 발행 요청을 받을 때 토큰 단위를 생성하는 책임, 그리고 주조가 준비 자산 풀의 해당 증가와 일치하도록 보장하는 책임을 맡습니다.

• BURNER_ROLE: 유효한 환매 요청을 받으면 토큰 단위를 파기하는 것을 포함하여 스테이블코인의 소각을 처리하는 역할을 담당합니다.

• PAUSER_ROLE: 비정상적인 이벤트(보안 위협 등)가 감지되면 전송, 주조 또는 상환을 일시적으로 중단하는 등 스테이블코인 작업을 일시 중지하는 역할을 담당합니다.

• RESUME_ROLE: 정지 이벤트가 해결된 후 스테이블코인 운영을 재개하는 역할입니다. 여기에는 전송, 주조, 상환이 다시 활성화됩니다.

• FREEZER_ROLE: 의심스러운 활동(자금세탁 위험 등)이 감지되면 자산을 일시적으로 동결하는 등 특정 지갑이나 토큰을 동결 및 동결 해제하는 역할을 담당합니다.

• WHITELISTER_ROLE: 허용된 지갑 주소를 추가하거나 제거하고, 채굴을 허용된 주소로 제한하는 등 허용 목록을 관리하는 역할을 담당합니다.

• BLACKLISTER_ROLE: 블랙리스트를 관리하고 블랙리스트를 제거하는 일, 의심스러운 지갑을 블랙리스트에 등록하여 이체를 방지하는 일을 담당합니다.

• UPGRADER_ROLE: 업그레이드 가능한 모델을 채택한 경우, 취약점을 수정하거나 기능을 추가하기 위해 계약 코드를 업데이트하는 등 스마트 계약을 업그레이드하는 역할을 담당합니다.

표 1: 역할 기반 액세스 제어 매트릭스(RBAC 매트릭스)

다음 표는 개발자와 감사자가 사용할 수 있는 명확하고 직관적인 사양을 제공하며, 각 특권 작업을 필요한 역할과 제어 유형에 명시적으로 매핑합니다.

2. 발행(주화) 메커니즘

규제 지침

발행은 "신중하고 견고해야" 합니다. 발행은 "기초 준비자산 풀의 상응하는 증가와 일치해야" 합니다. 발행자는 자금을 수령하고 유효한 발행 요청을 받은 후에만 고객에게 발행해야 합니다.

SlowMist 기술 설명

스마트 컨트랙트 자체는 "전체 준비금" 요건을 적용할 수 없으며, 적용할 필요도 없습니다. 대신, 스마트 컨트랙트는 통제된 원장의 역할을 수행하며, 여기서 발행 기관은 핵심 통제 지점 역할을 합니다. 전체 준비금 준수는 오프체인에서 발생하는 감사 검증 가능한 작업입니다. 규제는 발행을 "유효한 발행 요청"과 "수신된 자금"이라는 두 가지 오프체인 이벤트와 연관시킵니다. 따라서 온체인 발행 함수는 이러한 오프체인 조건이 충족되었는지 확인할 수 있는 신뢰할 수 있는 주체(즉, 발행자)에 의해서만 호출되도록 설계되어야 합니다.

구현 가이드

사전 확인: 채굴 기능을 실행하기 전에 해당 기능은 대상 주소가 블랙리스트 또는 동결 상태에 있는지 확인해야 합니다.

작업 과정:

• 오프체인 실사: 고객은 모든 필수 오프체인 KYC 및 CDD 절차를 완료해야 합니다.10 또한, AML/CFT 규정은 특정 금액(예: 8,000 홍콩달러) 이상의 사업 관계를 구축하거나 비정기적으로 거래를 수행하는 고객에게 CDD11를 요구합니다.
• 자금 수령: 고객은 발행자가 지정한 은행 계좌로 동일한 금액의 법정 통화를 이체합니다.
• 내부 검증: 발행인의 내부 시스템은 자금 수령을 확인하고 이에 따라 준비금 자산의 회계 기록을 업데이트합니다.
• 온체인 실행: 운영 팀은 다중 서명 거래를 생성하고 서명하고, 스마트 계약의 민트 토큰 기능을 호출하고, 새로 생성된 스테이블코인을 고객이 사전 등록하고 검증한 지갑 주소로 보냅니다.

3. 구원(파괴) 메커니즘

규제 지침

라이선스 소지자는 유효한 환매 요청을 "가능한 한 빨리, 요청 접수 후 1영업일 이내에" 처리해야 합니다.12. 준비금 자산 인출 시 "유통 중인 지정 스테이블코인의 액면가 감소분만큼" 인출해야 합니다.13

SlowMist 기술 설명

상환은 온체인 및 오프체인 상호작용을 포함하는 두 단계 프로세스입니다. 상환 과정에서 법정화폐 이체 실패 위험을 고려하여, 법정화폐 정산이 확인된 후 토큰을 파기해야 합니다. 이는 궁극적으로 실패한 상환으로 인해 발행자가 토큰을 조기에 파기하는 것을 방지하기 위한 것입니다.

만약 발행자가 먼저 토큰을 파기하고 은행 송금이 실패하면, 해당 자산 없이 부채를 지게 됩니다. 반대로, 발행자가 먼저 법정 통화로 지불하고 해당 토큰을 파기하지 못하면, 역시 손실을 입게 됩니다.

따라서 상환 작업 시 사용자는 발급자가 관리하는 지정 주소로 토큰을 이체해야 하며, 발급자는 법정화폐 결제 완료 후 토큰을 파기합니다. 이 모델을 통해 사용자는 상환을 위해 토큰을 "잠금"할 수 있으며, 발급자는 법정화폐 결제 의무를 이행한 후에만 토큰을 파기합니다. 따라서 양측 모두에게 더욱 안전한 운영 프로세스를 제공합니다.

구현 가이드

환매 준비: 사용자는 먼저 환매할 토큰을 발급자가 관리하는 지정 주소로 이체해야 합니다.

작업 과정:

• 오프체인 요청: 사용자가 발급사 플랫폼을 통해 오프체인 상환 요청을 제출합니다. 요청을 처리하기 전에 발급사는 해당 고객에 대한 적절한 고객 실사(CDD)를 수행해야 합니다.
• 시스템 검증: 발급자의 시스템은 요청의 유효성을 검증하고 사용자가 체인에서 해당 토큰 전송 작업을 완료했는지 확인합니다.
• 법정 통화 지불: 발급자가 사용자의 사전 등록 및 검증된 은행 계좌로 동일한 금액의 법정 통화를 이체합니다.
• 체인상 파괴: 법정 화폐 이체가 성공적으로 이루어졌음을 확인한 후, BURNER_ROLE을 보유한 다중 서명 지갑은 파괴 함수를 호출하여 지정된 주소에서 해당 수의 토큰을 파괴합니다.

4. 비상 통제 조치 시행: 정지 및 동결

규제 지침

계약은 일시 중지, 재개, 블랙리스트, 블랙리스트 해제, 동결 및 동결 해제와 같은 작업을 지원해야 합니다. 이는 인시던트 관리 프레임워크의 핵심 구성 요소입니다.

SlowMist 기술 설명

규제 문서는 "일시 중지"와 "동결"을 두 가지 별개의 항목으로 명시하고 있는데, 이는 규제 기관이 발급사가 유연하고 다층적인 사고 대응 역량을 갖추기를 기대한다는 것을 나타냅니다. 일시 중지는 주요 위기(예: 계약 악용)에 대응하는 수단인 반면, 동결은 특정 법률 또는 규정 준수 문제(예: 단일 계좌에 대한 법원 명령)를 처리하기 위한 구체적인 도구입니다. 이 두 가지는 기능적으로 구별되며 별도로 구현되어야 합니다.

• 일시 정지: 계약의 모든 핵심 기능(이전, 발행, 파기 포함)을 즉시 중단하는 글로벌 "비상 정지 스위치"입니다.
• 동결: 특정 주소가 토큰을 보내거나 받는 것을 방지하는 계정 수준의 제한이지만, 네트워크 내 다른 주소의 일반적인 활동에는 영향을 미치지 않습니다.

구현 가이드

일시 정지 기능: PAUSER_ROLE을 보유한 다중 서명 지갑에서만 호출되며, 계약 기능을 전역적으로 일시 정지하는 데 사용됩니다. 발동 조건에는 이사회 또는 고위 경영진의 승인이 필요한 비정상 이벤트(예: 네트워크 공격 또는 준비금 자산 불일치) 감지가 포함됩니다. 복구 기능은 업무 분리를 위해 별도의 RESUME_ROLE에 의해 처리됩니다.

동결 기능: FREEZER_ROLE을 보유한 다중 서명 지갑에서 특정 주소로의 이체를 제한하기 위해 호출됩니다. 트리거 조건에는 의심스러운 활동(예: AML 경고 또는 법원 명령)이 포함되며, 이러한 활동은 실행 전에 오프체인 검증이 필요합니다. 동결 해제는 동일한 역할에 의해 처리되지만, 남용을 방지하기 위해 추가적인 감사 검증 및 관련 공지가 필요합니다.

5. 주소 검색 및 블랙리스트 메커니즘

규제 지침

라이선스 취득자는 "제재되었거나 불법 활동과 관련된 것으로 확인된 지갑 주소를 블랙리스트에 등록"하는 것과 같은 조치를 취해야 합니다.15 이는 지속적인 모니터링을 위한 핵심 통제 수단이며, 발급자는 블록체인 분석 도구와 같은 기술 솔루션을 활용하여 불법 또는 의심스러운 활동과 관련된 거래를 식별해야 합니다.16

SlowMist 기술 설명

이는 온체인 강제 메커니즘이어야 합니다. 단순히 오프체인에서 경고를 발행하는 것만으로는 충분하지 않으며, 프로토콜 수준에서 해당 거래가 발생하지 않도록 방지해야 합니다. 블랙리스트 요건은 라이선스 보유자가 실시간 블록체인 분석 도구/서비스(예: MistTrack, Chainalysis, Elliptic)를 도입하도록 요구합니다. 규정 준수 팀은 이러한 도구에서 도출된 결론을 활용하여 여러 서명으로 서명된 거래를 안전하게 변환하고 온체인 블랙리스트를 업데이트합니다.

구현 가이드

• 함수 구현: 블랙리스트 추가 및 블랙리스트 제거를 구현하는 함수이며, BLACKLISTER_ROLE을 보유한 다중 서명 지갑에서만 호출할 수 있습니다.
• 전송 제한: 블랙리스트에 있는 주소는 토큰을 전송/수신할 수 없습니다.
• 운영 프로세스: 분석 도구가 경보를 발령하여 내부 규정 준수 검토를 시작합니다. 규정 준수팀이 검토 및 확인 후, BLACKLISTER_ROLE 다중 서명 지갑이 블랙리스트 추가 트랜잭션을 시작합니다.

6. 스마트 계약의 업그레이드 가능성

규제 지침

스테이블코인과 관련된 모든 스마트 계약 아키텍처는 "업그레이드 가능성"을 채택할 수 있습니다. 스마트 계약이 "업그레이드"될 때마다 감사를 받아야 합니다.

SlowMist 기술 설명

설계상 업그레이드 가능성은 규제 프레임워크 내 기술적 유연성과 위험 관리를 위한 핵심 요건입니다. 이를 통해 발급사는 버그 수정, 기능 확장 또는 규제 변경에 대응하기 위해 기존 계약 상태를 방해하지 않고 로직을 업데이트할 수 있습니다.

하지만 이는 높은 위험을 수반합니다. 업그레이드 프로세스가 악용되어 계약 동작에 예상치 못한 변화를 초래하거나 새로운 취약점을 유발할 수 있습니다. 따라서 업그레이드는 고위험 작업으로 간주되어야 하며, 단일 당사자(예: 다중 서명 프로토콜)에 의한 일방적인 실행을 방지하도록 설계되어야 하며, 역할 기반 접근 제어 시스템(RBAC)과 통합되어야 합니다.

규제 기관이 강조하는 감사 요구 사항은 업그레이드가 단순히 코드를 교체하는 것이 아니라 새로운 논리 계약이 배포 전에 제3자에 의해 검증되고 취약점이나 보안 결함이 없는지 확인하기 위해 엄격한 변경 관리 프로세스에 내장된 제어된 이벤트이기도 함을 의미합니다.

구현 가이드

• 프록시 모델: EVM 유형 스마트 계약의 경우, 성숙한 ERC-1967 프록시 모델을 채택하여 업그레이드를 실현할 수 있습니다.
• 권한 제어: 업그레이드 기능은 UPGRADER_ROLE을 보유한 다중 서명 지갑에서만 호출해야 합니다.
• 변경 관리 프로세스: 규정 요구 사항에 따라 업그레이드를 제안하기 전에 엄격한 변경 관리 프로세스를 완료해야 합니다. 여기에는 새로운 로직 계약에 대한 포괄적이고 독립적인 제3자 보안 감사가 포함됩니다.

7. 분석 및 보고를 위한 온체인 이벤트 로그

규제 지침

허가자는 "온체인 및 오프체인 정보를 포함한 모든 비즈니스 활동을 시기적절하고 정확하게 기록"하고 "적절한 감사 추적을 유지"하기 위해 강력한 "정보 및 회계 시스템"을 구축해야 합니다.19

SlowMist 기술 설명

스마트 컨트랙트는 모든 온체인 활동의 핵심적인 진실의 원천입니다. 오프체인 시스템이 로깅, 모니터링 및 보고서를 생성할 수 있도록 모든 중요한 상태 변화에 대한 상세 이벤트를 생성해야 합니다. 이러한 이벤트는 블록체인에 변경 불가능하고 영구적인 로그를 생성합니다. 이 로그는 모든 오프체인 모니터링, 회계 및 보고 시스템의 주요 데이터 소스로서, 감사를 위한 견고한 기반을 제공합니다.

구현 가이드

ERC-20 표준에서 요구하는 전송 및 승인 이벤트 외에도 계약은 모든 관리 작업 및 상태 변경에 대한 사용자 정의 이벤트를 정의하고 내보내야 합니다.

• 토큰 채굴/소각 이벤트
• 계약 일시 중지/재개 이벤트
• 블랙리스트 추가/블랙리스트 제거 이벤트
• 화이트리스트 추가됨 / 화이트리스트 제거됨 이벤트
• AddressFrozen / AddressUnfrozen 이벤트
• RoleGranted / RoleRevoked 이벤트
• 계약 업그레이드 이벤트

제3부 운영 안전 및 수명 주기 관리

이 섹션에서는 스마트 계약과 관련된 중요한 운영 보안 절차에 대해 자세히 설명합니다. 이러한 절차는 코드 자체만큼이나 중요하며, 포괄적인 보안 및 규정 준수를 달성하는 데 필수적입니다.

1. 보안 키 관리 아키텍처

규제 지침

이는 가장 상세하고 엄격한 규제 영역 중 하나입니다. 라이선스 취득자는 생성, 저장, 사용, 백업 및 파기를 포함한 개인 키의 전체 수명 주기에 대해 강력한 제어를 구현해야 합니다.20 "중요 시드 및/또는 개인 키"(예: 업그레이드, 역할 관리, 대규모 코인 주조에 사용되는 키)는 "에어갭 환경"21에서 오프라인으로 생성하고 하드웨어 보안 모듈(HSM)22에 저장하는 등 더 높은 수준의 보안 표준을 요구합니다.

SlowMist 기술 설명

홍콩 금융청(HKMA)은 본질적으로 암호화폐 네이티브 운영에 "전통적인 금융 수준"의 보안 태세를 적용할 것을 요구하고 있습니다. 이러한 수준의 키 관리를 구현하는 데 드는 비용과 복잡성은 막대하며, 모든 라이선스 발급사의 핵심 운영 부분이 될 것입니다. 이 보안 모델은 일반적인 DeFi 프로젝트의 표준 관행을 훨씬 뛰어넘습니다. 규제 문서는 키 관리를 위한 상세한 체크리스트를 제공하며, HSM(하드웨어 보안 모듈), 에어갭 환경, 키 세레모니, 다중 서명을 명시적으로 언급합니다. 이는 사실상 심층 방어 키 관리 아키텍처 구축을 의무화합니다. 하드웨어 지갑에 보관된 계정은 다중 서명 지갑의 서명자 역할을 하며, 다중 서명 지갑은 스마트 계약에 대한 관리 역할을 담당합니다. 최고 수준의 보안 기능을 위해서는 이러한 하드웨어 지갑 자체가 지정되고 물리적으로 안전한 에어갭 환경에서 관리되어야 합니다. 전체 아키텍처는 키 유출을 방지하기 위한 다층 방어 시스템을 구축합니다.

구현 가이드

• 키 생성: 물리적으로 안전하고 공기가 차단된 환경, 즉 외부 세계와 완전히 고립된 환경에서 잘 문서화된 "키 의식"23을 통해 완료되어야 합니다.
• 키 저장: 모든 관리 역할은 다중 서명 지갑으로 관리되어야 합니다. 이러한 다중 서명 지갑 서명자가 사용하는 개인 키는 HSM 또는 기타 보안 하드웨어 지갑에 저장되어야 합니다. 가장 중요한 역할의 경우, 해당 키는 온라인 환경과 물리적으로 분리된 에어갭 시스템에 보관해야 합니다.
• 키 사용: 다중 서명 정책을 시행해야 합니다. "중요한 개인 키"가 포함된 거래 서명의 경우, 관련 담당자가 직접 참석해야 할 수도 있습니다.
• 백업 및 복구: 키 샤드 또는 니모닉의 백업은 홍콩(또는 규제 승인 지역) 내의 여러 안전하고 지리적으로 분산된 위치에 보관해야 하며 변조 방지 패키징에 넣어 보관해야 합니다.

2. 완전한 배포 프로세스 및 런타임 모니터링

규제 지침

라이선스 취득자는 최소 연 1회, 그리고 배포, 재배포 또는 업그레이드 시마다 "자격을 갖춘 제3자 기관"과 스마트 계약 감사를 수행해야 합니다. 감사는 계약이 올바르게 구현되고, 예상대로 작동하며, "높은 신뢰도"에서 취약점이나 보안 결함이 없는지 확인해야 합니다.26 라이선스 취득자는 니모닉 및/또는 개인 키 사용을 모니터링하는 조치(예: IP 확인, 동작 모니터링, 중요 활동 알림, 기기 검사, 온체인 모니터링, 접근 제어 모니터링 등)를 구현해야 합니다.27 또한 라이선스 취득자는 새로운 위협을 탐지하기 위해 위협 인텔리전스를 모니터링하는 적절한 조치를 취해야 합니다. 위협 인텔리전스는 적시에 완화 조치를 구현할 수 있도록 분석되어야 합니다.28

SlowMist 기술 설명

배포 프로세스와 런타임 모니터링은 기술적 위험 관리를 위한 규제 프레임워크의 직접적인 확장으로, 취약점 원천 차단 및 운영 위험의 지속적인 모니터링을 강조합니다. 배포 전 감사는 스마트 계약을 중요 인프라로 취급하고 단위 테스트, 독립적인 감사, 코드 동결 등 여러 단계의 검증을 통해 결함이 없음을 보장해야 합니다. 이는 스테이블코인의 발행, 상환 또는 일상 운영에 영향을 미치는 코드 결함이나 취약점 악용을 방지하기 위해 규제 당국이 "신뢰도 높은" 표준을 추구한다는 것을 보여줍니다. 런타임 모니터링은 실시간 위협 탐지에 중점을 두고, 개인 키 사용 모니터링(예: 행동 분석)과 위협 인텔리전스 분석을 결합하여 폐쇄 루프 대응 메커니즘을 구축합니다. 이는 사고 관리 프레임워크의 요구 사항을 충족할 뿐만 아니라 시스템이 새로운 위험에 동적으로 대응할 수 있도록 보장합니다. 전반적으로 이 부분의 기술 구현은 추적 가능한 감사 추적을 위해 온체인 및 오프체인 도구를 통합하여 수동적인 방어를 능동적인 규정 준수로 전환해야 합니다.

구현 가이드

정식 배치에 앞서 "배치 전 체크리스트"를 개발하고 엄격히 따라야 합니다.

• 종합 테스트: 단위 테스트 범위가 95% 이상이고, 핵심 코드 범위가 100%인지 확인하고, 단위 테스트 범위 보고서가 출력되도록 합니다.
• 독립 감사: 평판이 좋은 감사 회사에서 최소 1개, 바람직하게는 2개의 독립 보안 감사 보고서를 작성하세요.
• 코드 동결: 감사가 완료된 후 코드는 온라인에 공개될 때까지 동결되며, 코드는 변경되지 않습니다.
• 회귀 테스트: 공식 배포 전에 단위 테스트와 회귀 테스트를 수행합니다.
• 규정 준수 승인: 내부 규정 준수 팀으로부터 공식적인 승인을 받아 계약 논리가 모든 관련 규제 요구 사항을 충족하는지 확인합니다.
• 배포 훈련: 자세한 배포 스크립트를 준비하고 메인넷 환경과 정확히 동일한 테스트넷에서 전체 배포 훈련을 수행합니다.
• 승인된 배포: 최종 배포 작업은 승인된 지갑에 의해 수행됩니다.

배포 후에는 적절한 모니터링 조치를 구현하여 권한 있는 역할의 사용을 모니터링하고 새로운 위협에 대한 완화 조치를 구현해야 합니다.

• 체인 내 활동 모니터링: 관리 역할의 사용을 모니터링합니다(예: SlowMist 보안 모니터링 시스템인 MistEye를 사용하여 주요 역할 활동 모니터링을 추가). 이를 통해 적시에 승인되지 않은 상황을 감지합니다.
• 위협 인텔리전스 모니터링: 새로운 위협은 신속히 감지해야 합니다(예: SlowMist 보안 모니터링 시스템인 MistEye의 위협 인텔리전스 구독 사용). 또한 위협 인텔리전스를 분석하여 적절한 시기에 완화 조치를 구현해야 합니다.

3. 사업 연속성 및 종료 계획에 대한 기술 지원 제공

규제 지침

허가받은 스테이블코인 사업체는 "허가받은 스테이블코인 사업의 질서 있는 정리를 위한 사업 종료 계획"을 마련해야 합니다.29 이 계획에는 준비금 자산을 청산하고 보유자에게 수익을 분배하는 절차가 포함되어야 합니다.

SlowMist 기술 설명

즉, 스마트 계약은 설계 초기부터 자체적인 "폐기" 프로세스를 고려해야 하며, 질서 있는 종료를 가능하게 하는 상태와 메커니즘을 갖춰야 합니다. 종료 메커니즘이 필요하다는 것은 스마트 계약의 수명 주기가 배포 시점에 끝나는 것이 아니라, 명확하게 정의된 프로토콜 수준의 "수명 종료" 프로토콜을 가져야 함을 의미합니다. 이는 "영구" 계약 구축에 익숙한 많은 개발자에게 새로운 개념이며, "종료를 위한 설계"라는 사고방식을 촉진하기도 했습니다. 질서 있는 청산 프로세스는 종료 시점에 누가 무엇을 소유하는지에 대한 명확하고 최종적이며 논쟁의 여지가 없는 기록을 필요로 합니다. 거래가 여전히 진행 중인 혼란스러운 상태에서 종료가 수행된다면 이러한 목표를 달성하기 어려울 것입니다. 따라서 계약 상태를 고정할 수 있는 기능은 이러한 규제 요건을 직접적으로 기술적으로 구현한 것입니다. 따라서 온체인 상태는 청산인의 손에 있는 최종적이고 감사 가능한 진실의 원천이 됩니다.

구현 가이드

사업 종료 계획을 수립합니다. 이 계획에는 질서 있는 종료로 이어질 수 있는 다양한 시나리오가 포함되어 있으며 이러한 시나리오의 실제 발생이나 잠재적 발생을 모니터링하기 위한 조치가 포함되어 있습니다.

온체인 종료 프로세스 30:

• 최대의 준비금 자산 청산 이익을 보장하고 전반적인 시장 안정성에 미치는 영향을 최소화하기 위해 모든 토큰 전송을 중단하기 위해 스마트 계약을 중단해야 합니다.
• 환매 기능과 화이트리스트 기능을 활용하여 스테이블코인 보유자가 환매 신청을 제출하도록 지원합니다.

제4부 부록: 규제 요건 교차 참조 표

이 표는 스마트 계약 시스템의 각 기술적 특징을 이를 규정하는 특정 규제 텍스트에 직접적으로 매핑한 것입니다.

관련 자료

[1] 홍콩 금융관리국(2025년 5월 26일). 규제 대상 스테이블코인 활동에 대한 자금세탁방지(AML)/테러자금조달(CFT) 요건 제안에 대한 협의 문서. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf

[2]홍콩 금융관리국(2025년 5월).허가받은 스테이블코인 발행자 감독에 관한 지침 초안. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf

참고문헌

[1]허가받은 스테이블코인 발행자 감독지침 초안에 대한 협의.pdf, p. 21, 6.5.5

[2]허가받은 스테이블코인 발행자 감독지침 초안에 대한 협의.pdf, p. 21, 6.5.5

[3]허가받은 스테이블코인 발행자 감독지침 초안에 대한 협의.pdf, p. 20, 6.5.3

[4]허가받은 스테이블코인 발행자 감독지침 초안에 대한 협의.pdf, p. 20, 6.5.3

[5]허가받은 스테이블코인 발행자 감독지침 초안에 대한 협의.pdf, p. 21, 6.5.4

[6]규제된 스테이블코인 활동에 대한 제안된 AMLCFT 요구 사항에 대한 협의 문서.pdf, p. 13, 3.6.2

[7]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 20, 6.5.3

[8]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 21, 6.5.4

[9]허가받은 스테이블코인 발행자 감독지침 초안 협의.pdf, p. 10, 3.1.1

[10]허가받은 스테이블코인 발행자 감독지침 초안 협의.pdf, p. 12, 3.4.1

[11]규제된 스테이블코인 활동에 대한 제안된 AMLCFT 요구 사항에 대한 협의 문서.pdf, p. 9, 3.2.1

[12]허가받은 스테이블코인 발행자 감독지침 초안 협의.pdf, p. 11, 3.2.3

[13]허가받은 스테이블코인 발행자 감독지침 초안 협의.pdf, p. 11, 3.2.5

[14]허가받은 스테이블코인 발행자 감독지침 초안에 대한 협의.pdf, p. 38, 6.8.2

[15]규제된 스테이블코인 활동에 대한 제안된 AMLCFT 요구 사항에 대한 협의 문서.pdf, p. 13, 3.6.2

[16]규제된 스테이블코인 활동에 대한 제안된 AMLCFT 요구 사항에 대한 협의 문서.pdf, p. 11, 3.4.2

[17] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 20, 6.5.2

[18]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 21, 6.5.5

[19]허가받은 스테이블코인 발행자 감독지침 초안 협의.pdf, p. 51, 8.1.1

[20] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 22, 6.5.8

[21] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 23, 6.5.8(ii)

[22] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 23, 6.5.8(iv)

[23]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 22, 6.5.8(ii)

[24]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 24, 6.5.8(vii)

[25]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 25, 6.5.8(x)

[26] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 21, 6.5.5

[27] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 24 6.5.8(ix)

[28] 라이센스가 있는 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 34 6.5.20(ii)

[29]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 42, 6.8.16

[30]허가받은 스테이블코인 발행자 감독 지침 초안에 대한 협의.pdf, p. 42, 6.8.16