브리지는 왜 서명 quorum보다 키 운영 계약이 먼저일까: AFX Trade 사고로 보는 hot-validator 리스크

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 스마트컨트랙트가 서명을 정확히 검증했는데도 브리지가 털렸다면, 개발자는 무엇을 보안 경계로 다시 그려야 할까?
• 핵심 출처:
  • Arbitrum-based AFX Trade drained of $24 million after bridge keys compromised - 2026-07-23, 2026-07-28 확인
  • AFX Trade Halts Bridge Operations After $24.15M USDC Withdrawal - 2026-07-23, 2026-07-28 확인
  • Arbiscan transaction 0x50d0…6547b - 2026-07-22, 2026-07-28 확인
  • AFX Trade Confirms Social Engineering and Infrastructure Attack - 2026-07-25 보도, 2026-07-28 확인
  • Token bridging overview - 현재 문서, 2026-07-28 확인

1. 왜 지금 봐야 하나

2026년 7월 22일 UTC 기준, AFX Trade가 운영하던 Arbitrum 위 USDC custody bridge에서 24,150,000 USDC가 빠져나간 거래가 관측됐다. Arbiscan 거래 페이지에는 batchedFinalizeWithdrawals(bytes32[] messages) 호출, 24,150,000 USDC 전송, 200초 dispute window 이후 AFX Trade exploiter로 자금이 릴리스됐다는 인사이트가 남아 있다. CoinDesk는 Blockaid의 분석을 인용해 이 사건을 “스마트컨트랙트 로직 우회”가 아니라 브리지 validator signing key compromise로 설명했다. 즉 컨트랙트는 서명을 검증했고, quorum이 찼고, 정해진 대기 시간이 지난 뒤 그대로 실행했다.

이 지점이 개발자에게 중요하다. 우리는 보통 브리지 보안을 “컨트랙트 audit을 받았는가”, “Merkle proof를 검증하는가”, “quorum threshold가 충분한가”로 본다. 그런데 AFX 사례가 보여준 실패 조건은 조금 다르다.

온체인 검증 규칙이 맞아도, 그 규칙이 신뢰하는 오프체인 키 운영이 깨지면 잘못된 상태 전이가 정상 거래처럼 통과한다.

Arbitrum 측 설명도 구분해야 한다. ForkLog와 CoinDesk 모두 Offchain Labs 공동창업자 Steven Goldfeder의 설명을 인용해 Arbitrum native bridge가 해킹된 것이 아니라, AFX가 별도로 운영한 third-party bridge에서 발생한 사건이라고 정리했다. Layer 2 위에 올라간 앱이 별도 브리지를 만들면, 사용자는 L2의 보안을 자동으로 상속받는 것이 아니라 그 앱이 만든 custody·validator·key-management 보안도 함께 떠안는다.

2. 핵심 개념

브리지는 결국 “한 체인에서 일어난 일을 다른 체인에서 믿게 만드는 장치”다. Arbitrum 공식 문서는 token bridging을 parent chain과 child chain 사이의 cross-chain messaging 능력을 이용해 자산을 trustlessly 이동시키는 구조로 설명한다. canonical bridge는 이 메시징·challenge·finality 모델 안에서 동작한다.

하지만 많은 앱은 제품 요구 때문에 별도 bridge 또는 custody bridge를 둔다. 예를 들어 빠른 입출금, 특정 자산의 자체 정산, 앱 전용 mainnet과 L2 사이 이동을 위해 “validator들이 서명하면 출금을 인정한다”는 모델을 선택할 수 있다. 이때 온체인 컨트랙트의 핵심 검증은 대략 다음과 같다.

1. 출금 message가 제출된다.
2. validator signature들이 threshold 이상 모였는지 확인한다.
3. dispute/challenge window가 지나면 출금을 finalize한다.
4. vault가 토큰을 목적지 주소로 보낸다.

여기서 중요한 점은 컨트랙트가 “서명이 왜 만들어졌는지”는 모른다는 것이다. 컨트랙트는 private key가 HSM 안에 있었는지, CI 서버에 노출됐는지, 운영자가 phishing을 당했는지, validator 5개가 독립된 주체였는지 검증하지 않는다. 단지 올바른 공개키에 대응하는 서명인지 확인한다.

그래서 bridge quorum은 숫자가 아니라 운영 계약이다. 5-of-7이라도 5개 키가 같은 build pipeline, 같은 password manager, 같은 hot server, 같은 배포 권한에 묶여 있으면 실제 보안은 1-of-1에 가까워질 수 있다. 반대로 threshold가 낮아 보여도 키가 독립 주체·독립 인프라·독립 모니터링·시간 지연을 갖추면 공격 난이도는 크게 올라간다.

3. 최신 이슈와 연결

확인된 공개 자료를 조심스럽게 나누면 세 층이 있다.

첫째, 온체인 결과다. Arbiscan 거래는 2026-07-22 21:30:25 UTC에 24,150,000 USDC 전송이 성공했고, batchedFinalizeWithdrawals가 호출됐음을 보여준다. 이건 추정이 아니라 체인에 남은 상태 전이다.

둘째, 보안업체·언론의 초기 분석이다. CoinDesk는 Blockaid를 인용해 공격자가 5개의 hot-validator signature로 약 2/3 quorum을 만족했고, 200초 dispute period 뒤 자금이 릴리스됐다고 보도했다. ForkLog도 같은 흐름을 정리하면서 AFX가 bridge operation을 중단했고, SlowMist·Zellic·Crypto Defense Alliance 등과 조사·추적을 진행한다고 보도했다. 단, ForkLog는 AFX가 당시 “정확한 attack vector는 조사 중”이라고 했다는 점도 함께 남겼다.

셋째, AFX의 예비 설명을 전한 후속 보도다. KuCoin Flash와 WEEX는 AFX가 X에서 “coordinated social engineering and infrastructure compromise”를 언급했고, 공격자가 development environment에서 시작해 internal build infrastructure와 validator systems로 권한을 확장한 것으로 보인다고 전했다. 이 부분은 공식 postmortem 원문이 아니라 거래소/미디어가 AFX 발언을 전한 것이므로, 글에서는 확정 원인보다는 “초기 조사 설명”으로만 다룬다.

핵심은 하나다. 이 사건의 교훈은 “서명 검증을 하지 않았다”가 아니다. 오히려 반대다. 서명 검증을 했기 때문에 문제가 더 또렷하다. 서명 검증은 signer 운영이 안전하다는 가정을 코드 바깥에서 빌려온다.

4. 개발자 관점 해석

브리지 개발자는 컨트랙트와 운영 인프라를 분리해서 생각하면 안 된다. 컨트랙트의 validateSignatures()는 보안 기능이지만, 동시에 오프체인 운영을 신뢰하는 API다. 이 API의 입력은 bytes signature가 아니라 “키가 어떻게 만들어지고, 어디에 저장되고, 누가 배포하고, 어떤 이상 징후에서 멈추는가”까지 포함한다.

개발자가 봐야 할 질문은 다음과 같다.

• validator key는 hot key인가, HSM/MPC/secure enclave에 있는가?
• threshold signer들이 같은 CI/CD, 같은 cloud account, 같은 admin SSO를 공유하는가?
• 신규 signer 등록이나 validator system 접근 권한 상승에 timelock이 있는가?
• 출금 finalize 전 200초 같은 짧은 window가 실제 대응 가능한 시간인가?
• 대형 출금은 금액별 rate limit, delayed finalization, manual review, circuit breaker를 거치는가?
• bridge UI는 “Arbitrum 기반”이라고만 말하는가, 아니면 “Arbitrum native bridge가 아닌 앱 운영 bridge”라고 명확히 말하는가?

특히 마지막 질문은 제품 책임이다. 사용자는 종종 “L2 위 앱”을 “L2가 보증하는 앱”으로 오해한다. 하지만 AFX 사례처럼 custom bridge가 중간에 있으면 신뢰 경계는 달라진다. 앱 개발자는 입금 화면에서 어떤 bridge path를 쓰는지, 어떤 withdrawal delay와 validator model을 쓰는지, 최대 손실 경계가 어디인지 설명해야 한다.

5. 내 프로젝트에 적용할 체크포인트

• quorum 독립성 표 만들기: signer 수만 쓰지 말고 각 signer의 조직, cloud account, key storage, deploy 권한, alert owner를 표로 적는다.
• hot key 최소화: 자동 서명이 필요해도 고액 출금 signer는 cold/MPC/HSM, 별도 approval, 별도 network boundary를 둔다.
• 금액 기반 지연: 모든 출금에 같은 dispute window를 두지 않는다. TVL의 1%, 5%, 20% 이상이면 지연과 승인 단계를 다르게 둔다.
• validator 변경 timelock: signer 추가·교체·threshold 변경은 즉시 적용하지 말고 public delay와 monitoring event를 둔다.
• build-to-validator 경로 차단: 개발 환경 compromise가 validator system으로 이어지지 않게 CI secret, artifact signing, production signer 권한을 분리한다.
• bridge path 라벨링: canonical bridge, third-party bridge, app-operated custody bridge를 UI와 문서에서 명확히 구분한다.
• 정상 서명 이상 탐지: 유효한 서명이라도 금액, 빈도, 목적지, 시간대가 비정상적이면 finalize 전에 멈출 수 있어야 한다.

6. 오늘 10분 액션

1. 내가 쓰는 DeFi 앱 하나의 입출금 경로를 열고 “canonical bridge인지, 앱 운영 bridge인지, CEX/커스터디 경로인지”를 적어본다.
2. 내 프로젝트에 bridge나 admin signer가 있다면 signer_count, threshold, key_storage, shared_infra, withdrawal_delay, emergency_pause_owner 여섯 칸짜리 표를 만든다.
3. “valid signature but malicious intent” 상황을 하나 상상하고, 컨트랙트가 멈출 수 있는지·운영자가 알 수 있는지·사용자에게 설명되어 있는지 체크한다.

7. 더 볼 자료

• CoinDesk의 AFX 사건 보도: hot-validator signature와 Arbitrum native bridge 구분을 이해하기 좋다.
• ForkLog의 사건 정리: AFX의 bridge 중단, 조사 파트너, white-hat settlement offer, 미확정 attack vector를 함께 볼 수 있다.
• Arbiscan 거래 페이지: 실제 상태 전이, 함수 호출, USDC 전송량, timestamp를 확인할 수 있다.
• Arbitrum token bridging overview: canonical bridge와 cross-chain messaging 개념을 비교 기준으로 삼기 좋다.

중복 회피 메모

로컬 content/generated와 Supabase의 최근 blockchain_dev 글을 확인했다. 최근 글은 OP Stack interop의 cross-safe fork choice, Chainlink SVR/OEV, Arbitrum Timeboost sequencing, KelpDAO/LayerZero DVN RPC quorum, EIP-4444 history expiry, EIP-7917 proposer lookahead, EIP-7939 CLZ opcode, EIP-7907 code size gas, Solana Alpenglow finality, Taiko bridge origin verification, OP Stack fault proof soundness, ERC-4626 NAV manipulation, ERC-1271 fail-closed 검증 등을 다뤘다. 이번 글은 브리지 proof 파싱이나 RPC quorum, L2 fork choice를 반복하지 않고, AFX Trade의 2026년 7월 bridge incident를 통해 “온체인 서명 검증이 맞아도 hot-validator key 운영 계약이 깨지면 잘못된 출금이 정상 상태 전이로 처리된다”는 operational trust boundary에 집중해 중복을 피했다.