2.1 철도 부문 에너지·디지털트윈 연구

철도 부문 에너지 연구는 도시철도 변전소의 견인부하 관리를 중심으로 연구되었다. Park 등^[8]과 Heo 등^[9]은 변전소 실측 부하 기반으로 ESS 용량 산정과 운영 알고리즘을 제시하였으나 역사 건물의 공조·조명·환기 부하를 다루지는 않는다. 역사 건물의 에너지 성능 평가는 정적 시뮬레이션에 의존해 왔다. 실측과 결합된 디지털트윈 연구는 Kaewunruen과 Xu^[6]의 BIM 기반 생애주기 평가처럼 정보 모델 구조에 초점을 두어 에너지 시뮬레이션 모델을 실측에 정합시키는 시스템 문제는 다루지 않았다.

2.2 FMU Co-Simulation과 그 한계

FMI 표준은 이종 시뮬레이션 도구를 결합하는 인터페이스로 모델 교환과 공동 시뮬레이션 두 방식을 제공하며, EnergyPlus는 FMU를 가져오는 공동 시뮬레이션으로 외부 도구와 시간 동기 방식으로 결합된다^[10]. 선행 FMU 파이프라인^[7]은 거점역사 모델(EnergyPlus 입력 파일 IDF 약 50,000줄·150 Zone)을 FMU로 변환하고 사내 구역 모델로 5분 주기 자동 시뮬레이션을 주당 2,016회 운영하였으며 FMU 변환에는 회당 약 5~10분이 소요되었다^[7]. 그러나 FMU는 내보내는 시점에 모델 입력이 고정되어 외피·설비 변수를 바꾸려면 다시 내보내야 한다(표 1). 재수출은 자동화할 수 있으나 매 변경마다 내보내기와 연동 검증을 거쳐야 하므로 외피·창호·열원 시나리오의 대화형 비교가 FMU 경로에서는 이루어지지 않는다.

2.3 EnergyPlus Python API 기반 결합

EnergyPlus 배포판에 내장된 Python API는 엔진을 프로세스 안에서 실행하고 런타임 콜백과 actuator로 외부 논리를 결합하는 경로를 제공한다. 이 경로는 강화학습 제어 환경 Sinergym^[11]처럼 제어 연구에서 이미 쓰이며, eppy^[12]는 IDF를 객체 수준에서 읽고 수정하는 라이브러리로 파라메트릭 연구에 널리 쓰인다. 본 연구는 도구 결합 자체가 아니라 철도역사 모델에 계량 캘리브레이션·센서 역산·서비스 계층을 한 환경으로 통합구현 및 운영에 있다.

3.1 설계 원칙

설계 원칙은 세 가지이다. 모델을 FMU로 고정하지 않는다. EnergyPlus 배포판에 내장된 pyenergyplus.api로 엔진을 프로세스 안에서 실행하고, 모델은 eppy^[12]로 IDF 객체 수준에서 수정하므로 어떤 변수를 바꾸어도 다시 내보내는 단계가 없다. 실측은 계층을 나누어 결합한다. 계량기 총량은 모델 전체를 캘리브레이션하는 기준으로, 실내환경 센서는 존 단위 검증과 환기·재실 입력의 역산에 쓴다. 응답 시간은 캐시와 대리모델로 확보한다. 같은 조합은 재계산하지 않고 탐색은 대리모델이 즉답한 뒤 후보만 실제 시뮬레이션으로 확인한다.

그림 1 5계층 디지털트윈 아키텍처와 거점역사 구현 구성

Fig. 1 Five-layer digital twin architecture as implemented for railway station

3.2 5계층 구성

시스템은 데이터·모델·시뮬레이션·서비스·인터페이스의 5계층으로 구성한다(그림 1). 각 계층의 설계 구성과 거점역사 구현 상태는 표 2에 정리하였다.

3.3 실측 결합 설계

계량기 총량과의 정합은 월별 12점에 대한 정규화 평균 편차(NMBE)와 평균제곱근오차 변동계수 CV(RMSE)로 판정하며, 판정 기준은 ASHRAE Guideline 14^[13]의 월간 허용범위(NMBE ±5%, CV(RMSE) 15%)이다. 캘리브레이션은 조정 가능한 입력(상시 부하·팬 계통·재실 스케줄·환기량)을 실측 근거로 변경하고 재실행하여 지표를 확인하는 반복 절차로 설계하였다. 현장 센서의 CO₂는 물질수지 역산으로 실효 환기량과 재실 프로파일을 산출하여 모델 입력으로 반영한다. 한 시계열에서 식별되는 것은 환기량과 재실의 곱이므로 재실은 승하차 자료의 프로파일로 외생 입력하고 환기량을 산출한다. 런타임 주입은 pyenergyplus.api의 callback_begin_zone_timestep에 콜백을 등록하고 set_actuator_value로 설정점·스케줄을 갱신하는 인터페이스로 정의하였다. 실행기는 콜백 등록 인자를 받도록 구현되어 있으나 측정값을 actuator에 주입하는 논리는 아직 구현하지 않았다. 5절에서 그 격차를 다룬다.

3.4 파라메트릭·최적화 흐름

파라메트릭 분석은 카탈로그의 파라미터 값을 받아 eppy 변형을 적용한 뒤 작업 큐를 통해 시뮬레이션을 실행한다. 결과 SQL을 파싱하여 목적함수(연간 냉난방 에너지·피크 수요·역사 전력)를 산출하고 파라미터 조합의 해시를 키로 캐시한다(그림 2). 라틴 하이퍼큐브 표본으로 스윕한 결과로 대리모델을 학습한다. 베이지안 최적화가 대리모델 위에서 후보를 탐색하고 후보는 실제 시뮬레이션으로 재검증한다. 캘리브레이션은 같은 실행 경로 위에서 계량 월별 실측과 결과 SQL을 대조하는 별도 판정 모듈이 담당한다.

그림 2 파라메트릭·최적화·캘리브레이션 데이터 흐름

Fig. 2 Data flow for parametric analysis, optimization and calibration

4.1 모델 정의와 생성

대상은 거점역사(지하 2층·지상 3층, 연면적 62,404 m²)이다. 선행 FMU 파이프라인의 150존 모델 대신 검증 가능한 범위로 스코프를 한정한 원칙에 따라 10개 존(실내환경 센서가 있는 3개 존과 주변 7개 존, 15,991 m²) 전관 모델을 사용한다. 파라미터 카탈로그는 존 10개, 가변 파라미터 13개(환기팬 동력·단열 두께·창 열관류율·태양열취득계수(SHGC)·조명밀도·장비밀도·재실밀도·설정온도), 출력 5개를 정의한다(표 3). 별도의 캘리브레이션 논문은 이 가운데 12개를 다룬다. IDF는 카탈로그와 도면·장비일람표 값을 읽는 생성 스크립트가 조립한다. 역사 전체 환기팬 445 kW와 에스컬레이터·엘리베이터 81.9 kW는 집약 부하 객체로, 냉난방은 존별 이상부하 시스템(IdealLoadsAirSystem)으로, 옥상 태양광 202 kW는 발전 객체로 둔다.

모델 계층은 카탈로그·변형·구조 추출의 세 모듈로 구현하였다. 카탈로그는 건물별 YAML 한 파일에 모델·기상 파일 경로, 존 목록, 가변 파라미터의 범위와 기본값, 출력 변수를 담는다. 변형 엔진은 eppy 위에서 필드 설정·스케줄 값 교체·형상 회전·객체 추가의 4종 연산을 파라미터 값 집합에 따라 순서대로 적용해 새 IDF로 저장한다. 구조 추출 모듈은 IDF 표면 좌표를 층고 기준으로 군집화해 건물·층·존·표면·창의 계층 트리와 층별 평면·3차원 형상을 인터페이스 계층에 넘긴다.

4.2 변형·실행 성능

웹 인터페이스에서 IDF 객체 필드를 직접 수정하면 새 IDF와 카탈로그가 등록된다. 실행기는 EnergyPlus 26.1.0 배포판의 pyenergyplus.api를 프로세스 안에서 호출한다. 16스레드 서버(Intel i7-10700F, 30 GiB)에서 10개 존 전관 모델의 연간 시뮬레이션은 1회 3.8~6.1초였다. 결과 파싱과 목적함수 산출을 포함한 작업 큐 처리는 6.0~7.1초였다. 이 실행 시간은 10개 존·이상부하계·플랜트 없는 모델의 값으로 모델 규모에 비례한다. 2026년 7월 22~27일에 234개 파라미터 조합이 캐시되었고, 라틴 하이퍼큐브 스윕 226런이 대리모델 학습에 쓰였다.

실행기는 실행 전에 선행 FMU 파이프라인의 ExternalInterface 블록을 제거하고 Output:SQLite 객체를 주입한다. 프로세스 안에서 EnergyPlus를 짧은 간격으로 반복 실행하면 비정상 종료가 발생할 수 있어 반복 호출이 잦은 기류 추정과 환기 시나리오 배치는 명령줄 실행으로 분리하였다. 런 유형별 소요 시간은 표 4와 같으며 경고 27~29건, 심각 오류 0건이었다.

4.3 실측 연계와 캘리브레이션

계량 실측은 한전 파워플래너의 2025년 월별 사용전력량 12점을 기준으로 하며 모델의 순 전력(시설전력 + 냉난방 부하/성능계수(COP) − 태양광)을 대조한다. 2026년 7월 22일에 보정 파라미터를 확정한 모델은 2025년 기상청 관측 기상과 2024년 실측에 맞춘 태양광으로 재실행했을 때 NMBE +2.32%, CV(RMSE) 5.66%(실측−모델 기준)로 월간 기준을 충족하였으며 별도의 월간 캘리브레이션 논문은 이 판을 기준 버전으로 보고한다. 8월 11일 재캘리브레이션(팬 계통 분리, 재실 연동 외기, 비공조 상시 부하 추가, 라운지 환기량의 CO₂ 역산값 교체; 표준기상연도·설계 태양광 기준)에서는 +0.06%, 4.68%였다. 재캘리브레이션 후에도 중간기 과대(상시 부하 80 kW 과다), 여름·겨울 부족(재실 연동 외기의 최소 풍량 미반영), 9·10월 부족(원인 미상, 습도 부하 가설)의 세 갈래 오차가 상쇄된 채 총량이 맞는 상태이며 본 시스템은 이 진단을 캘리브레이션 기록으로 보존한다.

현장 센서망은 2026년 5월 31일부터 지하 1층 대합실·지하 2층 대합실·고객라운지 3개 존에 배치된 21개 장치 ID(LoRa)로 온·습도, CO₂, PM, VOC를 수집한다. 대합실과 라운지의 CO₂ 시계열을 물질수지로 역산하여 실효 환기량과 재실 프로파일을 산출하였고, 라운지 환기량은 설계 코드값 34 m³/h·인에서 첨두 CO₂ 기준 역산값 12.2 m³/h·인으로 교체하였다. 이 값은 재실 입력에 비례해 움직이는 추정치이며 법정 최소 환기량과의 관계는 추적가스 계측으로 확인할 과제이다. 에너지 캘리브레이션 기준은 2025년 계량, 존 단위 검증은 2026년 센서로 연도가 다르다. 시간 단위 Guideline 14 판정은 수행하지 않았다. 센서망은 장치 분실·파손·교체가 잦아 가용성을 장치 시간 기준의 확보율로 관리한다.

4.4 서비스·인터페이스 계층

서비스 계층은 FastAPI 기반 HTTP 엔드포인트 22개와 WebSocket 1개, Celery 워커 4개(Redis 브로커), SQLite 케이스 캐시로 구성된다. 대리모델은 XGBoost 회귀 3종(연간 냉난방 에너지·피크 수요·역사 전력)으로 학습 180점·검증 46점의 단일 홀드아웃에서 결정계수 0.73·0.91·0.80을 보였고, 역사 전력의 특성 중요도는 환기팬 동력 0.52, 대합실 재실밀도 0.20 순이었다. 신재생 추정 모듈은 기본요금과 실측 부하를 반영하지 않은 시험 구현이다. 기류 모듈은 AirflowNetwork 2존 개념 모델과 지하 2층(대합실·환승통로)의 OpenFOAM 정상상태 CFD(약 65만 셀, 급기 52,500 m³/h ±50% 스윕) 결과를 스냅샷으로 제공한다. 인터페이스 계층은 Next.js 대시보드 7개 탭(환경 모니터링·에너지 모델·에너지 운영·설계 시뮬레이션·신재생·기류·시나리오)으로 3차원 모델과 시계열을 표출하며 공개 도메인을 통해 접속된다. 모니터링·운영 2개 탭은 공개이고 나머지 5개 탭은 관리자 인증 뒤에 둔다. 측정값과 시뮬레이션 값을 같은 차트에 겹쳐 보는 기능은 아직 없다.

실센서 모니터링은 인터페이스 계층의 서버 라우트가 시계열 데이터베이스를 직접 읽으며, 서비스 계층의 센서 API는 데이터 경로 시험용 합성 스트림에 연결되어 있어 본 논문의 실측 수치에는 쓰지 않는다.

4.5 운영

시스템은 2026년 8월 5일 서버 재부팅 후 재기동되어 9월 1일까지 27일간 운영되었다. API·작업 큐·합성 스트림 프로세스는 이 기간에 재기동 없이 가동되었고 대시보드 서버와 터널은 각 1회 재기동되었다. 그 사이 시뮬레이션 런 디렉터리는 343개(5.0 GB)로 늘었다. API 로그의 요청 수는 표 5와 같으며 외부 IP 접속이 포함되어 있다. 상태 확인과 센서 상태는 대시보드와 감시의 자동 폴링이고 시뮬레이션·분석 요청은 신재생·기류·케이스·예측을 합쳐 52건이므로 이 지표는 가용성의 증거이지 사용량의 증거가 아니다. 에너지 운영 탭의 합성 스트림(시뮬레이션 결과에 잡음을 얹은 2초 주기 자료, 27일간 약 3,519만 점)은 데이터 경로 시험용이며 본 논문의 어떤 수치에도 쓰지 않았다.