학습자의 실수를 만들 수 있어야 평가도 빨라진다

제일 먼저 든 생각

교육평가에서 제일 답답한 순간은 좋은 문항이나 과제를 만들었는데, 실제 학습자 데이터가 쌓이기 전까지 무엇이 어려운지 알기 어렵다는 점이다. 특히 프로그래밍 교육처럼 오류의 모양이 다양한 영역에서는 더 그렇다. 학생들이 실제로 어떤 실수를 할지 모르면 피드백도, 튜터링도, 대시보드도 늦게 따라온다.

이 논문은 그 빈칸에 LLM을 조심스럽게 넣어본다. 질문은 단순하다. LLM이 학생처럼 틀릴 수 있는가. 더 정확히는, LLM이 만든 Java 코드 오류가 실제 학생의 오류와 얼마나 다양하고, 얼마나 비슷한가를 본다.

이 그림은 논문을 읽기 위한 작업용 요약이다. 핵심은 “그럴듯한 오류 생성”도 다양성과 실제 학생 오류와의 정렬을 따로 봐야 한다는 점이다.

학생 데이터를 기다리지 않고도 볼 수 있는 것

연구진은 CodeWorkout 데이터셋의 37개 문제와 74,000개가 넘는 고유 학생 Java 제출물을 사용한다. 다섯 개 LLM을 대상으로 입력-출력 프롬프트(Input-Output), 사고 과정 유도(Chain-of-Thought), 반복 자기수정(Self-Refine) 방식 등을 비교한다.

평가 기준은 크게 두 가지다.

• 다양성(diversity): 서로 다른 오류 패턴을 얼마나 넓게 만들어내는가
• 정렬(alignment): 그 오류가 실제 학생 제출물과 얼마나 닮았는가

논문 초록의 결론은 흥미롭다.

모든 모델은 다양한 오류를 생성했지만, 실제 학생 제출물과의 정렬은 서로 달랐다.

“while all models generate diverse errors, their alignment to human submissions diverges”

또 전문가 블라인드 주석 연구에서는 합성 오류와 실제 오류가 기능적으로 구분되기 어려운 경우가 있었다고 보고한다. 다만 난도가 높고 학습자가 많이 어려워하는 문제일수록 더 다양한 오류가 나오지만, 실제 학생 같은 정도는 떨어질 수 있었다.

즉 “LLM이 오류를 많이 만들어준다”와 “그 오류가 교육적으로 쓸 만하다”는 같은 말이 아니다. HRD나 교육평가에 붙일 때도 이 구분이 중요하다.

HRD 관점에서는 ‘사전 리허설’에 가깝다

이 논문을 기업 교육으로 옮기면, LLM은 학습자를 대체하는 장치라기보다 평가 설계의 사전 리허설 도구에 가깝다. 실제 수강생에게 배포하기 전에 다음을 미리 점검할 수 있다.

• 과제가 한 가지 정답만 유도하는지, 여러 오류 경로를 드러내는지
• 자동 피드백 규칙이 흔한 오류에는 반응하지만 낯선 오류에는 무너지는지
• 튜터링 봇이 정답 설명만 잘하는지, 잘못된 사고 경로도 짚어내는지
• 학습분석 대시보드가 단순 점수보다 오류 유형을 보여줄 준비가 되어 있는지

특히 신입 교육, 데이터 리터러시 교육, 내부 툴 사용 교육처럼 실제 오류 로그가 충분히 쌓이기 전에는 이런 리허설이 유용할 수 있다. 다만 논문이 보여준 것은 Java 프로그래밍 오류 시뮬레이션이라는 조건 안의 결과다. 이를 곧바로 모든 직무교육에 일반화하기보다는, 각 교육 영역에서 “사람다운 실수”의 기준을 다시 세워야 한다.

원문 첫 페이지. 이 글은 LLM 오류 생성의 성능 자체보다 교육평가 설계에서 어떤 점검 루프를 만들 수 있는지에 초점을 둔다.

조심해야 할 착각

이 연구를 잘못 읽으면 “이제 학생 데이터 없이도 평가를 만들 수 있다”로 넘어가기 쉽다. 하지만 논문은 오히려 반대의 경고를 품고 있다. 합성 오류는 실제 오류를 기다리는 시간을 줄여줄 수 있지만, 실제 학습자의 맥락을 지우면 평가가 더 위험해진다.

예를 들어 LLM이 만든 오류는 기능적으로 그럴듯해도, 실제 학습자가 왜 그런 선택을 했는지는 다를 수 있다. 개념을 몰라서인지, 문제 문장을 오해해서인지, 시간 압박 때문인지, 이전 교육 경험 때문인지는 코드 조각만으로 다 보이지 않는다.

그래서 이 방법을 쓰려면 합성 오류를 최종 답으로 두기보다 이렇게 써야 한다.

1. LLM으로 예상 오류 풀을 만든다.
2. 전문가가 교육적으로 의미 있는 오류 유형을 고른다.
3. 실제 학습자 데이터가 들어오면 합성 오류와 비교한다.
4. 어긋난 부분을 다음 과제와 피드백 설계에 반영한다.

Deciflow에 붙이면

Deciflow식으로는 “평가 자동화”보다 “평가 전 검증 자동화”에 더 가깝게 쓰고 싶다. 예를 들어 Power BI 교육 과제를 만든다면, LLM에게 일부러 잘못된 DAX, 잘못된 관계 설정, 잘못된 시각화 해석을 만들게 한다. 그리고 그 오류들이 실제 현업 수강자가 낼 만한지 교육 담당자와 검토한다.

그 다음 자동 채점이나 피드백 시스템을 만들면, 정답을 맞히는 시스템보다 먼저 실패를 알아보는 시스템을 설계할 수 있다.

오늘 남길 작업 질문

다음 교육 콘텐츠를 만들 때, 정답 예시만 만들지 말고 “그럴듯한 오답 20개”를 먼저 만들어보면 어떨까. 그리고 그 오답을 보며 질문하자. 우리가 만든 교육은 학습자가 실제로 어디서 틀릴지 알고 있는가.

원문 정보

• 제목: Simulating Students’ Java Programming Errors with Large Language Models
• 저자: Ali Keramati, Jie Cao, Iman Mohammadi, Mark Warschauer, Yang Shi
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2606.14113v1
• PDF: https://arxiv.org/pdf/2606.14113

원문 논문: Simulating Students' Java Programming Errors with Large Language Models