[AirClass 개발기 8편] 화면 공유를 버리고 판서를 선택하다: AirClassTab과 LLM 학습 흐름

이 글에서 다루는 내용

• 왜 AirClassDisplay를 폐기하고 AirClassTab으로 전환했는지
• AirClassTab에서 구현한 판서 중심의 수업 흐름
• 판서 공유 → 리플레이 → LLM 요약 → 저장 → 학습자료 생성 → 문제 생성까지 이어지는 플로우
• 이 방식이 이전 Display 접근과 어떻게 다른지

AirClass를 시작하면서 가장 먼저 손댄 것은 Display였다. 화면을 학생에게 부드럽게 전달하고, 필요하면 다시 보게 하는 것. 그 목표는 분명했지만, 실제 수업에서는 계속 걸렸다. 그래서 결국 AirClassDisplay는 폐기했고, 대신 AirClassTab이라는 완전히 다른 방향을 잡았다.

왜 Display를 폐기했는가

AirClassDisplay는 기술적으로는 가능했다. WebRTC 기반으로 화면을 서버에 올리고, 학생들은 브라우저에서 거의 실시간으로 받아볼 수 있었다. 레이턴시도 어느 정도 통제 가능했고, 부드러운 렌더링도 확인했다.

하지만 실제 수업에 들어오는 순간 문제는 기술이 아니라 동선이었다.

첫째, 준비물이 늘었다. 태블릿만 들고 다니던 수업에 노트북을 추가로 챙겨야 했고, 브라우저를 띄우고 미디어 서버를 관리하는 흐름이 수업 전 점검 항목으로 들어왔다. 학생 경험을 개선하려다 교사의 운영 부담이 먼저 커졌다.

둘째, 태블릿 화면을 서버로 별도로 송출하는 구조가 막혔다. Miracast로 교실 화면에 연결하면서 동시에 WebRTC로 캡처해 서버로 별도 스트리밍하는 흐름이 실제 태블릿 환경에서는 원활하지 않았다. 결국 태블릿 중심 수업 흐름과 Display가 요구하는 구조가 서로 충돌했다.

셋째, 가장 본질적인 문제였다. 학생에게 전달하려는 것이 정말 "화면 전체"였는지 다시 보게 되었다. 수업에서 학생이 놓치는 것은 화면 전체가 아니라, 교사가 특정 순간에 강조한 부분이나 직접 판서한 부분이었다. 화면 전체를 복기하는 것보다, 교사가 직접 쓰고 그린 부분만 다시 보여주는 것이 훨씬 더 유용하다는 생각이 들었다.

그래서 AirClassDisplay는 여기서 멈췄다. 기술적으로는 가능했지만, 실제 수업에서 반복해서 쓸 수 있는 도구가 아니었다.

대신 선택한 것은 "판서"였다

Display를 접으면서 새로 떠오른 질문은 단순했다.

학생에게 정말 필요한 것은 교사의 화면 전체가 아니라, 수업에서 나온 판서와 강조 아닐까?

이 질문에서 AirClassTab이 시작됐다. AirClassTab은 화면 전체를 공유하는 도구가 아니라, 교사가 태블릿에서 직접 판서한 내용을 중심으로 수업 흐름을 설계한 도구다.

여기서 중요한 점은 판서가 단순히 "그림 그리기"가 아니라는 것이다. 수업 중에 교사가 작성한 필기, 강조, 설명 흐름은 그 자체로 수업의 핵심 기록이 된다. 학생이 다시 보고 싶어 하는 것도 화면 전체가 아니라, 교사가 직접 쓴 그 내용이다.

그래서 AirClassTab의 출발점은 이렇게 잡았다.

• 교사는 태블릿에서 PDF 위에 직접 판서한다
• 판서한 내용을 학생과 공유한다
• 필요한 부분만 선택해서 다시 재생할 수 있다
• 그 판서를 LLM으로 분석해 요약하고 학습자료를 만든다
• 나아가 그 내용으로 문제까지 생성한다

AirClassTab의 구조

AirClassTab은 Flutter로 구현했다. 태블릿에서 직접 쓰고 그리는 경험이 중요했기 때문에, 터치 기반 인터랙션에 최적화된 프레임워크가 필요했다.

PDF 위에 판서하기

가장 기본이 되는 화면은 PDF 위에 직접 필기하는 구조다. 교사는 수업 자료를 PDF로 불러오고, 그 위에 펜으로 직접 설명하고 강조한다.

class ClassroomScreen extends ConsumerStatefulWidget {
  const ClassroomScreen({super.key});
  // ...
}

PdfAnnotator 위젯이 PDF를 렌더링하고, 그 위에 CustomPainter 기반의 필기 레이어를 올린다. 학생이 보는 화면도 같은 구조로, 교사의 판서가 실시간으로 동기화된다.

펜 도구와 지우개

펜 도구는 색상과 두께를 프리셋으로 제공한다. 검정, 빨강, 주황, 노랑 형광, 초록, 파랑, 보라, 회색 등 수업에서 자주 쓰는 조합을 미리 준비해두고, 터치 한 번로 바꿀 수 있게 했다.

static const List<_PenPreset> _penPresets = [
  _PenPreset(label: '검정 얇게', color: Colors.black, width: 2.4),
  _PenPreset(label: '검정 기본', color: Colors.black, width: 3.6),
  _PenPreset(label: '빨강', color: Color(0xFFE53935), width: 3.4),
  _PenPreset(label: '주황', color: Color(0xFFF57C00), width: 3.8),
  _PenPreset(label: '노랑 형광', color: Color(0xFFFFC107), width: 8.0),
  _PenPreset(label: '초록', color: Color(0xFF43A047), width: 3.6),
  _PenPreset(label: '파랑', color: Color(0xFF1E88E5), width: 3.6),
  _PenPreset(label: '보라', color: Color(0xFF8E24AA), width: 4.0),
  _PenPreset(label: '회색', color: Color(0xFF616161), width: 2.8),
];

지우개는 두 가지 모드를 지원한다. 부분 삭제 모드는 펜 획의 특정 부분만 지우고, 획 삭제 모드는 한 번 그린 선 전체를 한 번에 지운다. 수업 중에 실수로 그은 선을 빠르게 처리할 때 획 삭제가 더 편한 경우가 많아서 둘 다 넣었다.

영역 선택과 캡처

AirClassTab에서 가장 중요한 기능 중 하나는 영역 선택이다. 교사가 특정 부분을 드래그로 선택하면, 그 영역만 캡처해서 LLM으로 보낼 수 있다.

Future<void> _captureAndSend() async {
  final selection = ref.read(annotationProvider).selection;
  if (selection == null) {
    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(content: Text('먼저 영역을 선택하세요'))
    );
    return;
  }
  // ... 캡처 및 LLM 분석
}

이 기능의 핵심은 "화면 전체가 아니라 필요한 부분만"이라는 철학이다. 교사가 방금 설명한 부분, 학생이 질문한 부분, 다시 강조하고 싶은 부분만 선택해서 후속 작업으로 넘길 수 있다.

리플레이: 판서를 다시 재생한다

AirClassTab에서 추가한 기능 중 특히 유용했던 것은 리플레이다. 판서는 정적인 그림이 아니라, 시간 순서대로 그려진 획의 집합이다. 이 획들을 기록해두면, 교사가 어떤 순서로 어떻게 그렸는지를 다시 재생할 수 있다.

리플레이 클립 생성

교사가 특정 영역을 선택하면, 그 영역 안에 포함된 획들을 모아서 "리플레이 클립"으로 만든다.

void _createReplayClip() {
  final annotation = ref.read(annotationProvider);
  final clip = _replayClipFactory.createFromSelection(
    selection: annotation.selection,
    strokes: annotation.strokes,
    previousVersion: _latestReplayClip,
  );
  // ...
}

리플레이 클립은 버전 관리도 된다. 같은 영역을 여러 번 설명하면 버전이 올라가고, 학생은 원하는 버전을 선택해서 다시 볼 수 있다.

학생 웹보드에서 재생

리플레이 클립은 학생 화면에서도 재생된다. 교사가 만든 클립을 서버에 업로드하면, 학생은 자기 기기에서 그 판서가 어떤 순서로 그려졌는지를 다시 볼 수 있다. 이건 단순히 결과 그림을 보여주는 것과 완전히 다르다. 교사의 설명 순서와 강조 흐름까지 함께 전달된다.

LLM 통합: 판서를 넘어서 학습자료와 문제까지

AirClassTab에서 가장 큰 방향 전환은 LLM 통합이다. 판서를 단순히 보여주고 끝내는 것이 아니라, 그 판서를 LLM으로 분석해서 다음 단계로 연결한다.

판서 분석과 요약

교사가 영역을 선택하고 "LLM 전송"을 누르면, 그 영역의 이미지가 서버로 전송된다. 서버에서는 LlmService가 이미지를 분석하고, 판서의 내용을 요약한다.

final result = await _llmService.analyzeImage(bytes);

이 요약은 단순히 OCR로 글자를 읽는 것이 아니다. 판서의 맥락, 강조된 부분, 수식이나 도형의 구조까지 함께 분석해서, 학생이 이해하기 쉬운 형태로 정리된다.

학습자료 생성

요약된 내용을 바탕으로 학습자료를 생성한다. 교사 판서의 핵심 개념을 정리하고, 관련 예시를 추가하고, 학생이 복습할 때 참고할 수 있는 형태로 재구성한다.

이 과정에서 LLM은 단순히 텍스트를 생성하는 것이 아니라, 판서의 시각적 구조를 함께 고려한다. 어떤 부분에 밑줄이 그어져 있고, 어떤 부분이 원으로 강조되었는지를 함께 분석해서, 그 의도가 반영된 학습자료를 만든다.

문제 생성

학습자료까지 생성되면, 다음 단계는 문제 생성이다. 판서에서 다룬 개념을 바탕으로 학생이 풀 수 있는 문제를 자동으로 만든다.

Future<void> _distributeQuiz() async {
  if (_llmResult.isEmpty) return;
  final result = await _llmService.sendQuizToStudents(
    _llmResult, 
    ['student_001', 'student_002', 'student_003']
  );
  // ...
}

이 문제 생성 기능은 현재까지는 LLM으로 문제를 자동 생성하는 단계까지 구현되어 있다. 생성된 문제를 학생들에게 실제로 배부하는 흐름은 아직 연결되지 않았지만, AirClassQuiz와의 통합을 곧 진행할 계획이다. AirClassQuiz의 흐름과 연결하면 학생이 문제를 풀고 결과를 제출하면 교사가 실시간으로 확인할 수 있게 될 것이다.

전체 플로우 정리

AirClassTab에서 하나의 수업 흐름이 완성되는 과정을 정리하면 다음과 같다.

이 플로우의 핵심은 각 단계가 단순히 순차적으로 나열된 것이 아니라, 하나의 판서가 여러 형태로 재사용된다는 점이다.

• 교사가 PDF 위에 판서한 내용은 그대로 학생과 공유된다
• 그 중 특정 영역은 리플레이 클립으로 만들어서 설명 순서까지 함께 전달된다
• 같은 영역은 LLM으로 분석되어 요약과 학습자료가 된다
• 학습자료를 바탕으로 문제가 생성되고, 곧 AirClassQuiz와 연동하여 학생에게 배부될 예정이다

즉 한 번의 판서가 실시간 공유, 리플레이, 요약, 학습자료, 문제까지 여러 형태로 파생된다. 문제 배부까지의 흐름은 아직 연결되지 않았지만, 전체 아키텍처는 이 방향으로 설계되어 있다.

이전 Display와 어떻게 다른가

AirClassTab은 AirClassDisplay와 완전히 다른 접근이다.

구분	AirClassDisplay	AirClassTab
공유 대상	화면 전체	판서 영역
입력 방식	화면 캡처	직접 필기
학생 경험	수동적 시청	능동적 복기
후속 활용	녹화본 저장	LLM 분석 및 자료 생성
교사 부담	노트북 추가 필요	태블릿만으로 가능
핵심 철학	"보여준다"	"같이 만든다"

가장 큰 차이는 방향성이다. Display는 교사가 학생에게 "보여주는" 구조였다. 화면을 전달하고, 학생은 그것을 받아본다. 반면 AirClassTab은 교사와 학생이 같은 판서를 중심으로 상호작용하는 구조다. 교사가 판서하면 학생이 보고, 학생이 다시 재생하고, 그 판서가 학습자료와 문제로 발전한다.

또 다른 중요한 차이는 데이터의 재사용성이다. Display의 화면 녹화는 한 번 쓰고 끝나는 경우가 많다. 하지만 AirClassTab의 판서는 획 단위로 저장되기 때문에, 리플레이로 재생할 수도 있고, LLM으로 분석할 수도 있고, 문제로 변환할 수도 있다. 같은 원본 데이터가 여러 형태로 재생산되는 구조다.

아직 남은 과제

AirClassTab은 아직 초기 단계다. Flutter 기반으로 핵심 흐름을 검증하고 있지만, 실제 수업에서 반복해서 쓰기까지는 몇 가지 더 필요하다.

첫째, 실시간 동기화의 안정성이다. 교사 태블릿의 판서가 학생 기기에 얼마나 지연 없이 전달되는지, 다중 학생 접속 상황에서도 일관성을 유지하는지는 실제 교실에서 검증해야 한다.

둘째, LLM 분석의 품질이다. 수학 수업의 판서는 단순 텍스트가 아니라 기호, 도형, 수식이 섞여 있다. LLM이 이런 시각적 요소를 얼마나 정확하게 이해하고 요약하는지는 지속적으로 개선해야 할 부분이다.

셋째, AirClassQuiz와의 연동이다. LLM으로 생성한 문제를 학생에게 실제로 배부하고, 응답을 수집하고, 결과를 확인하는 흐름은 아직 연결되지 않았다. AirClassQuiz에 이미 구현된 퀴즈 응답 수집 구조를 활용하면 이 흐름을 곧 완성할 수 있을 것이다.

넷째, AirClassSlide와의 통합이다. AirClassSlide가 슬라이드 중심의 수업 흐름을 담당하고, AirClassTab이 판서 중심의 흐름을 담당한다면, 이 둘을 어떻게 하나의 수업 안에서 자연스럽게 연결할 것인지가 더 큰 과제다.

마치며

AirClass에서 가장 먼저 시작했던 Display는 여기서 마무리된다. 화면 전체를 공유하려던 시도는 기술적으로는 가능했지만, 실제 수업 동선에서는 반복해서 쓸 수 없는 도구였다.

대신 AirClassTab은 판서를 중심으로 완전히 다른 방향을 제시한다. 교사가 태블릿에서 직접 쓰고 그린 내용이 학생과 공유되고, 리플레이로 재생되고, LLM으로 분석되어 학습자료와 문제까지 이어진다.

이제 AirClass는 "학생에게 무엇을 보여줄 것인가"라는 질문에서, "학생과 함께 무엇을 만들 것인가"라는 질문으로 방향을 바꿨다. 판서는 더 이상 일회성 설명 도구가 아니라, 수업의 핵심 기록이자 학습 자료의 출발점이 된다.

다음 글에서는 AirClassTab의 판서 데이터가 어떻게 저장되고, 어떻게 학생 기기에서 재생되는지 더 구체적으로 다뤄 보겠다.