Expo SDK 58 iOS EAS Build 실패, 어떻게 해야 할까? 2026년 점검

증상: Expo SDK 58 iOS EAS Build 실패. 가장 먼저 할 일은 SDK 업그레이드를 원인으로 단정하지 않고 전체 Xcode 로그에서 첫 유효 오류를 찾는 것입니다.
빠른 조치: 실패 단계에 따라 마이그레이션 변경, 업로드 파일, 환경 변수, 서명을 차례로 대조합니다. 로컬 도구 체인이 필요하거나 클라우드에서만 재현될 때는 도구 버전을 맞춘 Mac에서 다시 확인합니다.

이 글은 Expo SDK 58로 올린 뒤 iOS 빌드가 완료되지 않는 독립 개발자와 소규모 팀을 위한 진단 절차입니다.
config plugin, 직접 관리하는 iOS 폴더, 원시 모듈을 사용하는 프로젝트도 점검할 수 있습니다.
로컬 Mac 없이 EAS를 이용하는 개발자는 어떤 오류부터 Mac에서 재현할지 판단할 수 있습니다.

마지막 업데이트: 2026년 11월 6일. Expo의 SDK 58 변경 기록과 빌드 문제 해결 문서, Apple의 Xcode 시스템 요구 사항을 확인해 작성했습니다. SDK 변경이나 빌드 요구 사항이 바뀌면 프로젝트 로그와 함께 다시 검토해야 합니다. (SDK 58 변경 기록, Expo 빌드 문제 해결 안내, Apple Xcode 시스템 요구 사항)

Expo SDK 58 iOS EAS Build 실패는 로그의 첫 오류부터 봅니다

빌드 결과 화면의 요약 문구만으로 원인을 판단하지 마세요. 전체 로그에서 처음 나타난 실질적인 오류를 찾고, 오류가 속한 단계를 먼저 분류합니다. 마지막 줄의 일반적인 실패 문구는 앞 단계의 실패를 반복해 보여 주는 경우가 있습니다. Expo도 iOS 문제를 조사할 때 전체 Xcode 로그와 도구 버전을 확인하도록 안내합니다. (Expo 빌드 문제 해결 안내)

로그에서 확인한 실패 단계	먼저 대조할 항목	다음 조치
프로젝트 생성	SDK 변경, config plugin, 생성된 iOS 파일	생성 결과와 설정을 비교합니다
의존성 설치 또는 JavaScript 묶기	잠금 파일, 업로드 파일, 설치 로그	클라우드에 전달된 파일을 확인합니다
Xcode 컴파일	원시 모듈, Xcode 도구 체인, 컴파일 오류	오류가 발생한 모듈과 빌드 환경을 분리해 봅니다
서명 또는 보관	계정 권한, 팀, 앱 식별자, 인증 자료	컴파일 문제와 서명 문제를 따로 처리합니다
설치 후 실행	기기 로그, 릴리스 빌드, 런타임 경로	빌드 실패와 앱 실행 오류를 구분합니다

우선 실패한 작업의 전체 로그를 열어 보세요. 요약만 남아 있다면 빌드 세부 정보에서 전체 Xcode 로그를 내려받아 검색합니다. 그런 다음 아래처럼 현재 코드 상태와 업그레이드 전후 변경을 확인합니다.

git status --short
git diff -- package.json
git diff -- package-lock.json

프로젝트에서 다른 패키지 관리자를 쓴다면 실제 잠금 파일도 함께 확인합니다. 업그레이드 직전의 커밋과 현재 커밋을 비교하면 SDK 변경과 함께 들어온 의존성 변경을 분리하기 쉽습니다. 로그에서 첫 오류를 찾기 전에 설정을 여러 개 동시에 바꾸면 무엇이 해결했는지 확인하기 어렵습니다.

실패 단계에 따라 원인을 좁히는 순서

SDK 마이그레이션과 생성된 iOS 프로젝트를 대조합니다

Expo SDK 58의 변경 기록에는 이 버전의 주요 변경 사항과 iOS scene 기반 수명 주기에 관한 안내가 있습니다. 그렇다고 모든 프로젝트가 같은 방식으로 실패한다는 뜻은 아닙니다. 실제로 사용하는 기능과 코드 경로에 해당하는 변경만 확인합니다. (Expo SDK 58 변경 기록)

프로젝트가 CNG 방식이라면 app 설정과 config plugin이 생성 결과에 반영되는지 살펴봅니다. 직접 iOS 폴더를 관리한다면 AppDelegate를 덮어썼는지, 네이티브 모듈이 새 SDK와 맞는지, 생성물과 수동 수정 내용이 서로 어긋나지 않는지 확인합니다. 마이그레이션 문서의 항목을 프로젝트에 실제 사용하지 않는데도 원인으로 지목하지 마세요.

EAS 업로드 파일과 설치 과정을 분리합니다

클라우드 빌드는 개발자 컴퓨터의 작업 폴더를 그대로 읽는 것이 아닙니다. 업로드용 아카이브에서 제외된 파일은 서버에 전달되지 않습니다. .gitignore와 .easignore를 확인하고, 로컬에서만 존재하는 파일이나 커밋하지 않은 수정 사항을 빌드 입력으로 착각하지 않았는지 살펴봅니다. EAS의 파일 포함·제외 규칙은 업로드 아카이브 안내에서 확인할 수 있습니다.

git status --short
git check-ignore -v 경로/파일이름

실제 파일 이름과 경로로 바꾸어 실행합니다. 이어서 로그에서 JavaScript 묶기, 네이티브 의존성 설치, Xcode 컴파일 중 무엇이 먼저 실패했는지 구분합니다. 설치 실패를 Xcode 오류로 오인하면 원인과 관계없는 네이티브 설정을 바꾸게 됩니다.

환경 변수와 서명 자료를 별도로 검토합니다

로컬 셸에만 설정된 값은 EAS 빌드에서 자동으로 사용할 수 있다고 가정하면 안 됩니다. 빌드 프로필, 환경 변수 이름과 적용 범위를 대조하고, 비밀 값 자체를 로그나 공개 저장소에 출력하지 마세요. 환경별 변수 설정과 사용 방식은 EAS 환경 변수 안내를 기준으로 확인합니다.

서명 단계에서 실패했다면 Apple 팀, 앱 식별자, 빌드 자격 증명, 계정 접근 권한을 살핍니다. 컴파일 오류를 고치려는 목적으로 서명 자료를 무관하게 철회하거나 다시 만들지 마세요. 수정 후에는 같은 코드 상태로 재빌드하고, 보관과 서명, 이후 업로드가 각각 완료되는지 따로 확인합니다.

로컬은 성공하고 EAS만 실패할 때 차이를 좁힙니다

로컬 성공만으로 EAS 자체의 장애라고 결론 내릴 수 없습니다. 제출 커밋, Node 버전, 패키지 관리자와 잠금 파일, Xcode, 환경 변수, 업로드 아카이브가 서로 다를 수 있습니다. 먼저 이 항목을 양쪽에서 나란히 적어 차이가 실제로 있는지 확인합니다.

대조 항목	로컬에서 기록할 내용	EAS에서 확인할 내용
소스 상태	커밋과 변경 파일	빌드에 사용된 커밋
의존성	패키지 관리자와 잠금 파일	설치 단계의 명령과 결과
도구	Node 및 Xcode 정보	빌드 로그에 표시된 도구 버전
설정	로컬 환경 변수	선택된 빌드 환경과 변수
입력 파일	작업 폴더에 있는 파일	업로드 아카이브에 포함된 파일

이 비교에서 로컬과 클라우드의 차이가 확인되면, 그 차이를 하나씩 줄여 다시 빌드합니다. iOS 네이티브 컴파일처럼 macOS 도구가 필요한 오류라면 Xcode 버전과 프로젝트 상태를 맞춘 Mac에서 릴리스 빌드를 재현할 수 있습니다. EAS의 로컬 빌드 안내를 확인하되, 로컬 재현은 클라우드의 업로드와 환경을 그대로 증명하지 않으므로 두 로그를 계속 대조해야 합니다.

Apple은 Xcode별 시스템 요구 사항을 공개합니다. 로컬과 클라우드에서 사용하는 Xcode가 다른 경우에는 Apple의 현재 Xcode 요구 사항에서 지원되는 macOS 조건을 확인한 뒤 비교합니다. 필요한 도구 버전을 맞출 수 없다면 로컬 빌드 결과만으로 클라우드 환경을 판정하지 않습니다.

조건에 따라 다음 조사 위치를 선택합니다

아래 조건에서 해당하는 경로를 골라 진행합니다.

첫 유효 오류가 config plugin 또는 프로젝트 생성 단계에 있으면, SDK 변경과 생성 설정을 먼저 확인합니다. 직접 관리하는 네이티브 코드가 있다면 생성물과 수동 변경도 대조합니다.
오류가 파일을 찾지 못하거나 의존성을 설치하지 못하는 단계에서 시작되면, 업로드 아카이브와 잠금 파일을 먼저 확인합니다.
오류가 Xcode 컴파일에 한정되고 로컬 Mac에서도 재현되면, 컴파일 로그에 표시된 모듈과 Xcode 도구 체인을 조사합니다.
로컬 빌드는 통과하지만 EAS에서만 실패하면, 커밋·도구 버전·환경 변수·업로드 파일 차이를 기록한 뒤 한 항목씩 맞춥니다.
실패가 서명이나 보관 단계에서 시작되면, 계정 권한과 앱 식별자, 인증 자료를 확인합니다. 소스 코드 컴파일 오류와 섞어 수정하지 않습니다.
빌드가 완료된 뒤 앱이 충돌하거나 화면이 잘못 나타나면, 빌드 오류가 아니라 런타임 문제로 분리합니다. 릴리스 빌드와 실제 기기 로그를 확인하고, scene 수명 주기 변경은 프로젝트가 해당 경로를 사용할 때만 조사합니다.

SDK 58 변경 기록만으로 프로젝트의 실패 원인을 확정할 수는 없습니다. 로그에서 실패 단계와 오류가 시작된 지점을 확인한 뒤, 프로젝트가 실제로 사용하는 설정과 코드만 조사합니다.

Mac 재현이 필요한 시점과 다음 조치

Mac 재현은 모든 EAS 실패에 필요한 단계가 아닙니다. 문제가 업로드 파일, 환경 변수 또는 계정 설정에 있으면 해당 구성을 고치고 기존 EAS 흐름에서 다시 빌드하는 편이 빠릅니다. 반대로 Xcode 컴파일, 네이티브 모듈, 생성된 iOS 프로젝트를 조사해야 하거나 클라우드에서만 나타나는 도구 차이를 확인해야 한다면, 같은 커밋과 맞는 도구 버전의 Mac 환경이 도움이 됩니다.

현재 방식이 EAS만으로 충분하다면 로컬 Mac을 추가하지 않아도 됩니다. 다만 원시 프로젝트를 직접 열어 확인해야 하는데 접근할 Mac이 없으면, 디버깅이 막히고 도구 버전 차이를 좁히기 어려우며 같은 조건의 재현 환경을 만들기 힘들 수 있습니다. 이 경우 원인을 확인하는 동안 쓸 Mac이 필요한지 판단하고, 지속적인 개인 장비 구매 대신 원격 Mac을 단기 이용하는 선택지도 검토할 수 있습니다. 소스 설정이나 의존성 오류만 남아 있다면 Mac을 추가하기보다 해당 문제를 먼저 수정하는 것이 맞습니다.

Xcode에서 직접 확인할 환경이 필요하다면 한국에서 이용할 수 있는 Mac 환경을 살펴볼 수 있습니다. 이용 기간과 접근 방식까지 비교하려면 Mac 이용 방식 비교를 확인한 뒤, 임시 재현 작업인지 상시 빌드 운영인지에 맞춰 선택합니다.