[MAICE 개발기 1편] 단순 정답기가 아닌, '가르치는 AI' 만들기 (Project Overview)

1. 시작하며: 답변보다 먼저 질문을 보자

학생이 AI에게 "이거 어떻게 해요?"라고 묻는 장면을 떠올려 봅니다. AI는 바로 풀이를 만들 수 있습니다. 하지만 질문 안에는 정작 중요한 정보가 빠져 있습니다. 어느 단원인지, 어디까지 풀어봤는지, 정확히 무엇이 막혔는지 알 수 없습니다.

이 글의 핵심은 하나입니다. MAICE는 정답을 더 빨리 주기보다, 학생이 자신의 질문을 먼저 선명하게 만들도록 돕는 프로젝트였습니다.

이런 질문에 곧바로 답을 주면 대화는 빠르게 진행되는 것처럼 보입니다. 그러나 학습은 꼭 그렇게 좋아지지 않습니다. 학생은 자신이 어디에서 막혔는지 다시 생각하지 못하고, AI는 학생의 현재 이해 상태를 모른 채 일반적인 설명을 내놓게 됩니다.

예비 연구에서도 비슷한 신호가 보였습니다. 학생 질문 385개를 분석했을 때, 연구 기준상 72.3%는 현재 진도, 시도한 풀이, 구체적으로 막힌 지점 같은 학습 맥락을 충분히 담고 있지 않았습니다. 질문 품질과 답변 품질 사이에는 r=0.691, p<0.001의 양의 상관도 나타났습니다.

물론 이 수치는 "좋은 질문을 만들면 반드시 좋은 답변이 나온다"는 인과 증명이 아닙니다. 다만 수학 AI를 만들 때 답변 생성만 볼 것이 아니라, 질문이 만들어지는 과정을 함께 봐야 한다는 문제의식은 충분히 분명했습니다.

그래서 MAICE(Mathematical AI Chatbot for Education)는 "정답을 더 빨리 주는 챗봇"이 아니라, 학생이 질문을 더 명확하게 만들도록 돕는 수학 AI에서 출발했습니다.

2. 질문을 분류하고, 다시 묻는다는 것

MAICE의 설계에는 두 가지 교육학 관점이 들어갔습니다. 하나는 Bloom의 지식 차원이고, 다른 하나는 Dewey의 반성적 사고입니다.

Bloom의 지식 차원은 학생 질문이 어떤 종류의 앎을 요구하는지 보는 틀입니다.

K1 사실적 지식: 공식, 정의, 명칭을 묻는 질문
K2 개념적 지식: 왜 그런지, 개념 사이 관계를 묻는 질문
K3 절차적 지식: 풀이 과정이나 증명 절차를 묻는 질문
K4 메타인지적 지식: 자신의 풀이와 사고 과정을 점검하는 질문

예를 들어 "수학적 귀납법 공식 알려줘"는 K1에 가깝습니다. 반면 "왜 $n=k$ 에서 $n=k+1$ 을 보이면 충분한가?"는 개념과 절차가 함께 들어간 질문입니다. "내 풀이에서 어느 단계가 틀렸는지 봐줘"는 자신의 사고를 점검하는 질문에 가깝습니다.

Dewey의 반성적 사고에서 MAICE가 특히 주목한 부분은 문제가 무엇인지 정의하는 단계입니다. 학생이 "이거 모르겠어요"라고 말했을 때 바로 풀이를 보여주는 대신, "어느 부분이 헷갈리나요?", "직접 해본 풀이가 있나요?", "기초 단계와 귀납 단계 중 어디에서 막혔나요?"처럼 문제를 더 구체화하도록 돕는 것입니다.

3. 하나의 챗봇이 아니라, 역할이 나뉜 시스템

처음에는 이 과정을 하나의 프롬프트로 해결할 수 있을 것처럼 보였습니다. 질문을 읽고, 지식 차원을 분류하고, 필요하면 되묻고, 답변까지 생성하라고 지시하면 될 것 같았습니다.

하지만 실제 대화는 그렇게 단순하지 않았습니다. 질문을 분류하는 판단, 되묻는 판단, 답변을 만드는 판단은 서로 다릅니다. 한 모델에게 모든 역할을 한꺼번에 맡기면, 되물어야 할 때 답을 하거나, 답해도 되는 질문에 불필요한 역질문을 던지는 일이 생길 수 있습니다.

그래서 MAICE는 하나의 거대한 프롬프트가 아니라, 역할이 나뉜 에이전트 구조로 설계했습니다. 학생의 질문은 먼저 분류되고, 모호하면 명료화 과정을 거치고, 충분히 답할 수 있을 때 답변 생성으로 넘어갑니다.

개발 메모로 남기면, 실제 MAICE 저장소에서는 SvelteKit 프론트엔드, FastAPI 백엔드, Redis/PostgreSQL, 그리고 별도 에이전트 워커가 이 흐름을 나누어 맡습니다. agent/worker.py에서 실행되는 핵심 에이전트는 QuestionClassifier, QuestionImprovement, AnswerGenerator, Observer, FreeTalker입니다.

여기서 조심해야 할 점도 있습니다. 논문은 Agent 모드와 Freepass 모드를 비교했지만, 현재 코드의 운영 경로는 사용자에게 배정된 모드를 참고값으로 남기면서 실제 처리는 Agent 흐름으로 고정합니다. 따라서 A/B 비교 결과는 실험 설계와 분석 맥락에서 읽어야 하고, 현재 구현은 질문 명료화 중심의 Agent 흐름을 운영 대상으로 보는 것이 정확합니다.

4. 실험은 어떻게 보았나

MAICE의 효과를 보기 위해 본 연구는 고등학교 2학년 수학 I, 수학적 귀납법 단원에서 3주 동안 진행했습니다.

대상: 고2 58명 배정, 유효 참여자 55명
비교: Agent 모드와 Freepass 모드
유효 세션: 284개
평가 프레임: QAC 40점 체크리스트
추가 자료: 대화 로그 1,589건, 사후 설문, 교사 평가 표본

이 글에서 수치를 길게 해석하지는 않겠습니다. 결과 해석은 6편의 역할입니다. 여기서는 MAICE가 무엇을 하려 했는지, 그리고 왜 질문 명료화라는 개입을 시스템 안에 넣었는지 이해하는 것이 더 중요합니다.

5. 결과는 짧게만 보자

전체 결과를 한 문장으로 줄이면 이렇습니다. MAICE의 Agent 모드는 모든 지표에서 일방적으로 우세하지는 않았지만, 학습 과정 지원과 하위권 학생 집단에서 의미 있는 신호를 보였습니다.

예를 들어 LLM 평가에서는 C2 학습 지원 항목에서 Agent 모드가 Freepass보다 높게 나타났고, 하위권(Q1)에서는 효과크기가 더 크게 관찰되었습니다. 교사 평가에서도 하위권 표본에서 큰 차이가 나타났습니다.

다만 이 결과는 단일 학교, 특정 단원, 짧은 실험 기간 안에서 얻은 결과입니다. OCR, UI 개선, 배포 안정성 같은 구현 요소도 실험 환경을 지탱했지만, 그것들이 독립적으로 학습 효과를 만들었다고 해석하면 안 됩니다.

6. 이 시리즈에서 다룰 것

이 시리즈는 MAICE를 논문 요약으로만 정리하지 않으려 합니다. 실제로 어떤 문제를 만나서 어떤 구조를 만들었는지, 그리고 그 구조가 교육적으로 어떤 의미가 있었는지를 따라가려 합니다.

편	주제	핵심 질문
1편	프로젝트 개요	왜 답변보다 질문 명료화에 주목했나
2편	Multi-Agent System	왜 하나의 프롬프트 대신 역할을 나눴나
3편	SvelteKit Interface	학생이 수식 질문을 실제로 입력하게 하려면 무엇이 필요했나
4편	QAC Checklist	좋은 학습 대화를 어떻게 평가할 것인가
5편	Blue-Green Deployment	실험 중 서비스가 멈추지 않게 하려면 무엇이 필요했나
6편	Educational Impact	실제 데이터에서 어떤 효과와 한계가 보였나

다음 글에서는 이 중 두 번째 질문을 다룹니다. 왜 MAICE는 하나의 똑똑한 챗봇이 아니라 여러 에이전트가 협업하는 구조가 되었을까요?