Xcode 27에서는 SwiftUI의 State가 속성 래퍼에서 매크로로 바뀌었습니다. 애플은 대부분의 코드가 영향을 받지 않는다고 안내하지만, 기본값과 사용자 정의 초기화가 겹치는 경우에는 소스 호환성 오류가 발생할 수 있습니다. 클래스 상태의 초기화 동작도 달라질 수 있으므로, 모든 빌드 실패를 같은 원인으로 취급하면 안 됩니다. 애플의 호환성 안내는 영향을 받을 수 있는 코드 형태와 경계를 설명합니다.

실제 사례를 들어 보겠습니다. 기존 뷰에서 @State 프로퍼티에 기본값을 지정하고, 사용자 정의 init에서도 같은 상태를 초기화하도록 작성했습니다. Xcode를 올린 뒤 초기화 관련 컴파일 오류가 발생했다면, 먼저 그 중복 경로를 확인해야 합니다. 반대로 오류가 ContentBuilder나 제네릭 타입 추론을 가리킨다면 상태 선언을 바꾸기 전에 해당 진단을 따로 조사하세요.

Xcode 27에서 use before initialization 진단이 보이면 어디부터 봐야 하나요?

오류 문구만으로 원인을 단정하지 마세요. 첫 번째로 유효한 컴파일러 오류가 가리키는 프로퍼티와 init을 함께 확인합니다. @State 기본값과 init 할당이 같은 상태에 겹쳐 있다면, 둘 중 하나가 초기화 책임을 맡도록 정리한 뒤 최소 재현으로 다시 빌드하세요. SwiftUI 상태 문서의 초기화 규칙과 애플의 호환성 안내를 대조하면, 어떤 경로가 충돌하는지 좁힐 수 있습니다.

먼저 문제가 된 뷰 하나만 남겨 재현해 보세요. 여러 뷰와 의존성까지 한꺼번에 수정하면 어떤 변경이 오류를 해결했는지 알기 어렵습니다.

• 상태가 항상 같은 기본값으로 시작하고 외부 입력을 받지 않는다면, init의 중복 할당을 제거하는 쪽부터 검토합니다.
• 호출자가 초기 상태를 전달해야 한다면, 기본값과 외부 입력 중 어느 쪽이 초기화의 기준인지 정하고 그 기준에 맞게 선언과 init을 다시 구성합니다.
• 기존 코드가 속성 래퍼의 초기화 방식이나 매크로 확장에 기대고 있다면, 예전 문법을 그대로 복사하기보다 공식 호환성 예제에 맞는지 확인합니다.

중복 할당을 지웠는데도 오류가 남으면 해당 @State 선언만으로 최소 재현을 유지하세요. 매크로 확장 진단인지, 주변 프로퍼티 초기화 순서 문제인지 분리하는 데 도움이 됩니다. 오류가 @State를 직접 지목하지 않는다면 그 진단을 별도 호환성 문제로 분류해야 합니다.

@Observable 클래스 객체를 @State에 저장하는 코드는 값 타입 상태와 같은 기준으로만 판단할 수 없습니다. 애플의 안내는 상태 매크로 전환과 함께 클래스 상태의 초기화 동작이 달라질 수 있음을 설명합니다. 객체 생성이 언제, 어떤 경로에서 이뤄지는지 확인하고, 초기화 시점에 실행되던 부수 효과를 찾아야 합니다. WWDC26 SwiftUI 설명과 상태 문서를 함께 확인하세요.

객체 init에서 네트워크 요청, 파일 변경, 외부 리소스 생성 등을 수행한다면, 그 작업을 단순한 객체 생성과 묶어 두어도 되는지 검토합니다. 같은 뷰가 다시 구성될 때 작업을 반복해도 안전한지, 아니면 명시적인 작업 시작 지점이나 작업 단위로 옮겨야 하는지 판단하세요. 초기화 횟수가 늘거나 줄 것이라고 미리 단정하지 말고, 로그와 재현 테스트로 실제 동작을 확인해야 합니다.

Xcode 27의 @State 매크로는 @Observable 클래스의 초기화 시점을 바꾸나요?

클래스 상태의 초기화 의미가 달라질 수 있으므로, 기존 코드가 객체 생성 시점에 부수 효과를 실행한다면 영향 여부를 검증해야 합니다. 다만 모든 클래스가 동일하게 달라진다고 일반화할 수는 없습니다. 문제가 된 객체의 생성 로그와 사용자 동작을 기록하고, 공식 문서가 설명하는 적용 범위에 해당하는지 확인하세요.

Xcode 27의 기본값과 init 할당이 충돌하면 어떻게 정리하나요?

한 상태에 초기화 책임이 두 곳에 있는지 먼저 확인합니다. 기본값이 필요한지, 호출자가 전달하는 값이 필요한지 결정한 뒤 불필요한 경로를 제거합니다. 변경 후에는 해당 뷰의 빌드와 상태 갱신 동작을 함께 확인하세요. 오류가 사라졌더라도 초기 표시값이나 사용자 입력에 따른 상태 변경이 달라졌다면 수정이 끝난 것이 아닙니다.

다음 순서로 프로젝트를 검증하면 코드 문제와 도구 체인 차이를 분리하기 쉽습니다.

1. 영향받는 핵심 뷰와 클래스 상태를 고르고, 오류 메시지와 재현 과정을 기록합니다.
2. 기존 도구 체인에서 같은 브랜치와 의존성으로 빌드하고 관련 테스트를 실행합니다.
3. 의존성과 소스 변경을 맞춘 상태에서 Xcode 27로 빌드합니다. 도구 체인 변경 사항은 Xcode 27 출시 안내에서 확인합니다.
4. 컴파일 결과뿐 아니라 객체 초기화 로그, 핵심 화면 표시, 상태 갱신 결과를 비교합니다.
5. 수정 뒤에도 차이가 남으면 최소 재현과 도구 체인 정보를 함께 보관하고, 원인이 확인될 때까지 기존 빌드 경로를 회귀 테스트용으로 유지합니다.

빌드 결과가 서로 다르다면 소스 코드만 비교하지 마세요. 명령줄 빌드 도구 선택과 빌드 설정도 확인해야 합니다. 명령줄 도구 설치 안내와 Xcode 빌드 시스템 문서를 참고하면 환경 설정이 달라진 경우를 분리하는 데 도움이 됩니다.

기존 프로젝트에서 Xcode 26과 Xcode 27의 빌드 차이는 어떻게 확인하나요?

같은 코드와 의존성을 두 환경에서 빌드하고, 성공 여부와 첫 오류 위치를 비교하세요. 해당 프로젝트에서 클래스 상태 초기화가 문제라면 같은 화면을 실행해 로그와 동작도 비교해야 합니다. 도구 체인과 의존성 상태를 기록하지 않으면 환경 차이를 코드 변경 탓으로 오인할 수 있습니다.

아래 항목을 위에서부터 확인하고, 해당하는 조건의 조치를 선택하세요.

• [ ] 오류가 @State 기본값과 사용자 정의 init의 중복을 가리킵니까? 그렇다면 한 뷰의 초기화 경로만 정리하고 두 도구 체인에서 다시 빌드하세요. 양쪽에서 통과하면 전체 상태 코드를 다시 쓰지 않아도 됩니다.
• [ ] 클래스 init에서 네트워크나 파일 작업을 실행합니까? 그렇다면 객체 생성 로그를 비교하고, 작업을 명시적인 시작 지점으로 분리해야 하는지 검토하세요. 부수 효과가 반복돼도 안전하다고 확인하기 전에는 업그레이드를 완료 처리하지 마세요.
• [ ] 오류가 ContentBuilder, 매크로 확장, 제네릭 추론 등 다른 진단을 가리킵니까? 그렇다면 이를 @State 문제로 뭉뚱그리지 말고 최소 재현을 남겨 해당 컴파일 진단을 따로 조사하세요.
• [ ] 최소 재현에서도 도구 체인별 결과가 다릅니까? 그렇다면 원인이 확인될 때까지 기존 환경을 회귀 테스트 경로로 유지하세요.
• [ ] 핵심 빌드와 관련 테스트가 새 환경에서 통과하고 상태 동작도 기대대로입니까? 그렇다면 팀의 릴리스 경로를 Xcode 27로 전환할 수 있습니다.

로컬 맥 한 대에 기존 도구 체인과 새 도구 체인을 함께 유지하면 빠르게 비교할 수 있지만, 설치 상태와 프로젝트 설정이 섞이지 않도록 관리해야 합니다. 별도 빌드 환경은 구성을 분리하기 쉽지만, 접근 권한과 의존성 관리 절차를 추가로 마련해야 합니다. 어떤 방식을 택하든 재현 단계, 사용한 도구 체인, 테스트 결과를 남기는 것이 우선입니다.

팀에서 테스트 환경을 분리해야 하지만 새 맥을 바로 구매하고 싶지 않다면, 원격 맥 대여를 선택지로 검토할 수 있습니다. 기존 장비를 공동 사용하면 도구 체인 상태가 바뀌거나 빌드 시간이 겹칠 수 있고, 새 장비를 구매하면 초기 비용과 관리 부담이 생깁니다. 원격 환경은 별도 머신에서 검증 경로를 나누는 데 쓸 수 있지만, 물리 장치 연결이 필요하거나 장기간 고정된 고부하 작업이 이어진다면 직접 보유하는 편이 나을 수 있습니다. 대여와 구매의 비용 항목은 맥 미니 대여와 구매 비용 안내에서 비교하고, 국내 주문 조건이 필요하다면 한국 맥 미니 대여 안내도 확인하세요.

최종 기준은 빌드 통과만이 아닙니다. 핵심 상태가 기대대로 갱신되고, 클래스 초기화 부수 효과가 통제되며, 문제가 재현될 때 비교할 기록이 있어야 전환을 승인할 수 있습니다. 로컬에서 두 도구 체인을 안전하게 분리하기 어렵다면 KVMNODE의 원격 맥 환경을 검토해 별도 빌드 경로를 만들 수 있습니다. 다만 프로젝트의 회귀 테스트와 실제 장치 연결 요구부터 확인한 뒤, 임시 검증 환경이 필요한 경우에만 대여를 선택하세요.