웹 3.0 스택

웹 3.0 스택 구조를 정확하게 보여주는 그림을 아직까지 찾지 못해 본 포스팅을 통해 한 번 그려보려고 합니다. 웹 3.0 생태계는 매우 광범위하기 때문에 아래 그림 역시 최종 버전이라고 보기는 어려우며, 아마도 몇 군데 부정확한 부분도 있을 것입니다.

본 포스팅을 통해 이 도표에서 가장 흥미로운 점들을 자세히 살펴보겠습니다.

코어 스택

Dapp 개발자는 코어 개발 스택에서 정확히 어떤 것들이 필요할까요?

바로 유효 거래를 순서대로 기록한 단일 원장입니다.

이를 위해 P2P, 합의, 스테이트 트랜지션 머신 레이어가 필요합니다. 현재 이더리움과 비트코인은 이 세 가지 기능만 수행하고 있습니다. 이더리움은 서서히 확장되어 나중에는 샤딩까지 포함하겠지만 말입니다.

도표 오른쪽에 나와 있는 선택적 컴포넌트 구축 팀에 비하면 왼쪽에 표시된 컴포넌트를 구축하는 팀은 상대적으로 그 수가 적습니다. 스택 맨 밑에서부터 위로 올라가며 해당 팀들을 살펴보겠습니다. 선택적 컴포넌트는 포함하고 인터넷 프로토콜은 제외했습니다.

• Oasis Labs가 구축한 Ekiden은 다양한 체인이 TEE 기반 비공개, 오프-체인 컴퓨팅을 지원할 수 있도록 하는 중립적인 플랫폼입니다.
• Handshake은 탈중앙화 DNS를 구축하고 있습니다. 하지만 DNS는 시스템 운영체제에 포함되어 있기 때문에 보편적으로 사용되기는 어려울 것 같습니다..
• Monero는 노드 간 프라이버시 보존 패킷 라우팅을 가능하게 하는 Kovri를 구축하여 IP 단에서의 프라이버시 보장을 구현하려고 하고 있습니다. Kovri는 여러 체인을 지원할 예정입니다.
• BloxRoute는 다양한 체인에서 활용될 수 있는 블록 딜리버리 네트워크를 개발 중입니다.
• 이더리움 파운데이션에서는 DevP2P를, 프로토콜 랩에서는 LibP2P를 선보였습니다. 대부분의 신생 체인은 두 프레임워크 중 하나를 채택하고 있습니다. 이더리움이 LibP2P로 이전한다는 소문도 있습니다.
• 이더리움과 Polkadot이 풀-스테이트 샤딩을 개발 중입니다.
• 현재 다수의 팀이 합의 레이어에서 다양한 시도를 하고 있습니다:
• 리더 기반 블록체인 합의
• 비트코인 및 비트코인 캐시 – ASIC 최적화 작업 증명(POW)
• 이더리움 1.0, Monero, Zcash 등 – ASIC 내성 작업 증명(POW)
• Kadena– 브레이드형 작업 증명(POW)
• Chia– 공간 및 시간 증명(POST)과 경과 시간 증명(POET)
• Filecoin– 유용한 데이터에 대한 POST
• 이더리움 2.0 – 캐스퍼 TFG 지분 증명(POS)
• Thunder– 폴백으로 POW를 갖춘 POS
• Decred– POW/POS 하이브리드
• Polkadot– 허니배저 POS
• EOS– 위임 지분 증명(DPOS)
• Tezos– DPOS 변형
• Tendermint- DPOS 변형
• Solona– 기록 증명(POH)
• Dfinity– 임계치 릴레이(Threshold relay) + 확률적 슬롯 합의
• Algorand– 리더를 선출하는 방식의 비잔틴 합의(BA⋆). 리더가 없는(Leaderless) 블록체인 합의
• Ripple 합의 프로토콜
• Stellar 합의 프로토콜
• Avalanche 블록 DAG
• Byteball– Byteball 메인 체인 합의
• Hashgraph– Hashgraph 합의 프로토콜
• DAGlabs– 스펙터(Spectre)
• Blink– Blink 합의 프로토콜
• Spacemesh– 위원회 선출을 위한 POST, 이후 tortoise + hare

주요 스테이트 트랜지션 머신은 다음과 같습니다. 이더리움 1.0, 이더민트, Hashgraph, WANchain 등의 이더리움 가상 머신(EVM)과 Dfinity, EOS, Polkadot, 이더리움 2.0과 같은 웹 어셈블리 가상 머신(WASM), Cardano, Solona 등의 직접 LLVM 노출 방식 등이 있습니다.

커스텀 스테이트 트랜지션 머신에는 Kadena, Tezos, Rchain, Coda가 포함됩니다.

리스트를 훑어보면 이런 질문이 떠오릅니다. 코어 스택의 다른 레이어에 비해 유독 합의 레이어에 개발 팀이 몰리는 이유는 무엇일까요?

답은 간단명료합니다. 가장 많은 돈을 벌 수 있는 영역이기 때문입니다.

그렇다면 왜 합의 레이어에 대부분의 가치가 축적되는 것일까요?

블록체인 내에서 최대의 단일 병목이 바로 합의 레이어에서 발생합니다. 그리고 합의 방식들은 기본적인 트레이드-오프에 얽매일 수밖에 없습니다. 나아가 합의 방식은 상호 배타적입니다. 하나의 체인에 두 개의 합의 방식을 동시에 적용할 수 없죠. 전 세계적으로 손꼽히는 프로토콜 디자이너들은 이러한 비트코인 POW의 한계를 정확하게 이해하고 거대한 글로벌 디지털 준비 자산을 준비하고 있습니다. 앞으로 가치가 수십 조에 달할 시장에서 이미 경쟁을 시작한 것입니다.

블록체인 확장성 트릴레마 때문에 본질적인 파레토 개선을 달성한 합의 알고리즘은 아직까지 구축되지 않았다고 봐야 합니다. 합의 레이어에서 혁신을 꾀하는 대부분의 개발 팀은 목표하는 활용성에 최적의 트레이드-오프 세트를 채택했다고 믿고 나아가고 있습니다.

만약 어떤 한 팀이 기본적인 파레토 개선을 달성하는 매커니즘을 개발한다고 해도, 이를 어떻게 확인할 수 있을까요? 가장 쉬운 답은 특정 블록 생성 탈중앙화 정도에서의 처리량을 정량화하는 것입니다. Dfinity와 Algorand, Solana는 이러한 방법이 가능하다는 의견이지만, Vitalik은 동의하지 않는 듯 합니다.

합의 알고리즘의 복사 가능 여부는 아직 논의와 고민이 필요해 보입니다. 기술적으로 보면 충분히 가능하지만(Cosmos의 Tendermint-EVM) 기존 체인의 합의 알고리즘을 바꾸는 것이 정치적으로는 불가능할 수 있으며, 밀접하게 결합된 온-체인 거버넌스 기반의 시스템이라면 더욱 그렇습니다. 온-체인 거버넌스가 밀접할수록 기존의 이해관계자들을 설득하는 것이 어렵습니다. 21인의 EOS 블록 생성자 중 한 명에게 모두가 선망하는 자리를 포기하고 한층 더 탈중앙화되어 있으며 동등한 성능을 제공하는 이론상의 체계를 선택하라고 했을 때 과연 설득이 될까요? 이와 같은 이유로 이더리움은 POW를 버리고 POS로 이전할 수 있지만 네이티브 POS 체인은 비슷한 규모의 변화를 지양할 가능성이 높습니다.

합의 레이어가 아닌 스테이트 트랜지션 머신 레이어에서도 제법 많은 시도가 진행되고 있습니다. WASM을 사용하지 않는 개발 팀의 경우 블록체인 스테이트 트랜지션의 역할을 매우 명확하게 정의하고 있습니다.

• Kadena는 스마트 컨트렉트는 사람이 해독할 수 있어야 한다는 입장입니다.
• Tezos는 모든 스마트 컨트렉트를 공식적으로 검증할 수 있어야 한다는 입장입니다.
• Rchain은 스마트 컨트렉트를 Dapp 체인에서 동시에 수행하고 공식적으로 검증할 수 있어야 한다는 입장합니다.
• Coda는 소규모 노드도 체인의 무결성을 검증할 수 있도록 전 과정을 SNARK를 통해 수행하여 최고 수준의 탈중앙화를 영구적으로 유지할 수 있어야 한다는 입장입니다.

스테이트 트랜지션 머신 레이어에서 흥미로운 현상 두 가지를 꼽을 수 있습니다. 첫 번째는 원래 블록체인을 위한 기술이 아니었는데도 불구하고 여러 주요 프로젝트들이 WASM을 사용하기로 합의했다는 사실입니다. 두 번째로 Kadena, Tezos, Rchain, Coda의 핵심 가정이 매우 독특합니다.

크립토의 모든 영역이 오픈 소스 기반이기 때문에 스택 내 각 레이어의 네트워크 효과를 비교해볼 수 있습니다. 예를 들어 이미 임계치에 도달한 EVM의 경우 EVM용으로 개발된 개발자 교육, 개발 툴, 라이브러리 등으로 네트워크 효과가 발생합니다. 이더리움이 EVM에서 탈피하고자 하는데도 불구하고 Hashgraph, Cosmos Ethermint, Wanchain, RSK, Blink와 같은 다른 여러 프로젝트가 EVM을 적용하기로 결정한 것도 이 때문입니다.

사실 스테이트 트랜지션 머신을 체인 간에 옮겨가며 적용할 수 있다는 주장에 동의하지 않습니다. 이더리움 파운데이션조차 더는 EVM을 선호하지 않는 것으로 보입니다. 사견으로는 개발자들이 솔리디티로 코딩하는 것을 기피하는데도 솔리디티를 사용하는 이유는 대부분의 개발자가 탈중앙화된 블록 생성과 오픈 소스 소프트웨어 개발 등의 이더리움 이념을 따르기 때문입니다. 만약 위 가설이 사실이라면 EVM을 채택한 비이더리움 블록체인은 ‘EVM 네트워크 효과’를 누리지 못할 것입니다.

하지만 WASM은 다릅니다. 대부분의 주요 크립토 팀들은 WASM을 구축하고 유지하는 거인들의 어깨 위에 서서 더 큰 성과를 거두고 싶어하기 때문에 스테이트 트랜지션 머신으로서의 WASM을 주축으로 각기 여러 체인에 걸친 네트워크 효과가 발생할 수도 있습니다.

이러한 WASM의 네트워크 효과가 실제로 발생된다면 자체적인 스테이트 트랜지션 머신을 개발 중인 팀들은 장기적인 경쟁에서 뒤쳐질 것입니다.

확장된(Extended) 코어 스택

베이스 레이어에 포함되어 있지 않을 뿐더러 포함되면 안 되는 몇몇 요소들이 있습니다. 아직 Dapp 개발에 있어 필수 요소는 아니지만, 멀티코인은 앞으로 이러한 요소들이 개발 스택의 핵심적인 컴포넌트가 될 것이라고 생각합니다. 스택 밑에서부터 살펴보겠습니다.

• 여러 개발 팀이 사이드체인을 구축 중입니다. 가장 주목받는 비트코인 사이드체인은 drivechains와 Liquid입니다. 이더리움 생태계의 경우 플라즈마 프레임워크 내 SKALE과 자기주권형 Dapp 체인으로서 코스모스 이더민트가 있습니다.

• 비트코인 내에서 결제 채널과 스테이트 채널 네트워크를 구축하려는 개발 팀도 여럿 있는데, 그 중Lightning Labs와 Blockstream이 대표적입니다. 이더리움 생태계의 경우 Raiden과 Celer가 유사한 작업을 진행 중입니다. 많은 팀들, 특히 비트코인 커뮤니티에 속하는 팀들은 이와 같은 방안이 확장성을 확보하기 위한 유일한 방법이라고 생각하고 있습니다.
• 인터레저 프로토콜(ILP)는 몇 달 전 최종 확정되었습니다. 현재 상당수의 개발 팀이 체인 간 상호 운용이 가능하도록 하기 위해 ILP로 작업 중입니다. ILP는 사실 멀티코인을 포함한 대부분의 개발자와 투자자의 관심을 받지 못했습니다. 하지만 ILP가 웹 3.0 스택에서 가장 중요한 레이어가 되어, 그림과 같이 실질적인 커머스는 이더리움과 같이 더 다양한 기능을 구현할 수 있는 체인에서 이루어지고 가치 축적은 BTC와 같은 안정된 체인에서 일어날 가능성은 충분합니다.
• 멀티코인이 아는 바로는 이더리움 내 탈중앙화 쿼리 레이어를 구축하고 있는 개발 팀은 The Graph가 유일합니다. 이전에는 이더리움에서 Dapp을 구축하는 모든 개발 팀이 독자적인 인덱스 인프라를 구축해야 했습니다.
• BigchainDB, OrbitDB, 그리고Bluezelle을 비롯한 다수의 개발 팀이 웹 3.0 도표의 오른쪽 하단에 있는 불변성 정형 데이터베이스를 무허가성 단독 체인 형태로 구축하고 있습니다. 정형 데이터베이스를 사용하면 성능이 확실히 개선되기 때문에 앞으로 개발자들이 이러한 시스템을 플랫폼 상에서 직접적으로 활용할지 혹은 SKALE과 같은 팀들이 이와 같은 오픈 소스 시스템을 플라즈마 체인으로서 활용할지 지켜보는 것도 흥미로울 것입니다.

확장된 코어 스택은 기본 코어 스택보다 훨씬 덜 성숙합니다. 현재까지 다룬 컴포넌트 중 어떤 것도 유의미한 규모로 생산되고 있지 않습니다. 현재로서는 Dapp 개발자들이 컴포넌트를 활발하게 사용할 만한 환경이 갖추어져 있지 않은 상태입니다.

그러나 앞으로 확장된 코어 스택이 점차 성숙해짐에 따라 Dapp개발 속도도 상당히 빨라질 것으로 예상합니다. 이러한 컴포넌트들이 해결하려는 문제들에 대한 고민은 Dapp 개발자의 몫이 아닙니다. 하지만 스택의 현 상태에서는 개발자가 스택 컴포넌트를 직접 구축해야 하는 상황이며, 비효율적인 개발이 이루어지고 있습니다.

선택적 컴포넌트

이메일 전송(Sendgrid)에서부터 문자 메시지(Twilio), 지도(구글 맵스)까지 거의 모든 작업에 대한 클라우드 API가 갖춰져 있듯이, 선택적 탈중앙화 컴포넌트 형태의 ‘탈중앙화 라이브러리’가 엄청나게 많아질 것입니다. Dapp 개발자는 다양한 일련의 고유 기능을 갖춘 컴포넌트를 선택적으로 적용할 수 있습니다.

Livepeer, 0x, Kyber, Stoji, Sia, Oraclize, Civic 등 선택적 컴포넌트 서비스 중 일부만이 메인넷을 출시했습니다. 하지만 이러한 컴포넌트를 구축한 개발 팀 대부분이 아직 실제 활용이 가능한 툴을 출시하지 않은 실정입니다.

부족한 Dapp 숫자를 어느 정도 설명할 수 있는 요인입니다. 유용한 라이브러리 없이는 유용한 Dapp이 만들어지기 어렵습니다. 유용한 라이브러리가 없으면 모든 Dapp은 무에서 유를 창조하는 것과 같은 작업을 거쳐야 하는 것입니다.

이러한 컴포넌트의 대다수가 이더리움 생태계를 위해 구축되고 있다는 사실도 흥미롭습니다. 예를 들어 Keep이나 Truebit과 같은 소수의 개발 팀은 크로스-체인 서비스를 제공하기 위해 Dfinity를 지원하는 방법을 공개적으로 논의하기도 했습니다. 하지만 현 크립토 생태계 내 대다수의 인프라는 EVM, 더 넓게는 이더리움 생태계를 지원하기 위해서 구축되고 있습니다.

향후 일 년 동안 EOS, Tezos, Kadena, Dfinity, Solana, Tari, Hashgraph 및 기타 플랫폼들의 자체적인 체인이 출시되거나 확장되어 가며 Dapp 인프라 컴포넌트를 구축하는 개발 팀의 관심을 얻기 위해 경쟁할 것입니다. 현재로서는 크로스-체인 개발을 매끄럽게 지원하는 툴이 없기 떄문에 코어 체인을 구축하는 개발 팀은 Dapp 인프라 제공자의 채택을 위해 경쟁해야 합니다.

앞서 살펴본 것처럼, WASM과 같은 스테이트 트랜지션 머신의 네트워크 효과는 체인들에 걸쳐 발생할 가능성이 높지만 개발 노력이 더해지지 않으면 100%의 인터 체인 효과를 확보하기는 어려울 것입니다. 베이스 레이어 체인 팀들이 인프라를 막힘없이 다른 체인들에 포팅하는 과정을 수립하여 이더리움에 개발하고 있는 1세대 인프라 개발자들을 유인할 수 있을지 여부는 흥미로운 관전 포인트입니다.

스택의 최상단

대개 스택 도표의 최상단에는 앱이 자리 잡고 있습니다. 하지만 현재 크립토 생태계에서의 개발 노력은 모두 프론트 엔드보다는 백 엔드에 집중하고 있습니다. 그렇기 때문에 Web3스택의 경우 Dapp 상단에 존재하는 요소가 적은 편입니다.

흥미롭게도 암호자산 커뮤니티 내에서는 어플리케이션 호스팅을 탈중앙화하자는 이야기가 거의 나오지 않습니다. 현재 대부분 Dapp의 호스팅 레이어가 중앙화 되어 있다는 점을 고려하면 더욱 의아합니다. 두 가지 이유 중 하나일 것입니다. 1) 앱을 호스팅하는 웹 서버가 중앙화 되어 있기 때문이거나 2) 앱을 다운받아 클라이언트 디바이스에 설치할 때 단일 다운로드 링크를 사용하는데, 이로 인해 생태계가 본질적으로 폐쇄적인 월드 가든(Walled-garden) 모델로 돌아가게 됩니다. 이상적인 세상에서는 어플리케이션 호스트는 탈중앙화 되어 있는 동시에 현대의 웹 어플리케이셔내과 같이 적시에 필요한 데이터를 송수신할 수 있을 것입니다.

그렇다면 왜 탈중앙화 어플리케이션 호스팅을 목적으로 하는 솔루션을 거의 찾아볼 수 없는 것일까요? 이 또한 두 가지 이유 중 하나입니다. 이 레이어의 탈중앙화 여부가 중요하지 않거나 너무 어려운 문제라 누구도 해결하고자 시도해보지 못했거나 입니다. 사견으로는 두 가지 이유 모두 복합적으로 작용했을 것 같습니다.

어떤 Dapp이든 데이터베이스와 자산 스토리지가 적절한 수준으로 탈중앙화되어 있다면 어플리케이션 호스트의 중앙화 여부는 중요하지 않습니다. 만약 정부가 Dapp을 검열하기 위해 어플리케이션 호스트를 종료 시킨다면, Dapp 작성자는 프론트 엔드 코드를 오픈 소스화해 다른 누군가가 동일한 백 엔드로 연결되는 신규 호스트를 만들어주기를 기다리면 됩니다. 2000년대 토렌트 추적 프로그램(Torrent Trackers)의 사례처럼 하나를 폐쇄시키면 다른 데서 5개가 생겨나는 구조가 될 가능성이 높습니다.

만약 어플리케이션 호스트를 탈중앙화할 수 있다면 어떨까요? Ripple이 시작한 오픈 소스 프로젝트 Codius는 2015년에 Ripple이 지원을 중단하기 전까지 이를 시도했었습니다. 최근 Ripple의 전 CTO Stefan Thomas가 Ripple을 떠나 Coil을 시작하면서 Codius 개발이 중단된 부분부터 이어 나가고 있습니다. 앞으로 이 레이어가 실제로는 어떻게 적용될지, 또한 신뢰 가능한 중앙화 어플리케이션 호스트에 기반하는 기존 DNS와의 통합 가능 여부도 흥미롭게 지켜볼만한 부분들입니다.

마지막으로 스택의 최상단에서 최종 사용자들이 직접 교류하는 접점은 Dapp 브라우저입니다. 이더리움의 Metamask와 Toshi, EOS의 Scatter가 Dapp 브라우저 범주에 포함됩니다.

레이어-2 확장 솔루션

앞서 해당 레이어를 간략하게 살펴 보았으나 블록체인 확장성 측면에서 조금 더 세세하게 다시 다룰 필요가 있다고 생각합니다.

첫 번째는 샤딩입니다. 이더리움과 폴카닷 팀의 발목을 잡기도 했던 샤딩은 기술적으로 적용하기 가장 어려운 확장 솔루션처럼 보입니다. 제대로 기능한다고 하더라도 자사를 포함한 다수의 기대에 부응할 지는 미지수입니다. 샤딩의 최대 문제점은 이더리움의 경우 몇 분까지도 될 수 있는 샤드 간 레이턴시(Latency) 문제입니다. 이는 실전에서 샤딩의 효과를 현저하게 감소시킬 수도 있습니다. 또한 샤딩으로 인해 클라이언트가 사용자 쿼리에 대해 어느 샤드를 읽어와야 하는지 판단을 못하는 등 스택 하단에서 여러 문제가 발생할 수도 있습니다.

사이드체인, 결제 및 스테이트 채널 네트워크, ILP와 같은 레이어-2 확장 솔루션 역시 같은 근본적인 문제를 겪습니다. 사이드체인이 점차 늘어나게 되면 어떤 체인에 자산을 넣었는지 사용자가 기억하지 못하게 되며 굉장히 혼란스러운 상화이 발생할 수 있습니다. 결제 및 스테이트 채널 네트워크도 상당한 레이턴시 문제를 떠안고 있을 뿐만 아니라 유동성 라우팅, 화폐 전송, 개인 정보 보호 등과 관련된 새로운 문제들을 야기할 가능성이 높습니다. ILP 또한 가치 사슬의 저장고인 비트코인의 블록 생성 시간이 10분이기 때문에 실질적인 레이턴시 문제를 직면할 것입니다.

더욱 혼란스러운 상황도 충분히 일어날 수 있습니다. 특정 샤드의 결제 채널에 자산을 넣어두었는데, 이를 다른 샤드에 있는 사이드체인으로 돈을 옮기고자 하는 사용자도 있을 것이기 때문입니다.

현재 가지고 있는 의문점들이 해소되기 전에 아마 혼란이 가중될 것 같습니다.

앞으로의 동향

웹 3.0 스택의 가장 놀라운 점은 스택 자체가 굉장한 수준으로 탈중앙화 되어 있다는 사실입니다. 윈도우, iOS, 안드로이드 등과 같은 기존 어플리케이션 개발 스택 대부분은 거의 100% 중앙화 되어 있으며 소수의 제3자 개발자 라이브러리 및 서비스만이 임계치를 달성했습니다. 이는 세계 도처에 있는 수백 개의 개발 팀들이 동시에 구축하고 있는 웹 3.0 스택과는 정반대입니다! 이론상으로는 이더리움 코어 프로토콜만 있으면 Dapp을 구축할 수도 있으나 실제로는 이더리움 파운데이션이 지금도 그리고 앞으로도 구축하지 않을 여러 개발 툴이 필요합니다. 암호자산이 바자(Bazaar)의 정점이라는 것을 보여주는 완벽한 예시입니다.

웹 3.0 스택의 대부분이 아직 한창 개발 중에 있습니다. 따라서 Dapp 사용량이 매우 낮은 것은 어찌 보면 당연한 일입니다. 현재 웹 3.0 스택의 상태를 보면 유용한 Dapp 구축은 불가능에 가깝습니다! 여느 수많은 기술처럼 웹 3.0 스택은 서서히 진전을 보이다가 티핑 포인트 이후부터는 급격하게 발전할 것입니다.

웹 3.0 스택이 유용성, 안정성, 기능 완성도 측면에서 일정 수준에 도달한 직후 Dapp 혁명이 시작될 것입니다. 멀티코인은 2~3년 정도면 가능할 것이라고 예측하고 있습니다.

마무리하며

멀티코인은 웹 3.0 스택 내 여러 레이어에 걸쳐 십여 개의 프로토콜에 투자하고 있습니다. 앞으로도 지속적으로 웹 3.0 인프라 구축 프로젝트들을 눈여겨 볼 것입니다. 웹 3.0 스택의 일부를 개발 중이라면 언제든지 멀티코인 캐피탈로 연락 주시길 바랍니다.

본 포스팅에 대한 피드백 역시 언제나 환영입니다. 앞서 살펴본 웹 3.0 도표가 완성본이라고는 생각하지 않습니다. research@multicoin.capital로 아이디어와 코멘트, 피드백 등을 주저없이 보내 주세요.

본 포스팅을 읽고 피드백을 제공해준 Albert Wenger, Nick Grossman, Josh Nussbaum에게 감사의 말을 전합니다.

업데이트: 본 포스팅 게재 이후 Web3 Foundation, Trent McConaghy, Stephen Taul이 웹 3.0 스택에 관해 글을 쓴 적이 있다는 사실을 알게 되었습니다.