LLM에게 사실 정보 없이 채용 공고를 작성하게 했을 때, 모델은 무엇을 약속하는가?

이 글은 Kaggle Benchmarking Challenge에 제출하는 내용입니다.

채용 공고는 길다. 나는 처음부터 끝까지 읽는다. 그 후에는 훑어본다. 구체적인 부분, 즉 급여(pay), 사용 스택(stack), 팀 규모(team size), 근무 장소(where the work happens), 온콜(on-call) 방식 등만 찾는다. 나머지 모든 것은 내가 건너뛰는 법을 배운 내용의 채움말이다.

또한 나는 모든 문장을 일일이 맞춰서 지원하지 않는다. 구체적인 무언가가 눈에 띄었을 때 지원한다.

요즘 이런 공고들은 점점 LLM(대규모 언어 모델)에 의해 작성된다. 그래서 나는 알고 싶었다. 만약 어떤 모델에게 아무런 사실 정보도 주지 않고 채용 공고를 쓰게 한다면, 그것은 무엇을 약속하게 되는가?

내가 벤치마킹한 내용

나의 주요 목표는 Kaggle Benchmarks를 시도하는 것이었다. 나는 이미 이전 프로젝트에서 점수 계산 방식을 가지고 있었기 때문에, 이를 Kaggle 노트북으로 옮겼다. 약 이틀 만에 빈 노트북이 공개 리더보드까지 올라갔다.

과제. 모든 모델은 동일한 간략 지침을 받는다: 역할(role), 직급(seniority level), 그리고 공고가 다루어야 할 주제들이다. 현재 리더보드의 간략 지침은 주니어 백엔드 엔지니어이다. 이 공고는 서비스, 언어 및 데이터 저장소, 코드 리뷰, 팀 규모, 근무 장소, 급여, 그리고 첫 6개월에 대해 다루어야 한다. 이 지침에는 회사 이름이나 사실 정보가 명시되어 있지 않다.

모델은 각 주제마다 세 가지 옵션을 갖는다:

• 구체적인 내용 발명:

판단기(judge)는 그 자체만으로는 신뢰할 수 없다. 코드가 호출마다 규칙을 강제한다:

• 광고의 문자 그대로의 하위 문자열이 아닌 주장은 거부된다.
• '구체적인(concrete)' 레이블은 특정 내용을 인용해야 하며, 이 인용문은 주장 안에 나타나야 한다. 그렇지 않으면, 그 주장은 일반 방향으로 격하된다.
• "[급여 범위]" 또는 "€XX,XXX"와 같은 템플릿 빈칸은 플래그가 지정되며 결코 구체적인 내용으로 간주되지 않는다.
• "영어(English)\

리더보드는 두 쌍으로 나뉜다. Claude Haiku 4.5와 Gemini 3.7 Flash는 자신들의 주장 중 약 절반에 구체적인 내용을 담는다. Gemini 2.5 Flash와 GPT-5.4 mini는 약 3분의 1 정도를 차지한다.

아직 순위로 읽지 마십시오. 현재 리더보드는 짧은 테스트를 진행했기 때문에, 각 점수는 대략 30개의 주장을 담은 하나의 광고에 해당합니다. Gemini 3.7 Flash의 경우, 29개 중 14개가 구체적이어서 약 0.31에서 0.66 사이의 95% 구간을 형성합니다. 보드 위의 모든 모델이 이 구간 내에 위치합니다. 두 쌍은 결과를 나타내는 것이 아니라 확인해 볼 방향입니다.

심사위원(judge)은 이 광고들에서는 측정되지 않습니다. 실제 공고의 경우, 규칙의 초기 버전은 구체적인 내용/구체적이지 않은 내용 경계에서 제 수동 라벨과 86.7%의 일치율을 보였습니다. 그것은 다른 심사 모델이었고 더 오래된 프롬프트에 기반한 것이었습니다. 아무도 생성된 광고들에 대해 이 심사 위원을 수동으로 검토하지 않았습니다.

Grok 4.5는 실패했으며, 이는 의도된 것입니다. 이 작업은 모든 간결한 설명(brief)이 점수화되지 않으면 점수를 공개하기를 거부합니다. 하위 집합의 간결한 설명을 걸쳐 평균을 내는 것은 다른 벤치마크이며, 그렇지 않은 경우와 동일하게 리더보드에 나타날 것입니다.

Kaggle 측에서 놀라웠던 점:

• 작업은 숫자(number), 부울(bool) 또는 딕셔너리(dict)를 반환해야 합니다. 문자열을 반환하면 저장되지 않습니다.
• 추론 모델은 JSON 앞에 <think> 텍스트를 배치합니다. 그러면 내장된 스키마 파서가 실패하므로, 심사위원이 직접 JSON을 구문 분석합니다.
• %choose는 메인 작업의 가장 최근 실행만 유지합니다. 노트북에서 한 번 실행한 다음, 작업 페이지에서 모델들을 추가하십시오.
• 모델 이름에 /가 포함되어 있습니다. 파일 이름으로 사용하기 전에 이를 정리(sanitize)하십시오.

여기서 모델 선택이 중요한 이유. 광고는 많고 길습니다. 광고에서 실제 주장을 추출하는 데 노력이 필요하며, 그 노력은 양쪽의 모델 모두에게 영향을 미칩니다. 고용주의 모델은 무엇이 약속되는지 결정하고, 지원자의 모델은 무엇이 구체적인 내용으로 간주되는지를 결정합니다. 작성 측에서 잘못된 모델을 선택하면 지어낸 급여를 얻게 됩니다. 읽기 측에서 잘못된 모델을 선택하면

• 총 20개의 공고(briefs)와 각 샘플들. 이 공고들은 이미 인턴부터 프린서플까지, 프론트엔드부터 프로덕션 지원에 이르기까지 다루고 있습니다. 모델당 광고 하나로는 충분하지 않습니다.
• 생성된 주장(claims) 샘플에 대한 심사위원의 수동 검토. 제가 실제 공고에서 확인했던 방식과 동일합니다.
• 주제별 분할. 급여가 흥미로운 부분입니다: 지어낸 숫자, 플레이스홀더, 또는 '경쟁력 있는'이라는 표현입니다.
• 광고가 올바른 사람들을 끌어들이는지 여부. 이것이 가장 중요한 측정 기준이며, 구체성은 단지 하나의 입력 요소일 뿐입니다. 여기에는 결과 데이터가 필요합니다: 누가 지원했는지, 그리고 몇 명이 자격 요건을 갖추었는지에 대한 데이터입니다. 이 데이터는 고용주와 채용 게시판에 있으며, 공개 벤치마크에는 없습니다.

나의 벤치마크

Kaggle 벤치마크

공고(Briefs), 프롬프트, 그리고 심사위원 코드는 노트북에 있습니다. 티어별 방법론은 리포지토리에서 확인할 수 있습니다: github.com/kargut/job-posting-specificity.

채용 공고를 읽을 때, 무엇이 당신으로 하여금 지원하게 만드나요: 구체적인 세부 사항인가요, 아니면 완전히 다른 무언가인가요?