기술 블로그 (Tech) | kt cloud

[구축사례] kt cloud PLATFORM Observability Alert 플랫폼 구축하기

kt cloud 기술 블로그 — Thu, 20 Aug 2026 14:46:24 +0900

Tech-Frontier.md

kt cloud

$ whoami --team
❯ kt cloud Data플랫폼팀 유지연 님

요약

TL;DR

이 글에서는 KCP 클라우드 환경에서 Observability Alert 플랫폼을 구축하고
조직별 Alert 격리, 통합관제 연동, 이력 관리 체계를 설계한 과정을 다룹니다.
안정적인 클라우드 운영을 위해 Alert를 단순 알림이 아닌 운영 정책으로 관리해야 하는 이유를 정리합니다.

#Observability #Alert플랫폼 #LGTM스택 #통합관제 #멀티테넌트

1. 왜 Observability Alert 플랫폼을 직접 만들었나 — 문제의 출발점

클라우드 플랫폼을 운영하다 보면 자연스럽게 모니터링과 알림 체계가 고도화됩니다. 가상 서버, 네트워크, 컨테이너 플랫폼 각각을 감시하는 도구들이 늘어나면서, 어느 순간 "알림을 받는 것"보다 "어떤 알림을 어떤 팀에 어떻게 보낼 것인가"가 더 어려운 문제가 됩니다.

저희도 같은 지점에서 막혔습니다. KCP의 Observability 인프라는 Grafana, Loki, Tempo, Mimir로 구성된 LGTM 오픈소스 스택으로 잘 구축되어 있었습니다. 데이터 수집과 시각화는 이 스택이 충분히 처리해 주었지만, Alert 영역에서는 세 가지 문제가 반복됐습니다.

첫째, 조직(Org) 단위 Alert 격리가 어려웠습니다. Grafana는 데이터 조회를 조직 단위로 분리하지만, Alert 처리는 수집 테넌트(X-Scope-OrgID) 기준으로 동작합니다. 하나의 플랫폼을 여러 팀이 공유하는 환경에서 팀별로 완전히 독립된 Alert 정책을 운영하기가 구조적으로 어려웠습니다.

둘째, Alert 규모가 커질수록 확장성에 제약이 생겼습니다. Grafana Managed Alert는 설정과 사용이 직관적이지만, Alert 설정·평가·전송이 하나의 컴포넌트에 집중된 구조입니다. 엔터프라이즈 규모의 Alert 환경에서는 병목이 발생할 가능성이 있어, 컴포넌트를 분리하는 방향을 검토하게 됐습니다.

셋째, 표준화된 Alert API 계층이 없었습니다. Grafana에 종속된 구조에서 벗어나, 향후 자체 포털이나 외부 서비스에서도 동일한 인터페이스로 Alert를 생성·조회·관리할 수 있어야 했습니다.

세 문제의 공통점은 단순히 "알림 기능"이 부족한 게 아니라, Alert를 운영 정책으로 다룰 수 있는 계층이 없다는 것이었습니다. 저희는 외부 SaaS 도입 대신, LGTM 스택 위에 자체 Alert 관리 서비스를 구축하는 방향을 선택했습니다.

2. 전체 아키텍처

이번 구축의 목표는 통합관제 시스템 자체를 새로 만드는 것이 아니었습니다.
이미 운영 중인 통합관제 체계 앞단에서 Observability 데이터를 기반으로 Alert 이벤트를 생성하고, 이를 관제 시스템이 이해할 수 있는 표준 이벤트 형태로 전달하는 것이 핵심이었습니다.

전체 흐름은 다음과 같습니다

이 구조에서 Alert 관리 플랫폼은 Grafana, Mimir, Loki, 통합관제 시스템 사이의 중간 계층으로 동작합니다.
사용자는 Grafana를 통해 Alert를 관리하지만, 내부적으로는 API 계층에서 조직 정보, namespace, label, 이벤트 저장 구조를 일관되게 처리합니다.

3. 주요 설계 결정

Observability Alert 플랫폼을 구축하면서 가장 중요하게 본 지점은 단순히 Alert Rule을 생성하고 발송하는 기능이 아니었습니다.

실제 운영 환경에서는 여러 조직이 하나의 플랫폼을 함께 사용하고, Alert 이벤트가 통합관제 시스템까지 안정적으로 전달되어야 하며, 이후 장애 분석을 위해 이력도 남아야 합니다.

이를 위해 Alert 관리 계층에서는 다음 네 가지 설계 결정을 내렸습니다.

결정 1. 조직별 Alert 격리는 Namespace Prefix 방식으로 구현

KCP 환경에서는 여러 조직이 하나의 Observability Platform을 함께 사용합니다.
하지만 Alert Rule, Notification Policy, Silence와 같은 운영 설정은 조직별로 독립적으로 관리되어야 합니다.

이를 위해 두 가지 방식을 검토했습니다.

첫 번째는 클러스터 또는 백엔드 인스턴스를 조직별로 분리하는 방식입니다.
격리 수준은 높지만 조직이 늘어날수록 Mimir, Loki, Alertmanager 등의 컴포넌트를 각각 운영해야 하므로 인프라 비용과 운영 복잡도가 커집니다.

두 번째는 API 계층에서 namespace prefix를 주입하는 방식입니다.
Mimir와 Loki가 단일 인스턴스에서도 여러 tenant와 namespace를 처리할 수 있다는 점을 활용해, Alert 관리 API가 Rule 저장 시 namespace 앞에 조직 식별자를 추가하는 방식입니다.

예를 들어 특정 조직에서 cpu-alert라는 namespace를 생성하면, 백엔드에는 실제로 다음과 같이 저장됩니다.

cpu-alert → teamA_cpu-alert

저희는 두 번째 방식을 선택했습니다.
별도 인프라를 추가하지 않고도 조직 단위 격리를 구현할 수 있고, 사용자는 복잡한 backend tenant 구조를 직접 알 필요 없이 Grafana Organization 기준으로 Alert를 관리할 수 있기 때문입니다.

즉, Alert 관리 API 계층이 UI의 조직 구조와 백엔드의 namespace 구조 사이를 연결하는 역할을 하도록 설계했습니다.

결정 2. 통합관제 연계를 위해 Label 체계를 표준화

Alert를 통합관제 시스템으로 전달할 때 중요한 것은 Alert 조건 자체보다 이벤트를 식별할 수 있는 메타데이터였습니다.

예를 들어 CPU 사용률이 임계치를 초과했다는 Alert가 발생해도, 그 정보만으로는 관제 시스템이 이벤트를 정확히 처리하기 어렵습니다. 실제 운영에서는 다음 정보가 함께 필요합니다.

어떤 서비스 또는 인프라 대상에서 발생했는가
어느 지역 또는 영역에 속하는가
이벤트 유형은 Infra, Platform, Service 중 무엇인가
심각도는 어느 수준인가
관제 대상 식별자는 무엇인가
현재 상태가 발생인지, 해제인지

이를 위해 Alert Rule 생성 단계에서 필요한 label 체계를 정의했습니다.
관제 시스템으로 연계되는 Alert의 경우 필수 label이 누락되면 Rule 생성을 제한하도록 했습니다. 잘못된 label을 가진 Alert가 생성되면 이후 관제 시스템에서 대상을 찾지 못하거나 잘못된 이벤트로 분류될 수 있기 때문입니다.

이 과정에서 얻은 인사이트는 Alert 메시지보다 Label 설계가 운영 품질에 더 큰 영향을 준다는 점이었습니다.
메시지 문구가 잘 작성되어 있어도 label이 부정확하면 관제 시스템은 해당 이벤트를 올바른 대상으로 연결할 수 없습니다. 반대로 label 체계가 표준화되어 있으면 이벤트 분류, 담당 조직 식별, 후속 자동화까지 훨씬 수월해집니다.

결정 3. Alert 이벤트 저장 시 Loki 카디널리티를 낮게 유지

Alert 이벤트는 발생 순간에만 필요한 정보가 아닙니다.
장애가 언제 발생했고, 언제 해제되었으며, 어떤 대상에서 반복적으로 발생했는지 확인하려면 이력이 필요합니다.

이를 위해 Alert 이벤트를 Loki에 구조화된 로그 형태로 저장했습니다.
다만 모든 필드를 Loki label로 저장하지는 않았습니다.

Loki는 Stream Label을 기준으로 로그 스트림을 인덱싱합니다.
label 개수가 많아지거나 label 값의 종류가 지나치게 많아지면 카디널리티가 증가하고, 저장소 부하와 조회 비용이 커질 수 있습니다.

그래서 저장 필드를 두 가지로 나누었습니다.

구분	저장 필드 예시	용도
Stream Label	`status`, `event_level`, `type`, `region`	빠른 필터링에 사용하는 저카디널리티 필드
JSON Log Line	`event_id`, `alertname`, `target_ip`, `target_name`, `fingerprint`, `dashboard_url`	상세 조회와 분석에 사용하는 고카디널리티 필드

status, event_level, type, region처럼 값의 종류가 제한적이고 조회 조건으로 자주 사용하는 정보는 Stream Label로 저장했습니다.
반면 event_id, target_ip, fingerprint처럼 이벤트마다 값이 달라질 수 있는 필드는 JSON 로그 라인에 저장했습니다.

이 구조를 통해 통합관제 시스템은 저장된 이벤트를 조회 API를 통해 가져가도록 구성했습니다. Loki의 카디널리티를 낮게 유지하면서도, Alert History 조회와 장애 재발 분석에 필요한 상세 데이터는 함께 보존할 수 있었습니다.

결정 4. Rule 조회는 PostgreSQL First 전략으로 처리

Alert Rule 목록을 조회할 때마다 Mimir나 Loki에 직접 요청하면 백엔드 상태에 따라 응답 속도와 안정성이 영향을 받을 수 있습니다.

예를 들어 Mimir나 Loki가 일시적으로 불안정한 상황에서도 운영자는 현재 등록된 Rule 목록을 확인해야 합니다. 또한 Rule 수가 많아질수록 매번 백엔드 API를 직접 조회하는 방식은 응답 속도 측면에서도 부담이 될 수 있습니다.

이를 보완하기 위해 Alert 관리 계층에서는 PostgreSQL First 조회 전략을 적용했습니다.

Rule 생성, 수정, 삭제 시에는 PostgreSQL과 Mimir 또는 Loki에 모두 반영합니다.
그리고 Rule 목록을 조회할 때는 PostgreSQL을 우선 조회 소스로 사용합니다.

이 방식의 장점은 두 가지입니다.

첫째, 가용성입니다.
Mimir나 Loki가 일시적으로 불안정하더라도 PostgreSQL에 저장된 Rule 정보를 기준으로 목록 조회를 계속 제공할 수 있습니다.

둘째, 조회 성능입니다.
PostgreSQL의 인덱스를 활용하면 조직, namespace, Rule 이름, 상태 등 다양한 조건으로 Rule을 빠르게 조회할 수 있습니다.

물론 이 구조에서는 PostgreSQL과 Mimir/Loki 간 정합성 관리가 중요합니다.
Rule 생성, 수정, 삭제 과정에서 한쪽만 성공하고 다른 한쪽은 실패하는 상황이 발생할 수 있기 때문입니다. 따라서 요청 처리 순서와 실패 시 보상 처리도 함께 고려해야 했습니다.

결과적으로 PostgreSQL은 단순 캐시가 아니라, Alert 관리 계층에서 Rule 조회와 운영 정책 데이터를 안정적으로 제공하기 위한 기준 저장소 역할을 하도록 설계했습니다.

4. 운영하면서 배운 것들

Alert 시스템은 알림 발송 도구가 아니라 운영 정책 시스템이다

개발 초기에는 Alert Rule 등록과 Notification 발송 자체가 목표였습니다. 그런데 실제 운영 환경에 적용해보니, 발송 자체보다 다음 질문들이 훨씬 더 중요했습니다.

어떤 팀에 어떤 Alert를 보낼 것인가?
이 이벤트의 성격은 무엇이고 누가 관리하는가?
실제로 정상 발송되었는가?
배포·점검 시간에는 어떻게 Alert를 억제할 것인가?

이 질문들에 답하는 과정에서 Silence 기능(배포·점검 시 일시 중지), 조직별 Notification Policy, 통합관제 연동 매핑 체계 등이 설계에 추가됐습니다.

Label 설계가 Alert 품질을 결정한다

통합관제 연동 과정에서 가장 어려웠던 부분은 기술 구현이 아니라 Label 체계 표준화였습니다. Alert 메시지 내용보다, type, region, zone, target_name 같은 Label을 어떻게 정의하고 표준화하느냐가 실제 운영 품질에 훨씬 더 큰 영향을 줬습니다.

레이블 체계 없이 Alert만 보내면 통합관제 측에서 "이게 어느 서비스의 어떤 이벤트인지"를 파악하기 어렵습니다. Alert 메시지 설계보다 레이블 설계가 먼저라는 것을 경험했습니다.

오픈소스로 SaaS 수준 운영 체계 구현 가능성 확인했다

LGTM 오픈소스 스택과 자체 개발 서비스의 조합으로, 외부 SaaS 없이도 Org 격리, Alert 정책 관리, 다채널 Notification(Slack·Email), 통합관제 시스템 연동이 가능한 수준의 Alert 체계를 구성할 수 있었습니다.

다만 단순 기능 구현보다 운영 정책·확장성·표준화·조직 구조를 함께 고려해야 안정적인 플랫폼 운영이 가능하다는 점을 확인했습니다.

5. 마무리

이번 설계에서 가장 중요한 점은 Alert 플랫폼을 단순한 Rule 등록 도구로 보지 않았다는 것입니다.

운영 환경에서 Alert는 조직별 권한, 관제 대상 식별, 이벤트 이력, 조회 성능, 백엔드 안정성과 모두 연결됩니다.
따라서 Alert 관리 계층은 단순히 알림을 보내는 역할이 아니라, Observability 데이터와 통합관제 체계 사이에서 운영 이벤트를 표준화하고 관리하는 역할을 해야 했습니다.

결과적으로 KCP Observability Platform에서 발생한 Alert를 단순 알림이 아니라, 조직별로 관리되고 통합관제 시스템과 연결 가능한 운영 이벤트로 확장할 수 있었습니다.

앞으로는 Alert 발생·해제 이력과 Notification 전송 이력을 더 고도화해 장애 분석, 운영 리포트, 반복 장애 패턴 분석까지 활용할 수 있는 구조로 발전시켜 나갈 계획입니다.

?› 자주 묻는 질문 FAQ

Q. 왜 별도의 Alert 관리 플랫폼이 필요했나요?

A. Grafana만으로는 조직별 Alert 격리, 통합관제 연동, 이력 추적까지 일관되게 처리하기 어려워 별도 관리 계층을 구축했습니다.

Q. 조직별 Alert는 어떻게 분리했나요?

A. Alert Rule 저장 시 namespace 앞에 Org ID를 prefix로 주입해, 하나의 공통 백엔드 안에서도 조직별 Rule이 섞이지 않도록 했습니다.

Q. Alert 이벤트를 Loki에 저장할 때 고려한 점은 무엇인가요?

A. 카디널리티 증가를 막기 위해 자주 필터링하는 값만 Stream Label로 두고, 상세 정보는 JSON 로그 라인에 저장했습니다.

[AI활용] Claude 실무편 - kt cloud VM에서 PR 리뷰 자동화하기

kt cloud 기술 블로그 — Thu, 20 Aug 2026 14:17:10 +0900

kt cloud FE개발팀 강민호 님

요약 SUMMARY

이 글에서는 kt cloud VM 위에서 Claude 기반 PR Review Bot을 구축하고
PR 리뷰 자동화 구조를 설계한 실무 사례를 다룹니다.
리뷰 품질 편차와 반복 검증 부담을 줄이고 운영 가능한 자동화 방향을 정리합니다.

#Claude #PRReviewBot #PR리뷰자동화 #ktcloudVM #AI코드리뷰

1. 들어가며 — PR 리뷰는 왜 항상 병목이 되는가

PR(Pull Request)은 협업 기반 개발에서 코드 품질을 유지하기 위한 가장 중요한 프로세스 중 하나다.
모든 변경은 PR을 통해 공유되고, 리뷰를 거쳐 병합되며, 이 과정에서 코드의 안정성과 일관성이 확보된다.

하지만 실제 개발 환경에서는 PR 리뷰가 이상적으로 동작하지 않는 경우가 훨씬 많다.

리뷰어가 일정에 쫓기면 PR은 대기 상태로 쌓이기 시작하고,
프로젝트 맥락을 충분히 이해하지 못한 상태에서는 구조적으로 중요한 변경을 놓치기도 한다.
또한 동일한 코드라도 리뷰어에 따라 판단 기준이 달라지기 때문에, 리뷰 결과 자체가 일관되지 않는 경우도 빈번하게 발생한다.

특히 신규 프로젝트에 온보딩되는 시점에서는 이 문제가 더욱 두드러진다.
코드베이스와 아키텍처를 완전히 이해하지 못한 상태에서 PR 리뷰를 수행해야 하며,
그 과정에서 리뷰 품질은 개인의 경험에 크게 의존하게 된다.

PR 리뷰 병목 상황(ChatGPT)

리뷰 대기 상태의 PR이 쌓이며, 리뷰 속도와 품질이 사람의 상황에 따라 달라지는 구조

이 시점에서 필요한 것은 단순히 “리뷰를 더 열심히 하는 것”이 아니라,
리뷰를 시작하기 전에 구조적으로 문제를 걸러낼 수 있는 시스템이었다.

2. 문제 정의 — PR 리뷰의 본질적인 한계

기존 PR 리뷰의 핵심 문제는 단순히 리뷰가 느리다는 것이 아니다.
보다 본질적인 문제는 모든 판단과 검증이 사람에게 집중되어 있다는 점이다.

PR 리뷰 과정에서 반복적으로 수행되는 작업들을 살펴보면 다음과 같다.

아키텍처 레이어 의존성 확인
네이밍 컨벤션 검증
설정 파일 변경에 따른 영향도 판단
공통 모듈 변경 여부 확인
구조적 리스크 탐지

이러한 작업들은 대부분 규칙 기반으로 처리할 수 있는 영역임에도 불구하고,
현실에서는 모두 사람이 수동으로 수행하고 있다.

그 결과, 다음과 같은 문제가 구조적으로 발생한다.

리뷰어별 품질 편차
반복 검증에 따른 인적 비용 증가
시니어 리뷰어에게 집중되는 병목
신규 멤버 온보딩 속도 저하

기존 PR 리뷰 흐름(ChatGPT)

Developer → PR → Reviewer → Feedback

모든 검증이 사람에게 집중된 구조

이 문제를 해결하기 위해서는 리뷰를 강화하는 것이 아니라,
리뷰의 일부를 시스템으로 전환해야 했다.

3. 접근 전환 — AI는 판단하지 않는다

이번 구조를 설계하면서 가장 중요하게 설정한 원칙은 명확했다.

AI는 판단자가 아니라, 규칙 기반 결과를 설명하는 역할만 수행한다

일반적으로 AI를 코드 리뷰에 활용하려고 하면, AI에게 “이 코드가 좋은지 나쁜지 판단해달라”는 접근을 하게 된다.
하지만 이 방식은 결과의 신뢰성을 확보하기 어렵다.

대신 우리는 역할을 명확히 분리했다.

판단 기준 → 사람이 정의
검증 로직 → 규칙으로 명시
결과 설명 → AI가 수행

역할 분리 구조(ChatGPT)

판단과 실행을 분리한 구조

이 접근을 통해 다음과 같은 효과를 기대할 수 있었다.

결과의 재현성 확보
리뷰 기준의 명시화
AI 환각(Hallucination) 최소화
리뷰 신뢰도 향상

4. 왜 kt cloud VM 위에 직접 만들었는가

이 프로젝트의 핵심은 단순히 AI를 활용했다는 것이 아니다.
AI 리뷰 시스템을 직접 구축했다는 점에 있다.

당시 상황을 보면 선택지는 명확하지 않았다.

Claude는 PR 리뷰 기능을 제공하지 않았고
GitHub Copilot의 유료 기능은 조직 차원에서 바로 도입하기 어려웠으며
팀 내부에서는 코드 품질을 일정 수준 이상으로 유지해야 하는 요구가 있었다

이 상황에서 선택한 방법은 단순했다.

필요한 기능이 없다면, 직접 만든다

kt cloud VM 생성

kt cloud VM 목록

VM 생성, 네트워크 설정, 보안 구성 화면 등등 구성

kt cloud VM을 활용함으로써 다음을 동시에 해결할 수 있었다.

사내 접근 제어 (방화벽 / IP allowlist)
GitHub 연동 환경 구성
지속 실행 가능한 서버 확보
로그 및 실행 상태 관리

즉, 단순한 테스트 환경이 아니라
실제 운영 가능한 AI 실행 환경을 구축한 것이다.

5. 전체 구조 — PR Review Bot은 어떻게 동작하는가

PR Review Bot은 단순한 스크립트가 아니라,
여러 구성 요소가 결합된 하나의 실행 시스템이다.

전체 시스템 구조(ChatGPT)

이 구조에서 중요한 점은 “자동 실행”이다.

poller 스크립트는 일정 주기로 PR을 확인하고, 새로운 PR이 발견되면 diff를 수집한 뒤 Claude Code Agent를 호출해 리뷰를 수행한다.

이 과정은 사람이 개입하지 않아도 지속적으로 반복된다.

즉, PR 리뷰는 더 이상 사람이 시작하는 작업이 아니라, 시스템이 먼저 수행하는 작업으로 전환된다.

6. PR Review Agent 아키텍처

PR Review Agent는 단순히 AI 모델을 호출하는 구조가 아니라,
규칙 기반 검증 로직과 Claude Code 실행 환경이 결합된 형태로 설계되었다.

전체 구조는 다음과 같이 3개의 레이어로 구성된다.

3-Layer 구조(ChatGPT)

각 레이어의 역할은 명확하다.

Signals
git diff를 기반으로 변경된 파일 목록, 코드 변경 내용, 영향 범위를 수집한다.
이 단계에서는 어떠한 해석도 하지 않고, 순수하게 “사실 데이터”만 확보한다.
Policy Engine
.claude/architecture/architecture-rules.json에 정의된 규칙을 기반으로
아키텍처 위반 여부, 의존성 방향, 네이밍 컨벤션 등을 검증한다.
이 단계에서 모든 판단이 이루어진다.
Claude Code Agent
Claude Code에 로그인된 실행 환경에서 Agent가 동작하며,
Policy Engine의 검증 결과를 기반으로 PR 리뷰 코멘트를 생성한다.
이 과정에서 Claude는 새로운 판단을 내리는 것이 아니라,
이미 도출된 검증 결과를 사람이 이해하기 쉬운 형태로 정리하고 설명하는 역할을 수행한다.

7. 아키텍처 규칙을 코드로 정의한다

PR 리뷰를 자동화하기 위해 가장 먼저 해야 할 일은
리뷰를 대신 수행하는 시스템을 만드는 것이 아니라,
리뷰 기준을 명확하게 정의하는 것이다.

많은 팀이 PR 리뷰 자동화를 시도하지만 기대만큼의 효과를 얻지 못하는 이유는
검증 로직보다 먼저 정의되어야 할 “기준”이 명확하지 않기 때문이다.

7.1. 리뷰 기준은 존재하지만 실행되지 않는다

대부분의 조직에서 아키텍처 규칙과 컨벤션은 이미 존재한다.
다만 그 형태가 문서, 구두 전달, 개인 경험에 머물러 있기 때문에
항상 동일하게 적용되지는 않는다.

결국 PR 리뷰는 다음과 같은 상태에 머무른다.

규칙은 있지만, 일관되게 실행되지는 않는다.

7.2. 규칙을 실행 대상으로 바꾼다

이 문제를 해결하기 위해 우리는 규칙을 문서가 아니라
시스템이 직접 실행할 수 있는 형태로 정의했다.

즉,

문서 → 사람이 읽는 대상
규칙 파일 → 시스템이 실행하는 대상

으로 전환한 것이다.

이 순간부터 PR 리뷰는 사람이 확인하는 작업이 아니라
규칙을 실행하는 과정으로 바뀐다.

7.3. PR 리뷰는 규칙을 실행하는 과정이 된다

레이어 의존성, 네이밍 컨벤션, 설정 변경 영향도와 같은
반복적인 검증 요소들은 모두 규칙으로 정의할 수 있다.

이렇게 되면 PR 리뷰는 더 이상
코드를 눈으로 확인하는 작업이 아니라,

정의된 기준을 기반으로 검증하는 작업으로 전환된다.

7.4. 리뷰 기준이 팀 자산이 된다

규칙을 코드로 정의하는 순간,
리뷰 기준은 개인의 경험이 아니라 팀의 자산이 된다.

모든 PR이 동일한 기준으로 검증되고,
규칙은 코드로 관리되며,
변경 이력 또한 추적 가능해진다.

7.5. 왜 이 방식이 중요한가

이 구조는 단순 자동화가 아니라
다음 세 가지를 동시에 해결한다.

일관성: 모든 PR이 동일한 기준으로 검증된다
재현성: 언제나 동일한 결과를 얻을 수 있다
확장성: 팀이 커져도 품질을 유지할 수 있다

8. 운영 구성 — 실제 실행 환경

PR Review Bot은 단순히 한 번 실행되는 스크립트가 아니다.
팀의 코드 품질을 지속적으로 관리하기 위해서는,
이 Bot이 항상 동작하는 운영 시스템 형태로 구성되어야 한다.

즉, 이 구조의 핵심은 “자동 실행”이 아니라
“지속 실행 가능한 상태를 유지하는 것”이다.

운영 구조(ChatGPT)

8.1. 실행 환경 — kt cloud VM 기반 운영

PR Review Bot은 kt cloud VM 위에서 실행된다.
이 VM은 단순 테스트 환경이 아니라,
PR 리뷰 자동화를 지속적으로 수행하는 전용 실행 노드 역할을 한다.

이 환경을 선택한 이유는 명확하다.

항상 켜져 있는 실행 환경 필요
사내 접근 제어 및 보안 정책 적용 가능
GitHub allowlist 연동 가능
로그 및 상태 관리 가능

즉, 로컬 실행이 아닌 팀 단위 운영 환경을 구성하는 것이 목적이었다.

8.2. poller 구조 — “이벤트 기반”이 아닌 “지속 감지 방식”

GitHub Webhook 기반 이벤트 처리 대신,
이번 구조에서는 poller.sh를 활용한 주기적 감지 방식(Polling)을 사용했다.

tmux new -s poller
bash ~/projects/ai-team/scripts/schedules/pr_review/poller.sh

poller는 일정 주기로 다음 작업을 수행한다.

GitHub CLI를 통해 PR 목록 조회
신규 PR 또는 변경된 PR 감지
해당 PR의 diff 수집
Claude Code Agent 실행
리뷰 결과 생성 및 기록

이 방식의 장점은 다음과 같다.

별도 이벤트 서버 구성 불필요
네트워크/웹훅 장애에 영향 적음
단순한 구조로 유지보수 용이

즉, 복잡한 이벤트 기반 시스템이 아니라
안정성을 우선한 단순한 반복 실행 구조를 선택한 것이다.

8.3. tmux — 장기 실행을 위한 핵심 구성

PR Review Bot은 한 번 실행하고 끝나는 프로세스가 아니다.
서버 재시작, SSH 종료, 세션 단절과 같은 상황에서도
지속적으로 실행되어야 한다.

이를 위해 tmux를 사용했다.

tmux 실행 화면

poller가 지속적으로 실행되는 환경

tmux를 활용하면:

SSH 세션 종료 후에도 프로세스 유지
백그라운드 실행 가능
언제든지 세션 재접속 가능

# 세션 생성
tmux new -s poller

# 세션 분리
Ctrl + B, D

# 세션 재접속
tmux attach -t poller

이 구조 덕분에 PR Review Bot은
사람의 개입 없이 계속 동작할 수 있다.

8.4. 로그 관리 — 운영 시스템의 필수 요소

자동화 시스템에서 가장 중요한 것은
“잘 돌아가는 것”이 아니라 “문제가 발생했을 때 추적 가능한 것”이다.

이를 위해 모든 실행 결과는 로그로 남긴다.

tail -f ~/logs/pr-review.log

즉, 로그는 단순 기록이 아니라
운영 시스템의 신뢰성을 보장하는 핵심 요소다.

8.5. 운영 관점에서의 핵심 설계 포인트

이 구조에서 중요한 것은 기술이 아니라 설계다.

다음 세 가지를 기준으로 설계했다.

✔ 지속 실행 가능성

tmux 기반 장기 실행
poller 기반 반복 구조
사람이 개입하지 않아도 계속 동작

✔ 단순성

Webhook 대신 Polling
최소한의 구성 요소
장애 포인트 최소화

✔ 관측 가능성

로그 기반 상태 추적
실행 결과 기록
디버깅 가능 구조

9. 효과 — PR 리뷰의 출발점이 바뀐다

이 구조의 가장 큰 변화는 속도가 아니다.

리뷰의 “출발점”이 바뀐 것이다.

Before / After(ChatGPT)

기존	이후
사람이 분석	Bot이 분석
경험 의존	규칙 기반
편차 존재	항상 동일

기존에는 리뷰어가 PR을 열고, 어디를 중점적으로 봐야 할지 스스로 판단해야 했다.

이제는 Bot이 먼저 분석하고, 위험 요소와 구조적 문제를 정리해준다.

그 결과 사람은 반복 검증이 아닌, 비즈니스 로직과 설계 판단에 집중할 수 있게 된다.

10. 권장 협업 모델

PR Review Bot은 사람을 대체하기 위한 시스템이 아니다.
오히려 사람 리뷰어가 더 중요한 판단에 집중할 수 있도록 돕는 보조 실행 구조에 가깝다.

기존의 PR 리뷰는 모든 검증과 판단이 사람에게 집중되어 있었기 때문에,
리뷰어의 경험, 컨디션, 프로젝트 이해도에 따라 결과 품질이 달라질 수밖에 없었다.

반면 PR Review Bot을 도입한 이후에는 리뷰의 구조 자체가 다음과 같이 변화한다.

협업 구조(ChatGPT)

이 구조에서 가장 중요한 변화는 역할의 명확한 분리다.

10.1. Bot의 역할 — 반복 검증의 자동화

PR Review Bot은 다음과 같은 작업을 담당한다.

아키텍처 규칙 위반 여부 검증 (FSD 레이어, 의존성 방향 등)
네이밍 컨벤션 및 코드 스타일 체크
설정 파일 및 공통 모듈 변경 감지
변경 범위 및 영향도 분석
구조적 리스크 탐지 및 요약

이러한 작업들은 모두 규칙 기반으로 수행 가능하며,
사람이 반복적으로 수행하기에는 비용이 높은 영역이다.

Bot이 이 역할을 수행함으로써 얻는 가장 큰 이점은 다음과 같다.

모든 PR에 대해 동일한 기준 적용
검증 누락 없는 완전한 체크 수행
리뷰어의 반복 작업 제거
리뷰 시작 전 구조적 리스크 사전 제거

즉, Bot은 “빠르고 정확하게 반복 작업을 수행하는 실행 계층”이다.

10.2. 사람 리뷰어의 역할 — 맥락 기반 판단

반면 사람 리뷰어는 다음과 같은 영역에 집중하게 된다.

비즈니스 로직의 적절성 판단
설계 의도와 구현 방식의 정합성 검토
트레이드오프(성능 vs 유지보수성 등) 판단
사용자 경험(UX) 관점 검토
예외 상황 및 정책 미정 영역에 대한 판단

이러한 영역은 규칙으로 완전히 정의하기 어렵고,
프로젝트 맥락과 도메인 이해가 필요한 부분이다.

PR Review Bot이 1차 검증을 수행함으로써,
사람 리뷰어는 더 이상 “기계적인 체크”에 시간을 쓰지 않고,
가치 있는 판단에 집중할 수 있게 된다.

10.3. 조직 관점에서의 효과

이 협업 구조는 개인이 아니라 팀 단위에서 큰 효과를 만든다.

✔ 리뷰 품질의 표준화

모든 PR이 동일한 규칙으로 검증되기 때문에
리뷰어에 따른 품질 편차가 사라진다.

✔ 병목 해소

시니어 리뷰어에게 집중되던 부담이 줄어들고,
리뷰 처리 속도가 안정적으로 유지된다.

✔ 협업 비용 감소

“이건 괜찮은가?” 같은 반복 질문이 줄어들고,
리뷰 커뮤니케이션이 더 명확해진다.

실제 PR Review Bot이 달고 있는 리뷰들(꼭 확인해주세요.)

실제 PR Review Bot이 달고 있는 리뷰들(한번 봐주세요.)

실제 PR Review Bot이 달고 있는 리뷰들(좋아요!)

실제 PR Review Bot이 달고 있는 리뷰들(이런 건 어떨까요?)

11. 정리 — 없으면 만드는 것도 기술력이다

이 사례의 핵심은 단순하다.

AI 기능이 없으면, 직접 만들어서 쓰면 된다

이건 단순 자동화가 아니다.

팀의 기준을 시스템으로 만들고
클라우드 위에서 실행하며
지속적으로 운영하는 구조를 설계한 것이다

결론 — PR 리뷰는 실행 시스템이 된다

PR 리뷰는 더 이상 사람이 시작하는 작업이 아니다.

시스템이 먼저 수행하고, 사람이 완성한다

이번 사례는 kt cloud 서비스를 기반으로 Claude, GitHub, Script를 결합해 만든

실제 운영 가능한 AI 자동화 시스템이다

이번 PR Review Bot 구축은 FE개발팀과 협업을 통해 방향을 구체화할 수 있었다.

특히 아키텍처 규칙 정의 및 정책 설계 과정에서 김시엽님의 자동화 관점이 큰 도움이 되었으며,
이를 기반으로 실무에 적용 가능한 자동화 구조를 완성할 수 있었다.

함께 고민하고 방향을 만들어주신 점에 감사드린다.

자주 묻는 질문 FAQ

Q 왜 PR Review Bot을 직접 만들었는가?

A PR 리뷰는 팀 품질을 지키는 핵심 절차지만, 모든 리뷰를 사람이 직접 수행하면 리뷰어의 경험, 일정, 컨텍스트에 따라 품질 편차가 생긴다. 또한 GitHub Copilot 유료 기능을 팀 차원에서 바로 활용하기 어려운 상황에서는, 내부 환경에서 직접 운영 가능한 자동화 구조가 필요했다. 그래서 kt cloud VM 위에 Claude Code와 GitHub CLI를 조합해 팀 전용 PR Review Bot을 구성했다.

Q 왜 kt cloud VM 위에 구성했는가?

A 단순 로컬 실행이 아니라 팀에서 지속적으로 운영하려면 항상 켜져 있는 실행 환경이 필요했다. kt cloud VM을 사용하면 사내 접근 제어, GitHub allowlist, 전용 계정, 로그 관리, tmux 기반 장기 실행 구조를 구성할 수 있어 실무형 운영 환경에 적합했다.

Q Claude Code는 어떤 역할을 하는가?

A Claude Code는 PR diff를 읽고, 사전에 정의한 architecture-rules.json을 기준으로 변경 사항을 분석한 뒤 사람이 이해하기 쉬운 리뷰 결과로 정리한다. 중요한 점은 Claude가 임의로 판단하는 것이 아니라, 사람이 정의한 규칙을 기반으로 설명하는 역할을 맡는다는 점이다.

Q 이 구조의 가장 큰 가치는 무엇인가?

A 가장 큰 가치는 리뷰 품질의 표준화다. 리뷰어가 바뀌어도 동일한 기준으로 1차 검토가 가능하고, 신규 멤버도 팀의 아키텍처 규칙을 빠르게 이해할 수 있다. 결과적으로 PR 리뷰는 개인 역량에만 의존하는 절차에서, 팀의 품질 기준을 실행하는 시스템으로 확장된다.

[사례연구] 사내 개인용 개발환경 이미지 실험기 2부: 만들면서 마주친 것들과 풀어간 방법

kt cloud 기술 블로그 — Fri, 14 Aug 2026 16:29:54 +0900

kt cloud Platform엔지니어링팀 이초환 님

요약 SUMMARY

이 글에서는 OpenStack 샌드박스 이미지 구축 과정에서 발생한
IP 복구, GitOps 구성, 자격증명 관리 이슈와 해결 방안을 다룹니다.
보안성과 운영 재현성을 높이기 위한 실무적 판단 기준을 정리합니다.

#OpenStack #GitOps #ArgoCD #FluxCD #Vault

1. 부팅마다 바뀌는 IP 자동 복구

샌드박스 이미지는 누가 어디서 부팅하느냐에 따라 IP가 매번 다릅니다. K8s 다뤄보신 분들은 익숙하시겠지만 kubeadm으로 만든 클러스터는 빌드 시점 IP가 여러 곳에 박힙니다. 그대로 부팅하면 인증서 검증부터 어긋납니다.

처음엔 kube-apiserver 관련된 IP만 몇 개 건드리면 되겠지 생각했었습니다. 그런데 막상 첫 빌드를 부팅시켜보니 IP가 박혀 있던 자리들이 생각보다 줄줄이 나왔습니다.

apiserver 인증서의 SAN — 새 IP가 SAN에 없어서 TLS 검증부터 실패
kubeconfig 3종(admin·scheduler·controller-manager) — server: 필드에 옛 IP
apiserver static pod manifest의 --advertise-address
etcd static pod manifest의 --listen-client-urls / --initial-advertise-peer-urls
kube-proxy ConfigMap에 박힌 master IP — 인증서·apiserver는 살아났는데 워크로드 트래픽이 안 흐름

막힐 때마다 한 자리씩 추가하다 보니 결국 systemd oneshot으로 묶게 됐습니다. 부팅 시점에 한 번 실행되고, 동작 순서는 이렇습니다.

현재 IP 감지 (DHCP 대기 포함)
apiserver 인증서를 새 IP SAN으로 재발급
static pod manifest(kube-apiserver.yaml, etcd.yaml) IP 치환
kubeconfig 3종(admin·scheduler·controller-manager) 재생성
kubelet 재시작 → apiserver/etcd 재기동
CNI·CoreDNS Ready 대기
kube-proxy ConfigMap에 남은 옛 IP 치환 + DaemonSet rollout restart

각 단계에 retry/timeout만 넉넉히 잡아두는 정도로 마무리했습니다.

2. GitOps 적용 — helm install에서 HelmRelease + ArgoCD까지

1부 3번 섹션에서 이미지에 ArgoCD·Flux를 선탑재하고 values는 Git 레포의 ConfigMap으로 둔 구조를 결과만 적어뒀는데, 거기까지 한 번에 그렇게 잡힌 건 아닙니다. 시간순으로는 helm install → Flux HelmRelease → ArgoCD 추가 순서로 갈아탔고, 단계마다 막힌 게 있어서 다음으로 옮긴 흐름입니다.

1단계 — 단일 VM 환경 제약에 values 맞추기

처음엔 OpenStack 코어 6종과 인프라 의존성 3종을 helm install로 한 컴포넌트씩 직접 깔았습니다. 시작점은 차트의 default values였지만, default values는 멀티 노드·외부 스토리지를 전제하고 있고, 한편으로 1부 요건에 적은 대로 운영 환경 values와의 구조 정합도 잃지 않으려 했기 때문에, 그 두 사이에서 단일 VM 환경에 맞게 다듬는 게 1단계에서 한 일이었습니다.

cinder backend — 외부 스토리지 없이 동작해야 해서 단일 VM용 backend 정의로 교체
replicas·HA 전제(예: mariadb galera 다중 노드)를 단일 VM에 맞게 축소
컴포넌트 시작 순서 — mariadb·rabbitmq·memcached가 먼저 Ready여야 keystone이 올라가고, keystone이 떠야 다른 코어 컴포넌트들이 자기 endpoint를 등록하는 흐름
그 외 컴포넌트별 자잘한 보정

이 단계 결과물은 "단일 VM에서 OpenStack을 뜨게 할 수 있는 values 한 벌"이었습니다. 다만 install·upgrade를 매번 손으로 돌려야 했고, git 변경이 클러스터에 자동으로 반영되지 않았습니다.

2단계 — Flux HelmRelease로 git 변경 자동 반영

values가 어느 정도 굳고 나서 Flux HelmRelease로 옮겼습니다. Harbor OCI에 올린 차트를 가리키는 HelmRepository를 source로 두고, 컴포넌트별 HelmRelease가 그 차트를 참조해 install/upgrade를 수행하는 구조입니다. 여기서부터 git push 한 번으로 클러스터가 새 values를 따라가게 됐습니다.

이때 values를 HelmRelease manifest 안에 직접 박지 않기로 했습니다. HelmRelease의 spec.values에 값을 그대로 적는 방식 대신, kustomization의 configMapGenerator로 values/{arm64,amd64}/keystone.yaml 같은 외부 파일에서 ConfigMap을 만들고 HelmRelease는 spec.valuesFrom으로 그 ConfigMap을 참조하게 했습니다.

# kustomization.yaml
configMapGenerator:
  - name: keystone-values
    files:
      - values/arm64/keystone.yaml

이렇게 분리한 이유는 디버깅·검증 융통성입니다. values 파일이 평범한 yaml로 외부에 있으면 같은 파일로 helm template을 그대로 돌려 렌더링 결과를 미리 보거나 --dry-run을 떠보는 게 손쉽습니다. HelmRelease 안에 박혀 있으면 그 자리만 잘라내서 다시 yaml로 만들어야 같은 일이 됩니다. 평소 쓰던 손버릇이 막히지 않게 그냥 분리해뒀습니다.

3단계 — ArgoCD 추가

마지막으로 ArgoCD를 같이 올렸습니다. 사내 운영 환경이 ArgoCD 기반이라 Application 단위 가시성(Sync 상태, OutOfSync, diff)을 운영 결과 정합 측면에서 그대로 가져가야 했습니다. Flux는 차트 install/upgrade 자체를 책임지는 자리에 두고, ArgoCD는 그 위에서 ExternalSecret·HelmRelease 등을 Application으로 묶어 상태를 보여주는 역할입니다.

3. Git 레포와 이미지에 자격증명을 평문으로 두지 않게

1번과 2번 섹션이 만들면서 걸린 것이라면, 이건 처음부터 챙겨야 했던 부분입니다. 일반 운영 클러스터에서 시크릿을 다루는 것과 다른 점은, 이 이미지는 그 파일 자체가 개발자에게 전달되는 매체라는 점입니다. 이미지에 평문이 박혀 있으면 이미지를 받는 모든 사람에게 같은 평문이 함께 배포됩니다. Git 매니페스트에 base64 인코딩된 값을 두는 것도 평문과 다를 바 없고, 빌드 시점에 만든 K8s Secret이 etcd에 저장되면 그 etcd가 이미지에 포함되니 이미지 안에 평문이 남는 셈이었습니다.

Vault를 후보로 둔 이유

사내에 Vault가 이미 운영되고 있어서 첫 후보였습니다. 시크릿을 한 곳에 모아두고 빌드 타임이 아닌 각 사용자 로컬 부팅 시점에 가져오게 만들면, 이미지 자체에는 Vault 경로 참조만 남고 실제 값은 어디에도 평문으로 박히지 않게 됩니다.

Vault·ESO·CSI의 일반적 비교나 활용 패턴은 테크블로그 Vault 도입 전략 편[26-1차 링크 삽입 요청 - https://ktcloud.atlassian.net/wiki/x/6gHEaQ]과 Vault + ESO/CSI 아키텍처 편에서 이미 다루고 있어, 이 글에서는 이번 샌드박스 이미지 맥락에서 어떤 도구를 어떤 이유로 골랐는지만 짚겠습니다.

AVP에서 ESO로 옮긴 이유

ArgoCD를 이미 쓰고 있어서 첫 후보는 자연스럽게 AVP(Argo CD Vault Plugin)였습니다. Helm values에 plaintext placeholder(<path:secret/...#key>)를 두는 방식이 GitOps 운영 패턴에 잘 맞아서, 처음엔 AVP로 결정하고 진행하려 했습니다.

그런데 AVP 공식 호환 매트릭스를 보니 다음까지만 명시되어 있었습니다.

Argo CD Version	AVP Version
1.8.x	1.x
2.0.x	1.x
2.1.x	1.x

위 매트릭스는 2026-04 시점 AVP 공식 README 기준입니다.

저희 환경은 v3.x.x입니다. ArgoCD의 CMP(ConfigManagementPlugin) API가 하위 호환을 유지해서 기술적 동작 가능성은 높지만, 공식 테스트 범위 밖이라는 점이 부담이었습니다. Vault 도입 전략 편[26-1차 링크 삽입 요청 - https://ktcloud.atlassian.net/wiki/x/6gHEaQ]에서도 AVP는 "예외 수단"으로 포지셔닝되어 있었던 것과 결이 같았고요.

또 한 가지 — 1부에서 적었듯 이 샌드박스는 ArgoCD와 Flux HelmRelease를 둘 다 사용합니다. AVP는 ArgoCD CMP로 동작해서 시크릿 주입이 ArgoCD 렌더링 파이프라인을 거쳐야 합니다. Flux HelmRepository가 Harbor OCI에 붙을 때 쓸 Secret도 ArgoCD가 관리하는 Secret manifest에 placeholder를 박아 치환하는 식으로 우회는 가능하지만, 시크릿 생애주기가 ArgoCD sync에 묶이는 게 마음에 걸렸습니다. ESO는 ArgoCD와 무관하게 Vault에서 직접 K8s Secret으로 sync하는 별도 operator라, Flux·ArgoCD 양쪽이 같은 Secret을 그대로 참조할 수 있어 진입점을 하나로 둘 수 있다는 점이 컸습니다.

공식 호환 공백과 진입점 일원화, 두 이유로 ESO로 정했습니다.

결과 — 평문이 사라진 경로들

전반 흐름은 다음과 같이 정리됐습니다. 이미지에는 ExternalSecret 참조와 Vault AppRole secret-id만 박히고, 실제 값은 각 사용자 부팅 시점에 ESO가 Vault에서 가져와 K8s Secret으로 만들면 ArgoCD·Flux 양쪽이 같은 Secret을 참조하는 구조입니다.

경로별로 끊어낸 것을 정리하면 다음과 같습니다.

경로	변경 전	변경 후
containerd `config.toml`	registry auth 평문	블록 제거 → K8s `imagePullSecret`으로 옮김. 빌드 타임 pre-pull은 `ctr pull --user` 환경변수로만
Git 레포 매니페스트	base64 Secret 직접 커밋	ExternalSecret 참조 선언만 두고 실제 값은 Vault에
이미지 etcd	K8s Secret이 빌드 타임에 박힘	부팅 시 ESO가 Vault에서 fetch → 각 사용자 로컬에서 런타임에 생성

그래도 남는 자격증명 하나

경로를 끊어도 마지막 하나는 남습니다. Vault에 처음 접근하기 위한 부트스트랩 자격증명 — 저희 경우 Vault AppRole의 secret-id입니다. 이걸 다시 Vault에 넣으면 재귀가 되니 어딘가에는 평문으로 있어야 합니다.

이번 1차에서는 이 자격증명을 정책으로 좁혀두는 쪽으로 정리했습니다.

스코프 제한: sandbox-read 정책으로 secret/data/sandbox/* 경로 읽기만 허용. 쓰기 작업도 다른 경로 읽기도 불가능
TTL 경계: secret-id에 720시간(30일) TTL. 이미지가 오래된 상태로 유통되는 걸 정책 자체에서 차단
Audit 가능성: Vault Audit Log 활성화 → AppRole의 모든 fetch 요청이 기록되어, 유출 의심 시 secret-id accessor를 destroy하면 즉시 무력화

완전 제거는 아닙니다. 다만 남는 하나가 읽기 전용 + 단일 경로 스코프 + 30일 시간 경계 + Audit 가능 상태라면 이미지가 배포되는 상황에서 감수할 만한 리스크라고 봤습니다. 부트스트랩 경로 자체는 사내 클라우드 개인용 환경 제공 트랙으로 확장하면서 다른 방식(K8s Auth Method 등)으로 바꾸는 걸 검토하고 있습니다.

4. 마치며

이 글에서 짚은 것들을 정리하면 다음과 같습니다.

부팅마다 바뀌는 IP를 systemd oneshot으로 자동 복구
helm install로 values 안정화 후 HelmRelease + ArgoCD로 갈아탄 GitOps 구조 (values는 ConfigMap으로 분리해 helm template 등 검증 융통성 확보)
Git 레포와 이미지 어느 쪽에도 자격증명이 평문으로 박히지 않도록 Vault·ESO 조합으로 정리
AVP 대신 ESO를 택한 근거 (ArgoCD v3 공식 호환 공백 + Flux/ArgoCD 공통 진입점)

남은 과제는 다음과 같습니다.

부트스트랩 자격증명을 더 좁히는 방향 — 사내 클라우드 트랙에서 K8s Auth Method 등 검토
openstack-helm 외부 차트 대신 운영 노하우가 반영된 사내 차트로 전환
이미지에 nested virtualization을 활성화해 샌드박스 안에서 실제 OpenStack 인스턴스를 띄우는 검증 (Apple Silicon + Lima)

이 글도 1부와 마찬가지로 진행 중인 1차 실험의 한 시점을 기록한 것입니다.

위 항목들이 진행되면 후속 기록으로 또 공유드리겠습니다!

자주 묻는 질문 FAQ

Q AVP가 가장 자연스러운 후보일 텐데 왜 ESO를 택하셨나요?

A 저희도 처음엔 AVP로 가려고 했습니다. 다만 AVP 공식 호환 매트릭스가 ArgoCD v1.8~v2.1까지만 명시되어 있고, 저희 환경은 v3.x.x이었습니다. CMP API가 하위 호환을 유지해서 동작 가능성은 높지만 공식 테스트 범위 밖이라는 점이 부담이었고, Flux와 ArgoCD 양쪽이 공통 Secret을 참조해야 한다는 점까지 더해져 ESO 단일 경로로 갔습니다.

Q 이미지에 결국 평문 자격증명 하나는 남는 거 아닌가요?

A 맞습니다. Vault 자체에 처음 접근할 부트스트랩 자격증명(AppRole secret-id) 하나는 이미지에 남습니다. 이걸 다시 Vault에 넣으면 재귀가 되니 어딘가에는 평문으로 있어야 합니다. 대신 (1) sandbox-read 정책으로 읽기 전용, (2) secret/data/sandbox/* 단일 경로 스코프, (3) secret-id TTL 720시간으로 정책 레벨에서 영향 범위와 노출 시간을 묶어두는 방향으로 정리했습니다.

관련 / 출처 REFERENCES

https://tech.ktcloud.com/entry/2026-03-ktcloud-vault-eso-csi-%EB%B3%B4%EC%95%88-%EB%8F%84%EC%9E%85

↗

[AI활용] Claude 실무편 - Technical Writer Skill 만들기

kt cloud 기술 블로그 — Fri, 14 Aug 2026 15:56:47 +0900

kt cloud FE개발팀 강민호 님

요약 SUMMARY

이 글에서는 Claude Skill을 활용해 Technical Writer 업무를
용어 표준화와 문서 품질 관리 구조로 전환한 사례를 다룹니다.
AI 자동화를 반복 작업 대체가 아닌 업무 기준과 운영 방식의 재설계 관점에서 정리합니다.

#Claude #ClaudeSkill #TechnicalWriter #기술문서자동화 #용어표준화

들어가며 — 왜 용어는 항상 틀릴까

프론트엔드 개발을 하다 보면 누구나 한 번쯤은 비슷한 경험을 한다.
분명 같은 기능을 구현했는데도, 화면마다 용어가 다르고, 리뷰를 할 때마다 기준이 달라진다.

어떤 화면에서는 “삭제”라고 되어 있고, 다른 화면에서는 “삭제하기”라고 되어 있다.
어떤 서비스에서는 “Server”를 사용하고, 어떤 곳에서는 “서버”라고 표기한다.
심지어 “생성중”과 “생성 중” 같은 사소한 띄어쓰기조차 통일되지 않는다.

이 문제는 단순히 표기 실수나 리뷰 누락의 문제가 아니다.
조금 더 구조적으로 바라보면, 이 현상 뒤에는 하나의 공통된 원인이 존재한다.

용어는 규칙으로 관리되지 않고, 사람의 기억과 경험에 의존하고 있다.

이 구조에서는 아무리 숙련된 리뷰어가 참여하더라도 결국 한계에 도달할 수밖에 없다.
서비스가 늘어나고 화면 수가 증가할수록, 사람의 인지 능력으로 유지할 수 있는 일관성에는 분명한 한계가 있기 때문이다.

예시 이미지(ChatGPT)

문제 정의 — Technical Writer 업무는 왜 병목이 되는가

이 문제를 해결하기 위해 먼저 기존의 용어 관리 프로세스를 다시 살펴봤다.

일반적인 흐름은 다음과 같다.
UIUX 담당자들이 Figma 문서를 배포하면, Technical Writer가 각 화면을 기반으로 용어를 추출하고,
전사 용어 가이드를 참고해 이를 표준화한다. 이후 개발자가 해당 용어를 코드에 반영한다.

이 과정은 겉으로 보기에는 합리적인 협업 구조처럼 보인다.
하지만 실제로 운영해 보면 몇 가지 문제가 반복적으로 발생한다.

우선 Figma와 코드, 그리고 문서를 계속 오가며 비교해야 하기 때문에 컨텍스트 스위칭 비용이 높다.
또한 동일한 작업이 반복되면서 생산성이 떨어지고, 무엇보다 중요한 기준이 문서가 아니라 사람의 머릿속에 존재한다는 점이 문제다.

FE와 TW 고민의 흔적

기존 TW 프로세스 다이어그램(ChatGPT)

이 구조의 가장 큰 문제는 단순한 비효율이 아니라 확장 불가능성이다.
실제로 데이터를 기반으로 분석해보면 그 이유는 더욱 명확해진다.

25개 서비스, 728개의 화면을 기준으로 분석했을 때
총 11,961개의 용어가 존재했고, 그 중 고유 용어만 3,473개에 달했다

이 정도 규모가 되면 더 이상 사람이 일관성을 유지하면서 관리할 수 있는 영역이 아니다.
즉, 문제의 본질은 “용어가 많다”는 것이 아니라,
사람이 관리해야 하는 구조 자체가 잘못되어 있다는 것이다.

용어 분석 리포트(ChatGPT)

용어의 수와 중복률을 통해 문제의 규모를 데이터로 확인

접근 전환 — 문서를 데이터로 바라보는 순간

이 문제를 해결하기 위해 가장 먼저 바꾼 것은 도구가 아니라 관점이었다.

기존에는 문서를 사람이 읽고 이해해야 하는 대상으로 봤다면,
이제는 문서를 구조화 가능한 데이터로 보기 시작했다.

이 작은 관점의 변화는 생각보다 큰 구조적 변화를 만들어낸다.

문서를 데이터로 보기 시작하는 순간,
용어 추출은 사람이 화면을 보며 찾는 작업이 아니라 구조를 파싱하는 작업으로 바뀌고,
용어 수정은 감각이나 경험에 의존한 판단이 아니라 규칙 기반 처리로 전환된다.

즉, Technical Writer의 업무는 더 이상 “문서를 다루는 작업”이 아니라
데이터를 처리하는 문제로 재정의된다.

Figma → 데이터 구조 변환(ChatGPT)

Figma 문서를 구조화된 데이터로 변환하는 흐름

실행 구조 — Technical Writer Agent의 등장

이러한 관점 전환 이후, Technical Writer의 역할도 자연스럽게 변화한다.

기존에는 용어를 직접 작성하고 수정하는 역할이었다면,
이제는 용어를 생성하고 변환하는 규칙을 정의하는 역할로 바뀐다.

실제 실행은 사람이 아니라 Agent가 수행한다.

Figma에서 UI 데이터를 추출하면, Agent가 해당 데이터를 기반으로 용어를 수집하고,
정의된 정책을 적용해 표준화하며, 규칙에 맞지 않는 부분을 자동으로 탐지한다.
더 나아가 기존 정책으로 설명되지 않는 패턴을 발견하면,
그 자체를 새로운 정책 후보로 제안하기도 한다.

Technical Writer Agent 전체 흐름(ChatGPT)

이 구조에서 중요한 점은 단순히 자동화가 이루어졌다는 것이 아니다.

사람이 하던 일을 대신 수행하는 것이 아니라,
업무 자체가 실행 가능한 구조로 재설계되었다는 점이다.

Skill 구조 — 정책을 코드로 만든다는 의미

이 프로젝트의 핵심은 Technical Writer 업무를 Skill로 전환한 것이다.

기존에는 용어 표기 가이드나 띄어쓰기 규칙이 문서 형태로 존재했고,
사람이 이를 참고하여 수작업으로 적용했다.

하지만 이 구조에서는 그 가이드를 그대로 두지 않는다.
실행 가능한 형태로 변환하여 Agent가 직접 적용하도록 만든다.

예를 들어, “생성중”이라는 표현은 자동으로 “생성 중”으로 변환되고,
“Server”는 “서버”로 통일된다.
이러한 규칙은 사람이 기억하거나 판단할 필요 없이,
Skill로 정의되어 일관되게 적용된다.

Skill 적용 전/후 비교(ChatGPT)

용어 표준화가 사람의 판단이 아닌 규칙 기반 실행으로 전환된 사례

이렇게 되면 더 이상 “이게 맞는 표현인가?”를 고민할 필요가 없다.
모든 결과는 동일한 규칙에 의해 생성되기 때문이다.

정책 자동 분석 및 제안(ChatGPT)

정의되지 않은 패턴까지 탐지하고 정책 개선을 제안하는 구조

여기서 중요한 점은 Skill이 단순한 프롬프트가 아니라는 것이다.

Skill은 사람이 수행하던 판단을 대체하는
실행 가능한 업무 로직이다.

자동화 범위 — 어디까지 가능한가

실제 스킬화를 통해 확인한 결과, 자동화 범위는 예상보다 훨씬 넓었다.

용어 추출, 표준화, 정책 분석뿐 아니라
개발 코드 반영과 Figma 문서 업데이트까지 대부분의 단계가 자동화 가능했다.

이는 기존 6단계로 구성된 프로세스 중 대부분이 자동화 대상이라는 의미다.

자동화 범위 비교(ChatGPT)

기존 수작업 프로세스와 자동화 구조의 차이

이 결과는 단순한 효율 개선을 넘어선다.

효과 — 단순한 효율이 아닌 구조의 변화

자동화 이후 가장 눈에 띄는 변화는 시간 단축이다.

기존에는 용어 추출에 하루, 표준화에 수일이 걸렸던 작업이
모두 1시간 이내로 수행되며, 전체 작업이 반나절 수준으로 줄어든다.

Before / After 비교(ChatGPT)

시간 단축뿐 아니라 작업 구조 자체가 변화한 결과

핵심 인사이트 — Technical Writing을 실행 가능한 구조로 전환한다는 것

이 사례를 통해 얻은 가장 중요한 결론은 단순하다.

Technical Writer의 역할이 사라진 것이 아니라,
그 역할을 구성하고 있던 반복 작업과 규칙 기반 업무가
보다 효율적인 방식으로 재구성되었다는 점이다.

기존에는 용어를 추출하고, 비교하고, 수정하는 과정이
사람의 경험과 반복 작업에 의존했다면,
이제는 그 과정을 정책 기반으로 정의하고,
AI가 일관되게 실행하도록 만들 수 있게 되었다.

그 결과, Technical Writer는 단순한 작업 수행자가 아니라
용어 정책을 설계하고 품질 기준을 정의하는 역할에 더 집중할 수 있게 된다.

결론 — AI는 생산성을 증폭시키는 구조로 활용된다

AI를 도입한다는 것은 단순히 새로운 도구를 사용하는 것이 아니다.

기존의 업무를 그대로 둔 채 자동화하는 것이 아니라,
업무를 더 효율적으로 수행할 수 있도록 구조를 재정의하는 과정이다.

이번 Technical Writer Skill화 사례는
AI를 통해 생산성과 업무 효율성을 어떻게 실질적으로 개선할 수 있는지를 보여준다.

특히 이 구조는 특정 개인이나 팀에 국한되지 않는다.

향후에는 Claude Plugin 형태로 확장하여
다양한 구성원이 동일한 정책과 기준을 기반으로
용어 검수 및 표준화 작업을 수행할 수 있도록 발전시킬 수 있다.

이를 통해 조직 전체의 문서 품질과 개발 일관성을 동시에 향상시키는 것이 가능해진다.

이번 작업은 단순한 기술 구현이 아니라, 용어 표준화라는 조직 공통 과제를 함께 풀어가는 과정이었다. Cloud상품기획1팀의 권새하님과의 협업을 통해 기존 용어 정책을 정리하고, 이를 실행 가능한 구조로 전환하는 방향을 함께 설계할 수 있었다. 기획과 개발이 같은 문제를 바라보고 해결해 나간 의미 있는 경험이었다.

자주 묻는 질문 FAQ

Q Technical Writer 업무를 AI로 자동화할 수 있는가?

A 가능하다. 다만 단순히 AI에게 문장을 수정하게 하는 수준으로는 한계가 있으며, 용어 표기 규칙과 정책을 명시적으로 정의하고 이를 실행 가능한 구조(Skill)로 만드는 것이 핵심이다. 이 구조를 갖추면 반복적인 용어 추출, 표준화, 검수 작업은 AI가 일관되게 수행할 수 있다.

Q 기존 AI 활용 방식과 무엇이 다른가?

A 기존 방식은 “프롬프트 기반”으로 사람이 매번 요청을 정의해야 했다면, 이번 구조는 “정책 기반 실행”으로 AI가 동일한 규칙을 지속적으로 적용한다는 점이 다르다. Prompt 중심 → 일회성 결과 Skill 중심 → 지속적이고 재현 가능한 결과 라는 차이가 있다.

Q 이 구조를 도입하면 Technical Writer 역할은 어떻게 변화하는가?

A 역할이 사라지는 것이 아니라, 성격이 바뀐다. 기존에는 용어를 직접 수정하고 검수하는 역할이었다면 이제는 용어 정책을 정의하고 품질 기준을 설계하며 예외 케이스를 관리하는 역할로 확장된다 즉, 반복 작업에서 벗어나 더 중요한 의사결정에 집중할 수 있게 된다.

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

kt cloud 기술 블로그 — Thu, 6 Aug 2026 15:04:47 +0900

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 서빙에 강합니다. 하나의 엔진으로 전부 떠받치면 어느 한쪽이 병목이 됩니다. 목적별로 분리해 각 레이어를 독립적으로 확장할 수 있게 한 선택입니다.

[기술동향] LLM 추론 최적화 핵심 기술: 양자화, KV 캐시, 추론 칩

kt cloud 기술 블로그 — Thu, 6 Aug 2026 14:39:40 +0900

kt cloud Azure전환TF 이영호 님

요약 SUMMARY

이 글에서는 에이전틱 AI 확산에 따른 LLM 추론 최적화와 양자화, KV 캐시, 추론 전용 칩의 변화를 다룹니다.
제한된 인프라에서 성능과 비용을 함께 고려해야 하는 방향을 정리합니다.

#에이전틱AI #LLM추론 #양자화 #KV캐시 #추론전용칩

최근 AI 산업의 패러다임은 '학습(Training)' 단계를 넘어 '추론(Inference)'의 효율화로 완전히 넘어가고 있습니다. 이는 단순히 사용자의 질문에 한 번 답하고 끝나는 챗봇을 넘어, AI가 스스로 문맥을 파악하고 연속적인 작업을 수행하는 '에이전틱 AI(Agentic AI)' 시대가 본격적으로 열렸기 때문입니다.

Deloitte에 따르면 2023년 전체 AI 컴퓨팅의 약 1/3에 불과했던 추론 워크로드는 2025년 절반, 2026년에는 약 2/3까지 증가할 것으로 전망됩니다. AI 클라우드 인프라 지출 역시 2026년 375억 달러에 달할 것으로 예상되며, 이 중 55%(약 206억 달러)가 추론에 투입됩니다 — 사상 처음으로 학습 지출을 추월하는 것입니다.

에이전트가 똑똑해질수록 막대한 컴퓨팅 자원이 실시간으로 소모되며, 이제 시장의 핵심 과제는 '제한된 하드웨어에서 어떻게 추론 비용과 속도를 최적화할 것인가'에 맞춰져 있습니다.

Image: AI-Generated Content

1. 양자화: 제한된 인프라에서 거대 모델을 깨우는 법

에이전트가 복잡한 임무를 수행하려면 필연적으로 더 많은 파라미터(매개변수)를 가진 거대 모델이 필요합니다. 하지만 기업들이 무한정 GPU를 늘릴 수는 없습니다. 이때 양자화(Quantization) 기술은 제한된 하드웨어의 한계를 돌파하는 가장 확실한 열쇠가 됩니다.

양자화는 모델의 가중치(Weights)를 정밀도가 낮은 데이터 타입으로 변환해 모델의 물리적 크기를 획기적으로 줄이는 기술입니다. 예를 들어, FP16(16비트) 가중치를 INT4(4비트)로 변환하면 모델 크기가 약 75% 감소하여, 동일한 VRAM에서 훨씬 큰 모델을 구동할 수 있게 됩니다.

하드웨어 제약 극복: VRAM 용량이 부족한 환경에서도 더 큰 규모의 고성능 모델을 구동할 수 있습니다.
서비스 속도 가속: 메모리에서 데이터를 불러오는 시간이 단축되고 연산 복잡도가 줄어들어, 사용자에게 더 빠른 응답(Low Latency)을 제공할 수 있습니다.

2. 에이전트의 발목을 잡는 '단기 기억', KV 캐시 병목

에이전틱 AI가 제대로 작동하기 위해 가장 중요한 요소는 '컨텍스트(Context)'입니다. 에이전트는 과거의 대화 기록, 방대한 참조 문서, 현재 작업 상태 등을 모두 단기 기억으로 쥐고 있어야 합니다.

이때 연산이 끝난 토큰들의 상태를 메모리에 임시로 보관하는 공간이 KV 캐시(Key-Value Cache)입니다. KV 캐시는 이미 처리된 토큰 정보를 저장해 중복 계산을 피하는 고속 "치트 시트" 역할을 하지만, 에이전트가 처리해야 할 컨텍스트 윈도우가 길어지고 동시 접속 이용자가 늘어날수록 이 캐시가 차지하는 메모리 용량은 선형적으로 폭증합니다. 결국 모델 크기를 줄여도 입력 데이터(KV 캐시)가 GPU의 VRAM을 가득 채워버려 시스템이 멈추는 메모리 병목 현상이 발생하게 됩니다.

기존의 양자화 기법은 이 문제에 대해 한계를 보입니다. 대부분의 벡터 양자화 방식은 데이터 블록마다 양자화 상수(quantization constants)를 별도로 저장해야 하는데, 이 오버헤드가 데이터당 1~2비트를 추가로 소모하여 압축 효과를 상쇄시킵니다.

Image: AI-Generated Content

3. TurboQuant: 모델이 아닌 '기억' 자체를 압축하다

이러한 물리적 한계를 극복하기 위해 Google Research가 2026년 3월 블로그를 통해 공개한 기술이 바로 TurboQuant입니다(ICLR 2026에서 정식 논문으로 발표될 예정입니다). 기존의 양자화가 모델의 '가중치'를 줄이는 데 집중했다면, TurboQuant는 실시간으로 늘어나는 KV 캐시 자체를 압축하는 데 초점을 맞춥니다.

TurboQuant는 두 가지 핵심 알고리즘의 조합으로 작동합니다:

PolarQuant: 데이터 벡터를 직교 좌표계에서 극좌표계로 변환합니다. 이를 통해 기존 양자화에서 필수적이었던 데이터 정규화(normalization) 단계가 불필요해지며, 양자화 상수 저장에 따른 메모리 오버헤드를 원천적으로 제거합니다.
QJL (Quantized Johnson-Lindenstrauss): Johnson-Lindenstrauss 변환을 활용하여 고차원 데이터를 1비트 부호(+1/-1)로 축소합니다. PolarQuant 이후 남은 미세한 오차를 보정하는 역할을 하며, 메모리 오버헤드가 제로(zero)입니다.

실측 성능

Google Research의 벤치마크 결과에 따르면, TurboQuant의 성능은 다음과 같습니다:

KV 캐시 메모리 6배 이상 절감: Needle-in-a-Haystack 등 장문맥 태스크에서 KV 메모리 크기를 최소 6배 줄이면서도 정확도 손실 없이(lossless) 완벽한 결과를 달성했습니다.
어텐션 연산 최대 8배 가속: H100 GPU에서 4비트 TurboQuant는 32비트 비압축 키 대비 어텐션 로짓(attention logits) 연산 속도를 최대 8배 향상시켰습니다.
학습/파인튜닝 불필요: KV 캐시를 3비트까지 양자화하면서도 별도의 학습이나 파인튜닝 없이 모델 정확도를 완벽히 보존합니다.
벡터 검색 최적화: GloVe 데이터셋(d=200) 기준으로 PQ, RabbiQ 등 기존 최신 양자화 기법 대비 최적의 1@k recall ratio를 달성했습니다.

이 기술은 에이전트가 수만 토큰에 달하는 방대한 배경 지식과 문맥을 안정적으로 유지하면서 추론을 이어갈 수 있게 해줍니다.

4. 추론의 시대가 왔음을 증명하다: 추론 전용 하드웨어의 부상

소프트웨어 단위의 최적화와 더불어, 하드웨어 생태계 역시 '추론'을 중심으로 완벽히 재편되고 있습니다. 현재 추론 전용 하드웨어 시장에서 주목해야 할 두 가지 축은 Groq의 LPU와 Google의 TPU입니다.

Groq LPU (Language Processing Unit)

기존 GPU가 방대한 데이터를 동시에 처리하는 '학습'에 최적화되어 있다면, Groq의 LPU는 철저하게 실시간 '추론 속도'에 초점을 맞춥니다.

LPU는 HBM(High Bandwidth Memory) 대신 칩 내부에 초고속 SRAM(Static RAM)을 대거 탑재하여 데이터 이동 경로를 극한으로 줄였습니다. GPU 기반 추론에서는 가중치를 외부 HBM에서 연산 장치로 매 토큰마다 불러와야 하는데, 이 메모리 왕복 비용이 레이턴시의 근본 원인이 됩니다. LPU는 이를 원천적으로 차단합니다.

벤치마크 결과로 보면, Groq LPU는 Llama 2 70B 모델에서 초당 약 300토큰의 처리량을 달성했으며, 이는 동일 모델을 구동하는 H100 GPU 클러스터 대비 약 10배 빠른 수치입니다. 에너지 효율 역시 토큰당 1~3줄(joule)로, GPU의 10~30줄 대비 크게 우수합니다. 2025년 12월 NVIDIA는 Groq의 핵심 기술을 비독점 라이선싱하고 창업자 Jonathan Ross를 포함한 핵심 인력을 영입한 것으로 알려져 있으며(거래 규모 등 세부 내용은 공식 발표를 통해 확인 필요), 자사의 학습 중심 GPU 플랫폼에 추론 전용 역량을 통합했습니다. 이어 2026년 3월 GTC에서 그 첫 결실인 'Groq 3 LPU'를 공개하며, Vera Rubin GPU와 결합해 에이전틱 AI용 초당 1,500토큰 처리 목표를 제시했습니다. Groq 3 LPU는 GPU를 대체하는 것이 아니라, 추론의 디코드(토큰 생성) 단계를 전담하는 코프로세서로서 GPU의 프리필(입력 처리) 단계와 역할을 분담하는 구조입니다.

Google TPU (Tensor Processing Unit)

Google은 자체 설계한 ASIC(Application-Specific Integrated Circuit)인 TPU를 통해 추론 최적화의 또 다른 경로를 개척하고 있습니다. 특히 2025년 4월 발표된 7세대 Ironwood(TPU v7)는 거대 에이전틱 AI 시대를 맞아 대규모 추론 스케일링에 맞춰 구조를 새롭게 쇄신한 추론 특화 TPU입니다.

Ironwood는 칩당 192GB의 HBM과 7.37TB/s의 메모리 대역폭을 제공하며, 최대 9,216개 칩을 연결하여 42.5 엑사플롭스(ExaFLOPs)의 연산 능력을 구현합니다. 전력 효율은 2018년 초기 Cloud TPU 대비 약 30배 향상되었습니다. Google의 Gemini 모델 시리즈가 TPU에서 학습 및 추론되고 있으며, Midjourney는 GPU에서 TPU로 전환 후 월간 추론 비용을 210만 달러에서 70만 달러로 약 65% 절감한 것으로 알려져 있습니다.

LPU vs TPU: 접근 방식의 차이

구분	Groq LPU	Google TPU (Ironwood)
설계 철학	극한의 레이턴시 최소화	대규모 추론의 비용 효율 최적화
메모리 구조	온칩 SRAM (HBM 미사용)	대용량 HBM (칩당 192GB)
핵심 강점	초저지연 (TTFT 0.2초 이하)	대규모 스케일링 (9,216칩 Pod)
적합 시나리오	음성 AI, 실시간 에이전트 등 레이턴시 민감 워크로드	대규모 서비스 추론, 검색/추천 시스템
생태계	NVIDIA CUDA 통합 (Rubin GPU의 디코드 코프로세서)	Google Cloud 전용 (JAX/XLA 스택)

두 기술은 경쟁이라기보다 추론이라는 동일한 과제에 대해 서로 다른 병목을 공략하는 상보적 솔루션입니다. 특히 Groq 3 LPU는 독립 칩이 아닌 GPU와 짝을 이루는 코프로세서로 설계되어, GPU가 컴퓨팅 집약적인 프리필 단계를 처리하면 LPU가 대역폭 집약적인 디코드 단계를 넘겨받아 초저지연으로 토큰을 생성합니다. 반면 TPU는 학습부터 추론까지 하나의 칩으로 대규모 서비스를 아우르는 수직 통합형 접근을 취합니다.

5. GPU 및 AI 시장 전망: 추론용 인프라의 폭발적 성장

글로벌 AI 추론 시장은 2025년 약 1,060억 달러에서 2030년 약 2,550억 달러로 연평균 19.2% 성장할 것으로 전망됩니다(MarketsandMarkets). 추론 전용 칩 시장만 놓고 보더라도 2026년 500억 달러를 넘길 것으로 예측됩니다.

학습은 특정 시기에 집중적으로 발생하지만, 추론은 서비스가 운영되는 내내 24시간 발생합니다. Morgan Stanley는 2028년까지 AI 추론 컴퓨팅 수요가 학습 수요의 10배를 초과할 것으로 전망하고 있습니다. 에이전틱 AI가 일상화됨에 따라, 2026년 기업 애플리케이션의 약 40%가 AI 에이전트를 탑재할 것으로 예상되며(Gartner, 2025년 5% 미만에서 급증), 이에 따른 추론 인프라 수요는 기하급수적으로 증가할 것입니다.

대규모 데이터센터뿐만 아니라 온디바이스(On-device) 환경에서도 고성능 추론 성능이 요구되면서, 시장은 단순히 양적인 성장을 넘어 추론 효율에 특화된 구조로 다변화될 것입니다. GPU, TPU, LPU, 그리고 AWS Inferentia/Trainium 같은 클라우드 전용 칩까지 — 추론 하드웨어의 다양화는 기업들이 워크로드 특성에 맞는 최적의 하드웨어를 선택하는 '추론 하드웨어 포트폴리오' 시대를 열고 있습니다.

마무리하며

우리는 이제 AI가 독립적인 에이전트로 활동하는 시대를 맞이하고 있습니다. 에이전트가 더 깊은 문맥을 이해하고 복잡한 추론을 해내기 위해서는 넓은 컨텍스트 윈도우와 빠른 생성 속도가 필수적입니다.

TurboQuant를 통한 KV 캐시의 무손실 극한 압축, Groq LPU의 SRAM 기반 초저지연 아키텍처, Google Ironwood TPU의 대규모 추론 효율화까지 — 소프트웨어와 하드웨어 양 축에서 추론 최적화 혁신이 동시에 진행되고 있습니다.

다가오는 AI 시장의 승패는 '누가 가장 거대한 모델을 만들었는가'를 넘어, '누가 가장 한정된 자원 위에서 병목 없이 쾌적한 추론 인프라를 구축했는가'에 달려있습니다.

자주 묻는 질문 FAQ

Q 양자화를 적용하면 모델 정확도가 떨어지지 않나요?

A 가중치 양자화(예: FP16→INT4)는 정밀도를 낮추는 만큼 일정 수준의 품질 저하가 수반될 수 있습니다. 하지만 TurboQuant의 경우 KV 캐시를 3비트까지 양자화하면서도 별도의 학습이나 파인튜닝 없이 정확도 손실 제로(lossless)를 달성했습니다. 이는 PolarQuant의 메모리 오버헤드 제거와 QJL의 1비트 오차 보정이 결합된 결과로, 기존 양자화 기법(KIVI 등)이 오버헤드로 인해 압축 효과가 상쇄되던 한계를 극복한 것입니다.

Q Groq LPU가 GPU를 완전히 대체하게 되나요?

A 그렇지 않습니다. Groq 3 LPU는 GPU를 대체하는 독립 칩이 아니라, 추론 파이프라인의 디코드(토큰 생성) 단계를 전담하는 코프로세서입니다. GPU가 컴퓨팅 집약적인 프리필(입력 처리) 단계를 처리하면, LPU가 대역폭 집약적인 디코드 단계를 넘겨받아 초저지연으로 토큰을 생성합니다. NVIDIA가 Vera Rubin GPU + Groq 3 LPX 랙을 결합하는 이기종(heterogeneous) 아키텍처를 설계한 이유이기도 합니다.

관련 / 출처 REFERENCES

↗

[AI활용] AI가 코딩하고, kt cloud AI NEXUS로 AI 서비스를 배포한다

kt cloud 기술 블로그 — Thu, 6 Aug 2026 14:27:05 +0900

kt cloud AI사업개발팀 정소라 님

요약 SUMMARY

이 글에서는 AI 코딩 어시스턴트, Firebase, kt cloud AI NEXUS를 결합해
웹 애플리케이션을 개발하고 배포하는 과정을 다룹니다.
AI 개발 결과물을 안정적으로 서비스화하고 향후 확장 가능한 운영 방향을 정리합니다.

#AI_NEXUS #AI코딩 #Firebase #웹애플리케이션배포 #AI서비스

들어가며 — '아이디어'에서 '프로덕트'까지의 거리

"아이디어 → 배포"까지의 거리가 빠르게 짧아지고 있습니다. 과거에는 며칠, 길게는 몇 주가 걸리던 풀스택 웹앱 개발이, AI 코딩 어시스턴트와 클라우드 플랫폼의 결합으로 이제는 단 몇 시간이면 충분한 시대입니다.

이번 글에서는 'VocabMaster(나만의 영단어장)'라는 작은 토이 프로젝트를 통해, AI 코딩 어시스턴트(Antigravity) + Firebase + kt cloud AI NEXUS 조합이 만들어내는 시너지를 공유합니다. 단순한 개발 후기를 넘어, 이러한 워크플로우가 개발 생산성과 비즈니스 민첩성(Business Agility) 에 어떤 임팩트를 주는지를 의사결정 관점에서 짚어보겠습니다.

1. AI가 코딩한다 — Antigravity로 프론트엔드 개발

웹 개발을 시작할 때 가장 먼저 마주하는 장벽은 바로 프론트엔드입니다. 아무리 좋은 백엔드 로직이 있어도, 사용자가 마주하는 UI/UX가 투박하다면 프로덕트로서의 가치를 인정받기 어렵습니다. 하지만 최신 트렌드에 맞는 유려한 디자인을 HTML, CSS, JavaScript로 직접 구현하는 것은 막대한 시간과 노력을 요구합니다.

이번 프로젝트에서는 프론트엔드 개발의 전 과정을 AI 코딩 어시스턴트인 Antigravity에 일임했습니다.

Antigravity를 활용하여 웹앱 바이브코딩

2. Firebase로 백엔드 부담 제거— Firebase로 구현하는 실시간 데이터 동기화와 인증

UI는 완성됐지만, 새로고침하면 저장한 단어가 모두 사라지는 문제가 남아 있었습니다. 토이 프로젝트를 위해 컴퓨팅 인스턴스를 띄우고, Node.js나 Python으로 REST API 서버를 개발하며, MySQL이나 MongoDB를 세팅하는 것은 ‘배보다 배꼽이 더 클’ 수 있습니다. 정식 백엔드를 새로 구축하는 대신, 서버리스 DBaaS인 Firebase를 이용해 구글 로그인과 Cloud Firestore(NoSQL DB) 를 손쉽게 연결했습니다.

CMD(Windows) 창에서 Firebase 도구 설치(npm install -g firebase-tools), Firebase 로그인(firebase login) 명령어를 입력합니다.

CMD 창에서 Firebase 도구설치 명령어 입력

Anitgravity가 Firebase 프로젝트를 직접 조작할 수 있도록, Antigravity 실행 후 메뉴에서 MCP 서버를 선택 후, Firebase를 설치하였습니다.

Antigravity에서 MCP Server 선택

사용자 고유 ID를 키로 본인 단어장만 안전하게 동기화되도록 설계했고, 서버 코드 한 줄 없이 실시간 동기화까지 구현했습니다.

Firebase 콘솔 시작 화면_프로젝트 생성(Github 프로젝트 연동)

Firebase Authentication (구글 로그인 통합): 복잡한 OAuth 2.0 프로토콜을 직접 구현할 필요 없이, SDK의 메서드 호출 한 번으로 안전한 구글 로그인 기능을 연동했습니다.
Cloud Firestore (NoSQL 데이터베이스): users/{userId}/words/{wordId} 형태의 직관적인 문서 기반 스키마를 설계했습니다. 사용자 고유 ID(UID)를 키값으로 사용하여 본인의 단어장 데이터만 안전하게 격리되어 저장되도록 구성했습니다.
Firestore Security Rules: 서버 코드가 없는 환경에서의 보안 취약점을 막기 위해, 인증된 사용자만 자신의 데이터에 읽기/쓰기 권한을 가지도록 강력한 보안 규칙을 선언적으로 적용했습니다.

바이브코딩으로 push 및 deploy한 랜딩페이지

Firebase 구글로그인 기능 연동으로, 로그인 시 기존 데이터가 저장된 것을 확인 가능

3. AI NEXUS로 배포 — '학습과 추론의 경계를 허문' 플랫폼 위에 올리기

해외 무료 호스팅을 쓸 수도 있었지만, 데이터 주권, 확장성, 그리고 향후 AI 기능 결합 가능성까지 고려해 kt cloud AI NEXUS 환경에 올려봅니다.

AI NEXUS는 단순한 호스팅 플랫폼이 아닙니다. "Train과 Serving의 경계를 허물어, AI 워크로드 전체를 하나의 연결점(Nexus)에서 관리하는 플랫폼"이라는 포지셔닝답게, 개발 → 배포 → 확장을 하나의 환경에서 끊김 없이 이어갈 수 있도록 설계되어 있습니다.

GitHub에 코드를 푸시한 뒤, AI NEXUS가 제공하는 Interactive IDE 환경에서 개발을 마무리하고, 사전 생성된 도메인을 통한 서비스 배포 기능으로 웹앱과 DB 연계를 손쉽게 띄웠습니다. 복잡한 인프라 설정 없이도 안정적인 서비스 환경이 즉시 갖춰진다는 점이 인상적이었습니다.

AI NEXUS를 선택한 세 가지 이유:

① 노트북처럼 항상 켜져 있는 클라우드 개발 환경 (Interactive IDE)

개발 환경 세팅은 개발자들에게 언제나 고역입니다. AI NEXUS는 클라우드 기반의 Interactive IDE를 제공하여, 로그인부터 실행까지 1분 이내에 모든 세팅이 완료됩니다. "내 컴퓨터에서는 되는데 서버에서는 안 돼"라는 고질적인 문제를 원천 차단하며, 브라우저만 있으면 언제 어디서든 IDE 환경에서 코드를 수정하고 곧장 배포까지 이어지는 압도적으로 매끄러운 워크플로우를 경험할 수 있었습니다.

② 퍼블릭 클라우드급 안정성과 엔터프라이즈 보안 (Security & Stability)

AI NEXUS는 kt cloud가 자랑하는 퍼블릭 클라우드 인프라를 기반으로 작동합니다. WAF(웹 방화벽), DDoS 방어, 엄격한 네트워크 접근 제어 등 엔터프라이즈 기업들이 사용하는 최상위 수준의 보안 체계와 인프라 안정성을 작은 토이 프로젝트에서부터 동일하게 누릴 수 있다는 점은 엄청난 메리트입니다.

③ 자연스러운 AI 확장 시나리오 (Scalable AI Pipeline) — 가장 핵심적인 차별화 포인트

토이 프로젝트로 가볍게 시작했지만, 향후 이 서비스에 '개인화된 단어 추천 AI'나 'LLM 기반 예문 자동 생성 기능'을 결합하여 고도화된 AI 프로덕트로 발전시키고 싶다면 어떻게 될까요? 타 호스팅 플랫폼이라면 AI 모델 서빙을 위해 완전히 새로운 GPU 인프라를 찾아 나서고, 복잡한 API 연동과 마이그레이션 작업을 거쳐야 합니다. 하지만 AI NEXUS 위에서는 동일한 플랫폼 안에서 인프라 이전 없이 자연스럽게 진화할 수 있습니다. 데이터 전처리, 모델 학습(Train), 서빙(Serving), 파이프라인 구축에 이르는 전 과정을 마이그레이션 없이 단계적으로 스케일업(Scale-up) 할 수 있다는 점, 이것이 바로 AI NEXUS만이 제공하는 독보적이고 차별화된 비즈니스 가치입니다.

터미널에서 git clone

AI NEXUS GUI 콘솔에서 워크로드-세션

세션 생성

1. 설치 명령어 (install 포함)

npm install firebase-tools

(설치가 끝날 때까지 기다려 주세요.)

2. Firebase 로그인

npx firebase login --no-localhost

(URL이 나오면 복사해서 브라우저에서 로그인 후 발급된 코드를 터미널에 붙여넣습니다.)

3. 프로젝트 배포

npx firebase deploy

AI NEXUS 콘솔 화면

AI NEXUS 특장점

마무리 — '아이디어가 곧 AI 프로덕트'가 되는 시대

Antigravity — 코드 작성 속도를 10배로
Firebase — 백엔드 진입장벽 제거
kt cloud AI NEXUS — 프로토타입을 AI 프로덕트로 잇는 '연결점'

AI가 코드를 써주는 시대에, 화두는 이제 그 결과물을 어디에 어떻게 띄울 것인가입니다. 학습과 추론, 개발과 배포의 경계를 허문 AI NEXUS는 그 자연스러운 종착지가 되어줄 수 있습니다.

머릿속에 작은 아이디어가 있다면, 더 이상 미루지 마세요. AI가 코드를 써주고, kt cloud가 안정적으로 띄워줍니다.

'아이디어가 곧 프로덕트가 되는 시대', 지금 당장 여러분만의 프로젝트를 시작해 보시기 바랍니다.

자주 묻는 질문 FAQ

Q 가벼운 토이 프로젝트 배포에 굳이 kt cloud AI NEXUS를 선택한 이유는 무엇인가요?

A 토이 프로젝트 규모부터 엔터프라이즈급 보안을 적용받을 수 있는 것은 물론, 향후 해당 서비스에 LLM이나 AI서비스 를 추가할 때 별도의 인프라 마이그레이션 없이 동일한 플랫폼 내에서 매끄럽게 AI 파이프라인을 확장할 수 있는 장점이 있기 때문입니다.

[기술사례] OVN ACL Flow Sampling 기반 VPC Flow Log 서비스 개발

kt cloud 기술 블로그 — Fri, 31 Jul 2026 11:15:20 +0900

Tech-Frontier.md

kt cloud

$ whoami --team
❯ kt cloud Cloud플랫폼팀 서준호 님

요약

TL;DR

이 글에서는 OVN ACL Flow Sampling을 기반으로 VPC Flow Log 서비스를 개발한 과정과 아키텍처를 다룹니다.
대용량 트래픽 환경에서 로깅 부하를 줄이고 네트워크 운영 가시성을 높이는 방향을 정리합니다.

#OVN #ACLFlowSampling #VPCFlowLog #IPFIX #Goflow2

클라우드 환경이 고도화됨에 따라 네트워크 트래픽에 대한 투명성 확보와 보안 감사(CSAP 인증 등) 요건은 점점 더 까다로워지고 있습니다. 본 포스트에서는 클라우드 플랫폼팀, 데이터플랫폼팀, 보안플랫폼팀이 협업하여 7월 릴리즈를 목표로 개발한 VPC Flow Log 서비스의 아키텍처와, 기존 시스템의 한계를 극복하기 위해 적용한 기술적 내용을 공유합니다.

1. 배경: VPC Flow Log 서비스란?

VPC Flow Log는 테넌트(사용자)의 가상 네트워크(VPC) 내 가상 머신(VM) 및 리소스에서 발생하는 인/아웃바운드 IP 트래픽을 캡처하여 기록하는 서비스입니다.

비즈니스 요구사항: CSAP 인증 대응 및 보안팀의 감사 요건을 충족하기 위해, ACL(Access Control List)에 매칭된 flow의 통계 정보(flow duration, n_packets, n_bytes, direction, action 등)와 테넌트 식별을 위한 KCP 메타데이터(project_id, tenant_id 등)의 수집이 필수적이었습니다.

이러한 로그는 네트워크 연결 문제를 디버깅하거나, 보안 침해 사고를 분석하고, 대역폭 사용량을 모니터링하는 데 핵심적인 데이터로 활용됩니다.

2. OpenStack Packet Logging Framework의 진화와 기존 시스템의 한계

오픈스택 환경에서 트래픽을 로깅하기 위해 기본적으로 고려할 수 있는 두 가지 프레임워크가 있습니다.

① OpenStack Neutron Packet Logging Framework (기존 방식)

현 오픈스택은 Packet Logging Framework를 이용해 ACL audit 기능을 제공합니다. 이는 ACL에 매칭된 flow가 발생할 때마다 각 OVN Chassis(컴퓨트 노드)의 ovn-controller.log 파일에 텍스트 형태로 로그를 남기는 방식입니다.

Neutron Packet Logging 시스템의 한계점:

I/O 및 가독성 한계: 텍스트 기반의 로그(Syslog 형태)가 로컬 파일에 직접 쌓이기 때문에, 대규모 트래픽 발생 시 컴퓨트 노드의 디스크 I/O에 심각한 부하를 줄 수 있습니다.
중앙 집중화의 어려움: 수많은 컴퓨트 노드에 파편화된 로그 파일들을 실시간으로 수집·가공하기 위한 별도의 무거운 에이전트 파이프라인이 필요합니다.
네트워크 메타데이터 부족: 단순 패킷 매칭 정보 위주로 기록되어, 네트워크 성능 분석에 필요한 고도화된 Flow 통계 데이터를 유연하게 담아내기 어렵습니다.

② OVN ACL Flow Sampling (보완 및 해결책)

이러한 한계를 극복하기 위해 OVN 24.09부터 도입된 ACL Flow Sampling 기능을 활용했습니다. 이 방식은 패킷을 로그 파일에 쓰는 대신, ACL에 매칭된 flow의 메타 정보를 표준화된 IPFIX(Internet Protocol Flow Information Export) 포맷으로 변환하여 네트워크를 통해 외부 Collector로 직접 전송(Sampling)합니다.

개선 효과: 컴퓨트 노드의 로컬 디스크 I/O 부하를 완전히 제거하고, 네트워크 레벨에서 비동기적으로 flow 데이터를 바이너리 형태로 전달하므로 고속/대용량 트래픽 처리에 압도적으로 유리합니다.

3. 고성능 구조를 위한 분산형 아키텍처 설계

Scalability(확장성)를 확보하기 위해 중앙 집중형이 아닌 컴퓨트 노드(cnode) 분산 방식의 아키텍처를 채택했습니다.

각 컴퓨트 노드의 OVS(Open vSwitch)는 flow sample 데이터를 외부가 아닌 Local(127.0.0.1)의 IPFIX Collector로만 전송합니다.
로컬 IPFIX Collector는 자기 자신 노드에서 발생한 IPFIX 메타데이터만 파싱하므로 중앙 병목이 발생하지 않습니다.
파싱된 데이터는 데이터플랫폼팀과 협의한 유연한 Protobuf(Protocol Buffers) 포맷으로 가공되어 중앙의 Kafka(Topic: acl) 인프라로 고속 Ingestion됩니다.
추후 특정 컴퓨트 노드의 자원 constraints(CPU/MEM)가 우려될 경우, 해당 에이전트만 독립적으로 격리 및 관리할 수 있도록 설계되었습니다.

4. OVSDB Client Cache 기반의 고속 메타데이터 질의

IPFIX Collector를 원활하게 구동하기 위해 오픈소스인 Goflow2를 기반으로 IPFIX collector 개발을 진행했습니다.

이 과정에서 가장 중요한 핵심 과제는 "IPFIX raw 데이터(바이너리)에 KCP(Cloud Platform)의 가상 네트워크 메타데이터(Tenant ID, VM 정보 등)를 어떻게 지연(Latency) 없이 결합하여 Kafka로 보낼 것인가?"였습니다. 매 패킷(Flow)마다 외부 DB나 API를 호출하는 것은 고속 네트워크 환경에서 불가능하기 때문입니다.

이를 해결한 IPFIX Collector의 핵심 기술적 강점은 OVSDB client의 Cache 기능입니다.

OVSDB Client Cache 메커니즘

실시간 동기화 및 Local Memory Look-up: Collector 내부의 OVSDB 클라이언트는 컴퓨트 노드의 OVSDB(인터페이스, 포트, 매핑 테이블 등)와 커넥션을 맺은 후, 데이터베이스의 변경 사항을 모니터링(Monitor RPC)합니다. 초기 구동 시 데이터를 로컬 메모리에 캐싱(Cache)해 두고, 이후 변경 사항(추가/삭제/수정)만 이벤트 형태로 전달받아 캐시를 최신 상태로 유지합니다.
Zero-Network Latency 질의: IPFIX 패킷이 Collector에 들어오면, 외부 DB 조회를 위한 네트워크 라운드 트립(RTT) 없이 메모리 내 캐시에서 Interface ID나 Port 값을 기반으로 KCP 메타데이터를 즉시 매핑(Look-up)합니다.
고속 파이프라인 실현: 이 캐시 아키텍처 덕분에 인프라에 추가적인 부하를 주지 않으면서도, 초당 수만 건 이상의 Flow Record에 오픈스택 메타데이터를 실시간으로 결합(Enrichment)하여 Kafka로 밀어 넣는 초고속 파이프라인을 완성할 수 있었습니다.

5. 향후 로드맵 및 릴리즈 일정

클라우드팀과 데이터플랫폼팀의 긴밀한 협업을 통해 프로젝트는 순항 중이며, 서비스 제공을 위한 구체적인 타임라인은 다음과 같습니다.

4월 (QA 완료): 클라우드팀 주도로 로그 생성 및 수집 로직에 대한 QA 검증을 완료하고 5/7에 1차 배포를 마쳤습니다.
5월 ~ 6월 (파이프라인 구축): 데플팀에서 로그 가공 로직(파이프라인)을 개발 및 검증하고 있으며, 공동으로 데이터 가공을 위한 Query 정의를 완료했습니다.
7월 1일 (베타 서비스): 마침내 VPC Flow Log 서비스가 정식 오픈됩니다! 초기에는 mgmt stack에 저장되며 VOC 발생 시 가공 데이터를 추출하는 형태로 지원됩니다.
7월 이후 (진화): 사용자가 직접 VOC 및 로그를 조회할 수 있도록 LOKI(Observability 로그 저장소) 연계 개발을 추가 진행하여 사용자 경험을 극대화할 예정입니다.

포스트를 마치며 OVN의 최신 가상화 기술인 Flow Sampling과 Goflow2 기반의 최적화된 캐싱 아키텍처를 도입함으로써, 성능 저하 없는 대용량 VPC 가상 네트워크 로깅 시스템을 구축할 수 있었습니다. 안정적인 7월 출시와 더불어 향후 대시보드 및 고도화 서비스로 찾아뵙겠습니다. 기술적 질문이나 의견은 언제든 환영합니다!

?› 자주 묻는 질문 FAQ

Q. 기존 Neutron Packet Logging 방식 대비 OVN ACL Flow Sampling 방식의 가장 큰 차이점은 무엇인가요?

A. 기존 방식은 ACL 매칭 로그를 각 컴퓨트 노드의 로컬 파일( ovn-controller.log )에 텍스트로 기록하는 구조여서, 대규모 트래픽 시 디스크 I/O 부하가 심각하고 중앙 집중 수집을 위한 별도 에이전트 파이프라인이 필요했습니다. 반면 OVN ACL Flow Sampling 방식은 flow 메타 정보를 IPFIX 바이너리 포맷으로 네트워크를 통해 외부 Collector에 직접 전송하므로, 로컬 디스크 I/O 부하를 완전히 제거하고 고속·대용량 트래픽 처리에 훨씬 유리합니다.

Q. 매 Flow마다 외부 DB를 호출하지 않고 KCP 메타데이터(Tenant ID, VM 정보 등)를 어떻게 결합하나요?

A. OVSDB Client의 Cache 메커니즘을 활용합니다. Collector 내부의 OVSDB 클라이언트가 컴퓨트 노드의 OVSDB와 커넥션을 맺고, 초기 데이터를 로컬 메모리에 캐싱한 뒤 이후 변경 사항만 이벤트로 수신하여 캐시를 최신 상태로 유지합니다. IPFIX 패킷 수신 시 외부 네트워크 호출(RTT) 없이 메모리 내 Look-up만으로 메타데이터를 즉시 매핑(Zero-Network Latency)하기 때문에, 초당 수만 건 이상의 Flow Record도 실시간으로 Enrichment하여 Kafka로 전송할 수 있습니다.

Q. VPC Flow Log 서비스는 언제부터 이용할 수 있으며, 향후 어떤 기능이 추가될 예정인가요?

A. 7월 1일 베타 서비스로 정식 오픈됩니다. 초기에는 mgmt stack에 로그가 저장되며 VOC 발생 시 가공 데이터를 추출하는 형태로 지원됩니다. 7월 이후에는 사용자가 직접 VOC 및 로그를 조회할 수 있도록 LOKI(Observability 로그 저장소) 연계 개발을 진행하여, 대시보드 기반의 셀프서비스 로그 조회 경험을 제공할 예정입니다.

[트렌드 리포트] "DR은 필요하지만..." 진짜 고민은 따로 있었다

kt cloud 기술 블로그 — Wed, 29 Jul 2026 14:02:08 +0900

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

요약SUMMARY

AI 시대 운영 안정성에 대한 기업들의 실제 고민은 무엇일까요?
웨비나 참석자 200명의 설문을 통해 클라우드 운영 현황과 DR 준비 수준, 운영 과제를 분석했습니다.

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

AI·클라우드 환경에서는 장애 발생 이후의 대응만으로는 충분하지 않습니다. 장애가 발생하더라도 서비스를 지속할 수 있도록 설계하는 역량이 더욱 중요해지고 있습니다. 특히 시스템이 복잡해질수록 장애 대응에 대한 실무진의 부담은 커지고, 서비스 중단은 조직과 비즈니스 전반에 더 큰 영향을 미치게 됩니다.

그렇다면 실제 기업과 기관은 이러한 변화에 얼마나 준비되어 있을까요?

kt cloud는 지난 7월 7일 개최한 '중단 없는 운영을 위한 클라우드’ 웨비나 참석자 200명을 대상으로 설문조사를 진행했습니다. 실무자들은 현재 클라우드 운영 수준을 어떻게 평가하고 있으며, 정부 가이드라인에는 얼마나 대응하고 있을까요? 설문 결과를 통해 현장의 목소리를 살펴봤습니다.

↘️아래 이미지의 '전체 내용 확인하기'를 클릭하고, <200명 인프라 담당자가 답한 운영 안정성의 현실> 설문 리포트를 받아보세요.

아직도 많은 기업이 ‘단일 인프라’에 의존하고 있다

케클s피드 7월호｜AI 데이터센터의 새로운 기준을 말하다

kt cloud 기술 블로그 — Wed, 29 Jul 2026 13:52:57 +0900

AI 활용이 확산되면서 안정적인 서비스 운영과 유연한 확장을 위한 인프라의 중요성이 더욱 커지고 있습니다. 이번 케클s피드에서는 AI 데이터센터 전략과 핵심 인프라 기술, 중단 없는 클라우드 서비스를 위한 운영 기술과 플랫폼 전략, 그리고 실제 적용 사례를 담았습니다. AI 시대를 준비하는 기업들이 주목해야 할 기술과 인사이트를 함께 살펴보시기 바랍니다.

‘기술이 장르가 되는 곳, kt cloud의 케클러 인터뷰 시리즈’는

기술을 직접 설계하고 구현하는 케클러들의 목소리를 통해,

고객의 다음 문제를 먼저 고민하는 kt cloud의 생각과 해법을 전합니다.

AI 시대 데이터센터는 더 이상 서버를 수용하는 공간이 아닙니다. 고객의 AI 워크로드를 안정적으로 운영하기 위해서는 전력, 냉각, 네트워크, 운영까지 하나의 전략으로 연결되어야 합니다.

kt cloud DC사업담당 박재우 상무가 말하는 AI 데이터센터의 핵심 기준과 미래 방향, 그리고 현장에서 축적한 인사이트를 케클러 인터뷰에서 만나보세요.

AI 인프라의 미래 읽기

AI 시대, 기업들은 운영 안정성을 위해 무엇을 가장 고민하고 있을까요?
웨비나 참석자 200명을 대상으로 진행한 설문 조사 결과를 기반으로

클라우드 운영 현황과 DR 준비 수준, 현장의 주요 과제를 분석했습니다.

많은 기업이 DR의 필요성을 인식하고 있지만, 실제 운영 현장에서 우선 해결해야 할 과제는 예상과 달랐습니다.

웨비나 참석자 200명을 대상으로 진행한 설문을 통해 기업의 인프라 구성과 DR 준비 수준을 살펴보고, 운영 실무자들이 서비스 안정성을 확보하는 과정에서 겪는 어려움을 분석했습니다.

기업들이 여전히 단일 인프라 환경을 운영하는 이유는 무엇일까요? AI 시대의 운영자들이 새로운 기술 도입보다 우선하고 있는 과제는 무엇인지, 케클s피드 구독자 전용 트렌드 리포트에서 확인해 보세요.

AI 시대 운영 안정성 리포트 보러가기

AI 시대 서비스 중단을 최소화하는 운영 전략,

웨비나 다시보기를 통해 확인해 보세요.

AI 인프라의 경쟁력은 GPU 성능만으로 결정되지 않습니다.
GPU를 효율적으로 활용하는 NeoCloud와

이를 뒷받침하는 AIDC 핵심 기술을 살펴봅니다.

AI 모델이 고도화될수록 중요한 것은 GPU 자체보다 이를 안정적으로 운영하고 최적의 성능을 끌어낼 수 있는 인프라입니다. 이제 AI 경쟁력은 GPU 성능은 물론, 이를 얼마나 효율적으로 활용하고 안정적으로 운영할 수 있는지에 의해 결정됩니다.

AI 전용 클라우드는 일반 클라우드와 무엇이 다를까요? GPU 활용 기술부터 초고속 네트워크, 랙당 최대 80kW의 발열을 감당하는 AI 데이터센터의 핵심 기술까지, AI 인프라의 엔진룸을 함께 살펴보시기 바랍니다.

AI 인프라의 엔진룸 들여다보기

AIDC 열을 식히는 수자원 효율과 냉각 공학

AI 시대, 데이터센터의 경쟁력은 더 이상 전력 효율(PUE)만으로 결정되지 않습니다.

GPU 서버의 폭발적인 발열은 냉각수 소비를 급증시켰고,

수자원 효율(WUE)이라는 새로운 생존 지표가 부상했습니다.

GPU 서버의 고집적화로 냉각 부담이 커지는 가운데,

이번 Tech Story에서는 WUE 관리 전략과 차세대 수처리 기술,

그리고 안정적인 냉각을 위한 핵심 설비 운영 기술까지

AI 인프라를 지탱하는 냉각 공학을 살펴봅니다.

효율 지표 AI 데이터센터에서 WUE가 중요해지는 이유

AI 워크로드의 폭발적 확산으로 GPU 랙당 발열이 수십~수백 kW를 넘어서면서, 전력 효율(PUE)만으로는 데이터센터의 운영 효율을 설명할 수 없게 되었습니다. WUE(수자원 효율)가 새로운 운영 지표로 주목받는 이유와 AIDC 환경에서 WUE 관리가 어려운 4가지 구조적 원인, 그리고 현장 중심의 4대 개선 전략을 소개합니다. 자세히 보기

수처리 기술 데이터센터 냉각수 효율(WUE)을 높이는 하이브리드 수처리 전략

WUE를 실질적으로 개선하려면 냉각수의 농축 배율(CoC)을 높여 보충수 소비를 줄여야 합니다. 전기산화 기반 하이브리드 수처리 기술은 화학약품 투입 없이 WUE를 최대 40% 개선할 수 있는 현실적 경로로 주목받고 있습니다. AWS 싱가포르 등 글로벌 실증 사례와 함께 3단계 시스템 구성을 살펴봅니다. 자세히 보기

냉각 설비 데이터센터를 지키는 냉동기의 원리와 운영 기술

AI 서버의 열을 안정적으로 제어하지 못하면 성능 저하와 서비스 중단으로 이어질 수 있습니다. 냉동기(Chiller)의 열역학적 원리부터 중앙 냉수식 냉방 구조, 액체 냉각 기술, 그리고 냉각 효율을 높이기 위한 핵심 운영 포인트까지 데이터센터 냉각 기술의 핵심을 소개합니다. 자세히 보기

kt cloud가 여의도 데이터센터 증설을 통해 금융 특화 인프라 경쟁력을 강화합니다.

복수 거래시장 확대와 글로벌 투자 증가로 금융 인프라의 중요성이 더욱 커지고 있습니다. 특히 실시간 데이터 처리와 초저지연(Ultra-Low Latency) 환경은 금융 서비스의 안정성과 경쟁력을 좌우하는 핵심 요소로 자리 잡고 있습니다.

이러한 시장 변화에 맞춰 kt cloud는 여의도 데이터센터 증설에 착수했습니다. 금융 고객이 여의도 데이터센터를 선택하는 이유와 초저지연 금융 허브를 구축하기 위한 전략을 살펴봅니다.

초저지연 금융 인프라 자세히 보기

SUMMIT 2026 사전등록 바로가기

공공 클라우드의 새로운 기준은 무엇일까요?

kt cloud PLATFORM이 제시하는 차세대 클라우드 플랫폼을 소개합니다.

공공기관의 클라우드 전환이 확대되면서 안정성과 확장성을 모두 갖춘 차세대 클라우드 플랫폼에 대한 요구도 커지고 있습니다.

kt cloud는 자체 개발한 kt cloud PLATFORM을 적용한 공공 클라우드 구축을 완료했습니다. VM·컨테이너 통합 운영, 멀티 리전·멀티 AZ, 생성형 AI 지원 등 새롭게 적용된 플랫폼의 특징을 확인해 보세요.

kt cloud PLATFORM은 무엇이 다를까?

공공 서비스에 본격 적용된 kt cloud PLATFORM의 기반에는,
OpenStack의 변화를 안정적으로 검증하는 개발 체계가 있습니다.

kt cloud PLATFORM은 OpenStack 기반으로 지속적인 개발과 고도화를 이어가고 있습니다. 오픈소스는 끊임없이 변화하기 때문에 새로운 기능을 추가하는 것뿐 아니라, 서비스 안정성을 확보하기 위한 체계적인 검증 과정도 중요합니다.

kt cloud가 OpenStack을 내재화하며 구축한 개발·검증 체계와 안정적인 플랫폼 운영을 위한 핵심 원칙을 소개합니다.

OpenStack 개발 체계 살펴보기

뉴스레터 구독하기

케클s피드 6월호 보러가기

[케클러 인터뷰 시리즈] #4 전국에 1GW 규모 AI 데이터센터를 준비하는 kt cloud의 방식

kt cloud 기술 블로그 — Wed, 29 Jul 2026 09:00:39 +0900

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

요약 SUMMARY

‘기술이 장르가 되는 곳, kt cloud의 케클러 인터뷰 시리즈’는 케클러들의 목소리를 통해 고객의 다음 문제를 먼저 고민하는 kt cloud의 기술적 지향점과 해법을 전합니다.
네 번째 호에서는 kt cloud 데이터센터 사업을 총괄하는 박재우 상무를 만났습니다.
AI 시대에 데이터센터의 기준은 어떻게 달라졌는지, 고객마다 다른 AI *워크로드를 수용하려면 무엇을 설계해야 하는지, 그리고 kt cloud가 어떤 AI 데이터센터를 만들어가고 있는지를 담았습니다.

#ktcloud #AIDC #AI데이터센터 #AI #AI인프라 #GPU

kt cloud DC사업담당 박재우 상무

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

AI가 기업의 핵심 서비스로 자리 잡으면서 데이터센터의 역할도 빠르게 변화하고 있습니다. 과거에는 얼마나 많은 서버를 수용할 수 있는지가 경쟁력이었다면, 이제는 AI 서비스를 안정적으로 운영할 수 있는 인프라를 갖추는 것이 핵심 경쟁력이 되고 있습니다.

AI 연산의 핵심인 *GPU는 막대한 전력을 소비하고 많은 열을 발생시킵니다. 또한 수천 장의 GPU가 하나의 AI 모델을 동시에 학습하려면 대규모 데이터를 실시간으로 처리하는 초고속 네트워크가 필수입니다. 이처럼 AI 워크로드의 특성은 기존 데이터센터와는 전혀 다른 인프라를 요구합니다.

이에 따라 고밀도 랙, *액체 냉각, 고전압 전력 공급, 초고속 네트워크 등 AI에 최적화된 설비 구축이 필수 과제로 떠오르고 있습니다. 그러나 GPU를 많이 확보하고 최신 설비를 갖추는 것만으로 AI 데이터센터가 완성되는 것은 아닙니다.

진정한 AI 데이터센터는 입지 선정부터 전력과 냉각, 네트워크, 운영까지 모든 요소가 하나의 체계로 설계되고 유기적으로 운영되어야 합니다. 그래야 고객의 AI 서비스를 안정적으로 지원하고, 지속적으로 확장할 수 있기 때문입니다.

이번 인터뷰에서는 kt cloud DC사업담당 박재우 상무를 만나 AI 시대 데이터센터의 새로운 기준과 AI 서비스를 안정적으로 운영하기 위해 갖춰야 할 핵심 경쟁력에 대해 들어보았습니다.

이야기를 시작하며

박재우 상무 | kt cloud DC사업담당

kt cloud의 데이터센터 사업 전략과 상품 기획, AI 데이터센터 개발·공급을 총괄하고 있습니다. 데이터센터 입지 선정부터 설계·구축·운영(*DBO)까지 전 과정을 아우르는 컨설팅 경험을 바탕으로, 데이터센터를 단순한 시설이 아닌 통합된 비즈니스 프로세스로 바라보고 있습니다. 이를 바탕으로 고객의 AI 워크로드 특성에 맞는 최적의 AI 데이터센터를 기획하고 개발하는 데 집중하고 있습니다.

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

↳ AX를 추진하며 AI 데이터센터 파트너 또는 AI 서비스 이전을 검토 중인 CTO·CIO

↳ 대규모 GPU 클러스터와 AI 플랫폼을 운영하는 기술 리더
↳ 비즈니스 확장을 위한 데이터센터 전략을 고민하는 IT 의사결정자

Part 1. AI 시대, 데이터센터의 기준이 바뀌다

AI 시대, GPU 중심 AI 워크로드를 지원하는 데이터센터

과거 데이터센터의 역할은 명확했습니다. 안정적인 전력과 냉방 환경을 갖추고, 고객의 서버와 장비를 안전하게 수용하는 것이었습니다.

하지만 *AX(AI 전환, AI Transformation)가 본격화되면서 데이터센터의 역할도 근본적으로 달라지고 있습니다. 박재우 상무는 이러한 변화를 이끄는 가장 큰 요인으로 “GPU가 만들어낸 고집적 환경”을 꼽습니다.

기존 서버 랙이 수 kW 수준의 전력을 사용했다면, 최신 AI용 *고집적 랙은 수십 kW에서 많게는 100kW 이상의 전력을 요구합니다. 전력 소비가 급격히 증가하면서, 데이터센터 역시 이전과는 전혀 다른 설계 기준이 필요해졌습니다.

충분한 전력을 안정적으로 공급할 수 있는 수전 설비와 이중화 구조는 물론, GPU에서 발생하는 막대한 열을 효과적으로 처리할 수 있는 냉각 시스템까지 모두 함께 고려되어야 합니다. 이제는 *공랭 중심의 기존 방식만으로는 AI 워크로드를 안정적으로 운영하기 어려운 환경이 된 것입니다.

박재우 상무는 고객들의 질문도 달라졌다고 말합니다.

"

예전에는 ‘빈 상면이 있느냐’를 물었다면,

이제는 ‘이곳에서 우리 AI 서비스를 실제로 안정적으로 운영할 수 있느냐’를 묻습니다.

"

데이터센터는 이제 고객의 AI 서비스를 구축하고, 확장하며, 중단 없이 운영할 수 있도록 뒷받침하는 핵심 인프라이자 실행 기반으로 그 역할이 진화하고 있습니다.

Part 2. 고객의 워크로드에서 출발하는 ‘맞춤형’ 설계

산업별 AI 워크로드에 맞춰 설계되는 AI 데이터센터 모델

하나의 AI 데이터센터 모델로 모든 고객을 만족시킬 수 있을까요?

박재우 상무는 AI 데이터센터는 고객의 AI 워크로드와 비즈니스 특성에서 설계가 시작되어야 한다고 말합니다. 산업과 서비스마다 AI를 활용하는 방식과 데이터 환경이 모두 다르기 때문입니다.

금융권은 강력한 보안과 규제 준수, 무중단 운영이 최우선이며, 증권 서비스는 물리적 거리를 최소화한 초저지연 환경이 핵심 경쟁력입니다.

제조업은 생산 현장과 가까운 곳에서 실시간 데이터를 처리해야 하고, 공공 부문은 데이터 주권을 고려한 분리 환경이 필수적입니다.

반면 AI 기술·서비스 기업은 대규모 모델 학습을 위한 GPU 규모와 확장 가능한 초고속 네트워크를 가장 중요하게 살펴봅니다.

이처럼 고객이 요구하는 환경이 서로 다른 만큼, 하나의 데이터센터 모델로 모든 AI 서비스를 지원하기는 어렵습니다. 이에 kt cloud는 고객의 위치와 AI 워크로드, 데이터 특성, 운영 규모에 따라 하이퍼스케일(Hyperscale), 엣지(Edge), 마이크로(Micro) 데이터센터를 최적의 형태로 제안하고 있습니다.

구분	주요 특징	적합한 워크로드
01. 하이퍼스케일 데이터센터 (Hyperscale Data Center)	수천 대 이상의 서버, 대규모 전력, 초고속 네트워크를 갖춘 초대형 거점	대규모 AI 모델 학습, 대형 클라우드 등 막대한 연산 자원이 필요한 영역
02. 엣지 데이터센터 (Edge Data Center)	사용자나 산업 현장 등 데이터 발생지와 물리적으로 가장 가까운 곳에 분산 배치	초저지연 금융 거래, 제조 현장 실시간 분석, 자율주행 및 로봇 제어
03. 마이크로 데이터센터 (Micro Data Center)	서버·전력·냉각·보안을 소형 모듈(랙 단위)에 통합하여 필요한 위치에 즉시 배치	특정 거점이나 제한된 규모의 신속한 인프라 대응

핵심은 고객에게 이미 구축된 데이터센터를 선택하도록 하는 것이 아니라, 고객의 AI 서비스에 가장 적합한 데이터센터를 설계하는 데 있습니다.

kt cloud는 고객의 워크로드를 먼저 분석하고, 그에 맞는 데이터센터의 형태와 운영 조건을 설계합니다. 박재우 상무는 이런 접근이야말로 고객의 비즈니스에 최적화된 진정한 ‘맞춤형 AI 데이터센터’의 핵심이라고 설명합니다.

Part 3. AI 데이터센터를 완성하는 3대 핵심 기술

AI 데이터센터 운영의 핵심 기술

AI 데이터센터의 경쟁력은 GPU를 얼마나 많이 확보했는지가 아니라, 그 GPU를 얼마나 안정적으로 운영할 수 있느냐에서 결정됩니다. 박재우 상무는 AI 데이터센터를 뒷받침하는 핵심 요소로 전력 품질, 열 관리, 그리고 운영 역량을 꼽습니다.

01. 전력 품질: 용량을 넘어 품질과 효율까지

GPU가 밀집된 환경에서는 단순히 많은 전력을 공급하는 것만으로는 충분하지 않습니다. 대규모 전력이 한꺼번에 집중되면 전력 파형이 왜곡되는 고조파 현상이 발생할 수 있으며, 이는 고가의 GPU 장비 성능과 수명, 서비스 안정성에 영향을 미칠 수 있습니다. 따라서 안정적인 전력 공급은 물론, 전력 품질 관리와 이중화 설계까지 함께 갖춰져야 합니다.

kt cloud는 대기전력 손실을 줄이고 에너지 효율을 높이기 위해, 랙에 고전압을 직접 공급하는 800V DC(고전압 직류)기반의 차세대 전력 구조도 선제적으로 준비하고 있습니다.

02. 열 관리: 공기로 식히기 어려운 시대

GPU의 소비 전력이 증가하면 발생하는 열도 함께 늘어납니다. 수십 kW의 열을 발생시키는 고집적 랙 환경에서는 기존 공랭식 냉각만으로는 안정적인 온도 유지가 어렵습니다. 이에 kt cloud는 지난해 개소한 가산 AI 데이터센터에 냉각판을 부착해 액체로 직접 칩의 열을 식히는 Direct-to-Chip 방식의 액체 냉각을 가장 먼저 상용화했습니다.

하지만 진짜 기술 경쟁력은 액체 냉각 설비를 도입하는 데 있지 않습니다. GPU 배치와 워크로드를 고려해 어느 랙에서 얼마나 많은 열이 발생할지를 예측하고, 이를 바탕으로 냉각 구조까지 함께 설계하는 것이 핵심입니다.

03. 운영: 기술을 지속 가능한 서비스로 만드는 과정

전력과 냉각 설비를 갖췄다고 해서 AI 데이터센터가 완성되는 것은 아닙니다. 이를 안정적으로 운영할 체계와 노하우가 갖춰져야 고객의 AI 서비스를 중단 없이 지속할 수 있습니다. 특히 액체 냉각 환경에서는 물과 냉매가 서버 바로 옆을 흐르기 때문에 작은 누액도 서비스 장애로 이어질 수 있어 더욱 정교한 운영 관리가 필요합니다.

kt cloud는 가산 AI 데이터센터에서 배관 설계와 유량 제어, 24시간 관제, 실시간 장애 대응까지 축적한 운영 경험을 바탕으로 AI 서비스를 안정적으로 운영할 수 있는 체계를 구축하고 있습니다.

박재우 상무는 이러한 전력·냉각·운영 역량이 앞으로 AI 데이터센터 경쟁력을 좌우하는 핵심 요소가 될 것으로 전망합니다. 또한 이러한 기술은 데이터센터를 표준화된 모듈 형태로 빠르게 구축하는 '*모듈러 데이터센터'는 물론, 로봇과 자율주행 등 초저지연 연산이 요구되는 '*피지컬 AI 시대'의 엣지 인프라 경쟁력으로도 이어질 것이라고 설명합니다.

Part 4. AI 인프라 구축 이후, 고객이 마주하는 진짜 과제

고객이 필요한 범위를 선택할 수 있는 kt cloud 서비스

AI 인프라를 구축했다고 해서 곧바로 AI 서비스를 안정적으로 운영할 수 있는 것은 아닙니다. 박재우 상무는 GPU를 도입하는 것과 AI 서비스를 운영하는 것은 전혀 다른 영역이라고 말합니다.

고집적 GPU 환경을 자체적으로 구축하려면 데이터센터 시설은 물론 전력과 냉각, 네트워크까지 모두 갖춰야 합니다. 여기에 전문 운영 인력과 24시간 장애 대응 체계까지 필요해 초기 투자뿐 아니라 지속적인 운영 부담도 커질 수밖에 없습니다.

그래서 kt cloud는 고객이 인프라 운영보다 AI 서비스 개발과 비즈니스에 집중할 수 있도록 구축부터 운영까지 필요한 범위를 선택할 수 있는 서비스를 제공하고 있습니다.

01. Colocation

코로케이션은 고객이 보유한 GPU와 서버를 안정적으로 운영할 수 있도록 상면과 전력, 냉각, 네트워크, 보안 환경을 제공하는 서비스입니다. 자체 AI 데이터센터를 구축하기 어려운 기업도 AI 워크로드에 적합한 인프라를 빠르게 확보할 수 있습니다.

02. kt cloud Colocation.AI

한 단계 더 나아가 kt cloud Colocation.AI는 GPU 인프라와 전문 운영 서비스를 하나로 제공하는 AI 특화 서비스입니다. 고객은 GPU 장비를 직접 구매하거나 운영 조직을 별도로 구축하지 않아도, 필요한 규모의 AI 인프라를 월 과금 방식으로 이용할 수 있습니다. 이를 통해 초기 투자 부담은 줄이고, AI 서비스 개발과 운영에 더욱 집중할 수 있습니다.

박재우 상무는 "AI 시대에는 인프라를 얼마나 많이 보유했는지보다, 얼마나 빠르고 안정적으로 AI 서비스를 시작할 수 있는지가 더 중요한 경쟁력이 될 것"이라고 강조합니다.

Part 5. AI 병목을 해결하는 ‘연결’

kt cloud의 AI 데이터센터 연결 구조

AI 서비스의 성능을 결정하는 것은 GPU만이 아닙니다.

박재우 상무는 AI 워크로드의 숨은 병목은 연산 성능이 아니라 데이터가 이동하는 속도와 연결 구조에 있다고 설명합니다. 아무리 뛰어난 GPU를 갖추더라도 데이터가 제때 전달되지 않으면 GPU는 제 성능을 발휘하지 못하기 때문입니다.

결국 AI 시대의 네트워크는 단순한 연결 수단이 아니라, 데이터센터 전체 성능을 결정하는 핵심 인프라입니다.

박재우 상무는 kt cloud의 AI 데이터센터 연결 구조를 데이터센터 내부, 데이터센터 간, 글로벌 세 단계로 설명합니다.

01. 데이터센터 내부 연결 (Intra-DC)

수천 장의 GPU가 하나의 AI 모델을 동시에 학습하려면 GPU 간 데이터가 초고속·초저지연으로 오가야 합니다. kt cloud는 광통신 기반의 고속 네트워크를 촘촘하게 구성해 GPU 간 병목을 최소화하고 AI 연산 성능을 극대화합니다.

02. 데이터센터 간 연결 (Inter-DC)

여러 지역에 위치한 데이터센터도 하나의 AI 인프라처럼 동작해야 합니다. kt cloud는 데이터센터 간 전용망을 통해 대규모 데이터를 실시간으로 연동하고, 학습과 추론 작업을 여러 거점으로 분산해 연산 효율과 서비스 안정성을 높이고 있습니다.

03. 글로벌 연결 (Global DC)

AI 서비스가 글로벌로 확장될수록 국가 간 데이터 이동도 크게 늘어납니다. 특히 대규모 AI 모델의 학습과 추론 과정에서는 국제망을 통한 초대용량 데이터 전송이 빈번하게 발생합니다. 이를 뒷받침하는 핵심 인프라가 바로 '*해저케이블'입니다.

KT는 국내 최대 수준의 해저케이블과 인터넷 연동 거점(*IX), 통신 *백본망을 보유하고 있으며, 이를 기반으로 국내는 물론 글로벌까지 안정적인 AI 네트워크 환경을 제공합니다.

박재우 상무는 AI 데이터센터의 경쟁력은 개별 시설이 아니라 얼마나 끊김 없이 연결되는 하나의 인프라를 구현할 수 있는지에 달려 있다고 강조합니다.

kt cloud는 KT그룹의 네트워크 역량을 바탕으로 데이터센터 내부부터 데이터센터 간, 글로벌까지 하나의 AI 인프라처럼 유기적으로 연결해 대규모 AI 워크로드를 안정적으로 지원하고 있습니다.

Part 6. 진짜 AI 서비스를 운영할 수 있는 AI 데이터센터의 모습

kt cloud AI 데이터센터(AI DC) 비전

그렇다면 AI 서비스를 운영하는 기업은 앞으로 어떤 기준으로 데이터센터를 선택해야 할까요?

박재우 상무는 “사업자가 얼마나 많은 기술을 보유했는지가 아니라, 그 기술을 실제 서비스 환경에서 얼마나 안정적으로 운영해왔는지가 더 중요하다”고 말합니다.

새로운 기술은 도입보다 운영이 어렵습니다. 특히 액체 냉각과 같은 차세대 기술은 장기간의 운영 경험을 통해 안정성이 검증되어야 비로소 고객의 AI 서비스를 중단 없이 안정적으로 운영할 수 있습니다.

결국 앞으로의 경쟁은 누가 더 큰 데이터센터를 짓느냐가 아니라, 누가 고객의 AI 비즈니스를 더 안정적으로 지원할 수 있느냐에 달려 있습니다.

박재우 상무가 생각하는 '진짜 AI 서비스를 운영할 수 있는 AI 데이터센터'는 단순히 GPU를 많이 갖춘 시설이 아닙니다.

고객의 AI 워크로드에 맞는 인프라를 설계하고, 고집적 환경을 안정적으로 운영할 수 있는 기술과 경험을 갖추며, 고객이 인프라보다 AI 서비스와 비즈니스에 집중할 수 있도록 지원하고, 데이터센터 내부부터 글로벌까지 끊김 없이 연결하는 것. 이 모든 요소가 하나의 체계로 갖춰질 때 비로소 진정한 AI 데이터센터가 완성됩니다.

이러한 방향은 KT그룹이 추진하는 AI 인프라 전략과도 맞닿아 있습니다.

KT그룹은 향후 5년간 AI 인프라에 총 6조 원을 투자해 1GW 규모의 AI 데이터센터를 단계적으로 구축하고, 전국 수천 개의 국사를 초저지연 AI 엣지 거점으로 활용할 계획입니다. 또한 글로벌 해저케이블 용량을 128Tbps 이상으로 확대하는 등 AI 시대에 필요한 연결 경쟁력도 지속적으로 강화하고 있습니다.

kt cloud는 앞으로도 설계와 구축, 운영, 연결까지 AI 데이터센터의 전 과정을 책임지는 파트너로서, 고객이 AI 비즈니스에 집중할 수 있는 가장 신뢰받는 AI 인프라를 제공해 나갈 것입니다.

[기술분석] 데이터센터 냉각수 효율(WUE) 개선: 전기산화 기반 하이브리드 수처리 전략

kt cloud 기술 블로그 — Tue, 28 Jul 2026 10:50:14 +0900

kt cloud DC북부운용센터 유승철 님

요약 SUMMARY

이 글에서는 AI 데이터센터의 냉각수 효율 개선을 위한 WUE 지표와 전기산화 기반 하이브리드 수처리 전략을 다룹니다.
물 사용 규제와 운영 비용 부담에 대응하기 위한 실무적 방향을 정리합니다.

#WUE #AI데이터센터 #전기산화 #냉각탑 #수처리

AI 데이터센터가 폭발적으로 성장하면서, 냉각수 소비 효율(WUE)은 더 이상 운영 비용의 문제가 아니라 지속가능성의 핵심 지표가 되었습니다. 전기산화(Electrooxidation) 기술을 기존 수처리 시스템과 결합한 하이브리드 전략은, 화학약품 투입 없이 WUE를 최대 40% 개선할 수 있는 현실적 경로로 주목받고 있습니다.

1. WUE, 왜 지금 다시 주목받는가

WUE(Water Usage Effectiveness)는 데이터센터가 IT 장비 1kWh를 냉각하는 데 소비하는 물의 양(단위: L/kWh)을 나타냅니다.

WUE = 연간 냉각수 소비량(L) ÷ IT 장비 연간 소비 전력(kWh)

숫자가 낮을수록 효율이 좋습니다. 문제는 AI 워크로드가 급증하면서 GPU 클러스터의 열밀도가 기존 데이터센터 대비 3~5배 높아졌다는 점입니다. 이는 냉각탑이 훨씬 더 많은 물을 증발시켜야 한다는 뜻이며, 기존 수처리 방식으로는 이 수요를 따라가기 어렵습니다.

※ 업계 벤치마크 현황 (2024 기준)

구분	WUE (L/kWh)
업계 평균 (화학약품 처리)	1.8 ~ 2.2
선도 하이퍼스케일러	1.0 ~ 1.4
전기산화 하이브리드 적용 사례	0.9 ~ 1.2
Green Grid 2030 목표	< 0.9

기존 화학약품 기반 수처리는 스케일(Scale) 억제와 레지오넬라균 방제에는 효과적이지만, 물의 농축 배율(Cycles of Concentration, CoC)을 일정 수준 이상 높이기 어렵다는 구조적 한계가 있습니다. CoC가 낮으면 블로우다운(농축 오염수 배출) 빈도가 높아지고, 그만큼 보충수 소비가 늘어나게 됩니다.

2. 전기산화: 물이 스스로 소독제가 되는 기술

전기산화는 물에 직접 전류를 흘려 전극 표면에서 강력한 산화 라디칼을 생성하는 기술입니다. 복잡한 화학이 아니라, 전기화학 반응 자체가 수처리의 엔진이 됩니다.

Image: AI-Generated Content

양극 (산화): H₂O → ·OH + H⁺ + e⁻
음극 (환원): 2H⁺ + 2e⁻ → H₂↑
부반응 (염소계): Cl⁻ → ClO⁻ (차아염소산 생성)

생성된 하이드록실 라디칼(·OH)은 산화력이 오존의 약 2배에 달하며, 바이오필름을 분해하고 스케일 전구체(탄산칼슘, 실리카 등)를 이온 형태로 유지시킵니다. 이 덕분에 CoC를 기존 3~5에서 7~10 수준으로 상향할 수 있고, 그만큼 블로우다운 빈도와 보충수 소비가 줄어듭니다.

3. 하이브리드 수처리 시스템: 3단계 구성

위 아키텍처 다이어그램에서 보듯, 전기산화는 단독으로 쓰이는 기술이 아니라 기존 수처리 인프라와 통합됩니다.

① 전처리 단계: 기계적 여과(멀티미디어 필터)와 최소한의 스케일 억제제를 사용해 전기산화 셀에 유입되는 부하를 줄입니다. 전처리가 충분하지 않으면 전극 오염(Fouling)이 빨라지고 에너지 소비가 늘어납니다.
② 전기산화 셀: 비활성 금속 산화물(IrO₂/RuO₂ 코팅) 전극이 주로 사용됩니다. 전류 밀도는 일반적으로 10~50 mA/cm² 범위에서 운전하며, 이는 냉각탑 유량과 오염 부하에 따라 실시간 제어됩니다. 에너지 소비는 처리수 1톤당 0.5~2 kWh 수준으로, 화학약품 구매·운반·보관 비용과 비교할 때 경제성이 있습니다.
③ 후처리 단계: UV 조사나 잔류 ClO⁻ 모니터링으로 최종 위생 기준을 충족시킵니다. 특히 레지오넬라 방제를 위한 공공보건 규정 준수에 필수적인 단계입니다.

4. 경쟁 기술 비교: 왜 전기산화인가

구분	화학약품 처리	오존 처리	자외선(UV)	전기산화 하이브리드
스케일 억제	✅ 우수	❌ 미흡	❌ 미흡	✅ 우수
바이오필름 제거	△ 중간	✅ 우수	△ 표면 한정	✅ 우수
약품 보관·안전	❌ 위험물	△ 주의 필요	✅ 불필요	✅ 불필요
CoC 향상 가능성	△ 제한적	△ 중간	❌ 없음	✅ 높음
운영 자동화	△ 중간	△ 중간	✅ 용이	✅ 용이
탄소 발자국	❌ 높음	△ 중간	✅ 낮음	✅ 낮음

오존 처리는 산화력은 강하지만 설비 비용과 안전 관리 부담이 큽니다. UV는 살균에는 효과적이나 스케일 제어 기능이 없습니다. 전기산화 하이브리드는 이 두 약점을 동시에 보완하는 유일한 방식입니다.

5. 미래 전망: WUE 0.9 시대를 향해

Image: AI-Generated Content

2025년 현재, 전기산화 하이브리드 시스템은 아직 대규모 데이터센터에서 주류 기술로 자리잡지는 못했습니다. 전극 내구성(수명 3~5년), 초기 CAPEX, 그리고 고농도 실리카 환경에서의 성능 유지가 주요 해결 과제로 남아 있습니다.

그러나 AI 인프라 확장이 가속화되고, ESG 공시와 물 사용 규제가 강화되는 추세를 감안하면, 이 기술의 채택 속도는 빠르게 높아질 것으로 보입니다. 특히 수자원이 제한적인 중동, 남아시아, 동남아시아 지역에 건설 중인 AI 데이터센터들은 전기산화 하이브리드 전략을 초기 설계 단계부터 반영하는 사례가 늘고 있습니다.

WUE 0.9 L/kWh 이하라는 목표는 단순한 숫자가 아닙니다. 그것은 데이터센터가 지역 물 순환계에 미치는 영향을 최소화하면서도 지속적으로 성장할 수 있음을 증명하는 기준선입니다.

6. 현장 설치 사례

전기산화 시스템은 이미 글로벌 하이퍼스케일러와 대형 데이터센터 운영사 현장에서 실증되고 있습니다. 아래 사례들은 기술의 현장 적용 가능성과 실제 도입 맥락을 파악하는 데 참고할 수 있습니다.

사례 1 — AWS Singapore × Hydroleap (2022~현재)

항목	내용
운영사	Amazon Web Services (AWS)
위치	싱가포르 데이터센터
도입 배경	싱가포르 PUB(국가 수자원청)의 수자원 효율화 요구 및 2030 Water Positive 목표 달성
적용 기술	Hydroleap HL-EO 전기산화 시스템 + 재처리수(NEWater) 활용
주요 성과	COC 극대화를 통한 블로우다운 최소화, 냉각탑 수처리 자동화 달성
수상	2024년 PUB Singapore Watermark Award · Water Efficiency Award (데이터센터 부문)
확장 계획	APAC 전역 및 글로벌 확대 적용 추진 중

AWS는 싱가포르 현지 스타트업 Hydroleap과 협력하여 전기산화 기술을 냉각탑에 적용, COC를 최대한 높게 유지하는 방식으로 취수량을 최소화하는 데 성공했습니다. 이 협업은 약 2년간 지속되며 기술을 고도화했으며, 현재 APAC 전역으로 확대를 추진하고 있습니다.

시사점

AWS 사례는 단순한 수처리 효율화를 넘어, 재처리수(NEWater) 활용 + 전기산화 + 실시간 자동화 제어를 결합한 통합 수자원 관리 전략의 대표 사례입니다. 규제 압력이 높은 지역(싱가포르, 유럽 등)에서 전기산화 도입이 더욱 가속화될 것으로 전망됩니다.

사례 2 — 상업용 데이터센터 운영사 × Veolia Water Technologies

항목	내용
운영사	미국 소재 상업용 데이터센터 (익명)
도입 배경	연수기(Water Softener) 유지 비용 부담 및 실리카 스케일 문제로 인한 칠러 튜브 오염
기존 문제	연간 연수기 운영 비용 약 $160,000(소금·유지보수) + 실리카 침적으로 인한 열교환 효율 저하
적용 기술	Veolia TrueSense RSG 컨트롤러 기반 pH 제어 + 화학 수처리 통합 최적화
주요 성과	COC 약 2배 향상, 보충수(Make-up Water) 수요 약 50% 절감
정량 효과	연간 약 4,500만 리터(1,200만 갤런) 절감 · 연간 운영비 약 $150,000 절감

해당 데이터센터는 Veolia와의 협력을 통해 냉각탑 COC를 거의 2배 향상시켰으며, 보충수 수요를 약 50% 줄이고 연간 약 $150,000의 운영비를 절감했습니다.

시사점

이 사례는 전기산화 단독 도입이 아니더라도, COC 상향을 목표로 한 수처리 최적화 자체가 현장에서 즉시 측정 가능한 절감 효과를 낸다는 점을 보여줍니다. 전기산화는 이 수처리 최적화의 다음 단계로 자연스럽게 연결됩니다.

자주 묻는 질문 FAQ

Q 전기산화 시스템을 도입하면 기존 화학약품 투입을 완전히 없앨 수 있나요?

A 대부분의 경우 완전 대체보다는 대폭 감축 이 현실적인 목표입니다. 전기산화는 스케일 억제제와 살균제의 투입량을 70~90% 줄일 수 있지만, 특수한 오염 조건(고농도 실리카, 심한 유기물 부하)에서는 보완적인 화학약품 처리가 필요할 수 있습니다. 핵심은 "제로 케미칼"이 아니라 "최소 케미칼로 최대 CoC"를 달성하는 것입니다.

Q 기존 냉각탑에 레트로핏(retrofit)으로 설치할 수 있나요?

A 가능합니다. 전기산화 셀은 사이드스트림(side-stream) 방식으로 기존 배관에 바이패스 형태로 연결되기 때문에, 냉각탑 자체를 교체하거나 가동을 중단할 필요가 없습니다. 일반적으로 설치 기간은 2~5일 수준이며, 전체 냉각탑 유량의 5~15%만 처리해도 전체 수질 관리 효과를 얻을 수 있습니다.

Q WUE 개선 외에 운영 비용 측면에서 어떤 이점이 있나요?

A 세 가지로 요약할 수 있습니다. 첫째, 수도 요금 절감 — 보충수 소비가 줄어드는 만큼 직접적인 절감 효과가 발생합니다. 둘째, 화학약품 구매·처리 비용 절감 — 위험물 관리 비용과 폐수 처리 비용이 함께 줄어듭니다. 셋째, 설비 수명 연장 — 스케일과 바이오필름이 줄어들면 열교환기, 배관, 펌프의 유지보수 주기가 길어집니다. 일반적으로 ROI 회수 기간은 2~4년으로 보고됩니다.

관련 / 출처 REFERENCES

[1] Patterson, M. (2011). WP#35 — Water Usage Effectiveness (WUE): A Green Grid Data Center Sustainability Metric. The Green Grid.
[2] Shehabi, A. et al. (2024). 2024 United States Data Center Energy Usage Report. Lawrence Berkeley National Laboratory (LBNL-2001637). U.S. DOE.
[3] Mytton, D. (2021). Data Centre Water Consumption. npj Clean Water, Nature.
[4] Vertiv (2025). Optimizing Water Usage Effectiveness for Data Centers.
[5] Data Center Knowledge (2025). A Guide to Data Center WUE and Best Practices.
[6] ANSI/ASHRAE Standard 188-2021. Legionellosis: Risk Management for Building Water Systems.
[7] ISO 11731. Water Quality — Enumeration of Legionella. ISO.

↗

[AI인프라] 네오클라우드 GPUaaS와 고밀도 AIDC의 공학적 결합

kt cloud 기술 블로그 — Tue, 28 Jul 2026 10:22:34 +0900

kt cloud DC글로벌고객팀 심재문 님

요약 SUMMARY

이 글에서는 GPUaaS 네오클라우드와 고밀도 AIDC가 AI 인프라의 성능·전력·냉각 요구를 충족하는 방식을 다룹니다.
안정적인 AI 운영을 위한 인프라 설계의 중요성을 정리합니다.

#GPUaaS #네오클라우드 #AIDC #RDMA

Image: AI-Generated Content

1. ‘범용’의 시대에 ‘가속’의 시대로

과거의 데이터센터가 CPU 중심의 '범용 컴퓨팅(General Purpose Computing)' 공간이었다면, 현재는 GPU 중심의 '가속 컴퓨팅(Accelerated Computing)'으로의 완전한 전환을 요구받고 있습니다.

단순히 데이터를 저장하고 웹 페이지를 띄우는 서버와 달리, 수조 개의 파라미터를 가진 AI 모델을 학습시키는 서버는 물리적 요구 조건 자체가 다릅니다. 본 고에서는 kt cloud가 제공하는 GPUaaS 플랫폼인 네오클라우드(NeoCloud)의 기술적 실체와, 이를 지탱하기 위해 데이터센터 내부에서 벌어지는 하드웨어 엔지니어링의 혁신을 심층적으로 분석합니다.

2. 네오클라우드(NeoCloud): 하드웨어를 소프트웨어로 '조각'하다

일반적인 구독자에게 클라우드는 "컴퓨터를 빌려 쓰는 것"이지만, 테크 관점에서 네오클라우드는 "거대한 GPU 자원 풀(Pool)을 소프트웨어로 세밀하게 쪼개고 연결하는 추상화 기술"의 결정체입니다.

2.1 GPU 가상화의 핵심: MIG(Multi-Instance GPU)와 시분할 기술

고가의 H100 GPU를 한 사람이 통째로 쓰는 것은 자원 낭비일 수 있습니다. 네오클라우드는 엔비디아의 MIG 기술을 고도화하여 하나의 물리적 GPU를 여러 개의 독립된 인스턴스로 분리합니다.

기술적 원리: 기존의 소프트웨어 방식 가상화와 달리, MIG는 GPU 내부의 메모리 컨트롤러와 연산 코어(SM)를 하드웨어 수준에서 파티셔닝합니다.
독립적 성능 보장: 이를 통해 옆 인스턴스에서 아무리 복잡한 연산을 하더라도 내 연산 성능에는 간섭이 생기지 않는 '완벽한 자원 격리(Isolation)'를 실현합니다.

2.2 RDMA와 GPUDirect: 서버 간의 '고속도로'

AI 학습은 한 대의 서버로 끝나지 않습니다. 수백 대의 서버가 하나의 거대한 뇌처럼 움직여야 합니다. 이때 발생하는 병목 현상을 해결하는 것이 네오클라우드의 RDMA(Remote Direct Memory Access) 기술입니다.

커널 우회(Kernel Bypass): 데이터를 전송할 때 CPU나 운영체제의 개입 없이, 한 서버의 GPU 메모리에서 다른 서버의 GPU 메모리로 데이터를 직접 쏴줍니다.
지연 시간의 혁명: 이를 통해 네트워크 레이턴시를 마이크로초 단위로 줄이며, 수천 개의 GPU를 하나로 묶는 거대한 'AI 클러스터'를 완성합니다.

3. AIDC의 엔지니어링: 물리 법칙과의 사투

네오클라우드라는 강력한 소프트웨어가 구동되기 위해서는, 이를 수용하는 데이터센터(AIDC)가 겪는 '전력 밀도'**와 '냉각 효율'의 문제를 해결해야 합니다. 이것은 단순한 시설 관리가 아닌 극한의 공학 설계입니다.

3.1 랙당 전력 밀도의 수직 상승 (Power Density)

기존 데이터센터 설계의 상한선은 랙당 5~10kW 수준이었습니다. 하지만 네오클라우드에 투입되는 최신 AI 서버 한 대는 그 자체로 수 kW를 소비합니다. 한 랙에 이러한 서버를 8대만 실장해도 전력 수요는 40kW~80kW까지 치솟습니다.

전력 인입의 혁신 (Busway System): 기존의 얇은 전선으로는 이 막대한 전류를 감당할 수 없습니다. kt cloud는 고전류를 안전하게 흘릴 수 있는 구리 막대 형태의 '버스웨이' 시스템을 채택하여 전력 손실을 줄이고 공급 안정성을 확보합니다.
HVDC(High Voltage Direct Current): 변전소에서 들어오는 교류(AC)를 직류(DC)로 변환하는 단계를 최소화하여 에너지 효율을 10% 이상 높이는 엔지니어링이 적용됩니다.

3.2 냉각 패러다임의 변화: Air-Cooled에서 Liquid-Cooled로

공기는 열전도율이 매우 낮습니다. 80kW의 열을 공기로만 식히려면 태풍급의 강풍을 계속 불어넣어야 하며, 이는 팬(Fan)의 전력 소모만으로도 센터 운영 비용이 폭등함을 의미합니다.

DLC(Direct-to-Chip) 냉각: 차가운 냉각수가 흐르는 콜드 플레이트(Cold Plate)를 GPU 칩 위에 직접 밀착시킵니다. 액체는 공기보다 열전달 능력이 수천 배 뛰어납니다.
PUE의 극대화: 이를 통해 데이터센터의 에너지 효율 지표인 PUE를 1.1 수준으로 낮춥니다. 즉, IT 장비가 쓰는 에너지 외에 냉각에 들어가는 에너지를 10% 수준으로 억제하는 것입니다.

4. 왜 일반 클라우드보다 네오클라우드인가?

일반 구독자들은 "그냥 집에서 좋은 컴퓨터를 맞추거나 해외 대형 클라우드를 쓰면 안 되나?"라고 물을 수 있습니다. 하지만 여기에는 세 가지 명확한 기술적/경제적 이유가 있습니다.

전력 인프라의 문턱: 가정이나 일반 사무실은 랙당 40kW의 전력을 감당할 수 없습니다. 꽂는 순간 차단기가 내려가거나 전선이 타버릴 것입니다. 네오클라우드는 개인이 구축 불가능한 '특수 전력 요새'를 빌려주는 것입니다.
GPU 수명과 안정성: 24시간 100% 가동되는 AI 연산은 엄청난 열을 발생시켜 하드웨어 수명을 단축시킵니다. 전문적인 냉각 시스템(DLC/RDHx) 하에서 구동되는 네오클라우드의 GPU는 성능 저하(Throttling) 없이 최상의 컨디션을 유지합니다.
데이터 주권과 보안: 해외 클라우드를 쓸 때 발생하는 데이터 유출 우려와 고비용의 데이터 전송료(Egress Fee) 문제를 국내 인프라를 통해 완벽히 해결합니다.

5. 결론: 인프라는 더 이상 조연이 아니다

지금까지 인프라는 소프트웨어를 담는 조연에 불과했습니다. 하지만 AI 시대의 인프라는 소프트웨어의 성능을 결정짓는 핵심 변수입니다.

네오클라우드는 GPU라는 희귀 자원을 소프트웨어로 민주화(Democratization)하고, 고밀도 AIDC는 물리적 법칙의 한계를 공학적으로 돌파합니다. 우리는 이제 단순한 '서버 임대업'을 넘어, AI라는 인류 역사상 가장 거대한 연산 워크로드를 지탱하는 '디지털 엔진 엔지니어링'의 시대로 나아가고 있습니다.

자주 묻는 질문 FAQ

Q 일반 클라우드와 AI 전용 네오클라우드의 인프라는 무엇이 다른가요?

A 가장 큰 차이는 '밀도'와 '속도'입니다. 밀도(Density): 일반 클라우드 랙이 아파트 한 세대 전력을 쓴다면, 네오클라우드 전용 랙은 아파트 한 동 전체에 맞먹는 전력을 소모합니다. 이를 위해 버스웨이(Busway) 전력 공급과 액냉(Liquid Cooling) 시스템이 필수적으로 결합됩니다. 속도(Interconnection): 단순 인터넷 연결을 넘어, 여러 대의 GPU가 하나의 뇌처럼 움직이도록 RDMA 기술을 통해 서버 간 메모리에 직접 접근합니다. 즉, 물리적 서버의 벽을 허물고 하나의 거대한 가속기 풀(Pool)을 만드는 것이 핵심입니다.

관련 / 출처 REFERENCES

NVIDIA Whitepaper: Multi-Instance GPU (MIG) Architecture & Performance
ASHRAE Datacom Series: Liquid Cooling Guidelines for Datacom Equipment Centers
IEEE 802.3/InfiniBand Roadmap: High-Speed Interconnects for AI Clusters
kt cloud Tech Report (2026): 차세대 고밀도 AIDC 전력 계통 및 냉각 효율(PUE 1.1) 실증 사례

↗

[구축사례] IPFIX와 Goflow2로 구현한 kt cloud Network 미터링 내재화

kt cloud 기술 블로그 — Fri, 24 Jul 2026 14:31:30 +0900

Tech-Frontier.md

kt cloud

$ whoami --team
❯ kt cloud Cloud플랫폼팀 윤찬열 님

요약

TL;DR

이 글에서는 IPFIX와 Goflow2를 활용해 OVN 환경의 네트워크 과금 미터링 체계를 구축한 과정을 다룹니다.
정확한 트래픽 측정은 클라우드 운영 신뢰성과 과금 리스크 관리에 중요한 기준이 됨을 정리합니다.

#IPFIX #Goflow2 #OVN #NetworkMetering #OpenStack

iptables가 사라진 자리, 과금은 어디서 측정하나

클라우드 사업에서 네트워크 과금은 민감한 영역입니다. 테넌트별로 외부와 주고받는 North-South 트래픽을 정확히 측정해야 청구서가 나가는데, 여기서 1바이트라도 어긋나면 그대로 비즈니스 신뢰도 문제로 번지기 때문입니다.

ML2/OVS 시절에는 이걸 Neutron-metering-agent가 처리했습니다. iptables chain injection 방식으로 Netfilter 카운터를 읽어 L3 트래픽을 집계하는 구조였죠. 리눅스 IP 스택에 카운터가 붙어 있으니, 그 숫자를 그대로 긁어오면 됐습니다.

그런데 아키텍처가 ML2/OVN으로 넘어가면서 이 전제가 통째로 깨졌습니다. OVN은 라우팅을 OVS Flow로 처리합니다. 패킷이 리눅스 IP 스택(iptables 등)을 더 이상 타지 않는다는 뜻입니다. 카운터를 읽을 자리 자체가 없어진 겁니다. 기존 에이전트로는 측정이 불가능해졌고, 우리는 미터링 파이프라인을 처음부터 다시 설계해야 했습니다.

새 구조에 걸린 요건은 세 가지였습니다.

OVS Bridge 안에서 여러 테넌트 트래픽이 섞여 흐를 때, External IP를 기준으로 고객(테넌트)을 식별할 수 있을 것
과금 데이터인 만큼 데이터 정확도를 최대한 보장할 것
컴퓨트 노드(Cnode)에 성능 오버헤드를 주지 않을 것

sFlow를 버리고 IPFIX를 고른 이유

OVS Bridge에서 트래픽을 뽑아낼 방법으로 Traffic Mirroring, sFlow, IPFIX를 두고 검토했습니다. 최종 후보는 sFlow와 IPFIX였는데, 과금이라는 목적을 놓고 보면 둘의 구조적 차이가 결정적이었습니다.

sFlow는 상태를 저장하지 않습니다. 패킷이 스위치를 지날 때 1/N 확률(예: 1000개 중 1개)로 헤더만 복사해서 즉시 내보냅니다. 스위치 리소스를 거의 안 쓰니 오버헤드는 낮지만, 수집된 샘플로 전체 트래픽을 역산해야 합니다. "대략 이 정도 썼겠다"는 통계적 추정이라, "정확히 몇 바이트인가"를 따져야 하는 과금에는 정합성이 부족합니다.

IPFIX(NetFlow v9 기반 표준)는 OVS 내부에서 Flow 단위로 상태를 유지합니다. 동작은 이렇습니다.

5-Tuple로 분류: 패킷이 들어오면 출발지 IP, 목적지 IP, 출발지 포트, 목적지 포트, 프로토콜 — 이 5가지를 기준으로 묶습니다.
In-Memory 집계: 같은 5-Tuple 패킷은 매번 내보내지 않고 OVS Flow Cache에 쌓아두면서 패킷 수(n_packets)와 바이트 수(n_bytes)를 카운터에 누적합니다.
Timeout 시 Export: 통신이 끝나거나(Inactive Timeout), 너무 오래 지속되거나(Active Timeout), Cache가 가득 차면 그제서야 최종 카운터를 묶어서 수집기로 보냅니다.

핵심은 수집기에 도달하기 전에 이미 OVS 단에서 바이트가 합산돼 넘어온다는 점입니다. 그래서 정합성이 100%에 가깝습니다. 과금 로스를 감수할 수 없는 상황이라 IPFIX로 결정했습니다.

구분	sFlow	IPFIX
동작 방식	Stateless 샘플링	Stateful 집계
데이터 수집	1/N 확률로 헤더 복사	Flow 단위 카운터 누적
정확도	통계적 추정(역산 필요)	실측값에 가까움
오버헤드	매우 낮음	상대적으로 높음(튜닝 필요)
과금 적합성	정합성 이슈	적합

가장 큰 산: "이 IP, 대체 누구 건가?"

각 Cnode의 OVS에 IPFIX 설정을 마치고, 오픈소스 수집기인 Goflow2를 노드에 데몬셋으로 띄웠습니다. 그리고 여기서 이번 프로젝트의 진짜 난관에 부딪혔습니다.

IPFIX Raw 데이터에는 Source IP와 Destination IP만 있습니다. 그런데 청구서를 발행하려면 이 트래픽을 일으킨 주체, 즉 OpenStack Project ID(Tenant ID)를 알아야 합니다. IP만 가지고는 "누구한테 돈을 받아야 하는지"를 알 수 없는 거죠.

가장 단순한 방법은 패킷 로그가 들어올 때마다 Neutron API에 "이 IP 누구 거야?"라고 물어보는 겁니다. 그런데 초당 수만 건씩 쏟아지는 IPFIX 레코드마다 API나 DB 조회를 때린다면(매번 Network RTT 발생), 컨트롤 플레인은 그 즉시 주저앉습니다. 이 방식은 처음부터 선택지가 아니었습니다.

대신 외부 호출(네트워크 I/O)을 0으로 만드는 방향으로 갔습니다. Goflow2 소스코드를 직접 수정해서, 로컬 메모리 캐시 기반으로 O(1) 매핑을 하는 Enrichment 모듈을 붙였습니다. 파이프라인은 3단계로 동작합니다.

1단계 — 사전 캐싱(Initial Sync). Goflow2 프로세스가 뜨면 가장 먼저 해당 Cnode의 로컬 OVSDB(또는 OVN SB DB)와 소켓 커넥션을 맺습니다. 그리고 클라우드 안의 전체 FIP 및 NAT 자원 정보(IP ↔ Project ID 매핑)를 읽어와 프로세스 메모리에 Hash Map으로 올려둡니다. 이걸 가능하게 하려고, 사전에 Neutron NAT 리소스를 만들 때 External IDs 필드에 Project ID를 기록하도록 커스터마이징을 해뒀습니다.

2단계 — 실시간 동기화(Watch & Update). 클라우드는 살아 움직입니다. VM이 지워지거나 IP가 새로 할당되면 매핑이 바뀌죠. 그래서 Goflow2 내부 OVSDB Client가 DB 변경을 구독(Monitor RPC)합니다. NAT/FIP 정보가 추가·변경·삭제될 때마다 이벤트를 받아 로컬 Hash Map을 최신 상태로 갱신합니다.

3단계 — Zero-Latency 매핑(Enrichment). 실제 IPFIX 데이터가 Goflow2로 들어오면, 파서가 출발지·목적지 IP를 추출하고 Enrichment 모듈이 가동됩니다. 외부 통신은 전혀 하지 않고 프로세스 내부 Hash Map만 조회해서 매칭되는 Project ID를 찾습니다. 메모리 서치라 매핑 시간은 사실상 0에 수렴합니다.

이 캐시 구조 덕분에 인프라에 부하를 주지 않으면서도 openstack_src_project_id, openstack_dst_project_id가 깔끔하게 태깅된 과금용 로그를 Kafka로 흘려보낼 수 있었습니다.

왜 Sampling Rate를 1로 두고, 대신 캐시를 튜닝했나

여기서부터는 수치 얘기인데, 먼저 한 가지 분명히 해둘 게 있습니다. 아래 결과는 개발 환경에서 100MB 파일을 500회 다운로드하는 인위적인 시나리오로 뽑은 값입니다. 실제 운영 트래픽은 flow 분포, 패킷 크기, 동시 세션 수가 전혀 다르기 때문에, 같은 설정이라도 CPU 부하와 정확도 수치는 환경마다 달라집니다. 그래서 아래 숫자는 "이 설정이면 항상 이렇게 나온다"는 절대값이 아니라, 튜닝 방향을 잡기 위한 상대 비교로 읽는 게 맞습니다. 실제 적용 전에는 각자 환경의 대표 트래픽으로 재측정하는 걸 권장합니다.

그 위에서, 우리가 왜 Sampling Rate를 1로 고정했는지부터 짚겠습니다.

과금이라는 목적이 Sampling Rate를 1로 못박습니다. Sampling Rate를 N으로 두면 패킷을 1/N 확률로만 집계하고, 나머지는 통계적으로 역산합니다. 일반적인 트래픽 가시성·이상 탐지 용도라면 이 정도 오차는 충분히 허용됩니다. 실제로 많은 ISP가 1/1,000 수준의 샘플링으로 트래픽을 관측하고, “한 대형 ISP를 대상으로 1/8,000 샘플링 IPFIX와 SNMP 바이트 카운터를 비교했을 때 두 지표의 비율은 평균·중앙값 모두 약 0.98이었으며, 샘플링 레이트를 높일수록 SNMP 대비 정확도는 더 개선된다”고 보고됩니다. 즉 샘플링은 본질적으로 근사값입니다.이상적으로는 “모든 flow 모니터링 기술이 100% 정확도를 제공해야 하지만, 현실에서는 확장성 문제를 풀기 위한 데이터 축소 과정에서 정확도가 떨어진다”는 것이 일반적인 결론이고요. 청구서에 들어갈 바이트를 다루는 입장에서는 이 근사 오차 자체를 받아들일 수 없어서, Rate=1(전수 집계)이 사실상 강제됩니다.

문제는 "Rate를 1로 두면 CPU가 터지지 않나?"입니다. 실제로 튜닝 전에는 CPU 부하가 115%까지 치솟으며 패킷 드랍이 발생했고, 역설적으로 정확도가 94.9%로 떨어졌습니다. 다 잡으려다 오히려 흘린 셈이죠.

해법은 샘플링 비율(무엇을 볼지)과 export 동작(언제 묶어 내보낼지)을 분리해서 생각하는 것이었습니다. OVS IPFIX에서 패킷 선택 확률(sampling)과, 집계된 flow를 언제 수집기로 내보낼지 정하는 캐시 파라미터(cache_active_timeout, cache_max_flows)는 별개의 손잡이입니다. 패킷은 Rate=1로 전부 보되, 같은 5-Tuple은 캐시 안에서 카운터로 충분히 누적시킨 다음 한 번에 묶어 내보내면, 봐야 할 바이트는 그대로 다 세면서도 export 레코드 수와 그에 따른 유저스페이스 처리 부하는 크게 줄어듭니다. 그래서 "Rate=1인데 CPU가 낮다"는 게 모순이 아닙니다.

이 방향으로 Cache Active Timeout을 30초, Cache Max Flows를 1000으로 잡았더니, OVS 레벨 CPU 부하가 4% 미만으로 안정화되면서 데이터 정확도는 100.4%(헤더 오버헤드 포함 기준)까지 맞춰졌습니다. (100%를 살짝 넘는 건 IPFIX 헤더·패딩이 페이로드 바이트에 더해져 계측되기 때문으로, 과금 정합성 관점에서는 별도 보정 대상입니다.)

설정	CPU 부하	정확도	비고
Sampling Rate 1 (튜닝 전)	~115%	94.9%	캐시 미조정 → export 폭주 → 패킷 드랍
Sampling Rate 1 + Cache 튜닝	< 4%	100.4%	Active Timeout 30s / Max Flows 1000

⚠️ 다시 강조하면, 위 수치는 100MB×500회 다운로드라는 테스트 시나리오 기준입니다. Cache Timeout을 길게 잡을수록 export는 줄지만 과금 데이터의 반영 지연이 커지고, Max Flows가 실제 동시 flow 수보다 작으면 캐시가 조기에 차서 export가 잦아집니다. 두 값 모두 환경의 동시 flow 규모와 과금 정산 주기에 맞춰 다시 잡아야 합니다.

하지만 튜닝으로 끝날 문제가 아니었습니다. Goflow2 수집기가 Cnode 안에서 돈다는 건, 결국 고객의 실제 서비스 VM과 물리 CPU를 공유한다는 의미입니다. 프로세스를 아무리 가볍게 깎아도, 트래픽 스파이크로 미터링 프로세스에 과부하가 걸려 고객 VM 성능을 갉아먹는 Noisy Neighbor가 생기면 안 됩니다.

그래서 두 가지 방향을 잡았습니다.

CPU Pinning & Cgroups 격리 (현재 적용): 미터링 프로세스(Goflow2 등)가 리소스를 멋대로 점유하지 못하도록 OS 레벨 Cgroups로 CPU/Memory Limit을 엄격하게 걸었습니다. 더 나아가 고객 VM이 쓰는 코어와 에이전트가 쓰는 코어를 물리적으로 분리(CPU Pinning / cpuset)해서 리소스 경합을 원천 차단했습니다.
외부 수집기 클러스터 분리 (향후 대비): 지금은 Zero-Latency 매핑을 위한 로컬 데몬셋 구조가 최적입니다. 다만 트래픽 규모가 폭발적으로 커져서 로컬 튜닝·격리만으로 감당이 안 되는 임계점이 오면, Goflow2 Collector를 Cnode에서 떼어내 외부 전용 수집 서버 클러스터로 오프로딩하는 구조로 전환할 수 있게 설계 여지를 열어뒀습니다.

전체 아키텍처와 로드맵

완성된 데이터 플로우는 이렇습니다.

여담으로, IETF RFC 5472는 IPFIX를 과금에 쓸 때 UDP 전송 손실과 중복 레코드 문제가 생길 수 있다고 짚습니다. 우리는 이걸 두 갈래로 대응했습니다. 앞서 말한 대로 Goflow2를 Cnode에 로컬 배포해 장애 허용성(Fault Tolerance)을 먼저 확보하고, 후단에서 sequence_num으로 중복을 제거하는 로직을 추가했습니다.

OVN 전환은 미터링 입장에서 꽤 큰 숙제였습니다. 하지만 Goflow2 커스터마이징과 캐시 튜닝, 자원 격리 전략을 엮으면서, 결과적으로는 예전보다 더 견고하고 성능 좋은 미터링 시스템을 직접 손으로 만들어낼 수 있었습니다. 앞으로 고도화될 네트워크 서비스에도 많은 관심 부탁드립니다.

?› 자주 묻는 질문 FAQ

Q. ML2/OVN에서는 왜 기존 Neutron-metering-agent를 못 쓰나요?

A. 기존 에이전트는 iptables chain injection으로 Netfilter 카운터를 읽는 방식입니다. ML2/OVS 시절엔 패킷이 리눅스 IP 스택을 타니 거기 붙은 카운터를 긁으면 됐지만, OVN은 라우팅을 OVS Flow로 처리하기 때문에 패킷이 iptables를 더 이상 거치지 않습니다. 읽을 카운터 자체가 없어지는 거라, 측정 지점을 OVS Flow 레벨(IPFIX)로 옮겨야 합니다.

Q. 정확도가 중요하면 그냥 sFlow 말고 IPFIX 쓰면 끝 아닌가요?

A. 방향은 맞지만 그게 끝이 아닙니다. IPFIX도 Sampling Rate를 1로 두고 무작정 다 캡처하려 들면 CPU 부하가 100%를 넘기면서 패킷 드랍이 나고, 오히려 정확도가 떨어집니다(저희 환경에선 94.9%까지 하락). Sampling Rate는 1로 유지하되 OVS Cache Timeout과 Max Flows를 함께 튜닝해야 CPU를 4% 미만으로 누르면서 정합성을 확보할 수 있습니다.

Q. 수집기가 컴퓨트 노드 안에서 돌면 고객 VM에 영향을 주지 않나요?

A. 그 우려 때문에 자원 격리를 따로 챙겼습니다. Cgroups로 미터링 프로세스의 CPU/Memory Limit을 엄격히 걸고, CPU Pinning(cpuset)으로 고객 VM 코어와 에이전트 코어를 물리적으로 분리해 경합을 차단했습니다. 트래픽 규모가 더 커지면 수집기를 외부 전용 클러스터로 오프로딩하는 전환도 설계상 열어둔 상태입니다.

[kt cloud] kt cloud PLATFORM, 공공 클라우드를 위한 차세대 운영 기반

kt cloud 기술 블로그 — Fri, 24 Jul 2026 09:35:07 +0900

kt cloud 마케팅커뮤니케이션팀 김지웅 님

요약 SUMMARY

이 글에서는 공공 클라우드를 위한 kt cloud PLATFORM의 운영 구조와 확장성, 보안성, AI 인프라 기반을 다룹니다.

안정적인 서비스 운영과 변화 대응을 위한 클라우드 전환 방향을 정리합니다.

#ktcloud #공공클라우드 #OpenStack #Kubernetes #AI인프라

안녕하세요! kt cloud 테크 마케터 김지웅 입니다. ‍♂️

오늘은 공공 클라우드의 새로운 운영 기반이 될 kt cloud PLATFORM을 소개해 드릴게요.

공공 클라우드 환경의 변화

Image: AI-Generated Content

공공 클라우드 환경은 이제 가상서버(VM) 중심의 안정적인 인프라 운영을 넘어, 컨테이너, AI 인프라, 데이터 기반 서비스까지 함께 고려하는 방향으로 넓어지고 있어요. 기존 업무 시스템을 안정적으로 운영하는 일이 여전히 중요한 가운데, 디지털 행정 서비스 확대, 데이터 활용 고도화, 생성형 AI 기반 업무 혁신처럼 새로운 기술 수요도 빠르게 늘고 있죠.

이런 변화에 따라 공공 클라우드에는 더 높은 안정성, 보안성, 확장성이 요구돼요. 기존 시스템을 안정적으로 운영하면서 신규 디지털 서비스와 AI 인프라까지 함께 수용할 수 있는 유연한 플랫폼 구조가 중요해지고 있죠. 장애가 발생하더라도 서비스 영향을 최소화할 수 있는 고가용성 구조와, 공공 부문에서 요구하는 보안·운영 기준을 충족하는 신뢰성도 핵심 요소로 자리 잡고 있어요.

kt cloud PLATFORM이란?

Image: AI-Generated Content

kt cloud PLATFORM은 kt cloud가 자체 기술로 개발한 차세대 클라우드 플랫폼으로, OpenStack on Kubernetes 구조를 기반으로 해요. OpenStack이 제공하는 가상서버·네트워크·스토리지 같은 인프라 제어 역량에 Kubernetes의 자동화·복원력·확장성을 더해, 플랫폼 운영 구조를 한층 고도화한 것이 특징이에요.

이 구조 덕분에 플랫폼 구성요소를 표준화된 방식으로 배포·관리할 수 있고, 서비스 수요가 바뀌거나 장애가 생기는 상황에도 더 체계적으로 대응할 수 있어요. 그 결과 공공 클라우드 환경에 요구되는 운영 안정성, 자원 확장성, 서비스 연속성을 플랫폼 구조 차원에서 강화할 수 있죠.

kt cloud PLATFORM의 장점

1. 멀티 리전·멀티 AZ 기반의 고가용성 구조

Image: AI-Generated Content

첫 번째 장점은 멀티 리전·멀티 AZ 기반의 고가용성 구조예요. 공공 서비스는 행정, 민원, 공공 데이터처럼 국민 생활과 밀접하게 연결돼 있어 안정적인 운영이 무엇보다 중요하죠. kt cloud PLATFORM은 서울과 경북을 기반으로 한 멀티 리전 구조를 갖추고 있으며, 서울 리전은 목동·용산 2개 주요 AZ와 이를 보완하는 Satellite Zone으로 구성돼 있어요.

목동과 용산 AZ는 서비스 자원을 분산 운영하기 위한 주요 가용 영역이고, Satellite Zone은 이 두 AZ 구성을 보완해 플랫폼 운영 안정성을 높이는 보조 영역이에요. 이처럼 인프라를 리전과 AZ 단위로 분산 구성하면, 고객 서비스가 멀티 AZ 구조로 설계·배치될 경우 특정 데이터센터나 가용 영역에 장애가 생기더라도 서비스 영향을 줄일 수 있어요.

여기에 서울·경북 멀티 리전 구조를 함께 적용하면 지역 단위 장애나 재해복구 요구까지 대응할 수 있는 구조를 마련할 수 있어요.

2. 클라우드 네이티브 환경에 적합한 서비스 확장성

Image: AI-Generated Content

두 번째 장점은 클라우드 네이티브 환경에 적합한 서비스 확장성이에요. 공공 서비스에도 수요가 몰리는 시기가 있어요. 특정 기간에 민원이 급증하거나 새로운 행정 서비스를 빠르게 선보여야 할 때는, 필요한 시점에 자원을 확장하고 개선 사항을 바로 반영할 수 있느냐가 관건이 되죠.

kt cloud PLATFORM은 안정성이 중요한 기존 VM 기반 시스템은 그대로 수용하면서, 신규 디지털 서비스는 컨테이너 기반으로 유연하게 배포·확장할 수 있는 환경을 함께 제공해요. 대표적으로 관리형 서비스인 Managed Kubernetes Service를 제공하고 있고, 기존 환경 대비 kt cloud PLATFORM만의 이점을 바탕으로 컨테이너 기반 서비스를 더욱 확장해 나갈 예정이에요. 덕분에 공공기관은 기존 시스템 유지와 신규 서비스 확장이라는 두 가지 요구를 하나의 플랫폼에서 관리할 수 있게 돼요.

3. 공공 클라우드 보안·운영 요건에 대응하는 신뢰성

Image: AI-Generated Content

세 번째 장점은 공공 클라우드 보안·운영 요건에 대응하는 신뢰성이에요. 공공 부문에서 클라우드를 도입할 때는 성능과 확장성뿐 아니라 정보보호 기준과 인증 요건, 접근 통제, 네트워크 보안, 운영 안정성까지 함께 고려해야 해요. kt cloud PLATFORM은 이 요건들을 플랫폼 차원에서 뒷받침해요. 먼저 인증 측면에서, CSAP를 비롯해 공공 클라우드에 요구되는 보안 인증을 이미 취득했고, 그 범위도 지속적으로 넓혀가고 있어요.

권한과 자원 관리도 체계적이에요. Organization 구조로 조직 단위의 자원 관리 체계를 구성하고, IAM 기반 권한 관리로 사용자 역할과 접근 범위를 구분할 수 있어요. 이를 통해 부서별 자원 사용 범위를 나누고, 업무 역할에 따라 접근 권한을 부여하며, 보안 정책을 일관되게 적용할 수 있죠.

네트워크 보안도 한층 강화됐어요. 기존 플랫폼 대비 VPC 환경이 개선되면서 테넌트 간 네트워크를 더 명확하게 분리하고 통제할 수 있게 됐고, 접근 제어를 권한 차원을 넘어 네트워크 차원까지 촘촘하게 적용할 수 있어요. 인증부터 권한, 네트워크까지 이어지는 이 관리 체계는 여러 부서와 시스템이 함께 돌아가는 공공 환경일수록 그 가치가 커져요.

4. AI 인프라 확장 기반

Image: AI-Generated Content

네 번째 장점은 AI 인프라 확장 기반이에요. 공공 영역에서도 생성형 AI, 데이터 분석, 지능형 민원 서비스처럼 AI를 활용하는 업무가 빠르게 늘면서, 가속기(GPU·NPU)와 고성능 네트워크, 대용량 데이터 처리를 아우르는 인프라가 필요해지고 있어요.

kt cloud PLATFORM은 이를 위해 GPU·NPU 서버 서비스를 제공하고, RAG 구축에 필요한 다양한 API를 모아 제공하는 AI Foundry 'RAG Suite'까지 갖추고 있어요. 공공기관은 인프라를 일일이 조합하지 않고도 AI 서비스에 필요한 컴퓨팅 자원과 RAG 파이프라인 구성 요소를 플랫폼 안에서 함께 활용할 수 있죠.

AI 워크로드는 학습과 추론 단계에 따라 필요한 자원 특성이 달라지는 만큼, 상황에 맞게 자원을 구성하고 확장할 수 있어야 해요. kt cloud PLATFORM은 이런 특성을 고려해 AI 수요가 늘어날 때 필요한 만큼 가속기 자원과 관련 서비스를 유연하게 확장할 수 있도록 지원하죠.

마치며

Image: AI-Generated Content

공공기관에게 클라우드 전환은 늘 안정성을 지키는 일과 새로운 서비스로 나아가는 일 사이의 고민이었어요. kt cloud PLATFORM은 이 둘을 양자택일이 아니라 함께 풀어가도록 설계됐어요. 고가용성부터 자원 확장, 보안, AI 인프라까지 단일 UI에서 통합 관리할 수 있어, 운영 부담은 줄이고 변화에 대한 대응은 더 빨라지죠.

공공 클라우드의 요구가 빠르게 넓어지는 지금, 그 변화를 담아낼 차세대 운영 기반. kt cloud PLATFORM과 함께 다음 단계를 준비해 보세요.

자주 묻는 질문 FAQ

Q 어떻게 kt cloud PLATFORM은 공공 클라우드 환경에서 서비스 연속성을 높이나요?

A kt cloud PLATFORM은 멀티 리전·멀티 AZ 구조를 기반으로 인프라를 분산 구성합니다. 고객 서비스가 멀티 AZ 구조로 설계·배치되면 특정 데이터센터나 가용 영역에 장애가 발생해도 서비스 영향을 줄일 수 있습니다. 또한 서울·경북 멀티 리전 구조를 적용해 지역 단위 장애나 재해복구 요구에도 대응할 수 있는 기반을 제공합니다.

관련 / 출처 REFERENCES

https://gcloud.kt.com/business/kcp

↗

기술 블로그 (Tech) | kt cloud

[구축사례] kt cloud PLATFORM Observability Alert 플랫폼 구축하기

1. 왜 Observability Alert 플랫폼을 직접 만들었나 — 문제의 출발점

2. 전체 아키텍처

3. 주요 설계 결정

결정 1. 조직별 Alert 격리는 Namespace Prefix 방식으로 구현

결정 2. 통합관제 연계를 위해 Label 체계를 표준화

결정 3. Alert 이벤트 저장 시 Loki 카디널리티를 낮게 유지

결정 4. Rule 조회는 PostgreSQL First 전략으로 처리

4. 운영하면서 배운 것들

Alert 시스템은 알림 발송 도구가 아니라 운영 정책 시스템이다

Label 설계가 Alert 품질을 결정한다

오픈소스로 SaaS 수준 운영 체계 구현 가능성 확인했다

5. 마무리

?› 자주 묻는 질문 FAQ

[AI활용] Claude 실무편 - kt cloud VM에서 PR 리뷰 자동화하기

1. 들어가며 — PR 리뷰는 왜 항상 병목이 되는가

2. 문제 정의 — PR 리뷰의 본질적인 한계

3. 접근 전환 — AI는 판단하지 않는다

4. 왜 kt cloud VM 위에 직접 만들었는가

5. 전체 구조 — PR Review Bot은 어떻게 동작하는가

6. PR Review Agent 아키텍처

7. 아키텍처 규칙을 코드로 정의한다

7.1. 리뷰 기준은 존재하지만 실행되지 않는다

7.2. 규칙을 실행 대상으로 바꾼다

7.3. PR 리뷰는 규칙을 실행하는 과정이 된다

7.4. 리뷰 기준이 팀 자산이 된다

7.5. 왜 이 방식이 중요한가

8. 운영 구성 — 실제 실행 환경

8.1. 실행 환경 — kt cloud VM 기반 운영

8.2. poller 구조 — “이벤트 기반”이 아닌 “지속 감지 방식”

8.3. tmux — 장기 실행을 위한 핵심 구성

8.4. 로그 관리 — 운영 시스템의 필수 요소

8.5. 운영 관점에서의 핵심 설계 포인트

9. 효과 — PR 리뷰의 출발점이 바뀐다

10. 권장 협업 모델

10.1. Bot의 역할 — 반복 검증의 자동화

10.2. 사람 리뷰어의 역할 — 맥락 기반 판단

10.3. 조직 관점에서의 효과

11. 정리 — 없으면 만드는 것도 기술력이다

결론 — PR 리뷰는 실행 시스템이 된다

❔자주 묻는 질문 FAQ

[사례연구] 사내 개인용 개발환경 이미지 실험기 2부: 만들면서 마주친 것들과 풀어간 방법

1. 부팅마다 바뀌는 IP 자동 복구

2. GitOps 적용 — helm install에서 HelmRelease + ArgoCD까지

1단계 — 단일 VM 환경 제약에 values 맞추기

2단계 — Flux HelmRelease로 git 변경 자동 반영

3단계 — ArgoCD 추가

3. Git 레포와 이미지에 자격증명을 평문으로 두지 않게

AVP에서 ESO로 옮긴 이유

결과 — 평문이 사라진 경로들

그래도 남는 자격증명 하나

4. 마치며

❔자주 묻는 질문 FAQ

[AI활용] Claude 실무편 - Technical Writer Skill 만들기

들어가며 — 왜 용어는 항상 틀릴까

문제 정의 — Technical Writer 업무는 왜 병목이 되는가

접근 전환 — 문서를 데이터로 바라보는 순간

실행 구조 — Technical Writer Agent의 등장

Skill 구조 — 정책을 코드로 만든다는 의미

자동화 범위 — 어디까지 가능한가

효과 — 단순한 효율이 아닌 구조의 변화

핵심 인사이트 — Technical Writing을 실행 가능한 구조로 전환한다는 것

결론 — AI는 생산성을 증폭시키는 구조로 활용된다

❔자주 묻는 질문 FAQ

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

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

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

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

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

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

앞으로

?› 자주 묻는 질문 FAQ

[기술동향] LLM 추론 최적화 핵심 기술: 양자화, KV 캐시, 추론 칩

1. 양자화: 제한된 인프라에서 거대 모델을 깨우는 법

2. 에이전트의 발목을 잡는 '단기 기억', KV 캐시 병목

3. TurboQuant: 모델이 아닌 '기억' 자체를 압축하다

4. 추론의 시대가 왔음을 증명하다: 추론 전용 하드웨어의 부상

Groq LPU (Language Processing Unit)

Google TPU (Tensor Processing Unit)

자주 묻는 질문 FAQ

자주 묻는 질문 FAQ

자주 묻는 질문 FAQ

자주 묻는 질문 FAQ

자주 묻는 질문 FAQ

자주 묻는 질문 FAQ

자주 묻는 질문 FAQ