채용 플랫폼은 거짓 구인광고를 게재 전에 어떻게 막아야 하나

채용 플랫폼에서 거짓 공고를 막는 일은 금칙어 몇 개를 추가하는 문제로 끝나지 않는다. 정상적인 채용을 지나치게 늦추면 구인자와 구직자가 다른 경로로 떠나고, 검증을 느슨하게 하면 거짓 공고가 노출된 몇 시간 동안에도 개인정보 탈취나 금전 요구 같은 피해가 생길 수 있다. 결국 필요한 것은 모든 공고를 똑같이 의심하는 전수 수사도, 신고가 들어올 때까지 기다리는 사후 삭제도 아니다. 위험 신호에 따라 확인 강도를 높이고, 노출 상태와 증거 상태를 분리하며, 긴급 중지 뒤에도 설명·이의제기·감사가 이어지는 운영 체계다.

이 설계를 시작하기 전에 법의 현재 상태부터 정확히 나눠야 한다. 2026년 6월 9일 공포된 법률 제21787호는 직업정보제공사업자에게 구인자 신원·기업정보와 직업정보의 허위·과장 여부를 모니터링·검증하도록 하고, 신원이나 정보가 확실하지 않은 광고와 근무지가 불확실한 국외 취업 광고를 게재하지 않도록 정했다. 고용노동부장관이 거짓 구인광고의 수정, 게시 중지 또는 삭제를 명할 근거도 신설했다. 이 개정 법률은 2026년 12월 10일 시행 예정이며, 조치명령 조항은 시행 이후 게시하거나 게시를 의뢰한 광고부터 적용된다.[1]

반면 검증 방법, 조치명령 절차, 권한 위임 같은 세부 규칙은 아직 확정된 시행령·시행규칙이 아니다. 고용노동부는 2026년 9월 22일부터 하위법령 개정안을 입법예고했고, 의견 제출 마감은 2026년 11월 2일이다.[2] 이 글의 기준일인 10월 23일에는 의견 제출 기간도 끝나지 않았다. 따라서 아래 상태 기계는 확정 법령의 필드를 옮긴 제품 명세가 아니라, 공포된 법률과 입법예고안을 바탕으로 플랫폼이 미리 준비할 수 있는 내부 운영 제안이다.

확정된 법률과 예고안, 미정 사항을 한 표에서 분리하기

입법예고된 시행규칙안은 사전 확인 대상을 무작정 모든 공고로 넓히지 않는다. 최근 6개월 안에 조치명령을 통보받은 구인자의 광고, 최근 6개월 안에 신고 검토 결과 허위·과장 가능성이 인정된 구인자의 광고, 유사 직종보다 현저히 높은 임금을 제시한 광고, 사회통념상 구직자를 현혹할 우려가 있는 표현을 담은 광고를 의심 사유로 제시한다. 플랫폼이 보유하거나 통상적으로 이용할 수 있는 자료로 게재 전 허위·과장 여부를 확인하고, 게시 뒤에도 상당한 의심 사유가 생기면 모니터링하도록 하는 구조다.[2][4]

여기서 “현저히 높다”의 구체적 산정 방식, “현혹할 우려가 있는 표현”의 운영 기준, 어떤 자료가 “통상적으로 이용할 수 있는 자료”인지, 자동 판정만으로 어느 조치까지 허용할지는 최종 문언과 집행 지침을 더 확인해야 한다. 시행 예정일이 정해졌다고 하위법령의 예고 문구까지 확정된 것은 아니다.

상태 기계의 원칙: 신뢰 점수 하나가 아니라 전이 근거를 남긴다

다음 상태명은 법률 용어가 아니다. 플랫폼의 제품·정책·고객지원·감사 팀이 같은 사건을 같은 뜻으로 다루기 위한 내부 상태다. 하나의 enum에 절차를 모두 넣지 않고 세 축으로 저장한다.

publication_state  = draft | published | suspended | deleted
verification_state = identity_pending | content_review | evidence_requested | verified | rejected
appeal_state       = none | pending | upheld | modified | accepted

예를 들어 긴급 중지는 publication_state=suspended로만 노출을 멈춘다. 검토 중이라는 이유로 verification_state를 거짓 확정으로 바꾸지 않는다. 이의제기 접수는 appeal_state=pending으로만 기록하며, 접수 자체가 publication_state를 published로 되돌리지 않는다. 독립 검토자가 accepted 또는 modified 결정을 내리고 새 공고 버전을 승인해야 별도 복구 전이가 발생한다.

핵심은 점수 하나로 곧바로 deleted에 보내지 않는 것이다. 모델 점수, 신고 횟수, 비정상적으로 높은 임금 같은 신호는 검토 우선순위를 정할 수 있지만 거짓이라는 최종 사실과 같지 않다. 반대로 구직자에게 중대한 피해가 예상되는 정황이 있다면 최종 판단을 기다리느라 노출을 계속해서도 안 된다. 노출, 검증 판단, 이의제기 처분을 독립 축으로 보존해야 한다.

1단계: publication_state=draft에서 공고와 계정을 먼저 분리한다

공고가 제출되면 플랫폼은 두 개의 식별자를 만든다. 하나는 수정될 때마다 버전이 늘어나는 ad_id이고, 다른 하나는 구인 주체를 가리키는 내부 recruiter_account_id다. 같은 계정이 여러 공고를 올릴 수 있고, 하나의 공고가 여러 차례 수정될 수 있으므로 둘을 섞으면 과거 신고나 조치 이력을 잘못 적용하기 쉽다.

이 단계에서 필수 입력은 공고 작성에 필요한 최소 범위로 제한한다. 업체명 또는 구인 주체 표시, 확인 가능한 연락 경로, 직종, 고용형태, 임금·근로시간 등 핵심 조건, 근무 지역을 구조화해 받는다. 국외 취업이라면 국가와 도시 수준의 근무지 확인이 중요하다. 자유서술만 받으면 서로 모순되는 조건을 기계적으로 비교하기 어렵고, 나중에 무엇이 바뀌었는지도 추적하기 어렵다.

구직자의 주민등록번호, 신분증 사진, 계좌정보를 공고 검증 명목으로 받아서는 안 된다. 지원자의 민감한 서류는 구인자 검증과 무관하다. 구인자의 신원을 확인할 때도 플랫폼이 원본 증명서를 장기 보관하는 방식보다, 권한 있는 출처에 확인 질의를 보내고 확인 성공, 확인 시각, 확인한 속성, 출처, 만료 시각만 남기는 방식을 우선해야 한다. 증거 최소화는 검증을 약하게 만드는 것이 아니라 유출됐을 때의 피해 반경을 줄이는 통제다.

2단계: verification_state=identity_pending은 실재 확인과 권한 확인을 나눈다

사업자가 실재한다는 사실과 공고를 올린 사람이 그 사업자를 대표할 권한이 있다는 사실은 다르다. 도메인 이메일을 쓴다는 이유만으로 채용 권한이 증명되는 것도 아니고, 무료 메일을 쓴다는 이유만으로 거짓 공고가 되는 것도 아니다.

따라서 최소 두 질문을 분리한다.

1. 구인 주체가 확인되는가. 업체명·성명 또는 사업자 관련 정보와 연락 경로가 서로 맞는가.
2. 게시 권한이 확인되는가. 제출자가 그 구인 주체를 대신해 공고를 만들고 수정할 권한이 있는가.

확인 실패의 원인도 NOT_FOUND, MISMATCH, SOURCE_UNAVAILABLE, AUTHORIZATION_UNPROVEN처럼 나눠야 한다. 외부 확인 서비스 장애를 곧바로 사기 판정으로 바꾸면 정상 공고를 대량 차단할 수 있다. 일시 장애는 재시도나 사람 검토로 보내고, 신원 불확실 상태에서는 공고를 공개하지 않는 방식이 안전하다. 개정 법률은 업체명·성명 또는 사업자등록증 등을 확인할 수 없거나 연락처가 사서함 등으로 표시돼 신원 또는 정보가 확실하지 않은 구인광고를 게재하지 않도록 정한다.[1]

3단계: verification_state=content_review는 위험기반으로 증거 요구를 늘린다

신원이 확인됐다고 공고 내용까지 참인 것은 아니다. 여기서는 구조화된 조건끼리의 모순, 같은 구인자가 낸 최근 공고와의 급격한 변화, 신고·조치 이력, 유사 직종의 임금 분포와 큰 차이, 과도한 고수익·즉시 채용 표현을 위험 신호로 쓴다. 입법예고안이 제시한 최근 6개월 이력과 고임금·현혹 표현도 후보 신호다.[2][4]

다만 위험 신호마다 같은 서류를 요구해서는 안 된다. 임금이 통상 범위보다 높다는 이유만으로 대표자 신분증 전체를 다시 받는 것은 관련성이 낮다. 임금 산정 근거가 문제라면 기본급·수당·성과급의 조건을 구조화해 확인하고, 근무지가 문제라면 사업장 또는 파견 장소의 존재와 채용 주체의 관계를 확인하는 편이 맞다. 필요한 속성만 확인하고 목적이 끝난 원본은 지체 없이 파기하며, 보관이 필요한 경우에도 접근권한과 만료일을 둔다.

검토 결과는 세 갈래로 보낸다.

• 근거가 충분하고 모순이 해소되면 verification_state=verified
• 설명이나 자료가 더 필요하면 verification_state=evidence_requested
• 신원이 확인되지 않거나 명백한 금지 조건이 남으면 verification_state=rejected

verification_state=verified는 정부가 진실을 인증했다는 표시가 아니다. “플랫폼이 정한 시점과 범위에서 확인 절차를 통과했다”는 제한된 상태다. 이용자 화면에서도 확인 범위와 확인 시각을 과장하지 않아야 한다.

4단계: publication_state=published 뒤에도 버전과 위험 상태는 살아 있어야 한다

공개 후 공고를 수정할 수 있다면 최초 검증만으로는 부족하다. 업체명, 직종, 고용형태, 임금, 근무지, 외부 지원 URL 같은 핵심 필드가 바뀔 때 새 버전을 만들고 위험도를 다시 계산해야 한다. 연락처의 오탈자 수정과 국내 근무지를 국외로 바꾸는 변경을 같은 수준으로 다뤄서는 안 된다.

게시 후 모니터링은 신고 수만 세는 방식에서 벗어나야 한다. 같은 사건을 복제한 신고, 경쟁자의 악의적 신고, 자동화된 대량 신고를 그대로 가중하면 조작에 취약하다. 신고 내용의 독립성, 구체성, 공고 버전과의 관련성, 기존 증거와의 일치 여부를 따로 기록해야 한다. 신고자에게는 고용주 이름이나 지원자의 신분증·계좌·건강정보 같은 개인정보를 자유서술로 올리도록 요구하지 말고, 문제 유형과 공고 내 해당 문구를 선택하게 해야 한다. 추가 자료가 꼭 필요할 때만 안전한 별도 채널과 보관기한을 안내한다.

5단계: 수정·중지·삭제를 위험과 확실성에 맞춰 분리한다

개정 법률은 고용노동부장관이 수정, 게시 중지 또는 삭제를 명할 수 있는 근거를 둔다.[1] 입법예고된 시행령안은 명령을 원칙적으로 문서로 하고, 당사자, 광고 식별정보, 명령 내용과 사유, 결과 제출 방법과 기한을 적도록 제안한다. 구직자에게 중대한 피해가 발생할 우려가 있어 긴급하면 말이나 전화로 먼저 명령하고 지체 없이 문서로 통지하는 절차도 제안돼 있다.[3]

플랫폼 내부 조치도 세 층으로 나누는 편이 좋다.

• 수정 요청: 오해를 낳는 표현이나 상충하는 조건을 특정 기한 안에 고치도록 요청한다. 위험이 낮으면 publication_state=published를 유지하며 정정 검토 중 표시를 붙일 수 있다.
• 긴급 중지: 금전 송금 요구, 외부 메신저로의 즉시 유도, 신원 도용 정황처럼 노출을 계속할 때 피해가 커질 수 있으면 publication_state=suspended로 바꾼다. 이것은 최종 위반 확정이 아니라 임시 보호조치다.
• 삭제: 확인된 거짓, 반복적인 불응, 유효한 삭제 명령처럼 복구보다 제거가 필요한 근거가 갖춰졌을 때 publication_state=deleted로 바꾼다.

긴급 전화 명령을 받은 상담원이 발신 번호만 믿고 삭제해서는 안 된다. 담당 기관과 명령 권한을 독립된 공식 연락 경로로 재확인하고, 받은 시각·수신자·광고 식별자·요청 조치·긴급 사유를 기록한 뒤 노출을 우선 중지한다. 예고안대로 뒤따르는 문서가 오면 구두 명령 기록과 연결하고 불일치가 있으면 즉시 에스컬레이션한다. 최종 시행령에서 절차가 달라지면 이 운영 규칙도 함께 바뀌어야 한다.

6단계: 이의제기는 긴급조치를 되돌리는 버튼이 아니다

오탐을 고칠 통로가 없으면 플랫폼은 정상 공고를 장기간 막고도 오류를 발견하기 어렵다. 반대로 이의제기를 접수했다는 이유만으로 위험한 공고를 자동 복구하면 긴급 중지의 목적이 사라진다.

appeal_state=pending에서는 최초 결정자와 다른 검토자가 당시 공고 버전, 사용된 위험 신호, 구인자가 낸 반박 자료, 외부 명령 여부를 다시 본다. 구인자에게는 가능한 범위에서 어떤 항목이 문제였는지, 어떤 자료로 반박할 수 있는지, 언제까지 결과를 받을 수 있는지 알려야 한다. 그러나 탐지 임계값이나 공격자가 우회에 쓸 세부 규칙까지 공개할 필요는 없다.

결과는 appeal_state=upheld|modified|accepted 가운데 하나로 남긴다. modified는 삭제 판단을 수정 요구로 낮추거나 계정 제한은 유지하되 특정 공고를 재검토 대상으로 보내는 경우다. accepted도 자동 복구 명령이 아니다. 결정에 따른 별도 복구 승인이 publication_state=suspended|deleted를 published로 전이해야 한다. 복구할 때는 기존 공고를 조용히 덮어쓰지 말고 새 버전을 발행해 무엇이 달라졌는지 감사 가능하게 해야 한다.

7단계: 감사 로그는 개인정보 창고가 아니라 결정의 계보여야 한다

좋은 감사 로그는 원본 서류를 무기한 쌓아 두는 저장소가 아니다. 최소한 다음을 연결한다.

감사자는 “모델이 0.91이라 삭제했다”가 아니라 어떤 신호와 자료가 어떤 정책 버전 아래서 결정을 만들었는지 재구성할 수 있어야 한다. 관리자도 과거 로그를 몰래 바꿀 수 없도록 추가 기록 방식과 변경 탐지를 두고, 조회 권한을 직무별로 제한한다. 동시에 법적·분쟁 대응에 필요한 기간이 끝난 자료는 정해진 일정에 따라 파기한다.

운영 지표도 차단 건수 하나로 끝내면 안 된다. 게시 전 검토율, 검토 대기시간, 게시 뒤 중지까지 걸린 시간, 실제 거짓으로 확인된 비율, 정상 공고 오탐률, 이의제기 인용률, 반복 위반률, 원본 증빙의 기한 내 파기율을 함께 봐야 한다. 피해 예방과 정상 채용의 접근성을 같은 대시보드에서 보지 않으면 팀은 가장 쉬운 숫자만 최적화하게 된다.

시행 전까지 준비하되, 예고안을 확정 규칙처럼 코딩하지 말 것

10월 23일 현재 플랫폼이 할 수 있는 준비는 분명하다. 공고와 계정 식별자를 분리하고, 핵심 조건을 구조화하며, 신원 확인과 게시 권한 확인을 나누고, 위험기반 검토·긴급 중지·이의제기·감사 로그를 연결할 수 있다. 법률에 이미 들어간 모니터링·검증과 불확실한 광고의 게재 금지, 수정·중지·삭제 명령 수신 경로도 준비할 수 있다.[1]

하지만 하위법령안의 최근 6개월 기준, 의심 사유, 명령 서식, 권한 위임, 행정처분 기준은 11월 2일까지 의견을 받는 단계다.[3][4] 의견 수렴 뒤 문구가 바뀔 수 있고, 최종 공포 시점·고시 세부사항·기관 간 연계 규격·플랫폼별 적용 범위와 실무 해석은 아직 확인할 부분으로 남는다. 제품팀은 이 값을 코드에 고정하지 말고 버전이 있는 정책 설정으로 관리해야 한다.

거짓 구인광고 대응의 목표는 “AI가 사기를 판정했다”는 화려한 배지가 아니다. 의심 공고가 공개되기 전에 필요한 만큼만 확인하고, 위험하면 즉시 노출을 멈추며, 잘못된 판단은 독립적으로 고치고, 모든 결정을 나중에 설명할 수 있게 만드는 것이다. 상태 기계는 그 책임을 자동화에 넘기는 장치가 아니라, 자동화와 사람, 플랫폼과 행정기관 사이의 책임 경계를 보이게 하는 장치여야 한다.

이 글은 공포 법률과 입법예고 자료를 바탕으로 한 플랫폼 운영 설계 제안이며, 특정 사업자나 사건에 대한 법률 자문이 아니다. 실제 적용 전에는 최종 공포된 시행령·시행규칙·고시와 관계 기관의 최신 안내, 해당 서비스의 법적 지위를 함께 확인해야 한다.

Sources

[1] https://www.law.go.kr/LSW/lsRvsDocListP.do?chrClsCd=010202&lsId=001765&lsRvsGubun=all [2] https://www.moel.go.kr/news/enews/report/enewsView.do?news_seq=19989 [3] https://opinion.lawmaking.go.kr/gcom/ogLmPp/88798 [4] https://opinion.lawmaking.go.kr/gcom/ogLmPp/88726