질문에 대한 답변.
질문의 배경
Swift의 동시성 발전은 단일 프로세스 내의 데이터 경합을 제거하기 위해 구조적 동시성과 지역 액터로 시작되었습니다. 서버 측 및 분산 시스템으로 언어가 확장됨에 따라 개발자들은 액터가 다른 머신에 있을 때 Swift의 엄격한 메모리 안전성과 격리 보장을 유지할 방법이 필요했습니다. DistributedActor 제안은 네트워크 호출이 지역 메서드 호출과 동일한 async/await 계약을 준수하도록 보장하는 컴파일러 검증 분산 컴퓨팅 모델을 도입했습니다.
문제
전통적인 원격 프로시저 호출은 런타임 코드 생성 또는 Swift의 타입 검사를 우회하는 동적 프록시에 의존하여 API 계약이 클라이언트와 서버 간에 변동할 때 실패하는 문제를 야기했습니다. 언어는 프로세스 경계를 넘는 메서드가 직렬화, 네트워크 지연 및 전송 오류를 명시적으로 처리하도록 컴파일 타임에 강제로 보장하는 메커니즘이 필요했습니다. 문제는 액터 프로그래밍 모델을 분할하거나 제로 비용 추상화 원칙을 희생하지 않고 지역 동기 실행과 원격 비동기 디스패치를 구별하는 것이었습니다.
해결책
distributed actor 선언은 암시적으로 ActorSystem 속성을 합성하여 모든 인스턴스에 전송 메커니즘을 주입합니다. distributed 키워드로 표시된 메서드는 모든 매개변수와 반환 값이 Codable 또는 Sendable을 준수하는지 컴파일 타임 검증을 거치며, 컴파일러는 호출을 가로채는 분산 스로트(distributed thunk)를 생성합니다. 원격 호출이 발생하면 ActorSystem은 인수를 마샬링하고 전송 계층을 통해 전송하며, 역직렬화가 완료될 때까지 호출자를 정지시킵니다. 이 모든 과정은 Swift의 구조적 동시성과 오류 처리 의미론을 유지하면서 이루어집니다.
실생활 사례
문제 설명
한 핀테크 스타트업이 iOS 클라이언트와 백엔드 매칭 엔진 간의 고주파 거래 상태를 동기화해야 했습니다. 기존 REST 구현은 직렬화 오버헤드를 초래하고 프로토콜 버전의 컴파일 타임 검증이 부족하여 메세지 스키마가 다른 시장 변동성에서 런타임 디코딩 오류가 발생했습니다.
첫 번째 고려된 솔루션: gRPC 및 프로토콜 버퍼
이 접근 방식은 언어 경계를 넘어 타입 안전한 코드 생성을 제공하고 효율적인 이진 직렬화를 제공합니다. 그러나 .proto 정의 파일과 복잡한 빌드 파이프라인 통합을 유지해야 하므로 Swift의 네이티브 동시성 모델과 불일치를 초래했습니다. 개발자들은 gRPC의 콜백 기반 API와 Swift의 async/await를 수동으로 연결해야 했고, 그 결과 비즈니스 로직을 가리는 보일러플레이트 코드가 생성되었습니다.
두 번째 고려된 솔루션: WebSocket을 통한 맞춤형 이진 프로토콜
맞춤형 프로토콜을 구축하면 성능 조절이 극대화되고 Swift의 구조적 동시성과 긴밀하게 통합됩니다. 단점은 원격 인터페이스에 대한 컴파일러 강제가 완전히 부족하여 매개변수 불일치를 잡기 위해 포괄적인 통합 테스트가 필요했습니다. 또한 위치 투명성 결여로 인해 개발자들은 로컬 캐시와 원격 엔진을 위해 평행 코드 경로를 유지해야 하므로 유지 보수 부담과 오류율이 증가했습니다.
선택된 해결책 및 결과
팀은 WebSocket을 통한 맞춤형 ActorSystem 구현으로 Swift DistributedActors를 채택했습니다. 이를 통해 거래 액터를 네이티브 Swift 구문으로 정의할 수 있었고, 컴파일러는 모든 분산 메서드 매개변수가 직렬화 가능하고 메서드가 async throws로 표시되었는지 검증했습니다. distributed 키워드는 네트워크 경계를 명시적으로 만들고 액터 시스템이 전송 메커니즘을 투명하게 처리하도록 했습니다. 결과적으로 원격 매칭 엔진과 상호작용하는 코드베이스는 로컬 상태 접근과 동일한 구문을 사용하게 되었고, 런타임 API 불일치가 제거되었으며 분산 시스템의 복잡성이 40% 감소했습니다.
후보자들이 종종 간과하는 점
분산 메서드는 구현이 완벽해 보일 때에도 왜 throws로 선언되어야 하나요?
Swift의 분산 액터 모델은 네트워크 실패를 구현 버그가 아니라 기본적인 물리학으로 취급합니다. 컴파일러는 모든 분산 메서드 주위에 throwing thunk를 합성하여 ActorSystem 오류, 전송 시간 초과 및 역직렬화 실패를 처리합니다. 비즈니스 로직이 절대 던지지 않더라도 기저 전송이 원격 호스트에 도달하지 못하거나 잘못된 패킷을 수신할 수 있습니다. 이 요구사항은 개발자들이 Swift의 do-catch 오류 처리를 사용하여 실패 모드를 처리하도록 강제하며, 네트워크 분할 동안 클라이언트가 중단되는 것을 방지합니다. throws 주석은 분산 메서드의 ABI 계약의 일부가 되어 호출자가 신뢰할 수 없는 네트워크 경계를 인식하게 합니다.
ActorSystem은 분산 액터의 물리적 위치를 어떻게 해결하며, 로컬 액터 참조가 원격 프로세스에 전달될 때 어떤 일이 발생하나요?
모든 DistributedActor는 생성한 ActorSystem에 의해 할당된 고유 ActorID를 가지며, 이는 액터의 위치를 나타내는 능력 토큰 역할을 합니다. 네트워크 경계를 넘는 분산 액터를 전달할 때 Swift의 런타임은 객체 포인터를 전송하지 않고, 액터의 encode(to:) 메서드를 사용해 ActorID를 인코딩합니다. 수신 프로세스는 동일한 ActorID를 공유하지만 로컬 ActorSystem에 바인딩된 프록시 액터 인스턴스를 생성합니다. 프록시가 메서드 호출을 받으면 시스템은 라우팅 테이블에 문의하여 ActorID가 원격 노드를 가리킬 경우 호출을 투명하게 전달합니다. 이는 액터가 네트워크를 통해 값으로 복사되지 않도록 보장하며, Swift의 동시성 안전성을 위해 중요한 단일 소유자 의미론을 유지합니다.
동일한 분산 액터 내에서 distributed 메서드를 일반 메서드와 구별하는 점은 무엇이며, 왜 후자는 원격으로 호출할 수 없나요?
DistributedActor 내부의 일반 메서드는 로컬 스레드에서 동기적으로 실행되며 격리된 상태에 직접 접근하여 분산 스로트 메커니즘을 우회합니다. 이러한 메서드는 ActorSystem을 통해 직렬화되지 않기 때문에 네트워크 지연이나 실패 모드를 견딜 수 없습니다. 컴파일러는 원격 호출을 distributed 메서드로 제한하는데, 이는 추가적인 검증을 거쳐야 하기 때문입니다: 이들은 async 및 throws여야 하며 모든 매개변수는 Sendable 또는 Codable을 준수해야 합니다. 원격 액터 참조에서 일반 메서드를 호출하려고 시도하면 컴파일 타임 오류가 발생하는데, 이는 컴파일러가 메서드가 직렬화를 처리하거나 분산 실행 의미론을 준수하는지 보장할 수 없기 때문입니다. 이러한 구별은 로컬 전용 작업의 성능을 보존하면서 네트워크 바운드 호출에 대한 엄격한 계약을 강제로 집행합니다.