Xcode 27 JSON 프로젝트 형식으로 이전해야 할까요? 2026년 기업 CI 선택

Xcode 27 JSON 프로젝트 형식으로 이전할 필요는 없습니다. 기존 프로젝트라면 이번 주에는 격리된 CI 노드에서 빌드와 협업, 복구를 먼저 검증하고, 도구 호환성이나 복구 경로가 불확실하면 현재 형식을 유지하세요. 새 프로젝트의 기본 형식과 기존 프로젝트의 이전 결정은 별개입니다.

이 글은 여러 저장소의 형식 정책을 정해야 하는 기업 iOS 플랫폼 책임자를 위한 안내입니다.
CI 플랫폼 엔지니어는 노드별 Xcode 버전과 파이프라인 검증 기준을 확인할 수 있습니다.
코드 리뷰와 릴리스를 맡는 기술 책임자는 병합, 복구, 배포 위험을 점검할 수 있습니다.

마지막 확인: 2026년 10월 5일. 형식 지원 범위와 기본값은 Apple의 프로젝트 형식 안내 및 Xcode 릴리스 정보를 기준으로 확인했습니다.

기술 의사결정자: 새 프로젝트의 기본값과 기존 저장소 이전 분리

Apple 문서에 따르면 Xcode 27 이상은 .xcproj JSON 형식을 지원하며, Xcode 27.2 이상에서는 새 프로젝트의 기본 프로젝트 설정 형식으로 사용합니다. 기존 프로젝트도 형식을 전환할 수 있습니다. 하지만 이 사실은 기존 저장소를 즉시 바꿔야 한다는 뜻이 아닙니다. 형식 지원과 전환 범위와 기본 형식이 바뀌는 릴리스 정보를 각각 확인한 뒤, 팀의 실제 도구 체인에 맞춰 결정하세요.

판단은 기능 발표가 아니라 저장소별 증거에 근거해야 합니다. 여러 앱 저장소에 일괄 적용하면, 설정 변경과 Xcode 업그레이드가 동시에 발생했을 때 실패 원인을 분리하기 어렵습니다. 따라서 형식 정책을 정하더라도 Xcode 및 macOS 변경은 별도 검토 항목으로 관리하세요.

CI 플랫폼 팀: 개발자 화면과 운영 노드의 차이 확인

프로젝트가 개발자 컴퓨터에서 열리는 것과 운영 CI에서 안정적으로 빌드되는 것은 다른 검증입니다. Apple의 Xcode 시스템 요구 사항을 참고해 노드에 설치된 Xcode가 해당 macOS 환경에서 동작하는지 확인하세요. 이어서 명령행 도구 참조에 따라 실행 환경이 사용할 Xcode와 명령행 도구를 기록합니다.

시험은 현재 생산 파이프라인의 기준선과 비교할 수 있도록 구성하세요. 저장소 커밋, 의존성, 스킴 선택, 서명 설정이 다르면 형식 변경의 영향인지 환경 차이인지 판별하기 어려워집니다. 격리 노드에서 아래 항목을 차례로 점검합니다.

• 프로젝트 파일을 파싱하고 Xcode에서 여는 단계가 완료되는지 확인합니다.
• 각 운영 대상 스킴의 빌드 결과와 실패 원인을 기록합니다.
• 테스트가 실행되고 기존 파이프라인과 결과를 비교할 수 있는지 확인합니다.
• 배포 흐름에 포함되는 아카이브와 서명 단계도 검증합니다.
• 각 결과에 사용한 Xcode 버전, macOS, 커밋 식별자와 로그를 남깁니다.

Xcode 버전만 같다고 검증이 끝난 것은 아닙니다. CI 노드가 실제로 선택한 개발 도구 경로와 스킴별 설정이 일치하는지 확인하세요. 빌드와 테스트가 통과하더라도 아카이브 또는 서명이 흐름에 포함된다면 해당 단계가 통과하기 전에는 이전을 승인하지 않는 편이 안전합니다.

애플리케이션 팀: 프로젝트 설정과 생성 도구 추적

애플리케이션 담당자는 .xcproj 자체뿐 아니라 프로젝트 파일을 만들거나 수정하는 구성 요소를 살펴야 합니다. 저장소에 포함된 프로젝트 생성 스크립트, 플러그인, 의존성 관리 절차, 사내 자동화가 있다면 각각을 실제 이전 대상 목록에 올리세요. 모든 외부 도구가 새 형식을 지원한다고 미리 가정하지 말고, 각 도구의 현재 동작을 확인해야 합니다.

비교 대상은 파일 이름만이 아닙니다. 타깃, 스킴, 빌드 설정, 구성별 값, 서명 관련 설정이 전환 전후에 같은 의미를 유지하는지 확인하세요. Apple의 프로젝트 스킴 구성 안내는 스킴 동작을 점검할 때 참고할 수 있습니다. 형식이 바뀐 뒤 스킴이 보이더라도, CI가 선택하는 동작과 액션이 동일하다는 뜻은 아니므로 실제 명령과 로그로 검증하세요.

코드 리뷰 팀: 파일 차이보다 변경 의도를 판독

JSON은 구조가 드러나는 표현을 제공하지만, 파일 형식이 바뀐다고 리뷰 품질이 저절로 좋아지는 것은 아닙니다. 같은 종류의 설정 변경을 기존 파일과 새 형식에서 비교하고, 검토자가 바뀐 타깃이나 설정을 정확히 찾아낼 수 있는지 확인하세요. 불필요한 파일 재정렬이나 대량 변경이 리뷰 화면을 덮으면, 중요한 빌드 설정 변경을 놓칠 가능성이 커집니다.

형식 전환 커밋과 기능 변경을 한데 묶지 마세요. 리뷰어가 파일 표현의 변화와 제품 설정의 변화를 구분하지 못하면, 형식 자체의 가독성을 공정하게 평가하기 어렵습니다.

시험 브랜치에서 여러 담당자가 같은 프로젝트 설정을 수정하도록 하고, 병합 충돌을 해결하는 과정과 최종 diff를 기록하세요. 리뷰 의견에 변경 의도를 찾기 어려웠다는 지적이 반복되면, 포맷 전환이 협업을 개선했다고 결론 내리지 말고 리뷰 규칙이나 전환 범위를 조정하세요.

저장소 관리자: 되돌리기 기록과 실제 복구 검증

Apple의 형식 변경 안내에서 이전 과정과 .pbxproj 및 .xcproj 파일의 관계를 확인하세요. 저장소에서는 별도 브랜치에 전환 변경을 보관하고, 어떤 파일이 추가·삭제·수정됐는지 커밋 차이로 남깁니다. Apple의 프로젝트 형식 관련 공개 저장소도 형식 구조를 확인할 때 함께 살펴볼 수 있습니다.

복구 절차는 변경을 취소하는 것으로 끝나지 않습니다. 기존 파일 상태로 되돌린 커밋을 격리 CI에 반영한 뒤, 프로젝트 열기부터 빌드와 테스트까지 실행하세요. 배포에 아카이브나 서명이 포함된다면 해당 단계까지 확인해야 합니다. 파일 복원이 성공했더라도 이전 실행 환경과 산출물 생성이 회복되지 않았다면, 전체 릴리스 경로가 복구됐다고 기록해서는 안 됩니다.

릴리스 책임자: 통과·개선 후 재검토·보류 판정

최종 판정은 플랫폼 팀의 CI 기록, 애플리케이션 팀의 도구 호환 목록, 리뷰 팀의 협업 관찰, 저장소 관리자의 복구 결과를 함께 보고 내리세요. 하나라도 핵심 단계가 확인되지 않았다면 전체 저장소에 적용하지 말고, 담당자와 재검토 조건을 명시하세요. Xcode나 macOS도 함께 바꿔야 한다면 변경을 나눠 원인을 추적할 수 있게 합니다.

• 적용 승인: 운영에 필요한 빌드·테스트·아카이브 경로가 확인되고, 도구 동작과 복구 시험의 기록을 리뷰할 수 있으면 시범 저장소에서 다음 팀으로 확대합니다.
• 개선 후 재검토: 실패 원인과 담당 팀이 특정되지만 해결 전이라면, 대상 저장소를 제한하고 수정 증거를 받은 뒤 다시 판정합니다.
• 이전 보류: CI 노드의 Xcode 버전이나 생성 도구 호환성이 불명확하거나, 복구 커밋으로 운영 경로를 재현할 수 없다면 기존 형식을 유지합니다.

격리 노드를 새로 마련해 시험하려면 먼저 필요한 Xcode 버전과 접근 방식을 확인하세요. 예산과 제공 조건은 VMSPIN의 요금 안내에서 확인하고, 실제 환경을 살펴볼 필요가 있다면 한국 주문 안내를 참고할 수 있습니다. 원격 환경은 시험 노드 확보와 회수에는 유용할 수 있지만, 이미 고정된 장비에서 장기간 부하를 처리하거나 물리 연결 장치가 필요한 경우에는 자체 Mac이 더 적합할 수 있습니다. 기존 형식을 유지하면 전환 위험은 미루지만 새 형식 검증은 진행되지 않고, 자체 장비만으로 시험하면 도입·관리 부담을 계속 감당해야 합니다. 임시로 격리된 CI 검증 공간이 필요한 상황이라면 VMSPIN의 원격 Mac을 시험 환경 후보로 검토하되, 운영 투입 전에는 같은 승인 기준으로 직접 검증하세요.

자주 묻는 질문

기존 Xcode 프로젝트도 JSON 형식으로 바꿀 수 있나요?

가능합니다. Apple은 기존 프로젝트의 형식 전환을 안내하지만, 지원된다는 사실만으로 모든 저장소의 전환을 권하는 것은 아닙니다. 먼저 공식 형식 안내에서 현재 Xcode 버전과 전환 절차를 확인하고, 복제 저장소에서 프로젝트 설정 차이와 실제 빌드 결과를 비교하세요. 생성 도구나 플러그인이 전환 결과를 처리하지 못하면 기존 형식을 유지하는 편이 안전합니다.

.xcproj는 서로 다른 Xcode 버전의 CI 노드에서 빌드할 수 있나요?

확인 없이 서로 다른 버전 사이의 호환성을 가정하지 마세요. Apple 문서는 Xcode 27 이상에서 JSON 형식 지원을 설명하며, 기본값 변경은 Xcode 27.2 이상에 해당합니다. 각 CI 노드에 설치된 버전과 선택된 명령행 도구를 기록하고, 해당 조합으로 열기, 빌드, 테스트, 아카이브가 모두 완료되는지 확인해야 합니다. 로컬에서 열리는 것만으로 운영 노드의 성공을 입증할 수는 없습니다.

프로젝트 형식 전환을 저장소에서 안전하게 되돌리려면 무엇을 확인해야 하나요?

전환은 별도 브랜치에서 진행하고, 변경 전후 프로젝트 파일과 설정 차이를 커밋 기록으로 남기세요. 복구 시험은 파일을 이전 상태로 되돌리는 데서 끝나지 않습니다. 되돌린 커밋을 CI에 적용해 프로젝트가 다시 열리고 빌드와 테스트가 통과하는지 확인해야 합니다. 아카이브나 서명 단계가 운영에 포함된다면 해당 단계도 복구 범위에 넣어야 전체 배포 경로의 복구를 판단할 수 있습니다.

기업 CI에서 프로젝트 형식 변경을 배포 전에 어떻게 검증하나요?

격리된 노드와 시험 브랜치를 사용하고, 기존 기준선과 동일한 저장소 상태 및 도구 버전으로 비교하세요. 프로젝트 파싱, 스킴별 빌드, 테스트, 아카이브 결과와 생성 프로젝트 도구의 동작을 기록합니다. 코드 리뷰에서는 설정 변경이 의도대로 드러나는지, 동시에 수정한 변경이 병합되는지도 살펴보세요. 이 증거를 플랫폼 담당자와 릴리스 담당자가 함께 검토한 뒤 확대 여부를 결정해야 합니다.