# 태양광 발전소 통합 모니터링 플랫폼 — 종합 분석 보고서

> 작성일: 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. 제안 아키텍처 개요

```mermaid
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. 종합 평가

### ✅ 현재 프로젝트의 강점 (재활용 가능 자산)

1. **검증된 크롤러 코드**: NREMS, KREMC, Sun-WMS, Hyundai, CMSolar 등 핵심 제조사 크롤러가 이미 운영 검증됨. 플랫폼 전환 시 가장 큰 기술적 자산.
2. **스마트 스케줄러(crawler_manager)**: LEARNING/OPTIMIZED 모드 스케줄링 로직은 멀티테넌트 환경에서도 그대로 활용 가능.
3. **FastAPI + Supabase 백엔드**: 확장성 있는 구조로 재설계 부담 최소화.

### ⚠️ 핵심 해결 과제 (우선순위 순)

| 우선순위 | 과제 | 난이도 |
|---------|------|--------|
| 1 | 사용자 계정(ID/PW) 암호화 보관 체계 | ⭐⭐⭐ |
| 2 | IP 차단 우회 인프라 (Residential Proxy) | ⭐⭐⭐⭐ |
| 3 | 멀티테넌트 DB 설계 및 RLS 적용 | ⭐⭐⭐ |
| 4 | 프론트엔드 Next.js 전환 | ⭐⭐ |
| 5 | 법적 리스크 검토 (약관 위반) | ⭐⭐⭐ |

### 💡 최종 제언

> 현재 SolarPower 프로젝트는 이 플랫폼을 구축하기 위한 **훌륭한 기술적 원형(Prototype)**입니다. 그러나 단순히 "기능 추가"가 아니라 **보안, 멀티테넌시, 인프라** 세 축에서 구조적인 재설계가 필요합니다.
>
> 특히 **계정 정보 보안**과 **IP 차단 우회**는 서비스 신뢰도의 기반이므로, 개발 착수 전 이 두 가지 아키텍처를 먼저 확정한 후 나머지 기능을 쌓는 순서로 진행하기를 강력히 권장합니다.