[회고] 교내 성적알림서비스

I. 문제의 시작, 불편함

학생에게 성적은 꽤나 중요하다. 우리 학교는 기말고사 후 2주간의 성적 입력기간이 존재한다. 2주의 기간동안 성적 확인을 위해 교내 사이트를 들락날락하는 것이 참 귀찮았다. 사이트에 접속하고, 로그인을 하고, 학사정보의 성적 탭을 누르고, 또 현 학기 성적/석차 조회 탭을 누른 뒤에 스크롤을 내려야만 성적을 확인 할 수 있다. 무려 4번의 클릭과 스크롤이 요구되었다. 게다가 성적이 아직 미입력이라면 다시 또 이런 귀찮은 과정을 거쳐야 했다.

 

모든 학우를 위해 성적알림서비스를 만들어야겠다고 생각했을 때(23-2학기), 성적 확인 과정의 불편함이 나 혼자만 느끼는 것은 아닐까? 하는 의문이 들었다. 나만의 문제라면 굳이 서비스를 만들 필요가 없기 때문이다. 그래서 문제를 검증해보았다. 주변 학우들을 만날 때마다 내가 느낀 불편함과 서비스 아이디어를 나눴다. 수십명의 학우들과 이야기를 나눈 결과 대부분의 학우들이 겪는 공통의 문제라는 것을 확인할 수 있었다. 그렇게 프로젝트는 시작되었다. 나의 문제가 아닌 우리의 문제로부터 모두가 공감하는 포인트를 가지고 출발했다는 점이 진행 과정 중에 발생한 어려움을 극복하고 성장할 수 있었던 원동력이었다.

 

II. 문제 해결 과정

초기 접근 (2023-1 학기)

처음 문제의식을 마주한 23-1학기에는 개인적인 불편함 해소를 위해 나를 대상으로 하는 프로그램을 만들었다. 단순히 카카오톡으로 알려주면 좋지 않을까 하는 생각에 카카오톡 api를 연동하여 나에게 보내기로 알림을 주도록 했다. 그래서 따로 배포하지 않고 로컬에 백그라운드로 실행하여 성적입력 기간동안 동작하도록 해두었다. 실제로 알림을 받으니 정말 기분이 좋았다!

 

정식서비스 개발 및 배포/운영 (2023-2학기)

다음 학기인 23-2학기에는 정식서비스를 만들어야겠다고 다짐했다. 나만의 문제의식이 아니라는 것을 검증한 후에 바로 개발에 착수했다.

1. 태도
   기말고사 기간과 일부 겹쳐 개발을 시작했기에 시간적 압박이 있었다. 하지만 서비스가 배포되어서 학우들에게 불편함이 해소되는 기분 좋은 경험을 선물해주는 장면을 계속해서 상상했다. 그리고 주변 학우들에게 이것을 이뤄낼 것이라는 것을 말했다. 누군가에게 목표를 이야기하고 그것을 지속적으로 상상하는 것의 힘을 알았기 때문이다. 학우들이 겪는 이 문제를 내가 해결해야겠다는 나름의 사명감도 갖게 되었다. 그래서 자연스럽게 서비스를 사용하는 유저에게 최고의 UX를 선물하는 것에 가치를 두고 임했다.
   
   
2. 필요기능 정의
   • 프론트엔드
     
     • 입력받는 정보는 아이디, 비밀번호, 문자알림을 받을 전화번호이다.
     • 잘못된 계정이 입력된 경우 성적알림이 가지 않는 최악의 상황이 발생한다. 그래서 유저가 약간의 기다림을 감수하면서 정확한 알림발송을 위해 계정입력 과정에서 유효성 여부를 확인하도록 했다.
     • 추가적으로 전화번호와 계정의 중복 여부도 체크하였다.
   • 백엔드
     • 프론트엔드에서 요구되는 유효성 체크 및 중복 체크, 알림예약 등의 API를 구현한다.
     • DB 계정정보에 대해 일정시간마다 성적 업데이트 여부를 확인하여 성적이 업데이트 된 경우 문자를 발송하는 루틴을 구현한다.
       
       
3. 기술 스택 선정
   • 웹으로? 앱으로?
     가장 첫 고민은 개발을 웹으로 할지 앱으로 할지에 대한 고민이었다. 결정은 꽤 쉽게 내렸다. 성적알림 받으려고 앱을 설치 하는 것이 유저에게 오히려 귀찮음을 야기할 것이라고 생각했다. 나였어도 굳이 설치하기 싫었을 것 같다. 그리고 아이디, 비밀번호, 전화번호 정도만 입력하면 되었기 때문에 웹으로 만드는게 좋겠다고 판단했다. 링크하나만 있으면 되기 때문이다.
     
     
   • 웹 기술 스택 선정
     단 기간에 서비스를 개발해야했기에 나에게 가장 익숙한 스택(react, node, firebase, ec2)을 사용했다. 프론트의 경우 1~2페이지만 개발하면 되기에 굳이 react를 사용할 이유는 없었지만 react 사용 경험을 쌓기 위해 사용하기로 했다.
     
     
   • 어떤 방식으로 알림을 보내야 할까?
     카톡, 이메일, 문자 등 다양한 알림수단이 존재했다. 알림발송 시 유저가 알림을 바로 확인할 수 있는 것이 가장 중요하다고 보았다. 이메일을 잘 확인하지 않는 학우들이 있으므로 이메일은 제외했다. 공지의 성격이 있기 때문에 카톡보다는 문자가 상대적으로 적합하다고 판단했다. 카톡을 잘 확인하지 않거나 다른 카톡에 의해 알림이 묻히는 등의 경우가 있을 수 있다고 생각했다. 문자 API로는 네이버 클라우드 플랫폼의 Simple & Easy Notification Service를 사용하려 했으나 당시에 일시적으로 지원이 중단된 상태였다. 다른 api를 찾아보았는데 종류가 꽤 다양했다. 가격, UI의 직관성, 사용의 편의성 등을 비교하여 solapi를 사용하기로 했다.
     
     
4. 서비스 구조

서비스 아키텍처

 

5. 서비스 홍보
에브리타임, 실명카톡방, 지인 카톡방 등의 채널에 공지를 작성하여 올렸다. 공지 글도 어떻게 하면 학우들이 서비스에 대해 공감하고 명확히 알 수 있을까?를 생각하며 작성하려 노력했다.

6. 운영 과정

• 서버가 터졌다
  홍보 후 거의 바로 하나 둘씩 유저가 들어오는 모습을 모니터링하며 신기하고 뿌듯했다. 서비스가 인정받는 느낌도 들어 기분 좋았다. 하지만 10분도 채 안되어서 트래픽이 조금 몰리니 cpu util이 증가해서 서버가 죽었다. 복잡한 작업을 하는 것이 아니라 무엇이 문제인지 파악하기가 힘들었다. 일단은 서비스가 정상 동작하는 것이 중요했기에 바로 인스턴스 수준을 업그레이드 했다. 인스턴스 수준 올리고 재부팅하는 5분이 5년처럼 느껴졌다. 아마도 free tier를 사용했어서 조금만 트레픽이 발생해도 낮은 하드웨어 스팩으로 인해 문제가 되는 것 같았다.
  
  명확히 원인을 파악하지 못하고 cpu util도 종종 올라가서 새벽 2~3시까지 모니터링하고 원인을 찾으려 했다. 유저는 계속 들어오고 에브리타임의 좋아요 수는 늘어났지만 내 근심과 걱정도 같이 늘었다. cpu util 증가로 인해 서버가 3번 정도 멈추었고 그 때마다 인스턴스를 재시작하는 방식으로 대응했다. 2분여만에 복구되었지만 그 사이에 서비스가 동작하지 않는 모습을 마주했을 유저를 생각하니 뭔가 마음이 아팠다.
  
  로직상의 문제가 있을 수 있다는 생각에 코드를 살펴보았지만 복잡한 로직은 없었기에 특별히 문제되지는 않을 것 같았다. 그래서 ec2 하드웨어 스팩상 램이 부족하거나 cpu성능이 낮은 문제가 클것이라고 생각했다. 부하를 조금이라도 덜기 위해 react와 node를 별도의 ec2로 분리하여 재배포하였고 CPU util이 다소 안정화된 것을 확인할 수 있었다.
  (후에 swap space를 늘려서 성능을 최적화시키는 방법을 확인할 수 있었는데 free tier 스팩이 아쉽긴 한가보다.)
  
  
• 배포가 다가 아니다, 유저들의 문의 및 해야할 일이 생각보다 꽤 많았다!
  맞닥뜨린 문의사항과 에러를 정리해보았다.
  
  • 유저가 백명 이상이 되었을 때 solapi 일일 제한을 풀어야 했다. 당장 50개 이상의 성적 업데이트가 발생하지는 않을 거라 생각했지만 언젠가 해야할 일이었다. solapi의 경우 sms api의 일일 50개 제한이 걸려있었고 사용내역이 있어야 제한 해제 문의가 가능한 구조였다.
  • 등록한 계정정보를 삭제해달라는 유저가 계셨다. 개인정보 이슈로 계정삭제를 문의주셨던 것이다. 계정 삭제 기능은 생각도 안했었는데 급히 만들어 삭제한 후 답변을 드렸다.
  • 전화번호를 잘못 입력하신 유저가 계셔서 변경요청이 들어왔다. firebase 특성상 문서ID를 하나씩 눌러야만 정보를 확인할 수 있었기에 기능을 따로 만들어 전화번호 수정 후 답변을 드렸다.
  • 서비스 원리를 여쭤보시는 분도 계셨다.
  • 유저의 각종 요청/문의 응대하랴, 서버 모니터링하랴 약간 정신이 없었다. 늦은 밤이여서 피곤했기에 멘탈을 잘 잡자고 스스로를 독려했다.
  • 예상치 못한 오류도 발생했다.
    DB에 저장된 계정정보 중 유효하지 않은 계정이 있어서 업데이트 확인+알림전송 루틴 실행 중 타임아웃이 발생했다. 에초에 유효한 계정만 등록이 되도록 로직을 구현했는데 어떻게 유효하지 않는 계정이 db에 저장되어 있는 것인지 의문이 있었다. 나중에 생각해보니 사용자가 계정을 등록한 후에 비밀번호 변경한 것이라고 생각이 되었다.
    
    앞으로 로직을 구현할 때는 유저의 사후적 계정정보 변경에 대응할 수 있는 등 프로그램이 데이터에 의존하지 않도록 해야겠다고 생각했다. 유저가 생각 밖의 행동을 할 수도 있다는 것을 인지하고 예외처리를 꼼꼼하게 해야겠다는 생각을 했다.
    

7. 학교 정보화개발팀 연락과 서비스 중단

다음날 오전에 학교 정보개발팀에서 유선연락이 왔다. 학교 규정에 위반되는 부분이 있어 서비스 중단을 요청을 받았다. 그렇게 서비스는 배포 14시간만에 중단되었다. 어떤 부분이 위반되는지 궁금했고 문의를 보냈다. 그리고 정보개발팀에서 친절하고 구체적인 답변을 받을 수 있었다. 크게보자면 1) 원칙적으로 크롤링 금지, 2) 개인정보 동의 절차 미비, 3) 보안문제(ssl 적용안됨), 4) 정보유출 시 책임소재 미비 였다.

 

개인정보를 취급하는 터라 관련 검토가 필요했는데 그러한 검토과정 없이 서비스를 배포했었다. 홈페이지와 홍보과정에서 개인정보를 성적알림 외 용도로 사용하지 않겠다고 밝혔고, 개인정보가 오용되거나 노출하는 것이 꺼림칙한 사람은 서비스를 에초에 사용하지 않을 것이라고 생각했기 때문이었다. 그럼에도 개인정보를 사용한다는 것을 심도있게 고려했어야 했는데 그러지 못하고 지나쳤던 것을 인지하고 반성하게 되었다.

 

그럼에도 보안을 강화하고 개인정보처리동의 절차를 삽입한 후에 학교 측의 동의가 있다면 서비스가다시 재개될 수 있을 거라고 생각했다. 한국법을 복수전공하고 있는터라 궁금증이 생겨 관련판례들과 정보를 찾아보았다. 사이트 계정이 개인정보에 해당하면 학생이 동의하는 경우 문제 되지않았지만 동시에 학교의 정보자산이라는 점에서 학교측과의 동의가 없다면 여전히 문제가 있었다. 하지만 책임소재와 관련된 부분을 제외한다면 내 생각으로는 다면 충분히 학교측에서 용인가능한 서비스라고 생각했다. 정보화개발팀에 정식으로 찾아가 보완사항 및 운영계획을 공유드리며 양해를 구하는 시간을 가져야겠다고 생각했다. 다만 당시 시간적, 정신적 여유가 없어 이러한 보완사항들은 다음학기에 진행하기로 했다.

 

홍보했던 채널들에 다시금 중단 및 개인정보 정보폐기를 내용으로하는 공지를 올리는게 마음이 아팠다.

 

8. 유저의 반응이라는 큰 위로. 200명의 유저.
14시간의 짧은 러닝타임이었지만 200여명의 유저가 유입되었고 커뮤니티의 반응을 통해 내가 느낀 문제의식에 대해서 학우들도 함께 공감하고 있다는 것을 다시금 확인할 수 있었다. 그리고 무엇보다 지인과 다른 학우들의 응원과 격려가 정말 감사했다.

 

어쩌면 성적알림주는 프로그램 만드는 것이 뭐 대단한 일인가 싶을 수 있다. 그렇지만 나의 개인적인 불편함으로부터 시작하여 학우들의 문제를 해결하고자 노력하고 유저의 반응을 확인하고 위로와 격려를 받으며 서비스에 대한 애정이 커졌다. 그만큼 서비스가 중단되었을 때의 아쉬움은 컸다. 친한 친구 한명이 지나가면서 했던 잊을 수 없는 한마디가 있다. “그날 밤에 알림 문자 2개나 와서 기분 좋았는데!” 그 한마디가 내가 학우들의 삶에 작게나마 기여했다고 인정받는 듯해서 큰 뿌듯함과 위로로 다가왔다.

서비스 중단 후 익명커뮤니티 반응

문자 알림 전송 내역 일부

후속 시도 (2024-1학기)

다음 3가지를 중점으로 보완내용을 공유드리면서 정보개발팀측에 동의를 구하는 메일을 드렸다.

1. 개인정보동의절차 삽입
2. ssl 보안설정
3. 성적의 등록 여부만 저장

하지만 지난 학기 서비스 중단요청과 동일한 이유로 동의를 받지는 못하였다. 역시 교내 사이트 계정정보가 학교 정보자산이라는 점과 외부로 유출되었을 때의 책임 문제가 가장 큰 이슈였다. 정보개발팀 선생님께서 교무팀 성적담당 선생님께 건의를 드려보면 어떨지 조언을 해주셨다. 아쉬운 마음을 뒤로한 채 교내 성적담당 선생님께 성적알림 기능의 도입을 정식으로 요청드리는 것으로 나와 학우들의 귀찮음을 극복하고자 했던 시간은 매듭을 짓게 되었다.

 

III. 소회

짧은 시간이었지만 내가 속한 학생 공동체의 문제를 풀기 위해 고민하고 몰입하는 경험을 할 수 있어서 감사했다. 문제해결을 목표로 서비스를 개발하는 것의 즐거움을 많이 느낀 것 같다. 더불어 성적확인 과정의 불편함을 제거한다는 목표가 명확하니 개발 및 운영과정에서 에러를 만나고 서버가 터져도 열정을 다하고 긍정적인 태도로 임할 수 있었다. 그리고 서비스가 사용되는 모습을 지속적으로 상상하면서 스스로 대뇌이고 생각하는 것이 목표를 현실화하는 원동력이라는 것도 깨달았다. 이것이 론 다번의 The Secret이라는 책의 핵심내용과 동일한데, 머리로만 알고 있던 것을 체득할 수 있었던 좋은 시간이 된 것 같다.

 

개인적으로 나는 개발자가 개발만하는 사람이 아니라 문제를 해결하는 사람이라고 생각한다. 그래서 나에게 코딩은 하나의 문제해결의 도구에 불과하다. 내가 해결하고자 하는 문제가 코딩을 요구하지 않는다면 다른 방법을 통해 문제를 해결해야 할 것이다. 앞으로의 삶도 이와 같이 문제해결 과정의 연속이라면 의미있는 삶이 되지 않을까 생각한다.