가격 예측부터 입찰 전략까지, LG에너지솔루션의 Amazon Bedrock AgentCore 기반 ERCOT 분석 에이전트 구축기

– 박경수(AWS Solutions Architect), 장현태(AWS Solutions Architect),, 백승연 (LG에너지솔루션, Product Owner) · 최수아 (LG에너지솔루션, Data Scientist

“실시간으로 가격이 바뀌는 전력시장에서 최대 수익을 내려면 얼마에 입찰해야 할까? 그 가격을 예측하고 입찰 전략까지 분석해주는 에이전트가 있다면?” LG에너지솔루션 전력거래솔루션은 이 한 문장에서 출발했습니다.

LG에너지솔루션은 배터리 셀부터 ESS(Energy Storage System)까지 아우르는 글로벌 배터리 기업입니다. 하지만 배터리의 가치는 배터리를 만드는 것에서 끝나지 않습니다. 전력시장과 연결된 ESS 자산을 언제, 어떻게 운영하느냐에 따라 그 가치와 수익성이 달라지기 때문입니다.

그래서 LG에너지솔루션은 배터리와 ESS 자체뿐 아니라, 이를 실제 전력시장 안에서 효과적으로 운영하고수익을 극대화할 수 있는 솔루션까지 함께 만들고 있습니다. 현재 미국 최대 규모 도매전력시장 중 하나인 ERCOT(Electric Reliability Council of Texas)을 대상으로 BESS(Battery Energy Storage System) 자산의 입찰최적화 솔루션을 개발 중입니다.

이번 글에서 소개할 AI 에이전트 역시 이 문제를 풀기 위한 접근 중 하나입니다.

전력거래 업무는 데이터 수집 – EDA(Exploratory Data Analysis) – 모델 개발 – 사후 분석이 반복되는 구조입니다. 이 작업을 자연어 질의로 대체하기 위해 사내 전력거래솔루션에 탑재할 분석 에이전트를 개발했습니다. 분석가가 “지난주 A 노드의 DAM(Day-Ahead Market)·RTM(Real-Time Market) 가격 차이를 보여주고, 현재 규제 조건에서 어떤 입찰 전략이 유리했는지 분석해줘”라고 물으면, 에이전트는 질문 의도에 따라 적절한 MCP를 선택합니다. 사용자는 선택된 MCP를 통해 반환된 입찰 이력·BESS 사양·ERCOT LMP(Locational Marginal Price, 지역별 한계가격) 및 DAM/RTM 정산 데이터를 근거로 수익 최적화 전략이나 가격 예측 모델 추천 결과 등을 업무에 활용할 수 있습니다.

이 글에서는 여러 MCP(Model Context Protocol) 서버를 오케스트레이션하는 분석 에이전트를 설계하고 실제 업무에 적용하기까지의 과정을 공유합니다. 어떤 구조로 만들었는지, 그리고 Amazon Bedrock AgentCore와 Amazon Athena, Amazon Bedrock Guardrails, Amazon CloudWatch로 응답 속도 · 분석 품질 · 보안 통제 · 운영 효율을 각각 어떻게 확보했는지 순서대로 설명합니다.

매일 반복되는 Trader의 업무에 주목하다

ERCOT(Electric Reliability Council of Texas)은 10,000개가 넘는 LMP(Locational Marginal Price, 지역별 한계가격) 노드에서 시간·지점별로 가격이 형성되는 시장입니다. BESS (Battery Energy Storage System)운영자는 전력 가격이 낮을 때 충전하고 높을 때 방전하기 위해 수많은 노드별 시장 가격을 미리 예측하고 이를 바탕으로 최적화된 입찰 가격을 산출, 입찰 결과를 분석하여 더 나은 입찰서를 작성하는 과정을 반복합니다. 하지만 DAM(Day-Ahead Market)은 전일 10시에 입찰이 마감되고, RTM(Real-Time Market)은 5분 단위로 거래가 이뤄지기 때문에 이러한 작업을 사람이 반복하는 것은 상당한 비효율을 야기합니다.

그림 1. 전력거래 업무의 세 단계와 반복되는 작업

각 단계별로 반복되는 작업에서 비효율이 발생하는 원인은, 1) 반복적인 대용량 데이터 분석 2) 데이터 정성 정보 관리 부재 3) 분석리포트 반복 작성으로 정리될 수 있었습니다. 이를 자연어 질의로 대체하여 사용성을 높이기 위해, LG에너지솔루션은 응답속도 및 분석품질 개선, 보안관리에 주목하였습니다.

Architecture

그림 2. Amazon Bedrock AgentCore를 중심으로 구성한 아키텍처

전력거래솔루션 Agent는 크게 네 가지로 구성됩니다. 데이터파이프라인에서는 시장 내 전력·기상·계통·입낙찰 데이터가 AWS Glue로 수집·변환하여 Amazon S3에 저장, Glue Data Catalog에 스키마를 등록됩니다. 이 카탈로그는 향후 Agent내 LLM이 Athena Data Analyzer MCP를 호출해 Athena로 질의할 때 활용됩니다. 에이전트 실행 계층은 사용자 질의를 처리하는 계층으로, 사용자의 질의는 EC2를 거쳐 Amazon Bedrock Guardrails로 먼저 검증된 뒤 LLM에 전달됩니다. LLM은 Amazon Bedrock AgentCore Runtime에 배포된 MCP를 선택적으로 호출하고, 두 개 이상의 결과가 나오면 Synthesizer가 이를 교차 해석합니다. Agent에서 사용하는 MCP들은 AgentCore Runtime에 Stdio 방식으로 적용되었고, 향후 MCP 서버를 다른 서비스와 공유하게 될때에는 AgentCore Gateway과 AgentCore Runtime을 이용해 분리될 예정입니다.

상태저장 계층에서는 이렇게 쌓이는 사용자별 Task와 질문 단위의 대화 기록은 S3 Files(Task DB)에, 에이전트 내부 작업 상태는 Checkpoint에 분리해 저장하고, 관측 및 통제 계층에서 CloudWatch로 전송된 실행 로그와 토큰 사용량은 Logs와 Metrics Insights로 모니터링 및 분석을 수행하고, 입출력 안전성은 Amazon Bedrock Guardrails가 담당하게 됩니다.

단계 요약

다양한 목적에 범용적으로 사용할 수 있도록 Agent를 구현하고, 운영 가능한 수준으로 끌어올리기 위해 세 개의 목표를 설정하였습니다.

목표 1: 내부 데이터와 외부 소스를 참조하는 MCP를 구성합니다.
목표 2: 사용자 페르소나별 Guardrails와 AgentCore Evaluations로 안전성과 품질을 검증합니다.
목표 3: 사용자별 Context를 격리 저장하고 CloudWatch로 사용량을 추적해 운영과 과금 환경을 구축합니다.

목표 1: 내부 데이터 및 외부 소스를 참조하는 MCP 구성

전력거래 관련 질문에 답변하기 위해서는 내부에 적재된 데이터를 분석함과 동시에 뉴스, 시장 규제 등의 외부 맥락을 참고해야 합니다. 이를 위해 정보의 성격에 따라 MCP를 개별 생성하였고, 질문 의도에 맞는 적절한 MCP가 선택되도록 구성했습니다. 상세한 작업 사항은 다음과 같습니다.

내부 데이터 분석 MCP 생성: 내부에 산재되어 있는 데이터들 중 질의에 적절한 테이블을 선별하여 분석합니다. MCP는 가격, 기상, 발전, 부하 등 데이터 성격에 따라 개별로 구성하였습니다.
Web Search MCP 생성: 외부 웹 검색 엔진을 사용하여 데이터 센터 설립, 재생에너지 정책 변경 등 데이터로 포착할 수 없는 외부 사건에 대한 정보를 수집합니다.
ERCOT 전력거래 시장 규제 자문 MCP 생성: ERCOT 전력거래 시장의 규제는 매우 복잡하고 잦은 변경이 이루어지기에 확인과 해석이 어렵습니다. 이러한 규제를 해석 및 반영하여 가격, 입찰 전략 등을 분석합니다.
유기적 MCP 연결: MCP 실행 후에는 유효한 근거가 확보됐는지 검증을 진행한 뒤, 검증된 결과 2개 이상일 경우 Synthesizer가 각 MCP 결과에 대해 교차 해석을 수행하여 종합 결과를 도출합니다.

MCP 실행 코드 예시는 다음과 같습니다.

def classify_query_capabilities(question: str) -> frozenset[str]:
    """Detect internal/web/regulation capabilities requested by the question."""
    caps: set[str] = set()
    # ...
    if _task_requests_internal_analysis(question):
        caps.add(CAP_INTERNAL)
    if task_requests_external_market_context(question):
        caps.add(CAP_WEB)
    if task_requests_regulation_context(question):
        caps.add(CAP_REGULATION)
    return frozenset(caps)

목표 2: 사용자 페르소나별 Guardrails와 AgentCore Evaluations 체계 구축

Agent는 사내 전력거래 데이터와 입찰 전략까지 다루기 때문에, 누가 질문했는지에 따라 접근 가능한 범위가 달라야 합니다. 프롬프트 강제는 모델이 항상 따른다는 보장이 없기에 모델과 별개로 판단하여 답변을 차단할 수 있는 AWS Bedrock Guardrails를 사용하였습니다. 사용자 그룹에 따른 Guardrails 적용은 다음과 같은 과정에 따라 수행되었습니다.

사용자 페르소나를 일반 User와 Authorized User로 나누고, 각각에 서로 다른 Bedrock Guardrail을 연결합니다.
두 페르소나 모두에 유해 콘텐츠 필터(hate, insults, sexual, violence, misconduct)를 적용하되, 일반 User에는 더 엄격한 임계값을 설정합니다.
금지 주제(Denied Topics)를 정의합니다. 일반 User에게는 타 사용자 정보 노출, 권한을 우회한 데이터 접근, 프롬프트 인젝션, MCP 라우팅 정책 노출, 악의적 활동 지원, 내부 로그, 내부 아키텍처, 자격 증명 등의 주제를 차단합니다.

금지 주제는 입출력을 분리해 설정하여 “동작 원리가 궁금하다”와 같은 정상적 질문 시 차단되지 않고 모델에 입력되지만, 모델의 답변에 상세한 내부 로직이 포함될 시 차단되도록 구성하였습니다. 반대로 자격 증명 요구, 악의적 활동 지원처럼 질문 자체가 공격 시도인 경우는 입력과 출력을 모두 차단했습니다. 금지 주제 예시는 다음과 같습니다.

그림 3. 금지 주제별 입력·출력 차단 정책 예시

또한, LLM의 답변이 적절하게 이루어지고 있는지에 대한 지속적인 모니터링 및 평가를 위해 AgentCore Evaluations의 빌트인 metrics를 활용하여 품질 평가 체계를 구축하였습니다. Correctness, Faithfulness, GoalSuccessRate, Helpfulness로 최종 답변의 품질을 평가하고, InstructionFollowing, Refusal, ResponseRelevance, ToolSelectionAccuracy로 지시 준수와 도구 선택 경로를 함께 확인합니다. 해당 빌트인 평가자들을 사용하여 과거 답변 내용에 대한 on-demand 평가와 사용자에게 전달 되고 있는 답변의 실시간 평가를 수행할 수 있습니다.

목표 3: 사용자별 Context 관리와 사용량 모니터링 구성하기

Agent를 여러 사용자에게 제공하기 위해 필요한 작업이 두가지 있습니다. 하나는 사용자 간 대화 맥락이 섞이지 않도록 격리하며 대화 내용을 효율적으로 관리하는 것이고, 다른 하나는 누가 얼마나 썼는지를 측정해 비용을 배분하는 것입니다.

그림 4. 목적에 따른 사용자 context 관리와 사용자 간 격리

사용자의 대화는 기본적으로 AWS S3에 저장됩니다. 이때 저장 대상 및 위치는 용도에 따라 두 가지로 나뉩니다. UI 복원용 대화 기록(질문·답변 메시지)은 Task DB에, 내부 작업 상태(조회한 데이터, 도구 실행 결과, 모델용 대화 문맥)는 Checkpoint에 각각 S3 Files로 저장합니다. UI를 복원할 때는 질문과 답변 메시지만이 필요합니다. 하지만 이때 도구 실행 결과가 함께 들어 있으면 오히려 불필요하게 큰 페이로드를 매번 읽게 됩니다. 반대로 모델에 전달할 문맥을 복원할 때는 UI용 메시지만으로는 부족합니다. 두 목적을 분리하면서 적재량과 복원 지연을 함께 줄일 수 있었습니다. 이 Task DB와 S3 files를 사용자별로 개별 저장소에 적재함으로써 다른 사용자의 대화와 Checkpoint에 접근할 수 없도록 격리하였습니다.

사용량 추적은 CloudWatch에 전송된 실행 로그에서 사용자 ID, 모델명, 입력·출력 토큰을 함께 기록하는 방식으로 구성했습니다. 이를 통해 사용자별·모델별 사용량을 집계할 수 있게 되었고, 서비스 단위의 개별 과금 체계를 설계하기 위한 기반 데이터를 확보했습니다.

결과

이 글에서는 전력거래솔루션 안에 탑재될 Agent를 구성한 뒤, 운영을 위한 기반 환경을 구축하는 과정을 살펴보았습니다. 가장 신경 쓴 것은 답을 길게 쓰는 능력이 아니라, 질문 의도에 맞는 도구를 골라 검증하고 종합하여 신뢰성 있는 답변을 제공하도록 하는 것이었습니다.

Agent 자체적으로는 내부·웹·규제처럼 성격이 다른 정보에 대한 MCP 분리, Synthesizer의 검증 및 통합, AgentCore Evaluations 기반 평가를 통하여 답변의 품질을 확보할 수 있었습니다. 이후 운영을 위해 페르소나별 Bedrock Guardrails를 구성하여 보안 체계를 구축하였고, 목적에 따라 대화를 분리 저장하여 사용자별로 격리하고, CloudWatch 토큰 로그로 사용량과 과금 토대를 마련하였습니다.

AWS 기술 블로그