본문 바로가기
생각

TEE 안에서 학습해도 재시도가 위험한 이유: 키 승인과 결과 공개 상태

TEE의 격리만으로 결과 공개까지 보호되는 것은 아니다. 독립 노이즈를 더한 결과를 반복 공개하는 예시로, 키 승인과 공개 기록·장애 복구를 함께 검증해야 하는 이유를 설명한다.

TEE 안에서 학습해도 재시도가 위험한 이유: 키 승인과 결과 공개 상태 관련 이미지

Google Research의 Katharine Daly와 Daniel Ramage는 2026년 10월 2일 새 연합학습 시스템 (https://research.google/blog/toward-provably-private-learning-from-federated-data/ (새 창))을 소개했고, 이에 앞서 9월 30일에는 논문 v4 (https://arxiv.org/html/2609.31494v4 (새 창))를 공개했다. 연합학습은 여러 기기의 데이터로 공동 모델을 학습하는 방식이다. 새 시스템은 기기에서 하던 학습 계산을 서버로 옮기되, 보호 조치가 제대로 작동하는지 외부에서 점검할 수 있게 설계했다.

핵심은 연합학습을 서버로 옮겼을 때 무엇을 검증해야 개인정보가 보호된다고 말할 수 있는가다. 원자료에 담긴 설계 구조와 실제 운영 환경에서 적용할 판단 기준은 구분해서 살펴봐야 한다.

키를 주는 조건과 밖으로 내보낼 값을 함께 검증한다

이 시스템에서 기기가 학습 예제를 암호화해 업로드하면, 사전에 승인된 정책을 따르는 서버 프로그램만 이를 복호화할 수 있다. TEE(신뢰 실행 환경)는 실행 코드와 메모리를 격리하고 실행 환경을 원격으로 증명하며, KMS(키 관리 시스템)는 정책과 실행 환경이 일치하는지 확인한 뒤 복호화 키를 내준다. 정책과 프로그램을 공개 로그에서 확인하는 절차도 갖췄다. 구조도의 파란 경로는 암호화 업로드·키 전달·익명 결과 공개 과정을, 노란 경로는 코드와 정책을 공개 로그에 등록하고 기기나 외부 감사자가 이를 확인하는 흐름을 보여 준다. 데이터 전달과 실행 검증을 나누어 보면 복호화 권한을 누가 검증하는지 명확해진다. 공식 발표의 구조 설명 (https://research.google/blog/toward-provably-private-learning-from-federated-data/ (새 창))에 따르면 병렬 작업은 root TEE에서 worker TEE로 나뉜다.

DP(차등 개인정보 보호)는 특정 개인의 데이터 포함 여부가 출력 분포를 바꾸는 정도를 제한하는 수학적 보장이다. TEE로 데이터를 격리하더라도 외부에 공개할 결과물의 보호 수준은 별도로 확인해야 한다. 서버 운영자가 볼 수 있는 내부 상태와 모델이 외부로 드러내는 정보량은 서로 다른 검토 대상이기 때문이다.

실제 도입할 때 감사자는 승인된 프로그램 목록만 확인하는 데 그치지 않고, 그 코드가 어떤 결과를 반환하는지까지 추적해야 한다. 예를 들어 입력 추천 서비스가 집계 지표만 공개한다고 설명해 놓고 디버그 경로로는 개인별 문장을 내보낸다면, 프로그램이 승인 목록에 있다는 이유만으로 그 설계를 채택할 수는 없다. 모든 출력 경로에 동일한 제한이 걸려 있는지부터 확인해야 한다.

TEE 연합학습의 파란 데이터 경로와 노란 공개 로그 검증 경로를 연결한 공식 구조도
파란 경로는 암호화 업로드·키 전달·익명 결과 공개를, 노란 경로는 코드와 정책의 공개 로그 등록 및 기기·외부 감사자의 확인을 나타낸다. 숫자 1~6과 문자 A~D를 각각의 흐름으로 읽는다. 출처: Google Research · Katharine Daly · Daniel Ramage · Toward provably private learning from federated data — system overview (https://research.google/blog/toward-provably-private-learning-from-federated-data/)

장애 복구에서도 같은 데이터를 더 공개하지 않아야 한다

논문 §3.3.2 (https://arxiv.org/html/2609.31494v4#S3.SS3.SSS2 (새 창))를 보면 KMS는 파이프라인 상태도 함께 보관한다. 평문 결과를 공개할 때 상태를 원자적으로 갱신하고, 마지막으로 공개된 결과와 연결된 복구 정보로 작업 재개 범위를 제한한다. 이전 상태를 다시 불러와 동일한 학습 구간의 결과를 중복 공개하는 공격을 막기 위한 장치다.

운영 관점에서는 재시도 정책 역시 개인정보 보호의 검토 대상이다. 학습 작업이 모델을 내보낸 직후 중단됐을 때, 운영자가 이미 결과가 공개됐다는 사실을 놓치고 이전 상태로 되돌아가 새 난수로 결과를 다시 내보내면 관찰자는 서로 다른 출력을 둘 다 얻게 된다. 단순히 작업의 성공 여부만 기록하는 복구 절차로는 이처럼 정보가 노출되는 일을 막기 어렵다.

따라서 검증 계획에는 결과 공개 직전과 직후의 중단, 오래된 복구 상태 제출, 중복 재시도 시나리오를 모두 포함해야 한다. 재실행이 정상 종료됐는지뿐만 아니라 이미 공개된 결과는 무엇인지, 복구 후에도 공개 기록이 그대로 남는지까지 확인한다.

노이즈를 새로 뽑는 재시도가 왜 위험한지는 단순한 집계 예시로 생각해 볼 수 있다. 가상의 동일한 집계값 x에 평균이 0이고 분산이 σ²인 독립 노이즈를 더해 네 번 공개한다면, 네 출력의 평균은 여전히 x를 중심으로 모이지만 노이즈 분산은 σ²/4로 줄어든다. 표준편차가 처음의 절반이 되는 셈이다. 개별 출력에 노이즈를 넣었다는 사실만으로 여러 출력을 모아 관찰하는 경우까지 같은 수준으로 보호했다고 볼 수는 없다. 물론 이 계산은 독립 노이즈의 특성을 설명하기 위한 가상 예시일 뿐, 논문의 학습 알고리즘이나 실제 개인정보 보호 예산을 계산한 결과는 아니다.

반면 이미 공개한 결과 바이트를 그대로 다시 전송하는 것은 새 난수로 결과를 다시 계산해 내보내는 것과 다르다. 복구 과정에서 추적해야 할 핵심은 작업 프로세스의 종료 코드가 아니라 “어떤 결과가 이미 외부에 나갔는가”다. 공개 기록을 남기기 전에 결과부터 외부로 나가 버리면, 장애가 났을 때 이전 상태로 돌아가 같은 데이터로 계산한 새 결과를 또 내보낼 여지가 생긴다. 논문의 상태 갱신과 복구 제한 설계는 바로 이 차이를 시스템 실행 과정에 반영한 것이다.

Gboard 결과가 입증한 범위를 좁혀 읽는다

논문 §5.3 (https://arxiv.org/html/2609.31494v4#S5.SS3 (새 창))의 영어 Gboard 모델 A/B 실험은 실험군마다 기기 350만 대를 대상으로 진행됐다. 동일한 MF-DP-FTRL 방식으로 조정했을 때 기존 운영 모델의 개인정보 보호 예산(zCDP)은 0.641이었고, 가장 좋은 TEE 실험군은 0.215였다. 타이핑 속도나 추천 수정 비율 같은 주요 사용성 지표는 기존과 비슷한(중립적인) 수준을 유지했으며, 학습 기간은 기존 2개월에서 3주로 단축됐다.

다만 개인정보 보호 예산을 곧바로 유출 확률로 치환해 해석해서는 안 되며, 사용성이 유지됐다는 결과를 모든 언어와 서비스의 정확도 향상으로 확대 해석할 수도 없다. 이 실험이 입증한 범위는 어디까지나 해당 평가 조건의 영어 입력 모델에서 더 작은 예산을 쓰면서도 사용성을 유지했다는 점이다.

기술을 도입할 때는 자체 서비스의 사용성 기준에 먼저 맞춰 봐야 한다. 예를 들어 고객 상담 추천 모델이라면 입력 속도보다는 오안내 방지나 민감한 문구 차단이 더 중요한 평가 항목이 된다. 모델 크기, 참여 데이터의 구성, 결과 공개 방식이 달라지면 Gboard의 일정과 예산을 그대로 목표치로 삼기 어렵고, 서버 계산 비용과 실제 운영 환경의 지연 시간도 별도로 점검해야 한다.

보관 기한과 감사 체계를 설명할 수 있을 때 도입한다

논문 §4.1 (https://arxiv.org/html/2609.31494v4#S4.SS1 (새 창))은 복호화 가능 기간을 제한하는 TTL을 KMS가 최선의 노력(best-effort) 수준으로 집행한다고 명시한다. 여기서 TTL은 데이터 파일이 물리적으로 완전히 삭제됨을 뜻하지 않는다. 또한 공식 발표의 향후 과제 (https://research.google/blog/toward-provably-private-learning-from-federated-data/ (새 창))에서는 하드웨어 및 부채널 관측의 한계, 그리고 DP 알고리즘과 시스템 구현에 대한 완전한 정확성 증명을 남은 과제로 꼽고 있다. 제목의 ‘provably’만 보고 모든 구현이 이미 형식 검증까지 마쳤다고 받아들여서는 안 된다.

기기에서의 계산 부담과 참여 일정이 병목이라면 이 구조를 검토해 볼 만하다. 단, 서버에서 처리할 학습 예제의 범위와 외부에 공개할 결과를 제한할 수 있어야 한다. 운영자가 정책을 설명하는 것과 감사자가 실제 실행 증거를 확인하는 일은 별개이므로, 승인된 코드와 배포 산출물을 정확히 대응시키고 정책이 바뀔 때 재검토를 맡을 책임자도 지정해야 한다.

반대로 원자료를 서버로 옮기는 것 자체를 금지하는 데이터 계약이 있거나, 요구되는 보관 종료 수준을 키 만료만으로 충족할 수 없다면 전환을 보류하고 기기에서 계산한 갱신값만 모으는 기존 방식을 유지하는 편이 타당하다. 도입 전에 먼저 챙겨야 할 자료는 속도 향상 예상치가 아니라 실행 코드의 대응 근거, 출력 목록, 복구 상태 갱신 절차, 그리고 보관 종료 집행의 한계다.

참고 자료

채용 제안 보내기

생각

함께 해결할 LLM 과제와 기대하는 역할을 알려 주세요.

연락하기