데이터를 옮기지 않고 학습하기 — Federated·Swarm·Split Learning 아키텍처 비교

병원 두 곳이 힘을 합쳐 진단 모델을 개선하고 싶은데, 환자 데이터는 병원 밖으로 한 줄도 나갈 수 없다는 제약이 있다고 하자. 데이터를 모으는 대신 모델을 데이터가 있는 곳으로 보내는 접근이 분산 AI(Distributed AI)다. 데이터 이동을 최소화하면서 개인정보 보호 요구를 충족해야 하는 상황이 늘면서, Federated Learning, Swarm Learning, Split Learning 세 방식이 실무에서 함께 비교되는 경우가 많아졌다. 이 글은 세 방식의 구조와 보안 메커니즘, 실제 적용 사례를 정리한다.

방식별 핵심 차이

Federated Learning(FL)은 데이터를 로컬에 그대로 두고, 모델 파라미터나 그라디언트만 중앙 오케스트레이터로 모아 집계하는 라운드 기반 학습 방식이다. FedAvg, FedProx가 대표 알고리즘이다.

Swarm Learning(SL)은 중앙 서버 자체를 없앤다. P2P 네트워크와 블록체인·스마트컨트랙트로 모델을 집계·검증하며, 합의 프로토콜로 무신뢰(trustless) 환경에서 서로를 검증한다.

Split Learning(SPL)은 모델을 클라이언트와 서버로 물리적으로 나눈다. 클라이언트는 얕은 레이어만, 서버는 깊은 레이어를 맡고 중간 활성화(activation)와 그라디언트만 주고받는다. 데이터 유출을 최소화하면서도 중앙의 가속기 자원을 활용할 수 있다는 게 강점이다.

공통으로 갖춰야 할 것들

세 방식 모두 클라이언트(데이터 소유·로컬 학습), 오케스트레이션·합의 계층, 보안 계층(암호화·차등 개인정보 보호), 모델 레지스트리·버저닝이라는 구성 요소를 공유한다. 통신 프로토콜로는 gRPC·HTTP2를, 메시지 포맷으로는 Proto·JSON을 주로 쓴다. 핵심 흐름은 로컬 데이터를 입력받아 로컬 학습이나 분할 추론을 처리하고 글로벌 모델 갱신·재배포를 출력하는 것인데, 여기에 라운드 배리어와 재시도, 정합성 검증을 붙여야 장애와 일관성을 함께 잡을 수 있다.

FL은 중앙 오케스트레이터가 라운드를 동기화하고 파라미터 서버(PS)가 집계하는 구조다. 지연이나 이탈하는 노드에 대비해 타임아웃, 부분집계, 가중치 보정을 적용한다. 보안 쪽에서는 안전 합산(Secure Aggregation)과 차등 개인정보 보호(DP), 전송 계층 암호화(TLS)를 쓰고, 중독(poisoning) 공격을 막기 위해 Krum·Trimmed Mean 같은 로버스트 집계를 함께 쓴다.

SL은 P2P 토폴로지 위에 블록체인·스마트컨트랙트로 집계 규칙과 검증 로직을 내장한다. 리더 선출이나 라운드 로빈 방식으로 모델 병합을 트리거하고, 변경 불가능한 로그와 PBFT류 합의로 무결성을 보장한다. 다만 네트워크 지연이나 포크가 생기면 처리량이 떨어질 수 있고, 거버넌스와 키 관리가 운영의 핵심 부담이 된다.

SPL은 모델을 어디서 자를지(layer cut)를 설계하는 게 시작이다. 전방패스 활성화를 보내고 후방패스 그라디언트를 받는 구조인데, 활성화가 재식별되거나 그라디언트에서 원본이 역추론될 위험이 있어 노이즈 주입, 암호화, 분할 위치 탐색이 함께 필요하다.

운영 측면에서는 라운드 시간, 참여 수, 수렴률, 통신량, 실패율, 준법 감사 로그를 모니터링하고 MLflow·Weights & Biases 같은 도구로 모델 레지스트리·실험을 추적한다. 데이터 로컬리티, 동의 관리, 키·토큰 수명주기, 블록체인 거버넌스 같은 정책도 함께 정의해야 하고, 결국 정확도-프라이버시-통신비용 사이에서 균형을 잡는 게 운영의 본질이다.

⤢✕

어디에 쓰이는가

헬스케어 다기관 학습에서는 병원 간 데이터 이동 금지를 지키면서 질병 예측·세분화 모델을 고도화하는 게 목적이다. FL이나 SL을 기반으로 DP와 안전 합산을 결합하고, 로버스트 집계로 데이터 편향·중독에 대응한다. 교차 병원 라운드 스케줄링과 네트워크 창구 시간대 예약, 모델 성능 편차 모니터링·재가중치가 운영 포인트다.

제조·스마트팩토리 엣지 학습은 설비 상태 예지와 불량 탐지가 목적이다. FL로 공장별 데이터를 로컬에서 학습하고, 통신량을 줄이기 위해 양자화나 스케치 기법을 쓴다. 교대·정비 시간대에 라운드를 맞추고 장치 이탈에 대비한 리샘플링, 버전 롤백 메커니즘을 갖춘다.

금융 사기 탐지와 온디바이스 개인화는 개인정보 민감 규제를 지키면서 기기 단에서 개인화하는 게 목적이다. FL cross-device 방식에 프라이버시 예산 관리와 클라이언트 샘플링 전략을 병행하고, 참여자 수가 들쭉날쭉한 환경에 대응하기 위해 FedAsync·FedBuff류의 비동기 수렴 가속 기법을 쓰기도 한다.

고비용 가속기를 공유해야 하는 환경에서는 데이터는 각 사이트에 두고 대형 모델의 후반부만 중앙 가속기로 보내는 방식이 맞는다. Split Learning으로 활성화·그라디언트를 교환하고, 분할 경계를 자동으로 탐색하면서 활성화 암호화와 속도-정확도 최적화를 함께 다룬다.

도입 전 체크리스트

먼저 데이터 로컬리티 규제, 모델 크기, 실시간성, 예산을 정의하고 위협 모델과 위험 평가를 수행한다. 다음으로 cross-silo와 cross-device, 중앙집중과 P2P와 분할 학습 중 무엇을 택할지 통신·보안 오버헤드와 수렴 특성을 놓고 비교한다. 보안 설계 단계에서는 DP 예산(ε, δ)을 설정하고 안전 합산·HE·SMPC 중 채택할 것을 정하며, 키·토큰 수명주기와 로버스트 집계·이상치 탐지 정책을 함께 설계한다. MLOps 통합에서는 데이터 스키마를 고정하고 모델 레지스트리·실험 추적·CI/CD 파이프라인을 구성하며 장애·롤백·블루그린 배포 전략을 세운다. 마지막으로 정확도·AUC·라운드 시간·참여율·통신량 같은 메트릭과 감사 로그, 블록체인 거버넌스, SLA·SLO를 관측 체계로 정의한다.

지표로 놓고 비교하면

항목	Federated Learning	Swarm Learning	Split Learning
성능	중앙 집계로 수렴 안정성 우수, 통신량 최적화 용이	합의 오버헤드로 처리량 저하 가능, 리더 선출 비용 존재	서버 가속기 활용 시 대형 모델 유리, 활성화 전송 오버헤드 존재
확장성	수만 클라이언트까지 검증, 샘플링/비동기 전략 풍부	네트워크 노드 증가 시 합의 복잡도 증가	클라이언트·서버 스케일 비대칭 확장, 파이프라인 병렬화 필요
일관성	라운드 배리어로 강한 일관성, 부분집계로 유연성 확보	합의로 최종 일관성 보장, 포크 처리 필요	미니배치·파이프라인 지연에 따른 약한 일관성, 최종 수렴 보장
안정성	중앙 장애 지점 존재, 이중화/리더-팔로워로 완화	중앙 무관, 네트워크 분할 시 지연 증가	네트워크/가속기 장애 시 재시도·세션 복구 필수
운영 편의	성숙한 프레임워크 다수, 운영 자동화 용이	체인 관리·거버넌스 복잡, 키 관리 부담	스플릿 경계·보안 설정 튜닝 필요, 디버깅 난이도 존재

보안·프라이버시에서 감수해야 할 트레이드오프

차등 개인정보 보호는 ε를 줄일수록 프라이버시가 강해지지만 정확도가 떨어질 수 있어서, 적응형 노이즈와 클리핑으로 균형을 맞춘다. 안전 합산·암호화는 SMPC·HE를 적용하면 통신·연산 오버헤드가 늘어나므로 집계 주기를 완화하거나 클라이언트를 샘플링해 비용을 제어한다. 로버스트 집계(Krum·Median·Trimmed Mean)는 중독 공격을 완화하지만 수렴 속도가 느려질 수 있어 이상치 스코어 기반 가중치 조정을 함께 쓴다. Split Learning에서는 활성화·그라디언트 보호를 위해 압축·암호화, 라벨 혼합, GradPerturb 같은 기법을 적용하는데 역추론 공격 방어와 정확도 사이에서 균형을 잡아야 한다. 거버넌스·감사 측면에서 블록체인 로그는 불변 감사를 가능하게 하지만 운영 복잡도가 늘어나므로 체인 크기와 합의 파라미터를 최적화할 필요가 있다.

간단한 예제로 보는 FL(Flower 기반)

전제조건은 Python 3.10, Flower 1.x 이상, PyTorch 2.x 이상, 운영 환경에서는 TLS 인증서 준비다. 버전은 최신 정보를 확인해야 한다.

서버 쪽 코드는 FedAvg 전략으로 최소 10개 클라이언트, 최소 가용 클라이언트 50개를 기준으로 집계 전략을 구성한다.

# server.py
import flwr as fl

def weighted_average(metrics):
    total = sum(num for num, _ in metrics)
    acc = sum(num * m["accuracy"] for num, m in metrics) / total
    return {"accuracy": acc}

strategy = fl.server.strategy.FedAvg(
    fraction_fit=0.1, fraction_evaluate=0.1, min_fit_clients=10,
    min_available_clients=50, evaluate_metrics_aggregation_fn=weighted_average,
)

if __name__ == "__main__":
    fl.server.start_server(server_address="0.0.0.0:8080", strategy=strategy)

클라이언트 쪽은 NumPyClient를 상속해 파라미터 get/set, fit, evaluate를 구현하는 형태다.

# client.py
import flwr as fl
import torch

class Client(fl.client.NumPyClient):
    def __init__(self, model, trainloader, testloader, device="cpu"):
        self.model, self.trainloader, self.testloader, self.device = model, trainloader, testloader, device

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

    def set_parameters(self, params):
        state_dict = dict(zip(self.model.state_dict().keys(), [torch.tensor(p) for p in params]))
        self.model.load_state_dict(state_dict, strict=True)

    def fit(self, params, config):
        self.set_parameters(params)
        # ... 로컬 학습 루프(에폭/미니배치, DP 옵셔널) ...
        return self.get_parameters({}), len(self.trainloader.dataset), {}

    def evaluate(self, params, config):
        self.set_parameters(params)
        # ... 평가 루프 ...
        return 0.5, len(self.testloader.dataset), {"accuracy": 0.85}

if __name__ == "__main__":
    # model, loaders 초기화 생략
    fl.client.start_numpy_client(server_address="server.example.com:8080", client=Client(model, train, test))

운영 포인트는 min_available_clients를 조정해 이탈에 견고하게 만들고, fraction_*으로 통신량을 제어하며, DP-SGD를 적용할 경우 클리핑·노이즈 파라미터를 튜닝하는 것이다.

무엇을 얻는가

정량적으로는 데이터를 이관하지 않고 원위치에서 학습하기 때문에 네트워크 비용이 파라미터 전송 수준으로 줄어드는데, 환경에 따라 10100배 축소가 가능하다는 사례도 있다. 중앙 데이터 레이크를 새로 구축·보관할 필요도 줄어든다. 적응형 샘플링·가중치 보정을 적용하면 라운드 수가 1030% 줄어드는 사례도 있고, 장애가 생겨도 부분집계로 라운드 실패율이 줄어든다. 정성적으로는 규제 준수와 거버넌스가 강화되고 파트너십 확대가 쉬워지며, 지식 공유와 데이터 주권을 동시에 달성할 수 있다. 보안사고 노출면이 줄고, 특히 Swarm의 불변 로그는 감사 추적성을 강화하는 데 도움이 된다.

무엇을 먼저 고를 것인가

조직 특성에 따라 갈린다. 대규모 상용 운영과 도구 성숙도를 중시한다면 Federated Learning이 가장 안전한 선택이다. 중앙 신뢰를 줄이고 상호 검증이 필요하다면 Swarm Learning을 고려할 만하고, 대형 모델과 가속기 효율을 중시한다면 Split Learning이 우선순위가 된다. 어느 쪽을 택하든 DP·안전 합산·로버스트 집계·관측 체계를 함께 결합해 정확도-프라이버시-비용의 균형을 최적화하는 작업은 공통으로 필요하다.