1. 서 론
1.1 연구 배경
기후변화는 더 이상 미래의 문제가 아니다. 2024년 폭염일수는 24.0일로 평년(10.6일)의 2.3배에 달하였으며, 폭염과 한파로 인한 인명 피해와 경제적 손실이 급증하고 있다(KMA, 2025). 기후 위험에 효과적으로 대응하기 위해서는 다양한 데이터 소스로부터 기상 정보를 실시간으로 수집하고 분석하는 빅데이터 기반 모니터링 플랫폼이 필수적이다. 본 연구에서 “빅데이터 기반”이란 빅데이터 플랫폼의 데이터 수집 인프라 계층을 의미하며, 데이터 분석이나 예측 모델이 아닌 수집 인프라의 신뢰성 확보에 초점을 둔다.
빅데이터 플랫폼의 핵심은 데이터 수집 시스템의 안정성이다. 2025년 9월 대전 국가정보자원관리원 데이터센터 화재는 인프라 장애가 재난 대응 시스템에 미치는 파급력을 보여주었다(MOIS, 2025). 기후 데이터는 센서 장애에 의한 시계열 결측, 극한 기상 시 돌발 트래픽, 다기관 이질적 데이터 소스 통합 등의 고유한 특성을 가지며(Choi, 2018), 데이터 수집 장애가 곧 재난 대응 실패로 이어질 수 있다.
그러나 기존 기후 모니터링 시스템의 데이터 수집 상태 모니터링 방식은 운영자가 주기적으로 데이터베이스를 조회하는 수동적 접근에 의존하고 있다. Park et al. (2023)은 폭염 모니터링 시스템에서 도시 빅데이터를 활용하였으나 데이터 수집 장애 감지 메커니즘은 다루지 않았다. 수동 모니터링 방식에서는 데이터 수집 어댑터의 장애가 다음 점검 시점까지 인지되지 않아, 재난 대응 골든타임을 놓치는 결과를 초래할 수 있다. Table 1은 기존 수동 모니터링 방식의 주요 문제점이다.
Table 1
Limitations of Existing Monitoring Approaches
1.2 연구 목적 및 기여점
본 연구는 기후 위험 모니터링을 위한 빅데이터 플랫폼에서 데이터 수집 어댑터가 자신의 운영 상태를 표준 메트릭으로 실시간 노출하고 중앙 수집기가 자동으로 수집하는 메트릭 기반 자동화 모니터링 구조를 제안하고 검증하는 것을 목적으로 한다.
본 연구의 주요 기여점은 다음과 같다. 첫째, Prometheus 표준 형식의 메트릭 자동 노출을 통해 장애 감지 시간을 약 95% (인프라 수준 99% 이상) 단축시키는 실시간 장애 감지 구조를 제안한다. 둘째, 폭염⋅한파(Critical), 단기예보(High), 가뭄⋅장기관측(Medium)으로 기후 위험을 분류하고 각 레벨에 맞는 차별화 모니터링 전략을 제시한다. 셋째, 오픈소스 기반(Spring Boot 3.5.6, Java 17, PostgreSQL 17, Docker) 구현과 기상청 API를 이용한 48시간 연속 운영 실험 및 5종 장애 주입 실험을 통해 시스템의 실용성과 경량성(평균 메모리 481 MB, CPU 0.01%)을 입증한다.
2. 관련 연구
2.1 기후 위험 모니터링과 빅데이터 기술
기후변화로 인한 극한 기상 현상의 빈도와 강도가 증가하면서 빅데이터 기반 기후 위험 모니터링 시스템의 중요성이 커지고 있다. Park et al. (2023)은 폭염 심각도 진단을 위해 도시 빅데이터를 활용하였으며, Kim et al. (2018)은 재난자원 관리를 위한 위험성 평가 체계를 제안하였고, Park et al. (2019)은 재난안전데이터 시각화 시스템을 설계하였다. Choi (2018)는 기후변화 빅데이터의 높은 복잡성과 가변성을 지적하며 수집 단계의 이해가 분석의 전제조건임을 강조하였다. 그러나 이러한 연구들은 데이터 수집 인프라의 신뢰성을 보장하는 메커니즘이 부재하다는 공통된 한계를 가진다.
2.2 메트릭 기반 모니터링 기술
클라우드 네이티브 환경에서 Prometheus 기반 메트릭 수집 체계가 업계 표준으로 자리잡았다(CNCF, 2016). Sukhija and Bautista (2019) 및 Sukhija et al. (2020)은 고성능 컴퓨팅 환경에서, Saputra et al. (2024)은 실시간 서버 모니터링에서 그 효과를 입증하였다. 그러나 이러한 기술들은 IT 인프라의 성능 최적화를 목적으로 개발된 것으로, 기후 위험 모니터링이라는 방재 분야에 적용된 사례는 전무하다.
2.3 기존 데이터 수집 모니터링 방식의 한계
기존의 데이터 수집 상태 모니터링은 데이터 저장 여부를 사후적으로 확인하는 간접 모니터링 방식(Ryu, 2018)이거나, Push 방식으로 상태를 전송하여 수집 노드 장애 시 감지가 실패하는 방식(Siow et al., 2018)이다. 핵심 문제는 기존 방식이 모두 데이터 수집 프로세스가 정상 동작하는지를 직접 확인하지 않는다는 점이다.
2.4 본 연구의 차별성
Table 2는 기존 연구와 본 연구의 접근 방법을 비교한 것이다.
Table 2
Comparison of Related Studies and Proposed System
| Category | Representative Studies | Key Limitation | This Study’s Approach |
|---|---|---|---|
| Climate Hazard Monitoring |
Park et al. (2023); Kim et al. (2018); Park et al. (2019); Fang et al. (2014) |
- Data collection reliability mechanisms absent - Manual monitoring |
- Automated real-time monitoring via metrics exposure |
| Metrics-based Monitoring |
CNCF (2016); Sukhija and Bautista (2019); Sukhija et al. (2020); Saputra et al. (2024) |
- No application to disaster prevention domain | - First application of Prometheus to climate hazard monitoring with priority-based strategy |
| Data Collection Monitoring |
Ryu (2018); Siow et al. (2018) |
- Indirect monitoring via database queries - Failure detected through data absence |
- Direct metrics exposure by adapters - Approximately 95% reduction in failure detection time |
본 연구는 데이터 수집 프로세스가 자신의 상태를 직접 노출하는 메트릭 기반 아키텍처를 제안하며, 기후 위험 모니터링 분야에 Prometheus 기반 메트릭 노출 방식을 적용한 최초의 시도로서, 오픈소스 기반 프로토타입 구현과 48시간 검증을 통해 실용성을 입증한다.
3. 메트릭 기반 데이터 수집 상태 모니터링 시스템 설계
3.1 시스템 개요
기후 위험 모니터링 시스템은 재난 대응이라는 목적으로 인해 일반적인 빅데이터 플랫폼과 차별화된 요구사항을 가진다. 첫째, 기후 위험 유형에 따라 요구되는 실시간성 수준이 상이하다. 폭염과 한파는 수십 분 내 장애를 감지해야 인명 피해를 최소화할 수 있으며, 가뭄과 같은 장기 기후 현상은 수일 내 장애 복구로도 분석에 큰 영향이 없다. 둘째, 기상청, 환경부, 국립재난안전연구원 등 다중 기관의 데이터 소스를 통합 모니터링해야 한다(MOIS, 2025).
기존의 데이터 수집 상태 확인 방식은 수집된 데이터의 유무를 사후적으로 확인하는 간접적 접근에 의존하여, 수집 프로세스 자체의 장애를 실시간으로 파악하기 어렵다(Fang et al., 2014; Ryu, 2018). 이러한 한계를 극복하기 위해 본 연구에서는 즉시성(5분 이내 장애 감지), 신뢰성(장애 격리 및 자동 복구), 확장성(수평 확장 가능 구조), 표준화(Prometheus 표준 채택)의 4가지 설계 원칙을 수립하였다.
본 연구에서 제안하는 시스템은 데이터 수집 어댑터가 자신의 상태 정보를 표준화된 메트릭 형식으로 HTTP 엔드포인트에 노출하고, 중앙 집중식 메트릭 수집기가 이를 주기적으로 수집하는 Pull 방식의 아키텍처를 채택한다. 시스템은 데이터 수집 어댑터, 메트릭 수집기, 프로세서 노드, 모니터링 인터페이스의 4가지 핵심 구성 요소로 이루어진다.
3.2 전체 시스템 아키텍처
제안하는 시스템은 Fig. 1과 같이 데이터 수집 계층, 메트릭 수집 계층, 저장 계층, 시각화 및 알림 계층의 4계층 구조로 설계되었다. 각 계층은 명확히 정의된 인터페이스를 통해 통신하며, 계층 간 느슨한 결합을 통해 유연성과 확장성을 확보하였다.
데이터 수집 계층은 다수의 데이터 수집 어댑터로 구성되며, 각 어댑터는 특정 데이터 소스로부터 기후 위험 데이터를 수집하는 독립적인 프로세스로 동작한다. 메트릭 수집 계층은 Prometheus 기반의 메트릭 수집기로 구성되며(An et al., 2021), 각 어댑터의 엔드포인트에 주기적으로 HTTP GET 요청을 전송하여 메트릭을 수집한다. 저장 계층은 시계열 데이터베이스와 관계형 데이터베이스로 구성되며, 시각화 및 알림 계층은 대시보드와 알림 시스템으로 구성되어 운영자가 실시간으로 시스템 상태를 모니터링할 수 있도록 한다.
3.3 데이터 수집 어댑터 설계
3.3.1 기후 위험별 우선순위 기반 모니터링 전략
데이터 수집 어댑터는 기후 위험 유형에 따라 차별화된 모니터링 전략을 지원해야 한다. 본 연구에서는 기후 위험을 실시간성 요구수준에 따라 세 가지 우선순위 레벨로 분류하였다. Table 3은 각 우선순위 레벨의 특성과 모니터링 전략을 정리한 것이다.
Table 3
Priority-based Monitoring Strategy for Climate Hazards
Critical 레벨은 폭염, 한파, 집중호우와 같이 인명 피해에 직결되는 급성 기후 위험을 대상으로 하며, 2회 연속 수집 실패 시 즉시 알림을 발생시킨다.
3.3.2 어댑터 구조 및 메트릭 정의
데이터 수집 어댑터는 외부 데이터 소스로부터 기후 위험 관련 데이터를 수집하고, 수집 과정의 상태 정보를 메트릭 형태로 노출한다. 어댑터가 노출하는 4가지 메트릭은 Table 4와 같다.
Table 4
Definition and Purpose of Collection Metrics
각 메트릭은 region (지역), type (데이터 타입), priority (우선순위) 레이블을 포함하여 운영자가 PromQL로 특정 조건의 메트릭을 필터링하고 집계할 수 있다(An et al., 2021).
3.3.3 기상 데이터의 도메인 특수성과 메트릭 커버리지
기상 데이터는 일반적인 웹 API 데이터와 구별되는 고유한 특성을 가진다. 기상청 API (KMA, 2023)는 엄격한 시간 종속성(초단기실황: 매시 +10분, 초단기예보: 매시 +45분), 호출량 제한(일일 20,000~30,000건), 기상 특보 시 돌발 트래픽 발생, 시계열 결측의 분석 품질 영향 등의 특성을 가진다(WMO, 2018). Table 5는 이러한 도메인 특수성과 제안 메트릭의 커버리지, 그리고 WMO 데이터 품질 차원(WMO, 2019)과의 대응 관계를 정리한 것이다.
Table 5
Meteorological Data Characteristics, Metric Coverage, and Data Quality Dimensions
제안하는 4가지 메트릭은 WMO 데이터 품질 기준 중 완전성(completeness)과 적시성(timeliness)을 커버하나, 일관성(consistency)과 정확성(accuracy) 차원은 향후 데이터 품질 검증 계층을 추가하여 보완할 필요가 있다.
3.4 메트릭 수집기 및 저장 구조
메트릭 수집기는 데이터 수집 어댑터가 노출한 메트릭을 주기적으로 수집하여 시계열 데이터베이스에 저장한다. 본 연구에서는 Pull 방식의 Prometheus를 채택하였다(An et al., 2021). Pull 방식은 중앙 서버가 각 타겟에 주기적으로 접속하여 데이터를 가져오는 방식으로, 수집 주기를 직접 제어하고 타겟의 생존 여부를 즉시 파악할 수 있다. 메트릭 수집기는 각 타겟의 HTTP 엔드포인트에 5분 주기로 접속하며, 수집된 메트릭은 메트릭 이름과 레이블의 조합을 기준으로 시계열을 식별하여 저장된다.
3.5 컨테이너 기반 배포 및 모니터링 인터페이스
각 구성 요소는 독립적인 Docker 컨테이너로 패키징되어 배포되며, 데이터 수집 작업은 Cron 표현식 기반 스케줄러를 통해 수행된다. 모니터링 인터페이스는 시각화 대시보드와 알림 시스템으로 구성되며, 대시보드는 기후 위험 우선순위를 반영하여 Critical 레벨 데이터 소스를 최상단에 배치한다. 알림 규칙은 우선순위별로 차별화되어, Critical 레벨은 2회 연속 수집 실패 시 즉시 SMS/이메일 알림, High 레벨은 6시간 이상 실패 시 이메일, Medium 레벨은 48시간 이상 실패 시 일일 보고서에 포함한다.
3.6 신뢰성 및 확장성
시스템의 신뢰성은 세 가지 메커니즘으로 확보된다. 첫째, 각 데이터 수집 어댑터가 독립적인 컨테이너로 실행되어 장애가 다른 어댑터에 전파되지 않는다. 다만, 데이터베이스 등 공유 인프라의 장애는 이 격리 범위에 포함되지 않으며, 인프라 이중화로 별도 대응해야 한다. 둘째, 어댑터 프로세스의 비정상 종료 시 Docker의 자동 재시작 정책에 따라 복구된다. 셋째, PostgreSQL과 Prometheus의 데이터 디렉터리를 호스트 볼륨에 마운트하여 데이터 영속성을 보장한다.
수집 대상이 증가하여 단일 Prometheus 인스턴스의 처리 용량을 초과할 경우, Prometheus Federation 아키텍처를 통해 수평 확장이 가능하다. Federation은 하위 인스턴스가 수집한 메트릭을 상위 인스턴스가 선택적으로 집계하는 계층적 구조로, 기관별 리프(leaf) 레벨에서 광역 리전(regional) 레벨, 전국 글로벌(global) 레벨로의 확장 경로를 제공한다. 본 시스템이 Prometheus 표준 메트릭 형식과 HTTP 기반 Pull 아키텍처를 채택하고 있으므로, Federation 확장 시 어댑터 코드 수정 없이 Prometheus 설정 파일의 변경만으로 다기관 통합이 가능하다. 다만, 본 연구의 프로토타입은 단일 프로세서 노드에서의 검증에 초점을 맞추었으며, 다기관 Federation 환경에서의 실증과 샤딩 전략, 장기 저장 확장(Thanos 등)은 향후 연구 과제로 남겨둔다.
4. 시스템 구현 및 검증
4.1 시스템 구현
4.1.1 데이터 수집 어댑터 구현
데이터 수집 어댑터는 Spring Boot 3.5.6과 Java 17 기반으로 구현되었으며, PostgreSQL 17을 데이터베이스로 사용하였다. 외부 API 연동 계층은 기상청 단기예보 조회서비스 API와 HTTP 통신을 수행하고, 스케줄링 계층은 Spring의 @Scheduled 어노테이션을 통해 초단기실황은 매시간 10분, 초단기예보는 매시간 45분에 자동 실행되도록 설정하였다. 메트릭 생성은 Micrometer 라이브러리를 통해 Prometheus 표준 형식으로 이루어지며, Spring Boot Actuator의 /actuator/ prometheus 엔드포인트로 노출된다.
이러한 메트릭 노출 방식은 기존의 데이터베이스 직접 조회 방식과 근본적으로 다르다. Table 6은 두 방식의 주요 차이점을 비교한 것이다.
Table 6
Comparison between Database Query Method and Metric Exposure Method
시스템의 이식성을 위해 Docker 컨테이너 기반 배포를 채택하였으며, 환경변수 설정만으로 여러 지역의 인스턴스를 동시에 실행할 수 있다.
4.2 실험 설계
시스템의 신뢰성과 효과성을 검증하기 위해 서울(격자좌표 x = 60, y = 127)과 분당(격자좌표 x = 63, y = 123) 2개 지역을 대상으로 2025년 10월 12일 23:01부터 10월 14일 23:01 (KST)까지 48시간 연속 데이터 수집 실험을 수행하였다. 각 지역마다 독립된 Docker 컨테이너 인스턴스를 실행하였으며, Prometheus는 5분(300초) 주기로 메트릭을 수집하였다.
Prometheus 수집 주기의 최적값을 결정하기 위해 60초, 180초, 300초, 600초의 4가지 주기에 대한 비교 실험을 수행하였다. Table 7은 수집 주기별 비교 결과이다.
Table 7
Scrape Interval Trade-off Analysis
| Interval (sec) | Scrapes / Hour | Prometheus CPU (%) | Prometheus Memory (MB) | Detection Time (sec) |
|---|---|---|---|---|
| 60 | 60 | 0.07 | 31.6 | 2,007 |
| 180 | 20 | 0.01 | 28.5 | 1,274 |
| 300 | 12 | 0.01 | 28.2 | 1,242 |
| 600 | 6 | 0.01 | 28.2 | 1,165 |
60초 주기는 300초 대비 CPU 사용률이 7배 증가하는 반면 장애 감지 시간 개선 효과는 미미하였다. 이는 카운터 기반 장애 감지에서 감지 시간이 Prometheus 스크래핑 주기보다 데이터 수집 스케줄 주기(매시간 10분, 45분)에 주로 의존하기 때문이다. 따라서 자원 효율성과 감지 성능의 최적 균형점인 300초(5분)를 선정하였다.
4.3 실험 결과
4.3.1 데이터 수집 안정성 및 장애 감지 효과
48시간 동안 서울과 분당 각각 96회, 합계 192회의 데이터 수집이 시도되었으며, 모든 수집이 성공하여 100% 성공률을 달성하였다. 총 6,528개의 기상 데이터 레코드가 수집되었으며, weather_collection_success_total 메트릭은 0에서 192까지 단조 증가하여 누락된 수집 주기가 없음을 확인하였다. 수집 시각의 편차는 스케줄 시각 대비 ±2분 이내로 측정되었다.
4.3.2 장애 감지 효과
Table 8은 기존 방식과 제안 방식의 장애 감지 시간을 비교한 것이다.
Table 8
Comparison of Failure Detection Time
4.3.3 시스템 성능 분석
weather_collection_duration_seconds 메트릭 분석 결과는 Table 9와 같다. 전체 평균 수집 소요 시간은 372.49 ms로 측정되었으며, 두 지역 간 차이는 약 13 ms로 일관된 성능을 확인하였다.
Table 9
Data Collection Performance Analysis
| Region | Total Duration (s) | Number of Collections | Average (ms) | Efficiency |
|---|---|---|---|---|
| Seoul | 36.382 | 96 | 378.98 | High |
| Bundang | 35.137 | 96 | 366.01 | High |
| Overall | 71.519 | 192 | 372.49 | High |
시스템 자원 사용량은 Table 10과 같다. 평균 메모리 481.43 MB, CPU 사용률 0.01%로 매우 경량적이며, 제한된 자원의 소규모 기관에서도 운영 가능함을 입증하였다.
4.3.4 장애 감지 효과
시스템의 장애 감지 능력을 실증적으로 검증하기 위해 5종의 장애 시나리오를 설계하고 장애 주입(fault injection) 실험을 수행하였다(Konstantinou et al., 2021). 서울 인스턴스에 장애를 주입하고 분당 인스턴스는 정상 동작을 유지하여 장애 격리도 함께 검증하였다. Table 11은 장애 시나리오, 주입 방법, 감지 결과를 정리한 것이다.
Table 11
Fault Injection Scenarios and Results
인프라 수준 장애(F2, F4)는 Prometheus target 상태 변화를 통해 5분 이내에 신속하게 감지되었다. F2 (네트워크 단절)는 93초, F4 (컨테이너 크래시)는 32초 만에 감지되었다. 애플리케이션 수준 장애(F1, F3, F5)는 카운터 기반으로 감지되었으며, 최대 지연 시간은 ‘수집 스케줄 주기(최대 35분) + Prometheus 스크래핑 주기(5분)’로 결정된다. F3 (DB 장애)에서는 두 인스턴스가 동일한 PostgreSQL을 공유하여 장애 격리가 이루어지지 않았으며, 운영 환경에서는 데이터베이스 이중화로 해결할 수 있다.
Table 12는 장애 유형을 메트릭 시그니처로 분류한 결과이다.
Table 12
Error Type Classification by Metrics Signature
5종의 장애 유형은 failure_total 변화, duration 이상, Prometheus target 상태의 3가지 메트릭 차원 조합으로 구분된다. F1 (즉시 거부)과 F5 (타임아웃)는 failure_total이 동일하게 증가하지만 duration 이상 여부로 감별되며, 인프라 장애(F2, F4)는 target 상태 변화로 즉시 식별된다. 향후 failure_total에 오류 원인별 세분화 레이블을 추가하면 자동 분류가 더욱 정밀해질 것으로 기대된다.
5. 결 론
본 연구는 기후 위험 모니터링을 위한 빅데이터 플랫폼에서 데이터 수집 어댑터가 자신의 상태 메트릭을 표준 형식의 엔드포인트에 노출하고 중앙 집중식 수집기가 자동으로 수집하는 메트릭 기반 모니터링 시스템을 제안하고 검증하였다. 오픈소스 기술(Spring Boot 3.5.6, Java 17, PostgreSQL 17, Docker)로 프로토타입을 구현하였으며, 기상청 API를 이용한 48시간 연속 운영 실험과 5종의 장애 주입 실험을 통해 유효성을 입증하였다.
서울과 분당 2개 지역에서 192회 수집 시도 중 100% 성공률을 달성하였으며, 총 6,528개의 기상 레코드를 평균 372 ms의 수집 소요시간으로 처리하였다. 시스템 자원 사용량은 평균 메모리 481 MB, CPU 사용률 0.01%로 매우 경량적이었다. 기존 수동 데이터베이스 조회 방식 대비 장애 감지 시간을 약 95% (인프라 수준 99% 이상) 단축시켰으며, 5분 수집 주기는 Interval Trade-off 분석을 통해 자원 효율성과 감지 성능의 최적 균형점으로 선정되었다. 5종의 장애 시나리오에 대한 장애 주입 실험을 통해 인프라 수준 장애는 5분 이내에, 애플리케이션 수준 장애는 최대 약 40분 이내에 자동 감지되며 모든 유형에서 자동 복구가 가능함을 검증하였다.
본 연구는 실험 기간이 48시간으로 제한되어 장기 안정성 검증이 부족하며, 수집 대상 지역이 2곳으로 대규모 확장성을 검증하지 못한 한계가 있다. 향후 연구에서는 최소 3개월 이상의 장기 운영 실험, Prometheus Alertmanager 연동을 통한 실시간 알림 구현, 전국 규모의 Prometheus Federation 아키텍처 성능 검증, 다기관 이질적 데이터 소스에 대한 메트릭 표준화 방안 연구가 필요하다.
PDF Links
PubReader
ePub Link
Full text via DOI
Download Citation
Print
