암호화폐 보안 감사의 한계와 투자자가 확인해야 할 핵심 점검 사항

열쇠 네 개, 서명 세 개

암호화폐 보안 감사가 모든 위험을 막아주지는 않는 이유

암호화폐 거래소나 블록체인 프로젝트의 공식 웹사이트를 방문하면 보안 감사를 완료했다는 인증 표시를 쉽게 발견할 수 있습니다. 투자자 입장에서는 전문 보안 업체의 검증을 받았다는 사실만으로 해당 서비스가 안전하다고 생각하기 쉽습니다. 그러나 보안 감사 인증은 모든 위험이 제거되었다는 의미가 아닙니다. 실제로 감사 대상에 포함되지 않은 시스템이나 외부 서비스에서 문제가 발생하면, 감사가 완료된 플랫폼에서도 대규모 자산 손실이 발생할 수 있습니다.

2026년 10월 18일 코인데스크가 보도한 해켄(Hacken)의 분기별 분석에 따르면, 2026년 3분기 암호화폐 시장에서는 총 107건의 보안 사고가 발생했으며, 피해 규모는 약 11억 8,000만 달러에 달했습니다. 이 가운데 약 9억 680만 달러는 기존 보안 감사에서 충분히 다루지 않았던 영역과 관련된 것으로 분석됐습니다. 이는 전체 손실액의 약 77%에 해당하는 수치입니다.

해켄의 공동 창립자 안드리 마티우킨은 이러한 결과를 설명하면서 보안 감사의 범위가 얼마나 중요한지를 강조했습니다. 보안 사고가 발생했다고 해서 반드시 감사 업체가 코드를 잘못 검토했다는 뜻은 아닙니다. 감사 대상 자체가 제한되어 있었다면, 검토 과정에서 발견하기 어려운 위험이 남아 있을 수 있기 때문입니다.

따라서 투자자는 감사 인증의 유무만 확인할 것이 아니라 어떤 시스템을 대상으로 검토했는지, 언제 감사를 실시했는지, 발견된 문제를 실제로 해결했는지까지 살펴볼 필요가 있습니다.

2026년 3분기 암호화폐 보안 사고와 피해 규모

해켄이 집계한 자료에서 눈에 띄는 부분은 사고 건수뿐 아니라 전체 손실 규모의 증가입니다. 보도에 따르면 3분기 피해액은 직전 분기보다 약 55% 증가했습니다. 이러한 증가는 단순히 소규모 공격이 반복된 결과라기보다 일부 대형 보안 사고가 전체 피해 규모를 크게 끌어올린 영향이 컸습니다.

암호화폐 산업에서 보안 감사는 일반적으로 스마트 계약이나 특정 소프트웨어의 취약점을 확인하는 과정입니다. 감사 업체는 프로그램 코드를 검토하고, 공격자가 악용할 수 있는 논리적 오류나 권한 설정 문제를 찾습니다. 또한 예상하지 못한 상황에서 시스템이 어떻게 작동하는지 테스트하고, 발견된 문제를 심각도에 따라 분류합니다.

그러나 감사 결과는 계약 당시 합의한 범위에 따라 달라집니다. 스마트 계약만 검토했다면 거래소의 출금 서버나 관리자 계정, 외부 소프트웨어, 개인 키 관리 체계 등은 평가 대상에서 제외될 수 있습니다.

이러한 차이는 투자자가 이해해야 할 중요한 부분입니다. 특정 프로그램에 취약점이 없다는 결과와 해당 프로그램을 포함한 전체 서비스가 안전하다는 판단은 서로 다른 의미를 갖습니다. 감사 결과를 올바르게 해석하려면 검증된 부분과 검증되지 않은 부분을 명확하게 구분해야 합니다.

전체 피해의 약 77%가 감사 범위 밖에서 발생한 배경

해켄의 분석에서 전체 피해액의 약 77%가 기존 감사에서 다루지 않은 영역과 관련되었다는 점은 암호화폐 보안 체계의 구조적인 한계를 보여줍니다. 주요 원인은 외부 공급망과 개발 도구의 보안 문제, 이미 알려진 취약점에 대한 수정 지연, 감사 대상에서 빠진 시스템 구성 요소 등으로 구분할 수 있습니다.

첫 번째는 공급망 보안 문제입니다. 암호화폐 서비스는 자체 개발한 프로그램만으로 운영되지 않습니다. 외부 업체가 제공하는 보안 소프트웨어와 개발 도구, 서버 관리 서비스 등을 함께 활용하는 경우가 많습니다. 이 과정에서 외부 업체의 계정이나 소프트웨어가 침해되면, 정작 보호받아야 할 거래소나 블록체인 서비스까지 위험에 노출될 수 있습니다.

두 번째는 취약점 수정이 제때 이루어지지 않는 문제입니다. 감사 과정에서 결함이 발견되더라도 운영사가 이를 즉시 수정하지 않으면 위험은 계속 남습니다. 문제의 심각도를 낮게 평가하거나 수정 비용과 서비스 중단을 우려해 대응을 미루는 경우에도 비슷한 상황이 발생할 수 있습니다.

세 번째는 감사 범위의 제한입니다. 특정 스마트 계약이 안전하더라도 이를 제어하는 관리자 계정이나 서명 키가 탈취되면 공격자가 시스템의 권한을 악용할 수 있습니다. 따라서 계약 코드에 대한 검토만으로 전체 서비스의 보안 수준을 판단하기는 어렵습니다.

해켄 공동 창립자는 자금과 상호작용하는 모든 구성 요소를 감사 범위에 포함하면 비용과 작업량이 크게 늘어난다는 점도 지적했습니다. 보안 감사는 의뢰 기업이 비용을 부담하는 서비스인 만큼, 검토 범위가 현실적인 예산과 일정에 맞춰 제한될 수 있습니다.

공급망과 개발자 도구를 통한 공격의 위험성

암호화폐 보안에서 공급망은 사용자가 직접 확인하기 어려운 영역입니다. 거래소는 외부 업체의 소프트웨어를 이용하고, 개발자는 여러 도구와 라이브러리를 활용해 서비스를 구축합니다. 공격자가 이러한 연결 지점 중 하나를 장악하면 스마트 계약의 취약점을 직접 공략하지 않고도 시스템에 접근할 가능성이 생깁니다.

해켄의 3분기 분석에서는 거래소와 블록체인 서비스, 지갑 관련 소프트웨어를 둘러싼 여러 대형 사고가 언급됐습니다. 원문 보도에 따르면 비트겟(Bitget) 관련 사고에서는 약 3억 5,200만 달러의 피해가 보고됐으며, 리퀴드 네트워크(Liquid Network) 관련 피해액은 약 3억 1,900만 달러, 텍토닉(Tectonic)은 최소 7,500만 달러로 추산됐습니다. 콜드카드(Coldcard) 지갑 소프트웨어 관련 피해도 약 1억 1,400만 달러로 제시됐습니다.

이러한 사건의 세부적인 공격 경로와 피해 집계 방식은 각 사고의 조사 결과에 따라 달라질 수 있습니다. 따라서 개별 금액을 해석할 때는 피해가 발생한 시점과 원인, 직접적인 공격 대상이 무엇이었는지를 구분해서 살펴보는 것이 중요합니다.

또한 7월에는 세 개의 브리지 및 크로스체인 프로토콜과 관련해 6시간 동안 3,500만 달러 이상의 피해가 발생한 사례가 보고됐습니다. 이 가운데 AFX Trade에서는 약 2,400만 달러의 피해가 발생했으며, 검증자 키 탈취가 공격 경로로 지목됐습니다.

이러한 사례가 주는 교훈은 명확합니다. 보안은 프로그램 코드만의 문제가 아닙니다. 외부 공급업체를 선정하는 절차, 개발자 계정의 접근 권한, 소프트웨어 업데이트 방식, 키 관리 체계까지 함께 보호해야 실제적인 보안 수준을 높일 수 있습니다.

스마트 계약 감사에서 확인하는 영역과 제외될 수 있는 영역

스마트 계약은 블록체인에서 예치와 교환, 출금 등 미리 정해진 기능을 실행하는 프로그램입니다. 일반적인 스마트 계약 감사에서는 계약 코드의 논리적 오류와 권한 설정, 자산 처리 과정의 취약점 등을 확인합니다. 하지만 서비스 전체를 구성하는 모든 요소가 자동으로 검토 대상에 포함되는 것은 아닙니다.

예를 들어 이용자가 웹사이트에서 거래 버튼을 누르면 사용자 인터페이스가 요청을 전달하고, 서버가 필요한 정보를 처리하며, 서명 시스템과 스마트 계약이 실제 거래를 수행할 수 있습니다. 이 과정에는 가격 정보를 제공하는 오라클, 다른 블록체인과 연결하는 브리지, 개인 키를 보관하는 수탁 시스템 등이 관여할 수 있습니다.

감사 계약에 스마트 계약만 포함되어 있다면 이러한 주변 시스템은 별도의 검토가 필요합니다. 사용자 인터페이스가 악성 코드에 노출되거나 관리자 계정이 탈취되는 경우, 계약 코드가 정상적이더라도 이용자의 자산이 위험에 처할 수 있습니다.

감사 시점도 중요합니다. 감사 보고서는 특정 날짜에 검토한 코드 버전을 기준으로 작성됩니다. 이후 기능이 추가되거나 권한 구조가 변경되고 외부 서비스와의 연결 방식이 달라지면 기존 결과를 새로운 버전에 그대로 적용하기 어렵습니다.

따라서 투자자는 감사 보고서에서 검토한 코드의 버전과 날짜, 포함된 구성 요소, 제외된 영역을 확인해야 합니다. 플랫폼이 대규모 업데이트를 진행했다면 해당 변경 사항에 대한 추가 검토가 이루어졌는지도 살펴보는 것이 좋습니다.

수탁 구조와 관리자 권한이 만드는 보안 위험

해켄은 파생상품 거래소와 예측 시장 등 12개 플랫폼을 대상으로 한 조사에서 자산 수탁 구조와 권한 집중 문제도 살펴봤습니다. 보고서에 따르면 일부 대형 거래소에서는 7억 달러 이상의 담보 가치가 다중 서명 체계나 소유자가 명확히 공개되지 않은 관리자 키와 관련된 구조에 놓여 있었습니다.

다중 서명 방식은 여러 개의 키 중 일정 수 이상의 승인이 있어야 거래를 실행할 수 있도록 설계한 보안 체계입니다. 예를 들어 네 개의 키 가운데 세 개의 승인이 필요하다면, 하나의 키만 탈취된 상황에서는 공격자가 임의로 거래를 실행하기 어렵습니다.

그러나 다중 서명을 사용한다는 사실만으로 안전성이 보장되는 것은 아닙니다. 키를 보유한 사람이 누구인지, 키가 서로 독립적으로 관리되는지, 복구 절차가 어떻게 설계되어 있는지에 따라 위험 수준이 달라질 수 있습니다. 여러 키가 사실상 동일한 관리 환경에 집중되어 있다면 다중 서명의 효과가 제한될 수도 있습니다.

해켄은 조사 대상 거래소 시스템에서 실제로 작동하는 버그를 발견한 것은 아니라고 설명했습니다. 핵심은 특정 취약점의 존재보다 자산에 접근할 수 있는 권한이 얼마나 집중되어 있는지에 있었습니다.

이러한 관점에서 투자자는 거래소가 자산을 어떻게 보관하는지, 출금 승인에 몇 개의 키가 필요한지, 관리자 권한이 어떻게 통제되는지 등을 확인할 필요가 있습니다. 다만 모든 플랫폼이 세부적인 보안 구조를 공개하는 것은 아니므로 공개 정보만으로 전체 위험을 완전히 평가하기는 어렵습니다.

심각한 취약점을 낮은 등급으로 분류할 때 발생하는 문제

보안 감사 보고서에는 발견된 문제의 심각도가 표시됩니다. 일반적으로 심각도가 높은 취약점은 자산 탈취나 권한 오용처럼 중대한 피해로 이어질 가능성이 있어 신속한 대응이 필요합니다. 반면 영향이 제한적인 문제는 상대적으로 낮은 우선순위로 처리될 수 있습니다.

문제는 취약점의 심각도를 평가하는 과정에서 운영사와 감사 업체의 판단이 달라질 수 있다는 점입니다. 기업이 특정 문제의 위험성을 낮게 평가하면 수정 일정이 뒤로 밀릴 수 있으며, 경우에 따라 필요한 조치가 장기간 이루어지지 않을 수도 있습니다.

감사 보고서에 결함이 기록되어 있다는 사실만으로 보안 문제가 해결된 것은 아닙니다. 수정 계획이 존재하는지, 실제 코드가 변경되었는지, 수정 후 재검증을 받았는지를 확인해야 합니다.

특히 보고서에 미해결 항목이 남아 있다면 해당 항목이 자산 손실이나 관리자 권한 탈취로 이어질 가능성이 있는지 살펴봐야 합니다. 심각도가 낮게 표시되어 있더라도 어떤 근거로 평가했는지 확인하는 것이 바람직합니다.

투자자에게 필요한 것은 단순히 감사 완료라는 문구가 아니라 문제를 발견하고 해결하는 절차가 실제로 작동한다는 증거입니다.

신뢰할 수 있는 감사 보고서를 구분하는 방법

의미 있는 감사 보고서에는 몇 가지 기본 정보가 포함되어야 합니다. 우선 검토 대상 코드의 버전과 감사 날짜가 명시되어야 합니다. 이를 통해 현재 운영 중인 서비스와 감사 대상이 일치하는지 판단할 수 있습니다.

다음으로 감사 범위에 포함된 구성 요소와 제외된 영역이 구체적으로 설명되어야 합니다. 스마트 계약만 검토했는지, 관리자 권한과 오라클, 브리지, 수탁 구조 등도 확인했는지를 구분해야 합니다.

발견 사항과 조치 결과도 중요합니다. 보고서에는 취약점의 심각도와 함께 운영사가 어떤 방식으로 대응했는지 기록되어야 합니다. 주요 문제가 해결되지 않았다면 그 이유와 남아 있는 위험을 확인할 수 있어야 합니다.

마지막으로 후속 검토가 이루어졌는지 살펴보는 것이 좋습니다. 문제가 수정되었다는 운영사의 설명만으로는 충분하지 않을 수 있습니다. 수정된 코드가 실제로 안전하게 작동하는지 다시 확인하는 과정이 필요하기 때문입니다.

감사 인증 표시만 있고 보고서 전문이나 검토 범위를 확인할 수 없다면 해당 인증이 제공하는 정보를 신중하게 평가해야 합니다. 그렇다고 보고서가 공개되지 않았다는 이유만으로 즉시 사기나 보안 사고를 단정할 수는 없습니다. 다만 외부 투자자가 검증할 수 있는 정보가 부족하다는 점은 위험 평가에 반영할 필요가 있습니다.

거래소 보관과 개인 지갑 보관의 차이

암호화폐를 어디에 보관할 것인지는 보안 관리에서 중요한 선택입니다. 거래소에 자산을 보관하면 매매와 입출금이 편리하고 계정 복구 절차를 이용할 수 있다는 장점이 있습니다. 반면 이용자는 거래소의 운영 상태와 출금 시스템, 자산 관리 능력에 의존하게 됩니다.

거래소가 공격을 받거나 출금 기능을 중단하면 이용자가 즉시 자산을 옮기지 못할 수 있습니다. 플랫폼의 재정 상태나 법적 문제 역시 자산 회수 가능성에 영향을 줄 수 있습니다. 거래소에 표시된 잔액은 일반적으로 이용자가 해당 사업자에게 보유한 청구권과 연결되므로, 블록체인에서 개인 키를 직접 관리하는 방식과는 차이가 있습니다.

자체 보관은 개인 키를 이용자가 직접 관리하는 방식입니다. 하드웨어 지갑은 개인 키를 장치 내부에 보관하고 거래 서명을 수행하도록 설계되어 있어 온라인 환경에 키가 노출될 가능성을 줄이는 데 도움이 됩니다. 그러나 장치의 보안이 완벽하다는 의미는 아닙니다. 복구 문구 유출, 가짜 지갑 앱 설치, 피싱 사이트 접속, 악성 거래 승인 등으로 자산을 잃을 수 있습니다.

하드웨어 지갑을 사용할 때는 제조사 공식 웹사이트나 공식 판매 경로를 이용하고, 초기 설정과 복구 문구 보관 절차를 주의 깊게 따라야 합니다. 복구 문구를 온라인 문서나 사진으로 저장하거나 다른 사람에게 전달하는 행동은 피하는 것이 좋습니다.

어떤 보관 방식이든 장단점이 있으므로 거래에 필요한 자금과 장기 보유 자산을 구분하고, 자신의 기술적 이해도와 복구 능력에 맞는 방법을 선택해야 합니다.

규제 준수와 보안 감사는 서로 다른 역할을 한다

암호화폐 거래소를 평가할 때는 보안 감사뿐 아니라 해당 사업자가 관련 규제를 준수하는지도 살펴볼 필요가 있습니다. 유럽연합의 암호자산시장규정(MiCA)은 적용 대상 사업자에 대해 인가와 운영 의무 등 규제 체계를 마련하고 있습니다. 이러한 규제는 사업자의 책임과 감독 체계를 확인하는 데 도움이 될 수 있습니다.

하지만 규제상 인가를 받았다는 사실이 모든 사이버 공격을 막아준다는 의미는 아닙니다. 규제 준수와 기술 보안 감사는 서로 다른 위험을 다룹니다. 인가 여부는 사업자의 법적·운영적 요건을 판단하는 자료가 될 수 있지만, 특정 스마트 계약의 코드 결함이나 외부 공급망의 취약점까지 모두 해결해 주지는 않습니다.

따라서 거래소를 선택할 때는 사업자의 인가 상태와 고객 자산 관리 정책, 보안 사고 대응 절차, 감사 보고서의 최신성을 함께 확인하는 것이 바람직합니다. 한 가지 인증이나 평가 결과만으로 전체 위험을 판단하기보다 서로 다른 정보들을 종합해야 합니다.

투자자가 실천할 수 있는 암호화폐 보안 점검 방법

암호화폐 투자자가 보안 전문가 수준의 기술 지식을 갖춰야 하는 것은 아닙니다. 공개된 정보를 중심으로 몇 가지 항목을 확인하는 것만으로도 불확실성을 줄이는 데 도움이 됩니다.

먼저 이용 중인 거래소나 프로토콜의 보안 감사 보고서를 찾아보세요. 감사 날짜와 검토 대상이 명확한지, 주요 취약점이 해결되었는지 확인하는 것이 좋습니다. 서비스가 크게 변경되었는데도 오래된 보고서만 제공한다면 현재 보안 상태를 판단하는 데 한계가 있을 수 있습니다.

다음으로 자산 보관 구조를 확인해야 합니다. 거래소가 고객 자산을 어떤 방식으로 관리하는지, 출금 권한이 어떻게 통제되는지, 사고 발생 시 어떤 절차를 적용하는지 살펴보세요. 관련 정보가 공개되어 있지 않다면 확인할 수 없는 부분을 위험 평가에 반영해야 합니다.

또한 자산을 한곳에 집중하지 않는 방법도 고려할 수 있습니다. 거래에 필요한 금액과 장기 보유 자산을 구분하고, 자체 보관을 선택한다면 개인 키와 복구 문구를 안전하게 관리해야 합니다. 다만 여러 지갑으로 나누는 것만으로 모든 위험이 사라지는 것은 아니며, 관리 대상이 늘어날수록 실수 가능성도 커질 수 있습니다.

2026년 4분기 암호화폐 보안에서 주목해야 할 변화

앞으로 암호화폐 보안 수준을 평가할 때는 감사 인증을 받았는지보다 감사의 범위가 실제 운영 환경을 얼마나 반영하는지가 중요한 기준이 될 수 있습니다. 스마트 계약뿐 아니라 관리자 권한, 외부 개발 도구, 키 관리 체계, 오라클과 브리지까지 검토하는 통합적인 접근이 필요합니다.

이미 알려진 취약점에 대한 대응 속도도 중요한 지표입니다. 문제를 발견하고 보고서를 공개하는 것에 그치지 않고, 수정 사항을 적용하고 후속 검증을 완료하는 절차가 제대로 이루어져야 합니다. 감사 결과를 공개할 때 미해결 문제와 제외된 범위를 명확히 설명하는 태도 역시 신뢰를 평가하는 데 도움이 됩니다.

다만 감사 범위를 넓히는 것만으로 모든 공격을 예방할 수는 없습니다. 운영 과정에서 새로운 취약점이 발견될 수 있고, 사람의 실수나 외부 공급망의 침해도 발생할 수 있기 때문입니다. 따라서 보안 감사는 지속적인 모니터링과 접근 권한 관리, 사고 대응 계획을 보완하는 수단으로 활용해야 합니다.

해켄의 2026년 3분기 분석이 전달하는 핵심 메시지는 보안 인증을 무조건 불신하라는 것이 아닙니다. 감사가 무엇을 검증했으며 무엇을 검증하지 않았는지 구체적으로 파악해야 한다는 것입니다. 투자자는 감사 날짜와 범위, 미해결 취약점, 자산 보관 구조를 함께 살펴보고 자신이 감수하는 위험을 이해해야 합니다.

FAQ

암호화폐 보안 감사를 받았다면 안전한 거래소라고 볼 수 있나요?

보안 감사는 코드나 시스템의 취약점을 확인하는 데 도움이 되지만, 거래소 전체가 안전하다는 사실을 보장하지는 않습니다. 감사 범위에 포함되지 않은 서버와 관리자 계정, 외부 소프트웨어, 개인 키 관리 체계에서 문제가 발생할 수 있습니다. 따라서 감사 결과와 함께 자산 보관 방식 및 사고 대응 체계도 확인해야 합니다.

보안 감사 보고서에서 가장 먼저 확인할 항목은 무엇인가요?

감사 날짜와 검토 대상 코드의 버전을 먼저 확인하는 것이 좋습니다. 이어서 감사 범위에 포함된 구성 요소와 제외된 영역, 발견된 취약점의 심각도, 수정 여부를 살펴봐야 합니다. 서비스가 업데이트되었다면 기존 감사 결과가 현재 버전에도 적용되는지 확인하는 것이 중요합니다.

다중 서명 지갑을 사용하면 암호화폐 도난을 완전히 방지할 수 있나요?

다중 서명은 여러 키의 승인을 요구해 단일 키 탈취로 인한 위험을 줄이는 데 도움이 됩니다. 그러나 키 관리자가 서로 독립적인지, 키가 안전하게 보관되는지, 복구 절차가 적절한지에 따라 보안 수준이 달라집니다. 다중 서명 자체가 모든 공격이나 운영상 실수를 막아주는 것은 아닙니다.

거래소에 보관한 암호화폐와 개인 지갑에 보관한 암호화폐는 어떤 차이가 있나요?

거래소 보관은 매매와 입출금이 편리하지만, 거래소의 운영 상태와 출금 시스템에 영향을 받습니다. 개인 지갑을 이용하면 개인 키를 직접 관리할 수 있지만, 복구 문구를 분실하거나 피싱에 속아 정보를 노출하면 자산을 되찾기 어려울 수 있습니다. 각 방식의 장단점을 이해하고 거래용 자금과 장기 보유 자산의 관리 방식을 구분하는 것이 좋습니다.