이 글에서 다루는 내용
AirClass에서 가장 먼저 손댄 부분이 왜Display였는지- 첫 시도에서 가장 중요했던 기준이 무엇이었는지
- 실제로 어느 정도까지는 잘 되었는지
- 왜 결국 수업 현장에서는 쓰지 못하고 멈추게 되었는지
앞선 글들에서 적었듯 AirClass는 거대한 구조를 먼저 짜고 들어간 프로젝트가 아니었다. 내 수업에서 가장 불편했던 문제를 가장 먼저 건드려 보는 쪽으로 시작했다. 그래서 실제로 제일 먼저 개발을 시도한 부분도 Quiz나 전체 플랫폼이 아니라 Display 쪽이었다.
왜 가장 먼저 Display를 만들려고 했는가
내가 태블릿으로 수업하면서 가장 먼저 크게 느낀 문제는, 학생들이 지금 교사가 보고 있는 화면을 충분히 편하게 따라오지 못한다는 점이었다. 같은 자료를 보고 있다는 장점은 분명했지만, 실제 교실에서는 그 장점이 언제든 단점으로 뒤집힐 수 있었다.
수업은 계속 앞으로 나아가는데 어떤 학생은 방금 전 설명을 다시 보고 싶어 하고, 어떤 학생은 잠깐 놓친 부분 때문에 다음 내용을 따라가기 어려워한다. 그래서 처음부터 내가 해결하고 싶었던 것은 단순한 화면 공유가 아니었다.
내가 원했던 것은 대략 이런 형태였다.
- 교사의 수업 화면이 학생들에게 부드럽게 전달될 것
- 학생들이 자기 화면에서도 그 내용을 볼 수 있을 것
- 필요하다면 직전 내용을 다시 확인할 수 있을 것
- 기존 미라캐스트보다 더 안정적이고 더 유연할 것
즉 AirClassDisplay의 첫 출발은 "화면을 뿌리는 기술" 자체보다, 학생이 수업 화면을 덜 놓치게 만드는 방법에 가까웠다.
이 시도에서 가장 중요했던 것은 레이턴시였다
이 시점에서 가장 중요했던 기준은 아주 분명했다. 레이턴시가 낮아야 한다는 것이었다.
수업 도구에서는 몇 초 뒤에 보이는 화면은 사실상 쓸 수 없다. 교사가 설명하는 타이밍과 학생이 보는 화면이 어긋나면, 아무리 화질이 좋아도 수업 흐름은 금방 끊긴다. 그래서 첫 시도에서 내가 가장 중요하게 본 것은 해상도나 화려한 기능보다, 실제 수업에서 체감되는 반응 속도였다.
내 기준은 단순히 "영상이 나온다"가 아니었다.
- 가능한 한
Miracast이상으로 부드럽게 렌더링될 것 - 교사가 넘기는 화면이 학생 화면에서도 거의 즉시 보일 것
- 학생이 자기 기기에서 본다고 해도 수업 흐름이 끊기지 않을 것
그래서 자연스럽게 관심은 실시간 전송 쪽으로 향했고, 그 과정에서 WebRTC 기반으로 화면을 서버로 보내고 다시 학생들에게 전달하는 구조를 구상하게 되었다.
실제 구현도 꽤 분명한 구조를 갖고 있었다
나중에는 녹화나 분석 같은 방향까지 붙었지만, 실제 저장소 수준에서 보면 AirClassDisplay는 생각보다 분명하게 역할이 나뉘어 갔다.
backend/:FastAPI가 세션과 송출 흐름을 제어하고, 미디어 서버 프로세스를 관리하는 쪽frontend/: 학생이나 교사가 브라우저에서 스트림을 보고 상태를 확인하는 웹 화면android/: 교사 쪽 송출 입력을 따로 붙여 보려던 앱 영역dashboard/,gui/: 운영 화면과 설치/실행 보조 도구
즉 실제로는 "태블릿 화면 하나 띄우기"가 아니라, 송출 입력, 실시간 전송, 학생 수신 화면, 운영 제어를 분리한 구조로 가고 있었다. 교사 화면을 서버로 올리고, 백엔드가 세션과 미디어 계층을 제어하고, 학생은 웹에서 받는 구조였다. 그래서 문제도 더 분명해졌다. 이 구조는 기술적으로는 가능했지만, 실제 교실 동선에서는 입력 단계부터 이미 마찰이 컸다.
구현 구조를 조금 더 실제에 가깝게 단순화하면 아래 그림에 가까웠다.
단순 송출이 아니라 "학생도 볼 수 있고 다시 볼 수도 있는 화면"을 원했다
여기서 중요한 점은 단순한 미러링을 만들고 싶었던 것이 아니라는 점이다. 기존 미라캐스트도 당장 화면을 띄우는 일 자체는 가능하다. 하지만 그것만으로는 내가 원했던 문제를 해결하기 어려웠다.
내가 원했던 것은 교실 앞 화면만 보여 주는 구조가 아니라, 학생 각자가 자기 화면에서도 내용을 확인할 수 있는 구조였다. 더 나아가면 단순히 지금 화면만 보는 것이 아니라, 조금 전 내용을 다시 확인할 수 있는 방향도 함께 생각하고 있었다.
즉 이 시도는 "태블릿 화면을 TV에 띄운다" 수준이 아니라, 수업 화면을 학생에게 전달 가능한 형태로 다시 다루는 시도였다. 그래서 Display는 단순한 출력 장치가 아니라, AirClass의 가장 첫 실험장이 되었다.
결과는 생각보다 나쁘지 않았다
실제로 구현을 진행해 보니 결과는 제법 괜찮았다. 적어도 내가 처음 기대했던 핵심 기준, 즉 부드러움과 반응성 측면에서는 가능성을 확인할 수 있었다.
완벽한 제품 수준이라고 할 수는 없었지만, 단순 아이디어 수준을 넘어서 "이 방향이면 될 수도 있겠다"는 감각은 분명히 있었다. 수업 화면을 네트워크를 통해 전달하면서도 제법 부드럽게 보이게 만드는 데까지는 도달했기 때문이다.
이 지점까지만 보면 AirClassDisplay는 꽤 괜찮은 출발처럼 보였다. 문제는 기술 성능 그 자체보다, 실제 수업 준비와 운영 동선 안에 이 방식이 들어올 수 있느냐였다.
그런데 실제 수업에서는 오히려 준비물이 늘어났다
여기서 딜레마가 생겼다. 원래 내가 하던 수업은 비교적 단순했다. 태블릿과 동글만 챙기면 교실에서 바로 수업을 진행할 수 있었다. 이건 생각보다 큰 장점이었다. 장비가 적고 준비가 단순할수록 수업에 들어가기 쉽기 때문이다.
그런데 AirClassDisplay 방식으로 가면 얘기가 달라졌다.
- 태블릿만이 아니라 노트북도 함께 들고 다녀야 하고
- 브라우저를 띄워야 하고
- 모니터 연결도 신경 써야 하고
- 전체 동작 흐름을 수업 전에 한 번 더 점검해야 했다
즉 학생 경험을 더 좋게 만들기 위해 시작한 시도였지만, 정작 교사 입장에서는 수업 준비와 운영이 더 번거로워지는 문제가 생겼다. 실제 교실에서는 기능 하나가 좋아지는 것보다, 전체 준비 과정이 얼마나 단순한가가 더 중요할 때가 많다. 이 부분이 생각보다 컸다.
결정적인 문제는 태블릿 화면을 서버로 보내는 방식이었다
더 큰 문제는 태블릿 화면을 어떻게 서버로 보내느냐였다. 내가 구상한 구조에서는 태블릿 화면이 서버로 올라가고, 그 화면이 다시 학생들에게 전달되어야 했다. 그런데 실제 수업에서 많이 쓰던 Miracast 방식으로 태블릿을 연결하면 화면 캡처가 되지 않았다.
이 말은 곧, 태블릿 화면을 서버로 WebRTC로 보내는 핵심 단계가 막힌다는 뜻이었다. 화면을 학생에게 전달하려면 먼저 소스를 가져와야 하는데, 그 출발점 자체가 매끄럽게 연결되지 않았던 것이다.
결국 문제는 단순히 "조금 불편하다" 수준이 아니었다. 내가 실제 수업에서 유지하고 싶었던 태블릿 중심 운영 방식과, AirClassDisplay가 요구하는 전송 구조가 서로 충돌하고 있었다.
- 태블릿만으로 간단히 수업하고 싶다
- 그런데 학생 화면까지 보내려면 서버 송출 구조가 필요하다
- 그런데 미라캐스트 기반 연결에서는 화면 캡처가 막힌다
- 그래서 노트북을 추가로 들고 별도 흐름을 만들어야 한다
이 딜레마는 단순한 버그 하나보다 더 근본적인 문제였다.
그래서 이 시도는 실제 사용으로 이어지지 못했다
결과적으로 AirClassDisplay의 첫 시도는 기술적으로 완전히 실패한 프로젝트는 아니었다. 오히려 어느 정도는 꽤 부드럽게 동작했고, 방향성도 분명히 있었다.
하지만 실제 수업에 들어오는 순간 기준이 달라졌다. 수업 도구는 데모가 아니라, 교사가 반복해서 무리 없이 꺼내 쓸 수 있어야 한다. 그 기준에서 보면 이 시도는 아직 멀었다.
학생 입장에서 얻는 이점은 분명했지만, 교사 입장에서 준비물이 늘고 운영 흐름이 복잡해지는 순간 실제 채택 가능성은 크게 떨어졌다. 게다가 태블릿 화면 송출 구조에서 생긴 제약 때문에 핵심 흐름 자체가 매끄럽게 이어지지 못했다.
그래서 이 단계에서 개발은 실제 사용으로 넘어가지 못했고, 자연스럽게 멈추게 되었다.
그래도 이 시도가 남긴 것은 분명했다
비록 이 시도가 바로 수업 현장에 정착하지는 못했지만, 남긴 것은 분명했다. 적어도 나는 이 과정을 통해 AirClass에서 무엇이 중요한지 더 선명하게 보게 되었다.
첫째, 교육용 도구는 기술적으로 가능하다는 것만으로는 충분하지 않다. 수업 준비 동선 안에서 감당 가능해야 한다.
둘째, 학생 경험을 개선하는 기능이라도 교사 운영 비용이 너무 커지면 실제 사용으로 이어지기 어렵다.
셋째, Display 문제는 단순 출력 문제가 아니라, 이후 AirClass 전체를 설계할 때 계속 따라다닐 핵심 문제라는 점이 보였다. 학생에게 무엇을 어떻게 전달할지, 그리고 그것을 교사가 어떤 부담으로 운영하게 될지는 이후 구조에서도 계속 중요한 기준이 되었다.
그래서 AirClassDisplay의 첫 시도는 멈췄지만, 헛수고였다고 생각하지는 않는다. 오히려 이 실패 덕분에 무엇을 우선해야 하는지가 더 명확해졌다.
마치며
AirClass에서 가장 먼저 개발을 시도한 것은 Display였다. 그만큼 처음 문제의식이 "학생들이 수업 화면을 어떻게 따라오게 할 것인가"에 가까웠기 때문이다.
레이턴시와 부드러운 렌더링이라는 목표는 어느 정도 확인할 수 있었지만, 실제 수업에서는 장비와 운영 방식의 복잡성이 더 큰 벽이 되었다. 특히 태블릿 중심 수업 흐름을 유지하면서도 화면을 서버로 올려 학생에게 전달하는 구조는 생각보다 훨씬 까다로웠다.
다음 글에서는 이 경험 이후, AirClass를 어떤 쪽으로 다시 바라보게 되었는지 이어서 적어 보겠다.
💬 댓글
이 글에 대한 의견을 남겨주세요