발전소에는 목적이 다른 시스템과 문서가 함께 존재합니다. 원격 진동 고장진단 시스템(Remote Vibration Monitoring System, RVMS)은 회전설비의 베어링 진동을 상시 감시하고 임계치 초과를 알려 줍니다. 운전 매뉴얼과 로직 도면에는 조치 절차와 설비 관계가 기록되어 있습니다. 하지만 경보가 발생한 뒤 원인 후보를 좁히고, 여러 지표를 비교하고, 필요한 근거를 찾아 조치 순서를 정하는 일은 여전히 전문가의 경험에 의존합니다. […] ||
발전소에는 목적이 다른 시스템과 문서가 함께 존재합니다. 원격 진동 고장진단 시스템(Remote Vibration Monitoring System, RVMS)은 회전설비의 베어링 진동을 상시 감시하고 임계치 초과를 알려 줍니다. 운전 매뉴얼과 로직 도면에는 조치 절차와 설비 관계가 기록되어 있습니다. 하지만 경보가 발생한 뒤 원인 후보를 좁히고, 여러 지표를 비교하고, 필요한 근거를 찾아 조치 순서를 정하는 일은 여전히 전문가의 경험에 의존합니다.
경보 한 건의 조치사항을 확인할 때도 5,996건의 경보 목록, 64권의 운전 매뉴얼, 15,614장의 로직 도면을 오가야 합니다. 진동 상승이 정렬 불량인지 유막 불안정인지, 센서 이상인지 판단하려면 추세와 주파수 스펙트럼, Orbit, 운전조건, 정비이력을 함께 확인해야 합니다.
나래에너지서비스 발전AX팀은 AWS GenAI Boost Program에서 이 문제를 두 방향으로 검토했습니다. 첫 번째는 운영 중인 RVMS에 진단 보조 계층을 설계하는 것이고, 두 번째는 흩어진 운전 지식을 Plant Operation Supporter로 묶는 것입니다. 출발점은 달랐지만 두 사례 모두 판단 절차와 데이터 접근을 분리하는 구조로 수렴했습니다.
이 글의 중심은 Strands Agents로 구성한 운전 지원 Agent입니다. Agent는 질문을 받으면 전문가의 판단 절차를 담은 Agent Skill을 선택하고, 조회 전용 MCP (Model Context Protocol) 도구로 경보·매뉴얼·로직 도면과 현재 운전 상태를 확인합니다. 도구 결과를 다시 관찰한 뒤 다음 조회, 확인 질문, 최종 응답 중 하나를 결정하며, 근거가 부족하면 답을 만들지 않습니다. 이렇게 구성한 Agent를 Amazon Bedrock AgentCore Runtime에 배포하고 폐쇄망과의 연결을 고려한 실행 구조와 평가 방법을 함께 설명합니다. 운전 질문은 단순한 문서 검색만으로 해결되지 않습니다. 같은 경보라도 기동 단계, 부하, 직전 정비 작업에 따라 확인 순서가 달라지고, KKS (Kraftwerk-Kennzeichen-System) 태그처럼 의미보다 정확한 식별이 중요한 데이터와 도면의 연결 관계도 함께 살펴야 합니다. 따라서 이 글에서는 한 번의 검색으로 답을 생성하는 방식 대신, Strands Agents가 현재 상태를 확인하고 필요한 도구를 고른 뒤 결과를 관찰해 다음 행동을 정하는 과정을 중심으로 다룹니다. 두 PoC의 구현 범위와 목표 아키텍처를 구분하고, 검색 성공과 최종 응답 성공을 별도로 측정해 확인된 결과만 설명합니다.
솔루션 개요
Strands Agents는 미리 정한 검색 API를 한 번 호출해 답을 만드는 챗봇이 아닙니다. 모델은 시스템 프롬프트와 현재 대화, Agent Skills 설명, 사용 가능한 도구 스키마를 함께 보고 다음 행동을 선택합니다. 도구가 필요하면 Strands Agents가 조회 전용 MCP 도구를 실행해 결과를 다시 모델에 전달하고, 모델은 그 결과를 관찰해 다음 도구를 호출할지, 대상을 되물을지, 근거가 충분하므로 답을 끝낼지를 다시 판단합니다. 질문에 따라 호출 순서와 횟수가 달라지는 이 모델 주도 실행 루프가 이 구성에서 에이전트가 맡는 역할입니다.
이 구조에서 Skill과 MCP의 역할은 분명합니다. Skill은 전문가가 읽고 수정할 수 있는 마크다운 문서이고, MCP는 데이터에 접근하는 통로입니다. 진단 순서가 바뀌면 Skill 문서를 갱신하고, 데이터 연결 방식이 바뀌면