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

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

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

쿠키는 사용자의 브라우저에, 세션은 서버에 저장된다는 점에서 근본적으로 다릅니다. 이 차이 하나가 로그인 상태 유지 방식부터 보안 수준까지 완전히 바꿔놓습니다. 제가 처음 이 개념을 접했을 때는 "둘 다 로그인 유지에 쓰이는 거 아닌가?"라고 생각했는데, 직접 웹 개발을 하면서 이 둘이 완전히 다른 역할을 한다는 걸 체감했습니다. 브라우저를 닫았는데 로그인이 유지되는 사이트가 있고, 5분만 방치해도 로그아웃되는 사이트가 있는 이유도 여기에 있습니다.

브라우저 저장

쿠키(Cookie)는 사용자의 컴퓨터, 정확히는 브라우저에 저장되는 작은 텍스트 파일입니다. 로그인 정보, 장바구니 내용, 언어 설정 같은 데이터를 담아두고 다음 방문 시 재사용합니다. 쉽게 말해 브라우저가 "이 사람 지난번에 이런 걸 선택했었지"라고 기억하는 메모장인 셈입니다.

제가 쇼핑몰 사이트를 운영할 때 경험한 건데, 쿠키 덕분에 사용자가 장바구니에 담아둔 상품이 며칠 뒤에도 그대로 남아 있었습니다. 브라우저를 껐다 켜도 쿠키는 유지되기 때문입니다. 하지만 이게 양날의 검이더군요. 공용 컴퓨터에서 쿠키를 삭제하지 않고 나가면 다음 사람이 제 로그인 정보를 그대로 볼 수 있으니까요.

쿠키에는 만료 시간(Expiration Date)을 설정할 수 있습니다. 이 시간을 길게 잡으면 "자동 로그인"처럼 작동하고, 짧게 잡으면 브라우저를 닫으면 바로 사라집니다. 실제로 은행 사이트들은 보안상 쿠키 만료 시간을 극도로 짧게 설정해서, 조금만 방치해도 다시 로그인하라고 요구합니다(출처: 한국인터넷진흥원).

서버 관리

세션(Session)은 서버 메모리나 데이터베이스에 저장되는 사용자 상태 정보입니다. 사용자가 로그인하면 서버가 고유한 세션 ID를 생성하고, 이 ID만 쿠키로 브라우저에 전달합니다. 민감한 정보는 서버에만 남기고, 브라우저에는 "열쇠" 역할만 하는 ID만 주는 겁니다.

이 구조를 처음 알았을 때 "왜 이렇게 복잡하게 나눠놨지?"라고 생각했습니다. 그런데 직접 서비스를 운영해보니 이해가 됐습니다. 쿠키만 쓰면 브라우저에 비밀번호 같은 민감 정보를 그대로 저장해야 하는데, 그러면 해킹 위험이 너무 큽니다. 세션을 쓰면 브라우저에는 의미 없는 문자열만 남고, 실제 정보는 서버가 지키니까 훨씬 안전하죠.

세션의 핵심은 "서버가 주도권을 쥔다"는 점입니다. 서버가 세션 유지 시간(Session Timeout)을 정하고, 시간이 지나거나 사용자가 로그아웃하면 서버에서 세션을 삭제합니다. 이때 브라우저에 남은 세션 ID는 아무 쓸모가 없어집니다. 제가 운영하던 커뮤니티 사이트에서 30분 무응답 시 자동 로그아웃되게 설정했는데, 이게 바로 세션 타임아웃 기능이었습니다.

로그인 유지

쿠키와 세션은 따로 쓰이는 게 아니라 함께 작동합니다. 로그인 유지 과정을 단계별로 보면 이렇습니다.

  1. 사용자가 아이디와 비밀번호를 입력해 로그인 요청을 보냅니다.
  2. 서버가 정보를 확인하고 세션을 생성한 뒤, 세션 ID를 쿠키로 브라우저에 전달합니다.
  3. 이후 페이지를 이동할 때마다 브라우저는 자동으로 쿠키(세션 ID)를 서버에 보냅니다.
  4. 서버는 받은 세션 ID로 해당 사용자의 세션 정보를 조회해 로그인 상태를 확인합니다.
  5. 브라우저를 닫거나 일정 시간이 지나면 세션이 만료되고, 다시 로그인이 필요해집니다.

이 구조를 이해하고 나니 "왜 이 사이트는 자주 로그아웃되지?"라는 불만이 합리적으로 보이기 시작했습니다. 보안이 중요한 금융 사이트는 세션 타임아웃을 5분으로 잡고, 일반 커뮤니티는 30분, 쇼핑몰은 쿠키 만료를 30일로 설정하는 식으로 목적에 맞게 조절하더군요.

공용 PC에서 포털 사이트에 로그인한 뒤 쿠키를 삭제하지 않고 나간 적이 있습니다. 나중에 확인해보니 그대로 로그인돼 있었습니다. 서버에 세션은 남아 있고, 브라우저에도 쿠키가 살아 있으니 당연한 결과였죠. 그때부터 공용 PC에서는 로그아웃과 쿠키 삭제를 반드시 함께 하게 됐습니다.

보안과 편의성의 균형

쿠키와 세션을 단순한 기술 개념으로만 보면 안 됩니다. 이 둘의 설정 방식은 서비스가 사용자를 얼마나 신뢰하고, 보안과 편의성 중 어디에 무게를 두는지 보여주는 지표입니다. 은행 앱이 30초만 방치해도 재인증을 요구하는 건 귀찮지만, 그만큼 제 돈을 지키려는 노력이라고 받아들이게 됐습니다.

HTTP 프로토콜(HyperText Transfer Protocol)은 기본적으로 상태를 유지하지 않는 무상태성(Stateless) 특징을 갖습니다. 쉽게 말해 서버가 "방금 전 요청한 사람이 누군지" 기억하지 못한다는 뜻입니다. 쿠키와 세션이 없으면 페이지 이동할 때마다 로그인해야 하는 불편함이 생깁니다. 이 문제를 해결하려고 고안된 게 바로 쿠키와 세션 메커니즘입니다(출처: W3C).

개인적으로 느낀 건, 서비스마다 쿠키와 세션 정책이 다른 이유는 사용자층과 목적이 다르기 때문이라는 겁니다. 쇼핑몰은 재방문율을 높이려고 쿠키를 길게 유지하고, 은행은 한 번의 실수로도 큰 피해가 생기니 세션을 짧게 설정합니다. 제가 운영하던 사이트에서도 처음엔 편의성을 위해 세션을 2시간으로 잡았다가, 보안 이슈가 생긴 뒤 30분으로 줄였습니다. 사용자 불만은 늘었지만 보안 사고는 확실히 줄었습니다.

결국 쿠키는 브라우저에 저장되는 정보고, 세션은 서버가 관리하는 상태라는 점에서 명확히 구분됩니다. 두 요소는 서로 보완하며 로그인 유지와 사용자 식별을 가능하게 합니다. 공용 컴퓨터를 쓸 때는 로그아웃과 쿠키 삭제를 함께 하는 습관이 필수입니다. 개인 기기라면 자동 로그인이 편리하지만, 중요한 금융 서비스는 짧은 세션 타임아웃과 추가 인증이 있는 게 오히려 안전합니다. 이 구조를 이해하고 나면 각 사이트의 로그인 정책이 왜 다른지, 어떤 선택이 합리적인지 스스로 판단할 수 있게 됩니다.

댓글

이 블로그의 인기 게시물

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

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