업그레이드할 수 있는 계약에서 프록시(proxy)는 사용자가 호출하고 상태를 보관하는 고정 주소입니다. 구현 계약(implementation)은 delegatecall로 실행될 로직 코드를 내줍니다. 그래서 토큰을 지갑에 추가하거나 디앱을 쓸 때는 보통 공식 문서에 적힌 프록시 주소를 쓰고, 탐색기에서 현재 구현 계약과 관리자·업그레이드 권한을 따로 확인합니다. 구현 계약 주소로 직접 호출하면 초기화 상태와 저장소 맥락이 달라 기대한 서비스와 다른 결과가 나올 수 있습니다.
상태와 코드를 나눈 구조입니다
OpenZeppelin은 업그레이드형 인스턴스가 구현 계약, 사용자가 상대하는 프록시, 관리용 ProxyAdmin으로 이뤄질 수 있다고 설명합니다. 프록시가 delegatecall을 하면 구현 계약의 코드는 프록시 주소와 그 저장소 맥락에서 실행됩니다. 토큰 잔액과 승인 한도가 프록시 쪽 상태로 보이는 까닭입니다.
사용자는 탐색기의 계약 탭에서 ‘Proxy’ 표시, ‘Read/Write as Proxy’ 메뉴, 구현 계약 링크를 볼 수 있습니다. 표시가 없다고 프록시가 아니라고 단정하지 말고 바이트코드, 표준 저장 슬롯, 배포 문서를 맞춰 보세요. 최소 복제(minimal clone)나 비컨(beacon) 프록시는 구조가 다를 수 있습니다.
프록시는 사용자가 드나드는 주소와 상태를 지키고, 구현 계약은 그 안에서 돌아갈 현재 코드를 맡습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 상태와 코드를 나눈 구조입니다
OpenZeppelin은 업그레이드형 인스턴스가 구현 계약, 사용자가 상대하는 프록시, 관리용 ProxyAdmin으로 이뤄질 수 있다고 설명합니다.
- ERC-1967 슬롯과 이벤트가 단서입니다
OpenZeppelin의 ERC1967Proxy는 구현 계약 주소를 충돌을 피하도록 정해 둔 저장 슬롯에 보관합니다.
- 지갑에는 공식 사용자 주소를 씁니다
토큰 공식 문서가 프록시 주소를 배포 주소로 내세운다면 토큰 직접 추가, 승인 한도 조회, 디앱 호출은 모두 그 주소를 기준으로 합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
ERC-1967 슬롯과 이벤트가 단서입니다
OpenZeppelin의 ERC1967Proxy는 구현 계약 주소를 충돌을 피하도록 정해 둔 저장 슬롯에 보관합니다. 공식 문서는 eth_getStorageAt으로 이 값을 읽을 수 있다고 안내합니다. 탐색기가 자동으로 해석해 주면 구현 주소와 Upgraded 이벤트를 쉽게 볼 수 있지만, 중요한 거래라면 원시 슬롯 값과 문서도 확인하세요.
투명 프록시(Transparent proxy)는 ProxyAdmin을 거쳐 업그레이드하고, UUPS 방식은 구현 계약 안의 업그레이드 함수를 씁니다. 비컨 프록시는 비컨이 가리키는 구현 계약 하나를 여러 프록시가 함께 쓸 수 있습니다. ‘프록시’라는 한 단어만으로 관리자 위치와 변경 절차를 짐작하지 않습니다.
| 주소 | 주요 역할 | 확인 항목 |
|---|---|---|
| 프록시 | 사용자 호출·상태 맥락 | 공식 주소·저장소 |
| 구현 계약 | 현재 로직 코드 | 검증된 소스·버전 |
| ProxyAdmin | 업그레이드 관리 | 소유자·다중서명 |
| 비컨 | 공유 구현 지정 | 소유자·구현 계약 |
| 최소 복제 | 고정 구현에 위임 | 대상 바이트코드 |
지갑에는 공식 사용자 주소를 씁니다
토큰 공식 문서가 프록시 주소를 배포 주소로 내세운다면 토큰 직접 추가, 승인 한도 조회, 디앱 호출은 모두 그 주소를 기준으로 합니다. 구현 계약 주소는 같은 ERC-20 함수를 드러내더라도 자체 저장소가 비어 있거나 초기화 상태가 달라 잔액이 0으로 보일 수 있습니다.
서명 화면의 받는 주소가 공식 프록시인지 확인하고 입력 데이터에 담긴 함수와 사용 권한자를 살펴보세요. 디앱이 구현 계약으로 바로 보내라고 요구한다면 프로젝트 문서에 분명한 근거가 있어야 합니다. ‘가스 절약’이나 ‘동기화’를 핑계로 낯선 주소를 내미는 메시지는 따르지 않습니다.
- 공식 문서에서 사용자용 주소를 확인합니다.
- 탐색기의 프록시·구현 계약 표시를 봅니다.
- Upgraded·AdminChanged 이벤트를 살펴봅니다.
- 관리자 소유자가 다중서명·타임락인지 확인합니다.
- 서명 화면의 받는 주소를 다시 대조합니다.
검증된 소스도 현재 구현 기준으로 읽습니다
프록시 바이트코드만 검증됐다고 해도 실제 업무 로직은 구현 계약 소스에 있습니다. 탐색기의 ‘as Proxy’ ABI가 현재 구현과 맞는지 확인하세요. 업그레이드 직후라면 소스 검증과 감사 범위에 새 버전이 들어가는지도 봐야 합니다. 예전 감사 보고서에 적힌 구현 계약 해시가 지금 주소와 다를 수 있습니다.
저장소 배치를 잘못 맞춘 업그레이드는 기존 잔액이나 권한을 망가뜨릴 수 있습니다. 일반 사용자가 코드를 전부 감사할 수는 없어도 관리자 변경 이력, 타임락, 다중서명, 업그레이드 공지, 일시정지 권한을 보면 통제 위험을 가늠할 수 있습니다. ‘검증됨’ 표시만으로 관리자에 대한 신뢰를 대신하지 마세요.
업그레이드는 주소가 같아도 동작을 바꿉니다
프록시 주소가 그대로라 주소록과 승인 한도는 유지돼도 구현 계약의 로직은 바뀔 수 있습니다. 어제 안전했던 함수의 조건, 수수료, 차단 목록, 전송 훅이 오늘은 달라질 수 있다는 뜻입니다. 중요한 거래 전에는 최근 Upgraded 이벤트와 공식 출시 공지를 확인하세요.
수상한 업그레이드가 보이면 새 서명을 멈추고 승인 한도를 점검하며, 공식 팀의 사고 공지를 확인합니다. 구현 계약 주소를 마음대로 직접 호출해 돌아가려 하지 마세요. 기록에는 프록시, 구현 계약, 확인한 블록, 관리자, 공식 문서 주소를 함께 남겨 나중에 다시 따라 할 수 있게 합니다.
자주 묻는 질문
토큰 잔액은 프록시와 구현 계약 중 어디에 있나요?
흔히 쓰는 delegatecall 프록시라면 사용자 상태는 프록시 저장소 맥락에 있습니다. 프로젝트 구조는 공식 문서로 확인하세요.
탐색기가 proxy라고 표시하지 않으면 일반 계약인가요?
꼭 그렇지는 않습니다. 표준 슬롯, 바이트코드, 배포 문서, 이벤트를 더 확인해야 합니다.
proxy 주소가 같으면 계약 행동도 계속 같은가요?
아닙니다. 구현 계약을 업그레이드하면 로직이 바뀔 수 있으니 최근 업그레이드 내역과 관리자 권한을 확인하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
