백서 다운로드 — 본사업 전에 전환 범위와 공수를 확정하는 기준
「클라우드 네이티브 전환 사전 진단 컨설팅 백서」는 전환의 기본을 컨테이너 전환으로 두고 가상화(VM) 전환을 사유가 확인된 예외로 다루는 원칙에서 출발합니다. 사전 진단은 그 예외 목록과 컨테이너 전환 공수를 본사업 전에 확정하는 절차이며, 근거는 공공 발주 문서의 조항과 공개 기술 문서에서 가져왔습니다.
분량은 101쪽이고 8장과 도식 18개로 구성했습니다. 1장부터 4장까지는 견적이 어긋나는 원인, 진단 다섯 단계, 현황 체크리스트 13개 분류, Story Point 기반 공수 산정을 다룹니다. 5장부터 8장까지는 지원 종료 일정, 컨테이너 우선 판정 기준과 예외 사유, 발주 문서에 없는 정량 기준, 진단 이후의 추진 순서를 다룹니다.
주 독자는 상세설계나 본사업 발주를 앞둔 기관의 의사결정권자와 정책결정권자, IT 담당자입니다. 여덟 장 전문은 아래 버튼에서 PDF로 내려받을 수 있습니다.
MSAP.ai 백서 구독하기🔔
새로운 백서 소식을 가장 먼저 만나보세요!
MSAP.ai 가 전하는 AI 기반 운영 인사이트와 최신 백서 소식을 가장 빠르게 받아보실 수 있습니다.
구독해 주시면 더 좋은 콘텐츠로 보답하겠습니다.🙏
영상으로 먼저 보기
컨테이너 전환을 기본으로 두는 근거 가운데 하나는 기동 속도입니다. NIA 발주자 안내서의 비교표에 따르면 컨테이너는 크기가 MB 단위이고 즉시 기동되며, VM은 GB 단위이고 기동에 수 분이 걸립니다.
파드(Pod)는 Kubernetes가 컨테이너를 배치하고 관리하는 최소 단위입니다. 아래는 쿠버네티스 파드가 초 단위로 기동하는 이유를 설명한 클라우드네이티브TV 영상입니다.
이 백서가 답하는 여덟 가지 질문
백서는 장마다 질문 하나에 답합니다.
- 어느 클라우드에 둘지만 정한 계획은 왜 본사업에서 범위와 비용이 어긋나는가
- CNTA는 무엇에 답하고 어떤 절차와 산출물로 진행되는가
- 정성 조사와 코드 정적 분석은 각각 무엇을 재고 어떻게 합쳐지는가
- Story Point 등급은 무엇을 뜻하고 공수와 공공 대가 산정에는 어떻게 이어지는가
- Java·WAS·OS 버전을 그대로 둔 컨테이너 전환은 왜 성립하지 않는가
- 어떤 대상이 컨테이너로 가고 어떤 사유가 확인될 때만 가상화 전환을 허용하는가
- 발주 문서와 가이드는 무엇을 사업자에게 넘기고 사전 진단은 그중 무엇을 미리 확정하는가
- 진단 결과로 어떤 대상부터 옮기고 본사업을 어떻게 나눠 추진하는가
3주 진단이 200일 상세설계와 600일 본사업의 범위를 정하는 구조
전환 계획은 대상을 어느 클라우드에 둘지를 기준으로 예산을 편성해 왔습니다. 이 방식은 서버 이전비와 이용료는 계산하지만 코드와 미들웨어, 데이터의 수정 범위는 계산에 넣지 않습니다. 2025년에 공고된 한 지방교육청의 본사업 제안요청서도 서버 38식과 소프트웨어 132식을 품명으로만 실었습니다.
정부가 공개한 전환 사업 발표 자료도 이미 클라우드로 이전을 마친 시스템에 한계가 남아 있었다고 밝혔습니다. 클라우드로 옮기는 일과 클라우드 네이티브로 전환하는 일은 별개의 과제이므로, 어디에 둘지를 정하는 계획과 애플리케이션을 얼마나 고칠지를 정하는 계획은 따로 세워야 합니다.
클라우드 네이티브 전환 사전 진단은 3주 안팎의 작업인 반면 상세설계는 200일에 3개 시스템 약 13억 3천만 원, 본사업은 600일에 3개 시스템 약 46억 원 규모입니다. 즉 3주 진단의 결과가 수십억 원 규모 사업의 범위와 예산을 정하는 근거가 됩니다(백서 1장).
▲ 사전 진단, 상세설계, 본사업의 기간과 단계별 확정 항목 (백서 10쪽)
| 예산 항목 | 위치 중심 계획 | 사전 진단 기반 계획 |
|---|---|---|
| 코드 수정비 | 항목 없음 | 이슈별 난이도 점수와 작업 일수 |
| 미들웨어 교체비 | 항목 없음 | WAS 종속 코드의 수정 범위 |
| 가상화 예외 대상 | 구분 없음 | 사유와 재검토 시점을 기록한 목록 |
사전 조치에서 결과 공유까지 3주로 구성하는 CNTA 다섯 단계
CNTA는 사전 조치, 현황 분석, 목표 모델링, 전환 전략 수립, 결과 공유의 다섯 단계로 진행하며 단계마다 기관이 받는 산출물이 정해져 있습니다. 시스템 한 묶음을 대상으로 하면 3주로 구성할 수 있고, 1주차에 현황 파악과 1차 진단, 2주차에 서비스 분리 타당성 검토와 시범 전환 후보 선정, 3주차에 결과 통합과 로드맵 초안 작성을 수행합니다. 넷째 단계인 전환 전략 수립에서 컨테이너 전환 공수와 가상화 예외 목록이 함께 정해집니다. 다만 3주는 하나의 구성 예이므로 실제 기간은 대상 시스템의 수와 규모에 맞춰 조정합니다(백서 2장).
▲ 사전 진단 CNTA의 다섯 단계와 단계별 활동·산출물 (백서 15쪽)
인프라 5개·애플리케이션 7개·규모 1개로 나뉘는 체크리스트 13개 분류의 구조
클라우드 네이티브 전환 사전 진단은 전환대상기관이 현황 체크리스트를 작성하는 단계에서 시작하며, 체크리스트는 13개 대분류로 구성됩니다. 인프라 영역의 다섯 분류는 서버 구성과 WAS 상세, 성능 등을 물어 컨테이너 자원 산정과 세션 처리 방식 결정에 쓰입니다. 애플리케이션 영역의 일곱 분류는 코드 수정 범위와 예외 판정에 쓰이고, 규모 영역인 애플리케이션 상세는 JSP·Servlet·EJB 개수를 물어 공수와 기간 산정의 입력이 됩니다. 계약특수조건도 전환대상기관에 체크리스트의 최종 확인 의무를 두므로, 진단 단계에서 작성해 두면 본사업에서 다시 쓸 수 있습니다(백서 3장).
▲ 현황 체크리스트 13개 대분류의 세 영역 구성과 각 영역의 쓰임 (백서 24쪽)
정적 분석이 읽지 못하는 네 항목을 설문으로 보완하는 판정 방식
정적 분석(실행 없이 소스와 배포 파일을 규칙으로 검사하는 방법)은 하드코딩된 경로와 IP, 로컬 파일 입출력, 독점 API와 특정 OS 의존을 줄 단위로 검출합니다. 반면 세션 처리 방식, 벤더의 컨테이너 지원 여부, 하드웨어·커널 의존, 적용 규제는 코드에 적혀 있지 않아 설문과 인터뷰로만 확인됩니다. 그래서 두 결과를 항목별로 대조한 뒤 애플리케이션마다 컨테이너 전환을 기본으로 수정 항목과 공수를 정리합니다. 분석 도구 CNAMT(Cloud Native Application Migration Toolkit)의 정식 지원 언어는 Java이므로 C·PHP·ASP 코드는 수작업으로 진단합니다(백서 3장).
▲ 체크리스트 조사(정성)와 정적 분석(정량)을 합쳐 애플리케이션별 전환 가능 여부를 판정하는 흐름 (백서 31쪽)
937점에 5일, 한 자릿수 점수에 27일이 산정된 Story Point 사례
Story Point는 분석 도구가 이슈 한 건마다 수정에 드는 노력을 0·1·3·5·7·13점으로 매긴 점수입니다. 사전 진단은 1점 3시간을 기준으로 애플리케이션마다 기본 작업 5일을 더하고, 수행자가 대상 스택과 수정 패턴을 보고 경험에 따라 값을 조정합니다. 다만 이 기준은 수행 조직의 관행이며 점수를 일수나 기능점수로 바꾸는 공식 계수는 없습니다.
익명 진단 사례 6건에서도 점수와 일수는 비례하지 않았습니다. 공공기관 D는 총점 937점 가운데 920점이 목표 버전에 따라 생략할 수 있는 점수여서 5일이 산정됐고, 대학 E는 추정 점수가 한 자릿수인 애플리케이션에 12일과 27일이 산정됐습니다. 그러므로 발주자는 진단 전에 목표 Java 버전을 정하고, 결과에서는 총점보다 등급 분포를 먼저 확인합니다(백서 4장).
▲ 진단 사례의 Story Point 총점과 산정 일수 분포 (백서 40쪽)
구현 32%와 시험 25%만 적용하는 기능 변경 없는 전환의 대가 산정 경로
공공 소프트웨어 사업비는 SW사업 대가산정 가이드가 정한 기능점수와 투입공수로 산정하므로, Story Point는 금액 계산에 직접 쓰지 않고 적용할 경로를 고르는 근거로 연결합니다. 2024년 개정판의 개발 단계별 가중치는 분석 19%, 설계 24%, 구현 32%, 시험 25%입니다. 이 가이드는 기능 변경량이 0으로 산정된 재개발 사례에 분석과 설계를 제외하고 구현과 시험 단계만 다시 산정하는 방식이 적절하다고 설명하며, 두 단계를 더하면 57%입니다. 다만 등급 분포로 경로를 고르는 방법은 백서의 제안이며 공식 기준은 아닙니다(백서 4장).
▲ Story Point 등급 분포로 대가 산정 경로를 고르는 판단 흐름 (백서 43쪽)
| 경로 | 적용 조건 | 산정 방식 |
|---|---|---|
| 기능점수 | 기능을 추가하거나 수정하는 재개발 | 기능점수 × 단가, 전 단계 적용 |
| 구현·시험 단계 한정 | 기능 변경이 없는 전환 | 분석·설계 단계 제외, 구현 32%와 시험 25%만 적용 |
| 투입공수 | 기능점수 방식이 맞지 않는 작업 | 투입 인력과 기간으로 산정 |
Tomcat 8.5·Spring Framework 5.3·AIX 7.1의 지원 종료와 Java 17 상향의 이유
전환 대상의 구버전 스택은 운영체제, Java, WAS, 프레임워크 네 계층으로 나뉘고, 대부분 둘 이상의 계층에서 지원이 끝났습니다. AIX 7.1 TL5는 2023년 4월 30일, Apache Tomcat 8.5는 2024년 3월 31일에 지원이 끝났고 Spring Framework 5.3의 오픈소스 지원도 2024년 8월에 끝났습니다. 컨테이너로 전환하면 호스트 운영체제와 기반 이미지가 지원 중인 버전으로 바뀌지만, VM으로 이전하면 지원이 끝난 게스트 운영체제가 새 환경에 그대로 남습니다. 또한 Spring Boot 3.0이 Java 17을 요구하므로, 목표 Java를 17 이상으로 정해야 운영 단계에서 상향 사업을 다시 발주하지 않습니다(백서 5장).
▲ 운영체제·WAS·프레임워크의 지원 종료 시점과 Java 목표 버전 (CentOS 7과 Spring Boot 2.7의 종료 시점은 집계 사이트로 확인한 2차 확인 값) (백서 47쪽)
600MB 컨테이너에서 최대 힙을 약 2GB로 계산하는 구버전 JVM의 한계
컨테이너는 리눅스 커널의 cgroup으로 자원을 제한하는데, JVM(Java 가상 머신)이 이 한도를 읽지 못하면 호스트 전체의 메모리를 기준으로 최대 힙을 계산합니다. 예를 들어 메모리 8GB 호스트에서 한도 600MB로 컨테이너를 실행하면 JVM은 최대 힙을 약 2GB로 계산하고, 사용량이 600MB를 넘는 순간 커널이 컨테이너를 강제 종료합니다. JVM이 컨테이너 한도를 기본으로 인식하는 것은 JDK 10부터이고 JDK 8 계열에서는 8u191부터이며, cgroup v2 인식은 JDK 15와 11.0.16, 8u372에 들어갔습니다. 그래서 사전 진단은 Java 메이저 버전과 함께 업데이트 번호까지 수집합니다(백서 5장).
▲ 컨테이너를 인식하지 못하는 JVM과 인식하는 JVM의 최대 힙 계산 비교 (백서 50쪽)
리눅스 실행 가능성 하나로 정하는 컨테이너 전환 판정 기준
판정 기준은 한 문장입니다. 리눅스에서 실행할 수 있게 만들 수 있으면 컨테이너로 갑니다. 컨테이너는 호스트 커널을 공유하면서 격리된 프로세스로 실행되므로, 리눅스에서 프로세스로 실행되는 애플리케이션은 컨테이너로도 실행할 수 있습니다. 여기서 「만들 수 있으면」이라는 표현에는 수정과 포팅이 포함됩니다. 따라서 로컬 디스크에 상태를 저장하는 구조, 하드코딩된 파일 경로, 구버전 Java와 WAS, Unix에서 실행 중인 Java 애플리케이션은 가상화 예외에 해당하지 않고 컨테이너로 전환하면서 수정합니다(백서 6장).
▲ 호스트 리눅스 커널 하나를 여러 컨테이너가 공유하는 구조와 VM마다 게스트 OS를 두는 구조 (백서 62쪽)
최근 공고된 공공 클라우드 네이티브 전환 사업들도 요구사항에 컨테이너 오케스트레이션을 명시했습니다. 기대효과로는 서비스 배포 시간 단축과 운영비 절감, 신속한 기능 개선을 들었습니다. 가상 서버로 옮기는 이전만으로는 이 요구사항을 충족할 수 없으므로, 판정의 출발점을 컨테이너에 두는 기준은 발주 문서의 요구와도 일치합니다.
가상화 전환을 허용하는 다섯 가지 예외 사유와 기록 조건
리눅스에서 실행된다는 사실만으로 전환이 보장되지 않는 단서는 세 가지입니다. 커널에 직접 종속된 대상은 제외되고, 이미지와 호스트의 버전 차이는 배포판 공급자가 정한 지원 범위 안이어야 하며, CPU 아키텍처가 같아야 합니다. 가상화(VM) 전환은 컨테이너로 옮길 수 없다고 확인됐거나 커널 공유가 허용되지 않는 대상에만 허용하고, 편의와 촉박한 일정, 운영 조직의 익숙함은 사유로 인정하지 않습니다. 예외로 남기는 VM에는 사유와 해소 조건, 재검토 시점을 기록하며, 전환을 마친 대상으로 집계하지 않고 컨테이너 전환 전의 대기 상태로 관리합니다(백서 6장).
▲ 리눅스 실행 가능성에서 시작해 단서 세 가지와 예외 사유를 거치는 전환 판정 흐름 (백서 64쪽)
| 예외 사유 | 확인 방법 | 먼저 시도할 해소 경로 |
|---|---|---|
| 컨테이너로 전환할 수 없는 Windows 전용 소프트웨어 | 화면(GUI) 유무, OS 버전 | 리눅스 전환, 서버형이면 Windows 컨테이너 |
| 커널 모듈·특수 하드웨어·실시간 OS 의존 | 설치된 커널 모듈과 장치 목록 | 사용자 공간 대체 수단, 전용 노드 |
| 하드웨어나 IP에 종속된 라이선스 | 라이선스 계약과 인증 방식 | 라이선스 교환, 전용 노드 고정 |
| 소스가 없거나 제작사가 없는 상용 패키지 | 소스 보유 여부, 제작사 존속 여부 | 제작사의 컨테이너 지원판, 대체 소프트웨어 |
| 커널 공유를 금지하는 격리 규제 | 적용 규정의 조문 | 전용 노드, 클러스터 분리 |
예외 VM을 임시로 받는 브릿지 기술 KubeVirt와 데이터 계층의 판정 방식
예외 사유가 확인된 VM은 사유가 해소될 때까지 운영해야 하고, 이 VM 때문에 가상화 기반을 따로 유지하면 플랫폼을 이중으로 운영하게 됩니다. KubeVirt(Kubernetes 위에서 VM을 실행하는 오픈소스 기술)는 이 예외 VM을 컨테이너로 옮기기 전까지 임시로 받는 브릿지 기술이며, 전환의 목표 구성도 권장 기술도 될 수 없습니다. VM 실행 기능을 기본 전환 경로로 쓰면 파드와 VM의 이중 운영이 고착되기 때문입니다. 한편 데이터베이스를 관리형 서비스나 VM에 두더라도 애플리케이션은 접속 정보를 환경 변수로 외부화하면 컨테이너로 실행할 수 있으므로, 데이터베이스의 위치는 애플리케이션을 가상화 예외로 둘 근거가 아닙니다(백서 6장).
▲ 컨테이너로 전환하는 애플리케이션 계층과 따로 판정하는 데이터 계층의 배치 구분 (백서 70쪽)
난이도 등급표와 대상 선정 기준을 사업자에게 넘긴 상세설계 제안요청서의 한계
정부의 상세설계 제안요청서는 과업 구조와 전환유형의 정의, 기능점수 기반 비용 산정 방식을 정해 두었지만, 유형을 가르는 기준은 「전환시 난이도, 수정의 범위」라는 표현뿐입니다. 난이도 등급표와 대상 선정 기준은 사업자의 과업으로 넘어가 있습니다. 2024년 상세설계 사업은 21개 시스템에 약 56억 원 규모였으므로 어느 시스템을 올릴지는 그 전에 판단해야 합니다. 클라우드 네이티브 전환 사전 진단은 대상 지정 이전에 대상 선정과 전환유형 분류, 공수 범위, 가상화 예외 목록을 Story Point와 일수로 제시합니다. 즉 사전 진단은 상세설계를 대체하지 않고 그 앞 단계를 맡습니다(백서 7장).
▲ 사전 진단·상세설계·본사업이 각각 정하는 항목과 단계 사이에 전달되는 산출물 (백서 84쪽)
정부의 전면 전환 로드맵도 첫 단계에서 전환 대상과 전환유형을 확정하고, 다음 단계에서 확대와 운영 지원을 거쳐 전면화하는 순서로 짜여 있습니다. 발표 당시 집계에서도 클라우드로 전환을 마친 시스템 가운데 클라우드 네이티브까지 전환한 시스템은 일부에 그쳤습니다. 대상과 유형을 먼저 정하는 이 순서에서 클라우드 네이티브 전환 사전 진단의 결과는 첫 단계의 판단 근거로 쓸 수 있습니다.
업무 중요도가 높고 Mandatory 점수가 낮은 대상부터 옮기는 전환 순서
전환 순서는 기관이 정하는 업무 중요도와 진단에서 나오는 Mandatory 점수 합을 교차시킨 4분면으로 정합니다. 중요도가 높고 점수가 낮은 빠른 성과 구역을 가장 먼저 컨테이너로 전환하고, 첫 전환 대상도 이 구역에서 상태를 저장하지 않고 기동이 빠른 서비스로 고릅니다. 중요도와 점수가 모두 높은 대형 과제 구역은 개념 검증(PoC)으로 위험을 먼저 확인한 뒤 단계를 나눠 전환합니다. 본사업은 컨테이너 전환을 먼저 완료하고 서비스 분리(MSA)를 다음 단계에 두며, 이 순서는 NIA 발주자 안내서가 제시한 컨테이너, 데브옵스와 배포 자동화, MSA의 도입 순서와 같습니다(백서 8장).
▲ 업무 중요도와 Mandatory 점수 합으로 나눈 전환 우선순위 4분면 (백서 87쪽)
전환을 마친 공공 시스템의 성과 발표는 성공 요인으로 조직의 참여를 들었습니다. 임직원이 적극 참여했고, 별도 조직을 구성해 전환 사업단과 긴밀한 의사소통 체계를 유지했다는 내용입니다. 그러므로 첫 전환 대상을 고를 때는 점수와 함께 운영 조직이 참여할 수 있는 여건도 확인합니다.
핵심 정리
- 전환의 기본은 컨테이너 전환이고, 가상화(VM) 전환은 다섯 가지 사유가 확인된 대상에만 허용하는 예외입니다.
- 클라우드 네이티브 전환 사전 진단 CNTA는 다섯 단계로 진행하며, 시스템 한 묶음이면 3주로 구성할 수 있습니다.
- Story Point는 1점 3시간을 기준으로 수행자가 경험에 따라 조정하며, 일수나 기능점수로 바꾸는 공식 계수는 없습니다.
- 목표 Java 버전은 진단 전에 정하고, 결과에서는 총점보다 등급 분포를 먼저 확인합니다.
- KubeVirt는 예외 VM을 임시로 받는 브릿지 기술이며 전환의 목표 구성이 될 수 없습니다.
자주 묻는 질문
클라우드 네이티브 전환 사전 진단은 상세설계와 무엇이 다른가요?
사전 진단은 대상이 지정되기 전에 어느 시스템을 상세설계에 올릴지와 전환 공수의 범위를 제시합니다. 상세설계는 지정된 시스템의 목표모델과 이행계획, 기능점수 기반 예산을 정합니다.
Story Point 총점이 곧 사업비인가요?
Story Point 총점은 사업비가 아니며, 점수를 일수나 기능점수로 바꾸는 공식 계수는 없습니다. 사업비는 SW사업 대가산정 가이드의 경로로 따로 산정하고, 환산 결과는 단일 값이 아닌 범위로 제시해야 합니다.
가상화 전환은 언제 허용되나요?
컨테이너로 옮길 수 없다고 확인됐거나 커널 공유가 허용되지 않는 경우에만 허용합니다. 예외마다 사유와 해소 조건, 재검토 시점을 기록합니다.
클라우드 네이티브 전환 사전 진단에는 기간이 얼마나 걸리나요?
시스템 한 묶음을 대상으로 하면 사전 진단은 3주로 구성할 수 있습니다. 실제 기간은 대상 시스템의 수와 규모가 커질수록 늘어나고, 보안 구역의 반입·반출 절차에 걸리는 시간도 더해집니다.
진단을 시작하기 전에 기관은 무엇을 준비해야 하나요?
기관은 일정 협의, 분석용 PC, OpenJDK 11 이상, 애플리케이션 반입, 분석 도구 반입, 보고서 반출의 여섯 가지를 준비합니다. 반입하는 파일은 업무 소스나 업무용 WAR·EAR여야 하며, 타사 라이브러리 JAR만 제출하면 분석할 수 없습니다.
KubeVirt로 VM을 옮기면 전환을 마친 것으로 보나요?
KubeVirt 위에서 실행되는 VM의 수는 전환 성과로 집계하지 않습니다. KubeVirt는 예외 VM을 컨테이너로 옮기기 전까지 임시로 받는 브릿지 기술이며, 게스트 OS와 구버전 미들웨어의 부채는 그대로 남습니다.
Unix에서 운영 중인 Java 애플리케이션도 컨테이너로 전환할 수 있나요?
Unix에서 실행 중인 Java 애플리케이션은 가상화 예외가 아닌 리눅스 전환 검증 대상입니다. 순수 Java 애플리케이션은 JVM이 운영체제 차이를 흡수해 이식 난이도가 낮으며, 진단에서는 네이티브 라이브러리의 유무를 먼저 확인합니다.
문의
진단 대상과 범위 선정은 전환 사전 진단 상담 문의에서 상담할 수 있습니다.
