3개월 간의 교내 인트라넷 사이드 개발 및 운영기

사이드의 시작은 전교회장으로부터의 부탁이었다. 자기의 공약 사항인 건의함 사이트를 만들어 줄 수 있냐는 것이었다. 사실 나는 예전부터 욕심을 가지고 있었는데, 학교 교내 “통합 온라인 플랫폼”이었다. 그래서 방향을 단순 청원 사이트를 넘어 교내 모든 기능을 다 넣은, 우리 학교의 슈퍼앱으로 만들고 싶었다. 마치 한국디지털미디어고등학교의 <디미고인>#과 한세사이버고등학교의 <한빛>#처럼 말이다. 그래서 지체 없이 해당 요청을 수락하고 개발하기 시작했다.

소개

PHP를 메인으로 개발에 착수하였다. PHP를 기반으로 HTML, CSS와 몇몇 부분에서는 JS 및 제이쿼리, 디자인은 부트스트랩을 내 입맛대로 커스텀하여 사용하였다. 아이콘을 위해 Fontaswome 5를 사용했다. UI 디자인도 직접했다.

학교에서 예산 지원을 받기 어려워 최대한 가성비, 모두 비용이 들지 않는 선에서 해결해야 했다. 서버는 AWS의 프리티어를 사용하였다. (t2.micro) 즉, 프리티어의 기간인 1년이 지나면 폭파해야 된다는 의미겠다. 여기에 Apache2로 웹서버를, MySQL로 DB를 구축하였다.

가입 절차는 간소하게, 수집하는 개인정보는 간단하게 갔다. 딱 필요한 정보인 이메일, 이름, 학년, 반, 번호만 수집했다. 이메일은 비밀번호 찾기 기능을 위함이며 이름/학년/반/번호는 개인화된 서비스를 제공하기 위함이었다. 이 외 다른 개인정보는 일절 수집하지 않았다. 하다못해 IP도. 비밀번호는 MD5로 암호화해서 DB에 저장하였다. 그래서 내가 입력한 비밀번호는 아무도 모른다. 암호화가 되기 때문이며 복호화도 매우 어렵다.

이렇게 노력했음에도 개인이 만들었다는 이유로 학생들이 사이드의 보안을 신뢰하지 않는다는 의견이 몇몇 들렸는데, 솔직히 좀 속상하게 생각했다. 당장 메타는 페이스북의 비밀번호를 암호화하지 않고 평문으로 저장하여 과징금을 받았다. 나는 메타와 다르게 최소한의 개인정보만 수집했으며 비밀번호도 암호화하여 저장했다. 메타는 돈벌이를 위해 별별 정보를 다 수집하며 심지어 비밀번호 암호화까지 안 했다. 그런데도 메타의 페이스북과 인스타그램은 곧잘 사용하면서 사이드의 보안은 신뢰하기 어렵다니 어불성실이 아닌가?

그리고 처음으로 PWA 앱을 만들어봤다. 가장 좋은 것은 실제 네이티브 앱이지만 후술 할 현실적인 문제로 PWA 앱을 만들게 되었는데, 과정도 서비스 워커랑 코드 몇 줄만 추가해 주면 되는 간단한 작업인 데다가 앱도 네이티브 앱처럼 작동하여 꽤나 만족스러웠다. 다만 설치 과정이 직관적이지 않은 것이 흠이며 이를 보완하기 위해 PWA 앱 설치 유도 팝업을 넣었으나, 여전히 직관적이지 못했던 것이 사실이다.

정식 출시와 마케팅

마케팅 수단은 팔로워 500명 가량 되는 학교 인스타그램 계정 및 반마다 배부하는 포스터였다. 사이드라는 이름의 작명부터 로고, 포스터까지 내가 직접 만들었다. 다만 사이드라는 이름의 작명은 나의 잘못된 선택이라 생각한다. 최초 의도는 학교 앱 같은 느낌에서 벗어나고 싶었지만(왜 저런 생각을 했었는지 지금 생각해도 모르겠다) 학교 앱이라는 느낌을 주지 못해 네이밍적인 측면에서 실패라고 볼 수 있겠다.

사이드 출시 소식을 인스타그램에 게시하고 반마다 제작한 포스터를 배부했다. 타겟은 1-2학년으로 졸업을 앞둔 3학년은 타깃으로 삼지 않아 포스터를 배부하지 않고 마케팅을 딱히 하지 않았다. 이렇게 출시를 한 첫날 가입자는 50명이었다. 1-2학년 합쳐 대략 300명 정도 되기 때문에 생각보다 저조한 수치여서 좀 많이 실망했다.

왜 실패했을까?

사이드는 학교 시스템과 연동되는 부분이 없다. 강원과학고에서는 학생들이 만든 시스템으로 이석 관리를 하고 있고, 디미고에서는 방과후 신청, 동아리 신청, 과제 제출, 외출 신청 등 많은 부분을 교내 앱을 통해 하고 있다. 하지만 사이드는 아무것도 학교 교내 시스템과 연동하지 못했다. 즉, 사이드를 설치해 봤자 급식/시간표 확인 외 할 수 있는 것이 없다는 뜻이다.

내가 생각한 사이드로 전환하면 좋을 학교 내 포인트가 있었지만 “교내 앱으로 전환하자”라는 제안을 하기에도 어려웠다. 당장 선생님 선까지 가지 않아도 학생들 중에도 많이 “지금도 문제 없는데 굳이?”라는 의견이 많았다. 굳이 현행상으로도 문제없는 부분을 깨고 전환을 하려고 설득하는 것도 많이 어려울 것 같아 포기했다.

결과적으로 교내 앱이라는 메리트를 사이드는 단 하나도 살리지 못했다. 즉, 사이드에서 할 수 있는 것도 없었다.

또한 인원 부족의 영향도 컸다. 개발/디자인/마케팅/유지보수를 모두 혼자 1인 체제로 진행하는 것은 꽤나 버거운 일이다. 다른 학교에서의 교내 앱 사례를 봐더라도 최소 동아리 단위로 못해도 5-8명이 각자 분야를 나눠 개발하고 있다.

“내가 직접 학생을 선발하고 가르쳐서 사이드 개발에 투입해볼까?”라는 생각을 해보기도 했지만, 단기간에 사이드 개발에 참여시킬 정도로 의지 있는 인원을 뽑기도, 실력을 향상하는 것도 어려울 것 같았다.

예산 문제도 한몫한다. 무료로 사용할 수 있게 해주는 AWS 프리티어의 스펙과 성능은 절망적이었다. 원하던 퍼포먼스가 나오지 않았다. 내가 원하는 퍼포먼스가 나오는 EC2의 서버비는 비록 큰 금액은 아니지만 예산안을 올린다면 바로 컷당할 금액이다. 또한 아무리 PWA를 넣는 뭘 넣은 해봐도 앱스토어에서 다운로드하는, 그 앱의 접근성이 제일 높다 생각했다. 하지만 앱스토어 출시 비용은 $99, 14만 원 가까이하여 지체 없이 포기했다.

내가 망각한 사실은 보통 교내 앱을 자체적으로 개발하고 성공적으로 사용하는 학교는 마이스터고, 특성화고 등 IT 학교이지만 여기는 평범한 일반고였다는 것이다. 개발과 디자인이 되는 인력을 수급하기도 어렵고, 일반고에서는 기존 몇십년동안 이어진 학교 시스템을 타파하기도 어렵다.

느낀 점

학생들이 만드는 교내 앱이라는 시도는 특수한 학교에서만 가능하다. 일반고에서 이런 시도를 하는 것은 무모한 시도에 불과하다고 생각한다.