이 글에서 소개하는 도구는 웹에서 바로 열어볼 수 있습니다 — 추정 분할 점수 계산기 열기.

이 글의 문제의식

학기 말에 시험을 출제한 교사에게 남는 일은 점수 산출이 아닙니다. 산출은 컴퓨터가 해줍니다. 남는 일은 "이번 시험에서 A는 몇 점부터, B는 몇 점부터로 잡을지"를 결정하는 것입니다. 이 숫자를 분할점수라고 부릅니다. 그리고 여기서 교사 대부분은 망설입니다.

망설임의 정체는 단순합니다. 교사가 감으로 가지고 있는 것은 "이 문항은 대략 몇 퍼센트가 맞힐 것 같다" 정도입니다. 그런데 분할점수는 그것보다 훨씬 복잡한 요구를 합니다 — 난이도별로, 성취도 등급별로, 각각의 "예상 정답률"을 매트릭스로 넣어야 합니다. 사이에 수학이 필요합니다. 그리고 그 수학은 교사의 일이 아닙니다.

왜 이 문제가 교육 현장에서 중요한가

분할점수를 감으로 쓴다는 것의 진짜 비용은 결과에서 드러납니다. 많은 교사가 "90점, 80점, 70점…" 같은 일반적 절대 기준을 먼저 쓰고, 그 다음에 NEIS에서 나온 성취도 비율을 확인합니다. 비율을 본 순간 얼굴이 굳는 경우가 생깁니다.

A가 80% 이상 나오기도 합니다. 시험이 쉬웠다는 뜻이지만, 등급 구분이 유명무실해집니다. 반대로 A가 0%일 때도 있습니다. 아무도 90점 이상을 받지 못한 것입니다. 어느 쪽이든 다시 돌아가 분할점수를 고쳐야 합니다.

이 수정 과정이 반복되면 교사는 "시험 채점은 다 끝났는데 등급 매기는 일에서 자꾸 돌아오는" 피로를 겪습니다. 문제는 이 피로가 매 시험마다 반복된다는 점입니다. 비싸고 사라지지 않는 마찰입니다. 이 마찰은 기술의 문제가 아니라 교사가 자연스럽게 가진 예측 언어와, 시스템이 요구하는 입력 언어가 다르기 때문에 생깁니다.

접근 방식

이 프로젝트는 그 피로를 단 한 번의 수학적 변환으로 대체해보고 싶었습니다. 교사가 할 수 있는 예측은 문항별 정답률 예상이라는 것 — 여기서 출발했습니다.

그래서 입력 화면은 교사의 직관과 정확히 같은 층위에서 작동합니다. 각 문항에 대해 "이 문항은 대략 몇 % 정도 맞을 것 같다"만 적으면 됩니다. 난이도도 "쉬움 · 보통 · 어려움" 3단계에서 고르면 됩니다. 여기까지가 교사가 가진 언어입니다.

그 뒤는 앱의 일입니다. 앱은 그 정답률 감각을 표준정규분포와 Rasch 모형을 거쳐, 각 성취도 등급의 경계에 서 있는 학생이 그 문항을 맞힐 확률로 바꿔 계산합니다. 그 확률들을 배점으로 가중 평균해서 등급별 예상 정답률이 나오고, 최종적으로 5점 단위로 반올림된 분할점수가 나옵니다.

이 수학을 쉽게 가느냐 복잡하게 가느냐는 초기부터 고민이었습니다 — 단순 가중 평균으로 둘러댈 수도 있었습니다. 하지만 테스트를 진행하면서 방향이 분명해졌습니다. 복잡한 쪽이 실제로 더 납득이 가는 답을 냈습니다. 그래서 수학적으로는 치밀한 쪽으로 갔습니다. 대신 그 치밀함을 교사에게 드러내지 않는 것을 설계의 목표로 삼았습니다.

구현 내용

원칙은 두 가지였습니다.

1. 입력 화면은 교사의 직관과 1:1로 연결한다.

복잡한 수학이 뒤에 있어도, 교사가 손대는 입력은 정답률과 난이도뿐이어야 했습니다. 그 외의 변수 — 등급 경계의 z값, 항목 난이도 계수, 정규분포 역함수 같은 것 — 는 단 한 글자도 화면에 나오지 않습니다. 교사가 수학을 다루는 게 아니라, 수학이 교사를 돕는 구조를 만드는 것이 우선이었습니다.

2. 결과는 반드시 "왜 이 숫자인가"를 설명할 수 있어야 한다.

블랙박스를 만들면 교사는 안 씁니다. 분할점수는 학생의 성적표에 직접 영향을 주는 숫자이기 때문에, "컴퓨터가 알아서 해줬습니다"로 넘길 수 없습니다. 그래서 결과 테이블의 각 셀을 클릭하면 해당 등급 경계의 학생이 각 문항을 맞힐 확률이 어떻게 계산됐는지 전부 펼쳐서 보여줍니다. 배점이 어떻게 가중됐는지, 5점 단위 반올림이 어떻게 적용됐는지도 같이 드러납니다. 이 팝오버가 없으면 앱을 못 쓴다고 생각했습니다 — 그게 처음부터의 전제였습니다.

여기에 입력 검증을 얇게 한 겹 덧댔습니다. 등급 분포의 합이 100이 아니면 에러로 막았습니다. 전체 문항 정답률이 극단적으로 낮거나 높으면 경고를 띄웠습니다. 미도달을 별도로 잡는 모드에서는 예상 미도달율이 0일 때 따로 경고가 나옵니다. 과하게 막지는 않되, 교사가 눈으로 놓칠 만한 가비지 입력은 앞에서 거르자는 정도의 선입니다.

배운 점

이 프로젝트에서 가장 분명하게 배운 두 가지가 있습니다.

첫 번째는 교사의 직관과 수학 모델의 접점을 찾는 것이 설계의 절반이라는 것이었습니다. Rasch 모형을 있는 그대로 노출했다면 아무도 이 앱을 안 썼을 겁니다. 교사의 입력창은 Rasch를 전혀 모르는 사람의 언어 — "이 문항 정도면 몇 % 맞을 것 같다" — 까지 낮춰져 있어야 했습니다. 그 낮추는 작업이, 수학을 덧붙이는 작업보다 훨씬 더 어려웠습니다.

두 번째는 시각적 투명성이 신뢰를 만든다는 것이었습니다. 셀 팝오버를 열면 속에서 Rasch가 돌고 있다는 사실이 고스란히 드러납니다. 수학을 숨긴 게 아니라, "궁금할 때는 언제든 꺼내볼 수 있게" 뒤쪽에 정리해 둔 것입니다. 교사가 이 숫자를 학생들 성적표에 적으려면, "이 숫자가 어디서 왔는지 내가 설명할 수 있다"는 감각이 필요했습니다. 팝오버는 그 감각을 책임지는 장치였습니다.

기술적으로는 수학 엔진에 55개 이상의 테스트 케이스를 깐 것이 의외로 큰 역할을 했습니다. 등급 경계의 정확성을 초기부터 테스트가 보장해주고 있었기 때문에, 그 위에 UI를 얹는 과정이 마음이 편했습니다. "계산이 이상하면 테스트가 먼저 비명을 지른다"는 믿음이 있어야, 남은 시간을 사용자 경험에 쓸 수 있습니다.

다음 단계

이제 할 일은 글을 쓰는 일이 아니라, 교사의 책상 위에서 앱이 어떻게 쓰이는지를 지켜보는 일입니다. 실제 현장 교사들의 피드백을 받고, 입력창 표현 · 결과 테이블의 가독성 · 모바일 터치 반응 같은 부분을 계속 다듬을 예정입니다.

분할점수 산출은 교사의 여러 반복 업무 중 하나일 뿐입니다. 하지만 그 한 마디의 감각 — "내가 정답률만 생각해도 수학이 나머지를 채워줄 수 있다" — 이 앱 하나에서 자리를 잡는다면, 현장의 다른 영역에도 비슷한 접근을 시도해볼 수 있을 겁니다. 감은 감의 자리에, 수학은 수학의 자리에 두고, 그 사이의 번역만 도구가 맡는 방식으로.