소스 수정 전에 락을 겁니다만 — 락 기반 형상관리에서 동시 개발로 넘어간다는 것

공공기관 미팅에서 거의 매번 받는 질문이 있다.

"지금은 소스를 수정하려면 수정하기 전에 락을 겁니다. 이 솔루션은 어떤 형태로 이루어지나요?"

외산 상용 형상관리 도구를 오래 쓴 조직일수록 이 질문이 먼저 나온다. 체크아웃하면 파일이 잠기고, 내가 반영을 끝내야 다음 사람이 만질 수 있는 방식. 그 세계에서 "여러 명이 같은 파일을 동시에 고친다"는 말은 기능 설명이 아니라 사고 예고처럼 들린다. 정당한 걱정이고, 그래서 이 글은 그 걱정에 답하는 글이다.

락 기반 형상관리와 Git 방식은 뭐가 다른가?

락 기반 형상관리는 충돌을 원천 봉쇄하는 모델이고, Git 은 충돌을 허용한 뒤 머지 시점에 해소하는 모델이다. 학술 용어로는 비관적 동시성 제어와 낙관적 동시성 제어의 차이인데, 실무 감각으로 번역하면 이렇다. 락 모델은 "한 파일에 한 명"을 강제해서 안전을 산다. 대신 그 파일을 고쳐야 하는 두 번째 사람은 첫 번째 사람이 끝날 때까지 기다린다.

Git 은 반대로 간다. 각자 브랜치를 따서 동시에 수정하고, 합칠 때 도구가 변경을 자동 병합한다. 같은 파일의 다른 부분을 고쳤으면 사람이 개입할 일 자체가 없다. 같은 줄을 고쳤을 때만 충돌이 나고, 그때 어느 쪽을 살릴지 사람이 결정한다. 그러니까 락 모델에서 "기다림"으로 지불하던 비용을 Git 에서는 "가끔 발생하는 충돌 해소"로 지불한다. 그리고 대부분의 코드베이스에서 후자가 압도적으로 싸다. 두 사람이 정확히 같은 줄을 같은 기간에 고치는 일은 생각보다 드물기 때문이다.

솔직히 말하면 이 비교 자체는 새로운 얘기가 아니다. Git 이 이 논쟁에서 이긴 지 15년이 넘었다. 질문의 진짜 무게는 다음에 있다.

락이 없으면 통제는 어떻게 하나?

락이 하던 통제는 사라지는 게 아니라 파일 잠금에서 워크플로우 게이트로 자리를 옮긴다. 락 모델에서 락은 사실 두 가지 일을 겸하고 있었다. 하나는 동시 수정 방지(기술 문제), 다른 하나는 "아무나 함부로 못 고치게" 하는 통제(거버넌스 문제). 전자는 위에서 말한 대로 머지가 대체한다. 후자를 대체하는 게 브랜치 보호와 변경요청 승인이다.

CollabOps 에서 운영 브랜치에는 보호 규칙이 걸린다. 직접 푸시 금지, 강제 푸시 금지, 브랜치 삭제 금지. 변경은 반드시 변경요청(Change Request)을 거쳐야 하고, 지정된 수의 승인자가 승인해야 하며, 필수 검증(빌드·테스트·보안 스캔)이 통과해야 머지된다. 우리가 PR 이나 MR 이라는 용어 대신 굳이 변경요청이라는 단어를 쓰는 이유도 여기 있는데, 공공과 금융의 변경 승인 절차가 요구하는 단위가 정확히 이것이기 때문이다.

락과 게이트의 결정적 차이는 통제의 시점이다. 락은 수정하는 순간을 통제하고, 게이트는 반영되는 순간을 통제한다. 그리고 거버넌스가 실제로 지켜야 하는 건 후자다. 누가 어떤 파일을 열어봤는지가 아니라, 무엇이 어떤 승인을 거쳐 운영 코드에 들어갔는지. 락 모델은 전자를 잠그느라 후자의 증적을 놓치는 경우가 많다. 승인 절차가 형상관리 도구 밖의 결재 시스템에 따로 살기 때문이다.

그래서 형상관리는 구체적으로 어떻게 진행되나?

하나의 변경은 이슈에서 시작해서 감사 로그로 끝나는 하나의 연결된 흐름으로 진행된다. 순서대로 쓰면 이렇다.

1. 이슈: 요구사항이나 결함이 이슈로 등록된다. 변경의 "왜"가 여기 남는다.
2. 브랜치: 이슈에서 작업 브랜치를 딴다. 락을 거는 대신 자기 작업 공간을 만드는 것.
3. 커밋: 수정 내역이 한 줄 단위로 기록된다. 누가 언제 어느 줄을 바꿨는지는 웹에서 바로 추적된다.
4. 변경요청: 반영하려면 변경요청을 올린다. 여기서 리뷰어가 지정되고 승인 절차가 시작된다.
5. 리뷰와 파이프라인: 사람의 승인과 자동 검증(빌드·테스트·스캔)이 병행으로 돈다. 둘 다 통과해야 다음으로 간다.
6. 머지와 배포: 게이트를 통과한 변경만 운영 브랜치에 합쳐지고, 배포로 이어진다.
7. 감사 로그: 이 전 과정이 자동으로 기록된다. 감사 대응 때 캡처와 엑셀로 재구성할 필요가 없다.

락 모델 사용자가 여기서 주목할 부분은 3번이다. 락 모델에서도 "누가 이 파일을 마지막으로 반영했는지"는 안다. 하지만 "이 줄이 어떤 요구사항 때문에 언제 바뀌었는지"를 클릭 몇 번으로 따라가는 건 다른 차원의 이야기다. 이력이 파일 단위가 아니라 변경 단위, 줄 단위로 남는다.

기존 형상관리의 이력은 어떻게 되나?

기존 이력은 버리지 않고 가져오며, 전환 방식도 한 가지가 아니라 세 가지 중에서 고른다. 우리가 레거시 형상관리에 대해 지키는 원칙은 "기존 이력을 잃게 하지 않는다"이다.

• 전체 마이그레이션: 리비전 이력, 작성자 매핑, 커밋 메시지와 태그를 보존한 채 Git 으로 이전한다.
• 읽기 전용 인덱싱: 기존 저장소는 그대로 두고, 조회와 추적만 CollabOps 에서 한다. 이전 없이 공존.
• 미러 모드: 양쪽을 동기화하며 팀 단위로 점진 전환한다.

폐쇄망이라면 이 과정이 인터넷 없이 돌아야 하는데, CLI 기반 오프라인 임포트로 처리한다. 다만 정직하게 적어두면, 우리 마이그레이션 도구가 문서화된 대상은 SVN 과 Git 계열 호스팅이다. 상용 락 기반 도구의 전용 저장 포맷은 표준 경로가 아니라서, 도구별 export 형식을 보고 이전 경로를 함께 설계해야 한다. 미팅에서 "그건 검토가 필요합니다"라고 답하는 항목이고, 이 글에서도 같은 답이다.

하나 더. 락 모델 위에 쌓인 건 데이터만이 아니라 일하는 방식이다. 파일 단위 담당제, 반영 순번 같은 관행은 도구를 바꾼다고 자동으로 바뀌지 않는다. 그래서 우리는 빅뱅 전환보다 한 팀, 한 시스템에서 시작하는 쪽을 권한다. 안정성이 곧 레퍼런스라는 글에서 쓴 것과 같은 이유다. 무사고 기간 자체가 다음 팀을 설득하는 근거가 된다.

락은 20년간 그 조직의 사고를 막아온 도구다. 그 사실을 존중하지 않는 벤더의 말은 들을 필요가 없다고 생각한다. 우리가 하는 말은 락을 버리라는 게 아니라, 락이 지키던 것을 더 낮은 비용으로 더 촘촘하게 지키는 방법이 이미 표준이 되었다는 것이다. 기다림 없이, 그리고 증적은 더 완전하게.