들어가며
1. 문제 정의
1.1. 기존 프로세스의 문제점 분석
1.2. 해결방안: 현장 지식 구조화와 Agentic AI 기반 원인 분석
2. Agentic AI 설계 철학
2.1. 신뢰성 확보 : 예측 가능한 범위에서 Agent 행동을 제어하기
참고 자료
- SOP-Agent (arXiv, 2025) : 자연어 SOP를 Decision Graph로 변환하여 Agent의 행동을 가이드하는 프레임워크 제시.
- Flow-of-Action (WWW, 2025) : Root Cause Analysis 작업 대상으로 SOP 기반 Multi-Agent 구조를 적용하여, ReAct 구조 적용 대비 분석 정확도가 향상되는 결과 확인.
2.2. 설명가능성 확보 : Agent의 추론 근거를 명확하게 제시하기
① 단계별 Agent 추론 과정 제시
③ 종합 분석 리포트 제시
Agent가 모든 가설에 대한 검증을 완료하면, 해당 결과를 종합하여 최종 분석 리포트를 생성하게 됩니다. 분석 리포트에는 Agent가 검토한 가설들에 대한 판단 결과와 더불어 권장 조치 사항에 대한 정보도 포함되어 있습니다. 현장 마이스터는 분석 리포트 내용을 확인하고 신속하게 조치를 취하되, 상황에 따라서는 Agent의 상세 추론 과정을 참고하여 추가적인 점검을 수행할 수 있도록 구성하였습니다.
저희팀은 현장 마이스터로 하여금 Agent의 장애 진단 과정을 단계별로 확인하고, Agent의 판단 근거를 직접 확인하기 용이한 형태로 화면을 구성하여 제공함으로써, Agent의 행동에 대한 설명가능성을 확보할 수 있었습니다. 이어서, 저희팀이 설계한 Agentic 진단 로직에 대해 조금더 상세하게 설명드리도록 하겠습니다.
3. Agentic 진단 로직 구현 상세
3.1. 전체 진단 흐름
AIONet 플랫폼은 이상 탐지, 장애 진단, 조치 제안까지 네트워크 장애 대응의 전 과정을 포괄하는 시스템으로, 크게 이상 탐지 흐름과 장애 진단 흐름으로 구성되어 있습니다.
이상 탐지 흐름은 실시간으로 인입되는 네트워크 데이터에 기반하여 이상 징후를 포착하고 장애 판단 과정을 거쳐 장애 진단 Ticket이 발행되는 흐름을 의미합니다. 네트워크 장비마다 흐르는 트래픽의 특성이 다르므로, 이상 탐지 모듈은 Machine Learning 기법을 활용하여 각 장비별 데이터 특성을 학습하고 이에 기반하여 이상 징후를 탐지하도록 설계되어 있습니다. 이상탐지 모듈에서 다수의 이상 징후가 포착되면, 장애 판단 모듈에서는 이상 징후간 연관관계에 기반하여 장애 유형을 판단합니다. 이후, 이상 탐지 내역과 장애 판단 결과는 하나의 장애 진단 Ticket으로 묶여서 발행이 되고, 이는 장애 진단 흐름의 트리거로 작동하게 됩니다. 이상 탐지 및 장애 판단에 대한 자세한 내용은 AI기반 IP코어망 장애 선감지 서비스 개발 스토리를 참고해주시기 바랍니다.
장애 진단 흐름은 장애 진단 Ticket 내용에 기반하여 Agent가 원인 분석 가설을 수립하고 장비 상태를 진단하여 종합 결론을 도출하는 흐름으로 진행됩니다. 장애 진단 Agent는 전체 흐름을 관장하는 Supervisor Agent와 실제 작업을 수행하는 Action Agent로 구성되어 있습니다. Supervisor Agent가 Ticket 내용에 기반하여 전체 진단 프로세스를 오케스트레이션하고, 장애 유형과 연관된 가설 확인 및 각 가설의 SOP를 Action Agent에 전달합니다. SOP에는 Action Agent가 수행할 행동 절차에 대한 정보를 담고 있으며, 어떤 순서로 점검해야 하는지, 어떤 기준으로 판단해야 하는지에 대한 정보를 포함하고 있습니다. Action Agent는 SOP에 따라 [Tool 선택 → 원격 명령어 수행 → 장비 상태 판단] 과정을 반복하며 각 명령어 결과에 대해 정상/비정상을 판단하고, 이를 종합하여 해당 가설에 대한 채택/기각 결론을 도출합니다. 가설에 대한 검증이 끝나면 Supervisor Agent가 그 결과를 취합하여 Report Agent에 전달하고, Report Agent가 종합 리포트를 생성합니다.
3.2. 네트워크 장비 정상/비정상 판단 Tool 구현 과정
장애 진단 Agent가 활용하는 SOP는 원인 가설별 네트워크 장비 점검 절차를 정의해둔 문서를 의미합니다. Agent가 SOP에 기반하여 실제 장비 상태를 점검하기 위해서는 장비에 명령어를 내리고 그 결과를 받아와서 정상/비정상을 판단하는 Tool 구현이 필수적입니다. 그리고 Agent가 하나의 장애 진단 Ticket을 처리하기 위해 수십 번의 장비 상태에 대한 정상/비정상 판단을 수행하고 이를 종합하여 원인 가설에 대한 채택/기각을 결정하기 때문에, 이 Tool의 판단 정확도가 시스템 전체 품질에 직결됩니다. 이 Tool의 판단 정확도를 높이기 위해 여러 차례에 걸쳐 프롬프트 구조를 변경해보는 실험을 진행하였고, 점진적인 개선을 통해 현재의 구조에 이르렀습니다. 저희 팀이 단순한 형태부터 시작해서 어떤 과정을 거쳐서 현재 구조에 이르렀는지 순차적으로 설명드리도록 하겠습니다. (일반적으로 log 확인에 많이 사용되는 show system log 에 대한 가상의 출력결과로 예시를 들었습니다.)
v1: 기본 형태
우선, 가장 기본적인 형태로, 장비 출력 결과의 정상/비정상을 판단하는 Agent를 구성했습니다. Agent가 장비에 명령어를 실행하고 출력 결과를 받아오면, 그 결과를 그대로 LLM에 전달하여 정상/비정상을 판단하도록 했습니다.
- 입력: [명령어] + [출력결과]
- 출력: [판단(정상/비정상)]
| 입력 예시 |
출력 예시 |
|---|---|
명령어: show system log출력결과:
Bash
|
판단: 비정상 |
그러나 이 형태는 장비 명령어 출력 결과를 효과적으로 판단하기 어려운 구조였습니다. 네트워크 장비의 명령어 출력결과는 수십에서 수백 라인에 달하는 경우가 많고, 정상/비정상 판단을 위해 출력 결과의 어떤 부분이 핵심 정보인지에 대한 가이드가 없어서 LLM 판단 정확도가 다소 떨어졌습니다. 좀 더 객관적인 판단을 위해, 정상/비정상 판단 성능 측정용 데이터셋을 구축하고 정량적으로 성능을 측정해 보니, GPT-4류 모델의 Recall 성능이 기대 수준에 미치지 못하는 것을 확인했습니다.
v2: LLM Input 프롬프트에 조건문 추가
저희팀은 Recall 성능을 높이기 위해, LLM 입력 프롬프트에 각 명령어별 정상/비정상에 대한 판단 기준 문장을 추가하였습니다. 해당 판단 기준은 현장 마이스터 분들과 정리한 표준운용절차 SOP에 각 장비 제조사별로 정리되어 있습니다. 이렇게 판단 조건을 추가해주는 것만으로도 GPT-4류 모델에서 Recall 성능이 0.9로 향상되었으며, LLM이 명령어 출력 결과에서 어떤 내용을 집중적으로 봐야하는지 인지하게 되었습니다.
- 입력: [명령어] + [출력결과] + [점검 조건문]
- 출력: [판단(정상/비정상)]
| 입력 예시 |
출력 예시 |
|---|---|
명령어: show system log출력결과:
Bash
|
판단: 비정상 |
v3: LLM Output 프롬프트에 판단 이유 문장 추가
저희팀은 v2의 성능에 만족하지 않고 추가적인 프롬프트 엔지니어링을 진행하였습니다. 바로, LLM의 출력에서도 단순히 "정상" 또는 "비정상"만 출력하는 것이 아니라, 판단 이유를 함께 서술하도록 프롬프트를 변경했습니다. 이 방식은 Chain-of-Thought와 유사한 효과를 내어 판단의 정확도를 높였고, 이후 모델 파인튜닝을 위한 학습 데이터를 구축하는 데에도 해당 프롬프트 형식을 활용했습니다.
- 입력: [명령어] + [출력결과] + [점검 조건문]
- 출력: [판단(정상/비정상)] + [판단 이유]
| 입력 예시 |
출력 예시 |
|---|---|
명령어: show system log출력결과:
Bash
|
판단: 비정상 판단 이유: 전체 로그 중 4번째 줄에서 Power Supply * failed 문구가 감지되어, 전원 공급 장치 HW 비정상 상태로 결론 |
v3+: 장비별 파라미터 정보를 활용한 동적 호출
네트워크 장비의 정상/비정상을 판단할 때, 별도의 장비 연계 정보 없이 바로 수행할 수 있는 명령어가 대부분이었지만, 특정 IP 주소나 인터페이스명 같은 장비별 고유 파라미터를 입력해야 실행할 수 있는 명령어도 존재했습니다. 예를 들어, 특정 인터페이스의 상태를 조회하는 명령어는 점검 대상 장비의 실제 인터페이스명을 알아야 실행할 수 있었습니다.(“show ~” + “해당 장비의 인터페이스명”)
이를 위해 저희팀은 명령어 실행에 필요한 파라미터 정보를 내부 네트워크 관리 데이터로부터 동적으로 조회하도록 구현하였습니다. Agent가 명령어를 수행하기 전에 점검 대상 장비와 관련된 연결 정보를 자동으로 조회하여 명령어를 완성한 후 실행하는 구조로 구성하였습니다.
이처럼 네트워크 장비 정상/비정상 판단 Tool은 단순히 장비 명령어를 실행하는 것을 넘어, 판단 기준 주입, 판단 근거 생성, 동적 파라미터 처리까지 여러 차례의 개선을 거쳤습니다. 이러한 개선 과정을 거쳐 Agent가 현장 마이스터 수준의 정확도로 장비 상태를 판단할 수 있게 되었습니다.
3.3. 자체 파운데이션 LLM 파인튜닝을 통한 Vertical LLM 모델 확보 과정
앞서 설명드린 네트워크 장비 정상/비정상 판단 Tool에 활용되는 Vertical LLM 모델을 확보하는 작업도 진행을 하였습니다. Agentic 진단 로직 자체가 네트워크 도메인에 대한 높은 이해도를 요구함과 동시에, 하나의 장애 티켓을 분석하는 동안 수십 번의 모델 호출이 발생하기에 비용 측면도 고려가 되어야 했습니다. 특히, 네트워크 장비 CLI 출력에 대한 정상/비정상 판단 영역은 벤더별로 다른 출력 포맷과 네트워크 전문 용어, 사내 운용 환경에 특화된 판단 기준 등 일반 LLM이 학습하지 않은 영역이므로 Vertical 특화 모델이 더욱더 필요한 영역이었습니다. 이에 따라, 저희팀은 KT 자체 파운데이션 LLM 모델인 믿:음 2.0을 기반으로 파인튜닝 작업을 진행하였으며, 사내 운용 지식을 학습시키고, 벤더별 출력 포맷 차이를 이해하며, 희귀한 비정상 패턴에 대한 민감도를 높이고자 했습니다.
모델 파인튜닝을 위한 데이터셋 구축 과정은 다음과 같습니다. 우선, 장비 벤더별 명령어 실행 결과를 모아서 원본 데이터셋을 구성했습니다. 데이터셋은 명령어 출력, 정상/비정상 라벨, 판단 근거 등으로 구성되며, 다양한 데이터 증강 방법을 활용하여 최종 학습 데이터셋을 확보했습니다. 판단 기준의 표현을 변형하여 모델의 표현 대응력을 높였고, 학습 데이터 상에 비정상 케이스가 희귀하다는 특성을 고려하여 데이터 불균형을 보완하는 등의 증강 전략을 적용하였습니다.
사내 LLM 파인튜닝을 담당하는 부서(AI Alignment팀)와의 협업을 통해 파인튜닝을 진행했고, 여러 차례에 걸쳐 모델을 개선한 결과, 11.5B의 경량 모델로도 네트워크 장비 정상/비정상 판단 Task에서 대형 범용 모델(GPT-4류)에 준하는 성능을 달성했습니다. 경량 모델은 적은 GPU 자원으로 운영할 수 있어, 대형 범용 모델 사용 대비 상대적으로 적은 비용으로 서비스 제공이 가능합니다. 이번 실험을 통해 도메인 특화 데이터셋 구축과 파인튜닝으로 경량 모델에서도 충분한 성능을 확보할 수 있다는 가능성을 확인했으며, 향후 유사한 도메인 특화 태스크에 활용할 수 있는 기술적 기반을 마련했습니다.
4. Agentic AI 시스템 품질 관리: Agent 평가와 SOP 검증
장애 진단 작업을 수행하는 Agentic AI 시스템은 SOP 라는 도메인 전문 지식에 기반하여 Agent가 사람 대신 원인 분석 작업을 수행하기에, 해당 시스템의 품질은 SOP 지식 품질과 Agent 동작 품질로 직결됩니다. 저희팀은 두가지 품질을 체계적으로 관리하기 위하여 1) SOP 준수율 기반 Agent 동작 품질 관리, 2) SOP 퀄리티 Agent를 활용한 지식 품질 관리를 수행하고 체계를 구축하였습니다.
4.1. SOP 준수율 기반 Agent 동작 품질 관리
저희는 장애를 진단하는 Agent의 동작 품질을 측정하기 위해 “SOP 준수율”을 핵심 지표로 설정했습니다. SOP 준수율은 현장 전문가들과 함께 구축한 SOP 내 점검 시나리오를 대상으로 Agent가 SOP에 정의된 절차를 얼마나 정확히 따르는지 1~5점으로 평가하고, 전체 점검 시나리오 중 5점(완전 준수)을 만족하는 비율을 산출한 값입니다.
하지만, Agent가 SOP 내 정의된 절차를 준수한 정도를 사람이 일일이 평가하는 것은 불가능하기에, 저희팀은 LLM-as-a-Judge 방식을 도입했습니다. LLM-as-a-Judge는 LLM을 활용해 다른 AI 시스템의 출력을 평가하는 방법론으로, 대규모 평가를 일관된 기준으로 수행할 수 있다는 장점이 있습니다.
LLM-as-a-Judge 평가 방식의 신뢰성을 확보하기 위해, 저희는 명시적인 채점 기준(Rubric)을 프롬프트에 포함시켰습니다. “SOP를 준수하였는가?”와 같은 모호한 표현 대신 “SOP에 정의된 명령어가 모두 실행되었는가", “명령어의 파라미터가 누락 없이 전달되었는가"와 같이 객관적인 판단 기준을 정의하고 이를 프롬프트에 포함시켰습니다. 또한 LLM-as-a-Judge에게 Agent의 동작 Message 로그와 함께 해당 가설의 SOP 원문을 Context로 제공하여, 기대 동작과 실제 동작을 비교 평가하도록 설계하였습니다.
이 평가체계를 처음 적용했을 때 SOP 준수율은 60% 밖에 되지 않았습니다. 그러나, 저희팀은 평가 결과로 부터 취약점을 분석하고 프롬프트와 Tool Call 관련 로직을 개선하는 등의 최적화를 진행했고, 상용 오픈 시점에는 90%대의 SOP 준수율을 달성했습니다. 그리고, 새로운 SOP가 추가되거나 기존 SOP가 변경될 때마다 Agent의 SOP 준수율을 지속적으로 평가하여, 일정 수준 이상의 품질을 유지하는지 모니터링 할 수 있게 되었습니다.
4.2. SOP 퀄리티 Agent를 활용한 지식 품질 관리
저희팀이 현장 마이스터 분들과 함께 SOP를 구축할때 가장 시간이 많이 걸린 부분은 작성된 SOP 내용에 대한 검토 및 보완 작업이었습니다. SOP는 Agent가 현장 마이스터를 대신하여 원인 분석을 수행할 수 있을만큼 구체적이고 체계적으로 정리되어야 했습니다. 그래서 마이스터가 SOP를 작성하면 개발자가 Agent를 동작시켜 결과 품질을 확인하고, 해당 결과에 기반하여 마이스터 분에게 SOP 상에서 어떠한 부분이 모호하고, 어떠한 부분이 AI가 이해하기 어려운지 피드백을 주었습니다. 이후 다시 마이스터 분이 SOP를 수정하고, 개발자가 다시 Agent를 동작시켜보는 과정이 반복되었습니다.
SOP 품질을 향상시키기 위한 일련의 이터레이션 과정을 저희팀은 “SOP 퀄리티 Agent”로 자동화했습니다. 현장 마이스터가 사내 지식 저장소에서 SOP를 작성하면, 해당 내용이 AIONet 플랫폼 내 DB로 동기화됩니다. SOP 퀄리티 Agent는 새로 등록된 SOP에 대해 점검 명령어 시뮬레이션을 수행하고, Agent가 해당 SOP를 이해하고 실행할 수 있는지를 자동으로 평가합니다. 평가 결과 상에 보완 필요 항목이 발견되면 피드백을 생성하여 현장 마이스터에게 전달하고, 수정된 내용이 사내 지식 저장소에 반영되면 다시 검증하는 사이클이 반복됩니다.
SOP 퀄리티 Agent는 세 가지 관점에서 SOP를 검증합니다.
- ① 문법 및 형식 오류 검증: 파라미터 표기 형식, 필드 정의 일치 여부, 명령어 문법 오류를 점검
- ② 내용 구체성 검증: 비교 표현의 임계값, 상태값 명시, 시간 표현의 구체성을 점검
- ③ 데이터 충분성 검증: 명령어 출력에 판단에 필요한 필드와 값이 포함되어 있는지 점검
예를 들어, 현장 마이스터가 초안 작성 단계에서 "인터페이스별 데이터 흐름 수치 확인"이라고만 기술하였는데, Agent는 "장애로 판단되는 구체적인 상황 작성 필요"라는 피드백을 생성하였습니다. 현장 마이스터가 피드백을 반영하여 "개수가 지속적으로 감소하면 서비스 확인 필요"라고 1차 수정하였지만, Agent는 다시 "'지속적'이라는 시간 표현에 대한 구체적 시간 간격 필요"라는 피드백을 생성하였습니다. 현장 마이스터가 피드백을 반영하여 "임계치 OO이상이면 비정상. 또는, 일정 시간 간격(O분)으로 출력결과를 비교하여 변동이 감지되면 비정상."과 같이 구체화된 판단 기준을 추가하여 2차 수정을 하였더니, Agent의 최종 검증을 통과할 수 있었습니다. Agent 기반의 자동화된 피드백 사이클을 통해 저희팀은 SOP 품질 향상에 소요되는 시간을 크게 단축할 수 있었고, 개발자의 개입 없이도 현장 마이스터가 Agent가 이해할 수 있는 수준의 SOP를 작성할 수 있게 되었습니다.
| 단계 | SOP 내용 |
Agent 피드백 |
|---|---|---|
| 초안 작성 |
인터페이스별 데이터 흐름 수치 확인 |
개수 확인 방법 및 장애로 판단되는 구체적인 상황 작성 필요 |
| 1차 수정 |
인터페이스별 데이터 흐름 수치 확인, 개수가 지속적으로 감소하면 서비스 확인 필요 |
'지속적'과 같은 시간 표현에 대한 구체적 시간 간격 필요 |
| 2차 수정 |
[특정 명령어]로 인터페이스별 데이터 흐름 수치 확인, 해당 개수가 임계치 OO이상이면 비정상. 또는, 일정 시간 간격(O분)으로 출력결과를 비교하여 변동이 감지되면 비정상. |
(검증 통과) |
마치며
지금까지, 네트워크 장애 진단을 위한 Agentic AI 시스템을 어떻게 설계하고 구현하였는지, 그리고 그 과정에서 고민했던 포인트는 무엇이고 이를 어떻게 해결했는지, 실무자 레벨에서 궁금한 내용들을 좀 더 상세하게 설명드렸습니다.
저희팀이 이번 프로젝트를 진행하며 크게 느낀 점이 세 가지가 있습니다. 우선, 현업의 비즈니스 로직을 AI로 전환할 때, 핵심 로직은 Agent 코드가 아닌 프롬프트와 지식 형태로 구성해야 한다는 점이었습니다. 프로젝트 초기에는 Agent 코드 개발의 비중이 높았지만, 후반으로 갈수록 SOP 지식 구축과 프롬프트 최적화의 비중이 훨씬 높아졌습니다. 장애를 진단하는 메인 비즈니스 로직도 Supervisor Agent의 프롬프트에 녹여내어, 로직 변경 시 Agent 코드 수정 없이 프롬프트 수정만으로 대응할 수 있는 구조를 만들었습니다. 결국 이 프로젝트의 핵심 기술은 최신 AI Agent 기술 그 자체라기 보다는, 현장에서 쌓아온 경험과 판단 기준을 AI가 이해할 수 있는 형태로 구조화하는 것이었습니다.
두 번째로, Agentic AI 시스템은 이를 뒷받침하는 인프라와 데이터가 상당히 중요하다는 점이었습니다. 네트워크 각 장비의 상태와 연결 관계가 데이터로 정리되어 있어야 하고, 실시간으로 장비 상태를 조회하고 분석할 수 있는 인프라가 갖춰져 있어야 장애에 신속히 대응할 수 있습니다. 이러한 데이터 기반과 운용망 연동 인프라가 있었기에 AI Agent가 제 역할을 할 수 있었습니다.
마지막으로, 부문 간의 협업 시너지가 무엇보다 중요하다는 점이었습니다. 기술혁신부문에서 Agentic 로직 개발을 담당하는 동안, 네트워크부문 담당부서에서는 AIONet 웹 개발과 운용망 연동 인프라를 구축하였습니다. 특히 실제 운용 중인 네트워크 장비와 AI 시스템을 안전하게 연결하는 것은 쉽지 않은 작업이었는데, 이를 네트워크부문에서 안정적으로 구현해 준 덕분에 Agent가 실시간으로 장비 상태를 점검할 수 있게 되었습니다. 서로 다른 전문성을 가진 조직이 공동의 목표 아래 긴밀하게 소통하며 각자의 역할을 수행하였기에, AIONet이 KT 운용망에 안정적으로 론칭될 수 있었다고 생각합니다.
감사의 말
이번 프로젝트에는 여러 부서의 많은 분들이 함께해 주셨습니다. 특히, 이번 글에서 다룬 Agent 개발 파트를 이끌며, 부족한 리드임에도 끝까지 잘 따라와주신 김보민, 김소영, 오승희 님께 정말 감사드립니다.
기술혁신부문 D-Model 부서에서 권력환 팀장을 비롯하여, 신성진, 공지환, 임수진, 심훈용, 이도연, 장지호, 김남우, 남현서, 김보민, 김소영, 오승희 님이 함께해주셨고, 네트워크부문 AI운용혁신 및 AX기술지원 부서의 이호송 팀장, 김경열, 김승주, 김준혁, 정태진, 김민섭, 박주연, 이성현, 채동윤, 신민준, 전상영 님이 함께해주셨습니다.
그리고 현장 네트워크 운용 전문가이신 이현정 마이스터, 유성덕 마이스터, 윤지현 마이스터 님께서 도메인 지식 구축에 핵심적인 기여를 해주셨습니다. 수십 년간 현장에서 쌓아오신 경험과 노하우를 공유해 주신 덕분에, 시스템이 동작할 수 있었습니다.
이외에도 자체 파운데이션 LLM 모델(믿:음 K 2.0) 파인튜닝을 맡아주신 AI Alignment 부서의 원세연, 남상하, 심정용 님, 서비스 기획 및 디자인을 담당해 주신 X-Design센터의 유주원, 류정아 님께도 감사드립니다.
열정을 가지고 함께해 주신 모든 분들 덕분에 의미 있는 결과를 만들 수 있었습니다. 감사합니다.