R을 사랑한 느림보 데이터 분석가
프로젝트 회고: 2023년 복지 관련 공공 프로젝트 본문
프로젝트가 끝나고 난 후에 따로 회고를 작성해 본 적은 없지만, 그나마 기억에 남아있을 때 사소한 것 하나라도 기록해보려고 한다.
더군다나 보안이 필요한 프로젝트라 외부로 공유하는 자료조차 없어 먼 훗날 포트폴리오를 작성하게 될 경우, 기억을 더듬더듬하지 않아도 되기 위해 이런 식으로 기록하는 것도 좋을 거라 생각한다.
1. 프로젝트 소개
- 프로젝트명: 비공개
- 도메인: 복지(공공)
- 프로젝트 목표: 1) 모델 재학습, 2) XAI, 3) 재현 데이터, 4) 비정형 데이터, 5) 기획
- 기간: 2023.09.06 ~ 2024.04.02
- 참여 인원: 총 4명
- 담당 업무: 모델 재학습, 재현 데이터, 사업관리 지원
우리가 맡은 프로젝트 기간으로 주어진 것은 대략 8개월이다.
긴 기간이지만 체감상 2월 설날 이후에 몰아서 일한 느낌이다.
팀장(PL) 1명과 실무 3명이 투입되었다. 다들 같이 일해보는 것은 처음이였다.
2. 업무 내용 및 수행과정
사이트로 나가서 업무를 진행하기 전에 이미 어느 정도 윤곽이 나와있는 요구사항은 최대한 스터디하고 들어가기로 했다. 그래서 부지런히 공부했던 주제는 재현 데이터, 랜덤 포레스트 이렇게 두 개에 대한 이론을 공부하고 베이스 코드를 만들어 둔 상태로 사이트에 나가게 되었다.
1) 모델 재학습
제안 단계에서 정해져 있던 주제는 회의 과정을 거치면서 점차 바뀌고 사라지고 추가되고를 반복하였다. 제일 이상했던 요구사항은 최신기술을 쓰면 좋겠고, 설명가능한 XAI를 썼으면 좋겠지만, 비전문가들이 이해할 수 있는 모델이면 좋겠다. 블랙박스 모델일 경우엔 의사결정권자에게 설명하고 설득하기 어렵다는 것이다. 여러 대안을 가지고 갔었고 그나마 설득하기 좋은 것은 로지스틱 회귀였지만 그건 또 구식이라고 싫다고 한다. 결국 알고리즘을 바꿔서 모델을 재학습하기보단 기존에 사용한 XGBoost를 사용하겠다고 했는지 변경하지 않았다.
모델을 재학습하기 위해서 데이터만 최신 데이터로 바꾸고 새로운 칼럼을 추가하면 되었다. 재학습이 필요한 모델은 크게 3종이 있었고 각자 하나씩 맡으면서 난 제일 오래전에 설계되었던 모델을 맡았다. 오래 전 개발된 모델이라 그런지 데이터 형식도, 코드도, 설계된 방식도, 어설픈 것이 많았다. R을 사용하던 때에 만들어졌고, 파이썬으로 변경되었었고, 알고리즘을 바꾸기도 했었고, 중간중간 코드수정과정도 있었는지 많이 지저분했다.
초반 프로젝트에 투입되어 사무실에 갔을 땐 환경셋팅한다고 1달 넘게 소요되었다. 내부망을 설치하고 그 안에서 도커를 설치하고 허가를 받기 위해 기다리는 시간 등 많은 시간을 쓰게 되었다. 그 후로 사용할 데이터, 코드, 매뉴얼 등 자료를 인계받았고 그걸 이해하는데도 꽤 많은 시간을 쓰게 되었다.
과거 프로젝트를 경험했을 땐 주로 데이터 수집부터 분석 단계까지 모두 내가 처음 시작하는 것이기에 기획하고 코드 짜는 것 모두 내 몫이었다. 내 사고를 통해 나온 결과물들이기에 이해를 할 필요가 없고, 타인에게 설명하기도 수월했다. 그렇지만 타인이 만든 결과물을 보고 어떤 사고를 통해 이렇게 코드를 짠 것인지 이해하는 시간이 제일 어려웠다. 남이 쓴 코드를 보면서 모르는 것을 배우기도 해야 하고, 어떤 의도로 객체를 생성했고 어디에 쓰려고 하는지도 이해해야 했다. 여기서 코드를 보고 이해하는데만 두세 달이 걸렸던 것 같다. .py에 담겨있는 소스 코드를 노트북 파일에서 실행해 보면서 시간투자를 했다.
코드를 이해하면서 허점들이 발견되어 수정할까? 싶었지만 프로젝트 기한을 생각해서 크게 변경하지 말잔 의견을 받아들였다. 데이터 타입이 안 맞아도 돌리는데 크게 문제없고, 무사히 실행되면 된 거고, 성능만 잘 나오면 문제없다는 것. 아쉽지만 내가 크게 갈아엎어서 성능이라도 떨어진다면 그건 중요하지 않다는 것이 현실이기에 받아들일 수밖에 없었다. 이후 요구사항에 맞춰 필요한 칼럼을 추가하기 위해 코드를 수정하고 기계적으로 업무를 수행하다 보니 흥미가 점점 떨어졌다. 그저 빨리 별 탈 없이 끝내는 것이 목표가 되었다. 분석 솔루션에 넣어 테스트 과정을 여러 번 거치고, 추가적인 요구사항을 들어준 이후 마무리를 지었다.
2) 재현 데이터
초반에 과제 수행 시 요구되었던 사항은 재현 데이터를 만들어서 모델 학습용으로도 쓰면 좋겠고, 비식별 처리도 되면 좋겠고, nan값이 없으면 좋겠고 다양한 요구사항을 가져왔었다. 어느 정도 개념이 잡혀 고객이 원하는 것이 2가지의 기술이 혼용되었다는 것을 확인하고, 둘 다 하기로 결정했다.
하나는 재현 데이터를 생성하는 모델을 만들어서 제공하면 된다. 이건 더불어 임의의 데이터를 생성하는 것이기에 비식별 처리가 되면서, 모델이 학습하여 생성하는 것이기에 nan값이 존재하지 않는다. 다만 비정형 쪽에서 재현 데이터를 생성해서 모델 학습에 사용하듯이 이걸 정형 데이터에 모델 학습용으로 써도 되는지가 의문이었고, 유사기관/기업에서도 아직까진 모델 학습으로 사용하지 않기에 분석용/공유용으로만 사용하라고 전달했다.
다른 하나는 모델 학습용으로 쓰면 좋겠다는 요구사항을 충족하기 위해서 오버샘플링에 관한 자료를 제공했다. 기존 모델의 프로세스를 그대로 따른 모델과 오버샘플링을 적용한 모델의 성능을 비교하여 자료를 제공하고 크게 어려움이 없었다. 다만 고객이 이걸 이해하지 못하고, '진짜 데이터가 아니지 않느냐'로 반문을 제기하면 또 그만큼의 설득과정이 필요했다. 난 내가 해줄 수 있는 만큼 이해시켜 주긴 했다. 성능 비교로 더 나은 결과물이 나왔지만 실제 모델에 적용되진 않았다. 직접 발 벗고 나서서 데이터를 수집하러 다니는 방식이 있지만 기술적으로 데이터를 증강시키는 방식이 있다는 것을 알면 다음엔 적용할 수 있을 것이라고 제안했다. 인수인계받는 고객이 다시 또 상급자를 설득하기 위해선 쉽지 않겠다는 것을 알지만 내 입장에선 최대한 알려주려고 했다.
타인을 설득하고 이해하게 만들려면 내가 아는 만큼, 내가 써먹는 만큼만 공부하는 것이 아닌 더 깊은 공부가 필요하다고 생각된다.
3. 문제점 및 애로사항
내 업무에서 가장 큰 문제점은 내가 맡은 모델 2개 중 1개가 현재 운영 중인 모델에 비해 성능이 떨어지는 것이다. 이걸 실무자나 전문가 입장에선 왜 그런지 짐작은 가지만 결국 설득과정을 진행하기 위해서 별의별 실험을 하게 되었다. 데이터 기간/양을 늘리기도 하고 줄이기도 하고, 칼럼을 추가했다가 빼기도 하고, 크게 해결되지 않았지만 과정 중 꽤 많은 모델을 생성하는데 시간을 들였다.
사실 현재 운영 모델의 성능이 말도 안 되는 입장이지만 과거의 성능을 이겨야 하는 싸움은 꽤 피곤한 시간이었다. 말도 안돼도 어찌할 수 없고, 결국 해결방안은 데이터양이었다. 성능이 높게 나와야 하며, 내가 맡은 모델만 고려해 볼 것이 아닌 동료들이 맡은 모델도 설계가 통일성이 있어야 하고, 우리는 이 프로젝트를 무사히 완료하고 떠야 했고, 고려해야 할 사항들 사이에서 타협점이 필요했다.
해결방안은 여러 실험과정 중 생성한 모델의 자료를 제공/공유하고, 프로젝트를 하는 동안 수집된 최신 데이터를 추가한 모델을 하나 더 만들어 성능을 확인해 보니 좋게 나왔고 이것 역시 제공하였다.
4. 배운 점
기술적으로 배운 점은 타인의 코드를 이렇게 유심히 파헤쳐 본 적이 없는데, 배울게 많은 프로젝트였다. 단편적으로 분석하기 편한 코드를 만들어서 쓰곤 했는데, 자동화/모듈화를 염두하여 함수를 짠 코드를 많이 볼 수 있었다. 이론적으로 배운 점은 IV(Information Value)와 PSI(Population Stability Index)를 배우고 써먹어 봤다. 금융 도메인에서 많이 활용하는 것으로 팀장의 금융 도메인 경험을 공유받아해 볼 수 있었다.
그 밖에도 리눅스, 우분투, 도커에 대한 이해도가 높아졌고, 솔루션으로 자동화하는 것을 실무적으로 경험해 본 것도 좋았다.
팀과의 커뮤니케이션은 초반에 많이 이뤄졌다. 나와 다른 동료 1명은 이 회사에 입사한 지 얼마 안 되었고, 다른 2명도 합을 맞춰보는 것이 이번 프로젝트가 처음이었다. 팀장과의 커뮤니케이션에서 초반에 답답함이 컸다. 나와의 의사소통을 직접적으로 하지 않고 자꾸 동료를 거치게 했는데, 그 과정에서 소실되는 정보가 있었다. 그럼 내가 해야 할 일을 제대로 못하면 결국 내 책임이 돼버리는 것이다. 아마 그 사이에 껴있는 동료도 꽤 불편했을 것이다. 대놓고 직접 팀장을 찾아가란 조언을 해주었고, 여기 회사는 어떤 문화를 가진 회사인지 눈치만 보다 그래도 되는구나 싶어 팀장을 찾아가 긴 대화 끝에 스스름없이 팀장이 날 대해주고 나도 어려움 없이 질문할 수 있었다.
고객과의 커뮤니케이션은 나름의 전략이 필요하고 팀장이 어떻게 행동하는지 관찰하면서 배우게 되었다. 고객은 기획자 마인드로 대화를 이어가고, 팀장은 개발자 마인드로 대화를 이어가는데, 여기서 서로 충돌이 발생할 경우, 팀장은 조용히 과묵하게 생각을 한다. 여기서 고객들이 눈치를 보게 되면서, 양보를 하게 되는데, 그게 꽤 나로선 재밌고 신기한 경험이었다. 다른 회의를 수차례 따라다녀봤지만, 고객이 갑이기에 해달라는 거 다 해준다고 예스맨이었던 분들과는 달랐다. 근데 그 과묵함이 먹히는 것이 신기했고, 기획자 마인드를 이해 못 하는 것은 아니지만, 일부러 고지식한 척, 일부러 기획자의 대화를 이해 못 한 척하는 것이란 생각이 들었다.
그리고 또 하나, 나는 회의를 따라가는 것도 좋아하고, 때론 싫어한다. 회의를 따라가게 되면 프로젝트 흐름을 잘 파악할 수 있고, 고객의 요구사항을 글자 그대로만 이해하는 것이 아닌 내포한 의미까지 이해할 수 있어서, 일을 여러 번하지 않고 원하는 것만 딱 집어내서 할 수 있다. 남들은 이런 상황에서 어떻게 얘기하는지 관찰도 하고, 내 발언권은 없어도 한두 마디씩 거들어보기도 하면서 말연습도 해본다. 근데 내 일이 너무 많아서 회의시간에 뺏기고 싶지 않은 것과 따라가면 회의록을 써야 한다는 점은 꽤 싫다. 그래서 그런지 내가 쫓아가는 회의는 까딱 잘못하면 2~3시간씩 에너지는 소모하고 결론을 못 짓는 경우가 많았다. 차츰 팀장은 날 회의에 데려가지 않게 되었고, 나의 오지랖 푼수짓도 꽤 괜찮은 전략이라고 생각한다.
5. 앞으로의 계획
앞으로 회사에서 어떤 프로젝트에 투입될지는 모른다. 그것과 별개로 난 사이드 프로젝트를 하려고 한다.
재현 데이터 부분은 팀장이 전적으로 나에게 믿고 맡긴 게 느껴졌다. 관련 내용으로 회의를 할 땐 꼭 데려가려고 했었고, 모델 인수인계할 땐 옆에서 거들면서 많이 도와줬지만 재현 데이터 인수인계할 땐 관전만 하는 것만 봐도 그러했다.
그만큼 타인에게 신뢰를 주려면 많이 공부해야 하고 남들에게 설득시킬 만큼 공부해야 한다고 느낀다. 그리고 내가 남들을 설득시킬 수 있으려면 자신감이 있어야 했다. 자신감을 키우려면 확신이 있어야 하고 경험이 있어야 했다. 왜 모델 성능이 나오지 않은지 지레짐작 데이터양이 적어서인지는 우리들끼리는 이해하지만 이걸 타인에게 설명하기란 쉽지 않다. 그만큼 경험과 노하우가 필요하다는 것. 약간의 의문을 던져도 나도 내 의견을 같이 의심하게 된다. 그래서 사이드 프로젝트를 진행하여 경험을 많이 쌓아야 한다. 비록 속도는 더딜지라도 내가 하는 말에 힘이 생기려면 많이 경험해봐야 한다는 걸 느꼈다.
