HackerRank 오픈소스 ATS, 같은 이력서 점수가 90점·74점·88점으로 흔들리는 문제

HackerRank가 깃허브에 공개한 오픈소스 ATS(지원자 추적 시스템) hiring-agent가 LinkedIn과 Reddit에서 화제를 모은 가운데, 같은 이력서를 같은 명령으로 100회 반복 실행했더니 점수가 66점부터 99점까지 33점 폭으로 흔들렸다는 실험 결과가 공개됐다. 회사의 컷오프가 85점이라면 같은 이력서를 제출한 지원자가 65% 확률로 탈락하는 셈이다. 4B 파라미터짜리 gemma3:4b 모델을 temperature 0으로 낮춰도 비결정성은 사라지지 않았고, Gemini로 교체해도 60점 컷오프에서 28%가 탈락했다. LLM 기반 이력서 스크리닝의 본질적 불안정성을 잘 보여주는 사례다.

같은 이력서가 매번 다른 점수를 받는 이유

실험자는 디버그용 출력문을 제거한 뒤 같은 이력서와 같은 명령으로 hiring-agent를 다시 실행했고, 첫 실행에서는 90/100점이었던 점수가 74/100점으로 떨어졌다. DEVELOPMENT_MODE를 비활성화하고 100회 반복 실행하자 점수 범위는 66~99점까지 벌어졌다. 85점 컷오프라면 같은 이력서를 가진 지원자가 65% 확률로 탈락한다.

이 ATS는 PDF 이력서를 텍스트로 파싱한 뒤 LLM을 6번 호출해 기본 정보, 경력, 학력, 기술, 프로젝트, 수상 내역을 구조화하고, GitHub 프로필과 상위 저장소까지 스캔해 추가 맥락으로 붙인다. 점수는 100점 만점에 보너스 20점이 추가되는 구조다. 오픈소스 기여 35점, 개인 프로젝트 30점, 업무 경험 25점, 기술 스킬 10점이 기본이고 스타트업 경험, 포트폴리오 사이트, 기술 블로그 등에 최대 20점 보너스가 붙는다.

# hiring-agent 평가 구조 (요약)
sections = ["basic_info", "experience", "education",
            "skills", "projects", "awards"]
for s in sections:
    score[s] = llm_call(resume[s])  # 6번의 LLM 호출
score += github_scan(username)      # GitHub 프로필 추가
total = sum(score.values()) + bonus  # 100 + 20

일관적인 항목과 흔들리는 항목

기술 스킬 항목은 100회 중 98회에서 8/10점이 나와 거의 일관적이었다. React 같은 기술 보유 여부는 체크리스트에 가까워 LLM의 주관적 판단 여지가 작기 때문이다. 반면 프로젝트 항목은 실행마다 판단이 크게 갈렸다. 어떤 실행에서는 "아키텍처 복잡성이 부족함"으로 평가되고, 다른 실행에서는 "실제 배포를 보여줌"으로 평가됐다. temperature 0.1은 낮은 설정이지만, temperature 0으로 낮춰도 문제가 사라지지 않았다. 2025년 10월에 열린 GitHub 이슈에서도 temperature 0에서 6회 연속 점수가 27, 34, 32, 34, 34, 30으로 달랐다.

| 평가 항목 | 100회 점수 변동 | 일관성 |

|---|---|---|

| 기술 스킬 | 8/10 × 98회 | ✅ 거의 일정 |

| 프로젝트 | 66~99점 폭 | ❌ 큰 변동 |

| 경력 (인턴 1개) | 25/25 × 100회 | ⚠️ 일관적이나 무의미 |

| 오픈소스 기여 | 분포 좁음 | ✅ 비교적 일정 |

| GitHub 보너스 | 변동 큼 | ❌ 환각 발생 |

모델을 바꿔도 남는 불안정성

gemma3:4b가 로컬 모델이라는 점 때문에 모델 영향도 함께 확인됐다. Gemini를 사용하자 점수 분포는 48~64점으로 더 좁아졌지만, 컷오프가 60점이면 지원자는 자신의 이력서 내용과 무관하게 28% 확률로 탈락했다. 오픈소스 점수는 더 일관적으로 바뀌었지만, 프로젝트 점수는 여전히 크게 흔들렸다.

경력 항목의 반대 문제도 드러났다. 인턴십 하나만 있는 예전 이력서도 25/25점을 받았고, 평가 프롬프트의 Production 항목은 두 줄뿐이었다. work와 volunteer 섹션에서 실제 업무, 인턴십, 프로덕션 경험을 분석하고, 창업자/공동창업자/스타트업 초기 엔지니어 역할에 추가 고려한다는 내용이다. 15점과 25점을 가르는 기준, 예시, 기준점이 없어서 주니어 엔지니어의 인턴십, 10년 분산 시스템 경험을 가진 principal engineer, 테스트에 사용된 이력서가 모두 25/25점을 받을 수 있다.

LLM 점수화가 운에 따른 필터링이 되는 이유

오픈소스와 프로젝트가 합쳐서 65% 비중을 차지하는 구조는 채용 판단을 왜곡할 수 있다. 30년 경력으로 S3를 만든 엔지니어보다, 인턴십 2개와 오픈소스 프로젝트가 있는 지원자를 더 높게 볼 수 있다. GitHub에 남지 않은 중요한 작업을 해온 엔지니어는 절반 이상의 점수를 잃는다. 이력서 스크리닝에 AI 도구를 도입할 권한이 있는 엔지니어는 품질을 가르지 못하는 도구가 단순히 지원자를 걸러내는 장치가 될 수 있음을 주의해야 한다.

실제 사용자 보고도 유사했다. 내 GitHub 프로필을 찾지 못해서 70점대가 나왔고, 어떤 실행에서는 65점쯤 나왔는데 오픈소스 기여가 없다는 점을 싫어했기 때문이었다. 인증이나 수상도 잡아내지 못했고, GSoC(Goggle Summer of Code) 참여 경험이 없다는 점에서도 가산점을 준 환각 사례가 보고됐다.

전망: LLM 이력서 스크리닝의 법적 리스크

EU AI Act는 2027년 12월 2일까지 시행되지 않지만, 채용 또는 자연인 선발에 쓰이는 AI 시스템, 특히 지원서 분석·필터링, 후보자 평가에 쓰이는 시스템은 명시적으로 고위험 AI 시스템으로 분류된다. GDPR Article 22는 "정보주체는 프로파일링을 포함한 자동화 처리에만 근거해 자신에게 법적 효과를 발생시키는 결정의 대상이 되지 않을 권리"를 보장한다. 이런 환경에서 확률적 점수를 기준으로 한 채용 자동화는 체계적 차별과 이의 제기 양쪽 모두에 취약하다.

요약

• 같은 이력서를 100회 실행 → 66~99점 변동, 85점 컷오프에서 65% 탈락
• gemma3:4b + temperature 0에서도 비결정성 잔존, Gemini 교체해도 28% 탈락
• 기술 스킬은 일관적, 프로젝트/오픈소스는 큰 변동, 경력은 일관적이나 무의미
• 65% 가중치(오픈소스+프로젝트) 구조는 GitHub 활동 없는 엔지니어에게 불리
• EU AI Act + GDPR Article 22 적용 시 법적 리스크 동반

같은 이력서가 운에 따라 탈락하는 구조는 채용 파이프라인 전체의 신뢰를 떨어뜨린다. AI 도구를 도입할 때는 점수의 확률 분포를 함께 보고하고, 단일 점수가 아닌 분산까지 의사결정에 반영하는 설계가 필요하다.