3년간 진행했던 데이터 분석 프로젝트 회고

2018년부터 2020년까지 진행했던 정부과제 데이터 분석 프로젝트에 대한 회고입니다. 분석 및 개발 업무 자체는 거의 혼자서 진행했기 때문에 이것저것 배운 게 많았습니다. 물론 보안 상 상당수는 말할 수는 없겠지만 대략 어떤 분석이 있었고, 다음에는 어떤 걸 하지 말아야지 하는 정도의 회고를 써볼까 합니다.

대략 어떤 프로젝트였는가 하면...

제가 진행했던 프로젝트는 제품을 생산하는 공장 데이터를 바탕으로 진행되었으며, 차수 별로 진행되었는데요. 제가 참여하는 전체 기간 중 분기 별로 아래 3가지 일을 진행하였습니다. 크게 EDA를 기반으로 모델링을 수행하는 절차라고 보면 될 듯 합니다.

 

A분기 → 데이터 특성 조사 및 필요 데이터 요약

B분기 → 제품 생산시간 예측 모델링

C분기 → 예측 모델 기반 생산 최적화 모델링 & 워킹 프로그램 제작

 

수행 과정 및 결과물에 대해...

사용 언어는 Python이었고, DB는 MS-SQL 기반이었습니다.

그리고 데이터의 형태는 크게 '생산 주문기록'-'생산 중간기록'-'생산 완료기록' 을 바탕으로 '생산 중간기록'과 '생산 완료기록'을 활용하여 제품 생산 시간을 예측하는 모델을 학습하여 '생산 주문기록'만 가지고도 '제품 생산시간'을 예측하고 이를 기반으로 생산 순서 최적화까지 할 수 있는 것을 최종 목표로 하였습니다.

 

수행 과정에서 사용한 대략적인 방법론, 라이브러리는 아래와 같습니다.

 

1. 탐색적 데이터 분석 시 시도한 방법
   • 상관관계 분석(Pearson Correlation Coefficient)
     • 기존 변수 기반 파생변수 생성 후 상관관계 분석
   • Target - Feature 간 시각화
   • 시계열 분석(ARIMA test)
   • 맨-켄달 검정법(Seasonal Mann-Kendall test)

2. 예측 모델을 위해 시도한 방법
   • 예측모델
     • 선형회귀(Linear Regression)
     • XGBoost
   • 정규화
     • StandardScaler
     • MinMaxScaler
     • QuantileTransformer

3. 최적화 모델을 위해 시도한 방법
   • 실제 테스트 진행된 방법
     • 완전탐색(BruteForce)
     • 유전 알고리즘(Genetic Algorithm)
     • 탐욕 알고리즘(Greedy Algorithm)
   • 시도되었으나 여타 사유로 인해 애매하게 끝난 방법
     • 강화학습(Reinforcement Learning)

4. 워킹 프로그램 사용 프레임워크
   • 기본 개발언어 : Python
   • 웹 프레임워크(개발 테스트 용) : Python Flask
     • JS 프레임워크 : Angular JS / Bootstrap
   • CPS 구현 : Unity
     • 단, 결과 호출 API만 제공, 타 직원분이 unity 기반 프로그램 작성

 

이런 과정을 거쳐서 아래의 기능 및 특성을 가지는 프로그램을 제작하였습니다.

• 과거 데이터를 기반으로 생산 데이터 예측 모델을 주기적으로 생성

• 생산예정 기록을 바탕으로 예측모델 기반 생산시간 예측 스케줄 작성
  • 실시간 예측 : x분(min) 단위로 생산예정 기록을 조회하여 생산시간 예측 스케줄 작성
  • 히스토리 최적화 : 24시간 단위로 생산완료 기록을 조회하여 생산최적화 스케줄 작성

• 위 2가지를 DB에 기록하여 공장 사용자가 참고할 수 있도록 CPS 화면을 제공 (웹 화면은 CPS 연동 이전 내부 테스트를 위한 목적으로 구현)

 

그래서 최종 보고서 및 프로그램이 산출물로 제출되었습니다.

(아래 이미지는 개발 테스트용 웹 화면입니다. 보안 및 산출목표와 무관...)

아쉽다고 느꼈던 것...

시간이 지나고 나서 아쉽다고 느꼈던 몇몇 사항들에 대해 정리해보겠습니다.

1. 딥러닝(강화학습) 적용 문제
   1. 사실 최적화 문제는 딥러닝으로 시도해볼만한 가치가 충분하였으나 시간에 쫓기고, 확실한 output에 대한 부담감 때문에 애매하게 찔러보다가 최종적으로는 완전탐색(brute force) 알고리즘으로 선회하였는데 조금만 시간이 더 있었더라면 모델을 만들고 테스트 해볼 수 있지 않았을까 하는 아쉬움
   2. → 사용할 법한 방법론에 대해 로드맵에 정리하고, 일정 확보하기

2. SQL 쿼리 문제
   1. 최초 기획을 할 때는 필요한 쿼리가 많지 않을거라 예상되어, 그냥 Full String으로 작성하였으나, 이후 기획이 계속 변경되면서 SQL 쿼리량이 굉장히 많아져서 관리가 곤란했던 사항
   2. → 쿼리를 필수 부분과 변동 가능 부분으로 쪼개서 결합하는 방식 채택 필요

3. 데이터 전처리 에러 예외 처리
   1. 나름의 fault-tolerance를 유지하기 위해 예상 가능한 상황에 대해 예외처리를 하였으나 계절적으로, 상황적으로 기존엔 예상하지 못했던 예외들이 계속 튀어나와서 곤란했던 사항
   2. → 모듈 단계에서의 예외처리 뿐만 아니라 제품 전체 working 과정에서의 예외 처리 필요

4. 시간이 부족하여, 개발 = 제품이 동시에 이뤄지던 상황
   1. 사실상 단독 개발이였기 때문에 개발-QA-커밋을 모두 혼자 수행했어야 하는데 프로젝트 후반부에 접어들어서 시간이 촉박하게 되어서 QA가 제대로 하지 못하고, 그대로 제품(물론 테스트긴 하지만 Live로 동작하는)으로 직행하여서 이슈가 계속 발생하던 상황
   2. → 어쩔 수 없었긴 하지만 최대한 지킬 건 지켜야...

5. 인지하지 못한 중요 데이터에 대해서 후반에 알게 되었을 때
   1. 프로젝트 도중에 합류하였기 때문에 추가 데이터를 요구할 수 있는 지점이 지나버려서 feature engineering에 도움되겠다 하는 추가 변수를 받는데 시간이 소요되는 경우가 많았습니다. 바꿔말하면 모델을 새로 학습시켜야 하는데 데이터 받는데도 시간이 오래걸렸고, 그 탓에 모델 학습 시키는 데도 지연되는 문제가 발생
   2. → 초반에 도메인에 대해 많이 연구하고, 공부하고 요구할 수 있는 데이터는 최소 존재 유무라도 파악을 해야...

6. 개발할 때 추상화를 많이 하지 못한 것
   1. 이건 개발 쪽 이슈이긴 한데 초반에 이런 모델, I/O 정도면 앞으로 바뀔 일은 없을거야 했다가 후반에 고친다고 고생했던 경험
   2. → 모든 요소에 대한 추상화에 대해 반드시 생각하기, 디자인 패턴에 대해서도 초반에 고려하기...

마무리하며...

어쨌든 프로젝트는 종료되었고, 현재 최종 심사가 진행중으로 알고 있습니다(어쨌든 우리 손을 떠났단 얘기). 어떻게 보면 데이터 분석에서 프로덕션 과정까지 같이 진행된 케이스였는데 많은 걸 배우기도 했고, 앞서 서두에 말한 것처럼 다음에는 하지 말아야지 하는 경험들을 얻을 수 있었습니다. 현재 개발 일을 하고 있다 보니 아쉬운 점도 개발 관점에서 쓰인 얘기들이 많은 데 분석 쪽에서도 통계 기법 내지 인사이트 파악에 대해서 좀 더 배워야 할 점이 많았습니다. 이런 회고를 통해 다음에는 덜 삽질하면서 업무를 진행할 수 있었으면 합니다.