메타 스마트 안경 앱에 얼굴 인식 파이프라인이 통째로 들어있다

앱 안에 얼굴 인식 장치가 ‘거의 완제품’으로 들어있음

• 메타 스마트 안경의 동반 앱인 Stella 안드로이드 빌드 v273.0.0.21에서 온디바이스 얼굴 인식 파이프라인이 통째로 발견됨

  • 연구자가 확인한 구성은 얼굴 감지 모델, 얼굴 정렬 모델, 얼굴 임베딩 모델, 로컬 DB 스키마, 벡터 인덱스, 디스크 저장 경로, 알림 채널, 사용자용 ‘Connections’ 위젯까지 포함함
  • 그냥 모델 파일 몇 개가 들어있는 수준이 아니라, 각 부품이 서로 맞물려 실제 파이프라인으로 동작하는 구조였다는 게 포인트임

• 단, 연구자는 선을 꽤 명확히 그음. “메타가 지금 사용자 시야에 들어온 사람을 몰래 식별하고 있다”는 증거는 아님

  • 일반 계정에서는 사용자 UI가 보이지 않았고, 알림이 연결되는 화면도 현재 빌드에 없었음
  • 테스트 계정에서 메타 서버가 신원 데이터를 해당 DB로 푸시하는 장면도 관찰하지 못했다고 밝힘
  • 그래서 이 건의 정확한 표현은 “그런 일을 할 수 있는 장치가 앱 안에 조립돼 있고, 게이트 뒤에 있다”에 가까움

모델 3개와 2048차원 얼굴 지문

• 앱에는 얼굴 인식용 모델 3개가 들어있고, 전체 크기는 약 100MB 수준임

  • SCRFD 계열 모델은 얼굴 감지를 맡고, KPSAligner는 얼굴의 눈·코 같은 키포인트를 기준으로 정렬하는 역할로 보임
  • SFace 계열 모델은 얼굴을 숫자 벡터로 바꾸는 임베딩 모델임
  • 모델들은 메타의 에셋 전달 시스템인 NMLML을 통해 기기에 내려오는 ExecuTorch(.pte) 파일 형태였음

• 특히 SFace 변형이 꽤 큼. 공개 레퍼런스보다 훨씬 큰 형태로 보인다는 점이 흥미로움

  • 공개 SFace 레퍼런스는 대략 40MB, 출력은 128~512차원 쪽인데, Stella 안의 변형은 약 96MB이고 출력이 2048차원임
  • 2048차원 출력은 뒤에서 나오는 로컬 벡터 인덱스의 차원과 정확히 맞아떨어짐

• 얼굴 감지 모델이 있다고 해서 곧바로 “얼굴 인식”이라고 볼 수는 없음

  • 많은 카메라 앱이 자동 초점, 프레이밍, 얼굴 보정 같은 이유로 온디바이스 얼굴 감지를 씀
  • 그런데 여기서는 감지에서 끝나지 않고, 신원 매칭에 쓰는 얼굴 임베딩과 벡터 검색 DB까지 같이 발견됐다는 게 다름

로컬 DB가 얼굴 벡터 검색용으로 설계돼 있음

• 실제 파이프라인이 읽는 DB는 앱 내부의 RLDrive 동기화 영역 아래에 있음

  • 경로는 /data/user/0/com.facebook.stella/files/rldrive/person_profiles/objects.db
  • RLDrive는 메타의 크로스 디바이스 동기화 프레임워크이고, person_profiles라는 네임스페이스는 원격에서 채워질 수 있는 구조로 보임
  • 다만 연구자는 자신의 테스트 계정에서 이 네임스페이스로 실제 신원 데이터가 내려오는 건 보지 못했다고 함

• DB 스키마는 사람과 얼굴을 연결하고, 얼굴 벡터를 검색하는 구조임

  • person 테이블에는 nodeid, name, uri 같은 필드가 있음
  • face 테이블은 personUri로 사람을 가리키고, mediaPath를 얼굴 ID처럼 사용함
  • face_mediaPath_vec 가상 테이블은 sqlite-vec 기반이고, float[2048] 벡터를 코사인 거리로 검색하도록 만들어져 있음

• 이 조합은 꽤 노골적임

  • 앱 안의 SFace 모델 출력이 2048차원임
  • DB 인덱스도 정확히 float[2048]임
  • 얼굴 임베딩 비교에 흔히 쓰는 코사인 유사도(cosine similarity)를 사용함
  • 즉 모델 출력, 저장 스키마, 검색 방식이 한 방향을 보고 있음

sequenceDiagram
    participant 카메라사진 as 테스트 사진
    participant 감지정렬 as 얼굴 감지·정렬
    participant 임베딩 as SFace 임베딩
    participant 로컬인덱스 as SQLite 벡터 인덱스
    participant 알림 as 안드로이드 알림

    카메라사진->>감지정렬: 얼굴 영역 추출
    감지정렬->>임베딩: 정렬된 얼굴 전달
    임베딩->>로컬인덱스: 2048차원 벡터 검색
    로컬인덱스-->>알림: 매칭된 이름 반환
    알림-->>카메라사진: Person recognized 알림 표시

테스트해보니 두 갈래가 모두 동작함

• 연구자는 DB를 스냅샷으로 잡고, 같은 파이프라인을 두 번 돌려봄

  • 첫 번째는 빈 인덱스에 대해 실행해서 매칭이 없는 경우를 확인함
  • 두 번째는 미리 하나의 얼굴 임베딩을 넣어둔 뒤 매칭되는 경우를 확인함

• 매칭이 없으면 얼굴 이미지와 임베딩이 디스크에 저장됨

  • 저장 위치는 /data/user/0/com.facebook.stella/files/NameTagsPending/
  • 얼굴 하나당 UUID 기반 파일 2개가 생김
  • 하나는 잘라낸 얼굴 이미지 .jpg, 다른 하나는 2048개 숫자로 된 .emb 파일임
  • 디렉터리 권한은 0700이고, 재부팅 후에도 남는다고 함

• .emb 파일 구조도 실제 얼굴 임베딩답게 맞아떨어짐

  • 파일 크기는 8192바이트였음
  • 계산하면 2048 × float32와 정확히 일치함
  • L2 norm은 0.999999로, 정규화된 얼굴 임베딩에서 기대되는 형태임
  • 값 범위는 -0.092110에서 +0.098950, 평균은 +0.000292였음

• 매칭이 되면 저장 대신 알림으로 감

  • 테스트에서는 “Recognized Michel Foucault”라는 본문을 가진 안드로이드 알림이 떴음
  • 알림 채널 이름은 nametags_recognition이고, 중요도는 IMPORTANCE_HIGH라서 헤드업 알림·소리·배지까지 가능한 수준임
  • 즉 백그라운드에서 조용히 값만 반환하는 코드가 아니라, 사용자에게 “누군가를 알아봤다”고 보여주는 표면까지 준비돼 있음

사용자 UI도 흔적이 있음

• APK 안에는 ‘Connections’ 섹션과 카드 문구가 하드코딩돼 있음

  • 문구는 “See your connections”, “Remember the people you met and make new connections.” 같은 식임
  • 서버에서 내려온 문자열이 아니라 앱 안에 박혀 있는 리터럴이라고 함

• 하지만 일반 계정에서는 이 카드가 보이지 않았음

  • 연구 중 특정 조건에서 보이게 됐지만, 평범한 사용자 플로우에서는 노출되지 않는 상태였음
  • 알림을 눌렀을 때 열려야 할 fb-viewapp://name_tags?face_id=... 딥링크도 현재 v273 빌드에서는 목적지 화면이 빠져 있었음
  • 결과적으로 알림은 뜨지만, 탭하면 기본 탭으로 빠지는 상태였다고 함

그래서 이게 왜 큰 얘기냐

• 이건 “미래 기능 실험 코드가 조금 남아있네” 정도로 보기엔 부품이 너무 많이 맞아 있음

  • 모델 3개가 있고, 임베딩 차원과 DB 인덱스 차원이 정확히 맞음
  • 매칭 실패 시 얼굴 이미지와 임베딩을 저장하는 경로가 있음
  • 매칭 성공 시 이름을 꺼내 알림을 띄우는 경로도 있음
  • 사용자에게 보여줄 Connections 위젯과 딥링크까지 있음

• 연구자가 부정한 것도 중요함. 실제 활성화나 서버 데이터 전송은 증명하지 않았음

  • 일반 사용자에게 켜져 있다는 주장도 안 함
  • 메타가 현재 모르는 사람을 식별하고 있다는 주장도 안 함
  • 얼굴 프로필 DB가 서버에서 채워졌다는 직접 관찰도 없었음

• 그래도 “어쩌다 들어간 코드”라고 넘기기엔 엔지니어링 투자량이 큼

  • 2048차원 얼굴 지문 생성
  • sqlite-vec 기반 코사인 검색
  • NameTagsPending 저장소
  • 하드코딩된 “Person recognized” 알림
  • 이 정도면 기능의 방향성은 꽤 분명해 보임

기술 맥락

• 여기서 중요한 선택은 얼굴 인식을 서버가 아니라 기기 안에서 돌릴 수 있게 만든 점이에요. 온디바이스 방식은 지연 시간이 짧고 네트워크가 없어도 돌아가지만, 동시에 사용자 기기 안에 얼굴 crop과 생체 임베딩이 남을 수 있어서 프라이버시 리스크가 바로 로컬 저장소 문제로 바뀌어요.

• 2048차원 임베딩과 코사인 유사도 검색을 붙인 건 “사진을 저장해두고 사람이 보는” 방식이 아니라, 머신러닝 모델이 만든 얼굴 지문끼리 비교하겠다는 선택이에요. 그래서 DB 스키마의 float[2048]과 SFace 출력 차원이 맞는다는 점이 강한 단서가 되는 거예요.

• sqlite-vec를 쓴 것도 흥미로워요. 별도 서버 벡터 DB가 없어도 앱 내부 SQLite에서 얼굴 벡터 검색을 할 수 있으니까, 스마트 안경 companion 앱 안에서 감지부터 매칭까지 닫힌 루프로 만들기 쉬워져요.

• NameTagsPending이라는 저장 경로는 기술적으로는 “아직 이름을 못 붙인 얼굴을 나중에 처리하기 위한 큐”처럼 읽혀요. 원문이 실제 업로드나 서버 라벨링을 확인한 건 아니지만, 얼굴 crop과 임베딩을 쌍으로 남기는 구조는 나중에 식별 정보를 붙이기 좋은 형태인 건 맞아요.