CloudKit: 모든 엔티티의 프로퍼티 값을 옵셔널로 강제하는 이유

CloudKit와 옵셔널: 왜 모든 프로퍼티가 옵셔널이어야 할까?

이번에 앱을 만드는 과정에서 CoreData에 CloudKit을 연동시키려고 하자 앱이 빌드되지가 않았는데요.

문제는 기존의 엔티티 모델들의 속성 값들이 옵셔널이 아니기 때문이었습니다.

그렇다면 왜 CloudKit을은 모든 엔티티의 속성 값이 옵셔널로 강제하는 것일까요?

클라우드 환경의 불확실성

CloudKit은 네트워크를 통해 작동하는 원격 데이터베이스 시스템입니다. 로컬 데이터베이스와 달리, 네트워크 통신에는 여러 불확실성이 존재합니다

• 연결 중단: 사용자의 인터넷 연결이 언제든 끊길 수 있습니다.
• 데이터 전송 지연: 대용량 데이터를 전송할 때 시간이 오래 걸릴 수 있습니다.
• 부분적 데이터 전송: 모든 데이터가 항상 완전히 전송된다는 보장이 없습니다.
• 서버 부하: Apple의 서버가 과부하 상태라면 일부 데이터가 지연되거나 누락될 수 있습니다.

이런 상황에서 앱이 특정 프로퍼티 값이 항상 존재한다고 가정한다면, 네트워크 문제 발생 시 앱은 크래시될 가능성이 높아집니다. 옵셔널을 사용함으로써, 개발자는 값이 없는 상황에 대해 명시적으로 처리할 수 있게 됩니다.

// 안전하지 않은 접근 방식 (옵셔널 사용하지 않을 경우)
let name = record["name"] as! String // 값이 없으면 크래시!

// 안전한 접근 방식 (옵셔널 사용)
if let name = record["name"] as? String {
    // 이름이 있을 때의 처리
} else {
    // 이름이 없을 때의 대체 처리
}

부분적 레코드 업데이트의 자연스러운 지원

CloudKit에서는 레코드의 일부 필드만 업데이트하는 것이 매우 일반적입니다. 예를 들어, 사용자 프로필에서 이름만 변경하고 다른 정보는 그대로 유지하고 싶을 수 있습니다:

// 일부 필드만 업데이트하는 경우
let recordToUpdate = CKRecord(recordType: "UserProfile", recordID: existingRecordID)
recordToUpdate["name"] = "새 이름"
// 다른 필드(이메일, 전화번호 등)는 업데이트하지 않음

database.save(recordToUpdate) { record, error in
    // 저장 완료 후 처리
}

이 경우, 업데이트되지 않은 필드들은 서버에서 검색할 때 nil이 될 수 있습니다. 모든 프로퍼티가 옵셔널이면 이러한 부분 업데이트 시나리오가 자연스럽게 처리됩니다.

데이터 모델 진화와 유연성

앱 개발은 지속적인 과정입니다. 시간이 지남에 따라 데이터 모델은 변경됩니다.

• 새로운 필드가 추가됩니다.
• 기존 필드의 의미나 타입이 변경될 수 있습니다.
• 일부 필드는 더 이상 사용되지 않을 수 있습니다.

이런 변화 속에서 모든 프로퍼티를 옵셔널로 선언하면 다음과 같은 이점이 있습니다.

1. 하위 호환성: 이전 버전의 앱에서 생성된 레코드도 새 버전에서 문제 없이 처리할 수 있습니다.
2. 점진적 마이그레이션: 데이터 모델 변경 시 모든 레코드를 한 번에 업데이트할 필요 없이 점진적으로 마이그레이션할 수 있습니다.
3. 스키마 유연성: 새로운 필드를 추가하더라도 기존 코드는 그대로 작동합니다.

예를 들어, 앱의 V2에서 사용자 모델에 birthdate 필드를 추가했다고 가정해보겠습니다.

// V1 사용자 모델
struct UserV1 {
    let id: String
    let name: String?
    let email: String?
}

// V2 사용자 모델 (birthdate 추가)
struct UserV2 {
    let id: String
    let name: String?
    let email: String?
    let birthdate: Date? // 새로 추가된 필드
}

V1에서 생성된 레코드들은 birthdate 필드가 없지만, V2에서는 이 필드가 nil로 처리되어 자연스럽게 기존 코드베이스에 호환됩니다.

권한 및 액세스 제어의 자연스러운 처리

CloudKit은 매우 세밀한 액세스 제어 메커니즘을 제공합니다. 특정 사용자는 특정 필드에 접근할 수 없도록 설정할 수 있습니다. 이런 경우, 해당 필드는 nil로 반환됩니다.

// CloudKit 대시보드나 서버 측 설정에서 필드별 보안 설정
// 일부 사용자는 'secretField'에 접근할 수 없음

만약 모든 필드가 논옵셔널(non-optional)이라면, 권한이 없는 필드에 접근할 때마다 오류가 발생할 것입니다. 옵셔널을 사용하면 액세스 권한이 없는 필드를 자연스럽게 처리할 수 있습니다.

if let secretValue = record["secretField"] as? String {
    // 접근 권한이 있는 경우
} else {
    // 접근 권한이 없거나 값이 설정되지 않은 경우
}

서버 측 로직과의 호환성

CloudKit은 서버 측에서 다양한 로직을 실행할 수 있습니다. CloudKit 트리거나 자동화를 통해 일부 필드가 동적으로 설정되거나 변경될 수 있습니다. 예를 들어, 사용자가 새 레코드를 생성할 때 서버 측에서 자동으로 타임스탬프를 추가하는 경우가 있습니다.

이런 상황에서도 옵셔널 타입은 값의 존재 여부를 안전하게 확인할 수 있게 해줍니다:

if let creationTimestamp = record["createdAt"] as? Date {
    // 서버에서 설정한 타임스탬프 사용
}

네트워크 효율성 향상

CloudKit은 네트워크 효율성을 높이기 위해 다양한 최적화를 수행합니다. 그 중 하나가 델타 업데이트(delta updates)입니다. 변경된 필드만 전송함으로써 네트워크 트래픽을 줄입니다.

모든 프로퍼티가 옵셔널이면 이러한 최적화가 더 효과적으로 작동합니다. 서버는 변경된 필드만 전송하고, 변경되지 않은 필드는 nil로 표시할 수 있기 때문입니다.

결론: 제약이 아닌 설계 철학으로 이해하기

CloudKit에서 모든 프로퍼티를 옵셔널로 강제하는 것은 단순한 제약이 아닙니다. 이는 클라우드 기반 데이터 저장소의 근본적인 특성을 반영한 설계 철학입니다.

이 접근 방식을 통해 

• 네트워크 불확실성에 대비합니다
• 부분 업데이트를 자연스럽게 지원합니다
• 데이터 모델 진화를 용이하게 합니다
• 액세스 제어를 효과적으로 처리합니다
• 서버 측 로직과의 호환성을 보장합니다
• 무엇보다, 앱의 안정성과 복원력을 향상시킵니다