해커랭크가 공개한 AI 채용 필터, 같은 이력서가 66점부터 99점까지 흔들림

• HackerRank가 오픈소스로 공개한 ATS(Applicant Tracking System)를 글쓴이가 직접 돌려봤는데, 결과가 꽤 살벌함
  • 같은 이력서로 첫 실행은 90/100점
  • 디버그 출력 몇 줄 지우고 다시 돌렸더니 74/100점
  • 이후 100번 반복 실행했더니 점수 범위가 66점에서 99점까지 튐
  • 회사 커트라인이 85점이면, 같은 이력서가 65% 확률로 탈락한다는 계산이 나옴

• 이 도구의 처리 흐름은 대략 이렇게 생겼음
  • PDF 이력서를 텍스트로 파싱함
  • 대규모 언어 모델(LLM)을 6번 호출해서 기본 정보, 경력, 학력, 기술, 프로젝트, 수상 내역을 구조화함
  • GitHub 프로필을 가져오고, 상위 저장소를 스캔해서 추가 컨텍스트로 붙임
  • 마지막에 전체 정보를 한 번에 넣고 100점 만점으로 평가함

sequenceDiagram
  participant 이력서
  participant 파서
  participant 언어모델
  participant 깃허브
  participant 채점기
  이력서->>파서: PDF를 텍스트로 변환
  파서->>언어모델: 기본 정보와 경력 등 6개 영역 추출
  언어모델->>깃허브: 프로필과 상위 저장소 확인
  깃허브-->>언어모델: 프로젝트 컨텍스트 반환
  언어모델->>채점기: 구조화 정보와 저장소 맥락 전달
  채점기-->>이력서: 최종 점수 산출

• 점수 배분도 꽤 흥미로움

  • 오픈소스 기여 35점
  • 개인 프로젝트 30점
  • 업무 경험 25점
  • 기술 스킬 10점
  • 여기에 스타트업 경험, 포트폴리오 사이트, 기술 블로그 같은 보너스가 최대 20점 붙음
  • 즉 오픈소스와 개인 프로젝트만 합쳐도 기본 100점 중 65점을 차지함

• 안정적인 항목과 불안정한 항목의 차이가 확 갈림

  • 기술 스킬은 100번 중 98번이 8/10점으로 거의 같았음
  • 이유는 단순함. React를 아는지, Python을 아는지 같은 체크리스트는 LLM이 아니라 어린애도 매칭할 수 있음
  • 반면 프로젝트 평가는 엄청 흔들림
  • 어떤 실행에서는 “아키텍처 복잡도가 부족하다”고 하고, 다른 실행에서는 “실제 배포 경험을 보여준다”고 평가함

• 모델 설정을 낮춰도 문제가 사라지지 않았다는 게 더 골치 아픔

  • 기본 모델은 gemma3:4b이고 temperature는 0.1임
  • temperature 0.1은 출력 무작위성을 꽤 낮춘 설정인데도 점수가 흔들림
  • 2025년 10월 GitHub 이슈에서도 temperature 0에서 비결정성이 보고됐다고 함
  • 글쓴이는 이걸 “프롬프트 조금 고치면 해결될 버그”가 아니라 설계상 한계로 봄

• “그럼 로컬 모델이 구려서 그런 거 아님?”이라는 의심도 테스트함

  • Gemini로 돌리면 분포가 좀 좁아지긴 했음
  • 점수는 48점에서 64점 사이로 모였음
  • 하지만 커트라인이 60점이면 여전히 28%는 자기 잘못 없이 떨어짐
  • 즉 더 큰 모델을 써도 불확실성이 줄어들 뿐, 채용 필터로 쓸 만큼 안정적이진 않다는 얘기임

• 경력 평가 항목은 반대로 너무 일관적이라 쓸모가 없었음

  • 글쓴이의 현재 이력서는 매번 25/25점
  • 인턴십 하나만 있던 옛 이력서도 25/25점
  • 프롬프트를 보니 production experience 항목 설명이 사실상 두 줄뿐이었음
  • 15점과 25점을 나누는 기준, 예시, 앵커가 없음
  • 그래서 주니어 인턴도 25점, 10년 차 분산 시스템 엔지니어도 25점이 되는 식임

• 글쓴이가 제일 강하게 비판하는 부분은 “65%가 오픈소스 + 개인 프로젝트”라는 가중치임

  • GitHub에 공개된 프로젝트가 많은 사람에게 유리함
  • 반대로 회사 내부에서 대규모 시스템을 만든 사람, 예를 들어 S3 같은 걸 만든 엔지니어는 공개 저장소가 적을 수 있음
  • 실무에서 강한 엔지니어가 GitHub 점수 때문에 사람 눈에 닿기도 전에 걸러질 수 있다는 뜻임

• 결론은 LLM을 어디에 쓰느냐를 구분하자는 쪽임

  • 이력서를 구조화 데이터로 파싱하는 건 좋음
  • Python을 아는지, React를 언급했는지 확인하는 것도 괜찮음
  • 하지만 후보자의 경험이 18점인지 24점인지 판단하게 하면 그냥 바이브 체크가 됨
  • 채용팀이 수십 년 동안 피하려고 애쓴 주관적 느낌 평가가 자동화된 셈이라, 좀 웃픈 상황임

기술 맥락

• 이 사례에서 중요한 선택은 LLM을 “정보 추출기”로 쓸지 “판정자”로 쓸지예요. 이력서에서 경력 기간, 기술 스택, 프로젝트 이름을 뽑는 건 구조화 문제라서 비교적 잘 맞거든요.

• 반대로 프로젝트의 가치나 경력의 깊이를 점수로 매기는 건 기준이 애매해요. 프롬프트에 루브릭을 길게 써도 모델은 매번 같은 근거를 고정해서 적용하지 못할 수 있고, 짧게 쓰면 이번 글의 경력 항목처럼 모두 만점이 나와버려요.

• temperature를 낮추면 안정성이 올라갈 거라는 기대가 있지만, 여기서는 그걸로 충분하지 않았어요. 모델 실행 환경, 샘플링, 프롬프트 해석, 긴 컨텍스트에서의 주의 분산 같은 요소가 겹치면 채용 커트라인처럼 민감한 의사결정에는 여전히 위험해요.

• 그래서 실무에서는 LLM 점수를 바로 탈락 기준으로 쓰기보다, 사람이 볼 후보군을 정리하거나 누락된 정보를 표시하는 보조 도구로 제한하는 게 더 맞아요. 자동화의 목적이 비용 절감이어도, 같은 이력서가 운에 따라 떨어지는 시스템은 비용을 다른 사람에게 떠넘기는 구조가 되거든요.