Migrating the Password Monitoring service from Java
안녕하세요. 그린입니다 🍏
이번 포스팅에서는 Swift at Apple: Migrating the Password Monitoring service from Java 이라는 Swift 공식 블로그글을 토대로 한번 정리해보겠습니다 🙋🏻
Swift at Apple: Migrating the Password Monitoring service from Java
Swift is heavily used in production for building cloud services at Apple, with incredible results. Last year, the Password Monitoring service was rewritten in Swift, handling multiple billions of requests per day from devices all over the world. In compari
www.swift.org
얼마 전 Apple 공식 Swift 블로그에 재밌는 글이 올라왔습니다.
자바로 구축돼 있던 Apple의 비밀번호 모니터링 서비스를 완전히 Swift로 마이그레이션했다는 내용이였어요.
단순한 취미 프로젝트가 아니라, 실제 프로덕션에서 수억 명을 대상으로 서비스되고 있는 시스템을 Swift로 운영하고 있다는 얘기인데요.
Swift가 iOS 클라이언트뿐만 아니라 서버에서도 가능성을 인정받기 시작했다는 점에서 무척 흥미롭습니다.
이번 글에서는 해당 사례를 바탕으로, 왜 Apple이 자바 대신 Swift를 선택했는지, 어떤 기술적 이슈들을 만났는지, 그리고 그 선택이 어떤 결과를 가져왔는지를 하나씩 뜯어보려고 합니다 ☺️
What's this Service?
Apple의 패스워드 모니터링 서비스는 사용자 iCloud Keychain에 저장된 비밀번호가 유출된 적이 있는지를 확인해주는 기능입니다.
우리가 iOS에서 자주 보는 “이 비밀번호는 유출된 적이 있습니다”라는 알림이 바로 여기서 옵니다.
이 시스템은 기본적으로 아래 두 가지 역할을 합니다.
1️⃣ Bloom filter를 이용해 Apple이 수집한 유출된 비밀번호 데이터를 압축 저장
2️⃣ 클라이언트(iOS/macOS 등)로부터 요청이 오면, 해당 비밀번호가 유출 목록에 포함되는지 확인 후 알려줌
이렇게만 보면 단순한 REST API 같지만, Apple은 이 서비스를 개인정보 보호를 극단적으로 강조하는 구조로 만들었어요.
사용자의 비밀번호가 서버에 직접 전달되지 않도록, 클라이언트에서 암호화된 요청을 보내고, 서버는 오직 대응되는 bit vector만 응답해주는 구조입니다.
즉, 이건 단순한 패스워드 확인 API가 아니라, 상당히 정교하게 설계된 시스템입니다.
Story from JAVA
초기 구현은 Java로 작성되었고, 클라우드 상의 컨테이너 환경에서 작동했어요.
Java는 이미 검증된 서버 언어이고, JVM 위에서 잘 동작하기 때문에 선택된 것도 당연합니다.
하지만 시간이 지나면서 몇 가지 문제가 나타났어요.
1️⃣ 성능 병목: 메모리 중심의 작업(Bloom filter 연산)에 자바 GC가 간섭하는 경우가 생김
2️⃣ 빌드/배포 비용: Java 애플리케이션 특성상 이미지 빌드 시간이 길고 크기도 큼
3️⃣ 애플 생태계와의 이질감: 애플 내부에서 Swift가 점점 메인스트림이 되어가는데, 이 서비스만 자바로 운영되고 있었음
결국 Apple은 이 서비스를 Swift로 다시 쓰기로 결정합니다.
쉽게 말해 “우리가 만든 언어로 우리가 서비스를 돌리자”는 거라고 생각됩니다.
Migration to Swift
Swift는 원래 클라이언트 사이드 언어로 설계되었지만, 최근 몇 년 간 서버 사이드 생태계도 점점 커지고 있습니다.
Vapor, SwiftNIO 등을 중심으로 성숙해진 지금, Apple은 충분히 쓸 수 있는 언어라고 판단했습니다.
Apple이 선택한 아키텍처 구성은 다음과 같아요.
- SwiftNIO 기반의 비동기 서버
- 독립적인 모듈로 분리된 계층 구조 (예: crypto, storage, bloom-filter 등)
- Swift Concurrency 적극 활용 (특히 async/await 기반으로 구조가 깔끔해짐)
- Docker 기반 배포
가장 핵심은 기존 자바에서 쓰던 Bloom filter 관련 로직을 Swift로 재작성하는 부분이었는데, 이 과정에서 성능 최적화와 코드 구조 개선을 함께 진행했습니다.
What's changed after changing to Swift
1️⃣ 성능 향상
- GC 간섭 없이 메모리 사용량 제어 가능 (Swift는 ARC 기반)
- Binary 크기 약 78% 감소
- 실행 속도 개선: API 응답 평균 30% 향상
- Start-up time 감소: 컨테이너 기동 속도 빨라짐
2️⃣ 보안 및 신뢰성 향상
- Swift의 타입 시스템을 적극 활용해 논리 오류 가능성 낮춤
- 비동기 처리에서 발생할 수 있는 race condition을 Swift Concurrency로 안정적으로 제어
3️⃣ 내부 개발 문화와의 통합
- 다른 Swift 기반 도구들과의 통합이 쉬워짐 (예: 로깅, 모니터링)
- 코드 리뷰, 문서화 등 애플 내부 도구와의 연계가 훨씬 자연스러움
Conclusion
Apple은 단순히 '자바가 싫어서' Swift로 바꾼 게 아니라고 생각해요.
실무적인 성능, 코드의 유지보수성, 그리고 전체 생태계 통합 측면에서 Swift가 더 낫다고 판단했기 때문이지 않을까 합니다.
이 사례는 Swift가 단순한 iOS 앱 개발 언어를 넘어, 범용 언어로 확장되고 있음을 보여주는 대표적인 예시라고 생각합니다.
References
Swift at Apple: Migrating the Password Monitoring service from Java
Swift is heavily used in production for building cloud services at Apple, with incredible results. Last year, the Password Monitoring service was rewritten in Swift, handling multiple billions of requests per day from devices all over the world. In compari
www.swift.org