기술 블로그 (Tech) | kt cloud 최신 글

[프로모션] kt cloud Backup 소산 서비스 프로모션

케클s피드 10월호｜기술 경쟁력, 보이지 않는 곳에서 결정된다

table { border-collapse: collapse; border: 0; border-spacing: 0; margin: 0; } div, td { padding: 0; } div { margin: 0 !important; } ul, li { margin: 0; } 96 @media screen and (max-width: 460px) { .stb-two-col .stb-column { max-width: 100% !important; } } @media screen and (min-width: 461px) { .stb-two-col .stb-column { max-width: 50% !important; } } @media screen and (max-width: 640px) { img.stb-justify { width: 100% !important; } } .stb-one-col p, .stb-two-col p { margin: 0px !important; } AI 서비스의 성능과 안정성은 어디에서 결정될까요? 고성능 GPU와 AI 모델도 중요하지만, 방대한 데이터를 빠르게 전달하는 네트워크와 효율적인 인프라 운영, 장애에 대비하는 기술도 필요합니다. 우리가 사용하는 AI 서비스에는 이처럼 다양한 인프라 기술이 활용되고 있습니다. 케클s피드 10월호에서는 KT AI 데이터센터 광고를 시작으로 공공 DR 전략과 BIM·AIOps 기반의 데이터센터 구축·운영 사례를 소개합니다. 안산·청라 AI 데이터센터 구축 소식과 버티브 기술 협력, 피지컬 AI에 필요한 GPU 인프라까지 다양한 소식도 준비했습니다. AI 서비스를 안정적으로 구현하고 운영하기 위한 기술과 전략, 이번 케클s피드에서 만나보세요. --> 대한민국의 미래를 만드는 KT AI 데이터센터 AI 서비스가 확산될수록 방대한 데이터를 안정적으로 처리하고 전달하는 인프라의 중요성도 높아지고 있습니다. KT그룹은 25년간 축적한 데이터센터 운영 경험과 전국 통신 국사 기반의 AI Edge 인프라를 활용해 AI 인프라 경쟁력을 강화하고 있습니다. 데이터센터와 AI Edge 인프라가 어떻게 연결되어 대한민국의 미래 산업을 뒷받침하는지, [KT AI 데이터센터] 편 광고에서 확인해 보세요. AI 경쟁력, 어디서 시작될까? --> 예상치 못한 장애나 재해에도 공공 서비스를 안정적으로 유지하려면? 서비스 중요도와 복구 목표에 따른 재해복구(DR) 전략을 살펴봅니다. 예상치 못한 장애나 재해가 발생하면 중요한 공공 서비스를 어떻게 복구해야 할까요? 공공 정보시스템의 중요도에 따른 복구 기준이 구체화되면서, 데이터 백업뿐만 아니라 실제 서비스를 신속하게 복구하고 정상화하는 역량이 중요해지고 있습니다. 이번 케클러 인터뷰에서는 Cloud컨설팅팀 김광배 팀장과 함께 시스템 중요도와 복구 목표에 따른 DR 전략, Multi-AZ·Multi-Region을 활용한 kt cloud PLATFORM의 서비스 연속성 확보 방안을 알아봅니다. 백업만으로 서비스를 지킬 수 있을까? --> AI 기반 운영 도구와 BIM 기술을 활용해 데이터센터의 구축·운영 효율을 높이는 kt cloud의 혁신 사례를 소개합니다. 데이터센터의 구축과 운영, AI 기술을 활용하면 무엇이 달라질까요? kt cloud는 이번 웨비나에서 현장 운영자가 직접 AI 분석·예측 도구를 개발하는 AIDC Ops Studio와 BIM 기반의 설계·시공 관리 사례를 소개했습니다. 운영 데이터를 분석해 설비 이상에 선제적으로 대응하고, 3D 모델과 AR 기술로 설계 오류를 사전에 확인하는 등 데이터센터의 효율성과 안정성을 높이는 방법을 웨비나 영상에서 만나보세요. --> 데이터센터 운영 혁신 사례 알아보기 --> 안산 AI 데이터센터 착공부터 청라 AI 데이터센터 구축 참여까지, kt cloud가 수도권 AI 인프라 공급 확대에 속도를 내고 있습니다. kt cloud가 안산 AI 데이터센터 착공과 청라 AI 데이터센터 구축 참여를 통해 수도권 AI 인프라 공급 기반을 확대합니다. 안산에는 2029년 준공을 목표로 액체냉각

[케클러 인터뷰 시리즈] #6 - 백업만으로는 부족하다, 공공 DR의 새로운 기준

.ktc-poster img { transition: transform .3s ease, box-shadow .3s ease; } .ktc-poster:hover img { transform: translateY(-4px); box-shadow:0 10px 22px rgba(0,154,135,0.22) !important; } .imageblock img { max-width:100% !important; height:auto !important; } .ktc-summary-body p { margin:0 !important; color:#3f5158 !important; font-size:1rem !important; line-height:1.75 !important; } @media (max-width: 768px) { .ktc-author-box { height:80px !important; min-height:80px !important; border-radius:14px !important; box-shadow:0 10px 24px rgba(0,120,106,0.24) !important; } .ktc-author-box td { height:80px !important; min-height:80px !important; padding-left:20px !important; padding-right:20px !important; } .ktc-author-summary-gap { height:18px !important; line-height:18px !important; } .ktc-summary-title { padding-left:20px !important; padding-right:20px !important; } .ktc-summary-body { padding-left:20px !important; padding-right:20px !important; } .ktc-section-title { font-size:1.1rem !important; margin:28px 0 14px !important; } .ktc-ref-wrap { padding:18px 20px !important; border-radius:14px !important; } .ktc-poster-wrap { gap:12px !important; margin:28px auto 10px !important; } } @media (max-width: 480px) { .ktc-author-box { height:70px !important; min-height:70px !important; border-radius:12px !important; } .ktc-author-box td { height:70px !important; min-height:70px !important; padding-left:16px !important; padding-right:16px !important; } .ktc-author-summary-gap { height:16px !important; line-height:16px !important; } .ktc-author-brand { font-size:0.66rem !important; letter-spacing:0.12em !important; } .ktc-author-name { font-size:0.95rem !important; } .ktc-summary-title { padding-left:15px !important; padding-right:15px !important; } .ktc-summary-body { padding-left:15px !important; padding-right:15px !important; } .ktc-summary-head { display:block !important; } .ktc-summary-label { display:inline-flex !important; margin-bottom:8px !important; } .ktc-summary-en { disp

[기술해설] 데이터센터를 지키는 마지막 방어선, 소방 설비에 대하여

kt cloud DC동부운용팀 이민재 님 요약 SUMMARY 이 글에서는 데이터센터 화재 예방을 위한 감지기·수신기·스프링클러·가스계 소화설비의 역할과 설계·시공 원리를 다룹니다. 배터리 열폭주 대응과 소방설비 점검·운영을 통해 서비스 연속성을 확보하기 위한 관리 사항을 정리합니다. #데이터센터소방 #화재감지 #가스계소화설비 #준비작동식스프링클러 #배터리열폭주 불은 3분 만에 잡혔지만, 서비스는 그렇지 않았습니다 2022년 10월 15일 오후, 판교의 한 데이터센터 지하 3층 전기실의 UPS용 리튬이온 배터리 랙에서 스파크가 발생했습니다. 화염 자체는 비교적 빠르게 잡혔지만, 우리가 기억하는 것은 그 몇 시간이 아니라 국민 메신저가 며칠간 멈춰버린 그 주말입니다. 배터리 화재를 진압하려면 전력을 차단해야 했고, 전력이 끊긴 서버는 살아남을 방법이 없었습니다. 발화 지점 바로 위 천장으로 서버 연결 케이블이 지나가고 있었다는 지적도 나왔습니다. 불이 아니라 화재 대응 그 자체가 서비스를 멈춘 것입니다. 3년 뒤인 2025년 9월 26일 대전 국가정보자원관리원에서도 같은 계열의 사고가 반복됐습니다. UPS용 리튬이온 배터리를 이설하기 위해 케이블을 분리하던 중 스파크가 열폭주로 이어졌고, 배터리팩 수백 개가 소실되며 정부 업무 시스템 수백 개가 장시간 멈췄습니다. 두 사건의 공통점은 명확합니다. 발화점은 서버가 아니라 배터리였고, 피해를 키운 것은 화염이 아니라 정전과 열, 그리고 대응 과정이었습니다. 데이터센터의 소방설비를 '법에서 요구하니까 다는 것'이 아니라 가용성(Availability) 설비의 일부로 봐야 하는 이유가 여기에 있습니다. < 2022 데이터센터 화재로 인한 메신저 시스템 장애 > www.ytn.co.kr 주요 소방시설의 역할 및 종류 법에서 말하는 소방시설은 다섯 갈래입니다 소방 관련 법령은 소방시설을 소화설비, 경보설비, 피난구조설비, 소화용수설비, 소화활동설비의 다섯 가지로 나눕니다. 이 중 '소화활동설비'는 이름과 달리 불을 끄는 설비가 아니라 소방관이 활동하기 위한 설비입니다. 연결송수관, 제연설비, 비상콘센트, 무선통신보조설비가 여기 속하는데, 지하 전기실에서 무전이 터지지 않으면 소방대는 눈과 귀가 없는 상태로 진입해야 합니다. 데이터센터는 '공간별로' 소방을 설계합니다 같은 건물 안이라도 지켜야 할 대상이 다르면 설비도 달라집니다. 데이터센터 소방 설계의 핵심은 여기에 있습니다. 서버실: 최우선 원칙은 수손(水損) 회피입니다. 감지는 공기흡입형 조기감지설비로 극초기에, 소화는 물을 쓰지 않는 가스계 소화설비로 처리합니다. 스프링클러는 법정 설치 대상이지만 배관에 물이 없는 준비작동식(Pre-action)을 채택해 오방수를 원천 차단합니다. UPS실·배터리실: 데이터센터 화재 통계의 단골 발화 지점입니다. 최근에는 전기실과 배터리실을 방화 격벽으로 분리하고, 가스계보다 냉각 능력이 있는 수계 설비를 함께 두는 방향으로 설계가 바뀌고 있습니다. 발전기실·연료탱크: 비상발전기 옆에는 수천~수만 리터의 경유가 저장됩니다. 유류화재(B급)에 맞는 포(Foam)소화설비나 가스계, 그리고 방유제와 방화구획이 필요합니다. 사무공간·주차장: 일반 건축물과 동일하게 스프링클러와 옥내소화전, 피난설비가 적용됩니다. 즉 데이터센터 소방은 하나의 시스템이 아니라 공간마다 목적이 다른 여러 시스템의 조합입니다. < 소방설비의 역할 및 종류 > AI 이미지 생성 소방시설의 원리: 감지에서 방출까지 ① 감지기 — 데이터센터에서는 일반 감지기로 부족합니다 감지기는 무엇을 감지하느냐에 따라 열감지기(차동식·정온식), 연기감지기(광전식·이온화식), 불꽃감지기로 나뉩니다. 차동식은 온도의 '상승 속도'를, 정온식은 '절대 온도'를 봅니다. 문제는 서버실 환경입니다. 항온항습기(CRAH)가 초당 수 m/s의 기류를 만들어내는 공간에서는 연기가 발생해도 즉시 희석·확산되어 천장 감지기에 도달할 농도가 만들어지지 않습니다. 일반 감지기만 믿으면 이미 상당히 진행된 뒤에야 경보가 울립니다. 그래서 데이터센터는 공기흡입형 감지

[인사이트] AI 트랜스포메이션의 진짜 병목은 어디인가? 네트워크 인프라가 맞이한 거대한 지각변동

kt cloud 그룹사업기획팀 변세림 님 요약 SUMMARY 이 글에서는 AI 학습·추론 트래픽의 특성과 분산 학습 네트워크, WAN·DCI 아키텍처, JCT 기반 성능 평가를 다룹니다. 데이터 전송과 통신 병목을 줄이기 위한 AI 네트워크 설계의 핵심 고려사항을 정리합니다. #AI네트워크 #분산학습 #RoCEv2 #WAN #JCT 엔터프라이즈 환경에서 클라우드 전환과 AI 도입 프로젝트를 진행할 때 가장 많은 예산과 논의가 집중되는 영역은 단연 컴퓨팅 인프라입니다. 고성능 GPU의 확보 수량이나 GPU 클러스터의 전체 연산 능력(TFLOPS) 등이 주로 핵심 평가지표로 다루어집니다. 그러나 시스템 아키텍처를 설계하고 클라우드 랜딩존(Landing Zone)을 구성하는 엔지니어 관점에서 볼 때, 실제 병목과 인프라 측면의 과제는 GPU 서버의 가동 이후 본격적인 데이터 파이프라인을 구동하는 시점부터 시작됩니다. 아무리 연산 성능이 뛰어난 GPU 클러스터를 구축했더라도, 데이터가 이동하는 경로인 네트워크 인프라의 대역폭과 신뢰성이 뒷받침되지 못하면 하드웨어 자원의 잠재력을 온전히 활용할 수 없기 때문입니다. Cisco의 최신 'AI Network Traffic Report' 분석에 따르면, AI 워크로드는 단순히 처리하는 트래픽의 총량을 증가시키는 것에 그치지 않고 트래픽이 가진 구조적 성질 자체를 근본적으로 변화시키고 있습니다. Image: AI-Generated Content 1. AI는 왜 기존 네트워크 상식을 깨는가 전통적인 클라우드 환경의 네트워크 설계는 '통계적 다중화(Statistical Multiplexing)' 원칙을 기반으로 발전해 왔습니다. 웹 서비스, API 호출, 데이터베이스 쿼리 등은 수많은 사용자가 각기 다른 시간에 비교적 작은 크기의 데이터를 주고받는 형태입니다. 이러한 트래픽은 상호 간섭이 적고, 패킷 유실이 발생하더라도 TCP 혼잡 제어 알고리즘을 통해 자연스럽게 재전송 및 복구가 가능하므로 사용자 경험에 미치는 영향이 제한적입니다. 반면, AI 인프라가 유발하는 트래픽은 대규모 학습 단계와 실시간 추론 단계 전반에서 기존의 네트워크 설계 기준을 상회하는 요구사항을 가집니다. A. 데이터 인제스트 및 분산 학습 단계 — 대역폭 포화와 무손실 환경 요구 AI 모델 학습을 위해 수십에서 수백 테라바이트(TB)에 이르는 데이터셋을 스토리지에서 GPU 클러스터로 전송하는 단계는 전형적인 대용량 지속 트래픽(Bulk Transfer)의 형태를 띱니다. 기존 엔터프라이즈 환경에서 주로 사용되는 10G 또는 40G 대역폭의 전용 회선은 이 트래픽이 진입하는 순간 즉시 포화 상태에 도달하게 되며, 동일한 대역폭을 공유하는 일반 비즈니스 시스템의 대기 시간을 급격히 증가시키는 요인이 됩니다. 더욱 엄격한 관리가 필요한 영역은 분산 학습 단계입니다. 수백 대의 GPU 노드가 연산 결과인 가중치(Weight)를 실시간으로 교환하고 동기화(All-Reduce 통신)하는 내부망 트래픽은 미세한 패킷 손실도 허용하지 않는 구조를 가집니다. 패킷 드롭이 단 하나만 발생하더라도 나머지 전체 GPU 노드가 해당 데이터가 재전송되어 도달할 때까지 연산을 멈추고 대기하는 '낙오자 현상(Straggler Problem)'이 발생하기 때문입니다. 막대한 비용이 소요되는 GPU 자원의 공회전을 방지하기 위해, 분산 학습 환경에서는 RoCEv2(RDMA over Converged Ethernet) 프로토콜에 PFC(Priority-based Flow Control) 및 ECN(Explicit Congestion Notification)을 조합한 무손실 이더넷 패브릭이나 인피니밴드(InfiniBand) 기반의 전용 네트워크 아키텍처가 필수적으로 요구됩니다. B. 추론(Inference) 단계 — 장기 지속 흐름과 비대칭적 트래픽 구조 사용자의 요청에 응답하는 추론 단계의 트래픽은 학습 단계와는 또 다른 기술적 과제를 제시합니다. Cisco 보고서에 따르면, AI 추론 트래픽은 토큰을 순차적으로 생성하여 출력하는 연산 특성으로

[트렌드 리포트] AI로 데이터센터를 운영하는 시대, 현장은 얼마나 준비됐을까?

.ktc-poster img { transition: transform .3s ease, box-shadow .3s ease; } .ktc-poster:hover img { transform: translateY(-4px); box-shadow:0 10px 22px rgba(0,154,135,0.22) !important; } .imageblock img { max-width:100% !important; height:auto !important; } .ktc-summary-body p { margin:0 !important; color:#3f5158 !important; font-size:1rem !important; line-height:1.75 !important; } @media (max-width: 768px) { .ktc-author-box { height:80px !important; min-height:80px !important; border-radius:14px !important; box-shadow:0 10px 24px rgba(0,120,106,0.24) !important; } .ktc-author-box td { height:80px !important; min-height:80px !important; padding-left:20px !important; padding-right:20px !important; } .ktc-author-summary-gap { height:18px !important; line-height:18px !important; } .ktc-summary-title { padding-left:20px !important; padding-right:20px !important; } .ktc-summary-body { padding-left:20px !important; padding-right:20px !important; } .ktc-section-title { font-size:1.1rem !important; margin:28px 0 14px !important; } .ktc-ref-wrap { padding:18px 20px !important; border-radius:14px !important; } .ktc-poster-wrap { gap:12px !important; margin:28px auto 10px !important; } } @media (max-width: 480px) { .ktc-author-box { height:70px !important; min-height:70px !important; border-radius:12px !important; } .ktc-author-box td { height:70px !important; min-height:70px !important; padding-left:16px !important; padding-right:16px !important; } .ktc-author-summary-gap { height:16px !important; line-height:16px !important; } .ktc-author-brand { font-size:0.66rem !important; letter-spacing:0.12em !important; } .ktc-author-name { font-size:0.95rem !important; } .ktc-summary-title { padding-left:15px !important; padding-right:15px !important; } .ktc-summary-body { padding-left:15px !important; padding-right:15px !important; } .ktc-summary-head { display:block !important; } .ktc-summary-label { display:inline-flex !important; margin-bottom:8px !important; } .ktc-summary-en { disp

[현장 스케치] AI 데이터센터의 미래를 만나다! - Tech Week Singapore 2026

kt cloud 마케팅커뮤니케이션팀 님 요약 SUMMARY 이 글에서는 Tech Week Singapore 2026 현장에서 소개된 AI 데이터센터의 액체냉각, 모듈형 설계, 전력 인프라와 운영 자동화 기술을 다룹니다. 데이터센터의 구축·확장에 필요한 전력·부지·투자 조건과 전문 인력의 중요성을 정리합니다. #TechWeekSingapore2026 #AI데이터센터 #액체냉각 #모듈형데이터센터 #데이터센터전력 안녕하세요! kt cloud 마케팅커뮤니케이션팀 입니다. ‍♂️ AI 기술이 빠르게 발전하면서 이를 뒷받침하는 데이터센터의 모습도 달라지고 있습니다. 더 많은 전력을 안정적으로 공급하고, 고성능 GPU에서 발생하는 열을 효과적으로 식히는 것은 물론, 필요한 인프라를 얼마나 빠르게 구축할 수 있는지도 중요해지고 있죠. 그런데 데이터센터의 변화가 기술에만 머무르는 것은 아니에요. AI 인프라 수요가 늘어날수록 전력과 부지를 확보하는 일부터 투자, 전문 인력 양성까지 함께 고민해야 할 과제도 많아지고 있거든요. 그렇다면 글로벌 기업들은 이러한 변화에 어떻게 대응하고 있을까요? 이 궁금증을 안고 kt cloud 임직원들이 싱가포르에서 열린 Tech Week Singapore 2026을 찾았습니다. 아시아의 주요 기술 전시·컨퍼런스 중 하나인 이번 행사에서는 글로벌 기업들이 선보인 최신 데이터센터 기술과 함께 AI 시대를 준비하는 산업의 다양한 움직임을 살펴볼 수 있었는데요. 모듈형 데이터센터와 액체냉각 기술을 직접 살펴볼 수 있었던 전시장부터 데이터센터의 미래를 이야기한 글로벌 전문가들의 발표까지! kt cloud 참관단이 싱가포르 현장에서 직접 보고 느낀 이야기들을 지금부터 생생하게 전해드릴게요! 아시아의 기술 트렌드가 모인 곳, Tech Week Singapore 2026 싱가포르 마리나 베이 샌즈에서 열린 Tech Week Singapore 2026! 행사장 곳곳에는 글로벌 기업들이 준비한 다양한 전시 부스가 마련돼 있었고, 최신 기술을 살펴보려는 참관객들로 활기가 넘쳤습니다. 올해 행사의 주제는 'The Infrastructure Era(인프라 시대)'였습니다. AI와 클라우드 기술이 빠르게 발전하는 만큼, 이를 뒷받침하는 인프라의 중요성도 커지고 있다는 의미였는데요. 실제 전시장에서도 이러한 흐름을 곳곳에서 확인할 수 있었어요. 행사 규모도 상당했습니다. 주최 측 발표에 따르면 약 3만 8,000명의 참가자와 720개 국제 전시 참가사가 함께했으며, 250개 이상의 키노트와 패널 세션이 진행됐다고 해요. Tech Week Singapore 2026 한눈에 보기 공식 행사명: Tech Week Singapore 2026 일정: 2026년 9월 29~30일 장소: 싱가포르 마리나 베이 샌즈, Sands Expo & Convention Centre 주제: The Infrastructure Era 동시 개최 행사: Data Centre World Asia, Cloud & AI Infrastructure Asia, Big Data & AI World Asia, Cyber Security World Asia, DevOps Live! 주요 분야: AI 데이터센터, 클라우드·AI 인프라, 전력·냉각, 빅데이터, 사이버보안, DevOps, 인프라 운영 자동화 이번 행사는 다섯 개의 전문 전시·컨퍼런스가 동시에 열리는 만큼 볼거리도 풍성했는데요. 그중에서도 kt cloud 참관단이 특히 관심 있게 살펴본 곳은 바로 Data Centre World Asia였습니다. 전시장에서는 글로벌 데이터센터 기업들이 선보인 다양한 기술과 솔루션을 가까이에서 살펴볼 수 있었어요. 실제 전력·냉각 설비를 전시하거나 시연 장비를 선보이는 부스부터 거대한 데이터센터의 구조를 정교한 모형으로 구현한 전시까지! 평소 사진이나 자료로 접하던 기술들을 직접 눈으로 확인할 수 있다는 점이 특히 흥미로웠습니다. 그렇다면 수많은 전시 부스 가운데 kt cloud 참관단의 눈길을 사로잡은 기술은 무엇이었을까요? 지금부터 전시장에서 직접 살펴본 주요 기술과 솔루션

[분석] AI 데이터센터 냉방 시스템의 Fail-Safe: 마지막 방어선 래칭릴레이

kt cloud DC서부운용팀 서동진 님 요약 SUMMARY 이 글에서는 AI 데이터센터 냉방 시스템에서 발생하는 정전과 PLC 제어신호 소실의 차이, 래칭릴레이를 활용한 Fail-Safe 설계를 다룹니다. 냉방설비의 동시 정지를 예방하기 위한 접점 상태 유지 원리와 제어 안정성의 중요성을 정리합니다. #AI데이터센터 #데이터센터냉방 #FailSafe #래칭릴레이 #PLC AI 데이터센터, 냉방이 멈추면 안 되는 이유 AI 데이터센터는 기존 데이터센터와 근본적으로 다른 부하 특성을 가진다. GPU 클러스터는 고집적으로 군집화되어 있고, 랙당 발열 밀도가 기존 서버 대비 압도적으로 높다. 이런 환경에서 냉방설비가 단 몇 분이라도 정지하면, 서버의 써멀 히트(thermal heat)는 순식간에 임계치를 넘어선다. 과거의 저밀도 데이터센터에서는 냉방 중단이 수십 분의 대응 시간을 허용했다면, 지금의 AI 데이터센터에서는 그 시간이 훨씬 짧다. 그래서 AI 데이터센터 운영에서 가장 중요한 전제는 단 하나다. "냉방설비 전체가 동시에 셧다운되는 상황은 절대로 발생해서는 안 된다." 이 전제를 지키기 위해서는, 냉방설비가 한꺼번에 멈출 수 있는 모든 원인을 찾아내고 각각에 대한 대응책을 마련해야 한다. 그리고 그 원인은 크게 두 가지로 나뉜다. 원인 1 — 정전 (한전 전원 상실) 고압을 사용하는 칠러(chiller)는 구조적으로 UPS 전원 공급이 어렵다. 그래서 대부분의 데이터센터는 칠러에 한전 상용전원을 그대로 사용한다. 이 말은 곧, 한전 정전이 발생하면 칠러를 포함한 냉방설비가 일제히 정지한다는 뜻이다. 다행히 이 시나리오는 이미 잘 알려져 있고, 대응 체계도 표준화되어 있다. 정전이 발생하면 비상발전기가 기동하여 전원을 공급하고, 냉방설비는 자동으로 재기동하며 서비스를 이어간다. 정전 대응은 데이터센터 설계의 기본이자 오래된 숙제이기 때문에, 발전기 용량 설계·기동 시퀀스·부하 순차 투입 같은 개념이 이미 성숙해 있다. 원인 2 — 시그널 페일 (Signal Fail) 문제는 정전이 아닌데도 냉방설비 전체가 동시에 멈추는 두 번째 시나리오다. 바로 냉동기 운전 명령 시그널이 일제히 소실되는 경우다. 칠러, 펌프, 전동밸브 등 냉방 계통의 기계설비 대부분은 디지털 신호(Dry Contact)로 원격 운전/정지 제어를 받는다. 이 방식은 가정집 스위치와 원리가 비슷하다. 다만 사람이 손으로 켜고 끄는 대신, 전기적인 힘으로 접점을 붙였다 뗐다 하는 것이다. 문제는 여기서 발생한다. 이 전기적 힘 자체에 문제가 생기면, 즉 신호를 유지시키는 전원이나 로직이 어떤 이유로든 흔들리면, 접점은 자동으로 꺼진다. 그리고 이 신호에 종속된 모든 장비 — 밸브, 펌프, 냉동기 — 가 한꺼번에 정지해 버린다. 이 시나리오가 무서운 이유는, 정전과 달리 원인이 훨씬 다양하고 예측하기 어렵다는 데 있다. PLC의 불특정 오류, 통신 이상, 로직 리셋 등 여러 원인이 동일한 결과, 즉 "신호 소실"로 이어질 수 있다. 대응책도 마땅치 않다. 보통은 PLC를 리부팅하면 해결되지만, 리부팅 이후에도 PLC 자체의 에러가 해소되지 않는 경우에는 뾰족한 수가 없다. Fail-Safe의 핵심 — 래칭릴레이(Latching Relay) 이 시그널 페일 문제를 근본적으로 해결하기 위해 고안된 것이 바로 래칭릴레이다. 일반적인 릴레이는 전기적 힘이 가해지는 동안에만 접점 상태를 유지한다. 전원이 빠지면 접점도 함께 풀린다. 반면 래칭릴레이는 한 번 상태가 바뀌면, 그 상태를 기계적으로 유지한다. 즉 신호를 한 번만 순간적으로 인가해주면(펄스 제어), 그 이후 전기적 힘이 사라져도 접점 상태는 그대로 유지된다. 이 펄스 제어 방식은 사실 0과 1로 이루어진 디지털 통신의 가장 원초적인 형태이기도 하다. 하지만 이 오래되고 단순한 원리가 기계 제어의 안전성 확보에는 오히려 가장 강력한 해법이 된다. 래칭릴레이를 PLC와 제어 대상 기기(칠러, 펌프, 밸브) 사이에 안전장치로 배치하면, PLC에서 발생하는 각종 불특정 장애가 발생하더라도 하위 기기들은 오동

[인사이트] 로봇은 왜 챗봇과 GPU 수요가 다를까? 피지컬 AI 시대의 인프라 전략

kt cloud AI사업개발팀 정소라 님 요약 SUMMARY 이 글에서는 피지컬 AI의 로봇 파운데이션 모델(RFM)이 요구하는 학습·시뮬레이션·엣지 추론 인프라와 GPU 수요 구조를 다룹니다. 제조 중심의 국내 활용 환경에서 데이터 확보와 단계별 컴퓨팅 인프라 설계가 갖는 의미를 정리합니다. #피지컬AI #로봇파운데이션모델 #GPU인프라 #로봇시뮬레이션 #엣지추론 로봇은 왜 챗봇보다 GPU를 더 먹을까 — 피지컬 AI 시대의 RFM… 젠슨 황의 두 번째 방한이 남긴 신호 1. 젠슨 황은 왜 7개월 만에 다시 왔나 2026년 6월 초, 젠슨 황 NVIDIA CEO가 다시 한국을 찾았습니다. 지난해 10월 경주 APEC, 이른바 '깐부치킨 회동'으로 GPU 26만 장 공급을 발표한 지 약 7개월 만입니다. 이번엔 공식 행사 없이 국내 파트너 기업만 겨냥한 순수 사업 목적 방문이었고, 회동 대상 기업만 아홉 곳이 넘었습니다. 주목할 건 방문의 '주제'가 달라졌다는 점입니다. 1차(2025.10): 반도체·메모리(HBM)·자율주행 동맹. 키워드는 GPU 공급량 2차(2026.06): 로보틱스·휴머노이드·제조 데이터. 키워드는 피지컬 AI 젠슨 황은 대만 GTC 타이베이(6월 1일) 무대에서 로보틱스를 한국과의 '다음 협력 축'으로 지목했고, 방한 기간에는 로봇이 배치된 현대차 사옥, 로봇 친화형 네이버 사옥, 로봇 계열사를 둔 두산 등을 동선에 넣었습니다. 무엇보다 그는 "피지컬 AI 구현에서 가장 어려운 과제는 데이터 확보"라고 못을 박기도 했습니다. 이 한마디가 이 글의 출발점입니다. 데이터가 병목이라는 말은, 곧 그 데이터를 만들어내기 위한 컴퓨팅이 새로 필요하다는 뜻이기 때문입니다. LLM과는 다른 종류의 GPU 수요가 여기서 생깁니다. 2. RFM이란 무엇인가 — LLM과 무엇이 다른가 RFM(Robot Foundation Model)은 한마디로 로봇 버전의 거대모델입니다. LLM이 '텍스트를 받아 텍스트를 내놓는' 모델이라면, RFM은 멀티모달을 말합니다. 입력: 카메라 영상(Vision) + 언어 지시(Language) + 센서·관절 상태 출력: 텍스트가 아니라 행동(Action) — 어느 관절을 몇 도 움직일지 즉 RFM은 '보고(Vision) → 이해하고(Language) → 움직이는(Action)' 루프를 하나의 모델로 통합한 구조입니다. 챗봇은 틀린 답을 내도 사용자가 다시 물어보면 되지만, 로봇은 틀린 '행동'을 하면 물리 세계에서 사고가 납니다. 그래서 RFM은 정밀도와 안정성의 요구 수준이 다르고, 그만큼 학습·검증 비용이 큽니다. Image: AI-Generated Content 3. 핵심: RFM은 '한 대'가 아니라 '세 대'의 컴퓨터를 쓴다 여기서 LLM과 RFM의 결정적 차이가 나옵니다. NVIDIA는 이를 '세 대의 컴퓨터(Three Computers)' 구조로 설명합니다. 단계 역할 대표 스택 GPU 성격 ① 학습 (Training) 대규모 멀티모달 모델 학습 DGX / B300·H200 초고밀도 분산학습 클러스터 ② 시뮬레이션·합성데이터 (Simulation) 가상 환경에서 학습 데이터 생성 Omniverse · Cosmos · RTX PRO 시뮬레이션·렌더링 워크로드 ③ 엣지 추론 (Edge Inference) 로봇에 탑재된 실시간 추론 Jetson · Thor 저전력 온디바이스 Image: AI-Generated Content LLM은 사실상 ①과 약식 추론만 씁니다. 텍스트 데이터는 인터넷에 차고 넘치니, 데이터를 '만드는' 단계가 거의 필요 없습니다. RFM은 ②가 필수입니다. 로봇이 현실에서 수백만 번 넘어지며 데이터를 모을 수는 없기 때문입니다. 그래서 Omniverse·Cosmos 같은 디지털 트윈/월드 모델 안에서 가상으로 데이터를 합성합니다. 바로 이 시뮬레이션 단계가 LLM에는 없던 새로운 대규모 GPU 수요를 만듭니다. 젠슨 황이 말한 "데이터가 가장 어렵다"는 문제를, NVIDIA는 'GPU로 데이터를 찍어내는' 방식으로 푸는 셈입니다. 정리하면, 같은 파라미

[기술해설] AI 질문 한 줄은 얼마나 많은 에너지를 쓸까? 데이터센터가 지능을 만드는 법

kt cloud DC글로벌고객팀 심재문 님 요약 SUMMARY 이 글에서는 AI 토큰 생성에 필요한 에너지와 데이터센터의 고밀도 GPU 랙 전력 공급, 직접액체냉각(DLC), PUE를 다룹니다. AI 인프라의 연산 효율과 안정적인 운영을 좌우하는 전력·냉각 설계의 중요성을 정리합니다. #AI데이터센터 #데이터센터전력 #GPU전력밀도 #액체냉각 #PUE 1. 디지털 언어의 화폐 '토큰'에 내재된 물리적 실체 대중에게 AI는 단순히 화면 위에 텍스트를 출력하는 소프트웨어에 불과하지만, 이를 지탱하는 하드웨어 엔지니어링 관점에서 AI는 '에너지를 지능으로 변환하는 변환기'입니다. 이 변환의 최소 입자가 바로 토큰(Token)입니다. 1.1 토큰화(Tokenization)와 연산 밀도 언어 모델(LLM)은 텍스트를 숫자의 나열인 벡터로 처리하기 위해 언어를 쪼개는 과정을 거칩니다. 한글은 영어보다 토큰화 과정이 복잡하며, 한 글자가 생성될 때마다 GPU 내 수천 개의 텐서 코어(Tensor Core)는 수조 번의 부동 소수점 연산을 수행합니다. 이 과정에서 발생하는 전자의 이동은 저항을 만나 열에너지로 변하며, 이는 고스란히 데이터센터 전력 계통에 부하로 작용합니다. 즉, 토큰은 데이터센터의 수전 용량을 소모시키는 '에너지 화폐'인 셈입니다. 1.2 1토큰의 에너지 등가성 추산 최신 하이퍼스케일 모델(예: Llama 3 70B 이상)을 구동한다고 가정할 때, 1개 토큰을 출력하기 위해 시스템 전체(IT 장비 및 냉각 설비 포함)에서 소모되는 전력은 약 0.003~0.005kWh로 추정됩니다. 이를 물리적 에너지 단위인 줄(Joule)이나 칼로리(cal)로 환산하면, 우리가 무심코 받는 한 문장의 답변이 실제로는 종이컵 하나 분량의 물을 끓일 수 있는 에너지를 소모하고 있음을 알 수 있습니다. 2. 30MW 데이터센터: 서울 도심의 열역학적 엔진룸 서울 가산, 상암 등지에 위치한 중대형 데이터센터의 수전 용량은 보통 22MW에서 30MW 사이입니다. 이 수치는 단순한 전력량이 아니라, 도시 전력망이 단일 건축물에 허용할 수 있는 공학적 임계점입니다. 2.1 30MW의 물리적 규모와 전력 인입 과정 30MW는 인구 10만 명 규모의 중소도시 전체가 사용하는 전력량과 맞먹습니다. 이 막대한 에너지를 한 건물로 집중시키기 위해 데이터센터는 한국전력 변전소로부터 154kV(154,000V) 초고압 전력을 직접 인입받습니다. 이 전기가 서버가 사용할 수 있는 전압으로 낮아지는 과정에서 발생하는 변압 손실과 유도열 또한 데이터센터가 해결해야 할 거대한 공학적 숙제입니다. 30MW 전력망의 1%만 손실되어도 300kW의 열이 발생하며, 이는 일반 빌딩 전체를 난방할 수 있는 수준입니다. 2.2 지능의 생산 한계점 30MW급 센터가 냉각 및 기타 손실(PUE)을 제외하고 순수하게 AI 연산에 투입할 수 있는 전력을 25MW라고 한다면, 이 센터는 이론적으로 초당 수백만 개의 토큰을 동시에 생산할 수 있는 '지능 발전소'가 됩니다. 그러나 이 발전소의 출력은 곧 '냉각 능력'에 의해 제한됩니다. 3. 랙당 80kW의 시대: 극한의 열 밀도와 공학적 필연성 과거 CPU 중심의 데이터센터는 랙당 전력 밀도가 5~10kW 수준이었습니다. 그러나 GPU 기반의 AIDC(AI Data Center)는 서버 한 대가 수 kW를 소모하며, 랙 하나에 서버를 실장했을 때 전력 밀도는 80kW까지 치솟습니다. 3.1 공랭식(Air Cooling)의 한계와 열역학적 모순 80kW는 좁은 캐비닛 하나에서 8만 와트의 열이 뿜어져 나온다는 뜻입니다. 공기는 비열(Specific Heat)이 매우 낮아 열을 실어 나르는 능력이 떨어집니다. 이 열을 공기로만 식히려면 태풍급의 풍량을 24시간 내내 쏴주어야 하며, 이 과정에서 팬(Fan)이 소모하는 전력이 서버가 쓰는 전력을 앞지르는 '냉각 역설'이 발생합니다. 3.2 버스웨이(Busway)와 고전류 공급 시스템 80kW의 전류를 일반적인 구리 케이블로 공급하려면 팔뚝 굵기 이상의 전선이 필요합니다. 전선 자체의

[현장 스케치] AI 인프라의 경쟁력은 '운영' - KubeCon China 2026

kt cloud 마케팅커뮤니케이션팀 요약 SUMMARY 이 글에서는 KubeCon China 2026 현장에서 소개된 GPU 자원 최적화, 분산 학습의 성능과 장애 복원력, AI 기반 운영 자동화 및 주요 전시 기술을 다룹니다. AI 인프라의 경쟁력이 하드웨어 확보뿐 아니라 자원 활용 효율과 안정적인 운영에 달려 있다는 현장 시사점을 정리합니다. #KubeConChina2026 #AI인프라 #GPU자원관리 #분산학습 #운영자동화 안녕하세요! kt cloud 마케팅커뮤니케이션팀 입니다. ‍♂️ AI 인프라 하면 가장 먼저 무엇이 떠오르시나요? 아마 많은 분이 GPU를 생각하실 텐데요. 더 많은 GPU와 더 빠른 네트워크를 확보하기 위한 경쟁이 치열해지면서 AI 인프라의 규모도 빠르게 커지고 있죠. 그런데 아무리 뛰어난 GPU를 갖췄더라도 제대로 활용하지 못한다면 어떨까요? 어떤 GPU는 사용되지 않은 채 대기하고, 다른 GPU는 자원이 부족해 작업을 시작하지 못할 수도 있어요. 심지어 일부 장비의 장애로 오랫동안 진행한 AI 학습이 중단되는 상황도 발생할 수 있죠. AI가 연구·개발을 넘어 실제 서비스로 확산되면서 이제는 얼마나 뛰어난 하드웨어를 확보했는가 못지않게, 확보한 자원을 얼마나 효율적이고 안정적으로 운영할 수 있는가가 중요한 과제로 떠오르고 있습니다. 이러한 기술의 변화를 직접 살펴보기 위해 kt cloud의 네트워크·클라우드·데이터 플랫폼·통합관제 분야 임직원들이 중국 상하이로 향했습니다. 바로 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026에 참석하기 위해서였는데요! 이번 현장 스케치에서는 참관단이 인상 깊게 들었던 네 가지 기술 세션부터 전시장에서 눈여겨본 AI 인프라 장비와 솔루션까지, 상하이에서 만난 이야기를 여러분과 함께 나눠보려고 해요. 과연 상하이 현장에서는 어떤 기술들이 주목받고 있었을까요? 함께 살펴보시죠! 클라우드 네이티브와 AI가 만난 상하이 지난 9월, 중국 상하이의 Shanghai International Convention Center에는 클라우드 네이티브와 오픈 인프라, AI 분야의 기술 전문가들이 한자리에 모였습니다. Cloud Native Computing Foundation(CNCF), OpenInfra Foundation, PyTorch Foundation이 함께한 대규모 기술 컨퍼런스가 열렸기 때문인데요. Kubernetes, OpenStack, PyTorch 등 주요 오픈소스 기술을 중심으로 다양한 발표와 전시가 진행되면서 AI 시대의 인프라가 어떤 방향으로 발전하고 있는지 살펴볼 수 있는 자리였어요. KubeCon China 2026 한눈에 보기 공식 행사명: KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 일정: 2026년 9월 7~9일 장소: 중국 상하이, Shanghai International Convention Center 주요 분야: 클라우드 네이티브, 오픈 인프라, AI 프레임워크, GPU·NPU, 분산 학습, 보안, 관측성, 운영 자동화 이번 행사에서 특히 흥미로웠던 건 익숙한 클라우드 기술들이 AI 인프라를 운영하는 데에도 중요한 역할을 하고 있다는 점이었어요. 기존에 서버와 애플리케이션을 관리하는 데 주로 활용되던 Kubernetes와 OpenStack이 이제는 대규모 GPU 자원을 관리하고, AI 학습과 추론 서비스를 뒷받침하는 기술로도 활용되고 있었거든요. 발표 주제도 상당히 구체적이었습니다. GPU를 어떻게 하면 더 효율적으로 나눠 사용할 수 있을지, 대규모 AI 학습 중 장애가 발생하면 어떻게 대응할지, 나아가 AI가 직접 운영 과정의 문제를 분석하고 해결을 도울 수 있을지까지! 실제 AI 인프라를 운영하는 과정에서 마주할 법한 고민들이 다양한 기술 사례로 소개되고 있었죠. 인상 깊었던 세션 — AI를 잘 운영하기 위한 이야기 이번 행사에서는 글로벌 기업들이 AI 인프

[분석] DDoS 환경에서 OVS kernel datapath 성능 붕괴

kt cloud 요약 SUMMARY 이 글에서는 DDoS 공격 시 Open vSwitch(OVS) 커널 데이터패스에서 발생하는 Upcall Storm, Mask Explosion, 캐시 스래싱의 원인과 성능 저하 구조를 다룹니다. eBPF/XDP 사전 필터링과 TC·하드웨어 오프로드, 운영 지표를 활용한 대응 방향을 정리합니다. #OVS #DDoS #KernelDatapath #UpcallStorm #XDP DDoS 공격 상황에서의 성능 붕괴 무작위 패턴의 DDoS 공격(예: 위조된 소스 IP 및 포트를 사용하는 SYN flooding attack)은 OVS datapath의 구조적 전제 조건을 직접적으로 타격합니다. OVS의 고성능은 트래픽의 locality에 의존하기 때문입니다. 이 locality가 깨지면 시스템은 연산 비용이 가장 높은 처리 경로로 강제 진입하게 됩니다. Upcall Storm (Slow-Path Resource Exhaustion) 무작위 DDoS 공격에서는 일반적으로 모든 패킷이 고유한 플로우(Flow)로 인식됩니다. 메커니즘: 무작위로 생성된 헤더는 기존 커널 플로우와 일치하지 않으므로, 모든 패킷이 플로우 미스(Flow Miss)를 유발합니다. 영향: 커널은 Generic Netlink를 통해 모든 패킷에 대해 유저스페이스ovs-vswitchd로 업콜(Upcall)을 실행해야 합니다. 이 과정에서 CPU 사이클은 패킷 포워딩이 아닌 문맥 교환(Context switching), 넷링크 직렬화, 유저스페이스 파이프라인 처리에 소모됩니다. 결과: 처리량(Throughput)이 초당 수백만 패킷(Mpps) 단위에서 수만 단위로 급락하며, 정상적인 트래픽 처리가 불가능해지고 네트워크 노드는 응답 불능 상태에 빠집니다. TSS Mask Explosion (Lookup Scaling Failure) 특정 공격 패턴을 차단하기 위해 OpenFlow 파이프라인에 완화 규칙을 설치하면, 커널의 와일드카드 매칭 복잡도가 증가합니다. 메커니즘: 매칭된 헤더 필드의 고유한 조합마다 커널의 mask_array에 새로운 항목이 필요합니다. 영향: TSS(Tuple Space Search)의 조회 시간 복잡도는 마스크의 개수를 N이라 할 때 $O(N)$입니다. 마스크의 개수가 늘어날수록 커널은 모든 패킷에 대해 전체 데이터패스에 걸쳐 더 많은 해싱과 메모리 비교 작업을 수행해야 합니다. 결과: 시스템 전체의 지연 시간(Latency)이 완화 규칙의 수에 비례하여 선형적으로 증가하며, 이는 성능 면에서 '이차적인 공격' 효과를 낳습니다. Cache Thrashing 및 최적화 실패 무작위 공격 시 OVS의 주요 패스트 패스(Fast-path) 최적화 기능들이 무력화됩니다. 마스크 캐시 실패: 모든 무작위 패킷마다 하드웨어 RSS(skb_hash)가 달라지기 때문에, CPU별 mask_cache의 O(1) 성공률이 0%에 가깝게 떨어집니다. 재균형 작업의 과부하(Rebalancing Churn): 백그라운드의 마스크 재균형기(Rebalancer)가 끊임없이 변하는 "핫(Hot)" 마스크의 우선순위를 정하느라 CPU 사이클을 낭비하게 됩니다. 이는 지속적인 캐시 무효화와 RCU 동기화 오버헤드로 이어집니다. 성능 저하 요약 (Summary of Performance Degradation) 구분 주요 원인 (Primary Cause) 성능 영향 (Performance Impact) 결과 (Result) 처리량 (Throughput) 업콜 스톰 (Upcall Storm) 유저스페이스 전환 오버헤드 발생 Mpps 단위에서 Kpps 단위로 급감 지연 시간 (Latency) 마스크 폭발 (Mask Explosion) TSS 조회 복잡도 증가 (O(N)) 규칙 수에 따른 선형적 지연 증가 자원 효율성 (Efficiency) 캐시 스래싱 (Cache Thrashing) 최적화 실패 및 RCU 동기화 오버헤드 데이터 처리 전 CPU 자원 고갈 기술적 배경 위에서 기술한 성능 저하 모드를 이해하기 위해서는, 특화된 캐싱 레이어로서의

[AI활용] AI가 만든 코드, 팀은 어떻게 관리하나?

kt cloud 그룹사업기획팀 변세림 님 요약 SUMMARY 이 글에서는 팀이 AI 생성 코드의 일관성과 보안을 위해 페르소나, SKILL.md, YAML 기반 Harness 검증 체계를 설계한 과정을 다룹니다. 코드 생성 이후의 검증 병목을 줄이기 위한 팀 규칙의 명문화와 자동 검증, 사람의 최종 판단 원칙을 정리합니다. #AI생성코드 #코드거버넌스 #SKILLmd #Harness #Terraform Image: AI-Generated Content 안녕하세요. 지난 글에서 AI 자동화의 진짜 문제는 "만드는 것"이 아니라 "유지하는 것"이라는 이야기를 나누었습니다. 그리고 그 전제 조건으로, 팀의 암묵지를 먼저 명문화해야 한다는 점도 강조했었죠. 그렇다면 실제 현업에서는 이를 어떻게 구현하면 될까요? 이번 글에서는 그 고민을 팀 단위로 확장했을 때 어떤 일들이 벌어지는지, 그리고 저희 팀이 어떤 시행착오를 거쳐 지금의 거버넌스 구조에 이르게 되었는지를 이야기해 보려 합니다. 1단계: 혼자 쓸 때는 괜찮았습니다 처음에는 로컬 환경에서 혼자 AI를 활용했습니다. 제가 원하는 결과물을 Claude나 Cursor에게 요청하면 코드가 나왔고, 제가 직접 눈으로 확인하고 수정했습니다. 혼자 쓸 때는 이것만으로도 충분했습니다. 제 머릿속에 모든 맥락이 있었고, 제가 짠 코드이기에 제가 책임지면 그만이었으니까요. 그런데 이것을 '팀'의 영역으로 가져오는 순간부터 묘한 문제들이 생기기 시작했습니다. 2단계: 팀으로 확장하자 생긴 일 저희 팀은 Terraform을 활용해 Azure 인프라를 관리하고 있습니다. AI 코딩 도구가 팀 안으로 들어오면서 코드 생성 속도는 확실히 빨라졌고, GitHub에 올라오는 PR의 수도 눈에 띄게 늘었습니다. 그런데 속도가 빨라짐과 동시에 새로운 딜레마에 빠졌습니다. 코드는 빠르게 쏟아져 나오는데, 그 코드가 팀 기준에 맞는지 확인하는 건 여전히 '사람의 눈'에 달려있었기 때문입니다. 저희 팀에는 인프라 코드를 작성할 때 반드시 지켜야 할 기준들이 있습니다. 리소스 명명 규칙, 필수 태그 여부, 보안 정책 준수 여부 같은 것들입니다. 예전에는 모듈 수가 적었기 때문에 PR 리뷰 시 사람이 직접 꼼꼼히 확인하면 되었습니다. 그런데 AI가 코드 생성 속도를 폭발적으로 끌어올리면서 리뷰해야 할 코드의 양은 산더미처럼 늘어났고, 리뷰어의 수는 그대로였습니다. 결국 병목 현상이 '코드 생성'에서 '코드 검증'으로 이동했을 뿐이었습니다. 더 큰 문제는 따로 있었습니다. AI는 가끔 "그럴듯하지만 틀린" 코드를 아주 자신 있게 내놓는다는 점입니다. 명명 규칙을 미묘하게 벗어났거나, 필수 태그가 하나 빠졌거나 하는 자잘한 오류들은 리뷰어가 지치면 그냥 스쳐 지나가기 십상입니다. 팀의 인프라 기준이 전적으로 '사람의 주의력'에 의존하는 아슬아슬한 구조가 되어버린 것입니다. 3단계: AI에게 맥락을 주는 방법의 진화 이 문제를 처음 마주했을 때 가장 먼저 시도한 방법은 '페르소나(Persona) 정의'였습니다. "너는 우리 팀의 인프라 엔지니어야. 명명 규칙은 이렇고, 태그는 이걸 써야 해." 프롬프트 앞에 팀 기준을 줄줄이 적어서 AI에게 역할을 부여하는 방식입니다. 처음엔 꽤 효과가 있었습니다. AI가 맥락을 이해하고 팀 기준에 맞는 코드를 더 잘 생성해 주었죠. 그런데 한계가 금방 드러났습니다. 페르소나 정의는 대화가 길어질수록 점차 희석됩니다. 초반에 설정한 역할을 AI가 점점 잊어버리고, 대화 중반쯤 되면 처음과 전혀 다른 스타일의 코드가 튀어나오기 시작합니다. 매번 새로운 대화를 시작할 때마다 같은 맥락을 반복해서 주입해야 하는 피로감도 컸습니다. 그래서 다음으로 시도한 것이 'SKILL.md' 방식입니다. 팀의 인프라 작성 기준, 명명 규칙, 자주 쓰는 패턴들을 마크다운(Markdown) 파일로 깔끔하게 정리해 두고, AI가 작업을 시작할 때 이 파일을 참조하게 하는 구조입니다. # SKILL.md ## 명명 규칙 - Resource Group: rg-{service}-{env}-{region} - V

[웨비나 후기] AI 시대, 데이터센터 운영의 기준을 높이다

.ktc-poster img { transition: transform .3s ease, box-shadow .3s ease; } .ktc-poster:hover img { transform: translateY(-4px); box-shadow:0 10px 22px rgba(0,154,135,0.22) !important; } .imageblock img { max-width:100% !important; height:auto !important; } .ktc-summary-body p { margin:0 !important; color:#3f5158 !important; font-size:1rem !important; line-height:1.75 !important; } @media (max-width: 768px) { .ktc-author-box { height:80px !important; min-height:80px !important; border-radius:14px !important; box-shadow:0 10px 24px rgba(0,120,106,0.24) !important; } .ktc-author-box td { height:80px !important; min-height:80px !important; padding-left:20px !important; padding-right:20px !important; } .ktc-author-summary-gap { height:18px !important; line-height:18px !important; } .ktc-summary-title { padding-left:20px !important; padding-right:20px !important; } .ktc-summary-body { padding-left:20px !important; padding-right:20px !important; } .ktc-section-title { font-size:1.1rem !important; margin:28px 0 14px !important; } .ktc-ref-wrap { padding:18px 20px !important; border-radius:14px !important; } .ktc-poster-wrap { gap:12px !important; margin:28px auto 10px !important; } } @media (max-width: 480px) { .ktc-author-box { height:70px !important; min-height:70px !important; border-radius:12px !important; } .ktc-author-box td { height:70px !important; min-height:70px !important; padding-left:16px !important; padding-right:16px !important; } .ktc-author-summary-gap { height:16px !important; line-height:16px !important; } .ktc-author-brand { font-size:0.66rem !important; letter-spacing:0.12em !important; } .ktc-author-name { font-size:0.95rem !important; } .ktc-summary-title { padding-left:15px !important; padding-right:15px !important; } .ktc-summary-body { padding-left:15px !important; padding-right:15px !important; } .ktc-summary-head { display:block !important; } .ktc-summary-label { display:inline-flex !important; margin-bottom:8px !important; } .ktc-summary-en { disp

[분석] 보이지 않는 생명줄, 데이터센터 접지(Grounding) 설비

kt cloud DC동부운용팀 이민재 님 요약 SUMMARY 이 글에서는 데이터센터 접지(Grounding)의 원리와 종류, 메쉬 접지 시공, 본딩 및 접지저항 관리 방법을 다룹니다. 접지 설비의 노후화에 대비한 점검과 보강이 감전 예방 및 설비 안전에 갖는 의미를 정리합니다. #데이터센터접지 #보호접지 #메쉬접지 #등전위본딩 #접지저항 감전 사고, 흔한 '저압'이 품고 있는 치명적인 위협 전기는 눈에 보이지도, 냄새가 나지도 않습니다. 그래서 더욱 치명적입니다. 흔히 수만 볼트의 특고압 철탑이나 대형 변압기만 위험하다고 생각하기 쉽지만, 실제 감전 사망 사고의 절대다수는 우리가 매일 만지는 220V/380V의 '저압(Low Voltage)' 환경에서 발생합니다. 숫자가 낮다고 절대 안전한 것이 아닙니다. 인체의 피부가 건조할 때는 저항이 높아 어느 정도 버티지만, 현장에서 땀을 흘리거나 물기가 있는 손으로 누전된 서버 랙(Rack)이나 냉동기 외함을 만지는 순간 인체 저항은 급격히 떨어집니다. 이때 심장 근육을 마비시켜 심실세동을 일으키고 사망에 이르게 하는 데 필요한 전류는 불과 수십 mA(밀리암페어), 즉 1암페어의 100분의 1도 채 되지 않는 아주 미세한 양입니다. 찰나의 순간에 생사가 갈리는 이 끔찍한 시나리오와, 수십억 원을 호가하는 IT 장비들이 서지(Surge) 한 번에 숯덩이가 되는 것을 막기 위해 땅속 깊은 곳에 묻어두는 최후의 안전장치가 바로 오늘 이야기할 '접지(Grounding)'입니다. <접지 설비> Image source: www.hsi.com Ch 01: 대지는 무한한 전기 쓰레기통, 접지의 원리와 종류 접지의 본질적인 개념을 한 줄로 요약하면 '지구(Earth)라는 무한한 용량의 전기 쓰레기통에 전선을 연결하는 것'입니다. 지구는 전하(전기)를 아무리 많이 쏟아부어도 전압이 올라가지 않는, 마치 바다에 물 한 바가지 붓는 것과 같은 '전위 0볼트(0V)'의 거대한 덩어리입니다. 전기 에너지는 항상 전압이 높은 곳에서 낮은 곳(0V)으로 흐르려는 성질이 있기 때문에, 누전된 전류가 가장 빠르고 완벽하게 빨려 들어갈 수 있는 블랙홀이 바로 대지(땅)인 것입니다. 이러한 접지는 그 목적에 따라 크게 세 가지 종류로 구분할 수 있습니다. 보호 접지 (Equipment Grounding): 누전이 발생했을 때 기기의 금속 외함을 타고 흐르는 전류를 대지로 빼내어 '인명의 감전'을 막는 가장 기본적인 접지입니다. 계통 접지 (System Grounding): 전압을 변환하는 변압기의 중성점을 땅에 연결하는 것입니다. 고압선과 저압선이 사고로 닿았을 때 비정상적인 전압 상승을 억제하여 계통 전체의 안정을 유지합니다. 피뢰 및 통신/기능 접지: 낙뢰의 막대한 에너지를 방전시키는 피뢰 접지, 그리고 민감한 서버나 통신 장비가 외부 노이즈 없이 0V라는 명확한 기준점(Reference)을 잡고 동작하게 해주는 기능성 접지입니다. 최근의 데이터센터 설계 트렌드이자 KEC(한국전기설비규정)의 핵심은, 이 모든 접지를 땅속에서 하나로 묶어버리는 '통합 접지(등전위 접지)'입니다. 번개가 칠 때 땅속 접지극들 사이에서 발생하는 전압 차이(전위차)를 원천적으로 없애 장비를 보호하기 위함입니다. <낙뢰 보호 시스템> Image source: Schneider Electric Ch 02: "전류는 게으르다", 저항과 타협하지 않는 물리 법칙 그렇다면 전선 한 가닥을 기계와 땅에 연결했다고 어떻게 사람의 감전을 막을 수 있을까요? 이 원리는 옴의 법칙(V=IR)과 '전류는 저항이 적은 아주 편한 길만 고집한다'는 자연의 섭리에서 출발합니다. 물이 꽉 막힌 파이프 대신 뻥 뚫린 하수구로 쏟아져 내리는 것과 같습니다. 어떤 서버 랙에 절연이 파괴되어 외함에 전기가 흐르고 있다고 상상해 봅시다. 작업자가 이 랙에 손을 대는 순간, 전류 앞에는 두 가지 갈림길이 놓입니다. 하나는 험준하고 복잡한 산길인 '사람의 몸(약 2,000Ω)'이고, 다른 하나는 대지까지 곧게 뻗은 8차선 고속도로인 '접지선(약 2Ω)'입니다. 전류

[기술해설] Agentic AI 시대의 Kubernetes 인프라 활용: Agent Sandbox 입문

kt cloud Container Service팀 박지선 님 요약 SUMMARY 이 글에서는 Kubernetes Agent Sandbox의 주요 CRD와 AI 에이전트의 상태 유지·격리·유휴 상태 관리 방식을 다룹니다. StatefulSet 방식과의 차이, WarmPool을 이용한 사전 준비 및 런타임 선택 시 주의사항을 정리합니다. #AgentSandbox #Kubernetes #AgenticAI #CRD #SandboxWarmPool 하루가 다르게 AI 워크로드의 패러다임이 빠르게 바뀌고 있습니다. 초기 AI 인프라(AI v1으로 칭함)는 단순했습니다. 짧은 추론 요청 처리만 했으면 됐었으나 최근 등장한 자율형 AI 에이전트(AI v2으로 칭함)는 전혀 다른 특성을 가집니다. 구분 AI v1 (추론 서비스) AI v2 (자율 에이전트) 의미 API 엔드포인트 뒤에 추론 모델 서빙 스스로 판단하고 행동하는 에이전트 상태 stateless stateful 실행 패턴 요청 → 응답 → 종료 계속 실행하며 도구 호출, 상태 유지 활동 지속적 상태 유지, 고유 ID, 격리 환경 필요 신뢰 수준 내부 코드 외부·비신뢰 코드 실행 가능 이 패러다임 변화는 인프라 선택에도 직접적인 영향을 미칩니다. Kubernetes를 인프라로 한 AI v1 서비스를 하려면 심플했습니다. 무상태 추론 Pod를 Deployment로 올리고, HPA로 수평 확장하면 그만이었습니다. 하지만 AI v2 에이전트를 기존 Kubernetes 리소스인 StatefulSet, Service, PVC 조합으로 운영하려 하면 운영 복잡도가 급격히 올라갑니다. 이 문제를 해결하기 위해 Kubernetes SIG Apps는 Agent Sandbox 프로젝트를 공개했습니다. Agent Sandbox: 격리되고 상태를 유지하는 싱글톤 워크로드를 쉽게 관리하기 위한 Kubernetes CRD 및 컨트롤러 Google을 포함한 여러 기업에서 관심을 가지고 있는 이 Agent Sandbox 프로젝트에 대해 소개해 보겠습니다. Namespace 격리로는 부족한 이유 "Kubernetes는 Namespace로 이미 격리되어 있지 않나?"라는 의문이 자연스럽게 나옵니다. 결론부터 말하면, Namespace 격리와 Agent Sandbox가 해결하는 문제는 레벨이 다릅니다. Namespace는 Kubernetes API 레벨의 논리적 분리입니다. RBAC, NetworkPolicy로 "누가 어떤 리소스에 접근할 수 있는가"를 제어합니다. 이 모든 격리는 컨테이너 안의 코드를 신뢰한다는 전제 위에 있습니다. AI 에이전트는 이 전제를 깨뜨립니다. AI 에이전트처럼 외부에서 들어온 임의의 코드를 실행하는 경우가 많기 때문입니다. 사용자 입력 → "이 Python 코드 실행해줘" → 에이전트 → exec() ↓ 악성 코드가 커널 취약점 exploit ↓ Namespace와 무관하게 호스트 탈출 가능 컨테이너는 호스트 OS 커널을 공유하기 때문에, Namespace 격리만으로는 커널 레벨 탈출을 막을 수 없습니다. 이를 해결하기 위해 커널 격리를 제공하는 gVisor 또는 Kata Containers를 선택적으로 사용할 수 있도록 Agent Sandbox는 설계되었습니다. 단, Agent Sandbox 자체는 CRD + 컨트롤러이며 기본 런타임은 일반 runc입니다. 비신뢰 코드를 실행하는 경우에만 runtimeClassName으로 gVisor/Kata를 지정합니다. # 기본 (신뢰 코드) runtimeClassName 미지정 → runc (일반 컨테이너) # 비신뢰 코드 실행 시 (보안 강화) runtimeClassName: gvisor → 유저스페이스 커널로 호스트 완전 격리 runtimeClassName: kata → 경량 VM으로 하드웨어 수준 격리 2026년 3월 기준 최신 릴리스는 v0.4.2이며, 아직 v1alpha1 단계의 오픈소스 프로젝트 입니다. Agent Sandbox 상세 리소스 설명 API 정의 Agent Sandbox는 크게 두 개의 API 그룹으로 구성됩니다

[인사이트] GPUaaS 네트워크 경쟁 구조 분석

kt cloud Cloud 컨설팅팀 심대섭 님 요약 SUMMARY 이 글에서는 GPUaaS의 AI 학습 성능에 영향을 주는 GPU 간·서버 간 네트워크 구조와 NVLink, InfiniBand, RoCE, 고속 Ethernet의 역할을 다룹니다. 대규모 GPU 클러스터에서 데이터 교환 병목을 줄이기 위한 연결 구조의 중요성을 정리합니다. #GPUaaS #NVLink #InfiniBand #RoCE #GPU클러스터 생성형 AI가 본격적으로 확산되면서 클라우드 인프라를 바라보는 기준도 빠르게 바뀌고 있습니다. 예전에는 CPU 기반 가상 서버를 얼마나 안정적으로 제공하느냐가 중요했다면, 지금은 대규모 AI 모델을 얼마나 빠르게 학습시키고 안정적으로 운영할 수 있느냐가 더 중요한 기준이 됐습니다. NVIDIA는 AI 인프라를 설명할 때 NVLink 기반 scale-up과 InfiniBand·Ethernet 기반 scale-out을 포함한 전체 네트워킹 패브릭을 함께 제시하고 있고, kt cloud도 GPU 기반 AI 학습·AI 추론·고성능 컴퓨팅용 인프라를 중심으로 서비스를 전개하고 있습니다. GPUaaS는 GPU 자원을 클라우드 형태로 제공하여 AI 학습과 추론을 수행할 수 있도록 하는 서비스 모델입니다. 국내 시장에서도 이 흐름은 더 이상 먼 이야기가 아닙니다. GPUaaS는 단순히 비싼 GPU를 빌려주는 서비스가 아니라, AI 워크로드를 실제로 감당할 수 있는 데이터센터 역량 전체를 보여주는 영역으로 바뀌고 있습니다. 이 점에서 GPU 서버, 스토리지, 전력, 냉각, 네트워크는 따로 존재하는 요소가 아니라 하나의 시스템처럼 함께 설계돼야 합니다. NVIDIA가 AI 팩토리 관점에서 NVLink, InfiniBand, Ethernet, DPU까지 하나의 스택으로 제시하는 것도 같은 이유입니다. AI 데이터센터 GPUaaS 구조도 (Image: AI-Generated Content) 왜 GPUaaS가 빠르게 중요해졌나? 이유는 단순합니다. 최신 AI 워크로드는 더 이상 한 대의 서버 안에서 끝나지 않기 때문입니다. 대형 언어모델과 멀티모달 모델은 수십 개에서 수백 개, 많게는 수천 개의 GPU가 동시에 연결된 환경을 전제로 학습됩니다. 이 과정에서 GPU는 연산을 맡고, 스토리지는 데이터를 공급하며, 네트워크는 계산 결과와 파라미터를 빠르게 주고받게 만듭니다. 어느 한 축이라도 받쳐주지 못하면 전체 학습 시간은 길어지고 운영 효율도 급격히 떨어집니다. 그래서 오늘날 GPUaaS의 핵심은 GPU를 많이 확보하는 것만이 아니라, 그 GPU를 얼마나 잘 연결하고 안정적으로 운영할 수 있는가에 있습니다. GPUaaS는 무엇을 함께 제공하나? 겉으로 보면 GPUaaS는 GPU 서버를 임대하는 서비스처럼 보입니다. 하지만 실제 경쟁력은 그보다 훨씬 넓은 범위에서 결정됩니다. 먼저 GPU 컴퓨팅 계층이 있어야 하고, 그 위에 데이터를 제때 공급할 수 있는 스토리지 구조가 필요합니다. 여기에 전력과 냉각 설계가 받쳐줘야 고밀도 GPU 환경을 안정적으로 운영할 수 있습니다. 그리고 이 모든 요소를 실제 성능으로 묶어 주는 계층이 바로 네트워크입니다. kt cloud가 GPU 기반 AI 인프라를 통해 학습·추론·HPC 워크로드를 지원하는 구조를 제시하는 점도, GPUaaS가 단순 장비 제공이 아니라 워크로드 운영 기반이라는 점을 보여줍니다. 초고속 네트워크가 왜 최근 더 중요해졌나? GPUaaS를 이야기할 때 많은 사람이 먼저 GPU 종류나 개수에 주목합니다. 물론 중요합니다. 하지만 실제 AI 학습 성능을 결정하는 것은 GPU만이 아닙니다. 여러 GPU가 동시에 일하는 환경에서는, 계산한 결과를 얼마나 빠르게 주고받을 수 있는지가 전체 속도를 크게 좌우합니다. 그래서 최근에는 GPU 성능만큼이나 네트워크 구조가 중요해졌습니다. Google Cloud는 AI 워크로드에 RoCE v2 기반 RDMA 네트워크를 제공하며, 이런 환경에서는 높은 대역폭과 낮은 지연이 핵심이라고 설명합니다. 이유는 생각보다 단순합니다. 대규모 AI 학습은 여러

[플랫폼설계] DevOps에서 Platform Engineering으로: kt cloud의 여정

kt cloud Platform엔지니어링팀 이지은 님 요약 SUMMARY 이 글에서는 DevOps에서 Platform Engineering으로 전환하며 개발자의 인지 부담을 줄이기 위해 Platform Portal과 골든 패스를 설계하는 과정을 다룹니다. 셀프서비스·GitOps·정책 자동화와 RAG 기반 AI 에이전트로 개발자 경험을 개선하는 방향을 정리합니다. #PlatformEngineering #PlatformPortal #GoldenPath #GitOps #DeveloperExperience "이 YAML은 누가 작성하나요?" kt cloud에서 NEXT 프로젝트를 진행하던 시절, 회의에서 심심치 않게 오가던 질문입니다. 배포 파이프라인을 작성하고 수정하는 건 개발자 몫이었고, Kubernetes 매니페스트를 손보는 것도, CI 스크립트가 실패하면 원인을 추적하는 것도 결국 개발자에게 돌아왔습니다. 당시 조직 이름은 CICD 였습니다. 이름 그대로, 지속적 통합과 배포 자동화가 핵심 미션이었습니다. DevOps 철학이 퍼지던 시대의 흐름을 잘 반영한 이름이기도 했습니다. "만든 사람이 운영도 한다(You build it, you run it)"는 원칙 아래, 개발자들은 기능 개발과 배포 운영을 동시에 책임졌습니다. 그런데 클라우드 네이티브 생태계가 생각보다 훨씬 빠르게, 훨씬 복잡하게 성장하면서 문제가 발생했습니다. 인지 부담이라는 현실 개발자 한 명이 하루 동안 마주하는 것들을 나열해보면 이렇습니다. 기능 개발을 위한 비즈니스 로직 구현 ArgoCD SyncPolicy 조정, App yaml 작성 Kyverno 정책 위반으로 인한 배포 실패 원인 추적 Harbor 이미지 레지스트리 Push, Pull, Tagging 설정 Image CVE 취약점 조치 GitHub Actions 워크플로우 디버깅 비즈니스 가치를 만들어내는 행위는 첫 번째뿐입니다. 나머지는 인프라 복잡성이 만들어낸 부수적 업무입니다. 이것을 인지 부담(Cognitive Tax)이라 부릅니다. 개발자가 핵심 업무에 쓸 수 있는 두뇌 자원을 인프라 운영이 잠식하는 현상입니다. DevOps는 본래 사일로를 제거하자는 철학이었습니다. 하지만 많은 조직에서 이 철학은 "개발자가 운영까지 다 하면 된다"는 방식으로 실천됐고, 결과적으로 모든 팀원이 전문적인 인프라 지식을 갖춰야 한다는 암묵적인 요구로 이어졌습니다. 실제로 NEXT 프로젝트 시절을 돌이켜보면, 각 서비스 팀이 비슷한 배포 파이프라인을 각자 조금씩 다른 방식으로 작성하고 있었습니다. GitHub Actions 워크플로우, Helm values 파일 구조도 제각각이었습니다. 동일한 문제를 열 팀이 열 번 푸는 구조였고, 각자 조금씩 다른 버그를 품고 있었습니다. 아래 다이어그램은 이 변화의 흐름을 잘 보여줍니다. Image: AI-Generated Content 조직의 이름이 바뀌었다는 것 2026년, CICD에서 Platform엔지니어링팀으로 조직 이름이 바뀌었습니다. 단순한 명칭 변경이 아니었습니다. 업무의 철학이 달라졌습니다. 배포 자동화 도구를 만들고 관리하는 것에서, 개발자가 더 잘 개발할 수 있는 환경 자체를 설계하는 것으로 미션이 바뀐 것입니다. kt cloud의 플랫폼 엔지니어링 여정이 본격적으로 시작된 시점이었습니다. 이 전환을 촉발한 질문은 세 가지였습니다. 첫째, 개발자가 새 서비스를 시작할 때 왜 이렇게 많은 것을 직접 설정해야 하는가? 둘째, 보안 정책과 표준을 지키면서도 속도를 낼 수 있는 방법은 무엇인가? 셋째, AI가 발전하고 있는 지금, 플랫폼이 더 지능적으로 개발자를 도울 수 있지 않을까? 업무 방식이 달라졌다 명칭 변경과 함께 실제 업무 프로세스도 달라지기 시작했습니다. 가장 큰 변화는 티켓 기반 요청에서 셀프서비스로의 전환입니다. 이전에는 개발팀이 새로운 서비스 생성이 필요하면 CICD팀에 Slack 메시지를 보내거나 Jira 티켓을 등록해야 했습니다. ArgoCD 프로젝트 생성, Harbor 프로젝트 할당, Vault 시크릿 경로 구성 같은 작업들이 모

[AI활용] AI 자동화, 어디서부터 시작해야 할까?

kt cloud Azure전환팀 변세림 님 요약 SUMMARY 이 글에서는 반복 업무에서 자동화 대상을 찾고, AI로 만든 자동화 도구를 유지보수 가능한 구조로 설계하는 과정을 다룹니다. 암묵지를 데이터로 분리해 자동화 부채를 줄이고 팀 단위 시스템으로 발전시키는 방법을 정리합니다. #AI자동화 #업무자동화 #암묵지 #자동화부채 #관심사의분리 Image: AI-Generated Content 안녕하세요! 작년부터 AI가 빠르게 일상 속으로 들어오면서, 자연스럽게 이런 생각이 들기 시작했습니다. "우리 팀의 업무에도 AI를 본격적으로 써볼 수 있지 않을까?" 최근 전사적인 클라우드 전환이 가속화되면서 저희 팀으로 쏟아지는 인프라 구축 및 권한 요청의 수는 기하급수적으로 늘어나고 있었습니다. 처음에는 단순히 ChatGPT나 Claude로 인프라 설계를 물어보거나 CLI 문법을 체크하는 보조 도구 수준에서 AI를 활용했습니다. 그러다 점차 "이렇게 똑같은 패턴으로 매일 반복되는 파이프라인 자체를 시스템으로 자동화할 수 있지 않을까?" 하는 욕심이 생겼습니다. 1. 첫 번째 질문: 무엇을 자동화할 것인가? 자동화를 시작하려면 가장 먼저 해야 할 일이 있습니다. 단순 반복 업무가 무엇인지 정의하는 것입니다. 이게 생각보다 쉽지 않습니다. 그 이유가 뭘까 생각해봤는데, 결국 암묵지(Tacit Knowledge) 문제였습니다. 매일 반복하다 보면 "원래 이렇게 하는 거야"로 굳어버립니다. 의식하지 않고 몸이 먼저 움직이는 것들, 그게 암묵지입니다. 자동화 대상이 보이지 않는 게 아니라, 너무 익숙해져서 "업무"로 인식조차 안 되는 것입니다. 저희 팀의 일과를 하나씩 매의 눈으로 뜯어보았습니다. 매일 사내 요청 접수 채널에 들어오는 수많은 상세 내용을 확인하고, 화면을 이리저리 오가며 정보를 파악한 뒤, 이를 팀 내 작업 관리 도구(이슈 트래커)에 일일이 옮겨 적는 일이 반복되고 있었습니다. "요청 정보 복사해서 붙여넣기, 항목별로 찾아서 또 복사해서 붙여넣기..." "이 정보들을 종합해서 10개가 넘는 이슈 트래커 관리 항목에 일일이 찾아 넣기..." 이 과정은 단순히 지루할 뿐만 아니라 휴먼 에러(Human Error)의 온상이었습니다. 수작업으로 진행하다 보니 어떤 날은 데이터를 누락하기도, 어떤 날은 오타를 내기도 했습니다. 이런 사소한 오타 하나는 나중에 클라우드 리소스를 추적하거나 과금 비용을 정산할 때 엄청난 스노우볼이 되어 돌아옵니다. 이 '지루함'과 '비효율'의 순간을 포착했습니다. 반복적인 데이터 확인과 입력 업무를 스크립트로 처리하여, API를 통해 작업 관리 도구에 자동으로 이슈를 생성해 주는 맞춤형 자동화 도구를 직접 개발해 보기로 했습니다. 암묵지를 끄집어내는 가장 좋은 신호는 "이 작업을 하면서 지겹다는 생각이 드는 순간"입니다. 그 지루함이 암묵지를 명시지로 바꾸는 출발점이고, 자동화의 시작점입니다. 2. 두 번째 질문: AI한테 어떻게 물어볼 것인가? 목표가 명확해졌으니 코드를 작성할 차례입니다. 처음 AI에게 코드를 요청했던 방식은 무척 단순했습니다. 머릿속에 있는 요구사항을 그대로 쏟아내는 방식이었습니다. "사내 업무 시스템 화면을 스크래핑해서 이슈 트래커 API로 티켓을 생성해줘. 요요청 유형에 따라 필요한 관리 항목을 확인하고, 각각의 필요한 정보를 자동으로 입력해 줘." AI는 요구사항을 찰떡같이 알아듣고 자바스크립트 코드를 뚝딱 만들어주었습니다. 처음엔 정말 마법 같았습니다. 버튼 하나만 누르면 브라우저가 화면을 읽고 10개가 넘는 복잡한 Jira 필드가 1초 만에 자동으로 채워졌습니다. 수작업에 쏟던 시간이 0으로 수렴하는 듯했습니다. 그러면 해피엔딩이었을까요? 3. 진짜 문제는 그 다음이었습니다 동화처럼 "행복하게 잘 살았습니다"로 끝나면 좋았겠지만, 현실은 달랐습니다. 한번 만들면 끝이 아니었습니다. 회사 내의 업무는 살아 숨 쉬는 유기체와 같습니다. 새로운 서비스가 지속적으로 런칭되고, 기존 서비스의 아키텍처나 보안 등급이 수시로 변경됩니다. 이런 변경 사항을 반영하기 위해 AI가

케클s피드 9월호｜kt cloud summit 2026, 고객의 AX를 현실로 만드는 인프라 전략

table { border-collapse: collapse; border: 0; border-spacing: 0; margin: 0; } div, td { padding: 0; } div { margin: 0 !important; } ul, li { margin: 0; } 96 @media screen and (max-width: 460px) { .stb-two-col .stb-column { max-width: 100% !important; } } @media screen and (min-width: 461px) { .stb-two-col .stb-column { max-width: 50% !important; } } @media screen and (max-width: 640px) { img.stb-justify { width: 100% !important; } } .stb-one-col p, .stb-two-col p { margin: 0px !important; } AI 서비스를 안정적으로 운영하려면 어떤 인프라와 기술이 필요할까요? 이번 케클s피드에서는 kt cloud summit 2026에서 공개한 고객의 AX를 뒷받침하는 인프라 전략을 소개합니다. AI 데이터센터의 전력 인프라와 구축·운영 기술부터 AI 서비스의 성능과 비용을 함께 고려한 클라우드·AI 기술과 적용 사례까지 담았습니다. 비즈니스 현장에서 AI를 구현하고 운영하는 데 필요한 인사이트를 만나보세요. --> 1,500여 명이 함께한 kt cloud summit 2026 Composite AI부터 1GW 규모의 AIDC 공급 로드맵까지, 고객의 AX를 지원할 기술과 인프라 전략을 소개했습니다. 지난 9월 15일, ‘당신의 비즈니스를 위한 AX’를 슬로건으로 kt cloud summit 2026이 열렸습니다. 공공기관과 기업 관계자, 데이터센터·클라우드·AI 분야 전문가 등 1,500여 명이 참석해 고객의 AX 구현을 위한 기술과 적용 사례를 살펴봤습니다. kt cloud는 이번 행사에서 kt cloud PLATFORM을 중심으로 한 Composite AI 비전을 소개했습니다. 또한 2031년까지 20여 개 사이트에 1GW 이상의 AIDC 인프라를 공급하기 위한 로드맵을 공개했습니다. AI 서비스 구현을 위한 클라우드 기술부터 대규모 AI 연산을 지원할 데이터센터까지, 행사에서 소개한 주요 내용을 확인해 보세요. Summit 주요 내용 자세히 보기 --> 고객의 AX를 위한 기술과 적용 사례를 한자리에서! 키노트와 기술 세션, 전시·시연으로 가득 채운 서밋 현장을 만나보세요. 지난 9월 15일, ‘당신의 비즈니스를 위한 AX’를 주제로 kt cloud summit 2026이 열렸습니다. 다양한 산업의 고객과 파트너가 모여 AIDC·클라우드·AI 기술의 변화와 현장 적용 경험을 나눴습니다. 키노트에서는 Composite AI와 차세대 AIDC의 방향을 소개하고, 기술 세션에서는 고객과 파트너의 구체적인 적용 사례를 공유했습니다. 전시 부스에서는 AIDC와 kt cloud PLATFORM 관련 기술을 직접 살펴보고, 시연과 담당자의 설명을 통해 실제 활용 방안을 확인할 수 있었습니다. 각 발표의 주요 메시지부터 전시 부스의 생생한 모습까지, kt cloud summit 2026의 현장을 다시 만나보세요. kt cloud summit 2026 현장 다시 보기 --> AI 데이터센터, 전력부터 탄탄하게 kt cloud와 LS일렉트릭이 전력설비의 적기 공급부터 차세대 전력 솔루션까지 협력합니다. AI 데이터센터가 대형화되면서 필요한 전력설비를 제때 확보하는 일이 중요해졌습니다. kt cloud는 LS일렉트릭과 전략적 파트너십을 맺고, AIDC 구축에 필요한 전력 인프라 확보와 기술 협력을 추진합니다. 양사는 구축 일정에 맞춰 주요 전력설비를 안정적으로 공급하기 위한 협업체계를 마련합니다. 모듈형 데이터센터(MDC)에 최적화된 전력 솔루션도 공동 연구해 대규모 AIDC를 신속하고 안정적으로 구축할 수 있는 기반을 다질 계획입니다. 1GW 규모의 AIDC