1️⃣ 물리 계층 (Physical Layer)

가장 밑바닥, 즉 실제 하드웨어 단계야. 여기에는:

• 스마트 미터 디바이스
실제로 전기, 가스, 수도를 측정하는 물리적 장치들이지. 요즘 미터기들은 정말 똑똑해서 전압, 전류, 역률, 주파수까지 다 측정해. 😎

• 센서 네트워크
온도, 습도, 조도, CO2 농도 같은 환경 데이터를 수집하는 센서들도 포함돼. 이것들이 에너지 사용 패턴을 이해하는 데 중요한 컨텍스트를 제공하거든.

• 통신 모듈
측정한 데이터를 상위 시스템으로 전송하는 통신 장치. RS-485, Modbus, Zigbee, LoRa, LTE 등 다양한 프로토콜을 사용해.

2️⃣ 데이터 수집 계층 (Data Acquisition Layer)

물리 계층에서 올라온 날것의 데이터를 받아서 정리하는 단계야. 여기서 중요한 건:

• 데이터 수집 주기
얼마나 자주 데이터를 가져올 건지 결정해야 해. 상업건물에서는 보통 15분~1시간 간격으로 수집하는데, 중요한 설비는 1분 단위로도 해. 실시간성이 중요하거든! ⏱️

• 프로토콜 변환
각 미터기마다 다른 언어(프로토콜)를 쓰니까, 이걸 통일된 형식으로 바꿔줘야 해. 마치 통역사 같은 역할이지.

• 초기 검증
말도 안 되는 값(음수 전력량이라든지)이나 통신 오류를 걸러내는 1차 필터링을 해.

3️⃣ 데이터 저장 계층 (Data Storage Layer)

수집된 데이터를 체계적으로 저장하는 단계. 여기가 바로 오늘의 핵심이야! 🎯

• 시계열 데이터베이스 (Time-Series DB)
에너지 데이터는 시간에 따라 변하는 시계열 데이터야. 그래서 일반 데이터베이스보다 시계열 전용 DB(InfluxDB, TimescaleDB, OpenTSDB 등)를 많이 써. 이게 훨씬 빠르고 효율적이거든!

• 관계형 데이터베이스 (Relational DB)
건물 정보, 미터 정보, 테넌트 정보 같은 정적 데이터는 MySQL, PostgreSQL 같은 관계형 DB에 저장해. 이건 자주 바뀌지 않는 마스터 데이터야.

• 데이터 압축 및 아카이빙
오래된 데이터는 압축해서 저장하거나 별도 아카이브로 옮겨. 안 그러면 데이터가 기하급수적으로 늘어나서 저장 공간이 부족해지거든! 💾

4️⃣ 응용 계층 (Application Layer)

저장된 데이터를 실제로 활용하는 단계야. 여기서:

• 데이터 분석 및 리포팅
일별, 월별, 연별 사용량 통계, 피크 시간대 분석, 비용 계산 등을 수행해.

• 시각화 및 대시보드
그래프, 차트, 히트맵 같은 시각적 요소로 데이터를 보기 쉽게 만들어줘. 숫자만 보면 머리 아프잖아? 📈

• 알림 및 제어
이상 패턴 감지하면 알림 보내고, 필요하면 자동으로 설비를 제어하기도 해.

📍 1. 계측 데이터 (Metering Data)

가장 기본이 되는 데이터야. 실제 에너지 사용량을 담고 있지.

데이터 구조 예시:

{
  "meter_id": "MTR-B101-E001",
  "timestamp": "2024-01-15T14:30:00Z",
  "energy_type": "electricity",
  "readings": {
    "active_energy": 1234.56,  // kWh
    "reactive_energy": 123.45,  // kVArh
    "voltage_l1": 220.5,  // V
    "voltage_l2": 221.2,
    "voltage_l3": 219.8,
    "current_l1": 15.3,  // A
    "current_l2": 14.8,
    "current_l3": 15.1,
    "power_factor": 0.92,
    "frequency": 60.0  // Hz
  },
  "quality_flag": "good",
  "data_source": "automatic"
}

보다시피 단순히 "전기 몇 kWh 썼다" 이상의 정보가 들어가 있어. 전압, 전류, 역률까지 측정하는 이유는 전력 품질을 모니터링하기 위해서야. 전압이 불안정하거나 역률이 낮으면 전기요금 폭탄 맞을 수 있거든! 💸

주요 필드 설명:

• meter_id: 미터기 고유 식별자. 보통 건물코드-층-미터번호 형식으로 구성해.
• timestamp: 측정 시각. UTC 기준으로 저장하는 게 국제 표준이야.
• energy_type: 전기(electricity), 가스(gas), 수도(water), 냉난방(heating/cooling) 등
• quality_flag: 데이터 품질 상태. good, estimated, suspicious, error 등
• data_source: 자동 수집인지 수동 입력인지 구분

🏢 2. 자산 정보 데이터 (Asset Information)

건물, 미터기, 설비에 대한 정적 정보야. 이건 자주 바뀌지 않아서 관계형 DB에 저장해.

건물 정보 테이블 구조:

미터 정보 테이블 구조:

이런 정보들이 있어야 나중에 "이 미터는 언제 설치됐지?", "교정 시기가 지났네?" 같은 관리가 가능해져. 🔍

👥 3. 테넌트 및 계약 데이터 (Tenant & Contract Data)

상업건물에서 정말 중요한 부분! 누가 어디를 쓰고 있고, 요금은 어떻게 부과할지에 대한 정보야.

테넌트 정보 구조:

{
  "tenant_id": "TNT-2024-0015",
  "tenant_name": "ABC 주식회사",
  "business_type": "IT 서비스",
  "contact": {
    "person": "홍길동",
    "phone": "02-1234-5678",
    "email": "contact@abc.com"
  },
  "lease_info": {
    "start_date": "2024-01-01",
    "end_date": "2026-12-31",
    "area": 250.5,  // ㎡
    "floor": "5F",
    "zone": "5F-East"
  },
  "assigned_meters": [
    "MTR-B101-E005",
    "MTR-B101-W005",
    "MTR-B101-G005"
  ],
  "billing_config": {
    "billing_cycle": "monthly",
    "rate_type": "time_of_use",  // 시간대별 요금제
    "base_rate": 120.5,  // 원/kWh
    "peak_rate": 180.0,
    "off_peak_rate": 90.0,
    "demand_charge": 8000  // 원/kW
  }
}

여기서 핵심은 assigned_meters 필드야. 한 테넌트가 여러 개의 미터를 사용할 수 있거든. 예를 들어 전기 미터, 수도 미터, 가스 미터를 각각 가질 수 있지.

그리고 billing_config는 요금 계산의 핵심이야. 시간대별 요금제(TOU: Time of Use)를 쓰면 피크 시간대에는 비싸고, 심야에는 저렴하게 책정할 수 있어. 이게 에너지 수요 분산에도 도움이 되거든! 💰

📈 4. 집계 및 통계 데이터 (Aggregated & Statistical Data)

원시 데이터를 그대로 쓰면 너무 방대해서 분석이 어려워. 그래서 일정 주기로 집계한 데이터를 별도로 저장해.

시간대별 집계 구조:

집계 데이터 예시:

{
  "aggregation_id": "AGG-2024-01-15-14",
  "meter_id": "MTR-B101-E001",
  "period_start": "2024-01-15T14:00:00Z",
  "period_end": "2024-01-15T15:00:00Z",
  "aggregation_type": "hourly",
  "statistics": {
    "total_consumption": 125.6,  // kWh
    "average_power": 125.6,  // kW
    "max_power": 145.2,
    "min_power": 98.3,
    "max_power_time": "2024-01-15T14:23:00Z",
    "load_factor": 0.865,  // 평균/최대
    "data_completeness": 100.0  // %
  },
  "cost": {
    "energy_charge": 15072,  // 원
    "demand_charge": 1161.6,
    "total": 16233.6
  }
}

집계 데이터의 장점은:

• 쿼리 속도 향상: 1년치 1분 데이터를 조회하는 대신 월별 집계만 보면 되니까 훨씬 빨라! ⚡
• 저장 공간 절약: 원시 데이터는 오래되면 삭제하고 집계 데이터만 남겨도 돼.
• 분석 용이성: 통계값이 이미 계산되어 있어서 바로 사용 가능해.

⚠️ 5. 이벤트 및 알람 데이터 (Event & Alarm Data)

시스템에서 발생하는 각종 이벤트와 알람을 기록하는 데이터야. 이게 있어야 문제 발생 시 추적이 가능해!

이벤트 데이터 구조:

{
  "event_id": "EVT-2024-0001234",
  "timestamp": "2024-01-15T14:35:22Z",
  "event_type": "alarm",
  "severity": "high",  // low, medium, high, critical
  "category": "power_quality",
  "source": {
    "meter_id": "MTR-B101-E001",
    "building_id": "B101",
    "location": "3F East Wing"
  },
  "description": "전압 불균형 감지",
  "details": {
    "voltage_l1": 220.5,
    "voltage_l2": 221.2,
    "voltage_l3": 205.3,  // 비정상적으로 낮음
    "imbalance_rate": 7.2  // %
  },
  "threshold": {
    "parameter": "voltage_imbalance",
    "limit": 5.0,
    "actual": 7.2
  },
  "status": "active",
  "acknowledged": false,
  "acknowledged_by": null,
  "acknowledged_time": null,
  "resolved": false,
  "resolution_time": null,
  "actions_taken": []
}

주요 이벤트 유형들:

🔴 Critical (긴급)
• 전력 공급 중단
• 화재 감지
• 주요 설비 고장

🟠 High (높음)
• 전압/전류 이상
• 과부하 상태
• 통신 두절

🟡 Medium (중간)
• 에너지 사용량 급증
• 역률 저하
• 센서 오류

🟢 Low (낮음)
• 정기 점검 알림
• 교정 시기 도래
• 소프트웨어 업데이트 필요

1단계: 데이터 수집 (Collection)

실시간 수집 프로세스:

① 미터 폴링 (Polling)
데이터 수집기(Gateway)가 정해진 주기마다 각 미터에 "데이터 줘!" 하고 요청해. 보통 Modbus RTU/TCP, BACnet, DLMS/COSEM 같은 프로토콜을 사용하지.

② 데이터 버퍼링
수집된 데이터를 일단 로컬 버퍼에 임시 저장해. 네트워크가 끊겨도 데이터를 잃어버리지 않게 하기 위해서야. 📦

③ 타임스탬프 동기화
각 미터의 시계가 조금씩 다를 수 있으니까, NTP(Network Time Protocol) 서버와 동기화해서 정확한 시간을 기록해.

④ 데이터 전송
버퍼에 쌓인 데이터를 중앙 서버로 전송해. MQTT, HTTP REST API, 또는 전용 프로토콜을 사용해.

2단계: 데이터 검증 (Validation)

수집된 데이터가 믿을 만한지 확인하는 단계야. 쓰레기 데이터가 들어가면 분석 결과도 쓰레기가 되거든! 🗑️

검증 항목들:

• 범위 체크 (Range Check)
전압이 음수라든지, 전류가 정격의 200%를 넘는다든지 하는 말도 안 되는 값을 걸러내.

• 변화율 체크 (Rate of Change Check)
1분 사이에 전력 사용량이 10배로 뛰었다? 뭔가 이상해! 급격한 변화는 의심해봐야 해.

• 일관성 체크 (Consistency Check)
3상 전력에서 각 상의 전압이 너무 차이 나면 문제가 있는 거야. 서로 연관된 값들 간의 관계를 확인해.

• 중복 체크 (Duplicate Check)
같은 타임스탬프에 같은 데이터가 두 번 들어오면 하나는 버려야지.

검증 실패 시 처리:

{
  "validation_result": "failed",
  "original_value": -123.45,
  "validation_rules_failed": [
    "range_check"
  ],
  "action_taken": "flagged_for_review",
  "estimated_value": null,
  "confidence": 0.0,
  "manual_review_required": true
}

3단계: 데이터 정규화 (Normalization)

각 미터마다 다른 단위나 형식을 사용할 수 있으니까, 통일된 형식으로 변환하는 과정이야.

정규화 작업들:

• 단위 변환
Wh → kWh, BTU → kWh, m³ → L 등 표준 단위로 통일

• 시간대 변환
로컬 시간 → UTC 시간으로 변환

• 데이터 타입 통일
문자열로 온 숫자를 실제 숫자 타입으로 변환

• 결측치 처리
빠진 데이터를 보간(interpolation)하거나 추정(estimation)해서 채워 넣어. 물론 추정값이라는 플래그는 달아놔야 해! 🏷️

4단계: 데이터 저장 (Storage)

검증되고 정규화된 데이터를 적절한 저장소에 저장하는 단계야.

저장 전략:

• Hot Storage (뜨거운 저장소) 🔥
최근 7일~1개월 데이터. SSD 기반, 빠른 조회 속도. 실시간 대시보드용.

• Warm Storage (따뜻한 저장소) 🌡️
1개월~1년 데이터. 일반 HDD, 중간 속도. 월간/분기 리포트용.

• Cold Storage (차가운 저장소) ❄️
1년 이상 데이터. 압축 저장, 느린 조회. 규제 대응, 장기 분석용.

데이터 압축 예시:
원시 데이터가 1년에 1TB라면, 압축하면 100GB 정도로 줄일 수 있어. 특히 시계열 데이터는 패턴이 반복되니까 압축률이 좋거든!

5단계: 데이터 집계 (Aggregation)

원시 데이터를 다양한 시간 단위로 집계하는 과정이야. 이게 있어야 빠른 분석이 가능해!

집계 작업 스케줄:

집계할 때는 단순히 합계만 내는 게 아니라, 평균, 최대, 최소, 표준편차 같은 통계값도 함께 계산해. 이게 나중에 패턴 분석할 때 엄청 유용하거든! 📊

📊 실시간 대시보드

건물 관리자가 가장 많이 보는 화면이야. 실시간으로 에너지 사용 현황을 한눈에 파악할 수 있어.

대시보드 주요 위젯들:

• 현재 전력 사용량 게이지 ⚡
지금 이 순간 건물 전체가 몇 kW를 쓰고 있는지 표시. 계약 전력 대비 몇 %인지도 보여줘.

• 층별/구역별 히트맵 🗺️
어느 층, 어느 구역에서 에너지를 많이 쓰는지 색깔로 표시. 빨간색일수록 많이 쓰는 거야.

• 시간대별 사용량 그래프 📈
오늘 하루 동안 전력 사용량이 어떻게 변했는지 실시간 그래프로 표시. 어제, 지난주 같은 날과 비교도 가능해.

• 알람 및 이벤트 목록 🚨
현재 발생 중인 알람이나 최근 이벤트를 시간순으로 표시. 긴급한 것부터 우선순위로 정렬해.

• 비용 미터 💰
오늘 현재까지 발생한 전기요금을 실시간으로 계산해서 보여줘. "지금까지 XX만원 썼어요!" 이런 식으로.

📈 분석 리포트

주기적으로 생성되는 상세 분석 보고서야. 의사결정에 필요한 인사이트를 제공하지.

일일 리포트:
• 전일 총 사용량 및 비용
• 전일 대비 증감률
• 피크 시간대 및 최대 수요 전력
• 이상 패턴 감지 사항

월간 리포트:
• 월간 총 사용량 및 비용
• 전월/전년 동월 대비 비교
• 테넌트별 사용량 순위
• 에너지 효율 개선 제안
• 설비 가동률 분석

연간 리포트:
• 연간 에너지 소비 트렌드
• 계절별 패턴 분석
• 에너지 효율 등급 평가
• 탄소 배출량 계산
• 장기 투자 계획 제안

🔍 예측 분석

과거 데이터를 기반으로 미래를 예측하는 고급 기능이야. 머신러닝 알고리즘을 활용하지! 🤖

수요 예측:
내일, 다음 주, 다음 달의 에너지 수요를 예측해. 날씨, 요일, 계절, 과거 패턴 등을 고려해서 말이야. 이걸 알면 에너지 구매 계획을 최적화할 수 있어.

이상 감지:
정상 패턴에서 벗어난 이상 징후를 자동으로 감지해. 설비 고장 전조 증상을 미리 잡아낼 수 있지.

최적화 제안:
"3층 동측 구역의 냉방 설정 온도를 1도 올리면 월 50만원 절감 가능합니다" 같은 구체적인 제안을 해줘.

💳 자동 요금 청구

테넌트별 에너지 사용량을 자동으로 계산해서 청구서를 생성하는 기능이야.

청구 프로세스:

① 사용량 집계
각 테넌트에 할당된 미터의 월간 사용량을 집계해.

② 요금 계산
계약된 요금제(기본요금, 시간대별 요금, 수요 요금 등)를 적용해서 금액을 계산해.

③ 청구서 생성
PDF 형식의 상세 청구서를 자동 생성해. 일별 사용량 그래프, 전월 비교 등도 포함돼.

④ 자동 발송
이메일이나 빌딩 관리 시스템을 통해 자동으로 발송해.

이게 있으면 관리 인력이 엄청 절약돼! 예전에는 수십 개 테넌트 청구서 만드느라 며칠 걸렸는데, 이제는 버튼 하나로 끝이야. 😎

🔒 데이터 암호화

전송 중 암호화 (Encryption in Transit):
미터에서 서버로 데이터가 전송될 때 TLS/SSL 암호화를 사용해. 중간에 누가 가로채도 못 읽게 하는 거야.

저장 시 암호화 (Encryption at Rest):
데이터베이스에 저장될 때도 암호화해. 특히 개인정보(테넌트 연락처 등)는 AES-256 같은 강력한 암호화를 적용해.

키 관리:
암호화 키는 별도의 키 관리 시스템(KMS)에서 안전하게 보관해. 데이터와 키를 같은 곳에 두면 의미 없잖아?

👤 접근 제어

누가 어떤 데이터를 볼 수 있는지 엄격하게 관리해야 해.

역할 기반 접근 제어 (RBAC):

데이터 마스킹:
테넌트 이름이나 연락처 같은 민감 정보는 권한 없는 사용자에게는 마스킹해서 보여줘. "ABC 주식회사" → "A** 주식회사" 이런 식으로.

📝 감사 로그

누가 언제 어떤 데이터에 접근했는지 모두 기록해야 해. 나중에 문제 생기면 추적할 수 있게!

로그 항목:
• 사용자 ID
• 접근 시간
• 접근한 데이터 (테이블, 레코드 ID)
• 수행한 작업 (읽기, 쓰기, 삭제)
• IP 주소
• 결과 (성공/실패)

이 로그는 최소 3년 이상 보관해야 해. 규제 요구사항이기도 하고!

🌍 개인정보 보호 규정 준수

GDPR(유럽), CCPA(캘리포니아), 개인정보보호법(한국) 같은 규정을 준수해야 해.

주요 요구사항:

• 동의 획득: 개인정보 수집 전에 명시적 동의를 받아야 해.
• 목적 제한: 수집한 목적 외에는 사용하면 안 돼.
• 열람 권리: 본인 정보를 언제든 열람할 수 있어야 해.
• 삭제 권리: 요청하면 개인정보를 삭제해줘야 해.
• 이동 권리: 데이터를 다른 서비스로 옮길 수 있게 해줘야 해.

🏗️ 전형적인 기술 스택

데이터 수집 계층:
• 프로토콜: Modbus TCP/RTU, BACnet, DLMS/COSEM
• 게이트웨이: Raspberry Pi, Industrial PC, IoT Gateway
• 통신: MQTT, HTTP REST API, WebSocket

데이터 저장 계층:
• 시계열 DB: InfluxDB, TimescaleDB, Prometheus
• 관계형 DB: PostgreSQL, MySQL, MariaDB
• 캐시: Redis, Memcached
• 메시지 큐: RabbitMQ, Apache Kafka

데이터 처리 계층:
• 스트림 처리: Apache Kafka Streams, Apache Flink
• 배치 처리: Apache Spark, Python Pandas
• ETL 도구: Apache NiFi, Airflow

응용 계층:
• 백엔드: Node.js, Python (Django/Flask), Java (Spring Boot)
• 프론트엔드: React, Vue.js, Angular
• 시각화: Grafana, Kibana, D3.js, Chart.js
• 머신러닝: TensorFlow, PyTorch, Scikit-learn

🏢 실제 구현 예시: 중형 오피스 빌딩

20층 규모, 50개 테넌트가 입주한 오피스 빌딩의 스마트 미터링 시스템을 구축한다고 가정해보자.

하드웨어 구성:
• 전력 미터: 층별 1개 + 테넌트별 1개 = 총 70개
• 수도 미터: 층별 1개 = 총 20개
• 가스 미터: 층별 1개 = 총 20개
• 환경 센서: 층별 4개 = 총 80개
• 데이터 수집 게이트웨이: 층별 1개 = 총 20개

데이터 규모 추정:
• 미터당 데이터 크기: 약 500 bytes
• 수집 주기: 15분
• 일일 데이터 포인트: 110개 미터 × 96회 = 10,560개
• 일일 데이터 크기: 10,560 × 500 bytes ≈ 5 MB
• 연간 데이터 크기: 5 MB × 365 ≈ 1.8 GB (원시 데이터)
• 집계 데이터 포함 시: 약 3~5 GB

생각보다 크지 않지? 그래서 중소형 건물은 클라우드 서비스 없이도 온프레미스로 충분히 운영 가능해! ☁️

💡 성능 최적화 팁

1. 인덱싱 전략
시계열 데이터는 timestamp + meter_id 조합으로 복합 인덱스를 만들어. 조회 속도가 10배 이상 빨라져!

2. 파티셔닝
데이터를 월별로 파티션을 나눠. 오래된 파티션은 압축하거나 아카이브로 옮기면 관리가 쉬워져.

3. 캐싱 전략
자주 조회되는 데이터(최근 1시간, 오늘 누적 등)는 Redis에 캐싱해. DB 부하를 90% 이상 줄일 수 있어!

4. 비동기 처리
무거운 집계 작업이나 리포트 생성은 백그라운드 작업으로 처리해. 사용자는 기다릴 필요 없이 바로 다른 일을 할 수 있지.

5. 데이터 압축
시계열 데이터는 델타 인코딩이나 Gorilla 압축 알고리즘을 쓰면 10:1 이상 압축률을 얻을 수 있어!

🤖 AI/ML 통합

인공지능과 머신러닝이 더 깊이 통합될 거야.

• 자동 이상 감지: 사람이 설정한 임계값이 아니라, AI가 스스로 정상 패턴을 학습하고 이상을 감지해.
• 예측 유지보수: 설비 고장을 몇 주 전에 미리 예측해서 계획적으로 수리할 수 있어.
• 자동 최적화: 에너지 사용 패턴을 학습해서 자동으로 설비 운전을 최적화해.
• 자연어 인터페이스: "지난달 3층 전기 사용량 보여줘" 같은 자연어 질의가 가능해질 거야.

🌐 IoT와 엣지 컴퓨팅

더 많은 센서가 연결되고, 데이터 처리가 엣지(현장)에서 이루어질 거야.

• 엣지 AI: 게이트웨이 자체에서 AI 추론을 수행해서 실시간 의사결정이 가능해져.
• 5G 연결: 초저지연 통신으로 진짜 실시간 제어가 가능해질 거야.
• 디지털 트윈: 건물 전체를 가상으로 복제해서 시뮬레이션하고 최적화할 수 있어.

♻️ 탄소 중립과 ESG

환경 규제가 강화되면서 탄소 배출 추적이 필수가 될 거야.

• 실시간 탄소 발자국: 에너지 사용량을 실시간으로 탄소 배출량으로 환산해서 보여줘.
• 재생에너지 통합: 태양광, 풍력 같은 재생에너지 발전량과 소비량을 통합 관리해.
• ESG 리포팅: 환경·사회·지배구조 관련 데이터를 자동으로 수집하고 리포트를 생성해.

🔗 블록체인 통합

에너지 거래와 데이터 무결성 보장에 블록체인이 활용될 거야.

• P2P 에너지 거래: 건물 간 직접 에너지를 사고팔 수 있어.
• 데이터 무결성: 미터 데이터를 블록체인에 기록해서 위변조를 방지해.
• 스마트 계약: 에너지 사용량에 따라 자동으로 요금이 정산되는 스마트 계약이 가능해져.