문제: 앞단 스크리닝은 좋은데 ‘정본’이 갱신되지 않음

점수는 벤더 UI에만 있고 ATS 상태는 ‘신규’에 머물며, 메모는 개인 시트에 흩어집니다. 연동은 API 스위치가 아니라 상태·필드·권위·보관을 정본 시스템에 맞추는 프로젝트입니다.

흔한 실패 패턴

• 기능별로 다른 상태 해석 — 공통 상태 머신 부재.
• 같은 필드명, 다른 의미(HR 코어 vs 스크리닝 툴).
• 과도한 내보내기 권한과 병렬 스프레드시트.
• 운영으로 실행 불가능한 보존 정책.

설계 패턴: 상태 먼저, 매핑 다음

허용 전이 정의

지원→트리아지→구조화 스크린→부서 면접→합격/불합→종료까지 유효 전이, 담당, SLA를 정하고 불일치 점프는 막습니다.

필드 매핑·골든 소스

점수 상세, 미디어 링크, 평가자 ID 등 각 요소의 권위 시스템과 충돌 해결 규칙을 문서로 합의·서명합니다.

역할과 로그

최소 권한, 민감 접근 로깅, 발령·이동 시 권한 자동 회수를 설계합니다.

도입 단계

1. 시스템과 수동 재작업 핫스팟을 목록화합니다.
2. API 한도·재시도·멱등성을 IT/벤더와 확인합니다.
3. 한 직무 유형으로 ATS 필수 write-back 파일럿을 합니다.
4. 품질을 측정합니다: 결측 필드, 쓰기 지연, 멈춘 상태.
5. 분기별 매핑 검토; 정책·계약 변경 시 즉시 반영합니다.

리스크

통 후보 내보내기를 통제되지 않은 단말로 유도하지 마세요. 처리위탁·DPA를 프로그램에 맞춥니다. 규제 맥락은 감사 대응 글과 병행 — 법률 자문 아님.

다지점·컴플라이언스와의 일체화

글로벌 채용은 역할 일관성·데이터 상주 이슈가 있습니다. 정식 론칭 직전에만 묶지 말고 요구사항 정의부터 같은 타임라인으로 움직이세요.

체크리스트

• 소유자가 있는 공개 상태 머신이 있는가?
• 승인된 매핑 문서가 있는가?
• 쓰기 성공·지연 지표가 있는가?
• 발령 후 접근 검토가 자동화/감사 가능한가?
• 삭제·보관 런북이 실행 가능한가?