Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본문은 GrapheneOS 사용 시 영국 은행 앱의 지원 수준을 분석하며, 완전한 차단부터 일부 기능만 가능한 사례를 제시합니다. 이는 금융기관이 특정 OS에 의존하는 것에 대한 비판적 시각을 담고 있으며, 사용자에게 높은 수준의 통제권을 요구해야 함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기영국 은행·금융기관을 이용해 본 바로는 GrapheneOS 지원 수준은 네 가지로 나뉨. 아예 차단하는 곳, 일부 기능만 되는 곳, 기본 프로필에서만 되는 곳, 모든 기능이 되는 곳임.
완전히 차단하는 은행도 탓하기는 어려움. 누군가 휴대전화를 루팅하고 악성코드를 내려받으면 은행이 피해액을 돌려줘야 할 수 있으니, 그런 골칫거리를 피하려는 이유는 이해함.
일부 지원의 예로, 내가 쓰는 신용카드 앱은 일반 기능은 되지만 가상 카드 발급과 로그인 상태 유지가 안 됨. 내 용도로는 충분함. 가맹점 계좌 앱도 잔액 조회는 됐지만 휴대전화를 카드 결제 단말기로 쓰지는 못했음.
금융 앱은 잠긴 별도 프로필에 두고 싶지만, 기본 프로필만 허용하는 은행도 많음. 완전히 지원하는 앱도 일부 익스플로잇 방어 기능을 꺼야 할 수 있음.
소규모 은행 중에는 기술 문의를 개발자에게 잘 전달해 주는 곳도 있음. 영국은 은행을 옮기기 쉬워서, 내 휴대전화에서 잘 작동하는 곳으로 계좌를 옮기고 기존 은행에는 이유를 알려줬음.
Google이나 Apple이 승인하지 않은 OS를 쓰면 실제로 계정 탈취나 사기가 늘어난다는 근거 없이 특정 OS를 강요한다면 은행을 탓할 만함.
그런 근거를 찾아 가볍게 몇 차례 웹 검색을 해봤지만 찾지 못했음. 누군가 신뢰할 만한 데이터를 갖고 있더라도 공개하지는 않는 듯함.
기본 프로필에서만 작동하는 이유를 아는 분이 있는지? 프로필을 깊이 알지는 못하지만, 앱 실행 환경 관점에서는 다른 프로필도 기기 소유자 프로필과 동등하다고 이해하고 있었음.
두 가지 유형을 더 추가할 수 있음. 앱 버전이 바뀔 때마다 됐다 안 됐다 하는 경우, 그리고 AOSP 키보드나 Gboard를 활성화하면 되지만 LeanType에서는 안 되는 경우임. 원인만 알면 쉽게 해결되지만, 디버깅 과정은 꽤 괴로웠음.
은행을 옮기는 게 번거로운 나라도 있는지? 지금까지 약 세 나라에서 개인 계좌를 써봤는데, 새 계좌를 만들고 입금받을 IBAN과 자동이체 계좌를 바꾼 뒤 새 카드를 쓰는 정도였음. 마지막으로 옮길 때는 자동이체와 카드 관련 변경도 상당수 자동 처리됐음. 다른 나라에서는 보통 이보다 더 어려운지?
바로 그런 이유로 GrapheneOS는 자신들이 무결성을 증명하는 루팅 버전을 배포하지 않음. 은행들이 GrapheneOS를 명시적으로 금지한다기보다는 Google의 무결성 증명만 신뢰하는 것으로 보임.
일부 은행이 GrapheneOS를 명시적으로 허용하는 것도, 루팅된 OS가 아니어서 GrapheneOS의 무결성 증명을 추가로 신뢰하기 쉽기 때문임. 제대로 판단하는 은행 보안팀이라면 기본 Pixel을 포함한 다른 Android 휴대전화보다 더 안전하다는 점을 알아볼 수 있음.
이 구분이 더 잘 알려졌으면 함. 그래야 Apple이나 Google의 통제를 받지 않는 오픈소스 모바일 OS도 소비자가 안전하게 쓸 수 있는 정식 선택지로 인정받을 기회가 생김.
GrapheneOS를 쓰고 있지만, 은행이 특정 기술로 내 돈에 대한 접근을 제한하려면 그 기술도 계좌 서비스의 일부로 제공해야 함. 예를 들어 HSBC는 여전히 웹 브라우저로 계좌를 관리할 수 있게 하고, 배터리로 작동하는 하드웨어 인증 토큰도 제공함.
은행에 내 돈을 맡겼는데 왜 내가 은행의 분산 인프라까지 제공해야 하는지? 내 돈에 접근하려고 은행의 독점 악성 소프트웨어를 실행하도록 강요받을 생각은 없음. 기업에 돈을 내는 대가로 내 하드웨어의 연산 자원까지 무상 제공해야 한다는 흐름은 요즘 가장 황당한 현상 중 하나임.
JavaScript 웹 앱도 비슷하지만, 적어도 내가 통제하는 샌드박스 안에서 실행되고 코드와 요청을 살펴볼 수 있음. 하드웨어 일부를 사실상 별도의 통제 구역으로 떼어 주지도 않음. EME는 예외지만 별개의 주제이고, 은행이 그것까지 쓰기 시작하면 역시 반대할 것임.
너무 복잡하게 생각하는 것일 수 있음. 대부분은 휴대전화의 편의성을 원하고, 은행 업무에서 한 단계만 줄여줘도 앱을 쓸 가능성이 큼.
별도 인증 수단이 필요하다는 데는 동의함. 휴대전화 보유를 강제한다면 문제가 되겠지만, 그건 별개의 사안임.
보안과 하드웨어 무결성 증명에 그렇게 집착하는 앱들에 메모리 손상 버그와 잘못 구현된 변조 방지 코드가 많아서 앱별 익스플로잇 방어 호환 모드를 켜야 한다니, 역설적임.
실제 보안보다는 규정 준수 체크리스트 채우기가 주목적이기 때문임.
본문의 링크에는 지원 은행이 수백 곳 나오는데, 제목은 왜 “열두 곳”인지?
지원되는 앱 중 얼마나 많은 것이 은행 내부에서 자신이 좋아하는 모바일 OS를 지원하고 싶은 개발자들 덕분인지 궁금함.