---
title: "거버넌스 타임록은 어떻게 작동하는가?"
description: "거버넌스 타임록은 승인된 조치를 실행 전 대기가 필요한 공개 관찰 가능 작업으로 전환합니다. ID, 역할, 지연, 만료, 취소, 이탈 가능 시간의 작동 방식을 설명합니다."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 거버넌스 타임록은 어떻게 작동하는가?
> 교육 목적으로만 제공되며 투자 조언이 아닙니다. 투자로 손실이 발생할 수 있습니다.
## 직접 답변
거버넌스 타임록은 실행을 통제하는 장치이지 또 다른 투표가 아닙니다. 거버넌스가 페이로드를 승인하면 권한을 가진 제안자가 정확한 작업을 예약합니다. 컨트랙트는 실행 가능 시점을 기록하고 그 전의 실행을 거부합니다. 이 지연 덕분에 보류 중인 업그레이드, 매개변수 변경, 금고 자금 이체, 역할 변경을 효력이 발생하기 전에 관찰할 수 있습니다.
공식적으로 표시된 지연 시간은 통제 체계의 한 부분일 뿐입니다. 작업 ID, 가장 이른 실행 시점, 만료 규칙, 선행 작업, 제안자, 실행자, 취소자, 관리자, 그리고 대상을 통제할 수 있는 다른 모든 경로를 검토해야 합니다. 작업이 늦게 대기열에 들어가거나, 모니터링이 늦게 감지하거나, 출금에 더 오래 걸리거나, 별도의 특권 키가 같은 변경을 즉시 수행할 수 있다면 `48-hour` 타임록이 `48-hour`의 이탈 가능 시간을 제공하는 것은 아닙니다.
타임록은 조치가 정당하거나 안전한지 판단하지 않습니다. 사람과 자동 모니터링 시스템이 호출을 디코딩하고, 영향을 시뮬레이션하고, 권한이 있을 때 취소하거나 일시 중지하고, 변경 사항을 알리고, 실제 이탈 경로가 있을 때 포지션을 정리할 시간을 제공합니다.
## 작동 방식
1. **권한을 타임록에 부여합니다.** 타임록은 대상 컨트랙트를 소유하거나 그 컨트랙트에서 관련 역할을 보유해야 합니다. 거버너가 대상에 대한 권한이 없다면 제안이 통과되어도 아무것도 바뀌지 않습니다. 별도의 관리자가 병렬 권한을 계속 보유한다면 그 경로로 지연을 우회할 수 있습니다.
2. **제안자가 정확한 작업을 예약합니다.** OpenZeppelin의 `TimelockController`에서 단일 작업 ID는 `target`, `value`, `data`, `predecessor`, `salt`를 해시하여 생성합니다. 일괄 작업은 해당 배열에 같은 종속성과 솔트를 더해 해시합니다. 어느 필드든 바꾸면 다른 작업 ID가 만들어집니다. 솔트는 나머지가 동일한 작업을 구분합니다.
3. **최소 지연 시간은 예약 시점에 시작됩니다.** 투표 통과가 반드시 타임록의 시작을 의미하지는 않습니다. 예약할 때 컨트랙트의 현재 최소 지연 시간 이상인 지연을 적용해 준비 시각을 기록합니다. OpenZeppelin 작업은 `Unset`에서 `Waiting`, 이어서 `Ready`로 이동하고, 성공적으로 실행되면 마지막으로 `Done`이 됩니다.
4. **실행 시 종속성과 권한을 확인합니다.** 선행 작업은 이미 `Done` 상태여야 합니다. 호출자는 실행자 규칙을 충족해야 하며 대상 호출도 성공해야 합니다. 실행자는 예약된 페이로드를 변경할 수 없습니다. 실행자 역할을 `address(0)`에 부여하면 작업이 성숙한 후 누구나 실행할 수 있어 가용성이 높아지지만, 어느 계정이든 실행 가능해진 뒤의 정확한 실행 시점을 선택할 수 있습니다.
5. **취소하면 보류 중인 작업이 초기 상태로 돌아갑니다.** 현재 OpenZeppelin 컨트랙트에서는 `CANCELLER_ROLE`을 가진 계정이 이미 준비되었지만 아직 실행되지 않은 작업을 포함해 보류 중인 작업을 취소할 수 있습니다. 다시 예약하면 새 타이머가 시작됩니다. 역할 설정이 중요합니다. 구버전이나 다른 타임록에서는 제안자 또는 관리자에게 취소 권한을 줄 수 있습니다.
6. **만료 여부는 구현에 따라 다릅니다.** OpenZeppelin의 `TimelockController`에는 유예 기간에 따른 만료 기능이 내장되어 있지 않습니다. 준비된 작업은 실행되거나 취소될 때까지 준비 상태로 남습니다. 반면 Compound v2의 Timelock은 늦어도 `eta + GRACE_PERIOD`까지 실행하도록 요구하며, 소스 코드는 `GRACE_PERIOD`를 `14 days`로 설정합니다. Governor Bravo는 그 경계를 지난 대기열 등록 제안을 만료된 것으로 표시합니다.
7. **관리 권한 변경에도 지연을 적용해야 합니다.** OpenZeppelin은 타임록이 자신을 호출하는 방식으로만 `updateDelay`를 실행할 수 있게 합니다. 자체 관리형 배포는 역할 변경도 마찬가지로 예약된 작업을 거치도록 강제합니다. 초기 설정 중 사용한 임시 외부 관리자는 구성이 끝난 뒤 해당 역할을 포기해야 합니다. 그렇지 않으면 별도의 신뢰 경로로 남습니다.
대기열에 등록된 조치마다 컨트랙트 상태와 이벤트를 바탕으로 통제 기록을 재구성해야 합니다. 기록할 항목은 체인 ID, 타임록 및 대상 주소, 작업 ID, 디코딩된 페이로드, 제안자, 예약 트랜잭션과 타임스탬프, 최소 지연 시간, 준비 시각, 만료 시각이 있다면 해당 시각, 선행 작업, 실행자 정책, 취소 권한, 최종 트랜잭션 상태입니다. 거버넌스 웹사이트만 보고 이 필드들을 추정해서는 안 됩니다.
## 예시
어떤 제안이 대출 시장의 청산 임계값을 `75%`에서 `60%`로 낮춘다고 가정해 보겠습니다. 투표는 `Monday 12:00 UTC`에 끝나지만 제안자는 `Tuesday 18:00 UTC`가 되어서야 작업을 예약합니다. 설정된 지연은 `48 hours`이므로 가장 이른 실행 시점은 `Wednesday 12:00 UTC`가 아니라 `Thursday 18:00 UTC`입니다.
이 작업은 리스크 관리자 컨트랙트를 `target`으로, 네이티브 토큰 `value`를 영으로 설정하고, 인코딩된 매개변수 변경 `data`, 선행 작업 없음, 공개된 `salt`를 포함합니다. 이 필드들로 해시를 다시 계산한 결과는 이벤트에서 나온 작업 ID와 일치해야 합니다. 화면의 설명이 같아 보여도 시장 주소, 임계값, 솔트 중 하나가 다르면 별개의 작업입니다.
따라서 사용자는 예약 시점부터 `48 hours`를 갖지만 실제 이탈에 쓸 수 있는 시간은 더 짧습니다. 알림이 예약 후 `6 hours` 뒤에 도착하고 언스테이킹이나 출금 대기열에 `24 hours`가 걸린다면 남는 여유 시간은 `18 hours`뿐입니다.
`usable response time = ready time - detection time - exit settlement time`
긴급 멀티시그가 출금을 즉시 일시 중지할 수 있다면 사고 중 손실을 줄일 수 있지만, 대기열에 등록된 변경이 실행되기 전에 이탈하지 못하게 만들 수도 있습니다. 이 권한은 별도로 검토해야 합니다. 실행 후에는 대상의 실제 저장 상태와 발생한 이벤트를 확인하십시오. 타임록 실행 트랜잭션이 성공해도 기대한 경제적 결과에 대한 이해가 정확하다는 보장은 없습니다.
## 위험과 통제 수단
- **우회 권한.** 소유자, 프록시 관리자, 접근 제어 역할, 업그레이드 비콘, 긴급 위원회, 모듈, 크로스체인 실행자를 모두 확인합니다. 가장 짧은 특권 경로가 실질적인 지연 시간을 결정합니다.
- **페이로드 대체 또는 불충분한 디코딩.** 원시 필드로 작업 ID를 다시 계산하고, 프록시 구현을 확인하고, 모든 선택자와 인수를 디코딩한 뒤 전체 일괄 작업을 시뮬레이션합니다. 사람이 읽는 제안 문구는 실행 페이로드가 아닙니다.
- **불충분한 사전 통지.** 포럼 게시물뿐 아니라 온체인 예약 및 취소 이벤트를 기준으로 경보를 발생시킵니다. 예약이 확정된 시점부터 가장 이른 실행 가능 블록이나 타임스탬프까지를 통지 시간으로 계산한 뒤 감지 및 이탈 결제 시간을 뺍니다.
- **취소 기능 실패.** 어떤 계정이 취소할 수 있는지, 실제로 사용 가능한지, 어떤 서명 임계값이 필요한지, 작업이 준비된 뒤에도 취소할 수 있는지 확인합니다. 사고가 발생하기 전에 트랜잭션을 예행연습하십시오.
- **실행자 장애 또는 타이밍 조작.** 제한된 실행자는 사용할 수 없게 되거나 고의로 실행을 늦출 수 있습니다. 공개 실행은 가용성을 높이지만 제삼자가 성숙 직후 실행할 수 있게 하므로 관련 가격, 오라클 업데이트, 사용자 포지션이 그 경계 시점에 안전해야 합니다.
- **오래된 대기열 작업.** 만료가 없다면 오래전에 준비된 작업이 무기한 실행 가능한 상태로 남을 수 있습니다. 포기한 작업을 추적하고 명시적으로 취소하십시오. 유예 기간이 있다면 정확한 종료 시점을 모니터링하고 만료 후에는 새로운 거버넌스 절차를 요구해야 합니다.
- **종속성과 일괄 작업 위험.** 선행 작업 ID와 원자적 일괄 작업의 순서를 검증합니다. 호출 하나가 되돌려지면 원자적 일괄 작업 전체가 막힐 수 있고, 잘못된 종속성이 유효한 작업을 교착 상태로 만들 수도 있습니다.
- **안전하지 않은 관리.** 지연 시간 단축, 역할 부여, 타임록 교체도 타임록 자체의 적용을 받게 합니다. 배포 관리자를 제거하고 사용 가능한 제안자와 실행자를 적어도 하나씩 유지하며, 통제 권한이 영구히 잠기는 구성을 피하십시오.
- **신뢰할 수 있는 이탈 경로 부재.** 지연 시간을 출금 대기열, 브리지 완결성, 시장 유동성, 일시 중지 권한, 혼잡과 비교합니다. 실행 전에 자산을 이동할 수 없다면 공개된 지연 시간은 사용자를 보호하지 못합니다.
운영상의 기준은 화면에 표시된 카운트다운이 아니라 증거로 뒷받침되는 타임라인입니다. 예약 이벤트, 디코딩된 호출, 시뮬레이션 결과, 역할 보유자, 취소 계획, 가장 이른 실행 시각과 최종 실행 가능 시각, 소통 채널, 실행 후 상태 차이를 보관하십시오.
## 흔한 오해
- **"투표가 끝나면 지연이 시작된다."** 배포된 구현이 두 시점을 명시적으로 연결하지 않는 한, 일반적으로 통과된 조치가 예약된 시점부터 시작됩니다.
- **"누구나 실행할 수 있으니 누구나 제안을 바꿀 수 있다."** 공개 실행자는 작업 ID와 조건이 일치하는 이미 예약된 페이로드만 실행할 수 있습니다.
- **"준비 상태가 되면 즉시 실행되어야 한다."** 준비 상태는 실행 자격이 생겼다는 뜻입니다. 실제 실행에는 트랜잭션, 권한, 충족된 종속성, 성공하는 대상 호출이 여전히 필요합니다.
- **"모든 타임록에는 실행 가능 기간이 있다."** 만료는 구현마다 다릅니다. Compound v2는 유예 기간을 사용하지만 OpenZeppelin의 `TimelockController`는 기본적으로 준비된 작업을 만료시키지 않습니다.
- **"긴 타임록은 거버넌스 위험을 없앤다."** 지연은 모니터링, 내용 이해, 취소 또는 일시 중지, 소통, 이탈이 모두 실행 전에 가능할 때만 도움이 됩니다. 병렬 관리자와 막힌 출금은 그 효과를 무력화할 수 있습니다.
## 관련 주제
- [탈중앙화 자율 조직(DAO)](/ko/crypto/dao/)
- [거버넌스 공격](/ko/crypto/governance-attack/)
- [프로토콜 긴급 일시 중지](/ko/crypto/protocol-emergency-pause/)
- [프록시 컨트랙트](/ko/crypto/proxy-contract/)
- [타임록](/ko/crypto/timelock/)
## 출처
- [Governance API: TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance#TimelockController) - OpenZeppelin Documentation(확인일: 2026-08-20)
- [Access Control: Delayed operation](https://docs.openzeppelin.com/contracts/5.x/access-control#delayed_operation) - OpenZeppelin Documentation(확인일: 2026-08-20)
- [Timelock.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol) - Compound Finance(확인일: 2026-08-20)
- [GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) - Compound Finance(확인일: 2026-08-20)
Source: https://wiki.fcontext.com/ko/crypto/governance-timelock-operation/index.mdx