본문 바로가기
프로젝트/태양광발전소 이상감지

태양광 발전소 이상감지 알고리즘 프로젝트 - (2/2편)

by Jam 2026. 4. 22.

"태양광 발전소 이상감지 알고리즘"이라는 주제의 교내 프로젝트를 진행했다.


https://khgerr8909.tistory.com/entry/%ED%83%9C%EC%96%91%EA%B4%91-%EB%B0%9C%EC%A0%84%EC%86%8C-%EC%9D%B4%EC%83%81%EA%B0%90%EC%A7%80-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-12%ED%8E%B8

 

태양광 발전소 이상감지 알고리즘 프로젝트 - (1/2)

"태양광 발전소 이상감지 알고리즘"이라는 주제의 교내 프로젝트를 진행했다.0. 목차1. 프로젝트 배경2. 초기 진행 방향3. 문제 정의4. 고장 라벨링을 위한 모델5. 데이터 전처리6. Simple Regression Mode

khgerr8909.tistory.com

 

해당 글은 2편을 작성한 것이고 1편에 관한 내용은 위 게시글을 참고하면 된다.


0. 목차

[1편]
1. 프로젝트 배경
2. 초기 진행 방향
3. 문제 정의
4. 고장 라벨링을 위한 모델
5. 데이터 전처리
6. Simple Regression Model 설계
7. PR(Performance Ratio) 값 구하기
8. Simple Regression Model Parameters 구하기

[2편]
9. Margin 설정
10. 이상 감지 데이터들을 통한 insight 도출
11. 해당 알고리즘의 장점
12. 추가적으로 고려하고 싶었던 것들
13. 발표 끝나고 아쉬운 점, 피드백, 의문 사항

9. Margin 설정

앞에서 잔차가 대략적으로 정규분포를 띔을 확인했다. Margin은 정규분포를 띈다는 가정하에, 표준 편차의 K배로 설정을 한다.

주로 표준편차의 2배나 3배를 주로 이용하는데 3배를 사용했다.

 

1편에서 언급했듯이 고장을 조금 놓치더라도 확실하게 고장인 것만 판별하여 FP를 줄이고자 하는 것이 목적이었기 때문이다.

 

시각화한 결과는 그림과 같고 초록색 선으로 표시된 것들이 Margin 경계이다.

 

 

Margin 밖의 데이터들을 대상으로 PR 값을 오름차순 하여 확인한 결과 PR 값의 정상 범위인 0.8 ~ 1.0의 값은 단 하나도 존재하지 않는 것을 확인했다. 이를 통해 확실하게 정상인 것들은 정상으로 판단하며 고장이 의심되는 데이터들에 대해서만 필터링을 한 것으로 확인할 수 있었다.

 

 

 

총 데이터 중 이상감지 된 것들의 데이터는 3586개임(약 2%)을 확인할 수 있었다. 

해당 2%의 데이터들을 추가 분석하여 인사이트를 도출하고자 하였다.


10. 이상 감지 데이터들을 통한 insight 도출

사실상 가장 어려운 부분이었다. 사실 결론적으로 도출한 insight는 없는 것 같다는 생각도 든다.

 

그래도 나름의.. 도출된 결과를 정리했다.

 

일사량이 많은 여름보다 오히려 3,4,12월에 더 많이 몰려 있던 점을 확인할 수 있었다.

이 사실과 더불어 출력제한도 여름보다 오히려 3,4월에 더 많이 진행했던 것과 비슷하지 않은가 싶다.

 

대부분 발전소의 경우에는 일차함수 선에서 아래 부분에 점이 위치되어 있는데, 발전소 D와 I의 경우에만 과도하게 PR 값들이 몰려 있음을 확인할 수 있었다.

 

두 데이터들의 공통점을 확인한 결과 24년 4월로 확인되었다. 한수원 담당자님께서는 어떤 일이 있었는지 확인할 방법이 없다고 하셨지만 24년 4월에 어떠한 일이 있었는지 확인이 가능하다면 추가적인 자료로 활용할 수 있었을 것이다.

 

마지막으로 발전소 B의 비효율적인 발전량이다. 총 18개의 발전소가 제주도에 있지만 조금씩 위치가 다르다. 하지만, 발전소 B와 D의 경우에는 위치가 동일하고 모듈 및 인버터 정보가 동일했다. 그럼에도 불구하고 발전소 B가 발전소 D에 비해 발전량이 현격히 낮게 나옴을 확인할 수 있었다. 

따라서 발전소 B는 현재 효율이 떨어지는 상태라고 확인된다.


11. 해당 알고리즘의 장점

Ground Truth가 없는 상황에서 경사면 일사량의 값이 증가하면 발전량이 증가한다는 직관적인 해석을 통해 쉽게 해석할 수 있다는 장점이 있다. 또한, 최종 의사결정을 데이터 분석에만 의존하는 것이 아니라 현장 담당자의 상황 판단과 같이 고려하여 판단할 수 있다.

 

그리고 같은 주제에 대해 발표했던 다른 팀과 비교하면 현장 상황을 가장 많이 고려했다고 생각함. 

- 세부적인 고장을 잡는 것보다 확실히 고장인 것 잡기 + 어느 정도 고장을 데이터로 판단
(한수원은 데이터를 사용을 전혀 하고 있지 않았기에 복잡한 모델이 필요한 것이 아님)

- 우리 팀 멋대로 고장을 라벨링 하지 않음 (다른 팀은 멋대로 고장을 정의하고 지도학습을 진행함)

 

처음에는 나도 무작정 복잡하고 간지 있어 보이는 모델을 사용해야 한다고 생각을 했었는데, 실제로 한수원과 연계해서 해보니까 "사용자 요구사항 및 상황 고려"가 중요한 것을 여러 차례 깨닫게 되었음.

 

우리가 제작한 모델의 성능에서는 아쉬운 점이 많지만 위 사항을 가장 잘 고려한 모델이라고 생각함.


12. 추가적으로 고려하고 싶었던 것들

[처음 구상 계획]

- 웹 사이트 제작

- 실시간 스트리밍 vs 하루에 누적해서 확인

- LLM 탑재하기

- 비전공자도 쉽게 몇 번의 클릭으로 시각화할 수 있는 기능 구현

 

처음 계획은 하나의 웹 사이트를 만드는 것이었다. 웹 사이트를 제작해서 한수원 로컬에서만 실행 가능하도록 설계하고 싶었고, 데이터를 실시간으로 스트리밍 해서 경고 알림을 띄울지 아니면 하루치를 누적하고 일사량이 없는 시간대에 분석이 되도록 자동화할지 등의 방법을 고민했었다. (해당 방법에 대해서는 실시간보다 누적이 나은 것 같음. 한수원 담당자들은 뭔가 귀찮아하는 경향이 느껴짐.)

추가적으로 AI를 탑재해서 결과를 직접 해석하는 것보다 의심되는 발전소가 있다는 방향을 알 수 있게끔 하고 싶었다.

그리고 일차함수 형태라도 비전공자나 문과 직무인 분들도 직접 코딩을 통해 하는 것이 아니라 몇 번의 클릭을 통해 결과를 보여줄 수 있는 UI를 제공하고 싶었음.


13. 발표 끝나고 아쉬운 점, 피드백, 의문 사항

대회 결과는 완전 꽝이었고, 엄청난 욕만 먹은 것 같다.

(그리고 마음대로 Ground Truth를 설정한 다른 팀들에게 질문 공세를 쏟아 넣고 싶었다..)

 

직접 발표를 진행했었는데, 공격적인 질문에 대해서 매우 당황해서 어버버 했던 기억이 있음. (지금 생각해 보면 일부로 공격적으로 한 거 같기도 한데, 거기서 내가 쫄아버리는 순간 졌던 것 같음.)

평가 중에 "저 정도면 정규 분포를 띄는 경향이 아니라 그냥 띈다고 하면 되는 거 아니에요? 현실 세계에서 얼마나 정규성을 띈다고 ㅋㅋ" 식으로 말하셨는데, 진짜 어쩌라는 말인 거지?? 하면서 많이 당황..했다.. 이런 상황에 더 익숙하고 뻔뻔하게 나갈 필요가 있어 보인다..

 

그리고 다른 팀은 Ground Truth 없는데 마음대로 설정해서 지도 학습하고 LLM 탑재까지 하고...(근데 또 그 팀이 2등상 받고)

솔직히 억울했음. 아무리 이것저것 다해도 "고장"에 대한 라벨링이 틀리면 완전 엉터리 모델 아닐까...

 

이것과 별개로 데이터 분석 공모전이 처음이라 어떻게 역할 분담을 하고 진행해야 할지 조금 의문이 들었던 것 같음. 학생회에서 했던 일과는 결이 너무 달라서 역할 분담이 너무 어려웠던 것 같음. 또 혼자서 어느 정도 다 해야 한다는 강박이 있어서 그런지 더더욱 그랬던 부분도 있음.

 

추가적으로 우리에게 엄청난 비난(?)을 쏟은 교수님께 찾아가서 피드백도 요청함.

ㅎㅎㅎㅎ

교수님께 "Ground Truth"가 없는 상황에서 어떻게 할 수 있는지 여쭤봄. 한수원에서도 알아서 정해달라고 나 몰라라 하는데 달리 방법이 있냐?는 식으로 여쭤봤는데,

교수님께서는 꼭 태양광 데이터가 아니더라도 이런 이상감지와 관련된 데이터는 캐글에 엄청 많다고 하심.

그래서 비슷한 도메인의 주제를 다룬 캐글 대회를 찾아서 모델을 만들고 여러 데이터로 테스트해 보면서 성능을 평균 내는 방법이 있다고 하셨다. (우리 지도 교수님도 이런 피드백을 해줬더라면....)

 

이 얘기를 들으니까 납득이 되었다. 

 

[후기]

그것과 별개로 "데이터 분석"은 내가 원하는 방향이 아니라는 생각이 들었다.

당연히 데이터를 다루고 인사이트 도출을 통한 예측을 좋아할 것이라고 생각했는데, 분석하는 방법 및 과정보다 "어떤 도메인을 다루는지"가 더  중요한 것을 깨달았다. (태양광 에너지는 1도 관심 없어서 준비하는 과정이 귀찮았음.)

 

그래서 데이터 쪽으로 분야를 쭉 파는 일은 없을 것 같다. 내가 원하는 도메인과 관련된 지식이 있으면서 데이터 분석은 부가적으로 다룰 수 있는 역량을 가진 사람이어야지, 관심도 가지 않는 도메인의 데이터를 전문적으로 다루는 사람이 되고 싶지는 않다.

 

아무튼 이론 공부만 하는 것보다 이렇게 직접 대회를 해보면서 얻는 것이 확실히 얻는 게 많은 것 같다. 이제 개발 쪽 위주로 공부를 하겠지만 어느 정도 기회만 된다면 냅다 부딪히면서 공부를 해볼 생각이다.