엔터프라이즈에서 “플랫폼”을 그리면 결국 계층 다이어그램이 나온다. 아래에 인프라, 위로 갈수록 사람이 닿는 접점. 이 글은 서로 다른 세 장의 플랫폼 청사진 — 클라우드 관리 플랫폼 · AI/ML 플랫폼 · 데이터 거버넌스 플랫폼 — 을 나란히 놓고 그 구조를 읽는다. 세 장은 따로 그려졌지만, 겹쳐 보면 하나의 이야기가 된다.

핵심 명제: 클라우드가 뼈대(구조), 데이터가 혈액(연료), AI가 신경계(반응)다. 그리고 요즘 이 셋을 세로로 꿰는 것이 에이전트다.


1. 클라우드 관리 플랫폼 — 뼈대

계층형 클라우드 관리 플랫폼 — 사용자/시스템 관리·모니터링 / PaaS·DevOps·헬프데스크 / DevOps·MSA·CI-CD·Container / Security / Legacy·Private·Public Cloud

첫 장은 전형적인 클라우드 관리 플랫폼(CMP) 이다. 아래에서 위로 읽는다.

  • 맨 아래 — 인프라: Legacy System · Private Cloud · Public Cloud. 무엇 위에서 돌든 상관없게 만드는 하이브리드 기반.
  • 관통선 — Security: 특정 층이 아니라 전체를 가로지르는 띠. 모든 계층에 보안이 걸린다는 뜻.
  • 실행 기반: Container → CI/CD → DevOps·MSA. 컨테이너로 싣고, 파이프라인으로 나르고, 마이크로서비스로 쪼갠다.
  • 운영 도메인: PaaS 관리 · DevOps 관리 · 헬프데스크. 플랫폼을 운영하는 층.
  • 맨 위 — 관리·관측: 사용자 관리 · 시스템 관리, 그리고 오른쪽에 유독 따로 강조된 모니터링. 모니터링만 세로로 길게 그려진 건 우연이 아니다 — 나머지 모든 층의 이기 때문이다.

여기서 AI가 들어오는 자리는 명확하다. CI/CD엔 AI 코드리뷰·실패 로그 요약, 운영엔 AIOps(고정 임계치 대신 이상 탐지·경보 상관·자가 치유), 모니터링엔 “지금 주목할 3가지”를 먼저 읽어주는 요약, 헬프데스크엔 런북 RAG 코파일럿. AI는 새 박스가 아니라 각 층에 스며드는 신경이다.


2. AI/ML 플랫폼 — 신경계를 만드는 공장

AI/ML 플랫폼 — 분석사/관리자 포털·모니터링 / 데이터 준비·모델 생성·모델 테스트·배포 / 모델 DB·Opensource·파이프라인 / Metric·Logging·GPU Scheduling / Kubernetes / Mesosphere DC-OS

둘째 장은 MLOps(모델 생명주기) 플랫폼이다. 첫 장이 “무엇 위에서 돌리나”였다면, 이건 “지능을 어떻게 찍어내나”의 청사진이다. 구조를 뜯으면:

  • 맨 아래 — 실행 기반: Clustering (Mesosphere DC/OS)Container Orchestration (Kubernetes / Marathon) → 그 위 가로줄에 Metric · Logging · GPU Scheduling. 일반 클라우드 플랫폼과 결정적으로 다른 한 칸이 GPU Scheduling이다. 모델 학습은 GPU를 잡아야 하고, 그 비싼 자원을 어떻게 나눠 스케줄링하느냐가 이 플랫폼의 심장이다.
  • 자산 계층: 모델 DB · Opensource 관리 · 파이프라인 관리. 학습된 모델을 버저닝해 저장하고(모델 DB), 오픈소스 프레임워크를 관리하고, 학습→배포를 파이프라인으로 잇는다.
  • 핵심 워크플로우 (좌→우):
    • 데이터 준비/관리 — 테스트 데이터 · 데이터 검증 · 전처리 · 준비
    • 모델 생성 — 데이터 분석 · 모델 개발 · 모델 훈련 · 모델 최적화
    • 모델 테스트/배포 관리 — 모델 평가 · 검증 · 등록 · 배포
    • 이 좌→우가 곧 ML 생명주기다. 데이터 → 학습 → 평가 → 배포, 그리고 배포된 모델이 다시 데이터를 만들어내는 순환.
  • 포털·관측: 위에 분석사 포털(분석 환경/모델 개발 환경 신청, Job 관리)과 관리자 포털, 오른쪽에 또 세로로 강조된 모니터링. 여기서도 관측이 전 층을 관통한다.

첫 장의 관점에서 보면, 이 두 번째 플랫폼 전체가 사실 CMP 위에 새로 얹히는 “Intelligence 계층” 이다. Container 위에서 GPU로 모델이 돌고(소비), 그 모델이 나중에 CI/CD와 모니터링을 조종한다(제어).


3. 데이터 거버넌스·분석 플랫폼 — 혈액과 그 규율

데이터 거버넌스/분석 플랫폼 — 공통 포털·분석가/관리자 포털 / 데이터 관리·데이터 모델 관리·데이터 모델 서비스(에이전트) / 데이터 표준·거버넌스·메타 / Data Lifecycle 프로세스 / 연계 Gateway·모니터링·Solution(Data Catalog·BI·GitLab)

셋째 장은 데이터 거버넌스/분석 플랫폼이다. AI가 아무리 좋아도 데이터가 더럽거나 통제 안 되면 무너진다 — 이 장은 그 데이터의 규율을 다룬다. 구조는 이렇게 읽는다.

  • 맨 아래 — 프로세스: Data Lifecycle 관리 프로세스 (권한 신청). 데이터의 생성·활용·폐기 전 과정이 권한 신청/결재를 타고 흐른다. 아무나 아무 데이터에 손대지 못한다.
  • 표준/거버넌스 계층: 데이터 표준/표준 체계 관리 · 데이터 모델 표준 관리 · 데이터 거버넌스 · 비즈니스 메타 관리. 이름·형식·의미의 표준을 강제하는 층 — 데이터가 신뢰 가능해지는 근거.
  • 핵심 기능 (좌→우):
    • 데이터 관리 — 검색 · 추출/통합 · 분석 · 관리
    • 데이터 모델 관리 — 학습 · 모델링 · 평가/검증 · 관리
    • 데이터 모델 서비스 — 여기서 눈에 띄는 것: 에이전트 생성 · 에이전트 갤러리. 데이터/모델 위에서 곧바로 AI 에이전트를 찍어내고 카탈로그로 공유한다. 청사진 단계에서 이미 “에이전트”가 일급 시민이다.
  • 접점: 위의 공통 포털(통합검색·게시판·도움말), 데이터 분석가 포털(데이터 조회/신청, 결재 요청), 관리자 포털(권한/계정/품질/정책).
  • 오른쪽 세로축 — 연계와 관측: 연계/Link Gateway모니터링(감사 및 통계, 데이터 거버넌스 준수율, 데이터 변경사항 모니터링, 사후 관리, 외부 연계 자원 모니터링) → 최종 Solution(분석계 · 통합 결재 · Data Catalog · BI 포털 · GitLab).

거버넌스 “준수율”을 상시 모니터링한다는 점이 핵심이다. 데이터 품질과 규정 준수를 측정 가능한 지표로 관리한다 — AI의 연료가 오염되지 않도록.


4. 세 장을 겹치면 — 하나의 스택

세 청사진은 사실 한 스택의 세 단면이다. 아래에서 위로 쌓으면 이렇게 맞물린다.

                에이전트 (세로 관통: 세 층을 호출·제어)
   ┌──────────────────────────────────────────────┐
   │  ③ 데이터 거버넌스   — 혈액과 규율             │  신뢰 가능한 데이터
   │     (표준·거버넌스·Data Catalog·에이전트)      │
   ├──────────────────────────────────────────────┤
   │  ② AI/ML 플랫폼      — 신경계 공장             │  모델 생명주기 + GPU
   │     (데이터→학습→평가→배포, MLOps)             │
   ├──────────────────────────────────────────────┤
   │  ① 클라우드 관리     — 뼈대                    │  Container·CI/CD·MSA
   │     (K8s·DevOps·관측·Security 관통)            │
   └──────────────────────────────────────────────┘
                모니터링 (세 장 모두에서 강조된 그 눈)
  • ①이 없으면 ②③은 돌 곳이 없다. 컨테이너·GPU 스케줄링·네트워크가 기반이다.
  • ③이 없으면 ②는 오염된 연료로 학습한다. Garbage in, garbage model.
  • ②가 없으면 ①③은 규칙 기반에 머문다. 스스로 판단하는 신경이 없다.
  • 그리고 세 장 모두 모니터링을 유독 따로, 세로로 그렸다. 관측은 어느 한 층이 아니라 전체를 꿰는 척추다.

가장 흥미로운 변화는 세 번째 그림의 에이전트 생성/갤러리다. 에이전트는 더 이상 한 층의 기능이 아니라, 세 층을 위아래로 호출하며 관통하는 실행 주체가 되고 있다. 데이터를 조회하고(③), 모델을 부르고(②), 배포·조치를 실행한다(①).


5. 슬라이드가 아니라 실제로 — K3s 홈랩의 증거

이건 발표 자료 속 이야기가 아니다. 나는 이 세 층을 6노드 K3s 홈랩에서 실제로 굴린다.

  • ① 뼈대: 모든 워크로드가 K3s(Container) 위에서 GitOps(ArgoCD)로 배포되고, MSA(정산·커머스)가 Kafka Saga로 엮인다. Prometheus·Grafana·ELK·Tempo가 관측을 받치고, 핵심 서비스는 actuator/health를 딥체크해 상태가 바뀔 때만 텔레그램으로 알린다.
  • ②③ 데이터·지능: 벡터DB·RAG·모델 연동이 그 위에 얹힌다.
  • 에이전트 관통: 그리고 결정적으로 — 나는 텔레그램에서 AI 에이전트에게 지시한다. “이 버그 고쳐” 한마디에 에이전트가 코드를 고치고, CI를 돌리고, PR을 만들고, 배포와 관측까지 확인한다. 세 장의 그림을 위아래로 관통하는 그 “에이전트”가, 내 홈랩에선 이미 매일 일하고 있다.

지금 읽는 이 글 자체도, 내가 텔레그램으로 그림 세 장을 던지자 에이전트가 구조를 읽고 써 내려간 결과다.


6. 한눈 정리

청사진 역할 핵심 특징 AI/에이전트의 자리
① 클라우드 관리 뼈대 Container·CI/CD·MSA·Security 관통 AIOps · AI 리뷰 · 관측 요약
② AI/ML 플랫폼 신경계 공장 데이터→학습→평가→배포, GPU 스케줄링 플랫폼 자체가 지능 생산
③ 데이터 거버넌스 혈액과 규율 표준·거버넌스·Data Catalog·에이전트 갤러리 신뢰 데이터 + 에이전트 발행

플랫폼의 계층 구조는 앞으로도 남을 것이다. 뼈대는 튼튼하니까. 달라지는 것은, 그 관절마다 스스로 판단하고 반응하는 신경이 깔리고, 세 층을 위아래로 오가는 에이전트가 실행 주체로 올라선다는 점이다. 어디까지 자율에게 맡기고 어디서 사람이 손을 얹을지 — 그 경계를 설계하는 일이, 다음 몇 년 플랫폼 엔지니어의 진짜 과제다.