왜 “그대로 옮기면 된다”가 실패하는가
클라우드에서 잘 돌던 Jenkins·GitLab·SonarQube·Nexus·Harbor 조합을 온프레미스 폐쇄망으로 그대로 옮기는 프로젝트를 여러 번 진행했습니다. 매번 초기 견적은 “설치만 하면 된다”였고, 매번 실제 공수는 예상의 2배 이상이었습니다. 원인은 도구 자체가 아니라, 클라우드에서는 보이지 않던 암묵적 의존성이 폐쇄망에서 하나씩 끊어지기 때문입니다. 이 글은 SmartDevOps류 플랫폼을 온프레미스로 옮길 때 실제로 깨지는 지점을 순서대로 정리한 것이며, 특정 제품의 마케팅 스펙 비교가 아닙니다.
클라우드에서는 안 보이던 것들이 첫 주에 터집니다
가장 먼저 걸리는 것은 외부 인터넷 의존성입니다. Jenkins 플러그인 업데이트 센터, npm/PyPI/Maven Central, Docker Hub, GitHub Actions 마켓플레이스 — 이 모든 것이 클라우드 환경에서는 당연히 열려 있던 경로입니다. 폐쇄망에서는 이 경로가 전부 막힙니다. 두 번째는 라이선스 서버의 “전화 걸기(phone-home)” 문제입니다. 일부 상용 도구는 주기적으로 외부 라이선스 서버에 접속해 유효성을 검증하는데, 이 트래픽이 차단되면 도구가 그레이스 기간 이후 잠깁니다. 세 번째는 인증서 신뢰 체계입니다. 클라우드 관리형 서비스가 자동으로 처리해주던 TLS 인증서 발급·갱신(Let’s Encrypt, ACM 등)을 내부망에서는 사내 CA로 직접 구성해야 하고, 이 사내 CA 루트 인증서를 CI 러너, 컨테이너 런타임, 각 도구의 신뢰 저장소에 개별적으로 배포하지 않으면 TLS 핸드셰이크 실패가 산발적으로 발생합니다.
| 영역 | 클라우드에서 당연했던 것 | 온프레미스에서 직접 구성해야 하는 것 |
|---|---|---|
| 패키지 의존성 | 공개 레지스트리 직접 접근 | Nexus/Artifactory 내부 미러 + 정기 동기화 배치 |
| 컨테이너 이미지 | Docker Hub·ECR·GCR 직접 pull | Harbor 등 내부 레지스트리 + 이미지 서명 검증 |
| TLS 인증서 | 관리형 서비스가 자동 발급·갱신 | 사내 CA 발급 + 각 노드 신뢰 저장소 수동 배포 |
| 비밀 관리 | 클라우드 KMS/Secrets Manager | Vault 등 자체 운영 + 초기 봉인(unseal) 절차 별도 관리 |
| 가용성 확보 | 가용영역·오토스케일링으로 자동 처리 | 물리 서버 이중화, 스토리지 IOPS 직접 산정 |
구현에서 실제로 손이 많이 가는 4단계
여러 프로젝트에서 반복적으로 거친 순서를 그대로 옮기면 다음과 같습니다.
# 1. 내부 미러 구성 (예: Nexus 3 기준 프록시 리포지토리) nexus3 repo create maven-proxy internal-maven \ --remote-url https://repo.maven.apache.org/maven2/ \ --blob-store default # 2. 폐쇄망 반입 절차 - 반입 서버에서 이미지를 tar로 export docker save myregistry/app:1.2.0 -o app-1.2.0.tar # 보안 검토(백신 스캔, 취약점 스캔) 후 매체 반입 # 내부망에서 import docker load -i app-1.2.0.tar docker push internal-harbor.local/app:1.2.0 # 3. CI 러너의 신뢰 저장소에 사내 루트 CA 배포 cp internal-root-ca.crt /usr/local/share/ca-certificates/ update-ca-certificates # 4. Vault 초기 봉인 해제 - 키 조각을 서로 다른 인원이 분산 보관 vault operator init -key-shares=5 -key-threshold=3
이 중 실무에서 가장 시간이 오래 걸리는 것은 2번 반입 절차입니다. 보안 정책상 매체 반입 심사에 며칠이 걸리는 조직이 많고, 이 지연을 감안하지 않고 배포 일정을 잡으면 첫 배포부터 일정이 밀립니다.
보안 요건이 아키텍처를 바꾸는 지점
ISMS-P 인증이나 공공기관 보안 감사를 받는 환경이라면, 망분리 요건이 도구 선택 자체를 제약합니다. 예를 들어 SaaS 형태로만 제공되는 코드 스캔 도구는 애초에 후보에서 제외되고, 온프레미스 설치형 대안(SonarQube 자체 호스팅, Trivy 오프라인 데이터베이스 등)으로 대체해야 합니다. 취약점 스캐너의 CVE 데이터베이스도 외부 업데이트가 끊기므로, 별도의 오프라인 업데이트 파이프라인(반입 서버에서 최신 DB를 받아 내부로 옮기는 절차)을 만들어야 스캔 결과가 최신 취약점을 반영합니다. 이 파이프라인을 빼먹고 “스캔은 통과했다”고 보고하면, 실제로는 몇 달 전 취약점 DB로 검사한 결과일 수 있습니다.
오프라인 취약점 DB 갱신 파이프라인 예시
반입 서버(인터넷 가능)에서 Trivy DB 번들을 내려받아 무결성 체크섬을 확인한 뒤, 보안 검토를 거쳐 망분리 반입 절차로 내부망 스캐너에 전달하는 흐름이 일반적입니다. 이 주기를 주 단위로 고정하고, “마지막 갱신일”을 스캔 리포트에 함께 출력하도록 설정하면 감사 시점에 “이 스캔이 최신 DB 기준인가”라는 질문에 즉시 답할 수 있습니다.
온프레미스 전환의 총소유비용(TCO) — 라이선스만 보면 안 되는 이유
| 비용 항목 | 클라우드 SaaS | 온프레미스 전환 후 |
|---|---|---|
| 라이선스/구독료 | 사용량 기반, 예측 어려움 | 고정 라이선스 또는 무료(OSS), 대체로 절감 |
| 인프라 운영 인력 | 관리형 서비스가 대행 | 패치·백업·장애복구 전담 인력 신규 필요 |
| 장애 대응 시간 | 벤더 SLA로 커버 | 내부 당직 체계, 야간 대응 비용 발생 |
| 하드웨어 감가상각 | 해당 없음 | 3~5년 주기 서버·스토리지 교체 비용 |
| 보안 인증 대응 | 벤더가 상당 부분 제공 | 내부 문서화·증적 관리 공수 증가 |
라이선스 비용 절감분만 놓고 전환을 결정하면, 표의 나머지 네 항목이 뒤늦게 드러나며 총비용이 오히려 늘어나는 경우가 흔합니다. 전환 검토 단계에서 최소 3년 TCO를 항목별로 산정해 비교하는 것을 권장합니다.
한계와 제언
온프레미스 전환은 클라우드 대비 운영 인력 부담이 명확히 늘어납니다. 관리형 서비스가 대신 해주던 패치, 백업, 장애 복구를 전부 내부 팀이 맡아야 하기 때문입니다. 이 부담을 과소평가하고 “라이선스 비용만 아끼면 된다”는 논리로 전환을 결정하면, 운영 인력 증원 비용이 라이선스 절감분을 상쇄하는 경우를 여러 번 봤습니다. 전환을 결정했다면, 최소 1개월은 반입 절차·CA 배포·오프라인 업데이트 파이프라인 같은 “보이지 않는 인프라”에 배정하고, 애플리케이션 배포는 그 이후 일정으로 잡는 것을 권장합니다.
2주차에 깨지는 운영 단위
설치가 끝나도 파이프라인은 살아 있지 않습니다. 러너 이미지가 매주 최신을 받으면, 지난주 통과한 빌드가 이번 주 플러그인 해시 때문에 실패합니다. 폐쇄망에서는 “최신”이 미덕이 아닙니다. 러너 베이스 이미지 태그를 고정하고, 갱신은 반입 티켓과 같이 갑니다.
| 단위 | 클라우드에서 숨겨진 것 | 온프레에서 누가 책임지나 |
|---|---|---|
| 롤백 | 이전 리비전 클릭 | 이미지 태그 + DB 마이그레이션 짝 |
| 러너 | 에페메럴 자동 스케일 | 고정 이미지, 디스크, 동시 잡 수 |
| 봉인 해제 | 관리형 KMS | 키 조각 3/5와 당직 순서 |
| 로그 | 오브젝트 스토리지 무기한 보관 | 일수와 디스크 경보 |
롤백이 이미지가 아닌 이유
애플리케이션 이미지만 되돌리면 스키마가 앞으로 가 있는 경우가 많습니다. 배포 단위는 “이미지 태그 + 마이그레이션 버전 + 설정 해시” 세 줄입니다. 이 세 줄이 같은 변경 티켓에 없으면, 장애 밤에 일부만 되돌리고 나머지를 수동으로 맞춥니다. Vault unseal 키를 한 사람이 USB에 모아 두면, 그 사람이 휴가를 간 주말에 배포가 멈춥니다. 키 조각은 인원이 아니라 역할로 나눕니다.
품질 게이트와 보안 게이트를 한 Job에 묶으면, 보안 서명이 늦은 날 단위 테스트까지 다시 돕니다. 게이트는 실패 원인을 로그 한 줄로 나눌 수 있어야 합니다. 사내 CA를 러너에만 넣고 빌드 컨테이너에 안 넣으면, 파이프라인은 통과하고 런타임에서 TLS가 끊깁니다. 인증서 배포 체크리스트에 호스트와 컨테이너를 같은 항목으로 적으십시오.
조직 구조 — 온프레 DevOps 전환 후 누가 무엇을 책임지는가
클라우드에서는 인프라 운영을 벤더가 대행했지만, 온프레미스에서는 역할을 명시적으로 나누지 않으면 장애 시 “누가 봐야 하는지” 자체가 불명확해집니다. 최소한 다음 네 역할은 별도 담당자(또는 로테이션 당직)로 지정하는 것을 권장합니다.
- 미러·반입 담당: 패키지·이미지 반입 주기 관리, 반입 티켓 처리
- 인증서·비밀 관리 담당: 사내 CA 갱신, Vault 운영, unseal 키 조각 보관
- 파이프라인 담당: CI/CD 러너 이미지 버전 관리, 게이트 구성
- 인프라 당직: 물리 서버·스토리지 장애 1차 대응
Takeaway
- 온프레미스 전환의 실패 지점은 도구 기능이 아니라 외부 연결에 암묵적으로 의존하던 부분입니다.
- 패키지 미러, 이미지 반입, 인증서 배포, 비밀 관리는 클라우드에서는 보이지 않던 별도 구축 항목입니다.
- ISMS-P·망분리 요건은 도구 선택 자체를 제약하므로 프로젝트 초기에 보안 요건부터 확정해야 합니다.
- 라이선스 비용만 비교하지 말고, 늘어나는 운영 인력 비용을 총소유비용에 포함해 검토하십시오.
- 오프라인 취약점 DB 갱신 파이프라인 없이 “스캔 통과”를 보고하면 실제로는 오래된 기준으로 검사한 결과일 수 있습니다.
- 전환 후에는 미러·반입, 인증서·비밀 관리, 파이프라인, 인프라 당직 네 역할을 명시적으로 나눠야 장애 대응이 가능합니다.