재현 가능한 엔지니어링 워크플로

커밋, 빌드, 서명과 산출물 전달을 전용 클라우드 Mac에서 처리하세요.

MiniDebug M4는 다른 주문과 장비 컴퓨팅 리소스를 공유하지 않는 전용 물리 머신입니다. 실제 작업을 기준으로 입력, 실행 단계, 산출물과 일반적인 실패 지점을 나누어 기존 iOS·CI·AI·크리에이티브 워크플로에 적합한지 판단할 수 있도록 했습니다.

M4 / 16GB / 256GB 일·주·월·분기 단위 대여 선택 가능한 5개 노드
클라우드 Mac 노드, 빌드 작업과 산출물 전송으로 구성된 엔지니어링 워크플로 다이어그램
물리 노드 온라인 MiniDebug M4
01
커밋 가져오기 고정 커밋 해시와 의존성 잠금 파일
02
빌드 실행 아카이브 로그, 종료 코드 및 소요 시간
03
산출물 전달 파일 검증 및 작업 기록 저장
iOS 자동 패키징

Git 커밋부터 아카이브 가능한 산출물까지 모든 단계에 추적 가능한 결과가 남습니다.

안정적인 자동 패키징은 명령 하나만으로 완성되지 않습니다. 소스 버전, 의존성 상태, Xcode 선택, 서명 입력값, 내보내기 매개변수와 산출물 경로를 함께 고정하고, 어느 단계의 실패든 로그로 추적할 수 있어야 합니다.

  1. 01 · 트리거

    커밋 및 작업 입력 고정

    입력:저장소 주소, 브랜치, 커밋 해시, 빌드 구성 및 대상 Scheme. Webhook 또는 큐 작업은 식별자만 전달하고, 스크립트에서 브랜치를 임의로 추정하지 않습니다.

    실패 지점:커밋이 없거나 서브모듈이 동기화되지 않았거나 권한이 부족한 경우, 또는 동일 작업이 변경 중인 브랜치 헤드를 읽는 경우입니다.

  2. 02 · 의존성

    캐시 복원 및 의존성 설치

    입력: Package.resolved, Podfile.lock 또는 기타 잠금 파일. 캐시 키에는 최소한 의존성 잠금 요약, Xcode 버전 및 대상 아키텍처가 포함되어야 합니다.

    실패 지점:잠금 파일 변경, 도구 체인과 캐시 불일치, 비공개 의존성 인증 정보 만료 또는 디스크 공간 부족입니다.

  3. 03 · 아카이브

    xcodebuild archive 실행

    입력: Workspace 또는 Project 경로, Scheme, Configuration, Destination 및 아카이브 경로. 먼저 도구 버전을 출력한 뒤 아카이브를 실행합니다.

    실패 지점:컴파일 오류, 테스트 실패, 대상 버전 비호환, DerivedData 오염 또는 빌드 스크립트의 로컬 절대 경로 의존입니다.

  4. 04 · 서명

    작업별 서명 자료 주입

    입력:최소 권한의 인증서, 프로비저닝 프로파일 및 필요한 환경 변수. 자료는 작업 시작 시 주입하고 종료 후 제거해야 합니다.

    실패 지점:인증서와 프로비저닝 프로파일 불일치, 잘못된 권한 범위, 유효 기간 문제 또는 여러 작업이 동일한 임시 키체인을 잘못 사용하는 경우입니다.

  5. 05 · 내보내기

    내보내기 및 파일 검증

    입력:아카이브 파일과 ExportOptions 구성. 내보낸 뒤 파일명, 크기, 체크섬 요약 및 생성 시간을 기록하고 디렉터리 존재 여부만 확인하지 않습니다.

    실패 지점:내보내기 방식과 서명 구성 충돌, 출력 디렉터리 권한 부족 또는 스크립트가 0이 아닌 종료 코드를 무시하는 경우입니다.

  6. 06 · 보관

    로그 및 산출물 집계

    출력:빌드 산출물, 아카이브 파일, 테스트 보고서, 빌드 로그, 커밋 해시 및 작업 번호. 업로드 성공 후 작업 디렉터리를 정리합니다.

    실패 지점:업로드 중단, 산출물 이름 충돌, 로그에 민감한 필드 포함 또는 결과 확인 전에 정리가 실행되는 경우입니다.

빌드 팜 오케스트레이션

여러 저장소가 큐를 공유하되, 통제되지 않은 작업 디렉터리와 서명 자료는 공유하지 않습니다.

빌드 팜의 핵심은 작업을 동시에 실행하는 것이 아니라 큐, 노드 태그, 캐시 경계와 결과 반환을 모두 설명 가능하게 만드는 것입니다. 단일 MiniDebug M4는 통제된 실행 채널 하나를 맡기에 적합하며, 더 많은 동시 작업은 서로 다른 주문에 해당하는 물리 노드에 배정해야 합니다.

빌드 팜 스케줄링 예시

저장소·작업·노드 배정 순서

작업 1개 = 작업 디렉터리 1개
mobile-app release / archive M4 노드 배정
shared-sdk main / test 아카이브 작업 종료 대기
demo-client feature / build 우선순위에 따라 큐에 배치
  • 큐 등록:저장소, 커밋, 우선순위, 예상 시간 제한 및 필요한 태그를 저장합니다.
  • 매칭: Xcode 버전, 노드 상태, 작업 유형과 사용 현황에 따라 실행 노드를 선택합니다.
  • 실행:독립 작업 디렉터리를 만들고 캐시 키에 맞는 의존성을 복원한 뒤 이번 작업에 필요한 자료를 주입합니다.
  • 마무리:상태, 로그, 산출물과 소요 시간을 반환하고 업로드를 확인한 뒤 임시 디렉터리와 임시 인증 정보를 삭제합니다.
캐시 경계

다운로드 결과는 재사용하고 알 수 없는 상태는 재사용하지 않습니다.

의존성 캐시는 잠금 파일 요약, Xcode 버전 및 아키텍처를 기준으로 재사용할 수 있습니다. DerivedData, 임시 키체인, 내보내기 디렉터리와 커밋되지 않은 변경 사항은 저장소 간에 직접 재사용하지 않아야 합니다.

결과 요약

큐 상태와 빌드 결과를 분리하세요.

대기, 실행, 업로드 및 완료는 스케줄링 상태이고, 컴파일 성공·테스트 실패·서명 실패는 작업 결과입니다. 둘을 분리해 기록해야 용량 문제인지 프로젝트 문제인지 판단할 수 있습니다.

GitHub Actions 자체 호스팅 Runner

먼저 태그와 정리 정책을 설계한 뒤 워크플로를 Mac 노드에 연결하세요.

Runner 등록은 연결 절차일 뿐입니다. 안정성을 좌우하는 것은 정확한 태그, 통제된 단일 머신 동시성, 작업 종료 후 정리, 그리고 실패 로그를 해당 워크플로 실행 기록으로 되돌릴 수 있는지 여부입니다.

태그 계획

태그는 안정적인 기능만 설명해야 합니다.

시스템 태그를 유지하고 장기적으로 관리 가능한 기능 태그를 추가하는 것이 좋습니다. 예: macosarm64xcode-currentsigning-ready。임시 프로젝트명이나 단기 브랜치를 노드 태그에 넣지 마세요.

runs-on:
  - self-hosted
  - macos
  - arm64
  - xcode-current
등록 및 권한

전용 실행 계정으로 작업을 처리하세요.

등록 전에 Runner의 소속 범위, 저장소 접근 경계와 작업 디렉터리를 확인하세요. 실행 계정에는 빌드 실행에 필요한 권한만 부여하고, 일상적인 원격 작업과 공유하지 않으며, 장기 인증 정보를 스크립트 파일에 직접 작성하지 않습니다.

  • Runner 이름, 노드 및 용도 기록
  • 호출 가능한 저장소 또는 조직 범위 제한
  • 작업 디렉터리와 캐시 디렉터리 권한 확인
  • 등록 후 최소 빌드 검증 실행
정리 및 동시성

단일 채널로 실행하고 작업 사이를 명시적으로 정리하세요.

동일한 작업 디렉터리에서 두 개의 쓰기 작업을 동시에 실행하지 마세요. 작업 시작 전에 잔류 프로세스와 디스크 공간을 확인하고, 종료 후 소스 복사본, 임시 내보내기 파일, 임시 키체인과 프로젝트 환경 변수를 정리합니다.

동시성이 필요하면 서로 다른 작업을 서로 다른 물리 노드에 배정하세요. 같은 디렉터리에서 서명, 아카이브와 정리 단계가 서로 덮어쓰게 하지 마세요.

실패 결과 반환

빌드가 실패해도 진단 자료는 업로드해야 합니다.

실패 상황에서도 로그 수집 단계가 계속 실행되도록 하며, 최소한 xcodebuild 출력, 테스트 결과, 디스크 여유 공간, 도구 버전과 작업 식별자를 반환합니다. 업로드 전에 토큰, 개인 키 내용, 인증서 비밀번호와 저장소 민감 변수를 제거하세요.

Runner 오프라인, 작업 시간 초과, 스크립트 종료 및 산출물 업로드 실패를 구분하여 모든 문제가 '빌드 실패'로만 표시되지 않게 하세요.

개인 개발자 릴리스 흐름

그래픽 인터페이스는 소수의 수동 확인을 처리하고, 명령줄은 재현 가능한 빌드와 아카이브를 담당합니다.

개인 개발자는 보통 모든 단계를 한 번에 자동화할 필요가 없습니다. 그래픽 작업과 명령줄 작업의 인계 지점을 명확히 정해 수정, 검증, 아카이브와 TestFlight 전 산출물 준비를 모두 되돌릴 수 있게 하는 편이 안정적입니다.

로컬 개발 환경

수정 및 커밋

코드 수정, 기본 테스트와 커밋을 완료하고 고정 브랜치를 푸시한 뒤 검증할 기기 조건과 예상 결과를 기록합니다.

출력: 커밋 해시, 변경 사항 설명, 테스트 범위
원격 그래픽 인터페이스

Xcode 수동 확인

Scheme, 대상 버전과 프로젝트 설정을 확인하고 시각적 판단이 필요한 경고를 처리한 뒤 서명 구성이 이번 릴리스에 필요한 범위를 가리키는지 확인합니다.

출력: 확인된 프로젝트 상태 및 릴리스 매개변수
명령줄 작업

아카이브 및 내보내기

스크립트로 아카이브, 내보내기와 검증을 실행하고 전체 로그를 보존합니다. 문제가 발생하면 실패한 머신에서 알 수 없는 상태를 반복 수동 수정하지 말고 해당 입력으로 돌아갑니다.

출력: 아카이브 파일, 내보내기 패키지, 체크섬 요약
권장 인계 규칙

그래픽 인터페이스는 반드시 사람이 판단해야 하는 구성과 확인만 담당하고, 아카이브·내보내기·재시도·산출물 이름 지정은 스크립트에 맡깁니다. 수동 조정 후에는 프로젝트 변경 사항을 커밋하거나 차이를 기록해 다음 빌드를 재현할 수 있게 하세요.

AI 추론 실험

Apple Silicon에서 모델 버전을 비교하고 단 한 번의 실행 결과만 기록하지 마세요.

MiniDebug M4는 M4, 16GB RAM 및 256GB SSD로 구성됩니다. 실험에서는 먼저 모델과 데이터가 해당 리소스 범위에 적합한지 확인한 뒤 로딩, 메모리, 지속 추론과 출력 품질을 기록하여 서로 다른 매개변수의 결과가 섞이지 않게 해야 합니다.

01 · 준비

모델 및 실행 환경 고정

모델 형식, 양자화 버전, 런타임 버전, 커밋 해시, 입력 샘플과 무작위 매개변수를 기록합니다. 모델 파일은 체크섬 요약으로 식별해 이름은 같지만 내용이 다른 파일을 방지하세요.

필수 기록
모델 버전 및 양자화 방식
리소스 범위
16GB RAM / 256GB SSD
02 · 벤치마크

콜드 스타트와 지속 추론을 분리 측정

첫 로딩에는 모델 읽기와 초기화가 포함되므로 안정 실행 단계와 합산할 수 없습니다. 각 테스트 그룹은 동일한 입력 길이, 배치 크기, 반복 횟수와 샘플링 매개변수를 사용합니다.

시간 지표
로딩 시간, 첫 출력, 총 소요 시간
리소스 지표
최대 메모리 및 안정 상태 메모리
03 · 비교

속도·메모리·결과 편차 비교

양자화 버전은 속도만 비교해서는 안 됩니다. 동일 입력의 출력, 작업 품질 평가, 오류 샘플과 환경 정보도 저장한 뒤 기계 판독 가능한 결과와 사람의 결론을 함께 내보내야 합니다.

비교 항목
지연 시간, 처리량, 메모리, 출력 품질
실험 출력
CSV, 로그, 구성 및 결론
benchmark-run.json
{
  "machine": "MiniDebug M4 / M4 / 16GB / 256GB",
  "model_variant": "project-defined",
  "input_set": "fixed-evaluation-set",
  "measurements": [
    "load_time",
    "first_output_time",
    "total_time",
    "peak_memory"
  ],
  "artifacts": ["result.csv", "runtime.log", "notes.md"]
}
오디오·비디오 워크플로

대용량 파일 동기화, 원격 편집과 일괄 내보내기를 독립 단계로 나누세요.

오디오·비디오 작업의 병목은 소재 전송, 플러그인 호환성, 원격 화면, 디스크 용량 또는 내보내기 설정에서 발생할 수 있습니다. 이 단계를 분리하면 연결 지연을 호스트 계산 문제로 잘못 판단하는 일을 피할 수 있습니다.

단계 A

프로젝트 및 소재 동기화

먼저 소재 목록을 생성하고 파일 수, 전체 크기, 디렉터리 구조와 체크섬 요약을 기록합니다. 현재 단계에 필요한 프록시 파일이나 원본 소재만 동기화한 뒤 누락 항목을 확인합니다.

확인 지점:프로젝트 경로가 로컬 드라이브 문자에 의존하지 않고 미디어 참조를 다시 지정할 수 있어야 하며, 기본 256GB SSD에 프로젝트 캐시와 내보내기 공간을 남겨야 합니다.

단계 B

원격으로 프로젝트 열기 및 확인

그래픽 연결로 프로젝트를 열고 글꼴, 플러그인, 미디어 링크, 샘플링 설정과 출력 대상을 확인합니다. 네트워크가 불안정하면 프로젝트 출력 설정은 바꾸지 말고 원격 화질과 해상도를 먼저 낮추세요.

확인 지점:원격 미리보기 품질과 최종 파일 품질을 구분하세요. 플러그인이 없으면 불완전한 결과 생성을 막기 위해 일괄 작업을 먼저 중지합니다.

단계 C

일괄 내보내기 실행

내보내기 프리셋, 파일 이름과 대상 디렉터리를 고정한 뒤 작업 목록에 따라 실행합니다. 각 작업의 종료 상태, 소요 시간, 출력 크기와 오류 정보를 저장합니다.

확인 지점:장시간 작업을 시작하기 전에 디스크 여유 공간을 확인하세요. 병렬 작업 수는 메모리, 소재 읽기와 인코딩 부하를 기준으로 단계적으로 검증해야 합니다.

단계 D

검수 및 산출물 반환

화면, 오디오 트랙, 재생 시간, 해상도와 파일 헤더 정보를 샘플 검사한 뒤 체크섬 요약을 생성합니다. 로컬에 완전히 수신된 것을 확인하면 클라우드 임시 파일을 정리합니다.

출력:최종 파일, 내보내기 로그, 실패 목록, 체크섬 요약 및 로컬 수신 기록

노드 선택 가이드

싱가포르, 일본(도쿄), 한국(서울), 홍콩, 미국 동부 중 데이터 경로에 맞춰 선택하세요.

노드는 팀 소재지만으로 결정하지 않습니다. 코드 저장소, 의존성 소스, 원격 작업자와 최종 전달 대상도 함께 고려해야 합니다. 아래 내용은 선택 방향이며 고정된 네트워크 결과를 보장하지 않습니다. 실제 연결 성능은 사용자의 로컬 네트워크와 지역 간 경로에 따라 달라집니다.

MiniDebug M4 5개 노드의 워크플로 선택 가이드
노드 우선 고려할 팀 위치 저장소 및 의존성 위치 일반적인 전달 방향 주문 전 확인
싱가포르 동남아시아 팀 또는 동남아시아 협업 구성원 저장소, 아티팩트 또는 의존성 서비스가 주로 동남아시아에 있을 때 우선 테스트 동남아시아 팀을 위한 일상 빌드, 원격 개발 및 결과 반환 저장소 가져오기, 의존성 다운로드 및 원격 그래픽 연결 테스트
일본(도쿄) 일본 및 인근 동아시아 팀 코드와 의존성 접근 경로가 주로 일본에 가까울 때 우선 테스트 일본 팀의 iOS 빌드, 서명 확인 및 원격 Xcode 작업 로컬에서 노드까지의 상호작용 안정성과 대용량 파일 업로드 확인
한국(서울) 한국 및 동북아 협업 팀 저장소와 내부 리소스 접근이 한국 방향에서 더 직접적일 때 고려 지속적 통합, 자체 호스팅 Runner 및 지역 내 산출물 배포 Runner 재연결, 의존성 확보 및 로그 업로드 확인
홍콩 중국 남부와 동남아시아 사이에서 협업하는 팀 코드, 소재와 작업자가 중국 남부 및 동남아시아에 분산된 경우 우선 비교 지역 간 개발 협업, 원격 그래픽 작업 및 소재 처리 사무실 네트워크와 가정 네트워크의 연결 경로를 각각 테스트
미국 동부 북미 동부 및 서유럽과 협업하는 팀 저장소, CI 컨트롤 플레인 또는 전달 시스템이 주로 북미 동부에 있을 때 고려 북미 업무 시간대의 빌드 큐, 결과 반환 및 협업 확인 저장소, 아티팩트 저장소와 원격 작업자까지 세 경로 테스트
워크플로 템플릿

최소 구조부터 시작한 뒤 프로젝트 버전, 인증서와 경로를 교체하세요.

아래 조각은 스크립트 구조를 구성하기 위한 예시이며 모든 프로젝트에 바로 사용할 수 있는 완성된 구성은 아닙니다. 저장소에 저장하기 전에 프로젝트 유형에 맞게 Workspace, Scheme, Xcode 버전, 내보내기 설정, 서명 자료, Runner 태그와 산출물 디렉터리를 확인하세요.

Shell

xcodebuild 아카이브 구조

archive.sh
set -euo pipefail

PROJECT_ROOT="/path/to/project"
WORKSPACE="$PROJECT_ROOT/Example.xcworkspace"
SCHEME="Example"
ARCHIVE_PATH="$PROJECT_ROOT/output/Example.xcarchive"

xcodebuild -version
xcodebuild \
  -workspace "$WORKSPACE" \
  -scheme "$SCHEME" \
  -configuration Release \
  -destination "generic/platform=iOS" \
  -archivePath "$ARCHIVE_PATH" \
  clean archive
수정 항목

프로젝트 경로, Workspace, Scheme, Configuration, Destination 및 아카이브 디렉터리를 교체하세요. 스크립트는 0이 아닌 종료 코드를 보존하고 실행 전에 필요한 Xcode 버전을 확인해야 합니다.

Fastlane

빌드 및 산출물 기록 구조

Fastfile
lane :build_release do
  setup_ci

  build_app(
    workspace: "Example.xcworkspace",
    scheme: "Example",
    configuration: "Release",
    output_directory: "output"
  )

  sh("shasum -a 256 output/*")
end
수정 항목

프로젝트에 맞게 Workspace, Scheme, 출력 디렉터리와 내보내기 설정을 교체하세요. 서명 자료는 통제된 변수 또는 작업별 주입으로 제공하고 Fastfile에 직접 작성하지 마세요.

CI

자체 호스팅 Runner 작업 구조

build.yml
name: ios-build

on:
  workflow_dispatch:

jobs:
  archive:
    runs-on:
      - self-hosted
      - macos
      - arm64
      - xcode-current
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build
        run: ./scripts/archive.sh

      - name: Collect diagnostics
        if: always()
        run: ./scripts/collect-diagnostics.sh
수정 항목

실제 Runner 태그, 저장소 정책과 스크립트 경로에 맞게 조정하세요. 사용하는 액션 버전을 고정하고 작업 시간 제한을 설정하며 빌드 실패 시에도 진단 수집이 계속 실행되게 하세요.

기존 흐름 검증 시작

MiniDebug M4 한 대를 선택해 최소 빌드 사이클부터 완성하세요.

고정 커밋, 단일 작업 실행, 로그 아카이브와 산출물 검증부터 시작한 뒤 캐시, 서명 주입과 큐 스케줄링을 단계적으로 추가하세요. 일·주·월·분기 단위 대여를 지원하며 주문은 USD로 결제됩니다.

결제는 USDT-TRC20 및 Visa / Mastercard / Amex(Stripe)를 지원하며, 실제 이용 가능한 결제 게이트웨이는 관리 콘솔의 응답을 기준으로 합니다.