국내 기업 AX 소식: 현장 전문가의 판단은 AI가 매일 돌리고, 마지막 결정은 사람이 쥔다 (11월 14일 묶음)

KT와 GS칼텍스는 현장 전문가가 머릿속과 손작업에 두던 판단을 정해진 주기로 도는 운영 시스템에 올렸습니다. KT의 에이전트는 1분마다 망 이상을 분석하고, GS칼텍스의 예측 모델은 30분마다 추론합니다. 두 회사 모두 장비를 조작하거나 모델을 배포하는 마지막 단계는 사람이 승인하도록 코드로 막았습니다. 따라 하려면 전문가의 판단을 기록하는 방식, AI가 할 수 있는 일의 목록, 사람이 승인하는 지점부터 정해야 합니다.

요약

이번 묶음은 11월 11~13일에 나온 국내 기업 사례 두 건입니다. Microsoft Source는 KT가 망 장애 분석에 쓰는 에이전트 플랫폼 AIO-Net을 소개했습니다. KT의 20년 안팎 경력 망 전문가(Meister)들이 표준 운영 절차와 노하우로 이 플랫폼을 학습시켰고, Microsoft의 FDE(Forward Deployed Engineer, 고객사에 상주하며 함께 만드는 엔지니어)가 KT 사무실에서 코드를 썼습니다. AWS Machine Learning Blog에는 GS칼텍스 DAX Lab과 AWS가 함께 쓴 글이 실렸습니다. 공정 엔지니어가 SageMaker Canvas(코드 없이 모델을 만드는 AWS 도구)로 만든 예측 모델을 SageMaker Pipelines로 정기 운영에 올린 과정입니다.

두 회사가 바꾼 업무는 다르지만 구조는 같습니다. 전문가의 판단을 사람 손 없이 반복해서 돌리고, 위험한 마지막 단계는 사람에게 남겼습니다. KT는 에이전트가 장비에 읽기 전용 명령만 보낼 수 있게 애플리케이션에서 막았고, 조치는 운영자가 정합니다. 그 결과 장애 감지가 10분 이상에서 2~3분으로 줄었습니다. GS칼텍스는 Model Registry에서 승인된 모델만 배포 코드가 받아들이게 했습니다. 모델 배포 기간은 약 1주에서 몇 시간으로 줄었습니다. 아래에서 회사별로 정리한 뒤, 같은 방식을 실제로 돌릴 때 필요한 기술·현업 디테일을 덧붙입니다.

사례별 정리

KT: Meister의 절차를 배운 에이전트가 망 장애 감지를 10분 이상에서 2~3분으로 줄였다

• 상황: KT는 이동통신 가입자 2,900만 명에게 이동통신, 초고속 인터넷, TV, 전화를 제공합니다. 망 운영 혁신 책임자 Seonil Jeong은 운영 효율보다 망 안정성이 먼저라고 말합니다. 그런데 망 관리는 여전히 수작업 비중이 컸습니다. 서비스가 늘수록 알람 분석에 드는 시간이 길어졌고, 엔지니어는 알람 하나를 조사하려고 여러 시스템의 데이터를 오가야 했습니다. 장애 감지에는 10분 넘게 걸렸습니다. Meister인 Heeyoung Oh는 알람이 뜨고 처음 10분 안에 분석을 끝내는 것을 목표로 삼아 왔습니다.
• 한 일: KT와 Microsoft Frontier Company 팀이 문제 정의부터 함께 했습니다. Azure 위에 AIO-Net을 만들어 흩어진 데이터를 한 화면에 모았습니다. 에이전트는 Microsoft Foundry의 여러 LLM으로 만들었습니다. 전국 장비의 실시간 데이터를 1분마다 분석해 이상을 찾고 근본 원인을 진단합니다. 장비를 조회·점검하고 근거와 진단 보고서, 해결안, 고객 서비스 영향 여부를 내놓습니다. 장비에 보낼 수 있는 명령은 허용 목록의 읽기 전용 명령뿐이고, 이 제한은 프롬프트가 아니라 애플리케이션에서 강제합니다. KT 개발팀은 그 이유를 이렇게 설명합니다. “잘못된 명령 하나가 그 자체로 장애를 일으킬 수 있다.” 에이전트는 결론과 판단 과정을 기록해 전문가가 평가할 수 있게 합니다. 이 피드백을 모으고 적용하고 되돌리는 hill-climbing(조금씩 고치며 성능을 끌어올리는 반복 개선) 절차는 Microsoft 엔지니어와 함께 만들었습니다.
• 결과: Oh는 8월부터 AIO-Net을 쓰고 있습니다. 장애 감지는 2~3분으로 줄었습니다. 핵심 장애를 찾아 진단하는 데 평균 약 5분이 걸리고, 조사 보고서도 평균 약 5분 만에 나옵니다. 수작업으로 할 때의 약 절반입니다. 피드백은 예전에는 요청해도 지역 담당자 1~2명만 답했지만, 지금은 운영자가 쓰는 동안 저절로 쌓입니다.
• 다음 계획: 대상 핵심 장비를 70대에서 280대로 늘리고, 그다음 가입자에 가까운 액세스망으로 넓힙니다. 인력은 시설 관리와 품질 관리처럼 더 가치 있는 일로 옮길 계획입니다.

GS칼텍스: 공정 엔지니어의 노코드 모델을 그대로 파이프라인에 올려 배포를 약 1주에서 몇 시간으로

• 상황: GS칼텍스의 공정 엔지니어는 공정 변수와 데이터를 잘 압니다. 그래서 SageMaker Canvas에서 코드 없이 모델을 만들고 검증해 왔습니다. 문제는 이 모델을 정기 운영에 올리는 단계였습니다. ML 엔지니어가 운영 데이터 경로를 잡고, 모델 설정을 넣고, 전처리 작업과 추론 작업을 손으로 이어야 했습니다. 모델 하나를 배포하는 데 약 1주가 걸렸습니다.
• 한 일: Canvas 안의 Data Wrangler가 만든 전처리 파일(.flow)을 SageMaker Processing으로 그대로 다시 돌리게 했습니다. 같은 입력에 대해 Canvas 결과와 Processing 결과가 같은지 먼저 확인합니다. 검증한 모델은 Model Registry에 등록하고, ML 엔지니어가 데이터 형식과 예측 결과를 보고 승인 상태를 바꿉니다. 배포 코드는 패키지 상태가 완료이고 승인 상태가 승인일 때만 모델을 만듭니다. Model Registry는 승인 여부를 기록할 뿐 추론 요청마다 막아 주지 않기 때문입니다. 추론은 Amazon EventBridge가 30분마다 파이프라인을 시작해 하루 48회 돕니다. 상시 켜 두는 실시간 엔드포인트 대신, 작업이 끝나면 컴퓨팅을 반납하는 Batch Transform을 썼습니다.
• 결과: ML 엔지니어는 이제 몇 시간 안에 모델을 배포합니다. 상시 엔드포인트가 필요 없어져 추론 비용이 의미 있게 줄었다고 회사가 밝혔습니다. 금액이나 비율은 나오지 않습니다. 공정 엔지니어들이 다른 공정에도 써 보자는 제안을 내기 시작했고, ML 엔지니어는 반복 연결 작업 대신 파이프라인 운영과 모니터링에 시간을 씁니다. 어떤 공정의 무엇을 예측하는 모델인지는 글에 나오지 않습니다(예제 코드는 대출 분류 샘플 모델).
• 다음 계획: 2편에서는 Amazon Bedrock으로 기존 모델을 이 파이프라인에 옮기는 작업을 자동화한 과정을 다룬다고 예고했습니다.

글은 도입 순서를 세 단계로 제안합니다. Crawl 단계에서는 개발 결과를 운영에서 그대로 재현합니다. 모델을 검증해 등록하고 파이프라인을 손으로 돌려 봅니다. Walk 단계에서는 승인 확인, 주기 실행, 실패 알림, 실행별 결과 관리를 붙여 정기 운영을 믿을 수 있게 만듭니다. Run 단계에서는 공통 템플릿과 CI/CD, 변경 검증, 운영 책임 이관 절차로 같은 운영 방식을 여러 모델에 다시 씁니다.

기술 디테일: 전문가 판단을 반복 실행에 올리고 권한은 코드로 묶으려면

아래는 두 사례의 방식을 따라 만들 때 필요한 것입니다. 기사에 나온 내용이 아니라 AX Review가 덧붙인 실행 방법이며, 필드명·설정값·기준은 출처를 따로 밝힌 것 말고는 모두 가상 예시입니다.

에이전트 권한은 허용 목록으로 정하고 도구 호출 단계에서 막습니다(KT의 ‘읽기 전용 명령, 애플리케이션 강제’). 프롬프트에 “설정을 바꾸지 마라”라고 적는 것만으로는 모델이 지시를 어길 때 막을 수 없습니다. 에이전트가 장비에 명령을 보내는 도구를 하나로 모으고, 그 도구가 명령을 보내기 전에 허용 목록과 대조하게 합니다. 목록은 명령 패턴(show *), 대상 장비 등급, 호출 한도(장비당 1분 3회 같은)로 적습니다. 목록에 없는 명령은 실행하지 않고 denied 기록을 남깁니다. 거부 건수가 갑자기 늘면 프롬프트나 모델 버전을 바꾼 직후인지 먼저 확인합니다. 진단 결과는 incident_id, alarm_ids, root_cause, evidence[](실행한 명령과 응답 요약), customer_impact(있음·없음·불명), suggested_action, confidence를 담은 JSON으로 받습니다. 그래야 운영자가 근거를 따라 확인하고 전문가가 사례별로 평가할 수 있습니다.

전문가 피드백은 사례 단위로 쌓고 버전별로 비교한 뒤 반영합니다(KT의 hill-climbing 절차). 운영자가 진단을 그대로 썼는지, 고쳤는지, 버렸는지를 operator_action으로 남기면 따로 설문하지 않아도 피드백이 됩니다. Meister가 매주 고친 건과 버린 건을 골라 정답 원인을 적으면 평가 세트가 됩니다. 프롬프트나 절차 문서를 바꿀 때는 새 버전을 이 평가 세트에 먼저 돌려 원인 일치율을 비교합니다. 일치율이 떨어지면 반영하지 않고 이전 버전으로 되돌립니다. LLM 진단은 같은 입력에도 결과가 흔들릴 수 있으므로, 평가할 때는 사례마다 3회씩 돌려 결과가 엇갈리는 사례를 따로 표시합니다.

노코드 모델의 전처리는 다시 만들지 말고 같은 파일을 재사용합니다(GS칼텍스의 .flow 재사용). 원문이 강조하듯 스케일링이나 인코딩 값은 학습 때 정해진 값을 써야 하고 배치마다 새로 맞추면 안 됩니다. 전처리 파일 버전과 모델 버전을 짝으로 묶어 같은 실행 기록에 남깁니다. 목표 열에 의존하는 변환(행 필터링, target encoding)은 추론 경로에서 따로 처리합니다. 결과를 합칠 때 행 순서에만 기대면 어긋날 수 있으므로, 원문 권고대로 입력·출력 행 수를 비교하거나 레코드 ID로 맞춥니다.

승인은 레지스트리가 아니라 배포 코드에서 확인합니다(GS칼텍스의 ‘승인 상태 확인 후 배포’). 배포 함수 첫 줄에서 모델 패키지 상태가 완료이고 승인 상태가 승인인지 확인하고, 아니면 예외를 내고 멈춥니다. 승인을 취소하면 그 모델을 쓰는 스케줄과 실행 설정도 함께 바꿔야 합니다. 30분 주기라면 실행 하나가 30분을 넘지 않는지 시작 시간과 재시도까지 넣어 재고, 앞 실행이 끝나지 않았으면 다음 실행을 건너뛰게 합니다. 작업 실패와 처리 지연에는 CloudWatch 알림을 겁니다.

현업 실행 디테일: 누가, 언제, 무엇을

전문가 판단 한 가지를 골라 12주 동안 시범 운영하는 경우를 예로 듭니다. 망 장애 진단이든 공정 예측이든 같은 틀을 쓸 수 있습니다. 역할, 일정, 판정 기준은 모두 가상 예시입니다.

역할	담당	하는 일
시범 책임	운영 부서 팀장	대상 업무 선정, 판정 기준 확정, 확대 결정
도메인 전문가	10년 이상 경력자 2~3명(KT의 Meister, GS칼텍스의 공정 엔지니어 역할)	판단 절차 문서화, 주간 사례 평가, 정답 원인 기록
AI·ML 엔지니어	내부 엔지니어 또는 벤더 FDE 1~2명, 현장 상주	에이전트·파이프라인 구현, 평가 세트 운영, 버전 관리
승인권자	운영 책임자 1명	모델·프롬프트 새 버전의 운영 반영 승인
보안·IT	인프라 담당 1명	허용 목록 관리, 계정·역할 권한, 로그 보관

준비물은 다섯 가지입니다. 최근 6개월 알람·장애 또는 공정 이벤트 기록, 현재 표준 운영 절차 문서, 전문가가 실제로 보는 시스템과 화면 목록, AI가 해도 되는 일과 안 되는 일의 초안, 지금 걸리는 시간(감지·분석·보고서·배포)의 기준선입니다. 1~2주차에는 업무와 전문가를 고르고 기준선을 잽니다. 3~5주차에는 전문가 인터뷰로 판단 절차를 적고 허용 목록과 승인 지점을 정합니다. 6~9주차에는 AI 결과를 현장에 내보내지 않고 전문가 판단과 나란히 비교하는 그림자 운영을 합니다. 10~12주차에는 운영자에게 결과를 보여 주고 시간 단축과 정확도를 재서 확대 여부를 정합니다.

시작 전에 전문가에게 물을 질문입니다.

1. 알람이나 이벤트가 뜨면 처음 10분 동안 어떤 화면을 어떤 순서로 봅니까?
2. 원인을 확정하려고 장비나 시스템에 보내는 확인 명령·조회는 무엇입니까? 그중 상태를 바꿀 수 있는 것은 무엇입니까?
3. 고객이나 생산에 영향이 있는지는 무엇을 보고 판단합니까?
4. 신입이 가장 자주 틀리는 판단은 무엇이고, 그때 무엇을 놓칩니까?
5. AI가 낸 결과를 믿으려면 어떤 근거가 함께 보여야 합니까?

진행 판정 기준(예시)은 이렇게 둡니다. 그림자 운영 4주 동안 AI의 원인 진단이 전문가 판단과 80% 이상 맞고, 허용 목록 밖 명령 시도가 모두 차단됐으면 운영자에게 결과를 엽니다. 운영 전환 뒤에는 감지부터 첫 보고까지 걸린 시간의 중앙값이 기준선보다 절반 이상 줄고, 운영자가 진단을 버린 비율이 20% 이하이면 대상을 넓힙니다. 모델 배포형(GS칼텍스 방식)이라면 Crawl 단계에서 수동 실행 결과가 개발 결과와 같은지, Walk 단계에서 2주 동안 정기 실행 실패가 없는지를 다음 단계의 조건으로 둡니다.

AX 관점에서 두 사례는 첫 과제를 고르는 순서를 알려 줍니다. 전문가가 이미 잘하는 판단을 골라 그 사람의 절차로 AI를 가르치면 정답을 확인할 사람이 처음부터 곁에 있습니다. 권한은 처음부터 좁게 잡습니다. KT처럼 읽기만 허용하거나 GS칼텍스처럼 승인 뒤에만 배포하게 하면, 보안·운영 부서가 시범을 막을 이유가 줄어 시작이 빨라집니다. 성과는 AI가 낸 결과 수가 아니라 감지·배포에 걸린 시간과 전문가가 고친 비율로 재야 경영진이 확대를 판단할 수 있습니다. 벤더 FDE를 쓸 경우에는 피드백을 모으고 되돌리는 절차를 내부 팀이 넘겨받는 날짜를 계약에 적어 둡니다.

원문 사례

회사	대상 업무	한 일	수치·계획(원문 기준)
KT	망 장애 감지·분석	Azure 기반 에이전트 플랫폼 AIO-Net. Microsoft Foundry의 여러 LLM, Meister의 절차로 학습, 1분마다 이상 분석, 읽기 전용 허용 목록, 조치는 사람	가입자 2,900만 명. 8월부터 운영. 감지 10분 이상 → 2~3분, 진단·보고서 평균 약 5분(수작업의 약 절반). 핵심 장비 70대 → 280대, 이후 액세스망
GS칼텍스	공정 예측 모델 운영	SageMaker Canvas 노코드 모델과 .flow 전처리를 SageMaker Pipelines로 재사용, Model Registry 승인 확인 후 배포, Batch Transform	배포 약 1주 → 몇 시간 안. 30분마다, 하루 48회 추론. 파이프라인 5단계. 비용 절감 수치 없음. 2편은 Bedrock 자동화

기사	매체 · 저자	날짜	링크
KT ‘Meisters’ and Microsoft engineers build AI agents to spot network issues before customers do	Microsoft Source · Lim Ai Leen	2026-11-11	기사
Production MLOps at GS Caltex with Amazon SageMaker Canvas, part 1	AWS Machine Learning Blog · WonGu Rho(GS칼텍스 DAX Lab) 외 AWS 3명	2026-11-13	기사

핵심 개념

Meister

KT가 20년 안팎의 현장 경력을 가진 망 전문가를 부르는 이름. AIO-Net의 학습과 평가를 맡았다.

FDE(Forward Deployed Engineer)

고객사 현장에 상주하며 문제를 함께 정의하고 직접 코드를 쓰는 벤더 엔지니어.

허용 목록(allow list)

AI가 실행해도 되는 명령만 적어 둔 목록. 목록에 없는 명령은 시스템이 거부한다.

hill-climbing

작은 변경을 하나씩 시험해 나아지면 남기고 나빠지면 되돌리는 반복 개선 방식.

SageMaker Canvas

코드 없이 데이터 준비, 모델 학습, 예측을 할 수 있는 AWS 도구. 전처리 과정이 `.flow` 파일로 남는다.

Model Registry

모델 버전과 승인 상태를 기록하는 저장소. 승인을 강제하지는 않으므로 배포 코드에서 확인한다.

Batch Transform

쌓인 데이터를 한꺼번에 추론하고 작업이 끝나면 컴퓨팅을 반납하는 방식. 상시 켜 두는 실시간 엔드포인트와 대비된다.

그림자 운영(shadow mode)

AI 결과를 현장에 내보내지 않고 기록만 남겨 사람 판단과 비교하는 시범 방식.

내 메모

TODO: 내 생각 추가

원문: Microsoft Source Lim Ai Leen 「KT ‘Meisters’ and Microsoft engineers build AI agents to spot network issues before customers do」(2026.11.11)와 AWS Machine Learning Blog WonGu Rho·Hyunsoo Kim·Joonhyung Kim·Sang Hyun Kim 「Production MLOps at GS Caltex with Amazon SageMaker Canvas, part 1」(2026.11.13)을 원문으로 읽고 썼습니다. 이 묶음에 배정된 기사 두 건을 모두 열었고 뺀 기사는 없습니다. 요약, 사례별 정리, 원문 사례는 기사에 나온 사실을 AX Review가 다시 정리한 것이고 수치는 모두 원문에 나온 값입니다. 인물 이름은 원문의 영문 표기를 따랐습니다. 기술 디테일, 현업 실행 디테일, 인포그래픽과 표는 AX Review가 새로 작성했으며 필드명, 명령 예시, 호출 한도, 일정, 판정 기준은 가상 예시입니다. 실행 메타데이터 항목 가운데 입력 구간, 전처리 버전, 모델 패키지, 실행 기록은 AWS 글의 권고를 따랐습니다. 전체 내용은 원문에서 볼 수 있습니다.