글: Ken Wong(BitDATA PayFi Infra 창업자, 전 사이버보안 연구원)

번역: AididiaoJP, Foresight News

수년간 암호화폐 업계는 보안을 주로 스마트 컨트랙트 문제로 다뤄왔다. 이는 오랫동안 타당했다. 스마트 컨트랙트, 프라이빗 키, 감사, 지갑 보안은 여전히 필수적이다.

그러나 최근 일련의 사건은 다음번 대형 보안 위기가 반드시 암호학의 붕괴에서 오지는 않을 수 있음을 보여준다. 그것은 더 은밀할 수 있다. 시스템이 자신에게 권한이 부여된 작업을 충실히 수행했지만, 문제는 그 권한 부여 자체가 처음부터 신뢰할 수 없었다는 점이다.

1. 손실 구조가 바뀌었다: 절반 가까이가 더 이상 '코드 취약점'이 아니다

Hacken의 《2026년 3분기 보안 및 컴플라이언스 보고서》에 따르면 해당 분기 업계에서는 107건의 사건이 발생해 11억 8,000만 달러의 손실이 났으며, 전 분기 대비 55% 증가했다. 더 주목할 것은 손실 구조다. 48%는 스마트 컨트랙트 취약점에서, 40%는 접근 제어와 운영 실패에서 발생했다.

즉, 손실의 절반 가까이가 더 이상 전통적인 의미의 코드 버그가 아니라, 신원, 권한, 서명 프로세스 혹은 더 넓은 운영 신뢰 경계에서 생긴 문제다.

이 분포는 중요하다. 스마트 컨트랙트 취약점은 더 나은 감사, 형식 검증, 더 엄격한 엔지니어링 규율을 통해 보완할 수 있는 경우가 많다. 하지만 접근 제어와 운영 실패는 전혀 다른 접근법을 요구한다.

이는 업계에 더 어려운 질문들을 던진다. 누가 자금을 움직일 권한을 갖는가? 어떤 시스템이 서명 권한을 상속받는가? '권한을 부여받은' 서비스가 악의적으로 행동하기 시작하면 무슨 일이 벌어지는가? 하나의 신원이 침해되면 도대체 어느 정도의 피해가 발생할 수 있는가?

이는 더 이상 순수한 Web3 프로그래밍 문제가 아니라 금융 인프라 문제다.

2. 공격 표면의 외연 확대: 가용성도 보안이다

암호화폐 보안은 고립되어 있지 않다. 그것은 글로벌 네트워크 위협 환경 속에 있으며, 공격의 규모와 속도, 운영의 유연성은 모두 커지고 있다.

Cloudflare의 《2026년 3분기 DDoS 위협 보고서》에 따르면 해당 분기 1,820만 건의 네트워크 계층 DDoS 공격과 14조 4,000억 건의 HTTP DDoS 요청을 완화했으며, 평균 시간당 약 8,226건의 네트워크 계층 공격이 있었다. 단시간·저대역폭 공격은 208% 급증했고, DNS 증폭 공격은 215%, UDP 플러딩 공격은 122% 증가했다. 공격 대상도 더 분산되었다.

이 데이터는 암호화폐와 PayFi에 두 가지를 의미한다.

첫째, 네트워크 위험이 더 이상 거래소 같은 고가치 표적만 겨냥하지 않는다. 은행, 결제 처리업체, 인터넷 인프라 사업자, 통신 사업자, 서비스 제공업체가 모두 계속 확장되는 동일한 공격 표면 위에 있다.

둘째, 이는 많은 암호화폐 프로젝트가 여전히 과소평가하는 사실을 다시 보여준다. 가용성, 복원력, 운영 연속성 역시 보안 문제다.

보안 시스템은 단지 절도를 막는 것만이 아니라, 압박 속에서도 신뢰성을 유지하고, 남용을 신속히 억제하며, 안전하게 복구할 수 있어야 한다.

3. 바이낸스 사건의 핵심 디테일: 프라이빗 키 보안은 거래 보안과 같지 않다

바이낸스는 2026년 10월 29일 보안 사건 설명에서 약 63억 4,000만 달러의 디지털 자산이 영향을 받았고 약 28억 5,000만 달러가 동결 또는 차단되었으며, 10월 31일 기준 영향받은 토큰 자산의 98%가 복구되었다고 밝혔다.

그러나 보안 아키텍처 관점에서 더 중요한 것은 공격 경로다. 공격자는 내부 지갑 거래 서명 서비스에 무단으로 접근해 통상적인 출금 절차를 우회하여 작업을 실행했다.

이 디테일은 금액보다 중요하다. 프라이빗 키를 보호하는 것이 거래 권한을 보호하는 것과 같지 않다는 점을 보여주기 때문이다.

시스템은 키를 강화된 인프라에 가두고, 내부 서명 프로세스를 설정하고, 지갑 격리를 할 수 있다. 하지만 공격자가 본래 합법적인 거래 권한을 가진 시스템이나 서비스를 장악한다면 '암호학적으로 유효하다'는 것으로는 충분하지 않다.

유효한 서명이 유효한 비즈니스 의사결정은 아니다. 이것이 바로 업계가 지금 진지하게 구분해야 하는 지점이다.

4. 인증, 권한 부여, 거래 적법성은 세 가지 다른 문제다

디지털 금융에서는 최소한 세 가지 질문을 분리해야 한다.

누가 요청을 발신하는가? 이것은 신원 인증이다.
이 신원은 무엇을 할 수 있는가? 이것은 권한 부여다.
현재 상황에서 이 특정 이체를 허용해야 하는가? 이것은 거래 적법성이다.

너무 많은 시스템이 앞의 두 가지만 답한다. API 자격 증명이 유효하고, 서명자가 승인했으며, 워크플로가 기술적으로 권한이 부여되었다면 거래는 신뢰할 수 있는 것으로 간주된다. 이 가정은 점점 더 위험해지고 있다.

탈취된 세션 토큰은 비밀번호 검증을 우회할 수 있고, 침해된 공급자는 진입점이 될 수 있으며, 권한이 과도한 내부 서비스는 거래 통로로 변할 수 있고, 합법적인 서명자도 불법적인 지급을 승인할 수 있다.

따라서 다음 단계의 암호화폐 보안은 자산 보호에서 권한 제어로 확장되어야 한다. 문제는 더 이상 '공격자가 시스템에 침입할 수 있는가'만이 아니라, 더 중요하게는 신뢰할 수 있는 신원이 침해된 후 그것이 실제로 무엇을 할 수 있는가이다.

이것이 더 의미 있는 복원력 지표다.

5. PayFi가 복잡해질수록 권한 경계는 더 명확해야 한다

디지털 자산이 은행 채널, 가상 계좌, OTC 결제, 카드, 가맹점 수취, 프로그래머블 결제와 점점 더 깊게 연결되면서 신뢰 경계도 더 복잡해진다.

현대 PayFi 기술 스택에서 하나의 거래는 지갑 또는 커스터디, API 게이트웨이, 오케스트레이션 레이어, 컴플라이언스 또는 리스크 관리 엔진, 서명 또는 결제 컴포넌트, 그리고 하나 이상의 은행 또는 결제 파트너를 거칠 수 있다. 각 계층은 자체적인 권한, 의존 관계, 운영 가정을 갖는다.

엔지니어링 과제는 더 이상 '돈을 더 빨리 보내는 것'만이 아니라, 권한, 책임, 리스크 관리, 감사 가능성이 결제 전 생애주기에서 일관되게 유지되도록 보장하는 것이다.

향후 AI 에이전트와 자동화 서비스가 사용자나 기업을 대신해 행동할 때 이 점은 더 중요해진다. 머신 아이덴티티는 요청을 발신하도록 허용될 수 있지만, 그것이 새로운 수취인을 승인하거나, 한도를 확대하거나, 독립적 검증 없이 자금을 지급하도록 허용되어야 한다는 뜻은 아니다.

머신 아이덴티티는 금융 권한이 아니다. 위임된 권한이 무한한 권한이 되어서도 안 된다.

6. 자산 보호에서 권한 제어로

업계는 여전히 더 나은 스마트 컨트랙트가 필요하고, 더 나은 감사가 필요하며, 더 나은 키 관리가 필요하다.

하지만 최신 추세는 다음번 대형 보안 실패가 암호학의 붕괴가 아니라 신뢰할 수 있는 권한의 남용에서 발생할 수 있음을 보여준다.

따라서 암호화폐와 PayFi 보안의 다음 단계는 네 가지를 동시에 우선시해야 한다.

권한은 좁혀야 한다. 신원과 서비스는 최소한의 권리만 가져야 한다.
거래 수준의 제어가 따라와야 한다. 고위험 작업에는 상황 기반 재검토, 한도, 독립적 점검이 필요하다.
운영 복원력은 측정 가능해야 한다. 보안은 무엇을 막았는지뿐 아니라, 신뢰할 수 있는 컴포넌트가 실패할 때 무슨 일이 일어나는지도 봐야 한다.
감사와 책임 소재는 신뢰할 수 있어야 한다. 시스템은 누가 발의하고, 누가 승인하고, 누가 자금 흐름을 실행했는지에 대한 흔적을 남겨야 한다.

이것이 바로 사이버보안, 금융 인프라, 프로그래머블 결제가 교차하기 시작하는 지점이다.

7. 업계가 답해야 할 질문

공격자가 신뢰할 수 있는 시스템 신원을 획득하거나 권한을 부여받은 거래 서비스를 장악한다면, 실제로 남는 보호는 얼마나 될까?

더 나아가, 스마트 컨트랙트 감사, 신원 제어, 거래 수준 권한 부여, 운영 복원력 중 다음 단계에서 무엇을 우선해야 하는가?

나의 답은 이것들은 서로 경쟁하는 것이 아니라 서로 보완한다는 것이다. 그러나 우선순위는 중요하다. 자본, 엔지니어링 시간, 경영진의 주의력은 모두 한정되어 있기 때문이다.

다음번 보안 위기는 업계가 논쟁을 끝낼 때까지 기다려주지 않을 것이다.

dYdX 커뮤니티는 2025년 6월 이전에 wethDYDX 계약 지원을 중단하기로 투표했습니다.

인기 기사