[태그:] 사이버안보

법원, 병원, 공항. 보안이 생명인 곳들이 같은 이유로 한꺼번에 뚫릴 뻔했다. 범인은 다름 아닌 웹 콘텐츠 관리 소프트웨어, 이른바 CMS의 취약점이었다. 전혀 관련 없어 보이는 수백 개 사이트가 알고 보니 같은 부품을 쓰고 있었고, 그 부품 하나에 구멍이 나 있었던 셈이다.

교훈은 명확하다. 홈페이지 보안은 서버 하나만 잘 지킨다고 끝나는 문제가 아니다. 내가 쓰는 소프트웨어 자체에 결함이 있을 수도 있다는 뜻이다. 중소기업이나 개인 블로그 운영자라면 ‘나랑 무슨 상관이냐’ 싶겠지만, 이런 공급망형 취약점은 개인 사이트까지 그대로 파고든다. 그래서 정리해봤다. 내 홈페이지가 어떤 CMS로 돌아가는지, 뭘 점검해야 하는지.

CMS, 대체 뭐길래 자꾸 뚫리나

CMS는 코드를 몰라도 홈페이지 콘텐츠를 올리고 관리할 수 있게 해주는 소프트웨어다. 워드프레스, 그누보드, XE, 제로보드 같은 것들이 대표적이다. 국내 관공서와 기업 상당수가 이런 오픈소스 혹은 상용 CMS 위에 사이트를 얹어 운영한다. 문제는 같은 CMS를 쓰는 사이트가 전 세계에 수만 개씩 존재한다는 점. 공격자 입장에서는 CMS 코드 한 곳의 취약점만 찾아내면, 그 CMS를 쓰는 사이트를 통째로 노릴 수 있다. 법원과 병원, 공항이 같은 취약점으로 묶이는 이유도 여기 있다. 좀 얄궂지 않나.

내 홈페이지, 위험한지 확인하는 법

점검, 생각보다 어렵지 않다. 아래 항목부터 하나씩 짚어보자.

• 사이트 하단이나 페이지 소스에 CMS 이름과 버전이 그대로 노출되는지 본다
• Wappalyzer, BuiltWith 같은 브라우저 확장 프로그램으로 사용 중인 기술 스택을 조회해본다
• KISA(한국인터넷진흥원) 웹 취약점 자동진단 서비스나 무료 스캐너로 기본 점검을 돌려본다
• 관리자 로그인 페이지 주소가 기본값(/wp-admin, /admin 등) 그대로인지 확인한다
• 최근 1년 사이 CMS나 플러그인을 업데이트한 적이 있는지 본다

이 중 두세 개 이상 걸린다면, 손볼 때가 된 거다.

국내에서 많이 쓰는 CMS, 뭐가 약할까

CMS 종류마다 약한 지점이 조금씩 다르다.

• 워드프레스 — 본체보다 서드파티 플러그인과 테마에서 취약점이 훨씬 많이 터진다. 안 쓰는 플러그인 방치가 제일 흔한 실수다
• 그누보드, 영카트 — 게시판 파일 업로드 기능으로 웹셸을 심거나 SQL 인젝션을 노리는 게 단골 공격 경로다
• 카페24, 고도몰 같은 호스팅형 솔루션 — 플랫폼 자체 보안은 업체 몫이지만, 부가 모듈이나 디자인 스킨에서 구멍이 생기곤 한다
• 자체 개발 게시판 — 유지보수 인력이 빠지면 몇 년째 방치되는 일이 많아 오히려 더 위험하다

지금 바로 손댈 수 있는 보안 조치

큰돈 안 들이고도 손댈 수 있는 것부터 정리하면 이렇다.

• CMS 본체와 플러그인, 테마를 최신 버전으로 유지한다
• 안 쓰는 플러그인과 테마는 비활성화 말고 아예 삭제한다
• 관리자 페이지 접근을 특정 IP나 VPN으로 묶어둔다
• 관리자 계정에는 2단계 인증(OTP)을 걸어둔다
• 웹 방화벽(WAF)을 앞단에 세우고, 전체 백업은 주기적으로 별도 저장소에 보관한다

손보고 끝나는 게 아니다, 정기 점검이 진짜

한 번 손보고 끝내면 다시 뚫린다. 월 1회 CMS와 플러그인 업데이트 여부를 확인하고, 서버 접속 로그와 관리자 로그인 이력을 훑어보는 습관이 필요하다. 예산에 여유가 있다면 Nikto나 OpenVAS 같은 무료 취약점 스캐너를 정기적으로 돌리거나, 1년에 한 번쯤은 외부 보안업체에 모의해킹(펜테스트)을 맡기는 것도 방법이다. 공공기관이나 금융권처럼 규모가 큰 조직은 이런 점검이 의무인 경우가 많지만, 중소 웹사이트는 이런 절차 자체가 아예 없는 곳이 대부분이다.

해킹당했다면, 초기 대응 3단계

이미 이상 징후가 보인다면, 순서대로 움직이는 게 낫다. 먼저 서버를 네트워크에서 떼어내 추가 피해를 막고, 접속 로그와 파일 변조 흔적부터 확보한다. 증거를 남긴 다음엔 KISA 118 상담센터나 한국인터넷진흥원 침해사고 신고 창구에 신고하고, 안전한 시점의 백업으로 복원한 뒤 원인이 된 취약점을 반드시 막고 나서 서비스를 다시 열어야 한다. 원인을 못 찾은 채 복구만 하면, 같은 구멍으로 또 뚫리는 일이 흔하다.

자주 나오는 질문 몇 가지

Q. 워드프레스는 원래 위험한 CMS인가요?
A. 워드프레스 자체보다 관리 소홀이 진짜 원인인 경우가 많다. 본체 업데이트는 자동으로 잘 되는 편인데, 방치된 플러그인이 사고를 친다.

Q. 방문자가 적은 작은 사이트도 표적이 되나요?
A. 트래픽 크기와 상관없이 자동화된 스캐너는 도메인을 가리지 않고 훑는다. ‘설마 내 사이트가’ 싶겠지만, 오히려 관리가 허술한 소규모 사이트가 더 쉬운 먹잇감이다.

Q. 무료 CMS와 유료 솔루션 중 뭐가 더 안전한가요?
A. 라이선스보다 업데이트 주기와 관리 인력 유무가 안전을 가른다. 무료라도 꾸준히 관리하면 유료 솔루션보다 낫다.

출처: TechCrunch

맥은 알아서 업데이트를 챙겨준다고 믿는 사람, 생각보다 많다. 그런데 막상 설정 앱을 열어보면 몇 달, 심하면 1년 가까이 구버전 macOS를 쓰고 있는 맥북이 꽤 흔하다. 업데이트 알림을 두어 번 미루다 보면 그대로 잊어버리기 십상이라서다. 문제는 미루는 사이에도 보안 패치는 계속 쌓인다는 점. 애플이 소노마, 세쿼이아, 타호 세 버전 모두에 화면 공유(Screen Sharing) 기능 취약점을 손보는 패치를 배포한 사례만 봐도, 구버전을 오래 쓰는 맥북일수록 이런 구멍이 방치될 가능성이 크다는 걸 알 수 있다.

업데이트, 왜 미루면 안 되나

보안 패치는 한 번에 몰아서 나오지 않는다. 애플은 최신 macOS뿐 아니라 한두 세대 이전 버전까지 같이 패치하는 경우가 많다. 지금 쓰는 macOS가 최신이 아니어도 보안 업데이트 대상에 들어갈 여지가 있다는 얘기다. 다만 이 지원, 영원히 가지는 않는다.

• 애플은 보통 최신 macOS와 직전 두 버전, 총 3개 버전까지만 보안 패치를 지원한다
• 지원이 끊긴 구버전은 새 취약점이 나와도 패치를 못 받는다
• 화면 공유, 원격 로그인처럼 네트워크로 열려 있는 기능일수록 공격 표면이 넓어진다

결국 macOS 버전이 몇 세대 뒤처져 있다면, 업데이트 알림을 미룰 이유가 없다.

소프트웨어 업데이트 확인하는 법

맥에서 업데이트 확인하는 경로는 간단하다.

• 애플 메뉴(왼쪽 위 사과 아이콘) 클릭 → 시스템 설정 이동
• 왼쪽 사이드바에서 일반 선택 → 소프트웨어 업데이트 클릭
• 업데이트가 있으면 버전 정보와 함께 설치 버튼이 뜬다
• 애플 메뉴에서 이 Mac에 관하여를 누르면 현재 macOS 버전과 빌드 번호도 바로 뜬다

업데이트 항목 옆 톱니바퀴 아이콘, 눌러보면 자동 업데이트 세부 옵션도 켜고 끌 수 있다.

소노마, 세쿼이아, 타호 — 이름 헷갈리는 사람들에게

macOS는 버전마다 캘리포니아 지명을 코드네임으로 쓴다. 순서로 정리하면 이렇다.

• macOS 14 = 소노마(Sonoma)
• macOS 15 = 세쿼이아(Sequoia)
• macOS 26 = 타호(Tahoe) — 애플이 버전 번호를 연도식으로 바꾸면서 15 다음이 바로 26이 됐다

숫자가 갑자기 훌쩍 뛰어서 헷갈리는 사람 많은데, 코드네임이랑 번호를 굳이 외울 필요는 없다. 업데이트 화면에 뜨는 이름과 번호, 그때그때 확인하면 그만이다.

자동 업데이트는 켜두는 게 맞을까

설정 안에는 업데이트 관련 토글이 여러 개 있는데, 성격이 조금씩 다르다.

• 보안 대응 및 시스템 파일 업데이트: 켜두길 추천한다. 사용자 개입 없이 조용히 설치되고 재부팅도 거의 안 요구한다
• Mac 자동 업데이트: macOS 정식 버전 자체를 자동 설치하는 옵션이다. 새 버전 초기엔 호환성 문제가 종종 터지니, 한두 주 지켜본 뒤 수동으로 올리는 편이 안전하다
• 앱 스토어 앱 자동 업데이트: 켜둬도 부담 없다

보안 패치는 자동으로, macOS 대규모 업그레이드는 반쯤 수동으로. 이 조합이 실제로 문제를 가장 적게 겪는 방식이다.

화면 공유, 안 쓰면 그냥 꺼두자

화면 공유(Screen Sharing)는 다른 맥이나 아이폰에서 내 맥 화면을 원격으로 보고 조작하는 기능이다. 재택 지원, 파일 서버 관리 같은 데는 쓸모 있지만, 켜둔 채로 방치하면 그 자체가 공격 지점이 된다. 애플이 이 기능 취약점을 패치한 사례도 있으니, 평소 안 쓴다면 꺼두는 편이 마음 편하다.

• 경로: 시스템 설정 → 일반 → 공유 → 화면 공유 토글 끄기
• 꼭 써야 한다면 접근 가능한 계정을 특정 사용자로 제한하고, 계정 비밀번호는 따로 강력하게 설정한다
• 공유기에서 포트 5900(VNC 기본 포트)을 외부로 열어둔 상태라면, 지금 확인해서 막는 게 낫다
• 원격 로그인(SSH), 파일 공유 등 다른 공유 기능도 안 쓰면 같이 꺼두는 게 원칙이다

업데이트가 안 될 때, 이 순서로 확인

업데이트 버튼을 눌러도 진행이 안 되거나 중간에 멈추는 경우, 아래 순서로 점검하면 대부분 풀린다.

• 저장 공간 확인: macOS 업데이트는 용량을 꽤 차지한다. 최소 20GB 이상 여유 공간을 확보해두자
• 와이파이 대신 유선 연결: 대용량 다운로드는 유선 인터넷이 훨씬 안정적이다
• 관리자 계정으로 로그인: 일반 사용자 계정으로는 시스템 업데이트 설치가 막히는 경우가 있다
• 디스크 공간이 충분한데도 멈춘다면 시스템 설정 → 일반 → 저장 공간에서 업데이트 파일 캐시를 지우고 다시 시도한다
• 그래도 안 되면 복구 모드(전원 버튼 길게 누르기)로 들어가 macOS를 재설치하는 게 마지막 수단이다

핵심만 3줄로 정리하면

보안 관련 업데이트는 자동으로 켜두고, 화면 공유처럼 네트워크로 열려 있는 기능은 안 쓰면 끈다. macOS 코드네임이나 버전 번호는 외울 필요 없이, 업데이트 알림이 뜨면 그때 확인하고 바로 진행하면 된다. 이 세 가지만 지켜도 오래된 취약점 때문에 뒤통수 맞을 일, 크게 줄어든다.

엔가젯이 전한 소식이다. 원문 링크는 여기에 걸어둔다.

초록색 말풍선 하나 때문에 단체방에서 은근히 붕 뜨는 기분. 안드로이드 쓰는 사람이라면 다들 한 번쯤 겪어봤을 거다. 사진 화질은 깨지고, 읽음 표시도 안 뜨고, 리액션은 이상한 텍스트로 바뀌어서 도착한다. 아이폰과 안드로이드가 섞인 단톡방에서 흔히 벌어지는 일이다. 이 문제를 풀어보겠다고 나선 서드파티 앱이 몇 개 있는데, 방식도 리스크도 저마다 달라서 제대로 알고 골라야 한다.

그린버블 문제, RCS로도 왜 안 사라지나

애플과 구글이 RCS(Rich Communication Services) 지원을 넓히면서 문자 경험은 예전보다야 나아졌다. 고화질 사진, 읽음 확인, 타이핑 표시 정도는 이제 아이폰과 안드로이드 사이에서도 어느 정도 작동한다. 근데 RCS는 어디까지나 SMS의 업그레이드판이다. 아이메시지 특유의 반응(하트, 느낌표 리액션), 메시지 수정·취소, 이펙트, 종단간 암호화 수준의 통합 경험까지는 못 따라간다. 애플이 아이메시지를 안드로이드에 공식 개방할 계획이 없다 보니, 그 틈을 서드파티 개발사들이 메우고 있는 셈이다.

안드로이드에서 아이메시지 받는 방법 3가지

• Sunbird·Beeper 계열 앱: 맥이나 아이폰을 중계 서버로 써서 아이메시지를 안드로이드로 넘겨주는 구독형 서비스다. 월 몇 달러 수준 요금을 받는다.
• AirMessage: 오픈소스 기반이라 집에 있는 맥에 서버를 직접 깔아 쓰는 방식. 요금은 안 들지만 맥을 계속 켜둬야 하고, 초기 설정도 꽤 까다롭다.
• 맥 원격 접속: 크롬 리모트 데스크톱 같은 걸로 맥의 메시지 앱을 아예 원격 조작하는, 말 그대로 원시적인 방법이다. 번거롭다. 그래도 가장 투명하긴 하다.

방법마다 장단점이 이렇게 다르다

구독형 서비스는 설치가 간편하고 화면도 깔끔하다. 근데 개발사 서버를 거쳐서 메시지가 오간다는 게 좀 찜찜하다. 솔직히 여기서 갈린다. 실제로 애플은 2023년 말 비퍼 미니(Beeper Mini)를 서버 차단으로 무력화시킨 전례가 있다. 언제든 같은 일이 반복될 여지가 있다는 뜻이다. AirMessage는 데이터가 내 소유의 맥을 거치니까 상대적으로 믿음이 가지만, 맥을 계속 켜둬야 하는 전기세와 관리 부담은 그대로 따라온다. 원격 데스크톱 방식은 속도가 느리고 알림 연동도 불편해서, 매일 쓰기엔 무리다.

RCS만 있으면 충분한 거 아닌가

결론부터 말하면, 아니다. RCS는 구글이 주도하는 표준이다 보니 아이폰 쪽에서 완전한 지원을 보장하지 않는다. 그룹 채팅에서 리액션이 텍스트로 깨지는 문제, 반응 아이콘이 제대로 안 뜨는 문제는 RCS로도 완전히 해결 안 된다. 암호화 수준도 아이메시지 대 아이메시지 통신에는 못 미친다. 아이폰 비중이 높은 지역, 이를테면 미국에서 안드로이드 유저가 느끼는 소외감은 RCS 도입만으로 크게 줄어들지 않는다.

써도 안전할까? 보안과 애플 정책 리스크

서드파티 브리지 앱을 쓸 때 제일 먼저 따져야 할 건 내 애플 계정 정보가 어디로 흘러가는가다. 일부 서비스는 사용자의 애플 ID를 자체 서버에 등록된 가상 기기로 로그인시키는 구조를 쓴다. 이 과정에서 계정이 정지되거나, 서비스가 문 닫는 순간 메시지 기록에 아예 접근 못 하게 되는 사례도 나온 적 있다. 회사 업무용 계정이나 민감한 대화를 주고받는 계정이면, 이런 방식은 피하는 게 낫다. 반대로 개인 소유 맥을 서버로 쓰는 AirMessage류는 데이터가 제3자 서버를 거치지 않으니 상대적으로 안심하고 쓸 수 있다.

결국 뭘 골라야 하나

맥이 있고 손재주도 있다면 AirMessage를 직접 설치하는 쪽이 제일 안전하고 돈도 안 든다. 맥이 없거나 설정이 번거롭게 느껴진다면 구독형 서비스를 쓰되, 서비스가 언제 막힐지 모른다는 점은 감안해야 한다. 놓치면 곤란한 대화는 다른 채널에도 백업해두는 습관을 들이는 게 좋다. 상대방이 아이폰 유저 한두 명뿐이라면, 굳이 복잡한 앱을 깔기보다 RCS 설정만 제대로 켜두는 걸로 충분한 경우도 많다.

이것도 궁금하죠?

Q. 아이메시지 브리지 앱, 애플 계정 정지 위험은 없나?
드물지만 사례는 있다. 여분 계정이나 테스트 계정으로 먼저 써보고, 문제없으면 본계정으로 옮기는 걸 추천한다.

Q. 무료로 쓸 방법은 없나?
AirMessage는 무료다. 다만 맥이 꼭 있어야 한다. 맥이 없으면 사실상 유료 구독을 피하기 어렵다.

Q. RCS 설정은 어디서 켜나?
안드로이드는 메시지 앱 설정에서, 아이폰은 설정 > 메시지 > RCS 메시징 항목에서 켤 수 있다.

출처: The Verge

위치 권한, 딱 한 번 눌러서 허용했을 뿐인데. 그 사이 내 동선 정보가 어느 광고 회사 서버에 차곡차곡 쌓이고 있다면 기분이 어떨까. 전자프런티어재단(EFF) 조사에서 실제로 이런 사례가 여러 건 확인됐다. 더 황당한 건, 앱을 만든 개발자조차 이 사실을 모르는 경우가 적지 않다는 점이다. 앱에 심어둔 광고 SDK나 분석 라이브러리가 사용자 모르게, 심지어 개발자도 모르는 사이에 위치 데이터를 긁어다 제3자에게 넘기는 구조 때문이다. 테크크런치가 최근 이 문제를 짚었는데, 그 내용을 바탕으로 내 폰에서 위치 정보가 새고 있는지 확인하고 막는 방법을 정리해봤다.

권한은 앱에 줬는데, 데이터는 왜 광고사로 흘러가나

안드로이드 앱을 만들 때 개발자가 코드를 처음부터 끝까지 직접 짜는 경우는 드물다. 광고를 붙이거나 사용자 행동을 분석하거나 크래시를 리포트하는 기능, 이런 건 대부분 서드파티 SDK(소프트웨어 개발 키트)를 가져다 쓴다. 문제는 이 SDK가 앱 전체에 부여된 권한을 그대로 물려받는다는 데 있다. 사용자가 위치 정보 허용을 누르면, 그 앱 안에 얹혀 있는 광고 SDK도 똑같이 위치 정보에 접근하게 된다.

개발자 입장에서는 지도 기능이나 배달 앱처럼 실제로 필요해서 권한을 요청한 건데. 정작 그 데이터를 실어 나르는 건 개발자가 통제하지 못하는 외부 코드인 셈이다. 광고 네트워크는 이렇게 모은 위치 데이터를 사용자 프로필과 엮어서 타겟 광고에 쓰거나, 데이터 브로커에 되팔기도 한다. 개발자도 모르는 새 벌어지는 일이라니, 씁쓸하다.

내 폰에서 위치 권한 준 앱, 한눈에 보기

안드로이드라면 설정 → 위치 → 앱 위치 권한 순서로 들어가보자. 어떤 앱이 위치 정보에 접근 가능한지 목록으로 뜬다. 여기서 체크할 부분은 이거다.

• 손전등, 계산기처럼 위치가 전혀 필요 없는 앱이 권한을 갖고 있는지
• 설치만 해두고 안 쓰는 앱이 여전히 권한을 쥐고 있는지
• 같은 카테고리 앱인데 유독 권한이 많은 앱이 있는지

구글 플레이 스토어 앱 상세 페이지의 데이터 보안 섹션에서도 해당 앱이 위치 데이터를 제3자와 공유하는지 표시해준다. 설치 전에 한 번씩 훑어보는 습관, 들이면 좋다.

‘항상 허용’과 ‘앱 사용 중에만’, 뭐가 다른가

위치 권한을 켤 때 보통 선택지가 세 개 뜬다.

• 항상 허용 — 앱을 꺼놔도 백그라운드에서 계속 위치를 추적한다
• 앱 사용 중에만 허용 — 화면에 앱이 떠 있을 때만 위치에 접근한다
• 이번만 허용 — 한 번 쓰고 나면 권한이 자동으로 풀린다

배달 앱이나 내비게이션처럼 실시간 위치가 꼭 필요한 경우가 아니라면, 앱 사용 중에만 허용으로 낮춰두는 편이 안전하다. 백그라운드 위치 추적은 사용자가 앱을 켰는지조차 모르는 사이에 데이터를 쌓는다. SDK가 몰래 위치를 넘기는 구조에서 제일 큰 구멍이 바로 이 지점이다.

광고 ID 재설정, 추적 끊어내는 법

안드로이드에는 앱마다 다른 개인정보 대신, 광고사가 사용자를 식별할 때 쓰는 광고 ID라는 게 있다. 이 값이 그대로 유지되면 여러 앱에서 모은 위치 데이터가 하나의 프로필로 묶일 위험이 생긴다. 설정 → 구글 → 광고 경로로 들어가면 광고 ID를 삭제하거나 새로 발급받을 수 있다. 완전히 막는 방법은 아니다. 다만 기존에 쌓인 프로필과의 연결고리는 끊어내는 효과가 있다.

최근 안드로이드 버전에서는 광고 ID를 아예 꺼버렸을 때 앱들이 대체 식별자를 못 쓰게 막는 옵션도 추가됐다. 메뉴 이름은 기기 제조사나 OS 버전마다 조금씩 다를 수 있으니 참고하자.

위치정보 요구하는 앱, 걸러내는 나만의 기준

설치 전이든 후든, 아래 체크리스트로 한 번씩 걸러보면 도움이 된다.

• 앱의 핵심 기능과 위치 권한 요청이 실제로 맞물리는지 (손전등 앱이 위치를 요구하면 일단 의심)
• 리뷰나 개발자 정보에 낯선 SDK, 과도한 트래커 관련 언급이 있는지
• 구글 플레이 프로텍트, 프라이버시 대시보드에서 최근 권한 사용 이력을 확인했는지
• 비슷한 기능의 앱이 여러 개라면, 요청 권한이 적은 쪽을 고르는지

안드로이드 13 이상이면 설정 → 개인정보 보호 → 프라이버시 대시보드에서 최근 24시간 동안 어떤 앱이 위치 정보에 몇 번 접근했는지 그래프로 확인된다. 생각보다 자주 들락거리는 앱을 발견하면, 그 자리에서 권한을 낮추면 그만이다.

아이폰이라고 완전히 안심할 건 아니다

iOS는 앱 추적 투명성(ATT) 정책 덕분에 광고 목적의 추적을 앱마다 따로 허용받아야 한다. 구조적으로는 확실히 더 촘촘한 편. 다만 위치 권한 자체를 준 다음에는, 그 안에 포함된 SDK가 데이터를 수집하는 구조는 안드로이드와 크게 다르지 않다. 설정 → 개인정보 보호 및 보안 → 위치 서비스에서 앱별 권한을 확인하고, 화면 하단 시스템 서비스 항목에서 ‘중요한 위치’ 같은 백그라운드 추적 기능도 따로 꺼두면 된다.

자주 나오는 질문들

Q. 위치 권한을 다 꺼버리면 앱이 안 돌아가나?
지도, 내비게이션, 배달처럼 위치가 핵심 기능인 앱은 권한을 꺼두면 제대로 작동하기 어렵다. 그 외 대부분 앱은 위치 없이도 아무 문제 없이 돌아간다.

Q. VPN을 쓰면 위치 정보 수집을 막을 수 있나?
VPN은 인터넷 접속 위치, 그러니까 IP 기반 위치를 가려주는 거지, 앱이 GPS나 와이파이로 직접 수집하는 위치 권한 데이터까지 막아주진 않는다. 완전히 별개의 문제로 봐야 한다.

Q. 권한을 껐다가 필요할 때 다시 켜도 되나?
물론이다. 평소엔 꺼두고 내비게이션처럼 위치가 꼭 필요한 순간에만 켰다가 다시 끄는 방식, 이게 제일 안전하다.

출처: TechCrunch

APK 파일 하나 받아서 설치하는 것, 이제 예전처럼 쉽지 않다. 구글이 안드로이드 개발자 신원 확인 정책을 넓히면서, 플레이 스토어 밖에서 앱을 깔 때도 개발자 인증 여부부터 따지게 됐다. 이른바 사이드로딩 얘기다.

사이드로딩이 뭔지부터 짚고 가자

사이드로딩은 구글 플레이 스토어나 원스토어 같은 공식 마켓을 거치지 않고 APK 파일을 직접 받아서 기기에 깔아버리는 방식이다. 베타 테스트 앱, 국가 제한 때문에 스토어에 안 올라온 앱, 회사 내부 업무용 앱… 이런 걸 설치할 때 많이 쓴다. iOS는 처음부터 막혀 있었지만 안드로이드는 초창기부터 이걸 허용해왔다. 그리고 이 자유로움이 안드로이드를 안드로이드답게 만드는 특징이었다.

구글 개발자 인증, 뭘 요구하나

구글이 새로 도입한 개발자 인증(Developer Verification) 제도는 간단히 말해 이거다. 플레이 스토어에 앱을 안 올리는 개발자라도 정부 발급 신분증 같은 걸로 신원을 등록하라는 것. 인증 안 받은 개발자가 만든 앱은 설치가 아예 막히거나, 최소한 경고 화면을 거쳐야 한다. 문제는 여기서 시작된다. 취미로 앱 만들어서 친구들끼리 나눠 쓰던 개발자, 오픈소스 프로젝트 하나 배포하던 소규모 팀까지 전부 이 절차를 밟아야 한다. 반발이 안 나올 수가 없다.

왜 굳이 이렇게까지 하나

구글 쪽 설명은 명확하다. 악성 앱 차단. 가짜 은행 앱, 스미싱 문자에 딸려오는 앱, 스파이웨어. 상당수가 사이드로딩 경로로 퍼진다는 게 근거다. 개발자 신원만 확인되면 악성코드 뿌린 계정 추적이 훨씬 쉬워진다는 논리다. 틀린 말은 아니다. 근데 부작용도 만만찮다. 소규모 개발자와 오픈소스 커뮤니티 입장에서는 신원 등록 자체가 진입 장벽이다. 결국 안드로이드 생태계가 갖고 있던 자유도가 그만큼 줄어드는 셈이다.

쿠바, 이란은 왜 예외일까

이 정책에서 눈에 띄는 대목 하나. 미국 수출 제재 대상 국가는 예외로 뒀다는 점이다. 쿠바, 이란, 북한처럼 미국 상무부 제재 목록에 오른 나라 사용자들은 애초에 구글 서비스를 정식으로 쓰기가 어렵다. 개발자 인증 시스템에 접근할 방법 자체가 없다는 뜻이다. 그래서 구글은 이 지역만큼은 예전처럼 인증 없이 APK 설치를 그대로 놔두기로 했다. 아이러니하다. 제재국 일반 사용자는 오히려 규제 강화의 영향을 안 받는데, 그 나라에서 앱 만들어서 해외로 내보내려는 개발자는 인증 절차에서 사실상 빠지게 되는 처지다.

그래서 지금도 APK 설치는 되나 — 단계별로

정책이 바뀌었다고 사이드로딩 자체가 사라지는 건 아니다. 기기별로 방법을 정리하면 이렇다.

• 설정 진입: 설정 → 보안(또는 애플리케이션) → 출처를 알 수 없는 앱 설치 메뉴로 들어간다
• 앱별 권한 부여: 안드로이드 8 이상은 APK 설치할 브라우저나 파일관리자 앱마다 개별로 권한을 줘야 한다
• APK 다운로드: 믿을 만한 출처에서 받는다. 개발자 공식 깃허브, 공식 홈페이지가 우선이다
• 플레이 프로텍트 검사: 설치 전후 자동 스캔 켜두면 알려진 악성코드 패턴은 걸러낸다
• 제조사별 차이: 삼성은 ‘앱 설치 제한’이라는 이름으로, 샤오미는 ‘MIUI 보안센터’ 안에 따로 들어있는 식이라 기기마다 메뉴명이 조금씩 다르다

일반 사용자가 챙길 건 이 정도

당장 이 정책 때문에 뭘 바꿔야 할 필요는 별로 없다. 다만 출처 불분명한 사이트, ‘무료 프리미엄 버전’ 내세우는 커뮤니티 자료는 피하는 게 낫다. 설치 전에 앱이 요구하는 권한 목록 한 번쯤 훑어보는 습관도 들이면 좋다. 손전등 앱인데 연락처나 SMS 접근을 요구한다? 이런 건 의심해봐야 한다. 은행이나 결제 앱은 무조건 공식 스토어나 은행 홈페이지 링크로만 설치하고, 지인이 카톡으로 보낸 APK 파일은 한 번 더 출처를 확인하고 까는 게 안전하다.

이것도 궁금하죠?

Q. 플레이 스토어에서만 앱을 받으면 개발자 인증과 무관한가?
A. 맞다. 플레이 스토어에 올라온 앱은 이미 구글의 개발자 등록·심사 절차를 거친 상태라 따로 신경 쓸 게 없다. 인증 이슈는 스토어 밖에서 APK를 직접 받을 때만 해당한다.

Q. 회사 업무용 사내 앱도 인증받아야 하나?
A. 기업 자체 배포 방식은 보통 별도 예외 트랙이 마련돼서 일반 소비자용 앱과는 절차가 다르다. 회사 IT 부서에 확인하는 게 확실하다.

Q. 인증 안 된 앱은 아예 못 까나?
A. 완전 차단보다는 경고 화면 거치는 단계적 제한이 먼저 적용되는 구조다. 다만 정책이 지역별로 순차 확대되는 중이라 시기와 국가에 따라 체감 강도는 다를 수 있다.

출처: Ars Technica

초등학생 자녀 스마트폰에 게임 하나 깔았다고 성인 인증 화면부터 뜬 적, 있을 거다. 반대로 나이 제한 걸린 앱인데 확인 한 번 없이 술술 깔리는 경우도 많다. 이상하게 뒤죽박죽이다. 구글이 플레이 연령 신호(Play Age Signals) API를 전 세계 안드로이드 개발자에게 열었다. 앱에 개인정보를 넘기지 않고도 사용자 연령대만 전달하는 방식이 이제 표준처럼 자리 잡는 분위기다. 이 기술이 실제로 뭘 바꾸는지, 그리고 지금 당장 안드로이드 폰에서 자녀 보호 설정을 어떻게 하면 되는지 실전 위주로 정리해봤다.

앱 연령 제한, 왜 갑자기 신경 쓰이나

미성년자 대상 서비스에 나이 확인 의무를 지우는 법, 전 세계적으로 늘고 있다. 소셜미디어, 게임, 채팅 앱 — 다 걸린다. 문제는 기존 방식이 너무 번거로웠다는 거다. 신분증을 스캔하거나 신용카드 정보를 입력하는 식이니 개인정보 유출 걱정부터 앞섰고, 앱마다 따로 인증해야 하니 사용자 쪽도 피곤했다. 그래서 나온 대안이 운영체제 차원에서 연령대 정보를 딱 한 번 등록해두고, 여러 앱이 필요할 때마다 그걸 참조하는 방식이다.

연령 신호 API, 쉽게 말하면 뭔가

구글 계정에 등록된 나이 정보를 근거로, 앱은 사용자의 정확한 생년월일 대신 연령 구간(13세 미만, 13~17세, 18세 이상 등)만 전달받는다. 그게 전부다. 앱 개발자는 실제 생일이나 신분증 사본을 따로 저장할 필요가 없어지고, 사용자도 앱마다 나이를 반복 인증할 일이 없다. 서명된 토큰 형태로 신호를 주고받아 위변조를 막는다는 것이 핵심이다. 게임 연령 등급 표시, 콘텐츠 필터링, 특정 기능 잠금 — 이런 데 두루 쓰인다.

패밀리 링크로 자녀 계정 세팅하기

자녀 스마트폰을 실제로 관리하려면 Family Link 앱부터 까는 게 순서다.

• 부모 스마트폰에 Family Link 설치 후 자녀용 구글 계정 생성
• 자녀 폰에서 해당 계정으로 로그인, 부모 승인 절차 진행
• 앱 설치 시 부모 승인 필수로 설정 가능
• 하루 사용 시간, 취침 시간대 앱 잠금 설정
• 위치 확인 기능도 함께 켜둘 수 있음

계정에 등록된 생년월일이 연령 신호의 기준이 된다. 그러니 처음 계정을 만들 때 나이를 정확히 넣어두는 게 나중에 골치 안 아프다.

플레이 스토어 콘텐츠 필터 켜는 법

Family Link 없이 간단히 막는 방법도 있다. 플레이 스토어 앱을 켜고 프로필 아이콘 → 설정 → 가족 → 상위 관리 순서로 들어가면 콘텐츠 등급별 필터가 나온다. 폭력성, 선정성, 도박 요소 있는 앱은 등급에 따라 검색 결과와 다운로드 화면에서 아예 안 보인다. 여기에 인앱 결제할 때 비밀번호를 요구하도록 걸어두면, 앱 자체 나이 제한과는 별개로 한 겹 더 막게 된다.

아이폰 스크린타임과 비교하면

애플도 스크린타임(Screen Time)과 패밀리 공유로 비슷한 기능을 주긴 하는데, 접근 방식은 꽤 다르다.

• 안드로이드: 계정 기반 연령 신호를 여러 앱이 공유하는 구조로 확장 중
• iOS: 기기 단위 콘텐츠 제한과 앱별 다운로드 승인이 중심
• 안드로이드는 API 개방으로 서드파티 앱도 연령대 정보를 직접 받음
• iOS는 애플 생태계 안 앱스토어 등급 체계에 더 기대는 편

둘 다 완벽하진 않다. 솔직히, 결국은 부모가 초기 설정을 얼마나 꼼꼼히 해두느냐에서 갈린다.

설정했는데 안 먹힐 때 체크리스트

연령 제한을 걸어놔도 뚫리는 경우, 은근히 많다. 이럴 땐 아래 순서대로 짚어보면 웬만하면 해결된다.

• 자녀 폰에 부모 계정으로 로그인된 보조 계정이 남아있는지 확인
• 웹 브라우저로 앱스토어를 우회 설치하는 경우가 있으니 브라우저 접근 제한도 함께 설정
• 기기 자체를 초기화하면 필터 설정이 풀리므로 초기화 권한도 부모 계정으로 제한
• 이미 설치된 앱은 사후에 등급 필터를 켜도 자동 삭제되지 않으니 수동 확인 필요

자주 묻는 질문 몇 가지

Q. 연령 신호를 켜두면 앱 개발사가 내 정확한 생일을 알게 되나?
아니다. 구간 정보만 넘어가고, 생년월일 원본은 구글 계정 안에 그대로 남는다.

Q. Family Link 없이 콘텐츠 필터만 켜도 충분한가?
앱 다운로드만 막는 정도면 이걸로 충분하다. 근데 사용 시간이나 결제까지 관리하고 싶다면 Family Link를 같이 쓰는 게 낫다.

Q. 성인인데 연령 확인 요청이 자꾸 뜨면 어떻게 하나?
구글 계정 설정에서 생년월일이 제대로 등록돼 있는지부터 확인해보자. 필요하면 계정 보안 설정에서 나이 정보를 다시 인증하면 풀린다.

출처: TechCrunch