Road to Web3 (7) 서명 2종류: 메시지 서명 vs 트랜잭션 서명

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

 

이번 편의 목표는 단 하나입니다.

• 서명했다는 말이 무엇을 뜻하는지 분리해서 말할 수 있게 만들기

 

제가 처음 web3 서명을 접할 때 했던 오해는 이렇습니다.

• 지갑에서 sign 하면 곧바로 온체인 결제가 된다고 생각했다
• 메시지 서명과 트랜잭션 서명이 같은 행위라고 생각했다
• 서명은 인증이니까 결국 로그인 정도라고 생각했다

하지만 실제로는

• 메시지 서명은 보통 오프체인에서 검증되고
• 트랜잭션 서명은 네트워크에 브로드캐스트되어 블록에 포함될 때 상태를 바꿉니다

즉, 둘은 서명이라는 단어만 같고 결과가 완전히 다릅니다.

---

 

요약

구분	메시지 서명	트랜잭션 서명
목적	소유 증명, 로그인, 오프체인 계약	상태 변경, 전송, 컨트랙트 호출
결과물	서명 값(signature)	서명된 트랜잭션(signed tx)
실행 위치	오프체인 검증(서버 또는 앱)	온체인 실행(블록 포함 후)
비용	보통 0	가스비 필요
되돌림	서비스 정책에 따라	합의 규칙과 확정 정책에 따름
대표 표준	EIP-191, EIP-712	RLP 또는 타입드 tx, EIP-155, EIP-2718, EIP-1559

---

 

1) 메시지 서명은 무엇인가

메시지 서명은 말 그대로

• 어떤 바이트열 또는 구조화된 메시지
• 그 내용에 대한 승인 의사
• 그 승인을 한 주체가 키 소유자라는 증명

을 제공합니다.

하지만 이 서명은 네트워크로 자동 전파되지 않습니다.
효력을 만들려면 누군가가 검증해야 합니다.

대표 사용처

1) 로그인 또는 세션 발급

• 서버가 서명을 검증하고 세션을 발급한다

2) 오프체인 계약

• 서명된 주문서, 견적서, 약관 동의 같은 역할을 한다

3) 메타 트랜잭션 계열

• 사용자는 메시지에 서명하고
• 릴레이어가 그 서명을 온체인 트랜잭션으로 실행한다

보안 감각

메시지 서명은 공짜라서 UX가 좋지만, 피싱에도 약해집니다.

• 사용자가 뭘 서명했는지 이해하기 어렵다
• 악성 프론트엔드가 다른 내용을 서명시키기 쉽다

그래서 메시지 서명은 표준이 중요합니다.

• EIP-191: 사람 읽기용 메시지 서명에 접두어를 붙여 도메인 분리
• EIP-712: 구조화된 데이터 서명으로 내용을 더 명확하게 표시

참고
EOA 서명은 서버가 사용자의 public key를 미리 가질 필요 없이 서명 r s v 와 메시지 해시로 공개키를 복구해 주소를 계산하여 검증하며, 컨트랙트 지갑은 공개키 복구 대신 체인 규칙이나 isValidSignature 같은 방식으로 별도 검증이 필요할 수 있다.

 

 

오프체인 서명 계약의 함정: 전역 잔액을 잠글 수 없다

제가 처음 메시지 서명을 결제처럼 생각했을 때 제일 크게 헷갈렸던 지점이 있습니다.

서명은 승인 의사와 키 소유를 증명하지만, 그 자체로는 온체인 잔액을 전역적으로 예약하거나 잠그지 못합니다.

 

예를 들어 내가 10 USDC를 가지고 있고, A 서비스에 10 USDC를 소진하겠다는 오프체인 계약을 서명했다고 하겠습니다. A 서비스는 지갑을 통제하지 않으니, 서명을 검증하고 서비스 제공을 시작할 수 있습니다. 그런데 같은 사람이 B 서비스에도 10 USDC를 소진하겠다는 오프체인 계약을 또 서명하면 어떻게 될까요.

 

A와 B는 둘 다 서명 검증에 성공합니다.

둘 다 내가 해당 키를 가진 사용자라는 점도 맞습니다.

문제는 그 다음입니다. 실제 돈을 움직이는 전역 원장은 체인인데, 체인은 A와 B의 오프체인 계약을 조율해주지 않습니다. 결국 둘 중 하나는 돈을 받지 못하는 상황이 발생할 수 있습니다. 이건 전통적인 이중지불 문제의 변형이고, 오프체인 선제공 모델이 가진 본질적인 리스크입니다.

 

여기서 핵심 결론은 이겁니다.

 

• 메시지 서명은 결제 자체가 아니라 결제 의도 또는 승인 신호에 가깝다
• 온체인 잔액을 두 서비스 사이에서 동시에 예약해주는 기능은 없다
• 따라서 오프체인 계약만으로는 서비스 간 전역 정합성을 보장할 수 없다

 

해결책은 합의 경계를 어디에 둘지 선택하는 문제다

이 문제를 해결하려면 단 하나가 필요합니다.

중복 사용을 막아주는 단일 원장 또는 합의 경계입니다. 그걸 어디에 두느냐에 따라 모델이 갈립니다.

 

모델 1. 중앙화 원장 커스터디 거래소 방식

서비스가 사용자 자산을 맡아 내부 원장 DB에서 잔고를 차감합니다.

이 경우 서명은 승인 신호일 뿐이고, 실제 차감과 중복 방지는 DB 트랜잭션으로 해결합니다.

• 장점: 빠른 UX, 이중지불 방지 쉬움
• 단점: 서비스가 신뢰의 중심이 되고 보안과 운영 책임이 커진다

모델 2. 온체인에서 먼저 잠그기 approve escrow

서비스가 지갑을 소유하지 않아도, 온체인 메커니즘으로 먼저 자산을 묶을 수 있습니다.

• approve와 transferFrom으로 가져갈 권한을 확보하거나
• 에스크로 컨트랙트에 먼저 예치시키는 방식

 

이렇게 하면 A와 B가 동시에 집행을 시도해도, 체인은 잔액과 nonce 규칙으로 하나만 성공시키고 나머지는 실패합니다. 전역 원장이 체인이기 때문에 가능한 구조입니다.

모델 3. 오프체인 서명은 주문서, 집행은 온체인 메타 트랜잭션

사용자는 메시지로 결제 의도를 서명하고, 릴레이어나 서비스가 그 서명을 온체인 트랜잭션으로 집행합니다.

서명은 오프체인에서 빠르게 만들되, 최종 정산은 온체인에서 한 번만 성공하도록 강제하는 모델입니다.

결론: 서명만으로 서비스를 선제공하면 그건 신용 제공이다

오프체인 서명만 보고 서비스를 먼저 제공하는 순간, 그건 결제 시스템 비유로 승인만 믿고 상품을 먼저 내주는 신용 제공에 가깝습니다. 그래서 다음이 따라붙습니다.

• 선제공 범위를 제한할 것
• 회수 가능한 형태로 제공할 것
• 타임아웃과 만료를 둘 것
• 중복 요청을 막는 idempotency key를 쓸 것
• 최종 정산이 실패하면 어떤 보상 또는 롤백 정책을 적용할지 정할 것

 

정리하면 메시지 서명은 강력한 도구지만, 전역 잔액을 잠그는 장치가 아닙니다. 서로 다른 서비스가 동시에 같은 잔액을 기대하게 만들지 않으려면, 중앙화 원장으로 책임을 가져가거나, 온체인 잠금과 온체인 정산으로 합의 경계를 다시 체인 쪽으로 돌려야 합니다.

 

---

 

2) 트랜잭션 서명은 무엇인가

트랜잭션 서명은

• 체인의 상태를 바꾸는 요청을 만들고
• 그 요청을 개인키로 승인한 뒤
• 네트워크에 전파할 수 있는 형태로 직렬화

한 결과입니다.

여기서 중요한 점은 두 단계입니다.

• 서명했다는 사실
• 그리고 실제로 브로드캐스트되어 포함되었다는 사실

서명만으로는 아무 일도 일어나지 않습니다.
브로드캐스트와 포함이 있어야 상태가 바뀝니다.

트랜잭션이 담는 것들

EVM 계열에서 트랜잭션은 대략 이런 정보를 포함합니다.

• from 는 서명으로부터 복구된다
• to, value, data 는 상태 변경 대상과 내용
• nonce 는 계정 단위 순서와 중복 제어
• gasLimit 은 실행 자원 상한
• fee 관련 필드는 네트워크 수수료 정책과 연결
• chainId 는 다른 체인 재사용을 막는다

---

 

3) 무엇이 더 안전한가

정답은 없고, 위험이 다릅니다.

위험	메시지 서명	트랜잭션 서명
사용자가 의미를 모르고 승인	높음	중간
비용	없음	실패해도 비용 발생 가능
되돌림	서비스 정책에 좌우	체인 정책과 확정 정책에 좌우
피싱	높음	중간
자동화	서버가 쉽게 검증	인프라 필요(RPC, 트래킹)

실무에서는 보통 이렇게 설계합니다.

• 저위험 행위: 메시지 서명으로 소유 증명만
• 금전적 가치 이동: 트랜잭션 서명 + 확정 정책
• 중간 단계: 메시지 서명 + 릴레이어가 온체인 실행

---

 

5) 체크리스트 8개

1) 메시지 서명에는 반드시 도메인 분리(EIP-191 또는 EIP-712)를 사용한다
2) 메시지 서명만으로 온체인 결제라고 말하지 않는다
3) 트랜잭션 서명은 브로드캐스트와 포함까지 추적한다
4) 확정 정책을 included, confirmed, finalized 로 단계화한다
5) 오프체인 선제공을 한다면 회수 가능 설계를 우선한다
6) 서버는 idempotency key 로 중복 제공을 막는다
7) 릴레이어를 쓰면 수수료 대납과 abuse 방어를 같이 설계한다
8) 서명 UI 는 사용자가 이해 가능한 수준으로 강제한다(EIP-712가 유리)

---

 

결론

• 메시지 서명은 오프체인에서 효력이 생기고, 비용이 없지만 피싱 리스크가 높다
• 트랜잭션 서명은 온체인 상태 변경 요청이고, 브로드캐스트와 포함이 있어야 효력이 생긴다
• x402 같은 프로토콜에서는 결제 증거가 메시지 서명인지 트랜잭션인지가 제품 모델을 결정한다