Git LFS 다운로드가 병목인데 Mac부터 늘리고 있나요? 먼저 Git 전송, LFS 객체, 작업 공간 복원, 실제 빌드 시간을 분리해 측정해야 합니다. 네트워크 대기가 대부분이면 데이터 경로와 캐시를 고치고, 그 뒤에도 Xcode 빌드 단계가 계속 포화될 때만 고정 또는 탄력형 원격 Mac을 확장하는 것이 빠른 해결책입니다.
이 글은 대형 iOS 저장소를 운영하며 검출 시간과 Mac CI 용량을 함께 관리하는 기업 IT 담당자를 위한 글입니다. 특히 Mac 빌드기를 늘릴지, 이전할지, 탄력형 임대를 시험할지 판단해야 하는 플랫폼 팀과 보안 팀에 적합합니다.
먼저 시간표를 쪼개야 하는 이유
같은 작업의 전체 시간이 늘었다고 해서 Mac 컴파일 성능이 떨어졌다고 볼 수는 없습니다. checkout 단계 안에는 서로 다른 작업이 섞여 있습니다.
- 일반 Git 객체 전송
- LFS 포인터 확인
- 실제 LFS 객체 다운로드
- 작업 공간 파일 복원
- 의존성 복원
- Xcode 빌드와 서명
Git LFS는 저장소에 작은 포인터를 두고 실제 대형 파일을 별도 객체로 관리합니다. 따라서 Git fetch가 성공했다는 사실만으로 작업 공간에 필요한 파일이 모두 준비됐다고 판단하면 안 됩니다. Git LFS의 객체와 포인터 동작은 공식 명령 설명에서 확인할 수 있습니다.
첫 번째 기준은 간단합니다. 네트워크 대기와 객체 다운로드가 전체 checkout 시간의 대부분이면 Mac을 추가하지 않습니다. 반대로 검출이 끝난 뒤 Xcode 빌드에서 CPU 또는 메모리가 지속적으로 포화되고 대기열까지 늘어나면 Mac 용량을 검토합니다.
같은 기준 작업으로 냉시작과 반복 실행을 나누기
CI 로그에 다음 항목을 별도 기록합니다.
- 저장소 초기화부터 일반 Git 전송 종료까지의 시간
- LFS 객체 다운로드 시작과 종료 시간
- 작업 공간 복원 완료 시간
- 의존성 캐시 복원 시간
- Xcode 빌드 시작부터 산출물 생성까지의 시간
- 대기열 진입부터 실제 Mac 할당까지의 시간
동일한 커밋과 동일한 작업을 냉시작과 반복 실행으로 각각 수행합니다. 냉시작은 캐시가 없는 상태를 뜻하고, 반복 실행은 이전 객체와 의존성이 남아 있는 상태를 뜻합니다. 이 두 결과를 섞으면 캐시 효과와 Mac 성능을 구분할 수 없습니다.
Git LFS의 전송 기록은 git lfs fetch와 관련 로그로 확인합니다. fetch는 객체를 가져오는 작업이며 작업 공간 갱신과 동일하지 않으므로, 명령 동작은 Git LFS fetch 공식 문서와 대조해야 합니다.
주의: checkout 구성 요소가 LFS를 자동으로 가져오는지, 부분 검출을 적용하는지, 인증 정보를 얼마나 오래 남기는지는 사용 중인 버전과 설정에 따라 달라질 수 있습니다. 실제 CI 이미지에서 재현한 결과를 기준으로 승인해야 합니다.
전송 범위가 매번 치르는 비용을 결정합니다
대형 저장소에서 가장 먼저 볼 지표는 총 저장소 크기가 아닙니다. 현재 작업이 실제로 내려받는 객체의 범위입니다.
전체 검출은 설정이 단순하지만 PR 검증마다 관계없는 이미지, 동영상, 테스트 자료까지 확인할 수 있습니다. 반대로 경로 기준 필터링은 전송량을 줄일 수 있지만 작업별 의존 관계를 정확히 정의해야 합니다. Git clone의 깊이와 분기 범위는 Git 공식 clone 문서에서 확인할 수 있습니다.
| 선택 방식 | 줄일 수 있는 비용 | 운영상 위험 | 적합한 상황 |
|---|---|---|---|
| 전체 검출 | 설정 복잡도 | 관계없는 LFS 객체까지 반복 다운로드 | 릴리스나 재현성 검사가 모든 자원을 요구할 때 |
| 경로 기준 include | 네트워크 전송과 디스크 사용 | 누락된 자원으로 빌드가 실패할 수 있음 | PR 검증과 자원 경로가 명확할 때 |
| 경로 기준 exclude | 명시한 대형 자원 전송 | 새 경로가 추가될 때 정책이 낡을 수 있음 | 특정 테스트 자원을 항상 제외할 때 |
| 작업별 자원 집합 | 중복 다운로드와 작업 시간 | 파이프라인 정의와 검증 부담 | 앱, 테스트, 미디어 작업을 분리할 때 |
CI에서 git lfs fetch --include 또는 --exclude를 사용할 때는 명령 성공만 확인하면 부족합니다. 실제 빌드가 읽는 경로를 목록으로 만들고, 필터링 후에도 모든 파일이 존재하는지 검증해야 합니다. LFS 설치와 초기 설정은 공식 install 안내를 기준으로 이미지에 고정합니다.
포인터 파일과 실제 파일을 구별하기
작업 공간에서 파일이 존재하는 것처럼 보여도 내용이 LFS 포인터일 수 있습니다. 따라서 검증 작업에는 다음 조건을 넣는 편이 안전합니다.
- 빌드가 요구하는 LFS 경로 목록을 별도로 관리합니다.
- 각 경로가 포인터가 아닌 실제 파일인지 검사합니다.
- 파일 크기만 보지 말고 체크섬 또는 프로젝트의 재현 가능한 테스트로 확인합니다.
- 누락 시 캐시 적중으로 기록하지 않고 작업을 실패시킵니다.
이 과정을 생략하면 빠른 checkout처럼 보이지만 최종 앱에 리소스가 빠지는 문제가 늦게 발견될 수 있습니다.
캐시 적중률보다 캐시의 경계를 먼저 봅니다
장기 실행 Mac은 LFS 객체를 재사용할 가능성이 있습니다. 그러나 캐시가 존재한다는 사실만으로 효과가 입증되지는 않습니다. 다음 기록이 필요합니다.
- 작업별 LFS 다운로드 바이트
- 이전 작업과 겹치는 객체 비율
- 캐시 적중 후 작업 공간 복원 시간
- 캐시 디렉터리의 증가 추세
- 정리 후 첫 실행과 반복 실행의 차이
- 캐시 오류로 재다운로드한 횟수
일회성 환경은 작업마다 객체를 다시 받을 가능성이 높습니다. 장기 온라인 전용 Mac은 신뢰할 수 있는 프로젝트에 한해 객체를 재사용할 수 있습니다. 공유 작업 공간은 가장 빠를 수 있지만 이전 작업의 파일과 인증 정보가 남을 위험이 큽니다.
| 운영 방식 | 캐시 재사용 | 작업 공간 격리 | 관리 포인트 | 권장 용도 |
|---|---|---|---|---|
| 매번 새 환경 | 낮음 | 높음 | 냉시작 전송 비용 | 비신뢰 코드와 일회성 검증 |
| 장기 전용 Mac | 높음 | 프로젝트별 관리 필요 | 디스크 한도와 정리 | 신뢰된 저장소의 반복 빌드 |
| 공유 작업 공간 | 예측 어려움 | 낮음 | 잔여 파일과 인증 정보 | 제한된 내부 실험 |
| 혼합 운영 | 작업별 조정 | 정책으로 통제 | 신뢰 등급과 라우팅 | 생산 빌드와 PR 검증 병행 |
캐시를 프로젝트별로 분리하고, 신뢰 등급이 다른 저장소가 같은 객체 영역을 공유하지 않도록 합니다. 작업 공간은 캐시와 별도로 초기화합니다. 캐시 용량이 임계값을 넘으면 오래된 객체를 정리하되, 정리 직후 냉시작 비용을 다시 측정해야 합니다.
GitHub Actions를 사용한다면 캐시 키와 복원 범위가 다른 프로젝트에 예상치 못한 파일을 제공하지 않는지 확인해야 합니다. 공식 의존성 캐시 보안 안내는 캐시가 민감한 정보나 신뢰할 수 없는 작업과 섞이지 않도록 검토할 기준을 제공합니다.
보안과 재현성을 속도보다 먼저 승인합니다
Git LFS 가속에는 인증 정보가 따라옵니다. 저장소 토큰, LFS 다운로드 권한, SSH 키, 서명용 Keychain은 같은 등급으로 취급하면 안 됩니다.
다운로드 권한이 있다고 해서 코드 서명 권한까지 같은 노드에 둘 필요는 없습니다. 특히 비신뢰 브랜치가 생산 릴리스 노드의 장기 토큰이나 작업 공간을 물려받으면 캐시 가속이 보안 경계가 됩니다.
다음 정책을 분리해 적용합니다.
- 프로젝트별 LFS 캐시 분리
- PR과 릴리스 작업의 Mac 노드 분리
- 비신뢰 브랜치의 생산 인증서 접근 차단
- 작업 종료 후 작업 공간과 임시 인증 정보 정리
- 서명 노드에서 디버그와 검증 작업을 제한
- 토큰의 보관 기간과 사용 범위 기록
자체 관리 Runner를 외부 코드에 개방할 때의 위험은 공식 자체 관리 Runner 보안 문서에서 확인할 수 있습니다. checkout 동작과 인증 정보 처리도 checkout 프로젝트의 현재 문서를 사용 중인 버전과 함께 검토해야 합니다.
재현 가능한 검증 작업을 별도로 둡니다
가속 설정을 적용한 뒤에는 정상 빌드 한 번만 통과시켜서는 안 됩니다. 다음 작업을 냉시작과 열캐시 상태에서 모두 실행합니다.
- LFS 파일 존재 검사
- 주요 리소스 체크섬 검사
- 의존성 복원 검사
- Xcode 빌드
- 테스트와 아카이브 생성
- 서명 단계의 권한 검사
하나라도 누락되면 캐시 적중률이 높아도 승인하지 않습니다. 빠른 파이프라인보다 동일한 입력에서 같은 산출물을 만드는 능력이 우선입니다.
Mac 확장은 실제 처리량과 대기열로 판단합니다
Mac을 몇 대 보유했는지보다 중요한 것은 단위 시간에 처리할 수 있는 실제 작업량입니다. 용량 판단에는 다음 변수를 넣습니다.
- 검출을 제외한 유효 Xcode 빌드 시간
- 시간대별 작업 도착량
- 평균 및 최대 대기 시간
- 작업 실패와 재시도 횟수
- 노드 장애 시 대체 노드 확보 여부
- 서명 작업과 일반 검증 작업의 동시성
네트워크를 늘리는 선택은 LFS 객체 전송이 병목일 때 효과가 있습니다. 캐시 노드를 추가하는 선택은 반복 객체가 많을 때 유효합니다. 실제 Mac 빌드 노드를 추가하는 선택은 검출 이후 CPU, 메모리, Xcode 또는 서명 단계가 병목일 때 필요합니다. 서로 다른 문제를 같은 확장으로 해결할 수는 없습니다.
다음 조건으로 운영 방식을 나눌 수 있습니다.
고정 Mac 풀
신뢰된 릴리스 작업이 일정하게 발생하고, 서명 인증서와 Keychain을 엄격하게 통제해야 한다면 전용 고정 풀이 적합합니다. 대신 유휴 시간에도 점유 비용과 패치, 재부팅, 장애 대응 부담이 남습니다.
탄력형 원격 Mac 풀
PR 검증이나 특정 시간대의 작업 급증이 중심이면 원격 Mac을 탄력적으로 추가하는 방식을 검토할 수 있습니다. 단, 냉시작 시간, LFS 캐시 준비 시간, 네트워크 경로, 노드 반납 후 데이터 삭제를 실제 작업으로 확인해야 합니다. 필요하다면 KVMNODE의 원격 Mac 환경을 같은 저장소와 같은 파이프라인으로 시험해 볼 수 있습니다.
혼합 방식
생산 서명은 고정된 신뢰 노드에 남기고, 비서명 검증과 피크 시간대 빌드는 탄력형 원격 Mac으로 분리합니다. 기업 환경에서는 이 방식이 보안 경계와 대기열을 함께 관리하기 쉽습니다. 다만 캐시와 인증서가 자동으로 이동한다고 가정하면 안 됩니다.
승인 전에 이 표를 채우십시오
최적화나 확장을 승인할 때는 주장보다 증거가 필요합니다. 아래 표의 각 항목에 실제 로그 위치와 실패 시 조치를 기록합니다.
| 검증 항목 | 기록할 지표 | 통과 조건의 예 | 실패 시 조치 |
|---|---|---|---|
| 냉시작 | Git, LFS, 복원, 빌드별 시간 | 단계별 병목이 분리됨 | 로그 계측 보강 |
| 열캐시 | 다운로드 바이트와 복원 시간 | 재사용 효과가 기록됨 | 캐시 정책 재설계 |
| 자원 완전성 | 포인터 여부, 체크섬, 테스트 | 필요한 파일이 모두 실제 내용임 | 필터 범위 수정 |
| 인증 격리 | 토큰, SSH 키, Keychain 접근 | 작업 등급별 권한 분리 | 노드와 자격 증명 분리 |
| 디스크 회수 | 캐시 증가와 정리 결과 | 한도 초과 시 예측 가능한 정리 | 캐시 용량 정책 변경 |
| 대기열 | 작업 도착량과 할당 대기 | 피크 구간의 지연 원인 확인 | Mac 또는 캐시 용량 조정 |
| 장애 복구 | 노드 손실 후 재시도와 대체 | 작업이 안전하게 재실행됨 | 고정 노드와 탄력 노드 혼합 |
TCO는 임의의 가격으로 채우지 말고 다음 변수로 계산합니다.
TCO = 네트워크 전송 비용 + 저장 비용 + Mac 점유 시간 비용 + 운영 인력 비용 + 장애 영향 비용
구매와 임대의 비교에서도 같은 변수와 같은 기준 작업을 사용해야 합니다. 예를 들어 장비 가격만 비교하면 패치, 장애 교체, 유휴 시간, 피크 대응 비용이 빠집니다. 반대로 임대 비용만 보면 캐시 준비와 데이터 전송 비용을 놓칠 수 있습니다. Mac mini 렌탈 가격 정보는 실제 검토 시 기간과 작업량을 함께 대입해야 합니다.
최종 결론은 세 가지 중 하나입니다
- Git LFS만 최적화: 전송 범위와 캐시가 병목이고 Xcode 빌드는 여유가 있을 때 선택합니다.
- Mac 용량 확장: LFS와 작업 공간 단계를 정리한 뒤에도 실제 빌드와 대기열이 포화될 때 선택합니다.
- 고정 노드와 탄력 노드 병행: 생산 서명은 고정 노드에 두고, 검증과 피크 작업을 원격 Mac으로 분산할 때 선택합니다.
자주 묻는 운영 판단
FAQ는 위의 측정 결과를 실제 승인 문서로 옮길 때 참고하십시오. 저장소와 checkout 구성 요소의 버전이 바뀌면 같은 검사를 다시 실행해야 합니다.
현재 환경과 원격 Mac을 비교할 때의 기준
현재 환경이 개발자별 Mac에 의존하면 장비 유휴 시간이 생기고, 공용 Mac 한 대에 의존하면 작업 대기와 권한 충돌이 커집니다. 사내 고정 Mac만 운영할 때는 피크를 위해 미리 용량을 확보해야 하며, 장애 교체와 패치 시간도 IT 팀이 부담합니다.
이런 구조가 항상 나쁜 것은 아닙니다. 장기간 일정한 고부하를 처리하거나 물리 장치와 직접 연결해야 한다면 직접 보유가 더 적합할 수 있습니다. 반대로 검증 작업이 특정 시간대에 몰리고, 같은 저장소로 빠르게 비교해야 하며, 초기 구매 없이 용량을 시험하려면 KVMNODE의 원격 Mac을 단기 PoC에 투입하는 편이 판단에 도움이 됩니다.
먼저 현재 파이프라인의 냉시작, 열캐시, 실제 빌드, 피크 대기열을 기록하십시오. 그 다음 동일한 저장소와 동일한 작업을 원격 Mac에서 실행해 전송량과 컴파일 시간이 어디에서 달라지는지 비교하십시오. 증거가 Mac 빌드 포화로 이어질 때만 고정 노드를 늘리고, 피크에만 문제가 생기면 탄력형 용량을 유지하는 방식이 합리적입니다.