Strands Agents와 Amazon Bedrock AgentCore을 이용한 발전설비진단 구현하기

발전소에는 목적이 다른 시스템과 문서가 함께 존재합니다. 원격 진동 고장진단 시스템(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 문서를 갱신하고, 데이터 연결 방식이 바뀌면 MCP 도구를 수정합니다. 원천 시스템을 보호하기 위해 MCP에는 조회 도구만 제공합니다. 현재 Agent에서 사용하는 MCP는 다른 agent와 공유되지 않아서 AgentCore runtime과 함께 배포되지만, 추후 확장시는 별도 AgentCore Runtime이나 AgentCore Gateway로 분리될 수 있습니다.

그림 1. Strands Agents에 Agent Skills와 조회 전용 MCP 도구를 연결한 공통 구성

두 사례는 검증 범위가 서로 다릅니다. 이 글에서는 확인된 결과와 향후 목표 구성을 다음과 같이 구분합니다.

사전 준비 사항

• 서울 리전(ap-northeast-2)을 사용할 AWS 계정과 배포 권한을 준비합니다.
• Amazon Bedrock 콘솔의 Playground에서 사용할 모델이 동작함을 확인합니다.
• AgentCore Runtime용 arm64 컨테이너 이미지를 빌드할 수 있는 Docker 환경을 준비합니다.
• 폐쇄망 연결을 검토하여 Direct Connect 또는 Site-to-Site VPN과 필요한 VPC 엔드포인트를 설계합니다.

사례 1. RVMS에 진단 보조 계층 연결하기

첫 번째 사례는 이미 운영 중인 RVMS가 감지한 이상 신호를 바탕으로 전문가의 진단 순서를 적용하는 접근입니다. 다음 단계 1.1~1.3에서는 판단 절차를 Skill로 분리하고 진동 데이터를 조회 전용 MCP로 연결하는 설계를 설명합니다.

단계 1-1. 판단 절차와 데이터 접근 분리하기

도메인 지식을 시스템 프롬프트에 모두 넣으면 질문과 무관한 규칙까지 매 호출에 포함됩니다. 규칙 하나를 바꿀 때도 전체 프롬프트를 다시 검토해야 하고, 판단 절차와 데이터 연결 코드의 변경 주기가 서로 얽힙니다.

이를 피하기 위해 두 체계로 나눴습니다.

Skill의 description에는 적용할 질문과 응답의 한계를 함께 적습니다. 다음 예시는 RVMS 진동 분석 질문에만 Skill을 로드하고, 결과를 확정 판정이 아닌 전문가 검토용 초안으로 제한합니다.

---
name: vibration-diagnosis
description: RVMS 진동 분석 결과로 회전설비 이상 원인 후보와 판단 근거를 정리한다.
  진동 상승, FFT 분석, 원인 문의, 진단 보고서 초안 요청에 사용한다.
  확정 판정이 아니라 전문가 검토용 초안 작성이 목적이다.
---

단계 1-2. 진동 진단 순서를 Skill로 옮기기

RVMS는 임계치 초과를 정확하게 감지하지만, 복합 원인이나 운전조건 변화, 센서 이상이 겹치면 규칙만으로 원인을 설명하기 어렵습니다. 전문가는 여러 지표를 정해진 순서로 대조합니다. 이 순서를 Skill에 다음과 같이 기록했습니다.

## 판정 순서
1. Trend: 변화 시작 시점과 상승 속도 확인
2. FFT (Fast Fourier Transform): 1X, 2X, 서브싱크로너스, 결함주파수 성분 비교
3. Orbit: 형상과 축중심선 변화 확인
4. 운전조건: 부하, 회전수, 온도 변화와의 동조 여부 확인
5. 정비이력: 최근 작업과 부품 교체 여부 확인

스펙트럼 판독 규칙은 별도 Skill로 분리해 필요할 때만 불러옵니다. 예를 들어 1X 성분은 불평형과 정렬 상태를, 2X 성분은 정렬 불량과 커플링 이상을 검토하는 단서가 됩니다. 저주파 구간에서 급락하는 Ski-slope 형상처럼 수치가 아니라 형상으로 구분해야 하는 패턴도 함께 기록합니다.

보고서 서식도 Skill로 관리할 수 있습니다. 일일 진단 보고서와 이상 설비 정밀 진단 보고서의 구조를 포함하면 에이전트 결과를 담당자가 바로 검토할 수 있는 초안으로 정리할 수 있습니다.

단계 1-3. 조회 전용 MCP로 진동 데이터 연결하기

진동 데이터는 MCP 서버를 통해서만 읽습니다. get_trend, get_spectrum, get_orbit, get_alarms, get_operating_context, get_maintenance_history 도구가 각각 추세, FFT, Orbit, 경보, 운전조건, 정비이력을 조회합니다.

쓰기 도구를 제공하지 않는 이유는 원천 시스템 변경 경로를 애플리케이션 구조에서 제거하기 위해서입니다. 외부 웹 검색 도구도 연결하지 않아 진단 근거가 승인된 내부 데이터와 문서 범위를 벗어나지 않게 합니다.

응답에는 원인 후보만 아니라 근거 참조와 데이터 한계를 필수로 포함합니다. evidence_refs가 비어 있거나 필요한 데이터가 부족하면 확정적인 답을 만들지 않고, 추가로 확인할 항목을 반환합니다. 이 방식이 근거 없는 원인 후보를 완전히 제거한다고 보장할 수는 없습니다. 다만 검증 가능한 근거와 제한 사항을 응답 계약에 포함해 검토자가 판단할 수 있게 합니다.

폐쇄망 연결 구성에서는 인터넷 게이트웨이와 NAT 게이트웨이를 사용하지 않습니다. 필요한 AWS 서비스는 VPC 엔드포인트로 연결하고, 내부 ALB를 진입점으로 사용합니다. 발전소 사내망은 Direct Connect 또는 Site-to-Site VPN을 통해 AWS VPC에 연결합니다.

그림 2. RVMS 연계를 위한 폐쇄망 연결 아키텍처

다음 화면은 RVMS 감시 화면에 진단 보조 대화를 결합한 합성 프로토타입입니다. 운전원이 감시 화면을 벗어나지 않고 진단 현황과 판단 기준을 함께 확인하는 사용자 경험을 검토하기 위해 제작했습니다.

그림 3. RVMS 감시 화면과 진단 보조 대화를 결합한 합성 프로토타입

사례 2. Plant Operation Supporter로 운전 지식 연결하기

Plant Operation Supporter는 RVMS의 부가 기능이 아니라, 경보 목록과 운전 매뉴얼, 로직 도면에 흩어진 운전 지식을 하나의 작업 흐름으로 연결하기 위해 별도로 구현한 운전 지원 PoC입니다. Strands Agents는 질문을 ㅁ고정된 검색 경로에 넘기는 라우터가 아니라, 질문과 도구 결과를 차례로 해석하면서 필요한 Skill과 다음 도구를 선택하는 오케스트레이터로 동작합니다.

그림 4. Plant Operation Supporter

Strands Agents가 한 질문을 처리하는 과정

예를 들어 운전원이 ‘기동 중 BPT #3 온도만 상승합니다. 계속 기동해도 됩니까?’라고 묻습니다. 이때 Agent는 하나의 RAG 검색 결과를 곧바로 답으로 내보내지 않습니다.

• 현재 상태: pos_sequence_state로 기동 단계와 경과시간을 확인합니다.
• 절차 선택: paju-startup-diagnosis Skill로 확인 순서와 중단 기준을 적용합니다.
• 근거 수집: kb_alarm, kb_search, kb_manual_fts, kb_logic, kb_trace로 경보·절차·신호 관계를 조회합니다.
• 관찰·재계획: 결과가 모호하면 추가 조회하거나 되묻습니다. 문서명·페이지·Rev. 근거가 없으면 답하지 않습니다.

다음 단계 2-1~2-2에서는 Agent가 선택할 수 있도록 운전 지식을 네 개의 검색 트랙과 조회 도구로 구성한 과정을 설명합니다. 단계 2-3에서는 이 도구와 Skill을 실제 Strands Agents에 등록하고, 단계 2-4에서는 검색 결과와 최종 응답을 나눠 평가합니다.

단계 2-1. 운전 지식을 네 개의 검색 트랙으로 나누기

Plant Operation Supporter는 경보 5,996건, 운전 매뉴얼 64권, 로직 도면 15,614장에서 시작했습니다. 처음에는 모든 자료를 하나의 벡터 인덱스에 넣었지만, 21개 평가 질문에서 필요한 답을 찾지 못했습니다.

원인은 KKS 태그의 성격에 있었습니다. KKS 태그는 의미가 아니라 설비를 구분하는 식별자입니다. 문자열이 비슷한 두 태그가 임베딩 공간에서 가깝더라도 실제로는 서로 다른 설비일 수 있습니다. 따라서 태그 조회를 벡터 유사도에 맡기면 질문하지 않은 설비의 조치사항이 반환될 수 있습니다.

질문의 성격에 따라 다음 네 개의 트랙으로 검색 경로를 분리했습니다.

그림 5. 질문 유형에 따라 분리한 네 개의 검색 트랙과 평가 결과

트랙 A와 C에서 정확 일치와 그래프 관계를 먼저 확인해, 식별자와 도면 연결에서 발생할 수 있는 오답을 줄였습니다.

단계 2-2. 검색 트랙을 구현하고 지식 영역 격리하기

트랙 A의 경보 인덱스는 컨테이너 이미지에 78MB 크기의 경보 인덱스를 컨테이너 이미지에 함께 포함했습니다. 조회 시 네트워크 호출이나 임베딩 계산 없이 태그를 정규화한 뒤 완전 일치로 찾습니다. 태그 조회가 빈번하고 정확성이 가장 중요한 경로이기 때문에 이 방식을 선택했습니다.

트랙 B는 Bedrock Knowledge Bases의 벡터 검색과 매뉴얼 전문 검색을 함께 사용합니다. 구조화된 절차 데이터만으로 해결하지 못한 조건부 운전 질문은 매뉴얼 원문 청크를 함께 검색해 필요한 문장을 찾았습니다.

제품 문서가 발전소 운전 답변에 섞이지 않도록 데이터 소스와 Amazon S3 접두어를 분리하고, 객체에 plant_scope 메타데이터를 추가했습니다. 검색은 기본적으로 발전소 문서만 대상으로 하며, 제품 질문일 때만 범위를 명시합니다.

retrievalConfiguration = {
    "vectorSearchConfiguration": {
        "numberOfResults": k,
        "filter": {"equals": {"key": "plant_scope", "value": "platform"}},
    }
}

이 격리는 인용의 의미를 보존합니다. 제품의 기본 동작과 파주 발전소의 실제 운전 절차가 섞이면, 제품 기본값을 현장 설정처럼 인용할 수 있기 때문입니다.

도면에는 그려져 있지만 추출 텍스트에는 없는 정보도 있었습니다. 365페이지를 비전 모델로 판독해 텍스트층에서 찾지 못했던 KKS 태그 236개와 조건부 주석 291건을 추출했습니다. 이렇게 확보한 관계는 트랙 C의 도면 페이지 연결에 사용했습니다.

단계 2-3. Strands Agents 실행 루프와 런타임 구성하기

PoC에서는 plant-kb와 pos-state MCP 서버에서 조회 도구를 가져오고, 경보 조회·절차 조회·기동 진단 Skill을 AgentSkills 플러그인에 등록했습니다. 핵심은 모델만 설정하는 것이 아니라, 모델과 시스템 프롬프트, 도구, Skill, 대화 이력을 하나의 Agent에 결합하는 것입니다. 다음 코드는 실제 구성에서 에이전트 생성 부분만 줄여 표현한 예시입니다.

tools = mcp_manager.start(["plant-kb", "pos-state"])
skills = AgentSkills(skills=skill_dirs)

agent = Agent(
    model=build_model(model_name),
    system_prompt=BASE_SYSTEM_PROMPT,
    tools=tools,
    plugins=[skills],
    conversation_manager=conversation_manager,
)
result = agent(question)

agent(question)을 호출하면 한 번의 검색 함수가 실행되는 것이 아닙니다. 도구가 필요하면 Strands Agents SDK의 실행 루프가 모델이 요청한 조회 전용 MCP 도구를 호출하고, 그 결과를 toolResult 메시지로 모델에 돌려줍니다. 모델은 반환값을 본 뒤 다음 도구를 고르거나 최종 응답을 끝냅니다. 웹 UI에는 이 실행 이벤트와 최종 답변을 SSE로 전달해, 어떤 근거를 거쳐 답했는지 확인할 수 있게 합니다.

목표 구성에서는 arm64 컨테이너 이미지를 AgentCore Runtime에 배포하고, 웹 애플리케이션은 Amazon ECS on AWS Fargate에 배포합니다. 사용자 요청은 invoke_agent_runtime으로 전달하고 응답은 Server-Sent Events(SSE)로 스트리밍합니다. 설비와 기간, 이상 사례별로 runtimeSessionId를 분리해 서로 다른 진단 세션이 섞이지 않게 합니다.

버전 갱신 시 관리형 세션 저장소가 초기화될 수 있으므로 장기 세션 파일은 S3 Files를 /mnt/workspace에 마운트해 보존하는 구성을 검토했습니다. SSE 경로는 CloudFront와 ALB 구간에서 각각 프레임 도착 간격을 측정해 버퍼링 여부를 확인합니다.

단계 2-4. Plant Operation Supporter를 평가셋으로 검증하기

평가에 사용한 21건은 경보 정확 조회 7건, 경보 집계 3건, 절차 2건, 개념 1건, 도면 그래프 2건, 경보와 도면을 함께 찾는 트랙 교차 3건, 존재하지 않는 태그·범위 밖 발전소·중의적 경보명을 확인하는 함정 질문 3건으로 구성했습니다. 같은 21건을 대상으로 검색 계층과 최종 응답 계층을 각각 판정했습니다.

검색 계층의 21/21은 모든 질문에서 판정에 필요한 원문 데이터나 문서를 찾았다는 의미입니다. 응답 계층은 검색 결과를 최종 답변에 정확한 필드와 근거 형식으로 반영했는지를 더 엄격하게 검사했습니다. A5는 원문 경보명 전체를 그대로 표시하지 않았고, C1은 17쪽 커넥터 A의 페이지 연결값을 답했지만 근거 참조가 평가 계약에 맞게 남지 않았습니다. D1은 경보 조치와 관련 도면을 서술했지만 응답 구조에서 diagram_doc 필드가 누락됐습니다. 검색은 성공했지만 이 세 건이 최종 응답 판정에서 탈락해 18/21이 됐습니다. 함정 질문 세 건은 모두 통과했습니다.

평가 질문을 경보 정확 조회, 경보 집계, 절차, 개념, 도면 그래프, 트랙 교차, 함정으로 분류하면 실패 원인을 빠르게 좁힐 수 있습니다. 실제로 트랙 교차 질문에서 로직 시트 조회 도구와 매뉴얼 도면 페이지 조회가 섞인 문제를 발견했고, 도면 페이지 전용 조회 경로를 분리해 해결했습니다.

결론

이 글에서는 발전설비의 진단과 운전 지식을 Strands Agents에 연결하는 두 가지 접근을 살펴봤습니다. 여기서 Agent의 역할은 검색 결과를 문장으로 바꾸는 데 그치지 않습니다. 질문과 현재 상태를 관찰하고, 필요한 Skill과 조회 도구를 선택하고, 도구 결과를 다시 확인해 다음 행동을 정하며, 근거가 부족하면 되묻거나 멈추는 실행 루프를 담당합니다. RVMS 사례는 이 루프에 전문가의 진단 순서를 연결했고, Plant Operation Supporter는 식별자·절차·도면 관계를 서로 다른 도구로 제공했습니다.

평가 결과는 검색 품질과 응답 품질을 분리해야 하는 이유를 보여 줍니다. 정확 일치와 트랙 분리 후 검색 계층은 21/21을 통과했지만, 응답 계층은 18/21이었습니다. 특히 KKS 태그처럼 의미보다 식별이 중요한 데이터는 벡터 검색만으로 처리하지 않고 정확 일치와 관계 조회를 함께 설계해야 합니다.

발전소 현업 엔지니어가 판단 순서를 문서로 표현하고 데이터 접근을 제한된 도구로 정의할 수 있다면, 도메인 지식을 에이전트에 단계적으로 연결할 수 있습니다. 같은 방식은 설비 진단뿐 아니라 전문가의 판단 순서와 근거가 중요한 다른 업무에도 적용할 수 있습니다.

관련 자료

• Amazon Bedrock AgentCore 개발자 안내서
• Amazon Bedrock Knowledge Bases
• Amazon Bedrock Guardrails
• Amazon Bedrock 콘솔
• Introducing Strands Agents, an Open Source AI Agents SDK
• Strands Agents 문서
• Strands Agent의 AgentCore 배포 및 활용