평가는 정답보다 디버깅 과정을 남겨야 한다

제일 먼저 든 생각

교육평가나 성과관리를 하다 보면 결과물은 남는데 과정은 사라진다. 코드 과제에서는 최종 코드와 테스트 통과 여부가 남고, 보고서 업무에서는 완성본과 점수만 남는다. 하지만 실제 학습과 성장은 그 사이에서 일어난다. 어떤 실패를 재현했는지, 어떤 가설을 세웠는지, 어디를 보고 수정했는지, 검증을 어떻게 했는지가 더 많은 정보를 준다.

DebugTracker 논문은 이 빈칸을 디버깅 수업에서 다룬다. 학생의 디버깅 과정을 Visual Studio Code 안에서 가볍게 기록하고, 평가 모드와 훈련 모드를 나눠, 사람 교사가 검토할 수 있는 타임라인과 Markdown 보고서로 내보내는 도구를 제안한다.

최종 정답만 보면 디버깅 능력이 보이지 않는다. 논문은 실패 재현, 가설, 수정, 검증의 흔적을 평가 자료로 남기려 한다.

결과물 평가는 왜 자주 답답한가

논문이 출발하는 문제는 단순하다. 디버깅 과제를 최종 코드와 테스트 결과로만 평가하면, 학생이 어떤 사고 과정을 거쳤는지 숨겨진다. 운 좋게 고친 것인지, 오류를 제대로 재현했는지, 가설을 세우고 검증했는지, AI 도움을 연습용으로 썼는지 평가자가 보기 어렵다.

DebugTracker는 이 과정을 가볍게 기록한다. 테스트 명령, 편집기와 디버거 메타데이터, 학생 체크포인트, 소스 스냅샷, 선택적 이미지 증거, 사람 라벨, 선택적 AI 연습 피드백을 append-only JSONL 이벤트로 저장한다. 그리고 타임라인과 Markdown 보고서로 내보낸다.

“DebugTracker는 코칭이 없는 평가 모드의 흔적과 코칭이 있는 훈련 모드의 흔적을 분리하고, append-only JSONL 이벤트를 저장하며, 사람이 검토할 수 있는 타임라인과 Markdown 보고서를 내보낸다.”

“DebugTracker separates uncoached Evaluation Mode traces from coached Training Mode traces, stores append-only JSONL events, and exports timeline and Markdown reports for human review.”

여기서 중요한 단어는 “분리”다. 평가 상황에서 남긴 흔적과 연습 상황에서 AI 피드백을 받은 흔적은 같은 로그에 섞이면 안 된다. 학습을 돕는 장치와 평가를 판정하는 증거는 서로 다른 규칙을 가져야 한다.

평가 모드와 훈련 모드를 나누는 설계

논문은 두 모드를 둔다. Evaluation Mode는 코칭 없는 평가 흔적을 만든다. 힌트, 솔루션 프롬프트, 사후 AI 피드백이 꺼진다. Training Mode는 코칭이 있는 연습을 기록한다. 과정 프롬프트와 선택적 AI 피드백은 허용되지만, 직접 패치를 대신 만들어주는 방식은 막는다.

이 구조는 HRD와 성과관리에도 꽤 직접적으로 옮겨진다. 업무 교육에서 AI를 금지할 것인가 허용할 것인가만 묻기보다, “연습 장면의 AI 도움”과 “평가 장면의 독립 수행”을 구분해야 한다. 그리고 그 구분이 기록으로 남아야 한다.

원문 첫 페이지. DebugTracker는 VS Code 확장 형태로, Python·TypeScript·Java 디버깅 과제와 여러 운영체제 환경에서 프로토타입 검증을 진행했다.

업무 평가로 가져오면 과정 증거가 필요하다

성과관리에서도 비슷한 문제가 반복된다. 최종 산출물만 보면 누가 운 좋게 맞혔는지, 누가 문제를 체계적으로 좁혔는지, 누가 위험한 지름길을 썼는지 알기 어렵다. 특히 AI가 들어오면 결과물은 더 그럴듯해지고 과정은 더 안 보인다.

이 논문이 주는 힌트는 평가를 감시로 바꾸자는 것이 아니다. 평가자가 피드백할 수 있는 최소한의 과정 증거를 남기자는 쪽에 가깝다.

• 어떤 실패나 문제를 먼저 재현했는가?
• 어떤 가설을 세우고 어떤 증거로 확인했는가?
• AI 피드백은 연습 단계에서만 쓰였는가, 평가 산출물에도 개입했는가?
• 사람 평가자는 최종 결과가 아니라 과정의 어느 지점에 라벨을 붙일 수 있는가?

이런 기록이 있으면 피드백은 “잘했다/틀렸다”를 넘어 “가설은 좋았지만 검증이 약했다”, “수정은 맞았지만 실패 재현 없이 바로 고쳤다”, “AI 제안을 그대로 붙였고 본인 확인 흔적이 부족하다”처럼 구체화된다.

작은 실험

Deciflow 업무 교육에 붙인다면, 모든 업무를 녹화하거나 세세하게 감시할 필요는 없다. 과제형 업무 하나를 고르고, 수행자가 스스로 네 번의 체크포인트만 남기게 해볼 수 있다.

1. 내가 재현한 문제
2. 내가 세운 가설
3. 내가 바꾼 조치
4. 내가 확인한 검증 결과

AI를 썼다면 어느 단계에서 어떤 목적으로 썼는지도 함께 적는다. 연습 단계에서는 AI 피드백을 허용하고, 평가 단계에서는 도움의 종류를 제한하거나 명시한다. 핵심은 사람을 통제하는 것이 아니라, 나중에 배울 수 있는 흔적을 남기는 것이다.

조심해서 읽을 점

DebugTracker는 프로토타입 도구이며, 논문은 Python·TypeScript·Java 과제, 16개 자동 검사, 11개 수동 시험 매트릭스 등 제한된 조건에서 검증했다. 이것만으로 모든 교육평가 상황에 바로 적용할 수는 없다. 다만 최종 산출물 중심 평가가 놓치는 것을 “가벼운 과정 증거”로 보완하려는 방향은 HRD와 AI 시대 평가 설계에 꽤 실용적인 출발점이다.

원문 정보

• 제목: DebugTracker: Lightweight Process Evidence for Classroom Debugging
• 저자: Jiatong Liu, Xue Yao, Zehua Zhang, Yongqiang Tian
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2607.05871v1
• PDF: https://arxiv.org/pdf/2607.05871

원문 논문: DebugTracker: Lightweight Process Evidence for Classroom Debugging