"web3" 태그로 연결된 27개 게시물개의 게시물이 있습니다.

1. Web3 컨텍스트에서 MCP의 정의 및 기원​

** MCP (Model Context Protocol) **는 AI 어시스턴트 (대형 언어 모델과 같은)를 외부 데이터 소스, 도구 및 환경에 연결하는 공개 표준입니다. Universal Plug-and-Play Nature로 인해 AI의 USB-C 포트 "로 종종 MCP는 2024 년 11 월 말에 처음으로 소개되었으며 데이터베이스 및 API에서 개발 환경 및 블록 화장에 이르기까지 *“데이터가 생기는 시스템”을 단단히 브리지함으로써 AI 모델을 분리하여 분리하는 솔루션으로 등장했습니다.

원래 Anthropic의 실험적 측면 프로젝트 인 MCP는 신속하게 견인력을 얻었습니다. 20124 년 중반, 오픈 소스 참조 구현이 나타 났으며 2025 년 초까지는 AI Labs (Openai, Google Deepmind, Meta AI)가 기본적으로 채택하면서 에이전트 AI 통합 **의 사실상 표준이되었습니다. 이 빠른 흡수는 특히 ** web3 커뮤니티 **에서 주목할 만했습니다. 블록 체인 개발자는 MCP를 AI 기능을 분산 된 응용 프로그램에 주입하는 방법으로 보았으며, 온쇄 데이터 및 서비스를위한 커뮤니티 구축 MCP 커넥터가 확산되었습니다. 실제로, 일부 분석가들은 MCP가 자연어 인터페이스를 사용하여 사용자에게 권한을 부여함으로써 블록 체인보다 더 실용적인 방법으로 분산 된 사용자 중심 인터넷에 대한 Web3의 원래 비전을 충족시킬 수 있다고 주장합니다.

요약하면, MCP는 ** 블록 체인이나 토큰 **이 아니라 AI 세계에서 태어난 개방형 프로토콜은 AI 에이전트와 분산 된 데이터 소스 사이의 브리지로 Web3 생태계 내에서 빠르게 수용 된 공개 프로토콜입니다. 인위적인 개방형 표준 (초기 Github 사양 및 SDK 포함)을 개방하고 주변에 열린 커뮤니티를 재배했습니다. 이 커뮤니티 중심의 접근 방식은 MCP가 Web3에 통합되는 단계를 설정했으며, 현재 AI 지원 분산 응용 프로그램의 기초 인프라로 간주됩니다.

2. 기술 아키텍처 및 핵심 프로토콜​

MCP는 세 가지 주요 역할을 가진 경량 ** 클라이언트 - 서버 아키텍처 **에서 운영됩니다.

• ** MCP 호스트 : ** AI 응용 프로그램 또는 에이전트 자체가 요청을 조율합니다. 이것은 챗봇 (Claude, Chatgpt) 또는 외부 데이터가 필요한 AI 구동 앱일 수 있습니다. 호스트는 MCP를 통해 도구 나 정보를 요구하는 상호 작용을 시작합니다.
• ** MCP 클라이언트 : ** 호스트가 서버와 통신하기 위해 사용하는 커넥터 구성 요소. 클라이언트는 연결을 유지하고 요청/응답 메시징을 관리하며 여러 서버를 병렬로 처리 할 수 ​​있습니다. 예를 들어, Cursor 또는 VS Code의 에이전트 모드와 같은 개발자 도구는 다양한 MCP 서버로 로컬 AI 환경을 연결하는 MCP 클라이언트 역할을 할 수 있습니다.
• ** MCP 서버 : ** 일부 상황 데이터 또는 기능을 AI에 노출시키는 서비스. 서버는 ** 도구 **, ** 리소스 ** 또는 ** 프롬프트 **를 제공합니다. 실제로 MCP 서버는 데이터베이스, 클라우드 앱 또는 블록 체인 노드와 인터페이스하고 AI에 표준화 된 작업 세트를 제시 할 수 있습니다. 각 클라이언트-서버 쌍은 자체 채널을 통해 통신하므로 AI 에이전트는 여러 서버를 동시에 탭하여 다양한 요구에 맞게 할 수 있습니다.

** 핵심 프리미티브 : ** MCP는 AI-Tool 상호 작용을 구성하는 표준 메시지 유형과 프리미티브 세트를 정의합니다. 세 가지 기본 원시는 다음과 같습니다.

• ** 도구 : ** 개별 작업 또는 기능 AI가 서버에서 호출 할 수 있습니다. 예를 들어, "SearchDocuments"도구 또는 "Eth_Call"도구입니다. 도구는 API 쿼리, 계산 수행 또는 스마트 계약 기능을 호출하는 것과 같은 작업을 캡슐화합니다. MCP 클라이언트는 서버에서 사용 가능한 도구 목록을 요청하여 필요에 따라 호출 할 수 있습니다.
• ** 리소스 : ** AI가 서버를 통해 읽거나 때로는 쓸 수있는 데이터 엔드 포인트. 파일, 데이터베이스 항목, 블록 체인 상태 (블록, 트랜잭션) 또는 상황 데이터 일 수 있습니다. AI는 표준 MCP 메시지 (예 :listresources '및readResource'요청)를 통해 리소스를 나열하고 컨텐츠를 검색 할 수 있습니다.
• ** 프롬프트 : ** 서버가 AI의 추론을 안내하기 위해 서버가 제공 할 수있는 구조화 된 프롬프트 템플릿 또는 지침. 예를 들어 서버는 서식 템플릿 또는 사전 정의 된 쿼리 프롬프트를 제공 할 수 있습니다. AI는 프롬프트 템플릿 목록을 요청하여 해당 서버와 상호 작용하는 방식의 일관성을 유지하기 위해이를 사용할 수 있습니다.

후드에서 MCP 통신은 일반적으로 JSON 기반이며 RPC와 유사한 요청-응답 패턴 (원격 프로 시저 호출)을 따릅니다. 이 프로토콜의 사양은earnitizerequest,ListTools,`CallTool ','listresources '등과 같은 메시지를 정의하여 MCP 호환 클라이언트가 모든 MCP 서버와 균일 한 방식으로 대화 할 수 있도록합니다. 이 표준화는 AI 에이전트가 할 수있는 일을 * 발견 할 수있는 것입니다. 새로운 서버에 연결하면“어떤 도구와 데이터를 제공합니까?”를 문의 할 수 있습니다. 그런 다음 사용 방법을 동적으로 결정하십시오.

** 보안 및 실행 모델 : ** MCP는 안전하고 제어 된 상호 작용을 염두에두고 설계되었습니다. AI 모델 자체는 임의의 코드를 실행하지 않습니다. 클라이언트를 통해 높은 수준의 의도를 서버로 보낸 다음 실제 작업 (예 : 데이터 가져 오기 또는 API 호출)을 수행하고 결과를 반환합니다. 이 분리는 민감한 조치 (블록 체인 트랜잭션 또는 데이터베이스 쓰기)를 의미합니다. 샌드 박스 또는 명시적인 사용자 승인이 필요할 수 있습니다. 예를 들어,`Ping '(연결을 유지하기 위해)과 같은 메시지와'CreatemesSagerequest '와 같은 메시지가 있습니다. 이는 MCP 서버가 클라이언트의 AI에 일반적으로 사용자 확인에 의해 게이트 된 하위 응답을 생성하도록 요청할 수 있습니다. 인증, 액세스 제어 및 감사 로깅과 같은 기능은 MCP를 엔터프라이즈 및 분산 환경에서 안전하게 사용할 수 있도록 적극적으로 개발되고 있습니다 (로드맵 섹션의 자세한 내용).

요약하면 MCP의 아키텍처는 AI 에이전트 (호스트)를 도구, 데이터 및 작업을 제공하는 유연한 서버에 연결하는 ** 표준화 된 메시지 프로토콜 ** (JSON-RPC 스타일 호출)에 의존합니다. 이 개방형 아키텍처는 ** Model-Agnostic ** 및 ** Platform-Agnostic **-모든 AI 에이전트는 MCP를 사용하여 모든 리소스와 대화 할 수 있으며 모든 개발자는 AI의 핵심 코드를 수정할 필요없이 데이터 소스 용 새 MCP 서버를 만들 수 있습니다. 이 플러그 앤 플레이 확장성은 Web3에서 MCP를 강력하게 만드는 이유입니다. 블록 체인 노드, 스마트 계약, 지갑 또는 오라클을위한 서버를 구축 할 수 있으며 AI 에이전트가 해당 기능을 Web2 API와 완벽하게 통합하도록합니다.

3. Web3에서 MCP의 사례 및 응용 프로그램​

MCP는 AI 중심 애플리케이션이 블록 체인 데이터에 액세스하고 안전하고 높은 수준의 방식으로 온 체인 또는 오프 체인 동작을 실행할 수 있도록하여 광범위한 ** 사용 사례 **를 잠금 해제합니다. 다음은 Web3 도메인에서 해결하는 데 도움이되는 몇 가지 주요 응용 프로그램과 문제입니다.

-** 온 체인 데이터 분석 및 쿼리 : ** AI 에이전트는 실시간으로 라이브 블록 체인 상태를 쿼리하여 통찰력 또는 트리거 작업을 제공 할 수 있습니다. 예를 들어, 이더 리움 노드에 연결된 MCP 서버를 사용하면 AI가 계정 잔액을 가져 오거나 스마트 계약 저장을 읽거나 트레이스 트랜잭션을 추적하거나 이벤트 로그를 검색 할 수 있습니다. 이것은 챗봇 또는 코딩 어시스턴트를 블록 체인 탐색기로 바꿉니다. 개발자는 "Uniswap Pool X의 현재 유동성은 무엇입니까?"와 같은 AI 보조 질문을 할 수 있습니다. 또는 "이 이더 리움 거래의 가스 비용을 시뮬레이션"하면 AI는 MCP 도구를 사용하여 RPC 노드를 호출하고 라이브 체인에서 답을 얻습니다. 이것은 AI의 교육 데이터 또는 정적 스냅 샷에 의존하는 것보다 훨씬 강력합니다.

• ** 자동 DEFI 포트폴리오 관리 : ** 데이터 액세스 및 작업 도구를 결합하여 AI 에이전트는 Crypto 포트폴리오 또는 Defi 위치를 관리 할 수 ​​있습니다. 예를 들어, ** "AI Vault Optimizer"**는 수확량 농장에서 사용자의 위치를 ​​모니터링하고 실시간 시장 조건에 따라 재조정 전략을 자동으로 제안하거나 실행할 수 있습니다. 마찬가지로 AI는 위험 또는 요금이 변경 될 때 프로토콜 간의 할당을 조정하여 ** Defi Portfolio Manager ** 역할을 할 수 있습니다. MCP는 AI가 온 체인 메트릭 (가격, 유동성, 담보 비율)을 읽을 수있는 표준 인터페이스를 제공 한 다음 허용 된 경우 펀드 이동 또는 교환 자산과 같은 거래를 실행하도록 도구를 호출합니다. 이를 통해 사용자는 수율을 최대화하거나 수동으로 수행하기 어려운 방식으로 24/7의 위험을 관리하는 데 도움이 될 수 있습니다.
• ** 트랜잭션 용 AI 기반 사용자 에이전트 : ** 사용자의 블록 체인 상호 작용을 처리 할 수있는 개인 AI 어시스턴트를 생각하십시오. MCP를 사용하면 이러한 에이전트가 지갑 및 DAPP와 통합하여 자연어 명령을 통해 작업을 수행 할 수 있습니다. 예를 들어, 사용자는 "AI, 내 지갑에서 Alice로 0.5 ETH를 보내십시오"또는 "가장 높은 요법 수영장에서 토큰을 스테이크"라고 말할 수 있습니다. AI는 MCP를 통해 ** 보안 지갑 서버 ** (사용자의 개인 키를 보유)를 사용하여 트랜잭션을 생성하고 서명하고 블록 체인 MCP 서버를 사용하여 브로드 캐스트합니다. 이 시나리오는 복잡한 명령 줄 또는 메타 마스크 상호 작용을 대화 경험으로 바꿉니다. 보안 지갑 MCP 서버가 여기에서 사용되어 권한과 확인을 시행하는 것이 중요하지만 최종 결과는 AI 지원을 통해 온쇄 거래를 간소화하는 것이 중요합니다. -** 개발자 어시스턴트 및 스마트 계약 디버깅 : ** Web3 개발자는 블록 체인 인프라의 상황을 인식하는 MCP 기반 AI 어시스턴트를 활용할 수 있습니다. 예를 들어, ** ** Chainstack의 EVM 및 Solana 용 MCP 서버 ** ** AI 코딩은 개발자의 블록 체인 환경에 대한 깊은 가시성을 제공합니다. AI 어시스턴트 (vs Code 또는 IDE)를 사용하는 스마트 계약 엔지니어는 AI가 TestNet에서 계약의 현재 상태를 가져 오거나 트랜잭션 시뮬레이션을 실행하거나 로컬 블록 체인 노드에 대한 MCP 통화를 통해 로그를 확인할 수 있습니다. 이는 계약 디버깅 및 테스트에 도움이됩니다. AI는 더 이상 "맹목적으로"코딩하지 않습니다. 실제로 코드가 실시간으로 체인 동작 방식을 확인할 수 있습니다. 이 사용 사례는 AI가 문서 MCP 서버를 통해 최신 문서를 지속적으로 섭취하고 블록 체인을 직접 쿼리하여 환각을 줄이고 제안을 훨씬 정확하게 만들어 주요 진통 점을 해결합니다.
• ** 크로스 프로콜 코콜 조정 : ** MCP는 통합 인터페이스이기 때문에 단일 AI 에이전트는 여러 프로토콜과 서비스를 동시에 조정할 수 있습니다. Web3의 상호 연결된 환경에서 매우 강력합니다. 중재를위한 다양한 디피 플랫폼을 모니터링하는 ** 자율 거래 에이전트 **를 상상해보십시오. MCP를 통해 한 에이전트는 AAVE의 대출 시장, Layerzero 크로스 체인 브리지 및 MEV (Miner Extractable Value) 분석 서비스와 동시에 일관된 인터페이스를 통해 인터페이스 할 수 있습니다. AI는 하나의 "사고 프로세스"에서 Ethereum (Ethereum 노드의 MCP 서버를 통해)에서 유동성 데이터를 수집하고 가격 정보 또는 Oracle 데이터 (다른 서버를 통해)를 얻고 브리징 또는 교환 작업을 호출 할 수 있습니다. 이전에는 이러한 다중 플랫폼 조정에는 복잡한 맞춤형 코드 봇이 필요하지만 MCP는 AI가 전체 Web3 생태계를 하나의 빅 데이터/리소스 풀인 것처럼 탐색 할 수있는 일반화 가능한 방법을 제공합니다. 이를 통해 크로스 체인 수익률 최적화 또는 자동 청산 보호와 같은 고급 사용 사례는 AI가 자산을 사전에 이동하거나 담보로 이동하여 사전에 사전으로 이동할 수 있습니다.
• ** AI Advisory and Support Bots : ** 다른 카테고리는 암호화 응용 프로그램의 사용자 대상 고문입니다. 예를 들어, ** defi help chatbot ** Uniswap 또는 Compound와 같은 플랫폼에 통합되면 MCP를 사용하여 사용자의 실시간 정보를 가져올 수 있습니다. 사용자가“내 입장을 헤지하는 가장 좋은 방법은 무엇입니까?”라고 묻는 경우 AI는 MCP를 통해 현재 요금, 변동성 데이터 및 사용자의 포트폴리오 세부 정보를 가져올 수 있다면 컨텍스트 인식 답변을 제공 할 수 있습니다. 플랫폼은 ** AI 구동 조수 ** 지갑이나 DAPP에 내장되어 있으며 사용자가 복잡한 거래를 통해 사용자를 안내하고 위험을 설명하며 승인을 통해 일련의 단계를 실행할 수 있습니다. 이 AI 에이전트는 MCP를 사용하여 필요에 따라 쿼리하고 명령하여 사용자 경험을 단순화합니다.
• ** Web3 이상- 멀티 도메인 워크 플로 : ** 초점은 Web3이지만 MCP의 사용 사례는 AI가 외부 데이터가 필요한 모든 도메인으로 확장되는 것이 좋습니다. AI를 Google Drive, Slack, Github, Figma 등과 같은 것들에 연결하는 데 이미 사용되고 있습니다. 실제로, 단일 AI 에이전트는 Web3 및 Web2를 스팅 할 수 있습니다. 예를 들어, Google 드라이브에서 Excel 재무 모델을 분석 한 다음 해당 분석을 기반으로 한 쇄 트레이드를 하나의 워크 플로우로 제안합니다. MCP의 유연성을 통해 블록 체인 동작을 일상적인 도구와 혼합하는 크로스 도메인 자동화 (예 : "DAO 투표가 통과되면 회의 일정을 잡고 결과를 이메일로 보내십시오").

** 해결 된 문제 : ** 가장 중요한 문제 MCP 주소는 ** AI가 라이브 데이터 및 서비스와 상호 작용할 수있는 통합 인터페이스가 부족하다는 것입니다. **. MCP 이전에 AI가 새로운 서비스를 사용하려는 경우 해당 특정 서비스의 API에 대한 플러그인 또는 통합을 직접 코딩 해야하는 경우가 많았습니다. Web3에서 이것은 특히 번거 롭습니다. 모든 블록 체인이나 프로토콜에는 자체 인터페이스가 있으며 AI는 모두 지원할 수 없습니다. MCP는 AI가 원하는 것을 설명하는 방법 (자연 언어 맵핑)과 서비스가 제공하는 내용을 설명하는 방법을 표준화하여이를 해결합니다. 이것은 통합 작업을 크게 줄입니다. 예를 들어, 각 Defi 프로토콜에 대한 사용자 정의 플러그인을 작성하는 대신 개발자는 해당 프로토콜에 대해 하나의 MCP 서버를 작성할 수 있습니다 (본질적으로 자연 언어로 기능을 주석을 달았습니다). 그런 다음 모든 MCP 지원 AI (Claude, Chatgpt 또는 Open-Source 모델)가 즉시 활용할 수 있습니다. 이렇게하면 ai ** 확장 가능 **는 플러그 앤 플레이 방식으로 사용됩니다. 범용 포트를 통해 새 장치를 추가하는 것이 새 인터페이스 카드를 설치하는 것보다 쉽습니다.

요컨대, Web3의 MCP는 ** AI 에이전트가 블록 체인 월드의 일류 시민이 될 수있게합니다. 이것은 더 자율적 인 DAPP, 더 똑똑한 사용자 에이전트 및 온쇄 및 오프 체인 지능의 원활한 통합의 문을 열어줍니다.

4. 토 케노 믹스 및 거버넌스 모델​

일반적인 Web3 프로토콜과 달리 ** MCP에는 기본 토큰 또는 암호 화폐가 없습니다. ** 이는 자체적으로 블록 체인 또는 분산 된 네트워크가 아니라 오히려 개방형 프로토콜 사양 (HTTP 또는 JSON-RPC와 더 비슷합니다). 따라서 MCP 사용에 내재 된 토큰 발급, 스테이 킹 또는 수수료 모델과 같은 내장 토큰 유전학이 없습니다. AI 응용 프로그램 및 서버는 암호 화폐없이 MCP를 통해 통신합니다. 예를 들어, MCP를 통해 블록 체인을 호출하는 AI는 블록 체인 거래에 대한 가스 수수료를 지불 할 수 있지만 MCP 자체는 추가 토큰 수수료를 추가하지 않습니다. 이 디자인은 AI 커뮤니티에서 MCP의 기원을 반영합니다. 토큰 화 된 프로젝트가 아니라 AI-Tool 상호 작용을 개선하기위한 기술 표준으로 도입되었습니다.

** MCP의 거버넌스 **는 오픈 소스의 커뮤니티 중심 방식으로 수행됩니다. MCP를 개방 표준으로 발표 한 후, 무차별은 협업 개발에 대한 약속을 알렸다. 광범위한 ** 운영위원회 ** 및 실무 그룹은 프로토콜의 진화를 목자로 만들었습니다. 특히 20125 년 중반까지 Microsoft 및 Github와 같은 주요 이해 관계자는 MCP 운영위원회에 합류했습니다. 이것은 Microsoft Build 2025에서 발표되었으며, MCP의 로드맵 및 표준 결정을 안내하는 업계 플레이어의 연합을 나타냅니다. 위원회와 관리자는 공개 거버넌스 프로세스를 통해 일합니다. MCP 변경 또는 확장 제안은 일반적으로 공개적으로 논의됩니다 (예 : GitHub 문제 및“SEP” - 표준 향상 제안 - 가이드 라인). 또한 ** MCP 레지스트리 워킹 그룹 ** (블록, PulsEMCP, GitHub 및 Anthropic과 같은 회사의 관리자와 함께)는 다자간 거버넌스를 보여줍니다. 2025 년 초, 적어도 9 개의 다른 조직의 기고자들은 발견을위한 통합 MCP 서버 레지스트리를 구축하기 위해 협력하여 한 엔티티가 통제하기보다는 커뮤니티 구성원 간의 개발 방법을 보여줍니다.

토큰이 없기 때문에 ** 거버넌스 인센티브 **는 모든 사람의 프로토콜을 개선하기 위해 이해 관계자 (AI 회사, 클라우드 제공 업체, 블록 체인 개발자 등)의 공통 이익에 의존합니다. 이는 W3C 또는 IETF 표준이 어떻게 관리되는지와 다소 유사하지만 Github 중심 프로세스가 빠릅니다. 예를 들어, Microsoft와 Anthropic은 MCP (Oauth 및 Single Sign-on과 같은 것을 통합)에 대한 개선 된 승인 사양을 설계하기 위해 함께 일했으며 Github는 사용 가능한 서버 목록을 위해 공식 MCP 레지스트리 서비스에서 협력했습니다. 이러한 개선 사항은 모든 사람의 이익을 위해 MCP 사양에 기여했습니다.

MCP 자체는 토큰 화되지 않았지만 MCP 위에 경제 인센티브와 탈 중앙화 **에 대한 미래 지향적 인 아이디어가 있습니다. Web3의 일부 연구원과 사고 리더는 **“MCP 네트워크”**의 출현을 예상합니다-본질적으로 블록 체인과 같은 메커니즘을 사용하여 발견, 신뢰 및 보상을 사용하는 MCP 서버 및 에이전트의 분산 된 네트워크. 이러한 시나리오에서, 토큰이 고품질 MCP 서버를 실행하는 사람들에게 보상하는 데 사용되는 것을 상상할 수 있습니다 (광부 또는 노드 연산자가 인센티브를받는 방법과 유사합니다). ** 평판 등급, 검증 가능한 계산 및 노드 발견 **와 같은 기능은 스마트 계약이나 블록 체인에 의해 촉진 될 수 있으며, 토큰은 정직한 행동을 주도합니다. 이것은 여전히 ​​개념적이지만 MIT의 NAMDA (나중에 논의)와 같은 프로젝트는 MCP를 사용하는 AI 에이전트 네트워크에 대한 토큰 기반 인센티브 메커니즘을 실험하고 있습니다. 이러한 아이디어가 성숙하면 MCP는 온쇄 토큰 유전학과 더 직접적으로 교차 할 수 있지만 2025 년 현재 핵심 MCP 표준은 토큰이없는 상태로 남아 있습니다.

요약하면, MCP의 "거버넌스 모델"은 개방형 기술 표준의 것입니다 : 체인 거버넌스 토큰이없는 커뮤니티 및 전문가의 운영위원회가 공동으로 유지 관리합니다. 결정은 코인 가중 투표보다는 기술적 인 장점과 광범위한 합의에 의해 이어집니다. 이것은 많은 Web3 프로토콜과 MCP를 구별합니다. 이는 독점적 인 블록 체인 또는 토큰을 통한 개방형 소프트웨어 및 표준을 통해 Web3의 이상 (분권화, 상호 운용성, 사용자 권한 부여)을 충족하는 것을 목표로합니다. 하나의 분석의 말에 따르면, *“Web3의 약속은 마침내 블록 체인과 암호 화폐를 통해가 아니라 자연 언어와 AI 요원을 통해 실현 될 수 있습니다. 즉, MCP 네트워크가 성장함에 따라 블록 체인 기반 거버넌스 또는 인센티브 메커니즘이 생태계를 강화하는 하이브리드 모델을 볼 수 있습니다.

5. 커뮤니티 및 생태계​

MCP 생태계는 AI 개발자, 오픈 소스 기고자, Web3 엔지니어 및 주요 기술 회사에 걸쳐 짧은 시간에 폭발적으로 성장했습니다. ** 주요 기고자 및 파트너십 **을 포함한 활기찬 커뮤니티 노력입니다.

• ** Anthropic : ** 제작자로서 MCP 사양과 여러 참조 서버 (Google Drive, Slack, Github 등)를 개방하여 생태계를 시드했습니다. Anthropic은 계속해서 개발을 이끌고 있습니다 (예 : Theodora Chu와 같은 직원은 MCP 제품 관리자 역할을하며 Anthropic의 팀은 사양 업데이트 및 커뮤니티 지원에 크게 기여합니다). Anthropic의 개방성은 다른 사람들이 단일 회사 도구로 보지 않고 MCP를 구축하도록 유치했습니다.

• ** 얼리 어답터 (Block, Apollo, Zed, Replit, Codeium, SourceGraph) : ** 릴리스 후 첫 달에 얼리 어답터의 물결이 제품에서 MCP를 구현했습니다. ** Block (이전의 Square) ** 통합 MCP는 Fintech의 AI 에이전트 시스템을 탐색하기위한 통합 된 MCP-Block의 CTO는 AI를 실제 응용 프로그램에 연결하는 열린 교량으로 MCP를 칭찬했습니다. ** Apollo ** (아마도 Apollo GraphQL)는 MCP를 통합하여 AI 내부 데이터에 대한 액세스를 허용했습니다. ** Zed (Code Editor) **, ** Replit (Cloud IDE) **, ** Codeium (AI Coding Assistant) ** 및 ** SourceGraph (Code Search) **와 같은 개발자 도구 회사는 각각 MCP 지원을 추가하기 위해 노력했습니다. 예를 들어, SourceGraph는 MCP를 사용하므로 AI 코딩 어시스턴트는 질문에 대한 응답으로 저장소에서 관련 코드를 검색 할 수 있으며 REPLIT의 IDE 에이전트는 프로젝트 별 컨텍스트를 가져올 수 있습니다. 이 얼리 어답터는 MCP에게 신뢰성과 가시성을 제공했습니다.

• ** 대형 기술 보증 - OpenAi, Microsoft, Google : ** 주목할만한 경쟁 업체 인 회사는 MCP에 정렬되었습니다. ** OpenAi의 CEO Sam Altman CEO는 2025 년 3 월 OpenAI가 제품 (Chatgpt의 데스크탑 앱 포함)에서 MCP 지원을 추가 할 것이라고 공개적으로 발표했다. 이는 OpenAI의 에이전트 API 및 ChatGpt 플러그인이 MCP를 사용하여 상호 운용성을 보장한다는 의미입니다. 몇 주 후, ** Google Deepmind의 CEO 인 Demis Hassabis **는 Google의 다가오는 Gemini 모델과 도구가 MCP를 지원하여이를“AI 에이전트 시대”에 대한 훌륭한 프로토콜과 개방형 표준이라고 불렀습니다. ** Microsoft ** 스티어링위원회에 합류했을뿐만 아니라 Anthropic과 파트너 관계를 맺고 MCP가 Enterprise Developer Community에 서비스를 제공하기위한 공식 C# SDK를 구축했습니다. Microsoft의 Github 장치는 MCP를 ** Github Copilot (VS Code의 'Copilot Labs/Agent'모드)에 통합하여 Copilot이 저장소 검색 및 실행 테스트 케이스와 같은 제품에 MCP 서버를 사용할 수있게했습니다. 또한 Microsoft는 MCP 서버로서 Windows 11이 특정 OS 기능 (예 : 파일 시스템 액세스)을 노출시켜 AI 에이전트가 운영 체제와 안전하게 상호 작용할 수 있다고 발표했습니다. OpenAI, Microsoft, Google 및 Anthropic 간의 공동 작업 (MCP를 중심으로하는 모든 랠리)은 특별 하며이 표준의 커뮤니티와 경쟁 정신을 강조합니다.

• ** Web3 Developer Community : ** 많은 블록 체인 개발자와 신생 기업이 MCP를 수용했습니다. 몇몇 ** 커뮤니티 중심의 MCP 서버 **는 블록 체인 사용 사례를 제공하기 위해 만들어졌습니다.

• ** ALCHEMY ** (주요 블록 체인 인프라 제공 업체)의 팀은 MCP를 통해 주문형 블록 체인 분석 도구를 제공하는 ** Alchemy MCP 서버 **를 구축했습니다. 이를 통해 자연 언어를 사용하여 연금술의 API를 통해 AI가 역사적 거래, 주소 활동)를 얻을 수 있습니다.

  • 기고자들은 비트 코인 노드 및 번개 결제 네트워크와 상호 작용하기 위해 ** 비트 코인 및 번개 네트워크 MCP 서버 **를 개발하여 AI 에이전트가 비트 코인 블록 데이터를 읽거나 표준 도구를 통해 번개 송장을 만들 수 있습니다. -Crypto Media and Education Group ** Bankless **는 ** Onchain MCP 서버 **를 만들었습니다.
  • ** Rollup.codes ** (이더 리움 레이어 2S의 지식 기반)와 같은 프로젝트는 롤업 생태계 정보 **를위한 ** MCP 서버를 만들었으므로 AI는이 서버를 쿼리하여 롤업에 대한 기술적 질문에 대답 할 수 있습니다.
  • ** 블록 체인 노드 제공 업체 인 Chainstack **는 문서화, EVM 체인 데이터 및 Solana 용 MCP 서버 (이전에 다루는) 제품군을 출시하여 Web3 Builders의 "블록 체인 스테로이드에 AI를 넣는"것으로 명시 적으로 마케팅했습니다.

또한 Web3 중심 커뮤니티가 MCP 주변에서 생겨났습니다. 예를 들어, ** pulsemcp ** 및 ** goose **는 MCP 레지스트리 구축을 돕는 것으로 언급 된 커뮤니티 이니셔티브입니다. 우리는 또한 AI 에이전트 프레임 워크와의 교차 수분을보고 있습니다. Langchain 커뮤니티 통합 어댑터는 모든 MCP 서버가 Langchain 기반 에이전트의 도구로 사용할 수 있도록하고, Hugging Face TGI (Text Generation-Inference)와 같은 오픈 소스 AI 플랫폼이 MCP 호환성을 탐색하고 있습니다. 결과적으로 새로운 MCP 서버가 거의 매일 발표되는 풍부한 생태계로 데이터베이스에서 IoT 장치에 이르기까지 모든 것을 제공합니다.

• ** 채택 규모 : ** 트랙션은 어느 정도 정량화 될 수 있습니다. 2025 년 2 월 - 출시 후 거의 3 개월 후 - ** 1,000 개 이상의 MCP 서버/커넥터 **가 지역 사회에서 구축되었습니다. 이 숫자는 성장하여 산업 전반에 걸쳐 수천 건의 통합을 나타냅니다. Mike Krieger (Anthropic의 최고 제품 책임자)는 2025 년 봄에 MCP가“수천 가지 통합과 성장으로 번성하는 개방형 표준”**이 지적했다. 공식 MCP 레지스트리 (2025 년 9 월 미리보기에서 시작)는 공개적으로 사용 가능한 서버를 카탈로그로 만들어 도구를보다 쉽게 ​​발견 할 수 있습니다. 레지스트리의 Open API를 통해 누구나 "Ethereum"또는 "Notion"을 검색하고 관련 MCP 커넥터를 찾을 수 있습니다. 이것은 새로운 참가자의 장벽을 낮추고 더 많은 성장에 연료를 공급합니다.

• ** 파트너십 : ** 우리는 많은 암시 적 파트너십 (Microsoft 등의 안트로 등)을 다루었습니다. 몇 가지를 더 강조하려면 :

• ** Anthropic & Slack ** : Anthropic은 Slack과 파트너 관계를 맺고 Claude를 MCP를 통해 Slack의 데이터와 통합하여 공식 MCP 서버가있어 AI가 슬랙 메시지 또는 게시물 알림을 검색 할 수있게합니다).

  • ** 클라우드 제공 업체 ** : Amazon (AWS) 및 Google Cloud는 Anthropic과 함께 호스트 Claude와 협력했으며 이러한 환경에서 MCP를 지원할 수 있습니다 (예 : AWS 기반은 엔터프라이즈 데이터를위한 MCP 커넥터를 허용 할 수 있습니다). 인용에 명시 적으로는 아니지만 이러한 클라우드 파트너십은 엔터프라이즈 채택에 중요합니다.
  • ** Academic Collaborations ** : MIT 및 IBM Research Project NAMDA (다음에 논의)는 학계와 산업 간의 파트너십을 나타내며 MCP의 한도를 분산 된 환경에서 추진합니다.
  • ** Github & vs Code ** : 개발자 경험을 향상시키기위한 파트너십 - 예를 들어, VS Code 팀이 MCP에 적극적으로 기여했습니다 (레지스트리 관리자 중 하나는 VS 코드 팀의 것입니다).
  • ** 수많은 신생 기업 ** : 많은 AI 스타트 업 (에이전트 스타트 업, 워크 플로우 자동화 스타트 업)이 휠을 재창조하는 대신 MCP를 구축하고 있습니다. 여기에는“AI를 DAO”또는 자율 경제 요원을 제공하려는 신흥 웹 3 AI 스타트 업이 포함됩니다.

전반적으로 ** MCP 커뮤니티는 다양하고 빠르게 확장됩니다 **. 여기에는 핵심 기술 회사 (표준 및 기본 툴링), Web3 전문가 (블록 체인 지식 및 사용 사례를 가져 오기) 및 독립 개발자 (종종 좋아하는 앱 또는 프로토콜에 대한 커넥터에 기여)가 포함됩니다. 정신은 협력 적입니다. 예를 들어, 타사 MCP 서버에 대한 보안 문제로 인해 모범 사례에 대한 커뮤니티 토론 및 기여 (예 : MCP 서버 용 보안 도구 작업을하는 Stacklok 기고자)가 촉발되었습니다. 커뮤니티의 신속하게 반복 할 수있는 능력 (MCP는 몇 달 안에 여러 사양 업그레이드를 보았으며 스트리밍 응답 및 더 나은 인증과 같은 기능을 추가)는 광범위한 참여에 대한 증거입니다.

Web3 생태계에서 구체적으로 MCP는 “ai + web3” 프로젝트의 미니 에코 시스템을 육성했습니다. 사용하는 것은 단지 프로토콜이 아닙니다. AI 중심 DAO, AI 분석에 의해 보조 된 체인 거버넌스 및 교차 도메인 자동화 (AI를 통해 온쇄 이벤트를 연결)와 같은 새로운 아이디어를 촉진하고 있습니다. 주요 Web3 그림의 존재 - 예를 들어, ** Limechain의 Zhivko Todorov **“MCP는 AI와 Blockchain의 피할 수없는 통합을 나타냅니다. AI와 블록 체인 회사 간의 파트너십 (예 : Anthropic과 Block, 또는 Microsoft의 Azure Cloud 사이의 파트너십은 MCP가 블록 체인 서비스와 함께 배포하기 쉬운 MCP를 쉽게 배포 할 수 있습니다).

MCP가 Web3 개발자 커뮤니티와 AI 개발자 커뮤니티의 첫 번째 진정한 수렴을 불 태웠다 고 말할 수 있습니다. Hackathons 및 Meetups에는 이제 MCP 트랙이 있습니다. 2025 년 중반, ** Openai, Google 및 Anthropic-대부분의 고급 AI 모델을 대표하는 MCP ** 및 다른 한편으로는 ** 주요 블록 체인 인프라 제공 업체 (Alchemy, Chainstack), Crypto Companies (블록 훅 등) 및 소멸 된 프로젝트를 구축하는 McProlized Projects를 대표합니다. 이 양면 네트워크 효과는 MCP가 지속적인 표준이되기에 잘 어울립니다.

6. 로드맵 및 개발 이정표​

MCP의 개발은 빠르게 진행되었습니다. 여기서 우리는 지금까지 ** 주요 이정표를 간략하게 설명하고 로드맵은 공식 출처 및 커뮤니티 업데이트에서 얻은대로 다음과 같습니다.

• ** 2024 년 말- 초기 릴리스 : ** on ** 2024 년 11 월 25 일 **, Anthropic은 공식적으로 MCP를 발표하고 사양 및 초기 SDK를 오픈 소싱했습니다. 이 사양과 함께 공통 도구 (Google Drive, Slack, Github 등)에 대한 소수의 MCP 서버 구현을 출시하고 Claude AI Assistant (Claude Desktop App)에 지원을 추가하여 로컬 MCP 서버에 연결했습니다. 이것은 MCP의 1.0 런칭으로 표시되었습니다. Anthropic의 초기 개념 증명 통합 통합은 Claude가 MCP를 사용하여 파일을 읽거나 자연어로 SQL 데이터베이스를 쿼리하여 개념을 검증하는 방법을 보여주었습니다.
• ** Q1 2025 - 빠른 채택 및 반복 : ** 2025 년 첫 몇 달 동안 MCP는 ** 널리 퍼져있는 산업 채택 **을 보았습니다. ** 2025 년 3 월 **, OpenAi 및 기타 AI 제공 업체는 위에서 설명한대로 지원을 발표했습니다. 이 기간에는 ** Spec Evolution **을 보았습니다 : ** 스트리밍 기능 ** (큰 결과 또는 연속 데이터 스트림을 점진적으로 전송할 수 있도록). 이 업데이트는 2025 년 4 월 C# SDK 뉴스와 함께 기록되었으며, MCP는 이제 청크 응답 또는 실시간 피드 통합과 같은 기능을 지원했습니다. 커뮤니티는 또한 Anthropic의 SDK를 넘어 다양한 언어 (Python, JavaScript 등)로 ** 참조 구현 **을 구축하여 Polyglot 지원을 보장합니다.
• ** Q2 2025 - 생태계 툴링 및 거버넌스 : ** 2025 년 5 월 **에서 Microsoft와 Github가 노력에 합류하면서 거버넌스를 공식화하고 보안을 강화해야했습니다. Build 2025에서 Microsoft는 ** Windows 11 MCP 통합 **에 대한 계획을 공개했으며 ** MCP **의 승인 흐름을 개선하기위한 협업을 자세히 설명했습니다. 동시에 ** MCP 레지스트리 **라는 아이디어가 이용 가능한 서버에 소개되었습니다 (최초 브레인 스토밍은 2025 년 3 월 레지스트리 블로그에 따라 시작되었습니다). “표준 트랙” 프로세스 (SEP - 표준 향상 제안)는 Ethereum의 EIPS 또는 Python의 PEPS와 유사하게 GitHub에서 정연한 방식으로 기여를 관리했습니다. 커뮤니티 전화 및 실무 그룹 (보안, 레지스트리, SDKS)이 소집을 시작했습니다.
• ** 2025 년 중반- 기능 확장 : ** 20125 년 중반까지 로드맵은 몇 가지 주요 개선 사항을 우선시했습니다.
  • ** 비동기식 및 장기 실행 작업 지원 : ** MCP가 연결을 차단하지 않고 긴 작업을 처리 할 수 ​​있도록 계획합니다. 예를 들어, AI가 몇 분이 걸리는 클라우드 작업을 트리거하는 경우 MCP 프로토콜은 결과를 가져 오기 위해 비동기 응답 또는 재 연결을 지원합니다. -** 인증 및 세분화 된 보안 : ** 개발 ** 미세한 승인 ** 민감한 행동을위한 메커니즘. 여기에는 OAUTH 흐름, API 키 및 엔터프라이즈 SSO를 MCP 서버에 통합하여 AI 액세스를 안전하게 관리 할 수 ​​있습니다. 20125 년 중반까지 AI가 강력한 도구를 호출 할 수있는 보안 위험을 감안할 때 MCP 보안에 대한 가이드 및 모범 사례가 진행되었습니다. 예를 들어, AI가 MCP를 통해 사용자의 개인 데이터베이스에 액세스하려는 경우 개방형 엔드 포인트가 아닌 보안 승인 흐름 (사용자 동의서)을 따라야한다는 것입니다.
• ** 검증 및 규정 준수 테스트 : ** 신뢰성의 필요성을 인식하는 커뮤니티의 우선 순위를 정하는 건물 ** 준수 테스트 스위트 ** 및 ** 참조 구현 **. 모든 MCP 클라이언트/서버가 SPEC (자동 테스트를 통해)을 준수하도록함으로써 조각화를 방지하는 것을 목표로했습니다. AI로 전체 MCP 사용을 보여주는 참조 클라이언트 응용 프로그램과 마찬가지로 참조 서버 (원격 배포 및 인증에 대한 모범 사례가있는 예)가 로드맵에있었습니다.
  • ** 멀티 분류 지원 : ** 텍스트를 넘어 MCP를 확장하여 ** 이미지, 오디오, 비디오 데이터 **와 같은 양식을 지원합니다. 예를 들어, AI는 MCP 서버 (예 : 설계 자산 또는 다이어그램)의 이미지를 요청하거나 이미지를 출력 할 수 있습니다. 사양 토론에는 큰 멀티미디어 컨텐츠를 대화식으로 처리하기 위해 * 스트리밍 및 청크 메시지 *에 대한 지원 추가가 포함되었습니다. "MCP 스트리밍"에 대한 초기 작업은 이미 진행 중입니다 (라이브 오디오 피드 또는 연속 센서 데이터와 같은 것들을 지원하기 위해 AI에 대한 연속 센서 데이터).
  • ** Central Registry & Discovery : ** Central ** MCP Registry ** 서버 검색 서비스를 구현하려는 계획은 20125 년 중반에 실행되었습니다. 2025 년 9 월 **까지 공식 MCP 레지스트리는 미리보기에서 시작되었습니다. 이 레지스트리는 공개적으로 사용 가능한 MCP 서버를위한 ** 단일 진실 소스 **를 제공하므로 클라이언트는 이름, 카테고리 또는 기능으로 서버를 찾을 수 있습니다. 본질적으로 AI 도구 용 App Store (Open)와 같습니다. 이 디자인은 공유 API를 통해 상호 운용 가능한 공개 레지스트리 (글로벌 인덱스) 및 개인 지수 (Enterprise-Specific)를 허용합니다. 레지스트리는 또한 품질을 유지하기 위해 커뮤니티 중재 모델을 사용하여 악의적 인 서버를 플래그하거나 유도하기위한 ** 중재 메커니즘 **를 도입했습니다.
• ** 2025 년 후반 - 분산 된 MCP 네트워크를 향해 : ** "공식적인"로드맵 항목은 아니지만 궤적은 더 많은 분권화 및 Web3 Synergy **를 향해 지적합니다.
• 연구원들은 ** 분산 된 발견, 명성 및 인센티브 레이어를 MCP에 추가하는 방법을 적극적으로 탐색하고 있습니다. ** MCP 네트워크 ** (또는 "MCP 엔드 포인트의 시장")의 개념이 배양되고 있습니다. 여기에는 스마트 계약 기반 레지스트리 (따라서 서버 목록에 대한 단일 실패 지점이 없음), 서버/클라이언트가 좋은 동작에 대한 체인 아이덴티티와 스테이크를 보유한 평판 시스템, 그리고 ** 신뢰할 수있는 MCP 노드를 실행할 수있는 토큰 보상 **가 포함될 수 있습니다.
  • ** 2024 년에 시작된 MIT의 NAMDA **는이 방향으로 구체적인 단계입니다. 2025 년까지 NAMDA는 Dynamic Node Discovery, 에이전트 클러스터 간로드 밸런싱 및 블록 체인 기술을 사용한 분산 된 레지스트리와 같은 기능을 포함하여 MCP 기초에 프로토 타입 분산 에이전트 프레임 워크를 구축했습니다. 그들은 심지어 다중 에이전트 협력을위한 실험 토큰 기반 인센티브 및 출처 추적도 가지고 있습니다. NAMDA의 이정표에 따르면 신뢰할 수없는 조정으로 많은 기계를 가로 질러 MCP 에이전트 네트워크를 실행하는 것이 가능하다는 것을 보여줍니다. NAMDA의 개념이 채택되면 MCP가 이러한 아이디어 중 일부를 통합하기 위해 진화하는 것을 볼 수 있습니다 (아마도 옵션 확장 또는 별도의 프로토콜을 통해).
  • ** Enterprise Hardening : ** Enterprise 측에서 2025 년 후반까지 MCP가 주요 엔터프라이즈 소프트웨어 제품에 통합 될 것으로 예상합니다 (Microsoft의 Windows 및 Azure 포함은 한 예입니다). 로드맵에는 MCP 서버를위한 ** SSO 통합 ** 및 강력한 액세스 컨트롤과 같은 엔터프라이즈 친화적 인 기능이 포함되어 있습니다. MCP 레지스트리 및 툴킷의 일반적인 가용성은 MCP를 규모로 배포 할 수 있습니다 (예 : 회사 네트워크 내)는 2025 년 말까지 가능합니다.

지금까지의 주요 ** 개발 이정표를 요약하려면 ** (명확성을위한 타임 라인 형식) :

• ** 2024 년 11 월 : ** MCP 1.0 릴리스 (인류).
• ** 2024 년 12 월 - 2025 년 1 월 : ** 커뮤니티 구축 MCP 서버의 첫 번째 물결; MCP 지원으로 Claude 데스크탑을 출시합니다. 블록, 아폴로 등의 소규모 조종사
• ** 2025 년 2 월 : ** 1000+ 커뮤니티 MCP 커넥터 달성; 인류는 워크샵을 개최합니다 (예 : AI 정상 회담에서 교육 운전).
• ** 2025 년 3 월 : ** OpenAi 발표 지원 (ChatGpt Agents SDK).
• ** 4 월 2025 : ** Google Deepmind는 지원을 발표합니다 (Gemini는 MCP를 지원할 것입니다); Microsoft는 C# SDK의 미리보기를 릴리스합니다.
• ** 2025 년 5 월 : ** 운영위원회 확장 (Microsoft/Github); 2025 데모 (Windows MCP 통합)를 구축하십시오.
• ** 2025 년 6 월 : ** Chainstack은 공공 사용을 위해 Web3 MCP 서버 (EVM/Solana)를 시작합니다.
• ** 2025 년 7 월 : ** MCP 사양 버전 업데이트 (스트리밍, 인증 개선); MCP 사이트에 게시 된 공식 로드맵.
• ** 2025 년 9 월 : ** MCP 레지스트리 (미리보기) 출시; 아마도 MCP는 더 많은 제품에서 일반 가용성을 강타 할 가능성이 높습니다 (일을위한 Claude 등).
• ** 2025 년 후반 (예상) : ** 레지스트리 v1.0 라이브; 보안 베스트 실행 안내서가 출시되었습니다. 분산 된 발견을 통한 초기 실험 (NAMDA 결과).

** Vision Forward **는 MCP가 HTTP 또는 JSON처럼 보편적이고 보이지 않는 것입니다. 이는 많은 앱이 후드 아래에서 사용하는 일반적인 레이어입니다. Web3의 경우 로드맵은 더 깊은 융합을 제안합니다. AI 에이전트가 Web3 (블록 체인)이 정보의 소스 또는 싱크로 사용 할뿐만 아니라 Web3 인프라 자체가 AI 에이전트 (MCP를 통해)를 운영의 일부로 통합하기 시작할 수 있습니다 (예 : DAO는 특정 작업을 관리하기 위해 MCP 호환 AI를 실행할 수 있습니다. 검증 가능성 및 인증과 같은 것들에 대한 로드맵의 강조는 라인을 아래로 내려 놓는다. 이러한 가능성은 AI와 블록 체인 네트워크 사이의 선을 흐리게하며 MCP는 그 수렴의 핵심입니다.

결론적으로 MCP의 개발은 매우 역동적입니다. 그것은 주요 초기 이정표 (출시 1 년 이내에 광범위한 채택 및 표준화)에 도달했으며 ** 보안, 확장 성 및 발견 **을 강조하는 명확한 로드맵으로 빠르게 발전하고 있습니다. 달성 및 계획된 이정표는 MCP가 척도로 강력하게 유지됩니다. 장기 실행 작업, 안전한 권한 및 수천 가지 도구의 깎아 지른 결과와 같은 문제를 해결합니다. 이 순방향 운동량은 MCP가 정적 사양이 아니라 성장하는 표준이라는 것을 나타냅니다. 이러한 요구가 발생할 때 더 많은 Web3 풍향 기능 (서버의 분산 거버넌스, 인센티브 정렬)을 통합 할 가능성이 높습니다. 커뮤니티는 핵심 약속을 주시하면서 새로운 사용 사례 (멀티 모달 AI, IoT 등)에 MCP를 적용 할 준비가되어 있습니다. Web3 시대에 AI **를보다 연결하고, 상황을 인식하고, 사용자를 제외하고 **.

7. 유사한 Web3 프로젝트 또는 프로토콜과 비교​

MCP의 AI와 연결성의 고유 한 혼합 및 연결성은 직접 사과 대 사과에 해당하는 것이 많지 않지만 Web3 및 AI의 교차점 또는 유사한 목표와 다른 프로젝트와 비교하는 것이 밝혀졌습니다.

• ** Singularitynet (AGI/X) **-*분산 AI 시장 :*Singularitynet, 2017 년 Ben Goertzel 박사와 다른 사람들이 출시 한 AI 서비스의 블록 체인 기반 시장입니다. 이를 통해 개발자는 AI 알고리즘을 서비스 및 사용자가 서비스를 소비 할 수 있도록 해당 서비스를 소비 할 수 있습니다. 모두 지불 및 거버넌스에 사용되는 토큰 (AGIX)이 촉진합니다. 본질적으로, Singularitynet은 AI 모델의 ** 공급을 분산 시키려고 노력하고 있습니다. 이것은 근본적으로 MCP와 다릅니다. MCP는 AI 모델을 호스팅하거나 수익하지 않습니다. 대신, 데이터/도구 **에 액세스하기 위해 AI (어디에서나 실행중인 경우)에 대한 ** 표준 인터페이스를 제공합니다. MCP를 사용하여 AI를 SingularityNet에 나열된 서비스에 연결하는 것을 상상할 수는 있지만 SingularityNet 자체는 경제 계층 (AI 서비스를 제공하고 지불 방법)에 중점을 둡니다. 또 다른 주요 차이점 : ** 거버넌스 **-Singularitynet은 플랫폼을 발전시키기 위해 온 체인 거버넌스 (SNEPS (SingularityNet Enhancement Proposals) ** 및 AGIX 토큰 투표를 통해 온 체인 거버넌스를 가지고 있습니다. 대조적으로 MCP의 거버넌스는 토큰이없는 체인과 협력 적입니다. 요약하면, Singularitynet과 MCP는 모두 더 개방 된 AI 생태계를 위해 노력하지만 Singularitynet은 ** 토큰 화 된 AI 알고리즘 네트워크 **에 관한 반면 MCP는 AI-Tool Interoperability **에 대한 ** 프로토콜 표준에 관한 것입니다. 예를 들어, SingularityNet의 AI는 MCP를 사용하여 필요한 외부 데이터를 가져올 수 있습니다. 그러나 Singularitynet은 도구 사용을 표준화하려고 시도하지 않습니다. 블록 체인을 사용하여 AI 서비스를 조정하는 반면 MCP는 소프트웨어 표준을 사용하여 AI가 모든 서비스와 함께 작동하도록합니다.
• ** fetch.ai (FET) **-에이전트 기반 분산 플랫폼 :fetch.ai는 AI 및 블록 체인을 혼합하는 또 다른 프로젝트입니다. 작업을 수행하고 분산 된 네트워크에서 상호 작용하는 자율 에이전트 **를 구축하기위한 자체 스테이크 블록 체인 및 프레임 워크를 시작했습니다. Fetch의 비전에서 수백만의 "소프트웨어 에이전트"(사람, 장치 또는 조직을 대표)는 거래에 FET 토큰을 사용하여 가치를 협상하고 교환 할 수 있습니다. Fetch.ai는 원장의 에이전트와 통신을위한 에이전트 프레임 워크 (Uagents)와 인프라를 제공합니다. 예를 들어, 페치 에이전트는 주차 및 운송을 위해 다른 에이전트와 상호 작용하여 도시의 트래픽을 최적화하거나 공급망 워크 플로를 자율적으로 관리 할 수 ​​있습니다. 이것은 MCP와 어떻게 비교됩니까? 둘 다 에이전트의 개념을 다루지 만 Fetch.ai의 에이전트는 블록 체인 및 토큰 경제와 밀접한 관련이 있습니다. 이들은 Fetch Network **에 살고 체인 논리를 사용합니다. MCP 에이전트 (AI 호스트)는 모델 중심 (LLM과 같은)이며 단일 네트워크와 관련이 없습니다. MCP는 블록 체인없이 인터넷이나 클라우드 설정 내에서 작동하는 내용입니다. Fetch.ai는 접지에서 새로운 분산 된 AI 경제를 구축하려고 시도하지만 (신뢰 및 거래를위한 자체 원장) MCP는 ** 레이어-공감 **-기존 네트워크 (필요한 경우, 블록 체인 위에 사용될 수 있음)입니다. Fetch는 ** 자율 경제 에이전트 ** 및 MCP ** 스마트 도구 사용 에이전트 **에 관한 것이라고 말할 수 있습니다. 흥미롭게도, 이들은 교차 할 수 있습니다. fetch.ai의 자율 에이전트는 MCP를 사용하여 오프 체인 자원 또는 기타 블록 체인과 인터페이스 할 수 있습니다. 반대로, MCP를 사용하여 다른 블록 체인을 활용하는 다중 에이전트 시스템을 구축 할 수 있습니다 (하나만이 아닙니다). 실제로 MCP는 자체 네트워크가 필요하지 않기 때문에 더 빠른 채택을 보았습니다. 이는 이더 리움, Solana, Web2 API 등과 함께 작동합니다. Fetch.ai의 접근 방식은 더 헤비급이어서 참가자가 사용하려면 참여 해야하는 전체 생태계를 만듭니다. 요약하면, ** fetch.ai vs mcp ** : Fetch는 AI 에이전트를위한 자체 토큰/블록 체인이있는플랫폼이며, 상호 운용성 및 에이전트 간의 경제 교환에 중점을 두는 반면, MCP는 AI 에이전트 (모든 환경에서)가 도구 및 데이터에 연결하는 데 사용할 수있는프로토콜입니다. 그들의 목표는 AI 구동 자동화를 가능하게하는 데 겹치지 만, 스택의 다른 층을 다루고 매우 다른 건축 철학을 가지고 있습니다 (폐쇄 생태계 대 공개 표준).
• ** 체인 링크 및 분산 된 oracles -블록 체인 연결 오프 체인 데이터에 연결 :ChainLink는 AI 프로젝트가 아니지만 Web3 프로토콜과 매우 관련이 있습니다. ChainLink는 신뢰 모방 된 방식으로 스마트 계약에 오프 ​​체인 데이터를 가져오고 확인하고 전달하는 분산 된 노드 (Oracles) 네트워크입니다. 예를 들어, ChainLink Oracles는 ChainLink 기능을 통해 스마트 계약을 대신하여 Defi 프로토콜 또는 외부 API를 호출하는 가격 피드를 제공합니다. 이에 비해 MCP는 ** AI 모델 **을 외부 데이터/도구 (일부 블록 체인 일 수 있음)에 연결합니다. ** ChainLink는 데이터를 블록 체인으로 가져 오는 반면 MCP는 데이터를 AI **로 가져옵니다. 개념적 평행이 있습니다. 둘 다 미사 시스템 사이에 브리지를 설정합니다. ChainLink는 데이터를 공급하는 데이터의 신뢰성, 탈 중앙화 및 보안에 중점을 둡니다 (단일 고장 지점의 "Oracle 문제"). MCP는 AI가 데이터에 액세스 할 수있는 방법의 유연성과 표준화에 중점을 둡니다 (AI 에이전트의 "통합 문제 해결"). 그들은 다른 도메인 (Smart Contracts vs AI Assistant)에서 작동하지만 MCP 서버를 Oracles와 비교할 수 있습니다. 가격 데이터를위한 MCP 서버는 동일한 API를 체인 링크 노드로 호출 할 수 있습니다. 차이점은 ** 소비자 **-MCP의 경우 소비자는 결정 론적 스마트 계약이 아니라 AI 또는 사용자를 향한 보조원입니다. 또한 MCP는 본질적으로 체인 링크가 수행한다는 신뢰 보증을 제공하지 않습니다 (MCP 서버는 애플리케이션 수준에서 신뢰를 관리하면서 MCP 서버가 중앙 집중화되거나 커뮤니티 운영 될 수 있음). 그러나 앞에서 언급했듯이 MCP 네트워크를 분산시키는 아이디어는 Oracle Networks에서 빌릴 수 있습니다. 예를 들어, 여러 MCP 서버를 쿼리하고 결과를 교차 확인하여 AI가 잘못된 데이터를 공급받지 않도록하여 여러 체인 링크 노드가 가격을 집계하는 방식과 유사합니다. 요컨대, ** ChainLink vs MCP ** : ChainLink는Web3 Middleware입니다. 블록 체인은 외부 데이터를 소비 할 수있는 블록 체인을위한 Web3 Middleware입니다. MCP는*AI Middleware입니다 (블록 체인 데이터를 포함 할 수 있음). 그들은 다른 영역에서 유사한 요구를 해결하고 보완 할 수도 있습니다. MCP를 사용하는 AI는 체인 링크 제공 데이터 피드를 신뢰할 수있는 리소스로 가져올 수 있으며, AI는 체인 링크 Oracle이 체인을 묶는 분석 소스 역할을 할 수 있습니다 (후자 시나리오는 검증 가능성에 대한 질문을 제기 할 수 있습니다).
• ** ChatGpt 플러그인 / OpenAi 기능 대 MCP ** -*AI 도구 통합 접근 방식 :*Web3 프로젝트가 아니지만 ChatGpt 플러그인 및 OpenAi의 기능 호출 기능도 외부 도구에 연결하기 때문에 빠른 비교가 필요합니다. ChatGpt 플러그인은 서비스가 제공하는 OpenAPI 사양을 사용하며 모델은 사양에 따라 해당 API를 호출 할 수 있습니다. 제한 사항은 폐쇄 된 생태계 (OpenAI 서버에서 실행되는 OpenAI 승인 플러그인)이며 각 플러그인은 사일드 통합입니다. OpenAi의 새로운 * "에이전트" * SDK는 개념적으로 MCP에 더 가깝기 때문에 개발자는 AI가 사용할 수있는 도구/기능을 정의 할 수 있지만 처음에는 OpenAI의 생태계에 따라 다릅니다. ** Langchain ** 마찬가지로 LLMS 도구를 코드로 제공하는 프레임 워크를 제공했습니다. MCP는 ** 개방형 모델 공유 표준 **를 제공함으로써 다릅니다. 한 가지 분석이 말하면 Langchain은 도구 용 개발자를 향한 표준 (Python 인터페이스)을 만들었고 MCP는 * 모델을 향한 표준 *을 생성합니다-AI 에이전트는 사용자 지정 코드없이 런타임에서 MCP 정의 도구를 검색하고 사용할 수 있습니다. 실질적으로, MCP의 서버 생태계는 몇 달 안에 Chatgpt 플러그인 저장소보다 더 크고 다양 해졌습니다. 그리고 각 모델이 자체 플러그인 형식을 갖는 대신 (OpenAi는 자신의 플러그인 형식을 가졌고, 다른 모델은 다른 것을 가지고 있음) 많은 사람들이 MCP 주위에 합쳐지고 있습니다. OpenAI 자체는 MCP에 대한 지원을 신호하며 본질적으로 기능 접근법을 더 넓은 표준과 정렬했습니다. 따라서 ** OpenAI 플러그인을 MCP **와 비교하는 것은 큐 레이트 된 중앙 집중식 접근 방식이며 MCP는 분산 된 커뮤니티 중심의 접근 방식입니다. Web3 사고 방식에서 MCP는 "오픈 소스 및 허가없는"반면 독점 플러그인 생태계는 더 닫힙니다. 이로 인해 블록 체인이 아니더라도 MCP는 Web3의 정신과 유사하게 만듭니다. 상호 운용성 및 사용자 제어를 가능하게합니다 (모든 AI 제공 업체에 제공하는 대신 데이터 용 MCP 서버를 실행할 수 있음). 이 비교는 많은 사람들이 MCP를 장기적인 잠재력을 가진 것으로 간주하는 이유를 보여줍니다. 하나의 공급 업체 나 하나의 모델에 잠겨 있지 않습니다.
• ** 프로젝트 NAMDA 및 분산 된 에이전트 프레임 워크 : ** NAMDA는 MCP를 Web3 개념과 명시 적으로 결합하기 때문에 별도의 메모가 필요합니다. 앞에서 설명한 바와 같이, NAMDA (Networked Agent Modular Distributed Architection)는 2024 년 MIT/IBM 이니셔티브로 MCP를 통신 계층으로 사용하여 MCP를 사용하여 AI 에이전트의 ** 분산 된 분산 네트워크를 구축하기 위해 시작된 MIT/IBM 이니셔티브입니다. MCP를 메시징 백본으로 취급합니다 (MCP는 표준 JSON-RPC와 유사한 메시지를 사용하므로 Agent 간 통신에 적합) 한 다음 Blockchain에서 영감을받은 기술을 사용하여 ** 동적 발견, 결함 공차 및 검증 가능한 ID **에 대한 레이어를 추가합니다. NAMDA의 에이전트는 어디서나 (클라우드, 에지 장치 등) 일 수 있지만 분산 된 레지스트리 (DHT 또는 블록 체인과 비슷한)는 변조 방지 방식으로 이와 기능을 추적합니다. 그들은 심지어 협력이나 자원 공유를 장려하기 위해 에이전트 토큰을 탐구합니다. 본질적으로, NAMDA는 ** "Web3 버전의 MCP"**의 실험입니다. 아직 널리 배포 된 프로젝트는 아니지만 정신에서 가장 가까운“유사한 프로토콜”중 하나입니다. NAMDA vs MCP를 보면 NAMDA는 MCP를 사용하므로 경쟁 표준이 아닙니다. 그러나 신뢰 대기 방식으로 여러 에이전트를 네트워킹하고 조정하는 프로토콜로 확장합니다. 암호화 커뮤니티가 본 ** Autonolas 또는 MAS (Multi-Agent Systems)와 같은 프레임 워크와 NAMDA를 비교할 수는 있지만 강력한 AI 구성 요소 나 일반적인 프로토콜이 부족했습니다. NAMDA + MCP는 함께 분산 된 에이전트 네트워크가 어떻게 작동 할 수 있는지, ** 신원, 명성 및 토큰 인센티브 ** 및 ** 에이전트 커뮤니케이션 및 도구 사용 **을 제공하는 블록 체인을 제공합니다.

요약하면, ** MCP는 대부분의 이전 Web3 프로젝트와는 별다른 곳입니다. Crypto 프로젝트로 시작하지는 않았지만 보완적인 문제를 해결하기 때문에 Web3과 빠르게 교차합니다. Singularitynet 및 Fetch.ai와 같은 프로젝트는 블록 체인을 사용하여 AI 컴퓨팅 또는 서비스를 분산시키는 것을 목표로했습니다. 대신 MCP는 AI와의 AI 통합을 표준화하여 플랫폼 잠금을 피함으로써 분산을 향상시킬 수 있습니다. 체인 링크와 같은 Oracle 네트워크는 블록 체인으로 데이터 전달을 해결했습니다. MCP는 AI (블록 체인 데이터 포함)로 데이터 전달을 해결합니다. Web3의 핵심 이상이 분산, 상호 운용성 및 사용자 권한 부여라면 MCP는 AI 영역에서 상호 운용성 부분을 공격하고 있습니다. 예를 들어,이 오래된 프로젝트에도 영향을 미치고 있습니다. 예를 들어, Singularitynet이 MCP 서버를 통해 AI 서비스를 제공하지 못하거나 에이전트가 MCP를 사용하여 외부 시스템과 대화하는 것을 막는 것이 아무것도 없습니다. 토큰 중심의 AI 네트워크가 MCP를 링구아 프랑카 *로 사용하여 MCP의 유연성으로 Web3의 인센티브 구조와 결혼하는 수렴이 잘 보입니다.

마지막으로, 우리가 ** 시장 인식 **을 고려한다면 : MCP는 종종 Web3가 인터넷을 위해하고자하는 일을 AI에 대해 선전합니다 - Silos와 사용자에게 권한을 부여합니다. 이로 인해 일부는 비공식적으로 "AI 용 Web3"(블록 체인이 관련이 없더라도)로 비공식적으로 별명을 불러 일으켰습니다. 그러나 MCP는 프로토콜 표준임을 인식하는 것이 중요하지만 대부분의 Web3 프로젝트는 경제 계층이있는 풀 스택 플랫폼입니다. 이에 비해 MCP는 일반적으로보다 가볍고 보편적 인 솔루션으로 나오는 반면 블록 체인 프로젝트는 더 무겁고 전문화 된 솔루션입니다. 사용 사례에 따라 엄격하게 경쟁하기보다는 보완 할 수 있습니다. 생태계가 성숙함에 따라, 우리는 MCP가 많은 Web3 프로젝트에 모듈 (HTTP 또는 JSON의 유비쿼터스 방식과 마찬가지로)으로 통합 될 수 있습니다.

8. 대중의 인식, 시장 견인 및 미디어 보도​

MCP에 대한 대중의 감정은 AI와 Web3 커뮤니티 모두에서 압도적으로 긍정적이었으며, 종종 열정에 국경적입니다. 많은 사람들은 그것을 조용히 도착했지만 산업을 폭풍으로 가져간 ** 게임 체인저 **로 본다. 인식, 견인 및 주목할만한 미디어 이야기를 세분화합시다.

** 시장 견인 및 채택 메트릭 : ** 20125 년 중반에 MCP는 새로운 프로토콜을 위해 드문 수준을 달성했습니다. 사실상 모든 주요 AI 모델 제공 업체 (Anthropic, OpenAi, Google, Meta)가 뒷받침하고 앞에서 설명한대로 Big Tech 인프라 (Microsoft, Github, AWS 등)가 지원합니다. 이 단독만으로는 MCP가 여기에있을 가능성이 높다는 신호입니다 (광범위한 백업이 인터넷 초기에 TCP/IP 또는 HTTP를 추진 한 방법과 유사합니다). Web3 측면에서 *트랙션은 개발자 동작에서 분명합니다. *: Hackathons는 MCP 프로젝트를 특징으로하기 시작했으며 많은 블록 체인 개발 도구는 이제 MCP 통합을 판매 지점으로 언급했습니다. “몇 달 만에 1000 개 이상의 커넥터”와 Mike Krieger의“수천 개의 통합”인용문은 종종 MCP가 얼마나 빠르게 잡힌지를 설명하기 위해 인용됩니다. 이것은 강력한 네트워크 효과를 제안합니다. VCS와 애널리스트들은 MCP가 1 년 안에 초기“AI 상호 운용성”시도가 몇 년에 걸쳐 타이밍 (AI 에이전트에 대한 관심의 물결을 타기)과 오픈 소스로 인해 발생하지 않았다고 언급했다. Web3 Media에서 트랙션은 때때로 개발자 마인드 쉐어 및 프로젝트 통합 측면에서 측정되며 MCP는 현재 두 점수로 높아집니다.

** AI 및 Web3 커뮤니티의 대중의 인식 : ** 처음에 MCP는 처음 발표되었을 때 레이더 아래로 날아 갔다 (2024 년 후반). 그러나 2025 년 초, 성공 사례가 등장함에 따라 인식은 흥분으로 바뀌었다. AI 실무자들은 MCP를 AI 요원을 장난감 예제보다 진정으로 유용하게 만들기위한“누락 된 퍼즐 조각”으로 보았습니다. 반면에 Web3 Builders는 그것을 분산화를 버리지 않고 AI를 DAPP에 마침내 통합하는 다리로 보았습니다. ** 사고 지도자 *는 칭찬을 노래하고 있습니다. 예를 들어, 예수 로드리게스 (예수 로드리게스) (저명한 웹 3 AI 작가)는 Coindesk에서 MCP가“AI 시대에 가장 혁신적인 프로토콜 중 하나이며 Web3 Architectures에 큰 적합한 것”*라고 썼습니다. 주목할만한 캐피탈 블로그의 Rares Crisan은 MCP가 인터넷을보다 사용자 중심적이고 자연스럽게 만들어서 블록 체인만이 어려움을 겪는 Web3의 약속을 전달할 수 있다고 주장했다. 이 이야기는 MCP를 혁명적이지만 실용적이라고 생각합니다.

공정하게 말하면, ** 모든 논평이 비판적 이는 것은 아닙니다. **. Reddit과 같은 포럼의 일부 AI 개발자는 MCP가“모든 것을 수행하지는 않는다”고 지적했습니다. 이는 상자 외의 에이전트 나 추론 엔진이 아닌 커뮤니케이션 프로토콜입니다. 예를 들어, "MCP는 막 다른 트랩"이라는 제목의 Reddit 토론이 MCP 자체가 에이전트인지를 관리하지 않거나 품질을 보장하지 않는다고 주장했습니다. 여전히 우수한 에이전트 설계 및 안전 제어가 필요합니다. 이 견해는 MCP가은 총알로 과장 될 수 있음을 시사합니다. 그러나 이러한 비판은 MCP의 유용성을 거부하는 것보다 기대를 완화시키는 것입니다. 그들은 MCP가 도구 연결을 해결하지만 여전히 강력한 에이전트 로직을 구축해야한다는 점을 강조합니다 (즉, MCP는 지능형 에이전트를 마술처럼 생성하지 않으며 도구를 사용합니다). ** 컨센서스는 MCP가 신중한 목소리 중에서도 큰 발전 **이라는 것입니다. Hugging Face의 커뮤니티 블로그는 MCP가 해결책이 아니지만 통합, 상황을 인식하는 AI의 주요 인 에이 블러이며 개발자가 그 이유 때문에 그 주위를 모으고 있다고 지적했습니다.

** 미디어 커버리지 : ** MCP는 주류 기술 미디어 및 틈새 블록 체인 미디어에서 상당한 커버리지를 받았습니다.

• ** TechCrunch **는 여러 이야기를 실행했습니다. 그들은 2024 년에 출시 된 초기 개념 (“의인화 제안 데이터를 AI 챗봇에 연결하는 새로운 방법”)을 다루었습니다. 2025 년 TechCrunch는 각각의 큰 채택 순간을 강조했습니다 : Openai의 지원, Google의 포옹, Microsoft/Github의 참여. 이 기사들은 종종 MCP 주변의 산업 단결을 강조합니다. 예를 들어, TechCrunch는 Sam Altman의 승인을 인용하고 경쟁 표준에서 MCP로 빠른 전환을 언급했습니다. 그렇게함으로써, 그들은 MCP를 90 년대에 인터넷 프로토콜에서 벗어나기를 원하지 않는 방법과 비슷한 새로운 표준으로 묘사했습니다. 저명한 아울렛의 이러한 보도는 광범위한 기술 세계에 MCP가 프린지 오픈 소스 프로젝트가 아니라 중요하고 실제적이라는 신호를 보냈습니다.
• ** Coindesk ** 및 기타 암호화 간행물이 ** web3 각도 **에 걸렸습니다. 로드리게스 (Rodriguez) (2025 년 7 월)의 코인 데스크의 의견은 종종 인용됩니다. 모든 블록 체인이 MCP 서버가 될 수 있고 새로운 MCP 네트워크가 블록 체인에서 실행될 수있는 미래의 그림을 그렸습니다. 그것은 MCP를 분산화 된 정체성, 인증 및 검증과 같은 개념에 연결했습니다 - 블록 체인 잠재 고객의 언어를 말하고 MCP가 분산 된 프레임 워크로 AI를 진정으로 녹일 수있는 프로토콜이 될 수 있습니다. Cointelegraph, Bankless 등은 "AI 에이전트 및 Defi"및 유사한 주제와 관련하여 MCP를 논의했습니다. 일반적으로 가능성에 대한 낙관적입니다 (예 : Bankless는 AI가 ON 체인 거래를 관리하고 자체 MCP 서버를위한 How-to를 포함시킬 수 있도록 MCP를 사용했습니다.
• ** 주목할만한 VC 블로그 / 분석가 보고서 : ** 주목할만한 자본 블로그 게시물 (2025 년 7 월)은 MCP와 웹 프로토콜의 진화 사이의 유사점을 그리는 벤처 분석의 예입니다. 본질적으로 MCP는 Web3에 대해 Web1에 대해 할 수 있다고 주장합니다. Web1에 대해 HTTP가 한 일 - 기본 인프라를 대체하지는 않지만 사용할 수있는 새로운 인터페이스 계층 (자연 언어 인터페이스)을 제공합니다. 이런 종류의 이야기는 설득력이 있으며 패널과 팟 캐스트에서 반향되었습니다. MCP는 블록 체인과 경쟁하는 것이 아니라 다음의 추상화 계층으로서 정상적인 사용자 (AI를 통해)가 블록 체인 및 웹 서비스를 쉽게 활용할 수있게합니다.
• ** 개발자 커뮤니티 버즈 : ** 공식적인 기사 외부에서 MCP의 Rise는 개발자 담론 - 회의 대화, YouTube 채널, 뉴스 레터에 존재함으로써 얻을 수 있습니다. 예를 들어,“MCP : Agentic AI의 누락 된 링크?”와 같은 인기있는 블로그 게시물이 있습니다. Runtime.news 및 뉴스 레터 (예 : AI 연구원 Nathan Lambert)와 같은 사이트에서 MCP와의 실제 실험 및 기타 공구 사용 프레임 워크와의 비교 방법에 대해 논의합니다. 일반적인 톤은 호기심과 흥분입니다. 개발자는 AI를 홈 자동화 또는 암호화 지갑에 연결하는 데모를 공유합니다. 이 풀뿌리 흥분은 MCP가 기업 승인을 넘어서 마인드 샤인을 가지고 있기 때문에 중요합니다.
• ** 엔터프라이즈 관점 : ** Enterprise AI에 중점을 둔 미디어 및 분석가들도 MCP를 주요 개발로 기록합니다. 예를 들어, * 새 스택 *은 엔터프라이즈 사용을 위해 Claude의 원격 MCP 서버에 대한 인류가 추가 된 방법을 다루었습니다. 여기서 각도는 기업이 MCP를 사용하여 내부 지식 기반과 시스템을 AI에 안전하게 연결할 수 있다는 것입니다. 많은 블록 체인 회사가 기업 자체이며 내부적으로 MCP를 활용할 수 있기 때문에 Web3에도 중요합니다 (예 : 암호화 교환은 MCP를 사용하여 AI가 사기 탐지를 위해 내부 트랜잭션 로그를 분석 할 수 있습니다).

** 주목할만한 인용문 및 반응 : ** 일부는 대중의 인식을 캡슐화하는 것으로 강조 할 가치가 있습니다.

• *“HTTP 혁명 웹 통신과 마찬가지로 MCP는 단편화 된 통합을 단일 프로토콜로 대체하는 범용 프레임 워크를 제공합니다.” * - Coindesk. 이 HTTP와의 비교는 강력합니다. MCP를 인프라 수준 혁신으로 프레임합니다.
• *“MCP는 수천 개의 통합과 성장으로 번성하는 개방형 표준이되었습니다. LLM은 이미 가지고있는 데이터에 연결할 때 가장 유용합니다 ...” * - Mike Krieger (Mike Krieger) (Anthropic). 이것은 소셜 미디어에서 널리 공유 된 트랙션과 핵심 가치 제안에 대한 공식적인 확인입니다.
• *“Web3의 약속 ... 마침내 자연 언어와 AI 요원을 통해 실현 될 수 있습니다. 이 대담한 진술은 암호화의 느린 UX 개선으로 인해 좌절 된 사람들과 공명합니다. AI는 복잡성을 추상화하여 주류 채택 코드를 깨뜨릴 수 있음을 시사합니다.

** 도전과 회의론 : ** 열정이 높지만 미디어는 도전에 대해 논의했습니다.

• ** 보안 문제 : ** 새로운 스택 또는 보안 블로그와 같은 아울렛은 AI가 도구를 실행할 수있게하는 것이 샌드 박스가 아닌 경우 위험 할 수 있다고 생각했습니다. 악의적 인 MCP 서버가 AI가 유해한 행동을 수행하려고 시도하면 어떻게됩니까? Limechain 블로그는 커뮤니티 개발 된 MCP 서버 (예 : 개인 키를 처리하는 서버는 매우 안전해야 함)와 함께 * "중요한 보안 위험" 에 대해 명시 적으로 경고합니다. 이러한 우려는 토론에서 반영되었습니다. 본질적으로 MCP는 AI의 기능을 확장하지만 전력으로 위험이 발생합니다. 커뮤니티의 반응 (가이드, 인증 메커니즘)도 다루어졌으며 일반적으로 완화가 구축되고 있음을 안심시킵니다. 그럼에도 불구하고, MCP의 유명한 오용 (예 : 의도하지 않은 암호 전송을 유발 한 AI)은 인식에 영향을 미칠 것이므로 미디어는이 전선에서 조심 스럽습니다. -* 성능 및 비용 : ** 일부 분석가는 도구를 사용하여 AI 에이전트를 사용하는 것이 API를 직접 호출하는 것보다 느리거나 비용이 많이들 수 있다고 지적합니다 (AI는 필요한 것을 얻기 위해 여러 단계가 필요할 수 있기 때문입니다). 고주파 거래 또는 체인 실행 컨텍스트에서는 대기 시간이 문제가 될 수 있습니다. 현재로서는 거래 차단기보다는 더 나은 에이전트 설계 또는 스트리밍을 통해 최적화하기위한 기술적 장애물로 간주됩니다.
• ** Hype Management : ** 모든 트렌드 기술과 마찬가지로 약간의 과대 광고가 있습니다. 몇 가지 목소리는 MCP를 모든 것에 대한 솔루션을 선언하지 않도록주의합니다. 예를 들어, Hugging Face 기사는“MCP가은 총알입니까?”라고 묻습니다. 그리고 답변 - 개발자는 여전히 컨텍스트 관리를 처리해야하며 MCP는 좋은 프롬프트 및 메모리 전략과 함께 가장 잘 작동합니다. 그러한 균형 잡힌 테이크는 담론에서 건강합니다.

** 전반적인 미디어 감정 : ** 등장하는 이야기는 크게 희망적이고 미래 지향적입니다.

-MCP는 현재 실질적인 개선 사항을 제공하는 실용적인 도구로 여겨지며 (증기가 아닌), 미디어는 작업 예를 인용하여 미디어를 강조합니다 : 클로드 읽기 파일, VScode에서 MCP를 사용한 Copilot, 데모에서 Solana 트랜잭션을 완료하는 AI 등

• 또한 AI와 Web3의 미래를위한 전략적 린치 핀으로 묘사되어 있습니다. 미디어는 종종 MCP 또는 같은 것들이 "분산 된 AI"또는 "Web4"또는 차세대 웹에 사용하는 용어에 필수적이라고 결론지었습니다. MCP가 문을 열었고 이제는 NAMDA의 분산 대리인이든 레거시 시스템을 AI에 연결하든, 많은 미래의 스토리 라인이 MCP의 소개로 거슬러 올라가는 혁신이 진행되고 있다는 의미가 있습니다.

시장에서는 MCP 생태계 주변의 스타트 업 및 자금 조달에 의해 트랙션을 측정 할 수 있습니다. 실제로, "MCP 시장"에 중점을 둔 신생 기업에 대한 소문/보고서가 있습니다. 또는 자금을 조달하는 MCP 플랫폼 (이에 대한 자본 작성은 VC 관심을 암시합니다). 우리는 미디어가 접선 적으로 다루기 시작할 것으로 예상 할 수 있습니다. 예를 들어, "시작 X는 MCP를 사용하여 AI가 암호화 포트폴리오를 관리 할 수 ​​있습니다.

** 인식의 결론 : ** 2025 년 후반에 MCP는 기술을 가능하게하는 획기적인 기술로 명성을 얻습니다. 그것은 AI와 암호화 모두에서 영향력있는 인물들로부터 강한 옹호를 가지고 있습니다. 대중의 이야기는 *“여기에 깔끔한 도구가 있습니다” *에서 *“이것은 다음 웹의 기초가 될 수 있습니다” *로 진화했습니다. 한편, 실질적인 적용 범위는 그것이 작동하고 채택되고 있음을 확인하며, 대출 신뢰성을 확인합니다. 커뮤니티가 도전 과제 (보안, 거버넌스 규모)를 계속 해결하고 주요 재난이 발생하지 않으면 MCP의 공개 이미지는 "AI와 Web3가 함께 놀리는 프로토콜"으로 긍정적 인 상태를 유지하거나 상징적이 될 가능성이 높습니다.

미디어는 다음을 계속 주시 할 것입니다.

• 성공 사례 (예 : 주요 DAO가 MCP를 통해 AI 재무를 구현하거나 정부가 Open Data AI 시스템에 MCP를 사용하는 경우).
• 보안 사고 (위험 평가).
• MCP 네트워크의 진화와 토큰 또는 블록 체인 구성 요소가 공식적으로 사진을 입력하는지 여부 (이것은 AI와 암호화를 더욱 단단히 연결하는 큰 뉴스 일 것입니다).

그러나 현재로서는 Coindesk의 한 줄에 의해 적용 범위를 요약 할 수 있습니다. *“Web3와 MCP의 조합은 분산 된 AI의 새로운 기초 일 수 있습니다.” * - 대중의 눈에서 MCP를 둘러싼 약속과 흥분을 모두 포착하는 감정.

** 참조 : **

• 인간 뉴스 : * "모델 컨텍스트 프로토콜 소개" * 11 월 2024 년
• limechain 블로그 : * "MCP는 무엇이며 블록 체인에 어떻게 적용됩니까?" * 2025 년 5 월
• Chainstack 블로그 : * "Web3 Builders 용 MCP : Solana, EVM 및 Documentation," * 2025 년 6 월 -Coindesk op-ed : * "에이전트의 프로토콜 : Web3 's MCP 잠재력", * 7 월 2025 년 7 월
• 주목할만한 자본 : * "MCP가 실제 Web3 기회를 대표하는 이유" * 7 월 2025 년
• TechCrunch : * "Openai는 Anthropic의 표준을 채택합니다…", * 2025 년 3 월 26 일
• TechCrunch : * "Google, Anthropic의 표준을 받아들이는 Google…", * 4 월 9 일, 2025 년 -TechCrunch : * "Github, Microsoft Embrace… (MCP 운영위원회)", * 2025 년 5 월 19 일
• Microsoft Dev 블로그 : * "MCP 용 공식 C# SDK" * 4 월 2025 년 -Hehgging Face 블로그 : * "#14 : MCP 란 무엇이며 왜 모두가 그것에 대해 이야기하고 있습니까?" * 3 월 2025 년
• 메사리 연구 : * "Fetch.ai 프로파일", * 2023
• 중간 (nu fintimes) : * "Singularitynet의 공개", 2024 년 3 월

프라이버시가 공공 인프라가 되고 있습니다. 2025년에 개발자들은 데이터 저장만큼 쉽게 암호화를 수행할 수 있는 도구가 필요합니다. Mysten Labs의 Seal은 바로 그것을 제공합니다—온체인 접근 제어가 있는 탈중앙화 비밀 관리입니다. 이 튜토리얼은 신원 기반 암호화, 임계값 보안, 프로그래밍 가능한 접근 정책을 사용하여 안전한 Web3 애플리케이션을 구축하는 방법을 알려드립니다.

소개: Web3에서 Seal이 중요한 이유​

기존의 클라우드 애플리케이션은 단일 제공업체가 암호화된 데이터에 대한 접근을 제어하는 중앙화된 키 관리 시스템에 의존합니다. 편리하지만, 이는 위험한 단일 장애점을 만듭니다. 제공업체가 손상되거나, 오프라인이 되거나, 접근을 제한하기로 결정하면 데이터에 접근할 수 없거나 취약해집니다.

Seal은 이 패러다임을 완전히 바꿉니다. Sui 블록체인을 위해 Mysten Labs에서 구축한 Seal은 다음을 가능하게 하는 탈중앙화 비밀 관리(DSM) 서비스입니다:

• 신원 기반 암호화 - 콘텐츠가 환경을 떠나기 전에 보호됩니다
• 임계값 암호화 - 키 접근을 여러 독립적인 노드에 분산시킵니다
• 온체인 접근 제어 - 시간 잠금, 토큰 게이팅, 커스텀 인증 로직
• 스토리지 무관 설계 - Walrus, IPFS 또는 모든 스토리지 솔루션과 작동

안전한 메시징 앱, 게이티드 콘텐츠 플랫폼, 시간 잠금 자산 전송을 구축하든, Seal은 필요한 암호화 프리미티브와 접근 제어 인프라를 제공합니다.

시작하기​

전제 조건​

시작하기 전에 다음이 있는지 확인하세요:

• Node.js 18+ 설치
• TypeScript/JavaScript 기본 지식
• 테스트용 Sui 지갑 (Sui Wallet 등)
• 블록체인 개념에 대한 이해

설치​

npm을 통해 Seal SDK를 설치합니다:

npm install @mysten/seal

블록체인 상호작용을 위해 Sui SDK도 필요합니다:

npm install @mysten/sui

프로젝트 설정​

새 프로젝트를 생성하고 초기화합니다:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

간단한 TypeScript 구성을 생성합니다:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

핵심 개념: Seal 작동 방식​

코드를 작성하기 전에 Seal의 아키텍처를 이해해 봅시다:

1. 신원 기반 암호화 (IBE)​

공개 키로 암호화하는 전통적인 암호화와 달리, IBE는 신원(이메일 주소나 Sui 주소 등)으로 암호화할 수 있게 해줍니다. 수신자는 해당 신원을 제어한다는 것을 증명할 수 있을 때만 복호화할 수 있습니다.

2. 임계값 암호화​

단일 키 서버를 신뢰하는 대신, Seal은 t-of-n 임계값 체계를 사용합니다. 5개 중 3개 키 서버를 구성할 수 있으며, 이는 3개 서버가 협력하여 복호화 키를 제공할 수 있지만 2개 이하로는 불가능함을 의미합니다.

3. 온체인 접근 제어​

접근 정책은 Sui 스마트 컨트랙트에 의해 시행됩니다. 키 서버가 복호화 키를 제공하기 전에 요청자가 온체인 정책 요구사항(토큰 소유권, 시간 제약 등)을 충족하는지 확인합니다.

4. 키 서버 네트워크​

분산된 키 서버들이 접근 정책을 검증하고 복호화 키를 생성합니다. 이 서버들은 단일 제어점이 없도록 다른 당사자들에 의해 운영됩니다.

기본 구현: 첫 번째 Seal 애플리케이션​

Sui 블록체인 정책을 통해 민감한 데이터를 암호화하고 접근을 제어하는 간단한 애플리케이션을 구축해 봅시다.

1단계: Seal 클라이언트 초기화​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // 테스트넷용 Sui 클라이언트 초기화
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // 테스트넷 키 서버로 Seal 클라이언트 구성
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 3개 중 2개 임계값
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

2단계: 간단한 암호화/복호화​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // 암호화할 데이터
  const sensitiveData = "이것은 내 비밀 메시지입니다!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // 특정 Sui 주소로 데이터 암호화
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // 선택적: 메타데이터 추가
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('암호화된 데이터:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // 나중에 데이터 복호화 (적절한 인증 필요)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('복호화된 데이터:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('암호화/복호화 실패:', error);
  }
}

basicExample();

Sui 스마트 컨트랙트를 통한 접근 제어​

Seal의 진정한 힘은 프로그래밍 가능한 접근 제어에서 나옵니다. 특정 시간 이후에만 데이터를 복호화할 수 있는 시간 잠금 암호화 예제를 만들어 봅시다.

1단계: 접근 제어 컨트랙트 배포​

먼저 접근 정책을 정의하는 Move 스마트 컨트랙트가 필요합니다:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

2단계: Seal과 통합​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Sui에서 접근 정책 생성
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // 1분 후 잠금 해제
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // 정책 생성을 위한 트랜잭션 실행
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // 당신의 Sui keypair
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // 이제 이 정책으로 암호화
  const sensitiveData = "이것은 1분 후에 잠금 해제됩니다!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('시간 잠금 데이터가 생성되었습니다. 1분 후에 복호화를 시도해보세요.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

실용적인 예제​

예제 1: 보안 메시징 애플리케이션​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // 탈중앙화 스토리지(Walrus)에 암호화된 메시지 저장
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // 스토리지에서 검색
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Seal로 복호화
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Walrus 스토리지와의 통합
    // 이는 암호화된 데이터를 Walrus에 업로드하고
    // 검색을 위한 blob ID를 반환합니다
  }

  private async retrieveFromWalrus(blobId: string) {
    // blob ID를 사용하여 Walrus에서 암호화된 데이터 검색
  }
}

예제 2: 토큰 게이티드 콘텐츠 플랫폼​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // NFT 소유권 정책 생성
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // NFT 접근 요구사항으로 콘텐츠 암호화
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // NFT 보유자를 위한 특별한 수신자
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // 먼저 NFT 소유권 확인
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('접근 거부: 필요한 NFT를 찾을 수 없습니다');
    }

    // 콘텐츠 복호화
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // NFT 소유권을 확인하는 Move 컨트랙트 생성
    // 정책 객체 ID 반환
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // 사용자가 필요한 NFT를 소유하는지 확인
    // NFT 소유권을 위해 Sui 쿼리
  }
}

예제 3: 시간 잠금 자산 전송​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Sui에서 시간 잠금 정책 생성
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // 자산 전송 데이터 암호화
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`자산이 ${new Date(unlockTimestamp)}까지 잠겼습니다`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // 자산 전송 처리
    console.log('자산 전송이 잠금 해제되었습니다:', transferData);

    return transferData;
  } catch (error) {
    console.error('전송이 아직 잠금 해제되지 않았거나 접근이 거부되었습니다:', error);
    throw error;
  }
}

Walrus 탈중앙화 스토리지와의 통합​

Seal은 Sui의 탈중앙화 스토리지 솔루션인 Walrus와 원활하게 작동합니다. 두 가지를 모두 통합하는 방법은 다음과 같습니다:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Seal로 암호화
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // Walrus에 암호화된 데이터 저장
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Seal과 Walrus 정보를 모두 포함하는 참조 반환
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Walrus에서 검색
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Seal로 복호화
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// 사용 예제
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('중요한 문서 내용');
  const recipientAddress = '0x...';

  // 암호화된 상태로 저장
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Blob ID로 저장됨:', result.blobId);

  // 나중에 검색하고 복호화
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('검색된 데이터:', decrypted.toString());
}

임계값 암호화 고급 구성​

프로덕션 애플리케이션의 경우 여러 키 서버와 함께 사용자 정의 임계값 암호화를 구성하고 싶을 것입니다:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // 여러 독립적인 키 서버로 구성
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 5개 중 3개 임계값
    network: 'mainnet',
    // 고급 옵션
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "미션 크리티컬 암호화된 데이터";

  // 높은 보안 보장으로 암호화
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // 최대 보안을 위해 모든 5개 서버 필요
    customThreshold: 5,
    // 중복성 추가
    redundancy: 2,
    accessPolicy: {
      // 다중 인증 요구사항
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

보안 모범 사례​

1. 키 관리​

// src/security-practices.ts

// 좋은 방법: 안전한 키 유도 사용
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 좋은 방법: 키를 안전하게 저장 (환경 변수 예제)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// 나쁜 방법: 키를 하드코딩하지 마세요
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // 이렇게 하지 마세요!
);

2. 접근 정책 검증​

// 암호화 전에 항상 접근 정책 검증
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // 수신자 주소 검증
  if (!isValidSuiAddress(recipient)) {
    throw new Error('유효하지 않은 수신자 주소');
  }

  // 정책이 존재하고 유효한지 확인
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('유효하지 않은 접근 정책');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. 오류 처리 및 대체 방안​

// 견고한 오류 처리
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('접근 거부: 권한을 확인하세요');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // 백업 구성으로 재시도
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('사용 가능한 키 서버가 부족합니다');
    } else {
      throw new Error(`복호화 실패: ${error.message}`);
    }
  }
}

4. 데이터 검증​

// 암호화 전에 데이터 검증
function validateDataForEncryption(data: Buffer): boolean {
  // 크기 제한 확인
  if (data.length > 1024 * 1024) { // 1MB 제한
    throw new Error('암호화하기에 데이터가 너무 큽니다');
  }

  // 민감한 패턴 확인 (선택사항)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('경고: 데이터에 잠재적으로 민감한 패턴이 포함되어 있습니다');
  }

  return true;
}

성능 최적화​

1. 작업 일괄 처리​

// 효율성을 위해 여러 암호화를 일괄 처리
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. 키 서버 응답 캐싱​

// 지연 시간을 줄이기 위해 키 서버 세션 캐시
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Seal 통합 테스트​

단위 테스트​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal 통합', () => {
  it('데이터를 성공적으로 암호화하고 복호화해야 합니다', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('테스트 메시지');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('테스트 메시지');
  });

  it('접근 제어 정책을 시행해야 합니다', async () => {
    // 인증되지 않은 사용자는 복호화할 수 없음을 테스트
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('비밀'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('접근 거부');
  });
});

프로덕션 배포​

환경 구성​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // 보안 설정
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1시간
  retryAttempts: 3
};

모니터링 및 로깅​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] ${recipient}에 대해 데이터 ${encryptionId} 암호화됨`);
    // 모니터링 서비스로 전송
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] 복호화 ${encryptionId}: ${success ? '성공' : '실패'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] 키 서버 ${serverUrl}: ${status}`);
  }
}

리소스 및 다음 단계​

공식 문서​

• Seal 문서: https://seal-docs.wal.app/
• GitHub 저장소: https://github.com/MystenLabs/seal
• Sui 문서: https://docs.sui.io/
• Walrus 문서: https://docs.wal.app/

커뮤니티 및 지원​

• Sui Discord: 커뮤니티 지원을 위한 #seal 채널 참여
• GitHub Issues: 버그 신고 및 기능 요청
• 개발자 포럼: 토론을 위한 Sui 커뮤니티 포럼

탐구할 고급 주제​

1. 커스텀 접근 정책: Move 컨트랙트로 복잡한 인증 로직 구축
2. 크로스 체인 통합: 다른 블록체인 네트워크와 함께 Seal 사용
3. 엔터프라이즈 키 관리: 자체 키 서버 인프라 설정
4. 감사 및 컴플라이언스: 규제 환경을 위한 로깅 및 모니터링 구현

샘플 애플리케이션​

• 보안 채팅 앱: Seal을 사용한 엔드 투 엔드 암호화 메시징
• 문서 관리: 접근 제어가 있는 엔터프라이즈 문서 공유
• 디지털 권한 관리: 사용 정책이 있는 콘텐츠 배포
• 프라이버시 보존 분석: 암호화된 데이터 처리 워크플로우

결론​

Seal은 Web3에서 프라이버시와 암호화를 인프라 수준의 관심사로 만드는 근본적인 변화를 나타냅니다. 신원 기반 암호화, 임계값 보안, 프로그래밍 가능한 접근 제어를 결합하여 개발자들에게 진정으로 안전하고 탈중앙화된 애플리케이션을 구축할 수 있는 강력한 도구를 제공합니다.

Seal로 구축하는 주요 장점은 다음과 같습니다:

• 단일 장애점 없음: 분산된 키 서버가 중앙 권한을 제거
• 프로그래밍 가능한 보안: 스마트 컨트랙트 기반 접근 정책이 유연한 인증 제공
• 개발자 친화적: TypeScript SDK가 기존 Web3 도구와 원활하게 통합
• 스토리지 무관: Walrus, IPFS 또는 모든 스토리지 솔루션과 작동
• 프로덕션 준비: 엔터프라이즈 보안 표준으로 Mysten Labs에서 구축

사용자 데이터 보안, 구독 모델 구현, 복잡한 다자간 애플리케이션 구축 등 무엇을 하든, Seal은 자신감을 가지고 구축하는 데 필요한 암호화 프리미티브와 접근 제어 인프라를 제공합니다.

오늘부터 구축을 시작하고, 프라이버시를 공공 인프라의 기본 부분으로 만드는 개발자들의 성장하는 생태계에 참여하세요.

구축을 시작할 준비가 되셨나요? @mysten/seal을 설치하고 이 튜토리얼의 예제로 실험을 시작하세요. 탈중앙화 웹은 프라이버시와 보안을 우선시하는 애플리케이션을 기다리고 있습니다.

프로토콜을 출시하거나 온체인 제품을 확장하는 일은 더 이상 기술적 도전만이 아닙니다. 규제 당국은 토큰 발행부터 지갑 프라이버시까지 꼼꼼히 살펴보고, 사용자는 소비자 수준의 보호를 기대합니다. 확신을 갖고 개발을 이어 가려면, 복잡한 법률 메모를 프로덕트 의사결정으로 전환하는 체계가 필요합니다. 웹3 법률 실무에서 자주 등장하는 50가지 질문을 토대로, 이 플레이북은 빌더가 즉시 실행에 옮길 수 있는 방향을 제시합니다.

1. 설립과 거버넌스: 개발사, 재단, 커뮤니티를 명확히 분리​

• 맞는 법인 형태를 선택하세요. 급여, IP, 투자자 실사를 감당하려면 전통적인 C-Corp이나 LLC가 여전히 적합합니다. 프로토콜이나 보조금 프로그램을 운영하려면 별도의 비영리나 재단을 두어 인센티브와 거버넌스를 투명하게 유지하세요.
• 모든 관계를 문서화하세요. 지식재산권 양도, 비밀유지계약, 클리프·락업·불량행위자 환수 조항이 포함된 베스팅 일정을 사용합니다. 이사회 승인 기록을 남기고, 토큰 캡테이블을 지분 장부만큼 촘촘히 관리하세요.
• 법인 간 경계를 선명히 하세요. 개발사는 라이선스 아래에서 개발할 수 있지만, 예산·재무정책·의사결정 권한은 자체 정관과 헌장을 갖춘 재단이나 DAO에 두어야 합니다. DAO에 법적 실체가 필요하다면 LLC 등 래퍼를 사용하세요.

2. 토큰과 증권: 유틸리티 중심 설계와 근거 기록​

• 라벨보다 실질이 중요하다고 가정하세요. “거버넌스”“유틸리티”라는 이름만으로는 부족합니다. 사용자가 실제로 작동 중인 네트워크를 소비 목적으로 이용하고, 이익을 약속받지 않아야 합니다. 락업은 투기 억제에 도움이 되지만 안정성이나 시빌 방지 목적을 명확히 기록하세요.
• 접근권과 투자상품을 구분하세요. 액세스 토큰은 서비스 이용권처럼 설계하고, 가격·문서·마케팅이 향후 이익이 아니라 사용권을 강조해야 합니다. 스테이블코인은 준비금과 상환 권리에 따라 결제·전자화폐 규제를 받을 수 있습니다.
• 스테이킹과 수익 기능은 금융상품처럼 다루세요. APR 약속, 풀링, 팀의 노력에 대한 의존은 증권 리스크를 높입니다. 마케팅을 단순하게 유지하고, 리스크 공시를 제공하며, SAFT로 자금을 모집했다면 메인넷 출시까지의 준법 경로를 설계하세요.
• NFT도 증권이 될 수 있습니다. 지분 분할, 수익 공유, 이익 언급은 투자 상품으로 분류될 가능성을 높입니다. 명확한 라이선스와 소비 목적에 초점을 맞춘 NFT가 상대적으로 안전합니다.

3. 자금조달과 판매: 네트워크를 홍보하되, 한탕주의는 피하기​

• 성숙한 수준의 공시를 제공하세요. 목적, 기능, 베스팅, 배분, 양도 제한, 의존 관계, 자금 사용 계획을 판매 문서에 담습니다. 마케팅 문구도 이에 맞추고 “수익 보장”과 같은 표현은 금물입니다.
• 관할 구역의 경계를 존중하세요. 미국 등 고위험 지역에서 규정을 충족하기 어렵다면, 지오펜싱과 자격 확인, 계약상 제한, 판매 후 모니터링을 결합하세요. 토큰 판매는 물론, 에어드롭에서도 KYC/AML이 점점 일반화되고 있습니다.
• 프로모션 리스크를 관리하세요. 인플루언서 캠페인은 협찬 사실을 명확히 밝히고 규정을 준수하는 스크립트를 사용합니다. 거래소 상장이나 마켓메이킹 계약은 서면 합의, 이해상충 검토, 정확한 커뮤니케이션이 필수입니다.

4. AML·세무·IP: 제품 설계 단계부터 통제 장치를 내장​

• 자신의 규제상 역할을 파악하세요. 비수탁 소프트웨어는 AML 의무가 가볍지만, 법정화폐 온·오프램프, 수탁, 중개형 거래를 다루면 송금업자나 VASP 규제를 받습니다. 제재 스크리닝, 보고 절차, 필요 시 트래블룰 대응을 준비하세요.
• 회계상 토큰을 현금처럼 취급하세요. 토큰 유입은 보통 수취 시점의 시가로 소득이 되며, 이후 처분 시 손익이 발생합니다. 임직원·외주 인력에게 주는 토큰 보상은 베스팅 시 과세되는 경우가 많으니, 서면 계약으로 원가를 추적하고 변동성에 대비하세요.
• 지식재산 경계를 존중하세요. NFT와 온체인 콘텐츠에는 명확한 라이선스를 부여하고, 서드파티 오픈소스 조건을 준수하며, 상표를 등록하세요. AI 모델을 학습시킬 경우 데이터 권리를 확인하고 민감 정보를 제거하세요.

5. 프라이버시와 데이터: 수집을 최소화하고 삭제에 대비​

• 지갑 주소도 개인정보로 간주될 수 있습니다. IP, 디바이스 ID, 이메일과 결합되면 식별 가능한 정보가 됩니다. 꼭 필요한 데이터만 수집하고, 가능하면 오프체인에 저장하며, 해시나 토큰화를 활용하세요.
• 삭제 요청에 응답할 수 있도록 설계하세요. 불변 원장이라도 프라이버시 법에서 자유롭지 않습니다. PII는 온체인에 기록하지 말고, 삭제 요청 시 참조를 제거하며, 해시 값이 재식별되지 않도록 링크를 끊으세요.
• 테레메트리에 대한 투명성을 확보하세요. 쿠키 배너, 분석 도구 고지, 옵트아웃 수단은 기본입니다. 심각도, 통지 기한, 연락 창구를 포함한 사고 대응 계획을 문서화하세요.

6. 운영과 리스크: 조기에 감사하고 꾸준히 소통하기​

• 감사하고 공개하세요. 독립적인 스마트컨트랙트 감사, 필요 시 포멀 베리피케이션, 지속적인 버그바운티는 성숙도를 보여 줍니다. 보고서를 공개하고 잔존 리스크를 명확히 설명하세요.
• 명확한 서비스 약관을 마련하세요. 수탁 여부, 이용 자격, 금지 행위, 분쟁 해결, 포크 대응 방식을 명시합니다. 이용약관·프라이버시 정책·제품 동작을 일치시키세요.
• 포크, 보험, 해외 확장을 계획하세요. 지원 체인, 스냅샷 날짜, 마이그레이션 경로를 선택할 권리를 확보합니다. 사이버, 범죄, D&O, 테크 E&O 등 보험을 검토하고, 글로벌 운영 시 현지화된 약관과 수출 통제 검토, EOR/PEO를 통한 고용 구분 관리를 고려하세요.
• 분쟁 대비를 하세요. 중재나 집단소송 포기가 사용자층에 맞는지 미리 판단합니다. 법집행 기관 요청은 로그를 남기고, 법적 절차를 확인하며, 키를 보관하지 않는 등 기술적 한계를 설명하세요.

7. 빌더 실행 체크리스트​

• 우리 팀의 역할을 정의: 소프트웨어 벤더, 커스터디, 브로커 유사 서비스, 결제 중개 중 어느 쪽인지.
• 마케팅은 사실과 기능에 집중하고, 투기적 수익을 암시하는 표현을 피하기.
• 커스터디와 개인정보 수집을 최소화하고, 불가피한 접점은 문서화하기.
• 토큰 배분, 거버넌스 설계, 감사 진행 상황, 리스크 판단을 담은 문서를 최신 상태로 유지하기.
• 초기부터 법률 자문, 컴플라이언스 툴, 감사, 버그바운티, 세무 전문성에 대한 예산을 확보하기.

8. 법률 자문을 제품 속도로 전환하기​

규제는 빌더를 기다려 주지 않습니다. 결과를 바꾸는 힘은 법률적 고려를 백로그 우선순위, 재무 운영, 사용자 커뮤니케이션에 녹여내는 데서 나옵니다. 스프린트 리뷰에 법무를 참여시키고, 사고 대응 훈련을 반복하며, 공시 문구도 UX처럼 지속적으로 개선하세요. 그러면 50가지 FAQ는 장벽이 아니라 프로토콜의 경쟁 우위가 됩니다.

대부분의 앱은 여전히 아이디, 비밀번호, 중앙 집중식 데이터베이스에 아이덴티티를 고정합니다. 이 모델은 취약(침해), 누출(데이터 재판매), 그리고 번거로움(끝없는 KYC 반복)이라는 문제를 안고 있습니다. 분산 식별자(DID), 검증 가능한 증명(VC), 그리고 어태스테이션을 중심으로 떠오르는 새로운 스택은 다른 미래를 제시합니다: 사용자는 자신에 대한 암호학적 증명을 휴대하고, 필요한 것만 공개합니다—그 이상도 이하도 아닙니다.

이 글은 현황을 정리하고 오늘 바로 적용할 수 있는 실용적인 청사진을 제공합니다.

변화: 계정에서 증명으로​

이 새로운 아이덴티티 스택의 핵심은 두 가지 기본 W3C 표준 위에 구축됩니다. 이는 사용자 데이터를 다루는 방식을 근본적으로 바꿉니다.

• 분산 식별자(DIDs): 중앙 레지스트리(예: 도메인 네임 시스템)가 필요 없는 사용자 제어 식별자입니다. DID는 영구적인, 자체 소유 주소와 같습니다. DID는 공개키와 서비스 엔드포인트를 포함한 서명된 “DID 문서”로 해석되어 안전하고 분산된 인증을 가능하게 합니다. v1.0 표준은 2022년 7월 19일에 공식 W3C 권고안이 되었으며, 생태계에 중요한 이정표를 세웠습니다.
• 검증 가능한 증명(VCs): “나이 18세 이상”, “X 대학 학위 보유”, “KYC 통과”와 같은 클레임을 변조 방지 디지털 형식으로 표현합니다. VC Data Model 2.0은 2025년 5월 15일에 W3C 권고안이 되어, 증명의 발행 및 검증 방식에 현대적인 기반을 마련했습니다.

개발자에게 어떤 변화가 있나요? 민감한 개인식별정보(PII)를 데이터베이스에 저장하는 대신, 사용자의 지갑이 제공하는 암호학적 증명을 검증합니다. 선택적 공개(selective disclosure)와 같은 강력한 프리미티브 덕분에, 필요한 특정 정보(예: 특정 국가 거주)만 요청하고 원본 문서는 보지 않을 수 있습니다.

기존 로그인 방식과의 접점​

새로운 세계가 기존 로그인 경험을 포기하도록 요구하지는 않습니다. 오히려 보완합니다.

• 패스키 / WebAuthn: 피싱에 강한 인증 방식입니다. 패스키는 기기 또는 바이오메트릭(예: Face ID, 지문)과 결합된 FIDO 자격증명이며, 주요 브라우저와 운영체제에서 널리 지원됩니다. 앱이나 지갑에 비밀번호 없는 원활한 로그인 경험을 제공합니다.
• Sign-In with Ethereum (SIWE / EIP-4361): 사용자가 블록체인 주소를 제어하고 이를 애플리케이션 세션에 연결함을 증명합니다. 간단한 nonce 기반 서명 메시지를 통해 작동하며, 전통적인 Web2 세션과 Web3 제어 사이의 깔끔한 다리를 만듭니다.

베스트 프랙티스는 두 가지를 함께 사용하는 것입니다: 패스키는 일상적인 로그인에, SIWE는 암호화폐와 연관된 흐름에 적용합니다.

증명 발행 및 검증을 위한 레일​

증명을 유용하게 만들려면 표준화된 발행 및 제시 방법이 필요합니다. OpenID Foundation이 두 가지 핵심 프로토콜을 제공합니다.

• 발행: OpenID for Verifiable Credential Issuance (OID4VCI) – 발행자(정부 기관, KYC 제공자 등)로부터 사용자의 디지털 지갑으로 증명을 가져오는 OAuth 보호 API를 정의합니다. 다양한 증명 형식을 지원하도록 설계되었습니다.
• 제시: OpenID for Verifiable Presentations (OID4VP) – 애플리케이션이 “증명 요청”을 만들고 사용자의 지갑이 응답하는 방식을 표준화합니다. 기존 OAuth 리다이렉트나 최신 브라우저 API를 통해 동작합니다.

구현 시 마주하게 될 주요 증명 형식:

• W3C VC with Data Integrity Suites (JSON‑LD): 보통 BBS+ 암호와 결합돼 강력한 선택적 공개를 지원합니다.
• VC‑JOSE‑COSE 및 SD‑JWT VC (IETF): JWT와 CBOR 기반 생태계에 맞춰 설계됐으며, 역시 선택적 공개 기능을 갖추고 있습니다.

상호운용성은 빠르게 개선되고 있습니다. OpenID4VC High Assurance 프로파일은 기술 옵션을 좁혀 개발자가 벤더 간 통합을 더 쉽게 할 수 있게 돕습니다.

DID 메서드: 올바른 주소 체계 선택​

DID는 단순히 식별자일 뿐이며, “DID 메서드”는 신뢰 근원을 정의합니다. 흔히 쓰이는 두 가지를 지원하는 것이 좋습니다.

• did:web: 도메인에 기반한 DID입니다. 배포가 매우 쉽고, 기존 웹 인프라를 신뢰 근원으로 활용하려는 기업, 발행자, 조직에 최적입니다.
• did:pkh: 블록체인 주소(예: 이더리움 주소)에서 직접 파생되는 DID입니다. 이미 암호화폐 지갑을 보유한 사용자와 온체인 자산을 연결할 때 유용합니다.

원칙: 최소 두 가지 메서드—did:web은 조직용, did:pkh는 개인 사용자용—를 지원하세요. 표준 DID resolver 라이브러리를 사용해 조회하고, 새로운 메서드를 추가하기 전 공식 레지스트리에서 보안·지속성·거버넌스를 검토합니다.

바로 사용할 수 있는 빌딩 블록​

핵심 표준 외에도 아이덴티티 스택을 강화하는 도구들이 있습니다.

• ENS (Ethereum Name Service): 인간 친화적인 이름(yourname.eth)을 블록체인 주소와 DID에 매핑합니다. 사용자 경험을 개선하고 오류를 줄이며 간단한 프로필 레이어를 제공합니다.
• 어태스테이션: “무엇이든지에 대한 검증 가능한 사실”을 온체인·오프체인에 기록할 수 있습니다. 예를 들어 **Ethereum Attestation Service (EAS)**는 퍼블릭 레저에 PII를 저장하지 않으면서 평판·신뢰 그래프를 구축할 수 있는 견고한 기반을 제공합니다.

추적해야 할 규제 흐름​

규제는 장벽이 아니라 가속도입니다. 가장 중요한 발전은 **EU 디지털 아이덴티티 프레임워크(eIDAS 2.0)**이며, 2024년 5월 20일에 EU 2024/1183 규정으로 채택되었습니다. 이는 모든 EU 회원국이 시민에게 무료 **EU 디지털 아이덴티티 지갑(EUDI)**을 제공하도록 의무화합니다. 구현 규정은 2025년 5월 7일에 발표돼, 유럽 전역의 공공·민간 서비스에서 지갑 기반 증명의 채택을 강력히 촉진합니다.

EU 외 지역이라도 EUDI 지갑과 그 기반 프로토콜은 전 세계 사용자 기대치와 지갑 채택을 형성할 것입니다.

2025년 실전 디자인 패턴​

• 패스키 우선, 지갑 선택적: 기본 로그인은 패스키를 사용합니다. 보안·간편·친숙합니다. 사용자가 NFT 민팅·지급 등 암호화폐 연관 행동을 할 때만 SIWE를 도입합니다.
• 문서 대신 증명 요청: 번거로운 문서 업로드를 OID4VP 기반 VC 증명 요청으로 대체합니다. 운전면허증 대신 “18세 이상” 혹은 “거주 국가가 X”와 같은 증명을 요청합니다. BBS+ 또는 SD‑JWT와 같은 선택적 공개를 지원하는 증명을 받아야 합니다.
• 서버에 PII 저장 금지: 사용자가 무언가를 증명하면 어태스테이션이나 단기 검증 결과만 기록하고 원본 증명은 저장하지 않습니다. 온체인 어태스테이션은 “사용자 Y가 발행자 Z로부터 D일에 KYC 통과”와 같은 감사 가능한 기록을 제공하면서 개인 데이터를 보관하지 않습니다.
• did:web 로 조직을 발행자화: 기업·대학·기관은 이미 도메인을 보유하고 있습니다. did:web을 사용해 증명을 서명하도록 하면 기존 웹 거버넌스 모델 아래 키를 관리할 수 있습니다.
• ENS는 이름용, 아이덴티티는 아니다: ENS는 친숙한 핸들과 프로필 포인터 역할을 합니다. UX에는 좋지만 권위 있는 아이덴티티 클레임은 증명·어태스테이션에 두세요.

시작 아키텍처​

현대적인 증명 기반 아이덴티티 시스템 청사진:

• 인증
  • 기본 로그인: 패스키(FIDO/WebAuthn).
  • 암호 연계 세션: Sign‑In with Ethereum(SIWE)으로 지갑 기반 행동을 처리.
• 증명
  • 발행: 선택한 발행자(KYC 제공자, 대학 등)의 OID4VCI 엔드포인트와 통합.
  • 제시: 웹·네이티브 앱에서 OID4VP 증명 요청을 트리거. W3C VC(BBS+)와 SD‑JWT VC 모두 수용 준비.
• 해결·신뢰
  • DID Resolver: 최소 did:web·did:pkh 지원 라이브러리 사용. 스푸핑 방지를 위해 신뢰할 수 있는 발행자 DID 허용 목록 유지.
• 어태스테이션·평판
  • 내구성 기록: 검증 신호가 필요할 때는 원본 클레임 대신 해시·발행자 DID·타임스탬프를 포함한 어태스테이션을 발행.
• 스토리지·프라이버시
  • 미니멀리즘: 서버에 저장하는 PII를 극단적으로 최소화. 모든 데이터를 암호화하고 TTL 정책을 엄격히 적용. 일시적인 증명에 의존하고, 제로-지식·선택적 공개를 적극 활용.

UX 교훈​

• 보이지 않게 시작: 대부분의 사용자는 지갑을 인식하고 싶어 하지 않습니다. 패스키로 로그인 흐름을 매끄럽게 처리하고, 지갑 상호작용은 절대 필요할 때만 노출합니다.
• 점진적 공개: 한 번에 모든 정보를 요구하지 마세요. 사용자의 즉각적인 목표를 해제하는 최소 증명만 요청합니다. 선택적 공개 덕분에 전체 문서를 볼 필요가 없습니다.
• 키 복구는 필수: 단일 디바이스 키에 묶인 증명은 위험합니다. 재발급·다중 디바이스 이식성을 처음부터 설계하세요. 이는 SD‑JWT VC와 클레임 기반 홀더 바인딩이 채택되는 주요 이유입니다.
• 읽기 쉬운 핸들: ENS 이름은 긴 16진수 주소보다 친숙합니다. 오류를 줄이고 컨텍스트를 제공하지만, 실제 권한은 증명과 어태스테이션에 두세요.

다음 분기 로드맵: 실용적인 단계​

• 1~2주차:
  • 기본 로그인 흐름에 패스키 도입.
  • 모든 암호화폐 연관 행동을 SIWE 검증 뒤에 배치.
• 3~6주차:
  • OID4VP 요청을 활용한 간단한 연령·지역 제한 파일럿.
  • 선택적 공개를 지원하는 VC 2.0(BBS+ 또는 SD‑JWT) 수용.
  • “검증 통과” 이벤트에 대해 어태스테이션 생성, PII 로그 대신 사용.
• 7~10주차:
  • 파트너 발행자(예: KYC 제공자)와 did:web 연동 및 DID 허용 목록 구현.
  • 사용자 프로필에 ENS 이름 연결 기능 추가로 주소 UX 개선.
• 11~12주차:
  • 증명·폐기 흐름에 대한 위협 모델링 수행. 만료된 증명·신뢰할 수 없는 발행자 등 일반 오류에 대한 텔레메트리 추가.
  • 프라이버시 정책 공개: 어떤 정보를 왜 요청하는지, 보관 기간, 사용자 감사 방법 명시.

빠르게 변하는 영역 (주시 필요)​

• EU EUDI 지갑 출시: 구현·호환성 테스트가 전 세계 UX와 검증 능력에 큰 영향을 미칩니다.
• OpenID4VC 프로파일: 새로운 프로파일·테스트 스위트 덕분에 발행자·지갑·검증자 간 상호운용성이 지속적으로 향상됩니다.
• 선택적 공개 암호 스위트: BBS+와 SD‑JWT VC용 라이브러리와 개발자 가이드가 급속히 성숙해져 구현 난이도가 낮아지고 있습니다.

구축 원칙​

• 증명하고 저장하지 말 것: 원시 PII 대신 클레임 검증을 기본으로 합니다.
• 기본 상호운용성: 초기부터 여러 증명 형식·DID 메서드를 지원해 스택을 미래 지향적으로 설계합니다.
• 최소·투명: 가장 작은 클레임만 요청하고, 사용자가 무엇을, 왜 확인하는지 명확히 고지합니다.
• 복구는 평범하게: 디바이스 분실·발행자 교체 상황을 대비해 견고한 복구 흐름을 설계하고, 키 바인딩이 너무 경직되지 않도록 합니다.

Fintech, 소셜, 크리에이터 플랫폼을 구축한다면, 이제 증명 우선 아이덴티티는 미래의 선택이 아니라 위험 감소·온보딩 간소화·글로벌 상호운용성을 위한 최단 경로입니다.

퍼블릭 블록체인은 모든 참여자에게 동기화된 감사 가능한 원장을 제공하는 대신, 기본적으로 모든 데이터를 노출합니다. 2025년 9월 3일 Sui 메인넷에서 가동된 Seal은 온체인 정책 로직과 분산형 키 관리 계층을 결합하여, 어떤 페이로드를 누가 복호화할 수 있는지 Web3 빌더가 세밀하게 제어할 수 있도록 합니다.

요약​

• 무엇인가: Seal은 Sui 스마트 컨트랙트가 온체인에서 복호화 정책을 강제하고, 클라이언트는 아이덴티티 기반 암호화(IBE)로 데이터를 암호화한 뒤 임계값 키 서버에 의존해 키를 파생받을 수 있게 해주는 시크릿 관리 네트워크입니다.
• 왜 중요한가: 맞춤형 백엔드나 불투명한 오프체인 스크립트 대신, 프라이버시와 접근 제어를 1급 Move 프리미티브로 다룰 수 있습니다. 암호문은 어디에나 저장할 수 있고(가장 자연스러운 조합은 Walrus) 여전히 읽기 권한을 제어할 수 있습니다.
• 누구에게 필요한가: 토큰 게이팅 콘텐츠, 타임락 공개, 프라이빗 메시징, 정책 인지형 AI 에이전트를 제공하는 팀은 Seal SDK를 연결해 암호 인프라가 아닌 제품 로직에 집중할 수 있습니다.

정책 로직은 Move 안에 존재​

Seal 패키지에는 특정 아이덴티티 문자열에 대해 누가 어떤 조건으로 키를 요청할 수 있는지 정의하는 seal_approve* Move 함수가 포함됩니다. 정책은 NFT 소유, 허용 목록, 타임락, 맞춤 역할 시스템을 조합할 수 있습니다. 사용자가 복호화를 요청하면 키 서버는 Sui 풀노드 상태를 조회해 정책을 평가하고, 체인이 승인한 경우에만 응답합니다.

접근 규칙이 온체인 패키지의 일부이기 때문에 투명하고 감사를 받을 수 있으며, 다른 스마트 컨트랙트 코드와 함께 버전 관리가 가능합니다. 거버넌스 업데이트도 커뮤니티 검토와 온체인 이력을 거치면서 일반적인 Move 업그레이드와 동일하게 배포할 수 있습니다.

임계값 암호화가 키를 관리​

Seal은 애플리케이션이 정의한 아이덴티티에 데이터를 암호화합니다. 개발자가 선택한 독립 키 서버 위원회가 IBE 마스터 비밀을 공유합니다. 정책 검증을 통과하면 각 서버는 요청된 아이덴티티에 대한 키 조각을 파생합니다. t개의 서버가 응답하면 클라이언트는 조각을 결합해 사용할 수 있는 복호 키를 생성합니다.

위원회 구성원(Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One, Mysten의 Enoki 서비스 등)과 임계값을 선택해 가용성과 기밀성 사이의 트레이드오프를 조정할 수 있습니다. 더 높은 가용성이 필요하면 더 큰 위원회와 낮은 임계값을 택하고, 프라이버시 보장을 강화하고 싶다면 더 엄격한 쿼럼과 퍼미션형 제공업체를 선택하세요.

개발자 경험: SDK와 세션 키​

Seal은 암호화/복호화 흐름, 아이덴티티 포맷팅, 배치 처리를 지원하는 TypeScript SDK(npm i @mysten/seal)를 제공합니다. 또한 세션 키를 발급해 애플리케이션이 반복적으로 접근할 때 지갑에 승인 요청이 쏟아지는 일을 막아줍니다. 고급 워크플로에서는 Move 컨트랙트가 전용 모드로 온체인 복호화를 요청해, 에스크로 공개나 MEV 저항 경매 같은 로직을 스마트 컨트랙트에서 직접 실행할 수 있습니다.

Seal은 저장소에 구애받지 않으므로, 검증 가능한 Blob 저장소를 위해 Walrus와 결합하거나, 필요 시 IPFS 또는 중앙화 스토리지와 함께 사용할 수 있습니다. 암호화 경계와 정책 적용은 암호문이 어디에 있든 데이터와 함께 이동합니다.

Seal 설계 시 베스트 프랙티스​

• 가용성 리스크 모델링: 2-of-3, 3-of-5 같은 임계값은 그대로 가동 시간 보장과 연결됩니다. 운영 환경에서는 공급자를 혼합하고, 텔레메트리를 모니터링하며, 중요한 워크플로를 맡기기 전에 SLA를 체결하세요.
• 상태 변동에 주의: 정책 평가는 풀노드의 dry_run 호출에 의존합니다. 빠르게 변하는 카운터나 체크포인트 내 순서에 의존하는 규칙을 피해서 서버 간 승인 불일치를 방지해야 합니다.
• 키 위생 계획: 파생 키는 클라이언트 측에 존재합니다. 로깅을 계측하고 세션 키를 순환시키며, 필요하다면 엔벨로프 암호화(Seal로 큰 페이로드를 암호화하는 대칭 키를 보호)를 도입해 디바이스가 침해되었을 때의 피해 범위를 줄이세요.
• 회전을 위한 설계: 암호문의 위원회 구성은 암호화 시점에 고정됩니다. 공급자를 교체하거나 신뢰 가정을 조정해야 할 경우를 대비해, 새로운 위원회로 데이터를 재암호화하는 업그레이드 경로를 마련해 두세요.

앞으로의 로드맵​

Seal의 로드맵에는 검증자 운영 MPC 서버, DRM 스타일 클라이언트 도구, 포스트 양자 KEM 옵션 등이 포함됩니다. AI 에이전트, 프리미엄 콘텐츠, 규제 데이터 흐름을 탐색 중인 빌더에게 이번 릴리스는 이미 명확한 청사진을 제공합니다. Move에 정책을 작성하고, 다양한 키 위원회를 구성하여 Sui의 신뢰 경계 안에서 사용자 프라이버시를 존중하는 암호화 경험을 전달하세요.

다음 출시에서 Seal 도입을 고려하고 있다면, 먼저 2-of-3 오픈 위원회와 NFT 게이팅 정책을 단순히 프로토타입하고, 애플리케이션의 위험 프로파일에 맞는 공급자 조합과 운영 통제를 향해 반복적으로 다듬어 가는 것이 좋습니다.

요약​

크로스체인 추상화는 체인, 브리지, 지갑의 미로를 개발자와 최종 사용자 모두에게 단일하고 일관된 플랫폼 경험으로 바꿔줍니다. 생태계는 조용히 성숙해 왔습니다: 인텐트 표준, 계정 추상화, 네이티브 스테이블코인 이동성, 그리고 OP Superchain과 Polygon의 AggLayer 같은 네트워크‑레벨 이니셔티브가 “다중 체인, 하나의 경험” 미래를 2025년에 현실화합니다. 기업에게는 실용적인 이점이 있습니다: 통합이 간소화되고, 위험 통제가 강제되며, 운영이 결정론적이고, 규정 준수 준비가 된 감사 가능성을 제공하지만, 단일 체인에 모든 베팅을 할 필요는 없습니다.

기업이 실제로 겪는 문제 (그리고 왜 브리지만으로는 해결되지 않았는가)​

대부분의 기업 팀은 “체인을 선택한다”는 것을 원하지 않습니다. 그들은 결과를 원합니다: 결제 정산, 자산 발행, 거래 청산, 혹은 레코드 업데이트—신뢰성 있게, 감사 가능하게, 예측 가능한 비용으로. 문제는 오늘날 프로덕션 Web3가 되돌릴 수 없을 정도로 멀티체인이라는 점입니다. 지난 18개월만 해도 수백 개의 롤업, 앱체인, L2가 출시되었으며, 각각 고유한 수수료, 최종성 시간, 툴링, 신뢰 가정을 가지고 있습니다.

전통적인 크로스체인 접근 방식은 전송—토큰이나 메시지를 A에서 B로 옮기는 것—을 해결했지만 경험은 해결하지 못했습니다. 팀은 여전히 네트워크별 지갑을 관리하고, 체인별 가스를 프로비저닝하고, 경로별 브리지를 선택하고, 보안 차이를 정량화하기 어려운 상태로 감당해야 합니다. 이 마찰이 실제 채택 비용입니다.

크로스체인 추상화는 체인 선택과 전송을 선언형 API, 인텐트‑드리븐 사용자 경험, 통합된 아이덴티티와 가스 뒤에 숨겨서 이 비용을 없앱니다. 즉, 사용자와 애플리케이션은 무엇을 원하는지 표현하고, 플랫폼이 어디서 어떻게 안전하게 실행할지를 결정합니다. 체인 추상화는 최종 사용자에게 블록체인 기술을 보이지 않게 하면서도 핵심 이점을 유지합니다.

왜 2025년이 다른가: 핵심 블록이 드디어 맞물렸다​

원활한 멀티체인 세계에 대한 비전은 새롭지 않지만, 기반 기술이 이제 프로덕션에 사용할 준비가 되었습니다. 여러 핵심 요소가 성숙하고 수렴하면서 견고한 체인 추상화가 가능해졌습니다.

• 네트워크‑레벨 통합: 프로젝트들은 이제 별도 체인이 하나의 통합 네트워크처럼 느껴지도록 프레임워크를 구축하고 있습니다. OP Superchain은 공유 툴링과 통신 레이어를 갖춘 OP‑Stack L2를 표준화하려 하고, Polygon의 AggLayer는 “비관적 증명”을 사용해 체인‑레벨 회계를 제공함으로써 하나의 체인 문제로 다른 체인이 오염되는 것을 방지합니다. 동시에 IBC v2는 Cosmos 생태계를 넘어 표준화된 상호운용성을 확장해 “IBC everywhere”를 추진하고 있습니다.

• 성숙한 인터옵 레일: 크로스체인 통신을 위한 미들웨어가 이제 전투 검증을 마치고 널리 사용 가능합니다. Chainlink CCIP는 증가하는 체인 수에 걸쳐 엔터프라이즈‑급 토큰·데이터 전송을 제공하고, LayerZero v2는 옴니체인 메시징과 통합 공급량을 가진 표준 OFT 토큰을 지원합니다. Axelar는 복잡한 계약 호출을 위한 General Message Passing (GMP)을 제공해 EVM과 Cosmos 체인을 연결합니다. Hyperlane 같은 플랫폼은 허가 없이 새로운 체인이 네트워크에 합류하도록 허용하고, Wormhole은 40개 이상의 체인에서 사용되는 일반 메시징 레이어를 제공합니다.

• 인텐트·계정 추상화: 두 가지 핵심 표준이 사용자 경험을 혁신했습니다. ERC‑7683은 크로스체인 인텐트를 표준화해 앱이 목표를 선언하고 공유 솔버 네트워크가 이를 효율적으로 여러 체인에 걸쳐 실행하도록 합니다. 동시에 EIP‑4337 스마트 계정과 Paymaster는 가스 추상화를 가능하게 합니다. 이를 통해 애플리케이션이 거래 수수료를 스폰서하거나 사용자가 스테이블코인으로 비용을 지불하도록 할 수 있어, 다중 네트워크를 건드리는 모든 흐름에 필수적입니다.

• 네이티브 스테이블코인 이동성: Circle의 Cross‑Chain Transfer Protocol (CCTP)은 안전한 소각‑민팅 과정을 통해 네이티브 USDC를 체인 간 이동시켜 래핑 자산 위험을 감소시키고 유동성을 통합합니다. 최신 버전인 CCTP v2는 레이턴시를 더욱 줄이고 개발자 워크플로를 단순화해 스테이블코인 결제를 추상화된 경험의 매끄러운 일부로 만듭니다.

“크로스체인 추상화”가 기업 스택에서 어떻게 보이는가​

기존 시스템에 레이어드 기능을 추가한다고 생각하면 됩니다. 목표는 단일 엔드포인트에 인텐트를 전달하고, 단일 정책 레이어가 여러 체인에 걸쳐 실행 방식을 관리하도록 하는 것입니다.

1. 통합 아이덴티티·정책: 최상위 레이어는 역할 기반 접근 제어, 소셜 복구, 패스키·MPC 같은 현대적 커스터디 옵션을 갖춘 스마트 계정(EIP‑4337)입니다. 중앙 정책 엔진이 누가, 어디서, 무엇을 할 수 있는지를 정의하고, 특정 체인·자산·브리지에 대한 허용·거부 리스트를 관리합니다.

2. 가스·수수료 추상화: Paymaster는 “체인 X에 네이티브 가스가 필요하다”는 문제를 없앱니다. 사용자는 스테이블코인으로 수수료를 지불하거나, 애플리케이션이 정책·예산에 따라 전체를 스폰서할 수 있습니다.

3. 인텐트‑드리븐 실행: 사용자는 거래가 아니라 결과를 표현합니다. 예: “USDC를 wETH로 교환하고 Y 체인에 있는 공급업체 지갑에 오후 5시 이전에 전달한다.” ERC‑7683 표준이 이러한 주문 형식을 정의하고, 공유 솔버 네트워크가 안전하고 저렴하게 실행하도록 경쟁합니다.

4. 프로그래머블 정산·메시징: 내부적으로 시스템은 일관된 API를 사용해 각 경로에 가장 적합한 레일을 선택합니다. 기업 지원이 핵심인 토큰 전송에는 CCIP, 크로스‑에코시스템 계약 호출에는 Axelar GMP, 위험 모델에 맞는 라이트‑클라이언트 보안이 필요하면 IBC 등을 활용합니다.

5. 관찰성·기본 컴플라이언스: 전체 워크플로는 초기 인텐트부터 최종 정산까지 추적 가능하며, 명확한 감사 로그를 생성해 기존 SIEM에 내보낼 수 있습니다. 위험 프레임워크는 허용 리스트를 강제하거나, 브리지 보안 상태가 악화될 경우 라우트를 일시 중단하는 비상 정지 기능을 프로그래밍할 수 있습니다.

레퍼런스 아키텍처​

위에서 아래로 살펴보면, 체인‑추상화 시스템은 명확한 레이어로 구성됩니다:

• 경험 레이어: 사용자 인텐트를 수집하고 체인 세부 정보를 완전히 숨기는 애플리케이션 UI. SSO‑스타일 스마트 계정 월렛 흐름과 결합됩니다.
• 컨트롤 플레인: 권한, 할당량, 예산을 관리하는 정책 엔진. KMS/HSM 시스템과 연동하고, 체인·자산·브리지에 대한 허용 리스트를 유지합니다. 위험 피드도 자동으로 회로 차단에 활용됩니다.
• 실행 레이어: 정책·가격·레턴시 요구사항에 따라 최적의 인터옵 레일(CCIP, LayerZero, Axelar 등)을 선택하는 인텐트 라우터. Paymaster가 풀링된 가스·스테이블코인 예산에서 수수료를 차감합니다.
• 정산·상태: 커스터디·발행 등 핵심 기능을 위한 온‑체인 계약. 통합 인덱서가 크로스체인 이벤트와 증명을 추적해 데이터 웨어하우스·SIEM으로 내보냅니다.

Build vs. Buy: 체인 추상화 제공업체 평가 방법​

파트너를 선택할 때 기업이 물어야 할 핵심 질문:

• 보안·신뢰 모델: 기본 검증 가정은 무엇인가? 오라클, 가디언 세트, 라이트 클라이언트, 검증자 네트워크 중 어떤 것을 의존하는가? 슬래시·베토가 가능한가?
• 커버리지·중립성: 현재 지원되는 체인·자산은 무엇이며, 신규 추가는 얼마나 빠른가? 프로세스가 허가제인지, 무허가인지?
• 표준 정렬: ERC‑7683, EIP‑4337, OFT, IBC, CCIP 등 핵심 표준을 지원하는가?
• 운영: SLA는 어떻게 되는가? 사고에 대한 투명성은? 재생 가능한 증명, 결정론적 재시도, 구조화된 감사 로그를 제공하는가?
• 거버넌스·이식성: 라우트별로 인터옵 레일을 교체해도 애플리케이션을 다시 작성할 필요가 없는가? 공급업체 중립적인 추상화가 장기적 유연성에 필수적이다.
• 컴플라이언스: 데이터 보존·거주지 제어가 가능한가? SOC2/ISO 인증 수준은? 자체 KMS/HSM을 연동할 수 있는가?

실용적인 90일 기업 롤아웃​

• Day 0‑15 : 베이스라인·정책 – 현재 사용 중인 체인·자산·브리지·월렛을 모두 목록화하고, 초기 허용 리스트와 명확한 위험 프레임워크 기반 회로 차단 규칙을 정의합니다.
• Day 16‑45 : 프로토타입 – 크로스체인 지급 같은 단일 사용자 여정을 인텐트‑기반 흐름, 계정 추상화, Paymaster와 함께 구현합니다. 사용자 이탈률, 레이턴시, 지원 부하 변화를 측정합니다.
• Day 46‑75 : 레일 확장 – 두 번째 인터옵 레일을 추가하고 정책에 따라 트랜잭션을 동적으로 라우팅합니다. 워크플로에 스테이블코인 사용이 포함된 경우 CCTP를 연동해 네이티브 USDC 이동성을 확보합니다.
• Day 76‑90 : 하드닝 – 관찰성 데이터를 SIEM에 연결하고, 라우트 장애에 대한 카오스 테스트를 수행하며, 비상 정지 프로토콜을 포함한 모든 운영 절차를 문서화합니다.

흔히 저지르는 실수 (그리고 회피 방법)​

• “가스 가격만” 라우팅: 레이턴시·최종성·보안 가정도 수수료만큼 중요합니다. 가격만으로 위험 모델을 완성할 수 없습니다.
• 가스 무시: 다중 체인을 건드리는 경험이라면 가스 추상화는 선택 사항이 아니라 필수 조건입니다.
• 브리지를 교환 가능하게 취급: 브리지는 보안 가정이 크게 다릅니다. 허용 리스트를 코드화하고 회로 차단기를 구현해 위험을 관리하세요.
• 래핑 자산 남발: 가능하면 네이티브 자산 이동성(예: CCTP를 통한 USDC)으로 전환해 유동성 파편화와 카운터파트 위험을 최소화합니다.

기업에게 주는 이점​

체인 추상화가 제대로 구현되면 블록체인은 개별적인 이질적 네트워크 모음이 아니라 팀이 프로그래밍할 수 있는 실행 패브릭이 됩니다. 정책, SLA, 감사 로그가 기존 운영 기준과 일치합니다. 성숙한 인텐트 표준, 계정 추상화, 견고한 인터옵 레일, 네이티브 스테이블코인 전송 덕분에 이제 사용자를 혹은 개발자를 특정 체인에 얽매이지 않고 Web3 결과를 제공할 수 있습니다.

Alchemy는 Web3 인프라스트럭처 분야에서 지배적인 존재로, 수천 명의 개발자와 OpenSea와 같은 주요 프로젝트의 진입점 역할을 합니다. G2, Reddit, GitHub 등 공개된 사용자 피드백을 분석함으로써 개발자들이 무엇을 가치 있게 여기고, 어디에서 어려움을 겪으며, 미래의 Web3 개발 경험이 어떻게 변할지에 대한 명확한 그림을 얻을 수 있습니다. 이는 단일 공급자를 넘어, 전체 생태계의 성숙한 요구를 반영합니다.

사용자가 일관되게 좋아하는 점​

리뷰 사이트와 포럼 전반에 걸쳐, 사용자는 Alchemy의 몇 가지 핵심 강점을 지속적으로 칭찬합니다.

• 간편한 “온램프” 및 사용성: 초보자와 소규모 팀은 빠르게 시작할 수 있다는 점을 높이 평가합니다. G2 리뷰에서는 “Web3를 구축하기에 훌륭한 플랫폼”이라며 손쉬운 설정과 포괄적인 문서를 강조합니다. 노드 운영의 복잡성을 성공적으로 추상화했습니다.
• 중앙화된 대시보드 및 툴링: 개발자는 관측을 위한 단일 “커맨드 센터”를 선호합니다. 요청 로그 모니터링, 분석 보기, 알림 설정, API 키 회전 등을 한 대시보드에서 할 수 있다는 점이 큰 사용자 경험 개선으로 작용합니다.
• 지능형 SDK 기본값: Alchemy SDK는 기본적으로 요청 재시도와 지수 백오프를 처리합니다. 이 작은 기능이지만, 개발자가 보일러플레이트 로직을 작성할 필요를 없애고 복원력 있는 애플리케이션 구축의 마찰을 크게 낮춥니다.
• 강력한 지원 평판: 블록체인 개발이라는 복잡한 영역에서 신속한 지원은 큰 차별점입니다. TrustRadius와 같은 종합 리뷰 사이트에서는 Alchemy의 친절한 지원 팀을 주요 장점으로 자주 언급합니다.
• 사회적 증명 및 신뢰: OpenSea와 같은 거대 프로젝트 사례와 파트너 엔드오스먼트를 공개함으로써, 관리형 RPC 공급자를 선택하려는 팀에게 확신을 제공합니다.

주요 고통 지점​

긍정적인 면이 많지만, 애플리케이션이 확장될수록 개발자는 반복적인 문제에 직면합니다. 이러한 고통 지점은 개선을 위한 핵심 기회를 드러냅니다.

• “보이지 않는 벽”인 처리량 제한: 가장 흔한 불만은 429 Too Many Requests 오류입니다. 메인넷 포크 테스트, 버스트 배포, 다수 동시 사용자 서비스 등에서 이 오류가 발생합니다. 특히 유료 플랜에서도 제한을 느끼며, 중요한 트래픽 급증 시 스로틀링 당한다는 혼란을 야기합니다. 결과적으로 CI/CD 파이프라인이 깨지고 테스트가 불안정해지며, 개발자는 sleep 명령어나 백오프 로직을 직접 구현해야 합니다.
• 낮은 동시성 인식: Reddit 등 포럼에서는 저가 플랜이 동시 사용자 수가 적으면 바로 레이트 리밋에 걸린다는 이야기가 자주 등장합니다. 정확도와 워크로드에 따라 다르지만, 이러한 인식은 팀이 더 복잡한 멀티‑프로바이더 구성을 고민하거나 예상보다 일찍 업그레이드하게 만들 수 있습니다.
• 무거운 쿼리 타임아웃: 특히 eth_getLogs 같은 고부하 JSON‑RPC 호출은 타임아웃이나 500 오류를 유발합니다. 이는 클라이언트 경험을 방해할 뿐 아니라 Foundry, Anvil 같은 로컬 개발 툴을 크래시시켜 생산성을 크게 저하시킵니다.
• SDK와 프로바이더 혼동: 신규 사용자는 노드 프로바이더의 역할을 이해하는 데 어려움을 겪습니다. 예를 들어 Stack Overflow 질문에서 eth_sendTransaction 실패 원인을 프로바이더가 개인 키를 보관하지 않음에도 불구하고 착각하는 경우가 있습니다. 잘못된 API 키나 URL로 인한 불명확한 오류도 초보자에게 큰 장벽이 됩니다.
• 데이터 프라이버시 및 중앙화 우려: 일부 개발자는 자체 호스팅 혹은 프라이버시 중심 RPC를 선호합니다. 대형 중앙화된 공급자가 IP 주소를 로그하고 트랜잭션을 검열할 가능성을 우려하며, 투명성과 신뢰가 최우선이라고 강조합니다.
• 제품 범위와 로드맵: G2 리뷰에서는 경쟁사가 새로운 생태계로 빠르게 확장하고 있거나 Alchemy가 “몇 개 체인에만 집중하고 있다”는 인식이 나오기도 합니다. 이는 비‑EVM 체인에서 구축하는 팀에게 기대 불일치를 초래합니다.

개발자 기대가 깨지는 순간​

이러한 고통 지점은 개발 라이프사이클의 특정 시점에 예측 가능하게 나타납니다.

1. 프로토타입 → 테스트넷: 로컬에서는 완벽히 동작하던 프로젝트가 CI/CD 환경에서 병렬 테스트 시 처리량 제한에 걸려 실패합니다.
2. 로컬 포크: Hardhat이나 Foundry로 메인넷을 포크해 현실적인 테스트를 진행할 때, 대량 데이터 쿼리로 인한 429 오류와 타임아웃이 가장 먼저 보고됩니다.
3. NFT / 데이터 API 대규모 사용: 대규모 NFT 컬렉션의 민팅 이벤트나 데이터 로딩은 기본 레이트 리밋을 쉽게 초과해, 캐싱·배칭 최적화 방안을 찾게 만듭니다.

핵심 “Jobs‑to‑be‑Done” 정리​

피드백을 정리하면 Web3 개발자의 근본적인 요구 3가지가 도출됩니다.

• “관측과 디버깅을 위한 단일 창을 제공해 주세요.” – Alchemy 대시보드가 이 역할을 잘 수행합니다.
• “버스트 워크로드를 예측 가능하고 관리 가능하게 해 주세요.” – 제한은 받아들이지만, 스파이크를 부드럽게 처리하고, 더 나은 기본값과 즉시 사용 가능한 코드 스캐폴드를 원합니다.
• “인시던트 발생 시 차단되지 않게 도와 주세요.” – 문제가 생겼을 때 명확한 상태 업데이트, 실행 가능한 포스트‑모템, 손쉬운 페일오버 패턴이 필요합니다.

더 나은 DX를 위한 실행 가능한 기회​

이 분석을 바탕으로 인프라 공급자는 다음과 같은 기회를 통해 제품을 강화할 수 있습니다.

• 선제적 “Throughput Coach”: 대시보드 혹은 CLI 툴로 예정 워크로드를 시뮬레이션하고 CU/s(초당 컴퓨트 유닛) 제한 시점을 예측, ethers.js, viem, Hardhat, Foundry 등 인기 라이브러리에 맞는 재시도·백오프 스니펫을 자동 생성합니다.
• 골든‑패스 템플릿: 흔히 겪는 문제에 대한 프로덕션‑그레이드 템플릿을 제공. 예를 들어 메인넷 포크 시 보수적인 동시성을 적용한 Hardhat 네트워크 설정이나, eth_getLogs 를 페이지네이션으로 효율적으로 배칭하는 샘플 코드를 포함합니다.
• 어댑티브 버스트 용량: 유료 플랜에 “버스트 크레딧” 혹은 탄력적 용량 모델을 도입해 단기 트래픽 급증을 원활히 처리합니다. 이는 불필요한 제약 느낌을 직접 해소합니다.
• 공식 멀티‑프로바이더 페일오버 가이드: 복원력 있는 dApp은 다중 RPC를 사용한다는 점을 인정하고, 백업 프로바이더로 전환하는 의견 기반 레시피와 샘플 코드를 제공해 신뢰를 구축합니다.
• 근본적인 투명성: 프라이버시·검열 우려를 직접 해소하기 위해 데이터 보존 정책, 로그 항목, 필터링 여부 등을 명확하고 접근하기 쉬운 문서로 공개합니다.
• 실행 가능한 인시던트 리포트: 단순 상태 페이지를 넘어, 인시던트 발생 시 짧은 RCA(근본 원인 분석)와 구체적인 대응 방안을 제시합니다. 예: “2025년 8월 5‑6일 EU 지역 지연” 상황에서 “현재 할 수 있는 완화 조치”를 안내합니다.

결론: Web3 인프라 로드맵​

Alchemy에 대한 사용자 피드백은 전체 Web3 인프라스트럭처 영역을 위한 귀중한 로드맵을 제공합니다. 플랫폼이 온보딩 경험을 크게 단순화하는 한편, 확장성, 예측 가능성, 투명성에서 겪는 어려움은 다음 단계의 개발자 경험을 정의합니다.

산업이 성숙함에 따라 승자는 단순히 안정적인 접근성을 제공하는 것이 아니라, 개발자가 첫날부터 복원력 있고 확장 가능하며 신뢰할 수 있는 애플리케이션을 구축하도록 돕는 도구와 가이드를 함께 제공하는 플랫폼이 될 것입니다.

QuickNode는 Web3 인프라스트럭처 분야의 핵심 플레이어로, 속도와 폭넓은 멀티체인 지원으로 찬사를 받고 있습니다. 많은 개발자들이 QuickNode를 선택하는 이유와 경험을 개선할 수 있는 부분을 이해하기 위해, G2, Reddit, Product Hunt, Trustpilot 등 다양한 플랫폼에서 공개된 사용자 피드백을 종합했습니다.

분석 결과는 명확합니다. 개발자들은 핵심 제품을 사랑하지만, 특히 비용 측면에서 사용자 여정에 장애물이 존재합니다.

장점: 사용자가 QuickNode를 사랑하는 이유​

전반적으로 사용자는 QuickNode가 세 가지 핵심 강점을 바탕으로 프리미엄하고 마찰 없는 개발자 경험을 제공한다는 점을 강조합니다.

🚀 번개 같은 빠른 성능 & 견고한 안정성​

이것이 QuickNode의 가장 큰 강점입니다. 사용자들은 서비스를 “번개처럼 빠르다” 그리고 “가장 성능이 뛰어나고 안정적인 RPC 제공자” 라고 일관되게 표현합니다. 100ms 이하의 저지연 응답과 99.99% 가동률은 개발자에게 반응형 dApp을 구축하고 확장할 수 있는 자신감을 줍니다.

Nansen의 한 기업 고객은 QuickNode가 “수십억 건의 요청을 처리할 수 있는 견고하고 저지연, 고성능 노드” 를 제공한다고 언급했습니다. 이 성능은 단순한 수치가 아니라 최종 사용자 경험을 매끄럽게 만드는 핵심 기능입니다.

✅ 손쉬운 온보딩 & 직관적인 UI​

개발자들은 종종 “몇 분 안에 바로 실행할 수 있다” 고 말합니다. 플랫폼은 깔끔한 대시보드와 직관적인 워크플로우 덕분에 노드 운영의 복잡성을 추상화합니다.

Reddit의 한 개발자는 인터페이스를 “노 브레인” 이라고 부했으며, 풀스택 개발자는 “가입하고 노드를 프로비저닝하는 데 복잡한 DevOps 작업 없이도 몇 분이면 된다” 라고 강조했습니다. 이러한 사용 편의성은 QuickNode를 빠른 프로토타이핑과 테스트에 필수적인 도구로 만듭니다.

🤝 최고 수준의 고객 지원 & 문서​

뛰어난 지원과 문서는 일관된 주제입니다. 지원 팀은 “빠르게 응답하고 진정으로 도움이 된다” 라는 평가를 받으며, 시간에 민감한 문제를 해결할 때 큰 자산이 됩니다.

API 문서는 명확하고, 상세하며, 초보자 친화적이라는 보편적인 찬사를 받습니다. 한 사용자는 튜토리얼을 “잘 만들어졌다” 라고 평가했습니다. 이러한 개발자 리소스에 대한 투자는 진입 장벽을 크게 낮추고 통합 마찰을 감소시킵니다.

장애물: 사용자가 겪는 어려움​

탁월한 성능과 사용자 경험에도 불구하고, 사용자 피드백에서 두 가지 주요 마찰 지점이 나타났습니다. 주로 비용과 기능 제한에 초점이 맞춰져 있습니다.

💸 가격 구조의 딜레마​

가격은 가장 흔하고 감정적인 비판 포인트입니다. 피드백은 두 가지 사용자 집단의 이야기를 보여줍니다.

• 기업 고객에게는 프리미엄 성능과 안정성을 위한 정당한 비용으로 인식됩니다.
• 스타트업 및 인디 개발자에게는 비용이 장벽이 될 수 있습니다.

핵심 문제는 다음과 같습니다.

1. 요금제 간 큰 점프: 사용자는 “$49 ‘Build’ 플랜에서$249 ‘Accelerate’ 플랜으로의 큰 점프” 를 지적하며, 성장 중인 프로젝트를 지원할 중간 요금제가 필요하다고 요구합니다.
2. 과다 사용에 대한 가혹한 추가 요금: 이는 가장 큰 고통 포인트입니다. QuickNode는 할당량을 초과하면 자동으로 전체 블록의 추가 요청 비용을 청구하는 정책을 가지고 있어, 사용량 상한을 설정할 옵션이 없습니다. 한 사용자는 “의도치 않게 100만 요청을 초과하면 추가 $50이 부과될 수 있다” 고 설명했습니다. 이러한 예측 불가능성은 Trustpilot의 장기 고객이 서비스를 “가장 큰 사기…멀리 떨어져라” 라고 부르게 만들었습니다.

G2 리뷰어는 “가격 구조가 스타트업 친화적일 수 있다면 좋겠다” 라고 요약했습니다.

🧩 틈새 기능 부족​

QuickNode의 기능은 견고하지만, 고급 사용자는 몇 가지 부족한 점을 지적합니다. 일반적인 요청은 다음과 같습니다.

• 더 넓은 프로토콜 지원: Bitcoin 및 최신 L2인 Starknet 같은 체인 지원을 원합니다.
• 강력한 툴링: 일부 개발자는 경쟁사와 비교해 “더 강력한 웹훅 지원 같은 기능이 부족하다” 고 언급했습니다.
• 현대적인 인증: 장기 사용자 중 한 명은 OAuth 지원 을 원하며, 특히 기업 환경 에서 API 키 관리를 개선하고 싶어합니다.

이러한 격차는 대부분의 사용자에게 핵심 제공 가치를 훼손하지 않지만, 특정 사용 사례에서는 경쟁사가 우위를 가질 수 있음을 보여줍니다.

Web3 인프라 분야에 대한 핵심 인사이트​

QuickNode에 대한 피드백은 개발자를 위한 도구를 만드는 모든 기업에 귀중한 교훈을 제공합니다.

• 성능은 기본 조건: 속도와 안정성은 기반이며, 이것이 없으면 다른 모든 것이 무의미합니다. QuickNode는 여기서 높은 기준을 설정합니다.
• 개발자 경험이 차별화 요소: 깔끔한 UI, 빠른 온보딩, 훌륭한 문서, 신속한 지원은 충성도 높은 고객을 만들고 개발자가 실제로 즐겨 사용하는 제품을 만듭니다.
• 가격 예측 가능성이 신뢰를 구축: 이것이 가장 중요한 교훈입니다. 불투명하거나 가혹한 가격 모델, 특히 사용량 상한이 없는 경우는 불안감을 조성하고 신뢰를 무너뜨립니다. 깜짝 청구서를 받은 개발자는 장기 고객이 되기 어렵습니다. 예측 가능하고 투명하며 스타트업 친화적인 가격 은 강력한 경쟁 우위가 됩니다.

결론​

QuickNode는 확실히 최고 수준의 인프라 제공업체로서의 명성을 얻었습니다. 높은 성능, 뛰어난 안정성, 그리고 뛰어난 개발자 경험을 제공합니다. 그러나 가격 모델은 특히 스타트업과 독립 개발자에게 큰 마찰을 일으키고 있습니다.

이 사용자 피드백은 성공적인 플랫폼 구축이 단순히 기술적 우수성만이 아니라 비즈니스 모델을 사용자들의 요구와 신뢰에 맞추는 것이 중요함을 강력히 상기시켜 줍니다. QuickNode의 성능을 유지하면서 보다 투명하고 예측 가능한 가격 구조를 제공할 수 있는 인프라 제공업체는 미래에 매우 유리한 위치를 차지할 것입니다.

Web3 개발자 경험 (DevEx) 혁신에 대한 보고서의 요약을 제공합니다.

요약​

Web3 개발자 경험은 2024‑2025년에 프로그래밍 언어, 툴체인, 배포 인프라의 혁신으로 크게 향상되었습니다. 개발자들은 더 빠른 도구, 안전한 언어, 간소화된 워크플로우 덕분에 생산성과 만족도가 높아졌다고 보고합니다. 이 요약은 다섯 가지 핵심 툴체인(Solidity, Move, Sway, Foundry, Cairo 1.0)과 두 가지 주요 트렌드인 ‘원클릭’ 롤업 배포와 스마트 계약 핫리로딩에 대한 발견을 정리한 것입니다.

Web3 개발자 툴체인 비교​

각 툴체인은 고유한 장점을 제공하며, 서로 다른 생태계와 개발 철학에 맞춰 설계되었습니다.

• Solidity (EVM): 방대한 생태계, 풍부한 라이브러리(예: OpenZeppelin) 및 Hardhat, Foundry와 같은 성숙한 프레임워크 덕분에 가장 지배적인 언어로 남아 있습니다. 매크로와 같은 네이티브 기능은 부족하지만, 광범위한 채택과 강력한 커뮤니티 지원으로 Ethereum 및 대부분의 EVM 호환 L2에서 기본 선택이 됩니다.
• Move (Aptos/Sui): 안전성과 형식 검증을 최우선으로 합니다. 리소스 기반 모델과 Move Prover 도구는 재진입과 같은 일반적인 버그를 설계 단계에서 방지합니다. 따라서 고보안 금융 애플리케이션에 이상적이지만, 생태계는 작으며 Aptos와 Sui 블록체인에 집중되어 있습니다.
• Sway (FuelVM): 계약, 스크립트, 테스트를 하나의 Rust‑유사 언어로 작성할 수 있게 하여 개발자 생산성을 극대화하도록 설계되었습니다. 고처리량의 UTXO 기반 Fuel Virtual Machine 아키텍처를 활용해 Fuel 네트워크에서 성능 집약형 애플리케이션에 강력한 선택이 됩니다.
• Foundry (EVM Toolkit): Solidity용 혁신적인 툴킷으로 EVM 개발을 혁신했습니다. 매우 빠른 컴파일 및 테스트를 제공하며, 개발자가 Solidity에서 직접 테스트를 작성할 수 있습니다. 퍼즈 테스트, 메인넷 포크, “cheatcodes”와 같은 기능 덕분에 Ethereum 개발자의 절반 이상이 주요 선택으로 사용합니다.
• Cairo 1.0 (Starknet): Starknet 생태계의 주요 DevEx 향상을 나타냅니다. 고수준의 Rust‑영감 문법과 현대적인 도구(Scarb 패키지 매니저, Starknet Foundry 등)로 전환하면서 ZK‑rollup 개발이 크게 빨라지고 직관적으로 변했습니다. 디버거와 같은 일부 도구는 아직 성숙 단계이지만, 개발자 만족도가 크게 상승했습니다.

주요 DevEx 혁신​

두 가지 주요 트렌드가 개발자들이 탈중앙화 애플리케이션을 구축하고 배포하는 방식을 변화시키고 있습니다.

“원클릭” 롤업 배포​

• 기반: Optimism의 OP Stack과 같은 프레임워크는 롤업 구축을 위한 모듈식 오픈소스 청사진을 제공합니다.
• 플랫폼: Caldera와 Conduit와 같은 서비스는 Rollup-as-a-Service(RaaS) 플랫폼을 만들었습니다. 웹 대시보드를 통해 개발자는 몇 분 안에 맞춤형 메인넷 또는 테스트넷 롤업을 배포할 수 있으며, 블록체인 엔지니어링 전문 지식이 최소화됩니다.
• 영향: 이를 통해 빠른 실험이 가능해지고, 애플리케이션 전용 체인 생성 장벽이 낮아지며, DevOps가 단순화되어 팀이 인프라가 아닌 애플리케이션에 집중할 수 있습니다.

스마트 계약 핫리로딩​

• 개념: Scaffold-ETH 2와 같은 도구는 개발 사이클을 자동화합니다. 개발자가 스마트 계약을 수정하고 저장하면, 도구가 자동으로 재컴파일하고 로컬 네트워크에 재배포하며 프론트엔드를 업데이트해 새로운 로직을 반영합니다.
• 영향: 핫리로딩은 반복적인 수동 작업을 제거하고 반복 주기를 크게 단축합니다. 이는 개발 과정을 더욱 몰입감 있게 만들고, 신규 개발자의 학습 곡선을 낮추며, 빈번한 테스트를 장려해 코드 품질을 향상시킵니다.

결론​

Web3 개발 환경은 빠른 속도로 성숙하고 있습니다. 보다 안전한 언어, Foundry와 같은 빠른 도구, 그리고 RaaS 플랫폼을 통한 인프라 배포의 단순화가 블록체인과 전통 소프트웨어 개발 간의 격차를 좁히고 있습니다. 이러한 DevEx 개선은 프로토콜 수준의 혁신만큼이나 중요하며, 개발자들이 더 복잡하고 안전한 애플리케이션을 빠르게 구축할 수 있게 합니다. 이는 궁극적으로 전체 블록체인 생태계의 성장과 채택을 촉진합니다.

출처:

• Solidity Developer Survey 2024 – Soliditylang (2025)
• Moncayo Labs on Aptos Move vs Solidity (2024)
• Aptos Move Prover intro – Monethic (2025)
• Fuel Labs – Fuel & Sway Documentation (2024); Fuel Book (2024)
• Spearmanrigoberto – Foundry vs Hardhat (2023)
• Medium (Rosario Borgesi) – Building Dapps with Scaffold-ETH 2 (2024)
• Starknet/Cairo developer survey – Cairo-lang.org (2024)
• Starknet Dev Updates – Starknet.io (2024–2025)
• Solidity forum – Macro preprocessor discussion (2023)
• Optimism OP Stack overview – CoinDesk (2025)
• Caldera rollup platform overview – Medium (2024)
• Conduit platform recap – Conduit Blog (2025)
• Blockchain DevEx literature review – arXiv (2025)