블록체인은 정말 바뀌지 않는가: 불변성과 업그레이드 가능성 사이

• 한 번 배포된 스마트 컨트랙트의 코드는 같은 주소에서 직접 수정할 수 없지만, 프록시 아키텍처를 적용하면 동일한 주소와 상태를 유지한 채 실행 로직만 유연하게 교체할 수 있습니다.
• 업그레이드 권한은 파라미터 조정을 넘어 프로토콜의 메커니즘 자체를 재정의하는 강력한 권한입니다. 핵심 리스크는 코드 변경 유무보다도 권한 주체, 변경 절차, 영향 범위의 설계에 있습니다.
• 불변 컨트랙트는 버그를 직접 수정하기 어렵고, 업그레이드 가능한 컨트랙트는 관리자와 거버넌스를 신뢰해야 한다는 부담이 있습니다.

불변 컨트랙트와 가변 시스템

블록체인은 불변성을 핵심 가치로 내세웁니다. 이더리움에 한 번 배포된 스마트 컨트랙트의 코드는 기존 주소에서 직접 수정할 수 없습니다.

그러나 실제 디파이 프로토콜은 새로운 담보 자산을 추가하고, 수수료와 위험 기준을 조정하며, 발견된 취약점을 수정합니다. 사용자 잔액과 포지션은 그대로인데 프로토콜의 기능만 달라지기도 합니다.

이러한 변화는 기존 코드를 덮어쓰는 것이 아니라, 새로운 코드를 별도의 컨트랙트로 배포한 뒤 시스템이 참조하는 주소를 바꾸는 방식으로 구현됩니다. 이더리움 공식 문서 역시 배포된 주소의 프로그램 자체는 변경할 수 없지만, 사용자가 해당 컨트랙트와 상호작용할 때 실행되는 코드는 바꿀 수 있다고 설명하고 있습니다.

이를 가능하게 하는 것이 프록시 컨트랙트입니다.

사용자
  ↓
프록시 컨트랙트
- 고정된 주소
- 잔액·담보·부채 등 상태 보관
  ↓
구현 컨트랙트
- 실제 실행 로직
- V1 → V2 → V3로 교체 가능

사용자는 항상 프록시 주소와 상호작용합니다. 프록시는 호출을 현재 연결된 구현 컨트랙트로 전달하고, 구현 컨트랙트의 코드는 프록시가 보관한 상태를 기준으로 실행됩니다.

업그레이드는 기존 코드를 수정하는 것이 아니라, 프록시가 참조하는 구현 컨트랙트를 바꾸는 작업입니다.

업그레이드가 필요하면 구현 컨트랙트 V2를 새로 배포하고, 프록시에 저장된 구현 주소를 V1에서 V2로 변경합니다. ERC-1967은 구현 주소와 관리자 주소 등 프록시 관리 정보를 저장하는 위치를 표준화해, 일반 상태 변수와의 충돌 가능성을 줄입니다.

관리자 키의 통제 범위

프록시가 참조하는 구현 주소를 변경하려면 누군가에게 업그레이드 권한을 부여해야 합니다.

문제는 이 권한이 일반적인 관리자 권한보다 훨씬 강력하다는 점입니다. 수수료 조정 권한은 기존 코드가 허용한 범위 안에서만 작동합니다. 반면 구현 컨트랙트를 교체할 수 있는 권한은 그 범위 자체를 다시 정의할 수 있습니다.

새로운 구현 코드가 기존 프록시의 잔액과 상태에 접근할 수 있다면, 구조에 따라 출금 조건, 담보 계산, 청산 방식, 수수료 처리 등 프로토콜의 핵심 규칙까지 바꿀 수 있습니다.

단일 개인 지갑이 이 권한을 보유하면 키 하나의 탈취나 오용이 시스템 전체의 위험으로 이어집니다. 이를 완화하기 위해 여러 명의 승인이 필요한 멀티시그나 토큰 보유자의 투표를 거치는 DAO 거버넌스가 사용됩니다.

그러나 멀티시그가 곧 탈중앙화를 의미하지는 않습니다. 5명 중 3명의 승인이 필요한 구조라도 서명자들이 모두 같은 회사에 속해 있거나 동일한 운영 환경에서 키를 관리한다면, 실질적으로는 소수 운영위원회에 가까울 수 있습니다.

DAO 역시 마찬가지입니다. 투표가 온체인에서 이루어진다는 사실과 의사결정 권력이 충분히 분산돼 있다는 것은 별개의 문제입니다. 투표권 집중도, 위임 구조, 참여율, 제안 권한까지 함께 확인해야 합니다.

Compound III의 경우 거버넌스 타임락이 각 프록시와 구현 컨트랙트를 통제하며, 승인된 제안이 실행되면 프록시가 새로운 구현을 참조하도록 변경할 수 있습니다. 이는 거버넌스가 추상적인 의견 수렴 절차가 아니라 실제 프로토콜 코드를 교체하는 운영 권한임을 보여줍니다.

타임락과 긴급 정지

업그레이드 권한을 안전하게 운영하려면 일반적인 변경은 늦추고, 긴급 상황에는 빠르게 대응할 수 있어야 합니다. 일반적인 업그레이드에는 타임락을 적용해 검토 시간을 확보하고, 해킹과 같은 긴급 상황에서는 특정 기능을 즉시 정지할 수 있도록 설계합니다.

타임락이 적용된 업그레이드는 제안이 승인되더라도 즉시 실행되지 않습니다. 정해진 대기 시간이 지난 뒤에야 실제 코드 변경이 이루어집니다. Compound의 기존 거버넌스 구조에서는 제안 검토, 투표, 타임락을 포함해 프로토콜 변경에 최소 일주일이 필요하도록 설계됐습니다.

타임락은 변경 내용을 사전에 공개해 사용자와 보안 연구자에게 검토할 시간을 제공합니다. 위험하다고 판단한 사용자가 실행 전에 포지션을 정리하거나 자금을 회수할 수 있는 안전 장치인 셈입니다.

해킹이 진행되는 동안 거버넌스 투표와 타임락을 모두 기다린다면 피해가 계속 확대될 수 있습니다. 긴급 정지는 예치, 대출, 스왑 등 취약한 기능을 즉시 멈춰 추가 피해를 제한합니다. OpenZeppelin도 Pausable을 보안 문제를 해결하는 동안 기능을 중단할 수 있는 비상 대응 장치로 정의합니다.

좋은 권한 구조는 다음과 같이 역할을 분리합니다.

• 구현 교체와 핵심 규칙 변경은 멀티시그, 거버넌스, 타임락을 거쳐 실행합니다.
• 긴급 관리자는 위험이 확산되는 기능만 제한적으로 정지할 수 있습니다.
• 긴급 권한만으로 코드를 교체하거나 사용자 자산을 이동할 수 없도록 제한합니다.

즉, 권한이 강할수록 실행 절차를 엄격하게 하고, 긴급 권한은 행사 범위를 최소화해야 합니다. 긴급 정지가 모든 출금까지 차단한다면 보안 장치가 동시에 사용자 자산에 대한 통제 수단이 될 수 있습니다. 따라서 정지 기능의 존재만 볼 것이 아니라 어떤 기능을 멈출 수 있고, 누가 다시 재개할 수 있는지까지 확인해야 합니다.

업그레이드 기능 자체도 공격 표면

업그레이드 구조는 기존 컨트랙트의 버그를 수정할 수 있게 하지만, 동시에 새로운 종류의 취약점을 만듭니다.

대표적인 위험은 기존 상태와 새로운 코드의 저장 구조가 맞지 않는 경우입니다. 잔액이 기록된 저장 공간을 새 구현 코드가 다른 변수로 해석하면 데이터가 삭제되지 않았더라도 전혀 다른 의미로 읽힐 수 있습니다. 기존 금융 상태를 그대로 유지한 채 실행 로직만 바꾸기 때문에, 이전 버전과의 저장 구조 호환성이 특히 중요합니다.

초기화 과정도 문제입니다. 프록시 구조에서는 일반 컨트랙트의 생성자 대신 별도의 초기화 함수를 사용하는 경우가 많습니다. 초기화가 누락되거나 잘못 설정되면 공격자가 관리자 권한을 먼저 획득할 수 있습니다.

2021년에는 OpenZeppelin의 UUPS 업그레이드 구조에서 초기화되지 않은 구현 컨트랙트를 악용할 수 있는 치명적 취약점이 발견됐습니다. OpenZeppelin은 영향을 받을 수 있는 프로젝트를 대상으로 사전 완화 조치를 진행했고, 확인된 자금 손실 없이 수정 버전을 배포했습니다.

또한 이전 버전이 감사를 받았다는 사실은 새 버전의 안전성을 보장하지 않습니다. 프록시 주소가 동일하기 때문에 사용자는 같은 프로토콜을 이용한다고 느끼지만, 실제 실행 코드는 업그레이드 전후로 완전히 달라질 수 있습니다. 따라서 감사 이력만 볼 것이 아니라, 현재 연결된 구현 컨트랙트와 해당 버전의 감사 여부를 확인해야 합니다.

불변성과 업그레이드 가능성

업그레이드 가능성과 불변성 중 어느 한쪽이 절대적으로 안전한 것은 아닙니다.

완전히 불변인 컨트랙트는 관리자 신뢰를 줄일 수 있지만, 치명적인 버그가 발견돼도 수정할 수 없습니다. 새로운 컨트랙트를 배포하고 사용자 자산과 유동성을 이전해야 하며, 다른 프로토콜과의 연동도 다시 구축해야 합니다.

반대로 업그레이드 가능한 컨트랙트는 신속한 패치와 기능 개선이 가능하지만, 사용자는 현재 코드뿐 아니라 미래의 코드를 선택할 관리자와 거버넌스도 신뢰해야 합니다.

불변 컨트랙트는 초기 코드에 문제가 생겼을 때 직접 수정하기 어렵고, 새 버전으로 자산과 유동성을 이전해야 할 수 있습니다. 업그레이드 가능한 컨트랙트는 수정이 가능하지만, 관리자 권한의 탈취나 오용 위험이 계속 남습니다.

프로토콜이 안정화된 이후에는 핵심 기능의 변경 범위를 줄이고 오라클, 담보 한도, 수수료 등 운영상 조정이 필요한 요소만 별도로 관리하는 방식도 고려할 수 있습니다.

마무리

업그레이드 가능한 스마트 컨트랙트는 블록체인의 불변성을 깨는 예외가 아닙니다. 배포된 코드와 과거 거래는 그대로 남습니다. 새로운 구현 컨트랙트가 추가되고, 프록시가 앞으로 어떤 코드를 실행할지 결정하는 연결 정보가 변경될 뿐입니다.

중요한 것은 프록시 방식 자체보다 업그레이드 권한이 어떻게 관리되는지입니다. 누가 프로토콜의 규칙을 바꿀 수 있는지, 그 권한이 얼마나 분산돼 있는지, 변경 전에 사용자가 대응할 시간이 있는지, 긴급 권한의 범위가 어디까지인지가 더 중요합니다.

업그레이드 가능한 프로토콜에서는 코드뿐 아니라 권한 구조와 변경 절차도 신뢰의 대상이 됩니다. 업그레이드 기능이 있다는 사실만으로 안전성을 판단하기는 어렵습니다. 이를 위해선 권한의 범위와 변경 절차, 견제 장치를 함께 확인해야 합니다.

면책 고지: 본 콘텐츠는 일반 정보 제공 및 교육 목적만을 위해 "있는 그대로" 제공되며, 어떠한 종류의 진술이나 보증도 포함하지 않습니다. 본 콘텐츠는 금융, 법률 또는 기타 전문 자문으로 해석되어서는 안 되며, 특정 상품이나 서비스의 구매를 권유하기 위한 목적도 아닙니다. 필요할 경우 적절한 전문 자문가로부터 별도의 조언을 구하시기 바랍니다. 본 콘텐츠가 제3자 기고자에 의해 제공된 경우, 해당 견해는 제3자 기고자의 의견이며 고팍스의 견해를 반드시 반영하는 것은 아닙니다. 가상자산 가격은 변동성이 클 수 있습니다. 투자금의 가치는 하락하거나 상승할 수 있으며, 투자 원금을 회수하지 못할 수도 있습니다. 투자 결정에 대한 책임은 전적으로 본인에게 있으며, 고팍스 아카데미는 귀하에게 발생할 수 있는 어떠한 손실에 대해서도 책임을 지지 않습니다.