Flutter 3.47.0 릴리스 노트에는 Xcode 27의 DeviceHub.app 경로를 처리하는 변경이 기록되어 있습니다. Flutter 공식 릴리스 노트에서 이 내용을 확인할 수 있습니다. 따라서 Xcode 27을 선택한 상태에서 구버전 Flutter가 시뮬레이터를 찾지 못한다면, 먼저 이 경로 변경을 포함한 버전으로 전환하세요. 그다음 실제로 선택된 Xcode와 시뮬레이터 런타임을 확인합니다. 시뮬레이터 데이터 삭제나 Xcode 재설치는 첫 조치가 아닙니다.

이번 주 점검 순서: Flutter와 Xcode 경로를 기록하고, Device Hub에서 기기를 확인한 다음, 실제 프로젝트로 발견과 실행을 따로 검증하세요.

Flutter 개발자: Xcode 27 업데이트 뒤 flutter devices 결과가 바뀌었거나 iOS 시뮬레이터 실행이 실패한 경우에 해당합니다.
CI 엔지니어: 빌드는 되지만 원격 맥에서 기기 검색이나 시뮬레이터 실행 단계가 실패할 때 확인하세요.
플랫폼 관리자: 공유 노드를 초기화하기 전에 Flutter SDK, 선택된 Xcode, 런타임 중 원인을 구분해야 할 때 참고할 수 있습니다.

마지막 업데이트: 2026년 9월 30일. Flutter 3.47.0 릴리스 노트, Flutter iOS 개발 문서, Apple Xcode 27 릴리스 노트를 기준으로 확인했습니다. 이후 안정 버전이나 Xcode 업데이트로 동작이 달라질 수 있으므로, 변경 전에는 대상 조합에서 다시 검증하세요.

Flutter 3.47과 Xcode 27의 경로 변화

Xcode 27은 시뮬레이터 관리를 Device Hub 중심으로 안내합니다. 이전 방식의 Simulator.app 경로를 전제로 검색하는 도구는 앱 빌드가 성공해도 시뮬레이터를 발견하지 못할 수 있습니다. Apple은 Xcode 27의 변경 사항과 Xcode 27 릴리스 노트에서 관련 내용을 다룹니다.

Flutter 공식 문서도 Xcode 27의 Device Hub와 이전 Xcode의 Simulator 앱 진입 방식을 구분합니다. Flutter iOS 개발 설정 안내를 기준으로 현재 Xcode의 관리 경로를 확인하세요. Flutter 3.47.0의 변경은 경로 호환성과 관련된 것이지, 모든 시뮬레이터 발견 및 실행 문제를 해결했다는 뜻은 아닙니다.

관찰 결과 우선 의심할 원인 다음 확인
Xcode에서 프로젝트를 빌드할 수 있지만 flutter devices에 대상이 없음 Flutter가 이전 앱 경로를 검색하거나 다른 SDK가 호출됨 Flutter 버전과 실행 파일 경로
Device Hub에 기기가 보이지만 Flutter 목록에는 없음 Flutter와 Xcode의 선택 경로 불일치 가능성 xcode-select -p, flutter doctor -v
Flutter 목록에 기기가 있지만 실행이 실패함 런타임 상태 또는 시뮬레이터 시작 과정 Xcode에서 같은 기기와 프로젝트를 직접 실행

주의: Device Hub가 열리는 것만으로 Flutter가 올바른 Xcode와 런타임을 사용한다고 판단하지 마세요. 터미널, IDE, CI Runner는 서로 다른 사용자 환경이나 경로를 사용할 수 있습니다.

Flutter 3.47에서 Xcode 27 시뮬레이터를 어떻게 확인하나요?

먼저 Flutter가 실제로 사용하는 버전을 기록하고, 릴리스 노트에서 DeviceHub.app 경로 처리가 포함됐는지 확인하세요. 버전 문자열만 보지 말고 명령을 실행하는 파일의 위치도 살펴야 합니다.

flutter --version
which flutter
flutter doctor -v

Flutter 공식 3.47.0 릴리스 노트에서 경로 지원 변경을 확인할 수 있습니다. 팀에서 버전을 고정하고 있다면 무조건 전체 SDK를 최신화하지 말고, 해당 수정이 포함된 안정 버전을 프로젝트 정책에 따라 선택하세요. 수정이 들어간 버전인데도 문제가 지속되면 다음 단계로 넘어가야 합니다.

발견 실패와 환경 선택 오류 구분

Flutter SDK가 여러 개 설치되어 있으면 터미널의 flutter와 IDE 또는 CI에서 호출하는 실행 파일이 다를 수 있습니다. Xcode도 여러 위치에 설치되어 있거나, 명령줄에서 다른 버전을 선택했을 수 있습니다. 앱 코드가 같아도 실행 진입점이 다르면 서로 다른 결과가 나옵니다.

Apple의 Xcode 명령줄 도구 참고 자료를 참고해 선택된 도구 경로를 확인하세요.

xcode-select -p
xcrun simctl list devices available

flutter --version, which flutter, xcode-select -p 결과를 한곳에 기록한 뒤 IDE와 CI에서도 각각 확인합니다. 현재 작업 디렉터리와 프로젝트에서 사용하는 Flutter 버전 관리 방식도 함께 대조하세요. 로그만으로 SDK가 바뀌었는지 불분명하다면 실행 명령과 환경 변수를 저장한 뒤 재현하는 편이 안전합니다.

Xcode 27로 업그레이드한 뒤 무엇을 확인해야 하나요?

아래 항목을 위에서부터 비교하세요. Xcode에서 보이는 기기와 Flutter 명령 결과가 다르면, 먼저 도구 경로 차이를 확인해야 합니다.

점검 항목 확인 방법 결과가 다를 때
Flutter 버전과 실행 파일 flutter --version, which flutter IDE와 CI의 SDK 선택 설정 확인
선택된 Xcode xcode-select -p 의도한 Xcode 설치 위치인지 확인
사용 가능한 기기 xcrun simctl list devices available, flutter devices Xcode 표시와 Flutter 결과를 대조
런타임 인식 여부 Xcode의 기기 관리 화면과 구성 요소 상태 확인 필요한 런타임 설치 여부 조사

경로가 올바른데도 기기가 없다면 런타임을 확인합니다. Apple의 추가 Xcode 구성 요소 설치 안내에 따라 해당 Xcode가 필요한 시뮬레이터 구성 요소를 사용할 수 있는지 살펴보세요. 런타임 설치 여부와 Flutter의 경로 탐색 문제는 서로 다른 원인입니다.

기기 발견과 실행 실패 분리

flutter devices에 기기가 표시되는데 앱 실행만 실패한다면, 발견 경로 수정을 반복하지 마세요. Device Hub에서 같은 기기를 선택해 Xcode로 프로젝트를 실행하고, 실패 지점을 기록합니다. Xcode에서도 시작되지 않으면 런타임 또는 Xcode 실행 경로를 조사합니다. Xcode에서는 실행되지만 Flutter 명령만 실패한다면 Flutter 도구의 선택 경로나 프로젝트 설정을 다시 확인하세요.

Device Hub가 열렸는데 flutter devices에는 기기가 없는 경우에도 같은 원칙을 적용합니다. Device Hub의 기기 표시, xcrun simctl list devices available 결과, Flutter의 기기 목록을 각각 저장하면 어느 단계에서 차이가 생기는지 드러납니다. Flutter 관련 문제 기록은 비슷한 경로 문제를 확인할 때 참고할 수 있지만, 개별 사례를 모든 환경의 원인으로 일반화해서는 안 됩니다.

복구 전 기록: Flutter 버전, Flutter 실행 파일 경로, 선택된 Xcode, 실패 명령과 전체 로그를 보관하세요. 캐시나 기기 데이터를 삭제하면 재현에 필요한 상태가 사라질 수 있습니다. 초기화가 꼭 필요하다면 대상과 복구 방법을 먼저 정하고, 공유 노드에서는 영향 범위를 확인한 뒤 진행하세요.

원격 맥 CI 재현과 복구 검증

원격 맥의 셸, IDE, CI Runner는 같은 노드에서도 계정과 환경이 다를 수 있습니다. 개발자 계정에서 성공한 명령을 CI 설정에도 그대로 적용했다고 가정하지 마세요. 각 실행 주체에서 Flutter와 Xcode의 경로, 작업 디렉터리, 실패 로그를 별도로 확보해야 합니다.

다음 체크리스트를 완료한 뒤 실제 프로젝트 검증으로 넘어가세요.

  • [ ] 터미널, IDE, CI Runner에서 flutter --version과 which flutter 결과를 기록합니다.
  • [ ] 각 실행 환경에서 xcode-select -p 결과가 기대한 Xcode 경로인지 비교합니다.
  • [ ] Xcode의 Device Hub와 xcrun simctl list devices available에서 대상 기기를 확인합니다.
  • [ ] flutter devices에 같은 대상이 표시되는지 확인하고 결과를 보관합니다.
  • [ ] 실제 프로젝트를 해당 시뮬레이터에서 실행해 앱 시작 여부를 확인합니다.
  • [ ] 프로젝트의 테스트 작업도 실행해 발견과 실행 단계가 모두 통과하는지 확인합니다.
  • [ ] 실패가 재현될 때만 Flutter 버전 수정, Xcode 선택 변경, 런타임 조사 중 해당 원인에 맞는 조치를 적용합니다.

검증은 기기 목록 출력만으로 끝내지 마세요. 실제 프로젝트의 실행과 테스트까지 확인해야 CI 단계에서 같은 문제가 다시 나타나는지 판별할 수 있습니다. 조치 전후 명령과 로그를 비교하고, 한 번에 여러 설정을 바꾸지 않으면 어느 변경이 결과에 영향을 줬는지도 추적할 수 있습니다.

이번 문제의 중심은 Xcode 27 기능 전반이 아니라 Flutter의 경로 탐색, 선택된 개발 도구, 런타임, 실행 과정 중 어디에서 불일치가 생겼는지 찾는 일입니다. 로컬 맥 한 대에 계속 의존하면 실행 환경 공유와 CI 재현에 제약이 생길 수 있고, 노드가 바뀔 때마다 경로와 런타임을 맞추는 운영 부담도 남습니다. 반대로 원격 맥은 사용 중 네트워크 연결에 영향을 받고, 물리 장비나 특정 로컬 주변 장치가 필요한 작업에는 맞지 않습니다. 장기간 고정된 무거운 작업이라면 직접 맥을 운용하는 편이 나을 수도 있습니다.

개인 환경에 필요한 macOS 실행 환경이 없거나, 실제 Flutter 프로젝트로 원격 CI 노드를 먼저 검증하려는 경우에는 VMSPIN의 요금 안내를 확인할 수 있습니다. 필요한 기간과 작업 범위를 정했다면 원격 맥 주문 안내에서 이용 절차도 살펴보세요. 현재 장비를 그대로 유지할지, 원격 맥을 테스트와 빌드에 추가할지는 먼저 같은 프로젝트와 시뮬레이터 작업을 실행해 본 결과로 결정하세요.