먼저 구분할 점은 “지원이 들어왔다”와 “운영 중인 앱을 지금 옮겨야 한다”는 서로 다른 판단이라는 것입니다. 공식 안내는 React Native 0.88의 SwiftPM 지원을 실험적으로 설명하며, 사용하려면 활성화가 필요하다고 밝힙니다. CocoaPods 경로도 여전히 지원됩니다. 따라서 출시 프로젝트의 기본 선택은 현행 의존성 경로 유지입니다. 0.88 출시 안내의 SwiftPM 설명과 SwiftPM 관련 제안 문서를 함께 확인하세요.

공식 문서에서 다음 버전의 기본 경로 변경 계획을 언급하더라도, 이는 계획이지 현재 프로젝트에서 이미 적용된 동작이 아닙니다. 이전 판단은 현재 공식 상태와 프로젝트의 빌드 결과를 기준으로 하세요.

새 프로젝트에서 시험할 수 있는 조건

네이티브 의존성 목록이 짧고, 각 라이브러리가 SwiftPM 경로를 문서화했으며, 출시와 분리된 시험 브랜치를 만들 수 있다면 시험을 시작할 만합니다. React Native의 라이브러리 연결 문서는 라이브러리 연결 방식을 확인하는 출발점입니다. 다만 문서에 라이브러리가 나온다는 사실만으로 해당 프로젝트 조합의 SwiftPM 호환성이 보장되는 것은 아닙니다.

운영 중인 프로젝트에서 먼저 확인할 위험

플러그인이 CocoaPods 설정에 의존하거나, 자체 설치 스크립트가 의존성 파일을 수정하거나, 빌드 단계에서 특정 워크스페이스를 전제로 한다면 곧바로 경로를 바꾸지 마세요. 문제 발생 시 앱 코드, 의존성 방식, 출시 설정 가운데 무엇이 원인인지 분리하기 어려워질 수 있습니다.

CocoaPods 이전 전에 확인할 대상은 React Native 핵심 부분만이 아닙니다. 네이티브 모듈, 서드파티 라이브러리, 프로젝트 자체 스크립트까지 출처와 설치 방식을 확인해야 합니다. React Native 문서는 라이브러리 연결 방식을 설명하지만, 모든 외부 라이브러리의 SwiftPM 지원 여부를 보증하지는 않습니다. 확인되지 않은 항목은 호환으로 표시하지 말고 “검증 필요”로 남기세요.

CocoaPods와 SwiftPM을 한 프로젝트에서 섞어도 될까요?

두 경로를 함께 쓰는 것이 프로젝트 전체에서 문제없다고 미리 가정하지 마세요. 사용하려는 라이브러리와 React Native 설정이 혼합 경로를 어떻게 처리하는지 확인하고, 같은 네이티브 라이브러리가 두 방식으로 중복 연결되지 않는지도 살펴야 합니다. React Native의 SwiftPM 제안 문서와 각 라이브러리의 설치 안내를 기준으로 판단하세요. 문서로 확인되지 않는 조합은 별도 브랜치에서 검증하기 전까지 출시 경로에 넣지 않는 편이 낫습니다.

SwiftPM 시험은 기존 출시 브랜치에서 의존성 방식과 배포 설정을 한꺼번에 바꾸는 작업이 아닙니다. 먼저 복사본이나 독립 브랜치에서 현재 상태를 보존하고, 한 번에 비교할 변수를 줄이세요.

• 기존 CocoaPods 설정, 잠금 상태, 빌드 스크립트를 보존합니다.
• 시험 브랜치에서 React Native의 공식 안내에 따라 SwiftPM 경로를 활성화합니다.
• 라이브러리별 설치 문서와 실제 프로젝트 설정을 대조합니다. 근거가 없는 라이브러리는 호환으로 간주하지 않습니다.
• 의존성 해석, 빌드, 시뮬레이터 실행, 출시 작업을 각각 따로 확인합니다.
• 문제가 생기면 시험 브랜치를 폐기하거나 기존 설정으로 돌아갈 수 있는지 확인합니다.

SwiftPM과 CocoaPods의 차이는 단순히 설치 도구 하나를 바꾸는 데 그치지 않습니다. Xcode 안에서 패키지를 추가하고 관리하는 흐름은 Apple의 패키지 의존성 추가 안내에서 확인할 수 있습니다. 반면 프로젝트의 기존 스크립트, 플러그인 설정, 팀의 잠금 파일 관리 방식이 그대로 호환되는지는 별도로 시험해야 합니다. Ruby 등 기존 도구를 덜 사용하게 될 가능성만으로 전체 이전 비용이 낮아진다고 결론 내리면 안 됩니다.

깨끗한 체크아웃에서 의존성이 풀렸다는 사실은 앱이 빌드되고 정상 동작하며 출시 가능한 상태라는 뜻이 아닙니다. 검증 결과를 다음처럼 나누어 기록하세요.

• 의존성 해석: 새 체크아웃에서 필요한 패키지와 잠금 상태가 재현되는지 확인합니다.
• iOS 빌드: 실제 프로젝트 설정으로 빌드가 끝나는지 확인합니다.
• 앱 동작: 시뮬레이터에서 주요 화면과 네이티브 기능을 시험합니다.
• 출시 경로: 아카이브와 업로드 등 프로젝트의 실제 배포 절차를 확인합니다. 업로드 절차는 Apple의 App Store Connect 빌드 업로드 안내를 참고하세요.

검증 장비의 macOS와 Xcode 조합도 확인해야 합니다. Apple은 Xcode 시스템 요구 사항에 지원 환경을 안내하므로, 시험에 쓰는 Xcode가 해당 macOS에서 동작하는지 먼저 대조하세요. 지속적 통합 환경에서 패키지를 해석하는 절차는 Apple의 연속 통합 빌드 안내도 참고할 수 있습니다.

로컬 맥이 없어도 검증할 수 있을까요?

로컬에 맥이 없다면 실제 macOS와 Xcode를 제공하는 환경에서 프로젝트를 시험해야 합니다. 다만 원격 환경을 쓴다는 사실만으로 빌드가 보장되지는 않습니다. 프로젝트가 요구하는 도구 체인, 의존성, 네트워크 접근, 서명과 업로드 권한을 확인하고, 깨끗한 체크아웃부터 출시 절차까지 직접 재현하세요. 맥 미니 대여 비용 안내는 원격 맥을 시험 환경으로 마련할지 검토할 때 참고할 수 있습니다.

아래 조건 분기로 최종 판단을 내리세요.

• 핵심 네이티브 의존성의 SwiftPM 경로를 확인했고, 깨끗한 체크아웃부터 앱 동작과 출시 절차까지 재현했다면 시험 범위를 단계적으로 넓힙니다.
• 일부 라이브러리만 확인됐거나 혼합 경로의 동작이 불분명하다면 CocoaPods를 유지하고, 불확실한 항목만 격리해 검증합니다.
• 빌드 스크립트나 배포 설정이 기존 경로에 묶여 있고 되돌릴 기준도 없다면 이전을 보류합니다.

결정의 근거는 “SwiftPM을 한 번 실행했다”가 아닙니다. 의존성 적용 범위, 반복 가능한 깨끗한 빌드, 앱 동작, 팀의 유지 부담, 기존 경로로 돌아갈 수 있는지를 함께 보세요. 공식 지원 상태가 바뀌거나 의존성 호환 정보가 달라지면 판단을 다시 검토하되, 새 버전 계획만으로 현재 프로젝트의 검증을 대신하지 마세요.

개발 PC에 맥이 없거나 기존 CI에서 시험하기 어렵다면, 현재 방식의 제약도 따져야 합니다. Windows나 Linux 개발 PC만으로는 iOS 네이티브 빌드를 직접 확인하기 어렵고, 공유 빌드 환경은 프로젝트별 설정을 자유롭게 바꾸거나 문제를 재현하기에 제약이 있을 수 있습니다. 반면 맥을 직접 마련하면 사용 빈도와 유지 비용을 감당해야 합니다. 시험을 위한 독립된 macOS 환경이 필요하다면 KVMNODE 원격 맥 환경을 살펴보고, 프로젝트에 필요한 Xcode와 의존성, 서명 절차를 먼저 확인하세요. 장기간 안정적으로 무거운 빌드를 돌리거나 물리 장치 연결이 필요하다면 직접 보유한 맥이 더 맞을 수 있습니다.