헤데라를 소개하는 자료를 열면 첫 화면부터 좀 이상한 문장이 나옵니다. 자기는 블록체인이 아니라고 적어 놓았거든요. 이 글은 그 문장을 자랑으로도 흠으로도 읽지 않고, 그래서 사용자에게 무엇이 바뀌고 무엇은 그대로인지를 확인합니다. 회사 소개 자료 대신 네트워크가 공개해 둔 API에서 직접 읽은 숫자로 확인하고, 마지막에 필자의 판단을 따로 적었습니다.

1. 이 코인에는 없는 것이 많습니다: 채굴도, 락업도, 새로 찍는 물량도

헤데라(Hedera)는 누구나 열람할 수 있는 원장 네트워크이고, HBAR은 그 네트워크에서 쓰는 코인입니다. 둘의 관계는 이 한 줄로 끝나고, 진짜 특이한 건 이 코인에 없는 항목들입니다. 코인을 볼 때 으레 확인하는 항목을 순서대로 찾아보면 절반쯤이 빈칸으로 남습니다. 발행 일정 칸부터 적을 내용이 없거든요.

채굴이 없습니다. 채굴기를 사서 돌린다는 개념 자체가 성립하지 않습니다. 발행량이 주기적으로 절반으로 줄어드는 일정도 없습니다. 줄어들 신규 발행이 애초에 없거든요. 스테이킹에 락업이 없습니다. 코인을 어딘가로 보내 묶어 두는 절차가 없습니다. 총공급 500억 개는 네트워크가 출범할 때 전부 만들어졌고, 그 뒤로 새로 만들어진 적이 없습니다.

여기서 자연스럽게 질문이 세 개 생깁니다. 새로 찍어서 나눠 줄 코인이 없는데 노드는 왜 돌아갑니까. 락업이 없으면 스테이킹은 무엇을 담보로 보상을 줍니까. 그리고 이 구조에서 코인이 실제로 쓰이는 곳은 어디입니까. 이 세 질문을 따라가면 이 네트워크가 무엇을 얻으려고 무엇을 조건으로 걸었는지가 보입니다. 순서가 규칙으로 정해지는 대신, 합의에 들어갈 수 있는 곳이 명단으로 한정됩니다.

거래소 화면에서 바로 마주치는 표기 하나도 짚고 갑니다. 헤데라의 계좌 주소는 0.0.으로 시작하는 짧은 숫자입니다. 다른 체인에서 쓰던 긴 문자열과 생김새가 달라 처음에는 잘못 본 줄 알기 쉬운데, 계정 번호가 곧 주소인 구조라서 그렇습니다. 이 글 뒤에 나오는 보상 계정 0.0.800이나 수수료 표가 저장된 시스템 파일 0.0.113도 같은 방식으로 붙은 번호입니다. 표기가 이렇게 다른 것도 계정과 원장을 다르게 설계한 결과입니다.

그리고 코인을 보던 습관 몇 가지는 여기서 내려놓아야 합니다. 다른 코인에서 쓰던 판단 도구가 이 네트워크에서는 작동하지 않거든요. 발행이 절반으로 줄어드는 일정에 맞춰 계산하던 방식, 채굴 원가를 바닥값처럼 잡던 방식, 잠금 해제 일정표를 놓고 다음 물량을 세던 방식이 전부 그렇습니다. 그런 일정도, 그런 원가도, 그런 잠금도 이 네트워크에는 없습니다. 대신 봐야 할 것은 국고에서 물량이 나오는 계획, 수수료 금액이 정해지는 기준, 그리고 보상이 빠져나가는 계정입니다. 이 셋은 이 글에서 차례로 다룹니다.

한 가지 미리 밝혀 둡니다. 여기 적힌 숫자는 네트워크가 공개해 둔 미러노드 API를 직접 조회해서 읽은 값입니다. 조회에 쓴 경로도 뒤에 그대로 적어 두었으니 같은 값을 직접 확인하실 수 있습니다. 홍보 문구와 실제로 읽히는 값이 어긋나는 지점도 같이 다룹니다.

2. 블록을 쌓지 않으면 거래 순서는 누가 정합니까

비트코인 계열에서 거래 순서가 정해지는 절차는 단순합니다. 채굴자가 아직 처리되지 않은 거래를 모아 블록 하나를 만들고, 조건을 만족하는 값을 먼저 찾은 참가자가 그 블록을 앞 블록 뒤에 붙입니다. 이렇게 붙은 순서가 곧 거래의 순서입니다. 이 구조에서 순서를 정하는 주체는 이번 블록을 찾아낸 한 명입니다. 어떤 거래를 넣을지, 어떤 순서로 넣을지를 그 한 명이 정합니다. 자세한 배경은 비트코인이 어떻게 작동하는지 정리한 글에 적어 두었습니다.

해시그래프는 블록을 만들지 않습니다. 대신 노드들이 서로에게 자기가 아는 것을 계속 전달합니다. 여기까지는 다른 네트워크와 비슷하게 들리는데, 결정적인 차이가 하나 있습니다. 전달할 때 거래 내용만 넘기는 게 아니라 “내가 방금 누구한테서 무엇을 들었다”는 기록까지 같이 넘깁니다. 이 방식에 붙은 이름이 가십 어바웃 가십입니다. 들은 내용을 전달하면서 들은 경위까지 함께 전달한다는 뜻입니다.

순서대로 보면 이렇습니다. 첫째, 노드는 사용자가 보낸 거래를 자기 기록에 적습니다. 둘째, 아무 노드나 하나 골라 자기 기록을 넘기는데 이때 자기가 어떤 노드에게서 무엇을 언제 받았는지도 같이 넘깁니다. 셋째, 받은 노드는 자기 기록과 받은 기록을 합쳐 새 기록 하나를 만들고, 그 새 기록에 두 출처를 모두 적어 둡니다. 넷째, 이 과정을 계속 반복합니다. 그러면 시간이 조금 지난 뒤 모든 노드가 같은 내용을 갖게 됩니다. 무슨 거래가 있었는지는 물론이고, 누가 그 거래를 언제 알게 됐고 누구를 통해 알았는지까지 같은 내용으로 갖게 됩니다.

노드 세 대로 예를 들면 이렇습니다. 사용자가 A 노드에 거래 하나를 보냈습니다. A는 그 거래를 자기 기록에 적고, B에게 자기 기록을 넘깁니다. B가 받는 것은 거래 내용만이 아닙니다. A가 그 거래를 언제 받았는지, A가 그 전에 누구와 무엇을 주고받았는지까지 같이 받습니다. B는 자기 기록과 받은 기록을 합쳐 새 기록 하나를 만들고, 그걸 C에게 넘깁니다. 그러면 C는 A와 직접 통신한 적이 없는데도 A가 무엇을 언제 알았는지를 알게 됩니다. 이 전달이 반복되면 세 노드가 가진 내용이 같아지고, 같아진 다음부터는 각자 계산해도 같은 답이 나옵니다.

여기서 이 알고리즘의 두 번째 이름이 나옵니다. 가상 투표입니다. 보통은 순서를 합의하려면 노드들이 “나는 이 순서에 찬성한다”는 메시지를 서로 보내야 합니다. 해시그래프는 투표 메시지를 보내지 않습니다. 각 노드가 이미 “상대가 무엇을 언제 알고 있었는지”를 담은 같은 기록을 갖고 있으니, 상대가 그 시점에 무엇을 보고 어떻게 판단했을지를 자기 자리에서 계산해 낼 수 있습니다. 투표를 받는 대신 투표를 계산하는 것입니다.

그래서 네트워크에 실제로 오가는 것은 거래와 대화 기록뿐입니다. 투표 메시지가 오가지 않으니 그만큼 주고받을 것이 줄어듭니다. 근데 주고받는 양이 줄어든다는 것과, 이 네트워크가 실제로 몇 건을 처리하고 있느냐는 따로 봐야 하는 문제입니다. 실제 처리량은 소개 자료에 적힌 숫자가 아니라 직접 조회해서 확인해야 하고, 그 값은 조회 경로와 함께 뒤에 적어 두었습니다.

3. 확정이 확률인 네트워크와, 규칙으로 끝나는 네트워크

순서를 정하는 방식이 달라지면 사용자 쪽에서 바뀌는 것은 확정의 성격입니다. 비트코인·라이트코인·비트코인 캐시에서 거래가 확정됐다는 말은 엄밀히 말하면 “되돌려질 확률이 충분히 낮아졌다”는 뜻입니다. 블록이 하나 더 쌓이면 확률이 더 낮아지고, 또 하나 쌓이면 더 낮아집니다. 낮아질 뿐이지 0이 되지는 않습니다. 되돌려질 확률이 남아 있으니 거래소는 확인 수를 채운 뒤에야 잔고에 반영합니다. 이 대기 시간을 겪어 본 분이라면 입금이 안 들어올 때 확인해야 할 것들을 정리한 글이 익숙할 겁니다.

실제로 되돌려진 적이 있습니다. 라이트코인에서는 열세 개 블록이 통째로 무효가 된 적이 있고, 비트코인 캐시에서는 두 개 블록이 되돌려진 일이 있었습니다. 확인 수를 넉넉히 요구하는 거래소의 보수적인 정책은 이런 전례를 알고 만든 것입니다. 블록이 쌓일수록 확률은 작아지지만 0으로 떨어지지는 않습니다.

해시그래프에서는 순서와 합의 타임스탬프가 규칙으로 정해집니다. 모든 노드가 같은 대화 기록을 갖고 같은 계산을 하면 같은 결과가 나오고, 그 결과가 정해진 순간 이후로는 더 기다린다고 달라지는 것이 없습니다. 확인 수를 세는 개념 자체가 없습니다. 열 번 더 기다려도, 백 번 더 기다려도 같은 순서입니다. 사용자 쪽에서 보면 “언제부터 안심해도 되나”라는 질문의 답이 규칙으로 나옵니다.

이건 이 네트워크가 실제로 해낸 것이고, 여기에 과장은 없습니다. 정산이 확정되는 시점을 규칙으로 알 수 있다는 것은 그 자체로 분명한 장점입니다. 게다가 합의 타임스탬프는 거래마다 붙는 값이라, 두 거래 중 어느 쪽이 먼저였는지를 나중에 다시 다툴 일이 없습니다. 이 성질이 필요한 업무는 실제로 많습니다.

사용자 쪽에서 이 차이가 체감되는 자리는 두 곳입니다. 하나는 기다리는 시간입니다. 확인 수를 채울 때까지 화면을 들여다보는 시간이 이 구조에는 없습니다. 다른 하나는 거래소 화면에 잔고가 뜨는 시각입니다. 원장에서 순서가 정해지는 시점과 회사가 내 계정에 반영하는 시점은 따로 움직이고, 이 둘을 같은 것으로 보면 늦어졌을 때 엉뚱한 쪽부터 확인하게 됩니다.

원화 거래소 입금 화면 보면 코인마다 요구하는 확인 수가 다르게 적혀 있잖아요. 그 숫자는 그 체인에서 되돌려질 가능성을 회사가 어떻게 보느냐에 따라 정해집니다. 이 네트워크는 확인 수 개념이 없어서 그 자리에 다른 방식으로 표시되거나 아예 표시되지 않기도 합니다. 그런데도 반영이 늦어질 수 있습니다. 그건 원장에서 순서가 아직 안 정해져서가 아니라, 회사 내부 처리 절차 때문입니다. 두 원인을 섞어서 보면 엉뚱한 데를 확인하게 됩니다.

근데 여기서 오해하면 안 되는 게 하나 있습니다. 순서가 규칙으로 확정된다는 것은 원장 안에서의 이야기입니다. 제가 주소를 잘못 적어 보낸 거래도 규칙대로 똑같이 확정됩니다. 확정성이 실수를 되돌려 주지는 않습니다. 주소를 옮겨 적는 단계는 원장 규칙이 관여하지 않는 구간입니다. 확정이 규칙으로 정해진다는 사실과 별개로, 보내기 전에 주소를 한 번 더 읽는 습관은 그대로 필요합니다.

표의 마지막 줄이 이 설계의 참가 조건입니다. 왜 그렇게 되는지를 이어서 봅니다.

4. 3분의 1이라는 조건은 참가자 명단을 요구합니다

해시그래프는 비동기 비잔틴 장애 허용, 줄여서 aBFT로 분류됩니다. 용어가 길어서 그렇지 뜻은 두 부분입니다. 앞부분인 비동기는 메시지가 언제 도착할지에 대해 아무 가정도 하지 않는다는 뜻입니다. 어떤 메시지가 몇 초 뒤에 도착하든, 한참 뒤에 도착하든 알고리즘이 성립합니다. 뒷부분인 비잔틴 장애 허용은 참가자 중 일부가 꺼져 버린 정도를 넘어 적극적으로 거짓말을 하더라도 나머지가 같은 결론에 도달한다는 뜻입니다.

여기에 조건이 붙습니다. 참가 노드의 3분의 1 미만이 고장 나거나 거짓말을 하는 경우까지입니다. 이건 주장이 아니라 논문에 증명이 실려 있는 내용이고, 그 증명을 사람이 눈으로 읽고 넘어간 게 아니라 형식 검증 도구로 다시 돌려 확인한 결과까지 공개돼 있습니다. 여기까지는 이 알고리즘이 잘한 부분이고, 깎을 이유가 없습니다.

문제는 조건 문장에 들어 있는 분수입니다. 3분의 1 미만이라는 말이 성립하려면 분모가 있어야 합니다. 분모는 참가자의 수입니다. 참가자의 수를 세려면 누가 참가자인지 정해져 있어야 합니다. 정해져 있지 않으면 셀 수 없고, 셀 수 없으면 3분의 1이라는 조건 자체를 쓸 수 없습니다.

비트코인은 반대편을 골랐습니다. 참가자가 누구인지 세지 않습니다. 장비를 켜면 참가자고, 끄면 아닙니다. 명단이 없으니 분모도 없고, 분모가 없으니 “3분의 1 미만이면 안전하다” 같은 문장을 쓸 수 없습니다. 그 대신 확률로 말합니다. 블록이 쌓일수록 뒤집기 어려워진다는 방식으로요. 누구나 들어올 수 있게 한 대신, 확정은 확률로 남았습니다.

헤데라는 반대쪽을 골랐습니다. 참가자를 세는 쪽을 택했고, 그 대가로 확정이 규칙으로 정해집니다. 어느 쪽이 옳다는 문제가 아닙니다. 서로 반대편을 골랐고, 고른 쪽이 다르니 내준 것도 다릅니다. 참가자를 세는 조건도, 그 조건이 요구하는 명단도 알고리즘 문서에 그대로 적혀 있습니다.

조건 바깥에서 어떻게 되는지도 적어 둡니다. 참가자의 3분의 1 이상이 동시에 거짓말을 하는 상황이라면 이 보장은 성립하지 않습니다. 이건 이 계열 합의 전체에 공통으로 붙는 조건입니다. 그래서 보장의 실제 강도는 알고리즘만으로 정해지지 않습니다. 명단에 누가 올라 있고 그들이 서로 얼마나 독립적인지에 함께 달려 있습니다.

이 지점에서 명단이 공개돼 있다는 사실이 다시 중요해집니다. 운영 주체와 위치가 적혀 있으면 읽는 사람이 직접 따져 볼 수 있거든요. 서로 다른 나라에 흩어져 있는지, 업종이 겹치는지, 같은 계열사가 여러 자리를 차지하고 있지는 않은지 같은 것들입니다. 명단을 공개한다는 건 이런 검증을 받겠다는 얘기이기도 하고요.

그래서 다음 질문은 자연스럽게 이렇게 이어집니다. 그 명단에는 지금 누가 올라 있고, 명단을 정하는 것은 누구입니까. 이건 추측할 필요가 없습니다. 네트워크가 공개해 둔 API에 그대로 적혀 있습니다.

5. 합의 노드 명단은 정해져 있습니다: 누가 돌리고 누가 소유합니까

미러노드 API로 메인넷의 합의 노드 목록을 조회하면, 조회 시점 기준으로 25대였고 전부 카운슬 회원사가 운영하는 노드였습니다. 각 노드 항목에는 설명 문구가 붙어 있는데, 거기에 운영 기관 이름과 위치가 그대로 적혀 있습니다. LG가 싱가포르에서 운영하는 노드, 스월즈가 미국 아이오와에서 운영하는 노드, 노무라가 도쿄에서 운영하는 노드, 구글이 헬싱키에서 운영하는 노드, 자인 그룹이 쿠웨이트시티에서 운영하는 노드 같은 식입니다.

이 명단은 네트워크가 API에 직접 적어 공개해 둔 값입니다. 앞 항목에서 본 조건 때문에 반드시 이렇게 되어야 합니다. 3분의 1을 세려면 명단이 있어야 하고, 명단이 있으려면 누가 참가자인지가 공개돼야 합니다. 원하는 사람이 자기 장비로 합의 노드를 하나 켜서 명단에 끼어드는 구조는 아닙니다.

규칙 변경, 수수료 표, 국고 운용을 결정하는 것은 헤데라 카운슬입니다. 서른 곳이 넘는 기업과 기관이 들어와 있는데, 표를 세는 방식이 지분 순서가 아닙니다. 회사가 크든 작든 표는 한 장씩이고, 한 자리에 계속 앉아 있을 수도 없습니다. 임기가 끝나면 자리를 비우는 규칙이 문서에 적혀 있거든요. 한 회사가 결정을 오래 쥐지 못하게 만들어 둔 장치입니다. 그래서 회원사 이름을 외워 봐야 소용이 없습니다. 명단은 계속 바뀝니다.

이 구조는 창업자나 재단 한 곳이 마음대로 규칙을 바꾸는 형태보다 분산돼 있습니다. 의결권이 동등하고 임기가 제한된다는 건 실제로 의미가 있는 장치입니다. 동시에 원하는 사람이 들어와 규칙 결정에 참여하는 형태와는 명백히 다릅니다. 그래서 이 글은 두 사실을 같은 항목에 나란히 적어 둡니다.

여기서 한국 독자들이 자주 하는 오해 하나를 짚고 갑니다. 카운슬에 익숙한 대기업 이름이 보이면 “저 회사들이 이걸 업무에 쓰고 있구나”로 읽는 습관이 있습니다. 확인된 것은 거기까지가 아닙니다. 확인된 것은 그 회사들이 거버넌스에 참여하고 노드를 운영한다는 사실입니다. 그 회사가 자기 사업에서 이 네트워크를 얼마나 쓰는지는 따로 근거가 있어야 하는 이야기이고, 그 부분에 대해 1차 출처 없이 규모나 건수를 말하는 글은 걸러 들으시면 됩니다.

코드의 소유 구조도 같이 봐야 공평합니다. 초기에는 이 알고리즘이 특허로 묶여 있었습니다. 남이 가져다 쓸 수 없는 기술이라는 지적이 여기서 나왔고, 그 지적은 그 시점에서는 맞는 말이었습니다. 이후 카운슬이 해시그래프 지식재산권을 사들여 아파치 2.0 라이선스로 공개했고, 코어 네트워크 소프트웨어는 리눅스 재단 산하 조직에 하이에로라는 이름의 프로젝트로 넘어갔습니다. 지금 구조에서 코드의 소유와 유지는 특정 회사 한 곳에 묶여 있지 않습니다. 이 사실을 빼고 비판하면 그 비판은 부정확해집니다.

여기서 계층을 하나 구분해 두는 게 좋습니다. 합의에 참여하는 노드와, 기록을 저장해 두고 조회용으로 내주는 미러노드는 서로 다른 것입니다. 앞의 것은 명단으로 관리되고, 뒤의 것은 그렇지 않습니다. 이 글의 숫자는 전부 뒤쪽 계층에서 읽었습니다. 합의 노드로 참가할 수 없다고 해서 원장을 읽는 것까지 막히지는 않습니다. 읽는 쪽은 아무 제한 없이 열려 있습니다.

정리하면 이렇습니다. 합의에 참여하는 자리는 닫혀 있고, 코드는 열려 있으며, 원장을 읽는 일은 누구에게나 열려 있습니다. 이 글의 숫자도 그래서 아무 권한 없이 읽을 수 있었습니다.

6. 우리가 직접 조회한 숫자, 그리고 그 숫자의 한계

앞 항목의 노드 수는 우리가 직접 조회해서 읽은 값입니다. 같은 방식으로 읽을 수 있는 값이 몇 개 더 있어서, 시간이 지나면 달라지는 값들을 여기 한자리에 모았습니다. 출처는 네트워크가 공개해 둔 미러노드 REST API입니다. 계정도 권한도 필요 없고, 주소창에 경로를 넣으면 그냥 열립니다. 노드 목록은 network/nodes, 공급 현황은 network/supply, 스테이킹 설정은 network/stake, 계정 잔고는 accounts 뒤에 계정 번호를 붙이면 됩니다. 아래 값은 2026년 8월 31일에 조회한 결과입니다.

마지막 줄이 이 글에서 제일 조심해서 읽어야 하는 값입니다. 측정 방법은 이렇습니다. 최근 거래 100건을 받아 합의 타임스탬프 사이의 간격을 계산하고, 같은 측정을 세 번 반복해서 평균을 냈습니다. 그 결과가 초당 2.5건 수준이었고, 하루로 환산하면 이십만 건 대였습니다. 2차 자료에서는 하루 삼십칠만 건대 수치도 보입니다. 어느 쪽을 택하든 규모는 하루 수십만 건입니다.

이 값을 “느리다”는 근거로 쓰면 안 됩니다. 우선 조회한 그 순간의 값입니다. 시간대에 따라 부하가 달라지므로 다른 시각에 재면 다른 값이 나옵니다. 그리고 이 값이 보여 주는 것은 지금 이 네트워크에 걸려 있는 부하입니다. 어떤 네트워크든 실제 부하는 이론상의 상한보다 훨씬 아래에서 움직입니다.

그럼에도 이 값을 굳이 재서 적어 두는 이유가 있습니다. 이론상의 초당 처리 한도가 성능 사실처럼 인용되는 일이 워낙 잦거든요. 그 수치를 하루로 환산해 보면 위 표의 값과 자릿수가 완전히 다릅니다. 상한과 실측은 애초에 서로 다른 것을 재는 숫자입니다. 이 구분을 안 하고 이론값만 인용하면 독자는 실제와 다르게 이해하게 됩니다.

측정의 한계도 같이 적습니다. 거래 100건은 표본이 작습니다. 특정 시각에 처리가 몰렸다면 그 구간만 반영되고, 조용한 시각에 재면 더 낮게 나옵니다. 그래서 이 값은 조회 시점의 부하로만 읽어야 합니다. 더 정확히 보고 싶다면 하루 단위로 집계해 주는 자료를 여러 개 놓고 비교하는 편이 낫고, 그때도 집계 기준이 서로 같은지부터 확인해야 합니다.

표의 다른 값들도 같은 성격입니다. 노드 수도, 국고 비율도, 계정 잔고도 시간이 지나면 달라집니다. 그래서 조회 시점을 표에 박아 두었습니다. 어떤 글에서 이런 숫자를 보시거든 조회 시점이 적혀 있는지부터 보시면 됩니다. 시점 없는 숫자는 확인할 방법이 없습니다.

7. 새로 찍는 코인이 없으면 보안 비용은 누가 냅니까

이제 발행 쪽입니다. 작업증명 네트워크에서 보안 비용을 내는 방식은 명확합니다. 새로 발행되는 코인입니다. 채굴자는 전기와 장비를 쓰고, 그 대가로 새로 만들어진 코인과 수수료를 받습니다. 신규 발행이 곧 보안 예산인 셈이라, 발행이 줄면 예산도 줄고 그 자리를 수수료가 채워야 합니다. 비트코인 구조를 다룬 글에서 이 부분을 자세히 정리해 두었습니다.

헤데라에는 이 예산 항목이 없습니다. 500억 개가 출범 시점에 전부 만들어졌고 그 뒤로 늘어난 적이 없으니, 노드에게 나눠 줄 새 코인이라는 게 존재하지 않습니다. 인플레이션이 없다는 말은 보유자 입장에서 반가운 얘기지만, 동시에 보안을 살 예산이 발행에서 나오지 않는다는 뜻이기도 합니다.

그러면 노드 운영 비용은 누가 냅니까. 카운슬 회원사가 자기 인프라로 냅니다. 서버를 두고 대역폭을 쓰고 사람을 붙이는 비용을 회원사가 부담하는 구조입니다. 여기서 합의 노드 명단이 다시 나옵니다. 비용을 부담하는 주체가 정해져 있으니 참가자도 정해집니다. 명단과 비용 부담은 같은 설계에서 함께 나옵니다.

초기 배분도 이 구조와 이어집니다. 회사가 정한 계획에 따라 적격 투자자에게 사전 계약으로 판매하는 방식으로 시작했습니다. 비트코인 계열과 출발선 자체가 다릅니다. 어느 쪽이 옳다는 얘기가 아니고, 출발선이 다르면 이후 물량 흐름도 다르게 읽어야 한다는 얘기입니다.

지금도 총공급 전부가 시장에 나와 있는 것은 아닙니다. 일부는 국고에 남아 있고, 그 물량은 카운슬 국고 위원회가 공개한 계획에 따라 나옵니다. 아직 나오지 않은 물량이 있다는 것 자체는 이미 들고 있는 사람에게 희석 요인입니다. 대신 나오는 속도와 계획이 미리 공개돼 있어서, 아무 예고 없이 물량이 풀리는 구조보다는 낫습니다. 국고에 남은 비율은 조회 결과 표에 시점과 함께 적혀 있습니다.

이 구조에서 한 가지 더 따져 볼 것이 있습니다. 회원사가 비용을 부담한다는 말은, 그 회원사가 참여를 그만두면 그 자리도 비게 된다는 뜻입니다. 작업증명에서는 채굴자가 떠나도 다른 채굴자가 그 자리를 채울 유인이 코인으로 주어집니다. 여기서는 그 유인이 거버넌스 참여와 사업적 판단 쪽에 있습니다. 그래서 이 네트워크가 계속 돌아가느냐는 코인 가격보다 회원사가 남아 있느냐에 달려 있습니다. 좋고 나쁨을 판정하자는 얘기는 아닙니다. 무엇을 봐야 하는지의 문제입니다.

여기까지가 발행 쪽 이야기입니다. 그러면 이 네트워크를 실제로 쓰는 사람이 내는 돈은 어떻게 정해지는지 봅니다.

8. 수수료는 달러로 정해지고 결제는 코인으로 합니다

헤데라의 수수료는 달러 금액으로 적혀 있습니다. 코인 전송 한 번에 얼마, 토큰 전송 한 번에 얼마 하는 식으로 작업 종류마다 금액이 정해져 있고, 낼 때는 그 금액에 해당하는 HBAR로 냅니다. 표에 적힌 달러 금액은 그대로 있고, 그 금액을 채우는 코인 수량만 지불할 때마다 계산됩니다.

표의 값은 시스템 파일 0.0.113에 저장돼 있고, 카운슬 결정으로 바뀔 수 있습니다. 달러 금액을 HBAR 수량으로 바꿀 때는 네트워크가 관리하는 환율을 씁니다. 이 환율은 수수료를 환산하기 위한 내부 값이니, 거래소 가격과 같은 것으로 읽으시면 안 됩니다.

한국 독자에게는 구분해야 할 게 하나 더 있습니다. 거래소 출금 수수료입니다. 거래소에서 코인을 출금할 때 떼는 금액은 회사가 따로 정하는 값이고, 네트워크 수수료와 다릅니다. 두 값은 서로 연동되지 않아서, 네트워크 수수료가 얼마로 정해져 있든 출금 수수료는 회사가 정한 대로 나갑니다. 그러니 “이 네트워크는 수수료가 아주 싸다는데 왜 출금할 때 이렇게 나가지”라는 의문이 들면, 그 금액은 회사가 정한 값입니다.

수수료가 달러로 정해져 있다는 사실은 진짜 장점입니다. 이 네트워크로 무언가를 운영하는 쪽에서는 비용을 미리 예산으로 잡을 수 있습니다. 코인 가격이 어떻게 움직이든 한 건당 비용이 달러로 고정이니 계산이 됩니다. 코인 가격에 따라 한 건 비용이 몇 배로 뛰는 구조에서 겪는 골칫거리가 여기서는 생기지 않습니다.

그리고 같은 사실에서 보유자에게 중요한 결과가 나옵니다. 달러 금액이 고정이면, 코인 가격이 오를 때 같은 작업에 들어가는 코인 수량은 줄어듭니다. 한 건에 0.0001달러어치를 낸다는 규칙은 그대로인데, 그 0.0001달러를 채우는 데 필요한 코인 개수가 적어지는 것입니다. 사용량이 늘어도 네트워크가 걷는 금액은 달러 기준으로 예측 가능하게 유지되도록 설계돼 있고, 그게 사용하는 쪽이 원한 성질입니다.

원화로 얼마인지 궁금해지실 텐데, 여기서는 일부러 환산하지 않습니다. 환산값은 두 가지가 동시에 움직이는 값이라(코인 가격과 원달러 환율) 적어 두는 순간부터 틀리기 시작합니다. 기준만 기억하시면 됩니다. 한 건에 정해진 것은 달러 금액이고, 지불에 쓰이는 코인 수량은 그 달러 금액을 맞추기 위해 계산되는 값입니다. 이 순서가 뒤집히지 않는다는 것이 이 구조의 핵심입니다.

수수료 이야기가 나온 김에, 원화 거래소 화면에서 이 코인 옆에 자주 붙는 또 다른 숫자를 정리하고 갑니다.

9. 원화 거래소 화면의 “이자”와 네트워크 보상은 다른 것입니다

한국에서 이 코인을 처음 만나는 자리는 대개 원화 거래소 화면입니다. 그것도 스테이킹이나 이자 메뉴에서 만납니다. 화면에는 연 몇 퍼센트 같은 숫자가 뜨고, 그 옆에 예치 버튼이 있습니다. 그런데 그 화면에 뜬 숫자와, 이 네트워크가 규칙으로 정해 둔 보상은 같은 것이 아닙니다. 값이 정해지는 자리가 아예 다르거든요.

거래소 화면의 숫자는 그 회사가 제시하는 상품 조건입니다. 회사가 모은 코인을 어떻게 굴리는지, 어떤 조건으로 얼마를 돌려줄지를 회사가 정합니다. 그래서 최소 수량, 예치 기간, 중도 해지 규칙, 정산 주기가 상품마다 다릅니다. 그리고 이 경우 코인은 내 지갑이 아니라 회사에 있습니다. 회사에 무슨 일이 생기면 그 위험은 내가 집니다. 거래소 상품 일반에 대해서는 거래소 이자 상품이 어떻게 굴러가는지 정리한 글을 참고하시면 됩니다.

네트워크 보상은 다릅니다. 내 계정이 어느 노드를 지정했는지에 따라 24시간 단위로 계산되고, 네트워크가 정해 둔 낮은 상한이 그대로 적용됩니다. 어느 회사도 이 값을 임의로 올리거나 내리지 못합니다. 대신 상한이 낮습니다. 두 숫자를 나란히 놓으면 이렇습니다.

거래소 예치 상품 화면을 읽을 때 순서도 정해 두면 편합니다. 첫째, 최소 수량과 예치 기간을 봅니다. 둘째, 중도에 빼는 게 되는지, 빼면 그동안 쌓인 몫은 어떻게 되는지를 봅니다. 셋째, 정산 주기를 봅니다. 넷째, 표시된 수치에 상한이나 조건이 붙어 있는지 봅니다. 이 네 가지는 전부 회사가 정하는 값이라, 같은 코인이라도 회사마다 다릅니다. 네트워크 쪽 값과 비교하려면 이 네 가지를 먼저 확인해야 비교가 성립합니다.

실무 동선도 짚고 갑니다. 거래소에서 산 코인을 내 지갑으로 옮겨 직접 노드를 지정하려면, 먼저 지갑을 만들고 소액으로 시험 전송을 해 보는 순서가 안전합니다. 지갑 종류와 보관 방식을 먼저 정리하고, 출금할 때는 네트워크를 잘못 골라 보내는 사고가 이 단계에서 가장 자주 나므로 출금 화면의 네트워크 표기를 한 번 더 확인하시는 게 좋습니다. 처음이라 순서 자체가 낯설다면 거래소에서 코인을 사는 기본 절차부터 보고 오셔도 됩니다.

어느 거래소가 이 코인이나 관련 상품을 취급하는지는 회사마다 다릅니다. 그건 그 회사의 상장 기준과 상품 구성의 문제입니다. 지역에 따라 화면에 보이는 상품이 다르니, 본인 화면에서 직접 확인하시기 바랍니다. 아래 카드는 코인게코 티커 페이지에서 현물 페어를 직접 확인한 곳들입니다. 거래소 선택 기준 전반은 거래소 비교 정리에 따로 적어 두었습니다.

제휴 고지: 일부 링크는 제휴 링크이며, 추가 비용 없이 수수료를 받을 수 있습니다. 투자 조언이 아닙니다.

10. 락업이 없는 대신 상한이 있는 스테이킹

헤데라의 스테이킹은 프록시 스테이킹이라고 부릅니다. 절차는 간단합니다. 내 계정 설정에서 어느 노드에 스테이킹할지 지정하면, 그 시점부터 내 계정 잔고가 그 노드의 스테이크로 계산됩니다. 코인을 다른 주소로 보내지 않습니다. 잠기지도 않습니다. 지정만 해 두는 것이라, 팔고 싶으면 그냥 팔면 되고 옮기고 싶으면 그냥 옮기면 됩니다. 다른 체인의 스테이킹과 가장 크게 다른 지점이 여기입니다. 스테이킹의 일반적인 개념을 먼저 보고 오면 차이가 더 선명하게 보입니다.

정산은 24시간 단위로 돌아갑니다. 보상 기간이 24시간이고, 그 기간이 끝날 때 계산이 이뤄집니다. 그래서 하루가 안 되는 짧은 예치로 받는 구조가 아닙니다. 그리고 받지 않고 쌓아 둔 보상은 사라지지는 않지만, 소급해서 받을 수 있는 범위가 365일치까지로 정해져 있습니다. 오래 방치하면 앞쪽 몫부터 받을 수 없게 된다는 뜻입니다.

이제 조건 쪽을 봐야 합니다. 락업이 없다는 장점의 반대편에 상한이 여러 겹으로 걸려 있습니다. 첫째, 보상률 자체에 상한이 있습니다. 네트워크가 정한 값은 HBAR 한 개당 하루 5,232 티니바입니다. 티니바는 HBAR의 최소 단위이고 1 HBAR이 1억 티니바이므로, 하루 약 0.005232%가 되고 1년으로 환산하면 약 1.9%가 상한입니다. 여기서 중요한 건 이게 목표 수익률이 아니라 넘을 수 없는 상한이라는 점입니다.

둘째, 노드 한 대가 인정받는 스테이크에도 상한이 있습니다. 상한을 넘겨서 몰린 스테이크는 보상 계산에 아예 반영되지 않습니다. 이미 상한에 걸린 노드에 스테이킹을 지정해 두면 그 초과분은 보상 대상이 아닌 상태로 남습니다. 셋째, 노드가 자기 보상을 받지 않도록 설정할 수 있고, 실제로 그렇게 설정된 노드가 적지 않습니다. 절반에 가까운 수입니다. 넷째, 네트워크 전체에서 보상 대상이 되는 스테이크 총량에도 상한이 있습니다.

노드를 고를 때 실제로 확인할 것은 두 가지입니다. 그 노드가 보상을 받도록 설정돼 있는지, 그리고 이미 상한에 걸려 있는지입니다. 둘 중 하나라도 해당하면 내가 지정한 몫이 보상 계산에 들어가지 않을 수 있습니다. 이 정보는 앞에서 말한 노드 목록 조회로 그대로 확인됩니다.

정리하면 이 스테이킹은 “묶지 않는 대신 많이 주지 않는” 구조입니다. 자금을 잠그지 않아도 되는 편의를 얻고, 높은 이자를 얻는 것은 포기한 설계입니다. 왜 이 수치가 낮게 묶여 있는지는 보상이 어디서 나오는지를 보면 곧바로 설명됩니다.

11. 보상은 발행되지 않고 정해진 계정에서 빠져나갑니다

공급이 고정이라는 사실이 여기서 실제 결과로 나타납니다. 지분증명 체인 상당수는 스테이킹 보상을 새로 발행해서 지급합니다. 보유자 입장에서는 보상을 받는 만큼 전체 물량도 늘어나므로, 명목 수익률과 실질 수익률이 갈립니다. 헤데라는 새로 발행할 수 없으니 이 방식을 쓸 수 없습니다.

대신 보상은 정해진 시스템 계정에서 빠져나갑니다. 계정 번호가 0.0.800이고, 잔고는 누구나 조회할 수 있습니다. 우리가 조회한 값은 조회 결과 표에 시점과 함께 적어 두었습니다. 보상이 나간 만큼 이 계정의 잔고는 줄어듭니다. 잔고를 다시 채우는 결정은 카운슬이 하고, 그 절차도 공개돼 있습니다.

이 구조를 알면 앞 항목의 상한들이 왜 그렇게 낮게 걸려 있는지가 설명됩니다. 재원이 한정돼 있으니 하루에 나갈 수 있는 총액에도 상한을 두어야 하고, 보상 대상 스테이크 총량에도 상한을 두어야 하며, 코인 한 개당 보상률에도 상한을 걸어야 합니다. 이 세 규칙은 모두 하나의 재원 구조에서 나온 결과입니다.

잔고가 줄어든다는 점을 경고처럼 적어 둔 글이 있는데, 근거가 없습니다. 잔고가 줄면 카운슬이 채울 수 있고, 채우는 결정도 공개된 절차를 따릅니다. 그러니 잔고 숫자 하나를 놓고 앞날을 점치는 것은 의미가 없습니다. 의미가 있는 것은 구조입니다. 이 네트워크의 스테이킹 보상은 정해진 예산에서 나가는 값입니다.

보유자 입장에서 이걸 어떻게 읽어야 할까요. 두 가지가 동시에 성립합니다. 하나, 보상을 받아도 전체 물량이 늘지 않으므로 다른 보유자의 몫이 희석되지 않습니다. 둘, 그 대신 보상은 구조적으로 낮은 수준에서 묶입니다. 높은 수익률을 노리는 자리는 아닙니다. 대신 잔고를 묶지 않아도 됩니다.

다른 체인과 비교해서 읽으면 차이가 더 분명해집니다. 신규 발행으로 보상을 주는 체인에서는 스테이킹을 하지 않는 보유자가 상대적으로 손해를 봅니다. 물량이 늘어나는데 그 몫을 받지 못하니까요. 그래서 그런 체인에서는 스테이킹이 사실상 방어 행동에 가깝습니다. 여기서는 그 압박이 없습니다. 스테이킹을 하지 않아도 내 몫이 줄어들지 않습니다. 대신 스테이킹을 해도 받는 값이 크지 않습니다.

그리고 실무적으로 하나 더 있습니다. 보상률과 상한은 카운슬이 정하는 값이라 바뀔 수 있습니다. 그러니 어떤 글에 적힌 수익률 숫자를 고정값으로 외우지 말고, 스테이킹을 지정하기 전에 지금 값을 직접 확인하는 습관이 낫습니다. network/stake 경로를 열면 지금 값이 그대로 보입니다.

12. 네트워크가 파는 세 가지와, 그 사용량이 코인에 닿는 경로

이 네트워크가 파는 것은 크게 세 가지입니다. 첫째는 토큰 서비스입니다. 스마트 컨트랙트를 따로 짜지 않고 네트워크 기능만으로 토큰을 발행하고 옮길 수 있습니다. 발행·전송·동결 같은 동작이 네트워크에 기본으로 들어 있어서, 계약 코드를 작성하고 감사받는 과정을 거치지 않아도 됩니다.

둘째는 컨센서스 서비스입니다. 이게 이 네트워크의 성격을 가장 잘 보여 줍니다. 다른 시스템에서 벌어진 사건에 순서와 시각만 붙여 주는 서비스입니다. 데이터를 통째로 원장에 올리는 게 아니라, 그 사건이 언제 있었고 어느 사건보다 먼저였는지를 증명해 주는 값만 사 가는 방식입니다. 기존 시스템을 그대로 두고 순서 증명만 외부에서 받아 오는 셈이라, 앞에서 본 규칙 기반 확정이 그대로 상품이 됩니다.

셋째는 스마트 컨트랙트입니다. 이더리움 계열 도구와 호환되는 실행 환경을 제공합니다. 다른 곳에서 쓰던 개발 도구를 크게 바꾸지 않고 옮겨 올 수 있게 하는 쪽입니다.

세 가지 중에서 이 네트워크의 성격이 가장 잘 드러나는 쪽은 두 번째입니다. 토큰을 만들거나 계약을 굴리는 일은 다른 네트워크에서도 하지만, 사건 자체는 기존 시스템에 그대로 두고 순서와 시각만 바깥에서 받아 오는 방식은 앞에서 본 규칙 기반 확정이 있어야 성립합니다. 확정이 확률이면 순서 증명도 확률이 되고, 그러면 그 값을 근거로 삼기가 어려워집니다.

그러면 이 서비스들이 많이 쓰일수록 코인을 들고 있는 사람에게는 무엇이 돌아옵니까. 사용량이 늘면 수수료 지불이 늘어납니다. 그런데 수수료는 달러 기준으로 정해져 있습니다. 그러니 걷히는 총액은 달러 기준으로 늘지, 코인 수량 기준으로 비례해서 늘지 않습니다. 코인 가격이 오르면 같은 사용량에 필요한 코인 수량은 오히려 줄어듭니다.

스테이킹 쪽도 순서대로 따져 봅니다. 사용량이 늘어도 스테이킹 보상은 사용량에 연동되지 않습니다. 보상은 정해진 시스템 계정 잔고에서 나가고, 보상률에는 상한이 걸려 있습니다. 사용량이 두 배가 된다고 보상이 두 배가 되는 구조가 아닙니다.

그렇다고 코인이 필요 없다는 말은 아닙니다. 이 네트워크에서 무언가를 하려면 수수료를 코인으로 내야 하고, 계정을 새로 만들 때도 코인이 듭니다. 서비스를 운영하는 쪽은 잔고를 어느 정도 유지해야 하고, 처리 건수가 많으면 그 잔고도 그만큼 커집니다. 다만 그 잔고는 달러 기준 비용을 감당할 만큼이면 됩니다. 처리 건수가 두 배가 되어도 들고 있어야 할 코인이 두 배가 되지는 않습니다.

그래서 “기업이 많이 쓰면 코인 수요도 그만큼 늘어난다”는 문장은 이 구조에서 자동으로 성립하지 않습니다. 성립할 수 없다는 단정도 아닙니다. 수수료 지불에 코인이 필요하다는 사실은 그대로고, 네트워크 참여자가 코인을 보유해야 할 이유도 있습니다. 다만 그 경로가 사용량 증가와 몇 대 몇으로 연결되는지가 뚜렷하지 않다는 것이고, 이건 이 네트워크를 볼 때 반드시 알고 있어야 하는 구조적 사실입니다. 그래서 답을 단정하지 않고 구조만 적었습니다.

13. 흔히 듣는 말과 실제로 확인되는 것

이 코인에 대해 자주 도는 말들을 한자리에 모아 정리합니다. 대부분은 다른 코인의 상식을 그대로 가져다 붙여서 생기는 오해입니다.

표에서 세 번째 줄을 조금 더 풀어야겠습니다. 이 네트워크가 스스로 “블록체인이 아니다”라고 적어 둔 문구는 자료구조에 관한 서술입니다. 블록을 만들어 한 줄로 잇지 않는다는 뜻이고, 그건 사실입니다. 그런데 이 문구가 “그래서 더 열려 있다”거나 “그래서 더 자유롭다”는 뜻으로 확장되는 경우가 많습니다. 확장하면 틀립니다. 앞에서 본 대로 합의 참여는 명단으로 관리되고, 그 명단은 이 알고리즘이 성립하기 위한 조건입니다.

네 번째 줄도 한국에서 특히 자주 보이는 오해라 한 번 더 적습니다. 회원사 목록에 익숙한 이름이 있다는 사실은 그 회사가 거버넌스에 참여하고 노드를 운영한다는 뜻까지 확인해 줍니다. 그 회사가 자기 사업에서 이 네트워크를 얼마나 쓰는지는 별도의 근거가 있어야 하는 이야기입니다. 근거 없이 도입 규모나 처리 건수를 적어 놓은 글은 그 부분만 걸러 읽으시면 됩니다.

첫째와 둘째 줄은 다른 코인의 상식을 그대로 옮겨 와서 생기는 오해입니다. 코인 소개 글이 대체로 같은 틀로 쓰이다 보니, 발행 일정과 공급 곡선을 먼저 찾는 습관이 생깁니다. 그런데 이 네트워크에는 그 항목 자체가 없습니다. 대신 봐야 하는 것은 국고에 남은 물량과 그 물량이 나오는 계획입니다. 찾는 자리가 다를 뿐, 물량을 확인하는 일이 필요 없다는 뜻은 아닙니다.

다섯 번째 줄은 확인이 쉽습니다. 계정 번호만 알면 잔고를 조회할 수 있고, 노드 목록도 그냥 열립니다. 프라이버시를 목적으로 만든 네트워크와는 방향이 반대이고, 누가 무엇을 운영하는지 공개하는 쪽에 가깝습니다.

14. 필자의 판단: 기술은 정리됐고 코인 쪽 질문이 남습니다

여기서부터는 필자의 판단입니다. 사실 서술과 섞이지 않게 항목을 따로 뒀습니다. 가격을 두고 하는 판단은 여기 없습니다. 설계를 두고 하는 판단이라는 점을 먼저 밝혀 둡니다.

먼저 설계 자체는 앞뒤가 맞습니다. 원화 거래소 입금 화면에 코인마다 확인 횟수가 다르게 적혀 있는 건 그 체인이 되돌려질 여지를 확률로만 줄이기 때문인데, 확률 대신 규칙을 쓰려면 참가자 수를 셀 수 있어야 하고, 세려면 참가 자격을 명단으로 한정해야 합니다. 순서가 이렇게 묶여 있어서 다른 조합을 고를 수가 없습니다. 제가 점수를 주는 대목은 그 한정을 가려 두지 않았다는 쪽입니다. 어느 회사가 어느 도시에서 노드를 돌리는지가 API 응답에 그대로 적혀 있어서, 저처럼 밖에 있는 사람도 명단을 아무 때나 열어 볼 수 있습니다.

무엇에 맞는 설계인지도 비교적 분명합니다. 정산이나 기록의 순서와 시각이 확정되는 것이 중요하고, 비용을 미리 예산으로 잡아야 하며, 상대가 누구인지 아는 것이 오히려 요건인 업무에 맞습니다. 컨센서스 서비스가 정확히 그 수요를 겨냥합니다. 반대로 무허가 참여와 검열 저항 자체가 목적이라면 이 네트워크는 구조적으로 답이 아닙니다. 그건 이 네트워크가 다른 것을 만들기로 하면서 생긴 결과입니다. 두 목적을 동시에 만족시키는 설계는 아직 없습니다.

제가 걸리는 쪽은 기술이 아니라 코인입니다. 거래소에서 HBAR을 사서 그냥 들고 있는 상태를 놓고 물어보면 질문이 선명해집니다. 이 네트워크가 하루에 처리하는 건수가 열 배로 늘면, 제 계정에서는 무엇이 늘어납니까. 수수료가 달러 금액으로 적혀 있으니 걷히는 돈이 코인 수량 기준으로 비례해 늘지 않고, 스테이킹 보상은 사용량과 아예 연결되지 않은 계정에서 나갑니다. 그래서 사용량이 보유자 몫으로 이어지는 통로를 저는 아직 못 찾겠습니다. 통로가 없다고 단정하는 게 아니라, 어디로 이어지는지 제가 짚어 낼 수 없다는 얘기예요. 이걸 알고 들어가는 것과 모르고 들어가는 건 다른 일이라, 이 글에서 제일 힘주어 적었습니다.

반대 의견이 성립하는 지점도 적어 둡니다. 이 프로젝트에 흔히 붙는 “특허로 막힌 폐쇄 기술”이라는 비판은 지금 시점에서는 낡았다고 봅니다. 지식재산권을 사들여 아파치 2.0으로 공개했고 코어 코드는 외부 재단 프로젝트로 넘어갔습니다. 비판하려면 옛 사실이 아니라 지금 구조를 근거로 해야 합니다. 코드는 열려 있습니다. 남는 문제는 합의에 누가 들어갈 수 있느냐입니다.

하나 더 덧붙이면, 이 설계를 평가할 때 자주 어긋나는 지점이 있습니다. 무허가 참여와 규칙적 확정 중 어느 쪽이 더 낫냐는 질문은 성립하지 않습니다. 하나를 얻으려면 다른 하나를 조건으로 내줘야 하는 관계라서 그렇습니다. 그래서 저는 이 네트워크를 볼 때 “좋은가”보다 “내가 필요한 것이 어느 쪽인가”를 먼저 정하는 편이 훨씬 실용적이라고 봅니다.

마지막으로 하나 덧붙입니다. 솔직히 저는 이 글이 “사라”나 “사지 마라”로 읽히지 않았으면 합니다. 제가 판단할 수 있는 것은 이 설계가 무엇을 얻으려고 무엇을 조건으로 걸었는지까지입니다. 그다음 질문, 내가 원하는 것이 어느 쪽인가는 읽는 분이 정할 몫입니다. 저와 다르게 볼 여지도 충분히 있습니다. 규칙으로 끝나는 확정이 대단히 중요한 자리에 있는 분이라면, 제가 미심쩍게 본 지점보다 그 장점을 훨씬 크게 볼 수도 있습니다.

15. 용어 정리

이 글에 나온 용어를 한자리에 정리했습니다. 다른 자료를 읽을 때도 이 표만 옆에 두면 대부분 통합니다.

자주 묻는 질문

거래소 비교부터 확인하기