네 팀, 네 가지 CI 워크플로

1. 코드 푸시

   Windows에서 개발을 마친 뒤 확정한 커밋을 코드 저장소에 푸시합니다. 의존성 잠금 파일도 함께 커밋해 원격에서 다른 의존성 세트가 설치되지 않도록 하세요.

2. 아카이브 생성

   도쿄 노드에서 코드를 가져와 프로젝트에 필요한 의존성을 설치한 다음 다음 명령을 실행합니다: flutter build ipa. 서명 인증서와 프로비저닝 프로파일, 접근 권한은 직접 설정해야 합니다.

3. 배포 업로드

   버전과 빌드 번호를 확인한 뒤 fastlane pilot 을 사용해 TestFlight에 업로드합니다. ipa 파일, 로그, 해당 커밋 식별자를 자체 아티팩트 저장소에 보관하세요.

전제 조건: TestFlight 배포에 필요한 유효한 개발자 자격, 서명 자료, App Store Connect API Key는 직접 준비해야 합니다. 원격 노드가 이러한 조건을 대신해 주지는 않습니다.

1. 러너 등록

   싱가포르 노드에 GitHub Actions self-hosted runner를 설치하고, 라벨로 macOS 작업을 해당 노드에 지정합니다. 작업을 트리거할 수 있는 저장소와 브랜치도 제한하세요.

2. 우선순위 구분

   main 브랜치 병합 시 빌드와 기본 검사를 실행하고, 릴리스 브랜치에는 별도의 작업을 유지합니다. nightly 에는 시간이 오래 걸리는 시뮬레이터 UI 테스트를 실행합니다.

3. 작업 디렉터리 분리

   브랜치나 작업별로 작업 디렉터리와 DerivedData를 분리하세요. 최대 메모리 사용량, 디스크 증가량, 대기 시간을 기록한 뒤 동시 실행 수를 늘리거나 노드를 추가할지 결정합니다.

지역을 고를 때는 팀 위치만 보지 말고 저장소 다운로드, 의존성 설치, 결과물 업로드 경로를 비교하세요. 다른 지역과 협업한다면 실제 프로젝트로 먼저 시험 운영하는 것이 좋습니다.

1. 호환성 확인

   추론 프레임워크가 Apple Silicon과 필요한 연산자를 지원하는지 확인하세요. 모델 파일 크기뿐 아니라 가중치, 컨텍스트 길이, 런타임 오버헤드를 고려해 메모리를 추정해야 합니다.

2. 평가 입력 고정

   사용 권한이 있는 모델을 다운로드하고 버전, 양자화 설정, 프롬프트 세트를 기록하세요. 매번 같은 입력으로 실행하고 최초 로드 시간과 이후 추론 시간을 구분해 측정합니다.

3. 실험 기록 저장

   처리량, 최대 메모리 사용량, 품질 평가 결과를 내보내 자체 저장소에 동기화하세요. 모델 실행을 검증한 뒤 이 환경을 월 단위로 유지할지 판단합니다.

이 사례는 컴퓨팅 워크플로를 보여 주기 위한 것으로, 특정 모델의 속도나 결과를 보장하지 않습니다. 시험 운영 시 메모리, 최초 로드, 지속 추론 성능을 함께 측정하고 단일 실행 결과만으로 판단하지 마세요.

1. 전송 및 샘플 검증

   처리 권한이 있는 미디어 파일을 업로드하고, 먼저 짧은 구간으로 코덱, 색상 설정, 내보내기 매개변수를 검증하세요. 전체 작업의 납기 예산에 업로드 시간도 포함해야 합니다.

2. 내보내기 대기열 구성

   스크립트나 앱의 일괄 처리 기능으로 작업을 구성하세요. 병렬 작업 수를 단계적으로 늘리면서 메모리와 디스크 읽기·쓰기 상태를 살펴 여러 내보내기 작업이 서로 느려지지 않도록 합니다.

3. 결과물 전송 및 정리

   오디오와 영상의 동기화, 재생 시간, 파일 무결성을 확인한 뒤 완성본과 작업 로그를 가져옵니다. 백업을 확인한 후 중간 파일을 정리해 다음 작업에 필요한 공간을 확보하세요.

기본 제공되는 SSD 2TB를 기준으로 원본 미디어, 캐시, 내보내기 파일의 최대 용량을 계산하세요. 실제로 더 많은 공간이 필요할 때만 SSD +2TB를 추가하고, 처음부터 기본 사양으로 간주하지 마세요.