"돌릴 때마다 점수가 달라요" - AI 이력서 심사의 충격적 진실

그동안 커리어 설문에 90명 가까운 분들이 답을 남겨주셨는데, 표현만 다를 뿐 결국 같은 질문을 하고 계셨죠. 내가 지금 어디쯤인지 모르겠다는 것. 서류에서 떨어질 때마다 이게 내 실력 문제인지 이력서 문제인지 알 길이 없다는 것. 저도 이력서 특강과 멘토링을 하면서 가장 많이 받은 질문이 정확히 이거였습니다.

그런데 최근에 이 질문을 조금 다른 각도에서 흔들어놓는 글을 하나 읽었습니다. 답이 "당신 실력"도 "당신 이력서"도 아닐 수 있다는 겁니다. 그냥 주사위가 나쁘게 굴렀을 수도 있다는 거죠.

Dan Kinsky라는 개발자가 HackerRank가 오픈소스로 공개한 AI 채용 심사 도구에 자기 이력서를 100번 넣어봤습니다. 지난달 Hacker News에서 1,000포인트를 넘기고 댓글이 400개 넘게 달린 [Dan Kinsky의 실험 기록]을 읽고 나면 서류 전형을 보는 눈이 좀 달라지실 겁니다.

print문을 지웠더니 16점이 사라졌습니다

시작은 단순한 호기심이었습니다. HackerRank가 자사 채용 심사 도구를 오픈소스로 풀었고, 링크드인과 레딧에서 수백에서 수천 개씩 좋아요를 받으며 화제가 됐죠. Dan은 그냥 궁금해서 자기 이력서 PDF를 넣어봤고, 90점이 나왔습니다. 기분이 나쁘지 않았다고 해요.

그리고 셋업하다가 여기저기 뿌려둔 디버그용 print문을 정리하고 한 번 더 돌렸습니다. 74점. 이력서도 그대로였고 명령어도 그대로였는데 16점이 사라진 거죠.

여기서 오해하시면 안 되는 게, print문이 범인이 아닙니다. 그냥 돌릴 때마다 점수가 달랐던 겁니다. 그걸 확인하는 데 100번의 실행이 필요했고요.

이건 필터가 아니라 주사위입니다

1. 체크리스트로 확인되는 항목은 거의 완벽하게 일관됩니다.

2. 사람의 판단이 필요한 항목은 돌릴 때마다 점수가 튑니다.

3. 그런데 배점은 하필 그 판단 항목에 몰려 있습니다.

4. 모델을 바꿔도, 설정을 만져도 잡히지 않습니다.

결론: 변별력이 없는 자리에 배점이 몰려 있고, 그 상태로 사람이 걸러집니다.

제가 이 글을 오래 붙들고 있었던 이유는 따로 있습니다. LLM을 어디까지 믿어도 되는지, 그 경계선을 100번의 채점 데이터로 그어놨죠. 이력서를 쓰는 입장에서도, AI로 뭔가를 만드는 입장에서도 남는 게 있는 글입니다.

자, 그럼 100번의 실행이 무엇을 보여줬는지 함께 확인해볼까요? Dan Unparsed의 HackerRank open sourced its ATS. My resume scored 90/100. Oh wait 74/100. No — 88/100.에서 핵심 대목을 추려 번역해 가져왔습니다.

HackerRank가 오픈소스로 푼 채용 심사기, 제 이력서는 90점… 아니 74점… 아니 88점

같은 이력서, 매번 다른 점수

DEVELOPMENT_MODE를 끄고 루프에 넣어 100번을 실행했습니다. 점수는 66점에서 99점 사이에 흩어졌습니다.

33점 폭입니다. 커트라인이 85점인 회사에 지원한다면 저는 같은 이력서로 100번 중 65번을 그 선 아래에서 멈춥니다. 실력도 경력도 문서도 전부 그대로인 채로요. 완전히 똑같은 이력서로, 운만 다르게.

이 도구가 동작하는 방식

먼저 이력서 PDF가 텍스트로 파싱됩니다. 그다음 LLM이 여섯 번 호출되어 기본 정보, 경력, 학력, 스킬, 프로젝트, 수상 이력을 각각 구조화된 데이터로 뽑아냅니다. 여기에 지원자의 GitHub 프로필을 끌어와 상위 저장소들을 훑고 컨텍스트로 덧붙입니다. 마지막으로 이 전부가 한꺼번에 모델에 들어가 채점됩니다.

배점은 100점 만점에 보너스 20점이 얹히는 구조입니다. 오픈소스 기여 35점, 개인 프로젝트 30점, 경력 25점, 기술 스킬 10점. 여기에 스타트업 경력이나 포트폴리오 사이트, 기술 블로그 같은 항목으로 최대 20점이 더 붙습니다.

기본 모델은 gemma3:4b, temperature는 0.1로 잡혀 있습니다. 낮게 두면 출력이 결정론적인 쪽으로 밀린다는 계산이죠. 적어도 설계자의 의도는 그랬을 겁니다.

항목별로 뜯어보면 정확히 갈립니다

기술 스킬부터 봅시다. 100번 중 98번 8/10점이 나왔습니다. 거의 완벽한 일관성이죠.

왜 이럴까요. 기술 스킬은 체크리스트이기 때문입니다. React를 알거나 모르거나 둘 중 하나고, LLM이 판단할 여지 자체가 없습니다. 이력서에 적힌 단어와 요구 스택을 대조하면 끝나는 일입니다. 다섯 살짜리한테 시켜도 맞출 겁니다.

이제 프로젝트 항목입니다. 여기서 편차가 폭발합니다.

프로젝트가 인상적인지 아닌지는 결국 판단의 영역인데, LLM은 그 판단을 일관되게 내리지 못합니다. 똑같은 프로젝트를 두고 어떤 실행에서는 "아키텍처 복잡도가 부족하다"고 평가하고, 어떤 실행에서는 "실제 배포를 입증한다"고 평가합니다. 둘 중 무엇이 나올지는 그야말로 주사위 굴리기입니다.

여기서 자연스럽게 드는 생각이 "temperature를 더 내리면 되지 않나"일 텐데요. 안 됩니다. 2025년 10월에 열린 GitHub 이슈에는 temperature 0에서 여섯 번 연속 실행한 점수가 27, 34, 32, 34, 34, 30으로 기록돼 있습니다.

temperature 0은 이론상 가장 결정론적인 설정입니다. 그런데도 흔들립니다. 여기서 하나는 분명히 해두고 싶습니다. 이 비결정성은 파인튜닝으로 없앨 수 있는 버그가 아닙니다. 근본적인 설계 결함입니다.

모델이 약해서 그런 건 아닐까 싶어 Gemini로도 돌려봤습니다.

분포는 48점에서 64점으로 확실히 좁아졌습니다. 개선은 맞습니다. 그런데 커트라인이 60점인 회사라면, 저는 아무것도 바꾸지 않은 채로 어떤 날은 통과하고 어떤 날은 떨어집니다. 범위가 줄었을 뿐 성질은 그대로인 거죠.

흥미로운 건 항목별로 개선폭이 달랐다는 점입니다. 오픈소스 점수는 모델을 바꾸자 일관되게 나오기 시작했습니다. 이건 진짜 개선입니다. 반면 프로젝트 점수는 여전히 사방으로 튀었습니다. 모델을 키워도 판단 항목은 안 잡힙니다.

---

잠깐, 광고 하나 하고 가겠습니다

원문은 아직 안 끝났습니다. 여기서 한 번 끊고 제 얘기를 하겠습니다.

여기까지 읽으면 남는 질문이 하나 있죠. AI가 매긴 총점은 못 믿겠는데, 그럼 내 이력서가 실제로 괜찮은지는 어떻게 아느냐.

먼저 솔직하게 말씀드릴게요. 제가 최근에 만든 DevPill 커리어도 LLM으로 돌아갑니다. 위 글의 비판에서 자유롭지 않죠. 그래서 만들 때 세 가지를 못 박아두고 시작했습니다.

예를 들어 치환 검증은 이렇게 굴러갑니다. "팀원들과 원활히 협업하여 프로젝트를 성공적으로 완수했습니다"라는 문장은 옆자리 지원자 이력서에 그대로 붙여도 말이 되죠. 읽는 사람이 얻는 정보가 0입니다. 반면 "BE 2명 중 결제 도메인 단독 담당, 주문·결제 정합성이 깨지는 케이스를 재현해 멱등키를 도입"은 붙일 데가 없습니다. 고유명사와 수치와 범위, 이 셋이 하나도 없으면 그 문장은 거의 항상 치환되죠.

크래프톤 정글 이력서 특강 세 개 차수에서 100명 넘는 분들께 썼던 기준을 그대로 옮겼습니다. 무료이고, PDF 한 장이면 됩니다.

[내 이력서 진단받기 — devpill.kr]

자, 원문으로 돌아가겠습니다. Dan이 가장 걱정스럽다고 한 항목이 남아 있습니다.

가장 걱정스러운 항목은 경력이었습니다

경력은 매번 25점 만점이었습니다. 100번 중 100번, 단 한 번의 예외도 없이요.

처음엔 제 이력서가 좋아서 그런 줄 알았습니다. 확인 삼아 인턴 경력 하나만 적혀 있는 옛날 이력서를 꺼내 돌려봤는데, 그것도 25/25가 나왔습니다.

단서는 프롬프트에 있었습니다. 오픈소스라 누구나 열어볼 수 있는데, 경력 채점 지시문 전체가 두 줄입니다. 'work'와 'volunteer' 섹션에서 실무·인턴·프로덕션 경험을 분석하라는 것, 그리고 창업자나 공동창업자, 초기 멤버(1~20번째 직원) 역할에 가산점을 주라는 것. 그게 끝입니다.

루브릭이 없습니다. 예시도 없습니다. 무엇이 15점을 받고 무엇이 25점을 받는지 가르는 기준점이 아예 존재하지 않습니다. 그러니 인턴 한 번 한 주니어도 25점, 분산 시스템을 10년 다룬 프린시펄 엔지니어도 25점이 나오는 겁니다.

두 항목을 나란히 놓으면 이 도구의 구조적 문제가 선명해집니다.

- 경력: 기준점이 없어서 일관됩니다. 그런데 모두에게 만점을 주니 변별이 안 됩니다.

- 프로젝트: 상세한 루브릭과 예시가 있습니다. 그런데 가장 시끄럽습니다.

기준이 없으면 일관되지만 쓸모없고, 기준이 있으면 흔들립니다. 프롬프트를 아무리 정성껏 써도 LLM이 잘 못 하는 일이라는 게 있다는 뜻이죠.

결국 무엇이 문제인가

이 도구는 LLM을 잘하는 자리와 못하는 자리에 뒤섞어 쓰고 있습니다.

이력서를 구조화된 데이터로 파싱하는 것. 훌륭합니다. LLM이 가장 잘하는 일입니다. 이 사람이 Python을 아는지 확인하는 것도 놀랍도록 잘합니다. 그런데 이 지원자의 경력이 18점짜리인지 24점짜리인지 판정하라고 하면, 돌아오는 건 그냥 감입니다. HR 팀을 두고 바 레이저(채용 기준선을 지키는 전담 면접관)를 붙이면서, 수십 년 동안 온갖 채용 제도가 없애려고 애써온 바로 그 감이요.

배점 구조도 문제를 키웁니다. 오픈소스와 개인 프로젝트에 65%가 걸려 있습니다. 저라면 인턴 두 번에 오픈소스 프로젝트 하나 있는 사람보다 S3를 만든 30년차 엔지니어를 뽑겠습니다. 그런데 이 도구는 그렇게 하지 않습니다. 제가 아는 최고의 엔지니어 중 몇몇은 GitHub에 한 줄도 올린 적 없는 것들을 만들었는데, 그 사람들은 사람이 이력서를 열어보기도 전에 점수의 절반 이상을 잃고 시작합니다.

그래서 회사의 이력서 스크리닝 방식에 조금이라도 발언권이 있는 엔지니어라면, AI 스크리닝 도구는 아주 조심해서 다루시길 바랍니다. 변별하지 못하는 도구는 품질을 거르는 게 아닙니다. 그냥 거르는 겁니다.

글이 퍼진 뒤에 밝혀진 두 가지

이 글은 Hacker News에서 1,000포인트를 넘기며 크게 퍼졌고, 그 과정에서 두 가지가 추가로 확인됐습니다.

하나는 채점 템플릿의 대상 직급이 "Software Intern"으로 하드코딩돼 있다는 독자 제보였습니다. 문서화된 적도 없고 저장소 어디에서도 참조되지 않는 값인데, 뒤에서는 창업자와 초기 멤버 역할에 보너스를 주는 바로 그 템플릿에 들어 있었습니다. Senior SWE로 명시해 다시 돌려봤지만 결과는 동일했습니다. 채점 차원 자체가 직급과 무관하게 굴러가고 있었던 겁니다.

다른 하나는 "프론티어 모델을 쓰면 다르지 않냐"는 지적이었습니다. Claude Opus 4.8로 크레딧이 소진될 때까지 루프를 돌린 결과, 범위는 48~64에서 49~63으로, 프로젝트 항목은 12~25에서 13~23으로 아주 조금 좁아졌습니다. 결론은 바뀌지 않았습니다. 프로젝트는 여전히 비일관적이고, 스킬은 여전히 완벽합니다.

---

DevPill's 인사이트

저는 이 글에서 세 가지를 건졌습니다.

첫째, 서류 탈락을 전부 자기 탓으로 돌리지 마세요. 적어도 이런 도구를 쓰는 회사라면 결과의 일부는 운입니다. 물론 운 탓만 하고 앉아 있을 수는 없죠.

둘째, 기계가 일관되게 읽는 항목은 무조건 잡고 가세요. 기술 스킬처럼 대조표로 끝나는 영역은 100번을 돌려도 거의 안 흔들렸습니다. 흔들리지 않는 자리에서 점수를 흘리는 건 순수한 손해죠.

셋째, 판단이 필요한 영역은 사람 기준으로 쓰세요. 고유명사, 수치, 그리고 되돌린 흔적. 기계는 이 앞에서 흔들리지만 사람은 정확히 이것만 봅니다.

그런데 이 글을 덮고 나서 더 오래 남은 건 따로 있었습니다. 이건 채용 도구 하나의 결함 이야기가 아니라, 지금 여기저기서 동시에 벌어지고 있는 일의 한 조각이라는 생각이 들었죠.

AI에게 일을 넘기면, 검증 지점이 다른 데로 옮겨갑니다.

문장을 다듬는 일, 경험을 성과처럼 정리하는 일, 두서없는 내용을 한 장으로 압축하는 일. 이제 AI가 30분이면 다 해주죠. 그래서 잘 쓴 이력서의 가격은 0이 됐고, 서류만으로는 지원자를 구분할 수 없게 됐습니다. 구분이 안 되니 검증은 면접으로 넘어갔고요.

면접관은 이제 이력서에 적힌 줄을 하나씩 짚으면서 묻습니다. "이거 실제로 어떻게 하셨어요?" 이력서에 적은 모든 줄이 시험 문제가 된 겁니다. 기준이 "잘 썼는가"에서 "진짜인가"로 넘어간 거죠.

앞으로 이 뉴스레터에서는 이렇게 옮겨간 검증 지점을 계속 쫓아가 보려고 합니다. 커리어와 이력서, 조직이 AI를 도입할 때 실제로 무너지는 자리, 그리고 만든 걸 배포하기 전에 확인해야 하는 것들까지요. 물론 오늘처럼 좋은 해외 아티클을 번역해 소개하는 일은 그대로 계속하고요. 주제가 넓어지는 만큼 원하는 것만 골라 받으실 수 있게 하는 것도 숙제로 안고 있습니다.

---

그리고 230일 만에 인사드립니다

눈치채셨겠지만 이 뉴스레터, 작년 12월 11일 이후로 230일 동안 나가지 않았습니다.

회사에서 AX 팀을 맡았고, 밖에서는 파트 CTO로 세 팀을 보고 있고, 그 사이에 제품을 만들었습니다. 매주 한 편이 계속 뒤로 밀렸죠. 이유는 그게 전부입니다. 그런데 그 230일 동안 구독을 끊지 않고 계신 분들이 있었고, 그게 좀 염치없어서 다시 앉았습니다.

이번엔 안 끊기게 만들 방법도 같이 손봤습니다. 매주 손으로 처음부터 쓰는 구조가 세 번 다 저를 무너뜨렸으니까요. 그래서 백지에서 시작하는 구조를 없애기로 했습니다. 읽을거리를 모으고 초안을 세우는 데까지는 AI에 넘기고, 제가 하는 일은 고르고 다듬고 보내는 것만 남길 생각입니다. 잘 굴러가는지는 몇 달 지켜봐 주세요. 안 되면 그것도 여기에 쓰겠습니다 :)