# 설계 결함 공격 (Design Flaw Attack)

설계 결함 공격은 코드 구현 실수가 아니라 프로토콜·스마트 컨트랙트·시스템의 설계 자체에 있는 약점을 이용하는 공격입니다. 코드가 명세대로 정확히 작성되었더라도 명세가 잘못되어 있으면 공격이 가능하다는 점이 핵심입니다. 공격자가 처음부터 결함을 숨긴 컨트랙트나 서비스를 만들어 사용자를 끌어들이는 경우도 이 범주에 들어갑니다.

## 자세히 알아보기

보안 결함은 크게 **구현 결함**(버퍼 오버플로, 검사 누락 같은 코딩 실수)과 **설계 결함**(잘못된 가정, 경제적 유인 구조의 허점, 권한 설계 오류)으로 나눌 수 있습니다. 구현 결함은 패치로 고칠 수 있는 경우가 많지만, 설계 결함은 구조 자체를 바꿔야 해서 수정 비용이 큽니다. 코드 감사만으로는 잘 드러나지 않기 때문에 위협 모델링과 설계 단계 검토가 필요합니다.

대표적인 유형은 다음과 같습니다.

- **잘못된 신뢰 가정**: 조작 가능한 단일 가격 소스를 오라클로 믿는 설계.
- **경제적 허점**: 플래시 론으로 일시적으로 큰 자금을 빌려 거버넌스 투표나 가격을 조작할 수 있는 구조.
- **과도한 관리자 권한**: 운영자가 언제든 자금을 옮기거나 토큰을 무제한 발행할 수 있는 컨트랙트.

## 블록체인·암호화폐에서는

DeFi에서는 코드가 공개되어 있고 누구나 허가 없이 상호작용할 수 있기 때문에, 설계 결함은 발견되는 즉시 악용되는 경향이 있습니다. 또한 악의적인 개발자가 '매도 불가 토큰'(허니팟)이나 숨겨진 출금 함수를 넣어 두고 정상 프로젝트처럼 홍보하는 사기도 이 공격의 한 형태입니다.

이용자 입장에서는 감사 보고서 유무, 관리자 키·업그레이드 권한의 범위, 오라클 구조를 확인하는 것이 기본적인 방어입니다. 개발자는 설계 단계에서 공격자의 관점으로 위협 모델을 세워야 합니다.

설계 결함은 업그레이드 가능한 컨트랙트라면 고칠 수 있지만, 업그레이드 권한 자체가 또 다른 신뢰 지점이 됩니다. 그래서 타임락(변경 전 대기 시간)이나 멀티시그로 권한을 제한하는 설계가 함께 쓰입니다.

## 쉽게 말하면

벽돌 쌓기는 완벽했지만 설계도에서 비상구 위치를 잘못 정한 건물과 같습니다. 시공을 아무리 잘 점검해도 설계도 자체의 문제는 찾기 어렵습니다.

## 예시

어떤 대출 프로토콜이 담보 가치를 유동성이 적은 DEX 한 곳의 실시간 가격으로만 계산한다고 합시다. 공격자는 플래시 론으로 그 DEX의 가격을 한 블록 안에서 끌어올린 뒤, 부풀려진 담보로 대출을 최대한 받고 가격을 되돌려 놓을 수 있습니다. 코드에는 오류가 없지만 '이 가격은 조작할 수 없다'는 설계 가정이 틀렸기 때문에 생긴 공격입니다.

---
출처: https://achivx.kr/glossary/design-flaw-attack-%EB%94%94%EC%9E%90%EC%9D%B8-%EA%B2%B0%ED%95%A8-%EA%B3%B5%EA%B2%A9/ · ACHIVX 용어 사전 · 수정일 2026-10-20