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

 (danunparsed.com)
4P by GN⁺ | ★ favorite | 댓글 4개
  • 같은 이력서와 같은 명령으로 HackerRank의 오픈소스 ATS 채용 에이전트를 반복 실행하자 점수가 66~99점까지 흔들렸고, 85점 컷오프에서는 65%가 탈락하는 결과가 나옴
  • 이 도구는 PDF 이력서를 파싱하고 LLM을 6번 호출해 기본 정보, 경력, 학력, 기술, 프로젝트, 수상 내역을 구조화한 뒤 GitHub 정보까지 더해 100점+보너스 20점으로 평가함
  • 기술 스킬은 100회 중 98회가 8/10점으로 거의 일정했지만, 프로젝트 평가는 “아키텍처 복잡성이 부족함”과 “실제 배포를 보여줌” 사이를 오가며 큰 변동성을 보임
  • 기본 모델 gemma3:4b의 temperature 0.1뿐 아니라 temperature 0에서도 비결정성이 남았고, Gemini로 바꿔도 60점 컷오프 기준 28% 탈락률이 발생함
  • 경력 항목은 인턴십 하나만 있는 예전 이력서도 25/25점을 받아, LLM 점수화가 지원자 품질을 가르기보다 운에 따른 필터링이 될 수 있음

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

  • HackerRank의 오픈소스 ATS인 hiring-agent가 LinkedIn과 Reddit에서 주목받은 뒤 테스트 대상이 됨
  • 첫 실행 점수는 90/100점이었고, 디버그용 출력문을 삭제한 뒤 같은 이력서와 같은 명령으로 다시 실행하자 74/100점이 나옴
  • DEVELOPMENT_MODE를 비활성화하고 100회 반복 실행하자 점수 범위가 66~99점까지 벌어짐
  • 회사 통과 기준이 85점이라면 같은 이력서도 65% 확률로 탈락함

평가 파이프라인과 배점 구조

  • 도구는 PDF 이력서를 텍스트로 파싱한 뒤 LLM을 여러 번 호출해 지원자 정보를 구조화함
    • 기본 정보
    • 경력
    • 학력
    • 기술
    • 프로젝트
    • 수상 내역
  • GitHub 프로필과 상위 저장소를 스캔하고, 이 정보를 추가 맥락으로 붙여 전체 정보를 한 번에 LLM 평가에 넣음
  • 기본 모델은 로컬에서 실행되는 gemma3:4b이며 temperature는 0.1로 설정됨
  • 점수는 100점 만점이고, 최대 20점의 보너스가 추가됨
    • 오픈소스 기여: 35점
    • 개인 프로젝트: 30점
    • 업무 경험: 25점
    • 기술 스킬: 10점
    • 스타트업 경험, 포트폴리오 사이트, 기술 블로그 등: 최대 20점 보너스

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

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

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

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

경력 점수의 반대 문제: 일관적이지만 쓸모없음

  • 경력 항목은 모든 실행에서 25/25점이 나옴
  • 예전 이력서처럼 인턴십 하나만 있는 경우에도 25/25점을 받음
  • 평가 프롬프트의 Production 항목은 두 줄뿐임
    • work와 volunteer 섹션에서 실제 업무, 인턴십, 프로덕션 경험을 분석
    • 창업자, 공동창업자, 스타트업 초기 엔지니어 역할에는 추가 고려
  • 15점과 25점을 가르는 기준, 예시, 기준점이 없음
  • 결과적으로 주니어 엔지니어의 인턴십, 10년 분산 시스템 경험을 가진 principal engineer, 테스트에 사용된 이력서가 모두 25/25점을 받을 수 있음

이력서 스크리닝에서의 실무적 위험

  • LLM으로 이력서를 구조화된 데이터로 파싱하거나 Python 보유 여부를 확인하는 작업은 비교적 적합한 용도에 가까움
  • 후보자의 경험이 18점인지 24점인지 판단하는 작업은 vibe-check에 가까운 결과를 만듦
  • 오픈소스와 프로젝트가 합쳐서 65% 비중을 차지하는 구조도 채용 판단을 왜곡할 수 있음
    • 30년 경력으로 S3를 만든 엔지니어보다, 인턴십 2개와 오픈소스 프로젝트가 있는 지원자를 더 높게 볼 수 있음
    • GitHub에 남지 않은 중요한 작업을 해온 엔지니어는 절반 이상의 점수를 잃을 수 있음
  • 이력서 스크리닝에 AI 도구를 도입할 권한이 있는 엔지니어는 품질을 가르지 못하는 도구가 단순히 지원자를 걸러내는 장치가 될 수 있음을 주의해야 함

정정 사항

  • resume_evaluation_criteria.jinja 템플릿 1행에는 “Software Intern”이 있음
  • 이 문구는 문서화되어 있지 않고 저장소의 다른 곳에서도 참조되지 않음
  • 같은 템플릿은 뒤에서 창업자, 공동창업자, 초기 스타트업 엔지니어 역할에 보너스를 부여함
  • 명시적으로 Senior SWE 프롬프트를 넣어 다시 실행해도 결과는 동일했고, 점수 차원은 직무 수준과 무관하게 동작함

함께 보면 좋은 글 β

t7vonn   [-]

LLM을 그렇게 신뢰하면 채용은 왜 하나요, LLM한테 전부 맡기지

답변달기
laeyoung   [-]

GN+가 장황하게 요약했지만, 글쓴이가 말하려고 하는 것은

  1. 이력서 점수 hiring-agent 프로젝트가 인기를 얻는 것도 그렇고, 대부분의 기업들이 AI를 이력서 스크리닝에 쓸 것으로 생각됨.
  2. 그런데 AI 자체가 확률적이다보니, AI 스크리닝도 돌릴 때마다 점수가 달라짐. 그리고 실제 해보면 그 점수 폭이 큼 (90점 -> 74점 -> 88점)
  3. 즉, 내 이력서가 서류 탈락할지 말지 여부에 확률적 운빨 요소 크다. 스크리닝 통과한 사람도 그냥 운이 좋아서 일 수 있고, 탈락한 사람이 운이 나빠서 일 수 있다. 이거 괜찮나.

로 이해 했었습니다.

답변달기
heycalmdown   [-]

요약의 요약 너무 좋아요

답변달기
GN⁺   [-]
Hacker News 의견들

  • LLM이 순수 확률적 과정으로 동작한다는 걸 모르는 사람이 놀랄 만큼 많아서, 이런 심층 글이 반갑다
    구직 중인데 요즘 콜백 받기가 이렇게 어려운 이유가 이건지도 모르겠음. 이력서가 그냥 어떤 LLM 블랙홀에 던져지고, 실제로 어떻게 동작하는지 아무도 모르는 듯함
    글의 “temperature 0.1 — 낮은 값이라 모델을 결정적 출력 쪽으로 유도한다고 여겨짐”이라는 설명은 정확하지 않음. temperature는 결정성 스위치가 아니라 샘플링 분포에 영향을 주는 값이고, 더 뾰족한 분포가 될 뿐 여전히 분포임

    • 이론상 temperature 0은 LLM을 결정적으로 만들 수 있음
      더 엄밀히 말하면 temperature 0 자체는 존재하지 않음. 수학적으로 temperature가 0에 가까워질수록 분포는 점점 뾰족해지고, 가장 가능성 높은 샘플은 거의 무한대에 가까워지며 나머지는 거의 0에 가까워짐
      실제 구현에서는 temperature=0이 0이 아닌 값에 쓰는 공식을 쓰는 게 아니라, 0 나눗셈을 피하려고 if문의 별도 분기에서 가장 흔한 샘플을 고르는 식임
      다만 배치 처리나 구현별 부동소수점 오차 때문에 확률분포 자체가 실행마다 달라지는 경우가 많고, 그 결과 샘플도 달라짐
    • 텍스트 이해 전체가 불확실성하의 추론 문제임. 사람들이 어떤 “witch”를 말하는지 항상 확신할 수 없고, 어떤 채용 절차를 쓰든 채용한 사람이 성공할 수도 실패할 수도 있음
      같은 이력서를 두 사람이 보고 같은 결론에 이를 수도 있고, 같은 증상과 임상 양상을 가진 두 환자가 서로 다른 병을 가질 수도 있음
      옛 AI가 주로 지식베이스 유지 비용 때문에 죽었다는 설명은 잘 납득되지 않고, 오히려 불확실성을 다루는 보편적 추론 체계의 부재가 핵심이었다고 봄
      Spock이 “함장님, 이 임무에서 생존할 확률은 21%입니다” 같은 말을 늘 하던 게 개인적으로는 반복 농담처럼 느껴짐. 베이즈 관점에서는 확률분포에도 확률분포가 있으니 “이 임무에서 생존할 가능성은 β(5,1)입니다”가 더 맞는 표현에 가까움
      그런 의미에서 이력서를 그 기계에 100번 넣고 점수의 확률분포를 보는 것도 그렇게 이상한 일은 아님
      [1] 그렇긴 해도 나는 침대에 누워 태블릿으로 이미지 정리를 하다가 시각 체계가 망가질 때까지 계속하는 종류의 미치광이임
    • 명확히 하자면 temperature 0은 결정적이며, 완전히 같은 입력에 대해서는 어떤 시드 선택에서도 같은 출력을 냄
      단, MoE라면 중복 입력이 전체 배치에서도 동일해야 함. 배치 이웃이 전문가 선택에 영향을 줄 수 있음
      커널이 결정적이어야 하고, 사고형 모델에서 클러스터 전체 부하 같은 것에 반응하는 시스템 차원의 노력 수준 스위치가 없어야 함
      결론적으로 기존 클라우드 인프라에서는 temperature 0도 아마 결정적이지 않지만, 엣지 추론에서는 꽤 안정적으로 결정적일 수 있음
      0.1이 더 결정적이라는 표현에 대해서는 꽤 합리적인 요약이라고 봄. temperature 0.9보다 0.1에서 “temperature 0의 답” 쪽을 훨씬 더 자주 샘플링하게 되지 않나?
    • 이걸 복음처럼 반복하는 자칭 AI 전문가 동료들이 여럿 있음
      “일관된 결과를 얻으려면 temperature를 0으로 설정하라”는 말을 셀 수 없이 많이 들었음
    • 모든 확률질량이 하나의 결과에 몰린 분포는 결정적이므로, 원칙적으로 temperature를 0으로 설정하면 결정적 출력이 나와야 함
      그렇지 않을 수 있는 이유가 몇 가지 있지만, 글쓴이가 한 것처럼 로컬 모델을 실행하는 경우에는 그 이유들이 적용되지 않는다고 봄

  • AI가 AI가 만든 코드를 “선호”하는 경향과 다른 편향까지 합치면, 이런 방식은 EU에서 차별금지법을 여러 방식으로 위반해 매우 불법일 가능성이 큼
    이력서가 너무 많다는 이유로 무작위로 걸러내는 건 대체로 허용될 수 있다고 봄. 하지만 실제 무작위여야 하고, 이력서 내용과 독립적이어야 함
    AI에서는 무작위성이 실제 이력서 평가와 독립적이지 않으므로 해당되지 않음
    일반적으로 AI가 체계적 편향을 적용하지 않는다고 보장할 수 없고, 실제로 그럴 가능성이 높다는 신호도 큼
    사람에게는 편향을 무시하라고 훈련하고 지시할 수 있음. 물론 그것도 안정적으로 작동하지 않지만, 적어도 불법적 편향의 책임이 지시를 어긴 채용 담당자에게 위임되는 구조가 됨
    반면 AI 사용에서는 무엇을 지시했든 사용자가 책임짐. 특정 맥락에서 특정 AI가 강하게 편향돼 있다는 걸 기술적으로 “보여주거나 증명”할 수도 있음. 사람 직원에게도 기술적으로는 가능하지만 실무적으로는 거의 어렵지 않음
    결국 법적 위험이 “개별적이고 대체로 부인 가능한” 수준에서 체계적으로 입증 가능한 편향 영역으로 이동함. 다시 말해 채용에 AI를 쓴다는 걸 알면 사람들이 법적으로 체계적으로 공격할 수 있게 됨

    • 모든 것은 모든 것과 상관관계가 있음 [1]
      즉 수학적으로만 봐도 이것이 미국의 인종, 성별, 기타 보호 대상 집단과 어떤 방식으로든 상관될 가능성이 높음
      그래서 미국에서도 좋은 소송 한 번이면 불법이 될 수 있음. 꼭 승소할 필요도 없고, 법정에서 충분히 버티기만 해도 다른 회사들이 이걸 쓰기 겁나게 만들 수 있음
      내 AI 선별기가 모든 채용 법규를 완전히 준수한다고 증명해야 하는 피고 입장이 되고 싶지는 않음. 악몽 같을 것임
      [1]: https://gwern.net/everything
    • 완전히 무작위이고 내용과 독립적인 방식으로 이력서를 걸러내는 건 전혀 문제 없음
      더미에서 네 번째 이력서를 집어 그 사람에게 일자리를 제안하는 건 멍청하지만 완전히 공정한 채용 결정 방식임
      하지만 AI는 편향 포착을 아주 잘하므로, 이력서를 걸러내라고 하면 후보자 이름처럼 절대 기준으로 삼으면 안 되는 요소를 기준으로 삼게 되더라도 놀랍지 않음
      대형 오픈소스 프로젝트에서 오타를 고쳤다고 쓴 이력서는 모두 통과하지만, 자기 프로젝트만 적은 이력서는 60% 확률로 탈락하는 식일 수도 있음. 그러면 나쁜 후보보다 좋은 후보를 더 많이 잃게 됨
    • 이것이 Council Directive 2000/78/EC 같은 고용 관련 비차별 요건 위반이라는 걸 입증하기가 그렇게 쉬운지는 잘 모르겠음
      비합리적인 도박 기계처럼 작동하므로 원치 않는 간접 차별 효과가 있을 수 있다는 데는 동의함. 하지만 “종교 또는 신념, 장애, 나이, 성적 지향”을 이유로 차별한다고 보이기는 아마 쉽지 않을 것임. 가능은 하지만 변호사들이 법정에서 입증하려면 많은 작업이 필요함
      더 흥미로운 부분은 EU AI Act임. 이 부분은 2027년 12월 2일까지 아직 시행되지 않았지만, 채용 또는 자연인 선발에 쓰이는 AI 시스템, 특히 타깃 채용 광고 배치, 지원서 분석·필터링, 후보자 평가에 쓰이는 시스템은 명확히 고위험 AI 시스템임
      금지된다는 뜻은 아니지만, 나중에 LLM이 고위험 AI 사용 사례에서 제외될 수도 있음. 예외 없이 Article 6에 걸릴 수 있기 때문임
      아직 표준이 공개되지 않은 상황에서, 이런 작업에 LLM을 쓸 때 Article 10의 다음 부분을 어떻게 준수시킬지 전혀 모르겠음
      “(f) 사람의 건강과 안전에 영향을 미치거나, 기본권에 부정적 영향을 주거나, EU 법상 금지된 차별로 이어질 가능성이 있는 편향을 검토할 것. 특히 데이터 출력이 향후 작업의 입력에 영향을 미치는 경우
      (g) (f)에 따라 식별된 가능한 편향을 탐지, 예방, 완화하기 위한 적절한 조치”
      현재로서는 모델 제공자가 완전히 협조하더라도 일반적인 LLM으로는 기술적으로 불가능하다고 봄. 작은 모델은 의미 있는 감사가 가능할지도 모름
      EU AI Act는 결국 Annex III의 고위험 사용 사례에서 “LLM을 쓰긴 쓰는데 왜 쓰는지는 잘 모르는” 바이브 코딩식 접근을 모두 배제하게 될 수 있고, 그게 타당해 보임
      https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
    • GDPR Article 22에 따라 대체로 불법임
      “정보주체는 프로파일링을 포함한 자동화 처리에만 근거해 자신에게 법적 효과를 발생시키거나 이와 유사하게 중대한 영향을 미치는 결정의 대상이 되지 않을 권리를 가진다”
      22(2)의 예외는 적용되기 어려움. 진정으로 필요하다고 주장하기 어렵고, 고용 맥락에서는 동의도 거의 성립하지 않음. EU 또는 회원국의 특정 법률이 허용하는 경우라면 가능하겠지만, 별도 법적 근거가 필요함

  • 이쯤 되면 “운 나쁜 사람을 뽑고 싶지 않으니 이력서 절반을 눈감고 버린다”는 농담을 그냥 채택해도 되겠음

    • 과거 영국의 주요 의대인 Barts and The London School of Medicine and Dentistry, 즉 Queen Mary University of London 일부가 자격을 갖춘 지원자에 대해 무작위 선발을 도입한 적이 있음
      이 방식은 점점 더 복잡해지는 당시 수작업 이력서 평가 기준을 공략할 여유가 있는 학생보다, 덜 부유한 배경의 자격 있는 학생들에게 유리했음
      “예비 의사를 도박으로 뽑을 건가?”라는 식의 조직적 캠페인이 벌어졌고, 결국 추첨 방식은 조용히 폐지됨
    • 한 사람의 평생 운 총량은 일정함
      남은 절반의 후보자는 이미 이번 선발에서 운을 일부 써버렸으니, 평균적으로 버려진 절반보다 덜 운이 좋을 것임
    • 더 핵심적으로는 보통 자리에 비해 자격 있는 지원자가 훨씬 많음
      지난 수십 년간 훈련과 교육은 크게 확대돼 구직자는 계속 늘었지만, 일자리 창출은 그 속도를 따라가지 못했음
    • LLM 이력서 선별은 더 큰 문제의 증상일 수 있음
      공석 하나에 수십 명의 후보가 몰리면, 고용주는 이력서를 엉망으로 선별하거나 절반을 버려도 여전히 자격 있는 사람을 뽑을 수 있음

  • “나는 65% 확률로 탈락한다. 완전히 같은 이력서, 다른 운”이라는 결과는, 최근 몇 년간 기술 직군 채용 파이프라인을 운영해 본 입장에서는 사실 훌륭한 숫자임
    이렇게 말하기가 객관적으로 싫지만 사실임
    노력 없이 기술 인력을 다음 단계로 올릴 확률이 35%라니? 도메인 특화 선별 질문을 넣어도 시간당 지원자 100명 이상을 본 적이 있음. 그러면 한 시간에 35명의 “선별된” 지원자가 나오는 셈임
    유효한 후보가 걸러졌나? 맞음. 그래도 필요한 것보다 35배 큰 후보 풀을 갖게 되나? 안타깝지만 역시 맞음
    지원자 수가 너무 많아서 AI가 개입하지 않을 때 다음 단계로 넘어갈 확률은 오히려 훨씬 낮아짐. 즉시 지원하지 않았다면, 그것도 AI 봇을 써서 지원하지 않았다면, 앞에 50명 이상이 있고 지친 기술 리더가 언젠가 당신 이력서까지 도달해야 함
    추천 보너스가 존재하는 데는 이유가 있음

    • 그렇다면 내가 팔 사전 선별 시스템이 있음
      최신 기술을 통해 최고의* 지원서 1%만 통과시킴
      *우리의 독점적이고 비공개이며 비결정적인 지표 기준이며, Math.random일 수도 아닐 수도 있음
    • 정말 그런가? 아니면 한 인간도 보기 전에 이력서가 무시될 확률이 65%라서, 채용 파이프라인이 자격 있는 후보를 잡을 가능성도 같은 만큼 줄어드는 건가?
      이력서 유입을 줄이는 관문은 그 감소가 품질과 상관관계가 있을 때만 유용함. 그렇지 않으면 채용 절차를 질질 끌거나, 결국 채용 기준을 불필요하게 낮추게 만들 뿐임
    • 논리적 해법은 후보자가 연락처 정보를 살짝 바꿔 여러 번 지원하는 것임
      “John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt” 같은 식으로
    • 정확도 요구사항이 없다면 그냥 지원자 35%를 무작위로 다음 단계에 올리면 됨
      처음 지원한 50명이 모두 봇이라면, 왜 지원 순서대로 이력서를 읽고 있나?

  • 더 걱정되는 건, 다른 시스템도 이 ATS처럼 동작한다면 꽤 괜찮거나 좋은 후보들을 대거 탈락시킬 요소들로 판단하는 듯하다는 점임
    예를 들어 개인 프로젝트와 오픈소스 기여의 조합에 65점이 배정됨. 기술이 유일한 관심사이고, 가족·부양가족·두 번째나 세 번째 직업이 없다면 좋을 수 있음
    하지만 그런 것이 하나라도 있다면 가능성이 엄청나게 불리해 보임
    이런 시스템들이 얼마나 많이, 대학에 다니거나 원하는 업계의 한 직장만 다니는 것 외에는 걱정이 없고 기술에 거의 특수 관심 수준으로 집착할 수 있는 부유한 사람들에게 유리하게 설계돼 있는지 궁금해짐

    • 개인 프로젝트와 오픈소스 프로젝트를 과대평가하는 건 걱정스럽고 별로임
      나 자신을 예로 들면, 회사 밖에서는 개인 프로젝트를 거의 하지 않음. 실제 프로그래밍 경력은 전부 근무 시간에 고용주를 위해 한 일뿐임
      취미는 3D 프린팅, 하드웨어/Arduino, 사진처럼 기술 인접 영역이지만, GitHub에 프로젝트를 잔뜩 만들어 올리는 류는 아님
      잠재 고용주에게 보여주려고 가짜 CRUD나 SaaS 앱을 만드는 일도 절대 안 할 것임. 시간 낭비임
      나는 의도적으로 그런 온라인 존재감을 전혀 만들지 않았음. 내 GitHub에는 공개 저장소가 없고, 블로그도 안 함
      이 경향은 내가 일하는 운영/시스템 관리 쪽에도 퍼졌고, 그쪽에서는 오히려 더 심함. 당연히 내 GitHub에 환경 특화 스크립트를 잔뜩 올려놓지 않았는데, 왜 그래야 하나? 지금 회사의 내 부서에서 일하지 않는 사람에게는 아무 의미도 없음

  • 결정성이라는 단어는 닿는 온라인 글을 뒤틀어버리는 마법 같은 효과가 있음
    그 단어가 들리면 거의 틀린 방향으로 갈 거라고 보장할 수 있음. 그래도 이번에는 같은 입력이면 같은 출력이라는 실제 결정성을 다루고 있지, 엉뚱한 무관한 것들은 아님
    결정성은 재현성에 중요하지만, 이 경우에 정말 출력이 재현되길 원하는가? LLM 출력을 결정적으로 만드는 건 비교적 사소함. 배치를 쓴다면 배치 불변 커널을 쓰고, temperature를 0으로 설정하거나 그러지 말고 무작위 샘플링은 이유가 있으니, 더 낫게는 시드를 고정하면 됨. 몇몇 시스템에서는 이미 가능함
    하지만 이게 결과를 더 유용하게 만들지는 않음. 에이전트가 실제로 확신하지 못한다는 사실만 가릴 뿐임. 점수 범위를 보라. 여전히 아무것도 예측하지 못하지만 매번 점수만 같아질 것임. 정말 그걸 원하는가?
    여기서 벌어지는 일은 정보가 너무 적게 제공되고, 거의 잡음 수준인 이력서 하나만 주면서 너무 넓은 함의를 가진 답을 기대한다는 것임
    LLM 사용 여부와 무관하게 기본적인 설계 실수임. 모든 설문, 시험, 법, 투표 시스템은 너무 적은 정보로 작동하기 때문에 프레이밍에 극도로 민감함. 다만 그것들은 이 물건과 달리 진공 속에 존재하지는 않음

    • 비결정성이 올바른 출력에 안정적으로 도달할 수 없다는 뜻은 아님. 물론 때로는 그런 뜻일 수도 있음
      Las Vegas 알고리즘은 비결정적이지만 100% 정확함. 대신 정답에 도달하는 시간이 크게 달라지는 절충이 있음
      여기서의 실수는 비결정적 시스템을 쓴 것이 아님. 어떤 의미에서는 너무 적게 쓴 것이 실수일 수 있음. 같은 이력서를 5번 다시 평가해 점수 분산이 크다는 걸 보는 편이 한 번만 평가하는 것보다 더 유용한 신호임
    • 인간 판사와 시험관도 우리가 바라듯 결정적이지 않다는 사실은 유명함
      점심 직전 한 시간에 더 엄한 형량이 나온다는 얘기는 다들 들어봤을 것임
    • 비결정성은 버그가 아니라 기능이기도 함
      사람들이 필터링 과정에 맞춰 최적화하지 못하게 하려면 어느 정도 비결정적으로 만들어야 함
      예를 들어 상위 100명에서 딱 잘라내는 대신 더 나은 후보가 필터를 통과할 가능성을 지수적으로 높이는 식임
      그러면 필터링 과정을 Goodhart식으로 공략할 가치가 줄어듦. 확률이 거의 늘지 않고, 시간을 더 잘 쓸 곳이 훨씬 많기 때문임

  • 기본 모델이 gemma3:4b라면 아주 작은 모델임
    어떤 LLM도 완벽하고 반복 가능한 심판은 아니겠지만, 4B 모델을 이런 시스템에 꽂는 건 난수 생성기를 연결하는 것과 비슷함
    전체 실험이 누군가 오픈소스 ATS 프로젝트를 만들고 싶어서 바이브 코딩으로 ATS를 만든 뒤, 테스트가 통과할 정도까지만 맞춘 것처럼 느껴짐

    • 이런 모델도 올바르게 쓰면 작은 문제에는 괜찮음
      이 모델로도 잘 작동할 이력서 분석 방식은 아마 있을 것임. 하지만 “야 고철아, 이 사람이 어떤 프로젝트를 했지?” 같은 방식은 아님
      추출, 정리, 아마 OCR을 통한 비교와 추가 정리, 신호별 여러 차례 LLM 분석, 판정기 등이 필요함
      그 어느 것도 큰 모델일 필요는 없음. 큰 모델을 쓰면 약간 더 나아지겠지만, 맥락이 매우 적기 때문에 올바르게 쓰면 이런 모델도 잘 작동할 수 있음

  • ATS를 직접 돌려봤고 비슷하게 이상한 경험을 함
    내 GitHub 프로필을 찾지 못해서 70점대가 나왔고, 그다음에는 내가 만든 유명한 Ruby 라이브러리 몇 개를 마음에 들어 하지 않았음
    몇 번 돌린 뒤에는 적절히 인식하기 시작했지만, 공식 학력에서는 항상 감점당했음
    이런 건 역겨움

    • 비슷한 경험이었음. 어떤 실행에서는 65점쯤 나왔는데, 오픈소스 기여가 없다는 점을 싫어했기 때문임
      인증이나 수상도 잡아내지 못함. 사람들이 개선을 제안한 PR 몇 개를 적용해 봤고(https://github.com/Zem-0/hiring-agent), 도움이 되긴 했지만 전체적으로 이 ATS는 대규모 GitHub 오픈소스 기여가 있는 사람에게 크게 편향돼 있음

  • 좋은 엔지니어가 찾기 어렵다는 이유로 기술 회사가 30만 달러 이상을 지불하면서도, 정작 리크루터는 지원 없이 일하고 “좋은 후보”에 대한 기준도 전혀 다르다는 게 항상 놀라웠음
    ATS는 쓰레기 같은 필터링 휴리스틱 때문에 이력서의 50% 이상을 블랙홀로 보내고, 채용팀은 Google Gmail 연동 같은 이유로 ATS를 골랐으며, 그 ATS의 필터링 기술은 엔지니어링팀이나 데이터팀 누구에게도 검토받지 않았음

  • 내 이력서로 시도해 봤더니 somehow GSoC 보너스 점수를 받았음
    BONUS POINTS: 5.0
    ------------------------------
    Google Summer of Code (GSoC) participation: +5
    그런데 나는 GSoC를 한 적도 없고, 이력서에 했다고 적지도 않았음

답변달기