feat(talent-acquisition): 채용서류 반환·파기·인재풀·입사/퇴사 기록 보존 정책

[seonghobae]

Buyer problem

Orgmetra needs a jurisdiction-aware lifecycle for candidate and worker documents. “채용 개인정보”를 한 보관기간으로 묶으면 서로 다른 법적 목적과 DDD 소유권이 섞인다. 최소한 다음 네 흐름을 분리해야 한다.

1. 불합격자/미채용자의 채용서류 반환·보관·파기
2. 별도 목적의 인재풀 등록과 철회/만료
3. 최종 합격자의 candidate → worker 전환 때 실제 입사·고용기록으로 승계할 자료
4. 퇴직 후 법정 보존기간이 있는 근로자 명부·계약/고용 관련 기록과 그 기간 종료 후 파기

이 issue는 법률문구를 코드에 하드코딩하는 작업이 아니라, 법적 근거·목적·관할·기산점·보존/반환/파기 의무를 versioned policy로 표현하고 각 bounded context가 자기 truth만 소유하게 만드는 제품/도메인 작업이다.

Current Korean authority — verified 2026-09-11

채용절차법

채용절차의 공정화에 관한 법률은 원칙적으로 상시 30명 이상 사업/사업장의 채용절차에 적용하고(제3조), 제11조는 채용 확정 후 미채용자가 반환을 청구하면 본인확인 후 채용서류를 반환하도록 한다. 홈페이지/전자우편 제출 또는 구인자 요구 없이 자발적으로 제출한 경우에는 반환의무 예외가 있다. 반환 청구에 대비한 보관 후 청구기간이 지나거나 반환하지 않은 채용서류는 개인정보 보호법에 따라 파기해야 하며, 반환 관련 절차를 채용 확정 전에 알려야 한다.

시행령은 반환 청구를 받은 날부터 14일 이내 반환(제2조), 미청구 서류는 구인자가 정한 반환 청구기간까지 보관(제3조), 반환 청구기간은 채용 여부 확정일 이후 14일부터 180일까지 범위에서 정하고 확정 전에 고지(제4조)하도록 한다.

• 법 제3조·제11조: https://www.law.go.kr/LSW/lsInfoP.do?ancYnChk=0&lsId=011990
• 시행령 제2조: https://www.law.go.kr/LSW/lsSideInfoP.do?docCls=jo&joBrNo=00&joNo=0002&lsiSeq=209867&urlMode=lsScJoRltInfoR
• 시행령 제3·4조 구조 확인: https://www.lawmaking.go.kr/lmSts/govLm/2000000106350/detailRP

중요: 전자 제출이 “반환” 예외라는 사실을 보존기간 무제한 근거로 사용하지 않는다. 반환 workflow와 개인정보 보유/파기 workflow를 분리한다.

개인정보 보호법

2026-09-11 시행 법률 제21445호를 기준으로 한다. 제15조는 동의, 법령상 의무, 계약 체결 과정, 정당한 이익 등 법정 근거 안에서 수집·이용하도록 하고, 제18조는 목적 범위를 넘는 이용을 원칙적으로 제한한다. 제21조는 보유기간 경과·목적 달성 등 개인정보가 불필요해지면 지체 없이 파기하고, 다른 법령 때문에 보존해야 하는 경우에는 다른 개인정보와 분리 저장·관리하도록 한다.

• 2026-09-11 시행 개정법 확인: https://www.law.go.kr/LSW/lsInfoP.do?lsiSeq=283839&viewCls=lsRvsDocInfoR
• 제15조: https://law.go.kr/lsLinkCommonInfo.do?ancYnChk=&chrClsCd=010202&lsJoLnkSeq=1020398481
• 제18조: https://law.go.kr/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1020398985
• 제21조: https://www.law.go.kr/LSW/lsSideInfoP.do?docCls=jo&joBrNo=00&joNo=0021&lsiSeq=270351&urlMode=lsScJoRltInfoR

인재풀은 원래 지원한 특정 채용의 심사와 별도 목적일 수 있으므로 “지원했으니 자동 등록”하지 않는다. 목적·법적근거(필요 시 별도 동의)·항목·보유기간·철회/삭제 효과를 versioned evidence로 남기고, 기간 만료/철회 후 다른 보존근거가 없으면 파기 대상으로 전환한다. 당초 목적과 합리적으로 관련된 이용 여부를 제품이 임의로 추정해 자동 재사용하지 않는다.

입사자·퇴직자 기록

근로기준법 제42조는 근로자 명부와 대통령령상 중요한 근로계약 관련 서류를 3년간 보존하도록 한다. 시행령 제22조는 근로계약서, 임금대장, 임금 결정·지급 및 계산 기초 서류, 고용·해고·퇴직, 승급·감급, 휴가 등 대상과 기산점을 구분한다. 2026년 고용노동부 노무관리 가이드도 법정 3년 보존자료는 개인정보라는 이유로 조기 파기해서는 안 되고, 법정기간 종료 뒤에는 개인정보보호법에 따른 파기 등 조치를 해야 한다고 설명한다.

• 근로기준법 제42조: https://www.law.go.kr/법령/근로기준법
• 시행령 제22조 현행 구조: https://www.law.go.kr/법령/근로기준법시행령
• 고용노동부 2026 노무관리 가이드북의 계약서류 보존 해설을 acceptance 근거로 사용하고, 실제 구현 PR에서는 exact publication artifact/date를 TRACEABILITY에 고정한다.

“지원서 전체를 입사자 인사카드로 3년 보관” 같은 단순 규칙은 금지한다. 채용 evidence 가운데 실제 근로자 명부/고용·계약 기록으로 승계할 법적·업무상 근거가 있는 최소 데이터만 People 쪽으로 materialize하고, 나머지 candidate evidence는 원래 retention/disposition 정책을 따른다.

DDD ownership / Context Map

talent_acquisition — candidate/recruiting truth

• Candidate/Application/Requisition 및 채용 여부 확정 시점
• CandidateDocumentDisposition 또는 동등 aggregate: 반환대상 여부, 반환 청구기간, 청구/발송/전달/파기 상태, jurisdiction/applicability policy reference
• TalentPoolEnrollment: 별도 목적·법적근거/동의 버전·granted_at·expires_at·revoked_at·허용 항목/범위
• 최종 합격 시 candidate → worker conversion command와 승계 대상 classification
• 채용서류 반환 예외가 개인정보 파기 예외로 승격되지 않는 invariant

people_core — worker/employment truth

• confirmed-hire 이후 Worker/Employment 및 법정 인사기록 분류
• candidate evidence 전체를 복사하지 않고 승인된 최소 필드/문서 reference만 materialize
• 근로자 명부·고용/퇴직 등 statutory record category와 해당 보존정책 reference
• 퇴직/해고/사망 등 법정 보존 기산 사건의 authoritative employment event

document_records — artifact lifecycle owner

현행 ARCHITECTURE의 “canonical document/image artifact objects and their retention/export/delete lifecycle” 소유권을 유지한다. raw resume/certificate/document bytes를 다른 context DB로 복사하지 않는다.

• immutable artifact identity/hash/provenance
• hold/return/export/delete disposition 실행
• retention_policy_version, retention_anchor_event, retain_until, legal_hold/equivalent controls
• 반환 완료 또는 파기 완료 receipt
• 파기 시 복구 불가능성 evidence와 backup/replica 처리 정책

talent_acquisition/people_core는 document lifecycle을 cross-service SQL로 조작하지 않고 released API/event/ACL로 disposition을 요청한다.

Audit / high-impact evidence

법정 감사 evidence는 raw PII를 영구 보존하는 우회로가 아니다. audit row에는 policy/version, actor, purpose, timestamps, artifact opaque reference/digest, disposition result 등 필요한 최소 증거만 남기고 raw 채용서류가 파기된 뒤 재구성할 수 없게 한다.

Required state/invariants

• applicability는 tenant/company size/jurisdiction/effective date를 입력으로 하는 versioned policy다. “한국이면 모두 14~180일” 같은 전역 상수 금지.
• 반환 청구기간 시작점은 hiring_decision_finalized_at; 임의 upload time 기준 금지.
• 채용절차법 반환대상/전자제출 예외와 PIPA retention/deletion decision을 별도 상태로 계산한다.
• 반환 요청이 들어오면 본인확인과 immutable request receipt 후 법정 SLA를 계산하며, 반환/전달 완료 전에는 파기하지 않는다.
• 기간 만료 시 legal hold 또는 별도 법적 보존근거가 없으면 delete disposition을 idempotent하게 발행한다.
• 인재풀 등록은 opt-in/별도 lawful-basis evidence 없이 자동 생성하지 않는다. 철회·만료가 실제 검색/추천 eligibility에서 즉시 제외되고 deletion workflow로 이어져야 한다.
• confirmed hire는 candidate document 전체를 Employee record로 재분류하지 않는다. field/document 단위 purpose transition과 최소 승계를 요구한다.
• 법정 보존 대상은 조기 deletion에서 fail closed하고, 법정기간 종료 뒤 별도 근거 없이 계속 보존하는 것도 fail closed한다.
• litigation/legal hold는 원래 retention을 덮어쓰는 명시적 별도 policy/evidence이며 hold 해제 후 재평가한다.
• immutable audit와 backup 때문에 “논리 삭제만 하고 영구 복구 가능” 상태가 생기지 않도록 cryptographic erasure/backup expiry 또는 동등 recovery-aware deletion semantics를 ADR에 명시한다.

Acceptance scenarios

1. 미채용·종이 서류·반환 청구 없음: 적용대상 사업장, final decision 이후 tenant가 고지한 14~180일 범위 정책까지 보관 → 만료 후 PIPA 파기 receipt.
2. 미채용·반환 청구: 본인확인된 request → 14일 SLA → 발송/전달 receipt → retained artifact disposition 종료.
3. 전자 제출: physical-return workflow는 비대상이어도 채용 목적 종료 후 retention/legal-basis 평가와 파기는 계속 작동.
4. 인재풀 opt-in: 특정 채용 종료 뒤에도 별도 versioned purpose/lawful-basis와 expiry가 있을 때만 검색 가능. 미동의/철회/만료자는 추천 query에서 제외되고 delete/review queue로 진입.
5. 최종 합격: worker materialization은 승인된 최소 employment records만 People로 승계. 불필요한 portfolio/resume evidence는 candidate retention 정책에 남음.
6. 퇴직자: 근로자 명부/근로계약/고용·퇴직 등 각 record category의 법정 기산점으로 3년 retention을 계산하고, 기간 중 삭제 요청은 법정 보존근거를 표시해 거절/제한; 만료 후 hold가 없으면 파기.
7. 법령/정책 버전 변경: 새 policy는 새 사건에 적용하고, 기존 disposition은 effective-date/jurisdiction rule에 따라 재평가 여부를 명시적으로 결정. 과거 receipt를 rewrite하지 않음.
8. 복구 테스트: 파기 완료 artifact가 normal DB뿐 아니라 search index/cache/export queue/restore rehearsal 경로에서 buyer-visible content로 되살아나지 않음을 검증.

Delivery / evidence

• ADR: candidate-document disposition + worker-record retention Context Map, 법적 근거와 기각 대안 포함
• PRD/TRD/DATA_MODEL/UML/SECURITY/THREAT_MODEL/OPERABILITY/TRACEABILITY current화
• DB는 policy/evidence/receipt를 3NF로 분리하고 aggregate transaction을 최소화; 장시간 외부 반환/삭제/LLM 연산 중 explicit DB lock 금지
• async disposition worker는 idempotency key/UPSERT, retry/compensation, outbox, dead-letter/recovery evidence를 갖춤
• KO/EN/JA/ZH/VI/ES/DE/FR UI가 생기면 반환 요청/인재풀 동의·철회/retention explanation의 normal/loading/empty/error/permission/a11y를 E2E 검증
• current-head PostgreSQL/E2E 및 purpose-bound authorization/RLS tests; tenant A candidate/document를 tenant B가 반환·보존·삭제할 수 없어야 함
• 법률 문구/기간은 코드 상수 하나로 숨기지 않고 source citation/effective date가 있는 versioned jurisdiction policy로 관리

이 issue는 법률자문을 제품 코드가 대체한다는 의미가 아니다. 다만 현재 법령에서 이미 명확한 반환·파기·법정 보존 구조는 executable policy/acceptance로 구현하고, 회사별 적용범위·legal hold·추가 산업규제처럼 사실관계/법률판단이 필요한 부분만 policy approval gate로 남긴다.

[seonghobae]

Fresh protected-tree implementation audit after ADR PR #306 identifies an important owner-path prerequisite before the executable disposition slice.

Protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f has only services/job-analysis-api and services/people-api; there is not yet a talent_acquisition runtime service. The existing packages/candidate-evidence package is explicitly a reference-only intake/correlation contract: it carries a retention-policy reference but deliberately does not own raw document persistence, return/delete execution, candidate-to-worker conversion, or artifact lifecycle. Protected ARCHITECTURE.md assigns canonical document/image retention/export/delete lifecycle to document_records and prohibits cross-context application-table SQL. Therefore the next implementation must not grow candidate-evidence into a hidden disposition service or copy artifact bytes/state into Talent/People.

Recommended dependency order after #306's Proposed ADR becomes protected truth (or as an explicit dependent Draft stack that does not claim protected authority):

1. establish the talent_acquisition disposition application/aggregate boundary for policy applicability, return eligibility/request state, talent-pool purpose evidence, and candidate-side disposition intent/receipts;
2. define the released/versioned document_records ACL used to request return/export/delete/hold and consume immutable lifecycle receipts; raw artifact lifecycle remains document_records-owned;
3. keep confirmed-hire minimum-materialization as an explicit talent_acquisition -> people_core command/ACL rather than reclassifying the whole application or reading People tables;
4. only then add PostgreSQL owner schema/RLS/outbox/idempotency and async disposition execution, followed by UI/API paths.

Repository CI is also a sequencing constraint, not permission to bypass ownership. Current Foundation explicitly enumerates each package/service test invocation rather than package-neutrally discovering new owners. A new package/service therefore needs canonical Foundation admission/provenance rather than an untested directory or a resurrected leaf workflow; do not piggyback disposition semantics into candidate-evidence merely to avoid that admission work.

Acceptance for the first executable slice should remain policy/evidence-oriented and side-effect-free: tenant/jurisdiction/company-size/effective-date applicability; independent return-vs-retention decisions; exact policy/version/effective dates; no global Korean 14–180-day constant; no raw PII/document bytes; and no positive delete/return authority until the released document_records ACL exists. This keeps #303's DDD truth intact while #306's central Noema availability incident is repaired independently.

[seonghobae]

Implementation status update: PR #307 has been repaired into a dependency-first Draft rather than treating ADR 0303 as already shipped. It now targets exact #306 ddd76f85... and non-force adopted that parent. Review found and repaired three packet-integrity gaps: claim windows could end at/before hiring_decision_finalized_at; legal hold did not block the two specific destruction states; and the advertised frozen dataclass could be rewritten after validation through object.__setattr__. Test-first ae887b16... captures all three; current successor 16027eeda1259c89048b2b3eb7a4190c09165527 enforces claim-window ordering, all-destruction legal-hold denial, tuple-backed structural immutability, and required public docstrings. A separate acceptance blocker remains canonical Foundation ownership: predecessor #307 Foundation 34587627179 was GREEN without executing the new package because protected Foundation has an explicit package list. That false-green is handed to #258/#259. Required order is #306 + canonical Foundation owner normal protected integration -> #307 non-force adoption of fresh protected truth -> exact-head package coverage/security/review -> later document_records ACL/persistence worker slices. No candidate package is being promoted to document lifecycle authority.

[seonghobae]

Executable child #307 remains correctly stacked on Proposed ADR #306 rather than treating unmerged policy as protected truth. Current ordinary-forward source lineage now also hardens runtime evidence: exact built-in trust-bearing text (f589d1ef... -> 76f7b601...) and non-executable nested timezone evidence (d41523b6... -> 15d6dcac...). These changes do not move artifact lifecycle authority into talent_acquisition: the packet remains disposition intent/evidence only; document_records still executes hold/return/export/delete and supplies completion receipts. #306 must integrate normally first, then package-neutral Foundation #258/#259 must become protected truth, then #307 non-force adopts fresh develop and reacquires exact-head tests/coverage/security/review. No predecessor GREEN or stale Noema approval transfers.

[seonghobae]

#307 child audit에서 Issue acceptance와 source를 대조해 반환 완료 증거 누락을 실제 코드로 보강했습니다. 기존 packet은 return_dispatched/return_destroyed를 timestamp 없이 만들 수 있었고, ADR 0303이 명시한 deliver 단계도 아예 없었습니다. Test-first 1600812021e7a17ff9c016b22f3ac3705a889f64 → 70ef86a1dfeafc955cf1e1408e9c97b3278c9b3e로 dispatch 완료 state에 decision 이후 dispatch evidence를 요구했고, test-first 61bf81afdcdf758fe5006885a4bb8b17e7f20b28 → 4c1322b0619c4294e59bcd7755ee22fe83ef2215로 return_delivered/return_delivered_at을 추가해 delivery가 dispatch보다 앞서지 못하고 return_destroyed가 delivery receipt 없이 성립하지 못하게 했습니다. 기존 broad state fixture도 causal evidence를 제공하도록 45128373.../b1a2d15e...에서 current화했습니다. 이 receipt는 여전히 document_records의 실제 artifact lifecycle completion을 대체하지 않고, talent_acquisition packet은 검증된 intent/evidence transport 경계에 머뭅니다.

[seonghobae]

Implementation authority update from #307 exact 3af683009667f0c54f71c3e7ecc5dc6c83f9aaf3.

The CandidateDocumentDisposition packet now enforces the return lifecycle in both directions: later states require predecessor request/verification-SLA/dispatch/delivery receipts, and earlier states reject future-stage receipts. Test-first 445b707... captured the contradictory earlier-state/future-evidence cases; bda89e0... implements the minimal state/evidence envelope. Audit then found the predecessor return_due_at and return_claim_window_open requirements had left broad fixtures stale; 2ecff0b... and bc16dda... align due/claim-window evidence and canonical JSON coverage.

A second contradiction was executable: legal_hold_suspended could be emitted with legal_hold=False. Test-first 887ab342... plus 2fd12e5f... now bind that state to an active hold; 3af683... updates the broad state matrix accordingly. Existing fail-closed destruction-under-hold behavior remains separate.

These rules do not turn SLA misses into invalid events: actual late dispatch/delivery remains factual evidence and should receive a separate compliance outcome. #307 remains Draft on #306 until ADR 0303 and package-neutral Foundation #258/#259 are protected truth; no predecessor CI is being transferred.

[seonghobae]

구현 상태 갱신: dependent Draft #307 exact b0add8173ef5303c76d37fbeb02fe6e47fafa985에서 statutory_retained / statutory_retention_expired_destroyed가 policy boundary 없이 생성되던 gap을 수리했습니다. 0bb11541...이 두 상태의 statutory_retain_until 부재를 RED 계약으로 고정하고, 3c61995f...가 non-null normalized deadline을 요구하며, b0add817...이 broad state fixture를 같은 invariant에 맞춥니다. 법정기간 숫자는 package에 하드코딩하지 않으며 jurisdiction/category/effective-date별 versioned policy가 deadline을 계산한다는 #303/#306 경계를 유지합니다. #307은 계속 #306 위 Draft stack이고, #306 통합 및 package-neutral Foundation #258/#259 protected integration 뒤 fresh develop을 non-force adopt해 exact-head acceptance를 다시 받아야 합니다.

[seonghobae]

#307 current implementation authority is now fdda3d8039e38904fa33dcc079d8b6e5d523fe43. Fresh review findings were repaired ordinary-forward: d94b4e78... adds pre-request/return-request future-evidence regressions, 294394ff... repairs the statutory-destruction legal-hold fixture so the intended gate is reached, and fdda3d8... closes _RETURN_PRE_REQUEST_STATES over request/verification/SLA/dispatch/delivery evidence. CodeRabbit rechecked and resolved all three current threads; hosted GREEN is still not claimed because #307 is correctly stacked on #306.

A separate owner gap was also verified: #307 can name return_destroyed, statutory_retention_expired_destroyed, and destroyed, but protected develop has no released/versioned document_records completion-receipt contract. Issue #303/ADR 0303 already assign return/delete execution and completion receipts to document_records; local timestamps cannot prove authoritative destruction completion. Canonical owner issue #308 now owns immutable return/destruction receipt + recovery-aware deletion evidence. #307 remains Draft and may not claim completed destruction as integration-ready until it consumes the released #308 contract/ACL by exact version. No leaf-local schema/cross-service SQL/source copy workaround.