개요
기존에 있던 신용 평가 모델로는 대출을 받기 어렵지만, 충분히 상환 능력이 있는 그런 유저들이 새로운 신용 평가 모델에서는 대출을 받을 수 있다. 이렇게 새로운 신용 평가 모델에서 대출을 받은 유저들의 데이터가 쌓이면서 다시 한 번 신용 평가 모델을 개선할 수 있는 선순환 구조를 가지게 된다.
따라서, IT 업계에서 자체적인 신용 평가 모델을 가질려고 하고 이를 대출이나 후불 결제 등에서 사용한다. 이렇듯 신용 평가 시스템이 있고, 심사를 통해 대출을 받게되는데 이러한 대출 심사 프로세스를 간소화한 버전을 개발해보자!
최종 코드는 이쪽에서 확인
GitHub - happyprogfrog/fintech: 대출 심사 프로젝트
대출 심사 프로젝트. Contribute to happyprogfrog/fintech development by creating an account on GitHub.
github.com
사용하는 기술 스택
- 언어
- 코틀린
- 라이브러리/프레임워크
- SpringBoot(Multi Module) - 여러 개의 모듈을 하나의 프로젝트에서 다룬다!
- JPA(Spring Data JPA)
- Kafka - 메세지 큐
- Spring Cloud Gateway - 프록시 서버
- JUnit5 - 테스트 코드
- Swagger - API 명세
- 인프라스트럭처
- MySQL
- Redis - 캐시
- Docker
- 캐시 사용 이유?
- 일정 기간 동안은 신용 등급이 변하지 않게끔 캐시에 담아놨다가, 한 번이라도 신용 평가를 받은 적이 있는 유저다!라고 하면 캐시에서 바로 심사 결과 데이터를 보여주거나 심사를 받았다는 것을 노티를 해주는 것이 좋다.
- 메시지 큐를 중간에 넣은 이유?
- 대부분의 금융사들은 시스템이 오래됨
- 스케일 아웃보다는 스케일 업으로 트래픽을 감당 - 스케일 업에 한계가 있음
- 다양한 회사에서 신용 평가를 요청하기 때문에 트래픽이 많음
- 따라서, 메시지 큐를 둬서 순차적으로 신용평가를 받도록 할 예정
DB 테이블 구조
USR_INFO: 유저 테이블
- usr_key: UUID로 직접 생성
- usr_reg_num: 대부분의 금융사에서 유저의 주민번호를 키값으로 가지고 있으므로, 주민번호를 수집
- usr_nm: 유저 이름
- usr_icm_amt: 유저 소득 금액
LOAN_REVIEW: 대출 심사 테이블
- usr_key: UUID로 직접 생성
- loan_lmt_amt: 대출 한도 금액
- loan_intrt: 대출 이자율
API
프로젝트 진행 순서
데이트가 흐르는 플로우 기준
서비스 모듈 구현하기 -> 카프카 구현하기 -> Spring Cloud Gateway 구현하기 -> CB사 모형 서버 구현하기
반응형
