Cloud Native

로드맵의 0단계는 기술 도입이 아니라 애플리케이션 포트폴리오 평가입니다. 모든 시스템이 전환 대상은 아니기 때문입니다.

전환 계획은 보유 시스템의 목록화에서 시작합니다. 시스템별로 사업 중요도, 변경 빈도, 기술 부채, 의존 관계를 평가하고, rehost(그대로 이전)·replatform(부분 교체)·refactor(재설계)·retain(유지)·retire(폐기) 가운데 경로를 배정합니다. 이 분류 체계(6R)와 클라우드·클라우드 네이티브의 개념 차이는 클라우드 네이티브 vs 클라우드 글에서 자세히 다뤘습니다.

목록화와 함께 정해야 할 것이 하나 더 있습니다. 이번 전환을 어디까지 끌고 갈 것인가입니다. 컨테이너 플랫폼을 갖추는 데서 멈출 수도 있고, 애플리케이션을 클라우드 네이티브하게 다시 설계하는 데까지, 나아가 온프레미스와 퍼블릭을 같은 방식으로 다루는 데까지 갈 수도 있습니다. 목적 단계를 어디로 잡느냐가 이후 4개 단계의 범위와 기간을 결정합니다.

그림 1. 컨테이너 도입 목적의 네 단계 — 어디까지 갈 것인지 먼저 정한다

우선순위 기준은 명확합니다. 변경이 잦고 트래픽 변동이 크며 장애 시 영향이 큰 시스템일수록 재설계의 효과가 크고, 변화 없는 안정 시스템은 후순위이거나 유지 대상입니다. 첫 대상은 “중요하지만 치명적이지는 않은” 시스템이 적합합니다. 효과를 보여 줄 만큼 의미 있으면서, 실패해도 사업이 멈추지 않는 범위여야 조직이 학습할 수 있습니다.

• 흔한 실패 요인: 진단 없이 “전 시스템 동시 전환”을 선언하는 빅뱅 접근. 레거시 연계(EAI, 배치, 파일 인터페이스)를 목록에서 빠뜨려 전환 도중에 발견하는 경우.
• 다음 단계로 넘어가는 조건: 시스템별 경로 배정표와 1차 전환 대상 확정.

첫 단계는 애플리케이션을 컨테이너에 담는 것입니다. Trail Map 도 “복잡한 앱이라도 일단 컨테이너화하라”를 출발점으로 명시합니다.

Trail Map 의 1단계는 컨테이너화(Containerization)이며, 흔히 Docker 로 시작합니다. 주목할 점은 “코드와 의존성을 함께 패키징하되, 마이크로서비스 분해는 나중에 해도 된다”는 태도입니다(출처: CNCF Cloud Native Trail Map). 모놀리식을 그대로 컨테이너에 담는 것은 부끄러운 일이 아니라 권장 경로입니다.

이 단계에서 얻는 것은 환경 일관성과 이식성입니다. 개발·테스트·운영이 같은 이미지를 쓰게 되고, “제 환경에서는 됩니다” 문제가 사라지며, 이후 단계(파이프라인·오케스트레이션)가 다룰 표준 단위가 생깁니다. 애플리케이션 쪽 준비도 함께 시작합니다. 설정을 환경 변수로 빼고 로그를 표준 출력으로 돌리는 개선은 컨테이너화와 동시에 진행하는 편이 효율적입니다. 이 설계 원칙은 12 Factor App 글에서 12가지로 정리했고, 컨테이너가 MSA·CI/CD·DevOps 와 어떻게 맞물리는지는 클라우드 네이티브 4대 요소에서 다룹니다.

실무에서 발목을 잡는 것은 Dockerfile 자체가 아니라 애플리케이션에 남아 있는 전제들입니다. 컨테이너는 IP 가 바뀌고 언제든 다시 뜨는 것을 전제로 하므로, IP 를 고정해 두는 세션 클러스터링이나 소스에 박힌 호스트명은 그대로 두면 컨테이너 안에서 깨집니다. 아래 다섯 가지는 이미지를 만들기 전에 확인하는 편이 빠릅니다. 모놀리식을 잘게 나누는 작업은 여기서 하지 않습니다 — 자동 분해 도구를 검토하는 단계라도 Mono2Micro 같은 도구는 컨테이너화·파이프라인이 안정된 뒤에 꺼내는 카드입니다.

그림 2. 컨테이너화 전에 손봐야 하는 다섯 가지

• 흔한 실패 요인: 컨테이너화와 마이크로서비스 분해를 동시에 시도해 두 변화의 리스크가 곱해지는 경우. 이미지에 설정·시크릿을 박아 환경별 이미지가 늘어나는 경우.
• 다음 단계로 넘어가는 조건: 1차 대상 시스템이 컨테이너 이미지로 빌드되고, 어느 환경에서든 같은 이미지가 실행된다.

2단계는 빌드·테스트·배포 파이프라인 자동화입니다. 이것이 없으면 오케스트레이션이 만들어 낼 배포 빈도를 감당할 수 없습니다.

Trail Map 의 2단계는 CI/CD 입니다. 코드 변경이 자동으로 빌드·테스트되어 새 컨테이너 이미지로 만들어지고, 검증을 통과하면 배포까지 이어지는 흐름을 만듭니다(출처: CNCF Cloud Native Trail Map). 왜 오케스트레이션보다 먼저일까요. 쿠버네티스를 먼저 도입하면 배포 대상(클러스터)은 현대화됐는데 배포 방법(수동 절차)은 그대로인 어정쩡한 상태가 됩니다. 자동화된 파이프라인이 있어야 클러스터 도입 이후의 잦은 배포·롤백이 운영 가능한 일이 됩니다.

차이는 도구 목록이 아니라 배포라는 행위의 성격에서 드러납니다. 사람이 배포하면 배포 시간과 롤백 시간이 같고, 검증은 사람의 눈에 의존하며, 실패는 누락이나 오타 같은 형태로 나타납니다. 파이프라인이 배포하면 롤백은 이전 이미지로 되돌리는 일이 되고, 검증은 테스트가 대신하며, 실패는 배포 전에 차단됩니다.

그림 3. 사람이 배포할 때와 파이프라인이 배포할 때

이 단계의 핵심 산출물은 도구가 아니라 신뢰입니다. “파이프라인이 통과시킨 것은 배포해도 된다”는 신뢰가 쌓여야 배포 승인 회의가 줄고 배포 주기가 짧아집니다. 그러려면 테스트 자동화가 파이프라인의 실질을 채워야 합니다. 빈 껍데기 파이프라인은 수동 심사를 없애지 못합니다. 도구 선택 자체가 고민이라면 Jenkins·ArgoCD·GitHub Actions 비교를 먼저 보시기 바랍니다.

• 흔한 실패 요인: 파이프라인은 구축했지만 테스트가 없어 여전히 사람이 전 단계를 검수하는 경우. 팀마다 도구·규약이 제각각이라 표준화가 안 되는 경우.
• 다음 단계로 넘어가는 조건: 커밋에서 배포 가능한 이미지까지 사람 개입 없이 도달하고, 실패 시 파이프라인이 차단한다.

3단계는 쿠버네티스 도입입니다. 핵심은 설치가 아니라 “원하는 상태를 선언하면 시스템이 맞춘다”는 운영 방식의 정착입니다.

Trail Map 3단계는 오케스트레이션과 애플리케이션 정의(Orchestration & Application Definition)로, 사실상의 표준인 쿠버네티스와 Helm 같은 패키징 도구가 들어옵니다(출처: CNCF Cloud Native Trail Map). 쿠버네티스 도입은 업계 전반의 흐름이기도 합니다. CNCF 연례 서베이는 쿠버네티스가 조직 다수에서 이미 주류 기술로 자리 잡았음을 해마다 확인해 왔습니다(출처: CNCF Annual Survey, cncf.io/reports).

이 단계에서 진짜 바뀌어야 하는 것은 운영 습관입니다. 서버에 접속해 고치는 명령형 운영에서, 매니페스트를 고쳐 적용하는 선언형 운영으로 넘어가야 합니다. 죽은 컨테이너를 쿠버네티스가 알아서 되살리는 자가 치유, 부하에 따른 자동 확장이 이 선언형 모델 위에서 동작합니다. 쿠버네티스가 왜 마이크로서비스 운영의 필수 플랫폼으로 자리 잡았는지도 이 선언형 모델에서 설명됩니다. 배포 상태 자체를 Git 으로 관리하는 GitOps 를 이 단계에서 함께 도입하면 이후 감사·롤백이 크게 단순해집니다. 클러스터가 수백 개로 늘어난 뒤에도 이 방식이 버티는지는 360개 클러스터를 운영하는 Adobe 의 GitOps 확장 사례에서 확인할 수 있습니다.

• 흔한 실패 요인: 클러스터는 구축했지만 운영팀이 명령형 습관을 유지해 “쿠버네티스 위의 수동 운영”이 되는 경우. 운영 역량 준비 없이 서비스를 대거 올려 장애 대응이 마비되는 경우.
• 다음 단계로 넘어가는 조건: 1차 대상 서비스가 클러스터에서 선언적으로 배포·복구되고, 운영팀이 매니페스트 기반 변경에 익숙해진다.

4단계는 관측성과 정책으로 운영의 눈과 규칙을 세우는 단계이고, 5단계 서비스 메시는 서비스 간 통신이 복잡해졌을 때 선택하는 확장입니다.

Trail Map 4단계는 관측성과 분석(Observability & Analysis)입니다. Prometheus 기반 메트릭, 중앙화된 로그, 분산 트레이싱으로 시스템 상태를 항상 들여다볼 수 있게 만듭니다(출처: CNCF Cloud Native Trail Map). 서비스가 잘게 나뉠수록 “어디가 느린가”를 찾는 난도가 올라가므로, 관측성은 서비스 분해보다 먼저 갖춰야 하는 안전망입니다. 메트릭·로그·트레이스 3축이 각각 무엇을 답하는지는 Observability란 무엇인가 자료에 정리되어 있고, 수집한 데이터를 사람이 다 보지 못하는 규모에서 어떤 선택지가 있는지는 AI Native Observability에서 다룹니다. 저장 비용이 먼저 문제가 되는 조직이라면 ClickHouse 기반 관측 데이터 저장 같은 선택지도 이 단계에서 함께 검토하게 됩니다.

5단계는 서비스 프록시·디스커버리·메시(Service Proxy, Discovery & Mesh)입니다. 서비스 수가 늘어 통신 경로가 복잡해지면, Istio 같은 서비스 메시로 서비스 간 mTLS·트래픽 제어·재시도를 코드 밖에서 일괄 처리합니다(출처: CNCF Cloud Native Trail Map). 순서에 주의할 점이 있습니다. 서비스 메시는 강력하지만 운영 복잡도도 상당하므로, 서비스가 몇 개뿐인 단계에서 도입하면 이득보다 부담이 큽니다. Trail Map 이 메시를 후반부에 둔 이유입니다. 네트워크 정책·분산 스토리지·메시징 같은 나머지 단계도 필요가 확인될 때 확장하는 선택지입니다.

• 흔한 실패 요인: 관측성 없이 서비스를 분해해 장애 원인 추적이 불가능해지는 경우. 규모가 작은데 서비스 메시부터 도입해 운영 부담만 늘리는 경우.
• 점검 항목: 신규 서비스가 배포되면 대시보드·알림이 자동으로 따라붙는가. 장애 시 어느 서비스가 원인인지 트레이스로 좁힐 수 있는가.

5단계를 관통하는 실패 원인 1순위는 기술이 아니라 조직입니다. 전환은 플랫폼 구축과 조직 변화가 함께 가는 프로그램이어야 합니다.

단계별 실패 요인을 다시 보면 공통 분모가 보입니다. 빅뱅 선언, 수동 습관의 존속, 역량 준비 부족 — 모두 조직 문제입니다. 그래서 성공하는 전환 프로그램은 세 가지를 기술 로드맵과 병행합니다.

1. 파일럿-확산 구조 — 작은 성공을 만들어 패턴을 검증하고, 그 패턴을 표준화해 다음 시스템에 적용합니다. 단계마다 “다음으로 넘어가는 조건”을 명시해 성급한 확산을 막습니다.
2. 플랫폼 팀 — 각 서비스 팀이 쿠버네티스·파이프라인을 각자 익히게 두지 않고, 공통 플랫폼과 표준 경로(golden path)를 제공하는 팀을 둡니다. 이 역할을 맡는 사람이 어떤 일을 하는지는 플랫폼 엔지니어란?과 시스템 엔지니어에서 플랫폼 엔지니어로에서 구체적으로 다룹니다.
3. 문화와 역량 — 만든 팀이 운영까지 맡는 책임 구조, 장애를 비난 없이 학습하는 문화가 없으면 도구는 겉돕니다. 개발과 운영을 한 흐름으로 묶는다는 발상이 어디서 나왔는지는 DevOps 라는 단어를 사용하게 된 이유에서 확인할 수 있습니다.

팀 구성에서 자주 어긋나는 지점은 참여 방식입니다. 플랫폼 팀과 서비스 개발팀, 클라우드 운영은 전환 기간 내내 상시로 붙어 있어야 하지만, 보안·조달·인사는 필요한 시점에 들어왔다 나가는 편이 낫습니다. 이 구분 없이 전원을 상시 투입하면 회의만 늘고, 반대로 플랫폼 팀까지 겸업으로 두면 표준 경로가 만들어지지 않습니다.

그림 4. 전환을 끌고 가는 팀 — 상시 참여와 필요 시 참여

클라우드 네이티브 전환은 프로젝트가 아니라 여러 해에 걸친 프로그램입니다. 다만 방향과 순서는 이미 검증되어 있습니다. 진단으로 대상을 고르고, 컨테이너화로 표준 단위를 만들고, 파이프라인으로 흐름을 자동화하고, 오케스트레이션으로 운영을 선언형으로 바꾸고, 관측성과 정책으로 성숙도를 올리는 것 — 이 순서를 지키는 것만으로 실패 확률의 큰 부분을 줄일 수 있습니다.

Q. 클라우드 네이티브 전환은 얼마나 걸리나요?

조직 규모와 대상 시스템 수에 따라 다르지만, 1차 대상의 컨테이너화·파이프라인 구축에 수개월, 전사 확산까지는 통상 2~3년 이상을 보는 것이 현실적입니다. 중요한 것은 총 기간보다 단계마다 검증 가능한 성과를 내는 구조입니다.

Q. 컨테이너화와 마이크로서비스 분해를 동시에 해야 하나요?

아닙니다. CNCF Trail Map 도 모놀리식을 그대로 컨테이너화하는 것을 첫걸음으로 권합니다. 두 변화를 동시에 시도하면 리스크가 곱해지므로, 컨테이너화·파이프라인·오케스트레이션이 안정된 뒤 변경이 잦은 경계부터 분해하는 순서가 안전합니다.

Q. 쿠버네티스 도입 전에 CI/CD 를 먼저 만들어야 하는 이유는 무엇인가요?

쿠버네티스가 열어 주는 잦은 배포·롤백은 자동 파이프라인이 있어야 운영 가능하기 때문입니다. 파이프라인 없이 클러스터만 도입하면 배포 방법은 수동 그대로인 채 인프라 복잡도만 올라갑니다.

Q. 서비스 메시는 반드시 도입해야 하나요?

아닙니다. 서비스 수가 적을 때는 운영 부담이 이득을 넘습니다. 서비스 간 통신 경로가 복잡해지고 mTLS·트래픽 제어 요구가 뚜렷해진 시점에 도입하는 후반부 선택지입니다.

Q. 전환이 실패하는 가장 흔한 원인은 무엇인가요?

기술보다 조직입니다. 진단 없는 빅뱅 접근, 수동 운영 습관의 존속, 플랫폼 팀과 역량 준비 부족이 대표적입니다. 파일럿으로 패턴을 검증하고 단계별 통과 조건을 지키는 구조가 최선의 예방책입니다.

단계별로 더 깊이 들어갈 때 이어서 보시기 바랍니다.

• 0단계 진단 — 클라우드 네이티브 vs 클라우드: 마이그레이션 방식으로 보는 차이
• 1단계 컨테이너화 — 12 Factor App: 클라우드 네이티브 설계 원칙 12가지 · 클라우드 네이티브 4대 요소
• 2단계 CI/CD — Jenkins, ArgoCD, GitHub Actions 비교
• 3단계 오케스트레이션 — 쿠버네티스: 마이크로서비스 운영을 위한 필수 플랫폼 · Adobe 의 GitOps 플랫폼 확장 전략
• 4단계 관측성 — Observability란 무엇인가 (자료 다운로드) · AI Native Observability
• 조직 준비 — 플랫폼 엔지니어란? · DevOps 라는 단어를 사용하게 된 이유
• 공공부문 사례 — 공공부문 클라우드 네이티브 전략 · 공공기관 DR, 가상화에서 클라우드 네이티브로

• CNCF Cloud Native Trail Map
• CNCF 연례 서베이·보고서 모음
• Kubernetes 공식 문서 — 개요(한국어)
• 클라우드 네이티브란? 개념·구성요소·도입 전략 가이드 (cncf.co.kr)