형상관리 솔루션을 바꾸면 배포까지 따라오나요 — 교체 범위에 대한 질문
형상관리 도구 교체를 검토하는 기관이 묻는다. 형상관리 외에 배포까지 해주는지, 그리고 어디에 설치되는지. 저장소·변경요청·파이프라인·배포가 한 평면에 있다는 것의 의미와, UNIX 설치 질문에 대한 정직한 답.
형상관리 도구 교체를 검토하는 기관과 미팅을 하면 질문이 보통 이 순서로 나온다. "형상관리 외에 배포까지 해주나요?" 그리고 바로 이어서, "저희 서버에 설치는 되나요? UNIX 도 씁니다만."
첫 질문은 우리 제품의 정체성에 대한 질문이고, 두 번째는 현실의 기계실에 대한 질문이다. 둘 다 답할 가치가 있어서 이 글로 정리한다.
형상관리만 바꾸는 건가, 배포까지 오는 건가?
배포까지 온다. 정확히 말하면 CollabOps 는 형상관리 솔루션의 대체재가 아니라, 이슈·저장소·변경요청·파이프라인·배포·감사 로그가 처음부터 한 평면에 있는 플랫폼이다. 형상관리는 그 평면의 한 조각이다.
이 구분이 왜 중요하냐면, "형상관리 + 배포"를 별개 도구 두 개로 갖추는 것과 한 평면으로 갖추는 것은 연동의 방향이 다르기 때문이다. 도구 두 개면 누군가 그 사이를 API 와 웹훅으로 이어야 하고, 그 연동은 관리 대상이 된다. 한 평면이면 변경요청 승인이 곧 배포 게이트의 입력이다. 검토를 통과한 코드가 자동으로 빌드되고 배포되고, 실행 로그가 실시간으로 보이고, 실패하면 단계별 원인이 변경요청과 이슈에 그대로 연결된다. 이 구조 위에서만 성립하는 것들이 있다. 이 논리는 폭포수 SI 글에서 길게 썼으니 여기서는 배포 쪽 디테일에 집중한다.
참고로 기존 CI 서버를 이미 운영 중이라면 버릴 필요는 없다. 자체 실행 엔진(쿠버네티스 파드로 파이프라인을 실행하는 구조)과 별개로, 기존 빌드 서버를 플랫폼에 연결해서 변경요청·리뷰·배포 승인·감사 로그만 한 평면으로 올리는 공존 구성도 된다. 이주와 공존 중 뭐가 맞는지는 마이그레이션 vs 인테그레이션에서 다뤘다.
배포는 어떻게 통제되나?
배포는 환경별로 분리되고, 운영 배포는 게이트 조건을 전부 충족해야만 실행된다. 개발/스테이징/운영 환경이 나뉘어 있고, 운영으로 가는 배포에는 조건이 걸린다. 변경요청 승인자 수 충족, 테스트 성공, 보안 스캔 통과, 변경 승인, 운영자 승인, 롤백 계획 존재, 배포 시간대 승인. 공공형 DevSecOps 요건을 그대로 게이트로 옮긴 구성이다.
배포가 나간 뒤의 이야기도 있다. 모든 배포는 감사 로그에 남고, 문제가 생기면 롤백한다. 어떤 변경요청이, 누구 승인으로, 어느 환경에 나갔는지가 조회 가능한 기록으로 남는 것. 형상관리 교체를 검토하던 기관이 실제로 얻게 되는 건 이 증적 체인이다.
UNIX 서버에도 설치가 되나요?
플랫폼 자체는 UNIX 에 설치되지 않는다. Linux 컨테이너 기반이라서다. 이건 흐리게 답하고 싶지 않은 부분이다. CollabOps 는 쿠버네티스(또는 단일 VM 의 경량 구성)에 컨테이너로 배포되고, 최소 요구는 VM 1대, 8 vCPU, 16 GB 메모리, 200 GB 디스크다. 여기서 용어를 하나 정리하고 가자. Red Hat(RHEL) 계열, Ubuntu, Rocky 같은 주요 Linux 배포판은 전부 지원 범위다. Linux 는 UNIX 가 아니고, 컨테이너 기반이라 배포판을 가리지 않는다. 지원하지 않는 건 AIX 나 Solaris, HP-UX 같은 진짜 UNIX 계열이다. CPU 아키텍처부터 다르고 컨테이너 생태계가 없는 세계라, 여기에 플랫폼을 직접 올리는 구성은 지원하지 않는다.
다만 질문을 한 겹 벗기면 대개 진짜 질문은 따로 있다. "우리 시스템이 UNIX 에서 도는데, 그 소스도 관리가 되고 거기로 배포도 되나?" 이건 별개의 문제다. 플랫폼이 설치되는 서버와 배포가 도착하는 서버는 다르다. UNIX 에서 운영되는 시스템의 소스를 Git 으로 관리하고, 빌드하고, 그 결과물을 해당 서버로 내보내는 것은 플랫폼 설치 위치와 무관하게 성립한다. 미팅에서 이 두 질문이 하나로 뭉쳐서 나오는 경우가 많은데, 분리해서 보면 답이 명확해진다. 플랫폼용 Linux VM 한 대를 어디서 확보하느냐가 실질적인 숙제이고, 우리가 본 대부분의 기관에서 이건 문제가 아니었다.
정리 대신 현실적인 조언 하나. 형상관리 교체를 검토 중이라면 "형상관리 도구"를 바꾸는 프로젝트로 범위를 잡지 말고, 변경이 승인을 거쳐 운영에 도달하는 경로 전체를 놓고 비교하는 걸 권한다. 도구 하나를 바꾸는 비용은 비슷한데, 전자로 잡으면 배포와 증적은 여전히 남의 일로 남는다.
비슷한 글
커넥터를 다 만들어 놓고 왜 마이그레이션을 권하는가
깃랩, SVN, 젠킨스를 쓰고 있는데 연동이 되냐는 질문을 매번 받는다. 된다. 그런데도 우리는 마이그레이션을 권한다. 연동이 옮기는 것과 옮기지 못하는 것, 그리고 어떤 경우에는 연동이 맞는지에 대해.
백재민
CollabOps Q2 2026 릴리스 노트 — 4 개 메이저 + 12 minor
Q2 의 4 메이저 출시 (AI 에이전트 GA, 통합 마켓플레이스 베타, OpenShift Operator, FIPS-validated 빌드) + 12 minor 변경의 정리.
백재민
CollabOps CLI 투어 — 한 화면에 보는 우리 제품
GUI 데모는 *5분*. CLI 투어는 *30초*. 우리 제품의 멘탈 모델이 가장 빨리 전달되는 도구.
백재민