연합학습을 위한 분산 클라이언트 패키지 관리 시스템 구축 방안

1. 서론

연합학습(Federated Learning, FL)은 데이터를 중앙 서버로 이동시키지 않고, 분산된 클라이언트(기기 또는 사일로)에 존재하는 데이터를 활용하여 머신러닝 모델을 학습하는 기술입니다. 이 과정에서 중앙 서버는 학습 코드, 모델 구조, 설정 등을 클라이언트에 배포하고, 클라이언트는 로컬 학습 후 업데이트된 모델 가중치(또는 그래디언트)만을 서버로 전송합니다.

 

이때, 수천에서 수백만 개에 이를 수 있는 분산된 클라이언트에 학습 코드와 관련 종속성을 안정적이고, 안전하며, 효율적으로 배포하는 것이 큰 도전 과제입니다. 본 문서는 이러한 연합학습 환경의 특수성을 고려한 패키지 관리 시스템(Package Management System, PMS)의 구축 방안을 제안합니다.

2. 핵심 구성 요소

안정적인 FL 패키지 관리 시스템은 크게 '중앙 리포지토리', '패키지 포맷', '클라이언트 에이전트'의 세 가지 요소로 구성됩니다.

2.1. 중앙 패키지 리포지토리 (Central Package Repository)

모든 버전의 FL 패키지를 저장하고 배포하는 중앙 저장소입니다.

• 기능:
  • 버전 관리: SemVer(Semantic Versioning, 예: 1.2.3)를 사용한 엄격한 버전 관리.
  • 보안 저장소: GPG 서명이나 해시(SHA-256 등)를 통해 패키지의 무결성을 보장하고, 저장소 자체에 대한 접근 제어(IAM 등)를 구현합니다.
  • 플랫폼별 저장: 동일 버전이라도 타겟 플랫폼(예: android-arm64, linux-x86_64, ios-arm64)별로 다른 바이너리/패키지를 저장하고 구분할 수 있어야 합니다.
• 구축 방안:
  • 솔루션 활용: JFrog Artifactory, Sonatype Nexus와 같은 상용 아티팩트 저장소 솔루션을 활용합니다.
  • 클라우드 스토리지 기반: AWS S3, Google Cloud Storage 등에 버전 및 플랫폼별로 구조화된 경로(예: s3://fl-packages/my-project/1.0.1/linux-x86_64/package.tar.gz)를 생성하고, 메타데이터는 별도 DB(예: DynamoDB, RDBMS)에서 관리합니다.

2.2. 패키지 표준 포맷 및 매니페스트

클라이언트에 배포될 코드와 종속성을 묶는 표준화된 방식입니다.

• 패키지 구조 (예시: tar.gz 또는 zip):fl-package-v1.2.0.tar.gz

├── run.py                 # 학습 실행 스크립트 (Entrypoint)
├── model/                 # 모델 구조 정의 (예: .py, .pb, .onnx)
├── requirements.txt       # Python 종속성 목록
├── lib/                   # 사전 빌드된 라이브러리 (필요시)
└── manifest.json          # ★ 패키지 메타데이터 파일

• 매니페스트 (manifest.json): 패키지 관리의 핵심 파일입니다.

{
  "packageName": "credit-fraud-model",
  "version": "1.2.0",
  "platform": "linux-x86_64",
  "entrypoint": "run.py",
  "dependencies": [
    { "name": "tensorflow", "version": "2.10.1" },
    { "name": "pandas", "version": "1.8.0" }
  ],
  "checksum": "sha26-abcdef123...",
  "signature": "gpg-signature-blob..."
}

2.3. 클라이언트 에이전트 (Client Agent)

각 클라이언트 디바이스에 설치되어 패키지 수명 주기를 관리하는 경량 소프트웨어입니다.

• 주요 책임:
  1. 업데이트 확인: 클라이언트는 새 학습 라운드에 참여하라는 요청을 받을 때, 또는 정해진 유휴 시간(Jitter 포함)에 중앙 FL 서버(Orchestrator)에 "체크인"하여 새 패키지 버전을 확인합니다.
  2. 다운로드: 리포지토리로부터 새 패키지를 다운로드합니다. (이어 받기, 저대역폭 최적화 필요)
  3. 무결성 검증: 다운로드 후, manifest.json의 체크섬(checksum)과 서명(signature)을 검증하여 패키지가 변조되지 않았는지 확인합니다. (매우 중요)
  4. 환경 격리 및 설치:
     • 기존 시스템과 충돌하지 않도록 격리된 환경에 패키지를 설치합니다.(예: Python venv, conda 환경 생성, Docker 컨테이너 풀링, 모바일 앱 내의 샌드박스 폴더)
     • manifest.json에 명시된 종속성을 설치합니다.
  5. 실행: FL 서버의 요청에 따라 격리된 환경에서 entrypoint 스크립트를 실행합니다.
  6. 롤백: 검증 또는 설치 실패 시, 즉시 이전 버전으로 롤백하고 서버에 실패를 보고합니다.
  7. 상태 보고: 현재 설치된 버전, 업데이트 성공/실패 여부 등을 중앙 서버에 보고합니다.

3. 주요 고려 사항

단순히 파일 배포를 넘어 FL 환경에 특화된 다음 사항들을 반드시 고려해야 합니다.

3.1. 보안 및 무결성 (가장 중요)

• 코드 서명 (Code Signing): 리포지토리에 업로드되는 모든 패키지는 신뢰할 수 있는 키(예: GPG)로 서명되어야 합니다. 클라이언트 에이전트는 이 서명을 검증하기 전에는 절대 코드를 실행해서는 안 됩니다.
• 전송 계층 보안: 리포지토리 및 FL 서버와의 모든 통신은 HTTPS/TLS를 사용해야 합니다.
• 최소 권한 실행(Principle of Least Privilege): 클라이언트 에이전트는 격리된 환경(예: 샌드박스, Docker 컨테이너의 non-root 유저, Android의 앱별 저장 공간)에서 학습 코드를 실행해야 합니다. 이 환경은 명시적으로 허용된 데이터 폴더 외에는 파일 시스템 접근, 네트워크 호출, 시스템 리소스 접근을 기본적으로 차단해야 합니다.

3.2. 환경 격리 (Dependency Hell 방지)

이기종 클라이언트 환경에서 종속성 충돌은 치명적입니다.

• 컨테이너 (서버/엣지): Docker 또는 이와 유사한 컨테이너 기술은 가장 강력한 격리 방법을 제공합니다. 패키지 자체가 Docker image가 될 수 있습니다.
• 가상 환경 (Python): Python 기반 클라이언트의 경우, venv 또는 conda를 사용하여 각 패키지 버전에 맞는 격리된 Python 환경을 동적으로 생성/삭제합니다.
• 모바일 (Android/iOS): 모바일 앱은 자체 샌드박스를 가집니다. FL 코드는 앱의 일부(라이브러리)로 포함되며, 패키지 관리는 "앱 업데이트" 또는 앱 내 "동적 코드 로딩" 메커니즘을 통해 이루어집니다. (예: TensorFlow Lite 모델 파일 및 관련 로직 업데이트)

3.3. 네트워크 및 대역폭 최적화

• 델타 업데이트 (Delta Updates): 전체 패키지를 다시 받는 대신, 이전 버전과의 차이점(binary diff)만 다운로드하여 대역폭을 절약합니다.
• 압축: 패키지는 gzip, zstd 등으로 압축되어야 합니다.
• 다운로드 관리: 네트워크가 불안정한 클라이언트를 위해 이어 받기(Resumable downloads) 및 백그라운드 다운로드를 지원해야 합니다.

3.4. 배포 및 롤백 전략

모든 클라이언트에 동시에 배포하는 것은 위험합니다.

• 카나리 배포 (Canary Release): 전체 클라이언트의 1%, 5%, 20%... 순으로 점진적으로 배포하여 안정성을 모니터링합니다.
• A/B 테스팅: 서로 다른 패키지 버전(예: 다른 하이퍼파라미터)을 다른 클라이언트 그룹에 배포하여 성능을 비교할 수 있습니다.
• 강제 롤백: 중앙 서버에서 특정 버전에 심각한 오류를 감지하면, 해당 버전을 실행 중인 모든 클라이언트에 즉시 롤백 명령을 내릴 수 있어야 합니다.

4. 단계별 구축 로드맵

Phase 1: MVP (최소 기능 제품)

• 리포지토리: S3 버킷 또는 간단한 Nginx/Apache HTTPS 서버.
• 패키지 포맷: tar.gz + manifest.json (SHA-256 체크섬만 포함).
• 클라이언트 에이전트:
  • 단순 Python 스크립트.
  • 지정된 폴더에 tar.gz 다운로드 및 압축 해제.
  • 체크섬 검증.
  • subprocess를 사용해 run.py 실행.
  • 환경 격리 없음 (시스템 Python 사용) - 종속성 충돌 위험 높음.
• 배포: 수동으로 버전 업로드 및 클라이언트에 공지.

Phase 2: 강화 (Hardening)

• 리포지토리: Artifactory 또는 Nexus 도입.
• 패키지 포맷: GPG 서명(signature)을 manifest.json에 추가.
• 클라이언트 에이전트:
  • 서명 검증 로직 추가 (실패 시 즉시 중단).
  • Python venv를 사용한 환경 격리 구현.
  • 설치 실패 시 이전 버전 폴더로 복귀하는 기본 롤백 기능 추가.
• 배포: FL Orchestrator가 API를 통해 클라이언트에 "새 버전 사용"을 지시.

Phase 3: 확장 및 최적화 (Scale-Out)

• 리포지토리: CDN을 연동하여 전 세계 클라이언트에 빠른 다운로드 제공.
• 패키지 포맷: 델타 업데이트 지원 (예: bsdiff).
• 클라이언트 에이전트:
  • 이기종 플랫폼(ARM, x86 등) 지원 로직 추가.
  • (서버/엣지) Docker 기반 환경 격리 지원.
  • 네트워크 이어 받기 기능 구현.
• 배포: 중앙 서버 대시보드를 통한 카나리 배포, A/B 테스팅, 실시간 모니터링 및 강제 롤백 기능 구현.

5. 결론

연합학습을 위한 패키지 관리 시스템은 단순한 파일 배포 시스템이 아니라, 분산 시스템의 안정성과 보안을 책임지는 핵심 인프라입니다.  초기에는 MVP로 시작하더라도, 시스템의 확장에 따라 보안(코드 서명), 환경 격리, 롤백 전략을 지속적으로 강화해 나가야만 수백만 대의 이기종 클라이언트 환경에서 안정적인 연합학습 생태계를 유지할 수 있습니다.