김훈 AWS코리아 솔루션즈 아키텍트

[컴퓨터월드]

김훈 AWS코리아 솔루션즈 아키텍트
김훈 AWS코리아 솔루션즈 아키텍트

김훈 AWS코리아 솔루션즈 아키텍트는 금융 고객의 클라우드 도입을 위한 기술 지원을 하고 있으며 웹3, 애플리케이션 현대화에 대한 기술적 관심을 고객들과 나누고자 ‘현대화 프리퀼(Modernization Prequel)’ 이니셔티브에 참여하고 있다.

STO란 시큐리티 토큰 오퍼링(Security Token Offerings)의 약자로 자산에 대한 소유권을 가진 토큰(Security Token)을 발행하는 것을 말한다. 금융위원회는 2023년 1월 금융규제혁신회의에서 ‘증권형 토큰의 발행·유통 규율체계’를 규제 혁신 안건으로 심의하고 국내 STO의 제도권 편입 계획을 발표했다.

이후 가이드라인은 자본시장법상 증권을 분산원장 기술(Distributed Ledger Technology)로 디지털화(Digitalization)한 것으로 정의해 자본시장법 규율 대상으로 규정했다.

더불어 토큰 증권의 발행 및 유통을 허용함으로써 최근 출현한 다양한 권리의 증권화를 지원하고, 분산원장 기술 활용으로 기존 증권의 발행과 거래도 더욱 효율적이고 편리하게 개선하려 한다는 목표를 제시했다.

토큰 증권의 개념 (출처: 금융위원회 토큰증권 가이드라인)
토큰 증권의 개념 (출처: 금융위원회 토큰증권 가이드라인)

시장에서는 부동산, 미술품, 금 등 실물 및 금융 자산을 블록체인 기반의 증권 토큰에 연동하기 위해 비즈니스적, 기술 협의체를 만들어 합종연횡 중이다. 특히 국내 증권사들은 중장기 사업을 위한 플랫폼 구축을 계획하고 있으며, 실물 자산을 보유한 기업들도 관심을 보이며 주로 토큰 발행에 초점을 맞추고 있다.

아직까지는 후속 규제의 부재로 규제 샌드박스에 적용을 받는 일부 조각 투자사에 의해 제공되는 투자 상품에만 한정적으로 허용되고 있다.

그러나 규제 당국에서 토큰 증권 시장을 육성하고자 법제화와 관련된 여러 논의를 진행 중인 만큼 입법에 대한 불확실성은 해소될 것으로 보인다. 토큰 증권 유통을 위한 시스템 설계를 위해서는 분산원장 기술, 즉 블록체인에 대한 이해가 선행돼야 하고, 기존 증권 시스템과 연동 방안을 세우는 것도 고민해야 할 부분이다.

여기에서는 블록체인 관점에서 토큰 증권을 준비하는데 고려해야 할 기술적 요소들을 살펴보고자 한다.


유형- 퍼블릭 블록체인, 프라이빗 블록체인, 컨소시엄 블록체인

특정 과업 달성을 위한 블록체인의 유형을 선택할 때 선행돼야 할 검토사항은 과연 블록체인이 이 과업 달성에 적합한가이다. 구체적으로 이야기하면 ‘이 과업이 데이터에 대한 불변성을 요구하는가’다. 모든 과업에서 데이터는 읽을 수 있고, 쓸 수 있어야 한다. 어느 시스템에서든 데이터는 변경 가능하다.

그러나 블록체인은 태생적으로 데이터의 수정과 삭제가 불가능하고 데이터 변경에 대한 추가 기록만 남길 수 있다. 그러므로 목표 과업이 데이터의 수정과 삭제가 필요하다면 블록체인은 적합한 기술이 아니라는 의미가 된다. 금융 원장이라면 거래 내역이 더 이상 수정되거나 삭제되지 않아야 하므로 부합한다고 볼 수 있다.

다음으로는 ‘과업이 다룰 데이터가 디지털상에서 여러 기업이나 개인끼리 공유할 수 있는 네트워크가 필요한가’다. 이러한 네트워크가 필요하다면 그다음은 신뢰할 수 있는 정제된 데이터와 자동화가 도움을 줄 수 있는지, 다수의 참여가 필요한지, 참여자들 간의 권리는 동등한지, 기대 성능은 어느 정도 인지 검토해야 한다. 만약 이러한 요건을 필요로 하지 않는다면 기존 데이터베이스(DB)를 사용하는 시스템을 고려하는 것이 바른 방향이다.

그 다음으로 과업이 퍼블릭 블록체인과 프라이빗 블록체인 등 어떤 유형의 블록체인에 적합한지 고려해야 한다. 퍼블릭 블록체인은 비허가형 네트워크를 구성하므로 참여자를 특정하지 않고 누구나 참여할 수 있다. 따라서 트랜잭션의 데이터가 누구에게나 공유되기 때문에 참여자의 익명성을 어떻게 보장하느냐가 중요한 화두가 된다. 누구나 참여하여 읽기 쓰기가 가능하므로 혁신의 동력이 될 수도 있다.

금융 서비스에 대한 열린 접근성이 필요한 탈중앙화 금융(디파이, DeFi)이나 디지털 자산에 대한 소유권, 고객 관여 마케팅에 활용하는 대체불가 토큰(NFT)이 사용 예시다. 다만 다수의 참여로 인해 처리 속도가 느리다는 단점도 있다. 비트코인, 이더리움이 대표적인 퍼블릭 블록체인이다.

반면 프라이빗 블록체인의 경우 네트워크에 참여하기 위해서는 허가가 필요하다. 누가 참여할 것인지 미리 결정할 수 있어야 하고, 참여 멤버가 누구인지 무엇을 할 것인지, 무엇을 할 수 있는지와 같은 내용을 설계에 반영해야 한다. 이렇게 결정된 멤버들끼리 보안성이 강화된 네트워크를 구성하는 것이 프라이빗 블록체인이라 할 수 있다. 프라이빗 블록체인의 장점은 참여 멤버에 대한 세밀한 권한 설정과 접근제어를 할 수 있다는 것과 참여 멤버들 사이에서 비공개 데이터, 개인정보, 금융과 같은 민감 정보를 취급하는 등 기업 환경에 필요한 고급 기능을 다룰 수 있다는 점이다.

또한 참여 멤버들끼리 상호 신뢰할 수 있기에 좀 더 효율적인 합의 알고리즘을 선택해 성능 효율성을 높일 수 있는 장점이 있다. 하이퍼레저 패브릭(Hyperledger Fabric)이 대표적인 프라이빗 블록체인이다.

금융위원회의 STO 가이드라인에 따르면 다수가 참여하고, 노드의 51% 이상이 다른 금융 기관 등으로 구성되는 컨소시엄 블록체인을 사용할 것이며, 권리자 및 거래정보 기록을 위해 별도의 가상자산을 필요로 하지 않을 것을 언급하고 있다. 컨소시엄 블록체인은 프라이빗 블록체인의 일종으로, 여러 기관이 블록체인의 구성원으로서 공동으로 컨소시엄에 참여하는 형태다. 인가나 권한 등에서 프라이빗 블록체인의 그것과 유사한 정책을 취하게 된다.

권리자 및 거래 정보 기록을 블록체인 용어로 트랜잭션이라 한다면, 그 과정에서 가상자산을 필요로 하지 않는다는 것은 무엇을 의미할까. 블록체인은 단순히 코인 전송뿐만 아닌 특별한 일들을 수행할 수 있다. 이 작업 과정을 스마트 콘트랙트(Smart Contract)라 하며 스크립트나 프로그램 언어로 작성할 수 있다. 물론 비트코인에는 스마트 콘트랙트가 도입되지 않았으므로 이와 같은 다양한 일들을 할 수 없고, 스크립트를 사용해 제한된 형태의 작업만 가능하다.

그런데 블록체인의 합의 과정은 네트워크에 참여하는 참여자 모두가 동일한 코드를 수행해 결과가 일치한다는 것을 기록으로 남기는 과정의 연속이다 보니, 누군가가 코드를 종료하지 못하도록 작성된 코드로 만든 트랜잭션을 제출하게 되면 전체 네트워크가 무한 루프에 빠지는 문제를 수반하게 된다. 이것을 막기 위한 장치로 비트코인은 스크립트가 튜링 불완전성을 띄도록 설계해 포 루프(For Loop) 구문을 쓸 수 없게 했다.

이더리움은 스마트 컨트랙트의 자유도와 활용도를 높이기 위해 루프(Loop) 구문을 허용하지만, 각 코드가 수행될 때 일정 비용을 지불해 최대 비용에 도달하면 실패하도록 가스(Gas)라는 장치를 두게 됐다. 하이퍼레저 패브릭의 경우에는 노드제이에스(NodeJs), 고언어(GoLang), 자바(Java)와 같은 범용 언어를 사용해 스마트 콘트랙트와 유사한 개념의 체인코드(Chain Code)를 작성하며, 가스와 같은 제한 장치를 두지 않고 있다.

제한된 멤버들이 참여하므로 네트워크를 마비시킬 수 있는 악성코드를 작성하지 않을 것이라는 기대와, 배포 과정에서도 멤버 간의 합의가 필요하고, 또 배포된 코드도 다시 회수하거나 새로운 버전으로 변경이 가능하므로 이러한 장치들이 불필요하기 때문이다.

개발 환경 관점에서 볼 때 비트코인과 이더리움은 개별 스크립트와 개발 언어로 네트워크의 안정성을 보장하는데, 개발자에게는 새로운 언어를 배우는 시간이 필요하게 된다. 블록체인에 대한 관심도가 높아짐에 따라 관련 서적이나 인터넷상에서 참조할 만한 코드도 많아지고 있지만, 잘못 삽입된 코드가 사고를 일으키는 경우도 발생하는 등 학습곡선이 완만하지는 않다.

하이퍼레저 패브릭은 범용 언어를 지원하지만 주로 기업 환경에서 많이 사용되므로 참조할 만한 자료가 비교적 적지만, 이 또한 리눅스 재단의 오픈소스 과제로 운영되고 있어 관련 자료가 부족하지는 않다. 두 경우 모두 지속적 통합 및 지속적 배포(CI/CD) 과정에서 다양한 층위의 테스트가 이루어지도록 보완할 필요가 있다.


암호화폐, 코인 그리고 토큰

블록체인의 가장 큰 오명은 암호‘화폐’로 인식되고 투자를 넘어 투기의 대상이 된 것에서 비롯한다. 나카모토 사토시가 처음 비트코인을 내어놓을 때는 이것을 P2P 거래 목적으로 사용하고자 함이었다. 흔히 비트코인 백서로 알려진 ‘비트코인: 개인 간 전자 화폐 시스템(Bitcoin: A Peer-to-Peer Electronic Cash System)’의 제목이 시사하듯 개인 간의 직접 거래를 위한 전자적 화폐 시스템 개발이 목적임을 밝히고 있다.

기존의 중앙화된 시스템은 시스템을 유지하기 위한 동인이 명확하다. 시스템에 대한 소유주가 있고 운영 주체와 목적이 있기 때문이다. 그러나 블록체인은 명확한 소유주를 두지 않고 탈중앙화하는 것이 목적이다. 개개인의 선한 의지에 기대해야 하므로 경제적인 인센티브가 필요했다. 비트코인은 블록체인이라는 인프라를 P2P 거래 목적으로 정의하고 있고, 이 블록체인 인프라를 운영하기 위한 인센티브로 암호화폐의 유통을 허용했다.

반면 이더리움은 블록체인이라는 인프라 위에 애플리케이션의 확장을 위해 스마트 콘트랙트 개념을 도입했고 이것을 통해 토큰을 발행할 수 있게 했다. 이더리움은 인프라에 대한 인센티브로서 코인을, 그리고 애플리케이션 확장을 위한 인센티브로서 토큰을 제공할 수 있게 한다. 이러한 관점에서 볼 때 토큰 증권은 퍼블릭 블록체인과 달리 컨소시엄 블록체인의 형태를 띄므로 시스템을 유지하기 위한 인센티브로 도입된 코인이나 토큰이 필요하지는 않을 것이다. 오히려 공동 설계해 참여한 블록체인 네트워크의 비용을 어떻게 분담할 것인가가 화두가 될 수 있다.


STO와 관련된 토큰 표준안

블록체인은 오픈소스로 커뮤니티가 중심이 돼 발전하는 프로젝트가 많다 보니, 블록체인 개선 논의도 오픈소스처럼 공유된다. 이더리움의 경우 이더리움 개선 제안(EIP, Ethereum Improvement Proposal)에 제출된 순서에 따라 숫자를 붙이게 되고, 논의 및 승인이 진행되면서 이더리움 의견 요청(ERC, Ethereum Requests for Comments) 단계가 돼 실질적인 표준으로 인정받는다.

이 대표적인 사례가 ERC-20, ERC-721과 같은 토큰 표준안이다. 다만 이것은 표준안이므로 구현의 실체보다는 인터페이스 설계에 초점이 맞춰졌다. ERC-20과 721의 기준에 맞춰 스마트 콘트랙트를 작성해 이것을 트랜잭션으로 제출하면 비로소 토큰이 실체화되는 것이다. 흔히 하이퍼레저 패브릭에는 토큰이 없다고 이야기하는데, 엄밀히 말하면 토큰에 대한 표준이 없을 뿐이지 애플리케이션에서 필요로 하는 토큰에 대한 인터페이스를 설계하고 구현하게 되면 토큰처럼 사용할 수 있다. 다만 퍼블릭 블록체인처럼 누구나 참여하는 토큰은 아니므로 유통이 되거나 할 수는 없다.

토큰증권과 관련해 주로 언급되는 표준안은 ERC-1400, ERC-3643 등이 있다. 토큰증권에는 기술적인 요건도 필요하지만, 규제나 비즈니스에서 필요로 하는 요구사항들이 표준안에 포함될 것이다. 가령 발행 조건이나 이익 배분에 관한 문서를 첨부할 수 있는 기능, 공급량을 제한하거나 조절할 수 있는 기능, 토큰의 발행을 통제하는 기능 등이 그것이다. ERC-1400이 이런 요건들을 담고 있고, ERC 3643의 경우 신원 인증에 대한 요구사항을 담고 있는 특징이 있다.


무엇을, 어떻게 저장할 것인가

블록체인의 가장 큰 특징은 데이터의 불변성이다. 다만 이것은 양날의 검과 같아 한 번 쓰인 데이터는 삭제나 변경이 불가능하다는 문제를 가지고 있다. 먼저 유럽의 GDPR(General Data Processing Regulation)이나 국내 개인정보보호법에서는 개인정보의 삭제 권리를 규정하고 있다. 국가나 지역에 따라 규제에 의해 데이터를 반드시 삭제해야 하는 경우가 있는 것이다.

원장에 저장된 데이터는 한번 쓰이면 삭제할 수 없으므로 어떤 데이터를 남겨야 할지 그리고 이 데이터가 개인정보 등을 포함하고 있는지 고려해야 한다. 한 가지 힌트라면 프라이빗 데이터(Private Data)와 유사하게 데이터의 해시값을 원장에 남기고 민감 데이터는 별도 보관하는 것도 생각해 볼 수 있다. 그렇다고 민감 정보만 아니면 다 남겨도 되는 것은 아니다. 블록체인은 DB도 아니고, 오브젝트 스토리지도 아니기 때문이다. 가령 이미지를 권리로 삼는 NFT가 있다면 이미지 파일은 IPFS(InterPlanetary File System)와 같은 공간에 저장하고, 부여받은 컨텐츠 식별자(CID) 값만 남겨 블록체인 원장에 기록하면 될 것이다. 결국 꼭 써야 할 데이터가 무엇인지를 식별하는 것이 중요하다.

하이퍼레저 패브릭에서 모두가 공유되는 원장에는 해시(Hash) 값만 남기고, 프라이빗 스테이트(Private State)로 실제 데이터가 공유된다. (출처: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html)
하이퍼레저 패브릭에서 모두가 공유되는 원장에는 해시(Hash) 값만 남기고, 프라이빗 스테이트(Private State)로 실제 데이터가 공유된다. (출처: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html)

한편, 분산원장이라는 개념에서 볼 때 원장에 쓰여진 데이터는 네트워크에 참여한 누구나 볼 수 있다는 점도 문제가 될 수 있다. 가령, A사와 B사만의 계약에 의해 거래가 진행되는 경우 제3자인 C사는 이 거래에 대해 알 필요도 없지만 알아서도 안 될 것이다. 이에 대해 하이퍼레저 패브릭에서는 두 가지 방식을 제안한다.

첫 번째는 채널 기능을 제공해 컨소시엄 내에서도 다시 특정 멤버들만 참여해 트랜잭션을 주고받을 수 있도록 제한한다. 다른 한 가지는 매번 채널을 만들지 않더라도 원하는 멤버끼리 데이터를 주고받을 수 있도록 암호화한 데이터(Private Data)를 공유하고, 채널에는 이 데이터의 해시값만 남겨 블록체인에 이 기록을 남기는 것이다. 채널을 만드는 방법의 경우 새로운 소그룹이 만들어질 때마다 새로운 채널을 만들어야 하므로 운영 및 관리가 어려워지는 단점이 있는 반면, 채널에서 공유되는 데이터를 타 채널 참여자가 볼 수 없으므로 보다 보안성을 높일 수 있다. 후자인 프라이빗 데이터(Private Data)의 경우 멤버 노드 간에 데이터 전송은 Gossip 프로토콜을 이용하므로 손쉽게 전송이 가능하다.

반면 어떤 암호화 키를 사용하고 어떻게 공유할 것인가의 문제를 고려해야 한다는 단점이 있지만, 다수가 참여하는 채널에서 또 다른 채널을 구성하지 않고도 일부에게만 암호화된 데이터를 공유할 수 있다는 편의성도 제공한다.


완결성(Finality), 단일 지식 공급원(Single Source of Truth)

블록체인에서 발생한 거래는 멤버들이 원장에 공유하지만, 블록체인이 보유한 데이터를 읽어서 활용할 때는 또 다른 고민이 필요하다. 일반적인 시스템에서는 원하는 비즈니스 로직을 수행하기 위해 데이터베이스를 이용하는데, 여기서는 트랜잭션으로 데이터를 입력하거나 수정, 삭제하는 쿼리를 묶고 모든 쿼리 수행이 완료되는 순간 적용된다.

반면 퍼블릭 블록체인은 이 과정을 합의라 부르며, 설계상 더 이상 변경될 가능성이 없다고 여길 만큼 블록이 체인에 새로 추가되면 트랜잭션 처리가 완료됐음을 인정하게 된다. 새로운 블록을 생성하는 합의의 기준을 누가 먼저 달성했느냐에 따라 다른 블록이 생성되기 때문이다. 더구나 더 긴 체인이 발견되면 짧은 체인은 버려지게 되므로(전복), 내가 작성한 트랜잭션이 포함된 체인이 버려지게 되면 그 트랜잭션이 무효가 될 수도 있다. 더 이상 변경될 가능성이 없다는 것은 ‘이 정도 길이의 체인이 나오면 확률적으로 안정적이다’라고 판단하는 것인데, 이것을 완결성(Finality)이라 한다. 이것은 정해진 기준이 있는 것은 아니나, 흔히 비트코인에서는 6블록, 이더리움은 PoS(Proof of Stake) 적용 이후 64블록 이후에 완결(Finalized)됐다고 이야기한다.

반면 프라이빗 블록체인인 하이퍼레저 패브릭의 경우, 멤버가 트랜잭션을 제출하면 이것은 네트워크상에 하나만 있는 오더러(Orderer)의 큐에 들어가고, 이후 오더러가 설정한 시간이나 블록당 트랜잭션 수와 같은 기준에 따라 블록을 생성하게 된다. 따라서 완결성 이슈로부터 상대적으로 자유롭기 때문에 오더러가 생성한 블록은 전복되지는 않는다. 요지는 블록체인의 합의 알고리즘에 따라 트랜잭션의 완성 시점이 달라진다는 것이다.

블록체인을 활용한 시스템 아키텍처 예시
블록체인을 활용한 시스템 아키텍처 예시

다음으로 생각할 점은 멤버 간의 데이터 공유가 이루어지는 블록체인 노드의 위치가 시스템의 내부이면서도 외부라는 점이다. 전통적인 3티어 아키텍처에서는 모든 데이터를 시스템의 가장 깊은 곳에 놓인 DB에 보관하고 이것이 단일 지식 공급원(Single Source of Truth)이 된다.

블록체인은 이 지식 공급원이 블록체인 네트워크상의 멤버들이 만들어 낸 블록이 되므로 시스템의 바깥에 있으면서도 나 또한 멤버이므로 안에 있는 것과 같다. 더불어 블록체인 노드에서는 대량의 데이터를 읽거나 분석하기 어렵기 때문에 시스템에서 블록체인을 활용하기 위해서는 생성된 블록을 받아 관계형 DB나 NoSQL DB에 적재하게 된다.

관련된 AWS의 서비스로는 아마존 오로라(Amazon Aurora)나 아마존 RDS(Amazon Relational Database Service)와 같은 관계형 DB, 아마존 다이나모DB(Amazon DynamoDB)로 대표되는 NoSQL DB가 있는데, 이런 데이터를 다룰 서비스는 기존 3티어 아키텍처의 경우와 마찬가지로 가장 내부의 프라이빗 서브넷(Private Subnet)에 위치시키고, 블록체인 노드는 외부와 인터넷 통신이 가능한 퍼블릭 서브넷(Public Subnet)에 두거나 전용망을 통해 타 노드와 접근할 수 있게 하는 별도의 망 구성 설계가 필요하다.


월렛, 키 관리

블록체인의 근간을 이루는 또 다른 한 축으로 암호화 기술이 있다. 전자서명과 해시가 그것이다. 퍼블릭 블록체인이든 프라이빗 블록체인이든 참여자는 각자의 암호화키를 가지고 네트워크에 참여하게 된다. 이때 ECC(Elliptic Curve Cryptography)와 같은 공개키 암호화(또는 비대칭암호화) 방식을 사용하게 되며, 참여자는 임의로 생성한 시드(Seed)에서 유도된 개인키(Private Key)와 공개키(Public Key)를 암호화키로서 사용하게 된다.

은행 통장에 계좌번호와 비밀번호가 있듯 공개키는 해시와 약간의 알고리즘을 거쳐 은행 계좌번호와 유사한 개념인 고유의 주소(월렛 주소)를 만들며 이 월렛에 있는 잔고를 이용할 때는 비밀키가 은행 비밀번호처럼 작용해 트랜잭션을 만든다. 은행에서 계좌 비밀번호를 노출하지 말라고 하는 것처럼, 블록체인에서도 마찬가지로 개인키를 노출해서는 안 된다.

은행 시스템에서는 오송금된 경우라도 적법한 사유가 있다면 절차에 의해 돌려받을 수 있지만, 블록체인에서는 되돌릴 수 없기 때문이다. 가끔 발생하는 암호화폐 유출 사고도 대부분 이 개인키가 유출되는 데에서 기인한다. 그래서 블록체인에서는 콜드월렛(Cold Wallet) 형태로 보관하는 것을 권고한다.

콜드월렛은 별도의 물리적 저장장치(하드웨어 월렛)에 개인키를 보관하므로 보안성 측면에서 안전하지만, 즉각적인 거래가 불가능하다는 단점이 있다. 또한 하드웨어 월렛을 분실하거나 고장나는 경우 복구가 어렵다는 단점도 있다. 콜드월렛과 대비되는 개념인 핫월렛(Hot Wallet)은 인터넷과 연결된 서버상에 키를 보관하게 되는데, 거래는 손쉽게 만들 수 있지만 보안 사고 시 탈취 가능성이 높다는 단점이 있다. 콜드월렛을 사용하는 것이 가장 권장되지만 현실적이지는 않다.

그 대안으로 디지털 자산 수탁(커스터디, custody)을 생각해 볼 수 있다. 커스터디란 투자자가 자산의 보관·관리를 제3자에게 맡기는 것을 말하는데, 트랜잭션을 생성할 때 사용자의 키와 수탁사의 키를 함께 서명하도록 하거나(Multi-Sig), 키를 나눠 갖는 방식(MPC, Multi-party Computation)을 이용한다면 키 보관과 보안 사고에서 조금 더 안전한 방식이 될 수 있을 것이다. 마치 금고를 여는 열쇠가 하나만 있지 않고 복수의 키로 동시에 열어야 금고 문이 열리는 것과 유사하다.

AWS에도 AWS 키 매니지먼트 서비스(AWS Key Management Service), AWS 클라우드HSM(AWS CloudHSM)과 같은 다양한 방식의 관리형 서비스를 제공해 암호화키를 보관, 운영할 수 있도록 도와주고 있다. 다만 대부분의 서비스에서 키를 생성하는 개수에 한계를 두고 있기 때문에 대고객용 키를 발급하기에는 어려운 점이 있다. 대안 중의 하나로 증권사의 키는 AWS 클라우드HSM에 보관해 고객의 키와 증권사의 키를 모두 서명하도록 하는 멀티시그 방식을 고려해볼 수 있다.


트랜잭션 서명 과정의 격리

블록체인에서 트랜잭션이 만들어질 때는 앞서 언급한 개인키로 트랜잭션을 서명하고 이것을 포함한 전문을 네트워크에 전송하게 된다. 전자서명 과정에서 트랜잭션의 무결성과 부인방지를 보장했는데 트랜잭션을 서명하는 순간 키가 노출된다면 어떻게 될까.

현대 컴퓨팅에서는 물리적 또는 논리적으로 격리 공간을 제공해 이런 상황에 대처할 수 있게 도와준다. 일반 애플리케이션이 구동되는 컴퓨트 영역과 격리된 별도의 환경에서 보안이 중요한 애플리케이션을 호스팅해 외부와 직접 연결되지 않으므로 키가 유출되는 등의 보안 사고를 예방할 수 있다는 장점이 있다. 애플리케이션 영역에서는 월렛과 관련된 인터랙션을 처리하고, 격리 영역에서는 트랜잭션 서명 등 보안 측면에서 민감한 작업만 하도록 역할을 나누어 설계한다.

AWS 니트로 엔클레이브(AWS Nitro Enclaves) [출처: https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html]
AWS 니트로 엔클레이브(AWS Nitro Enclaves) [출처: https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html]

AWS의 대표적인 컴퓨트 서비스인 아마존 EC2(Amazon EC2)에서는 민감한 데이터를 추가로 보호하고 안전하게 처리할 수 있도록 격리된 컴퓨팅 환경을 생성할 수 있는데, AWS 니트로 엔클레이브(AWS Nitro Enclaves)가 그것이다. 니트로 엔클레이브는 소프트웨어에 대한 암호화 증명을 포함하고 민감한 자료에 엑세스할 수 있도록 권한이 부여된 코드만 실행할 수 있으며 암호화 키 관리를 도와주는 AWS 키 매니지먼트 서비스와 통합을 보장한다. 따라서 암호화 키 관리에서부터 디지털 서명까지 안전하게 클라우드 환경에서 마무리 지을 수 있도록 해 공격에 노출되는 영역을 크게 줄일 수 있다는 장점이 있다.

지금까지 STO 아키텍처를 설계할 때 고려해야 할 블록체인과 그에 연관된 기술 요소에 대해 알아보았다. 해외 주요 국가들은 이미 STO에 대한 규제를 세우고 인프라를 구축 중인 것으로 알려져 있다.

미국은 투자 계약 요건 기준인 하위 테스트(Howey Test)를 이용해 토큰의 증권성을 판단하고, 디지털 자산이 증권에 해당할 경우 증권과 동일한 규제를 부과하고 있다. 일본은 STO에 금융상품거래법을 적용해 제도권에 편입시켰으며, 업계 주도의 STO 자율규제기관이 STO와 관련된 업계 규칙과 지침을 제정하는 역할을 수행 중인 것으로 전해진다.

국내 기업들도 관련 사업을 추진하며 STO에 대한 기술적 검토와 개념증명(Proof of Concept)을 진행하고 있는 상황이다. 입법의 영역에서 투자자 보호를 위한 안전장치 확보 방안 논의가 이뤄지는 것과 별개로, 기술 영역에서는 기존 시스템과는 다소 다른 접근이 필요한 블록체인의 특성을 고려해 원활한 비즈니스 수행이 이뤄질 수 있도록 다양한 기술적 논의가 계속됐으면 하는 바람이다.

저작권자 © 컴퓨터월드 무단전재 및 재배포 금지