투명 프록시(Transparent proxy)는 들어온 호출이 관리자 것인지 먼저 가려, 관리자 호출은 업그레이드 관리 함수로 처리하고 일반 사용자의 호출만 구현 계약(implementation)에 위임합니다. UUPS는 프록시를 단순한 ERC-1967 위임 프록시로 두고, 업그레이드 함수와 권한 검사를 구현 계약 코드가 맡습니다. 둘 다 같은 구현 슬롯을 쓸 수 있지만 권한 코드가 놓인 자리가 다릅니다. UUPS에서 새 구현이 업그레이드 기능이나 권한 검사를 실수로 빼 버리면 계약이 영구히 굳거나 탈취될 수 있습니다. UUPS용 구현을 투명 프록시 뒤에 잘못 붙이면 관리자가 아닌 사용자가 구현 쪽 업그레이드 함수에 닿는 조합 위험도 생길 수 있습니다.
권한 코드가 사는 위치가 다릅니다
투명 패턴에서 관리자의 호출은 프록시 관리 경로로 가고, 구현 계약의 폴백으로는 넘어가지 않습니다. 일반 사용자의 호출은 구현 계약으로 위임됩니다. 관리자가 프록시를 거쳐 구현 계약의 일반 함수를 부르지 못하게 막아 두었기 때문에 함수 선택자가 겹칠 때 생기는 혼동이 줄어듭니다.
UUPS 패턴에서는 ERC1967Proxy의 폴백이 대부분의 호출을 구현 계약에 넘기고, 구현 계약의 upgradeToAndCall 계열 함수가 ERC-1967 슬롯을 바꿉니다. _authorizeUpgrade는 소유자·역할·거버넌스 중 하나로 반드시 구현해야 합니다. 프록시 바이트코드가 작더라도 구현을 바꿀 때마다 업그레이드 로직을 다시 검증해야 합니다.
두 프록시는 같은 구현 슬롯을 쓸 수 있지만, 누가 그 슬롯을 바꾸는지 판정하는 코드는 서로 다른 주소에 있습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 권한 코드가 사는 위치가 다릅니다
투명 패턴에서 관리자의 호출은 프록시 관리 경로로 가고, 구현 계약의 폴백으로는 넘어가지 않습니다.
- 호출자별 분기를 표로 추적합니다
투명 프록시의 관리자가 업무용 선택자를 호출하면 구현 계약으로 넘어가지 않고, 관리 인터페이스 규칙에 따라 처리되거나 실패할 수 있습니다.
- 잘못된 구현 조합은 예상치 못한 업그레이드 경로를 엽니다
UUPS 기능이 있는 구현을 투명 프록시에 연결하면, 프록시 자체의 관리자 업그레이드 말고도 관리자가 아닌 사용자가 위임된 구현의 업그레이드 함수에 접근할 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
호출자별 분기를 표로 추적합니다
투명 프록시의 관리자가 업무용 선택자를 호출하면 구현 계약으로 넘어가지 않고, 관리 인터페이스 규칙에 따라 처리되거나 실패할 수 있습니다. 운영 관리자 주소를 일반 사용자 주소처럼 쓰면 기능 호출이 예상과 다르게 움직입니다. ProxyAdmin 같은 별도 관리 계약을 두는 이유가 여기에 있습니다.
UUPS에서는 일반 사용자도 구현 계약의 업그레이드 선택자에 닿을 수 있으므로, 함수 자체의 권한 검사가 마지막 방어선입니다. onlyProxy·proxiableUUID 검사는 delegatecall 실행 환경과 슬롯 호환성을 확인하는 데 쓰이지만 접근 제어를 대신하지 않습니다.
| 항목 | Transparent | UUPS |
|---|---|---|
| 업그레이드 로직 | 프록시·관리자 계층 | 구현 계약 |
| 일반 호출 분기 | 관리자 외 호출만 위임 | 대부분 위임 |
| 권한 변경 | 관리자·ProxyAdmin | _authorizeUpgrade |
| 새 구현 요건 | 업무 로직과 저장소 배치 | 저장소 배치와 업그레이드 기능 |
| 주요 오조합 | 관리자 사용 방식·선택자 | 권한 누락·영구 고정 |
잘못된 구현 조합은 예상치 못한 업그레이드 경로를 엽니다
UUPS 기능이 있는 구현을 투명 프록시에 연결하면, 프록시 자체의 관리자 업그레이드 말고도 관리자가 아닌 사용자가 위임된 구현의 업그레이드 함수에 접근할 수 있습니다. 그 함수가 제대로 막혀 있으면 거부되지만, 누구나 부를 수 있거나 소유자가 잘못 초기화돼 있다면 슬롯을 바꿀 수 있습니다.
반대로 UUPS 프록시를 업그레이드 함수가 없는 구현으로 바꾸면 그 뒤로는 정상적인 업그레이드 입구가 사라질 수 있습니다. 최신 라이브러리는 호환성 검사를 제공하지만, 직접 짠 어셈블리나 권한 우회가 없는지는 바이트코드와 테스트로 확인해야 합니다.
- 프록시 실행 코드를 보고 어떤 패턴인지 식별합니다.
- 구현·관리자 슬롯을 블록별로 읽습니다.
- 관리자·소유자·일반 사용자 세 호출자로 분기를 시험합니다.
- 새 구현의 proxiable UUID와 권한 검사를 확인합니다.
- 저장소 배치·초기화 함수와 되돌리기 절차를 검증합니다.
업그레이드 권한과 초기화 권한을 함께 봅니다
UUPS의 _authorizeUpgrade가 onlyOwner로 막혀 있어도, 프록시 소유자가 제로 주소이거나 공격자가 초기화 함수를 먼저 차지하면 방어가 무너집니다. 투명 프록시의 ProxyAdmin 소유권도 멀티시그·타임락이 실제로 어떻게 구성됐는지와 연결해 확인합니다. 소스 코드의 제어자 이름만 보고 권한자를 단정하지 않습니다.
업그레이드와 재초기화를 한 거래에 묶으면 새 코드에 필요한 상태를 곧바로 설정할 수 있습니다. 다만 delegatecall로 실행되는 초기화 함수가 되돌려질 때의 처리와 재진입은 시험해 봐야 합니다. 둘을 나누면 초기화가 끝나지 않은 중간 상태에서 공격 창이 생깁니다.
운영 증거는 슬롯·이벤트·권한 실행을 연결합니다
Upgraded 이벤트는 변경을 알아채는 데 유용하지만, 현재 구현 주소는 ERC-1967 슬롯 원본 값으로 확인합니다. 업그레이드 거래를 보낸 주소가 중계자나 타임락일 수 있으므로 최종 거버넌스 승인까지 거슬러 추적합니다.
점검표에는 프록시 주소, 패턴, 구현 코드 해시, 관리자 또는 권한 계약, 지연 시간, 저장소 배치 차이, 초기화 호출 데이터를 적습니다. ‘UUPS가 더 저렴하다’ 또는 ‘Transparent가 더 안전하다’ 같은 한 줄 평가 대신 실제 배포의 권한 경로를 따져 봅니다.
자주 묻는 질문
UUPS와 Transparent는 서로 다른 구현 슬롯을 쓰나요?
둘 다 ERC-1967 구현 슬롯을 쓸 수 있습니다. 핵심 차이는 업그레이드 로직과 호출 분기가 어디에 있느냐입니다.
UUPS의 proxiableUUID가 맞으면 안전한가요?
슬롯 호환성을 확인하는 데는 도움이 되지만 권한 검사, 저장소 배치, 업무 로직의 안전까지 보장하지는 않습니다.
Transparent 관리자도 일반 함수를 호출할 수 있나요?
프록시를 거친 관리자 호출은 보통 구현 계약으로 넘어가지 않습니다. 그래서 일반 기능은 별도 사용자 주소로 호출합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
