--- title: "해커랭크가 공개한 AI 채용 필터, 같은 이력서가 66점부터 99점까지 흔들림" published: 2026-06-29T01:44:40.000Z canonical: https://jeff.news/article/4384 --- # 해커랭크가 공개한 AI 채용 필터, 같은 이력서가 66점부터 99점까지 흔들림 HackerRank가 공개한 오픈소스 ATS를 직접 돌려본 결과, 같은 이력서가 실행할 때마다 66점에서 99점까지 크게 흔들렸다는 실험 글이다. 글쓴이는 LLM을 이력서 파싱이나 기술 체크리스트 확인에 쓰는 건 괜찮지만, 후보자의 프로젝트와 경력을 점수화하는 순간 운빨 필터가 된다고 비판한다. - HackerRank가 오픈소스로 공개한 ATS(Applicant Tracking System)를 글쓴이가 직접 돌려봤는데, 결과가 꽤 살벌함 - 같은 이력서로 첫 실행은 90/100점 - 디버그 출력 몇 줄 지우고 다시 돌렸더니 74/100점 - 이후 100번 반복 실행했더니 점수 범위가 66점에서 99점까지 튐 - 회사 커트라인이 85점이면, 같은 이력서가 65% 확률로 탈락한다는 계산이 나옴 > [!IMPORTANT] > 핵심은 “AI가 사람보다 냉정하게 평가한다”가 아님. 같은 입력을 넣어도 합격과 탈락이 바뀌면, 그건 평가가 아니라 운빨 필터에 가까움. - 이 도구의 처리 흐름은 대략 이렇게 생겼음 - PDF 이력서를 텍스트로 파싱함 - 대규모 언어 모델(LLM)을 6번 호출해서 기본 정보, 경력, 학력, 기술, 프로젝트, 수상 내역을 구조화함 - GitHub 프로필을 가져오고, 상위 저장소를 스캔해서 추가 컨텍스트로 붙임 - 마지막에 전체 정보를 한 번에 넣고 100점 만점으로 평가함 ```mermaid 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점이 되는 식임 > [!WARNING] > 이 도구는 프로젝트 평가는 흔들리고, 경력 평가는 구분을 못 함. 둘 다 채용 필터로는 치명적인 실패 모드임. - 글쓴이가 제일 강하게 비판하는 부분은 “65%가 오픈소스 + 개인 프로젝트”라는 가중치임 - GitHub에 공개된 프로젝트가 많은 사람에게 유리함 - 반대로 회사 내부에서 대규모 시스템을 만든 사람, 예를 들어 S3 같은 걸 만든 엔지니어는 공개 저장소가 적을 수 있음 - 실무에서 강한 엔지니어가 GitHub 점수 때문에 사람 눈에 닿기도 전에 걸러질 수 있다는 뜻임 - 결론은 LLM을 어디에 쓰느냐를 구분하자는 쪽임 - 이력서를 구조화 데이터로 파싱하는 건 좋음 - Python을 아는지, React를 언급했는지 확인하는 것도 괜찮음 - 하지만 후보자의 경험이 18점인지 24점인지 판단하게 하면 그냥 바이브 체크가 됨 - 채용팀이 수십 년 동안 피하려고 애쓴 주관적 느낌 평가가 자동화된 셈이라, 좀 웃픈 상황임 --- ## 기술 맥락 - 이 사례에서 중요한 선택은 LLM을 “정보 추출기”로 쓸지 “판정자”로 쓸지예요. 이력서에서 경력 기간, 기술 스택, 프로젝트 이름을 뽑는 건 구조화 문제라서 비교적 잘 맞거든요. - 반대로 프로젝트의 가치나 경력의 깊이를 점수로 매기는 건 기준이 애매해요. 프롬프트에 루브릭을 길게 써도 모델은 매번 같은 근거를 고정해서 적용하지 못할 수 있고, 짧게 쓰면 이번 글의 경력 항목처럼 모두 만점이 나와버려요. - temperature를 낮추면 안정성이 올라갈 거라는 기대가 있지만, 여기서는 그걸로 충분하지 않았어요. 모델 실행 환경, 샘플링, 프롬프트 해석, 긴 컨텍스트에서의 주의 분산 같은 요소가 겹치면 채용 커트라인처럼 민감한 의사결정에는 여전히 위험해요. - 그래서 실무에서는 LLM 점수를 바로 탈락 기준으로 쓰기보다, 사람이 볼 후보군을 정리하거나 누락된 정보를 표시하는 보조 도구로 제한하는 게 더 맞아요. 자동화의 목적이 비용 절감이어도, 같은 이력서가 운에 따라 떨어지는 시스템은 비용을 다른 사람에게 떠넘기는 구조가 되거든요. ## 핵심 포인트 - 같은 이력서를 100번 평가했더니 점수가 66점부터 99점까지 넓게 분포함 - 커트라인이 85점이면 동일 후보가 65% 확률로 탈락하는 결과가 나옴 - 기술 스킬 항목은 100회 중 98회가 8/10으로 안정적이었지만, 프로젝트 평가는 크게 흔들림 - Gemini로 바꿔도 48점부터 64점 사이로만 좁아졌을 뿐, 커트라인 60점 기준 28%는 운 없이 탈락함 - 경력 항목은 인턴 1개짜리 옛 이력서도 25/25를 받아 일관적이지만 구분력이 없었음 ## 인사이트 이 글의 포인트는 “AI 채용이 나쁘다”가 아니라 “어떤 판단을 LLM에게 맡기면 안 되는가”에 더 가까움. 구조화 추출은 잘하지만, 후보자의 프로젝트 가치를 18점인지 24점인지 매기는 순간 시스템은 평가기가 아니라 분위기 점수 생성기가 됨.