중앙집중이란 가치와, 그에 맞선 분산의 효율성, 이 두가지의 변증과 어울림은 지금 디지털 시대에서도 가장 문제적인 문제다. 개발 플랫폼의 최적화를 위한 데브옵스(DevOps) 국면에서도 그렇다. 중앙집중형(CVCS) 버전관리냐, 분산형(DVCS)이냐가 화두가 되고 있는 판국이다. 다만 이는 상호 대립된 선택지로만 볼 일은 아니다. 개발과 운영, 양자 간에 신뢰의 메시지를 실어나를 네트워크 언어를 찾는 작업이라고 해야 맞다.
애당초 ‘분산’은 독점적 매개자의 일방적 독주에 대한 제동에서 탄생했다. 중앙집권, 과잉통제, 자율과 존재를 억제하는 권력행위에 대한 응당한 질문에서 생겨난 것이다. 잘만 되면 분산된 신뢰에 바탕을 둔 새로운 물리적․정신적 이노베이션을 기대할 만하다. 그런데 다시 되짚어보면 전혀 다른 해석도 가능하다. 이형동질(異形同質)의 가치라고 할까. ‘분산’이란 것 역시 본질적으론 그 무엇으로 수렴되는 ‘통합’과 화해하기 위한 과정이라고 해야겠다.
최근의 데브옵스 생태계를 바라보는 경험자들 의견도 이와 비슷하다. 중앙집중형과 분산형관리 양자가 결국은 정반합의 수렴으로 모아진다는 것이다. 다시 말해 일도양단 격의 이분법적 선택이 아니라, 융합에 가까운 탄력적 섞임이다. 물론 코드나 패키지, 라이브러리, 자동화 수준, 콘테이너 운용 등에 따라 양자의 쓰임새는 일단 달라진다.
일단 파일이나 데이터 사용자가 많다면 분산형, 즉 DVCS가 적합하다. 반면에 사용자의 위치(로케이션)가 널리 분산되어있다면, 이에 맞는 중앙집중형 소스버전툴인 ‘퍼포스’(Perforce)에 의한 CVCS가 적당하다. 큰 파일을 동기화하거나, 클로닝을 여러 번 반복할 때, 또 파일이 크고 많거나, ‘레포’(Repogitory)가 클 때도 역시 CVCS가 안전하다. 반면에 분산형은 중앙서버 중심의 CVCS가 갖는 치명적 리스크를 미연에 방지한다. 사용자들이 아예 파일 저장소를 통째로 복제해서 서버를 내것마냥 사용하므로 중앙 서버에 문제가 생겨도 관계없다. 복제해둔 저장소(레포)를 다시 서버에 복사하고, 그 안에서 데이터를 복원하면 된다.
그러나 요즘은 양자를 병행하는게 좋다는 의견이 늘어나고 있다. 그 이유도 다양하다. “중앙저장소 방식과 분산관리 두 가지를 모두 사용해보니 그렇게 편리할 수 없다”는 경험담도 있고, “일부 양심불량형 참여자들을 저지하기 위해서”라는 의견도 있다. 분산형 DVCS를 쓰다보니 어떤 오픈소스 사용자들은 실행 중인 프로세스의 복사본(클론)을 과다하게 만들곤 한다. 만인 공유라는 오픈 소스 프로젝트와는 엇나간 ‘일탈’인 셈이다. 기존의 CVCS에선 그래서 표준 코드베이스를 중앙 서버에 저장하거나, 개발자들이 코드의 현재 상태를 ‘체크(인)’한 후 변경하도록 함으로써 이런 행동을 제어하고 있다.
이에 많은 오픈 소스 프로젝트는 CVCS에 의존하면서도 DVCS의 장점을 접목하고 있다. ‘분산 처리를 통해 획득하려는’ 작동 방식과 유사한 방식으로 중앙서버 저장소를 유지 관리하는 것이다. 프로젝트 특성에 따라선 중앙집중과 분산형 양자의 장단점이 교차하기도 한다. 그래서 “두 가지를 특성에 맞게 사용하는게 좋다.”는 업계 현장의 목소리가 자연스럽게 들리는 요즘이다.
시야를 넓혀보면 이는 또 다른 융합의 연속이다. 물론 그 과정에선 양자의 선택적 효용이 최대한으로 발현되어야 한 것이다. 중앙으로의 맹목적 수렴이 아닌, 계몽되고 지각된 신뢰, 즉 분산의 에너지가 작동하는게 옳다. 또 다른 한편으론 분산된 기능에 그치지 않고, 개발과 운영이 최적의 ‘통합’을 이루며 하나의 가치사슬을 형성해야 한다. 곧 개발과 운영 간의 협업을 통해 객체인 ‘타자’를 주체화하는 태도, 즉 융합의 수준이 중요한 것이다. 이는 곧 ‘분산되고 통합된 신뢰’의 조건으로 치환되면서 데브옵스의 성패마저 결정하게 된다.