내부망에서 Git을 쓰면 공공기관도 안전한가 — 공개 자료로 확인한 답

"Git은 클라우드 기반이잖아요. 저희는 폐쇄망이라 못 씁니다."

공공 쪽 미팅에서 종종 듣는 말이다. 정당한 질문이다. 소스코드는 기관이 가진 자산 중 가장 민감한 축에 들고, 20년 가까이 사고 없이 써온 도구를 바꾸는 데 신중한 건 당연하다. 개발자 커뮤니티에서도 2024년에 같은 논쟁이 있었는데 댓글로 반박과 정정이 오가다 결론 없이 끝났다. 그래서 이번에는 감으로 답하지 않기로 했다. Git과 SVN의 공식 문서, 정부 발표, 조달 문서, CVE 공지를 놓고 하나씩 확인했다.

먼저 답부터 적는다. 내부망에 구축한 Git은 공공기관에서 안전하게 운영할 수 있다. 정부가 직접 그렇게 쓰고 있고, 보안 요구가 강한 금융 유관기관이 폐쇄망 GitLab을 조달했으며, 전자정부 표준프레임워크도 Git을 표준 도구로 안내한다. SVN에서 넘어올 때 설계 단계에서 챙길 지점이 두 가지 있는데, 둘 다 알려진 해법이 있다. 이 글은 그 근거와 두 지점, 그리고 보안 심사에서 바로 쓸 수 있는 질문 목록을 순서대로 정리한 것이다.

Git을 쓰려면 인터넷이 필요한가?

필요 없다. Git은 버전관리 소프트웨어이고, SSH·HTTP(S)·로컬 경로로 기관 내부 서버에서 그대로 운영된다. Git 공식 프로토콜 문서가 정의하는 통신 방식 어디에도 외부 클라우드는 전제로 들어있지 않다. GitLab도 인터넷이 완전히 차단된 오프라인 환경의 설치 절차를 공식 문서로 제공한다.

오해가 생기는 이유는 짐작이 간다. 많은 사람에게 Git의 첫 경험이 GitHub라서 "Git = GitHub = 외부 SaaS"로 묶여 기억되는 거다. 근데 이건 "이메일을 쓰려면 Gmail을 써야 한다"는 말과 같은 구조다. 프로토콜과 호스팅 서비스는 다른 층위이고, 이 구분이 이 논쟁 전체에서 제일 중요하다.

SVN은 소스가 서버 밖으로 안 나오는데 Git은 나온다?

둘 다 나온다. SVN도 checkout을 하면 소스가 개발자 PC에 내려온다. 그게 checkout이라는 동작의 정의다. SVN working copy에는 작업 파일과 별도로 원본 캐시(pristine copy)까지 로컬에 저장되는데, Apache SVN 1.8 릴리스 노트에 적혀 있는 동작이다.

"중앙집중형"은 이력의 원본이 서버 한 곳에 있다는 뜻이지 개발자에게 파일 사본을 주지 않는다는 뜻이 아니다. 사본 없이는 개발 자체가 안 된다. 그러니까 어느 도구를 쓰든 지켜야 할 대상은 같다. 서버와 단말, 둘 다다.

국내 공공 부문에서 Git을 실제로 쓰고 있나?

쓰고 있다. 공개 자료에서 Git 자체를 일괄 금지하는 규정은 확인되지 않았고, 정부가 직접 운영하는 사례가 세 가지 확인된다.

행정안전부의 공공 GitLab. 2026년 7월 2일 행안부는 「AI 정부 실험실」을 발표하면서 과제 문서·소스코드·프롬프트를 공공 GitLab으로 통합 관리한다고 밝혔다. 7월 22일 후속 자료에는 개발산출물이 공공 GitLab에 등록되어 관리된다고 명시되어 있다.

금융결제원의 폐쇄망 GitLab 조달. 2025년 6월 제안요청서는 GitLab Premium 250 사용자, 내부망(폐쇄망) 구축, 원내 클라우드 사용, 보안성 검토와 계약업체 책임, 소스코드 누출금지 특약을 함께 요구한다. 보안 요구가 강한 기관이 폐쇄망 Git 플랫폼과 접근통제·책임 관리를 양립시키는 조달 설계를 이미 해봤다는 뜻이다.

전자정부 표준프레임워크. eGovFrame 5.0 형상관리 가이드는 SVN과 Git을 나란히 대표적인 소스 버전관리 도구로 설명한다.

정확하게 적어두면, 이 세 자료가 "모든 기관에서 Git이 승인된다"를 뜻하지는 않는다. 행안부 사례는 인터넷망 시범운영으로 시작했고 정부 업무망 확장은 2027년 계획이다. 특정 사업 문서에 SVN이 지정되어 있다면 계약상 변경 절차는 별개로 밟아야 한다. 다만 "공공에서 Git은 원래 안 된다"는 일반화는 이 자료들 앞에서 유지되지 않는다.

정책 방향도 같은 쪽을 가리킨다. KISA가 2026년 6월 17일 발표한 국가 망 보안체계(N2SF)는 업무 정보를 기밀·민감·공개로 분류하고 등급별로 보안 수준을 적용한다. 도구 이름이 아니라 정보 등급과 처리 위치로 판단하는 체계다.

내부망 Git이 안전하려면 무엇을 갖춰야 하나?

SVN과 같은 수준의 통제를 유지하려면 설계 단계에서 두 가지를 정해야 한다. 여기서 얼버무리면 앞의 주장도 믿기 어려워지니 있는 그대로 적는다.

1. 개발 PC에 내려가는 이력의 범위를 정한다

기본 Git clone은 현재 파일뿐 아니라 도달 가능한 과거 이력 전체를 가져온다. 최신 버전에서 지운 코드가 과거 commit에는 남아 있다. SVN은 선택한 revision의 working copy만 받는 게 기본이다. 검증 과정에서 외부 접속 없이 로컬 더미 저장소, Git 2.51.1로 직접 확인했다.

• 파일을 commit했다가 삭제한 뒤 clone → 최신 작업 트리에는 없지만 과거 commit에서 읽을 수 있었다
• sparse checkout으로 일부 폴더만 표시 → 나머지 파일도 화면에서 사라질 뿐 Git 객체 조회로 읽을 수 있었다
• depth 1로 얕게 clone한 뒤 unshallow fetch → 이력이 다시 전부 늘어났다

그러니까 같은 단말이 침해됐을 때 노출될 수 있는 범위가 Git 쪽이 더 넓다. 침해 확률이 높아진다는 뜻은 아니다. 대응은 명확하다. 단말 보안을 SVN 때와 같은 수준으로 유지하고, 과거 commit에 들어간 비밀값은 파일 삭제가 아니라 자격증명 폐기·교체로 처리한다는 원칙을 세우면 된다. GitHub의 민감정보 제거 문서도 순서를 그렇게 안내한다. 폐쇄망이라면 이력이 단말 밖으로 나갈 경로 자체가 통제되어 있어 이 항목의 부담은 더 줄어든다.

2. 폴더별 읽기 권한은 저장소 분리로 옮긴다

SVN은 path 기반 authz로 한 저장소 안에서 경로별 읽기 권한을 나눌 수 있다. 외주 A사는 frontend만, B사는 backend만 읽게 하는 구성이다. 표준 Git은 읽기 권한을 저장소 단위로 준다. Git 공식 문서 스스로 namespace가 읽기 접근통제 수단이 아니라고 명시하고, 숨겨야 할 데이터는 다른 저장소에 두라고 권고한다.

해법은 저장소를 신뢰 경계별로 나누는 것이다. 지금 SVN authz에서 경계가 그어진 곳을 그대로 저장소 경계로 옮기면 되고, 그 이관 설계는 락 기반 형상관리에서 Git으로에서 다뤘다. 분리 설계가 끝나기 전까지 해당 저장소만 SVN을 병행하는 것도 합리적인 순서다. 한 번에 다 옮길 필요는 없다.

취약점 개수로 비교하면 되지 않나?

둘 다 실제 취약점이 있어서 개수로는 판단이 안 된다. Git 프로젝트는 2025년 7월 8일 CVE-2025-48385를 공지했다. 특정 bundle URI 기능에서 악의적 원격이 파일 기록 위치를 조작할 수 있는 문제였고, 수정 버전과 조건이 공지에 명시됐다. Apache는 SVN mod_dav_svn의 제어문자 처리로 서비스가 중단될 수 있는 CVE-2024-46901을 공지하고 1.14.5에서 수정했다.

제품 노출 면적, 설치 기반, 보고 관행, 패치 속도가 다 달라서 CVE 개수로 안전 순위를 매길 수 없다. 이 두 사례가 알려주는 건 어느 쪽을 쓰든 패치 반입 절차가 폐쇄망 운영의 필수 요건이라는 점이고, 이건 SVN을 운영해온 기관이라면 이미 갖추고 있는 절차다.

보안 심사에서는 무엇을 물어야 하나?

도구 이름 대신 네 가지 층위를 나눠서 물으면 된다.

"Git이냐 SVN이냐"는 첫 번째 층위만 건드린다. 실제 유출 사고의 경로는 대부분 나머지 세 층위에 있다. 개발자 PC 탈취, 권한 있는 직원의 외부 전송, 계정·토큰 탈취, 과거 commit에 남은 비밀값. 위협 시나리오별로 대조해보니 Git에만 해당하는 건 사실상 없었고, 대부분 "둘 다 가능하되 Git 쪽이 이력 범위가 넓다" 정도의 차이였다.

심사 자리에서 바로 쓸 수 있는 질문은 이 네 가지다.

• 제한하려는 대상이 Git 프로그램 자체인가, 외부 코드 저장 서비스인가, 단말 복제 범위인가? 근거 문서는 무엇인가?
• 현재 SVN에서 누가 어떤 경로와 과거 revision을 읽을 수 있는가? Git 전환 시 그 범위가 넓어지는가?
• 소스·이력·빌드 산출물·프롬프트의 허용 저장 위치와 실제 반출 경로는 무엇인가?
• 사고가 났을 때 인증 사용자, 다운로드, 승인 변경, 외부 반출을 각각 어떤 증거로 확인하는가?

마지막 질문에서 하나 짚을 게 있다. Git commit의 author 표시는 설정값이라 그 자체로는 신원 증명이 아니다. 책임 추적은 서버 쪽 인증·접근 기록으로 하면 되고, 설치형 Git 플랫폼은 그 기록을 기본으로 남긴다. 금융결제원 제안요청서가 계약업체·관리자 책임과 자료 반납·폐기를 특약으로 명시한 것처럼, 기록과 책임 배분은 도입과 함께 설계할 수 있다.

우리는 이 질문에 어떻게 답하나

CollabOps는 Git 기반이고 폐쇄망 설치를 기본 형상으로 지원한다. 미팅에서 "Git이라서 안 된다"는 말을 들을 때 실제로 하는 답은 이거다.

Git은 외부 클라우드를 전제로 하는 도구가 아니며 기관 내부 폐쇄망에 구축할 수 있다. 분산형 특성으로 과거 이력이 개발 환경에 복제되므로 단말 통제와 비밀값 교체 원칙을 함께 세우고, SVN의 폴더별 읽기 권한은 저장소 분리로 옮긴다. 그 위에서 코드의 등급, 저장·처리 위치, 반출 통제, 접근기록과 운영 책임을 검증하면 SVN과 같은 수준의 안전성을 갖춘다.

이 답의 뒷부분이 사실 우리 제품이 존재하는 이유와 닿아 있다. 네 층위 중 마지막인 운영과 증거 층위를 개별 도구 조합으로 만들면 이슈 트래커 따로, 저장소 따로, CI 따로, 감사 로그 수집 따로 붙여야 하고 연결부마다 증적이 끊긴다. 저장소·변경요청·파이프라인·배포 기록이 처음부터 한 평면에 있으면 "누가 승인했고 무엇이 나갔는가"가 일하는 행위의 부산물로 남는다. 보안 심사가 요구하는 게 정확히 그 기록이다.

물론 "설치형이라 안전합니다"라는 말도 도구 이름으로 안전을 주장하는 같은 오류다. 폐쇄망 완전 동작, 저장소 읽기 분리, 기존 SVN authz의 권한 이관, 계정·키 회수, 과거 비밀값 대응을 실제 시험과 증적으로 입증하는 게 공급사의 일이고, 검증 문서에는 14개 검수 항목으로 정리해뒀다. 통제를 주장하는 쪽이 시험으로 설명할 수 있어야 한다는 원칙은 우리한테도 똑같이 적용된다.

폐쇄망에서 SVN을 오래 무사고로 운영해온 보안 담당자라면 이 질문들을 계속 던지는 게 맞다. 그 질문에 도구를 파는 쪽이 어떻게 답해야 하는지는 SVN 잘 쓰고 있는데 왜 바꿔야 하나요에서 이어진다. 요구할 것은 도구의 이름이 아니라 검증의 증거이고, 내부망 Git은 그 증거를 내놓을 수 있는 구성이다.