빌드가 막혔나요? 여기서 해결 방법을 찾아보세요

콘솔에서 해당 인스턴스를 열어 머신 번호, 서비스 상태, 만료 시각을 확인하세요. 인스턴스 상세 정보에 표시된 현재 연결 주소와 로그인 정보를 사용하고, 이전 주문이나 다른 고객의 머신 정보를 재사용하지 마세요.

주소를 확인한 다음 원격 데스크톱 클라이언트의 연결 방식과 계정을 점검하세요. 연결 시간이 초과되면 다른 로컬 네트워크에서 다시 시도해 보세요. 인증 실패가 표시되면 사용자 이름, 비밀번호, 입력기 설정을 중점적으로 확인하세요. 두 오류를 구분하지 않고 비밀번호를 반복해서 변경하지 마세요.

계속 실패하면 클라이언트 이름, 전체 오류 메시지, 발생 시각과 시간대를 기록하세요. 스크린샷에서는 비밀번호를 가려 주세요. 연결 정보는 로그인 후 인스턴스 상세 정보에서 확인하고, 공개 페이지에 올리지 마세요.

콘솔의 인스턴스 상세 정보에서 SSH 주소, 포트, 사용자 이름을 확인하세요. 연결 시간이 초과되면 주소, 포트, 로컬 네트워크의 외부 연결, 머신 상태부터 점검해야 합니다. 인증이 거부되면 계정과 실제로 사용 중인 인증 방식을 확인하세요.

원인을 더 자세히 확인하려면 기존 연결 명령에 -v를 추가하고 연결 단계에서 멈추는지, 인증 단계에서 멈추는지 확인하세요. 관련 오류 행만 티켓에 첨부하면 됩니다. 개인 키, 비밀번호 또는 민감한 경로가 포함된 전체 로그는 제출하지 마세요.

명령줄 빌드가 가능한 프로젝트는 SSH를 사용할 수 있습니다. 그래픽 설정, 키체인 권한 또는 Xcode 구성을 처음 확인할 때는 원격 데스크톱으로 점검하는 편이 더 편리합니다.

먼저 프로젝트에서 요구하는 Xcode 버전을 확인한 다음, xcodebuild -version 과 xcode-select -p 로 현재 도구 체인을 점검하세요. 버전을 설치하거나 전환한 뒤에는 먼저 GUI에서 필요한 최초 실행 설정을 마치고 스크립트로 돌아와 빌드하세요.

서명 자료는 고객의 승인을 받아 제공받아야 합니다. 프로젝트에서 사용하는 키체인에 서명 인증서를 가져온 뒤, 연결된 개인 키가 포함되어 있는지, 인증서가 유효한지, 프로비저닝 프로파일의 팀·Bundle Identifier·내보내기 방식이 서로 일치하는지 확인하세요.

컴파일은 성공했지만 내보내기에 실패하면 Archive 오류와 내보내기 오류를 따로 보관하세요. 두 단계를 하나로 취급하지 마세요. 먼저 Xcode에서 검증한 뒤 자동화에 연결하는 것이 좋습니다. 서명 자료를 확인하지 않은 상태에서 전체 파이프라인을 반복 실행하지 마세요.

코드와 의존성 잠금 파일을 클라우드 Mac에 동기화하고, 먼저 flutter doctor -v 로 iOS 도구 체인을 확인한 다음 flutter pub get을 실행하세요. 팀원 모두 프로젝트에서 정한 Flutter 버전을 사용하고, 납품 직전에 의존성을 임의로 업그레이드하지 마세요.

Xcode 프로젝트와 서명 설정을 마친 후 flutter build ipa를 실행하세요. 의존성 설치 단계에서 오류가 발생하면 먼저 의존성을 해결하세요. 서명이나 프로비저닝 프로파일을 명확히 가리키는 오류라면 서명 설정을 다시 확인해야 합니다. 의존성을 반복해서 내려받아도 대개 해결되지 않습니다.

빌드가 성공하면 ipa와 필요한 심볼 파일을 내보내고, 빌드에 사용한 커밋 버전을 확인하세요. Windows에서 일상적인 개발을 계속할 수 있으며 iOS 최종 빌드와 서명은 Mac에서 진행합니다.

먼저 Node, 패키지 관리자, 프로젝트 의존성 버전을 고정하고 저장소 안내에 따라 iOS 의존성을 설치하세요. 프로젝트에서 CocoaPods를 사용한다면 개별 프로젝트 파일만 열지 말고 해당 workspace를 여세요.

Xcode에서 올바른 Scheme과 Release 구성을 선택해 Archive를 실행하세요. JavaScript 리소스 번들링, 네이티브 의존성 컴파일, 서명 및 내보내기를 각각 구분해 확인해야 합니다. 개발 모드에서 사용하는 로컬 디버깅 서버가 배포 패키지에 필요한 리소스를 모두 포함한다는 뜻은 아닙니다.

티켓에 실패 단계, 처음 발생한 유효한 오류, 도구 버전을 첨부하세요. 비즈니스 코드나 서드파티 의존성 자체의 오류는 프로젝트 팀이 소스 코드를 확인해 수정해야 합니다. 머신 연결 및 환경 문제는 지원팀과 함께 점검할 수 있습니다.

여러 프로젝트를 동시에 납품하며 격리가 중요하다면 고객별로 독립 물리 머신을 대여하는 것이 명확합니다. 머신 번호, 저장소, 키체인, 납품 날짜를 각각 대응시키면 빌드 작업을 한 머신에서 순서대로 처리할 필요도 없습니다.

가끔 컴파일하는 소규모 프로젝트라면 하루 단위로 머신을 대여해 번갈아 사용할 수 있습니다. 머신을 교체할 때는 로컬 사용자 계정, 코드 디렉터리, 서명 자료를 각각 분리하세요. 관리에는 편리하지만 물리적으로 머신을 분리하는 것과 같지는 않습니다.

독립 머신 한 대는 대여 고객 한 명에게만 제공되며, 스튜디오 내부의 프로젝트별 격리가 자동으로 설정되는 것은 아닙니다. 고객 계약상 데이터 경계가 중요하다면 먼저 계약 내용을 확인한 뒤 머신을 공유할지 분리할지 결정하세요.

콘솔에서 해당 인스턴스의 주문 또는 구독 관리 메뉴를 열어 만료 시각과 갱신 방법을 확인하세요. 갱신할 대상과 기간을 확인한 뒤 결제하세요. 다른 고객의 프로젝트를 연장하지 않도록 머신 메모만 보고 판단하지 마세요.

만료 시 갱신하지 않으면 서비스가 중지되며 별도의 해지 수수료는 없습니다. 결제를 제출했다고 해서 연장이 완료된 것은 아니므로 콘솔의 결제 결과와 갱신된 만료 시각을 확인하세요. 계속 작업하려면 기존 대여 기간이 끝나기 전에 확인을 마쳐야 합니다.

USDT-TRC20 및 Visa / Mastercard / Amex(Stripe 경유)만 지원하며 모든 결제는 미국 달러(USD)로 처리됩니다. 실제로 사용할 수 있는 결제 게이트웨이는 백엔드에서 제공하는 정보를 기준으로 합니다.

결제 상태가 갱신되지 않으면 먼저 콘솔에서 해당 청구서를 열어 주문 번호, 금액, 결제 게이트웨이 결과를 확인하세요. USDT-TRC20 결제는 네트워크와 페이지에 표시된 수취 정보를 확인하세요. 상태를 갱신하려고 결제를 반복하지 마세요.

인보이스와 청구서는 콘솔에서 확인할 수 있습니다. 도움이 필요하면 티켓에 청구서 번호를 적어 주세요. 온체인 결제는 트랜잭션 해시를 첨부할 수 있지만, 카드 결제의 전체 카드 번호나 보안 코드는 보내지 마세요.