암호화폐 결제를 위한 키 관리 및 운영 보안

2025-2026년의 주요 보안 사고들은 궁극적으로 대부분 키 또는 서명 문제로 귀결됩니다 — 손상된 서명 도구, 유출된 관리자 키, 또는 피싱 당한 운영자가 그 원인입니다. (해당 사례들은 최근 암호화폐 결제 해킹 분석에서 별도로 다루고 있습니다.) 공통적인 문제는 키가 어떻게 인가되고, 저장되며, 서명에 사용되는지에 있습니다.

문제는 멀티시그, MPC, 핫/콜드 지갑, HSM이 동일한 수준의 선택지인 것처럼 논의된다는 점이며, 이를 혼동하면 선택이 복잡해집니다. 이것들은 실제로 세 가지 독립적인 차원이며, 실제 키 관리 설정은 세 가지를 모두 조합한 것입니다. 이 글에서는 각 차원을 살펴본 후, 이를 하나로 묶는 하이브리드 아키텍처, 서명 인프라 및 운영 표준, 그리고 그 주변의 더 넓은 운영 영역 — API 및 인프라 격리, 인력과 벤더, 도메인과 신원, 그리고 가장 새롭고 가장 덜 이해된 위험인 자금 접근 권한을 가진 AI 에이전트 — 을 다룹니다.

개인 키, 시드 구문, 그리고 "내 기기에 있다"가 보안이 아닌 이유

이 모든 것의 핵심은 개인 키입니다: 암호화된 난수 문자열입니다. 이를 보유한 사람은 트랜잭션에 서명하고 해당 주소의 자금을 이동할 수 있습니다. 이는 주소 자금에 대한 궁극적인 통제권이자 — 궁극적인 단일 위험 지점입니다.

시드 구문(보통 12개 또는 24개의 단어, BIP-39 표준)은 해당 개인 키를 사람이 읽을 수 있는 형태로 인코딩한 것입니다. "계층적 결정론적"(HD) 규칙은 하나의 시드 구문에서 수천 개의 개인 키와 주소를 파생합니다. 따라서 시드 구문은 단일 개인 키만큼이나 민감하며, 어떤 면에서는 더욱 그렇습니다: 개인 키 하나가 유출되면 주소 하나를 잃지만, 시드 구문이 유출되면 전체 지갑을 잃게 됩니다.

직접 짚어볼 만한 흔한 오해가 있습니다: 일부는 서명 기기와 지갑이 자신의 손에 있고 키가 오프라인 상태라면 아무 문제도 없다고 가정합니다. 문제는 일반 소프트웨어 및 하드웨어 지갑의 개인 키와 시드 구문은 내보낼 수 있다는 것입니다. 기기나 백업에 내부 접근 권한이 있는 사람은 개인 키를 내보내고 복사한 다음, 그 "자신의" 기기를 건드리지 않고 어디서든 자금을 제어할 수 있습니다.

따라서 "키가 내 기기에 있다"는 것이 "다른 누구도 가져갈 수 없다"와 동일하지 않습니다. 실제로 중요한 것은 개인 키를 내보낼 수 있는지 여부입니다. 아래에서 살펴보겠지만, HSM만이 하드웨어 수준에서 내보내기를 차단하는 유일한 옵션입니다.

하나의 스펙트럼이 아닌 세 가지 독립적인 차원

설정을 선택하기 전에, 실제로 답해야 할 세 가지 질문을 분리하는 것이 도움이 됩니다.

인가 모델: 싱글시그, 멀티시그, 또는 MPC/TSS

싱글시그는 하나의 개인 키가 모든 것을 제어하는 방식으로 — 가장 단순한 설정이자, 가장 큰 단일 장애 지점입니다.

멀티시그는 N개의 독립적인 개인 키 중 M개가 함께 서명해야 하며(예: 5개 중 3개), 각 서명자는 완전하고 독립적인 개인 키를 보유합니다. 스마트 컨트랙트를 지원하는 체인에서, 컨트랙트 멀티시그(Safe가 사실상 표준)는 이 로직을 컨트랙트로 구현하여 서명과 임계값 규칙을 온체인에서 공개적으로 검증할 수 있습니다 — 트랜잭션당 높은 가스 비용과, 서명자를 변경할 때마다 컨트랙트 구성을 수정해야 하는 비용이 따릅니다. 여기에는 쉽게 간과되는 약점도 있습니다: 컨트랙트 멀티시그를 위한 서명 인프라는 아직 미성숙합니다. Safe의 execTransaction 호출은 하드웨어 지갑에서 긴 calldata 문자열로 표시되는 경우가 많아, 서명자들이 실제로 무엇을 승인하는지 파악하기 어렵고, 명확한 서명과 트랜잭션 파싱에 대한 에코시스템 지원은 아직 제한적입니다. 이것이 바로 바이비트 사건에서 악용된 공격 표면이며, 컨트랙트 멀티시그를 채택하는 기업들이 종종 격차를 메우기 위해 제3자 트랜잭션 파싱 및 교차 검증을 도입해야 하는 이유입니다. 반면 비트코인과 같은 체인은 컨트랙트 의존성 없이 스크립트 레이어에서 기본적으로 멀티시그를 지원합니다.

**MPC(임계값 서명, TSS)**는 "완전한 개인 키 하나를 조각으로 자르는 것"이 아닙니다. 실제 MPC는 분산 키 생성(DKG)을 사용합니다: 키는 생성되는 순간부터 분산되어 있으며, 각 당사자는 독립적인 키 조각을 보유하고, 완전한 개인 키는 어떠한 시점에도 존재하지 않습니다. 각 당사자는 자신의 조각에서 부분 서명을 계산하고, 이 부분 서명들은 암호화 프로토콜에 의해 하나의 표준 서명으로 결합됩니다 — 바이트 문자열의 연결이 아닌 계산이므로 — 결과는 온체인에서 일반 단일 서명과 구별할 수 없습니다. 가스 비용은 정상이고, 크로스체인 호환성이 좋으며, 서명자나 임계값을 변경할 때 컨트랙트를 건드릴 필요가 없습니다.

MPC/TSS와 더 오래되어 혼동하기 쉬운 방법인 **샤미르 비밀 공유(SSS)**를 구분하는 것이 중요합니다. SSS는 이미 존재하는 완전한 개인 키를 n개의 조각으로 자릅니다; 서명을 위해서는 충분한 조각들을 모아 서명 전에 메모리에서 완전한 개인 키를 재구성합니다 — 그 재구성 순간이 단일 장애 지점입니다. TSS는 절대 재구성하지 않습니다; 완전한 개인 키는 결코 나타나지 않습니다. 이것이 SSS보다 더 안전한 이유입니다.

멀티시그와 MPC 모두 단일 지점 위험을 제거하지만, 서로 다른 메커니즘을 통해서입니다. 멀티시그는 다수의 완전한 키와 온체인 검증으로: 투명하지만 비용이 높고 서명자 교체가 번거롭습니다. MPC는 다수의 키 조각과 부분 서명의 오프체인 결합으로: 유연하고 저렴하지만, 조율은 인프라에 의존합니다.

하드웨어 보호: 소프트웨어, 하드웨어 지갑, TEE, 또는 HSM

소프트웨어 저장은 서버나 소프트웨어에 개인 키를 보관하는 방식으로 — 가장 편리하지만 가장 취약한 옵션입니다. 하드웨어 지갑(Ledger, Trezor 등)은 보안 칩에 키를 보관하고, 기기 내부에서 서명하며, 키가 절대 외부로 나가지 않습니다.

TEE(신뢰할 수 있는 실행 환경) — Intel SGX, AWS Nitro, 또는 Apple Secure Enclave를 생각해보십시오 — 는 범용 CPU에서 격리된 암호화 메모리 영역을 분리하여, OS 루트 권한을 가진 공격자로부터도 키와 서명 계산을 보호합니다. 소프트웨어와 HSM 사이에 위치합니다: 강력한 논리적 격리, 좋은 성능, MPC 프로토콜을 포함한 임의의 코드를 실행할 수 있지만, 물리적 변조 방지 및 컴플라이언스 인증은 HSM에 미치지 못합니다. 이것이 MPC 키 조각을 저장하는 가장 일반적인 방법이기도 합니다 — 엔클레이브 내부에서 DKG에 의해 생성되어 절대 외부로 나가지 않습니다. 예를 들어, Fireblocks는 MPC 키 조각을 여러 클라우드의 SGX 엔클레이브에 분산합니다.

**HSM(하드웨어 보안 모듈)**은 FIPS 140-2/3 같은 인증을 충족하는 엔터프라이즈급 변조 방지 하드웨어로, 물리적 변조 방지 기능과 침입 시 자동 삭제 기능을 갖추고 있습니다. 가장 강력한 보장: 개인 키는 하드웨어 내부에서 생성되어 내보내기 불가로 표시되며, 물리적으로 외부로 나갈 수 없습니다. 이것이 소프트웨어 및 하드웨어 지갑과 근본적으로 구별되는 점이며, HSM이 고가치 완전 개인 키 보관에 적합한 이유입니다.

이 차원은 위의 인가 모델과 직교합니다: 멀티시그의 각 완전한 키는 하드웨어 지갑이나 HSM에 보관될 수 있으며, 각 MPC 조각은 보통 TEE 엔클레이브에 보관됩니다.

자금 온도: 핫, 웜, 또는 콜드

이 차원은 키가 어떻게 저장되는지에 관계없이 — 개인 키가 인터넷에 얼마나 노출되어 있는지, 즉 자금이 얼마나 빠르고 자동으로 이동될 수 있는지만을 다룹니다.

핫 지갑은 항상 온라인 상태로 즉시 결제와 자동 지급에 사용됩니다 — 가장 빠르고 위험이 가장 높으며, 보통 전체 자금의 한 자릿수 퍼센트만 보유합니다. 웜 지갑은 온라인 상태이지만 개인 키가 보호된 환경(전용 서명 서비스 또는 HSM)에 격리되어 있어, 서명 과정에 사람이 개입해야 합니다; 일상적인 운영 결제를 처리합니다. 콜드 지갑은 완전히 오프라인이고 에어갭 상태로, 대규모 준비금의 장기 보관에 사용됩니다 — 가장 높은 보안, 가장 느린 사용, 보통 대부분의 자금을 보유합니다.

분명히 말씀드리자면, 온도는 근본적으로 개인 키의 온라인 노출과 자금이 얼마나 쉽게 이동하는지에 관한 것입니다; 이체 빈도와 자금 비율은 그 결과이지 정의가 아닙니다. 이 차원도 앞의 두 가지와 직교합니다: 콜드 지갑은 멀티시그와 HSM을 사용할 수 있고, 핫 지갑은 MPC를 사용할 수 있습니다.

세 가지를 합치면 전체 그림이 나옵니다: 인가 모델, 하드웨어 보호, 자금 온도는 독립적이며, 실제 키 관리 설정은 세 가지 모두를 결합합니다.

일반적인 키 관리 설정

업계에서 세 가지 차원을 일반적으로 조합하는 방법은 다음과 같습니다:

선택의 요점은 자금 온도에 따라 계층을 나누고 각 계층에서 최선의 조합을 사용하는 것입니다. 핫 지갑은 속도가 필요하므로 MPC를 선호합니다. 콜드 지갑은 안정성과 감사 가능성이 필요하므로 멀티시그와 HSM을 선호합니다. 거버넌스와 컨트랙트 권한은 투명성과 책임성이 필요하므로 컨트랙트 멀티시그와 타임락을 선호합니다.

BlockSec의 권장 하이브리드 아키텍처

BlockSec은 온도에 따라 계층화된 하이브리드 아키텍처를 권장합니다.

핫/웜 지갑: MPC 서명. 개인 키의 단일 장애 지점을 제거하고, 서명 지연을 낮게 유지하며, 고빈도 결제에 적합합니다. 조각은 서로 다른 물리적 위치와 보안 도메인에 분산되어야 합니다.

콜드 지갑: 다자 제어와 온체인 감사 가능성, 대규모 준비금에 적합합니다. 어떤 구현을 사용할지는 팀의 온체인 운영 역량에 따라 다릅니다 — 두 가지 경로가 있습니다:

• 최대 투명성을 원하는 성숙한 온체인 운영 팀의 경우: 컨트랙트 멀티시그(예: Safe의 3-of-5)를 사용하여 임계값 규칙과 모든 서명을 온체인에서 공개적으로 검증할 수 있습니다. 비트코인에서는 스크립트 레이어 기본 멀티시그를 사용하며, 각 서명자는 HSM이나 하드웨어 지갑으로 자신의 키를 보호합니다. 컨트랙트 멀티시그를 위한 서명 파싱 도구가 아직 미성숙하므로 팀이 교차 검증을 직접 추가해야 합니다 — 이 부분의 운영이 가볍지 않습니다.
• 온체인 실행에 덜 익숙하고 운영 복잡성을 줄이고 싶은 팀의 경우: TEE에 조각을 보관하는 MPC 임계값 서명을 사용하고, 독립적인 제3자를 공동 서명자로 도입하여 각 서명 전에 트랜잭션 안전성 검사를 실행합니다. 이렇게 하면 컨트랙트 멀티시그 도구 격차를 피하고 독립적인 제3자 검증을 서명 임계값에 직접 구축할 수 있습니다.

컨트랙트 업그레이드 및 정책 변경: 멀티시그와 타임락. 권한 변경 작업은 다자 승인과 시간 지연이 필요합니다.

어떤 경로를 선택하든 몇 가지 매개변수가 중요합니다. 최소 3명의 서명자를 사용하고, 임계값은 최소 50% 이상이지만 전체 수보다 낮게 설정하십시오 — N-of-N을 피하십시오, 한 명의 서명자가 연락 불가능해지면 서명이 차단되고 자금이 잠길 수 있으며, 모든 서명자가 없어서는 안 될 존재가 되면 각각이 강압이나 납치의 핵심 표적이 됩니다. 전체보다 낮은 임계값은 여유를 남기고 특정 서명자를 표적으로 삼는 가치를 낮춥니다. 각 서명자는 각 멀티시그에서 새로운 전용 주소를 사용해야 하며, 다른 멀티시그나 개인 지갑과 공유하지 않아야 합니다. 서명자들은 지리적, 조직적 역할, 법인 측면에서 다양해야 하며 — 지갑의 위험 수준이 높아질수록 분산도가 높아져야 합니다.

위험 수준은 공식적인 등급 평가에서 나와야 합니다: 각 지갑을 비즈니스에 미치는 재정적 영향, 프로토콜 의존성, 평판 위험으로 평가하고, 각 등급을 서로 다른 임계값, 승인 흐름, 모니터링 밀도에 매핑하십시오. 6개월마다, 그리고 대규모 TVL 변경, 컨트랙트 업그레이드, 또는 보안 사고 직후에 등급을 검토하십시오.

블라인드 서명과 서명 환경 격리

블라인드 서명은 서명 도구가 트랜잭션이 실제로 무엇을 하는지가 아닌 calldata 해시를 보여주는 것을 의미합니다. 이는 가상의 위험이 아닙니다: 서명 시 서명자는 인터페이스에서 트랜잭션의 실제 의미를 이해할 수 없으며, 그 격차는 바이비트 사건의 직접적인 원인 중 하나였습니다. 서명에 사용된 프론트엔드 또는 백엔드가 침해되어 서명자들이 컨트랙트 자체의 버그 없이 악의적인 트랜잭션을 승인했습니다.

위의 세 가지 차원을 강화하는 것은 그 주변의 서명 프로세스가 똑같이 강화된 경우에만 유효합니다. 설정에 관계없이 적용되는 몇 가지 표준이 있습니다:

• 필수 서명 하드웨어. 모든 프로덕션 멀티시그 작업은 전체 트랜잭션 요약을 표시할 수 있을 만큼 충분히 큰 화면과 명확한 서명 지원, PIN 보호, 펌웨어 무결성 검증, 제조업체 또는 공인 리셀러로 제한된 공급망을 갖춘 하드웨어 지갑을 사용해야 합니다 — 수령 시 정품 여부를 확인하십시오.
• 물리적으로 격리된 서명 환경. 서명은 일상적인 사무실 네트워크를 공유하지 않는 에어갭 기기에서 실행되어야 합니다; 고가치 작업에는 전용 서명 기기가 필요합니다. 서명 서비스를 비즈니스 로직 및 프론트엔드와 물리적으로 격리된 독립적인 보안 도메인에 배포하십시오. 서명 노드는 공용 인터넷에 직접 노출되어서는 안 됩니다 — VPN이나 전용 회선을 통해서만 연결하십시오. 서명 작업 로그는 비즈니스 시스템이 수정할 수 없도록 별도로 저장되어야 합니다.
• 독립적인 트랜잭션 검증. 서명 전에 독립적인 채널 — 전용 터미널, 하드웨어 기기, 또는 제3자 트랜잭션 시뮬레이션/위험 서비스 — 을 통해 트랜잭션 내용을 검증하십시오. 이 검사는 자체 프론트엔드나 백엔드가 아닌 독립적인 제3자가 수행하는 것이 가장 좋습니다 — 내부 시스템만 신뢰하는 것 자체가 단일 장애 지점입니다. 바이비트의 경우처럼 내부 프론트엔드나 백엔드가 침해되면, 서명자가 화면에서 보는 것은 변조된 가짜 정보이며, 자신을 상대로 스스로 검증하는 것은 아무런 검증이 아닙니다. 지급 경로는 특히 이 독립적인 방어선이 필요합니다.
• 명확한 서명과 교차 검증. 트랜잭션 의미를 파싱하는 도구를 사용하여 서명자가 calldata 문자열 대신 "0x1234...로 1,000 USDC 전송..."을 볼 수 있도록 하고, 체인 ID, 대상 주소, calldata, 값, 논스, 작업 유형 등 핵심 매개변수를 최소 두 개의 독립적인 도구나 인터페이스에서 동일하게 교차 검증하십시오.
• 사람과 자동화의 이중 검사. 자동화된 규칙 엔진이 1차 심사를 처리하고, 대규모 트랜잭션이 발송되기 전에 사람이 확인합니다.
• 제로 트러스트와 백업. 서명 서비스, 비즈니스 로직, 프론트엔드 인터페이스를 서로 다른 보안 도메인에 배포하고, 기본 서명 UI, RPC, 블록 익스플로러에 대한 대안을 마련하여 단일 벤더나 서비스 장애가 긴급 서명을 차단하지 않도록 하십시오.

멀티시그 운영 표준

키와 임계값 선택만으로는 충분하지 않습니다. 몇 가지 운영 표준이 그만큼 중요합니다.

멀티시그 레지스트리. 모든 멀티시그의 단일 기록을 유지하며, 각 항목에는 최소한 다음을 포함해야 합니다: 주소, 체인, 서명 임계값, 위험 등급, 목적, 서명자 주소, 제어되는 컨트랙트, 온체인 역할, 마지막 검토 날짜. 보안에 민감한 변경은 24시간 이내에, 일반 변경은 3일 이내에 레지스트리를 업데이트해야 합니다.

서명자 수명 주기 관리. 온보딩 전에 특정 메시지에 서명하게 하여 주소를 검증하고, 독립적인 도구로 확인하십시오. 위험 등급별로 퇴직하거나 제거된 서명자의 권한을 제거하는 SLA를 설정하십시오 — 긴급 사항은 48-72시간 이내, 중요 사항은 7일 이내, 나머지는 14일 이내. 분기별 접근 검토를 실시하여 각 서명자가 여전히 키를 제어하고 있는지 확인하고, 최소 연간 서명자 교육을 갱신하여 트랜잭션 검증, 긴급 절차, 소셜 엔지니어링/피싱 방어를 다루고, 이후 실습 평가를 실시하십시오.

시드 구문 및 백업 보호. 어떠한 형태의 디지털 저장도 안 됩니다 — 클라우드 드라이브, 사진 앨범, 문서 포함. 백업을 서로 다른 지리적 위치에 분산하여 자연재해, 도난, 운영자 실종에 대비해 복구 가능하도록 하십시오. 어떤 단일 지점도 완전한 복구 정보를 보유해서는 안 됩니다.

보안 통신. 서로 다른 플랫폼의 기본 및 백업 채널을 사용하여 서명자들 간에 조율하되, 각 채널은 MFA, 종단간 암호화, 초대 전용 멤버십을 적용해야 합니다. 서명 전에 독립적인 채널 — 화상 통화, 암호 문구, 인증된 두 번째 채널 — 을 통해 서명자의 신원을 확인하여 탈취된 IM 계정이 서명자를 사칭하는 것을 방지하십시오.

긴급 대응 SLA. 사고 심각도에 따라 서명자 응답 시간을 설정하십시오, 예를 들어 긴급은 2시간 이내, 시간에 민감한 것은 2-12시간, 일반은 24-48시간. 서류상만이 아니라 분기별로 서명자 연락 가능 여부를 테스트하고, 유출된 키, 연락 불가능한 서명자, 침해된 통신 채널, 긴급 프로토콜 작업 등의 시나리오를 포함하여 연간 최소 한 번의 종단간 긴급 훈련을 실시하십시오.

멀티시그 온체인 모니터링. 서명자/임계값 변경, 임계값 초과 이체, 논스 격차, 알 수 없는 주소와의 상호작용, 실패한 트랜잭션, 모듈/가드 변경, 비정상적인 제안자 지갑 잔액을 모니터링하십시오. 모니터링 인프라 자체도 변조 방지가 필요합니다.

API 보안

API 보안은 결제 백엔드의 첫 번째 방어선입니다. 이는 API 키와 HMAC 서명 또는 FIDO2/WebAuthn을 통한 인증, 무차별 공격 및 남용 방지를 위한 속도 제한, CDN/WAF 서비스를 통한 DDoS 보호, 인젝션 방지를 위한 모든 입력 매개변수의 엄격한 검증, 그리고 모든 API 호출이 완전한 감사 추적을 생성하는 로그 감사를 의미합니다.

서명 환경은 이 모든 것으로부터 단순히 보호받는 것이 아니라 격리되어야 합니다 — 이것이 위에서 다룬 것처럼 서명 서비스가 자체 보안 도메인에 있어야 하는 이유입니다.

운영 보안: 인력, 벤더, 및 독립 감사

2026년의 여러 주요 사고는 소셜 엔지니어링을 포함했습니다 — 가짜 채용, IT 지원 가장, AI 얼굴 교체 등이 그 예입니다. 이를 방어하려면 세 가지 수준이 함께 작동해야 합니다.

교육과 평가가 먼저입니다: 서명 시스템, 프로덕션 자격 증명, 또는 민감한 작업에 접근하는 모든 사람은 온보딩 시 보안 교육을 완료하고, 연간 갱신하며, 프로세스 변경 후 30일 이내에 내용을 업데이트합니다.

직무 분리도 마찬가지로 중요합니다: 개시, 승인, 실행은 동일인이 수행할 수 없으며, 관리자 계정은 직접 지급할 수 없습니다. 서명과 같은 고민감도 작업은 전용 기기를 사용해야 합니다 — 전체 디스크 암호화, 자동 잠금 — 하드웨어 지갑은 사용하지 않을 때 금고에 보관하며, 모든 원격 접근은 VPN을 통해 이루어져야 합니다.

제3자도 동일한 규율이 필요합니다. 벤더 선택 전에 실사를 수행하고, 주요 벤더의 컴플라이언스 및 보안 상태를 연간 재검토하며, 제3자 접근에 명확한 범위, 목적, 만료일을 부여하십시오 — 만료되거나 프로젝트가 종료되면 즉시 취소합니다. 접근 권한을 부여하기 전에 제3자 직원의 신원을 독립적으로 확인하십시오.

이 중 어느 것도 내부 자체 점검에만 의존해서는 안 됩니다. 최소한 침투 테스트, 레드팀 훈련, 코드 및 스마트 컨트랙트 감사를 포함하는 독립적인 제3자 보안 평가를 정기적으로 실행하십시오. 발견 사항을 하나씩 수정하고 다음 평가 라운드에서 종결 여부를 확인하십시오.

개발 및 인프라 보안

최근 몇 년간 주요 결제 및 암호화폐 사고들 중 상당수는 침해된 개발 프로세스로 거슬러 올라갑니다 — 컨트랙트와 서명 로직 자체는 완벽하게 정상이었습니다. 이는 개발 및 인프라 레이어가 네 가지 영역에 걸쳐 서명 레이어와 동일한 주의를 받아야 함을 의미합니다.

개발 환경 격리는 개발 계정을 권한 있는 계정(서명, 클라우드 관리)과 분리하고, 프로덕션 자격 증명을 개발 환경이 접근할 수 없게 하며, 개발 도구와 확장 프로그램을 승인 목록에 넣습니다.

코드 저장소와 공급망은 메인 브랜치에 브랜치 보호, 서명된 커밋, 다자 검토가 필요합니다. 고정된 버전과 오타 스쿼팅 검사로 공식 저장소에서만 종속성을 가져오고, 노출된 키를 즉시 취소하고 교체하는 자동 비밀 스캐닝을 실행하십시오.

CI/CD에서, 파이프라인 구성 변경은 다자 승인과 버전 관리가 필요하며, 재현 가능한 빌드가 필요합니다. 비밀은 Vault나 클라우드 KMS 같은 전용 관리자를 통해 관리하십시오 — 프로덕션 비밀은 사람이 직접 접근할 수 없어야 합니다 — SAST와 종속성 스캐닝은 선택 사항이 아닌 배포의 전제 조건입니다.

인프라 및 클라우드의 경우, 적시 프로비저닝, 다자 승인, 시간 제한을 통해 권한 있는 접근을 부여하십시오. 긴급 상황을 위한 브레이크글라스 계정을 유지하되, 모든 사용에 경고를 발령하십시오. 완전한 감사 로그, 관리자 작업에 대한 실시간 경고, 정기적으로 훈련된 백업 및 재해 복구를 실행하십시오.

도메인, DNS, 신원: 과소평가된 공격 표면

도메인과 DNS는 암호화폐에서 심각하게 과소평가된 공격 표면입니다 — 많은 피싱 사고와 도난은 침해된 등록 기관 계정이나 탈취된 DNS로 거슬러 올라갑니다. 사용자가 자금 작업을 시작하는 도메인을 보호하는 것은 서명 환경을 보호하는 것만큼이나 중요합니다.

등록 기관 계정을 고권한 계정으로 관리하십시오: 하드웨어 키 MFA를 적용하고, 이전, 삭제, 네임서버 변경과 같은 중요한 변경에 대역 외 두 번째 확인을 요구하십시오. DNS 및 이메일 측면에서, 중요 도메인에 DNSSEC를 활성화하고, CAA를 사용하여 인증서를 발급할 수 있는 CA를 제한하며, 모든 발송 도메인에 SPF/DKIM/DMARC(p=reject)를 구성하십시오 — 발송하지 않는 도메인도 스푸핑을 방지하기 위해 명시적으로 메일을 거부하도록 설정하십시오.

DNS 레코드 변경, 네임서버 위임, 비정상적인 인증서 투명성 로그 발급을 감시하는 도메인에 의존하지 않는 모니터링 인프라를 사용하여 지속적으로 모니터링하십시오. 도메인 하이재킹 및 무단 이전에 대한 처리 프로세스를 문서화하고, 연간 훈련하며, 만료된 도메인이 진입점이 되지 않도록 계층화된 만료 경고와 자동 갱신을 설정하십시오.

신원과 계정은 거의 모든 횡적 이동의 진입점입니다. 조직 계정의 완전한 인벤토리와 엄격한 MFA 표준은 어떤 단일 지점 방어보다 중요합니다.

계정 인벤토리부터 시작하십시오: 모든 조직 계정 — 소셜 미디어, 이메일, SSO/IdP, 등록 기관, 수탁 플랫폼, 코드 저장소, 클라우드 루트, 주요 SaaS — 을 명확한 소유자와 함께 등록하고 정기적으로 검토하십시오. 고권한 계정에 FIDO2/WebAuthn 하드웨어 키로 피싱 방지 MFA를 적용하고, SMS나 음성을 기본 요소로 절대 사용하지 마십시오 — SIM 스왑, SS7, 보이스 피싱 모두 이를 우회합니다. 이것이 계정 탈취에 대한 가장 효과적인 단일 방어입니다.

고유한 강력한 암호를 가진 암호 관리자를 적용하고, 공유 로그인을 금지하며, 복구 이메일과 전화를 조직 도메인으로 제한하십시오 — 복구 코드는 개인 이메일이나 클라우드가 아닌 안전한 저장소에 보관하십시오. 누군가가 퇴직하면 24시간 이내에 모든 접근 권한을 취소하고 그들이 접촉한 공유 자격 증명을 교체하며, 활성 상태인 동안 고권한 계정에 대한 행동 및 자격 증명 유출 모니터링을 지속적으로 실행하십시오.

AI 에이전트의 아키텍처가 설계상 안전하지 않은 이유

결제 회사들은 개발 및 운영 효율성을 높이기 위해 AI 도구와 에이전트를 점점 더 많이 사용하고 있습니다 — 하지만 이는 잘못 처리되면 자금을 직접적으로 위협하는 새로운 공격 표면을 열어줍니다.

여기서 쉽게 놓치는 부분이 있습니다: AI 에이전트는 단순히 질문에 답하는 모델이 아닙니다. 외부 콘텐츠를 읽고, 도구를 호출하고, 자격 증명을 보유하고, 작업을 실행할 수 있는 기계입니다. 위험의 근원은 신뢰할 수 없는 콘텐츠에서 읽은 텍스트를 실행할 명령으로 처리한다는 점입니다.

이는 공격자에게 취약점도, 도난당한 계정도 필요 없다는 것을 의미합니다. 문서, 웹 페이지, 코드 주석, 또는 PR 설명에 한 문장을 숨기면 에이전트의 동작을 데이터 유출이나 무단 작업으로 탈취할 수 있습니다. 이를 프롬프트 인젝션이라고 하며, 2026년까지 원격 코드 실행으로 직접 확대되는 것이 입증되었습니다 — Microsoft는 에이전트를 실행하는 기계에서 단일 프롬프트로 프로그램을 실행하는 것을 시연했으며, GitHub Copilot, Cursor, MCP 인프라 모두 CVSS 9.6 이상으로 평가된 RCE 취약점을 공개했습니다.

권한 있는 것에는 더 악화됩니다. 개발 또는 운영 에이전트는 기본적으로 운영자의 파일 접근, 셸 권한, 데이터베이스 키를 상속합니다. 주류 코딩 에이전트를 다룬 2026년 연구에서 모두 프롬프트 인젝션으로 침해될 수 있었으며, 적응형 공격 성공률이 85% 이상이었습니다. 신뢰할 수 없는 입력을 처리하는 모든 에이전트는 자격 증명을 보유한 잠재적 내부자로 취급되어야 합니다 — 공급망도 고위험 링크입니다: 2026년 3월, 오염된 AI 게이트웨이 종속성이 공개 저장소에 3시간 동안 존재하며 거의 47,000번 다운로드되었습니다.

자금 통제권을 잃지 않고 AI 에이전트 효율성을 활용하는 방법

접근 방식은 에이전트를 신뢰할 수 없는 코드에 적용하는 것과 동일한 제약 아래 두는 것으로, 다섯 가지 통제를 통해 이루어집니다:

• 격리된 실행 — 에이전트의 도구 실행을 샌드박스에서 실행하여, 프롬프트 인젝션이 실제 셸, 프로덕션 키, 또는 서명 환경에 접근할 수 없도록 합니다.
• 최소 권한 — 에이전트의 도구, 데이터베이스 키, MPC 서비스에 단일 작업에 필요한 최소한만 부여하고, 절대 "전체 접근" 자격 증명을 부여하지 마십시오.
• 자금 작업에 대한 사람 게이트 — 이체, 서명, 권한 변경과 관련된 모든 것에 대해 에이전트는 제안만 할 수 있으며, 자동으로 실행할 수 없습니다. 독립적인 사람의 승인이 여기에도 적용됩니다, 위에서 다룬 서명 검증의 동일한 원칙입니다.
• 신뢰할 수 있는 명령과 신뢰할 수 없는 데이터를 아키텍처 수준에서 분리 — 모델이 "스스로 구별하기를" 기대하지 마십시오.
• 공급망 잠금 — 일반 코드 저장소에 적용하는 것과 동일한 버전 고정 및 출처 검사를 AI 관련 종속성에 적용하십시오.

이러한 제약이 이론에 머물 필요는 없습니다. BlockSec의 오픈소스 Web3 Companion은 보안 에이전트 지갑의 참조 구현입니다 (MIT 라이선스, 연구 미리보기). AI 에이전트가 사용자의 온체인 트랜잭션 준비를 도우면서 개인 키와 최종 인가는 에이전트의 손이 닿지 않는 곳에 완전히 보관할 수 있도록 합니다. 위협 모델은 에이전트 자체를 신뢰할 수 없는 것으로 취급합니다 — 완전히 침해된 에이전트조차도 사용자의 자금을 이동할 수 없음을 전체 시스템이 보장해야 합니다.

아키텍처는 세 가지 지점에 기반합니다. 키 격리는 하나의 독립적인 서명 모듈(별도의 Go 프로세스)만이 개인 키를 건드릴 수 있음을 의미합니다 — 에이전트는 트랜잭션 의도 ID를 받고, 서명을 요청할 수 있지만, 키는 절대 볼 수 없습니다. 키는 엔벨로프 암호화(AWS KMS 또는 로컬 AES-256)로 저장되며, 평문은 서명 순간에만 메모리에 존재하고 이후 제로화됩니다.

브로드캐스트 전에, 트랜잭션은 각각 이전 것이 실패했다고 가정하며 순서대로 네 개의 레이어를 통과합니다: 트랜잭션 시뮬레이션(calldata 디코딩, 되돌림 예측), 상대방 위험 점수 산정, 순수 Go 하드 정책 제한(트랜잭션당 한도, 일일 예산, 화이트리스트 — 에이전트가 수정할 수 없음), 그리고 마지막으로 패스키 사람 확인, 소프트웨어 전용 공격이 위조할 수 없는 WebAuthn 지문 또는 얼굴 스캔. 키, 정책, 패스키는 세 개의 독립적인 신뢰 경계를 형성하므로, 하나를 침해해도 다른 두 개는 그대로 유지됩니다.

AI 에이전트는 진정으로 효율성을 높일 수 있지만, 자금과 서명에 대한 단독 제어권을 가져서는 안 됩니다. 최소 권한 샌드박스에서 보조자로 사용하고, 자금과 서명에 대한 최종 결정은 사람이 내리도록 하십시오.

종합

키 관리는 하나의 결정이 아닙니다 — 독립적으로 이루어지다가 결합되는 세 가지 결정입니다: 누가 서명해야 하는지, 키 또는 조각이 물리적으로 어디에 있는지, 그리고 인터넷에 얼마나 노출되어 있는지. 각 자금 계층에 맞는 올바른 조합을 선택하고, 강화된 서명 인프라로 뒷받침하며, 위의 운영 표준으로 유지하는 것이 2025-2026년의 주요 키 및 서명 관련 사고의 격차를 해소하는 BlockSec의 프레임워크입니다. 그리고 이제 표면이 키를 넘어 API, 인력, 벤더, 코드 파이프라인, 도메인, 신원, AI 에이전트로 확장되었으므로 — 각각은 동일한 처리가 필요합니다: 이전 레이어가 실패했다고 가정하고, 자금이 이동할 수 있는 곳마다 사람이 개입하도록 하십시오.

결제 시스템의 컴플라이언스 프로그램의 나머지 부분과 함께 키 관리 및 운영 보안이 어디에 적합한지에 대한 전체 그림은 암호화폐 결제 보안 및 컴플라이언스 플레이북(PDF)을 다운로드하십시오.

FAQ

MPC와 멀티시그의 실제 차이점은 무엇인가요? 멀티시그는 다수의 완전한 개인 키로, 각각 온체인에서 별도로 검증됩니다 — 투명하지만 비용이 높고 서명자 교체가 번거롭습니다. MPC(임계값 서명)는 완전한 개인 키가 절대 존재하지 않도록 생성된 다수의 키 조각입니다; 부분 서명들이 오프체인에서 하나의 서명으로 결합됩니다 — 유연하고 저렴하지만 조율 인프라에 의존합니다.

샤미르 비밀 공유(SSS)가 MPC와 같은 것인가요? 아닙니다. SSS는 이미 존재하는 완전한 개인 키를 조각으로 나누고 서명을 위해 메모리에서 전체 키를 재구성하며, 이 재구성 순간이 단일 장애 지점이 됩니다. 실제 MPC(TSS)는 완전한 개인 키를 절대 재구성하지 않습니다 — 각 당사자는 자신의 조각에서만 부분 서명을 계산합니다.

TEE와 HSM의 차이점은 무엇인가요? TEE(Intel SGX, AWS Nitro, 또는 Apple Secure Enclave 등)는 MPC 프로토콜을 포함한 임의의 코드를 실행할 수 있는 범용 CPU의 격리된 암호화 영역입니다 — 강력한 논리적 격리이지만 HSM보다 물리적 변조 방지 및 인증이 약합니다. HSM은 개인 키가 내부에서 생성되어 내보내기 불가로 표시되며 물리적으로 외부로 나갈 수 없는 전용 변조 방지 하드웨어입니다.

웜 지갑이란 무엇이며, 핫 또는 콜드와 어떻게 다른가요? 웜 지갑은 온라인 상태이지만 개인 키가 보호된 환경(전용 서명 서비스 또는 HSM)에 격리되어 있어 서명 과정에 사람이 개입해야 하며, 일상적인 결제에 사용됩니다 — 항상 온라인 상태의 자동화된 핫 지갑과 완전히 오프라인인 에어갭 콜드 지갑 사이에 위치합니다.

BlockSec이 콜드 스토리지에 대해 구체적으로 권장하는 것은 무엇인가요? 팀의 온체인 운영 역량에 따라 다릅니다: 성숙한 온체인 운영을 갖춘 팀은 각 서명자의 키를 HSM이나 하드웨어 지갑에 보관하는 컨트랙트 멀티시그(예: Safe의 3-of-5)를 사용할 수 있습니다; 운영 복잡성을 줄이고 싶은 팀은 TEE에 조각을 보관하는 MPC 임계값 서명에 트랜잭션 안전성 검사를 위한 독립적인 제3자 공동 서명자를 추가하여 사용할 수 있습니다.

블라인드 서명이란 무엇이며, 왜 위험한가요? 블라인드 서명은 서명 인터페이스가 트랜잭션이 실제로 무엇을 하는지 대신 calldata 해시만 표시하는 경우입니다. 서명자는 자신이 승인하는 것의 실제 의미를 확인할 수 없으며, 이것이 바이비트 사건의 직접적인 원인 중 하나였습니다.

AI 에이전트를 암호화폐 결제 작업에 신뢰할 수 있나요? 단독 제어권은 아닙니다. AI 에이전트는 자금 작업을 제안하는 것만 허용되어야 하며, 자동으로 실행해서는 안 됩니다 — 이체, 서명, 권한 변경 모두 독립적인 사람의 승인이 필요하며, 에이전트는 최소 권한 샌드박스에서 실행됩니다.

프롬프트 인젝션이란 무엇이며, 얼마나 심각한가요? 프롬프트 인젝션은 신뢰할 수 없는 콘텐츠 — 문서, 웹 페이지, 코드 주석, 또는 PR 설명 — 에 명령을 숨겨 AI 에이전트의 동작을 탈취합니다. 2026년까지 주류 코딩 도구에서 공개된 취약점에서 원격 코드 실행으로 확대되어 CVSS 9.6 이상으로 평가되었습니다.

계정 탈취에 대한 가장 효과적인 단일 방어는 무엇인가요? 피싱 방지 MFA — 고권한 계정에 FIDO2/WebAuthn 하드웨어 키를 적용하고, SIM 스왑, SS7, 보이스 피싱이 모두 이러한 채널을 우회할 수 있으므로 SMS나 음성을 기본 요소로 절대 사용하지 않는 것입니다.