Vercel Git LFS 빌드 속도 개선: 저장소 체크아웃 지연 확인 방법

Vercel Git LFS 개선 수치와 적용 범위

개선은 별도 작업 없이 자동 적용된다는 것이 공식 발표의 설명입니다. 2 vCPU 이하 환경에도 같은 수치가 보장된다고 읽거나, 54%를 최대 개선율로 바꾸면 안 됩니다. 발표는 LFS 프로젝트의 평균값을 설명합니다.

P90은 관측 시간의 90%가 그 값 이하였다는 뜻입니다. 모든 배포가 22% 빨라진다는 의미가 아니며, 일부 느린 사례와 평균이 다른 방향으로 움직일 수 있습니다. 개별 프로젝트는 같은 조건의 배포 표본으로 확인해야 합니다.

먼저 확인: 저장소가 Git LFS를 사용하나요?

git lfs version
git lfs ls-files
# 특정 파일 경로를 넣어 attributes 확인
git check-attr filter -- [asset-path]

ls-files는 LFS 관리 파일을 조사하는 명령입니다. 근거: Git LFS 공식 명령 문서 로컬에 Git LFS가 설치되지 않았으면 명령이 실패할 수 있습니다. 빈 결과와 도구 미설치를 구분하세요.

큰 파일이 있다는 사실과 Git LFS 관리 여부는 다릅니다. .gitattributes의 패턴과 실제 추적 파일을 대조하고, 배포에 필요한 이미지·영상·모델 등 바이너리가 LFS에 들어 있는지 확인하세요. 로컬 작업 폴더의 상태만으로 원격 LFS 객체가 정상 업로드됐다고 판단하지 않습니다.

Vercel 프로젝트의 Git LFS 설정 확인

프로젝트 Settings의 Git 설정에서 LFS 지원 상태를 확인합니다. 활성화하면 저장소에서 사용하는 LFS 객체를 가져오며, Git LFS를 켠 뒤에는 재배포가 필요합니다. 근거: Vercel Git 설정

자동 속도 개선과 프로젝트의 LFS 지원 활성화는 다른 문제입니다. LFS 자산이 필요한 앱에서 속도를 줄이려고 지원을 끄면 실제 파일 대신 포인터가 남거나 자산이 누락될 수 있습니다. 설정을 바꿀 때에는 결과 파일과 화면까지 확인해야 합니다.

체크아웃 지연과 앱 빌드 지연을 구분하는 방법

1. Vercel에서 대상 배포를 열고 커밋·환경·생성 시각을 기록합니다.
2. Build Logs와 표시되는 배포 단계 정보를 확인합니다.
3. 로그에 드러난 clone·checkout·파일 준비의 시작·완료 지점을 찾습니다.
4. 의존성 설치, 프레임워크 빌드, 이후 배포 작업의 구간을 따로 기록합니다.
5. 단계 경계가 명확하지 않으면 전체 시간을 체크아웃 시간으로 대체하지 않고 미확인으로 남깁니다.

Build Logs 접근 방법은 Vercel 공식 문서를 참고하세요. 실제 로그 표시와 타임스탬프의 상세 수준은 배포에 따라 확인해야 합니다. 이 글에서 특정 로그 문자열이나 파일 준비 전용 대시보드 항목이 항상 존재한다고 가정하지 않습니다.

가상 계산: 파일 준비가 절반이 돼도 전체는 다릅니다

가상의 배포에서 파일 준비 30초, 나머지 설치·빌드·배포 150초라면 합계는 180초입니다. 파일 준비만 15초로 줄고 나머지가 같으면 총 165초, 전체 절약은 약 8.3%입니다. 이 숫자는 원리를 설명하는 예시이며 Vercel 공식 54% 관측이나 이 프로젝트의 실측을 적용한 결과가 아닙니다.

전체 시간이 그대로여도 파일 준비는 개선되고 앱 빌드가 느려졌을 수 있습니다. 반대로 캐시가 잘 맞아 전체 시간이 줄어도 체크아웃 효과만으로 설명할 수 없습니다. 단계별 기록이 있어야 변경 원인을 좁힐 수 있습니다.

전후 비교에서 맞춰야 할 조건

몇 차례의 비교만으로 발표의 P90을 재현했다고 주장하지 마세요. 동일 조건으로 수집한 표본 수와 측정 경계를 함께 적고, 평균·중앙값·느린 사례를 구분해 관찰하는 편이 좋습니다. 이미 적용된 서버 측 개선을 로컬 설정으로 켜고 끄는 대조 실험처럼 취급해서도 안 됩니다.

파일 준비가 계속 느릴 때 점검할 사항

1. LFS 자산 누락: 원격 객체 존재·접근 권한·제공자 오류를 확인합니다.
2. 불필요한 대형 자산: 배포에 필요한 파일인지 서비스 담당자와 검토합니다.
3. 변경 빈도·범위: 매 배포마다 큰 객체가 바뀌는지 기록합니다.
4. 모노레포: 앱 빌드 범위와 저장소 파일 준비 범위를 동일하다고 가정하지 않습니다.
5. 지원 문의: 배포 ID·커밋·발생 시각·환경·단계별 시간·오류를 정리합니다.

기록을 정리하기 전에 Git 이력을 강제로 재작성하거나 LFS 추적을 해제할 필요는 없습니다. 자산을 외부 저장소·CDN으로 옮기는 방안도 다운로드 시점, 인증, 가용성, 비용이 바뀌므로 단순한 속도 설정으로 취급하지 마세요.

복사해서 사용할 배포 진단 기록

배포 ID / 커밋 SHA / 시각:
환경 / 빌드 머신·vCPU / 리전:
LFS 지원 여부 / 필요한 LFS 파일:
파일 준비 시작·완료 / 측정 근거:
설치 시간 / 앱 빌드 시간 / 기타 시간:
캐시·재배포 조건 / 오류·재시도:
비교 표본 / 판단 / 다음 확인사항:

파일 준비·전체 시간 비교 도구 다운로드

로그에서 직접 확인한 구간 시간을 입력하면 전후 감소율을 계산하는 작은 도구를 제공합니다. Vercel 로그 파서나 성능 측정기는 아니며, 입력한 숫자의 산술 계산만 수행합니다.

• 시간 비교 도구 compare.mjs
• 가상 측정 입력 measurements.example.json

node compare.mjs measurements.example.json

두 파일을 같은 폴더에 저장한 뒤 실행하세요. 예시의 before·after는 파일 준비 30→15초, 나머지 150→150초로 구성돼 있습니다. 실제 도구 실행에서 파일 준비 50%, 전체 8.33% 감소가 계산되는 것을 확인했습니다. 입력값은 가상이므로 실제 배포 개선의 증거는 아닙니다.

prepareSeconds에는 파일 준비 구간, otherSeconds에는 측정한 나머지 구간 합계를 입력합니다. before·after의 측정 경계가 같아야 합니다. 음수 감소율은 느려졌다는 뜻이며, 기준값이 0이면 비율을 정의할 수 없어 null을 반환합니다. 준비 단계가 로그에 드러나지 않으면 추정 숫자로 채워 넣지 마세요.

자주 묻는 질문

속도 개선을 켜는 설정이 있나요?

발표는 자동 적용이라고 안내합니다. 프로젝트의 LFS 지원 설정과 자동 최적화는 구분하세요.

모든 빌드가 54% 빨라지나요?

아닙니다. 발표 수치는 2 vCPU 초과 머신에서 LFS 프로젝트의 파일 준비 평균입니다. 전체 배포 시간과 다릅니다.

로컬 git clone 시간을 재면 Vercel 효과를 알 수 있나요?

로컬 네트워크·캐시·인증·실행 환경이 다릅니다. 로컬 결과는 자산 조사에 참고하고 Vercel 배포의 단계별 시간과 동일시하지 마세요.

관련 Vercel 운영 안내

• Vercel 마이크로프론트엔드 방화벽 요청 과금
• Vercel CLI 도메인 검색·구매 승인