증상 → 대형 파일을 받았는데 프로젝트에서 열리지 않습니다. 빠른 해결 → Git LFS와 원격 Mac을 함께 쓰되, 저장소 초기화부터 인증·파일 확인·용량 점검·이동 검증까지 순서대로 진행하세요.
적용 조건 → 모델, 디자인 소재, 바이너리 의존성처럼 Git LFS로 관리할 파일이 있고 여행 중에도 macOS 환경이 필요한 경우에 적합합니다.
독립 개발자: 여행 중 모델·소재·바이너리가 포함된 저장소를 관리해야 하는 분에게 맞습니다.
원격 디자인·개발자: iPad나 가벼운 노트북으로 원격 Mac에 접속해 큰 파일 프로젝트를 이어가려는 분을 위한 내용입니다.
기술 프리랜서: 도시를 옮기거나 다른 기기로 작업을 넘길 때도 프로젝트를 계속 전달해야 하는 분에게 유용합니다.
Git LFS와 원격 Mac이 필요한 기준
Git LFS는 대용량 파일을 Git 저장소의 일반 이력에 그대로 쌓는 대신, 저장소에 파일 포인터를 두고 실제 내용을 별도로 주고받는 방식입니다. 따라서 원격 Mac에서 사용할 수 있지만, 코드 저장소 로그인에 성공했다고 실제 LFS 파일까지 내려받았다는 뜻은 아닙니다. Git LFS 공식 설치 안내와 서비스 탐색 방식 설명을 함께 확인하세요.
먼저 큰 저장소의 원인을 나눠 보세요. 소재나 모델 파일의 버전 이력을 관리하려는 경우에는 Git LFS가 맞을 수 있습니다. 반면 빌드 결과물이나 다시 만들 수 있는 캐시가 커진 문제라면, 해당 파일이 저장소에 들어가지 않도록 규칙을 손보는 편이 나을 수 있습니다. Git LFS는 버전 파일을 관리하는 방법이지, 프로젝트 전체를 독립적으로 복구하는 백업은 아닙니다.
플랫폼별 업로드 제한과 LFS 저장 정책은 다를 수 있습니다. 파일을 추적하기 전에 GitHub의 일반 파일 크기 안내와 Git LFS 제한 안내를 확인하고, 사용하는 저장소의 현재 정책과 대조하세요.
먼저 작업 방식을 고르는 조건
아래 조건에 따라 전체 파일을 받을지, 작업에 필요한 파일만 받을지 정하세요.
- 지금 바로 저장소의 모든 LFS 파일을 열어야 한다면 전체 수신을 선택합니다. 출발 전 복구 연습이나 파일 누락 여부를 확인할 때 적합합니다.
- 특정 폴더나 파일 유형만 처리한다면 필요한 항목만 받는 방식을 우선합니다. 현재 브랜치와 작업 파일을 확인하고 불필요한 다운로드를 줄이세요.
- 연결이 불안정하거나 원격 Mac의 여유 공간이 불확실하다면 수신 범위를 좁혀 시작합니다. 작업에 필요한 파일이 검증되기 전까지는 범위를 넓히지 않습니다.
- 파일 크기 문제와 저장소 정책이 원인이라면 원격 Mac을 추가하기 전에 플랫폼 제한부터 확인합니다. LFS 설정만으로 업로드 제한을 해결할 수 있다고 가정하지 마세요.
| 방식 | 적합한 상황 | 점검할 지표 | 주의할 점 |
|---|---|---|---|
| 전체 수신 | 프로젝트 전체를 열거나 복구 연습을 할 때 | 완료된 파일과 실제 사용 가능 공간 | 저장소의 모든 LFS 객체를 받을 필요가 있는지 확인합니다 |
| 필요한 항목만 수신 | 일부 소재나 모델만 작업할 때 | 대상 파일, 브랜치, 경로 범위 | 범위 밖 파일은 프로젝트에서 열리지 않을 수 있습니다 |
| 우선 코드만 준비 | 네트워크나 공간이 불확실할 때 | 포인터 상태와 다음 수신 대상 | 포인터 파일만으로 실제 소재가 준비된 것은 아닙니다 |
1단계: 테스트 작업 공간에서 규칙을 확인합니다
정식 저장소의 추적 규칙을 바로 바꾸지 말고, 테스트 브랜치나 별도 작업 사본에서 시작하세요. 현재 환경에 Git과 Git LFS가 설치되어 있는지 확인한 다음 공식 설치 절차에 따라 초기화합니다. 그 뒤 대상 파일 유형을 git lfs track으로 지정하고, .gitattributes 변경을 검토한 뒤 테스트 파일을 커밋하고 다시 받아 봅니다. Git LFS 추적 규칙 문서에는 추적 규칙과 파일 패턴의 동작이 설명되어 있습니다.
이 과정에서는 저장소 주소, 작업 디렉터리, 브랜치, 사용 가능한 디스크 공간을 함께 확인하세요. 파일 유형을 잘못 지정하면 이미 커밋한 일반 Git 파일이 자동으로 LFS 파일로 바뀌는 것이 아닙니다. 변경을 공유하기 전에 테스트 파일이 포인터로 기록되는지와 다른 작업 사본에서 실제 파일을 받을 수 있는지 확인해야 합니다.
주의: 파일이 커밋된 뒤에 추적 규칙을 추가해도 과거 이력이 자동으로 정리되지는 않습니다. 이력 변경이 필요한 저장소라면 팀원과 협의한 뒤 별도의 복구·재배포 계획을 세우세요.
원격 Mac에서 인증과 파일 받기를 분리해 확인합니다
코드 저장소 인증, LFS 객체 인증, 원격 Mac 접속 정보는 서로 다른 확인 대상입니다. git clone이 성공해도 LFS 서버 인증이 거부되거나 객체 다운로드가 실패할 수 있습니다. Git LFS 인증 문서는 LFS 서버가 인증 정보를 다루는 방식을 설명하므로, 저장소 제공자의 인증 절차와 함께 확인하세요.
Git LFS 인증을 매번 다시 하지 않으려면 먼저 어떤 인증 계층에서 다시 로그인을 요구하는지 확인해야 합니다. 원격 Mac 로그인 암호를 저장소 암호처럼 입력하거나, 접근 토큰을 기록이 남는 명령줄에 그대로 적지 마세요. 승인된 자격 증명 저장 방식을 사용하고, 토큰이 만료되거나 권한이 바뀌었을 때 다시 인증하는 절차도 마련하세요. 계정·접속 관련 일반 안내는 도움 센터, 개인정보 처리 범위는 개인정보 정책에서 확인할 수 있습니다.
파일을 받을 때는 작업 범위에 맞춰 git lfs fetch의 포함·제외 조건을 검토하거나, 현재 작업에서 필요한 내용을 가져오는 git lfs pull을 사용합니다. fetch의 포함·제외 규칙을 확인하면 불필요한 파일까지 받는 일을 줄일 수 있습니다. 부분 복제 기능도 LFS 파일의 수신 여부와 같은 기능은 아니므로, Git의 clone 옵션 설명을 읽고 두 동작을 구분하세요.
약한 네트워크에서는 수신 완료와 파일 복구를 따로 봅니다
호텔이나 카페의 연결이 끊겼다면 같은 명령을 무작정 반복하기보다, 먼저 터미널에 남은 오류와 현재 작업 브랜치를 기록하세요. 그런 다음 필요한 범위를 확인해 수신을 다시 시도하고, 작업 파일이 실제 내용으로 복원됐는지 검증합니다. 명령이 성공했다는 표시만으로는 응용 프로그램에서 파일이 정상적으로 열리는지 확인할 수 없습니다.
확인은 세 부분으로 나눕니다. 첫째, LFS 대상 목록과 포인터 상태를 확인합니다. 둘째, 파일을 열어야 하는 디자인 도구나 개발 도구에서 실제로 읽히는지 확인합니다. 셋째, 저장소가 허용하는 경우 해시나 프로젝트 자체의 검증 절차로 내용의 일치 여부를 살핍니다. 객체 검사에는 Git LFS fsck 안내를 참고하세요.
경험상 중요한 점은 재시도 횟수보다 실패 위치를 남기는 것입니다. 인증 오류인지, 전송 중단인지, 저장 공간 부족인지 구분해야 다음 접속에서 같은 문제를 반복하지 않습니다.
저장 공간과 임대 기간 종료를 함께 관리합니다
원격 Mac의 저장 공간은 작업 트리, Git LFS 객체 캐시, 내보낸 결과물, 임시 소재로 나눠 살펴보세요. 사용량은 프로젝트와 작업 흐름에 따라 달라지므로 고정 용량을 기준으로 삼지 말고, 작업 전후의 실제 사용량을 확인합니다. macOS의 디스크 확인 도구로 여유 공간을 살피고, 정리 전에는 필요한 객체가 다른 저장소나 백업 위치에서 다시 받아지는지 검증하세요.
LFS 캐시를 정리할 때는 작업 중인 브랜치와 미완료 파일을 먼저 확인합니다. Git LFS prune 안내에 따라 정리 대상과 보존 조건을 이해한 뒤 실행하세요. 디스크가 부족해도 실행 중인 작업이나 유일한 복사본을 확인하지 않고 캐시를 지우면 복구 시간이 늘거나 파일을 다시 받을 수 없게 될 수 있습니다.
프로젝트를 넘기거나 임대 기간을 마칠 때는 다음 항목을 확인합니다.
- 필요한 브랜치와 커밋이 원격 저장소에 올라갔는지 확인합니다.
- 로컬에만 있는 변경 사항, 환경 변수, 빌드 방법과 필요한 도구를 기록합니다.
- 새 Mac에서 저장소를 복제한 뒤 LFS 파일을 받아 실제 프로젝트가 열리는지 검증합니다.
- 기존 원격 Mac에만 남은 내보낸 결과물과 임시 소재를 확인한 뒤 보존 또는 삭제합니다.
- 새 환경에서 인계가 끝난 것을 확인하기 전에는 기존 작업 공간을 정리하지 않습니다.
계속 같은 원격 Mac을 사용한다면 작업 공간과 인증을 점검하고, 다른 Mac으로 옮긴다면 새 기기에서 실제 프로젝트를 열어 보세요. 임시 기기에 넘길 때도 코드만 전달하지 말고 LFS 파일 수신 상태와 필요한 환경 설정을 함께 확인해야 합니다.
여행 전 최종 선택 기준
- 작업 파일의 범위가 명확하고 저장 공간도 확인했다면 필요한 파일만 받는 방식으로 출발합니다.
- 팀원과 환경을 공유하거나 전체 복구 가능성을 확인해야 한다면, 출발 전에 전체 수신과 실제 파일 열기를 시험합니다.
- 인증 오류나 업로드 제한이 해결되지 않았다면 저장소 규칙과 제공자 정책을 먼저 바로잡고, 검증 전에는 원격 Mac을 유일한 작업 환경으로 삼지 않습니다.
- 임대 종료 뒤의 이동 계획이 없다면 먼저 새 환경에서 복제·수신·열기까지 검증하는 인계 절차를 만듭니다.
노트북에 저장소 전체를 들고 다니는 방식은 장비 분실 위험, 여러 기기의 환경 차이, 큰 파일의 재수신 부담을 남깁니다. 반대로 원격 Mac도 네트워크 품질과 인증 상태, 저장 공간을 직접 확인해야 하며, 물리 장비가 필요한 작업이나 장기간의 고정된 고부하 작업에는 자가 장비가 더 알맞을 수 있습니다. 출발 전에 저장 공간·백업·파일 전송 방식까지 확인하고 큰 프로젝트를 옮기기로 했다면, 필요 기간에 맞춰 이용할 수 있는 SSHMac 원격 Mac으로 먼저 실제 저장소의 수신과 복구를 시험해 보세요.