본문으로 건너뛰기
피드

지메일 가입, 이제 QR 찍고 문자까지 보내야 할 수도

security 약 5분
vote
0
댓글
북마크

구글 계정 신규 가입 과정에서 QR 코드를 스마트폰으로 스캔하고, 사용자가 직접 구글로 문자를 보내는 방식의 전화번호 인증이 나타난다는 제보가 나왔다. 아직 모든 국가와 모든 가입 시나리오에 공통 적용되는지는 불확실하지만, 프록시 품질·위치·기기 상태 같은 위험 신호에 따라 인증 방식이 달라지는 것으로 보인다. 프라이버시를 중시하는 사용자 입장에서는 가상 SMS 번호 사용이 어려워지고, 기기·위치 정보 노출 우려도 커지는 변화다.

  • 1

    구글 계정 가입 시 QR 코드 스캔 뒤 사용자가 직접 SMS를 보내는 인증 흐름이 일부 사용자에게 나타남

  • 2

    이 방식은 SMS 수신 대행 서비스 사용을 막는 효과가 있어 익명 계정 생성이 더 어려워짐

  • 3

    국가별 적용 여부와 발동 조건은 명확하지 않고, 프록시·위치·기기 신호에 따라 달라질 가능성이 큼

  • 4

    SIM 실명 등록 국가에서는 전화번호 이력이 계정 식별성에 어떤 영향을 주는지도 쟁점으로 떠오름

ℹ️참고

> 이 내용은 공식 발표가 아니라 사용자 제보와 토론 기반임. 그래서 “전면 적용”이라기보다는 일부 조건에서 보이는 가입 흐름으로 보는 게 맞음.

  • 구글 계정 신규 가입 과정에서 이상한 인증 흐름이 보인다는 제보가 나옴 — QR 코드를 스마트폰으로 찍고, 사용자가 직접 구글에 SMS를 보내는 방식임

    • 기존 SMS 인증은 보통 “구글이 내 번호로 코드를 보내고 내가 입력”하는 식이었음
    • 이번 제보는 반대로 “내 폰이 구글 쪽으로 문자를 보내 번호를 증명”하는 형태라서, 프라이버시 커뮤니티에서 바로 반응이 터짐
  • 보안 명분은 있음 — 가짜 번호나 SMS 수신 대행 서비스를 써서 계정을 대량 생성하는 걸 더 어렵게 만들 수 있으니까

    • 글쓴이도 이 방식이 피싱이나 악용을 더 어렵게 만드는 논리는 인정함
    • 다만 SMSpool 같은 SMS 인증 대행 서비스를 막는 효과도 있어서, 익명 계정을 만들려는 사용자에게는 장벽이 확 올라감
  • 문제는 이게 단순한 “번호 확인”에서 끝나지 않을 수 있다는 점임

    • QR을 스마트폰으로 스캔하는 순간, 사용자는 브라우저·기기·위치·네트워크 상태 같은 추가 신호를 더 노출할 수 있다고 우려함
    • 특히 프록시나 VPN을 쓰는 사용자 입장에서는 “내 위치를 숨겼다고 생각했는데 스마트폰 쪽 신호로 다시 엮이는 거 아님?”이라는 의심이 생김
  • 적용 범위는 아직 불명확함 — 모든 국가에서 항상 뜨는 건 아닌 듯함

    • 토론 참여자에 따르면 어떤 때는 QR 코드가 뜨고, 어떤 때는 안 뜸
    • QR을 찍어도 어떤 경우엔 SMS 발송을 요구하고, 어떤 경우엔 요구하지 않는다고 함
    • 결국 프록시 품질, 접속 위치, 계정 생성 패턴, 기기 상태 같은 위험 점수 기반 시스템이 작동하는 것 같다는 추정이 나옴
  • SIM 실명 등록 국가에서는 더 찝찝한 질문이 생김

    • 예를 들어 이탈리아처럼 SIM 구매나 사용에 신분증 등록이 필요한 나라에서 잠깐 번호를 사서 구글 계정을 만들었다고 치자는 거임
    • 이후 인증 앱, YubiKey, 복구 코드까지 설정하고 SMS 없이 몇 달·몇 년 동안 계정을 쓰면, 구글이 그 초기 번호를 통해 실제 신원까지 추적할 수 있느냐는 질문이 나옴
    • 번호가 재할당된 뒤에도 통신사나 정부가 “과거 이 번호를 누가 썼는지” 기록을 보관하는지 국가별로 확인해야 한다는 얘기도 이어짐
  • “덤폰 쓰는 사람은 어쩌냐”도 꽤 현실적인 지적임

    • QR 스캔과 스마트폰 기반 인증을 전제로 하면, 의도적으로 피처폰을 쓰는 사람은 계정 생성 단계에서 막힐 수 있음
    • 보안 강화를 이유로 스마트폰 보유를 사실상 강제하는 건 접근성 측면에서 깔끔하지 않음
  • 개발자 입장에서 흥미로운 포인트는 계정 생성이 점점 “단일 인증값”이 아니라 “리스크 스코어링” 문제로 바뀌고 있다는 거임

    • 전화번호 하나만 보는 게 아니라, IP·프록시·국가·기기·브라우저·행동 패턴을 합쳐서 인증 강도를 다르게 거는 구조로 보임
    • 보안팀 입장에서는 당연한 방향인데, 사용자 입장에서는 어떤 조건 때문에 추가 인증이 걸렸는지 거의 알 수 없다는 게 문제임

중요

> 핵심은 “구글 가입에 SMS가 필요하다”가 아니라, 계정 생성 단계에서 전화번호·기기·위치 신호가 더 강하게 묶일 수 있다는 점임. 익명성이나 분리된 계정 운영을 기대하던 사용자에겐 꽤 큰 변화임.

이건 단순히 가입 UX가 귀찮아졌다는 얘기가 아니라, 대형 플랫폼이 계정 생성 단계에서 ‘번호 소유’와 ‘기기 신호’를 더 강하게 묶는 흐름으로 봐야 한다. 보안 명분은 이해되지만, 익명성·접근성·프라이버시를 포기하게 만드는 비용도 꽤 크다.

댓글

댓글

댓글을 불러오는 중...

security

AI 에이전트 보안, 이제 권한이 아니라 ‘실행 증거’ 싸움으로 간다

오페이크가 AI 에이전트의 ID, 실행 환경, 도구 호출, 정책 적용 여부를 암호학적으로 검증하는 오페이크 3.0을 공개했다. 핵심은 에이전트 매니페스트와 컨피덴셜 MCP라는 두 오픈소스 기술이며, 기밀 컴퓨팅과 서명된 실행 증거를 결합해 감사자나 규제기관도 독립적으로 확인할 수 있게 하는 방향이다. AI 에이전트가 업무 시스템과 데이터를 직접 만지는 시대에는 접근 권한보다 ‘무슨 일을 했는지 증명할 수 있느냐’가 더 중요해지고 있다.

security

취약점 제보가 더 이상 특별하지 않은 시대가 왔다

전 Go 보안팀 리드였던 필리포 발소르다가 LLM 이후 취약점 제보의 의미가 바뀌었다고 주장한다. 예전에는 희소한 통찰과 비공개 제보가 귀했지만, 이제는 잠재 취약점을 찾는 것보다 실제 영향도를 빠르게 가려내는 triage가 병목이라는 얘기다.

security

스패로우, AI가 만든 코드 취약점 잡는 ‘Sparrow MCP’ 출시

스패로우가 AI 코딩 에이전트가 생성한 코드의 보안 취약점과 사용된 오픈소스를 실시간으로 검사하는 보안 어시스턴트 ‘Sparrow MCP’를 출시했다. 핵심 기능은 취약점 분석과 소프트웨어 자재명세서(SBOM) 생성이며, 앤트로픽의 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI와 연결할 수 있다는 점이다. AI 코딩이 빨라질수록 보안 검증과 오픈소스 추적이 개발 파이프라인 안으로 더 깊게 들어오는 흐름이다.

security

오픈AI, 오픈소스 취약점 고치는 ‘패치 더 플래닛’ 시작

오픈AI가 트레일 오브 비츠와 함께 주요 오픈소스 프로젝트의 취약점을 AI로 찾고, 사람 검토를 거쳐 실제 패치까지 연결하는 프로그램을 시작했다. 파이썬, 고, cURL, 시그스토어, NATS 서버 같은 핵심 프로젝트가 초기 대상이고, 지금까지 수백 건의 보안 이슈와 수십 건의 병합된 패치가 나왔다. 핵심은 AI가 보안팀을 대체하는 게 아니라, 탐지·검증·패치·공개 조율을 빠르게 만드는 보조 엔진이라는 점이다.

security

오픈AI, 취약점 찾기부터 패치까지 돕는 ‘코덱스 시큐리티’ 공개

오픈AI가 사이버보안 이니셔티브 데이브레이크를 확대하면서 보안 전용 도구 코덱스 시큐리티와 GPT-5.5-사이버를 공개했다. 목표는 취약점 탐지에서 끝나는 게 아니라 검증, 위험도 평가, 패치 개발, 테스트, 배포까지 AI로 지원하는 것이다. cURL, Go, Python, Sigstore 등 30개 이상 오픈소스 프로젝트도 패치 지원 프로그램에 참여한다.