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를 한 적도 없고, 이력서에 했다고 적지도 않았음