Unity Version Control에서 Checkout과 Checkin 이해하기

들어가기에 앞서

Unity는 기본적으로 컴포넌트 기반으로 개발해야 하는 엔진이다. 게임 오브젝트에 컴포넌트를 붙이고, Inspector에서 값을 조정하고, 프리팹으로 저장하고, 씬에 배치하는 방식으로 작업이 진행된다.

결국 Unity 개발은 많은 부분이 파일 에디팅이다. 프리팹, 씬, 머티리얼, ScriptableObject 같은 에셋 파일을 수정하면서 프로젝트를 만들어간다. 그리고 이런 파일들은 코드처럼 단순한 텍스트 변경으로만 다루기 어렵다. 실무에서는 사실상 바이너리 에셋을 관리하는 것에 가깝게 봐야 한다.

문제는 버전 관리에서 바이너리 머지가 사실상 불가능하다는 점이다. 두 사람이 같은 프리팹이나 씬을 동시에 수정하면, 나중에 변경사항을 합치는 일이 매우 어렵거나 위험해진다. 겉으로는 YAML 텍스트처럼 보이는 Unity 에셋도 참조 ID, 직렬화된 값, 컴포넌트 순서가 얽혀 있기 때문에 충돌을 사람이 안전하게 해결하기 쉽지 않다.

따라서 내가 특정 파일을 작업하는 동안에는 다른 사람이 해당 파일에 접근하지 못하도록 막는 방법이 필요하다. 이 글에서는 Unity Version Control에서 Checkout으로 lock을 걸고, Checkin으로 변경사항을 제출하면서 lock을 푸는 흐름을 소개한다.

개인 프로젝트라면 Unity Version Control을 더 적극적으로 사용해볼 만하다. Unity DevOps 무료 플랜은 개인이 실험하거나 작은 프로젝트를 관리하기에 꽤 넉넉한 무료 한도를 제공한다. 2026년 6월 기준 공식 문서에서는 무료 플랜에 Standard Storage 25GB와 월 100GB Egress가 포함된다고 안내하고 있다. 요금과 한도는 바뀔 수 있으니 실제 프로젝트에 적용하기 전에는 공식 가격 정책을 다시 확인하는 것이 좋다.

핵심만 먼저 말하면 다음과 같다.

Checkout
→ 이 에셋을 내가 수정하겠다고 표시한다
→ 동시에 lock을 건다

Checkin
→ 수정한 내용을 저장소에 제출한다
→ 동시에 lock을 푼다

즉 Checkout과 Checkin은 단순히 파일을 받고 올리는 동작이 아니다. Unity 에셋 작업에서는 Checkout을 통해 lock을 걸고, Checkin을 통해 lock을 푼다는 점이 중요하다.

왜 lock을 거는가

소스 코드는 두 사람이 같은 파일을 수정해도 비교적 머지를 시도해볼 수 있다. 변경된 줄을 비교하고, 충돌이 난 부분을 사람이 직접 고치는 방식이다.

하지만 Unity 에셋은 다르다. 프리팹이나 씬은 내부적으로 YAML 형태로 저장되더라도, 사람이 읽어서 안전하게 머지하기 어려운 경우가 많다. 컴포넌트 순서, 참조 ID, 직렬화된 값, 메타 파일이 함께 얽히기 때문이다.

예를 들어 한 사람이 무기 프리팹의 Weapon 컴포넌트 값을 수정하고, 다른 사람이 같은 프리팹의 위치나 머티리얼을 수정했다고 해보자. 겉으로는 서로 다른 값을 바꾼 것처럼 보이지만, 실제 파일에서는 같은 영역이 함께 변경될 수 있다.

이런 파일은 동시에 수정해서 나중에 머지하는 것보다, 한 사람이 수정하는 동안 다른 사람이 건드리지 못하게 잠그는 편이 안전하다. Unity Version Control의 Checkout은 바로 이 잠금을 시작하는 동작이다.

1. Checkout으로 lock 걸기

아래 화면은 scify rifle 프리팹을 수정하기 전 상태다. Inspector에 Checkout 버튼이 보인다. 아직 이 에셋은 내가 수정 중인 상태가 아니므로, 값을 바꾸기 전에 먼저 Checkout을 해야 한다.

여기서 Checkout 버튼을 누르면 Unity Version Control은 이 파일을 내가 수정할 파일로 표시한다. 동시에 다른 사용자가 같은 에셋을 수정하지 못하도록 lock을 건다.

이 단계는 "서버에 변경사항을 올리는 것"이 아니다. Checkout은 아직 제출이 아니라 선언이다.

이 파일을 내가 수정하겠습니다.
그러니 수정이 끝날 때까지 다른 사람이 건드리지 못하게 잠가주세요.

이렇게 이해하면 된다.

만약 프리팹을 더블 클릭하여 편집하려 하면 자동으로 체크아웃이 된다.

2. Checkout 완료 후 수정하기

Checkout이 완료되면 Inspector에 Locked by me 상태가 표시된다. 말 그대로 이 에셋의 lock을 내가 가지고 있다는 뜻이다.

이제 프리팹 값을 수정할 수 있다. 예시에서는 Weapon 컴포넌트의 Table Asset에 NewGunTable이 할당되어 있고, 선택된 아이템 정보도 함께 보인다.

이 상태에서 수정한 내용은 아직 내 로컬 작업공간에만 있다. 다른 팀원이 바로 볼 수 있는 상태가 아니다. 또한 lock도 아직 유지된다.

정리하면 Checkout 이후의 상태는 다음과 같다.

에셋 수정 가능
변경사항은 아직 로컬에만 있음
lock은 내가 가지고 있음
다른 사람은 같은 에셋을 수정할 수 없음

그래서 Checkout한 에셋은 작업이 끝난 뒤 반드시 Checkin하거나, 필요 없어진 경우 Checkout을 취소해야 한다.

3. Checkin 창에서 변경사항 확인하기

수정이 끝났다면 체크인 버튼을 눌러 Checkin을 진행한다. 그러면 변경사항 체크인 창이 열린다.

이 창에서 가장 먼저 볼 것은 두 가지다.

• 체크인 코멘트
• 이번에 함께 제출될 파일 목록

예시에서는 코멘트로 테이블 정보 할당이 입력되어 있다. 에셋 변경은 코드 diff만 보고 의도를 알기 어려운 경우가 많기 때문에, 코멘트에는 무엇을 바꿨는지 짧게라도 남기는 편이 좋다.

좋은 코멘트는 거창할 필요가 없다.

무기 프리팹에 테이블 정보 할당
총구 이펙트 위치 보정
소총 머티리얼 설정 변경

반대로 다음처럼 너무 막연한 코멘트는 나중에 이력을 볼 때 도움이 되지 않는다.

수정
작업
테스트

그리고 파일 목록도 꼭 확인해야 한다. Unity에서는 프리팹을 수정할 때 .prefab 파일뿐 아니라 .meta 파일이나 다른 관련 에셋이 함께 변경될 수 있다. 이번 작업과 관계없는 파일이 섞여 있다면 Checkin 전에 제외하거나 원인을 확인하는 것이 좋다.

4. Checkin 완료 후 lock 해제

Checkin을 완료하면 변경사항이 저장소에 올라가고, Checkout으로 잡고 있던 lock이 풀린다.

화면을 보면 다시 Checkout 버튼이 보인다. 이는 더 이상 내가 이 에셋을 잠그고 있지 않다는 뜻이다. 이제 다른 팀원이 최신 변경사항을 받은 뒤, 필요하다면 다시 Checkout해서 수정할 수 있다.

전체 흐름은 다음과 같다.

Checkout 버튼 클릭
→ lock 획득
→ 에셋 수정
→ Checkin 창에서 코멘트와 파일 목록 확인
→ Checkin
→ 변경사항 제출
→ lock 해제

여기서 가장 중요한 부분은 마지막이다. Checkin은 단순히 변경사항을 올리는 동작이 아니라, 내가 잡고 있던 lock을 푸는 동작이기도 하다.

Checkout을 취소해야 하는 경우

Checkout했다고 해서 반드시 Checkin해야 하는 것은 아니다. 실수로 잘못 Checkout했거나, 수정해보니 변경이 필요 없다는 것을 알게 될 수도 있다.

이럴 때는 Checkout을 취소해야 한다. Unity 화면에서는 실행 취소 또는 Undo Checkout에 해당하는 버튼을 사용할 수 있다. 다만 이때 로컬에서 수정한 값이 되돌아갈 수 있으므로, 실제로 버려도 되는 변경인지 확인해야 한다.

흐름은 이렇게 나눌 수 있다.

수정한 내용을 남기고 싶다
→ Checkin

수정한 내용이 필요 없다
→ Checkout 취소

가장 피해야 하는 상황은 lock을 잡아둔 채 방치하는 것이다. 내가 더 이상 수정하지 않는 에셋을 계속 잠그고 있으면 다른 팀원의 작업을 막게 된다. 특히 공용 프리팹, 주요 씬, 공통 머티리얼처럼 여러 사람이 자주 만지는 파일은 작업이 끝나면 빠르게 Checkin하거나 Checkout을 취소하는 습관이 필요하다.

실무에서 조심할 점

첫 번째로, Checkout하기 전에 최신 상태를 받는 것이 좋다. 오래된 파일을 기준으로 수정하면 이미 다른 사람이 바꾼 내용을 놓칠 수 있다.

두 번째로, 필요한 파일만 Checkout하는 편이 좋다. 여러 에셋을 한꺼번에 잠그면 다른 사람의 작업 범위를 불필요하게 막을 수 있다.

세 번째로, Checkin 전 파일 목록을 반드시 확인해야 한다. Unity는 의도하지 않은 파일이 함께 변경되는 경우가 있다. 특히 .meta 파일, 자동 생성된 에셋, 테스트 중 건드린 프리팹이 섞여 있지 않은지 확인해야 한다.

네 번째로, 코멘트는 작업 단위가 보이게 작성하는 것이 좋다. 나중에 문제가 생겼을 때 "어떤 변경이 들어갔는지"를 빠르게 찾을 수 있기 때문이다.

정리

Unity Version Control에서 Checkout은 에셋을 수정하기 위해 lock을 거는 작업이다. Checkout이 완료되면 Locked by me 상태가 되고, 다른 사람은 같은 에셋을 동시에 수정하기 어렵다.

Checkin은 수정한 내용을 저장소에 제출하는 작업이다. 동시에 Checkout으로 잡고 있던 lock을 해제한다. 그래서 에셋 수정이 끝났다면 Checkin을 통해 변경사항을 공유하고 lock을 풀어야 한다.

Unity 프로젝트에서는 에셋 충돌 비용이 생각보다 크다. Checkout과 Checkin의 의미를 정확히 이해하고, 필요한 파일만 잠그고, 작업이 끝나면 빠르게 제출하거나 취소하는 습관이 팀 작업을 훨씬 편하게 만든다.