COVID-19 시국 때문에 사용하는 우리 대학교의 비대면 강의 시스템에 불편함을 느껴 만들었던 프로그램이 있다.
최근에 이 프로그램을 업데이트하면서 배포하게 되었는데 이 과정에서 겪은 경험들을 공유해 보려 한다.
KNU LMS Scheduler
프로젝트 시작 이유
나는 대학교에 다니고는 있지만, 학교에서 배우는 내용보다 혼자 작업하면서 경험해 보는 걸 선호하는 편이다.
복학 후 COVID-19 때문에 모든 강의를 온라인으로 진행하고 있는데 이런 상황과 나의 성향 때문에 학교 과제나 강의가 뒷전인 경우가 많았다.
기존 학교의 온라인 강의 시스템은 인터페이스가 보기 너무 힘들었고 특히 과목별로 분리되어 모든 강의들을 돌아다니면서 완료하지 못한 강의들을 찾아다녀야 했다.
또한 내가 신청한 강의 외에 학교에서 강제로 내 수강 목록에 넣어둔 불필요한 강의들이 화면에 표시되는데 이 두 가지의 환장의 콜라보로 내가 못 듣고 결석 처리되어버리는 과목들이 생겼다.
최소한 과제는 몰라도 수업은 모두 출석하자는 생각으로 이번 프로젝트를 시작하게 되었다.
개발방향
대충 구상한 개발방향은 학교에서는 제공하는 API가 없기 때문에 크롤링을 통해 얻은 학교 데이터를 새로운 인터페이스로 재구성하자는 생각이었다.
처음에는 나 혼자 사용할 생각이었기 때문에 인터페이스의 디자인적인 부분에 대해서는 생각하지 않았다.
무엇보다 최소한의 조작으로 원하는 정보들을 한눈에 확인할 수 있게 하는 게 목표였다.
배포를 결심하게된 이유
처음에는 혼자 쓰려고 만들었지만 완성 후에 나름 괜찮은 것 같아서 일단 주변 동기들에게 공유해줬다.
그렇게 한 학기 동안 잘 사용한 뒤, 하고 있던 토이 프로젝트를 마치고 이번엔 어떤 프로젝트를 해볼까 고민하던 중 이 프로그램을 쓰면서 동기들이 해주었던 피드백들과 내가 불편하다고 느낀 점 들이 생각났다.
그 부분 들을 업데이트하고 나니 이 프로그램을 그냥 혼자 쓰고 버리긴 아까워서 배포하게 되었다.
개발 과정
도구선정
Javascript
크롤링을 통해 정보를 받아야 한다고 생각했을 때 가장 먼저 생각난 게 Python과 Javascript였다.
그중에 Javascript에는 이미 몇 번 사용해본 Electron이라는 프레임워크도 있었고 크롤링과 동시에 해당 데이터를 Front에 넘길 수 있어 서버가 필요 없는 좋은 방법인 것 같았다.
처음에는 이 프로젝트는 혼자 사용하고 유지 보수할 생각이 없었기 때문에 Typescript를 고려하지 않았는데 배포하고 피드백 받은 내용들을 수정하는 순간 후회했다.
Electron
- 속도는 느리지만 해당 프로그램이 그렇게 성능이 좋을 필요는 없으니 상관없음
- 자체적으로 브라우저를 포함
- 배포의 편리함
- 다른 프레임워크, 라이브러리와 호환성이 좋음
- Javascript를 이용해 Windows 프로그램을 작성할 때 다른 대안 이 생각나지 않음
Puppeteer
크롤링을 할 때 기본적으로 사용하는 cheerio와 같은 파싱 라이브러리만으로 학교 페이지에 개인정보들을 입력하거나 정보들을 가져올 수 없었기 때문에 브라우저 자체를 핸들링할 필요가 있었고 이런 경우 puppeteer를 사용했다. (일반적인 크롤링 방법에 비해 속도가 느리기 때문에 사용을 최소한으로 하려 고민 많이함)
크롤링
처음엔 일반적인 사이트처럼 puppeteer를 이용해서 로그인만 넘기면 간단하게 해결될 줄 알았는데 필요한 데이터들이 모두 iframe안에 들어가 있었 다.
일반적인 경우라면 해당 iframe에 진입하는 단계를 추가해주기만 하면 평범하게 크롤링할 수 있었겠지만 특이하게 iframe내부 HTML 코드에는 그 어떤 내용물도 없었다.
그렇게 돌아다니는 동안 온라인 강의 시스템중 메뉴중 유일하게 성적 처리 관련 탭들만 정보가 온전히 HTML 태그 안에 들어가 있었고 심지어 사용자에게 표시되지 않는 링크들도 존재했다.
거기서 대부분의 정보를 구하고 그걸 기반으로 URL의 규칙성 등을 이용해 추가적인 정보들을 크롤링했다.
로그인 처리
Electron은 Chromium을 포함하고 있으니 혼자 사용하려 했을 때는 그냥 학교의 로그인 페이지 자체를 띄어주고 로그인이 완료되면 크롤링을 시작하게 했다.
이번에 업데이트하면서 로그인 페이지를 직접 만들고 입력받은 정보를 따로 로컬에 저장 후 학교 로그인 페이지에 입력해 주는 방법을 사용했다.
일단 로그인 정보 저장 기능을 원하는 사람들이 많았고 이 프로그램은 사용할 때마다 학교 사이트들을 돌아다니면서 정보들을 다시 크롤링해야 해서 최대한 크롤링 대상을 줄이기 위해 사용자가 원하는 과목만을 지정 및 저장해 사용하려면 사용자 정보를 로컬에 저장해 두고 비교해야 할 필요가 있었다.
back-end(?)
이걸 back-end라고 부르기 민망한 수준이지만 일단 front-end는 더더욱 아니기에 이렇게 분류 했다.
Electron back-end에서 작성한 내용들은 로그인 정보와 크롤링한 데이터의 CRUD, 데이터들을 클렌징해서 front로 전달, 브라우저 핸들링, 프로그램 종료 같은 부분들의 코드를 작성했다.
그리고 처음에 램 누수를 생각하지 않고 엉망진창으로 코드를 짜다가 Electron으로 작성해서 돌려본 프로그램들이 하나같이 램 누수가 있어서 이런 부분들도 신경 써서 수정했다.
front-end
일단 위에서 서술했듯이 리액트를 사용했는데 처음에는 나만 쓸 생각이었기 때문에 부트스트랩을 이용해서 대충 찍어냈다.
하지만 배포를 목적으로 수정했을 때는 부트스트랩을 이용한 부분들은 모두 빼버리고 이전에 COVID19 Dashboard 토이 프로젝트를 진행할 때 만들었던 인터페이스를 대부분 따왔다.
항상 느끼는 거지만 나는 미적 감각이 없어서 한번 인터페이스를 만들어두면 다른 프로젝트 할 때 어울리는 인터페이스면 그대로 가져다가 쓰는편이다. (아니면 디자인 생각하는데 시간을 너무 많이 씀)
피드백
어느 정도 실사용이 가능해지면서 일종의 클로즈 베타 느낌으로 또 한번 동기들에게 피드백을 요청했고 동기들이 준 피드백을 기반으로 소소한 버그들을 수정했다.
배포
이 부분은 Electron을 사용한 가장 큰 이유기도 한데 편리하게 실행파일로 빌드해서 배포할 수 있었다.
동기가 에브리타임이라는 대학교 커뮤니티를 알려줬는데 학생증이 있어야 계정을 생성할 수 있어서 그냥 친구 아이디를 빌려서 게시물을 작성했다.
배포는 해당 프로젝트 Repository에 릴리즈 탭을 통해 진행했다.
마지막으로
배포하면서 걱정했던 점
아무래도 Github 릴리즈가 일반적인 대학생들에게는 친숙하지 않아서 걱정했지만 다행히 다들 잘 사용하는 것 같았다.
물론 Github의 이슈 섹션에 피드백을 받는건 불가능 했지만.. 그래도 나름 댓글로 여러가지 피드백이 있었다.
그리고 테스트를 해본 사람들이 모두 내 동기들이다 보니 수강하는 과목들이 비슷한데 다른 과목에서 발생할지 모를 상황들을 예외처리 못하진 않았을까 걱정했다.
이 부분에 대해서는 아직 피드백이 없으니 확신할 순 없지만 성공적이었다고 생각한다.
느낀점
학교 온라인 강의 시스템에서 내가 불편하다고 느끼는 부분들을 다른 사람들도 똑같이 공감하고 있다는 것도 신기했고 프로젝트도 그냥 혼자 만들고 끝나는게 아니라 완성후 배포도 해보고 사용자들의 반응도 보고 하는게 더 재미있는 것 같다.
해당 프로젝트도 일회성으로 끝나는게 아니라 사용자들이 준 피드백을 기반으로 시간 날 때마다 업데이트를 하는 것도 좋을 것 같다. (물론 졸업 전까지만 ^^)
반응
올린지 몇분만에 HOT 게시물과 실시간 인기 검색 게시물이 되었다.
에브리타임에는 많은 반응을 얻은 글을 연도와 학기별로 구분해 Best 게시물로 선정해 놓는 기능이 있던데 나중에는 거기에 선정되어 있었고 특별한 경험이었다.
분명히 익명으로 올렸는데 깃허브 링크에 이름이 포함되어있어서 의도치 않게 익명성이 전혀 없어졌지만 게시물 댓글들도 재미있는 댓글들이 많았다.