긴급 거버넌스는 일반 제안의 투표 기간을 단순히 줄인 절차가 아닐 수 있다. 헌법·정관·스마트계약이 특정 위원회에 별도 실행 권한을 위임할 수 있다. 공지에서는 누가 긴급성을 판정했는지, 몇 명의 승인이 필요한지, 어떤 계약 기능까지 실행할 수 있는지, 조치가 임시인지, 언제 공개·검토·해제되는지를 확인해야 한다.
긴급 절차는 먼저 권한의 출처를 찾는다
프로젝트가 ‘긴급 투표’를 열었다고 발표해도 커뮤니티 여론조사인지, 재단 이사회 결의인지, 온체인 Security Council 실행인지 알 수 없다. 헌법·정관·거버넌스 계약에서 긴급 조치를 정의한 조항과 위임 대상을 찾는다. 공지 채널의 직함만으로 권한을 인정하지 않는다.
Arbitrum Foundation 정관은 Security Council을 12명 위원회로 설명하고 ArbitrumDAO Constitution에 따른 Emergency Action과 Non-Emergency Action 권한을 위임한다. 같은 문서는 긴급 회의를 사전 통지 없이 소집할 수 있는 경우도 둔다. 이는 모든 DAO가 같은 구조라는 뜻이 아니라, 프로젝트별 문서가 실제 권한 범위를 정한다는 사례다.
긴급성은 절차 생략의 만능 근거가 아니라 미리 정한 예외 권한을 발동하는 조건이어야 한다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 긴급 절차는 먼저 권한의 출처를 찾는다
프로젝트가 ‘긴급 투표’를 열었다고 발표해도 커뮤니티 여론조사인지, 재단 이사회 결의인지, 온체인 Security Council 실행인지 알 수 없다.
- 투표 화면과 실행 거래를 따로 본다
오프체인 투표가 찬성으로 끝나도 실행자가 별도 거래를 제출해야 할 수 있다.
- 긴급과 비긴급 조치의 경계를 읽는다
동일한 위원회가 긴급 조치와 비긴급 조치를 모두 담당할 수 있지만 승인 수, 지연 시간, 공개 절차가 다를 수 있다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
투표 화면과 실행 거래를 따로 본다
오프체인 투표가 찬성으로 끝나도 실행자가 별도 거래를 제출해야 할 수 있다. 반대로 긴급 위원회는 공개 투표 전에 제한된 기능을 실행하고 사후 보고할 수 있다. 결과 화면, 서명자 승인, timelock 상태, 실제 계약 호출과 이벤트를 시간순으로 연결한다.
‘통과’라는 말은 제안 상태만 설명할 수 있다. 프록시 일시정지, 브리지 제한, 파라미터 변경이 실제 적용됐는지는 대상 계약의 상태와 거래 영수증을 확인한다. 실행 거래가 취소되거나 실패했으면 결의와 네트워크 상태가 다르다.
| 단계 | 확인 자료 | 핵심 질문 |
|---|---|---|
| 권한 | 헌법·정관·계약 | 누가 무엇을 할 수 있는가 |
| 결정 | 회의록·서명·투표 결과 | 정족수와 이해상충은 충족됐는가 |
| 실행 | 온체인 거래·이벤트 | 어떤 주소와 함수가 바뀌었는가 |
| 사후 통제 | 보고서·만료·취소 거래 | 조치가 검토되고 되돌려졌는가 |
긴급과 비긴급 조치의 경계를 읽는다
동일한 위원회가 긴급 조치와 비긴급 조치를 모두 담당할 수 있지만 승인 수, 지연 시간, 공개 절차가 다를 수 있다. 자금 탈취를 막기 위한 pause와 장기 수수료 정책 변경을 같은 경로로 처리하면 권한 남용 위험이 커진다. 정의 조항에서 긴급 상황의 유형과 허용되는 함수 목록을 찾는다.
긴급 권한이 프록시 업그레이드까지 가능한지, 특정 계약만 멈출 수 있는지, 사용자 자금을 직접 옮길 수 있는지에 따라 위험이 크게 달라진다. 문서상의 범위와 실제 멀티시그·역할 설정이 일치하는지 확인한다.
속도와 견제 장치를 함께 평가한다
빠른 대응은 공격 확산을 막지만 소수 인원에게 큰 권한을 집중시킨다. 최소 서명 수, 지역·조직 다양성, 키 회전, 임기, 이해상충 회피, 공개 지연 상한이 견제 장치다. 단순히 위원 수가 많다는 사실보다 한 거래를 실행하는 데 필요한 실제 임계값을 본다. 서명자가 같은 고용주나 같은 키 관리 인프라에 의존하는지도 공개 가능한 범위에서 점검해야 한다.
보안상 세부 내용을 즉시 공개하지 못할 수 있다. 그렇더라도 조치 존재, 영향 범위, 이용자 행동, 다음 업데이트 시각은 가능한 범위에서 알리고 위험이 낮아진 뒤 근거와 타임라인을 공개해야 한다. 영구 비공개를 ‘보안’으로 정당화하면 검증이 불가능해진다. 사후 보고가 예고됐다면 실제 게시됐는지와 미공개 항목의 이유도 추적한다.
- 헌법·정관·계약에서 긴급 권한 근거를 찾는다
- 위원 수와 실제 서명 임계값을 구분한다
- 결의와 온체인 실행 거래를 연결한다
- 영향 계약·함수·자산 범위를 확인한다
- 사후 보고·만료·권한 해제 거래를 추적한다
이용자 공지에서 찾아야 할 행동 정보
긴급 pause가 걸렸다면 예치, 출금, 브리지, 청산 중 무엇이 멈췄는지 확인한다. ‘프로토콜 중단’이라는 넓은 표현만으로는 포지션 관리가 가능한지 알 수 없다. 이미 제출한 거래의 처리 상태, 재개 전 취소 가능성, 공식 지원 채널을 찾아 기록한다.
긴급 조치를 빌미로 새 계약 주소로 자산을 옮기거나 시드 문구를 입력하라는 메시지는 피한다. 주소 변경이 필요한 경우에도 헌법상 권한, 공식 공지, 온체인 실행을 교차 확인한다. 위원 개인 계정의 글 하나는 충분한 근거가 아니다.
사건이 끝난 뒤 권한이 원상복구됐는지 본다
일시 권한은 사고 뒤에도 남을 수 있다. pause 해제만 보지 말고 임시 signer, 우회 모듈, 낮춘 threshold, 단축 timelock이 원래 설정으로 돌아갔는지 확인한다. 긴급 패치가 정상 거버넌스의 추인 대상이라면 제안과 결과도 추적한다.
사후 평가는 대응 속도만이 아니라 필요성, 비례성, 기간, 투명성을 본다. 실제 피해를 줄였어도 과도한 권한 사용이나 기록 누락은 개선 과제다. 반대로 정해진 범위 안에서 신속히 조치하고 검증 가능한 보고를 냈다면 제도 설계가 작동한 증거가 된다.
자주 묻는 질문
긴급 투표가 통과되면 바로 실행되나요?
구조에 따라 다르다. 별도 멀티시그·timelock·계약 거래가 필요할 수 있으므로 실행 증거를 확인한다.
보안 사고면 모든 정보를 비공개해도 되나요?
패치 전 세부 유예는 가능하지만 영향과 이용자 행동, 후속 공개 계획까지 영구히 숨기는 근거는 아니다.
위원이 12명이면 12명 모두 동의해야 하나요?
아니다. 실제 실행 임계값은 헌법과 계약 설정에 따른다. 구성원 수와 필요한 서명 수를 분리한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
