[AirClass 개발기 5편] 프롬프트가 지나가지 않게: AirClassSlide 첫 수업 적용기

이 글에서 다루는 내용

왜 이번에는 AirClassSlide를 만들게 되었는지
이전 Display 문제와 무엇이 닮아 있었는지
슬라이드에 어떤 기능을 직접 붙였는지
오늘 첫 사용에서 무엇이 실제로 달라졌는지
그리고 왜 이 경험이 오늘 AirClass 통합 구현으로 이어졌는지

AirClassQuiz가 퀴즈 수업 흐름의 마찰을 줄이는 도구였다면, 그다음은 슬라이드였다. 이번에는 정규수업이 아니라 부산 수학문화원 바이브코딩 시간에서 반복해서 부딪히는 문제가 있었다.

시작은 "학생들에게 보여줘야 할 프롬프트가 자꾸 지나간다"는 문제였다

바이브코딩 수업에서는 학생들이 직접 프롬프트를 입력하고, 결과를 확인하고, 다시 수정해 보는 흐름이 계속 이어진다. 그런데 실제 진행에서는 학생들이 입력해야 할 프롬프트가 화면에서 한 번 지나가 버리면 수업이 금방 끊겼다.

어떤 학생은 지금 설명을 듣고 있고, 어떤 학생은 막 입력을 시작했고, 어떤 학생은 한 줄을 잘못 쳐서 다시 보고 싶어 한다. 그런데 화면은 계속 넘어가니, 질문이 반복되고 진행 속도는 계속 벌어졌다.

돌아보면 이건 3편의 Display 문제와 꽤 닮아 있었다. 결국 핵심은 또다시 학생이 지금 필요한 내용을 자기 속도로 다시 확인하기 어렵다는 점이었다.

그래서 첫 번째 목표는 "바로 고치고 바로 반영되는 슬라이드"였다

이번에는 아예 목표를 분명하게 잡았다. 수업 중에도 바로 수정할 수 있고, 그 수정이 학생 화면에 바로 반영되는 슬라이드를 만들자는 것이었다.

미리 완성된 발표 자료를 띄우는 정도로는 부족했다. 바이브코딩 수업에서는 수업 도중에 프롬프트를 고쳐야 하고, 예시 코드를 다시 적어 줘야 하고, 학생 질문에 맞춰 설명 순서를 바꾸는 일이 자주 생긴다. 그래서 슬라이드도 정적인 자료가 아니라, 수업 중 계속 살아 움직이는 화면이어야 했다.

즉 AirClassSlide의 출발점은 예쁜 발표 도구가 아니라, 실시간 수업 운영에 맞는 수정 가능한 슬라이드 런타임에 가까웠다.

두 번째 문제는 과제물 제출 방식 자체였다

여기서 끝이 아니었다. 학생들의 성과물 제출 방식도 계속 걸렸다. 기존에는 결과물을 메일로 보내게 했는데, 생각보다 메일 발송 자체를 어려워하는 학생이 많았다.

이건 코딩 실력과는 또 다른 종류의 마찰이었다. 어떤 학생은 결과물은 만들었지만 파일을 제대로 첨부하지 못했고, 어떤 학생은 제목 형식을 틀렸고, 어떤 학생은 아예 보내는 흐름에서 멈췄다. 결국 과제 확인 이전에 제출 방식부터 막히는 경우가 너무 많았다.

그래서 이번에는 슬라이드 안에서 바로 해결하고 싶었다.

코드 예시를 바로 배부할 수 있을 것
필요한 과제 파일도 바로 배부할 수 있을 것
학생 결과물도 같은 흐름 안에서 업로드할 수 있을 것

즉 슬라이드는 설명 화면이면서 동시에 배부와 제출이 이루어지는 수업 작업면이 되어야 했다.

실제 구현도 수업 흐름에 맞춰 꽤 구체적으로 나뉘었다

실제 저장소 구조를 보면 AirClassSlide도 꽤 분명하게 역할이 나뉘어 있다.

src/routes/teacher: 교사가 room을 만들고, 덱을 고르고, 수업을 제어하는 교사용 화면
src/routes/student: 학생이 room code와 이름을 입력해 입장하는 화면
src/routes/room/[code]: 학생이 실제로 현재 슬라이드를 보고 상호작용하는 수업 화면
src/lib/airclass-slide/runtime/ws/client.ts: /ws 기반으로 교사/학생 화면을 실시간 연결하는 WebSocket 클라이언트
src/lib/airclass-slide/runtime/stores/*: 교사용·학생용 room 상태를 snapshot과 event 기준으로 유지하는 store
src/lib/airclass-slide/core/schema/*, core/protocol/*: room, deck, slide 구조와 command / event / snapshot 규약
data/library-decks/*.json: 실제 수업 전에 만들어 두는 덱 저장 형식

즉 교사 화면에서 room을 만들고, 학생은 코드로 들어오고, 현재 슬라이드와 허용된 열람 범위는 실시간으로 동기화된다. 설계 문서에서도 이 프로젝트를 단순 뷰어가 아니라 서버 권위 상태관리와 snapshot + event recovery를 갖는 실시간 슬라이드 수업 앱으로 잡고 있었다.

이 구조를 흐름 기준으로 단순화하면 아래처럼 볼 수 있다.

이번에는 슬라이드 안에 수업용 컴포넌트를 붙였다

이번 작업에서 중요한 것은 슬라이드가 단순 텍스트 묶음으로 끝나지 않았다는 점이다. 수업 운영에 필요한 요소를 컴포넌트처럼 슬라이드 안에 직접 넣으려 했다.

실제 코드 기준으로도 그 흔적이 꽤 분명하다.

content/extensions/component-block.ts: 슬라이드 안에 특정 컴포넌트를 블록처럼 삽입하는 구조
content/renderers/code-block-view.svelte: 코드 예시를 보여 주는 렌더링 컴포넌트
student/result-upload-panel.svelte: 학생 결과물을 바로 올리는 업로드 패널
src/routes/room/[code]/handouts/download/+server.ts: 교사가 배부한 파일을 학생이 직접 내려받는 경로
src/routes/room/[code]/upload/+server.ts: 학생 업로드를 실제로 저장하는 경로

이걸 수업 흐름으로 바꾸면 결국 내가 만들고 싶었던 것은 아래와 비슷했다.

즉 AirClassSlide는 단순 슬라이드 앱이라기보다, 프롬프트 전달·자료 배부·결과물 업로드를 한 화면 흐름으로 묶는 수업 도구 쪽에 가까웠다.

오늘 처음 써 봤는데, 바로 차이가 났다

이걸 오늘 처음 실제로 사용해 봤다. 아직 한 번 써 본 수준이라 과장해서 말하고 싶지는 않지만, 적어도 바로 체감되는 차이는 있었다.

가장 먼저 느낀 것은 학생 질문이 줄었다는 점이었다. 이전에는 "프롬프트 다시 보여 주세요", "이 코드 어디에 있나요", "파일은 뭘 받으면 되나요", "메일은 어떻게 보내나요" 같은 질문이 계속 반복됐다. 그런데 이번에는 학생이 필요한 요소를 슬라이드 안에서 바로 다시 확인할 수 있었고, 배부와 제출도 같은 흐름 안에서 처리할 수 있었다.

그 결과 구현 성공률도 확실히 올라갔다. 학생이 막히는 지점이 줄어드니, 질문에 소비되는 시간이 줄고 실제 구현으로 넘어가는 학생이 더 많아졌다. 이 차이는 생각보다 컸다.

그래서 오늘 AirClass 통합 구현까지 시도하게 되었다

이 경험이 중요한 이유는 단순히 슬라이드 하나가 잘 동작했기 때문만은 아니다. 오늘 처음 써 보면서, Display, Quiz, Slide가 따로따로 존재할 이유가 점점 줄어든다는 느낌이 더 강해졌다.

학생이 봐야 할 수업 화면은 Display
학생이 응답하고 기록이 남는 흐름은 Quiz
설명, 프롬프트, 배부, 제출은 Slide

실제 수업에서는 이 셋이 따로 놀지 않는다. 같은 시간 안에서 계속 이어진다. 그래서 오늘 AirClass 통합 구현을 진행해 보려 했던 것도 자연스러운 흐름이었다. 각각의 도구가 따로 유용한 수준을 넘어서, 이제는 한 수업 운영 체계 안에서 붙여 보고 싶어졌기 때문이다.

마치며

AirClassSlide는 프롬프트가 지나가 버리고, 자료 배부와 결과물 제출이 따로 놀던 바이브코딩 수업의 마찰을 줄이기 위해 시작했다. 출발점은 3편의 문제와 닮아 있었지만, 이번에는 학생이 자기 속도로 다시 보고 바로 행동할 수 있는 구조를 더 직접적으로 만들 수 있었다.

실시간 수정 슬라이드, 코드 배부, 과제물 배부, 결과물 업로드를 한 흐름에 넣자 학생 질문은 줄고 구현 성공률은 올라갔다. 적어도 오늘 첫 사용에서는 꽤 분명한 차이가 있었다.

이제 다음 단계는 더 분명하다. 따로 만든 Display, Quiz, Slide를 실제 수업 흐름 안에서 어떻게 하나로 묶을 것인가. 오늘 내가 AirClass 통합 구현을 시도하게 된 이유도 바로 거기에 있다.