이더리움 계정 모델: EOA와 계약 계정은 무엇이 다른가

이더리움의 EOA는 개인키 서명으로 거래를 시작하는 계정이고, 계약 계정은 주소에 연결된 코드가 호출될 때 실행되는 계정입니다. 둘 다 ETH와 토큰을 보유할 수 있지만 권한의 출발점, 생성 비용, 실행 조건이 다르므로 주소 모양만으로는 유형을 확정하기 어렵습니다.

같은 0x 주소가 같은 계정을 뜻하지 않는다

이더리움 상태에서 계정은 잔액과 nonce 같은 값을 가진 항목이다. EOA와 계약 계정 모두 20바이트 주소를 쓰고 ETH와 토큰을 받을 수 있어 겉모양만으로 구분되지 않는다. 차이는 권한의 근원이다. EOA는 개인키로 만든 서명이 유효해야 하고, 계약 계정은 그 주소에 저장된 EVM 코드가 호출 규칙을 결정한다.

Ethereum accounts는 두 유형 모두 자산을 보유하고 계약과 상호작용할 수 있다고 설명한다. 따라서 ‘토큰을 보유했으니 지갑 주소’ 또는 ‘거래가 많으니 개인 계정’이라는 추론은 성립하지 않는다. 탐색기의 Code 탭과 실제 호출 추적을 함께 봐야 한다.

거래의 첫 발신자는 왜 EOA인가

프로토콜의 일반 거래에는 from, to, nonce, value, input data, signature가 들어간다. Ethereum transactions가 설명하듯 네트워크에 제출되는 거래의 서명 주체는 EOA다. 계약은 스스로 개인키로 서명해 메모리풀에 거래를 내지 않고, 이미 시작된 실행 중 CALL 같은 명령으로 다른 계약을 부른다.

이 구분은 ‘계약이 토큰을 보냈다’는 탐색기 표시를 읽을 때 중요하다. 사용자가 EOA에서 거래를 시작했더라도 최종 Token Transfer 이벤트의 발신자는 계약일 수 있다. 바깥 거래의 from과 내부 호출의 caller, 이벤트의 from을 서로 다른 층으로 읽어야 한다.

nonce와 codeHash가 말해 주는 것

EOA의 nonce는 보낸 거래의 순서를 관리해 같은 서명이 다시 쓰이는 것을 막는다. 계약 계정의 nonce는 계약 생성과 연관될 수 있다. codeHash는 현재 계정에 연결된 코드를 가리키지만 프록시 구조라면 실제 동작은 다른 구현 주소의 코드에 위임될 수 있다.

코드가 없다고 영원히 EOA였다는 뜻도 아니다. 계약은 SELFDESTRUCT 의미 변화나 네트워크 규칙, 생성 전 미리 계산된 CREATE2 주소 같은 예외를 고려해야 한다. 특정 블록 시점의 상태를 조회하는 아카이브 RPC와 현재 상태 조회 결과가 다를 수 있으므로 조사 기준 블록을 기록한다.

• 탐색기에서 주소의 Contract/Code 표시 확인
• 외부 거래와 내부 호출 트레이스를 분리
• 프록시라면 구현 주소와 관리자 슬롯 확인
• 판단 기준 블록 번호와 체인을 기록

지갑 앱과 계정은 같은 말이 아니다

지갑은 계정과 상호작용하는 인터페이스다. 하나의 앱이 여러 EOA를 파생할 수도 있고, 스마트 계정 계약을 제어할 수도 있다. 그래서 ‘지갑을 바꾼다’가 반드시 온체인 주소나 권한 주체를 바꾼다는 뜻은 아니다.

복구 가능성을 평가할 때는 앱 이름보다 서명 권한과 복구 규칙을 본다. EOA라면 개인키·시드 관리가 핵심이고, 계약 계정이라면 소유자 목록, 임계값, 복구 모듈, 업그레이드 권한이 추가된다. 인터페이스가 사라져도 다른 도구로 같은 계정을 제어할 수 있는지 확인해야 한다.

탐색기에서 유형을 직접 확인하는 순서

먼저 올바른 체인과 주소인지 확인한 뒤 현재 bytecode 존재 여부를 본다. 코드가 있으면 verified source, proxy 표시, 구현 주소, 생성 거래를 차례로 확인한다. 거래 하나를 골라 최상위 발신자와 내부 호출, 로그를 펼쳐 보면 누가 서명했고 어느 코드가 자산 이동을 실행했는지 분리된다.

코드 검증 배지가 없다는 사실은 곧 악성이라는 뜻이 아니지만 사람이 읽을 수 있는 소스와 배포 바이트코드의 대응을 확인하기 어렵다는 뜻이다. 반대로 검증 배지는 코드의 안전성 보증이 아니다. 권한 함수와 실제 상태까지 별도로 읽는다.

주소 형식은 같아도 권한의 출발점은 다르다.

JOBCOIN 해설

계정 추상화 시대에도 남는 기본 구분

스마트 계정과 EIP-7702 같은 방식은 사용 경험을 바꾸지만, 어떤 코드가 어떤 서명을 검증하고 누가 거래를 포장해 제출하는지 따져야 한다는 원칙은 같다. ‘가스 대납’이나 ‘일괄 실행’은 권한이 사라졌다는 뜻이 아니라 검증 로직과 비용 지불자가 분리됐다는 뜻이다.

독자는 기능 이름보다 실패 경계를 확인해야 한다. 번들러가 멈췄을 때 대체 경로가 있는지, 복구자가 자산을 옮길 수 있는지, 코드 업그레이드가 가능한지 살피면 단순 EOA/계약 이분법을 넘어 실제 통제 구조를 이해할 수 있다.

특히 서명 화면에서는 최종 호출 대상과 value, calldata를 확인한다. 스마트 계정이 여러 호출을 한 번에 묶으면 지갑 화면의 대표 동작 한 줄만으로는 전체 효과를 알기 어렵다. 시뮬레이션 결과와 실행할 계약 목록을 대조하고, 모듈 설치나 소유자 변경처럼 장기 권한을 바꾸는 동작은 단순 토큰 전송과 구분한다.

자주 묻는 질문