프라이버시 보존 머신러닝 2026 완벽 가이드 - Federated Learning · Flower · NVIDIA FLARE · Opacus · Zama Concrete · OpenMined PySyft 심층 분석

프롤로그 - "데이터를 옮기지 말고, 모델을 옮겨라"

2017년 4월, Google AI 블로그에 한 편의 글이 올라옵니다. 제목은 "Federated Learning: Collaborative Machine Learning without Centralized Training Data". Brendan McMahan과 동료들은 Gboard(안드로이드 키보드)에서 사용자의 타이핑 데이터를 서버로 보내지 않고도, 각 폰에서 학습한 모델 업데이트만 모아 평균하는 방식으로 다음 단어 예측 모델을 개선했다고 발표합니다. FedAvg(Federated Averaging) 알고리즘이 세상에 공개된 순간이었습니다.

2024년 6월, Apple WWDC에서 Craig Federighi는 더 충격적인 무대를 보여줍니다. Private Cloud Compute(PCC) - 사용자의 요청이 Apple의 클라우드 서버로 갈 때, 서버는 절대 그 요청의 내용을 볼 수 없도록 하드웨어와 소프트웨어를 재설계한 인프라입니다. Secure Enclave, Apple Silicon, 검증 가능한 빌드(verifiable build), 자체 디바이스에서 검증하는 인증서 투명성(certificate transparency)까지. "데이터를 서버에 보내되, 서버가 보지 못하게 한다"는 모순적 명제가 실제 제품으로 출시되었습니다.

이 7년 사이, 프라이버시 보존 머신러닝(Privacy-Preserving Machine Learning, PPML)은 학계의 호기심에서 빅테크의 핵심 인프라로 성장했습니다. 2026년 5월 현재, PPML은 5가지 기술 스택의 조합으로 이뤄집니다.

Federated Learning(FL) - 데이터를 옮기지 않고 모델 가중치만 집계
Differential Privacy(DP) - 통계적으로 "한 명이 빠져도 결과가 거의 같다"는 수학적 보장
Homomorphic Encryption(HE) - 암호화된 상태로 연산을 수행
Secure Multi-Party Computation(MPC) - 여러 당사자가 자기 입력을 공개하지 않고도 함수를 계산
Trusted Execution Environment(TEE) - 하드웨어 격리 영역에서 코드를 실행

이 글에서는 2026년 5월 기준 각 영역의 대표 프레임워크, 실제 배포 사례, 규제 환경을 차근차근 살펴봅니다.

1. PPML이 등장한 이유 - 4가지 압력

1.1 GDPR(2018)부터 EU AI Act(2024)까지

2018년 5월 25일 발효된 EU GDPR(General Data Protection Regulation)은 PPML 시대의 신호탄이었습니다. 개인정보 처리의 6가지 합법 근거(동의, 계약, 법적 의무, 생명, 공익, 정당한 이익), 잊혀질 권리(Right to be forgotten), 데이터 최소화(data minimization) 원칙. 위반 시 매출의 4% 또는 2천만 유로 중 큰 금액.

이어 2023-2024년 EU AI Act가 통과되며, 고위험 AI 시스템(의료, 채용, 신용평가, 법 집행)에는 데이터 거버넌스, 투명성, 인간 감독, 견고성(robustness) 요구사항이 추가되었습니다. 2026년 8월부터 일반 목적 AI(GPAI) 의무가 단계적으로 적용됩니다.

미국 HIPAA(1996), 한국 PIPA(개인정보보호법), 일본 APPI(個人情報保護法), 중국 PIPL, 캘리포니아 CCPA/CPRA. 각국의 규제가 동시에 강화되며, "모든 데이터를 한 곳에 모아서 학습한다"는 전통적 ML 워크플로우가 위태로워졌습니다.

1.2 데이터 사일로(Data Silo)와 협업 학습의 욕구

병원 한 곳의 MRI 영상으로는 희귀 종양 검출 모델을 학습하기에 데이터가 너무 적습니다. 하지만 환자 영상을 다른 병원에 공유하는 것은 법적으로도, 윤리적으로도 어렵습니다. 은행도 마찬가지 - 사기 탐지 모델은 여러 은행의 데이터가 합쳐질수록 강력해지지만, 거래 데이터는 절대 공유할 수 없습니다.

이 "공유하고 싶지만 공유할 수 없는" 데이터 사일로 문제가 PPML, 특히 Federated Learning의 가장 큰 응용 동력입니다.

1.3 모델 추론 시의 입력 프라이버시

LLM 시대에 새로 떠오른 문제. 사용자가 ChatGPT에 자신의 코드, 의료 기록, 재무 정보를 입력합니다. OpenAI 서버는 그 입력을 평문으로 봅니다. 이걸 막을 수 있는가?

TEE 기반 - Apple PCC, AWS Nitro Enclaves, Confidential VM
FHE 기반 - Zama Concrete-ML로 암호화된 입력에 대해 추론
MPC 기반 - CrypTen, EzPC로 분산 추론

1.4 모델 자체의 프라이버시 - 멤버십 추론 공격

Carlini et al.(2021)은 GPT-2가 학습 데이터의 일부(이메일 주소, 전화번호, 의료 기록)를 그대로 출력할 수 있음을 보였습니다. 학습된 모델은 "기억"을 합니다. 이를 막기 위한 수학적 도구가 바로 Differential Privacy(DP)입니다.

2. Federated Learning 개념 - FedAvg부터 FedProx까지

2.1 FedAvg 알고리즘(McMahan et al., 2017)

FedAvg는 단순합니다. 매 라운드마다:

서버가 글로벌 모델 가중치 w_t를 클라이언트들에게 배포
각 클라이언트 k가 자신의 로컬 데이터 D_k로 E 에폭 동안 학습 -> w_t^k
서버가 가중 평균: w_(t+1) = sum(n_k / n) * w_t^k
다음 라운드 반복

+----------+              +----------+              +----------+
| Client 1 |              | Client 2 |              | Client 3 |
| D_1      |              | D_2      |              | D_3      |
+----+-----+              +----+-----+              +----+-----+
     |  w_t^1                   |  w_t^2                  |  w_t^3
     +--------------------+-----+--------------------+----+
                          v
                  +-------+-------+
                  |    Server     |
                  | w_(t+1) =     |
                  |  weighted avg |
                  +---------------+
                          |
                          v
                    (분배 to 모든 클라이언트)

2.2 Cross-Device vs Cross-Silo

Cross-Device FL - 수백만 대의 모바일 폰, 매번 일부만 참여, 연결 불안정. 대표: Google Gboard, Apple Siri.

Cross-Silo FL - 수십 개의 기관(병원, 은행). 안정적 인프라, 거의 항상 참여, 데이터 크기가 큼. 대표: NVIDIA FLARE 기반 BraTS, MELLODDY(제약사 컨소시엄).

구분	Cross-Device	Cross-Silo
클라이언트 수	1만 - 1억대	2 - 100개 기관
클라이언트 가용성	간헐적, 비신뢰	거의 항상 가능
데이터 크기/노드	매우 작음	매우 큼
통신 비용	매우 비쌈(셀룰러)	비교적 저렴(전용선)
보안 모델	Honest-but-curious 클라이언트 다수	신뢰할 만한 기관
대표 프레임워크	TensorFlow Federated, Flower	NVIDIA FLARE, Flower, OpenFL

2.3 Non-IID 데이터의 도전

연합 학습의 가장 큰 난점은 **각 클라이언트의 데이터 분포가 다르다(Non-IID)**는 점입니다. 한 병원은 소아 환자가 많고, 다른 병원은 고령 환자가 많습니다. 단순 FedAvg는 이런 환경에서 발산하거나 정확도가 크게 떨어집니다.

이를 해결하기 위한 변형 알고리즘들:

FedProx(Li et al., 2018) - 로컬 업데이트에 근접항(proximal term)을 추가
SCAFFOLD(Karimireddy et al., 2020) - 클라이언트별 분산 보정(variance reduction)
FedNova(Wang et al., 2020) - 로컬 스텝 수 정규화
FedAdam / FedAdagrad / FedYogi(Reddi et al., 2021) - 서버 측에 적응형 옵티마이저 적용

2.4 보안 집계(Secure Aggregation)

FedAvg에서 한 가지 약점 - 서버는 각 클라이언트의 w_t^k를 봅니다. 모델 가중치에서 학습 데이터를 역추론하는 공격(model inversion, gradient leakage)이 가능합니다. 이를 막기 위해 Secure Aggregation(Bonawitz et al., 2017)이 사용됩니다.

핵심 아이디어 - 각 클라이언트가 자신의 가중치에 비밀 노이즈를 더하되, 모든 클라이언트의 노이즈가 합산되면 0이 되도록 페어와이즈 마스크를 공유. 서버는 sum만 볼 수 있고, 개별 클라이언트의 기여는 볼 수 없습니다.

3. Flower 1.13 - 가장 인기있는 오픈소스 FL 프레임워크

3.1 Flower의 부상

Flower(flower.ai)는 2020년 Daniel J. Beutel과 Taner Topal이 만든 오픈소스 FL 프레임워크입니다. 2022년 Flower Labs Inc.로 회사화되었고, 2024-2025년 시리즈 A 펀딩을 받았습니다. 2026년 5월 기준 GitHub 스타 약 5,500개로, 가장 활발한 FL 프레임워크 중 하나입니다.

Flower의 철학 - "프레임워크 중립(framework-agnostic)". PyTorch, TensorFlow, JAX, Scikit-learn, Hugging Face Transformers 등 어떤 ML 라이브러리도 클라이언트로 감쌀 수 있습니다.

3.2 Flower 1.13의 핵심 구조

Flower 1.13(2025년 말 릴리스)은 세 가지 컴포넌트로 구성됩니다.

ServerApp - 글로벌 학습 로직(어떤 클라이언트 선택, 어떤 집계 알고리즘 사용)
ClientApp - 클라이언트 측 학습/평가 로직
SuperLink + SuperNode - 서버/클라이언트 사이 통신을 담당하는 백본

# Flower 1.13 ClientApp 예시
from flwr.client import ClientApp, NumPyClient
from flwr.common import Context

class FlowerClient(NumPyClient):
    def __init__(self, net, trainloader, valloader):
        self.net = net
        self.trainloader = trainloader
        self.valloader = valloader

    def get_parameters(self, config):
        return [val.cpu().numpy() for _, val in self.net.state_dict().items()]

    def set_parameters(self, parameters):
        params_dict = zip(self.net.state_dict().keys(), parameters)
        state_dict = {k: torch.tensor(v) for k, v in params_dict}
        self.net.load_state_dict(state_dict, strict=True)

    def fit(self, parameters, config):
        self.set_parameters(parameters)
        train(self.net, self.trainloader, epochs=1)
        return self.get_parameters(config={}), len(self.trainloader.dataset), {}

    def evaluate(self, parameters, config):
        self.set_parameters(parameters)
        loss, acc = test(self.net, self.valloader)
        return float(loss), len(self.valloader.dataset), {"accuracy": float(acc)}

def client_fn(context: Context):
    partition_id = context.node_config["partition-id"]
    net = Net()
    trainloader, valloader = load_data(partition_id)
    return FlowerClient(net, trainloader, valloader).to_client()

app = ClientApp(client_fn=client_fn)

3.3 시뮬레이션 엔진

Flower의 강력한 기능은 시뮬레이션 모드입니다. 실제 분산 환경 없이 단일 머신에서 수천 개의 가상 클라이언트를 시뮬레이션할 수 있습니다. Ray를 백엔드로 사용해 GPU 자원을 효율적으로 분배합니다.

from flwr.simulation import run_simulation

run_simulation(
    server_app=server_app,
    client_app=client_app,
    num_supernodes=100,  # 100개의 가상 클라이언트
    backend_config={"client_resources": {"num_cpus": 2, "num_gpus": 0.1}}
)

이 기능 덕분에 연구자가 알고리즘 변경의 효과를 빠르게 검증할 수 있어, Flower가 학계에서 사랑받는 이유가 되었습니다.

3.4 Flower 전략(Strategy)

Flower는 30개 이상의 집계 전략을 내장하고 있습니다.

FedAvg, FedAdagrad, FedYogi, FedAdam, FedProx
FedAvgM(Momentum), FedTrimmedAvg, FedMedian
Krum, Bulyan(비잔틴 robust)
FedXgbBagging, FedXgbCyclic(XGBoost 전용)
DifferentialPrivacyClientSideAdaptiveClipping(DP 통합)

4. NVIDIA FLARE - 엔터프라이즈 FL의 표준

4.1 FLARE의 위치

NVIDIA FLARE(Federated Learning Application Runtime Environment)는 2021년 NVIDIA가 의료 AI 자회사 Clara와 함께 발표한 FL 프레임워크입니다. 2026년 5월 현재 2.5.x 시리즈가 안정 버전이며, Apache 2.0 라이선스로 제공됩니다.

FLARE의 타깃은 명확합니다 - 엔터프라이즈, 특히 헬스케어와 금융 Cross-Silo FL. Flower가 "유연성과 시뮬레이션"에 강하다면, FLARE는 "운영 안정성, 보안, 감사 추적"에 강합니다.

4.2 Hub & Spoke 아키텍처

FLARE는 중앙 서버(FL Server)와 다수의 클라이언트(FL Client) 간 hub-and-spoke 통신 모델을 사용합니다. 모든 통신은 mTLS로 암호화되며, 각 사이트는 PKI 기반 인증서로 신원을 증명합니다.

                +---------------+
                | FL Server     |
                | (Hub)         |
                | Aggregator    |
                +-------+-------+
                        |
        +---------------+---------------+
        |               |               |
    +---+---+       +---+---+       +---+---+
    |Site A |       |Site B |       |Site C |
    |Hospital|     |Hospital|     |Hospital|
    +-------+       +-------+       +-------+

4.3 BraTS 의료 컨소시엄

FLARE의 대표적 성공 사례는 BraTS(Brain Tumor Segmentation Challenge) Federated입니다. 71개 의료 기관(미국, 유럽, 아시아)이 참여해 뇌종양 분할 모델을 연합 학습했습니다(Pati et al., Nature Communications, 2022). 단일 기관에서 학습한 모델보다 정확도가 평균 6% 향상되었고, 그 어떤 환자 데이터도 기관 밖으로 나가지 않았습니다.

이 사례는 FL이 "이론에서 의료 현장으로" 넘어간 결정적 순간이었습니다.

4.4 FLARE의 핵심 기능

Job Submission - 학습 작업을 패키지로 만들어 서버에 제출, 관리자가 승인 후 실행
Provisioning - 사이트별 인증서, 설정, 보안 정책을 자동 생성
Privacy Filters - 가중치 전송 전에 DP 노이즈, gradient clipping 등을 자동 적용
POC(Proof of Concept) 모드 - 로컬에서 빠르게 멀티 사이트 시뮬레이션
NVFlare Dashboard - 학습 진행 상황, 메트릭, 보안 이벤트 시각화

# FLARE Controller(서버 측) 예시
from nvflare.app_common.workflows.fedavg import FedAvg
from nvflare.job_config.fed_job import FedJob

job = FedJob(name="brats_seg")
controller = FedAvg(num_clients=10, num_rounds=20)
job.to_server(controller)
job.to_clients(executor=BraTSExecutor())
job.export("./jobs/brats_seg")

5. TensorFlow Federated(TFF) - Google의 시뮬레이션 우선 접근

5.1 TFF의 정체성

TensorFlow Federated(TFF)는 Google이 2019년 오픈소스화한 FL 라이브러리입니다. 하지만 Flower나 FLARE와는 결이 다릅니다 - TFF는 연합 알고리즘의 수학적 정의를 표현하는 언어에 가깝습니다. 실제 분산 배포보다는 알고리즘 시뮬레이션과 연구가 주된 사용 사례입니다.

5.2 두 가지 레이어

Federated Core(FC) - federated_computation, federated_map, federated_aggregate 같은 저수준 연산자
Federated Learning(FL) API - FedAvg, FedSGD 같은 고수준 API

import tensorflow_federated as tff

@tff.federated_computation
def get_average_temperature(client_temperatures):
    return tff.federated_mean(client_temperatures)

이런 선언적 표현 덕분에, TFF는 알고리즘의 통신 비용, 수렴성, DP 보장을 수학적으로 분석하기 쉽습니다.

5.3 한계와 위치

TFF는 시뮬레이션에 강하지만, 실제 모바일 단말에 배포하기는 어렵습니다. Google 내부에서는 별도의 프로덕션 시스템(Federated Compute, Federated Compute Platform)이 Gboard 같은 실제 서비스를 지원합니다. 2026년 기준 TFF는 학계 연구용으로 주로 쓰이며, 산업계 채택은 Flower/FLARE에 밀린 상황입니다.

6. PySyft 0.9와 OpenMined - 구조화된 투명성

6.1 OpenMined의 비전

OpenMined는 Andrew Trask가 2017년 시작한 비영리 오픈소스 커뮤니티입니다. 슬로건은 "Answer questions using data you cannot see" - 보지 못하는 데이터로 질문에 답하는 것. 이 한 문장이 PPML의 본질을 담고 있습니다.

OpenMined의 대표 프로젝트는 PySyft입니다. PySyft는 단순한 FL 라이브러리가 아니라, "구조화된 투명성(Structured Transparency)" 프레임워크입니다.

6.2 구조화된 투명성

전통적 데이터 분석 - 분석가가 데이터 사본을 받아서 자신의 서버에서 분석. 데이터 소유자는 분석가가 무엇을 했는지 통제할 수 없음.

PySyft의 모델 - 데이터는 데이터 소유자(Data Owner)의 Domain Server에 남아있고, 분석가(Data Scientist)는 "이런 함수를 데이터에 적용해도 되겠습니까?"라는 요청을 보냅니다. 데이터 소유자는 함수를 검토하고, 결과만 반환합니다(필요시 DP 노이즈 추가).

+----------------+                       +------------------+
| Data Scientist |                       | Data Owner       |
| (Jane)         |  1. 코드 + 데이터    | (Hospital)       |
|                |     레퍼런스 제출    |                  |
|                | --------------------> | Domain Server    |
|                |                       | (data here)      |
|                |  2. 검토/실행/결과   |                  |
|                | <-------------------- |                  |
+----------------+                       +------------------+

6.3 PySyft 0.9의 핵심 개념

Domain - 데이터 소유자가 운영하는 서버. 데이터, 정책, 결과 보관소
Code Request - 데이터 사이언티스트가 제출한 함수. 소유자가 승인하면 실행
Privacy Budget - 각 사용자에게 할당된 DP 엡실론 한도
Mock Data - 실제 데이터와 같은 스키마의 합성 데이터. 분석가가 실제 데이터를 보지 않고도 코드를 작성/디버깅 가능

import syft as sy

# 데이터 소유자 측
domain = sy.orchestra.launch(name="hospital", port=8081)
client = domain.login(email="admin@hospital.org", password="...")

# 실제 데이터를 도메인에 업로드, mock 데이터로 자동 생성
asset = sy.Asset(name="patient_mri", data=real_data, mock=mock_data)
dataset = sy.Dataset(name="MRI Study 2026", asset_list=[asset])
client.upload_dataset(dataset)

# 데이터 사이언티스트 측
ds_client = sy.login(url="https://hospital.openmined.org", email="researcher@univ.edu", password="...")
mri_mock = ds_client.datasets[0].assets[0].mock

@sy.syft_function_single_use(mri=mri_mock)
def compute_tumor_volume(mri):
    return mri.mean()  # 실제로는 더 복잡한 ML 모델

ds_client.code.request_code_execution(compute_tumor_volume)
# 데이터 소유자가 승인하면 실제 데이터로 실행되고 결과만 반환

6.4 OpenMined 생태계

PySyft 외에도 OpenMined은 다양한 도구를 만들고 있습니다.

PyDP - Google DP Library의 Python 바인딩
PSI(Private Set Intersection) - 두 당사자의 데이터 교집합을 노출 없이 계산
TenSEAL - Microsoft SEAL의 Python 바인딩, FHE 텐서 연산
HAGrid - PySyft Domain 클러스터 배포 도구

7. Differential Privacy 기초 - 엡실론과 델타

7.1 DP의 수학적 정의

랜덤화된 알고리즘 M이 (eps, delta)-DP를 만족한다는 것은 - 한 사람의 데이터가 다르기만 한 두 데이터셋 D와 D'에 대해, 모든 출력 집합 S에 대해 다음이 성립한다는 것입니다.

P[M(D) in S] <= exp(eps) * P[M(D') in S] + delta

직관적으로 - eps가 작을수록 "한 사람의 데이터가 결과에 거의 영향을 못 미친다". delta는 그 보장이 깨지는 확률.

전형적인 값 - eps는 0.1에서 10 사이, delta는 1/n^1.5 정도(n은 데이터셋 크기).

7.2 Laplace 메커니즘과 Gaussian 메커니즘

가장 단순한 DP 메커니즘 - 답에 노이즈를 더하기.

True query: f(D) = 평균 키 (cm)
DP answer:  f(D) + Lap(sensitivity / eps)
            or
            f(D) + N(0, sigma^2)

sensitivity는 한 사람의 데이터가 빠지거나 추가될 때 함수값이 바뀔 수 있는 최대값. 노이즈의 양은 sensitivity / eps에 비례합니다.

7.3 Composition

여러 DP 쿼리를 같은 데이터셋에 실행하면, 프라이버시 손실이 누적됩니다. Basic composition - eps들의 단순 합. Advanced composition - sqrt(k * log(1/delta)) * eps 정도. Renyi DP, zCDP 같은 고급 회계 기법은 더 정확한 누적치를 줍니다.

7.4 Apple의 DP 도입(2017)

Apple은 iOS 10(2016)부터 키보드 사용 통계, 이모지 빈도, Safari 충돌 보고 등에 Local DP를 적용했습니다. Local DP는 사용자 디바이스에서 데이터에 노이즈를 더해 서버로 보내는 방식. eps 값이 일반적으로 4-8 정도로 비교적 큰 편이지만, 데이터 자체가 서버에 평문으로 도달하지 않는다는 보장이 있습니다.

이는 DP가 학계 개념에서 빅테크 운영 도구로 넘어간 첫 사례 중 하나였습니다.

7.5 미국 Census 2020

미국 통계청은 2020년 인구조사 결과 발표에 (eps=19.61) Central DP를 적용했습니다. 한 가구가 다르면 통계 결과가 거의 같다는 보장. 학계의 거센 논쟁이 있었지만(통계 정확도와 프라이버시 트레이드오프), DP가 정부 통계의 표준으로 자리잡는 계기가 되었습니다.

8. Opacus 1.5 - Meta의 PyTorch DP 라이브러리

8.1 DP-SGD 알고리즘

DP를 ML 학습에 적용하는 표준 방법은 DP-SGD(Differentially Private Stochastic Gradient Descent)(Abadi et al., 2016)입니다. 핵심 차이점 - per-sample gradient clipping과 노이즈 추가.

For each minibatch:
  for each sample x_i in batch:
    g_i = compute gradient of L(theta, x_i)
    g_i = g_i * min(1, C / ||g_i||)   # per-sample clipping
  g_bar = (sum g_i + N(0, sigma^2 * C^2 * I)) / batch_size
  theta = theta - lr * g_bar

이렇게 하면 한 샘플이 빠질 때 최종 모델에 미치는 영향이 sigma 노이즈에 의해 가려집니다.

8.2 Opacus의 등장

Opacus는 Meta(전 Facebook) AI Research가 2020년 공개한 PyTorch DP 라이브러리입니다. PyTorch 표준 옵티마이저를 한 줄 코드로 DP-SGD로 바꿔주는 것이 핵심 가치였습니다.

import torch
from opacus import PrivacyEngine

model = MyModel()
optimizer = torch.optim.SGD(model.parameters(), lr=0.05)
data_loader = torch.utils.data.DataLoader(...)

privacy_engine = PrivacyEngine()
model, optimizer, data_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=data_loader,
    target_epsilon=2.0,
    target_delta=1e-5,
    epochs=20,
    max_grad_norm=1.0,
)

# 이후 평소처럼 학습
for epoch in range(20):
    for x, y in data_loader:
        optimizer.zero_grad()
        loss = criterion(model(x), y)
        loss.backward()
        optimizer.step()

print(f"Final eps: {privacy_engine.get_epsilon(delta=1e-5)}")

8.3 Opacus 1.5(2025-2026)의 개선

Per-sample gradient의 GPU 효율화 - GhostClip, Functorch 활용
LLM 미세조정 지원 - LoRA 기반 DP fine-tuning
Distributed DP-SGD - 다중 GPU/노드에서 정확한 프라이버시 회계
RDP/zCDP 회계자 - 더 정확한 eps 계산

8.4 DP-SGD의 정확도 비용

DP-SGD는 무료가 아닙니다. eps=1-3 정도의 강한 프라이버시를 보장하려면, 보통 정확도가 1-5%p 떨어집니다. 더 많은 데이터, 더 큰 배치, 더 긴 학습이 이 비용을 줄이는 핵심 처방입니다.

9. OpenDP 0.10 - Harvard의 Rust 기반 DP 코어

9.1 OpenDP의 차별점

OpenDP는 Harvard University와 Microsoft가 공동 시작한 프로젝트로, 수학적으로 검증된 DP 메커니즘 라이브러리를 목표로 합니다. Opacus가 "ML 학습에 DP 적용"에 초점이라면, OpenDP는 "통계 쿼리, 분석, 데이터 릴리스에 DP 적용"이 주력입니다.

OpenDP의 핵심은 Rust로 작성된 핵심 메커니즘에 Python/R 바인딩을 제공하는 구조. 메모리 안전성과 수학적 정확성을 동시에 잡으려는 시도입니다.

9.2 OpenDP의 빌더 패턴

import opendp.prelude as dp
dp.enable_features("contrib")

# eps=1.0 보장 하에 평균 계산
input_domain = dp.vector_domain(dp.atom_domain(T=float, bounds=(0.0, 200.0)))
input_metric = dp.symmetric_distance()

trans_mean = (
    input_domain >> input_metric >>
    dp.t.then_clamp((0.0, 200.0)) >>
    dp.t.then_sum() >>
    dp.t.then_division_with_size(n=1000)
)
meas = trans_mean >> dp.m.then_laplace(scale=0.2)

heights = [165.0, 170.5, ...]  # 사용자 키 리스트
private_mean = meas(heights)
print(f"DP mean height: {private_mean}, eps spent: {meas.map(d_in=1)}")

OpenDP의 객체는 **변환(Transformation)**과 **측정(Measurement)**으로 나뉘며, 각 객체는 자기 자신의 프라이버시/안정성 boundary를 수학적으로 증명합니다.

9.3 PSI 통합과 SmartNoise

OpenDP는 Microsoft의 SmartNoise SDK의 백엔드로도 사용됩니다. SmartNoise는 SQL 쿼리에 자동으로 DP를 적용해주는 도구. WHERE/GROUP BY/JOIN 쿼리를 분석해 sensitivity를 자동 계산하고 노이즈를 추가합니다.

10. Google DP Library와 JAX-Privacy

10.1 Google DP Library

Google은 2019년 자체 C++ Differential Privacy Library를 오픈소스화했습니다. 핵심 알고리즘은 Laplace/Gaussian 메커니즘, BoundedSum, BoundedMean, Count, Quantile 등. Go, Java, C++, Python 바인딩이 있고, PipelineDP라는 Apache Beam 기반 분산 DP 처리기도 있습니다.

import pipeline_dp

# Apache Beam pipeline에서 DP 통계 산출
dp_engine = pipeline_dp.DPEngine(
    pipeline_dp.NaiveBudgetAccountant(total_epsilon=1.0, total_delta=1e-7),
    pipeline_dp.BeamBackend(),
)
params = pipeline_dp.AggregateParams(
    metrics=[pipeline_dp.Metrics.COUNT, pipeline_dp.Metrics.MEAN],
    max_partitions_contributed=3,
    max_contributions_per_partition=2,
)
dp_result = dp_engine.aggregate(pcollection, params, data_extractors)

10.2 JAX-Privacy

DeepMind가 만든 JAX 기반 DP 라이브러리. 대규모 모델(특히 LLM) 학습 시 Opacus보다 효율적인 vectorization을 제공합니다. 2024-2025년 DeepMind는 JAX-Privacy로 학습한 DP 언어 모델 결과를 다수 발표했습니다.

10.3 Google RAPPOR

Local DP의 산업계 첫 대형 적용 사례. Chrome 브라우저에서 사용자가 어떤 홈페이지를 기본값으로 쓰는지 통계를 수집하되, 각 사용자의 응답에 비트 단위로 노이즈를 더해 서버는 개별 사용자의 답을 알 수 없게 했습니다. 2014년 발표.

11. Homomorphic Encryption 개념 - CKKS, BFV, TFHE

11.1 FHE의 약속

Fully Homomorphic Encryption(FHE)은 "암호문에 대해 직접 연산을 수행하면, 그 결과를 복호화했을 때 평문에 대한 연산 결과와 같다"는 성질을 가진 암호 시스템입니다. 1978년 Rivest et al.이 가능성을 제기, 2009년 Craig Gentry가 첫 구체 구현을 발표.

FHE의 약속 - 클라이언트가 데이터를 암호화해 서버에 보내고, 서버는 데이터를 보지 못한 채 연산을 수행해 암호화된 결과를 돌려준다. 클라이언트만 복호화 가능. 궁극의 외주 계산.

11.2 주요 스키마들

스키마	특징	적합 워크로드
BGV(2012)	정수 평문	정수 산술, SQL 집계
BFV(2012)	정수 평문, 다항식 슬롯	SIMD 정수 연산
CKKS(2017)	근사 부동소수점	ML 추론, 통계
TFHE(2016)	비트 단위, 빠른 부트스트래핑	임의 회로, 비교, 조건
FHEW(2014)	TFHE의 전신	단일 비트 연산

ML 추론에는 주로 CKKS(부동소수점, 근사 연산)나 TFHE(임의 회로)가 사용됩니다.

11.3 부트스트래핑(Bootstrapping)

FHE의 핵심 도전 - 연산을 거듭할수록 암호문의 노이즈가 누적되어 결국 복호화가 안 되는 시점이 옵니다. 부트스트래핑은 "암호문을 자기 자신을 복호화하는 회로에 통과시켜 노이즈를 리셋"하는 마법 같은 기법입니다. 비용이 매우 높지만(밀리초-초 단위), 무제한 깊이 회로를 가능하게 합니다.

TFHE는 부트스트래핑이 빠르고(밀리초), 모든 게이트마다 부트스트래핑을 하는 "프로그램 가능한 부트스트래핑(Programmable Bootstrapping, PBS)" 전략을 씁니다. 이것이 Zama Concrete의 핵심입니다.

12. Zama Concrete - FHE 컴파일러의 새 시대

12.1 Zama와 Concrete

Zama는 2020년 파리에서 설립된 FHE 전문 기업입니다. CEO Rand Hindi, CTO Pascal Paillier(Paillier 암호의 그 Paillier). 2024년 시리즈 A에서 7,300만 달러를 펀딩했습니다. 핵심 제품은 Concrete라는 FHE 컴파일러.

전통적으로 FHE 라이브러리(SEAL, OpenFHE)는 "이 함수를 FHE로 직접 다시 작성하세요"라는 저수준 API를 제공했습니다. Zama Concrete의 혁명 - 일반 Python/Rust 코드를 FHE로 자동 컴파일합니다.

12.2 Concrete Python

from concrete import fhe

@fhe.compiler({"x": "encrypted", "y": "encrypted"})
def add_mul(x, y):
    return (x + y) * 2

inputset = [(i, i) for i in range(10)]
circuit = add_mul.compile(inputset)

# 키 생성
circuit.keygen()

# 클라이언트 측 - 입력 암호화
encrypted_input = circuit.encrypt(5, 7)

# 서버 측 - 암호문 위에서 연산
encrypted_result = circuit.run(encrypted_input)

# 클라이언트 측 - 복호화
decrypted = circuit.decrypt(encrypted_result)
print(decrypted)  # 24

이 단순함이 Zama의 강점입니다. 개발자는 FHE의 수학을 몰라도 됩니다.

12.3 Concrete-ML

ML 모델을 FHE로 컴파일하는 고수준 라이브러리. scikit-learn 호환 API를 제공합니다.

from concrete.ml.sklearn import LogisticRegression as ConcreteLogReg
from sklearn.datasets import load_iris

X, y = load_iris(return_X_y=True)
model = ConcreteLogReg(n_bits=8)
model.fit(X, y)

# FHE 회로로 컴파일
model.compile(X)

# 추론(평문)
y_pred = model.predict(X)

# 추론(FHE)
y_pred_fhe = model.predict(X, fhe="execute")

지원 모델 - Linear/Logistic Regression, Random Forest, XGBoost, Decision Tree, 작은 신경망. 2025-2026년에는 ViT 같은 트랜스포머 모델의 부분 FHE 추론(특히 어텐션 부분)도 데모로 공개됐습니다.

12.4 TFHE-rs

Concrete의 백엔드인 TFHE-rs는 Rust로 작성된 TFHE 라이브러리입니다. 2025년 GPU 가속이 추가되었고, 부울/정수 연산 모두 지원합니다.

use tfhe::{ConfigBuilder, generate_keys, FheUint8, prelude::*};

let config = ConfigBuilder::default().build();
let (client_key, server_key) = generate_keys(config);
set_server_key(server_key);

let a = FheUint8::encrypt(150u8, &client_key);
let b = FheUint8::encrypt(100u8, &client_key);

let sum = &a + &b;
let decrypted: u8 = sum.decrypt(&client_key);

12.5 fhEVM - 블록체인 위의 FHE

Zama의 또 다른 흥미로운 작업은 fhEVM - 이더리움 호환 EVM에 FHE 데이터타입(euint8, ebool 등)을 추가한 체인입니다. 비공개 트랜잭션, 비공개 투표, 비공개 DeFi가 스마트 컨트랙트로 가능해집니다.

13. Microsoft SEAL, IBM HElib, OpenFHE, Lattigo

13.1 Microsoft SEAL 4.1

Microsoft Research가 만든 C++ HE 라이브러리. BFV와 CKKS를 지원합니다. 2024년 4.1 버전이 발표되었고, 오랜 기간 학계와 산업의 표준 중 하나였습니다. Python 바인딩은 OpenMined의 TenSEAL이 인기.

13.2 IBM HElib

IBM Research가 2013년부터 개발한 BGV/CKKS 라이브러리. 부트스트래핑 최적화로 유명합니다. Shai Halevi와 Victor Shoup가 주도.

13.3 OpenFHE 1.2(전 PALISADE)

2022년 PALISADE 프로젝트가 더 광범위한 협업 형태로 재출범한 결과. BFV, BGV, CKKS, FHEW, TFHE까지 모두 지원하는 가장 포괄적인 라이브러리. Duality Technologies, Intel, Samsung, NJIT 등이 참여합니다. 2026년 5월 기준 1.2.x가 안정 버전.

13.4 Lattigo - 스위스 Tune Insight의 Go 라이브러리

EPFL Spinoff인 Tune Insight가 만든 Go 기반 HE 라이브러리. BFV, CKKS, 그리고 Multiparty HE(여러 당사자 키)를 지원합니다. Go 생태계에서 빠른 성능을 보입니다.

13.5 라이브러리 비교

라이브러리	언어	주요 스키마	강점
Microsoft SEAL	C++	BFV, CKKS	성숙, 문서, 표준
OpenFHE	C++	거의 모든 스키마	포괄성, 학계 협력
HElib	C++	BGV, CKKS	부트스트래핑 최적화
TFHE-rs	Rust	TFHE	Concrete 백엔드, GPU
Lattigo	Go	BFV, CKKS, MHE	Go, 멀티 파티
TenSEAL	Python	CKKS, BFV	SEAL 바인딩, OpenMined

14. Secure Multi-Party Computation 개념

14.1 Yao's Garbled Circuits(1986)

Andrew Yao의 백만장자 문제 - "두 백만장자가 누구 재산이 많은지 알고 싶지만, 각자의 정확한 재산은 공개하고 싶지 않다". Yao는 부울 회로를 "garbled" 형태로 만들어 한 명이 회로를 평가하고 다른 한 명이 입력을 oblivious transfer로 받는 2-party 프로토콜을 제안했습니다.

14.2 GMW 프로토콜(1987)

Goldreich, Micali, Wigderson은 임의 수의 당사자(n-party)에서 동작하는 secret sharing 기반 MPC를 제안했습니다. 각 비트를 XOR 비밀 공유로 나눠 갖고, AND/XOR 게이트를 처리합니다.

14.3 SPDZ(2012)와 그 후예들

SPDZ(Damgard et al., 2012)는 악의적 적(malicious adversary)에 강한 MPC 프로토콜. 사전 처리 단계에서 Beaver triple 같은 상관 랜덤성을 생성해 두고, 온라인 단계에서 빠르게 연산합니다. 이후 SPDZ2, MASCOT, Overdrive 등 변형이 나왔습니다.

14.4 보안 모델

Semi-honest(Honest-but-curious) - 프로토콜은 따르지만 메시지에서 정보를 추출하려 시도. 가장 약한 모델.
Malicious - 임의로 프로토콜을 위반. 가장 강한 보안 요구.
Covert - 위반하더라도 일정 확률로 탐지되면 만족.

15. CrypTen, MP-SPDZ, EzPC - PPML용 MPC 프레임워크

15.1 CrypTen(Meta/Facebook)

Facebook AI Research가 2020년 공개한 PyTorch 기반 MPC 라이브러리. PyTorch 텐서를 secret-shared 텐서로 래핑하여, ML 워크로드를 거의 그대로 MPC에서 실행 가능하게 만들었습니다.

import crypten
import torch

crypten.init()

# 두 당사자에서 각자 텐서를 만들고
x_party0 = torch.tensor([1.0, 2.0, 3.0])

# CrypTen 텐서로 변환(자동으로 secret-shared)
x_enc = crypten.cryptensor(x_party0, src=0)
y_enc = crypten.cryptensor([4.0, 5.0, 6.0], src=1)

# MPC 위에서 연산
z_enc = x_enc + y_enc

# 결과 복호화(양측 모두 동의 시)
z = z_enc.get_plain_text()
print(z)  # tensor([5., 7., 9.])

CrypTen은 의도적으로 semi-honest 보안 모델만 지원합니다. 빠르고 사용하기 쉬운 대신, 적이 거짓말하지 않는다는 가정에 의존.

15.2 MP-SPDZ

브리스톨 대학의 Marcel Keller가 주도하는 MPC 프레임워크. 30개 이상의 프로토콜(semi-honest, malicious, dishonest majority, honest majority)을 지원하는 사실상 MPC의 백과사전. 학계 벤치마크에서 자주 사용됩니다.

15.3 EzPC(Microsoft Research India)

EzPC는 "Easy Secure Multi-party Computation"의 약자. C 스타일 코드를 자동으로 secure 2-party 프로토콜로 컴파일합니다. CrypTFlow는 그 위의 ML 컴파일러로, TensorFlow 모델을 MPC로 변환합니다. 2023-2025년 BERT 같은 트랜스포머 모델을 MPC 추론하는 SIGMA, BumbleBee 같은 후속 작업이 발표되었습니다.

15.4 MPC의 통신 비용 문제

MPC의 가장 큰 비용은 연산이 아닌 통신입니다. AND 게이트마다 oblivious transfer 라운드가 필요하고, 이는 ms 단위의 RTT를 누적시킵니다. 결과적으로 MPC ML 추론은 같은 모델의 평문 추론보다 100배에서 10,000배 느릴 수 있습니다.

16. TEE - 하드웨어 격리의 길

16.1 Intel SGX와 그 위기

Intel Software Guard Extensions(SGX)는 2015년 도입된 x86 명령어 셋. CPU 내부에 격리된 enclave를 만들어 코드와 데이터를 호스트 OS, 하이퍼바이저, 심지어 BIOS로부터도 보호합니다. 한때 confidential computing의 표준이었습니다.

하지만 2018년 이후 Foreshadow, Spectre, Plundervolt, AEPIC Leak 등 일련의 사이드채널 취약점이 발견되면서 SGX의 보안 모델이 의심받기 시작했습니다. Intel은 2021년 클라이언트 CPU에서 SGX를 제거하기 시작했고, 서버 CPU에서는 SGX-DCAP를 통해 원격 attestation을 강화했습니다.

16.2 AMD SEV-SNP

AMD의 Secure Encrypted Virtualization-Secure Nested Paging은 VM 전체를 암호화합니다. SGX가 enclave 단위라면 SEV는 VM 단위. AWS, Azure, GCP의 confidential VM 제품들이 SEV-SNP 기반입니다.

16.3 Apple Private Cloud Compute(2024)

Apple이 2024년 WWDC에서 발표한 PCC는 TEE 역사상 가장 야심찬 시스템 중 하나입니다. 핵심 아이디어들 -

Custom Apple Silicon 서버 - Secure Enclave가 키 관리
Stateless 노드 - 요청 처리 후 모든 데이터 즉시 폐기, 영구 저장 없음
Code transparency - 노드에서 실행되는 모든 코드의 해시가 공개 투명성 로그에 게시
End-to-end attestation - 사용자 디바이스가 PCC 노드의 측정값을 검증
No privileged access - Apple 직원조차 노드 내부 데이터 접근 불가

2025년부터 Apple Intelligence의 일부 큰 모델 요청이 PCC를 통해 처리됩니다. 사용자 데이터가 Apple 서버로 갈 수는 있지만, Apple은 그것을 볼 수 없는 구조입니다.

16.4 AWS Nitro Enclaves

AWS의 Nitro 하이퍼바이저 위에서 만들어지는 격리된 가상 머신. EC2 인스턴스의 일부 vCPU/메모리를 떼어내 enclave로 만들고, 부모 EC2와는 vsock으로만 통신합니다. Nitro Security Module은 KMS와 통합되어 attestation 기반 키 릴리스를 제공합니다. 의료, 금융 분야 confidential 워크로드에서 인기.

16.5 NVIDIA H100/H200 Confidential Compute

2023년부터 NVIDIA GPU도 confidential computing 기능을 갖추기 시작했습니다. H100/H200 GPU에서 CPU side는 SEV-SNP/TDX, GPU는 자체 confidential 모드로 동작하며, GPU 메모리도 암호화됩니다. LLM 추론을 TEE에서 돌릴 수 있게 된 첫 GPU 세대입니다.

17. 실제 배포 사례 - 빅테크부터 한일 금융권까지

17.1 Google Gboard

가장 유명한 FL 사례. 안드로이드 Gboard 키보드는 사용자의 타이핑 데이터를 서버로 보내지 않으면서, 다음 단어 예측, 이모지 추천, 음성 인식 모델을 학습합니다. 매일 수백만 디바이스가 야간 충전 중에 학습에 참여합니다. Secure Aggregation으로 개별 그래디언트도 보호됩니다.

17.2 Apple

Siri 음성 인식 향상에 FL
이모지 추천에 Local DP
2024년부터 Apple Intelligence와 PCC

17.3 BraTS Federated와 의료

NVIDIA FLARE 기반 BraTS Federated는 71개 의료기관 협업으로 뇌종양 분할 모델을 학습했습니다(Pati et al., 2022). 이후 NVIDIA Clara FL은 흉부 X-ray, 병리학, 코로나 진단 등 다양한 협업 학습 사례를 만들고 있습니다.

17.4 MELLODDY

10개 글로벌 제약사(Janssen, Bayer, GSK, Novartis, AstraZeneca 등)가 IMI(Innovative Medicines Initiative)의 지원으로 2019-2022년 진행한 연합 학습 프로젝트. 각 사의 화합물-단백질 활성 데이터를 공유하지 않고 약효 예측 모델을 공동 학습했습니다. 결과적으로 예측 정확도가 단일 회사 모델 대비 향상되었고, 데이터는 한 글자도 회사 밖으로 나오지 않았습니다.

17.5 한국 금융권의 FL/MPC 적용

2023-2025년 한국에서 가명정보 결합과 데이터 결합전문기관 제도가 활성화되면서, FL과 MPC가 금융권 실무에 들어왔습니다.

신한은행, 국민은행, 우리은행은 결합전문기관(금융보안원, NICE 등)을 통한 데이터 결합으로 신용평가 모델을 협업합니다.
네이버클라우드는 금융권 대상 FL 플랫폼을 제공합니다.
통신사(SKT, KT, LGU+)와 카드사가 PSI 기반 광고 효율 측정에 참여 중.

17.6 일본 NTT R&D와 금융

NTT 연구소는 BFV 기반 HE를 활용해 일본 금융권 사기 탐지 협업 모델을 PoC 단계에서 진행했습니다. APPI(個人情報保護法) 하에서 가명 데이터를 활용한 공동 분석이 가능하지만, 그 안에서도 HE/MPC를 활용해 추가 보호층을 만드는 시도입니다. 2024-2025년 NTT 데이터, 미츠비시 UFJ, 미즈호 등이 다양한 PoC를 진행 중입니다.

18.1 GDPR과 PPML

GDPR Article 25(데이터 보호 by design and by default)는 PPML 기법을 사실상 권장합니다. Article 32(보안)와 함께 읽으면, "필요시 가명화, 암호화, 익명화 기법을 적용해야 한다"는 의무로 해석됩니다.

특히 GDPR Recital 26이 명시하는 "익명화된 데이터는 GDPR 적용 대상이 아니다"라는 점이 중요합니다. 잘 적용된 DP나 FHE는 GDPR 의무를 상당 부분 면제받을 가능성이 있습니다(법적 해석은 사례별).

18.2 HIPAA Safe Harbor와 Expert Determination

미국 HIPAA는 의료 데이터의 비식별화 방법으로 두 가지를 정의합니다. (1) Safe Harbor - 18개 식별자 제거, (2) Expert Determination - 통계 전문가의 위험 평가. DP 기반 비식별화는 Expert Determination 경로로 인정받는 사례가 늘고 있습니다.

18.3 EU AI Act와 PPML

2024년 발효된 EU AI Act는 고위험 AI(의료, 채용, 신용평가, 법 집행, 교육) 시스템에 대해 데이터 거버넌스(Article 10), 견고성과 정확성(Article 15), 인간 감독(Article 14) 요구사항을 부과합니다. 데이터 거버넌스 요구사항은 PPML 기법 채택의 강한 인센티브가 됩니다.

18.4 한국 PIPA와 가명정보

2020년 개정 PIPA(개인정보보호법)는 가명정보 개념을 도입했습니다. 추가 정보 없이는 특정 개인을 식별할 수 없게 처리된 정보로, 통계 작성, 과학적 연구, 공익 기록 보존 목적으로는 동의 없이 활용 가능합니다. 가명처리 기준은 PIPC(개인정보보호위원회) 고시에 따르며, k-익명성, l-다양성, t-근접성 같은 기법이 사용됩니다. 2023년부터 DP도 권장 기법에 포함되기 시작했습니다.

18.5 일본 APPI

일본 개인정보보호법(APPI)는 2022년 개정에서 **익명가공정보(anonymized processed information)**와 가명가공정보(pseudonymized processed information) 두 가지를 명확화했습니다. 익명가공정보는 동의 없이 제3자 제공 가능, 가명가공정보는 내부 분석용으로만. PPC(個人情報保護委員会)가 가이드라인을 제공합니다.

18.6 비교 요약

규제	지역	핵심 PPML 관련 조항
GDPR	EU	Art 25 (by design), Recital 26 (익명화)
HIPAA	US	Safe Harbor, Expert Determination
EU AI Act	EU	Art 10 (데이터 거버넌스), 고위험 AI
CCPA/CPRA	캘리포니아	Sensitive Personal Information 카테고리
PIPA	한국	가명정보, 결합전문기관
APPI	일본	익명가공정보, 가명가공정보
PIPL	중국	분리 동의, 데이터 출국 보안 평가

19. PPML 도입 체크리스트 - 어디서부터 시작할 것인가

19.1 위협 모델 정의

먼저 누구로부터 무엇을 보호할지 명확히 합니다.

외부 공격자로부터 학습 데이터 - DP가 핵심
다른 협업 기관으로부터 자기 데이터 - FL + Secure Aggregation
클라우드 사업자로부터 모든 데이터/모델 - TEE 또는 FHE
분석가로부터 raw 데이터 - PySyft 같은 structured transparency

19.2 정확도-프라이버시-효율 트라이앵글

PPML 기법은 본질적으로 트레이드오프입니다.

기법	정확도 영향	통신/계산 비용	보안 강도
Plain FL(no SecAgg)	거의 없음	중간	낮음
FL + SecAgg	거의 없음	중간	중간
FL + DP	1-5%p 손실	중간	높음
MPC inference	거의 없음	매우 높음	매우 높음
FHE inference	거의 없음(CKKS는 근사)	극도로 높음	매우 높음
TEE	없음	거의 없음	하드웨어 신뢰 가정

19.3 추천 시작점

소규모 협업 - Flower(시뮬레이션 -> 실제 배포)
의료/금융 컨소시엄 - NVIDIA FLARE
DP가 필요한 학습 - Opacus(이미 PyTorch라면)
DP 통계 릴리스 - OpenDP / SmartNoise / PipelineDP
클라우드 LLM 추론 보호 - TEE(Apple PCC 모델), Confidential VM
암호화된 추론 - Concrete-ML(쉬움) 또는 SEAL/OpenFHE(고급)

19.4 운영 측면

DP 회계(privacy accountant)는 매 실행마다 누적되어야 합니다. 데이터셋별 eps 한도 정책 필수.
모델 자체에 메타데이터 누설 방지(model serialization 시 클라이언트 정보 제거).
attestation 로그 보관 - TEE 사용 시 어떤 코드/펌웨어 버전이었는지 사후 감사 가능해야 함.
키 관리는 KMS/HSM에 위임. FHE 비밀키가 유출되면 모든 게 무너집니다.

20. 2026년의 전망 - PPML이 표준이 될 것인가

20.1 LLM 시대의 PPML 재정의

ChatGPT, Claude, Gemini가 사용자 입력을 보는 문제는 2024-2026년 PPML이 다시 주목받게 만들었습니다. Apple PCC는 첫 대규모 운영 사례이고, 다른 빅테크들도 비슷한 confidential AI 인프라를 만들고 있습니다. 2026년 5월 기준 -

Microsoft Azure Confidential AI - SEV-SNP + GPU TEE
Google Cloud Confidential GKE - AMD SEV / Intel TDX
AWS Nitro Enclaves + EC2 H100 confidential instances
Anthropic Constellation(Confidential Workloads)

20.2 FHE 가속 하드웨어

FHE의 100-10,000배 성능 페널티를 극복하기 위한 ASIC들이 등장하고 있습니다.

Optalysys(영국) - 광학 FHE 가속기
Cornami - FHE 전용 칩
Niobium Microsystems - DPRIVE(DARPA) 프로그램 ASIC
Intel Centaurus(DARPA DPRIVE)

이들이 양산화되면 FHE의 비용이 10-100배 낮아질 수 있습니다.

20.3 ZK + FHE + MPC의 융합

zk-SNARK(영지식 증명) 기술이 블록체인 발전 덕에 빠르게 성숙했습니다. 이와 FHE/MPC를 결합한 시스템들이 등장 중 - zkML, FHE on chain(fhEVM), MPC with attested integrity. PPML과 web3의 경계가 흐려지고 있습니다.

20.4 표준화 노력

IEEE P3652.1 - FL 표준
ISO/IEC 27559 - 비식별화 가이드
ISO/IEC 4922 - Secure Multi-Party Computation
IETF PPM(Privacy Preserving Measurement) - Prio3 등 LSPS 표준

20.5 시장 규모

Markets and Markets, Gartner, IDC 등은 PPML/Confidential Computing 시장이 2026년 100억 달러 규모로 성장하며, CAGR 50% 이상이라고 추정합니다. 가장 큰 견인차는 LLM 시대의 입력 프라이버시 요구.

20.6 마무리 - 데이터가 떠나지 않는 시대

10년 전 "빅데이터" 시대의 모토는 "데이터를 모아라"였습니다. 2026년 PPML 시대의 모토는 정반대 - "데이터를 그대로 두고, 답만 가져와라". Federated Learning은 모델을 옮기고, Differential Privacy는 답에 안전을 더하고, Homomorphic Encryption은 암호화된 채로 답을 만들고, MPC는 여러 당사자가 협업하고, TEE는 하드웨어 격리로 그것을 강제합니다.

이 5가지 기술은 서로 배타적이지 않습니다. 실제 시스템은 보통 2-3가지를 조합합니다 - FL + DP + Secure Aggregation, TEE + FHE, MPC + DP. 어떤 조합이 옳은가는 위협 모델, 정확도 요구, 통신 예산, 규제 환경에 따라 다릅니다.

확실한 것은 - 데이터를 옮기지 않고도 협업하고 학습하고 추론하는 시대가 이미 시작되었다는 점입니다.

참고 자료

Flower Labs - https://flower.ai/
Flower 1.13 Documentation - https://flower.ai/docs/framework/
NVIDIA FLARE GitHub - https://github.com/NVIDIA/NVFlare
NVIDIA FLARE Documentation - https://nvflare.readthedocs.io/
TensorFlow Federated - https://www.tensorflow.org/federated
OpenMined PySyft - https://github.com/OpenMined/PySyft
OpenMined.org - https://www.openmined.org/
Opacus (PyTorch DP) - https://opacus.ai/
OpenDP - https://opendp.org/
Google DP Library - https://github.com/google/differential-privacy
Microsoft SmartNoise - https://smartnoise.org/
Zama Concrete - https://www.zama.ai/concrete
Concrete-ML - https://docs.zama.ai/concrete-ml
TFHE-rs - https://github.com/zama-ai/tfhe-rs
Microsoft SEAL - https://github.com/microsoft/SEAL
OpenFHE - https://www.openfhe.org/
IBM HElib - https://github.com/homenc/HElib
Lattigo - https://github.com/tuneinsight/lattigo
CrypTen (Facebook) - https://crypten.ai/
MP-SPDZ - https://github.com/data61/MP-SPDZ
EzPC (Microsoft Research) - https://github.com/mpc-msri/EzPC
Apple Private Cloud Compute - https://security.apple.com/blog/private-cloud-compute/
AWS Nitro Enclaves - https://aws.amazon.com/ec2/nitro/nitro-enclaves/
Confidential Computing Consortium - https://confidentialcomputing.io/
McMahan et al., FedAvg (2017) - https://arxiv.org/abs/1602.05629
Abadi et al., DP-SGD (2016) - https://arxiv.org/abs/1607.00133
Pati et al., BraTS Federated (Nature Communications 2022) - https://www.nature.com/articles/s41467-022-33407-5
EU AI Act - https://artificialintelligenceact.eu/
Korea PIPA - https://www.pipc.go.kr/
Japan APPI / PPC - https://www.ppc.go.jp/