docker, kubernetes … 뜬구름 잡는 용어, 물류창고 비유로 한 번에 이해하기

현업 미팅에서 백 번쯤 듣는 질문: “컨테이너 쓰니까 우리 MSA 맞죠?”

새로운 대형 프로젝트나 클라우드 네이티브 전환을 검토하는 회의실에 들어가면, 거의 예외 없이 나오는 단어들이 있습니다. MSA, 컨테이너, 도커, 쿠버네티스… 여기에 조금 더 깊게 들어가면 오픈시프트(OpenShift)나 아코디언(Accordion) 같은 상용 플랫폼 이름까지 튀어나옵니다.

그런데 실제 기획자, 관리자, 심지어 몇몇 엔지니어분들과 이야기를 나누다 보면 이 용어들을 한 주머니에 넣고 마구 섞어 쓰는 경우를 정말 자주 봅니다.

“우리 이번에 도커(Docker) 도입하니까 아키텍처는 자동으로 MSA로 넘어가는 거죠?”

“쿠버네티스 쓰면 도커는 안 써도 되는 건가요?”

결론부터 콕 짚고 말씀드리면, 컨테이너 환경과 MSA(마이크로서비스 아키텍처)는 교집합이 있을 뿐, 태생부터가 완전히 다른 개념입니다. 이 둘을 동의어로 생각하고 프로젝트를 시작했다가는 십중팔구 아키텍처가 꼬여 배가 산으로 가게 됩니다.

제가 현업에서 겪은 시행착오와 수많은 밤샘의 경험을 녹여, 뜬구름 잡는 IT 인프라 개념을 아주 직관적으로 정리해 드리겠습니다. 대형 프로젝트에서 인프라 분리 이슈나 솔루션 선택으로 머리를 싸매고 계신 분들에게 확실한 이정표가 되기를 바랍니다.

1. 헷갈리는 개념 한 큐에 정리: MSA와 컨테이너는 뭐가 다를까?

이해를 돕기 위해 가장 직관적인 ‘건축’에 비유해 보겠습니다. MSA는 ‘집을 어떻게 설계하고 쪼갤 것인가’에 대한 설계 도면(소프트웨어 공학 방법론)이고, 컨테이너는 ‘그 집을 어떤 자재로 쉽고 빠르게 조립할 것인가’에 대한 최신식 건축 자재(인프라 기술)입니다.

MSA의 본질: 잘게 쪼개서 각자 살기

MSA는 하나의 거대한 프로그램(Monolithic)을 로그인, 결제, 상품 관리, 자산 관리 등 서비스 단위로 쪼개어 독립적으로 개발하고 운영하는 방식입니다. 결제 모듈에 불이 나도 로그인이나 상품 조회는 정상 작동하게 만들겠다는 게 핵심입니다.

• 반전 팁: 굳이 컨테이너를 안 써도 전통적인 가상머신(VM) 여러 대에 서비스를 나누어 올리거나, 물리 서버를 여러 대 사서 쪼개 배포해도 MSA의 조건을 만족합니다.

컨테이너의 본질: 내 방을 그대로 들고 이사하기

컨테이너는 애플리케이션과 원활한 실행에 필요한 모든 라이브러리, 설정 파일을 통째로 하나의 그릇에 담아 격리하는 기술입니다. “내 PC에서는 잘 되는데 왜 서버에만 올리면 에러가 나지?” 하는 개발자의 해묵은 스트레스를 해결하기 위해 태어났습니다.

• 반전 팁: 쪼개지 않은 거대한 덩어리 프로그램(모놀리식)을 통째로 컨테이너 하나에 담아서 실행할 수도 있습니다. 기술은 컨테이너를 썼지만 아키텍처는 MSA가 아닌 셈입니다.

그런데 왜 사람들은 자꾸 혼용할까?

MSA를 하게 되면 서비스를 수십, 수백 개로 쪼개야 합니다. 그런데 무겁고 느린 가상머신(VM)을 수백 대 띄우면 서버 비용과 자원 낭비가 감당이 안 됩니다. 반면 컨테이너는 OS 커널을 공유해서 가볍고, 1초 만에 켜고 끌 수 있습니다. 즉, MSA라는 예쁜 그림을 가장 효율적으로 담아낼 수 있는 ‘찰떡궁합의 그릇’이 컨테이너이기 때문에 항상 세트처럼 묶여 다니는 것입니다.

2. 물류창고 비유로 끝내는 도커(Docker)와 쿠버네티스(K8s)

컨테이너 세계에 발을 들이면 필수적으로 마주치는 삼형제가 있습니다. 컨테이너, 도커, 그리고 쿠버네티스입니다. 이들은 경쟁 관계가 아니라, 명확한 계층 구조와 역할을 가집니다. 항만 물류 시스템을 상상하면 이해가 아주 쉽습니다.

┌────────────────────────────────────────────────────────┐
│  쿠버네티스 (Kubernetes / K8s)                          │
│  ▶ 수천 개의 컨테이너 박스를 지휘하고 통제하는 '항만 총괄 시스템'│
└────────────────────────────────────────────────────────┘
                           │ (지휘 및 관리)
                           ▼
┌────────────────────────────────────────────────────────┐
│  도커 (Docker)                                         │
│  ▶ 규격화된 표준 컨테이너 박스를 찍어내는 '제조사 및 도구'      │
└────────────────────────────────────────────────────────┘
                           │ (생성 및 규격화)
                           ▼
┌────────────────────────────────────────────────────────┐
│  컨테이너 (Container)                                  │
│  ▶ 내용물을 안전하게 격리하여 수송하는 '화물 박스 자체'       │
└────────────────────────────────────────────────────────┘

• 컨테이너 (화물 박스): 리눅스 커널 기술을 활용해 프로세스를 격리한 방입니다. 불필요한 OS 오버헤드가 없어서 가상머신보다 훨씬 가볍습니다.
• 도커 (박스 제조사): 과거에는 리눅스 커널로 컨테이너를 만드는 과정이 눈물겹게 복잡했습니다. 도커는 이를 명령어 몇 줄로 뚝딱 만들고 배포할 수 있게 표준화 표준을 만든 대중적인 플랫폼입니다. 오늘날 “컨테이너 쓴다”는 말은 보통 “도커 규격 박스를 쓴다”는 말과 같습니다.
• 쿠버네티스 (항만 총괄 시스템): 단일 서버에서 도커 박스 몇 개 띄우는 건 쉽습니다. 하지만 실전 엔터프라이즈 환경에서는 수백, 수천 개의 박스가 돌아갑니다. 이걸 사람이 밤새 감시할 순 없겠죠. 이때 등판하는 구원투수가 바로 ‘쿠버네티스(K8s)’입니다.
  • 자가 치유(Self-healing): 박스가 터지면 알아서 새 박스를 즉시 살려냅니다.
  • 자동 확장(Auto-scaling): 트래픽이 몰리면 박스 개수를 자동으로 늘렸다가, 한산해지면 줄여서 비용을 아낍니다.
  • 로드 밸런싱: 들어오는 사용자를 여러 박스로 골고루 찢어 분산해 줍니다.

3. [실전 사례] 빌링과 자산관리 시스템, 무조건 신기술이 답일까?

이해를 돕기 위해 제가 실제로 자문을 맡았던 한 기업의 실전 인프라 구축 시나리오를 소개해 드리겠습니다. 트렌드만 좇다가 대형 사고가 날 뻔한 아찔한 상황이었습니다.

[상황 프로필]

• 기존 선행 프로젝트 (빌링 시스템): VM OS(RHEL 9.6) 기반으로 애플리케이션을 올리고, 대형 Oracle ExaCC DB를 연동하여 이미 5개월 동안 뼈대를 튼튼하게 다져놓은 상태 (컨테이너 미적용).
• 신규 프로젝트 (자산관리 시스템): 원래 같이 시작하려다가 윗분들의 승인이 지연되면서, 뒤늦게 5개월이나 늦은 시점에 킥오프하게 된 상황. 일정이 매우 촉박함.

여기서 아키텍트인 저에게 두 가지 날카로운 질문이 던져졌습니다. 실무를 하시는 분들이라면 누구나 한 번쯤 마주할 딜레마입니다.

Q1. 이미 잘 굴러가는 빌링 시스템 인프라에 자산관리를 얹을까요, 아니면 물리적으로 찢을까요?

• 나의 선택: 물리적 독립 분리 및 신규 인프라 구축 (강력 권장)

💡 그렇게 판단한 이유:

우선 두 프로젝트의 생명주기(Lifecycle)가 완전히 다릅니다. 빌링 시스템은 5개월간 공을 들여 이제 안정화 단계나 오픈을 바라보고 있습니다. 이 민감한 시점에 늦게 출발한 자산관리 개발진이 들어와서 매일 테스트하고, 빌드와 배포를 반복하며 소스 에러를 내면 선행 중인 빌링 시스템의 운영 환경까지 덩달아 마비될 리스크가 너무 컸습니다.

게다가 ‘빌링(Billing)’은 돈이 오가는 기업의 핵심(Core) 워크로드입니다. 반면 자산관리는 임직원들이 주로 쓰는 내부 관리형 시스템이죠. 두 업무를 한 인프라에 섞어 쓰다가 자산관리의 무거운 통계 쿼리나 배치 작업이 빌링 시스템의 자원(CPU, 메모리)을 갉아먹으면 그야말로 대형 장애로 이어집니다. 독립성을 위해 물리 분리가 정답이었습니다.

Q2. 늦게 시작한 자산관리 시스템, 요즘 유행하는 컨테이너 기반으로 갈까요?

• 나의 선택: 전통적인 VM OS 기반 구축 (컨테이너 미적용)

🚫 신기술을 과감히 포기한 실리적 이유:

트렌드만 따지면 무조건 컨테이너와 쿠버네티스를 도입하자고 했어야 합니다. 하지만 5개월이나 지연된 일정을 만회해야 하는 비즈니스 관점에서는 VM OS(RHEL 9.6) 기반으로 가는 것이 훨씬 영리하고 안전한 선택이었습니다.

1. 초기 세팅 시간(Lead Time)의 절약: 지금 당장 코딩하고 화면을 뽑아야 하는데, 여기에 쿠버네티스 아키텍처를 새로 설계하고, 컨테이너 보안 가이드 수립하고, CI/CD 배포 파이프라인 연동 테스트를 하고 있으면 초기 몇 주가 그냥 날아갑니다. 촉박한 일정 속에서 리스크를 너무 키우는 꼴이었습니다.
2. 선행 프로젝트의 자산 복사(Ctrl+C / Ctrl+V): 앞서 달린 빌링 팀이 RHEL 9.6 VM 기반으로 환경을 완벽하게 셋업해 뒀습니다. 자산관리 팀도 동일한 VM OS 스택을 채택하면, 빌링 팀이 수개월 동안 삽질하며 검증한 OS 보안 강화 설정, 사내 보안 솔루션 연동 가이드, 모니터링 세팅을 그대로 가져다 쓸 수 있습니다. 인프라 구축 기간을 혁신적으로 단축하는 지름길입니다.
3. 운영 조직의 기술 부채 방지: 프로젝트가 끝나면 시스템은 현업 운영팀으로 넘어갑니다. 한 팀은 VM을 보고, 다른 팀은 쿠버네티스를 봐야 한다면 운영팀 입장에서는 엄청난 기술 부채가 됩니다. 인프라 환경을 통일해 주어야 기존 인력만으로도 매끄럽게 통합 모니터링과 운영이 가능합니다.
4. 업무 특성상 실익 없음: 컨테이너가 주는 최대 축복은 트래픽이 폭발할 때 자동으로 서버를 늘려주는 ‘오토스케일링’입니다. 하지만 사내 자산관리 시스템은 사용자가 딱 정해져 있고 트래픽 변동이 거의 없습니다. 굳이 아키텍처를 복잡하게 만들어 고생할 실리가 전혀 없었던 것이죠.

4. 상용 컨테이너 플랫폼 솔루션 정밀 비교: 오픈시프트 vs 아코디언

만약 여러분의 조직이 장기적인 클라우드 네이티브 로드맵에 따라 “우리는 이번에 무조건 컨테이너로 간다!”라고 최종 결정을 내렸다면, 다음 고개는 “순수 오픈소스 쿠버네티스를 쓸 것인가, 돈을 주더라도 상용 솔루션을 살 것인가?”입니다.

순수 오픈소스 쿠버네티스(Vanilla Kubernetes)는 공짜지만, 모니터링, 로깅, 보안 설정을 엔지니어가 일일이 수작업으로 조립해야 하는 ‘대형 조립형 레고 블록’입니다. 기술 내재화가 완벽하지 않은 일반 기업이 덤볐다간 백전백패입니다.

결국 안정적인 엔터프라이즈 운영을 위해 상용 플랫폼을 찾게 되는데, 시장에서 가장 핫한 투톱이 바로 글로벌 1위 레드햇 오픈시프트(Red Hat OpenShift)와 국산 대안의 자존심 맨텍 아코디언(Mantech Accordion)입니다.

🏢 레드햇 오픈시프트: 글로벌 표준의 묵직함과 철통 보안

IBM 산하 레드햇의 오픈시프트는 전 세계 대기업과 대형 금융권에서 가장 신뢰받는 맏형 같은 플랫폼입니다.

• 장점: 보안이 눈물 나게 엄격합니다. 컨테이너의 Root 권한 실행을 원천 차단하는 등 외부 위협에 가장 완벽한 방어막을 칩니다. 게다가 탄탄한 Red Hat Enterprise Linux(RHEL) 코어 위에서 구동되므로 OS부터 플랫폼까지 단일 제조사의 완벽한 최적화를 맛볼 수 있습니다. 글로벌 솔루션들과의 호환성도 단연 탑입니다.
• 단점: 가격이 정말 비쌉니다. 코어(Core) 수 기반으로 라이선스 비용이 청구되는데 예산이 넉넉지 않다면 숨이 턱 막힙니다. 기능이 너무 방대하고 엄격해서 내부 엔지니어들의 숙련도가 낮으면 사소한 에러 하나 해결하는 데도 진땀을 흘려야 합니다.

🇰🇷 맨텍 아코디언: 한국형 UI/UX와 미친 가성비의 실속파

국내 인프라 소프트웨어 명가인 ‘맨텍’이 만든 아코디언은 한국 기업의 정서와 IT 관리 환경을 철저하게 분석해서 만든 아주 실용적인 플랫폼입니다.

• 장점: 관리자 웹 콘솔이 기가 막히게 직관적입니다. 오픈시프트가 시커먼 터미널 창을 좋아하는 찐 엔지니어용이라면, 아코디언은 한글 대시보드 기반이라 쿠버네티스 명령어를 잘 모르는 인프라 담당자도 마우스 클릭 몇 번으로 컨테이너를 쉽게 배포합니다. 게다가 성능 모니터링(APM), 자동 빌드/배포(CI/CD), 백업 기능이 올인원으로 기본 탑재되어 있습니다. 무엇보다 장애 시 국내 전문 엔지니어가 즉각 방문하거나 원격 지원을 해준다는 게 최고의 강점입니다. 가격 또한 합리적입니다.
• 단점: 글로벌 초대형 멀티 클라우드를 구축해야 하거나, 해외의 까다로운 컴플라이언스를 100% 충족해야 하는 초국적 대기업의 코어 시스템 관점에서는 글로벌 대장인 오픈시프트에 비해 레퍼런스 규모나 인지도가 다소 밀릴 수 있습니다.

5. 아키텍트의 최종 제언: 우리 회사에 맞는 의사결정 체크리스트

유행하는 신기술이 항상 정답은 아닙니다. 현재 우리 조직의 상황과 업무의 특성을 냉정하게 저울질하는 것이 프로젝트 성공의 지름길입니다. 머리가 복잡한 관리자분들을 위해 깔끔한 가이드를 정리해 드립니다.

📌 인프라 구성 방식, 뭘 골라야 할까?

• 일정이 촉박하고 업무 연속성이 최우선인가요?👉 고민하지 말고 기존에 검증된 VM OS 환경을 복제해서 쓰세요. 가장 빠르게 골인 지점에 안착하는 방법입니다.
• 트래픽이 수시로 요동치고 무중단 배포를 매일 해야 하나요?👉 초반 공수가 들더라도 인프라를 분리하고 컨테이너 기반(쿠버네티스)으로 첫 단추를 채우셔야 합니다.

📌 컨테이너 솔루션, 어떤 걸 도입해야 할까?

• 순수 오픈소스 쿠버네티스: 내부에 밤샘 대기가 가능한 정예 DevOps 엔지니어 팀이 있고, 비용을 극단적으로 아끼면서 커스터마이징을 끝까지 해보고 싶을 때.
• 레드햇 오픈시프트: 글로벌 표준 준수가 필수적이고, 보안 컴플라이언스가 하늘이 두 쪽 나도 중요한 제1금융권, 대형 공공기관, 대기업 코어 시스템.
• 맨텍 아코디언: 쿠버네티스 도입이 처음이라 두려운 인프라 운영팀, 직관적인 한글 관리 포털이 필요한 환경, 합리적인 예산 안에서 신속하고 원활한 국내 기술 지원을 받으며 빠르게 클라우드로 전환하고 싶을 때.

기술의 화려함에 현혹되지 마세요. 비즈니스의 일정, 우리 팀원들의 현재 숙련도, 그리고 시스템의 특성을 종합적으로 고려해 ‘가장 실익이 큰 선택’을 내리는 것, 그것이 바로 진짜 일 잘하는 아키텍트의 자세입니다.

전문가의 인사이트 : 함께 읽어 보세요.

VM vs Container, 무조건 유행을 따라야 할까?

참조 및 출처 URL:

https://www.samsungsds.com/kr/insights/msa.html