[데이터분석 부트캠프] 3조 7월 4주차 수행일지(7.21 ~ 7.25)

syeom·2026년 7월 30일

Track B

강사님 피드백 다섯 항목을 반영해 대안변수를 46개에서 69개로 확장했다. 다중공선성 필터링은 후순위로 미루고, 소비패턴 변수를 절대금액과 성장률 쌍으로 넓게 추가한 뒤 SHAP 기반으로 사후 선별하는 방식으로 전환했다. 이 과정에서 리케이지 변수와 센티넬코드값 오염 필드를 추가로 발견해 제거했다.
씬파일러 자체검증에 쓰던 레퍼런스 인원수 오류(197명→240명)도 바로잡았다. 정의 시점과 신호 시점이 겹쳐 있던 197명 대신, 정의(202103)와 신호(202203)를 시점분리한 240명을 기준으로 삼았다. 이후 26개 전통 신용변수 베이스라인 대비 H4, 대안변수의 보완관계를 확인한 H7, 48개 변수 전부 단독 변별력을 확인한 H8 가설 검증을 마쳤고, 69개 변수 모델 기준 Val AUC 0.7824를 확보했다.
저장소 정비도 함께 진행했다. macOS의 유니코드 정규화 방식 차이로 한글 파일명이 중복 인식되던 문제를 해결했고, v1.0.0/v1.1.0/v1.2.0 형태의 태깅 컨벤션 초안을 세워 팀 논의에 부쳤다.
2차 멘토링을 진행하며 두 트랙의 구조적 한계에 대한 지적을 받았고, 두 트랙의 병합 가능 여부를 코드북으로 다시 확인해 병합이 불가능함을 재확인했다.

Track A

강사님 피드백을 반영해 타겟변수를 12개월 단일에서 12개월/24개월 병행(주 타겟은 24개월)으로 확장했고, 그 결과 양성 표본이 96건에서 144건으로 늘었다.
불균형 처리 방식도 바꿨다. 기존 가중치 방식 대신 음성 다운샘플링과 앙상블 조합으로 교체했는데, SMOTE 방식은 fold 내부 대조 실험에서 실
제 이득이 없음이 확인되어 배제했다. 자산 신뢰수준 변수는 독립 변수가 아니라 결측 품질을 나타내는 플래그로 재배치했고, 최근 1년간의 변화를 보는 Δ생활이력 파생변수를 새로 추가했다.
최종적으로 인구변수(성별·연령)를 제외한 기준으로 AUROC 0.679를 공식 성능으로 확정했다. 인구변수를 배제한 이유는 은행권 차별금지 모범규준과 신용평가사 공시 관행상 성별·연령이 평가요소에 포함되지 않기 때문이다. 또한 2022년 진입자가 급증한 원인도 규명했는데, 인터넷전문은행의 중·저신용자 포용 정책과 시기·방향이 정합함을 확인했다.

모델링

Track B 모델의 튜닝과 교차검증을 진행했고, H4 가설의 정식 재검증 결과 개선폭이 +8.64%p로 상향 확인됐다.

2차 멘토링 피드백

가장 핵심적인 지적은 두 트랙이 서로 다른 방식으로 불완전하다는 점이었다. 한쪽 트랙은 정답 라벨은 있지만 대안변수로 쓸 소재가 부족하고, 다른 쪽 트랙은 소재는 풍부하지만 정답 라벨이 없다는 것이다. 이 구조적 차이가 다른 모든 지적의 원인이라는 진단을 받았다.
여기서 파생된 지적으로, 씬파일러에게 모델을 적용하는 것은 정답이 있는 것이 아닌 이상 "검증"이 아니라 "적용"이라 불러야 한다는 점, 소재가 풍부한 트랙을 메인으로 두고 다른 트랙을 보조로 재배치할 필요가 있다는 점을 정리했다. 두 트랙의 병합 가능 여부도 다시 검토해볼 것을 권고받았는데, 코드북을 확인한 결과 개인 식별자 체계가 트랙마다 완전히 달라 물리적으로 병합이 불가능함을 확인했다.

느낀 점​

이번 주는 변수를 늘리는 작업과 그 결과를 점검하는 작업이 동시에 일어난 한 주였다. 46개에서 69개로 변수를 확장하는 과정에서 리케이지 변수와 센티넬코드값 오염 필드를 새로 발견했는데, 둘 다 이전 단계에서 이미 한 번 걸러냈다고 생각했던 지점에서 다시 나온 것이었다. 변수 조합이 달라지면 같은 검증을 처음부터 다시 해야 한다는 것을 이번에 체감했다.
Track A의 성능 확정 과정도 인상적이었다. 인구변수를 포함하면 AUROC가 더 높게 나오지만, 실무 규범(차별금지 모범규준·신용평가사 공시 관행)에 맞춰 성별·연령을 제외한 수치를 공식 성능으로 삼았다. 처음엔 성능을 낮춰 잡는 보수적인 선택처럼 보였지만, 오히려 "규범을 지키면서도 대안변수만으로 변별력이 성립한다"는 게 프로젝트가 증명하려는 것과 정확히 일치하는 지점이라는 걸 깨달았다. 숫자를 그대로 쓰는 것보다, 어떤 조건에서 나온 숫자인지가 더 중요하다는 걸 확인한 사례였다.
2차 멘토링에서 받은 지적은 지금까지의 작업 방향을 다시 생각하게 만들었다. 각 트랙이 서로 다른 문제(라벨은 있는데 소재가 없는 트랙, 소재는 있는데 라벨이 없는 트랙)를 안고 있다는 건 알고 있었지만, 이게 "두 트랙이 서로를 검증할 수 없다"는 근본적인 한계로 이어진다는 지적을 받고 나서야 지금까지의 설계가 데이터가 허용하는 범위 안에서의 최선이었다는 걸 더 명확히 설명할 수 있게 됐다. 병합이 물리적으로 불가능하다는 걸 코드북으로 직접 재확인한 것도 같은 맥락이었다. 앞으로는 두 트랙의 결과를 각각 완결된 근거로 제시하되, 메인·보조 구조를 재배치하는 방향으로 다음 주 작업을 이어가야겠다고 생각했다.

다음 주 계획

2차 멘토링 피드백을 반영해 Track B를 메인, Track A를 보조로 재배치하는 방향을 팀 논의로 확정
모델링 결과를 확인하고 방향성 착수
서비스 대상을 확실히 정하기(은행/보증기관/둘 다/그 외)
Git 태깅 컨벤션을 팀 협의 후 확정 및 적용
Streamlit 대시보드 설계 착수

profile
공부 기록

0개의 댓글