Podfile과 플러그인을 정리하다 보니 Flutter 3.44에서 의존성 관리 방식을 지금 바꿔야 할지 막막하신가요?
이번 주에는 새 프로젝트는 Swift Package Manager 경로를 우선 평가하고, 기존 프로젝트는 플러그인 호환성을 점검한 뒤 macOS와 Xcode CI에서 빌드·테스트·서명까지 검증하세요. 등록소가 읽기 전용으로 바뀔 계획이라는 사실만으로 기존 앱이 즉시 빌드되지 않는다고 단정할 수는 없습니다.
이 글은 Flutter iOS 앱을 유지 관리하며 이전 시점을 판단해야 하는 개발자를 위한 기준입니다.
플러그인이나 네이티브 연동을 담당한다면 팀의 호환성 책임을 확인할 수 있습니다.
Apple 플랫폼 CI를 관리한다면 운영 전 격리 검증 항목을 점검할 수 있습니다.
마지막 확인: 2026년 11월 4일. Flutter의 통합·플랫폼 문서와 CocoaPods의 등록소 계획을 기준으로 정리했습니다. 전환 직전에는 공식 문서의 변경 여부와 프로젝트 CI 기록을 다시 확인하세요.
Flutter 3.44 iOS 의존성 이전은 프로젝트 유형부터 나누세요
Flutter 공식 문서에 따르면 Flutter 3.44부터 iOS와 macOS 의존성의 기본 경로는 Swift Package Manager입니다. CocoaPods는 유지 관리 모드로 안내됩니다. 따라서 새 앱은 기본 경로를 기준으로 시작하는 것이 합리적이지만, 기존 앱은 플러그인과 빌드 절차를 조사한 뒤 결정해야 합니다. Flutter iOS 프로젝트 설정 안내
| 판단 기준 | 새 프로젝트 | 기존 프로젝트 |
|---|---|---|
| 기본 방향 | Swift Package Manager 적용 가능성을 우선 평가합니다. | 현재 CocoaPods 의존성과 전환에 필요한 변경을 목록화합니다. |
| 플러그인 | 필요한 플러그인의 패키지 지원 상태를 먼저 확인합니다. | 직접·간접 플러그인, 네이티브 연동, 사용자 정의 스크립트를 확인합니다. |
| 빌드 판단 | 초기 CI에서 깨끗한 빌드와 서명까지 검증합니다. | 기존 경로와 새 경로를 격리 검증한 뒤 단계적으로 전환합니다. |
| 미지원 항목 | 대체 패키지나 네이티브 연동을 검토합니다. | 해결될 때까지 기존의 재현 가능한 빌드 경로를 유지할 수 있습니다. |
여기서 구별해야 할 것은 세 가지입니다. 의존성 해석이 성공하는지, 앱이 실제로 컴파일되는지, 테스트와 서명·아카이브를 포함한 전체 배포 흐름이 통과하는지는 각각 다른 검증 결과입니다. 하나가 성공했다고 나머지까지 확인된 것은 아닙니다.
CocoaPods 등록소 계획과 기존 앱의 영향은 구분하세요
Flutter 문서가 안내하는 CocoaPods Specs 등록소의 읽기 전용 전환 예정일은 2026년 12월 2일입니다. 이는 계획된 날짜이며 변경될 수 있습니다. Flutter의 iOS 통합 안내와 CocoaPods 등록소 계획을 확인하되, 이 계획을 기존 의존성의 즉각적인 무효화나 빌드 중단으로 해석하지 마세요.
현재 프로젝트에 미칠 영향은 저장소 정책만으로 판정할 수 없습니다. 이미 잠금 파일에 고정된 의존성이 로컬 또는 CI 환경에서 재사용되는지, 새 의존성 버전을 가져와야 하는지, 의존성 해석이 외부 저장소에 의존하는지를 따로 살펴야 합니다. 팀 내부 캐시나 미러가 있다면 그 경로도 실제 새 빌드에서 확인해야 합니다.
기존 프로젝트를 급히 바꾸면 플러그인 하나의 네이티브 설정이나 스크립트가 빌드에 미치는 영향을 놓칠 수 있습니다. 반대로 아무 확인 없이 현 상태만 유지하면 새 의존성을 추가하거나 깨끗한 환경에서 빌드할 때 드러나는 문제를 뒤늦게 발견할 수 있습니다. 그러므로 “바로 전체 이전”과 “아무 조치 없이 유지” 중 하나를 택하기보다, 먼저 영향 범위를 조사하고 검증 가능한 전환 계획을 세우세요.
플러그인 지원과 팀의 책임 범위를 함께 판단하세요
Swift Package Manager 지원 여부는 앱의 직접 의존성만 보고 판단하면 안 됩니다. 직접 추가한 Flutter 플러그인 아래에 어떤 네이티브 패키지가 들어오는지, 앱의 iOS 프로젝트에 별도 설정이 필요한지 확인하세요. Flutter의 패키지 및 플러그인 개발 문서는 플러그인과 네이티브 플랫폼 연동을 점검할 때 참고할 수 있습니다.
Swift 패키지는 Package.swift에서 제품과 의존성을 선언합니다. 하지만 선언 형식이 존재한다고 해서 해당 패키지가 현재 앱의 플러그인 구성과 자동으로 호환되는 것은 아닙니다. 패키지 설명은 Swift Package Manager의 공식 문서를 참고하고, 실제 연결 여부는 앱에서 확인해야 합니다.
- 이전 적합도가 높은 경우: 새 프로젝트이거나, 필요한 플러그인과 네이티브 의존성이 새 경로에서 지원되고 팀이 변경된 빌드 설정을 관리할 수 있습니다.
- 병행 검증이 필요한 경우: 일부 플러그인이 지원 상태를 명확히 밝히지 않았거나 CocoaPods 전용 스크립트가 남아 있습니다. 운영 브랜치는 유지하면서 별도 CI 작업에서 새 경로를 시험하세요.
- 잠시 보류할 경우: 필수 플러그인의 대체 경로가 없고 서명·배포까지 재현할 검증 환경도 마련되지 않았습니다. 이때는 기존 빌드의 재현성을 유지하면서 의존성별 지원 상태를 추적하세요.
팀이 플러그인 전환과 네이티브 설정을 누가 관리할지도 합의해야 합니다. 앱 팀이 변경을 소유할지, 플러그인 유지 관리자의 업데이트를 기다릴지, 자체 연동을 책임질지 정하지 않으면 기술적으로 빌드가 되는 상태와 지속해서 운영할 수 있는 상태가 달라질 수 있습니다.
macOS와 Xcode CI에서 통과시킬 검증 항목
Flutter iOS 앱을 빌드하려면 macOS와 Xcode를 갖춘 환경이 필요합니다. Linux CI만으로는 Xcode 기반 iOS 빌드와 서명 흐름을 그대로 검증할 수 없습니다. 필요한 플랫폼 도구와 설정 경계는 Flutter iOS 설정 문서를 확인하세요. 앱에 환경별 설정이 있다면 iOS 플레이버 설정 안내도 함께 살펴야 합니다.
- 검증 환경을 분리합니다. 운영 빌드와 다른 CI 작업이나 브랜치에서 의존성 관리 변경을 시험합니다. Flutter와 Xcode 버전, 빌드 환경 변수를 기록해 결과를 다시 만들 수 있게 합니다.
- 의존성 입력을 고정합니다. Podfile, 잠금 파일, Flutter 패키지 잠금 정보, 네이티브 패키지 설정을 보관합니다. 기존 경로와 새 경로에서 어떤 파일이 생성되거나 달라지는지 비교합니다.
- 깨끗한 상태에서 해석합니다. 캐시가 남아 있는 개발자 컴퓨터의 성공만으로 판단하지 말고, 새 CI 작업에서 의존성 해석 로그를 저장합니다. 실패하면 저장소 접근 문제인지 선언된 의존성 문제인지 분리합니다.
- 컴파일과 테스트를 따로 확인합니다. 컴파일 성공 뒤에도 테스트를 실행하고, 앱이 사용하는 플러그인의 네이티브 기능이 실제로 동작하는지 확인합니다.
- 서명과 아카이브를 검증합니다. 테스트용 빌드만으로 끝내지 말고 팀의 인증서·프로비저닝 설정을 적용해 서명과 아카이브가 재현되는지 확인합니다. 실패 로그와 사용한 잠금 파일을 함께 보관합니다.
- 작은 범위부터 전환합니다. CI에서 검증된 프로젝트 조합을 기준으로 변경을 단계적으로 반영합니다. CI 통과는 시험한 프로젝트와 의존성 조합에 대한 결과이지, 모든 Flutter 플러그인이 호환된다는 보증은 아닙니다.
| CI 검증 결과 | 확인된 범위 | 다음 판단 |
|---|---|---|
| 의존성 해석만 통과 | 패키지를 찾고 해석한 결과입니다. | 컴파일과 플러그인 연동을 계속 확인합니다. |
| 깨끗한 빌드와 테스트 통과 | 시험한 구성의 컴파일·테스트 결과입니다. | 서명과 아카이브까지 확인합니다. |
| 서명·아카이브까지 통과 | 시험 환경에서 배포 산출물을 만든 결과입니다. | 로그와 잠금 파일을 보관하고 단계적으로 반영합니다. |
자주 묻는 질문
기존 프로젝트는 지금 바로 이전해야 하나요?
아닙니다. Flutter 3.44의 기본 의존성 경로 변경과 기존 프로젝트의 즉시 빌드 중단은 같은 의미가 아닙니다. 플러그인과 스크립트의 호환성을 확인하고, 격리된 macOS와 Xcode CI에서 전체 흐름을 통과한 뒤 이전 범위를 정하세요.
CocoaPods를 유지하면 당장 빌드할 수 없게 되나요?
등록소를 읽기 전용으로 바꾸려는 계획은 기존 프로젝트의 현재 빌드 결과를 자동으로 무효화하지 않습니다. 다만 새 의존성 해석이 필요한지, 잠금 파일과 캐시가 어떤 역할을 하는지에 따라 영향이 달라집니다. 공식 계획과 프로젝트 로그를 함께 검토하세요.
Swift Package Manager를 지원하지 않는 플러그인은 어떻게 처리하나요?
필수 기능에 쓰이는지, 대체 플러그인이나 자체 네이티브 연동이 가능한지 확인하세요. 유지 관리자의 지원 여부만으로 운영 전환을 결정하지 말고, 실제 앱에서 의존성 해석부터 테스트까지 검증해야 합니다. 대안이 확인되지 않았다면 기존 경로를 유지하며 별도 CI에서 계속 평가할 수 있습니다.
이전 후 Xcode CI가 성공하면 모든 플러그인이 호환된다는 뜻인가요?
아닙니다. 성공은 해당 CI 환경에서 시험한 Flutter 버전, 프로젝트 설정, 의존성 조합의 결과입니다. 다른 앱이나 플러그인까지 검증한 것은 아닙니다. 사용한 잠금 파일과 해석·빌드·테스트·서명 로그를 보관하고, 운영 환경과 같은 설정에서 결과를 재현하세요.
기존 Mac에서만 검증하면 작업 환경 차이와 캐시가 결과를 가릴 수 있고, Linux 서버만으로는 Xcode 빌드와 서명을 확인할 수 없습니다. Mac을 직접 구입하면 장비 관리와 유지 비용을 감당해야 하므로, 검증 기간이 짧거나 팀에 격리된 macOS 환경이 없다면 원격 Mac을 빌드 시험용으로 활용하는 방안도 비교할 수 있습니다. 다만 물리 장비 연결이 필요하거나 장기간 고정된 부하를 처리해야 한다면 직접 보유한 Mac이 더 적합할 수 있습니다.
먼저 Mac 환경 선택 기준을 살펴보고, 프로젝트를 분리해 검증할 Mac이 필요하다면 VpsHold의 한국 원격 Mac 환경에서 자신의 Flutter 의존성 해석과 Xcode CI 흐름을 시험해 보세요. 결과가 확인된 뒤에 운영 전환을 결정하는 편이 안전합니다.
자주 묻는 질문
Flutter 3.44에서는 기존 iOS 프로젝트도 반드시 Swift Package Manager로 바꿔야 하나요?
아닙니다. Flutter 공식 안내는 Flutter 3.44부터 iOS와 macOS 의존성의 기본 경로로 Swift Package Manager를 사용한다고 설명하지만, 이것만으로 기존 프로젝트의 CocoaPods 의존성이 즉시 작동을 멈춘다는 뜻은 아닙니다. 기존 프로젝트는 직접·간접 플러그인과 빌드 스크립트를 먼저 조사하고, 실제 CI에서 검증한 뒤 이전 여부를 정하세요.
기존 Flutter iOS 앱에서 CocoaPods를 계속 사용하면 어떤 점을 확인해야 하나요?
CocoaPods 공식 안내와 Flutter 문서에는 Specs 저장소를 읽기 전용으로 전환할 계획이 안내되어 있습니다. 계획된 날짜는 2026년 12월 2일이며 변경될 수 있습니다. 이 계획과 이미 내려받은 의존성의 사용 가능성, 새 의존성 해석, 프로젝트 전체 빌드 성공은 서로 다른 문제입니다. 잠금 파일과 의존성 해석 로그를 보관하고, 새 환경에서도 재현되는지 확인하세요.
Swift Package Manager를 지원하지 않는 Flutter 플러그인이 있으면 어떻게 해야 하나요?
해당 플러그인이 앱의 필수 기능인지, CocoaPods 통합이나 사용자 정의 빌드 스크립트에 의존하는지부터 확인하세요. 유지 관리자가 지원 계획을 안내했는지도 살펴보되, 지원 예정이라는 말만으로 이전 가능하다고 판단하지 마세요. 대체 플러그인이나 자체 네이티브 통합을 검토하고, 해결 전까지는 검증된 기존 빌드 경로를 유지하는 편이 안전합니다.
의존성 이전 뒤 Xcode CI에서는 무엇을 검증해야 하나요?
격리된 macOS 환경에서 의존성 해석, 캐시가 없는 깨끗한 빌드, 테스트, 서명 및 아카이브까지 확인하세요. 실패 시 원인을 추적할 수 있도록 Xcode와 Flutter 버전, 잠금 파일, 해석 로그와 빌드 로그를 함께 보관합니다. CI 성공은 해당 프로젝트와 테스트한 의존성 조합이 통과했다는 뜻일 뿐, 모든 Flutter 플러그인의 호환성을 보증하지는 않습니다.
의존성 이전 전, 전용 맥에서 먼저 검증하세요
실제 맥 미니를 전용으로 대여해 새 의존성 구성을 기존 환경과 분리하여 점검할 수 있습니다.