암호화폐 세계에는 거의 신성한 공식이 하나 있다: "믿지 말고, 검증하라." 모든 사용자는 자신만의 노드를 운영하고 네트워크 규칙을 직접 확인할 수 있으며 개발팀이나 어떤 중앙 권한에도 의존하지 않을 수 있다.
그러나 이 공식에는 심각한 한계가 있다. 아무리 꼼꼼히 코드를 감사해도, 진정한 해커만이 찾아낼 수 있는 취약점은 내가 발견하지 못한다 — 나는 단지 그 전문성이 없기 때문이다. 그래서 결국은 누군가를 신뢰할 수밖에 없다: 나를 대신해 모든 것을 확인하고 그 결과를 알려주는 사람들을 신뢰하는 것이다.
2026년 5월 5일, 비트코인 코어 개발자들은 취약점 CVE-2024-52911을 공개했다. 이 취약점은 비트코인 코어 0.14.0 이후 버전에 영향을 미쳤고 29.0에서 수정되었다. 이 버그는 채굴자가 원격으로 다른 사람들의 노드를 중단시킬 수 있게 했다.
그러나 여기서 가장 눈에 띄는 점은 이 버그가 얼마나 오래 전부터 알려져 있었는가이다. 코리 필즈(Cory Fields)는 이를 개발자들에게 2024년 11월 2일에 비공개로 신고했다. 2024년 11월 6일까지 Pieter Wuille이 은밀한 수정을 커밋했다. 2024년 12월 3일에는 패치가 공식 저장소에 아무런 공지 없이 올라왔고 단지 "사소한 업데이트"로만 설명되었다. 2025년 4월 12일에 비트코인 코어 29.0이 수정사항을 포함해 배포되었다. 공개적인 공지는 마지막 취약 분기인 28.x가 지원 종료를 맞은 이후인 2026년 5월 5일에야 이루어졌다.

1년 반 동안, 가장 널리 신뢰받는 비트코인 클라이언트는 개발자들이 알고 있던 취약점을 안고 동작했지만 — 그 소프트웨어를 운영하는 노드 운영자들은 이를 몰랐다. 그리고 이 사례는 고립된 사건이 아니다; 암호화폐 분야에서 반복되는 패턴이다. 다양한 프로젝트의 개발자들이 수년간 이런 식으로 행동해 왔다.
나는 같은 유형의 다른 사례들을 살펴보고, 궁극적으로 묻고자 한다: 당신의 저축을 암호화폐에 보관하는 것은 실제로 얼마나 안전한가?
2018년 9월, 비트코인 코어는 버전 0.16.3을 급히 내보냈다. 사용자들에게는 서비스 거부(DoS) 취약점을 패치했다고 알려졌다.
그러나 이틀 후, 그것이 이야기의 절반에 불과하다는 사실이 드러났다. 0.15.x와 0.16.x 버전의 동일한 결함은 채굴자가 비트코인 공급량을 부풀릴 수 있게 했고 — 단일 블록 내에서 동일한 출력을 두 번 소비해 추가 BTC를 챙기는 식이었다. 개발자들은 초기 공지에서 위험도가 낮은 DoS 구성요소만 공개했고, 인플레이션 위협의 전체 설명은 채굴자, 기업 및 기타 핵심 참가자들이 업데이트할 시간을 벌기 위해 고의로 보류했다고 인정했다.
최악의 경우, 이 공격은 개별 지갑이 아니라 비트코인의 핵심 약속인 고정 공급에 대한 공격이 되었을 것이다. 2100만 개 규칙이 클라이언트의 버그로 깨질 수 있다면 비트코인의 전체 경제적 신화는 무너진다.
이 취약점은 악용되지 않았다. 그러나 CVE-2018-17144는 윤리적 딜레마를 정확히 보여준다. 한편으로는 즉각적인 전면 공개가 공격자에게 기성의 플레이북을 넘겨줄 수 있다. 다른 한편으로는 사용자는 업데이트가 얼마나 중요한지에 대해 사실상 진실을 전달받지 못했다.
Zcash 사례는 더욱 불안하다. 이 코인은 블록체인에서 모든 것이 보이는 것이 아닌 프라이버시 코인이기 때문이다. 2018년에 팀은 영지식 증명(zero-knowledge proofs)의 기반이 되는 암호화에 취약점을 발견했다. 수정되기 전에는 공격자가 아무도 감지할 수 없는 방식으로 가짜 ZEC를 생성할 수 있었다. 투명한 체인에서는 잔액 분석을 통해 적어도 이론적으로 인플레이션 버그를 볼 수 있지만, 프라이버시 시스템에서는 이러한 검증이 훨씬 어렵다.
Zcash는 이 문제를 Sapling 업그레이드(2018년 10월 28일 활성화)에서 수정했고, 공개적으로는 몇 달 후에야 이를 알렸다. 공식 공개문에서 팀은 솔직하게 썼다: "열한 달 전 우리는 취약점을 발견했다" — 그리고 수정 이전에는 공격자가 탐지되지 않은 상태로 위조된 Zcash를 발행할 수 있었다고 인정했다.
여기서 침묵을 선택한 이유는 이해하기 쉽다. 이 결함을 패치 전에 공개하면 Zcash를 파괴하는 레시피를 누군가에게 건네주는 것이 될 것이다. 하지만 반대편도 분명하다: 거의 1년 동안 사용자들은 이론적으로는 보이지 않는 위조가 가능한 자산을 보유하고 있었지만 — 그 사실을 전혀 알지 못했다.
이것은 진정한 역설을 드러낸다:
2017년, 모네로는 유사한 위협에 직면했다. 팀은 모네로와 여러 프라이버시 코인들의 기반 프로토콜인 CryptoNote에서 치명적인 버그를 발견했다. 이 취약점은 정확히 무엇을 찾아야 하는지 모르는 관찰자에게는 보이지 않는 방식으로 무제한의 코인을 생성할 수 있게 했다.
모네로의 패치는 은밀하게 도입되었다. 더구나 공개 설명에서는 링CT(RingCT) 서비스 거부 공격으로부터 보호하기 위한 것이라고 밝혔는데 — 팀이 이후 솔직하게 인정한 바에 따르면 — 그런 공격은 사실 존재하지 않았다. 이는 거래소와 채굴 풀을 업데이트하게 하려는 위장 이야기였고, 실제 인플레이션 위험을 드러내지 않기 위해 꾸며진 것이었다.
모네로 자체로는 이야기가 잘 끝났다: 팀은 블록체인을 확인했을 때 착취 징후를 찾지 못했다고 보고했다. 그러나 취약점은 모네로를 넘어 확장되었다. 모네로가 업데이트한 뒤 팀은 다른 CryptoNote 기반 프로젝트들에 통지를 시작했다. 하지만 그중 하나인 Bytecoin은 곧 공격을 받아 6억 9,300만 개의 추가 코인이 생성되었다.
이 사례는 취약점을 비밀로 하는 것의 또 다른 문제층을 드러낸다. 코드가 수십 개 프로젝트에서 공유될 때, 한 장소에서 발견된 위협을 발표하는 것은 다른 곳을 겨냥하는 공격자에게 실마리를 제공할 수 있다. 개발자들은 언제 자신들의 사용자에게 알릴지뿐만 아니라 경쟁 프로젝트들 중 누구에게 언제 경고할지 — 어떤 순서로 알릴지까지 결정해야 한다. 왜냐하면 정보를 먼저 받은 경쟁자가 아직 정보를 받지 못한 경쟁자에게 이를 이용할 수도 있기 때문이다.
2018년, 모네로는 성격은 덜 근본적이지만 매우 교훈적인 사건인 버닝 버그에 직면했다. 이 버그는 누구도 허공에서 XMR을 찍어내거나 공급 일정을 깨는 것을 허용하지는 않았지만, 거래소, 상인 및 기타 서비스에 실질적인 재정적 피해를 줄 수 있었다. 이 버그는 수신된 일부 출력이 사용 불가능해지도록 자금을 전송할 수 있게 했다.
예를 들어 rabbit.io 같은 스왑 서비스는 이런 공격에 취약할 수 있었다.
다음은 rabbit.io에서 암호화폐 스왑이 작동하는 방식이다:
당시 우리 서비스는 존재하지 않았지만, 만약 존재했다면 공격은 다음과 같았을 수 있다:
모네로 팀은 은밀한 패치를 준비하고 도달 가능한 거래소들과 알려진 XMR 판매자들에게 직접 통지했다. 사후 분석에서 개발자들은 이 접근법이 기존에 접촉이 없던 조직들을 필연적으로 빠뜨리며, 정보에 대한 특권적 접근이라는 인식을 만들었다고 솔직하게 인정했다.
이것이 선택적 공개의 실용적 현실이다: 일부 시장 참가자들은 언제나 다른 사람들보다 먼저 위험을 알게 된다. 그 비대칭성 자체가 보안 문제다.
스텔라의 이야기는 대부분의 사례와는 다르다. 왜냐하면 버그가 개발자들만 아는 채 조용히 존재한 것이 아니라 이미 사용되었기 때문이다.
2017년, 공격자는 스텔라 프로토콜의 동시성 결함을 악용해 22억 5천만 XLM을 생성했다 — 당시로 약 1천만 달러에 해당했고 유통 중인 토큰의 약 4분의 1에 해당했다. Messari에 따르면 새로 발행된 XLM은 거래소로 전송되어 아마도 매도되었다.
스텔라 개발 재단은 이후 공급 희석을 막기 위해 자신들의 보유분에서 동등한 양의 XLM을 소각했다. 그러나 공개 발표는 하지 않았다 — Messari가 2년 뒤인 2019년에 사건을 폭로할 때까지는. 이에 대해 스텔라 관계자들은 프로토콜 업데이트 릴리스 노트에서 이 버그를 언급했다고 답변했다. 기술적 릴리스 노트에 조용히 적혀 있었던 것은 완전한 침묵은 아닐 수 있다. 그러나 시장이 Messari의 조사로 2년 후에야 알게 된 그 조용한 한 줄은, 실제로는 침묵이나 다름없다.
이 사례는 업계에 특히 불편하다. "우리는 아무도 악용하지 못하게 취약점을 숨겼다"고 말할 수 없다. 누군가는 이미 악용했기 때문이다. 이 침묵은 사용자를 공격으로부터 보호한 것이 아니라 — 개발자를 조사로부터 보호한 것이었다.
가장 널리 사용되는 이더리움 클라이언트인 Geth에서는 은밀한 패치 관행이 사실상 공식화되었다. 팀의 문서는 이더리움 메인넷의 건강을 위협하는 취약점에 대해서는 취약점 자체를 공개하지 않고 새로운 릴리스에 조용히 수정을 포함시킬 권리를 명시적으로 보유한다고 적고 있다. 그 이유는 단순하다: 노드 운영자들은 몇 주 또는 몇 달 동안 업데이트를 하지 않을 수 있으며, 릴리스가 정확히 어떤 버그를 고쳤는지를 적어두면 누군가 대부분의 노드가 업그레이드되기 전에 이를 악용하려 들 수 있기 때문이다.
그러나 2021년 8월 이 논리는 역효과를 낳았다. Geth는 CVE-2021-39137을 패치하며 8월 24일에 수정을 배포했지만 세부사항은 공개하지 않았다. 누군가가 무엇이 수정되었는지 알아내었고 — 8월 27일에 그 취약점은 악용되어 일부 구버전 Geth 노드가 메인 체인에서 포크되는 결과를 낳았다.
이것이 비밀의 칼날이 가진 또 다른 면이다. 너무 많이 말하면 공격을 가속화할 수 있고, 너무 적게 말하면 일부 운영자들은 업데이트가 시급하다는 사실을 이해하지 못할 수 있다. 네트워크는 정확히 피하려 했던 것 — 취약점의 능동적 악용 — 을 맞이할 수 있다.
2021년 12월, 폴리곤은 동일한 딜레마에 직면했다. 보안 연구자들은 폴리곤 PoS 제네시스 계약에서 약 240억 달러 상당의 MATIC 토큰을 약탈할 수 있는 치명적 취약점을 보고했다. 팀은 조용히 대응하기로 결정했다: 나중에 그들이 말한 바에 따르면 "이 업그레이드의 성격상 너무 많은 주목을 끌지 않고 실행될 필요가 있었다." 검증자들과 풀노드 운영자들에게 통지가 이루어졌고 네트워크는 빠르게 업그레이드되었다.
그러나 빠른 대응조차도 창을 완전히 닫기에는 충분하지 않았다. 업그레이드가 적용되기 전, 공격자는 801,601 MATIC — 약 200만 달러에 가까운 — 를 탈취하는 데 성공했다. 개발자들은 폴리곤 재단이 손실을 보전할 것이라고 확인했다. 이 취약점을 신고한 연구자들은 약 346만 달러 상당의 바운티 보상을 수령했다.
팀은 문제를 은폐하려 하지는 않았다. 다만 사용자들은 거의 일이 일어나기 직전에 어떤 일이 거의 벌어졌는지에 대해 사건이 끝난 뒤에야 전체 규모를 알게 되었다. 그 접근법을 이끈 두 가지 이유가 있었다: 첫째, 우선 행동하는 것이 우선이었다; 둘째, 문제가 해결되기 전에는 그 사실을 아는 추가 인원은 잠재적으로 그 지식을 악용할 사람이 될 수 있었다.
어쩌면 이것이 합리적 타협의 모습일지도 모른다: 패치되기 전에 공격 사실을 공개하지는 말되, 수개월 또는 수년 동안 수정을 비밀로 유지하지는 말자.

때로는 비밀이 진정으로 네트워크를 구한다. 조용한 수정을 하지 않았다면 Zcash는 보이지 않는 인플레이션을 겪었을지도 모른다. 은밀한 패치가 없었다면 모네로는 탐지 불가능한 위조에 직면했을 수도 있다. 폴리곤의 신속한 비공개 조치가 없었다면 해당 네트워크에 대한 잠재적 피해는 비교할 수 없을 정도로 더 컸을 것이다.
그러나 비밀에는 대가가 따른다. 그것은 내부자와 외부자의 계층을 만든다. 팀이 비공개로 경고한 사람들에게 우위를 제공한다. 릴리스가 일상적인 유지보수처럼 보일 때 노드 운영자들이 업데이트할 긴박감을 줄인다. 그리고 암호화폐를 사용할 때 가장 중요한 심리적 기반 중 하나 — 게임의 규칙이 모든 사람에게 동시에 알려져 있다는 느낌 — 을 약화시킨다.
그 느낌은, 알고 보니, 환상이다. 이 모든 이야기는 동일한 호를 따른다: 조용한 패치, 긴 침묵, 그리고 결국 네트워크의 보안이 소수의 사람들, 즉 다른 사람들보다 더 많은 것을 알고 있던 이들에 대한 신뢰에 의존하고 있었다는 인정으로 끝난다.