Psychometrics와 Situational Judgment Test 설계

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L11-80 (평가), L12-90 (LLM 평가), L12-140 (역량 모델링)

Psychometrics와 Situational Judgment Test 설계 — Reliability, Validity, Scoring, Bias

1. 한 줄 정의

Psychometrics는 사람의 능력·성향·역량을 측정하는 도구의 신뢰도와 타당도를 다루는 분야이고, SJT(Situational Judgment Test)는 실제 업무 상황을 제시한 뒤 선택/서술 응답으로 판단·행동 역량을 평가하는 문항 형식이다.

2. 왜 중요한가

AI 평가 앱의 근거: LLM이 면접 답변, 상담 품질, 업무 역량을 평가하려면 측정 기준이 심리측정 원칙을 따라야 한다.
편향 통제: 평가 도구는 특정 집단·표현 스타일에 불리하지 않은지 검증해야 한다.
SJT는 agent eval에도 유용: “상황 → 선택지 → 판단 이유” 구조는 AI agent 행동 평가에도 잘 맞는다.
LLM-as-judge 보정: judge prompt는 rubric만으로 부족하고 reliability/validity 검증, judge calibration, drift monitoring이 필요하다.
법적·윤리적 리스크: 채용·승진·교육 평가에 쓰면 설명 가능성과 감사 가능성이 필수다.

2.5 선행 기술의 한계 — 인상 평가와 단일 점수의 위험

사람이나 LLM에게 “이 답변이 좋은가?”라고 묻는 방식은 빠르지만 측정 도구가 아니다. 평가자가 바뀌면 점수가 바뀌고, 같은 평가자도 순서·문체·길이에 영향을 받는다. LLM judge도 position bias, verbosity bias, self-preference bias를 보인다.

심리측정은 이 문제를 “평가자의 느낌”에서 “측정 도구의 품질”로 바꾼다.

신뢰도(reliability): 같은 능력을 반복 측정할 때 안정적인가
타당도(validity): 정말 측정하려는 역량을 측정하는가
문항 분석(item analysis): 어떤 문항이 너무 쉽거나 변별력이 없는가
공정성(fairness): 집단별로 불리하게 작동하지 않는가

SJT는 업무 상황 기반 평가로, 일반 지식 퀴즈보다 실제 판단과 행동을 더 가깝게 측정하려는 시도다. SJT selection validity에 대한 meta-analysis도 존재한다. 출처: PubMed — Situational judgement test validity for selection: systematic review and meta-analysis.

3. 핵심 개념

3.1 Construct

측정하려는 대상이 construct다.

construct: incident judgment
definition: 장애 상황에서 사용자 영향, 원인 가설, 완화 조치를 우선순위화하는 능력
not:
  - AWS 서비스 이름 암기
  - 말투의 자신감

construct 정의가 없으면 문항과 점수는 해석할 수 없다.

3.2 Reliability

유형	의미	AI 평가 적용
Internal consistency	같은 construct 문항들이 일관되게 움직이는가	비슷한 SJT 문항 점수 상관
Inter-rater reliability	평가자 간 일치하는가	human judge vs LLM judge
Test-retest reliability	시간이 지나도 안정적인가	같은 응답 재평가 일관성
Parallel-form reliability	동등 문항 세트가 같은 결과를 내는가	prompt/model 교체 후 비교

LLM judge에서는 temperature, model version, prompt version이 reliability에 영향을 준다. 지표는 상황에 맞게 골라야 한다. 두 명의 평가자가 pass/fail, A/B 선호처럼 범주형 판정을 내리면 Cohen’s kappa를 쓴다. 평가자가 3명 이상이거나 일부 응답만 평가한 누락 데이터가 있으면 Krippendorff’s alpha가 더 잘 맞는다. 여러 SJT 문항을 합쳐 하나의 역량 점수로 보고하려면 Cronbach alpha로 internal consistency를 확인하되, alpha가 높다고 단일 construct가 보장되지는 않는다. UCLA OARC도 alpha를 “scale reliability” 계수로 설명하면서 높은 alpha가 unidimensionality를 의미하지 않는다고 경고한다. 출처: UCLA OARC — What does Cronbach’s alpha mean?, UPenn Annenberg — Krippendorff’s Alpha Reliability.

상황	우선 지표	해석 포인트
human 1명과 LLM 1명의 범주형 판정	Cohen’s kappa	단순 일치율에서 우연 일치를 뺀다
3명 이상 평가자 또는 누락 데이터	Krippendorff’s alpha	평가자 수와 결측이 있는 gold set에 적합하다
여러 문항을 하나의 점수로 합산	Cronbach alpha	문항들이 같은 construct를 보조하는지 본다
threshold 근처 pass/fail 결정	false accept/reject rate	운영 리스크에 맞춰 human review 범위를 정한다

미니 gold set으로는 먼저 단순 판정을 확인한다. 예를 들어 5개 응답에서 human=[pass, pass, fail, fail, pass], LLM=[pass, fail, fail, fail, pass]라면 단순 일치율은 4/5=80%다. pass 비율이 양쪽 모두 높으면 우연 일치도 커지므로 kappa까지 보고, 불일치한 2번 응답이 threshold 근처인지 rubric ambiguity인지 확인한 뒤 배포 여부를 정한다.

3.3 Validity

유형	질문	예시
Content validity	문항이 업무 내용을 대표하는가	실제 incident 시나리오 기반
Construct validity	의도한 역량을 측정하는가	문제해결력과 단순 영어 유창성 분리
Criterion validity	외부 성과와 관련 있는가	평가 점수와 온콜 성과 상관
Face validity	응시자가 납득 가능한가	실제 업무처럼 보이는 상황

타당도는 한 번 “획득”하는 인증서가 아니라 누적 증거다.

Assessment design에서는 이 증거를 나중에 붙이지 않고 처음부터 설계한다. 먼저 업무 성공 기준을 construct로 정의하고, construct별로 문항 수, 상황 범위, 난이도, 채점 방식, human review 조건을 blueprint로 만든다.

assessment_blueprint:
  construct: "incident judgment"
  target_decision: "온콜 훈련 통과 여부"
  scenarios:
    - "배포 직후 오류율 상승"
    - "부분 장애와 고객 영향 불확실"
  item_mix:
    best_answer: 2
    rank_order: 1
    open_response: 2
  validity_evidence:
    content: "실제 incident postmortem에서 상황 추출"
    criterion: "온콜 shadowing 평가와 상관 확인"
  review_rule: "threshold 근처 응답은 human reviewer가 최종 확인"

이 blueprint가 없으면 문항은 그럴듯해도 평가 결과가 어떤 의사결정에 충분한지 말하기 어렵다.

3.4 SJT 문항 구조

situation: "배포 직후 결제 API 오류율이 3%로 상승했다."
stem: "가장 먼저 해야 할 행동은?"
options:
  A: "새 기능을 계속 관찰한다."
  B: "배포를 즉시 롤백하고 영향 범위를 확인한다."
  C: "고객 공지를 먼저 작성한다."
  D: "원인을 찾을 때까지 아무 조치도 하지 않는다."
scoring_key:
  B: 4
  C: 2
  A: 1
  D: 0
competency: "incident judgment"
evidence: "사용자 영향 SLO 우선"

좋은 SJT는 “정답 맞히기”가 아니라 실제 trade-off 판단을 드러낸다. 같은 구조는 HR 밖에서도 그대로 작동한다. incident response에서는 “롤백·완화·공지·원인분석”의 순서를 묻고, customer support QA에서는 “환불 요구·정책 위반·분노한 고객” 사이의 응대 우선순위를 본다. code review eval에서는 “보안 결함을 잡았지만 스타일 지적만 남긴 리뷰”를 낮게 채점하고, agent benchmark에서는 “도구 호출 전에 사용자 권한과 부작용을 확인했는가”를 scoring key에 넣는다. 즉 situation은 도메인별로 바뀌지만 construct, 선택지, 근거, 채점 키를 분리하는 원리는 같다.

3.5 Scoring 방식

Best answer: 가장 적절한 선택지 1개
Rank order: 선택지를 좋은 순서로 정렬
Rate effectiveness: 각 선택지의 효과성을 1~5점으로 평가
Open response: 자유 서술 후 rubric/LLM judge로 채점

Open response는 풍부하지만 채점 reliability를 별도로 검증해야 한다.

3.6 LLM-as-Judge와 Psychometrics 연결

LLM judge는 평가자다. 따라서 운영 절차는 “자동 채점기를 만들었다”가 아니라 “측정 도구를 배포했다”에 가깝다. 먼저 human expert가 만든 gold set을 준비하고, judge prompt와 scoring guide, model version, temperature를 고정한다. 그다음 human-judge agreement를 계산한다. OpenAI는 LLM judge가 80% 이상 human preference agreement에 도달할 수 있지만 position bias와 verbosity bias가 과제라고 설명하고, 자동 점수는 human feedback으로 보정하라고 권고한다. 출처: OpenAI — Evaluation best practices, OpenAI Cookbook — Getting started with OpenAI Evals.

1. human expert gold set 생성
2. LLM judge prompt/scoring guide/model version 고정
3. Cohen's kappa 또는 Krippendorff's alpha로 judge-human agreement 측정
4. 정답 위치, 응답 길이, 문체, 모델 자기선호 bias probe 실행
5. threshold를 정하고 false accept/false reject 사례를 human review
6. 배포 후 drift monitoring으로 model/prompt/log distribution 변화 감시

점수 하나만 저장하지 말고 evidence span과 rationale을 함께 남긴다.

judge calibration은 한 번 맞추고 끝나는 작업이 아니다. 운영 전에는 anchor 응답을 만들고, 사람 평가자와 LLM judge가 같은 anchor를 채점하게 한 뒤 disagreement를 유형화한다. 운영 중에는 새 모델, 새 prompt, 새 rubric을 배포할 때마다 같은 anchor set을 재채점해 기준점이 움직였는지 본다.

calibration loop:
1. construct별 low/medium/high anchor 응답 수집
2. human expert가 점수와 evidence span을 확정
3. LLM judge가 같은 응답을 채점
4. disagreement를 rubric ambiguity, missing evidence, judge bias로 분류
5. rubric anchor와 prompt를 수정하되 gold label 자체는 별도 승인 없이 바꾸지 않음
6. 변경 전후 agreement와 threshold 영향도를 기록

rubric drift는 평가 기준 자체가 조용히 바뀌는 현상이다. 예를 들어 “incident judgment”에서 처음에는 사용자 영향 완화를 가장 높게 봤는데, 몇 달 뒤 원인분석이 자세한 답변에 더 높은 점수를 주기 시작하면 같은 4점도 다른 의미가 된다. 그래서 평가 로그에는 rubric_version, judge_model, prompt_version, anchor_set_version을 함께 저장하고, 월별 점수 분포뿐 아니라 evidence 유형 분포도 비교해야 한다.

3.7 문항 품질 점검

점검	실패 신호	조치
난이도	모두 맞히거나 모두 틀림	선택지 재작성
변별도	고성과자/저성과자 차이 없음	construct와 상황 재검토
cueing	문장 길이로 정답 추측 가능	선택지 길이·톤 균형
construct-irrelevant variance	영어 실력이 점수를 좌우	언어 난이도 통제
adverse impact	특정 집단에 불리	differential item functioning 분석

문항 난이도는 classical test theory에서는 정답률, IRT에서는 50% 정답 확률에 해당하는 능력 위치로 본다. 문항 변별도는 능력이 조금 달라질 때 정답 확률이 얼마나 가파르게 달라지는지다. Columbia Public Health의 IRT 설명처럼 변별도가 음수면 능력이 높을수록 정답 확률이 낮아지는 이상 신호이므로 문항을 폐기하거나 다시 써야 한다. 채용·승진처럼 고위험 의사결정에 연결되면 집단별 선발률도 같이 본다. EEOC의 Uniform Guidelines 해설은 최고 선발률 집단 대비 4/5, 즉 80% 미만이면 adverse impact의 실무 신호로 본다. 출처: Columbia — Item Response Theory, EEOC — Uniform Guidelines Q&A.

3.8 Silent Failure

증상	원인	복구
LLM judge가 긴 답변에 높은 점수	verbosity bias	길이 통제, evidence-first 채점
문항이 너무 쉬움	obvious best answer	distractor 개선
평가 점수가 업무 성과와 무관	construct 정의 부정확	competency question 재정의
사람 평가자끼리 불일치	rubric anchor 부족	anchor 예시와 calibration
모델 업데이트 후 점수 drift	judge version 변경	parallel-form eval, 기준 모델 고정
같은 rubric인데 채점 이유가 변함	rubric drift	anchor set 재채점, rubric versioning

고위험 평가에서는 LLM judge가 최종 결정자가 되면 안 된다. 채용, 승진, 징계, 교육 선발, 신용·보험처럼 개인에게 실질적 영향을 주는 경우에는 human final decision, 감사 로그, appeal 경로, adverse impact review를 배포 조건으로 둔다. EU AI Act 안내도 고위험 AI에 documentation, traceability, transparency, human oversight, lifecycle monitoring을 요구하고, Article 14 관련 설명은 감독자가 개입·중지할 권한과 역량을 가져야 한다고 말한다. NIST AI RMF도 조직이 AI 위험관리를 운영 가능한 절차로 만들도록 설계된 프레임워크다. 출처: European Commission — Navigating the AI Act, AI Act Service Desk — Recital 73, NIST — AI RMF 1.0.

Low-stakes 평가(연습 피드백, 내부 QA 샘플링)는 feature flag로 일부 트래픽에 먼저 적용하고 disagreement와 appeal 로그를 본다. High-stakes 평가(채용, 승진, 선발)는 rollout flag가 켜져도 LLM 점수를 추천 신호로만 쓰고, human review와 공정성 점검을 통과한 뒤에만 의사결정에 연결한다.

4. 실무에서 어디에 쓰이나

채용 SJT와 면접 답변 평가 보조
고객지원 상담 품질 평가
AI agent의 상황 판단 benchmark
교육/코칭 앱의 역량 진단
보안·운영 사고 대응 훈련 평가

5. 현재 내 업무와 연결점

학습 문서 하네스도 넓게 보면 심리측정과 비슷하다. “좋은 문서”라는 construct를 rubric으로 쪼개고, evaluator 간 일관성·score drift·개선 후 재평가를 관리한다. LLM 평가 시스템을 만들 때도 같은 질문이 필요하다. 무엇을 측정하는가, 같은 결과가 반복되는가, 실제 목표와 관련 있는가.

실무적으로는 평가 도구를 만들 때 “프롬프트가 잘 채점하는가”보다 먼저 “이 점수로 어떤 결정을 해도 되는가”를 묻는다. 그 답이 채용 합격, 교육 통과, agent 배포 승인처럼 무겁다면 reliability/validity 증거, judge calibration 기록, rubric drift 모니터링이 모두 제품 요구사항이 된다.

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Reliability	Validity	반복 측정 안정성 vs 측정 대상의 적절성
SJT	Knowledge test	상황 판단/행동 선택 vs 지식 암기
Rubric	Scoring key	rubric은 기준 설명, scoring key는 점수 매핑
Bias	Error	bias는 체계적 편향, error는 무작위 오차
Criterion validity	Face validity	성과와의 관련성 vs 겉보기 납득 가능성

7. 체크리스트

평가하려는 construct를 한 문장으로 정의할 수 있다.
SJT 문항의 situation, stem, options, scoring key를 분리할 수 있다.
reliability와 validity의 차이를 설명할 수 있다.
LLM judge를 평가자로 보고 inter-rater agreement를 측정할 수 있다.
assessment blueprint로 construct, 문항 구성, 의사결정 기준을 연결할 수 있다.
anchor set으로 judge calibration과 rubric drift를 점검할 수 있다.
문항 난이도·변별도·편향을 점검할 수 있다.

8. 추가 학습 키워드

psychometrics, situational judgment test, assessment design, construct validity, inter-rater reliability, item analysis, differential item functioning, judge calibration, rubric drift, rubric calibration, criterion validity, adverse impact

9. 내가 직접 확인해볼 것

“장애 대응 판단력” construct 정의와 SJT 문항 3개 작성
같은 응답 50개를 human rubric과 LLM judge로 채점해 agreement 계산
선택지 길이와 정답 위치를 바꿔 position/verbosity bias 확인
문항별 정답률과 고득점자/저득점자 차이 분석

10. 5줄 요약

Psychometrics는 평가 도구가 안정적이고 적절한지 검증하는 관점이다.
SJT는 실제 업무 상황 속 판단과 행동을 측정하는 문항 형식이다.
좋은 평가에는 construct 정의, rubric, 신뢰도, 타당도, 공정성 검토가 필요하다.
LLM judge도 평가자이므로 사람 평가자와 같은 calibration과 bias 점검이 필요하다.
AI 평가 앱에서 점수보다 중요한 것은 점수의 근거와 측정 품질이다.

11. 출처

최종 수정: 2026-05-22