졸업 작품이 끝나고... 회고 1부

"계획은 꽤 그럴싸하다. 실천이 안 될 뿐..."

 

4월 초부터 본격적으로 시작한 캡스톤 디자인 과목. 그냥 졸업작품의 프로토타입이라고 보면 된다.

1학기(4월 초 ~ 6월 중순)에는 캡스톤 디자인이라는 과목으로 졸업작품의 프로토타입을 만들고 여름 방학 + 2학기(11월 초)까지 졸업작품을 완성하면 된다.

 

학과가 바뀌고 교육 과정이 바뀌면서 우리가 그나마 해봤었던 것은 DJango, DB(Oracle), OpenCV 수박 겉핥기 정도의 지식수준이었던 것 같다.

 

너무 뻔한 주제, 너무 쉽게 구현이 되는 것을 우리도 원치 않았고 교수님께서도 그런 주제가 나왔을 때 거부를 하셨기에 고민을 거듭해 실시간 웹 퀴즈 게임을 만들고자 했었다.

 

실시간을 처리할 수 있는 그런 코딩? 과목? 짜보 지도 배우지도 않았기 때문에 막연히 구글에서 찾아보면 될 거라고 생각했었다. 

 

프로젝트 설계부터 완성까지 제대로 해보는 것은 처음이었기 때문에 모든 것이 삐걱거렸다.

 

"막연하게 하다 보면 어떻게든 되겠지?"

 

팀원들의 수준이 비슷했었다면 진행하기도 수월했겠지만 나포함 팀원 1명은 비슷했지만 다른 한 명은 그렇지 않았다.

팀을 친구들끼리 짠 거다 보니 우리가 안고 가야 했다.

 

협업을 위해서 개발자들은 git을 이용한다. 나도 협업을 제대로 해본 적은 없었어서 git은 commit, push, clone 그 정도만 알고 있었고 팀원들은 그조차도 몰랐다. 내가 알고 있는 git의 간단한 commit, push, clone을 팀원들에게 알려주었다.

깃 저장소는 Github을 사용했다. 

 

IDE 도 갈렸다. Pycharm 이냐 VS code 나.. 처음에는 VS code로 가기로 했는데 git 명령어들을 활용을 잘 못하다 보니 Pycharm으로 바꿔서 진행했다. Pycharm 은 git을 쓰기가 참 편하다.

 

가상 환경에서도 막혔다. 우리가 그나마 쓸 줄 알았던 가상 환경이 Venv 나 Anaconda 였고 학교 과목에서도 Anaconda를 주로 많이 사용하다 보니 Anaconda로 결정했지만 터미널에서 가상 환경을 활성화하는 데에 있어서 수많은 에러가 났었다. 

 

개발 환경 구축만 1달 반? 그쯤 걸렸다. 

 

회의를 일주일에 한 번씩만 한 게 문제였던 것 같다. 일주일 중 수요일 한 번만 만나서 5~6시간을 뭘 할지 고민하고 그것에 대해서 해보다가 결과가 조금이라도 나오면 다음 주 수요일이 되기 전까지 완성을 해오는 이런 방식으로 진행을 했었다. 그 결과가 프로젝트의 지연이 아니었을까... 

 

"남은 시간은 1달 아니 3주... DB 설계도 못했는데 코드는 언제 짜고 UI 적용하고 서버 구축해서 프로토타입 어떻게 띄우지?"

 

이때부터 일주일에 3번은 회의를 했던 것 같다. 당장 급한 불부터 끄자고 UI 적용과 서버 구축은 제외하고 DB 설계랑 코드만 짜서 로컬로 실행하자고... 실시간 처리는 시간이 남으면... 그때 하기로...

 

DB 설계... 제약 조건을 걸고 난 후 임의적으로 값을 넣어 테스트할 때 테이블마다 외래 키로 묶여 있다 보니 값이 넣어지지가 않아 제약 조건 자체를 없애 버렸다. 

 

app 구조 및 코드 설계...  각 앱을 생성했지만 앱들의 관계는 독립적인 것이 아닌 종속적이었다. 진짜 난잡했다. A app에서 처리해야 할 코드가 B app에 있고 B app에 있어야 할 코드가 A app에 있었다. 

 

실시간 웹 퀴즈 게임이었기에 채팅은 실시간으로 되어야 할 것 같아 현업에 있는 친구에게 조언을 받아 ajax로 채팅은 구현했지만 일정 주기로 계속 호출을 해주는 것이었기 때문에 졸업작품 진행할 때 방법을 바꾸는 것으로 진행했다.

 

당연히 프로토타입이라 불릴 수 있을만한 결과물은 아니었다. 간단하게 설명하자면

 

1. 로그인을 하면 방목록이 보인다.
2. 방목록에서 해당 방을 클릭하면 방 입장이 된다.
3. 로컬에서 돌리기 때문에 또 다른 유저를 보고 싶다면 시크릿 창이나 다른 브라우저를 이용해서 들어와야 한다. 
4. 유저들은 채팅을 할 수 있고 다른 유저들의 채팅 내용을 볼 수 있다.

5. 게임은 실시간 처리가 안되어있으므로 싱글 플레이로 진행한다.(개발자가 임의적으로 넣어 놓은 이미지를 토대로 플레이)

 

싱글 플레이 퀴즈 게임이라도 유저가 직접 이미지를 넣고 OpenCV로 이미지가 변형이 되어 유저 자기 자신이 넣은 이미지로 플레이가 가능해야 했었는데 우리가 만든 것은 장고 admin. 즉, 관리자 페이지에서 개발자가 임의적으로 이미지를 넣어 놓고 유저가 정답을 맞히는 방식. 참 이상한 플레이 방식이었다. 

 

"깃 브랜치는 어떻게 관리? 와 이거를 이렇게?"

 

master 브랜치가 있고 feature/X, feature/Y, feature/Z 이런 식으로 각 개개인의 브랜치를 하나 생성했다. 개발할 기능이나 에러를 고쳐야 되면 본인 브랜치에서 commit, push를 진행했다.

merge 같은 경우 나만 할 줄 알았기에 내가 팀원들의 브랜치에 들어가서 내 브랜치에 merge를 하고 그 브랜치에서 master로 merge 하는 방식으로 했다. conflict 가 발생할 것 같다면 한 명이 디스코드로 화면 공유를 하며 다른 한 명이 그 화면을 보면서 코드를 같이 구현했다. 

 

"대망의 발표날..."

 

교수님과 다른 팀들에게 발표하는 형식이었기 때문에 오류 나는 부분은 보여주지 않고 잘 된 부분들만 보여주었다. 공격적인 질문이 들어오긴 했으나 팀장으로 있는 팀원이 해당 부분의 문제점이 무엇이고 그런 것들을 해결할 수 있는 방안들에 대해서 발표를 잘했기에 대처를 할 수 있었고 좋은 점수를 받을 수 있었다.

 

실행 방법에 대해서는 아래의 깃헙 레포지토리에서 볼 수 있다.

GitHub - A-WOS/Capstone-Design: 졸업작품 - 퀴즈 게임

하지만 이걸로 이어서 졸업작품을 할 생각에 걱정이 많았다.

 

다들 서버를 다뤄본 경험이 없었기 때문에 서버 구축에도 고민이 많았다.

학교 과목에서 AWS EC2 프리티어를 사용해보긴 했었지만 서버가 어떻게 굴러가는지에 대해 모르고 있었고 멋모르고 만졌다가 과금도 당해본 이력이 있었기 때문이다.

AWS에서 홈(개인) 서버로 구축

 

Django에서 실시간 처리를 할 수 있는 소켓에 대한 부분이 channels라는 것이 있었기에 방학 동안 개개인이 channels에 대해 공부 및 서버에 대한 지식을 쌓기로 하였다. Django에 대한 기본지식이 부족한 부분이 있으면 그것도 포함해서 말이다.