Git에서는 텍스트 파일의 병합(Merge) 충돌은 흔한 일이지만, 만약 포토샵(.psd) 파일이나 3D 모델링(.max) 파일처럼 내용을 합칠 수 없는 바이너리(Binary) 파일의 버전이 충돌하면 어떻게 될까요? 둘 중 한 명의 작업 내용은 무조건 덮어써져서 사라지는 끔찍한 상황이 발생합니다. 😱
이런 '병합 불가' 파일들의 비극을 막기 위해, Subversion(SVN)에는 "이 파일은 지금 내가 독점해서 작업할 테니, 다른 사람은 수정하지 마!"라고 선언하는 매우 고전적이고 확실한 교통정리 기능이 있습니다. 바로 잠금(Lock-Modify-Unlock) 모델입니다.
SVN 잠금이란? 도서관의 '대출 중' 팻말
SVN의 잠금 기능은 도서관에서 책을 빌리는 것과 똑같습니다. 📖
- 잠금 (Lock): 중요한 책(파일)을 수정하기 전에, 당신은 사서(SVN 서버)에게 가서 "이 책 제가 빌려갈게요"라고 말하고 대출(Lock)합니다. 사서는 책꽂이에 '대출 중' 이라는 팻말을 꽂아둡니다.
- 수정 (Modify): 책을 빌린 당신만이 유일하게 책의 내용을 수정하고 필기할 수 있습니다. 다른 사람들은 그 책이 '대출 중'이라는 사실을 알 수 있지만, 빌려가서 수정할 수는 없습니다.
- 잠금 해제 (Unlock): 수정이 끝나면, 당신은 책을 도서관에 반납(Commit)합니다. 커밋이 완료되면 '대출 중' 팻말은 자동으로 사라지고(Unlock), 이제 다른 사람이 그 책을 빌려갈 수 있게 됩니다.
이처럼, 한 사람이 파일을 잠그면 다른 사람은 그 파일을 수정 후 커밋할 수 없도록 SVN 서버가 강제로 막아줍니다. "일단 각자 작업하고 나중에 합치자(Git 방식)"가 아니라, "애초에 동시에 작업할 수 없도록 하자" 는 매우 명확하고 보수적인 협업 방식입니다.
직접 사용해보기: Lock & Unlock 명령어
이 기능은 주로 TortoiseSVN과 같은 GUI 툴에서 우클릭 메뉴(Get lock)로 사용하는 경우가 많지만, 명령어는 더 간단합니다.
상황: 디자이너 'A'가 main-banner.psd 파일을 수정하려고 합니다.
- 파일 잠그기 (Lock): 디자이너 'A'는 작업을 시작하기 전에 파일을 잠급니다.
-
Bash
# svn lock [파일명] svn lock main-banner.psd # 'main-banner.psd' locked by user 'A'. - 다른 사람의 시도 (실패): 잠시 후, 디자이너 'B'가 같은 파일을 모르고 수정하려 하거나 잠그려 하면, SVN이 막아줍니다."이 파일은 이미 'A'가 잠갔습니다" 라는 명확한 메시지를 받게 됩니다.
-
Bash
# 'B'가 잠금을 시도 svn lock main-banner.psd # svn: E195022: 'main-banner.psd' is already locked by user 'A' in this working copy. - 수정 후 커밋 & 자동 잠금 해제: 디자이너 'A'는 수정을 마치고 파일을 커밋합니다.성공적으로 커밋이 완료되면, 'A'가 걸었던 잠금은 자동으로 해제(Unlock) 됩니다. 이제 'B'를 포함한 다른 팀원들이 이 파일을 다시 잠그고 수정할 수 있습니다.
-
Bash
svn commit -m "메인 배너 시안 수정" main-banner.psd # ... # Transmitting file data .done # Committed revision 149.
Tip: 만약 수정을 포기하고 강제로 잠금을 풀어야 한다면 svn unlock [파일명] 명령어를 사용하면 됩니다.
어디에 사용하면 좋을까?
이 잠금 모델은 여러 명이 동시에 코드를 수정하고 병합하는 일반적인 소프트웨어 개발에는 잘 맞지 않습니다. 하지만 다음과 같은 상황에서는 여전히 매우 강력하고 효과적인 해결책입니다.
- 디자인 에셋 관리: 디자이너들이 포토샵, 일러스트레이터, 스케치 파일을 관리할 때.
- 게임 개발: 3D 모델, 텍스처, 사운드 파일 등 바이너리 에셋을 관리할 때.
- 문서 관리: MS 워드, 파워포인트 등 동시에 편집하고 병합하기 어려운 공식 문서를 관리할 때.
마치며
SVN의 잠금(Lock) 기능은 Git의 유연한 병합 모델에 익숙한 개발자에게는 다소 답답하고 구식으로 느껴질 수 있습니다. 하지만 병합이 불가능한 자산을 다루는 환경에서는, 복잡한 커뮤니케이션 비용을 줄이고 치명적인 작업 손실을 원천적으로 방지하는 가장 확실하고 직관적인 안전장치입니다.
"일단 가져가서 고치고 보자"가 아닌, "수정하기 전에 허락을 구한다"는 이 고전적인 예절이, 어떤 상황에서는 팀의 평화를 지키는 최고의 방법이 될 수 있습니다. 🧐