DeFi가 처음 모멘텀을 얻었을 때, 그 강력한 판매 포인트 중 하나는 불변성이었습니다. 지지자들은 스마트 계약을 거래소나 카지노 같은 중앙화된 서비스와 대비시켰습니다.
서사는 단순하고 설득력이 있었습니다.
- 중앙화된 거래소, 카지노, 결제 처리업체 등은 소유자에 대한 신뢰를 필요로 합니다. 소유자는 계정을 동결하거나 수수료를 변경하거나 암호화폐를 들고 도주하거나 정부의 첫 요청에 자산을 넘길 수 있습니다.
- 대조적으로 DeFi는 스마트 계약 코드의 신뢰성만을 요구하는 것으로 여겨졌습니다. 스마트 계약은 블록체인의 콘크리트로 둘러싸인 자판기로 제시되었습니다. 규칙은 사전에 알려져 있고, 개발자도, 경찰도, 법원도 런치 이후에는 이를 변경할 수 없습니다.
몇 년이 지났습니다. 오늘날 이 서사는 사실상 죽어버렸지만, 공개적으로 인정되는 일은 드뭅니다. 현대 DeFi 프로토콜(예: Aave, Compound, Uniswap V3, Sky Protocol, 다양한 브리지와 L2 솔루션)의 압도적 다수는 기술적 관점에서 업그레이드 가능(upgradeable)합니다. 이들의 관리자들은 스마트 계약을 정기적으로 백엔드를 업데이트할 수 있는 일반적인 웹 서버에 더 가깝게 만드는 키를 보유하고 있습니다.
이 조용한 혁명은 어떻게 일어났을까요? 개발자들은 정확히 어떻게 블록체인 불변성을 우회하는 법을 배웠을까요? 그리고 우리가 계속해서 '탈중앙화 금융'이라고 부르는 것들 안에 진정으로 불변인 것은 아직 남아 있을까요?
Anatomy of Control: How Proxy Contracts Work
많은 독자들은 이 지점에서 반대할 수 있습니다: “잠깐만요. DeFi 이념은 이더리움 내에서 등장했습니다. 논란이 된 The DAO 사건 이후로는 그 블록체인에서 어떤 것도 다시 쓰려는 사람은 없을 것입니다. 그러니 배포 후에는 어떤 스마트 계약의 코드도 불변으로 남아 있어야 합니다.”
그 말은 맞습니다. 이더리움뿐만 아니라 어떤 블록체인도 추가 전용(append-only) 데이터베이스입니다. 한 번 체인에 기록된 계약을 지우는 것은 불가능합니다.
하지만 개발자들은 결국 업계 표준이 된 우아한 우회법을 찾았습니다: 프록시 패턴(Proxy Pattern).
애플리케이션이 단일 계약이 아니라 두 개의 계약으로 구성된다고 상상해보세요.
- 프록시(Proxy)는 외부 인터페이스입니다. 사용자가 상호작용하는 고정된 온체인 주소를 가지고 있으며, 모든 토큰과 잔액 기록이 여기 저장됩니다. 그러나 이 계약은 의도적으로 얕습니다: 핵심 금융 로직을 포함하지 않습니다.
- 실행 구현(Implementation)은 내부 메커니즘입니다. 이곳에 이자 계산 방식, 토큰 스왑 방식, 누가 얼마를 인출할 수 있는지 등의 공식이 존재합니다. 하지만 이 계약 자체는 암호화폐를 보유하지 않습니다.
토큰을 예치하거나 인출할 때 당신은 프록시와 상호작용합니다. 프록시는 delegatecall이라는 낮은 수준 명령어를 사용해 Implementation 계약을 읽고 그 코드를 프록시 자신의 스토리지 컨텍스트에서 실행합니다.
프록시 계약 내부에는 현재 Implementation의 주소를 저장하는 변수(종종 내부 _implementation 함수로 노출됨)가 있습니다. 또한 관리자만 접근할 수 있는 특수 함수가 존재합니다: upgradeTo(newAddress).
언제든지 프록시 관리자는 다음을 할 수 있습니다:
- 새 기능이나 버그 수정을 위해 새로운 Implementation 계약을 블록체인에 배포한다;
- 프록시에서
upgradeTo를 호출해 새 Implementation 주소를 가리킨다.
그 후 프록시는 즉시 새로운 로직을 사용하기 시작합니다.
사용자 관점에서는 아무것도 변하지 않은 것처럼 보입니다. 계약 주소는 동일하고, 그들의 암호화폐는 여전히 그곳에 저장되어 있습니다. 그러나 실제로는 시스템의 규칙이 완전히 바뀌었을 수 있습니다.
관리자가 악의적인 Implementation(예: 관리자에게 모든 자금을 인출할 수 있게 하는)을 배포하면, 프록시는 무조건 해당 코드를 실행하므로 모든 암호화폐를 기꺼이 넘겨줄 것입니다.
우리는 왜 이에 동의했는가?
불변성에서 업그레이드 가능성으로의 전환은 악의에서 비롯된 것이 아니라 필요성에서 비롯되었습니다.
먼저 The DAO 사건을 떠올려봅시다. 그 스마트 계약의 취약점은 해커가 막대한 자금을 빼내는 것을 가능하게 했습니다. 이를 되돌리기 위해 이더리움 노드 운영자들은 암호화폐 순수주의자에게는 이단에 가까운 결정을 내렸습니다: 해커의 트랜잭션을 무효화하기 위해 블록체인 역사를 다시 썼습니다. 이 사건은 한 가지를 분명히 했습니다 - 불변 코드(immutable code)는 불변 버그를 의미한다. 계약에 결함이 있으면 패치할 수 없습니다. 그러면 남는 선택지는 두 가지뿐입니다: 전체 네트워크에 대한 중앙화된 통제(그때의 이더리움처럼), 또는 개별 계약에 대한 중앙화된 통제. 시간이 지나면서 업계는 덜 악한 것으로 보이는 쪽을 택했습니다: 생태계 수준에서는 탈중앙화의 외형을 유지하면서 계약 수준에서는 중앙화된 통제를 허용하는 것입니다.
둘째, 많은 DeFi 프로젝트는 사실상 스타트업입니다. 새로운 전략을 추가하고, 새로운 토큰을 지원하며, 엣지 케이스를 수정해야 합니다. 프록시 계약이 없었다면, 모든 업데이트마다 사용자는 오래된 계약에서 자금을 인출해 새 계약에 재예치해야 했을 것입니다. 그건 불편하고 비용이 많이 들며 채택에 불리합니다.
셋째, 규제 당국이 개입했습니다. DeFi는 스테이블코인에 크게 의존하며, 규제 당국은 주소 블랙리스트 기능이나 업그레이드 가능한 로직 같은 기능을 포함해야 금융 규제를 준수할 수 있다고 요구합니다. 한때 탈중앙화된 스테이블코인의 상징이던 MakerDAO조차도 압력에 굴복해야 했습니다. Sky Protocol로 리브랜딩하면서 관리자 통제 기능을 새 스테이블코인 USDS에 추가했습니다.
사용자들은 어떻게 반응했을까요? 그들은 지갑으로 투표했습니다. 높은 수익률(APY)과 세련된 인터페이스는 대부분의 사람들에게 탈중앙화 같은 추상적인 이상보다 더 중요했습니다.
탈중앙화의 환상: '레드 버튼'을 누르는 사람은 누구인가?
많은 프로젝트가 관리자 키가 한 개인에게 있지 않다는 이유만으로 자신들을 탈중앙화되었다고 주장합니다. 하지만 그것이 실제로 무언가를 바꾸는 걸까요?
업그레이드 키가 한 명의 개발자에게 있으면, 그것이 가장 위험한 시나리오입니다. 그 사람이 해킹을 당하거나(신체적·법적 압력 등) 압박을 받으면 사용자 자금은 한순간에 사라질 수 있습니다. 그럼에도 이런 구조는 특히 밈 코인 계약에서 여전히 흔합니다. 밈 코인은 종종 진지하게 다뤄지지 않기 때문입니다.
때로는 키가 여러 부분으로 나뉘어 보안이 강화된 듯 보입니다—예를 들어 다섯 명(보통 창업자와 초기 투자자)이 각각 하나씩 보유하고 변경을 위해 세 개의 서명이 필요하게 하는 식입니다. 그러나 이것도 여전히 중앙화입니다. 공모(collusion)가 가능하며, 국가의 개입도 가능합니다.
조금 더 안전한 옵션은 타임록(Timelock) 메커니즘입니다. 여기서는 관리자가 업그레이드를 예약할 수 있지만, 실제로는 24~48시간 이후에만 적용됩니다. 이는 사용자가 새 코드를 검토하고 악의적인 변경이면 자금을 인출할 시간을 줍니다. 그러나 현실에서는 아무도 스마트 계약을 24/7 감시하지 않습니다. 그리고 긴급 상황(예: 활성 익스플로잇)에서는 24~48시간은 공격자가 모든 것을 빼내기에 충분한 시간입니다.
덜 나쁜 선택은 DAO 기반 거버넌스입니다. Compound나 Uniswap 같은 프로토콜에서는 업그레이드 권한이 토큰 보유자 투표에 연결된 스마트 계약으로 처리됩니다. 충분한 찬성표가 있어야 변경이 일어납니다. 이론적으로 이는 진정한 탈중앙화를 향한 한 걸음입니다. 하지만 실제로는 a16z나 Polychain 같은 대형 VC 펀드가 너무 많은 거버넌스 토큰을 보유해 거의 모든 결정을 밀어붙일 수 있습니다. 게다가 투표 참여율이 종종 저조해 과정 자체를 통제하기가 쉽습니다.
불변성의 섬들: 아직 변하지 않는 것은 누구인가?
여전히 "코드가 법이다(code is law)"가 적용되는 DeFi 서비스가 있을까요? 있습니다—하지만 그들은 이제 생태계에서 매우 좁은 틈새를 차지합니다. 진정으로 불변인 스마트 계약의 드문 사례들입니다.
Uniswap V1 / V2
이 버전들의 유동성 풀은 완전히 불변입니다. 개발자도, 투자자도, 정부도 자금을 인출하거나 공식을 바꾸거나 규칙을 변경할 수 없습니다. 스마트 계약은 돌에 새겨진 것처럼 고정되어 있습니다—관리자 키도, 업그레이드 경로도 없습니다.
Liquity USD (LUSD)
LUSD 계약에는 관리자 키도 없고 업그레이드 함수도 없습니다. 시스템 파라미터는 출시 시 수학적으로 하드코딩되어 결코 변경될 수 없습니다. 이는 DeFi에서 가장 탄력적인 스테이블코인 중 하나로 만듭니다. 널리 사용되지는 않는데, 사람들은 유동성이 부족하다고 생각하기 때문일 수 있습니다. 하지만 그건 오해입니다:
- 프로토콜 수준에서 모든 LUSD는 항상 이를 뒷받침하는 ETH로 상환될 수 있습니다.
- rabbit.io에서는 LUSD가 제한이나 제약 없이 어떤 암호화폐로든 교환될 수 있습니다.
Tornado Cash V1 / V2
Tornado Cash 초기 버전의 계약은 라이브 환경에서 버그를 패치하기 위해 관리자 키를 가지고 있었습니다. 그러나 프로토콜이 안정성이 입증되자 통제를 포기했습니다: 관리자 키가 0x00...0000 주소로 넘겨져 계약을 완전한 불변으로 만들었습니다.
이 결정은 불변성이 거버넌스 공격으로부터 보호한다는 근본적 진실을 강조했습니다.
Tornado Cash V3를 교훈으로 보세요. 이 버전은 개선 사항을 도입했습니다: 유연한 예치 금액(단지 0.1, 1, 10, 100 ETH만이 아닌)과 Gnosis Chain을 통한 L2 기반의 프라이빗 전송 시스템. 이렇게 복잡한 프로토콜에 대해 업그레이드와 보안 패치를 가능하게 하려면 거버넌스를 DAO, 즉 TORN 토큰 보유자에게 맡겨야 했습니다.
2023년에 공격자는 겉보기에는 무해한 거버넌스 업데이트를 제안했습니다. 코드 안에 백도어가 숨겨져 있었습니다. 통과되자 공격자는 DAO에 대한 완전한 통제권을 얻었습니다. 그들은 계약 로직을 장악하고 일부 거버넌스 토큰을 탈취했습니다.
이런 공격은 불변 버전에서는 물리적으로 불가능했을 것입니다. 업그레이드 경로도 없고, 투표도 없고, 레드 버튼도 없었습니다.
이더리움 너머: 다른 생태계는 계약 업그레이드를 어떻게 다루나
프록시 계약은 EVM 호환 블록체인 전반에서 사실상 표준이 되었습니다. 비-EVM 생태계는 어떨까요?
솔라나(Solana)
많은 경우, 불변성은 이더리움보다 더 약합니다. 기본적으로 솔라나 스마트 계약은 업그레이드 권한(Upgrade Authority)을 통해 업그레이드될 수 있습니다. 개발자들은 이 권한을 포기하여 프로그램을 불변으로 만들 수 있지만, 솔라나의 빠르게 움직이는 혁신 중심 문화에서는 그렇게 하는 경우가 드뭅니다. Near Protocol에서도 유사한 상황이 있으며, 업그레이드 가능성이 표준입니다.
Polkadot과 Cosmos
이들 생태계는 다른 접근을 따릅니다: 업데이트는 계약 내부의 관리자 함수가 아니라 밸리데이터 수준의 거버넌스를 통해 일어납니다. 이러한 네트워크의 스마트 계약에 자금을 예치할 때, 당신은 계약 관리자 한 명을 신뢰하는 것이 아니라 체인 전체의 밸리데이터들이 정직하게 행동할 것이라는 점을 신뢰하는 것입니다.
카르다노(Cardano)
카르다노는 여러 형태의 스마트 계약을 지원하지만, 주된 것은 엄격한 불변성 모델을 중심으로 한 Plutus 스크립트입니다.
- Plutus 스크립트는 특정 UTXO에 묶여 있으며 그 코드가 주소 자체에 해시되어 저장됩니다.
- 한 번 배포되면 코드 변경은 불가능합니다.
- 개발자가 버그를 수정하거나 비즈니스 로직을 변경하려면 다른 해시를 가진 새 스크립트를 배포하고 자금을 수동으로 마이그레이션해야 합니다.
- 이 아키텍처 때문에 프록시 패턴은 불가능합니다.
기술적으로 카르다노는 오프체인 로직 계약도 지원해 관리자가 있는 업그레이드 가능한 시스템을 구축할 수는 있습니다. 그러나 실제로는 EVM 체인처럼 그런 설계는 드뭅니다.
비트코인 생태계
네, 비트코인에도 스마트 계약 프로토콜이 존재합니다.
- RGB
여기서는 스마트 계약과 토큰 상태가 체인이 아니라 사용자 기기 로컬에 저장됩니다. 업그레이드 가능한 중앙화된 계약이 존재하지 않습니다. 토큰 발행자가 새 규칙을 발표하면 사용자는 앱을 업데이트하듯 선택적으로 업데이트에 참여해야 합니다. 모든 사용자를 강제로 동시에 변경하는 방법은 없습니다. - Stacks
Stacks의 모든 스마트 계약은 배포 후 불변이 됩니다. 업데이트는 모듈식 아키텍처를 통해서만 도입될 수 있습니다: 새로운 기능은 원래 계약과 상호작용하는 별도의 계약으로 추가되지만 기존 규칙을 무효화하거나 덮어쓸 수는 없습니다. 즉, 모든 업데이트는 수정이 아니라 추가입니다. 원래 로직은 그대로 유지되며 배포된 계약의 어떤 부분도 소급하여 변경될 수 없습니다. - Elastos와 Rootstock
이들은 EVM 호환 사이드체인이며, 이더리움과 동일한 업그레이드 패턴을 따릅니다. 개발자들은 프록시 계약을 구현하고 관리자 통제를 유지할 수 있습니다.
따라서 전통적으로 유연성보다 불변성을 중시해온 비트코인 커뮤니티에서도 이제는 서비스 운영자가 사용자의 자금을 받은 후 규칙을 수정할 수 있게 하는 스마트 계약 프로토콜이 존재합니다.
결론
보면 “탈중앙화 애플리케이션”이라는 용어는 종종 마케팅 트릭에 불과한 경우가 많습니다. 반드시 나쁜 것만은 아닙니다: 스마트 계약을 업데이트할 수 있는 능력은 취약점이 발견되었을 때 수십억 달러를 구했습니다. 그러나 사용자들은 위험을 이해해야 합니다:
- 전통적인 중앙화된 서비스에서는 당신이 지갑의 키를 보유하지 않았다는 이유만으로 암호화폐를 잃을 수 있습니다.
- 현대의 DeFi에서는 관리자가 잠금장치(스마트 계약의 규칙)를 변경할 수 있다는 이유만으로 암호화폐를 잃을 수 있습니다.
진정한 불변성은 Tornado Cash Classic, Liquity, 그리고 Cardano의 네이티브 솔루션이나 Bitcoin 상단의 솔루션처럼 보수적인 프로토콜의 영역으로 남아 있습니다. 이들은 보안을 위해 유연성을 희생합니다. 그 외의 모든 것은 궁극적으로 신뢰로 귀결됩니다—반짝이는 “DAO” 라벨 뒤에 숨은 팀에 대한 신뢰입니다.
