"Git은 위험하고 SVN은 안전하다"는 말은 어디까지 맞을까 — 운영 관점 비교표

공공기관의 형상관리를 이야기하다 보면 Git과 SVN을 보안 관점에서 비교하게 된다. 최근에도 SVN은 구축형 서버에 코드를 보관하므로 유출이 어렵고, Git은 클라우드 기반이라 유출 가능성이 있다는 설명을 접했다. 이 설명에는 먼저 구분해야 할 두 문제가 섞여 있다. 저장소를 어디에 운영하는가, 그리고 개발자에게 어떤 데이터가 복제되는가.

정부 운영 사례와 조달 문서로 "공공기관에서 Git을 써도 되는가"에 답한 글은 내부망에서 Git을 쓰면 공공기관도 안전한가에 따로 있다. 이 글은 그 뒤에 오는 실무 질문을 다룬다. 두 도구의 동작이 실제로 어디에서 갈리고, 보안 검토 회의에서 어떤 항목을 표에 놓고 확인해야 하는가.

Git을 쓰면 코드가 외부 클라우드로 나가는가?

나가지 않는다. Git은 버전 관리 시스템이고, GitHub 같은 호스팅 서비스와는 다른 개념이다. Pro Git의 서버 운영과 프로토콜 설명은 자체 서버를 운영하는 방법과 로컬 경로, SSH, HTTP로 저장소를 사용하는 방식을 다룬다. 내부 서버와 내부망으로 구성하는 것이 기술적으로 가능하므로, "Git인가"와 "외부 서비스로 코드를 전송하는가"는 별도로 확인해야 하는 질문이다.

SVN을 쓰면 코드가 서버 밖으로 안 나오는가?

나온다. SVN도 개발자가 파일을 수정하려면 작업 복사본을 받는다. Subversion 문서는 checkout이 저장소 하위 트리에 대한 개인 작업 복사본을 만든다고 설명한다. 서버가 잘 보호돼 있더라도 개발자가 받은 소스 파일의 보관과 반출은 별도로 관리해야 하고, 이건 중앙집중형 저장소와 양립하는 사실이다.

그렇다고 두 도구의 유출 영향이 같다고 말할 수도 없다. 일반적인 Git clone은 가져온 브랜치와 태그에서 도달 가능한 과거 이력을 로컬에 보관한다. Pro Git의 분산 버전 관리 설명이 말하는 그 특성이다. SVN의 일반적인 checkout은 작업 대상의 파일과 작업용 정보를 받으며, 저장소의 전체 이력 데이터베이스를 복제하지는 않는다. 단말 한 대에서 어떤 데이터가 노출될 수 있는지 비교한다면 이 차이를 놓고 봐야 한다.

shallow clone이나 sparse checkout으로 막을 수 있나?

내려받는 양은 줄일 수 있지만, 그 자체가 강제된 보안 경계는 아니다. git-clone 문서가 설명하는 shallow clone과 partial clone은 처음 내려받는 이력과 객체의 양을 줄인다. 그러나 사용자가 다른 방식으로 clone하거나 추가 fetch를 할 수 있는지는 서버 권한과 실행 환경에 달려 있다. 내려받은 양이 적다는 사실과 더 받을 권한이 없다는 사실은 다르다.

git-sparse-checkout도 마찬가지다. 작업 디렉터리에 표시할 파일을 줄이는 기능이지, 특정 폴더를 보이지 않게 했다는 이유만으로 그 폴더 데이터에 대한 읽기 권한이 차단된 건 아니다. Git의 namespace 문서 역시 같은 저장소의 namespace를 효과적인 읽기 접근 통제로 보지 않으며, 보호할 데이터는 별도 저장소에 두는 방법을 제시한다.

읽기 권한의 단위가 여기서 갈린다. SVN은 경로 기반 권한으로 한 저장소 안의 경로별 읽기·쓰기 권한을 서버 설정에서 줄 수 있다. 하나의 저장소 안에서 협력사별로 볼 수 있는 디렉터리를 나눠왔다면, Git으로 전환할 때 그 요구를 저장소 분리로 어떻게 옮길지 먼저 설계해야 한다. 그 이관 설계는 락 기반 형상관리에서 Git으로에서 다뤘다.

운영 관점에서 정리하면 어떻게 되나?

다섯 항목으로 놓고 보면 두 도구가 같은 곳과 다른 곳이 분명해진다.

다섯 항목 중 셋은 두 도구가 같다. 다른 둘, 로컬 복사 범위와 경로별 읽기 분리는 설계로 대응하는 항목이다.

실제 요구사항에 따라 이 표에서 무겁게 볼 항목도 달라진다. 협력사에게 소스 일부만 공개해야 하는 조직이라면 읽기 경계를 먼저 확인한다. 과거 이력의 노출 범위를 줄여야 한다면 이력 분리와 작업 환경을 검토한다. 코드가 개발자 개인 단말에 남으면 안 되는 조건이라면, 통제된 개발 환경에서 작업하게 하는 접근을 함께 검토할 수 있다.

폐쇄망이면 이 검토를 생략해도 되나?

안 된다. 폐쇄망이라는 조건이 데이터 흐름을 대신 설명해주지는 않는다. 인터넷 연결이 제한돼 있어도 허용된 반출 절차와 이동식 매체, 빌드 서버와 백업 경로가 무엇인지 확인해야 한다. 저장소 서버만 표시한 구성도에 개발 단말, 러너, 결과물 저장소, 백업을 함께 그려보는 것이 보안 논의의 출발점이다. 폐쇄망 배포 환경을 어떻게 나누는지는 온프레미스 배포의 다섯 환경에 적어뒀다.

계정 권한을 회수했을 때 무엇이 사라지는지도 구분해야 한다. 서버에 새로 접근하는 권한을 막는 것과 이미 내려받은 파일을 삭제하는 것은 다른 조치다. Git과 SVN 모두 읽을 수 있었던 소스의 복사본이 어디에 남는지 관리할 필요가 있다. Private 설정 역시 허용된 사용자가 받은 코드의 이후 사용까지 자동으로 통제한다는 뜻은 아니다.

보안 검토 회의에 가져갈 체크리스트

위 내용을 회의에서 바로 쓸 수 있는 질문으로 바꾸면 이렇다.

• 저장소 서버는 어디에 있고, 코드가 외부 서비스로 전송되는 경로가 있는가
• 개발자 단말에 내려가는 범위는 무엇인가 (현재 파일만인가, 과거 이력까지인가)
• 한 저장소 안에서 경로별로 읽기 권한을 나눠야 하는 요구가 있는가, 있다면 저장소 분리로 옮길 수 있는가
• 개발 단말, 러너, 결과물 저장소, 백업이 구성도에 모두 있는가
• 계정을 회수했을 때 이미 받은 복사본은 어떤 절차로 처리하는가

공공기관의 도입 판단은 해당 기관의 보안 요구사항과 실제 구성을 기준으로 해야 한다. 이 비교는 그 판단에 필요한 기술적 구분이다. 제품 이름만으로 안전을 선언하면 확인해야 할 위협과 통제가 빠진다.

나는 Git을 사용하는 플랫폼을 만드는 사람이다. 그래서 Git의 장점을 설명하는 만큼 이력 복제와 읽기 경계의 제약도 같은 정확도로 설명해야 한다고 본다. CollabOps가 폐쇄망 설치를 기본 형상으로 두고 저장소·변경요청·파이프라인·배포 기록을 한 평면에 남기는 이유도 결국 위 체크리스트의 마지막 줄들에 답하기 위해서다. 고객이 확인할 수 있어야 하는 것은 자신의 코드가 어디에 존재하고, 누가 어디까지 접근할 수 있으며, 그 사실을 무엇으로 검증할 수 있는가다.