설계 결함 공격

1.개요

설계 결함 공격(Design Flaw Attack)은 시스템의 코드가 의도대로 정확히 동작하더라도, 그 시스템을 설계할 때 세운 규칙과 구조 자체에 허점이 있어 공격자가 이를 악용하는 행위를 가리킨다. 즉 오탈자나 계산 실수 같은 구현 단계의 버그가 아니라, 설계 단계에서 미처 고려하지 못한 상호작용·유인 구조·예외 상황을 이용한다는 점이 특징이다.

일반적인 소프트웨어 취약점이 '코드가 설계와 다르게 동작해서' 생긴다면, 설계 결함은 '코드가 설계대로 정확히 동작하는데도' 문제가 생긴다는 점에서 구분된다. 이 때문에 설계 결함 공격은 코드 검토(코드 리뷰)만으로는 잘 드러나지 않고, 시스템 전체의 동작과 경제적 유인을 함께 분석해야 발견되는 경우가 많다.

블록체인·암호화폐 분야에서 이 개념이 특히 중요한 이유는, 스마트 컨트랙트가 한 번 배포되면 수정이 어렵고 자금을 직접 다루기 때문이다. 설계 단계에서 놓친 결함 하나가 곧바로 되돌리기 힘든 금전적 손실로 이어질 수 있다.

2.상세

설계 결함은 여러 계층에서 나타날 수 있다. 첫째로 합의 알고리즘 수준의 결함이 있는데, 특정 조건에서 소수의 참여자가 규칙을 악용해 부당한 이득을 얻을 수 있도록 인센티브 구조가 잘못 설계된 경우가 여기에 해당한다. 둘째로 스마트 컨트랙트 로직 수준의 결함이 있으며, 함수 호출 순서나 외부 계약과의 상호작용을 충분히 고려하지 않아 자금이 예상과 다르게 인출되는 사례가 대표적이다.

설계 결함 공격은 흔히 경제적·게임이론적 측면과 맞물린다. 예를 들어 51% 공격은 그 자체가 소프트웨어 버그가 아니라, 다수의 해시파워를 확보하면 장부를 되돌릴 수 있다는 작업증명 설계의 구조적 특성을 이용하는 것이다. 이처럼 '규칙대로 행동했는데 시스템에 해가 되는' 상황이 설계 결함 공격의 전형적인 모습이다.

방어는 근본적으로 설계 단계에서 이루어져야 한다. 배포 전 감사(audit), 형식 검증, 테스트넷에서의 충분한 검증, 그리고 위협 모델을 세워 공격자의 유인을 미리 점검하는 과정이 필요하다. 결함이 발견된 뒤에는 이미 배포된 규칙을 바꾸기 위해 하드 포크와 같은 대규모 네트워크 변경이 동원되기도 한다.

3.예시

가장 널리 인용되는 사례는 2016년 이더리움 기반 탈중앙화 자율 조직인 The DAO 사건이다. 공격자는 자금을 인출하는 함수가 잔액을 갱신하기 전에 외부 호출을 수행하도록 짜여 있는 점을 이용해, 같은 인출을 반복 실행하는 방식(재진입)으로 막대한 이더를 빼냈다. 이는 솔리디티로 작성된 컨트랙트가 자금 흐름의 순서를 안전하게 설계하지 못한 데서 비롯된 것으로, 결국 이더리움 커뮤니티는 하드 포크를 통해 대응했다.

이 사건은 개별 코드 한 줄의 오류라기보다, 외부 계약과의 상호작용 순서를 잘못 설계한 구조적 문제로 평가된다. 그 결과 이후 개발 관행에서는 '검사-효과-상호작용(checks-effects-interactions)' 패턴처럼 설계 차원의 방어 원칙이 표준으로 자리 잡았다.