Swift Testing vs XCTest: 2026 독립 개발자는 전량 마이그레이션해야 할까?

Swift Testing과 XCTest는 하나를 즉시 폐기하고 다른 하나로 교체하는 관계가 아닙니다. Apple의 공식 전환 문서는 두 체계를 단계적으로 함께 사용하는 경로를 설명하며, Xcode 27은 현재 베타 자료를 기준으로 판단해야 합니다. 따라서 XCTest가 이미 사용 중단되었다고 전제해서는 안 됩니다.

Apple의 테스트 프레임워크 안내와 WWDC26 테스트 전환 세션을 기준으로 테스트 종류를 다음처럼 분류하면 됩니다.

Swift Testing은 XCTest를 완전히 대신할 수 있습니까?

아닙니다. Swift Testing은 Swift 문법에 맞는 단위 검증, 매개변수화된 테스트, 동시성 코드를 다루는 테스트 구성에 유리합니다. 그러나 화면을 실제로 조작하는 UI 자동화와 성능 측정까지 같은 방식으로 바꿀 수 있다고 일반화하면 안 됩니다. Apple의 Testing 공식 문서도 기능별 실행 맥락을 구분해 설명합니다.

새 iOS 또는 macOS 프로젝트라면 업무 규칙과 값 검증을 Swift Testing으로 작성하는 편이 관리 범위를 줄이기 쉽습니다. 반면 화면을 누르고 전환 결과를 확인하는 테스트는 처음부터 XCTest UI Tests Target을 따로 두는 편이 명확합니다. 테스트 목적이 다른데 파일 확장자나 선언 형태를 맞추기 위해 한 체계로 통일할 이유는 없습니다.

Swift Testing의 핵심 구성은 다음과 같습니다.

• @Test: 테스트의 의도를 선언하고 반복 가능한 테스트 단위를 만듭니다.
• #expect: 조건이 참인지 확인하고 실패 위치를 남깁니다.
• #require: 이후 검증에 꼭 필요한 값이 없으면 해당 흐름을 중단합니다.
• traits: 조건, 분류, 실행 특성을 테스트에 붙여 선택 실행을 돕습니다.
• 매개변수화 테스트: 입력값만 바꾸는 반복 검증을 하나의 검증으로 관리합니다.

최소한의 전환 형태는 다음처럼 유지할 수 있습니다.

import Testing

struct 가격계산테스트 {
    @Test(arguments: [1, 2, 3])
    func 수량에따른합계(수량: Int) {
        let 결과 = 계산기().합계(수량: 수량)
        #expect(결과 >= 0)
    }
}

실제 프로젝트에서는 테스트 이름, 상품명, 경로, 계정, 로그에 운영 정보를 넣지 않아야 합니다. 예시는 테스트 선언 방식만 보여 주며, 기존 XCTest의 검증 의미를 바꾸지 않는 것이 우선입니다. Xcode에서 테스트를 추가하고 실행하는 기본 절차는 공식 프로젝트 테스트 안내와 대조해야 합니다.

다음 조건을 만족하면 새 단위 테스트는 Swift Testing으로 시작합니다.

• 테스트가 화면이나 실제 앱 생명주기를 구동하지 않습니다.
• 검증 대상이 Swift 업무 코드 또는 데이터 변환 로직입니다.
• 입력값을 바꾸는 반복 검증이 많습니다.
• 동시성 코드의 성공·실패 조건을 코드 가까이에서 확인해야 합니다.

반대로 UI 구동이나 성능 측정이 핵심이면 XCTest를 남깁니다. 테스트 파일을 모두 같은 문법으로 만드는 것은 품질 기준이 아닙니다.

기존 프로젝트에서 가장 위험한 계획은 “테스트 파일을 전부 다시 작성한다”는 목표입니다. 파일 수가 많지 않아도 공용 도우미, 테스트 데이터 생성기, 환경 변수, 실행 Scheme이 서로 연결되어 있으면 작은 문법 변경이 회귀 기준 전체를 흔들 수 있습니다.

기존 XCTest는 다음 세 묶음으로 나누는 편이 좋습니다.

1. 현재 기능을 수정하면서 함께 건드리는 테스트
2. 여러 테스트가 공유하는 도우미와 테스트 데이터 구성 코드
3. 오랫동안 안정적이고 변경이 거의 없는 테스트

첫 번째 묶음부터 Swift Testing으로 이동합니다. 두 번째 묶음은 먼저 입력과 출력의 의미를 고정한 뒤 옮깁니다. 세 번째 묶음은 유지 비용이 낮다면 그대로 두어도 됩니다. 이 방식은 파일 개수보다 실제 변경 지점에 맞춰 작업하므로, 한 번의 대규모 재작성으로 회귀 기준을 잃을 가능성을 낮춥니다.

현재 XCTest 프로젝트에서는 무엇부터 옮겨야 합니까?

새 기능을 검증하는 단위 테스트, 매개변수화하기 쉬운 테스트, 공용 화면 상태에 의존하지 않는 통합 테스트부터 검토합니다. 이미 자주 실패하거나 환경 의존성이 큰 테스트는 먼저 옮기기보다 원인을 분리해야 합니다. Apple의 XCTest 전환 문서는 선언과 검증 표현의 대응 관계를 확인하는 출발점으로 사용할 수 있습니다.

이동 전후에는 다음 증거를 남깁니다.

• 같은 결함을 넣었을 때 두 버전이 모두 실패하는지 확인합니다.
• 조건부 건너뛰기와 환경별 제외 규칙이 동일하게 적용되는지 확인합니다.
• 실패한 테스트의 이름과 위치가 결과 보고서에서 정확히 구분되는지 확인합니다.
• 비동기 작업의 완료 시점과 오류 전파가 이전 의미와 같은지 확인합니다.

Swift Testing과 XCTest를 같은 Target에서 실행할 수 있습니까?

공식 문서와 WWDC26 자료가 설명하는 상호 운용 경로에 따라, 같은 테스트 묶음에서 두 체계를 병행하는 구성을 먼저 검토할 수 있습니다. 다만 실행 방식은 Xcode 버전, Scheme, Test Plan, 패키지 구성에 따라 달라질 수 있습니다. 따라서 한 실행 경로에서 성공했다고 모든 실행 환경이 같다고 판단해서는 안 됩니다. Swift Testing 공식 저장소의 지원 범위와 프로젝트의 실제 실행 결과를 함께 확인해야 합니다.

UI 테스트는 앱을 실행하고, 접근성 식별자나 화면 요소를 찾고, 사용자 동작 뒤의 상태를 확인해야 합니다. 이 목적을 단위 테스트 문법으로 바꾸면 화면 구동이라는 검증 자체가 사라질 수 있습니다. 성능 테스트도 측정 구간, 기준값, 결과 비교가 중요하므로 단순한 값 검증으로 치환해서는 안 됩니다.

다음과 같이 역할을 분리하면 이중 체계가 기술 부채가 아니라 능력별 선택이 됩니다.

• Swift Testing: 계산, 상태 전이, 네트워크 응답 해석, 저장소 규칙, 동시성 업무 코드
• XCTest: 화면 자동화, 앱 실행과 생명주기 확인, 성능 측정, 일부 Objective-C 예외 동작
• 공통 영역: 테스트 데이터, 모의 객체, 환경 설정은 의미가 변하지 않는 범위에서 공유

UI 테스트와 성능 테스트에 XCTest가 계속 필요한 이유는 무엇입니까?

두 테스트는 코드의 결과만 확인하지 않고 시스템과의 상호작용을 측정하기 때문입니다. 화면 자동화는 실제 인터페이스 구동이 필요하고, 성능 테스트는 측정 API와 결과 해석이 필요합니다. Swift Testing이 새 단위 테스트에 적합하다는 이유만으로 이 영역까지 옮기면 테스트 이름은 바뀌어도 검증 능력은 약해질 수 있습니다.

Swift Package, Apple 플랫폼 앱, 여러 운영 체제를 함께 지원하는 Swift 프로젝트는 같은 테스트 코드를 사용하더라도 실행 경로가 다를 수 있습니다. swift test에서 통과한 결과를 Xcode의 Test Plan이나 실제 기기 통합 검증 결과로 확대 해석하면 안 됩니다.

• Swift Package의 순수 코드 테스트는 패키지 도구 흐름에서 먼저 확인합니다.
• Apple 플랫폼 앱의 권한, 서명, 앱 생명주기, 화면 통합은 macOS와 Xcode 실행이 필요합니다.
• Windows 또는 Linux에서 가능한 순수 Swift 검증은 앞단에서 실행하되, Apple 플랫폼 통합 단계는 macOS에서 별도로 확인합니다.
• Test Plan에서는 선택된 테스트, 환경 변수, 반복 실행 조건, 결과 저장 위치를 고정합니다.

Xcode 27은 베타 단계 자료를 기준으로 판단해야 하므로, 기본 실행 동작과 상호 운용성 설정은 Xcode 27 베타 릴리스 노트에서 다시 확인해야 합니다. 2026년 9월 2일 기준으로는 정식 버전의 동작을 미리 보장할 수 없습니다.

원격 맥에서 테스트를 돌릴 때는 “명령이 종료 코드 0을 반환했는가”만 확인하면 부족합니다. 화면 테스트가 실행되지 않았는데도 성공으로 처리되거나, Swift Testing의 실패가 XCTest 결과와 분리되지 않으면 회귀 검증이 불완전해집니다.

다음 순서로 검증 환경을 고정합니다.

1. Xcode와 Swift 도구 모음의 버전을 기록합니다.
2. Scheme, Test Plan, 대상 기기와 테스트 실행 경로를 고정합니다.
3. Swift Testing 단위 테스트와 XCTest 단위 테스트를 같은 변경 사항으로 실행합니다.
4. XCTest UI Tests를 별도 단계에서 실행하고, 화면 테스트가 실제로 발견되었는지 확인합니다.
5. 전환 전후의 발견된 테스트 수, 실패 이름, 건너뛴 이유를 비교합니다.
6. xcresult와 로그를 보관해 실패 귀속을 다시 확인합니다.
7. 연결이 끊기거나 원격 호스트가 재시작된 뒤에도 같은 Test Plan을 재실행하고 결과 파일이 남는지 확인합니다.

실패 위치, 결과 묶음, 로그 보관 방식은 테스트 실행과 결과 해석에 관한 Apple 안내를 기준으로 구성합니다. 처음부터 가장 엄격한 상호 운용성 검사로 바꾸기보다, 공용 도우미를 정리하고 두 체계의 발견과 결과 분류가 안정된 뒤 검사 강도를 높이는 편이 진단 가능성을 보존합니다.

원격 CI에서 두 테스트 체계의 결과는 어떻게 확인합니까?

먼저 같은 커밋에서 각 체계가 기대한 테스트를 실제로 발견했는지 확인합니다. 다음으로 동일한 결함을 주입해 실패가 발생하는지 비교하고, 실패한 테스트 이름과 결과 파일이 서로 덮어쓰이지 않는지 확인합니다. 마지막으로 원격 맥을 재시작한 뒤 같은 Scheme과 Test Plan을 다시 실행합니다. 성능 향상을 가정하지 말고, 반복 실행과 결과 보존을 통과 기준으로 삼아야 합니다.

• 새 프로젝트이며 단위 검증이 중심이면 Swift Testing을 선택합니다.
• 기존 XCTest 중 자주 수정하는 단위 테스트가 있으면 해당 영역부터 점진적으로 이동합니다.
• 테스트가 화면 요소를 조작하면 XCTest UI Tests를 유지합니다.
• 실행 시간이나 메모리 같은 성능 지표를 측정하면 XCTest를 유지합니다.
• Objective-C 예외 동작이 검증 대상이면 동일한 의미가 입증되기 전까지 XCTest를 유지합니다.
• Swift Package의 순수 코드만 필요하면 패키지 실행 환경에서 먼저 확인합니다.
• 서명, 권한, 앱 생명주기, 화면 통합이 필요하면 macOS 실행 단계를 별도로 둡니다.
• 원격 CI에서 테스트 발견 수나 결과 파일이 달라지면 전환을 멈추고 Test Plan과 도우미부터 조사합니다.
• 재시작 후 반복 실행이 되지 않으면 프레임워크 선택보다 원격 실행 환경을 먼저 안정화합니다.

현재 Windows나 Linux 개발 환경에서 Apple 플랫폼 테스트까지 한 번에 해결하려 하면 실행 경로, 서명, 화면 자동화, 결과 보관 문제가 따로 남습니다. 로컬 장비만으로 야간 회귀를 유지하는 방식도 전원 상태, 디스크 공간, Xcode 설치 상태를 직접 관리해야 하고, 필요할 때만 테스트하는 소규모 팀에는 과한 고정 비용이 될 수 있습니다.

반대로 장기간 같은 프로젝트를 높은 빈도로 실행하고 물리 기기나 특수 장비가 반드시 필요한 팀이라면 자체 Mac을 보유하는 편이 더 적합할 수 있습니다. 다만 새 프레임워크 전환을 검증하거나 원격 회귀용 Mac을 임시로 확보해야 한다면, NUKCLOUD의 원격 맥 환경처럼 실제 macOS 실행 환경을 별도로 두는 방법이 더 현실적입니다. Test Plan과 결과 파일을 직접 확인하려는 경우에는 원격 맥 이용 안내에서 접속 방식과 운영 조건을 먼저 확인하는 것이 좋습니다.

마지막으로 프로젝트별 테스트 목록을 이동할 항목, 유지할 항목, 아직 검증할 항목으로 나누어 기록해야 합니다. 로컬 맥이 두 프레임워크의 회귀 실행을 계속 맡기 어렵다면, 실제 Test Plan을 기준으로 필요한 원격 맥 테스트 환경을 판단해야 합니다. NUKCLOUD의 맥 렌탈 요금 안내를 검토할 때도 장기 고정 부하인지, 일시적인 마이그레이션과 CI 검증인지부터 구분하면 과도한 환경 선택을 피할 수 있습니다.