12 KiB
12 KiB
태양광 발전소 통합 모니터링 플랫폼 — 종합 분석 보고서
작성일: 2026-04-22 참조 문서:
docs/check.md(과업 요구사항),README.md(현 시스템 현황)
1. 프로젝트 전체상 (Vision)
1-1. 현재 시스템 vs. 목표 시스템
| 구분 | 현재 SolarPower | 목표 플랫폼 (check.md) |
|---|---|---|
| 사용 주체 | 내부 관리자 1인 | 다수의 외부 고객사 (B2B) |
| 발전소 수 | 약 9개 (고정) | 무제한 (사용자가 직접 등록) |
| 크롤러 관리 | 개발자가 직접 코딩 | 사용자 계정 기반 자동 생성 |
| UI | React Native App (모바일 중심) | PC Web 반응형 (발전왕 수준) |
| 인프라 격리 | 단일 테넌트 | 멀티 테넌트 (고객사 간 데이터 완전 격리) |
| 확장 목표 | 현행 모니터링 유지 | EMS, VPP까지 단계적 확장 |
1-2. 제안 아키텍처 개요
flowchart TD
subgraph CLIENT["클라이언트 (PC Web)"]
USER["일반 사용자\n(발전소 등록/모니터링)"]
ADMIN["관리자\n(계정/시스템 관리)"]
end
subgraph PLATFORM["플랫폼 코어 (Oracle Cloud)"]
NEXTJS["Next.js\nFrontend (SSR)"]
FASTAPI["FastAPI\nBackend (REST API)"]
SCHEDULER["Crawler Scheduler\n(사용자별 독립 스케줄)"]
SECRET_MGR["Secret Manager\n(AES-256 암호화)"]
QUEUE["Task Queue\n(Redis/Celery)"]
end
subgraph CRAWLERS["수집 레이어"]
PROXY["Residential Proxy Pool\n(IP 차단 우회)"]
HEADLESS["Headless Browser\nCluster (Playwright)"]
end
subgraph EXTERNAL["외부 제조사 시스템"]
NREMS["NREMS"]
KREMC["KREMC"]
SUNWMS["Sun-WMS"]
ETC["기타 제조사..."]
end
subgraph DATA["데이터 레이어"]
SUPABASE["Supabase\n(PostgreSQL + RLS)"]
TIMESERIES["시계열 DB\n(향후 EMS/VPP용)"]
end
USER --> NEXTJS
ADMIN --> NEXTJS
NEXTJS --> FASTAPI
FASTAPI --> SECRET_MGR
FASTAPI --> SCHEDULER
SCHEDULER --> QUEUE
QUEUE --> HEADLESS
HEADLESS --> PROXY
PROXY --> NREMS & KREMC & SUNWMS & ETC
FASTAPI --> SUPABASE
HEADLESS --> SUPABASE
2. 기능별 위험 요소 및 해결 방안
2-1. 핵심 기능: 발전소 등록 및 자동 데이터 연동
이 기능은 전체 프로젝트에서 기술적 난이도와 리스크가 가장 높은 부분입니다.
🔴 위험 1: 사용자 계정 정보(ID/PW) 보안
문제:
- 타사 서비스의 평문 비밀번호를 DB에 저장하는 것은 법적·윤리적 리스크를 내포합니다.
- 서버 침해 시 사용자 계정 유출로 인한 2차 피해 및 배상 책임이 발생합니다.
- 개인정보보호법 및 정보통신망법 위반 소지가 있습니다.
해결 방안:
1. 양방향 암호화 필수 적용
- 저장: AES-256-GCM 암호화 후 DB 저장
- 복호화 키: 애플리케이션 서버 환경변수 또는 전용 KMS(Key Management Service)에 분리 보관
- DB 유출 시에도 암호화 키 없이는 복호화 불가
2. 저장 범위 최소화
- 최초 로그인 성공 후 세션 쿠키/토큰만 저장하고 원본 PW는 메모리에서 즉시 파기
- 토큰 갱신 주기에만 PW 재사용 (접근 빈도 최소화)
3. 사용자 동의 및 약관
- 계정 정보 위탁 보관에 대한 명시적 동의 받기
- 개인정보 처리 방침에 해당 내용 명기
🔴 위험 2: 제조사 사이트의 자동화 탐지 및 차단
문제:
- 다수의 계정이 동일 IP에서 짧은 시간 내 로그인 → 보안 시스템에 의해 IP 차단
- 사용자 계정이 자동 잠금(Lock) 처리되는 최악의 UX 발생
- 2단계 인증(MFA), 캡차(CAPTCHA) 등의 방어 기제
해결 방안:
1. 분산 프록시 전략
- Residential Proxy Pool 사용 (실제 가정용 IP 활용)
- 사용자별 고정 프록시 IP 할당 (한 IP = 한 계정 원칙)
- 예시 서비스: Bright Data, Oxylabs, IPRoyal
2. 인간 행동 시뮬레이션
- requests 방식 → Playwright/Puppeteer 헤드리스 브라우저로 전환
- 로그인 간격을 랜덤하게 설정 (1~5분 지연)
- User-Agent, 쿠키, 세션 헤더 완전 복제
3. 세션 캐싱 전략
- 로그인 성공 후 세션 쿠키를 Redis에 캐싱하여 재활용
- 세션 만료 직전에만 재로그인 수행 (로그인 빈도 최소화)
4. 실패 대응 UX
- 수집 실패 감지 즉시 → 사용자에게 이메일/앱 알림
- "계정 정보를 다시 확인해 주세요" UI 안내 흐름
🟡 위험 3: 제조사별 크롤러 유지보수 부담
문제:
- 제조사 사이트 UI 변경 시 크롤러 즉시 중단
- 지원 제조사 수 증가에 따라 유지보수 공수가 선형 증가
해결 방안:
1. 크롤러 플러그인 아키텍처 도입
- 제조사별 크롤러를 독립 모듈(어댑터 패턴)로 분리
- 공통 인터페이스(BaseCrawler) 상속으로 신규 제조사 추가 용이
2. 자동 헬스체크 시스템
- 매 수집 후 데이터 유효성(날짜, 수치 범위) 자동 검증
- 연속 3회 실패 시 관리자에게 자동 알람 발송
3. 현행 SolarPower 크롤러 재활용
- NREMS, KREMC, Sun-WMS, Hyundai, CMSolar 크롤러는 이미 검증됨
- 기존 코드를 멀티테넌트 구조로 래핑하는 방식으로 빠르게 확장 가능
2-2. 멀티테넌시 및 데이터 격리
🔴 위험: 고객사 간 데이터 혼재
문제:
- 현재 구조는 단일 사용자 가정 하에 설계됨
- 다수 고객사가 사용할 경우 데이터가 섞일 위험
해결 방안:
1. Supabase Row Level Security (RLS) 적용
- 모든 테이블에 tenant_id 컬럼 추가
- RLS 정책: "자신의 tenant_id에 해당하는 행만 SELECT/INSERT/UPDATE 가능"
- DB 레벨에서 격리 보장 → 애플리케이션 버그로도 타 사용자 데이터 접근 불가
2. 데이터 모델 재설계 필요
현재: plants (plant_id, name, ...)
변경: plants (plant_id, tenant_id, name, ...) ← tenant_id FK 추가
credentials (id, tenant_id, plant_id,
encrypted_id, encrypted_pw, ...) ← 신규 테이블 (암호화 계정 저장)
2-3. 프론트엔드 아키텍처 (PC Web)
🟡 위험: Expo Web의 B2B 대시보드 한계
문제:
- 현재 React Native(Expo) 기반은 모바일 UX 중심
- '발전왕' 수준의 복잡한 PC 데이터 대시보드 구현에 Expo는 적합하지 않음
- 복잡한 그리드, 데이터 테이블, 인터랙티브 차트를 구현하기 어려움
해결 방안:
권장 프론트엔드 스택:
- Framework: Next.js 14 (App Router, SSR/ISR 지원)
- Styling: TailwindCSS + shadcn/ui (B2B 대시보드 컴포넌트)
- Charts: Recharts 또는 Apache ECharts (고성능 시계열 차트)
- State: Zustand + React Query (서버 상태 캐싱)
기존 Expo 앱은 모바일 알림 수신용으로 유지하고,
PC Web은 Next.js로 별도 구축하는 이원화 전략 추천
2-4. 인프라 확장성 (크롤링 서버)
🟡 위험: 단일 Oracle Cloud 인스턴스의 한계
문제:
- 고객사 수 증가 → 동시 크롤링 작업 급증
- 나스의 단일 IP를 Exit Node로 사용 → IP 차단 시 전체 서비스 중단
해결 방안:
단계별 인프라 전략:
[1단계 - 소규모, ~50개 발전소]
현행 Oracle Cloud + Tailscale(나스) 구조 유지
Celery + Redis로 크롤링 태스크 큐 관리
[2단계 - 중규모, ~300개 발전소]
Residential Proxy Pool 도입 (IP 차단 우회)
크롤링 서버 인스턴스 수평 확장 (2~3대)
[3단계 - 대규모, 300개 이상]
Kubernetes 기반 크롤러 파드 자동 스케일링
제조사별 전용 크롤러 워커 분리
3. 법적·사업적 리스크
3-1. 제조사 서비스 약관 위반
| 위험 수준 | 내용 | 대응 |
|---|---|---|
| 🔴 높음 | 제조사 ToS의 자동화 접근 금지 조항 위반 | 서비스 초기에 제조사에 협력 제안 검토 |
| 🟡 중간 | 스크래핑 행위 자체의 법적 회색 지대 | 법무 검토 후 이용약관에 면책 조항 추가 |
| 🟢 낮음 | 수집 데이터 저작권 분쟁 | 가공된 통계 데이터만 노출, 원문 미재현 |
3-2. 개인정보 처리
필수 조치:
- 개인정보 처리 방침 수립 (개인정보보호법 준수)
- 타사 계정 정보 위탁 처리에 대한 별도 동의 절차
- 개인정보 보호책임자(CPO) 지정
- 연 1회 이상 보안 취약점 점검
4. 권장 기술 스택
| 영역 | 현재 | 권장 (플랫폼) | 이유 |
|---|---|---|---|
| Frontend | React Native (Expo) | Next.js 14 | SSR, B2B 대시보드 최적화 |
| Backend | FastAPI | FastAPI 유지 | 검증된 구조 재활용 가능 |
| Database | Supabase (PostgreSQL) | Supabase 유지 + RLS 강화 | 멀티테넌트 RLS 기능 내장 |
| 크롤러 | Python requests | Playwright (헤드리스) | 자동화 탐지 우회 |
| 비동기 큐 | 없음 (Cron) | Celery + Redis | 다수 계정 동시 수집 관리 |
| 암호화 | 없음 | AES-256-GCM + KMS | 계정 정보 안전 보관 |
| 프록시 | Tailscale (나스) | Residential Proxy Pool | IP 차단 근본 해결 |
| 인프라 | Oracle Cloud 단일 | Oracle Cloud + 수평 확장 | 트래픽 증가 대응 |
5. 단계별 개발 로드맵
Phase 1 — MVP (2~3개월)
목표: 소수 고객사를 대상으로 핵심 기능 검증
- 멀티테넌트 DB 스키마 설계 (RLS 포함)
- 사용자 회원가입/로그인 (Supabase Auth 활용)
- 발전소 등록 UI (제조사 선택 → ID/PW 입력)
- 기존 크롤러를 멀티테넌트 구조로 래핑
- 기본 모니터링 대시보드 (일/월별 발전량 차트)
- 수집 실패 알림 시스템
Phase 2 — 안정화 (2~3개월)
목표: 보안 강화 및 운영 안정성 확보
- AES-256 계정 암호화 체계 적용
- Playwright 헤드리스 브라우저 전환 (탐지 우회)
- Celery + Redis 비동기 크롤링 큐 도입
- 관리자 페이지 구축 (사용자/연동 상태 관리)
- 크롤러 헬스체크 및 자동 알람 시스템
Phase 3 — 확장 (3~4개월)
목표: 상용 서비스 품질 달성 및 EMS 기반 마련
- Residential Proxy Pool 연동 (IP 차단 근본 해결)
- 신규 제조사 크롤러 플러그인 추가 (수요 기반)
- 시계열 DB 도입 (EMS/VPP 대비)
- 화이트 라벨링 지원 (브랜드 커스터마이징)
- 정식 제조사 API 파트너십 추진
6. 종합 평가
✅ 현재 프로젝트의 강점 (재활용 가능 자산)
- 검증된 크롤러 코드: NREMS, KREMC, Sun-WMS, Hyundai, CMSolar 등 핵심 제조사 크롤러가 이미 운영 검증됨. 플랫폼 전환 시 가장 큰 기술적 자산.
- 스마트 스케줄러(crawler_manager): LEARNING/OPTIMIZED 모드 스케줄링 로직은 멀티테넌트 환경에서도 그대로 활용 가능.
- FastAPI + Supabase 백엔드: 확장성 있는 구조로 재설계 부담 최소화.
⚠️ 핵심 해결 과제 (우선순위 순)
| 우선순위 | 과제 | 난이도 |
|---|---|---|
| 1 | 사용자 계정(ID/PW) 암호화 보관 체계 | ⭐⭐⭐ |
| 2 | IP 차단 우회 인프라 (Residential Proxy) | ⭐⭐⭐⭐ |
| 3 | 멀티테넌트 DB 설계 및 RLS 적용 | ⭐⭐⭐ |
| 4 | 프론트엔드 Next.js 전환 | ⭐⭐ |
| 5 | 법적 리스크 검토 (약관 위반) | ⭐⭐⭐ |
💡 최종 제언
현재 SolarPower 프로젝트는 이 플랫폼을 구축하기 위한 **훌륭한 기술적 원형(Prototype)**입니다. 그러나 단순히 "기능 추가"가 아니라 보안, 멀티테넌시, 인프라 세 축에서 구조적인 재설계가 필요합니다.
특히 계정 정보 보안과 IP 차단 우회는 서비스 신뢰도의 기반이므로, 개발 착수 전 이 두 가지 아키텍처를 먼저 확정한 후 나머지 기능을 쌓는 순서로 진행하기를 강력히 권장합니다.