앱은 왜 기기 정보를 수집할까? (호환성, 오류대응, 보안통제)

앱은 왜 기기 정보를 수집할까라는 질문은 개인정보와 보안에 대한 관심이 높아질수록 자주 제기됩니다. 많은 사용자가 앱을 설치하거나 실행할 때 기기 정보 접근 권한을 확인하지만, 그 목적과 구조를 정확히 이해하지 못한 채 동의하는 경우가 많습니다. 앱을 처음 설치할 때 뜨는 권한 요청 화면, 그냥 "허용" 누르신 적 있으시죠? 저도 그랬는데 어느 날 같은 앱인데 오래된 폰에서는 UI가 완전히 깨져서 나오는 걸 보고 나서야 궁금해졌습니다. 기기 정보를 수집한다는 게 도대체 어떤 의미인지, 단순한 추적인지 아니면 앱이 제대로 돌아가기 위한 필수 조건인지. 그 차이를 이해하면 권한 요청을 볼 때 훨씬 합리적인 판단을 내릴 수 있습니다. 기기 정보와 호환성: 앱이 내 폰 환경을 먼저 파악하는 이유 앱이 처음 실행될 때 가장 먼저 하는 일 중 하나가 기기 환경을 파악하는 겁니다. 운영체제 버전, 화면 해상도, 제조사 정보, 언어 설정 같은 것들이죠. 이걸 두고 "나를 감시하는 거 아니냐"고 보는 시각도 분명히 있습니다. 그런데 제가 직접 앱 개발 관련 커뮤니티를 들여다보면서 느낀 건, 이 정보들이 없으면 앱 자체가 정상 동작을 보장하기 어렵다는 점이었습니다. API 레벨(API Level)이라는 개념이 있습니다. 안드로이드 기준으로, 이는 운영체제 버전에 따라 앱이 사용할 수 있는 기능의 범위를 숫자로 표현한 것입니다. 예를 들어 특정 알림 기능이 API 레벨 26 이상에서만 동작한다면, 앱은 기기 정보를 읽어서 그 이하 버전에서는 아예 해당 기능을 비활성화하거나 다른 방식으로 대체합니다. 이걸 모르고 그냥 실행하면 앱이 강제 종료되거나 기능이 절반만 동작하는 상황이 생깁니다. 화면 해상도(Screen Resolution) 역시 마찬가지입니다. 화면 해상도란 가로와 세로 방향으로 표시할 수 있는 픽셀 수를 의미하며, 기기마다 천차만별입니다. 같은 앱이라도 해상도 정보 없이 고정 레이아웃으로만 구성하면 어떤 기기에서는 버튼이 ...
댓글 쓰기

앱은 왜 백그라운드에서 실행될까? (시스템 자원, 알림 유지, 사용자 설정)

앱은 왜 백그라운드에서 실행될까라는 질문은 배터리 소모나 데이터 사용량 문제를 겪어본 사용자라면 한 번쯤 떠올리게 되는 의문입니다. 저도 그랬습니다. 분명히 앱을 다 껐다고 생각했는데 다음 날 아침에 배터리가 20%밖에 안 남아 있는 걸 보고 멍했던 기억이 납니다. 알고 보니 앱을 껐다고 해서 진짜 꺼진 게 아니었습니다. 그때부터 백그라운드 실행이라는 개념을 제대로 파고들기 시작했습니다.

앱이 진짜로 꺼지는 순간은 언제일까

홈 버튼을 눌렀다고 앱이 종료된다고 생각하는 분들이 많습니다. 저도 그렇게 알고 있었습니다. 그런데 직접 겪어보니 이건 완전한 오해였습니다. 스마트폰 운영체제는 앱의 실행 상태를 단순히 '켜짐'과 '꺼짐' 두 단계로만 나누지 않습니다.

실제로는 포그라운드(Foreground) 상태, 백그라운드(Background) 대기 상태, 그리고 캐시(Cache) 상태라는 세 단계로 구분됩니다. 포그라운드란 사용자가 화면을 직접 보며 조작하는 상태를 뜻합니다. 백그라운드는 화면에서 사라졌지만 일부 작업이 계속 돌아가는 상태이고, 캐시는 메모리에는 남아 있지만 실제로 아무 동작도 하지 않는 대기 상태입니다.

운영체제는 이 세 단계를 끊임없이 오가며 앱을 관리합니다. 제가 처음 이걸 알았을 때 솔직히 이건 예상 밖이었습니다. 앱을 닫은 줄 알았는데 사실은 조용히 대기 중이었다는 사실이 당황스러웠습니다. 출처: Android Developers - 앱 수명 주기에 따르면 안드로이드는 시스템 자원 상황에 따라 앱의 프로세스를 자동으로 종료하거나 유지하는 방식으로 메모리를 관리합니다.

이 구조 덕분에 다시 앱을 열었을 때 처음부터 로딩하지 않아도 되는 것입니다. 빠른 전환 경험은 사실 이 캐시 상태가 만들어주는 효과입니다.

시스템 자원 관리, 생각보다 훨씬 치밀합니다

스마트폰은 배터리와 메모리라는 두 가지 유한한 자원을 가지고 있습니다. 만약 모든 앱이 아무 제약 없이 백그라운드에서 실행된다면 기기는 금세 과부하 상태에 빠질 것입니다. 그래서 운영체제는 앱 스케줄러(App Scheduler)를 통해 백그라운드 작업을 촘촘하게 통제합니다. 앱 스케줄러란 어떤 앱이 언제 CPU 자원을 사용할 수 있는지를 결정하는 시스템 내부 조율자를 뜻합니다.

많은 분들이 백그라운드 앱을 죄다 강제 종료하면 배터리가 오래 간다고 믿고 있는데, 제가 실제로 써봤더니 오히려 역효과가 나는 경우가 많았습니다. 강제 종료된 앱을 다시 실행할 때 CPU가 훨씬 더 많은 자원을 소모하기 때문입니다. 가볍게 대기 중인 상태보다 새로 켜는 것이 더 비효율적입니다.

앱이 백그라운드로 전환되면 운영체제는 해당 앱의 CPU 사용량을 대폭 제한합니다. 장시간 사용되지 않은 앱은 캐시 상태로 전환되고, 메모리가 부족해지면 자동으로 프로세스가 종료됩니다. 이 일련의 흐름을 메모리 관리 정책(Memory Management Policy)이라고 부르며, 쉽게 말해 운영체제가 필요에 따라 앱들의 우선순위를 매기고 자원을 재분배하는 규칙 체계입니다.

아래는 운영체제가 백그라운드 앱을 관리할 때 고려하는 주요 요소들입니다.

  1. 배터리 잔량 및 충전 여부: 잔량이 낮을수록 백그라운드 제한이 강화됩니다
  2. 앱의 최근 사용 빈도: 오래 사용하지 않은 앱은 자동으로 제한 대상에 포함됩니다
  3. 앱이 요청한 작업의 종류: 음악 재생처럼 사용자 경험과 직결된 작업은 우선적으로 허용됩니다
  4. 네트워크 상태: Wi-Fi 환경에서는 모바일 데이터 환경보다 동기화 작업이 더 자주 허용됩니다

이 기준들을 알고 나니 배터리 관리에 대한 접근 방식이 완전히 바뀌었습니다. 무조건 앱을 죽이는 게 능사가 아니라는 걸 직접 겪어보고 나서야 이해했습니다.

알림 하나가 오기까지 벌어지는 일들

카카오톡 메시지 알림이 울릴 때 저는 그냥 앱이 항상 켜져 있어서 오는 건 줄 알았습니다. 그런데 실제로는 완전히 다른 구조로 작동하고 있었습니다.

현대 스마트폰의 알림 시스템은 푸시 알림(Push Notification) 방식으로 동작합니다. 푸시 알림이란 앱이 직접 서버와 통신을 유지하는 대신, 운영체제 수준의 알림 채널을 통해 메시지를 수신하는 방식을 뜻합니다. 앱은 항상 서버와 연결을 유지할 필요가 없고, 서버에서 신호가 오면 운영체제가 해당 앱을 깨워 처리하게 합니다.

안드로이드는 FCM(Firebase Cloud Messaging), iOS는 APNs(Apple Push Notification service)라는 각각의 알림 인프라를 운영합니다. FCM이란 구글이 운영하는 클라우드 기반 메시지 전달 서비스로, 앱 개발자가 사용자 기기에 알림을 보낼 수 있도록 중계해주는 시스템입니다. 출처: Firebase 공식 문서 - Cloud Messaging에 따르면 FCM은 앱이 백그라운드에 있거나 종료된 상태에서도 알림 수신이 가능하도록 설계되어 있습니다.

이 구조 덕분에 앱이 배터리를 과도하게 소모하지 않으면서도 실시간에 가까운 알림 전달이 가능합니다. 배터리 최적화 설정을 건드리지 않은 앱들은 알림이 지연되는 경우가 거의 없었습니다. 반면 배터리 절약 모드에서 제한된 앱들은 메시지가 몇 분씩 늦게 오는 일이 종종 있었습니다.

사용자 설정으로 뭘 바꿀 수 있을까

백그라운드 실행은 사용자가 직접 제어할 수 있는 영역이기도 합니다. 설정 앱에 들어가면 앱별로 백그라운드 데이터 사용이나 배터리 최적화 예외 여부를 조절할 수 있습니다. 제가 이 설정을 처음 발견했을 때는 괜히 다 꺼놓으면 배터리가 엄청 오래 갈 것 같았습니다.

결론부터 말하면 절반은 맞고 절반은 틀렸습니다. 별로 안 쓰는 앱의 백그라운드 실행을 제한하면 분명히 배터리에 도움이 됩니다. 그런데 메신저나 이메일처럼 실시간성이 중요한 앱까지 제한하면 알림이 늦게 오거나, 앱을 다시 열 때 동기화에 시간이 걸리는 불편이 생깁니다.

배터리 최적화(Battery Optimization)란 운영체제가 사용 빈도가 낮은 앱의 백그라운드 동작을 자동으로 제한하는 기능입니다. 안드로이드 기준으로 '제한 없음', '최적화', '제한' 세 가지 옵션이 있으며, 앱의 성격에 따라 맞는 옵션을 선택하는 것이 중요합니다. 저는 은행 앱이나 배달 앱처럼 주문·결제 알림이 중요한 앱은 '제한 없음'으로, 잘 안 쓰는 게임 앱은 '제한'으로 설정해두고 있습니다. 이렇게 앱마다 다르게 관리하고 나서 배터리 하루 사용량이 체감상 20~30% 정도 늘어난 느낌이었습니다.

일반적으로 배터리 절약을 위해 백그라운드 실행을 모두 차단하면 좋다고 알려져 있지만, 제 경험상 그건 오히려 스마트폰 사용 경험 자체를 불편하게 만드는 선택이었습니다. 앱의 성격을 파악하고 선별적으로 설정하는 게 훨씬 현명합니다.

백그라운드 실행은 단순한 배터리 낭비 요인이 아닙니다. 운영체제가 치밀하게 설계한 자원 관리 체계 위에서 작동하는 기능이고, 덕분에 우리가 스마트폰을 자연스럽게 쓸 수 있는 것입니다. 다만 모든 앱을 동일하게 대우할 필요는 없습니다. 자주 쓰고 알림이 중요한 앱은 허용하고, 그렇지 않은 앱은 과감하게 제한하는 것이 실질적인 배터리 관리 전략입니다. 설정 한 번만 손봐도 하루 사용량이 눈에 띄게 달라질 수 있으니, 한 번쯤 직접 확인해보시길 권합니다.

--- 참고--- 
- Android Developers - 앱 수명 주기: https://developer.android.com/guide/components/activities/activity-lifecycle

- Firebase 공식 문서 - Cloud Messaging: https://firebase.google.com/docs/cloud-messaging

관련 글

앱 알림은 어떻게 전달될까?

댓글

댓글 쓰기

이 블로그의 인기 게시물

쿠키 삭제해도 괜찮을까? (로그인 유지, 사이트 설정, 브라우저 정리)

솔직히 말씀드리면, 저도 예전에는 쿠키를 삭제하는 게 뭔가 중요한 정보를 날려버리는 것처럼 느껴져서 망설였습니다. 로그인 정보가 사라지면 어쩌나, 혹시 계정 자체가 날아가는 건 아닐까 하는 막연한 불안감이 있었죠. 그런데 실제로 여러 번 삭제해보니 생각보다 별일 아니더군요. 이 글에서는 쿠키가 정확히 무엇인지, 삭제하면 어떤 일이 벌어지는지, 그리고 언제 삭제해도 안전한지 제 경험을 바탕으로 정리해드리겠습니다. 쿠키가 뭐길래 삭제를 고민하게 될까? 쿠키(Cookie)란 웹사이트가 사용자를 구분하기 위해 브라우저에 저장하는 작은 텍스트 파일을 말합니다. 쉽게 말해, 여러분이 어떤 사이트에 방문했을 때 그 사이트가 "아, 이 사람 전에도 왔었네"라고 알아볼 수 있게 해주는 메모지 같은 겁니다. 로그인 상태를 기억하거나, 장바구니에 담아둔 상품을 유지하거나, 언어 설정 같은 환경을 저장하는 역할을 합니다. 제가 처음 쿠키의 개념을 제대로 이해했을 때 든 생각은 "그럼 이게 내 컴퓨터에 있는 중요한 파일은 아니구나"였습니다. 실제로 쿠키는 여러분의 문서나 사진 같은 개인 파일과는 전혀 다릅니다. 단지 웹사이트 이용을 편리하게 만들어주는 보조 정보일 뿐이죠. 그래서 삭제해도 컴퓨터 자체에는 아무런 영향이 없습니다. 다만 쿠키가 쌓이다 보면 오래된 정보가 꼬이면서 문제를 일으킬 때가 있습니다. 로그인이 갑자기 풀린다거나, 사이트가 제대로 작동하지 않는다거나 하는 경우가 그렇습니다. 이럴 때 쿠키를 삭제하면 사이트가 처음 방문하는 것처럼 인식하면서 문제가 해결되는 경우가 많습니다. 쿠키를 삭제하면 로그인 정보가 정말 날아갈까? 이 질문이 많은 분들이 가장 궁금해하는 부분일 겁니다. 결론부터 말하면, 쿠키를 삭제하면 로그인 상태는 해제됩니다. 하지만 계정 자체가 사라지는 건 절대 아닙니다. 쿠키는 단지 "지금 이 브라우저에서 로그인되어 있다"는 상태를 기억하는 정보일 뿐이거든요. 제가 직접 실험해본 ...
자세한 내용 보기

비밀번호 저장 기능은 믿어도 될까?(브라우저 보안, 자동 로그인, 암호화)

비밀번호 저장할까요? 매번 로그인할 때마다 뜨는 이 알림을 무심코 눌러왔다면, 지금 당장 멈춰야 합니다. 저 역시 몇 년간 아무 생각 없이 허용 버튼을 눌렀습니다. 편하니까요. 그런데 어느 날 노트북을 잠깐 맡겼을 때, 제 계정이 아무런 확인 절차 없이 열리는 걸 보고 등골이 오싹했습니다. 그때부터 '이 기능, 정말 믿어도 되는 걸까?'라는 의문이 생겼습니다. 브라우저 보안, 어디까지 안전한가 브라우저의 비밀번호 저장 기능은 크게 두 가지 방식으로 작동합니다. 첫째, 입력한 계정 정보를 암호화(encryption)해서 로컬 기기에 보관합니다. 여기서 암호화란 평문 데이터를 특정 알고리즘을 통해 읽을 수 없는 형태로 변환하는 기술을 말합니다. 둘째, 브라우저 계정에 로그인한 상태라면 클라우드 서버와 동기화됩니다. 이론상으로는 안전해 보이지만, 문제는 '어떤 환경에서 쓰느냐'에 달려 있습니다. 제가 직접 테스트해본 결과, 크롬이나 엣지 같은 주요 브라우저는 AES-256 방식의 강력한 암호화를 적용합니다. AES-256은 현존하는 가장 강력한 암호화 표준 중 하나로, 군사·금융 분야에서도 쓰이는 방식입니다. 하지만 암호화가 완벽해도 기기 자체가 뚫리면 소용없습니다. 예를 들어 윈도우 로그인 비밀번호가 '1234'처럼 허술하거나, 기기 잠금을 아예 안 걸어둔다면 저장된 비밀번호는 그대로 노출됩니다. 실제로 제 지인 중 한 명은 회사 공용 PC에서 비밀번호 저장 기능을 켜놓았다가, 다른 동료가 실수로 그의 계정에 접속한 적이 있습니다. 브라우저는 자동으로 로그인 정보를 불러왔고, 그 동료는 아무런 악의 없이 메일함을 열었습니다. 다행히 큰 문제는 없었지만, 만약 민감한 업무 계정이었다면 어땠을까요? 이런 일이 생기는 이유는 브라우저가 '기기를 쓰는 사람=계정 주인'이라고 가정하기 때문입니다. 자동 로그인, 편리함의 대가는 자동 로그인(Auto-login)은 저장된 비밀번호를 바탕으로 사용자...
자세한 내용 보기

쿠키와 세션은 무엇이 다를까? (브라우저 저장, 서버 관리, 로그인 유지)

쿠키는 사용자의 브라우저에, 세션은 서버에 저장된다는 점에서 근본적으로 다릅니다. 이 차이 하나가 로그인 상태 유지 방식부터 보안 수준까지 완전히 바꿔놓습니다. 제가 처음 이 개념을 접했을 때는 "둘 다 로그인 유지에 쓰이는 거 아닌가?"라고 생각했는데, 직접 웹 개발을 하면서 이 둘이 완전히 다른 역할을 한다는 걸 체감했습니다. 브라우저를 닫았는데 로그인이 유지되는 사이트가 있고, 5분만 방치해도 로그아웃되는 사이트가 있는 이유도 여기에 있습니다. 브라우저 저장 쿠키(Cookie)는 사용자의 컴퓨터, 정확히는 브라우저에 저장되는 작은 텍스트 파일입니다. 로그인 정보, 장바구니 내용, 언어 설정 같은 데이터를 담아두고 다음 방문 시 재사용합니다. 쉽게 말해 브라우저가 "이 사람 지난번에 이런 걸 선택했었지"라고 기억하는 메모장인 셈입니다. 제가 쇼핑몰 사이트를 운영할 때 경험한 건데, 쿠키 덕분에 사용자가 장바구니에 담아둔 상품이 며칠 뒤에도 그대로 남아 있었습니다. 브라우저를 껐다 켜도 쿠키는 유지되기 때문입니다. 하지만 이게 양날의 검이더군요. 공용 컴퓨터에서 쿠키를 삭제하지 않고 나가면 다음 사람이 제 로그인 정보를 그대로 볼 수 있으니까요. 쿠키에는 만료 시간(Expiration Date)을 설정할 수 있습니다. 이 시간을 길게 잡으면 "자동 로그인"처럼 작동하고, 짧게 잡으면 브라우저를 닫으면 바로 사라집니다. 실제로 은행 사이트들은 보안상 쿠키 만료 시간을 극도로 짧게 설정해서, 조금만 방치해도 다시 로그인하라고 요구합니다( 출처: 한국인터넷진흥원 ). 서버 관리 세션(Session)은 서버 메모리나 데이터베이스에 저장되는 사용자 상태 정보입니다. 사용자가 로그인하면 서버가 고유한 세션 ID를 생성하고, 이 ID만 쿠키로 브라우저에 전달합니다. 민감한 정보는 서버에만 남기고, 브라우저에는 "열쇠" 역할만 하는 ID만 주는 겁니다. 이 구조를 처음 알았을 때 ...
자세한 내용 보기