PROJECT 01
대출기업 부실징후 탐지
조기경보시스템 (EWS)
은행이 대출을 내준 기업이 흔들리기 시작할 때, 그 신호를 재무제표에서 먼저 잡아내는 시스템입니다. 예측 모델을 만드는 데서 끝내지 않고, 실무자가 실제로 열어보는 웹 대시보드까지 이어 붙였습니다.
01 배경
부실은 갑자기 오지 않는다
기업이 부실해지는 과정은 대체로 재무제표에 먼저 흔적을 남깁니다. 문제는 그 흔적이 수치 하나가 아니라 여러 지표의 조합으로 나타나고, 담당자가 수천 개 기업을 일일이 들여다볼 수는 없다는 점이었습니다.
그래서 질문을 이렇게 좁혔습니다 — "지금 이 기업이 위험한가?"가 아니라, "어떤 기업부터 먼저 봐야 하는가?" 판단을 대신하는 시스템이 아니라, 담당자의 시선이 향할 순서를 정해주는 시스템을 목표로 삼았습니다.
판단은 사람이 합니다. 시스템이 할 일은 봐야 할 것을 앞에 놓아주는 것입니다.
02 데이터
7.5만 개 기업, 24년치
TS2000과 KRX에서 KOSPI·KOSDAQ 상장사의 재무제표를 수집했습니다. 약 7.5만 개 기업, 24년에 걸친 시계열이었고 원본은 예상대로 손볼 곳이 많았습니다.
- 이상치 — 소수 기업의 극단적인 재무비율이 분포 전체를 끌고 다녔습니다. Winsorizing으로 상·하위 꼬리를 눌러 모델이 특이 케이스에 과하게 반응하지 않도록 했습니다.
- 결측 — 한 가지 방식으로 몰아서 채우지 않았습니다. 항목 자체가 없는 경우와 값이 0인 경우, 공시 누락인 경우를 구분해 처리를 나눴습니다.
- 분포 — 한쪽으로 심하게 치우친 지표는 로그 변환으로 정리해 선형 모델이 신호를 놓치지 않게 했습니다.
- 파생 변수 — 안정성·수익성·성장성·활동성 축으로 재무비율을 설계하고, 회계 조작 징후를 잡는 Beneish M-score를 별도 경보 지표로 넣었습니다.
03 모델링
세 모델을 나란히 놓고 비교했습니다
Logistic Regression을 기준선으로 두고 XGBoost와 CatBoost를 함께 학습·튜닝했습니다. 부실 기업은 전체의 극소수이기 때문에 정확도(Accuracy)는 애초에 의미가 없었고, ROC-AUC를 주 지표로 삼았습니다.
해석 가능성도 함께 봤습니다. 금융 도메인에서는 "왜 이 기업이 위험한가"를 설명하지 못하면 아무리 좋은 점수도 쓰이지 않습니다. 그래서 성능이 비슷한 구간에서는 변수 기여도를 읽어낼 수 있는 쪽을 택했습니다.
0.88
최종 모델 ROC-AUC
0.88–0.90
데이터셋별 ROC-AUC 범위
4종
재무 축별 파생 지표 + M-score
04 시스템
수집부터 전달까지 하나로
이 프로젝트에서 제가 단독으로 맡은 부분입니다. 학습된 모델을 FastAPI로 감싸 부실확률 API로 만들고, PostgreSQL에 기업·재무·예측 결과를 적재했습니다. 프론트엔드는 HTML·CSS·JavaScript로 직접 작성했고, AWS EC2에 Nginx를 리버스 프록시로 올려 배포까지 마무리했습니다.
대시보드가 답하는 것
- 부실확률 게이지 — 모델이 낸 확률을 0~100 스케일의 게이지로 보여줘, 숫자에 익숙하지 않아도 위험 수준이 바로 읽히게 했습니다.
- 업종별 벤치마크 — 절대값만으로는 판단이 어렵습니다. 같은 업종 안에서 이 기업이 어디쯤인지를 함께 보여줍니다.
- Beneish M-score 경보 — 회계 조작 징후가 임계치를 넘으면 별도 경보로 띄웁니다.
- AI Report 자동 생성 — OpenAI API로 예측 근거와 주요 지표 변화를 문장 리포트로 정리합니다.
- 이메일 알림 — 관심 기업의 위험도가 기준을 넘으면 담당자에게 메일이 나갑니다. 대시보드를 열지 않아도 신호가 먼저 도착합니다.
05 결과
만장일치 최우수상
하나은행, 한국상장회사협의회, KODATA 심사위원단의 만장일치 최우수상을 받았습니다. 모델 성능 자체보다, 예측 결과가 실무 화면까지 실제로 이어져 있다는 점에 심사평이 모였습니다.
3.5주라는 짧은 기간이었지만 수집·전처리·모델링·서빙·전달이 전부 돌아가는 상태로 마무리했습니다. 데모가 아니라 접속해서 쓸 수 있는 형태였다는 것이 이 프로젝트에서 가장 마음에 드는 부분입니다.
06 배운 점
모델은 절반이었습니다
- 0.88은 시작점이지 결론이 아니다. 성능을 올리는 데 쓴 시간보다, 그 결과를 어떻게 보여줄지 고민한 시간이 실제 평가를 갈랐습니다.
- 배포까지 해봐야 아는 것들이 있다. 로컬에서 잘 돌던 API가 EC2에서는 다르게 굴었습니다. Nginx 설정과 환경 변수, 응답 지연 — 직접 부딪히며 배운 것들이 문서로 읽은 것보다 오래 남았습니다.
- 전처리 속도가 빨라졌다. 첫 프로젝트에서 3주 걸렸던 규모의 전처리를 이번에는 7일 안에 끝냈습니다. 지난번에 막혔던 지점을 기록해둔 것이 그대로 시간이 됐습니다.
- 혼자 다 만들면 구조가 보인다. 백엔드·프론트·배포를 한 사람이 맡으니 어디서 병목이 생기는지가 명확했습니다. 이후 협업에서도 남의 영역을 이해하는 데 도움이 됐습니다.
07 링크
github.com/ksw222/riskqueens — 모델 코드와 대시보드 소스
배포 환경은 AWS EC2 + Nginx로 운영했으나, 교육과정 종료와 함께 인스턴스를 내렸습니다. 화면 구성과 동작은 위 저장소에서 확인하실 수 있습니다.