일괄등록 사전 면접자 선별 설계안

1. 컨펌

현재 코드베이스 기준으로 “문서 일괄등록 미리보기 단계에서 지원자 기본정보와 문서 데이터를 기반으로 1차 면접자 선별”을 붙이는 방향은 가능하고, 구조적으로도 적합하다.

이유:

DocumentBulkImportService가 이미 preview job에서 파일 staging, 텍스트 추출, 지원자 프로필 추론, 중복 검사, row 상태 산정을 수행한다.
preview 결과는 AiJob.result_payload.rows에 저장되고, CandidateDetailPage.tsx가 polling으로 조회해 CandidateDetailModal.tsx에 전달한다.
즉, 확정 저장 전에도 row 단위로 충분한 데이터가 존재하므로 screening_preview 결과를 row에 붙이면 일괄등록된 지원자 후보를 저장 전에 선별/검토할 수 있다.
확정 저장 시에는 HR이 선택한 row만 candidate/document로 생성하므로, “선별된 후보만 등록” 또는 “전체 등록하되 선별 결과 보존” 중 하나를 선택할 수 있다.

권장 UX는 전체 preview row를 보여주되, AI 추천 후보를 기본 선택 상태로 제안하는 방식이다. AI가 자동으로 탈락 처리하거나 저장 대상에서 강제 제외하면 위험하므로, 최종 선택은 HR 담당자가 한다.

2. 현재 흐름

현재 문서 기반 일괄등록 흐름:

ZIP/다중 파일 업로드
→ AiJob(DOCUMENT_BULK_IMPORT) 생성
→ 파일 staging
→ 문서 텍스트 추출
→ 지원자 기본정보 추론
→ 중복/필수값 검증
→ preview row 생성
→ CandidateDetailModal에서 미리보기 표시
→ HR이 선택 row 확정
→ candidate/document 저장

추가할 흐름:

문서 텍스트 추출
→ 지원자 기본정보 추론
→ 사전 면접자 선별 평가
→ screening_preview를 preview row에 저장
→ 추천/보류/비추천 상태를 미리보기에서 표시
→ 추천 후보를 기본 선택
→ HR이 최종 선택 row 확정
→ candidate/document 저장
→ 저장된 후보 상세/목록에서 선별 결과 조회

3. 적용 위치

Backend

위치	변경 방향
`backend/services/document_bulk_import_service.py`	`_build_preview_row()`에서 profile/documents 생성 후 `screening_preview` 산정
`backend/schemas/candidate.py`	`DocumentBulkImportPreviewRow`에 `screening_preview` 필드 추가
`backend/models/ai_job.py`	기존 `DOCUMENT_BULK_IMPORT` preview job의 `result_payload`에 screening preview 포함
신규 모델	MVP에서는 추가하지 않음. 기존 `AiJob.result_payload`와 `AiJob.candidate_id`를 재사용

Frontend