Wagmi v3와 Solana MWA 2.0: 모바일 지갑의 백그라운드 세션 끊김을 해결하는 아키텍처 패턴

모바일 환경의 엄격한 백그라운드 제약으로 인한 지갑 세션 해제는 Web3 개발자들의 가장 큰 고민거리 중 하나입니다. 이를 해결하기 위해 EVM 진영은 기존 useAccount를 useConnection으로 변경하고 useReconnect와 reconnectOnMount 속성을 통해 브라우저 이벤트 기반의 유연한 복구를 지원하는 Wagmi v3 및 메타마스크 커넥트 EVM(MetaMask Connect EVM)을 도입했습니다. 이에 맞서 SVM 진영은 기기 로컬 웹소켓 통신을 기반으로 인증 간소화를 지향하는 솔라나 모바일 지갑 어댑터(MWA) 2.0 규격으로 대응하고 있습니다. 두 진영의 아키텍처 차이와 모바일 OS 장벽을 극복하는 실전 최적화 패턴을 비교해 봅니다.

EVM의 접근법: Wagmi v3와 MetaMask Connect의 클라우드 릴레이

EVM 생태계는 모바일 환경의 하드웨어 및 운영체제 제약을 극복하기 위해 외부 클라우드 중계 서버를 적극적으로 활용합니다. 이 아키텍처의 핵심은 dApp과 지갑이 직접 통신하는 대신, 외부의 웹소켓 릴레이 서버를 거쳐 JSON-RPC 메시지를 주고받는 구조입니다. 이 방식은 기기나 플랫폼에 구애받지 않는 크로스 플랫폼 호환성을 제공하지만, 외부 인프라에 대한 의존성과 모바일 운영체제의 백그라운드 앱 제한 정책에 따라 세션이 유실될 수 있는 구조적 문제를 동시에 안고 있습니다.

최근 출시된 Wagmi v3는 이러한 연결 신뢰성을 높이고 번들 크기를 최적화하기 위해 전면적인 아키텍처 개편을 단행했습니다. 기존에 모든 지갑 커넥터를 내장하던 방식에서 벗어나, 이제 메타마스크의 새로운 SDK인 @metamask/connect-evm과 같은 도구들을 피어 의존성으로 분리하여 개발자가 필요에 따라 직접 명시적으로 설치하도록 변경했습니다. 또한 기존의 useAccount 훅은 useConnection으로 대체되었으며, 세션 복구는 reconnectOnMount 속성을 활성화하거나 useReconnect 훅을 통해 클라이언트 측에서 명시적으로 처리하도록 요구합니다.

이 흐름의 중심에 있는 메타마스크 커넥트 EVM은 기존의 메타마스크 SDK를 완전히 대체하며 CAIP-25 멀티체인 규격을 구현했습니다. 이 SDK는 EIP-1193을 준수하는 프로바이더를 생성하여 멀티체인 세션을 안정적으로 유지하고 플랫폼별 딥링크 제약을 유연하게 우회합니다. 결과적으로 EVM 진영은 클라우드 릴레이 서버 덕분에 플랫폼 파편화 문제를 영리하게 해결하고 있지만, 모바일 브라우저가 백그라운드 탭의 실행을 강제로 일시 정지할 때 활성화된 웹소켓 중계 연결이 끊어지는 고질적인 숙제를 개발자가 직접 핸들링해야 하는 부담을 안고 있습니다.

SVM의 접근법: Solana MWA 2.0의 로컬 웹소켓과 인라인 인증

솔라나는 외부 클라우드 중계기 없이 기기 내부에서 직접 암호화된 로컬 웹소켓 채널을 개설하는 모바일 지갑 어댑터(MWA) 아키텍처를 지향합니다. 안드로이드 환경에서 dApp이 지갑 구성 인텐트를 호출하면 지갑 앱이 디바이스 내부 로컬 웹소켓 서버를 구동하고, 디피-헬먼 키 교환과 AES-128-GCM을 적용해 종단간 암호화 채널을 생성합니다. 외부 서버망을 거치지 않으므로 클라우드 지연 시간이 발생하지 않고 외부 인프라 장애로부터 자유롭습니다.

솔라나 모바일 개발자 문서에 따르면, MWA 2.0 규격은 매번 지갑 승인을 요구하던 기존 재인증 절차를 정리하고 사용자 경험을 크게 단축했습니다. 이전 스펙에서 사용하던 reauthorize 메소드를 폐지하는 대신, 메인 authorize 호출 시 선택적 파라미터인 authToken을 직접 전달하는 방식을 지원합니다. 캐싱된 토큰을 활용하면 지갑 화면으로 화면 전환을 강제하지 않고도 서명 프로세스를 백그라운드에서 매끄럽게 승인하는 고속의 로컬 통신 구조를 설계할 수 있습니다.

이와 함께 MWA 2.0은 신원 인증 단계를 효율화하는 솔라나 로그인(SIWS)을 기본 지원합니다. authorize 호출 단계에서 signInPayload 파라미터를 결합하여 전달하면, 지갑 연결과 사용자 신원 확인 절차가 단 하나의 사용자 액션으로 묶입니다. 결과적으로 복잡한 온체인 결제나 멀티 트랜잭션 서명 시 불필요하게 반복되던 이탈 단계를 줄일 수 있습니다.

플랫폼 장벽: 안드로이드 로컬 채널과 iOS 샌드박스의 한계

두 아키텍처의 실질적인 성능과 개발 경험은 운영체제 샌드박스 정책에 의해 결정적인 차이를 보입니다. 안드로이드는 로컬 웹소켓을 통한 MWA 통신을 안정적으로 지원하지만, iOS는 보안과 배터리 효율을 이유로 백그라운드 소켓 통신을 엄격히 제한하기 때문입니다.

솔라나 모바일 코어 팀의 연구 결과에 따르면, iOS 환경에서 앱이 백그라운드로 전환되면 운영체제는 보통 30초 이내에 실행을 일시 정지하며 이 과정에서 로컬 웹소켓 연결이 강제로 해제됩니다. 이로 인해 Solana MWA의 로컬 웹소켓 방식은 안드로이드 크롬 브라우저 환경 등으로 제한됩니다. iOS 환경의 dApp들은 결국 개별 지갑 앱의 유니버설 링크를 통한 상호 호출 방식에 의존해야 하며, 이는 잦은 화면 전환 지연과 딥링크 무한 루프 문제를 동반합니다.

이러한 플랫폼별 한계와 성능 저하 때문에 모바일 Web3 생태계에서는 새로운 아키텍처 대안이 부상하고 있습니다. 최근 많은 개발자들은 복잡한 딥링크와 백그라운드 연결 끊김 문제를 완전히 우회하기 위해, dApp 내부에 보안 키 보관 및 서명 기능을 직접 내장하는 프리비(Privy)나 파라(Para) 같은 임베디드 지갑 아키텍처로 선회하는 추세입니다.

백그라운드 세션 유지를 위한 실전 대응 패턴

모바일 브라우저의 백그라운드 탭 정지 현상으로 인한 세션 끊김을 해결하려면 dApp 레벨에서 능동적인 재연결 루틴을 설계해야 합니다.

EVM 개발 환경에서는 Wagmi v3의 연결 상태 관리 정책 변화에 맞춘 대응이 필요합니다. Wagmi v3에서는 기존 useAccount가 useConnection으로 변경되었으며, 자동 재연결은 reconnectOnMount 설정이나 useReconnect 훅을 통해 제어하도록 개편되었습니다. 모바일 브라우저가 백그라운드 탭의 자원을 회수해 웹소켓 릴레이 세션이 끊기는 현상을 방지하려면, 브라우저의 Page Visibility API를 활용해야 합니다. visibilitychange 이벤트를 감지하여 화면이 다시 활성화되는 순간 useReconnect 훅의 재연결 실행 함수를 호출하면, 사용자가 다시 진입할 때 지갑 커넥터 세션을 자동으로 즉시 복원할 수 있습니다.

SVM 진영의 모바일 dApp 개발자는 MWA 2.0의 심리스한 로컬 연결 복구 메커니즘을 적극 활용해야 합니다. MWA 2.0 사양에서는 별도의 재인증 단계를 거치지 않고, authorize 메서드를 호출할 때 선택 매개변수로 기존에 발급받은 인증 토큰(authToken)을 인라인으로 직접 전달할 수 있도록 통합되었습니다. React Native 환경에서 @solana-mobile/wallet-adapter-mobile을 구성할 때 기기 보안 저장소와 연동되는 사용자 정의 캐시 저장소인 authorizationResultCache를 주입하는 아키텍처를 권장합니다. 이를 통해 최초 로그인 시 획득한 토큰을 안전하게 유지하고, 후속 서명 요청 시 지갑 앱이 백그라운드에서 깨어날 때 해당 토큰을 자동으로 전달함으로써 사용자 승인 팝업 없이 세션을 안전하게 재활성화할 수 있습니다.

EVM vs SVM: 우리 서비스에 맞는 모바일 아키텍처 선택

EVM의 클라우드 릴레이 아키텍처와 SVM의 로컬 웹소켓 기반 MWA 2.0 방식은 모바일 세션 끊김을 해결하는 방향성에서 뚜렷한 차이를 보입니다. 크로스 플랫폼 호환성이 최우선이고 모바일 웹 사용자가 타겟이라면, Wagmi v3의 reconnectOnMount 옵션이나 useReconnect를 페이지 가시성 이벤트인 visibilitychange와 연동해 세션을 복구하는 EVM 설계가 적합합니다. 반면 고성능 네이티브 앱을 지향한다면, authorize 호출 시 기기 내부 보안 저장소에 캐싱한 authToken을 전달해 사용자 개입 없이 세션을 재인증하는 Solana MWA 2.0 아키텍처가 유용합니다. 플랫폼별 운영체제 제약과 dApp의 배포 환경을 면밀히 비교하여 최적의 세션 재연결 루틴을 설계해야 모바일 사용자 이탈을 막을 수 있습니다.

참고 링크