소상공인 금융지원 의사결정 플랫폼 구축 계획

1. 목표와 범위

현재 서비스는 브라우저에서 입력값을 받아 가상 위험도와 심사 트랙을 표시하는 프로토타입이다. 다음 단계의 목표는 실제 데이터와 비동기 모델 파이프라인을 연결하되, 모델이 승인·거절을 자동 결정하지 않는 담당자 의사결정 보조 플랫폼으로 구축하는 것이다.

MVP의 범위는 신청 입력, 통계 비교, 모델 점수, 심사 트랙, 담당자 검토, 결과 설명, 이의제기 접수, 감사 로그, 운영 모니터링이다. 결제·실제 대출 실행·완전 자동 승인과 같은 금융 핵심 업무는 MVP 범위에서 제외한다.

2. 목표 아키텍처

브라우저 SPA
  ├─ 입력·통계·결과·담당자 콘솔
  └─ HTTPS API
       ├─ 신청/조회 서비스
       ├─ 통계 집계 서비스
       ├─ 모델 추론 워커
       ├─ 담당자 결정·이의제기 서비스
       └─ 감사·모니터링
            ├─ PostgreSQL (업무·결정·감사 메타데이터)
            ├─ Redis (작업 큐·캐시·rate limit)
            ├─ 오브젝트 스토리지 (서류, 암호화)
            └─ 모델 저장소/버전 레지스트리

개발 초기에는 단일 FastAPI 애플리케이션과 백그라운드 워커로 시작하고, 트래픽과 운영 경계가 확인된 뒤 서비스를 분리한다. 인증은 담당자·관리자와 일반 신청자를 구분하는 OIDC 또는 검증된 세션 토큰을 사용한다.

3. 백엔드 설계

3.1 주요 API

• POST /api/applications: 신청 초안 또는 신규 신청 생성
• GET /api/applications/{id}: 신청 상태와 입력값 조회
• POST /api/applications/{id}/score: 모델 점수 작업 등록
• GET /api/applications/{id}/result: 점수·트랙·설명 조회
• GET /api/statistics: 조건별 표본 수·평균·중위값·범위 조회
• GET /api/model-health: 모델·큐·결과 저장소 상태 확인
• GET /api/reviews: 담당자 검토 목록
• POST /api/applications/{id}/decision: 담당자 결정 저장
• POST /api/applications/{id}/appeals: 이의제기 접수
• GET /api/audit: 권한이 있는 운영자용 감사 로그

모든 쓰기 요청은 요청 ID, 인증 주체, 서버 시각, 입력 스키마 버전을 기록한다. API는 idempotency key를 지원해 네트워크 재시도로 중복 신청·중복 결정을 방지한다.

3.2 추론 파이프라인

신청 접수 → 입력 정규화 → 범위·결측 검증 → 통계 기준 조회 → 모델 버전 고정 → Redis 큐 등록 → 추론 워커 실행 → 결과와 설명 저장 → 담당자 큐 배정 → 사용자 화면 갱신 순서로 처리한다.

모델 결과에는 model_version, feature_version, scored_at, 예측 위험도, 트랙, 기준선, 주요 기여 요인, 입력값 출처를 함께 저장한다. 워커 장애·타임아웃·모델 버전 불일치는 조용히 기본값으로 대체하지 않고 명시적 오류 상태와 운영 알림으로 남긴다.

4. 프런트엔드 설계

React/TypeScript SPA를 기준으로 다음 화면을 구성한다.

1. 신청 입력: 단계형 폼, 필드별 단위·범위·출처 안내, 저장 가능한 초안, 키보드·스크린리더 접근성
2. 통계 비교: 조건 필터, 표본 수, 평균·중위값·전례 범위, 표본 부족 경고
3. 심사 결과: 위험도, 트랙, 기준선, 모델 버전, 설명, 보완점, 결과의 한계
4. 담당자 콘솔: 대기열, 필터, 원자료와 모델 결과 비교, 결정 사유, 재검토
5. 이의제기: 신청자 확인, 이의 사유, 첨부자료, 처리 상태와 답변
6. 운영 대시보드: 지연·오류·모델 드리프트·트랙 분포·이의제기 현황

프런트엔드는 서버가 반환한 결과만 표시하고 승인·거절을 자체 계산하지 않는다. 로딩·지연·실패·재시도 상태를 분리하고, 결과 화면마다 체험용인지 실제 검토 결과인지 명확히 표시한다.

5. 데이터베이스 구조

PostgreSQL을 기준으로 다음 테이블을 설계한다.

• applicants: 최소 신청자 식별자, 동의 상태, 생성·삭제 시각
• applications: 신청 번호, 자금유형, 상태, 입력 스키마 버전, 생성 시각
• application_features: 업종, 지역, 업력, 매출, 금액 등 정규화된 입력과 원자료 출처
• scoring_jobs: 큐 작업, 재시도 횟수, 상태, 오류 코드, 시작·종료 시각
• model_scores: 모델 버전, 예측 위험도, 등급, 백분위, 기준선, 트랙, 설명 JSON
• review_assignments: 담당자 배정, SLA, 검토 상태
• human_decisions: 승인·보류·거절 등 담당자 결정, 사유, 결정자, 결정 시각
• appeals: 이의제기 사유, 상태, 처리자, 답변, 처리 시각
• statistics_snapshots: 집계 기준일, 필터 차원, 표본 수, 통계값, 집계 버전
• model_registry: 모델 파일 위치, 버전, 학습 데이터 기준일, 승인 상태, 성능 지표
• consents: 동의 문구 버전, 목적, 시각, 철회 시각
• audit_events: 주체, 행위, 대상, 결과, request ID, 최소 변경 전후 메타데이터

민감한 원자료와 분석용 파생값을 분리하고, 신청자 식별자는 서비스 전용 난수 ID로 처리한다. 보존기간이 끝난 원자료는 삭제 또는 비식별화하며, 운영자 조회에는 역할 기반 행 단위 권한을 적용한다.

6. 정보수집 계획

6.1 수집 항목

MVP에서는 신청 판단에 직접 필요한 항목만 수집한다. 업종 코드, 사업 소재지(필요 최소 단위), 개업 시점, 신고 매출 구간, 신청 금액·기간, 자금 목적, 기존 지원·상환 이력의 동의된 요약값을 우선한다. 주민등록번호, 계좌 비밀번호, 불필요한 원문 개인정보는 수집하지 않는다.

6.2 출처와 품질

각 필드에 원천, 수집 시각, 단위, 변환 규칙, 신뢰 수준을 기록한다. 공식 행정·금융 연계 데이터는 제공기관 약관과 법적 근거를 확인한 뒤 사용하고, 사용자가 직접 입력한 값은 self_reported로 표시한다. 과거 승인·실행 사례만 사용하는 경우 거절·중도탈락 표본이 빠지는 선택 편향을 문서화하고, 가능한 범위에서 신청 전체 모집단 통계를 별도로 확보한다.

6.3 수집·정제 절차

1. 데이터 사전과 필수·선택 필드를 확정한다.
2. 개인정보 영향과 법적 근거를 검토한다.
3. 스키마 검증, 중복 제거, 단위 통일, 결측·이상치 규칙을 작성한다.
4. 원자료와 정제 데이터의 해시·버전을 기록한다.
5. 시간 기준으로 학습·검증·테스트를 분리해 미래 정보 누수를 방지한다.
6. 업종·지역·사업 연령별 표본 수와 성능 편차를 공개 가능한 범위에서 보고한다.

7. 단계별 일정

1주차: 요구사항·안전 기준 확정 (2026-08-27~09-02)

• 사용자 유형, 상태 전이, MVP 제외 범위 확정
• 데이터 사전·API 계약·오류 코드 초안 작성
• 개인정보·보존·동의·이의제기 정책 검토
• 완료 기준: 승인된 요구사항 문서, 위협 모델, 필드 목록, 화면 흐름

2주차: 저장소·배포·DB 기반 구축 (09-03~09-09)

• 영구 Git/배포 디렉터리 확정, CI 기본 파이프라인 구성
• PostgreSQL 마이그레이션과 초기 스키마 작성
• FastAPI 프로젝트, 환경변수 검증, 구조화 로그, request ID 추가
• 완료 기준: 빈 환경에서 마이그레이션·health check·롤백 성공

3주차: 신청·통계 API와 프런트 입력 (09-10~09-16)

• 신청 생성·조회·입력 검증 API 구현
• 통계 스냅샷 조회 API와 표본 부족 처리 구현
• 단계형 입력 폼, 초안 저장, 접근성 오류 표시 구현
• 완료 기준: API 계약 테스트, 주요 브라우저 폼 테스트, 잘못된 입력 100% 명시 처리

4주차: 모델 파이프라인·결과 화면 (09-17~09-23)

• 모델 레지스트리·버전 고정·Redis 작업 큐 구축
• 추론 워커, 타임아웃·재시도·실패 상태 구현
• 결과·설명·모델 한계 화면 구현
• 완료 기준: 동일 입력 재현성, 모델 버전 추적, 장애 시 성공 위장 없음

5주차: 담당자 검토·이의제기 (09-24~09-30)

• 담당자 큐, 배정, 결정 사유, 감사 이벤트 구현
• 이의제기 등록·상태·답변 흐름 구현
• 역할 기반 접근 제어와 민감 필드 마스킹 추가
• 완료 기준: 신청자·담당자·관리자 권한 매트릭스 테스트 통과

6주차: 데이터 파이프라인·모델 검증 (10-01~10-07)

• 수집 배치, 스키마·품질 검사, 비식별화 작업 구현
• 시간 분할 검증, 기준 모델과 비교, 캘리브레이션 측정
• 업종·지역·사업 연령별 성능·오류율·트랙 분포 분석
• 완료 기준: 데이터 품질 리포트, 누수 점검, 모델 승인 체크리스트

7주차: 보안·성능·운영 검증 (10-08~10-14)

• rate limit, CORS allowlist, CSRF 방어, 입력 크기 제한 점검
• 부하·장애주입·복구·백업 복원 테스트
• 지연·오류·드리프트·감사 로그 대시보드 구성
• 완료 기준: 보안 점검 조치 완료, 목표 p95 지연·가용성 측정, 복구 시간 기록

8주차: 제한적 시범 운영·출시 판정 (10-15~10-21)

• 합성·비식별 데이터로 운영 리허설
• 담당자 교육, 사용자 안내, 이의제기 처리 리허설
• 시범 사용자 피드백과 오류 수정
• Go/No-Go 회의: 안전·정확도·운영·법무 기준 모두 충족할 때만 확대

8. 단계별 검증 방법

• 단위 테스트: 입력 정규화, 위험 트랙 경계, 통계 계산, 권한 규칙
• 계약 테스트: OpenAPI 스키마, 상태 코드, 오류 응답, idempotency
• 통합 테스트: 신청→큐→추론→담당자 검토→이의제기 전체 흐름
• E2E 테스트: 모바일·데스크톱 주요 브라우저와 접근성 키보드 시나리오
• 모델 테스트: 시간 분할 holdout, 재현성, calibration, subgroup 성능, drift
• 보안 테스트: 인증 우회, 수평 권한 상승, SQL injection, XSS, CSRF, 비밀정보 노출
• 운영 테스트: 워커 중단, DB 장애, 큐 지연, 재시작, 백업 복원, 중복 요청
• 사용자 검증: 담당자가 결과를 오해하지 않는지, 이의제기 경로를 찾을 수 있는지 사용성 평가

정량 출시 기준은 임의로 정하지 않고 1주차에 업무 위험도와 규제 검토를 바탕으로 확정한다. 모든 모델 결과에는 최종 결정이 아니라는 표시를 유지하며, 자동 승인·거절을 출시 기준에 포함하지 않는다.

9. 리스크와 의존성

가장 큰 의존성은 합법적으로 사용할 수 있고 대표성을 갖춘 학습·검증 데이터다. 데이터가 부족하면 통계 비교와 모델 출력을 제한하고, 표본 수를 표시한 체험 모드로 유지한다. 모델 성능이 subgroup별로 크게 다르면 배포를 중지하고 데이터 보강·모델 재설계 후 재검증한다. 금융 민감정보의 외부 전송, 인증서·키 관리, 운영 담당자 확보도 출시 전 차단 조건이다.

결론

8주 계획은 먼저 계약·안전·데이터 기준을 세운 뒤 API와 화면, 모델 파이프라인, 사람의 검토, 운영 검증을 순차적으로 연결한다. 이 순서를 지키면 현재의 브라우저 데모를 추적 가능하고 검증 가능한 의사결정 보조 플랫폼으로 확장할 수 있다. 단, 데이터 대표성·법적 근거·담당자 검토가 확보되지 않는 한 실제 금융 의사결정 자동화로 확대하지 않는다.