[구축사례] 흩어진 운영 데이터를 하나로, kt cloud 운영 데이터 통합 플랫폼 Deck 구축기

 

Tech-Frontier.md  kt cloud

$ whoami --team ❯ kt cloud Data플랫폼팀 김주환 님

📋 요약 TL;DR

이 글에서는 분산된 클라우드 운영 데이터를 통합하기 위한 레이크하우스 기반 데이터 플랫폼 Deck의 구축 과정을 다룹니다. 운영 데이터의 기준을 일원화해 과금, 분석, 의사결정의 신뢰성을 높이는 방향을 정리합니다. #데이터플랫폼 #레이크하우스 #ObjectStorage #Trino #Kafka

---

데이터는 넘치는데, 정작 쓸 수가 없었다

클라우드를 운영할수록 로그, 지표, 이벤트, 사용량 데이터가 쉴 새 없이 쌓입니다. 문제는 이 데이터들이 시스템마다 서로 다른 형태로, 서로 다른 위치에 흩어진다는 점입니다. 정보 하나를 확인하려 여러 도구를 차례로 열어야 하고, 장애가 나면 "무엇이 멈췄나"를 넘어 "왜 멈췄나"까지 가는 데 시간이 한참 걸립니다. 같은 데이터를 팀마다 다시 수집, 가공하는 비효율도 반복됐습니다.

 

결국 본질은 이거였습니다. 데이터는 충분히 존재하지만, 의사결정에 쓸 수 있는 형태로 연결되어 있지 않다.

---

그래서 필요했던 것: 데이터를 잇는 하나의 기준

이 문제를 풀려면 데이터를 개별 시스템에 흩어둔 채로는 안 됐습니다. 필요한 건 단순한 저장 공간이 아니라, 흩어져 생성되는 운영 데이터를 수집부터 저장, 활용까지 하나의 흐름으로 연결하는 기반이었습니다.

 

요건은 세 가지로 정리됐습니다. 여러 서비스에서 발생하는 데이터를 공통 방식으로 수집하고, 동일한 기준으로 저장해 특정 도구나 시스템에 종속되지 않게 하며, 누구나 같은 데이터를 기준으로 분석, 판단할 수 있어야 했습니다. 그래야 운영팀, 개발팀은 물론 사업 조직까지 동일한 근거 위에서 의사결정을 내릴 수 있습니다.

 

이 요건을 충족하기 위해 만든 통합 데이터 플랫폼이 Deck입니다. 단순 수집 도구가 아니라, 서비스 증가와 데이터 규모 확장에 대응하는 표준 저장, 처리 체계를 목표로 합니다.

---

왜 레이크하우스인가, 그리고 두 가지 설계 원칙

데이터 플랫폼 아키텍처는 분석 효율과 확장성을 좇아 Data Warehouse에서 Data Lake로, 다시 Data Lakehouse로 진화해 왔습니다.

구분	Data Warehouse	Data Lake	Data Lakehouse ⭐
데이터 유형	정형	정형 / 반정형 / 비정형	정형 / 반정형 / 비정형
트랜잭션	강함	약함	ACID 지원
장점	신뢰성	유연성	유연성 + 신뢰성
한계	확장성, 비용	품질 관리	구현 복잡도

 

웨어하우스는 신뢰성은 높지만 정형 데이터에 갇혀 있고, 레이크는 유연하지만 품질, 정합성 보장이 어렵습니다. 클라우드 운영 데이터는 정형 사용량부터 비정형 로그까지 다양하면서도 과금 같은 영역에선 신뢰성이 필수였습니다. 레이크의 유연성 위에 ACID와 스키마 관리를 얹어 신뢰성까지 잡는 레이크하우스가 가장 맞았습니다.

 

그 위에 Deck 전체를 관통하는 두 원칙을 세웠습니다. 첫째, 순수 오픈소스로 직접 구축한다. 벤더에 종속되지 않아야 기술 선택의 자율성을 지키고, 자체 운영으로 라이선스 비용을 최소화해 장기 비용 효율을 확보할 수 있다고 봤습니다. 둘째, Object Storage를 단일 기준 저장소(SSOT)로 둔다. 원본은 한 번만 저장하고, 이후 단계에선 복제하지 않고 같은 원본을 참조하거나 파생 형태로 재사용합니다. 덕분에 데이터 중복과 관리 복잡도가 크게 줄었습니다.

---

레이어마다 어떤 오픈소스를, 왜 골랐나

Deck은 Object Storage를 축으로 한 Layered Architecture입니다. 각 레이어는 독립적으로 동작하며, 여기서부터는 결과보다 선택의 이유가 더 흥미로운 지점입니다.

레이어	핵심 기술	선택 이유
🚄 수집	Kafka, Vector	Kafka는 안정성이 검증됐고 KRaft로 운영 부담이 줄었으며 연동이 표준화돼 있음. Vector는 경량, 고성능에 전처리가 유연
📁 저장	Object Storage	확장성, 내구성, 비용 효율이 높고 엔진 중립적이라 모든 레이어가 독립 접근 → SSOT의 물리적 기반
🔥 쿼리	Trino	적재 없이 Object Storage를 바로 SQL로 조회하는 대화형 분석. 레이크하우스 사실상 표준
⚙️ 처리	Airflow, Spark	Airflow가 배치 파이프라인의 스케줄, 의존성, 재처리를 관리, 대용량 정제, 집계는 Spark가 담당
🚀 서빙	StarRocks	실시간 Upsert와 고속 조인에 강하고 스토리지, 컴퓨트 분리로 저지연 OLAP 서빙
🖥️ 표현	Superset	완전 오픈소스 BI로 라이선스 비용이 없고 벤더 비종속

 

레이어를 나눈 의도는 분명합니다. 하나의 엔진이 수집부터 서빙까지 떠받치면 어딘가 반드시 병목이 됩니다. 목적별로 최적화된 도구를 두고, Object Storage라는 공통 기준 위에서 각 레이어를 독립적으로 확장할 수 있게 한 것입니다.

---

Deck 적용 사례: 빌링 파이프라인

Deck이 풀어낸 대표적인 적용 사례는 빌링 파이프라인입니다.

 

클라우드 서비스는 사용량 기반 과금(Usage-based Billing)을 위해 리소스 사용 정보를 정확히 수집하고 요금을 산정해야 합니다. 수십 종의 클라우드 상품을 다루는 kt cloud PLATFORM 환경에서는 미터링부터 과금, 청구까지를 하나의 일관된 기준으로 처리할 수 있는 데이터 기반 체계가 핵심 과제였습니다. 서비스별 사용량 기준을 표준화하고, 정책 변경에 유연하게 대응하며, 과금 근거 데이터를 추적, 검증할 수 있어야 했습니다.

 

Deck은 이 전 과정을 레이어 흐름 하나로 꿰었습니다. 각 서비스의 사용량 데이터가 수집(Kafka, Vector) 단계로 들어와 저장(Object Storage)에 단일 기준 원본으로 적재되고, 처리(Airflow, Spark)가 이를 서비스, 기간, 지표 단위로 정제, 집계해 과금용 미터링 데이터로 가공하며, 서빙(StarRocks)이 이를 저지연으로 조회할 수 있게 제공합니다. 같은 원본을 복제 없이 흘려보내므로 과금 근거의 정합성과 추적성이 그대로 유지됩니다.

 

이 구조가 가져온 효과는 다음과 같습니다.

Deck 기반 빌링 파이프라인의 효과

단일 기준 원본 위에서 서비스별 사용량을 표준 정산 구조로 처리

정책 기반 요금 체계로 신규 상품 추가 시에도 별도 개발 없이 과금 자동화

원본 기반의 과금 근거 추적, 검증 및 Cost Explorer 비용 분석 제공

 

핵심은 미터링부터 청구까지가 하나의 데이터 기준 위에서 일관되게 처리된다는 점입니다.

---

앞으로

앞으로는 클라우드 운영 데이터를 단계적으로 더 적재해 활용 사례를 넓히고, Deck을 단순 저장 환경이 아니라 운영 의사결정을 지원하는 분석 플랫폼으로 확장하려 합니다. 데이터가 늘어도 자원을 유연하게 키우는 확장성, 신규 서비스, 테넌트 추가 시 수작업을 줄이는 서비스 자동화, Multi-tenancy 기반 인증, 인가와 RBAC을 포함한 통합 보안 체계도 함께 다져 갈 계획입니다.

 

흩어진 데이터를 하나로 모으는 일은 화려하지 않지만, 클라우드 운영의 거의 모든 판단이 그 위에서 이뤄집니다. Deck이 그 단단한 바닥이 되도록 계속 다듬어 가겠습니다.

 

---

?› 자주 묻는 질문 FAQ

Q. Trino, Spark, StarRocks 모두 데이터를 다루는 엔진인데 역할이 겹치지 않나요?

A. 같은 SQL/처리 엔진처럼 보여도 최적화 지점이 다릅니다. Trino는 적재 없이 Object Storage를 바로 SQL로 조회하는 대화형 탐색에, Spark(+Airflow)는 대용량 원천을 정제, 집계, 재처리하는 배치 처리에, StarRocks는 가공된 집계 데이터를 다수 사용자가 동시에 저지연으로 조회하는 OLAP 서빙에 강합니다. 하나의 엔진으로 전부 떠받치면 어느 한쪽이 병목이 됩니다. 목적별로 분리해 각 레이어를 독립적으로 확장할 수 있게 한 선택입니다.

---