Xcode 27 Swift Testing과 XCTest 상호 운용, 무엇을 선택할까? 2026 안내

Swift Testing과 XCTest는 한 테스트 묶음에 함께 둘 수 있습니다. 상호 운용 설정은 한쪽 프레임워크를 다른 쪽으로 교체하는 옵션이 아닙니다. 두 프레임워크를 섞어 쓸 때 생기는 문제를 어떻게 처리할지 정하는 설정입니다. Apple은 Xcode 테스트 개요와 XCTest 프레임워크 문서에서 각 테스트 도구의 역할을 안내합니다.

예를 들어 새 테스트 함수에서 XCTest 단언 API를 호출하는 혼합 사례를 만들 수 있습니다.

import Testing
import XCTest

@Test
func mixedAssertion() {
    XCTAssertEqual(2 + 2, 4)
}

이 예제의 목적은 두 프레임워크의 기능을 비교하는 것이 아닙니다. 선택한 모드에서 교차 호출이 어떤 문제로 기록되는지, 심각도가 예상과 일치하는지 확인하는 것입니다. Apple의 XCTest 이전 안내는 XCTest 테스트를 Swift Testing으로 옮기는 과정에서 두 프레임워크를 함께 사용할 수 있음을 설명합니다.

모드는 호환성 안내를 남길지, 원래 심각도를 유지할지, 특정 호출을 막을지, 진단을 끌지에 따라 선택하세요. 아래 구분은 Apple의 이전 문서와 Xcode 27 릴리스 노트에 설명된 동작을 기준으로 합니다.

처음에는 complete로 같은 혼합 테스트를 실행하고 결과를 저장하세요. 테스트 실패나 진단이 팀의 기존 심각도 기준과 맞는지 확인합니다. 특정 API 호출 자체를 막아야 한다면 strict를 검토하세요. limited는 이전 프로젝트의 호환 동작을 확인할 때 유용하지만, 설정을 확인하지 않고 새 프로젝트에도 같은 동작이 적용된다고 가정하지 마세요.

none으로 테스트가 통과해도 교차 프레임워크 문제가 해결된 것은 아닙니다. 진단이 보이지 않게 된 결과일 수 있으므로, 원인 확인 뒤에는 원래 모드로 되돌리고 같은 사례를 다시 실행하세요.

Xcode를 새 버전으로 올렸다는 사실만으로 기존 테스트 계획이 새 프로젝트의 설정을 자동으로 사용한다고 판단할 수 없습니다. 기존 계획에는 limited가 남아 있을 수 있습니다. 새 프로젝트의 안내나 시연 결과를 기존 저장소에 그대로 대입하지 마세요.

테스트 계획 편집 화면에서 대상 계획의 상호 운용 설정을 직접 확인하세요. 계획이 여러 개라면 개발, 테스트, CI에서 실제로 선택하는 계획을 각각 살펴봅니다. Apple의 테스트 계획 구성 안내와 WWDC26 시연을 대조하면 계획별 구성과 이전 흐름을 점검할 수 있습니다.

설정값은 저장소의 이전 기록이나 팀 문서와 비교하세요. 버전 업그레이드 뒤 결과가 달라졌다면 모드 변경, 테스트 대상 변경, 실행 방식 변경을 한 번에 묶어 해석하지 말고 각각 분리해야 원인을 좁힐 수 있습니다.

Swift 패키지와 Xcode 프로젝트의 기본 동작이 항상 같다고 가정하지 마세요. Swift 패키지는 도구 체인과 swift-tools-version의 영향을 받을 수 있습니다. Xcode 프로젝트는 선택한 테스트 계획의 설정을 적용할 수 있습니다. 어느 한쪽의 기본값을 모든 저장소에 일반화하지 말고, 사용하는 도구 체인과 실행 경로를 함께 기록하세요.

재현할 때는 동일한 혼합 테스트를 패키지의 명령줄 실행과 Xcode 테스트 실행에서 각각 돌립니다. 명령줄 실행 절차는 Apple의 테스트 실행 및 결과 해석 안내를 참고하세요. 테스트 대상, 선택한 계획, 도구 체인, 기록된 문제와 심각도를 한 묶음으로 남기면 실행 환경 차이를 추적하기 쉽습니다.

모드 선택은 빌드 성공 여부만으로 승인하지 마세요. 교차 프레임워크 문제가 결과에 기록되는지, 심각도가 팀의 기대와 일치하는지, 기존 XCTest 테스트가 계속 실행되는지를 함께 확인해야 합니다. Swift Testing의 문제 기록 API 문서는 문제와 심각도가 테스트 결과에 어떤 의미를 갖는지 살펴볼 때 참고할 수 있습니다.

• [ ] 혼합 호출을 포함한 최소 테스트를 준비하고 변경 전 결과를 보관합니다.
• [ ] 테스트 계획에서 실제 선택된 상호 운용 모드를 확인합니다.
• [ ] complete로 실행해 문제 기록과 심각도가 예상과 맞는지 검토합니다.
• [ ] 기존 XCTest 테스트와 새 Swift Testing 테스트가 함께 실행되는지 확인합니다.
• [ ] 패키지 명령줄과 Xcode에서 같은 테스트를 실행하고 결과를 비교합니다.
• [ ] 모드를 바꿨다면 변경 이유와 되돌릴 기준을 팀 기록에 남깁니다.

원격 맥 CI에서도 로컬과 같은 저장소, 테스트 대상, 테스트 계획을 사용한다고 단정할 수 없습니다. 실제 실행 경로가 Xcode인지 명령줄인지, 어떤 테스트 계획이 선택됐는지 확인하세요. 로컬 Xcode, 로컬 명령줄, 원격 실행 결과를 나란히 놓고 상호 운용 모드와 도구 체인을 비교합니다.

특히 CI의 초록색 결과만을 목표로 none을 적용하지 마세요. 진단이 숨겨지면 이전 과정에서 수정해야 할 호출까지 놓칠 수 있습니다. 먼저 complete에서 혼합 테스트 결과를 확인하고, 팀이 의도적으로 호출을 금지할 때 strict를 적용하세요. 이전 테스트 계획의 설정을 유지해야 한다면 그 이유와 종료 조건을 기록합니다.

원격 맥에서 Xcode 테스트를 실행할 환경이 아직 없다면 CALMVPS의 원격 맥 개발 환경 안내에서 연결과 개발 환경의 범위를 살펴보세요. 임시 테스트 노드가 필요한 경우에는 요금 및 임대 조건을 확인하고, 장기간 같은 워크로드를 계속 돌리거나 물리 기기 연결이 필수라면 직접 보유한 맥이 더 적합한지도 함께 비교해야 합니다.

혼합 테스트를 한 테스트 묶음에 둘 수 있나요?

가능합니다. 다만 같은 테스트 패키지에서 두 프레임워크를 쓰는 것과 한 테스트 함수 안에서 서로의 API를 호출하는 것은 별도 검증 항목입니다. 최소 사례를 만들어 실제 선택한 모드에서 문제가 기록되는지 확인한 뒤 전체 테스트 묶음에 적용하세요.

점진 이전에는 어떤 모드를 먼저 확인하나요?

complete를 기준으로 평가하세요. 교차 프레임워크 문제의 기존 심각도가 유지되어, 이전 과정에서 진단 강도가 달라지는지 판단하기 쉽습니다. 팀이 특정 호출을 허용하지 않는다면 strict를 별도로 검토하고, 먼저 결과와 규칙을 합의하세요.

기존 테스트 계획이 limited를 유지할 수 있나요?

그럴 수 있습니다. Xcode 버전만으로 저장된 테스트 계획의 설정을 추정하지 마세요. 실제로 CI가 선택하는 계획을 열어 값을 확인하고, 새 계획이나 로컬 실행과 차이가 있다면 계획 이름과 설정을 함께 기록하세요.

패키지와 Xcode 프로젝트의 기본 동작은 같나요?

같다고 단정할 수 없습니다. 도구 체인과 패키지 설정, Xcode 테스트 계획이 각각 영향을 줄 수 있습니다. 동일한 혼합 테스트를 두 실행 경로에서 실행하고, 결과와 사용한 도구 체인을 비교해야 프로젝트에 맞는 기준을 세울 수 있습니다.

전환 전에 현재 테스트 계획의 모드를 확인하고, 같은 혼합 테스트를 로컬과 CI에서 실행해 결과를 맞춰 보세요. 로컬에 Xcode 테스트를 실행할 맥이 없고 이전 검증을 위한 임시 환경이 필요하다면, CALMVPS의 한국 내 원격 맥 옵션을 검토할 수 있습니다. 장기적이고 지속적인 부하나 물리 장비 연결이 필요한 작업은 구매한 맥과 비교한 뒤 결정하세요.