brunch

You can make anything
by writing

C.S.Lewis

by N Lee Sep 15. 2024

대망의 부트캠프 중간 프로젝트 리뷰

[한국경제신문 with toss bank] Tech우수인재양성 MLOps

이전 포스팅은 아래에서 -- 
1. 한달 후기(feat. 퇴사) - [한국경제신문 with toss bank] Tech 우수인재 양성을 위한 (풀스택 / MLOps) 과정
2. 한국경제신문 with toss bank 대망의 첫 날, OT 및 첫 수업 후기(feat. 국비지원 부트캠프 지원 계기)

머신러닝 수업을 다 나갈 때 즈음

미니 프로젝트, 그러니까 중간 프로젝트를 시작한다고 했다. 


그렇게 시작된 약 3주간의 중간 프로젝트..!


팀은

정말 고맙게도 먼저 제안해준 친구가 있어서 조심스레 합류했다. 


'조심스레' 는..진짜 아직 초짜에 생초짜라 할 줄 아는게 있나 싶기도 하고...

내 나이가 적지 않은터라 편하지만은 않을 텐데 이렇게 먼저 제안을 해줬다는게 고마우면서도 민폐가 되지 않을까

노심초사했다. 


우선 결과부터 말하자면

잘했다. 




중간 프로젝트라 조금 가벼운 마음으로 임했으나

다른 친구들은 매우 진지하고 깊게 파고든 덕분에

'대상'을 타게 되었다.



수상은 토스뱅크 사무실 투어를 진행하는 날에 진행됐는데,



그때 CTO님도 봤고



멘토님들의 발표도 들을 수 있어서 좋았다.

생각보다 더 동기부여가 뽱뽱 됐달까



귀여운 스티커도 받고

토스의 귀여운 '캐치' 캐릭터로 된 키링과 인형도 받았다!



커피도 제공해주시고, 

사무실 투어도 쉽지 않은데..아주 귀한 기회를 마련해주셨다. 

행사가 모두 끝난 이후에는 아주 든든한 점심도 챙겨주셨다. ㄷㄷ

심지어 소갈비...


완전 꿀맛이었는데, 

더 좋았던 건

평소에 수업듣느라 이야기해보지 못했던 다른 친구들과도

커뮤니케이션 할 수 있는 기회가 생겨서 좋았다. �

수상까지 하고 나니, 


프로젝트가 드디어 끝났구나..싶으면서도

막 상금이 걸린 그런 대회가 아니라서 '대상'이란게 

크게 의미가 있겠냐 생각할 수도 있겠냐싶지만


개인적으로는 이렇게 좋은 결과물을 얻었다는 것에 놀랐고, 

실력 좋은 팀원들 덕분에

공부에 대한 마음가짐부터 데이터 분석 및 모델링에 대한 전반적인 프로세스를 잔뜩 배울 수 있었다. 




프로젝트 간단 후기


이번 진행한 프로젝트의 주제는 

'연체 예측 모델링'이다. 


그래서 우리는 ‘고객 정보를 이용한 대출 연체 예측 모델링’을 주제로 했다. 


우리가 작업했던 전체 Github은 아래에서 볼 수 있는데,

프로젝트를 이끌었던 팀장이 굉장히 깔끔하게 정리해놓은 터라

누구나 쉽게 이해할 수 있을 것이다.

HKToss-Project Github


프로젝트는 발표 25분+QnA10 분 정도를 포함해 약 35분 정도 진행되었다. 


이 중, 우리 팀은 예측 모델링을 통한 대시보드를 Streamlit으로 만들어서 시연했는데


사실 이것보다도 핵심은

'MLOps Pipeline'을 구축하여 스케줄/이벤트 기반으로 머신러닝 라이프사이클과

모델 버전 관리 및 CI/CD를 통해 테스트 및 배포를 모두 자동화 한 것이었다.

그리고 이를 웹 UI 등을 통한 간편한 모니터링으로 구축했는데 


아직 수업 시간에 MLflow를 배우지 않은 나의 입장에서는

계획 -> 설계 -> 구축 을

뚝딱뚝딱 해 낸 팀원들이 멋있기도 하고

어나더레벨로 보이기도 했다.


난 아직 EDA도, 머신러닝도 허덕거리는 와중인데...

다행스럽게도

발표로 만회할 수 있어서 다행이었다. 

(휴)



프로젝트 피드백(feat. 토스뱅크 멘토님)


이렇게 발표를 마치고나서

토스뱅크 멘토님으로 부터 받은 피드백을 받은 내용에 대해 정리해보았다. 


먼저 


1. 대출 연체 예측은 0,1이 아닌 등급으로 카테고리화 해야 한다. 

대출 연체 예측 시, '대출 승인/거절 을 0~1 확률 로 예측하는 것은 옳지 않다'.


'대출 여부는 신용 등급이 나뉘어진 이유와 동일하게 `등급화` 되어야하며, 등급 값(int) 을 기준으로 대출 여부가 결정된다. 

예를 들면, '부도율 == 연체/미납'으로 보기 때문에 6등급 이상이 되면 부도율, 즉 연체 가능성이 높다고 본다. 

이런 등급에겐 대출 승인의 리스크가 크지만, 리스크를 충당할 만한 수준으로 금리 조절을 하여 해결할 수 있다.  


그러나 '금리'는 국가기관에서 지정한 공식적인 수식이 있고, 은행은 여기서 1~2% 정도의 수준으로만 변동이 가능하기 때문에

대출 승인 여부는 결국 신용 등급을 보고 예측한다. 


그러므로 신용 등급에 따른 부도율을 예측해야 하는 것이다. 




(ex. 대출 이자는 어떻게 계산 되나요?)



그리고 두번째로 받은 피드백은 F1 socre에 대한 내용이었다.


2. 모델 분류 성능 평가 지표로 AUROC를 사용해야 한다. 


모델 분류 성능 평가 지표로 F1 score을 사용했는데, 대출 승인 여부는 F1 score 대신 AUROC를 사용해야 했다. 

신용 등급에 따른 부도율에는 AUROC(=AUC-ROC)가 주로 사용되며, threshold값은 은행이 고른다는 것. 

대출 여부 결정과 같은 이진 분류 문제에서 AUC-ROC가 F1 Score보다 더 자주 사용되는 이유는 두 지표의 특징과 해석 방식에서 차이가 있기 때문인데,

클래스 불균형 문제와 분류 모델의 성능 평가 목적에 관련이 있다. 


대출 여부에서 AUC-ROC가 더 적합한 이유

대출 결정 문제는 보통 클래스 불균형이 심한 경우가 많다. 
승인보다 거절이 많을 때, 양성 클래스(대출 승인)에 집중한 F1 Score는 대출 거절 예측 성능을 제대로 평가하지 못할 수 있다.
AUC-ROC는 모든 임계값에서 모델의 성능을 측정하며, 양성(대출 승인)과 음성(대출 거절) 모두에 대해 고려하므로 대출 여부를 평가하는 데 더 적합하다.
대출 승인 확률에 대한 순위화가 중요: AUC-ROC는 모델이 잘 예측한 순서에 대한 정보를 제공한다. 
은행에서는 확률을 기반으로 대출을 승인을 결정하는데, 이 순서가 중요한 경우가 많다.
따라서, 대출 승인 여부와 같은 문제에서는 모델의 전체적인 성능과 클래스 불균형을 고려할 수 있는 AUC-ROC가 더 적합하게 사용된다.


- AUC-ROC

 (Area Under the Curve - Receiver Operating Characteristic): True Positive Rate (TPR)(민감도)와 False Positive Rate (FPR)의 관계를 시각적으로 표현한 그래프인 ROC 커브의 아래 면적을 계산한 값이다. AUC-ROC는 주로 모델의 

전체적인 분류 성능

을 평가하는 데 사용된다.                 

장점:                        

클래스 불균형 문제: 대출 승인 여부와 같이 거절(0)과 승인(1)의 비율이 불균형할 때도 AUC-ROC는 모델의 전체적인 성능을 측정하는 데 유리다. 이는 모든 임계값에서 True Positive Rate와 False Positive Rate를 모두 고려하기 때문이다.


임계값 변화에 따른 성능 평가: AUC-ROC는 모델이 출력하는 확률을 임계값(threshold)에 따라 조정하면서, 다양한 민감도와 특이도를 고려한다. 대출 여부 결정에서 임계값을 조정해야 할 경우 AUC-ROC는 더 유용한 지표다.


모델의 예측 순서를 평가: AUC-ROC는 모델이 얼마나 잘 순위를 매기는지 평가할 수 있어, 대출 승인 확률이 높은 사람을 상위에 배치할 때 성능이 좋다.


- F1 Score


 정밀도(Precision)와 재현율(Recall)의 조화 평균이다. F1 Score는 양성 클래스(예: 대출 승인)를 얼마나 잘 예측했는지에 중점을 둔다.                

F1 Score의 한계:                        클래스 불균형에 민감: F1 Score는 양성 클래스(대출 승인)의 예측에만 집중하므로, 클래스 불균형이 있는 경우(대출 거절이 많고 승인이 적은 경우) 성능을 제대로 평가하기 어렵습니다.             임계값 고정: F1 Score는 특정 임계값에서의 성능만 평가합니다. 대출 여부에서 임계값을 변경해야 할 때(예: 더 보수적인 대출 정책을 위해) F1 Score는 그 변화를 반영하지 못한다.  


아래는 위와 관련된 내용들을 더 찾아보다가 아래의 '신용평가' 관련 내용들을 조금 더 깊게

살펴볼 수 있었다. 

신용평가의 비밀 - 신용평가모형의 등장 (저 Ryan choi)

NICE - 개인신용평점의 의미: 주요 평가 요소


참고

a. 신용정보란 무엇인가요? 신용정보란 금융거래 등 상거래에 있어서 나를 식별하여 신용도, 신용거래능력 등의 판단을 위하여 필요로 하는 정보로 1-10등급 또는 0-1000점으로 표기되며 1등급에 가까울수록, 1000점에 가까울수록 신용도가 더 높다는 것을 의미합니다. (출처: 카카오뱅크)


b. KCB와 NICE 신용점수는 무엇이 다른가? KCB와 NICE는 신용평가사로 신용카드, 대출 등의 금융 활동 정보로 나의 신용을 평가하고 신용점수를 제공하는 곳입니다. KCB 와 NICE는 신용점수를 평가하는 방식이 조금 다르지만 두 곳의 점수를 다양한 금융기관에서 사용하고 있기 때문에 함께 관리가 필요합니다.




c. CB사(Credit Bureau, 개인신용조회회사): 금융기관, 기업 등으로부터 신용정보를 수집하여 이를 평가하고 개인의 신용상황을 판단할 수 있는 정보를 금융회사 등에게 제공·판매하는 회사(나이스(NICE)평가정보, 코리아크레딧뷰로(KCB), 한국기업데이터(KED), 한국평가데이터, SCI평가정보 등)             


d. 신용평가모형은 활용 목적에 따라 '일반 신용평가모형'과 '내부 신용평가모형'으로 구분된다. 


일반 신용평가모형은 신용평가회사에서 개발하는 모형으로 Generic 모형 또는 CB(Credit Bureau) 모형이라고 불리는데, 범용적으로 활용할 수 있게 만든 모형 또는 금융소비자가 본인의 신용도를 조회할 때 쓰이기 위한 목적으로 개발한 모형이다. 


반면, 내부 신용평가모형은 은행 등의 금융회사가 해당 차주(creditor, 돈을 빌리는 측의 사람)의 금융거래 이력 정보(ex. 대출, 연체 관련 정보)와 자사 고객에 대해 수집한 정보(ex. 소득, 자산, 직업, 연령 등)을 함께 활용하여 만든 모형으로, 해당 금융회사의 정책이나 자사 고객의 특성을 더욱 상세하게 반영할 수 있다. 이러한 모형을 금융회사의 CSS(Credit Scoring System)이라고 부르며, 이 CSS 내에서 신규 거래고객을 대상으로 대출 승인 여부와 신규계좌 개설 등을 판단하기 위한 ASS(Application Scoring System)과 기존 거래 고객을 대상으로 대출 연장 및 금리 변경 등을 판단하기 위한 BSS(Behavior Scoring System)로 다시 구별하여 운영하게 된다. 



ex. [보도자료] ‘24~’26년 인터넷전문은행 중‧저신용자 대출 공급계획 발표 중


아쉬운 점과 향후 계획


아쉬운 점은 사실 차고 넘친다.


처음엔 중간 프로젝트가 '미니 프로젝트'로 간단히 배운 걸 복습하는 차원이라고 해서

주어진 가이드에서 받은 데이터셋을 토대로 EDA 후, 간단하게 Streamlit으로 구현하면 되겠지 라고만 생각했다. 


그런데....

팀원들은 달랐다..!!


모두 다 금융 도메인 지식이 부족한 상황임에도 각 데이터셋과 컬럼을 하나하나 다 뜯어보면서

주제에 맞춘 파생변수들을 생성했다.

그리고 부족한 지식들은 그때그때 배우면서 가장 적절한 모델을 선정했고,

MLOps Pipeline의 설계부터 구축까지 한 다음에 AWS 클라우드에 배포하여 모두 자동화되도록 했다. 

또, Streamlit과 Figma도 다들 처음이라 익숙하지 않은 상황임에도

지인에게 물어가며, 구글링과 Chatgpt의 도움을 받아가며

여느 팀보다 가장 깔끔하고 잘 정리된 ppt를 완성했다.


다들 알고 있는 지식 수준과 배경이 다르지만

각자 역할에 맞춰 정말 진심으로 열심히 했다. 


그 와중에 

난 1인분을 소화했나 싶을 정도로 개인적으로는 참 부족했다고 생각이 많이 들었다. 

다행히 최종 발표를 부끄럽지 않게 했기에 망정이지

그것도 아니었다면

부트캠프에서 배운 것들을 충분히 소화시키지 못한 상태로 무임승차가 될 뻔 했다.


아무래도 내가

제일 나이도 많고, 사회경험도 꽤나 있는 상태였기에 이를 잘 활용하면

좋은 메리트가 될 거라고 생각했다. 

그런데

'과연 나의 그런 메리트를 팀원들에게 충분히 제공해주었는가'부터 시작해서

오히려 .... '피해를 끼치진 않았을까' 하는 생각까지 들었다. 


그래서 다시금

프로젝트를 리뷰하며 곱씹어보았고

이를 통해 내가 목표하는 직무로 가기 위해 필요한 것들이 무엇인가를 생각해보았다. 


결국 기본기다. 


토스뱅크 멘토님이 피드백 주신 것처럼

각 모델링에 대해 충분히 공부하고, 특히 관심있는 분야의 모델링을 파고 들어야 하겠다.

관련 기법이나 관련 논문을 빠삭하게 이해할 수 있는 수준까지 해야 할 것이다. 


지나가던 누군가가 '왜 이 모델을 썼는가' 에 대한 질문을 급 던진다고 했을 때

그에 대한 답변이 술술 나와야할 수준까지 되야 하지 않을까

더 나아가서는

나만의 전문성을 만들고

또, 금융권에 대한 도메인 지식도 틈틈히 공부하면서 최신 트렌드도 놓치지 말아야 한다..

(적다보니.. 갈길이 멀다멀어)


이 직무로 넘어오기 전에

'내가 과연 평생 공부하며 살 수 있을까?' 였는데,

거기에 대한 대답이 Yes였으므로

부트캠프까지 왔다. 


그런데 

약 3개월간 공부를 해본 입장에선

진짜로.....IT쪽은 패션 산업 보다 더 빠르게 트렌드가 대체되고

새로운 기술이 나오고,

배워야 할 것들이 산더미다...ㄷㄷ


그래....후

아직은 코드 한 줄 쓰는 것도,

강사님이 알려 주시는 개념들도 버벅버벅 거리는 수준이지만


계속 킵고잉 하자고.....


원래

꾸준히 하는게 제일 힘들다고 했다 ㅎㅎㅎㅎㅎㅎ


출석도 열심히 하고 있고, 인강을 통해 보충도 하고 있고, 공부도 아직

손 놓지 않고 꾸준히 하고 있다.

그리고 이 공부를 ..반짝 취업 때문에 하는 것도 아니니까

힘내서 계속 더 기본기를 잘 다져놓자고

(사실 개인적으로 아픙로의 다짐을 다지는 목적으로 쓴 포스팅이다 그러니까..추석때.... 놀지만 말자 젭알� )


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari