Google 연합 학습 해설: 개인정보 보호 규칙이 서버에서 실행되는지 검증하기

배경과 문제

기존 연합 학습(FL)은 여러 기기가 원문을 서버에 모으지 않고 각자 계산한 학습 결과를 모으는 방식이다. Google은 Gboard의 다음 단어 예측, Google Messages의 답장 추천, Android의 Smart Text Selection 등에 이를 활용해 왔다. 차등 프라이버시(DP)는 학습 결과에서 특정 개인의 데이터가 포함됐는지 알아내는 능력을 수학적으로 제한한다. 이 연구에서는 계산 결과에 정해진 노이즈를 더하는 알고리즘을 사용한다. 단순히 이름을 지우거나 전송 파일을 암호화하는 것과는 다른 보호다.

문제는 서버가 약속한 노이즈를 실제로 넣는지 외부에서 확인하기 어려웠다는 점이다. 기존 시스템에서는 기기와 감사자가 서버 로직을 검증하지 못해 운영자를 믿어야 했다. 또 그래디언트, 즉 모델을 어느 방향으로 바꿀지 나타내는 계산을 기기에서 수행해 모델 크기와 학습 속도가 기기 성능에 제한됐다. 충전·Wi-Fi·배터리 조건을 만족한 기기가 제때 모이지 않으면 학습 라운드가 지연됐다.

기존 접근의 한계

보안 집계는 개별 기기의 업로드를 암호학적으로 보호하고, 분산 DP와 함께 쓰여 서버가 관찰할 정보를 줄였다. 하지만 이 Google 블로그가 설명한 기존 구성은 최신 중앙 DP 보장과 결합하는 데 제약이 있었다. 모든 보안 집계 기법과 중앙 DP가 원리상 양립 불가능하다는 결론으로 확대하면 안 된다. 이번 시스템은 데이터 계산 위치와 서버를 검증하는 방식을 함께 바꾼다.

기존 방식에서는 한 기기가 일정 기간에 한 번만 참여하도록 제한했다. 예컨대 144시간 간격을 사용하면, 실제 학습 라운드 사이의 간격은 매일 달라지는 기기 가용성과 처리 속도에 영향을 받는다. 새 방식은 업로드를 먼저 모은 뒤 서버에서 참여 순서를 정한다. 이를 통해 참여 횟수와 간격을 더 직접 제어해, 모델 학습에 필요한 신호와 개인정보 보호용 노이즈의 관계를 개선하려 한다.

연구방법을 단계별로

첫째, 데이터 업로드 단계에서 기기는 학습 예제를 암호화한다. 업로드 전에 어떤 TEE 연산이 데이터를 처리할 수 있는지 정한 접근 정책과 KMS 소프트웨어가 공개 투명성 로그에 등록됐는지 확인한다. 데이터는 이 정책과 암호학적으로 묶여 저장된다. 기존의 기기 내 그래디언트 계산과 달리 원문 학습 예제가 암호화된 형태로 서버에 올라간다는 점이 중요하다.

둘째, 키 관리 시스템(KMS)은 여러 TEE로 구성되며 정책과 일치하는 실행 환경에만 복호화 키를 준다. 정책에는 실행할 Python 프로그램과 루트·워커 바이너리의 해시가 들어간다. 하드웨어의 원격 증명은 어떤 바이너리가 실행되는지 확인하는 근거다. 루트 TEE는 워커의 증명도 확인하고 암호화 통신 채널을 만든다. 이 연구는 AMD SEV-SNP와 Intel TDX를 이용한 구조를 설명한다.

셋째, 루트 TEE가 Python 학습 루프를 실행하고 병렬 작업은 워커 TEE에 나눈다. 분산 부분은 특정 ML 프레임워크에 묶이지 않는 오픈소스 언어 Federated Language로 표현한다. 학습 프로그램은 데이터 처리와 노이즈 적용을 수행하고, 공개가 허용된 익명화 결과를 밖으로 내보낸다. 외부 감사자는 공개 프로그램이 실제로 약속한 DP 처리를 하는지 검토할 수 있다.

넷째, 장애 복구 때 결과가 중복 공개되지 않도록 KMS가 롤백 방지 상태를 관리한다. 논문의 예처럼 10라운드마다 결과를 내고 206번째 라운드에서 실패했다면, 200~205라운드의 복구 상태에서만 재개한다. 훨씬 이전 상태로 돌아가 무작위 노이즈가 다른 결과를 반복 공개하면 추가 정보가 새어 나갈 수 있기 때문이다. 이는 원문 데이터를 공개하는 기능이 아니라 이미 공개한 결과를 추적해 프라이버시 예산을 지키려는 설계다.

결과와 숫자의 의미

일본어 모델의 기기 참여 실험에서 기존 시스템은 코호트 6,500으로 38일 동안 3,000라운드를 학습했다. 가용 기기 3,550만 중 실제 기여는 850만, 즉 23.9%였다. 2,050만은 작업을 받지 못했고 650만은 받은 작업을 끝내지 못했다. 새 시스템은 약 6일간 1,780만 업로드를 모은 후 서버 학습을 시작했고 이 업로드를 모두 활용했다. 6일은 데이터 수집 기간으로, 전체 학습 완료 기간이 아니다. 두 관찰 기간이 다르고 업로드하지 않은 기기까지 모두 대표한다는 결과도 아니다.

별도의 영어 모델 분석은 5,000라운드·코호트 6,500에서 가능한 프라이버시와 노이즈 조합을 비교한다. 한 기기의 최대 참여 횟수 maxP는 기존 8에서 새 방식 3으로, 최소 참여 간격 minSep은 561에서 1,822라운드로 바뀌었다. 그림 3에서는 노이즈 배수 7.38을 유지할 때 zCDP가 0.388에서 0.113으로 낮아지고, zCDP를 0.388로 유지하면 노이즈 배수를 3.99로 낮출 여지가 보인다. 이는 가능한 조합을 보여 주는 곡선이다. 본문의 TEE 학습은 목표 zCDP 0.232에 맞춰 노이즈 배수 5.16을 정했으며, 아래 실서비스 A/B의 최선군 수치와도 구별해야 한다.

영어 Gboard 실서비스 A/B는 군마다 350만 기기를 포함했다. 최선의 TEE군 zCDP 0.215는 같은 MF-DP-FTRL 메커니즘으로 조정한 기존 운영 모델의 0.641에 비해 약 3분의 1 수준이다. 이는 프라이버시 예산의 비교이며 개인정보 유출 위험이나 데이터량이 정확히 3분의 1이라는 뜻은 아니다. 분당 입력 단어 수와 제안 수정 비율은 neutral로 보고돼 사용성이 유지됐다는 근거다. 정확도 향상률이나 차이가 완전히 0이라는 통계적 증명은 제시되지 않았다. TEE 모델의 학습 기간은 3주, 기존 모델은 2개월이며 사용자 키보드 응답 지연을 비교한 수치가 아니다.

구체적인 예시

논문 부록의 예제 프로그램은 API가 어떤 일을 하는지 보여 준다. 매 라운드 데이터를 고르고 누적 합에 노이즈를 더해 공개하면서 암호화된 복구 정보도 저장한다. 예제의 간단한 무작위 정수 덧셈은 API 사용을 설명하는 코드이므로 그대로 안전한 DP 알고리즘으로 배포하라는 처방으로 읽으면 안 된다. 실제 보장은 공개된 프로그램의 전체 데이터 처리와 노이즈 계산을 검토해야 판단할 수 있다.

ExternalHandle은 기기 데이터 읽기, 런타임 정보 주입, 통제된 결과 공개, 복구 상태 저장을 연결한다. 이 가운데 사이드로딩은 모델 구조나 사용자별 전처리를 비공개로 넣는 기능이다. 이 비공개 로직 자체가 모두 공개되는 것은 아니다. 블로그가 제시한 조건은 프라이버시에 영향을 주는 처리를 공개 Python 코드에 고정하는 것이다. 감사자는 비공개 입력이 그 처리 경계를 벗어나지 않는지 살펴야 한다.

한계와 오해하기 쉬운 점

현세대 TEE의 기밀성과 무결성에는 하드웨어 신뢰 가정과 부채널 한계가 남는다. 실행 시간이나 메모리 접근에서 정보가 드러나는 문제까지 이번 시스템이 모두 해결한 것은 아니다. 저자도 소프트웨어 구현 전체의 정확성 증명을 향후 가능성으로 설명한다. 공개 프로그램을 검사할 수 있다는 사실과 모든 공격에 안전함이 증명됐다는 주장은 구별해야 한다.

블로그는 공개 소스에서 TEE 바이너리를 재현 가능하게 빌드할 수 있다고 설명한다. 반면 공식 README는 바이너리와 소스의 연결을 검증하는 binary transparency를 최종 목표로 두고 빌드 검증 지침을 계속 다듬는다고 쓴다. 따라서 모든 구성 요소에 대한 독립 감사 완료로 해석하지 않는다. 데이터 접근 만료인 TTL도 KMS가 best-effort 수준으로 강제한다는 조건이 있다.

학습한 모델은 최대 1,000만 파라미터이고 위 실험에는 14대 머신을 썼다. 대형 LLM에도 같은 효율이 나온다는 검증은 아니다. 모델마다 한 설정만 시험했으며 GPU 활용·루트와 워커 사이 통신·참여 일정 최적화는 후속 과제다. 운영자는 암호화 업로드의 내용은 못 보지만 어느 업로드가 각 라운드에 쓰였는지는 본다. 이 정보를 숨겨 샘플링에 따른 프라이버시 이득을 얻는 설계 역시 향후 과제로 남아 있다.

실제로 어떻게 활용할까

실무에서는 접근 정책·실행 바이너리·공개 프로그램을 따라 데이터가 어디서 풀리고 어떤 결과가 나오는지 확인하는 틀로 활용할 수 있다. 단순히 TEE라는 이름을 붙였는지보다, 공개된 코드가 명시한 DP 예산과 결과 공개 규칙을 실제로 강제하는지가 판단 대상이다. 비공개 전처리와 동적 파라미터를 허용할 경우 그 입력이 보호 규칙을 바꾸지 못하는지도 검토해야 한다.

운영에는 수집 기간과 학습 시간의 균형도 필요하다. 예를 들어 TTL이 30일인 데이터를 여러 날 모으면, 오래된 업로드의 키가 만료되기 전 남은 시간 안에 결과를 내야 한다. 학습 시작 후 도착한 업로드는 해당 학습에 반영하지 못한다. Google은 합성 데이터 생성이나 추론 같은 다른 Python 작업도 탐색하고 있지만, 이번 Gboard 결과만으로 그런 모든 작업의 성능과 프라이버시를 검증했다고 볼 수는 없다.