
교육용 소프트웨어는 희망만으로는 구축될 수 없다는 것을 오늘 배웠습니다
요약
교육용 소프트웨어 개발 과정에서 직면하는 기술적 책임과 설계의 중요성을 다룹니다. 단순한 코딩을 넘어 시스템이 학습자의 진전을 설명할 수 있어야 한다는 결정론적 설계의 필요성을 강조합니다.
핵심 포인트
- 교육용 소프트웨어는 단순한 의도나 UI를 넘어 데이터와 논리로 증명되어야 함
- 시스템은 학습자의 진전 이유를 설명할 수 있는 결정론적 근거를 갖춰야 함
- 코딩은 소프트웨어가 허용할 지식, 추론, 거부 범위를 결정하는 과정임
- 직관적인 아이디어를 정직하고 테스트 가능한 시스템으로 변환하는 것이 핵심 과제임
전체 작업물 및 동반 파일
오늘은 코딩이라는 작업이 더 이상 낭만적이지 않게 느껴지는 그런 날 중 하나였습니다.
프로젝트의 의미가 퇴색되었기 때문이 아닙니다. 오히려 그 반대입니다. 프로젝트가 너무나 의미가 깊어지다 보니, 코드가 지름길을 거부하기 시작한 것입니다. 모든 취약한 가정(assumption)이 눈에 보이게 됩니다. 모든 멋진 문장은 상태(state), 규칙(rule), 테스트(test), 경계(boundary), 또는 시스템이 나중에 설명할 수 있는 결정(decision)이 되어야만 합니다.
오늘 제가 완성한 기사는 SecuredMe Education 제품군 내의 음절 우선 학습 엔진인 Scholarium Teach에 관한 것입니다. 하지만 더 깊은 교훈은 단지 음절에 관한 것만이 아니었습니다. 아이들, 언어적 난이도, 접근성(accessibility), 개인정보 보호(privacy), 그리고 AI가 모두 동일한 시스템에 맞닿아 있을 때 교육용 소프트웨어를 구축하는 현실에 관한 것이었습니다.
오늘의 가장 큰 교훈은 단순하고도 잔혹했습니다:
좋은 교육적 의도가 증거가 될 수는 없습니다. 아름다운 인터페이스가 증거가 될 수는 없습니다. 모범 답안이 증거가 될 수는 없습니다. 만약 시스템이 학습자를 왜 진전시켰는지 설명할 수 없다면, 학습을 측정했다고 가장할 권리가 없습니다.
이것이 사람들이 외부에서 항상 볼 수 없는 코딩의 측면입니다.
코딩은 단순히 함수(function)를 작성하는 것이 아닙니다. 코딩은 소프트웨어가 무엇을 알 수 있도록 허용할지, 무엇을 추론(infer)하도록 허용할지, 무엇을 거부해야 하는지, 그리고 무엇이 인간의 책임 아래 머물러야 하는지를 결정하는 것입니다.
진짜 어려움은 Python이 아니었습니다
오늘 가장 어려웠던 부분은 Python이 아니었습니다.
어려운 부분은 직관을 테스트할 수 있을 만큼 정직한 무언가로 변환하는 것이었습니다.
시작 아이디어는 강력합니다. 아이에게 고립된 글자를 조작하도록 요구하기 전에, 아이가 듣고 발음할 수 있는 음절(syllable)부터 시작하는 것입니다. 실라바리오(silabario)를 구축하십시오. 학습자가 듣고, 읽고, 구성하게 한 다음, 나중에 글을 쓰게 하십시오. 이미지는 보조 수단으로 유지하되, 아이가 해독(decoding) 없이 추측할 수 있게 만드는 정답으로 사용해서는 안 됩니다.
그 아이디어에는 진심이 담겨 있습니다. 교육적 가치가 있습니다. 그 뒤에는 실제 경험이 뒷받왕하고 있습니다.
하지만 만약 제가 그 아이디어를 하나의 법칙(law)으로 코딩한다면, 저는 시스템을 위험하게 만드는 것입니다. 악의적이거나 극적인 것이 아니라, 그저 조용히 잘못된 상태가 되는 것입니다. 소프트웨어는
오늘 저는 Scholarium Teach를 아름다운 야망의 단계에서 검사 가능한 (inspectable) 아키텍처 (architecture)로 이동시켰습니다.
최종 기사는 학습자의 진행 상태를 언어 모델 (language model)이 소유하지 않는 시스템을 기록합니다. Scholarium이 정전 상태 (canonical state)를 유지합니다. 결정론적인 (deterministic) Python 엔진이 이전 상태, 콘텐츠 버전, 이벤트, 그리고 정책을 전달받습니다. 그러면 엔진은 구조화된 영수증 (structured receipt)을 반환합니다. 제품은 해당 영수증을 검증하고 영구 저장 (persist)합니다.
이것은 매우 중요합니다.
만약 내일 동일한 상태와 동일한 시도가 엔진에 입력된다면, 반드시 동일한 결정이 나와야 합니다. 비슷한 분위기가 아니라, 확률적인 설명도 아닙니다. 바로 동일한 결정이어야 합니다.
또한 저는 주변 시스템들의 역할을 명확히 했습니다:
- D1은 학습자 체크포인트와 영수증을 위한 트랜잭션 기반의 신뢰할 수 있는 단일 원천 (source of truth)으로 남습니다.
- Python은 결정을 계산하지만, 숨겨진 두 번째 메모리가 되지는 않습니다.
- PostgreSQL은 언어 팩과 버전을 카탈로그화할 수 있습니다.
- TimescaleDB는 권한이 부여된 시간적 이벤트 (temporal events)에 유용하며, 학습 뇌 전체인 척하는 용도가 아닙니다.
- CodeProject.AI는 선택적인 관찰 계층 (observation layer)이 될 수는 있지만, 교수법 (pedagogy)에 대한 권위자가 될 수는 없습니다.
- Synthia Scholarium은 출처 (provenance)와 변환을 추적하지만, 진실에 대해 투표하지는 않습니다.
- Google Drive는 소유자 측의 자료를 아카이브할 수 있지만, 교실의 런타임 의존성 (runtime dependency)이 되어서는 안 됩니다.
이것은 방대한 경계 설정 작업 (boundary work)입니다. "AI가 아이들을 자동으로 가르칠 것이다"라고 말하는 것보다 덜 화려하지만, 훨씬 더 책임감 있는 방식입니다.
그리고 솔직히 말해서, 저는 그것이 자랑스럽습니다.
이 작업이 끝났다고 가장하는 것이 아니기에 저는 자랑스럽습니다. 이제는 테스트가 가능할 정도로 충분히 구조화되었습니다. 그것이 더 나은 이정표 (milestone)입니다.
하루를 바꾼 순간
가장 강렬했던 순간은 시스템이 '아니오'라고 말할 수 있어야 한다는 것을 깨달았을 때였습니다.
아니오, 이 이미지는 너무 많은 것을 드러냅니다.
아니오, 이 유도된 답변은 숙달 (mastery)이 아닙니다.
아니오, 이 오디오 샘플은 해석하기에 너무 노이즈가 심합니다.
아니오, 이 데이터셋은 흥미롭지만 교실용으로 라이선스가 허가되지 않았습니다.
아니오, 이 AI 생성 카드 (AI-generated card)는 컴파일 (compilation), 검토 (review), 그리고 출처 (provenance) 확인 없이는 표준 학습 경로 (canonical learning path)에 진입할 수 없습니다.
아니오, 이 아이를 단 하나의 양식 (modality)이 실패했다는 이유로 점수로 환원해서는 안 됩니다.
그것은 부정적인 것이 아닙니다. 그것은 공학적 존중 (engineering respect)입니다.
진지한 교육 시스템은 항상 전진하기 때문에 신뢰할 수 있는 것이 아닙니다. 언제 멈추고, 삼가고, 검토하거나, 인간의 결정을 요청해야 하는지를 알 때 신뢰할 수 있게 됩니다.
그것이 아마도 제가 오늘 배운 가장 큰 교훈일 것입니다:
AI 보조 학습 도구에서 가장 중요한 기능은 생성 (generation)이 아닐 수도 있습니다. 그것은 이유를 동반한 거절 (refusal with a reason)일 수 있습니다.
이유를 동반한 거절은 학습자를 보호합니다. 교사를 보호합니다. 학부모를 보호합니다. 프로젝트가 과도한 주장 (overclaiming)을 하는 것을 방지합니다. 코드의 미래 버전이 거짓을 상속받는 것을 방지합니다.
흥분이 지나간 후의 코딩의 현실
흥분이 구현 (implementation)과 충돌하는 순간은 언제나 존재합니다.
비전 (vision)으로 시작합니다. 그다음 코드가 이름을 요구합니다. 그다음 데이터베이스가 스키마 (schema)를 요구합니다. 그다음 개인정보 보호 (privacy)가 제한을 요구합니다. 그다음 접근성 (accessibility)이 대안을 요구합니다. 그다음 연구 (research)가 겸손을 요구합니다. 그다음 배포 (deployment)가 저사양 기기를 사용하는 학습자 20명이 한꺼번에 접속했을 때 어떤 일이 벌어질지 묻습니다.
그 지점에서 저는 속도를 늦춰야 했습니다.
저는 살아있는 것처럼 느껴지는 시스템을 원했습니다. 하지만 저는 또한 교실용 도구가 지루한 제약 조건 (constraints) 하에서 실행되어야 한다는 점을 받아들여야 했습니다: 안정적인 상태 (stable state), 재현 가능한 결정 (replayable decisions), 유계된 이벤트 (bounded events), 가공되지 않은 음성 수집 금지 (no raw voice hoarding), 숨겨진 모델 권한 금지 (no hidden model authority), 가짜 숙달 금지 (no fake mastery), 브라우저 AI 모델에 대한 마법 같은 의존성 금지 (no magical dependency on a browser AI model).
4 GiB 크롬북 (Chromebook)이 중요합니다. 조용한 폴백 (fallback)이 중요합니다. 지루한 영수증 (receipt)이 중요합니다. 엄격한 경계 (hard boundary)가 중요합니다.
이것이 지난 몇 년 동안 저를 변화시킨 코딩의 부분입니다. 초기에는 엔진이 인상적이기를 원했습니다. 이제 저는 엔진이 책임감 (accountable) 있기를 원합니다.
그것은 다른 종류의 자부심입니다.
다른 빌더들이 여기서 얻어갈 수 있는 것
만약 당신이 AI를 활용해 무언가를 구축하고 있다면, 특히 교육 분야라면, 모델이 얼마나 많은 일을 할 수 있는지부터 묻지 마십시오.
먼저 다음 질문들을 던지십시오:
- 진실의 근원 (source of truth)은 무엇인가?
- 무엇을 다시 재생 (replay)할 수 있는가?
- 무엇을 인간이 검토 (review)해야 하는가?
- 어떤 데이터를 절대 저장해서는 안 되는가?
- 모델이 설명은 하되, 결정은 내리지 않는 것은 무엇인가?
- 엔진이 결정하되, 선언된 정책 (policy) 하에서만 결정하는 것은 무엇인가?
- 시스템이 불확실할 때 어떤 일이 발생하는가?
- 학습자가 다음 단계로 넘어가기 전에 어떤 증거가 필요한가?
이러한 질문들은 관료주의가 아닙니다. 그것은 신뢰의 골격 (skeleton)입니다.
오늘 저는 실제 소프트웨어를 구축한다는 것이 기계가 자신감 있게 들리도록 만드는 것이 아니라는 점을 다시 한번 배웠습니다. 그것은 기계가 계약 (contract) 안에 머물도록 강제하는 것에 관한 것입니다.
그것은 더 어렵습니다.
그것은 더 느립니다.
하지만 그것은 자부심을 느낄 만한 가치가 있습니다.
현재 작업 현황
Scholarium Teach 음절 엔진 (syllable engine)은 하나의 방법이 우월하다고 증명되었다는 주장이 아닙니다. 그것은 연구 및 구축 아키텍처 (architecture)입니다. 이것은 우리가 방어 가능한 (defensible) 것을 코드로 구현하고, 여전히 테스트가 필요한 것을 격리하며, 제품이 자신이 알지 못하는 것을 아는 척하는 것을 금지하는 방법을 제공합니다.
그것이 오늘 얻은 가장 깔끔한 결과입니다.
기적이 아닙니다.
작동하는 경계 (working boundary)입니다.
그리고 때때로 소프트웨어에서, 작동하는 경계는 첫 번째 진정한 승리입니다.

AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기
