[케클러 인터뷰 시리즈] #5 - AI가 클라우드를 운영하려면, 데이터부터 이해해야 합니다

 

kt cloud 마케팅커뮤니케이션팀

 

📝 요약 SUMMARY

‘기술이 장르가 되는 곳, kt cloud의 케클러 인터뷰 시리즈’는 케클러들의 목소리를 통해 고객의 다음 문제를 먼저 고민하는 kt cloud의 기술적 지향점과 해법을 전합니다.

다섯 번째 호에서는 데이터 기반의 지능형 클라우드 운영 모델을 만드는 kt cloud Data플랫폼팀 김종민 팀장을 만났습니다.

흩어진 클라우드 데이터를 연결하는 Observability부터 AI가 분석하고 운영자의 판단을 지원하는 *AIOps까지, AI 시대의 클라우드 운영 방식이 어떻게 만들어지고 있는지 살펴봅니다.

#ktcloud #Observability #AIOps #AIAgent #CloudNative

---

kt cloud Data플랫폼팀 김종민 팀장

 

안녕하세요. kt cloud 마케팅커뮤니케이션팀입니다.

 

클라우드 환경이 복잡해질수록 운영자가 확인해야 할 데이터도 빠르게 늘어납니다. 특히 Cloud Native 환경에서는 하나의 요청이 여러 마이크로서비스와 인프라를 거치기 때문에, 문제가 나타난 지점과 실제 원인이 발생한 지점이 다를 수 있습니다.

 

AI를 클라우드 운영에 활용하려면 또 하나의 조건이 필요합니다. AI가 운영자의 판단을 제대로 지원하려면 각 시스템에 흩어진 데이터가 서로 연결되고, 그 데이터가 어떤 서비스와 자원을 의미하는지 맥락까지 확인할 수 있어야 합니다.

 

이번 인터뷰에서는 kt cloud Data플랫폼팀 김종민 팀장과 함께 AI가 활용할 수 있는 클라우드 운영 데이터가 어떻게 만들어지는지, Observability(관측 가능성)를 기반으로 클라우드 운영 방식이 어떻게 변화하고 있는지 살펴봅니다.

 

※Observability는 시스템에서 발생하는 데이터를 바탕으로 시스템의 상태와 문제의 원인·맥락을 파악할 수 있도록 하는 관측 체계입니다.

 

 

💡이야기를 시작하며

 김종민 팀장 | kt cloud Data플랫폼팀

20여 년간 게임·통신·플랫폼 서비스와 CSP·MSP를 거치며 Public·Private·Cloud Native 환경을 경험했고, Linux Foundation 오픈소스 프로젝트 CMP Cloudforet에서 Technical Lead를 맡았습니다.
현재 kt cloud에서 Observability 및 Data Platform을 구축하고 있으며, 분산된 클라우드 운영 데이터를 연결해 AI가 활용할 수 있는 지능형 클라우드 운영 모델을 만들어가고 있습니다.

 이번 인터뷰의 주인공이 꼽은 '이 글이 필요한 분들'

↳ AI·Cloud Native 환경의 플랫폼 아키텍처를 설계하는 기술 리더
↳ 대규모 분산 환경의 Observability와 운영 자동화를 고민하는 DevOps·SRE 엔지니어
↳ 운영 데이터와 AI를 연결한 AIOps 도입을 검토하는 아키텍트·엔지니어

---

Part 1. 장애 알람은 울리는데, 왜 원인은 바로 알 수 없을까?

복잡한 Cloud Native 환경에서 기존 모니터링의 한계

 

기존 모니터링의 역할은 비교적 명확했습니다. CPU·메모리·디스크처럼 미리 정의한 지표를 지속적으로 확인하고, 기준을 벗어나면 알람을 보내는 방식입니다. 감시 대상이 고정되어 있고 서비스 구조가 단순할 때는 이러한 방식으로도 문제를 확인할 수 있었습니다.

 

하지만 Cloud Native 환경에서는 상황이 달라집니다. 컨테이너가 수시로 생성되고 사라지며, 하나의 요청이 여러 마이크로서비스를 거쳐 처리됩니다. 문제가 나타난 지점과 실제 원인이 있는 지점이 다른 경우도 많아 하나의 알람만으로 원인을 파악하기 어렵습니다.

 

예를 들어 특정 서비스의 응답 지연 알람이 발생했더라도 인프라 지표는 정상일 수 있고, 애플리케이션 로그에서도 바로 오류가 발견되지 않을 수 있습니다. 결국 운영자는 여러 시스템과 대시보드를 오가며 데이터를 확인하고, 관련 담당자들과 정보를 맞춰가며 원인을 좁혀야 합니다. 이 과정에서는 원인을 분석하는 시간만큼 데이터를 찾고 연결하는 데 많은 시간이 들어갑니다. 어느 시스템을 확인해야 하는지에 대한 판단 역시 담당자의 경험에 의존하기 쉽습니다.

 

김종민 팀장은 바로 이 지점에서 ‘모니터링’과 ‘Observability’의 차이가 시작된다고 설명합니다.

모니터링이 이미 알고 있는 문제를 감시하는 방식이라면, Observability는 예상하지 못한 문제가 발생했을 때도 남아 있는 데이터를 통해 원인을 추적할 수 있는 상태를 만드는 것입니다.

 

kt cloud Observability Platform은 개별 지표를 확인하는 데 그치지 않고, 문제가 나타난 지점에서 실제 원인이 있는 구간까지 데이터를 따라갈 수 있는 운영 기반을 만드는 데 초점을 맞추고 있습니다.

 

데이터가 연결되면 장애를 분석하는 방식도 달라집니다. 과거에는 각 시스템 담당자가 자신의 영역을 개별적으로 확인한 뒤 결과를 맞춰가며 원인을 좁혔다면, 이제는 하나의 데이터 흐름을 함께 보면서 문제가 어디에서 시작되고 어디까지 영향을 미쳤는지 확인할 수 있습니다. 담당자의 경험에 의존하던 장애 분석 과정을 공통된 데이터와 절차를 기반으로 수행할 수 있게 되는 것입니다.

---

Part 2. AI 운영의 출발점, 흩어진 신호를 하나의 데이터로 연결

Metric·Log·Trace를 하나의 흐름으로 연결

 

AI가 운영자의 의사결정을 지원하려면 먼저 신뢰할 수 있는 데이터가 필요합니다.

 

Observability의 핵심 데이터인 *Metric·*Log·*Trace는 각각 다른 정보를 제공합니다. Metric은 무엇이 언제부터 이상해졌는지를 보여주고, Log는 해당 시점에 시스템에서 어떤 일이 발생했는지를 기록합니다. Trace는 하나의 요청이 여러 서비스를 거치는 동안 어느 구간에서 지연되거나 실패했는지를 추적합니다.

 

각 데이터가 서로 다른 시스템에 따로 쌓여 있으면 필요한 정보를 모두 가지고 있어도 원인을 찾기 어렵습니다. Metric에서 이상 구간을 발견한 뒤 같은 시간대의 Log를 다시 검색하고, 해당 요청의 전체 경로를 확인하기 위해 또 다른 시스템으로 이동해야 하기 때문입니다.

 

kt cloud는 이를 해결하기 위해 *OpenTelemetry를 표준 수집 규격으로 활용하고, Metric·Log·Trace를 하나의 데이터 흐름으로 연결했습니다. Metric에서 이상 구간을 확인한 뒤 관련 Log로 이동하고, 다시 해당 요청의 Trace를 따라 전체 호출 경로를 확인할 수 있도록 한 것입니다. 수집 범위도 애플리케이션에 한정하지 않았습니다. 실제 원인이 네트워크나 인프라 계층에 있다면 애플리케이션 데이터만으로는 원인을 찾을 수 없기 때문입니다. 네트워크, 인프라, 플랫폼, 애플리케이션까지 클라우드의 각 계층에서 발생하는 데이터를 함께 수집합니다.

 

김종민 팀장이 이 과정에서 중요하게 본 기준은 연결성, 일관성, 규모입니다. 서로 다른 데이터가 같은 기준으로 검색되고 연결될 수 있어야 하며, 서비스·자원·리전·테넌트 등의 레이블과 데이터 규격도 일관되게 관리되어야 합니다. 동시에 대규모 클라우드 환경에서 빠르게 증가하는 데이터를 안정적으로 처리할 수 있어야 합니다.

특히 AI가 데이터를 활용하려면 데이터 자체뿐 아니라 ‘이 데이터가 어떤 서비스와 자원에 속하며 무엇을 의미하는지’가 데이터 안에 명확하게 정의되어 있어야 합니다.

 

사람은 여러 화면과 경험을 바탕으로 맥락을 추론할 수 있지만, AI는 그 관계가 데이터로 표현되어 있어야 하기 때문입니다. 서로 다른 계층에서 발생한 데이터를 같은 이름과 기준으로 정리하는 작업이 중요한 이유입니다.

---

Part 3. 데이터를 연결하니, AI가 운영을 이해하기 시작했다

AI Agent와 Observability 및 사내 운영 시스템을 연결

 

데이터가 연결됐다면 다음 과제는 AI가 이 데이터를 어떻게 안전하게 활용할 것인가입니다.

 

가장 단순한 방법은 AI Agent를 각각의 운영 시스템에 직접 연결하는 것입니다. 하지만 시스템이 늘어날수록 연결 구조가 복잡해지고, 인증 방식과 권한 체계도 시스템별로 관리해야 합니다.

Data플랫폼팀은 시스템마다 별도의 연결을 만드는 대신 MCP Hub라는 공통 연결 계층을 두는 구조를 선택했습니다.

 

kt cloud Observability Platform이 운영 데이터를 수집·저장하고 AI Agent가 사용자의 질문을 분석한다면, MCP Hub는 그 사이에서 AI와 실제 운영 시스템을 연결합니다.

중요한 점은 AI가 데이터 저장소에 직접 접근하지 않는다는 것입니다. MCP Hub에는 ‘특정 기간의 지표 조회’, ‘특정 자원의 상태 확인’처럼 목적이 정의된 도구가 등록되고, AI Agent는 필요한 도구를 선택해 호출합니다.

여기서 도구를 어떤 단위로 정의할 것인가도 중요한 설계 요소입니다. 범위가 지나치게 넓으면 AI가 적절한 도구를 선택하기 어렵고, 반대로 너무 세분화하면 하나의 질문을 해결하기 위해 불필요하게 많은 호출이 필요합니다. 김종민 팀장은 운영자가 실제로 질문하는 단위를 기준으로 도구를 설계했습니다.

 

즉 AI에게 데이터 전체를 열어주는 것이 아니라, 무엇을 어떤 방식으로 조회할 수 있는지를 사전에 정의하는 구조입니다. 향후에는 관제 시스템과 협업 도구도 같은 구조로 연결해 데이터 조회부터 분석, 결과 공유까지 하나의 운영 흐름으로 이어갈 계획입니다.

---

Part 4. AI의 데이터 접근, 어떻게 통제할 것인가

AI의 운영 데이터 접근을 통제하고 이력까지 관측

 

AI가 운영 시스템에 접근하기 시작하면 보안과 권한 관리도 함께 고려해야 합니다. AI가 활용할 수 있는 데이터와 도구가 늘어날수록 누가 무엇에 접근했고, 그 요청이 어떻게 처리됐는지를 명확하게 확인할 수 있어야 합니다.

김종민 팀장은 이를 세 가지 질문으로 설명합니다.

 

🤖 AI 데이터 접근의 3가지 원칙

1️⃣ 누가 요청했는가?

2️⃣ 무엇까지 볼 수 있는가?

3️⃣ 요청은 어떻게 처리됐는가?

 

kt cloud는 MCP Hub를 중심으로 인증 및 인가 체계를 연결합니다. AI Agent가 자체 권한으로 데이터를 조회하는 것이 아니라 요청한 사용자의 신원을 각 시스템까지 전달하고, 최종 데이터 접근 여부는 각 시스템의 권한 정책에 따라 결정합니다.

 

즉 MCP Hub가 모든 권한을 대신 판단하는 것이 아니라, 사용자의 신원과 요청을 일관된 방식으로 전달하고 각 시스템이 기존 권한 정책에 따라 접근 여부를 판단하도록 하는 구조입니다. 이를 통해 AI가 연결되더라도 기존 운영 시스템의 보안 원칙과 데이터 접근 경계를 유지할 수 있습니다.

 

AI의 활동 역시 Observability의 대상입니다. 어떤 사용자가 어떤 도구를 호출했고 어떤 정보가 오갔는지를 기록하고, 외부로 전달되면 안 되는 정보나 AI의 동작에 영향을 줄 수 있는 외부 지시가 포함되어 있는지도 확인합니다. 이 기록은 다시 kt cloud Observability Platform에 적재되어 다른 운영 데이터와 함께 분석됩니다.

 

AI가 어떤 데이터에 접근하고, 이를 어떻게 활용하는지까지 신뢰할 수 있는 운영 체계 안에서 관리해야 합니다. 김종민 팀장은 이를 AI 기반 클라우드 운영을 위한 핵심 전제로 보고 있습니다.

---

Part 5. OSS를 기반으로 kt cloud 환경에 필요한 기술을 직접 만들다

Grafana LGTM·OpenTelemetry와 자체 컴포넌트를 결합

 

kt cloud Observability Platform은 *Grafana LGTM과 OpenTelemetry 기반의 OSS 생태계를 활용합니다.

 

상용 솔루션 대신 OSS를 선택한 것은 비용뿐 아니라 기술을 직접 통제할 수 있는 구조가 필요했기 때문입니다. Observability는 내부 운영 도구이면서 동시에 고객에게 제공되는 서비스이기 때문에, *CSP 환경에 맞게 기능을 확장하고 다른 서비스와 연결할 수 있어야 한다고 판단​했습니다.

 

다만 오픈소스를 그대로 적용하지는 않았습니다. 대규모 CSP 환경에 필요한 *멀티테넌시·권한 관리·확장성을 구현하기 위해 Telemetry Gateway와 Siren을 직접 개발했습니다.

 

Telemetry Gateway는 고객별 관측 데이터를 테넌트 단위로 격리하고 적절한 클러스터로 연결합니다. 데이터가 증가하면 동일한 구조의 클러스터를 추가하고 Gateway가 테넌트에 따라 요청을 분산시키는 방식으로 규모에 대응합니다. Siren은 서로 다른 알람과 레이블, 대시보드 연결 규격을 표준화해 운영자가 같은 방식으로 알람을 확인할 수 있도록 합니다.

 

여기에는 한 가지 원칙이 있습니다. 오픈소스의 소스코드 자체를 수정하지 않는 것입니다. CSP에 필요한 기능은 독립적인 컴포넌트로 구현해 오픈소스의 발전을 그대로 따라가면서도 필요한 기능은 kt cloud의 속도로 개발할 수 있도록 했습니다. 김종민 팀장은 이를 “내재화가 부채가 아니라 자산이 되게 만드는 구조”라고 설명합니다.

---

Part 6. 고객 데이터와 운영 데이터, 처음부터 경계를 나누다

고객 데이터와 kt cloud 운영 데이터를 별도 클러스터에 저장

 

‘고객 데이터’와 ‘내부 운영 데이터’의 격리는 Observability Platform을 설계할 때 중요하게 고려한 원칙입니다.

 

고객 데이터에는 고객이 어떤 자원을 사용하고 어떤 로그를 남기는지가 담기는 반면, 내부 운영 데이터에는 노드나 플랫폼 컴포넌트의 상태 등 kt cloud가 운영을 위해 확인해야 하는 정보가 담깁니다. 볼 수 있는 대상과 보호해야 할 기준이 다르기 때문에 저장 단계부터 경계를 나눴습니다.

 

두 데이터를 하나의 저장소에 두고 권한만으로 구분할 수도 있지만, 권한 설정에만 의존하면 설정 오류가 곧 데이터 노출로 이어질 수 있습니다. 김종민 팀장은 고객 데이터와 내부 운영 데이터를 서로 다른 클러스터에 저장해 저장 계층부터 데이터 경계를 분리했습니다. 고객 데이터가 저장되는 클러스터 안에서도 Telemetry Gateway가 프로젝트를 관측 데이터의 테넌트로 매핑해 고객별 데이터가 서로 섞이지 않도록 격리합니다.

 

이는 사후에 접근 기록을 확인하는 것보다 애초에 서로 닿을 수 없는 구조를 만드는 접근입니다. 실제로 Data플랫폼팀은 공공 부문 클라우드 인증 요건까지 고려해 설계 단계부터 데이터 격리를 구조에 반영했습니다.

 

이렇게 데이터의 경계를 명확하게 설계하면 보안뿐 아니라 유연한 플랫폼 확장에도 유리합니다.

새로운 kt cloud PLATFORM 서비스가 추가되더라도 별도의 격리 구조를 매번 설계하는 대신, 기존의 공통 원칙과 구조를 그대로 적용해 확장할 수 있기 때문입니다.

---

Part 7. AI가 먼저 분석하고, 운영자는 판단한다

데이터 기반의 지능형 클라우드 운영 모델

 

실제 클라우드 운영에서는 “왜 자원이 늘었는가”, “어떤 고객과 서비스에 영향을 주는가”, “현재 사용량이 비용 측면에서 어떤 의미인가”와 같은 질문도 발생합니다. Metric·Log·Trace만으로는 답하기 어려운 영역입니다. 이를 위해 Data플랫폼팀은 클라우드 자원과 고객, 비용과 매출 등 판단에 필요한 데이터를 함께 연결하는 통합 데이터 플랫폼으로 범위를 확장하고 있습니다.

 

여기에 *MCP Hub와 *AI Agent가 연결되면 운영 방식도 달라집니다. 장애가 발생하면 AI가 Metric·Log·Trace를 분석해 문제가 발생한 구간을 좁히고, 관련 서비스와 자원을 연결해 무슨 일이 발생했고 어디까지 영향을 미쳤는지 정리합니다. 과거의 유사 장애와 대응 이력까지 연결하면 필요한 조치도 함께 제시할 수 있습니다.

 

운영자는 여러 시스템을 오가며 데이터를 찾는 데서 시작하는 대신, AI가 정리한 상황을 바탕으로 ‘어디를 볼 것인가’보다 ‘무엇을 할 것인가’를 판단하는 데 집중​할 수 있습니다.

 

kt cloud는 내부 운영에서 먼저 검증하고 개선한 경험을 바탕으로, Observability를 AI가 이해하고 활용할 수 있는 지능형 데이터 플랫폼으로 확장하고 고객이 활용할 수 있는 서비스로 이어갈 계획입니다.

 

 

 

---

📚관련 용어 설명

• Observability(옵저버빌리티, 관측 가능성): 시스템에서 발생하는 Metric·Log·Trace 등의 데이터를 바탕으로 서비스의 상태뿐 아니라 문제의 원인과 맥락까지 파악할 수 있도록 하는 관측 체계입니다.
• AIOps(AI for IT Operations): AI와 데이터 분석 기술을 IT 운영에 적용해 장애 탐지·분석·대응 및 운영 의사결정을 지원하는 방식입니다.
• Monitoring(모니터링): CPU·메모리·디스크 등 미리 정의한 지표와 임계치를 지속적으로 확인해 이상 상태를 감지하는 방식입니다.
• Metric(메트릭): CPU 사용률, 응답 시간 등 시스템이나 서비스의 상태 변화를 수치로 나타낸 데이터입니다.
• Log(로그): 애플리케이션과 시스템에서 발생한 이벤트와 동작을 시간 순서대로 기록한 데이터입니다.
• Trace(트레이스): 하나의 요청이 여러 서비스와 시스템을 거치는 전체 호출 경로를 추적하는 데이터입니다.
• OpenTelemetry: Metric·Log·Trace 등의 텔레메트리 데이터를 생성·수집·전달하기 위한 오픈소스 관측 프레임워크입니다.
• CSP(Cloud Service Provider): 컴퓨팅·스토리지·네트워크 등 클라우드 인프라와 서비스를 제공하는 사업자를 의미합니다.
• Grafana LGTM: Loki(Log), Grafana(Visualization), Tempo(Trace), Mimir(Metric)를 중심으로 구성되는 Observability 기술 스택입니다.
• MCP(Model Context Protocol) Hub: AI Agent와 다양한 운영 시스템 사이에서 데이터 및 도구 접근을 연결하고 인증·인가와 접근 경로를 통제하는 kt cloud의 연결 계층입니다.
• AI Agent: 주어진 목표나 사용자의 질문에 따라 필요한 데이터와 도구를 선택하고 분석·실행하는 AI 기반 시스템입니다.
• 멀티테넌시(Multi-tenancy): 하나의 플랫폼을 여러 고객이나 조직이 함께 사용하면서도 각 사용자의 데이터와 자원을 논리적으로 격리하는 구조입니다.