스푸핑된 이체 승인 공격이란 무엇인가?
스푸핑된 이체 승인 공격은 공격자가 출금 요청을 승인하는 백엔드 시스템을 장악해, 실제 서명용 개인 키를 훔치지 않고도 거래소가 마치 정상 요청인 것처럼 자금을 내보내게 만드는 공격입니다.
스푸핑된 이체 승인 공격은 거래 자체에 서명하는 암호학적 키가 아니라, 출금 요청을 승인하는 백엔드 시스템을 공격자가 장악하는 방식의 거래소 해킹입니다. 금고 비밀번호를 훔치는 대신, 금고를 열라고 지시하는 서류 자체를 위조하는 셈입니다. 이 구분이 중요한 이유는, 해킹 사건 이후 거래소가 “우리 키는 안전했다”고 말할 때 그 말이 실제로 무엇을 의미하는지를 완전히 바꿔놓기 때문입니다.
이 공격 방식은 여기서 자세히 다룬 Bitget 해킹 사건 이후 대중적으로 크게 주목받았습니다. 당시 거래소 경영진은 이 사건을 은행 창구 비유로 설명했습니다. 금고 자체는 한 번도 열리지 않았지만, 누군가 정상적인 출금 전표를 제시한 것처럼 창구 직원에게 현금을 내주게 만드는 방법을 찾아냈다는 것입니다. 이 비유가 유용한 이유는, 대부분의 트레이더가 상상하는 “거래소 보안이 뚫리는 방식”과 정확히 다르며, 바로 그렇기 때문에 이 공격 유형이 흔히 알고 있는 “개인 키 탈취” 서사와 별도로 설명될 가치가 있기 때문입니다.
거래소의 출금 승인 시스템은 실제로 어떻게 작동하나요?
모든 중앙화 거래소는 사용자가 ‘출금’ 버튼을 누르는 순간과 실제로 코인이 지갑을 떠나는 순간 사이에 여러 계층으로 이루어진 구조를 두고 있습니다. 대략적인 흐름은 이렇습니다. 요청이 시스템에 들어오면, 승인 계층이 이 요청이 정상인지(계정 일치, 2FA 통과, 사기 플래그 없음, 리스크 한도 이내인지 등) 확인하고, 이 검증을 통과한 후에야 서명 시스템이 온체인에서 자금을 이동시키는 암호학적 서명을 생성합니다.
개인 키 자체는 대체로 스택에서 가장 엄격하게 보호되는 부분입니다. 하드웨어 보안 모듈(HSM), 다자간 계산(MPC) 구조, 또는 여러 물리적 승인을 요구하는 콜드 스토리지 등에 보관되는 경우가 많습니다. 이 부분에 가장 많은 보안 투자가 이루어지는 이유는, 뚫렸을 때 파급력이 가장 명백하게 치명적이기 때문입니다. 하지만 그 앞단에 있는 승인 계층 역시 결국 소프트웨어 시스템입니다. 엔지니어가 만들고 유지 관리하며, 서버에서 구동되고, 데이터베이스에 연결되어 있으며, 올바른 자격 증명을 탈취하거나 올바른 취약점을 악용하는 누구든 접근할 수 있습니다.
이 승인 계층이 바로 스푸핑된 이체 승인 공격의 공격 표면입니다. 공격자가 이 시스템으로 하여금 출금 요청이 정상이라고 믿게 만들 수 있다면, 그 뒤에 있는 서명 시스템은 설계된 대로 정확히 동작합니다. 즉, 지시받은 대로 서명하는 것입니다. 개인 키는 안전한 환경을 한 번도 벗어나지 않고, 기술적으로도 탈취되지 않습니다. 하지만 사기성 지시는 정상적인 요청으로 위장한 채 결국 키까지 도달하게 됩니다.
”우리 개인 키는 절대 유출되지 않았다”는 말이 왜 해킹이 심각하지 않았다는 의미가 아닌가요?
이 발언이야말로 이런 사건 이후 대중의 혼란을 가장 많이 일으키는 부분입니다. 거래소가 이 표현을 쓰는 이유는 기술적으로 사실이면서 동시에 안심시키는 느낌을 주기 때문입니다. 가장 깊은 층의 방어선이 뚫리지 않았다는 뜻이니까요. 좁은 의미에서는 실제로 그렇습니다.
하지만 자금은 여전히 플랫폼을 떠났습니다. 사용자는 여전히 돈을 잃었습니다. 도난 경로가 서명 키가 아니라 승인 로직을 통과했다는 사실이 결과를 바꾸지는 않습니다. 다만 내부 구조상 어느 부분이 실패했는지가 달라질 뿐입니다. 물리적 보안 침해에 비유하자면 이렇습니다. 누군가 은행의 내부 이체 승인을 위조하고 그에 따라 창구 직원이 자금을 내줬다면, 금고 문은 한 번도 건드려지지 않았지만 은행은 여전히 강도를 당한 것입니다. 이 구분은 사후 엔지니어링 관점에서는 의미가 있습니다(보안팀에게 어디를 재구축해야 하는지 알려주니까요). 하지만 자금을 잃은 사용자 입장에서는 아무런 의미가 없습니다.
이 때문에 거래소 해킹 사건을 비교하는 헤드라인들이 “키가 탈취됐는가, 아닌가”만 기준으로 삼으면 오해를 부를 수 있습니다. 역대 최대 규모 거래소 해킹을 정리한 이 글처럼 좀 더 폭넓은 사건 순위는 대개 결과뿐 아니라 공격 메커니즘까지 함께 다뤄야 합니다. 메커니즘이야말로 실제로 어떤 종류의 방어선이 무너졌는지 알려주기 때문입니다.
이런 유형의 공격을 실제로 막는 통제 장치는 무엇인가요?
백엔드 취약점을 찾아낸 집요한 공격자를 단 하나의 장치로 확실히 막을 방법은 없지만, 여러 장치를 겹겹이 쌓으면 공격을 훨씬 더 어렵고 느리게 만들 수 있습니다.
| 통제 장치 | 역할 | 한계 |
|---|---|---|
| 다중 서명 승인 | 자금 이동 전 여러 키/시스템의 독립적인 승인 요구 | 여러 승인자가 동시에 장악되면 무력화됨 |
| 출금 주소 화이트리스트 | 사전 승인된 주소로만 출금 허용, 신규 주소는 대기 시간 적용 | 이미 등록된 화이트리스트 항목이 장악되면 여전히 악용 가능 |
| 고액 출금 시간 지연 | 고액 이체 실행 전 검토 시간 확보 | 잘 계획된 공격을 늦출 뿐 완전히 막지는 못함 |
| 검증/서명 시스템 분리 | 승인 로직과 서명 인프라를 제한된 신뢰 관계의 별도 시스템으로 유지 | 시간이 지나며 의도치 않게 결합되지 않도록 엄격한 엔지니어링 필요 |
| 독립 채널 요청 검증(아웃오브밴드) | 요청을 생성한 채널과 다른 별도 채널로 출금 요청을 재확인 | 편의성을 위해 일부 플랫폼이 생략하는 마찰 요소 |
다중 서명 검증은 특히 짚고 넘어갈 가치가 있습니다. 스푸핑 문제를 직접적으로 해결해 주기 때문입니다. 출금 시 서로 동일한 단일 실패 지점을 신뢰하지 않는 시스템이나 사람들로부터 독립적인 확인을 요구한다면, 공격자는 한 번에 하나 이상을 장악해야 합니다. 이는 단일 백엔드 검증 시스템 하나를 속이는 것과는 본질적으로 다른 난이도의 과제입니다.
트레이더는 이런 유형의 사기로부터 어떻게 스스로를 보호할 수 있나요?
개인 트레이더가 거래소 내부 구조를 감사할 수는 없으므로, 실질적인 방어는 노출을 줄이고 사기를 조기에 알아차리는 데 더 초점을 맞춰야 합니다. 몇 가지 습관이 특히 중요합니다.
- 별다른 요청 없이 도착한 출금 확인 알림은 기본적으로 의심하기. 특히 긴박한 어조로 오는 이메일은 더욱 주의해야 합니다.
- SMS 2FA 대신 하드웨어 기반 인증 사용하기. SMS 인증 코드는 여전히 계정 탈취로 이어지는 대표적인 경로 중 하나입니다.
- 지원되는 거래소에서는 출금 주소 화이트리스트를 활성화하고, 신규 주소에 대해 대기 기간을 설정하기.
- 실제로 매매 중인 자금만 거래소에 남기고 나머지는 셀프 커스터디로 옮기기. 이미 플랫폼을 떠난 자산은 거래소 측 어떤 보안 장치로도 보호할 수 없기 때문입니다.
- 계정의 활성 세션과 API 키를 주기적으로 점검하기. 출금 권한이 있는데도 잊고 방치한 API 키는, 만약 유출되면 스푸핑된 승인 방식의 공격이 악용하기 딱 좋은 지점입니다.
기본적인 계정 리터러시도 도움이 됩니다. 레버리지나 청산 같은 용어를 이해하는 것 자체가 출금 보안과 직접 관련은 없지만, 거래소의 전반적인 작동 원리를 잘 이해하는 트레이더일수록 계정 설정과 보안 옵션에도 더 세심한 주의를 기울이는 경향이 있습니다. 거래소 이용이 아직 낯설다면, 초보자 학습 가이드에서 거래 기초와 함께 계정 보안의 기본기도 다룹니다.
이 사건은 앞으로 거래소 보안을 평가하는 방식을 어떻게 바꿔야 할까요?
이제는 어떤 질문을 던질지 자체를 바꿔야 합니다. “키가 안전했는가”는 필요하지만 충분한 질문은 아닙니다. 더 유용한 질문은 거래소가 다층적인 승인 통제에 관한 정보를 공개하고 있는지, 출금 주소 화이트리스트를 지원하는지, 그리고 사고 발생 시 축소하려는 표현 대신 투명하게 공개해 온 이력이 있는지입니다.
Bitget과 같은 거래소는 이번 사건 이후 바로 이 구분을 공개적으로 해명해야 했고, 적어도 이 문제를 공론화하는 계기가 됐습니다. 수수료나 레버리지만 보고 플랫폼을 비교하기보다는, 마케팅 문구 너머로 해당 플랫폼이 출금 구조를 실제로 어떻게 설명하는지 읽어볼 가치가 있으며, 개별 거래소 후기와 함께 거래소 순위 비교표도 참고할 만합니다.
스푸핑된 이체 승인 공격이 완전히 새로운 유형의 범죄는 아닙니다. 다만 거래소 보안이 하나의 자물쇠가 아니라 여러 시스템으로 이어진 사슬이라는 점을 다시 한번 일깨워 줍니다. 세상에서 가장 강력한 키 관리 체계라도, 그 키를 언제 쓸지 결정하는 시스템 자체가 속아 넘어간다면 아무 소용이 없습니다.
자주 묻는 질문
암호화폐 거래소에서 스푸핑된 이체 승인 공격이란 무엇인가요?
실제 거래에 서명하는 암호학적 키를 훔치는 대신, 거래소가 출금을 승인하는 내부 프로세스를 위조하거나 조작하는 공격입니다. 거래소 시스템이 해당 출금 요청을 정상으로 오인하게 만들어, 겉으로는 정상적으로 승인된 경로처럼 보이는 방식으로 자금이 빠져나갑니다.
암호화폐 거래소 출금 요청이 정상인지 어떻게 확인하나요?
출금 확인 이메일이나 앱 알림이 본인이 직접 시작한 행동과 일치하는지 확인하고, 무조건 괜찮다고 넘기기 전에 계정 활동 기록에서 목적지 주소를 대조해야 합니다. 본인이 출금을 요청한 적이 없다면 어떤 확인 알림이든 의심스럽게 여기고, 메시지 속 링크가 아니라 거래소 공식 사이트를 통해 고객센터에 문의해야 합니다.
암호화폐 플랫폼에서 무단 이체를 막는 보안 조치에는 무엇이 있나요?
고액 출금에 대한 다중 서명 승인, 출금 주소 화이트리스트(허용 목록), 신규 주소에 대한 시간 지연 이체, 요청을 검증하는 시스템과 서명 키를 보관하는 시스템의 분리 등 여러 계층의 통제가 있습니다. 단독으로 충분한 장치는 없기 때문에, 보안 체계가 성숙한 거래소일수록 여러 장치를 함께 적용합니다.
2026년에 트레이더는 거래소 이체 사기로부터 어떻게 스스로를 보호할 수 있나요?
가능하다면 출금 주소 화이트리스트를 활성화하고, SMS 대신 하드웨어 기반 2FA 방식을 사용하며, 거래소를 사칭한 스팸성 이메일 속 링크는 클릭하지 않아야 합니다. 실제로 매매에 사용하지 않는 자금은 개인 지갑(셀프 커스터디)으로 옮기는 것이 좋습니다. 거래소에 더 이상 보관하지 않는 자산은 거래소 측 어떤 보안 장치로도 보호할 수 없기 때문입니다.
어느 나라들이 거래소 이체 보안 요건을 규제하고 있나요?
MiCA 규제를 적용하는 EU, 싱가포르 MAS, 홍콩 SFC 등의 관할권은 라이선스를 받은 거래소에 운영 복원력 및 자산 보관 보안 요건을 부과하고 있습니다. 다만 세부 내용은 관할권마다 다르고, 2026년 기준으로도 시행 체계는 아직 정착 중입니다. 규제는 대체로 출금 승인용 특정 기술 구조를 강제하기보다는 자본 및 공시 규정에 초점을 맞춥니다.
다중 서명 검증은 스푸핑된 승인 공격을 어떻게 막나요?
다중 서명 구조는 출금이 실행되기 전에 서로 독립된 키나 시스템으로부터 각각의 승인을 요구하므로, 승인 구성요소 하나를 장악하는 것만으로는 자금을 빼낼 수 없습니다. 공격자는 여러 개의 독립된 시스템이나 서명자를 동시에 장악해야 하는데, 이는 단일 백엔드 검증 시스템 하나를 뚫는 것보다 훨씬 어렵습니다.
스푸핑된 승인 공격이 발생했다는 것은 거래소의 개인 키가 유출됐다는 뜻인가요?
아닙니다. 그리고 바로 이 차이 때문에 이런 공격이 일반 사용자들 사이에서 혼란을 일으킵니다. 거래소는 서명 키가 한 번도 노출되지 않았다고 사실대로 말하면서도, 동시에 상당한 규모의 사용자 자금을 잃을 수 있습니다. 공격자가 서명 시스템에 '이 출금은 정상'이라고 알려주는 승인 계층 자체를 조작했기 때문입니다.
스푸핑된 이체 승인 공격이 개인 키 탈취 해킹보다 더 심각한가요?
어느 한쪽이 절대적으로 더 심각하다고 할 수는 없으며, 이 둘은 서로 다른 실패 지점을 보여줍니다. 개인 키 탈취는 최후 방어선을 직접 뚫는 것이고, 스푸핑된 승인 공격은 그 키 앞에 있는 승인 로직 자체가 조작될 수 있음을 보여주는 것으로, 내부 시스템 무결성과 접근 통제에 대한 별개의 질문을 제기합니다.