330 예약 시스템 개발 후기

  330 예약 시스템을 개발하게 된 것은 우연한 기회에 시작을 했다. 같은 랩실에 있는 선배와 뜻을 같이 해서 코딩 스터디를 만들었다. 스터디는 학교에서 알려주지 않는 혹은 아직 배워보지 못한 언어, 기술을 사용해서 하나의 완성품을 만들면서 겨울 방학을 보내자는 목표를 가진 스터디였다. 꽤 많은 사람들이 모였고, 랜덤하게 팀을 꾸렸고 나를 포함해 3명의 팀원이 생겼다. 나는 거의 완성되가는 게임 추천 시스템의 배포를 목표로 하려다, 같은 팀원이 배우는게 너무 없을 것 같았고, 또 모종의 이유로 다른 주제를 선정해야 했다. 그러던 중 330 예약 시스템이 게시판 형식으로 운영되고 있어 이용 할 때 마다 너무 불편한 것이 생각났고, 330 예약 시스템을 만들기했다.

  330 예약 시스템을 만들기 위해 사용 기술들을 정해야 했다. 팀원들은 처음 웹을 하는 친구들이었다. 그래서 프래임워크를 사용하면 어렵지 않을까라는 생각을 했으나, '그래도 성적이 좋은 친구들이니까, 잘하겠지?'라는 안일한 생각을 했다. 하지만 처음 웹을 하는 친구들과 같이 하는데 나도 처음하는 프래임워크를 쓰게 되면 너무 헤맬 것 같았다. 그래서 React와 Vue를 배제하고 이전부터 사용하고 있던 Angular를 사용하기로 했다. 또한 백앤드도 MongoDB를 제대로 써본적이 없었기 때문에 Mysql과 Nodejs를 이용해서 구성하기로 했다.

  나는 프론트앤드와 백앤드를 넘나들며 개발하였고, 한 친구는 프론트앤드, 다른 한 친구는 백앤드를 맡겼다. 현재까지 프론트앤드 개발 시에 혼자 했기 때문에 협업은 처음이었다. 그래서 이번 기회에 협업하는 방법이나 프로세스를 만들어 두는 것도 좋을 것 같다는 생각을 했다.

  그래서 나는 Github를 사용하기로 했고, 거기에 Github Flow와 Git Flow에 대한 공부를 진행하고 팀원들에게 자세히 설명을 해서 Github를 적극적으로 사용할 수 있도록 했다. (이에 대한 내용은 나중에 정리해서 포스팅 하겠다.) 그리고 나서 나는 처음 Git을 접하는 팀원들에게 조금이라도 부담을 덜 주기 위해 그나마 쉬운 Github Flow를 선택해야 했다. 처음에는 커밋하는 방법 브랜치 내는 방법도 모르는 친구들이었는데 한 두번 알려주니 곧잘 따라했다.

  그 전부터 나는 배포 자동화에 관심이 많이 있었다. 귀찮은 걸 싫어하고 반복적인 것을 싫어하는 성격 탓에 그런 것이 있으면 개선하고 싶어했다. 그래서 찾아본 것이 Travis CI 였다. 우리 팀은 내 AWS에 개발 환경을 구축 하였고 Travis CI를 쓰면 커밋을 하게 되면 자동으로 AWS에 배포할 수 있게끔 만들고 싶었다. 하지만, Travis CI를 처음 써봤고, 예제를 봐도 잘 되지 않았기 때문에 AWS에 배포하는 것이 너무 어려웠다. AWS의 Bucket등을 이용해서 하는 방법도 있었는데 프리티어를 사용하는 내 계정으로 두어번 하니 용량이 끝이 나더라. 그래서 어쩔 수 없이 손수 빌드 하는 것으로 할 수 밖에 없었다. 나중에 기회가 되면 다시 Travis CI를 이용해서 자동 배포를 해보고 싶다.

  그 후 개발에 본격적으로 돌입했다. 처음에는 학생회장과 인터뷰를 했고, 그 다음에는 학과 게시판에 기존 330 예약 시스템의 불만과 새로운 330 예약 시스템에게 바라는 점을 댓글로 달아달라고 했다. 이후 모인 요구사항을 가지고 팀 회의에서 사용하며 개발 할 수 있는 부분과 없는 부분으로 나눴고, 한달의 개발 기간 중에 각각 개발 언어에 대한 공부를 2주 진행하고 나머지 2주 동안 개발을 했어야 했기때문에 최소한의 기능을 가진 시스템을 만들기로 하였다.

  사용자 페이지와 관리자 페이지를 따로 만들고, 로그인 기능, 사용자는 예약, 예약 취소, 사용 종료, 신고 기능을 만들었고, 관리자는 섹션 관리, 관리자 관리, 신고 관리, 제제 관리, 예약을 하고 자리를 비우는 사람들 때문에 예약 취소 기능을 만들었다.

  개발 당시에는 학과의 공식적인 개발이 아니여서 학과의 서버라던지, 데이터베이스같은 자원을 서포트 받을 수 없었다. 그래서 로그인 기능을 만들어야 하는데 어떻게 하지 고민하다가 학교의 로그인 시스템을 이용하기로 했다. 그렇게 되면 굳이 회원가입 없이 학교 로그인 아이디와 비밀번호를 이용해 로그인 할 수 있고, 같은 시스템에 있다는 연속성을 보여 줄 수도 있었다. 그래서 우리는 굳이 회원정보를 수집하지 않고 로그인을 구현 할 수 있었다.

  또 예약 기능을 할 때 가장 신경 썼던 것이 중복예약을 막는 것이었다. 이전 시스템에서는 게시판 형식으로 되어있어 말 그대로 알아서 예약시간이 겹치지 않게 하는 것이었다. 그것 때문에 예약을 하고 확인을 한번 더 해야하는 불편함이 있었고, 그것을 이용할 때마다 내가 이걸 다시 만들어야겠다는 생각을 했던 것 같다. 그래서 이번 시스템에서는 다음과 같이 중복 예약을 방지했다. 프론트앤드에서는 이미 예약된 시간을 표시하고 클릭할 수 없게 만들어서 예약을 할 수 없게 만들었고, 백앤드에서는 이미 예약된 시간이 포함된 예약이 들어오게 되면 Reject 시키는 것으로 만들었다.

  또 이전 시스템에서는 게시판 형식이기 때문에 (애초에 게시판으로 예약 시스템을 만든게 잘못되었던 것 같다.) 필수 입력값이 너무나 많아서 예약 할 때마다 필수 입력값을 입력하지 않았다는 alert 창을 몇번이고 봤다. 하지만 이번 시스템에서는 단위 시간을 1시간으로 두고 시작시간과 마지막 시간만 클릭해서 예약 할 수 있도록 했다. 이전에는 분단위였는데 사실상 분단위로 예약 하는 사람도 없었기 때문에 그런 판단을 했다.

  신고 기능은 이전에는 없던 기능이다. 한번씩 학과 게시판에 330 실습실을 너무 더럽게 쓴다는 글이 올라왔는데 그 글이 올라올 때마다 쓰레기를 버리고 간 사람에게는 경각심을 주었겠지만, 그 글을 보는 나로써는 기분이 썩 좋지는 않았다. 또한, 학과 게시판이 익명인데 익명이 아니게 만드는 몇몇 코난들 때문에 신고자 역시 별로 좋지는 않았을 것이다. 때문에 이번 시스템에서 신고 기능에 신경을 쓴 부분은 학과 게시판에 이런 글이 올라오지 않게하고, 코난들에게 최대한 증거를 숨기자 라는 것을 목표로 했다. 처음에는 신고자의 학번을 저장하지 않도록 하고 싶었지만, 악의적으로 신고를 작성해서 선량한 피해자를 발생하는 경우가 있을 것 같다는 의견이 있어 데이터베이스에 저장은 하되 데이터 베이스를 열지 않으면 볼 수 없게 했다.

  이번 시스템은 배포 후에 버그가 아니면 최대한 코드 수정이 없도록 하는 것을 목표로 했다. 아무래도 회사에 다니면서 그것을 유지보수 할 수 있는 시간이 많지 않을 것 같았고, 내년에 복학을 하더라도 4학년이기 때문에 그 곳에 쏟을 시간이 별로 없다고 판단했기 때문에 최대한 변경하지 않고 지속 가능한 웹 서비스를 만들도록 노력했다. 그래서 관리자 페이지도 몇년을 문제 없이 쓸 수 있도록 관리자 관리를 넣은 것이고, 섹션 관리도 혹시나 발생할 섹션 이동을 예상해서 넣어둔 것이다.

  개발이 완료되고 학과 서버를 관리하고 있는 대학원생 친구에게 빌드 파일을 넘겼다. 사실 내가 서버에 배포해야하나라는 생각에 굳이 AWS에 올려서 배포 연습도 하고 했는데 그러지 않게 되었다. 배포에 대해서 대학원생 친구랑 이야기하는데 뭔가 내가 원하는 걸 그 친구도 알고 있고 그 친구가 원하는 걸 나도 알고 있는 느낌을 받았다. 역시 해본 사람은 다르구나 라는게 느껴졌다. 그렇게 2017년 8월 30일 우리가 만든 330 예약 시스템이 공식적으로 학과 게시판에 공지를 통해 알려졌다. 사실 폭발적인 반응을 기대하지 않은 것은 아니지만, 생각보다 조용히 그 날이 지나갔다. 흔한 버그도 하나 없었다. 잘 동작하는 걸 보니 꽤 자신감이 생긴 것 같다. 나도 할 수 있구나 라는 생각을 하게 되었다.

  이번 개발을 하면서 협업의 장점을 많이 느꼈다. 시스템의 총괄적인 설계는 내가 담당하고 R&R을 했지만, 그것을 실제 개발하면서 미스난 곳을 팀원들이 꼼꼼히 찾아주었다. 그 덕에 내가 자잘한 부분에 큰 신경을 쓰지 않아도 무리없이 시스템이 만들어져갔다. 한번씩 '조금이라도 웹을 할 줄 아는 친구들이었으면 더 빨리 더 큰 시스템을 만들 수 있었을텐데' 라는 생각을 했지만, 부족한 실력이지만 열심히 하려하고 하나라도 더 배우고 싶어하는 친구들이었어서 나도 거기에 힘입어 하나라도 더 알려주고 싶었고, 더 열심히 할 수 있었던 것 같다. 그것이 협업의 장점이 아닐까 싶다.

  이번 스터디의 목적은 학교에서 배우지 않는 혹은 내가 처음 써보는 것을 써보는 것이 목적인 스터디였다. 사실 나는 Angular도 써봤고, Nodejs도 써봤기 때문에 별로 배울 것이 없는 스터디가 될 수도 있다는 생각을 했다. 하지만 생각보다 얻은 것이 많다. 협업을 해보기도 했고, 그것 때문에 Git Flow, Github Flow도 알게 되었고, 또 이것 때문에 Travis CI의 맛도 봤고, 제일 중요한 내가 할 수 있다는 자신감을 얻었다. 다음에 스터디가 있으면 하겠냐는 질문에 한 친구는 너무 힘들어서 하지 않겠다는 친구도 있었고, 재밌어서 하겠다는 친구도 있었다. 나는 또 할 것 같다.