공공기관은 왜 SVN을 계속 쓰는가, 안정성이 곧 레퍼런스라는 말

어느 공공기관 실장님이 말했다. SVN 왜 쓰냐고? 내부에서 힘들다고 해도 안정적이라 쓰는 거다. 안정성이 제일 중요하다. 그것이 레퍼런스다. 공공 도입의 실제 의사결정 구조와, 벤더가 그 앞에서 해야 할 일에 대해.

백재민
백재민
CollabOps 창업자
공공기관은 왜 SVN을 계속 쓰는가, 안정성이 곧 레퍼런스라는 말

한 공공기관에서 발표를 마쳤을 때, 그쪽 실장님이 마무리 말씀으로 이런 얘기를 했다.

"저희는 레퍼런스가 중요합니다. SVN 이런 거 왜 쓰냐고요? 내부에서 힘들다고 해도 안정적이라 쓰는 겁니다. 안정성이 제일 중요해요. 그것이 레퍼런스입니다."

기술 영업을 하는 입장에서는 그 무게를 그 자리에서 알아차리기 어려운 종류의 말이다. 우리 제품이 얼마나 현대적인지 말하고 싶은 자리에서, 상대는 20년 된 형상관리 도구를 계속 쓰는 이유를 설명하고 있으니까. 그런데 돌아와서 곱씹을수록 이 말이 공공 IT 도입의 의사결정 구조를 가장 정확하게 요약하고 있다는 생각이 들었다.

공공기관이 SVN을 계속 쓰는 진짜 이유

공공기관이 SVN 을 계속 쓰는 이유는 게으름도 무지도 아니고, 검증된 안정성이 다른 모든 가치보다 우선하기 때문이다. 그 조직에 Git 을 아는 사람이 없어서가 아니다. 내부 개발자들도 힘들다고 한다. 그런데도 안 바꾼다. 20년 동안 사고를 안 낸 도구라는 사실이, 새 도구가 줄 수 있는 어떤 생산성보다 무겁기 때문이다.

이 계산은 공공의 인센티브 구조를 생각하면 합리적이다. 민간 기업에서 생산성 20% 향상은 성과다. 공공에서 장애 한 번은 감사이고, 보도자료이고, 어쩌면 국정감사다. 얻는 것의 상한은 낮고 잃는 것의 하한은 깊은 구조에서, 보수적인 선택은 비합리가 아니라 최적해다.

같은 미팅에서 나온 또 하나의 말이 이 구조를 완성한다. "공공이기 때문에 SLA 는 중요하지 않습니다. 장애는 전혀 고려하지 말고, 대비책을 준비해서 제시해야 합니다." 처음 들으면 이상하다. SLA 가 중요하지 않다니. 그런데 뜻은 이렇다. 99.9% 같은 확률적 보장은 필요 없고, 장애가 났을 때 무엇을 할 것인지가 문서로 준비되어 있어야 한다는 것. 보상 조항이 아니라 대비책. 확률이 아니라 절차.

그러면 벤더는 무엇을 해야 하나

벤더가 이 구조 앞에서 해야 할 일은 기능 데모가 아니라 안정성의 증거를 만드는 일이다. 우리가 실제로 하고 있는 것들을 적어 보면 이렇다.

첫째, 기능 로드맵보다 대비책 문서를 먼저 만든다. 장애 시나리오별 복구 절차, 데이터 백업과 복원 경로, 롤백 절차. 화려하지 않지만 공공 담당자가 내부에서 검토를 통과시키려면 이게 있어야 한다. 담당자는 우리 제품의 팬이 되어서 도입하는 게 아니라, 내부에서 방어 가능한 선택을 하는 것이다.

둘째, 인증을 쌓는다. GS 인증 1등급을 받았고 조달청 나라장터에 등록되어 있다. ISO 관련 인증도 준비하고 있다. 인증이 품질을 보장하느냐는 논쟁은 있을 수 있지만, 공공 도입에서 인증은 품질 증명이 아니라 책임의 근거다. 담당자가 "검증된 절차를 따랐다"고 말할 수 있게 해 주는 것.

셋째, 책임 주체를 분명히 한다. 외산 오픈소스의 문제는 기능이 아니라, 문제가 생겼을 때 책임지고 달려올 사람이 없다는 것이다. 국산 자체 기술로 제공하고 문제가 있으면 오너인 내가 책임진다고 미팅에서 직접 말하는 이유가 이거다. 과장이 아니라, 공공 담당자가 실제로 확인하고 싶어 하는 항목이기 때문이다.

넷째, PoC 를 권한다. 그 실장님도 결국 "써 봐야 알 것 같다, 내부 개발 인력들과 검토하겠다"고 했다. 맞는 순서다. 안정성은 발표 자료로 증명되는 게 아니라 그쪽 환경에서 몇 달 돌아간 기록으로 증명된다. 레퍼런스가 없으면 만들 기회를 달라고 하는 수밖에 없고, 그 기회가 PoC 다.

SVN에서 현대적인 스택으로, 언제 어떻게 넘어가나

SVN 에서 현대적인 형상관리로 넘어가는 전환은 안정성이 증명되는 속도만큼만 진행하는 게 맞다. 빅뱅 전환을 밀어붙이는 벤더는 공공의 인센티브 구조를 이해하지 못한 것이다.

한 팀, 한 시스템에서 시작해서 사고 없이 돌아간 기간 자체를 다음 단계의 근거로 쓴다. 6개월 무사고가 내부 보고서의 한 줄이 되고, 그 한 줄이 다음 팀의 도입 품의를 통과시킨다. 느려 보이지만 이 경로만이 실제로 끝까지 간다. 반대로 초기에 작은 사고 하나가 나면 프로젝트 전체가 몇 년 뒤로 밀린다. 그래서 초기 범위는 보수적으로 잡을수록 좋다.

우리 같은 벤더 입장에서 이 글의 결론은 자기 훈련에 가깝다. 공공 미팅에서 "저 조직은 왜 저렇게 보수적이지"라는 생각이 들 때마다 그 실장님 말을 떠올린다. 안정성이 곧 레퍼런스다. 그 기준을 통과하는 게 우리 일이지, 그 기준을 바꾸는 게 우리 일이 아니다.

태그#public-sector#svn#stability#reference#adoption