Assessment Engineering

---
name: assessment-engineering
description: "퀴즈출제자(quiz-maker)가 사용하는 평가 공학 전문 스킬. 문항 유형별 설계, 오답지 설계 심리학, 루브릭 구축, 형성평가/총괄평가 전략을 제공한다. '퀴즈 설계', '평가 문항', '루브릭', '시험 출제' 등에 활용한다."
---

# Assessment Engineering — 평가 공학 방법론

quiz-maker 에이전트가 형성평가/총괄평가를 설계할 때 활용하는 평가 전문 지식.

## 왜 평가 공학인가

좋은 평가는 학습자의 이해도를 **정확히 측정**하는 동시에 **학습을 강화**한다. 나쁜 평가는 암기를 보상하고, 좋은 평가는 이해를 보상한다.

## 문항 유형별 설계 가이드

### 1. 객관식 (Multiple Choice)

| 요소 | 규칙 |
|------|------|
| **문두 (Stem)** | 독립적으로 읽었을 때 질문이 명확해야 한다 |
| **정답 (Key)** | 명백하게 최선의 답이어야 한다 |
| **오답지 (Distractor)** | 그럴듯하되 명확히 틀려야 한다 (아래 상세) |
| **선택지 수** | 4개 (5개는 의미 없는 오답 증가, 3개는 찍기 확률 33%) |
| **선택지 길이** | 비슷한 길이 유지 (정답이 가장 긴 것은 단서 유출) |

### 오답지(Distractor) 설계 심리학

| 오답 유형 | 목적 | 예시 (질문: "REST에서 리소스 삭제에 사용하는 HTTP 메서드는?") |
|----------|------|------|
| **흔한 오해** | 잘못된 지식 진단 | "POST" (생성과 삭제 혼동) |
| **부분 정답** | 피상적 이해 진단 | "PUT" (수정과 삭제 혼동) |
| **관련 개념** | 개념 간 구분 진단 | "PATCH" (부분 수정, 유사 개념) |
| **정답**: | | "DELETE" |

### 2. 코드 작성 문제

```
[상황 설정]
다음 요구사항을 만족하는 함수를 작성하세요.

[입력/출력 명세]
- 입력: [타입과 범위]
- 출력: [타입과 조건]
- 제약: [시간/공간 복잡도, 금지 사항]

[예시]
입력: [예시 입력]
출력: [예시 출력]

[평가 기준]
- [ ] 정확성: 모든 테스트 케이스 통과
- [ ] 코드 품질: 가독성, 네이밍
- [ ] 효율성: 시간/공간 복잡도
```

### 3. 시나리오 기반 문제

```
[시나리오]
당신은 ~한 상황에 있습니다. [구체적 상황 묘사]

[질문]
이 상황에서 가장 적절한 [행동/설계/해결책]은 무엇인가?

[평가 관점]
- 문제 식별 능력
- 해결 전략의 적절성
- 트레이드오프 인식
```

## 형성평가 vs 총괄평가

| 속성 | 형성평가 (Formative) | 총괄평가 (Summative) |
|------|-------------------|-------------------|
| **시점** | 학습 중 (매 레슨) | 학습 완료 후 (모듈 끝) |
| **목적** | 이해 확인, 즉시 교정 | 성취 측정, 등급 부여 |
| **분위기** | 부담 없음, 연습 | 공식적, 최종 |
| **문항 수** | 3~5개 | 10~20개 |
| **피드백** | 즉시, 상세 | 완료 후, 총합 |
| **재응시** | 무제한 | 1~2회 |
| **블룸 수준** | 1~3 (기억, 이해, 적용) | 3~6 (적용~창조) |

### 형성평가 설계 원칙

1. **매 레슨 끝에 3~5문항**: 핵심 개념 확인
2. **즉각적 피드백**: 정답/오답 + "왜 이것이 정답인가" 설명
3. **오답 시 학습 유도**: "이 부분을 다시 확인해보세요: [섹션 링크]"
4. **난이도 순서**: 쉬움→어려움 순서로 배치 (자신감 구축)

### 총괄평가 설계 원칙

1. **학습목표 100% 커버**: 모든 학습목표가 최소 1개 문항에 매핑
2. **블룸 분포**: 기억 20% + 이해 20% + 적용 30% + 분석/평가/창조 30%
3. **시간 배분**: 문항당 2~3분, 전체 30~60분
4. **실전 가중치**: 실습/프로젝트가 총점의 40~60% 차지

## 루브릭 (Rubric) 구축

### 분석적 루브릭 템플릿

| 기준 | 우수 (4점) | 양호 (3점) | 보통 (2점) | 미흡 (1점) |
|------|-----------|-----------|-----------|-----------|
| **기능 구현** | 모든 요구사항 충족 | 90% 충족 | 70% 충족 | 50% 미만 |
| **코드 품질** | 깔끔, 일관된 스타일 | 대체로 깔끔 | 일부 비일관 | 가독성 낮음 |
| **에러 처리** | 모든 엣지 케이스 | 주요 케이스 | 기본 케이스만 | 에러 처리 없음 |
| **문서화** | 상세한 주석+README | 주요 함수 주석 | 최소 주석 | 주석 없음 |

### 루브릭 작성 규칙

1. **관찰 가능한 행동으로 기술**: "잘 이해했다" 대신 "~을 설명할 수 있다"
2. **수준 간 차이가 명확**: 각 수준이 명백히 구분되어야 한다
3. **3~5개 기준**: 너무 많으면 평가가 비현실적
4. **학습자에게 사전 공개**: 평가 전에 루브릭을 보여줘야 학습 방향 설정

## 피드백 설계

### 효과적 피드백 공식: EEC

```
E (Evidence): "당신의 코드에서 에러 처리가 없습니다"
E (Effect): "이 경우 사용자가 빈 값을 입력하면 프로그램이 충돌합니다"
C (Change): "try-except 블록으로 감싸고, 사용자에게 안내 메시지를 보여주세요"
```

### 피드백 규칙

- **구체적**: "좋아요" 대신 "변수명이 기능을 잘 설명합니다"
- **즉각적**: 제출 후 가능한 빨리 (자동 테스트 우선)
- **행동 지향**: 다음에 무엇을 해야 하는지 알려준다
- **긍정 먼저**: 잘한 점 → 개선점 → 다음 단계