지갑과 키 관리, 실무에서 절대 놓치면 안 되는 것들: 지갑·니모닉·프라이빗키·단위(wei/gwei/ETH)까지

처음 블록체인을 배우면 지갑은 단순한 “로그인 도구”처럼 보이기 쉽습니다.
하지만 실무로 들어가면 지갑은 로그인보다 훨씬 더 큽니다. 권한, 자산 이동, 책임이 모두 지갑을 중심으로 돌아가기 때문입니다.

초반에는 “니모닉만 잘 백업하면 되지 않을까”라고 생각하기도 합니다.
그러나 운영/배포를 하다 보면 문제는 대체로 다음 두 지점에서 발생합니다.

• 키를 어디에 두는지(노출/유실/권한 분리)
• 서명을 누가 하는지(사용자 vs 서버 vs 멀티시그/정책)

이 글은 지갑과 키 관리를 ‘정의’가 아니라 사고가 나는 지점 중심으로 정리합니다.
끝까지 읽으면 지갑/키/니모닉/주소의 관계가 한 줄로 연결되고, 운영 체크리스트도 손에 잡히는 형태로 정리됩니다.

---

0) 큰 그림: 지갑은 ‘자산을 담는 통’이 아니라 ‘키 관리 + 서명 도구’입니다

블록체인에서 자산은 지갑에 “들어가” 있는 것이 아닙니다.
자산은 체인의 상태(장부)에 있고, 지갑은 그 자산을 움직일 수 있는 서명 권한(키)을 관리합니다.

• 지갑(wallet): 키를 보관하고 서명을 만들어주는 도구(앱/기기/소프트웨어)입니다.
• 주소(address): 공개키에서 파생된 식별자이며, 보통 “받는 곳”으로 사용됩니다.
• 프라이빗키(private key): 서명 권한 그 자체이며, 유출되면 자산을 지키기 어렵습니다.
• 서명(signature): “내가 이 트랜잭션을 승인했다”는 암호학적 증명입니다.

한 문장으로 정리하면 다음과 같습니다.

지갑은 자산 저장소가 아니라, 서명 권한을 안전하게 관리하는 장치입니다.

---

1) 주소, 공개키, 프라이빗키: 구분이 어렵지만 실무에서는 필수입니다

• 프라이빗키: 절대 유출되면 안 되는 비밀 값입니다.
• 공개키: 프라이빗키로부터 생성되며 공개 가능합니다.
• 주소: 공개키(또는 그 해시)에서 파생되며, 사람들에게 공유하는 “입금 주소”입니다.

실무에서는 “공개키 = 주소”로 단순화하면 사고가 날 수 있습니다.
특히 체인/지갑 방식에 따라 주소 생성/표현(체크섬, 접두사 등)이 달라지기 때문입니다.

자주 발생하는 실수

• 주소를 복사하는 과정에서 앞/뒤 글자가 잘려 전송하는 경우가 있습니다.
• 네트워크를 착각하여 비슷한 형태의 주소로 다른 체인에 전송하는 경우가 있습니다.

---

2) 니모닉(BIP39)은 ‘마법의 문장’이 아니라 ‘키 복구를 위한 시드 표현’입니다

니모닉은 흔히 12/24개의 단어로 보입니다.
그러나 핵심은 단어 자체가 아니라, 단어가 만들어내는 시드(seed)입니다.

• 니모닉: 사람이 백업하기 쉬운 형태입니다.
• 시드: 실제로 키를 재생성하는 근본 값입니다.
• 파생 경로(derivation path): 같은 니모닉이라도 어떤 경로로 키를 뽑느냐에 따라 주소가 달라집니다.

실무에서 자주 터지는 포인트

• 니모닉은 있는데 파생 경로가 달라 원래 주소가 복구되지 않는 경우가 있습니다.
• 다른 지갑 앱으로 옮길 때 파생 규칙이 달라 “자산이 사라진 것처럼 보이는” 경우가 있습니다.

---

3) 지갑 종류를 실무 기준으로 나누면 보안과 UX가 함께 보입니다

1) 핫월렛(Hot Wallet)

• 인터넷 연결 환경에서 사용하는 지갑입니다.
• UX는 좋지만 공격면(피싱/악성코드/세션 탈취)이 커질 수 있습니다.

2) 콜드월렛(Cold Wallet)

• 키가 인터넷과 분리된 환경(하드웨어 지갑, 에어갭 등)입니다.
• 보안은 강하지만 사용성이 불편할 수 있습니다.

3) 수탁형(Custodial) vs 비수탁형(Non-custodial)

• 수탁형: 서비스가 키를 보관합니다(편하지만 신뢰/운영 리스크가 생깁니다).
• 비수탁형: 사용자가 키를 보관합니다(책임이 커지며 복구/지원이 어려워질 수 있습니다).

제품을 만들 때는 “무조건 비수탁”처럼 결론부터 정하기보다,
사용자 경험(복구/지원)과 보안 책임의 균형을 먼저 정의하는 것이 좋습니다.

---

4) 서명(Signature)에도 두 종류가 있습니다: 트랜잭션 서명 vs 메시지 서명

지갑의 핵심은 서명입니다. 실무에서는 특히 다음 둘을 자주 혼동합니다.

1) 트랜잭션 서명

• 온체인 상태를 바꾸는 승인입니다(가스/수수료가 발생할 수 있습니다).
• 전송, 승인(approve), 컨트랙트 호출 등이 포함됩니다.

2) 메시지 서명(예: Sign-In with Ethereum)

• 온체인 상태 변경 없이 “내가 나임”을 증명합니다.
• 로그인, 권한 확인, 오프체인 동의 등에 사용됩니다.

자주 발생하는 실수

• 로그인 메시지 서명을 받아 놓고 결제 승인처럼 오해하게 만드는 UX가 발생할 수 있습니다.
• 반대로 트랜잭션 서명을 너무 쉽게 유도하여 사용자가 모르게 자산 이동을 승인하는 문제도 생길 수 있습니다.

---

5) 키 보관: “서버에 두면 편하다”는 말이 가장 위험할 수 있습니다

개발을 하다 보면 “서버가 프라이빗키를 들고 있으면 자동화가 쉽다”는 생각이 들 수 있습니다.
실제로 편해집니다. 그러나 사고가 나면 회복이 어렵습니다.

서버가 키를 들고 있을 때 생길 수 있는 문제

• 서버 침해가 곧바로 자산 유출로 이어질 수 있습니다.
• 운영 인력이 늘어날수록 접근 통제가 어려워질 수 있습니다.
• 실수로 로그/에러 리포트에 키가 섞여 나가는 사고가 발생할 수 있습니다.

실무 대안(선택지)

• KMS/HSM(관리형/하드웨어 기반 키 보관)을 고려할 수 있습니다.
• 키를 여러 조각으로 나누는 방식(임계값 서명 등)을 적용할 수 있습니다.
• 멀티시그(다중 승인)로 권한을 분산할 수 있습니다.
• 핫키는 최소 권한, 콜드키는 최종 권한으로 역할을 분리하는 방식을 권장합니다.

---

6) 멀티시그와 정책은 ‘사람 실수’를 막는 장치입니다

보안은 해킹만 막는 것이 아닙니다. 실무에서는 “실수”로도 큰 사고가 납니다.

• 잘못된 주소로 송금하는 경우가 있습니다.
• 단위를 착각(wei/gwei/ETH)하는 경우가 있습니다.
• 승인 권한을 과도하게 부여하는 경우가 있습니다.
• 테스트넷을 메인넷으로 착각하는 경우가 있습니다.

멀티시그/정책은 이런 실수를 완화합니다. 예를 들어 다음과 같습니다.

• 일정 금액 이상은 2명 이상 승인하도록 설정합니다.
• 승인자 역할을 분리합니다(개발/운영/재무 등).
• 출금 한도/화이트리스트 정책을 적용합니다.

---

7) 단위(wei/gwei/ETH): 실무자도 자주 넘어지는 구간입니다

이더리움 단위는 다음처럼 정리할 수 있습니다.

• 1 ETH = 10^18 wei
• 1 gwei = 10^9 wei

문제는 “사람이 읽는 숫자”와 “컨트랙트/노드가 받는 숫자”가 다르다는 점입니다.

자주 발생하는 실수

• 1 ETH를 보내려다 1 wei를 보내는 경우가 있습니다(거의 0원).
• 1 gwei를 1 ETH로 착각하여 매우 큰 값을 넣는 경우가 있습니다.
• 토큰도 decimals가 있어 “1 토큰”이 내부적으로 1 * 10^decimals로 표현됩니다.

실무 팁으로는, 입력 단계에서 단위를 강제로 표기하고, 전송 전에 요약 화면에서 최종 금액을 다시 보여주는 것이 좋습니다.

---

8) 운영 체크리스트(현실 버전)

아래 항목은 사고를 줄이기 위해 최소로 지키는 체크리스트입니다.

• 프라이빗키/니모닉을 로그에 남기지 않습니다.
• 운영 키는 역할을 분리합니다(핫키/콜드키/권한 키).
• 큰 금액은 멀티시그 또는 2단계 승인으로 묶습니다.
• 네트워크(체인ID)와 주소를 전송 전에 재확인합니다.
• 단위(wei/gwei/ETH, 토큰 decimals)를 UI에서 강제로 명시합니다.
• RPC 장애에 대비해 대체 엔드포인트/재시도 정책을 준비합니다.
• 피싱 방어를 위해 도메인/서명 메시지/권한 범위를 명확히 보여줍니다.

---

마무리

지갑과 키 관리는 암호학 지식만으로 해결되지 않습니다. 결국 습관과 정책의 문제입니다.
한 번 새어나간 키는 되돌리기 어렵고, 한 번 잘못 승인된 서명은 취소가 쉽지 않습니다.

따라서 가장 좋은 설계는, 복잡한 기술을 늘리는 것이 아니라
실수를 했을 때도 크게 무너지지 않는 구조(권한 분리, 승인 정책, 최소 권한)를 만드는 것입니다.

---

FAQ

Q1. 니모닉만 있으면 무조건 복구할 수 있습니까?

대부분 가능하지만, 같은 니모닉이라도 파생 경로가 다르면 주소가 달라질 수 있습니다. 지갑 이동/복구 시 이 부분이 핵심 포인트입니다.

Q2. 서버가 키를 들고 있으면 무조건 나쁩니까?

서비스 성격에 따라 수탁형이 필요한 경우도 있습니다. 다만 그 순간부터는 보안 운영(KMS/HSM, 접근 통제, 승인 정책, 감사 로그 등)이 제품의 핵심 역량이 됩니다.

Q3. 메시지 서명은 안전합니까?

온체인 상태를 바꾸지는 않지만, 사용자가 무엇에 동의하는지 명확히 보여주지 않으면 피싱에 취약할 수 있습니다. 서명 메시지 설계가 중요합니다.