GS에너지의 SageMaker Unified Studio와 Bedrock AgentCore로 구축하는 엔터프라이즈 에이전트 데이터 플랫폼

프로젝트 기반 데이터 구독과 에이전트 실행을 연결한 GS에너지 발전 계열사 통합 데이터 플랫폼 구축 사례

1. 소개

에너지 산업의 디지털 전환이 가속화되면서, 기업들은 단순한 데이터 저장과 분석을 넘어 AI가 데이터를 능동적으로 활용하는 플랫폼을 요구하고 있습니다. 에너지 기업의 운영 데이터는 발전소 설비 센서, 운전 지표, 환경 계측, 전력 거래, 시장 가격, 규제 공시처럼 성격이 서로 다른 시스템에 분산되어 있습니다. 계열사가 여러 곳이면 같은 종류의 데이터도 회사마다 다른 스키마와 접근 절차를 갖게 됩니다. GS에너지는 GS파워를 시작으로 GS EPS, 인천종합에너지 등 발전 계열사의 데이터를 하나의 플랫폼으로 통합하고, 그 위에서 현업 사용자가 대화형으로 데이터를 찾고 요청하고 활용할 수 있는 에이전트 서빙 체계를 구축하고 있습니다.

이 블로그에서는 Amazon SageMaker Unified Studio(SMUS)를 데이터 카탈로그와 거버넌스 허브로, Amazon Bedrock AgentCore를 에이전트 런타임으로 결합하여 “데이터에서 에이전트까지(Data-to-Agent)” 엔드투엔드 플랫폼을 구축한 GS에너지의 아키텍처와 구현 과정을 소개합니다.

데이터 수집과 표준화, 프로젝트 단위 구독, 에이전트 실행까지 이어지는 구조와, 사용자 인증과 AWS 서비스 호출 권한과 데이터 조회 권한을 어떻게 나눴는지 설명하고, 이 경계를 연결하는 플랫폼의 역할을 소개합니다. 이 글에서 말하는 프로젝트는 SageMaker Unified Studio에서 협업과 데이터 이용의 단위가 되는 개념으로, GS에너지는 참여 법인과 업무 조직을 기준으로 프로젝트를 구성합니다.

2. 배경과 과제

2.1 에너지 데이터를 현업의 AI 활용으로 연결하기

발전 데이터가 원천 시스템에 안전하게 저장되어 있어도 현업이 필요한 데이터를 찾고 활용하려면 어떤 설비의 값인지, 어느 기간의 데이터인지, 누가 조회할 수 있는지 확인해야 합니다. AI 에이전트에도 같은 정보가 필요합니다. 데이터 레이크와 Amazon SageMaker 기반 MLOps 환경은 이미 있었지만, 데이터가 여러 시스템에 흩어져 있고 계열사마다 인가 정책과 사내 인증 체계가 달라 비개발자가 필요한 순간에 데이터를 수동으로 직접 찾아서 쓰기는 어려웠습니다. GS에너지는 참여사별 데이터 접근 경계를 유지하면서 승인된 데이터와 공통 에이전트를 함께 쓸 수 있도록, 데이터의 위치와 의미, 이용 절차를 공통 플랫폼에서 관리하는 구조를 설계했습니다. 장기 목표는 통합 데이터 플랫폼 위에서 에너지 분야의 AI 모델을 개발하고 운영하는 체계를 만드는 것입니다.

2.2 해결해야 했던 문제

이 목표를 실제 시스템으로 옮기는 과정에서 다음 다섯 가지 과제가 서로 얽혀 드러났습니다.

법인 간 데이터 경계와 공유의 공존: 참여사의 원천 데이터는 기본적으로 격리하되, 승인된 데이터는 프로젝트 간에 공유해야 합니다. 카탈로그에서 데이터를 발견하는 권한과 실제 값을 조회하는 권한을 구분하고, 참여사가 늘어나도 같은 절차로 온보딩할 수 있어야 했습니다.
비개발자의 데이터 접근: 데이터 요청이 IT 조직 티켓으로 처리되면 스키마 파악과 권한 조율에 며칠이 걸립니다. 현업 사용자가 카탈로그를 직접 검색하고 구독을 신청하고 승인 상태를 확인할 수 있는 셀프서비스 경험이 필요했습니다.
에이전트의 권한 범위: 에이전트가 사람보다 많은 데이터에 접근하는 일이 없어야 합니다. 에이전트는 호출한 사용자의 권한으로만 데이터를 조회해야 하고, 그 판단은 별도의 에이전트용 권한 체계가 아니라 데이터 플랫폼의 거버넌스 규칙에서 나와야 합니다.
에이전트 인프라 운영 부담: 사용자마다 격리된 실행 환경이 필요하지만, 데이터 플랫폼 팀이 에이전트용 컴퓨트의 프로비저닝과 스케일링, 세션 정리를 직접 운영하는 것은 부담이었습니다.
사내 인증 체계와의 통합: Keycloak 기반 SSO로 사용자를 인증하고 사내 EAI 시스템을 통해 사용자, 조직 정보를 연동하면서, AWS 서비스 호출에는 별도의 AWS Identity and Access Management (IAM) 자격증명을 사용해야 했습니다.

각 참여사가 서로의 원천 데이터를 볼 수 없도록 경계를 유지하면서도, 공유 카탈로그와 공통 에이전트는 함께 써야 합니다. 이 두 조건을 데이터 레이크와 카탈로그, 거버넌스, 에이전트 런타임, 인증을 하나의 흐름으로 설계한 것이 이번 플랫폼 구축의 출발점입니다.

3. 플랫폼 구성과 솔루션 아키텍처

그림 1. 전체 아키텍처와 다섯 영역

현업 사용자는 SageMaker Unified Studio 콘솔 대신 Data Portal에서 카탈로그 탐색과 구독 신청, 승인을 처리합니다. LibreChat에서 시작한 에이전트 요청은 Amazon Elastic Kubernetes Service (Amazon EKS)의 Custom Endpoint, AgentCore Runtime, MCP 서버를 거쳐 데이터 서비스에 도달합니다. MCP 서버 실행 위치는 서비스별로 상이하고, 실제 데이터 조회는 Amazon Athena나 서빙 저장소가 담당합니다. 모델 호출은 사내 LLM Gateway를 거쳐 Amazon Bedrock 모델에 도달합니다.

아키텍처는 크게 다섯 영역으로 나뉩니다.

사용자 접점 & 인증: Data Portal과 LibreChat이 사용자 접점, Keycloak이 인증을 담당합니다. Custom Endpoint가 사용자 토큰을 검증하고 Runtime 호출을 중계합니다.
에이전트 런타임 & 모델: AgentCore Runtime이 세션별 실행 환경을 제공하고, AgentCore Memory 사용 여부는 에이전트별로 구성합니다. 모델 호출은 사내 LLM Gateway를 거쳐 Amazon Bedrock 모델에 도달합니다.
에이전트 도구: EKS의 MCP 서버가 카탈로그 검색, 태그 탐색, 외부 정보 조회, 서빙 DB 조회 도구를 제공합니다.
데이터 플랫폼: Raw/Conformed/Curated 3계층 데이터 레이크가 기반입니다. SageMaker Unified Studio의 카탈로그와 구독, AWS Glue Data Catalog의 기술 메타데이터, AWS Lake Formation의 접근제어를 Amazon Simple Storage Service (Amazon S3) 저장소와 Athena 조회 엔진, Supabase 서빙 DB에 연결합니다.
수집: Airflow 기반 배치/증분 파이프라인을 중심으로 Kafka 실시간 연계를 병행합니다.

3.1 컴포넌트

영역	상세 구분	구성	역할
사용자 접점 & 인증	사용자 인터페이스	LibreChat (오픈 소스), Data Portal	대화형 에이전트 인터페이스와 데이터 카탈로그, 데이터 신청과 승인, 프로젝트 관리 화면
사용자 접점 & 인증	인증	Keycloak (EAI 연동)	전사 SSO와 사용자/조직 정보 연동. 사용자 인증 토큰과 AWS 서비스 호출용 IAM 자격증명을 구분
에이전트 런타임 & 모델	에이전트 런타임	Amazon Bedrock AgentCore Runtime, AgentCore Memory	세션별 에이전트 실행과 microVM 격리. IAM 또는 JWT 인바운드 인증 지원
에이전트 런타임 & 모델	모델	사내 LLM Gateway, Amazon Bedrock	에이전트의 모델 호출은 사내 LLM Gateway를 거쳐 Bedrock 모델에 전달. Gateway가 모델 접근과 사용량, 비용 집계를 담당
에이전트 도구	툴 연계	MCP 서버 (EKS), AgentCore Gateway	카탈로그/태그 탐색, 외부 정보, 서빙 DB 연결. 서버별 배포 위치와 사용자/프로젝트 인가를 확인
데이터 플랫폼	데이터 레이크, 데이터 조회	Amazon SageMaker Unified Studio, Amazon Athena, AWS Glue Data Catalog, AWS Lake Formation	카탈로그, 프로젝트, 구독 관리와 Lake Formation 접근제어. Athena 분석 조회와 Glue 기술 메타데이터 관리
수집	실시간, 배치성 수집	Airflow, Dataflow, DuckDB, Kafka, Kafka Connect	선언형 배치/증분 수집, 변환과 Iceberg 적재, 백필과 실시간 연계
기반 서비스	컴퓨트	Amazon EKS	Data Portal, LibreChat, Custom Endpoint, 카탈로그 서비스, MCP 서버, OpenSearch, Kafka (Strimzi), Phoenix 호스팅
	저장소	Amazon S3, Supabase, PostgreSQL, MongoDB, OpenSearch (EKS 자체 호스팅)	S3 3계층 데이터 레이크, Supabase 서빙 DB, 포털 카탈로그 DB, LibreChat 대화 이력, 문서 검색 저장소
	관측성	Phoenix (EKS)	에이전트 실행 트레이스와 툴 호출 추적

데이터 카탈로그와 거버넌스, 객체 저장소, 에이전트 실행처럼 관리형 서비스의 이점이 큰 영역에는 AWS 서비스를 사용합니다. 포털, 채팅, 수집 오케스트레이션, 일부 저장소와 MCP 서버는 EKS에서 자체 운영합니다. 자체 호스팅 영역은 자원 활용의 유연성을 얻는 대신 백업, 업그레이드, 장애 복구를 플랫폼 팀이 책임집니다.

4. 데이터 플랫폼: 수집, 거버넌스와 서빙

그림 2. 데이터 수집, 거버넌스와 서빙 경로

4.1 선언형 수집과 데이터 표준화

플랫폼은 원천 시스템마다 새 파이프라인 전체를 만드는 대신 YAML로 수집 주기, 소스 연결, 스키마, 변환식, 대상 저장소와 작업 의존성을 정의하는 Dataflow 프레임워크를 사용합니다. Airflow가 이 정의를 DAG로 구성하고, 컨테이너 작업이 수집, 변환, 적재를 수행합니다. 수집 정의와 실행 환경을 분리했기 때문에 같은 정의를 Kubernetes Pod나 AWS Batch에서 그대로 실행할 수 있습니다.

그림 3. Raw/Conformed/Curated 데이터 정제와 서빙 저장소의 연결

데이터 레이크는 Raw, Conformed, Curated 세 계층의 Medallion 아키텍처로 구성합니다. 원천 데이터를 보관하고, 공통 기준으로 정제 및 통합한 뒤, 업무 목적에 맞게 가공하는 구조입니다. 각 계층의 역할을 나누어 공통 데이터의 재사용성과 업무별 활용 요구를 함께 다룹니다.

Raw 계층: 원천 데이터를 S3에 보관합니다. 수집한 데이터를 원천과 대조하고, 변환 규칙이 바뀌거나 과거 구간을 다시 처리할 때 재처리의 출발점으로 사용합니다.
Conformed 계층: 컬럼 이름과 타입, 시각 단위, 업무 식별자를 공통 기준으로 정리해 서로 다른 원천의 데이터를 일관된 기준으로 활용할 수 있게 합니다.
Curated 계층: 정제된 데이터를 업무 목적에 맞게 결합, 집계하거나 업무 규칙을 적용해 분석 데이터셋과 데이터 마트로 구성합니다. 현업 대시보드와 에이전트가 이 데이터를 활용합니다.

메타데이터도 이용 목적에 맞게 관리합니다. 원천의 기술 메타데이터는 DataHub가 수집하고, 테이블 스키마는 AWS Glue Data Catalog가, 자산의 소유 프로젝트와 설명, 구독 정보는 SageMaker Unified Studio 카탈로그가 관리합니다.

4.2 테이블 포맷과 쿼리 엔진: Iceberg, Athena, DuckDB

그림 4. 선언형 수집 파이프라인과 Iceberg 테이블, Glue Data Catalog 등록 경로

수집 경로에 따라 JSON이나 Parquet 등의 원천 데이터를 Amazon S3에 보관하고, SQL 조회에 필요한 테이블 메타데이터는 AWS Glue Data Catalog에서 관리합니다. 분석용 Iceberg 테이블도 Amazon S3에 저장하고 Glue Data Catalog에 등록합니다. 분석 SQL과 애플리케이션 조회에는 Athena를 씁니다. DuckDB는 입수 데이터 변환에 쓰고, Glue Iceberg REST 카탈로그를 통해 Iceberg 테이블을 직접 읽고 적재하고 병합하는 데도 씁니다. 이전에는 upsert마다 대상 테이블 전체를 임시로 복사했지만, DuckDB의 네이티브 MERGE로 바꾼 뒤 이 복사 작업을 줄였습니다. 이처럼 데이터의 계층과 처리 엔진의 역할을 나누어 워크로드에 맞게 구성합니다.

이제 프로젝트와 카탈로그, 구독 모델이 데이터 이용 범위를 어떻게 정하고 실제 조회 경로의 권한으로 연결되는지 살펴보겠습니다.

4.3 프로젝트와 카탈로그를 통한 데이터 이용

그림 5. 프로젝트 구독에서 권한 부여, 조회와 서빙 경로로 이어지는 구성

이 프로젝트에서 SageMaker Unified Studio는 데이터 이용 정책의 기준이 되는 거버넌스 백엔드입니다. 도메인은 사용자, 프로젝트, 데이터 자산을 묶는 조직 단위로, 자산의 소유 프로젝트, 설명과 용어집, 구독 상태를 카탈로그에서 관리합니다. 포털과 에이전트는 카탈로그의 프로젝트, 구독 정보를 공통 정책의 기준으로 삼되, 실제 조회 권한은 MCP, Athena, Supabase 등 각 경로에서 별도로 검증하고 강제합니다. 도메인은 여러 AWS 계정을 연결할 수 있어, 법인별로 계정을 분리해 운영하는 경우에도 하나의 도메인에서 거버넌스를 통합할 수 있습니다.

GS에너지는 참여 법인과 업무 조직을 기준으로 프로젝트를 구성하고, 팀과 사용자의 소속에 따라 사용할 수 있는 테이블을 구분한 뒤 구독으로 데이터 접근을 요청하는 구조를 구현했습니다. 포털에서는 프로젝트 선택, 카탈로그 탐색, 이용 신청과 승인 상태 확인을 연결해 현업 사용자가 데이터 이용 절차를 직접 수행합니다. 현재 SMUS Data Asset 총 개수 73개와 영상 등 비정형 데이터가 등록되어 있고, 약 690여명의 사용자가 플랫폼에 접근해 활용합니다.

그림 6. Data Portal 프로젝트 목록

위 화면은 실제 운영 중인 Data Portal의 프로젝트 목록입니다. 프로젝트 카드에는 소속 법인, 연결된 데이터셋 수, 구성원 수가 표시됩니다.

그림 7. Data Portal 프로젝트 개요

프로젝트 개요 화면에서는 최근 활동, 사용 가능한 데이터, Instance App, 검토 중인 요청, 구성원과 역할(Owner, Contributor)을 한눈에 확인할 수 있습니다.

포털과 에이전트는 SageMaker Unified Studio의 기반인 Amazon DataZone API로 프로젝트와 자산, 구독 상태를 조회합니다. 이 API 호출에는 IAM 자격증명을 쓰고, 사용자와 프로젝트의 관계와 구독 정보로 데이터 이용 범위를 판단합니다.

4.4 구독 모델과 승인 워크플로우

그림 8. 구독 승인과 실제 접근 권한 부여를 구분한 데이터 이용 흐름

데이터를 소유한 프로젝트가 자산을 카탈로그에 게시하면 다른 프로젝트가 이를 검색하고 구독을 요청합니다. 게시 프로젝트의 승인 권한을 가진 구성원이 요청을 검토하고, 승인하면 SageMaker Unified Studio가 지원하는 데이터 소스에 대해 실제 접근 권한을 부여합니다. 승인과 권한 부여 완료는 별개 단계이므로, 포털의 사용 가능 표시와 실제 조회 가능 여부를 함께 확인해야 합니다.

그림 9. Data Portal의 Data Catalog 화면

승인 절차는 자산 단위로 조정할 수 있습니다. 게시 시 승인 불필요로 설정하면 모든 구독 요청이 자동 승인되고, 요청자가 게시 프로젝트와 요청 프로젝트 양쪽에서 소유자 또는 기여자 역할을 갖고 있으면 역시 자동 승인됩니다. GS에너지는 이 워크플로우를 Data Portal의 신청과 승인 화면에 연결했습니다.

4.5 테이블/행/컬럼 단위 접근제어

그림 10. 프로젝트에서 사용 가능한 데이터 화면

구독을 승인할 때 전체 접근을 줄 수도 있고 행 필터와 열 필터를 적용해 승인할 수도 있습니다. AWS Glue 테이블의 경우 SageMaker Unified Studio가 필터를 AWS Lake Formation의 데이터 셀 필터로 변환해 구독 프로젝트에 읽기 권한을 부여하고, 필터를 수정하면 활성 구독의 권한도 갱신합니다.

이 행/열 필터는 Athena처럼 Lake Formation과 통합된 엔진이 쿼리를 실행할 때 적용됩니다. Athena 엔진 버전 3은 Iceberg 테이블의 행/열 수준 접근제어를 지원합니다. 같은 S3 파일이나 Iceberg 카탈로그를 읽는다는 이유만으로 모든 엔진과 애플리케이션에 같은 필터가 자동 적용되는 것은 아닙니다.

Supabase에 복사한 데이터에는 Lake Formation 대신 PostgreSQL의 권한 체계가 적용됩니다. 그래서 프로젝트별 복제 범위, DB 역할, 필요한 뷰나 RLS 정책, 구독 회수 후의 접근 차단과 복사본 처리를 따로 설계해야 합니다. Reverse ETL은 Conformed 또는 Curated 계층에서 필요한 데이터만 PostgreSQL로 옮기며, 적재 전용 DB 역할과 스키마를 두고 기존 RDBMS sink를 재사용합니다. 소유 프로젝트가 구독을 회수하면 Lake Formation 권한과 PostgreSQL 권한을 함께 바꿔야 하는 점이 이 구조의 운영 과제입니다.

4.6 서빙 저장소와 데이터 최신성 관리

Curated는 분석용으로 정제한 데이터가 있는 레이크 내부 계층이고, Supabase 같은 서빙 저장소는 화면이나 API의 응답 패턴에 맞춰 데이터를 제공하는 실행 환경입니다. 데이터의 가공 수준과 제공 방식을 구분하면 Curated 데이터셋을 Athena로 분석하면서 필요한 범위만 별도 서빙 저장소에 전달할 수 있습니다.

서빙 저장소의 데이터는 레이크의 복사본이므로 최신성과 권한을 함께 관리합니다. 배치 Reverse ETL과 실시간 최신값은 업데이트 방식이 다르므로 조회 경로별로 갱신 주기와 지연을 정하고, 원천 측정 시각, 수집과 적재 완료 시각, 마지막으로 성공한 동기화 시각을 구분합니다. 이를 통해 중복, 누락, 지연 처리 방식과 구독 회수 후 복사본과 캐시의 보존을 데이터별 운영 정책에 따라 관리합니다.

그림 11. 데이터 수집과 서빙 확장의 논리 구성

비정형 데이터는 EKS에 자체 호스팅한 OpenSearch와 MongoDB가 담당합니다. OpenSearch는 HR, 복지 등 사내 문서를 대상으로 하는 RAG의 벡터 검색과 문서 검색에 사용하며 현재 내부 운영 중입니다. 처음에는 Amazon OpenSearch Serverless를 검토했지만 대상 문서의 규모가 작아 비용 대비 효율이 맞지 않았고, EKS에 소규모 OpenSearch를 직접 운영하는 쪽을 택했습니다. MongoDB는 LibreChat의 대화 이력과 문서 저장에 사용합니다.

5. 에이전트 플랫폼: Amazon Bedrock AgentCore

에이전트는 데이터 플랫폼의 카탈로그와 조회 경로를 그대로 사용하며, 구독으로 정한 이용 범위를 에이전트 실행에서도 유지합니다.

5.1 세션 단위 격리를 위한 AgentCore Runtime과 기억 유지를 위한 AgentCore Memory

AgentCore Runtime은 서버리스 실행 환경으로, 에이전트 코드를 컨테이너 이미지로 배포하면 스케일링, 세션 관리, 보안 격리, 인프라 관리를 Runtime이 처리합니다. 호출 측이 고유한 세션 ID를 사용하면, Runtime이 세션마다 별도 microVM을 할당해 컴퓨트, 메모리, 파일시스템을 격리합니다. 실행 환경이 종료된 뒤에도 대화 이력이나 장기 컨텍스트를 유지하려면 별도 저장소를 사용합니다. 이 환경에서 서빙되는 Text-to-Any 에이전트는 자연어 요청을 발전 데이터의 태그와 스키마 탐색, 허용된 테이블의 SQL 조회와 분석 도구 실행으로 연결하는 GS 에너지의 데이터 분석 에이전트입니다. 이 에이전트는 AgentCore Memory를 사용하여 단기 기억을 관리형으로 활용합니다.

5.2 EKS와 AgentCore Runtime의 실행 책임 나누기

그림 12. AgentCore Runtime의 세션 격리와 외부 자원의 권한 검증 책임

EKS는 Data Portal, LibreChat, Custom Endpoint, 데이터 서비스, MCP 서버, Airflow, PostgreSQL, OpenSearch, Kafka, 관측성 서비스를 운영하고, 에이전트 실행은 AgentCore Runtime이 담당합니다. 세션 격리는 Runtime이 맡고, 사용자와 세션의 소유 관계, MCP와 DB 같은 외부 자원의 권한은 애플리케이션이 검증합니다. 에이전트 실행을 관리형 서비스에 맡기는 것이 자체 애플리케이션의 운영 책임을 구분하는 구성입니다.

5.3 사용자 토큰 전파

그림 13. 사용자 토큰 전파와 AWS API 인증 경계

사용자 신원 전달과 서비스 호출 인증은 역할이 다릅니다. Keycloak 토큰은 사용자를 식별하고, AWS IAM 자격증명은 Runtime과 DataZone, Athena 등의 API 호출을 인증하며, 프로젝트 멤버십과 구독 권한은 실제 조회 경로에서 확인합니다. 실제 요청의 흐름은 아래와 같습니다.

사용자가 사내 SSO인 Keycloak에 로그인합니다. Keycloak의 사용자와 조직 정보는 EAI 시스템에서 API로 연동합니다.
Keycloak이 사용자 식별자와 조직 클레임이 포함된 JWT를 발급합니다.
포털에 포함된 채팅 화면(LibreChat)에는 postMessage로 사용자 정보를 전달하고, LibreChat은 Custom Endpoint에 HTTP Authorization 헤더로 사용자 토큰을 보냅니다.
Custom Endpoint는 JWT 서명을 검증한 뒤 IAM SigV4 인증으로 Runtime을 호출합니다. 사용자 Authorization 값은 요청 본문의 authorization 필드에 담아 전달합니다.
Runtime 호출은 AWS SDK의 IAM SigV4 인증을 사용합니다. 이 호출 권한과 요청 컨텍스트에 포함된 사용자 신원은 서로 다른 역할을 담당합니다.
에이전트는 전달받은 사용자/프로젝트 정보를 MCP 도구 호출에 함께 넘깁니다. MCP 서버는 토큰을 다시 검증하고 사용자, 프로젝트, 구독 권한을 확인합니다.
MCP 서버는 선택한 프로젝트의 IAM 역할을 AssumeRole 하여 임시 자격증명을 얻고, 이 자격증명으로 DataZone 구독 조회와 Athena SQL 조회를 SigV4 서명합니다. 사용자와 프로젝트의 관계와 구독 상태에 따른 데이터 조회 허용 범위는 별도로 확인합니다.
Supabase 테넌트 조회는 프로젝트 인가와 읽기 전용 경로로 처리합니다.

목표는 사용자 A가 프로젝트 X의 허용 데이터에만 접근할 수 있다면 A의 에이전트도 같은 범위만 접근하도록 만드는 것입니다.

5.4 MCP로 데이터와 에이전트를 연결

그림 14. MCP 도구 계층과 데이터 소스, 관측성의 연결

에이전트는 필요한 기능을 도구로 호출하고, MCP 서버는 카탈로그 검색과 구독 관리, 외부 데이터 연계의 인터페이스를 제공합니다. 에이전트 로직과 Tool 등록 부분, MCP 서버, 백엔드 서비스를 나누어 구성합니다. 이 구조를 통해 에이전트의 업무 로직과 데이터 서비스의 연계를 분리해 관리합니다.

MCP는 카탈로그 검색, 태그 탐색, 외부 정보 조회, 서빙 DB 접근 등의 도구를 에이전트에 연결하는 공통 인터페이스입니다. EKS의 MCP 서버와 함께 태그 탐색 서버를 AgentCore Runtime의 MCP 프로토콜로 배포하는 구성도 마련했습니다. Supabase MCP에는 Keycloak 기반 프로젝트 선택과 계정 내 프로젝트 탐색, 테넌트의 읽기 전용 조회 경로를 구현했습니다. 도구를 추가할 때는 등록뿐 아니라 스키마, 인증과 호출 권한, 오류 처리와 동작 검증을 함께 관리합니다.

5.5 에이전트 구성과 현황

카탈로그 조회 에이전트를 출발점으로, Text-to-Any와 공시 자동화 에이전트로 활용 범위를 넓히고 있습니다. Text-to-Any는 자연어 요청을 발전 데이터의 태그와 스키마 탐색, 허용된 테이블의 SQL 조회와 분석 도구 실행으로 연결하는 GS에너지의 데이터 분석 에이전트입니다. 공시 자동화는 자료와 규칙에 근거해 담당자의 판단을 보조하는 방향으로 개발하고 있습니다.

에이전트	기능	상태
카탈로그 조회	자연어로 데이터 자산과 메타데이터, 소유 프로젝트, 구독 상태를 안내합니다. 자산 탐색 범위와 실제 데이터 조회 권한을 구분합니다.	운영 중
공시 자동화	공시 관련 자료와 규칙에 근거해 판단, 서식 작성을 보조하는 기능을 개발합니다. 최종 판단과 제출은 담당자의 검토를 전제로 합니다.	개발 중
Text-to-Any	태그/스키마 탐색, 허용 테이블을 대상으로 한 Athena SQL, 분석 도구 실행. 사내 LLM Gateway와 AgentCore Memory 연동.	구현 및 배포 체계 구축

5.6 관측성

Phoenix는 EKS에서 에이전트 실행과 도구 호출의 트레이스를 수집합니다. 모델 응답, 도구 오류, 데이터 갱신 지연과 조회 실패를 구분할 수 있도록 요청, 세션, 프로젝트, 파이프라인 실행을 연결해 관측합니다. 사용자 토큰이나 민감한 질의와 결과는 기록하지 않도록 수집 항목을 정했고, 에이전트와 데이터 파이프라인을 함께 살펴볼 수 있는 운영 체계로 발전시키고 있습니다.

이를 통해 데이터 수집 요청부터 사용 가능 시점까지의 시간, 수집/서빙 지연, 파이프라인 성공률과 에이전트 답변의 근거 제시 여부를 중심으로 활용 효과 측정이 가능해지고, 기술 구성뿐 아니라 현업이 데이터를 준비하고 판단하는 전체 흐름을 평가하는 기반을 구축할 수 있습니다.

6. 프로젝트 데이터 활용 사례

그림 15. Data Portal 프로젝트 화면의 Instance App

Instance App은 프로젝트 데이터를 활용한 대시보드와 조회 화면을 배포하고 공유하는 기능입니다. 데이터 구독으로 사용 가능해진 테이블을 에이전트 대화뿐 아니라 고정된 화면으로도 쓸 수 있도록, Data Portal에서 앱을 등록하고 승인 후 EKS에 배포하는 흐름입니다.

앱 배포 승인도 데이터 구독과 같은 프로젝트 소유자가 합니다. 프로젝트 구성원이 프로젝트 화면에서 앱을 등록하고 배포를 요청하면 소유자가 검토해 승인하거나 반려하고, 승인된 앱은 EKS에 배포됩니다. 그림 15의 인스턴스 앱 탭에는 버전과 배포 상태(배포 완료, 반려됨)가 표시되고, 구성원은 여기서 앱 바로가기로 들어갑니다. 프로젝트 개요 화면의 최근 활동에도 배포 요청과 완료 이력이 남아 누가 어떤 화면을 추가했는지 추적할 수 있습니다.

그림 16. 지역난방 계측 태그 조회 대시보드

첫 적용 사례는 Athena 조회 기반의 지역난방 계측 대시보드입니다. 그림 16처럼 사용자가 계측 태그를 선택하고 조회 포인트 수와 자동 갱신 주기를 지정하면, 최근 값과 최소, 평균, 최대, 시계열 추이를 함께 보여 줍니다. 여러 태그를 선택하면 태그별 최근 샘플을 포인트 순서로 정렬해 비교합니다. 태그 탐색과 SQL 작성은 Text-to-Any 에이전트가, 반복 확인은 Instance App이 맡는 식으로 대화형 도구와 고정 화면이 같은 프로젝트 데이터를 나눠 쓰는 구조입니다.

다음으로 앱 로그인과 프로젝트 멤버십 확인, 단기 조회 토큰 기반 접근제어를 보강하고, 조회 성능과 데이터 최신성 요구가 높은 앱은 Supabase 서빙 경로로 옮길 계획입니다.

7. 구현 여정

그림 17. 구현 여정: 단계별 데이터 플랫폼, 에이전트, 운영 확장

7.1 데이터 기반 통합과 접근성 확대

2025년 하반기부터 2026년 상반기까지 진행한 첫 단계에서는 GS파워의 발전 데이터를 하나의 플랫폼으로 통합했습니다. 대표 AI 사례로 설비 이상 감지를 실증하고, 다른 발전사에도 같은 절차로 적용할 수 있는 구조를 만든 뒤 인천종합에너지와 GS EPS를 온보딩해 발전 운영과 환경 데이터 수집 범위를 넓혔습니다.

이 기간에 데이터 카탈로그 메타데이터 표준화, 프로젝트 구조 설계, 구독 기반 데이터 공유 워크플로우를 정했습니다. 대화형 인터페이스는 여러 오픈소스 후보를 검토한 뒤 LibreChat을 선정하고 AgentCore 연동 PoC를 검증했습니다.

7.2 AgentCore 기반 에이전트 허브와 프로덕션 파이프라인

2026년 하반기에는 AgentCore 실행 경로와 MCP 연계, Data Portal의 카탈로그와 프로젝트 관리, 수집과 서빙 파이프라인을 함께 발전시키고 있습니다. 지금까지 입수 승인에 따른 회사별 DAG 배포와 백필, DuckDB 기반 Iceberg 병합 개선, Supabase Reverse ETL을 구현했고, Text-to-Any에는 사내 LLM Gateway와 AgentCore Memory를 연동했습니다. 이어서 Instance App, 실시간 서빙 운영 체계, 도구와 MCP 관리, 관측성을 단계적으로 확장하고 있습니다.

7.3 현재까지의 결과

GS파워를 시작으로 참여 발전 계열사의 데이터와 활용 환경을 단계적으로 연결하면서 데이터 요청과 수집, 이용 승인과 에이전트 활용을 같은 흐름으로 다룰 수 있는 기반을 마련했습니다.

현재까지 GS파워, GS EPS, 인천종합에너지 3개 발전 계열사의 데이터를 플랫폼에 연결했으며, 카탈로그 조회 에이전트가 운영 중이고 Text-to-Any와 공시 자동화 에이전트가 개발 및 배포 단계에 있습니다. 프로젝트 기반 구독 모델을 통해 데이터 요청에서 승인까지의 과정이 카탈로그와 포털 안에서 처리되며, 별도의 IT 티켓 없이 현업 사용자가 직접 데이터를 탐색하고 구독을 신청할 수 있게 되었습니다.

앞으로는 데이터 수집 요청부터 사용 가능 시점까지의 시간, 수집 및 서빙 지연, 파이프라인 성공률과 에이전트 답변의 근거 제시 여부를 중심으로 활용 효과를 측정할 계획입니다. 기술 구성뿐 아니라 현업이 데이터를 준비하고 판단하는 전체 흐름을 평가하는 방향입니다.

7.4 AI-Ready 데이터 표준화와 운영 확장 계획

AI-Ready 데이터는 에이전트가 활용하기 위해 정제된 데이터로, 서로 다른 발전소의 태그와 테이블을 같은 업무 의미로 찾을 수 있고, 의미와 품질, 이용 권한과 갱신 조건을 설명할 수 있는 데이터입니다. 에이전트가 “특정 발전소의 압력 계측값”을 찾을 때 문자열 검색 대신 발전소, 설비, 측정 종류를 조합해 후보 태그를 좁힐 수 있고, 답변에는 데이터셋과 태그의 의미, 조회 기간, 단위와 원천, 마지막 갱신 시간을 함께 반환하여 현업 담당자가 검증할 수 있게 하는 것이 목표입니다.

이를 위해 현재의 의미 매핑과 관계형 조회 모델을 바탕으로 온톨로지 및 그래프 기반 활용으로 확장할 계획입니다. 식별자, 측정 단위, 시각 기준, 품질 표시, 갱신 주기, 이용 권한을 함께 관리하고, 같은 의미의 데이터라도 원천과 수집 조건이 다르면 구별해 제공합니다. 데이터의 의미와 최신성을 설명할 수 있어야 에이전트의 답변도 검증할 수 있기 때문입니다.

다음 단계로는 프롬프트 기반 에이전트 생성, 이상 감지 및 예측을 수행하는 도메인 에이전트, 실행과 평가 파이프라인, 데이터 서빙 확대를 추진합니다. Text-to-Any의 데이터 탐색과 분석 흐름을 바탕으로 업무별 도구와 데이터 활용 범위를 확장해 나갈 계획입니다.

또한 데이터 이용의 확대에 맞춰 프로젝트별 사용량과 비용을 설명하는 체계도 발전시킬 계획입니다. 데이터 접근을 허용하는 구독 승인과 비용 배분은 구분하고, 인프라, 모델, 쿼리, 저장소 사용량을 프로젝트와 연결하는 방식으로 접근합니다. 자원 소유 관계와 측정 단위, 집계 기간을 정의해 조직별 활용 현황을 파악하는 것이 목표입니다.

8. 정리하며

GS에너지는 Amazon SageMaker Unified Studio를 데이터 카탈로그와 거버넌스 허브로, Amazon Bedrock AgentCore Runtime을 에이전트 실행 환경으로 결합해 데이터에서 에이전트까지 이어지는 플랫폼을 구축했습니다. 설계 원칙은 다음과 같이 정리할 수 있습니다.

데이터 이용 정책의 기준을 카탈로그와 프로젝트, 구독 모델에 모읍니다. 이를 참조하는 에이전트와 도구가 늘어날수록 실제 조회 경로의 인가, 정책 갱신과 권한 회수도 함께 연결해야 합니다.
사용자 신원 전달과 AWS 서비스 호출 인증을 구분합니다. JWT가 어디서 검증되는지, IAM 자격증명은 어느 주체의 것인지, 프로젝트 권한은 어느 단계에서 강제되는지를 요청 경로별로 명확히 해야 합니다.
AgentCore의 구성 요소는 에이전트의 요구에 맞게 선택합니다. AgentCore Runtime은 실행 환경을 제공하고, 최신 Text-to-Any 구현은 AgentCore Memory를 사용합니다.
에이전트 운영은 AgentCore에 맡기고 사용자, 프로젝트와 세션의 소유 관계는 애플리케이션이 검증해야 합니다. Memory, DB, MCP와 로그 등 외부 상태의 격리도 별도로 확인합니다.
MCP는 도구 연결의 공통 인터페이스를 제공합니다. 효과는 단순히 도구를 등록하는 데서 끝나지 않으며, 데이터 의미, 권한, 최신성, 오류 처리를 함께 정의해야 재사용할 수 있습니다.

이 구조는 에너지 산업에 한정되지 않습니다. 여러 법인과 여러 데이터 소스를 관리하면서 기존 SSO를 유지해야 하는 제조, 금융, 물류 조직에도 같은 방식으로 적용할 수 있습니다. 이 사례가 관련 프로젝트에 영감이 되길 바랍니다.

AWS 기술 블로그