[Review] Architectural patterns for the design of federated learning systems

0. Abstract

Federated learning has received fast-growing interests from academia and industry to tackle the challenges of data hungriness and privacy in machine learning. A federated learning system can be viewed as a large-scale distributed system with different components and stakeholders as numerous client devices participate in federated learning. Designing a federated learning system requires software system design thinking apart from the machine learning knowledge. Although much effort has been put into federated learning from the machine learning technique aspects, the software architecture design concerns in building federated learning systems have been largely ignored. Therefore, in this paper, we present a collection of architectural patterns to deal with the design challenges of federated learning systems. Architectural patterns present reusable solutions to a commonly occurring problem within a given context during software architecture design. The presented patterns are based on the results of a systematic literature review and include three client management patterns, four model management patterns, three model training patterns, four model aggregation patterns, and one configuration pattern. The patterns are associated to the particular state transitions in a federated learning model lifecycle, serving as a guidance for effective use of the patterns in the design of federated learning systems

- 본 연구는 연합학습(Federated Learning, FL) 시스템의 설계를 위한 15가지 소프트웨어 아키텍처 패턴을 제안

- FL 시스템은 데이터 프라이버시를 유지하면서 분산 학습을 수행하지만 실제 구현 시 설계 상의 여러 문제가 존재

- 본 연구는 기존 문헌과 실제 산업 사례를 분석하여 반복적으로 등장하는 설계 문제와 해결 구조를 패턴으로 정리

- 총 15개의 아키텍처 패턴을 제시하며 제안된 패턴들은 연합 학습 시스템 설계 시 재사용 가능한 구조적 가이드 라인을 제공

1. Short Background

- 연합학습은 데이터를 중앙에 모으지 않고, 각 사용자 단말(클라이언트)에서 로컬 모델을 학습한 뒤 중앙서버에서 이를 집계하는 분산형 학습 방식임

- FL은 개인정보 보호와 데이터 활용을 동시에 달성할 수 있어, 최근 산업계와 학계에서 빠르게 주목받고 있음.

- 그러나 수많은 클라이언트, 네트워크 지연, 데이터 이질성 등으로 대규모 분산 소프트웨어 시스템처러 복잡하게 동작함.

- 기존 연구들은 주로 머신러닝 알고리즘 개선에 집중했으며, 소프트웨어 아키텍처 설계 관점에서의 접근은 부족

- 즉, FL 시스템은 단순히 모델 학습 기술이 아니라, 클라이언트 관리, 모델 버전 추적, 통신 효율, 보안 및 배포 구조를 포함한 통합적 시스템 설계가 필수적임

2. Methods

- 연합학습 시스템에서는 반복적으로 발생하는 설계상의 문제를 체계적으로 분석하고 해결하기 위한 아키텍처 패턴을 정의함

- 연구팀은 소프트웨어 공학의 패턴 언어 접근법을 활용하며, 체계적 문헌 고찰 (Systematic Literature Review, SLR) 수행

패턴 수집 과정 (SLR)

1단계 논문 조사

- Initial search → ‘페더레이티드 러닝 시스템’ 관련 논문들을 광범위하게 검색

- Paper screening → 주제에 진짜 관련 있는 논문만 남김

- Snowballing → 참고문헌에 있는 다른 논문들도 찾아 추가

- Quality check → 논문이 믿을 만한지 평가

- Data extraction → 자주 등장하는 설계 문제와 해결법을 추출

- Reporting → 지금까지 조사한 내용을 정리

 

2단계 실무조사

- Extra literature review → 논문 외의 보고서나 기술문서, 최신 연구도 함께 조사

- Real-world application review → 실제 기업이나 오픈소스 FL 시스템(Azure, Google FL 등)을 직접 분석

 

3단계 통합 및 정리

- 앞의 두 단계를 합쳐서 중복된 내용을 통합하고 15개의 공통 패턴을 최종 정의함.

- 마지막에 논문 본문에 패턴 설명서 형태로 보고(reporting)

 

- 해당 수집과정을 통해 패턴 후보군(pattern candidates)을 도출하고, 중복되는 개념을 통합하여 최종 15개 패턴으로 정리함.

 

패턴의 분류 기준

- 도출된 패턴들은 모델 생애 주기의 단계와 연결됨

- 각 단계에서 발생하는 문제를 해결하기 위해 아래와 같이 5개 그룹으로 분류함.

Client Management	3	클라이언트 참여 관리, 선택, 그룹화
Model Management	4	모델 버전, 압축, 교체, 배포 관리
Model Training	3	학습 전략, 데이터 이질성 처리, 인센티브 제공
Model Aggregation	4	분산 모델 집계, 보안, 계층적 통합
Configuration	1	사용자 친화적 시스템 설정 자동화

 

각 패턴의 구성요소

- 모든 패턴은 동일한 5단 구조로 기술됨

Context (문맥)	문제가 발생하는 환경 또는 상황
Problem (문제)	해결해야 할 핵심 이슈
Solution (해법)	일반화된 구조적 해결책
Consequences (결과)	장단점 및 트레이드오프
Known Uses (적용 사례)	실제 플랫폼 또는 논문 사례

 

검증 및 매핑

- 각 패턴은 FL 모델의 생애주기 단계(client registration → training → aggregation → deployment)에 매핑되어 있음.

- 연구진은 각 단계별 설계문제를 실제 사례와 비교하여 제안된 패턴들이 현실적이고 재상용 가능함을 검증함.

 

3. Results

- 연구 결과 연합학습 시스템 설계에서 반복적으로 나타나는 구조적 문제들을 해결하기 위한 15개의 아키텍처 패턴 도출

- 이 패턴들은 FL 모델의 전체 생애주기(클라이언트 등록 -> 모델 학습 -> 집계 -> 배포 -> 재구성) 과정에 맞춰 구성됨

(1) Client Management Patterns (3개)

- Client Registry Pattern

Context (문맥)	중앙 서버가 수천 개의 클라이언트를 관리하는 대규모 FL 환경. 클라이언트의 접속 상태, 자원 스펙, 참여 시점이 계속 변동됨.
Problem (문제)	중도 이탈·오류·악성 클라이언트를 추적하기 어렵고, 학습 이력 기록이 부재하면 라운드 정렬(sync)과 모델 신뢰성이 저하됨.
Solution (해법)	모든 클라이언트를 중앙 등록부(Registry)에 등록하여 식별자, 접속 시간, 상태, 자원정보, 참여 이력을 기록·관리함. 이를 통해 클라이언트 상태를 추적하고 악성 노드 식별 가능.
Consequences (결과)	장점: 관리 용이성·신뢰성 향상, 악성 노드 조기 탐지. 단점: 개인정보 유출 위험(접속·자원 메타데이터), 저장·통신 비용 증가.
Known Uses (적용 사례)	IBM Federated Learning(Party Stack), doc.ai, Siemens Mindsphere Asset Manager.

 

- Client Selector Pattern

Context (문맥)	수백~수천 개의 클라이언트 중 일부만 참여하는 대규모 FL 학습 환경. 네트워크 상태, 자원 스펙이 불균형함.
Problem (문제)	모든 클라이언트를 동시에 참여시키면 속도 저하·통신 과부하가 발생하고, 비효율적인 클라이언트 선택은 학습 품질 저하로 이어짐.
Solution (해법)	네트워크 지연, 장치 성능, 데이터 품질 등을 기반으로 동적 클라이언트 선택 알고리즘 적용. 효율적인 샘플링으로 매 라운드 학습 대상 자동 선정.
Consequences (결과)	장점: 학습 속도 및 효율 향상, 리소스 절약. 단점: 일부 클라이언트 데이터가 지속적으로 배제될 가능성 존재.
Known Uses (적용 사례)	FedCS (Wang et al., 2019), Google FL API.

 

- Client Cluster Pattern

Context (문맥)	클라이언트 간 데이터 분포(Non-IID)가 다르고, 자원 수준이 불균형한 환경.
Problem (문제)	서로 다른 데이터 분포로 인해 글로벌 모델이 특정 그룹에만 편향될 수 있음.
Solution (해법)	유사한 데이터·리소스 특성을 가진 클라이언트들을 클러스터 단위로 묶어 부분 학습을 수행하고, 결과를 병합.
Consequences (결과)	장점: Non-IID 문제 완화, 정확도 향상. 단점: 클러스터 재조정 시 통신 및 연산 부하 증가.
Known Uses (적용 사례)	IFCA, Clustered FL (CFL), Personalized FL.

 

 

(2) Model Management Patterns (4개)

- Message Compressor Pattern

Context (문맥)	클라이언트가 학습 후 전송하는 로컬 모델의 크기가 커서, 중앙 서버로의 통신이 병목이 되는 환경.
Problem (문제)	대규모 모델 파라미터를 빈번히 전송하면 네트워크 지연, 에너지 소비, 전송 실패가 발생함.
Solution (해법)	모델 업데이트를 압축(Compressor) 기법(양자화, 희소화, 해싱 등)을 통해 전송량을 최소화함.
Consequences (결과)	장점: 통신 비용·시간 절감, 전송 효율 향상. 단점: 압축으로 인한 미세한 성능 손실 가능, 추가 인코딩 연산 부담.
Known Uses (적용 사례)	Deep Gradient Compression (DGC), SignSGD, QSGD.

 

- Model Co-versioning Registry Pattern

Context (문맥)	각 클라이언트와 중앙 서버에서 모델 버전이 달라질 수 있는 환경 (비동기 학습, 지연된 업데이트 등).
Problem (문제)	모델 버전 불일치 시, 업데이트 충돌·불일치가 발생해 수렴 실패나 성능 저하 초래.
Solution (해법)	모든 모델 버전을 버전 레지스트리(Registry)로 관리. 각 라운드별 버전 해시, 작성자, 적용 시간, 메타데이터를 기록해 동기화 유지.
Consequences (결과)	장점: 추적성, 재현성 향상 / 버전 간 충돌 방지. 단점: 저장 공간 증가, 버전 관리 복잡도 상승.
Known Uses (적용 사례)	MLflow, DVC, Pachyderm, Azure ML Workspace.

 

- Model Replacement Trigger Pattern

Context (문맥)	모델이 배포 후 시간이 지나며 데이터 환경 변화로 점차 성능이 저하되는 환경.
Problem (문제)	성능 저하를 수동으로 탐지·교체하면 지연이 발생하고, 안정적 서비스 제공이 어려움.
Solution (해법)	글로벌 모델 성능 모니터링 시스템을 두고, 성능 임계값 이하 시 자동 교체 트리거를 발동하여 다시 학습하여 모델 전환.
Consequences (결과)	장점: 자동화된 유지보수, 안정적 성능 유지. 단점: 트리거 설정 오류 시 불필요한 모델 교체 반복 가능.
Known Uses (적용 사례)	Amazon SageMaker Model Monitor, Azure ML Designer.

 

- Deployment Selector Pattern

Context (문맥)	학습된 모델을 다양한 환경(클라우드, 엣지, 모바일)에 배포해야 하는 상황.
Problem (문제)	환경별 리소스·네트워크 차이로 인해 동일 모델이 비효율적으로 동작하거나 실패할 수 있음.
Solution (해법)	시스템이 자동으로 배포 환경을 탐지하고, 각 클라이언트(모델 사용자)의 데이터 특성이나 애플리케이션 유형을 검사하고, 이에 가장 적합한 모델 버전을 매칭 (예: 환경 인식 기반 배포)
Consequences (결과)	장점: 리소스 활용 최적화, 효율적 배포. 단점: 환경 인식 오류 시 잘못된 배포로 성능 저하 가능.
Known Uses (적용 사례)	Google Cloud AI Platform, AWS SageMaker, Azure ML Pipelines.

 

(3) Model Training Patterns (3개)

- Multi-Task Model Trainer Pattern

Context (문맥)	클라이언트마다 데이터 특성이 다르지만 관련된 여러 작업을 동시에 학습해야 하는 환경.
Problem (문제)	단일 모델이 다양한 데이터 분포를 다루기 어려워, 각 클라이언트의 개별 특성이 반영되지 않음.
Solution (해법)	멀티태스크 학습(MTL) 구조를 적용해, 공유 계층에서는 글로벌 지식을 학습하고 로컬 전용 계층에서는 개별 데이터를 학습함.
Consequences (결과)	장점: 여러 작업 간 정보 공유로 학습 효율과 일반화 성능 향상 단점: 모델 구조가 복잡해지고 태스크 간 간섭(interference) 위험이 있음.
Known Uses (적용 사례)	FedMTL, MOCHA (Smith et al., 2017), FedProx 기반 멀티태스크 학습.

 

- Heterogeneous data handler Pattern

Context (문맥)	클라이언트별 데이터가 비독립·비동일 분포(Non-IID) 상태로 존재하는 분산 환경.
Problem (문제)	데이터 편향과 분포 차이로 인해 모델이 특정 그룹에 과적합되거나 불안정하게 수렴함.
Solution (해법)	데이터 클래스 가중치 조정, 데이터 증강, 로컬 정규화, 손실 함수 보정 등을 통해 Non-IID 문제를 완화함.
Consequences (결과)	장점: 모델 수렴 안정화, 클라이언트 간 공정성 향상. 단점: 추가 연산량 증가 및 프라이버시 제약으로 세밀한 통계 활용이 어려움.
Known Uses (적용 사례)	FedProx (Li et al., 2020), Scaffold, FedNova, Clustered FL.

 

- Incentive Mechanism Pattern

Context (문맥)	클라이언트가 자발적으로 참여해야 하는 환경(예: 모바일, IoT).
Problem (문제)	참여자가 연산·데이터 제공 비용을 부담하지만 보상이 부족해 참여율이 낮아짐.
Solution (해법)	블록체인 기법 기여도(정확도 향상, 데이터 품질, 참여 횟수 등)에 따라 인센티브를 부여하는 보상 시스템 구축.
Consequences (결과)	장점: 참여율 증가 및 데이터 다양성 확보. 단점: 기여도 산정의 투명성 확보가 어려우며 관리 비용이 발생함.
Known Uses (적용 사례)	BlockFL (Kang et al., 2020), WeBank FATE incentive module, FLock.

 

(4) Model Aggregation Patterns (4개)

- Asynchronous Aggregator Pattern

Context (문맥)	클라이언트의 네트워크 속도나 계산 능력이 제각각인 환경에서, 일부 느린 클라이언트(Straggler)가 전체 학습 속도를 저하시킴.
Problem (문제)	모든 클라이언트가 모델 업데이트를 끝낼 때까지 기다리면 전체 학습이 지연되고, 시스템 효율이 떨어짐.
Solution (해법)	몇 개의 업데이트만 도착해도 즉시 새로운 글로벌 모델을 계산하여 준비된 클라이언트들에게 배포 느리게 도착하는 업데이트는 해당 라운드에서는 제외되지만,다음 라운드에 지연 가중치(delay weight)를 적용하여 반영
Consequences (결과)	장점: 학습 속도 향상 및 시스템 지연 감소. 단점: 일부 클라이언트의 업데이트 반영 시점 차이로 수렴 안정성이 떨어질 수 있음.
Known Uses (적용 사례)	FedAsync, FedBuff, FedAT 등 비동기 FL 프레임워크.

 

- Decentralised Aggregator Pattern

Context (문맥)	중앙 서버에 모든 모델 업데이트가 집중되면 단일 장애점(SPoF)이 생기고, 확장성이 제한됨.
Problem (문제)	중앙화된 집계 구조는 통신 병목·보안 위협·서버 과부하를 유발할 수 있음.
Solution (해법)	분산 집계(Decentralised aggregation)를 적용해 클라이언트 간 P2P 방식으로 모델을 교환하고, 집계 역할을 분산시킴.
Consequences (결과)	장점: 단일 장애점 제거, 신뢰성 향상. 단점: 네트워크 토폴로지 복잡화, 모델 일관성 유지 어려움.
Known Uses (적용 사례)	Swarm Learning (HPE), DFL, Gossip FL, blockchain-FL 구조.

 

- Hierarchical Aggregator Pattern

Context (문맥)	수천~수만 개 클라이언트가 여러 지역이나 엣지 서버를 통해 연결된 대규모 분산 환경.
Problem (문제)	모든 클라이언트가 중앙 서버로 직접 업데이트를 전송하면 통신 부하와 지연이 과도하게 커짐.
Solution (해법)	계층적 집계(Hierarchical aggregation) 구조 도입 지역(Edge) 수준에서 부분 집계를 수행하고, 상위(Global) 서버에서 최종 통합.
Consequences (결과)	장점: 통신 효율 및 확장성 향상. 단점: 계층 간 지연·불일치로 인한 집계 오차 발생 가능.
Known Uses (적용 사례)	HierFAVG, EdgeFed, FedHC, Cross-silo FL (Google).

 

- Secure Aggregator Pattern

Context (문맥)	로컬 모델 업데이트에 개인정보가 포함될 수 있는 환경 (의료·금융 등).
Problem (문제)	중앙 서버가 개별 클라이언트의 모델을 직접 확인하면 프라이버시가 침해될 수 있음.
Solution (해법)	보안 집계(Secure aggregation) 동형암호 기법 사용 — 클라이언트가 업데이트를 암호화하고, 서버는 전체 합(sum)만 복원함. (예: Secure Multi-Party Computation, Homomorphic Encryption)
Consequences (결과)	장점: 개인정보 보호 강화, 신뢰도 향상. 단점: 암호화·복호화 계산비용과 통신 오버헤드 증가.
Known Uses (적용 사례)	Google Secure Aggregation Protocol (Bonawitz et al., 2017), PySyft, NVFlare Secure FL.

 

(5) Configuration Pattern (1개)

- Training Configurator Pattern

Context (문맥)	Federated Learning 시스템에서는 여러 클라이언트, 모델, 데이터셋, 학습 설정(예: 학습률, 통신 주기, 모델 버전 등)을 동시에 관리해야 하는 복잡한 환경이 존재함. 연구자나 개발자는 각 학습 라운드마다 설정을 수동으로 변경·조정해야 함.
Problem (문제)	학습 설정이 분산되어 있거나 비표준화된 경우, 실험 재현이 어렵고 설정 오류(Configuration drift)가 발생함. 특히 다수의 클라이언트가 참여할 경우, 동일한 설정을 일관성 있게 적용하기 어렵다.
Solution (해법)	중앙 관리형 Training Configurator(훈련 설정 관리자) 를 도입하여 사용자가 코드 수정 없이 학습 프로세스와 모델 설정을 손쉽게 구성·배포·버전 관리할 수 있게 함. 이를 통해 파라미터를 통합 관리하고, 모델 업데이트 주기·통신 빈도·로깅 설정 등을 자동화함.
Consequences (결과)	장점: 실험 재현성 향상, 유지보수 용이, 자동화된 학습 설정 관리 가능. 단점: 중앙화된 설정 시스템 장애 시 전체 학습이 중단될 위험, 설정 서버의 접근 제어 필요.
Known Uses (적용 사례)	TensorFlow Federated Config API, NVFlare ConfigManager, OpenFL Orchestrator Config, PySyft Pipeline Config.

 

4. Conclusion 

- 연합 학습 시스템 설계 시 반복적으로 등장하는 문제를 해결하기 위해 15개의 아키텍처 패턴을 제안

- FL 시스템의 소프트웨어 아키텍처 설계 측면에서의 체계적인 접근을 제공

- 모델 생명주기 각 단계에 대응되는 패턴을 명확히 정의하여, 설계자들이 실제 환경에 맞는 패턴을 선택 작용에 도움

- 제시된 패턴 모음은 FL시스템을 구축할 때 품질 속성간의 균형을 고려할 수 있게 하며 산업적 규모의 FL 시스템 개발을 체계적 설계 프레임 워크를 제시함.

 

5. Discussion

- 각 패턴이 FL 시스템의 비기능적 요구사항(non-functional requirements) 즉 성능, 신뢰성, 보안, 효율성 등—에 어떤 영향을 미치는지를 트레이드오프 관점에서 분석함.

Client Management Patterns	Client RegistryClient SelectorClient Cluster	• 모델 및 학습 효율성 향상 • 학습 참여자 관리 및 자원 최적화	• 클라이언트 정보 수집으로 인한 보안·프라이버시 위험 • 클라이언트 추적/등록 관리 비용 증가
Model Training Patterns	Multi-Task Model TrainerHeterogeneous Data HandlerIncentive Registry	• Non-IID 데이터 문제 완화• 개인화 모델 성능 향상 • 참여 유도 및 다양성 확보	• 연산 부하 증가 • 보안 위협(악의적 노드, 데이터 편향)
Model Aggregation Patterns	Asynchronous AggregatorHierarchical AggregatorDecentralised / Secure Aggregator	• 통신 병목 완화 및 효율 향상 • 확장성 높은 집계 구조 제공	• 지연(latency) 및 일관성(consistency) 저하 가능 • 추가 계층 구조로 복잡도 상승
Configuration Pattern	Training Configurator	• 사용자 친화적 인터페이스 제공 • 자동화된 설정 및 관리로 사용성 향상	• 확장성·유연성 부족 • 단일 장애점(SPoF) 발생 가능성

 

- 각 패턴은 특정 품질 속성을 향상시키지만 동시에 다른 속성에는 부정적 영향을 줄수 있음

- 제안된 패턴 프레임워크는 모든 문제를 완전히 해결은 못하지만 설계 선택시 품질 속성 간 트레이드오프를 체계적으로 고려 가능