AI 서술형 채점 시스템: Ext JS·Node.js·OpenAI 참조 아키텍처

시험 채점 시스템에서 객관식은 어렵지 않습니다. 정답 키와 비교하면 끝이고, 같은 입력에 같은 결과가 나옵니다. 서술형은 다릅니다. 루브릭이 있어도 그것을 답안에 적용하는 과정에 해석이 들어갑니다.

사람이 오래 채점할 때 생기는 특유의 문제도 있습니다. 원문은 이것을 채점 쏠림(grading creep) 이라고 부릅니다. 50번째 답안을 볼 때 채점자는 루브릭이 아니라 앞서 본 49개의 답안과 비교하고 있습니다. 기준이 조용히 이동합니다.

3계층 참조 아키텍처

원문이 제시하는 구조는 세 층입니다. 원칙은 한 줄로 요약됩니다. 브라우저는 상호작용을 맡고, 신뢰는 백엔드가 맡는다.

• Ext JS 프런트엔드: DataGrid 가 응시 정보, 문항, 답안, AI 점수, AI 피드백, 수동 보정 값을 한 화면에서 보여 줍니다
• Node.js / Express 중간 계층: OpenAI 를 호출하는 유일한 지점이며, 업무 로직이 여기 있습니다
• MySQL: 점수와 근거의 정본입니다

왜 그리드가 중요한가

AI 채점 기능을 별도 화면으로 떼어 놓으면 교육자가 그것을 쓰지 않습니다. 평소 채점하던 화면 안에 AI 점수와 피드백 열이 함께 있어야 업무 흐름에 들어옵니다. 한 그리드에서 답안을 읽고, AI 점수를 보고, 필요하면 그 자리에서 보정합니다.

데이터 모델: 모든 점수를 되짚을 수 있게

테이블 다섯 개가 정본입니다. 시험(tests), 문항(questions), 학생(students), 응시 기록(test attempts), 학생 답안(student answers)입니다.

설계 목표는 분명합니다. 모든 점수를 특정 답안·특정 문항·특정 루브릭으로 되짚을 수 있어야 합니다. 이의 제기가 들어왔을 때 "AI 가 그렇게 줬습니다" 로 끝나면 시스템을 쓸 수 없습니다.

보안은 모델 앞에서 시작합니다

가장 먼저 지킬 선은 하나입니다. OpenAI API 키는 서버에만 둡니다. 브라우저로 내려보내지 않습니다. 프런트엔드에서 모델을 직접 호출하는 구조는 키가 공개되는 구조입니다.

• 키는 환경변수로 넣고, 설정 파일은 gitignore 로 제외합니다
• CORS 로 허용 출처를 제한합니다
• Helmet 으로 보안 헤더를 적용합니다
• 모든 요청 본문을 서버에서 검증합니다

프롬프트는 문서가 아니라 계약입니다

원문은 프롬프트를 다섯 부분으로 구조화할 것을 권합니다. 역할, 규칙, payload(답안과 루브릭), 출력 스키마, 그리고 한계입니다.

규칙 쪽에서 중요한 두 가지가 있습니다. 루브릭에 언급되지 않은 개념에는 점수를 주지 않게 하고, 부분 점수는 반드시 명시된 루브릭 요소에 대응시키는 것입니다. 그래야 "왜 3점인가" 에 답할 수 있습니다.

산수를 모델에게 맡기지 않습니다

모델은 답안 하나하나의 판단만 합니다. 합계, 백분율, 합격·불합격 판정은 Node.js 가 계산합니다. 원문의 표현을 그대로 옮기면 "AI 는 판단하고, 애플리케이션은 연산한다" 입니다. 이 경계를 흐리면 재현되지 않는 성적표가 나옵니다.

구조화 JSON 을 애플리케이션 계약으로

모델의 응답은 정해진 JSON 스키마로 받고, 저장 전에 Node 가 검증합니다. 형식이 맞지 않으면 거부합니다. 그리고 교육자가 점수를 덮어쓸 수 있는 human-in-the-loop 를 반드시 남깁니다.

이 구조에서 교육자의 역할이 바뀝니다. 전수 채점에서 예외 처리와 품질 보증으로 옮겨갑니다. 사람이 빠지는 것이 아니라 사람이 보는 지점이 달라지는 것입니다.

비용과 재현성

호출 방식은 두 갈래입니다. 학생별로 세밀하게 평가하는 쪽은 대화형 화면에 맞고, 일괄 평가는 대규모 비동기 처리에 유리하지만 컨텍스트 크기 제한을 만납니다.

재현성을 위해서는 temperature 를 낮추고 seed 를 고정합니다. 그리고 프롬프트·루브릭·스키마· 모델 설정을 운영 산출물처럼 버전 관리합니다. 모델 설정이 바뀌면 점수가 바뀝니다. 그것을 추적할 수 없으면 작년 성적과 올해 성적을 비교할 수 없습니다.

정리하면

• AI 는 판단만, 합계·백분율·합불 판정은 애플리케이션이 계산합니다.
• API 키는 서버에만 둡니다: 이 선이 무너지면 나머지 설계가 의미 없습니다.
• 모든 점수는 답안·문항·루브릭으로 되짚을 수 있어야 합니다.
• 프롬프트·루브릭·스키마·모델 설정은 운영 산출물로 버전 관리합니다.
• 사람은 전수 채점에서 예외 처리와 품질 보증으로 옮겨갑니다.

미래웹이 덧붙입니다

이 구조는 시험 채점에만 쓰이는 것이 아닙니다. 사람의 판단을 모델이 1차로 대신하고, 결과를 사람이 확인해 확정하는 업무는 어디에나 있습니다. 보험 청구 심사, 민원 분류, 품질 검사 소견, 계약서 조항 검토가 모두 같은 모양입니다.

국내 도입에서 가장 자주 걸리는 지점은 두 곳입니다. 하나는 데이터를 외부 모델에 보낼 수 있는지의 문제이고, 다른 하나는 판정 근거를 어디까지 남겨야 하는지의 문제입니다. 전자는 민감 항목을 중간 계층에서 걷어내거나 사내 모델로 분리 배치하는 설계로 다루고, 후자는 위에 적힌 "되짚을 수 있는 데이터 모델" 이 그대로 답이 됩니다.

화면 쪽에서는 Ext JS 의 그리드가 이런 업무에 잘 맞습니다. 원본, 모델 판단, 사람의 보정, 확정값을 한 행에서 보여 주고 그 자리에서 수정하는 화면은 결국 그리드 기능의 깊이에 달려 있습니다. 미래웹은 Ext JS 도입과 함께 이런 AI 보조 업무 화면의 설계를 상담해 드립니다.

AI 보조 업무 화면을 검토하고 계신다면

어느 판단을 모델에 맡기고 어느 연산을 애플리케이션에 남길지, 그리고 근거를 어떻게 남길지가 설계의 핵심입니다. 미래웹의 AI 컨설팅으로 문의해 주십시오.

이 글은 Sencha 공식 블로그 게시물 AI-Driven Test Grading with Ext JS, Node.js, and OpenAI: A Secure Enterprise Architecture (2026년 10월 2일, Team Sencha)을 미래웹 주식회사가 한국어로 옮기고 해설을 덧붙인 것입니다. 원문의 저작권은 Sencha / Idera, Inc. 에 있습니다. "미래웹이 덧붙입니다" 항목은 원문에 없는 미래웹의 견해입니다. 번역 과정에서 생긴 오류가 있다면 원문을 기준으로 판단해 주십시오.