Apple이 키보드 학습에 ε=2~4를 공개한 진짜 의미

Apple이 이모지·키보드 학습에 내건 ε=2~4는 한 번의 보고에 붙는 숫자입니다. 누적으로 보면 하루 16까지 허용된 설계와 그 논쟁의 핵심을 짚습니다.

정현진(Hyunjin Jeong) · 2026-05-05 · 6분 분량

2017년, Apple은 기술 백서에 숫자 하나를 그대로 적어 두었습니다.

이모지 학습 ε=4, 키보드 자동완성 ε=8, 건강 데이터 ε=2.

그 시기에 ε을 이렇게 공개적으로 못 박은 회사는 거의 없었습니다. 같은 해, 한 연구팀이 macOS 안에 실제로 박혀 있는 그 숫자를 디스어셈블로 끄집어내자 논쟁이 시작됩니다.

한 줄 요약 Apple이 공개한 ε=2~4는 "한 번의 보고"에 붙는 값이고, 시스템이 device-day 단위로 매일 예산을 새로 주기 때문에 누적 손실은 옵트인 이후 경과 일수만큼 선형으로 커집니다. 그래서 같은 ε이라도 "하루치"로 보느냐 "평생치"로 보느냐에 따라 안전/위험 판정이 갈립니다.

ε을 숫자로 공개한 것 자체가 당시엔 이례적이었습니다

대부분의 회사는 ε을 "있긴 한데 공개는 안 하는" 내부 값으로 다뤘습니다.

Apple은 달랐습니다. 기능별로 ε을 직접 적었고, 하루에 몇 건까지 보낼 수 있는지까지 명시했습니다. Lookup Hints는 ε=4에 하루 2건, 이모지는 ε=4에 하루 1건, QuickType은 ε=8에 하루 2건, 건강 데이터는 ε=2에 하루 1건입니다.¹

ε은 프라이버시 예산입니다. 이 말은 이런 뜻입니다. 한 사람의 데이터가 있고 없고가 결과를 얼마나 흔들 수 있는지, 그 흔들림의 상한을 정해 두는 숫자입니다. ε이 작을수록 보호가 세고, 클수록 헐겁습니다.

문제는 숫자만 봐서는 그게 마케팅 라벨인지 수학적 보장인지 알 수 없다는 점입니다. macOS 10.12를 역공학한 연구팀조차 "Apple의 접근에 대한 세부는 빈약했고, 프라이버시 파라미터를 어떻게 골랐는지에 대한 정확한 설명은 없었다"고 적었습니다.²

즉 ε이라는 숫자가 공개됐다는 것과, 그 숫자가 무엇을 보장하는지가 설명됐다는 것은 별개였습니다.

ε=2~4는 "한 사용자의 한 번 보고"에 붙는 값입니다

Apple이 쓰는 방식은 로컬 차등 프라이버시(LDP)입니다.

노이즈를 서버가 아니라 사용자 기기에서 더합니다. 데이터가 기기를 떠나기 전에 이미 흐트러뜨리기 때문에, Apple 서버는 원래의 참값을 복원할 수 없습니다.¹

여기서 ε이 정확히 무엇에 붙는지가 중요합니다. Apple의 수집 메커니즘에서 입력은 해시되어 비트 벡터가 되고, 각 비트는 일정 확률로 뒤집힙니다. 그 확률을 정하는 값이 ε이며, 한 번 제출할 때 스케치의 무작위 한 줄만 서버로 보냅니다.¹

이 말은 이런 뜻입니다. ε=4 같은 값은 "한 번의 보고(report)"에 대한 보장입니다. 한 사용자가 평생 보낸 모든 보고를 합친 노출량이 아닙니다.

실제로 같은 연구팀은 macOS 구현에서 한 건당 프라이버시 손실이 ε으로 1 또는 2 수준이라고 실측했습니다.² 즉 우리가 보는 "한 자리 ε"은 한 조각의 데이터에 붙는 숫자라는 뜻입니다.

로컬 모델의 형식적 정의도 같은 자리를 가리킵니다. 한 개인의 데이터 한 건을 노이즈로 가린 결과가, 입력이 무엇이었든 비슷한 확률로 나오도록 제한하는 것이 로컬 프라이버시입니다.³ 보장의 단위가 "개인의 한 데이터 포인트"라는 점이 핵심입니다.

이모지 한 번을 따라가면 ε이 비트에 붙는 양이 보입니다

추상적인 ε을 구체적인 비트로 내려보겠습니다.

Apple이 이모지 빈도를 모으는 방식은 Count Mean Sketch(CMS)입니다. 단어나 이모지는 후보 해시 함수 여러 개 중 하나를 무작위로 골라 one-hot 벡터로 바뀌고, 그 벡터의 각 비트가 독립적으로 일정 확률로 뒤집힙니다.⁴

이모지 수집의 실제 프로덕션 설정은 벡터 크기 1024, 해시 함수 65,536개, ε=4, 사전 크기 2,600개입니다.⁴

ε=4를 비트 뒤집힘 확률에 넣으면 약 0.119가 나옵니다. 즉 각 비트가 대략 11.9% 확률로 거짓값으로 바뀐 채 서버로 갑니다. 이게 ε이 "추상"이 아니라 실제로 데이터에 섞이는 잡음의 양이라는 뜻입니다.

Hadamard 변형(HCMS)에서는 한 걸음 더 나갑니다. 변환을 거친 벡터에서 단 하나의 좌표만 골라 뒤집고, 서버로는 (선택된 해시 인덱스, 좌표 인덱스, 처리된 1비트)만 보냅니다.⁴ 한 기여당 실제로 나가는 정보는 1비트입니다.

숫자로 보면 더 선명합니다. 한 사람이 한 번 이모지를 보낼 때 서버가 받는 건, 약 12% 확률로 거짓일 수 있는 비트 하나입니다. 개인 단위로는 거의 무의미한 신호이고, 수백만 명을 모아야 비로소 전체 빈도가 드러납니다.

누적으로 보면 하루 16, 시간이 갈수록 무제한이 됩니다

여기서 함정이 생깁니다.

같은 연구팀이 macOS Sierra 10.12를 정적·동적 분석으로 뜯어보니, 한 건당 ε은 1~2로 묶여 있었지만 시스템이 하루에 허용하는 전체 손실은 훨씬 컸습니다. 이모지, 새 단어, 딥링크, Lookup Hints 네 기능의 예산을 합치면 하루 최대 16까지 허용됐습니다.²

진짜 반전은 그다음입니다. Apple은 프라이버시 예산을 매일 새로 줍니다. 그래서 옵트인한 이후로 가능한 누적 손실은 "하루 16 × 경과 일수"가 되고, 기기 수명 전체로 보면 사실상 상한이 없습니다.² "하루치 ε"이라는 프레이밍 자체가 누적으로 보면 보장을 풀어 버리는 셈입니다.

16/day는 이론적 상한이고, 딥링크가 macOS엔 미구현이라 실측은 플랫폼마다 달랐습니다.

저자들은 이 허용 손실이 학계가 통상 합리적이라 보는 수준보다 훨씬 높다고 명시했습니다.²

이 결과가 코드 수준에서 단단한 이유가 하나 더 있습니다. 디스어셈블된 구현은 비트 뒤집힘 확률을 1.0/(exp(PrivacyParameter) + 1.0)이라는 상수로 계산했는데, 이는 Apple ML 백서의 노이즈 공식과 정확히 일치합니다.² 즉 역공학으로 끄집어낸 숫자가 곧 노이즈 양을 정하는 같은 ε임이 확인된 것입니다.

"매일 리셋한다"는 결정은 답이 아니라 누적의 원인입니다

Apple의 설계 논리는 일관됩니다.

Apple은 ε을 "기여 1건당 예산"으로 정의하고, 한 사용자가 보낼 수 있는 기여 수에 엄격한 상한을 둡니다. 이유로는 노이즈가 여러 기여에 걸쳐 평균적으로 상쇄되어, 한 사용자의 많은 관측에서 활동이 추론될 수 있기 때문이라고 적었습니다.⁵

Apple ML 자료도 ε과 별개로 "use case마다 매일 전송 가능한 처리된 레코드 수에 상한을 둔다"고 명시합니다.⁴ 일일 전송량 상한이 사실상 device-day 예산을 정의하는 두 번째 통제 장치입니다.

문제는 이 "매일 리셋"이 Tang 측 비판에 대한 반박이 되지 못한다는 점입니다.

오히려 정반대입니다. 매일 예산을 새로 준다는 것은, 어제 다 쓴 예산이 오늘 다시 채워진다는 뜻입니다. 누적을 막는 장치가 아니라 누적이 발생하는 메커니즘 그 자체입니다.⁵ 일별 리셋은 "하루 단위로는 ε이 작다"는 가정을 지킬 뿐, 시간 지평 전체의 보호를 약속하지 않습니다.

Apple은 ε 바깥의 운영적 완충도 둡니다. 수집 데이터는 최대 3개월만 보관하고, 식별자나 IP는 저장하지 않습니다.⁵ 다만 이건 ε이 보장하지 못하는 부분을 정책으로 메우는 것이지, 누적 ε 자체를 줄이는 장치는 아닙니다.

ε이 같아도 위협 모델이 다르면 결론이 갈립니다

이 논쟁에서 한쪽이 다른 쪽을 산술적으로 "틀렸다"고 못 박지 못하는 이유가 있습니다.

Tang 측 본인들이 ε 값의 선택을 이론 컴퓨터과학에서 통상 "사회적 선택"으로 다루는 문제라고 규정했습니다.⁶ 즉 같은 측정값을 두고도 "안전이냐 위험이냐"는 합의된 임계값이 없는 가치 판단에 기댑니다.

결론을 가르는 진짜 축은 ε 숫자가 아니라 "어느 단위로 합산하느냐"입니다.

같은 구현이라도 device-day로 끊어 보면 한 자리 ε이고, user-lifetime으로 누적하면 수백·수천이 됩니다. 어느 단위를 프라이버시 단위로 잡느냐에 따라 같은 시스템이 안전해지기도, 위험해지기도 합니다.

여기서 차등 프라이버시의 한계도 분명해집니다. DP는 "이웃 데이터셋", 즉 한 개인의 데이터에서만 차이 나는 쌍에 대해서만 보장을 줍니다. 두 상황의 차이가 선택된 프라이버시 단위로 포착되지 않으면, DP는 그 둘을 구별하려는 적대자를 전혀 막지 못합니다.⁷

로컬 모델 자체도 하나의 위협 모델을 깔고 있습니다. 로컬 DP는 데이터 제공자가 수집자조차 신뢰하지 않는다는 전제에서 출발합니다.³ 신뢰 가능한 큐레이터가 있는 중앙 모델이냐, 수집자를 불신하는 로컬 모델이냐에 따라 같은 ε이라도 보호 대상과 강도가 달라집니다.

이 말은 이런 뜻입니다. Apple과 Tang은 서로 다른 시간 단위와 위협 모델을 깔고 같은 숫자를 보고 있었습니다. 한쪽이 다른 쪽을 자동으로 반증하지 못하는 건 그래서입니다.

ε 숫자를 만나면 같이 물어야 할 네 가지가 있습니다

다른 제품이 "우리는 ε=N"이라고 말할 때, 숫자 하나만으로는 판단할 수 없습니다.

NIST는 DP 보장이 프라이버시 파라미터(ε)와 "프라이버시 단위"(이웃 데이터셋 정의) 두 가지로 정의되며, 현실에서는 단위 쪽이 ε 설정보다 더 중요한 경우가 많다고 못 박습니다.⁸ 운영에서는 이렇게 네 가지를 같이 물어야 합니다.

특히 마지막 항목은 Apple 사례의 정확한 급소입니다. 사용자당·일당 k건으로 기여를 상한하면 단위가 event-level과 user-level 사이의 중간이 되고, NIST는 이런 보장이 "event보다 강하지만 user보다 약하며, 강도를 해석하기 어렵다"고 경고합니다.⁸

Apple식 device-day가 바로 그 해석이 까다로운 중간 영역입니다.

ε이라는 숫자 하나를 신뢰의 근거로 삼고 싶을 때, 실제로 신뢰를 정하는 건 그 숫자가 아니라 "어느 단위로, 며칠 동안, 누구를 불신하는 모델에서" 측정됐는가입니다. Apple의 ε=2~4 논쟁이 남긴 가장 실용적인 교훈이 바로 이것입니다.

참고 문헌