[프로젝트 회고] 비대면 통합 교육 플랫폼 Drawing Dream

프로젝트라고는 학부 때 해 본 HTML5, CSS, jQuery, Java로 한 학기 내내 만들었던 미약한 프로젝트와 둘이서 진행했던 간단한 CRUD 프로젝트가 전부였던 제가 처음으로 웹 서비스 프로젝트를 완주했습니다. 짝짝짝.

 

 

Github: (추후 등록)

Notion

 

1. 서비스 소개

모두에게 필요한 맞춤형 학습 도우미, Drawing Dream에서 등교부터 하교까지 함께 하세요!

---

기본 개발 스택

• 공통: Gitlab, Jira, Mattermost, Notion
• Front: HTML5, CSS, JavaScript, React, Redux
• Back: Java Zulu, Spring, AWS S3, Gradle
• 서버: AWS EC2
• 배포: Ubuntu, Docker, Jenkins

주요 기능

• 온라인 수업
• 채팅 
• 수업 알림
• 알림장
• 위젯 커스터마이징
• 다크모드

 

---

 

2. 나의 역할

이번 프로젝트에서는 팀장과 프론트엔드 개발을 맡았다. 팀장도 처음, 프론트 업무만 담당한 것도 처음이었기 때문에 걱정이 많았지만 잘 마무리 된 것 같아 기쁘다.

---

팀장

사실 어디 가서 팀장을 도맡아서 하는 성격이 절대 아니다... 나는 누가 시키는 걸 잘하고 주도적으로 뭔가를 찾아서 하는 능력이 조금 부족하다고 생각해 왔었는데 어쩌다 보니 팀장을 맡게 되어 부담감이 컸다. 개발 능력이 뛰어난 것도 아니고 기획부터 배포까지 하는 개발 프로세스를 경험해 본 적도 없다 보니 걱정이 되었다.

하지만 결론부터 말하자면 정말 좋은 경험이 되었다. 일단 팀원들과 트러블이 전혀 없었고, 다들 의견도 잘 내 주시고 잘 따라와 주셨기 때문에 팀장 역할도 잘해 낼 수 있었다고 생각한다. 일주일 스프린트 단위로 개발 일정을 짜고, 매일 아침 저녁으로 진행했던 스크럼 회의에도 진행이 서툴렀지만 다들 잘 도와주셨다!

다음 프로젝트에서는 어떻게든 미룰 거지만(힘들었기에...) 언젠가 이런 역할을 또 하게 될 때면 두려움은 없을 것 같다.

좋은 평가를 받아 본선 발표를 앞두고 있는데, 마지막까지 깔끔하게 완주했으면 한다.

 

 

Front-end

프론트엔드 개발자로 희망 직무를 결정하고 처음 진행한 프로젝트였다. 그동안은 프론트 백 구분하지 않고 기능별로 도움이 되는 대로 개발에 참여했었고, 자바스크립트보다는 자바가 익숙했기에 백 쪽을 더 도맡아서 했다.

하지만 리액트와 뷰를 접하면서 프론트에 대한 흥미가 생겼고 백 업무를 할 때보다 재미있었다. 따라서 프론트엔드 개발자로 희망 직무를 결정했다.

우리 서비스는 리액트를 사용했는데, 리액트로 혼자서 간단한 앱을 만들어 보긴 했으나 이렇게 규모가 큰 프로젝트는 처음이었기에 리덕스를 사용하는 부분이라든지 리렌더링을 처리한다든지 하는 부분에 있어서 어려움이 있었던 건 사실이다.

하지만 결과적으로 리액트 앱 흐름에 대해 익숙해졌고 기본적인 html, css 능력이나 Javascript 능력도 많이 향상된 것 같아서 뿌듯하다.

 

---

 

3. 좋았던 점

이번 프로젝트에서는 처음 접해 본 기술과 툴들이 많았다. 크게 잡아 보면 리덕스와 웹소켓, jira가 있다. 또한 데이터베이스 설계를 할 때 공통코드와 UUID를 접목했는데 이 부분은 아예 생소한 내용이었지만 적용한 후에 꽤 좋은 효과를 냈다.

---

WebSocket과 WebRTC

우리는 화상 회의 기능을 구축해야 하는 서비스였다. 비대면 교육 플랫폼이다보니 당연하게 온라인 수업 기능이 필요했고, webRTC 기술을 사용해야 했다. 팀원 중 아무도 webRTC를 접해 본 사람이 없었기 때문에 굉장히 애를 먹었다.

또한 webRTC를 구현하려면 어느정도 websocket에 대한 이해가 있어야 했는데, 그것조차 없었기에 먼저 채팅 기능을 구현하면서 websocket에 대한 공부를 하고자 했다.

우리는 stomp와 sockjs로 웹소켓을 사용했다. stomp를 사용하면 subscribe라는 개념으로 메시지를 받을 수 있다. 솔직히 말하면 react+spring으로 기술 스택을 선정했던 우리 프로젝트에 제일 적합한 프로토콜이라고 생각해서 채택했다. 기회가 되면 정확한 개념과 사용하면 좋은 이유 등을 다시 자세하게 정리해 봐야 할 것 같다.

 

백엔드를 담당하던 팀원 한분이 endpoint를 주시면 내가 프론트에서 연결하는 식의 작업을 했다. 연결 자체는 어렵지 않게 할 수 있었다. 실시간 통신이 되는 것 자체가 너무 신기해서 오오오오 하고 있을 때 채팅이라면 알림을 띄워야 한다는 문제에 직면했다. 우리가 처음으로 구현했던 채팅 기능은 카카오톡 같은 실시간 채팅 기능이라기보다는 게임 방처럼 생성된 방에 들어가야만 실시간으로 주고받을 수 있는 기능이었다. db에 채팅방 table을 만들어 생성되는 roomId로 구독을 진행했는데, 그건 알림 기능을 구현하기에는 잘못된 방법이었다.

고심 끝에 적용한 방법은 userId로 구독하는 거였다. 그리고 웹소켓 연결을 채팅방을 들어가서 하는 게 아닌, 최대한 바깥 레이아웃에서 진행하는 것이었다. (우리 같은 경우에는 채팅 컴포넌트를 제일 바깥으로 빼놔서 그곳에서 연결을 했다) 그리고 채팅방에 입장할 때마다 상대 userId로 한 번 더 구독을 진행한다.

이렇게 되면 상대는 내 userId로 메시지를 보내게 될 것이고, 전역으로 나와 있기 때문에 알림도 잘 뜨게 되었다.

이걸 구현하기까지 너무 많은 시간이 걸렸고, 이게 정답인지도 아직 모르겠지만..... 첫 프로젝트였기에 만족하고 넘어갔다.

 

채팅을 구현하고 나서 화상 수업을 구현해야 했다. 백엔드를 담당했던 팀원 분이 마찬가지로 메소드를 만들고 쿠렌토 미디어 서버를 docker image로 주시고, 내가 프론트에서 wss 연결을 진행하는 식이었다.

처음에 연결됐을 때 마찬가지로 너무 신기해서 소리질렀다. 내가 만든 프로젝트에 화면까지 뜨는 게 너무 신기했다. 하지만 샘플 코드를 그대로 들고왔다 보니 정확한 이해도가 떨어졌기에 그 이후 기능을 구현하는 데에 너무 애를 썼다.

먼저 비디오와 오디오 컨트롤이 가능해야 했는데, 이걸 나는 프론트에서 서버로 메시지를 보내면 그 메시지를 받고 비디오와 오디오를 컨트롤 해 주는 메시지를 다시 보내 줘야 한다고 생각했다. 그래서 백 팀원분을 괴롭혔는데... 그게 아니었다. 내가 peer에 대한 개념이 부족했기 때문에 어떻게 통신하는지 확신이 없었다.

아마 팀원분이 알려 주지 않았다면 나는 화면 공유 기능도 프론트에서 처리하는 게 아니라 백을 거쳐야 한다고 생각하고 또 괴롭혔을 거다. 그렇지만 화면 공유 기능 또한 peer에 미디어 스트림을 처리할 때 화면 공유 화면을 만들어서 넣어 놨기 때문에 문제 없이 잘 동작했다.

 

이렇게만 보면 순탄한 흐름이었지만... 제일 심각한 문제는 배포 후에 마주하게 되었다. 이는 뒤의 아쉬운 점에서 다시 이야기하겠다.

 

 

Redux

이전에 Vue를 공부할 때 Vuex라는 전역 상태 관리 라이브러리를 접해 보고 신문물이라고 생각했던 기억이 있다. React에도 당연히 그런 게 있을 텐데... 하면서 이번 프로젝트에 들어왔고 마침 Redux를 사용해야 하는 부분을 발견했다.

 

 

Git, Jira

Git은 혼자 공부할 때나 앞선 프로젝트 때 사용했지만 Git Flow 전략이나 컨벤션 같은 것들도 모른 채 그저 코드 백업용(?)으로 사용했다. 그래서 충돌도 정말 많이 마주했고, 지웠다 다시 클론받고.... 이런 적이 정말 많았다. 나한테 git은 어렵기만 한 존재였다.

하지만 이번에 git flow 전략과 컨벤션, 그리고 충돌을 해결하는 방법이나 mr 날리는 법 등 git에 대한 전반적인 개념과 흐름을 잡고 갈 수 있었다. 물론 앞으로 더욱 많은 연습이 필요할 것 같다. 

 

Jira는 아예 처음 접해 본 툴이었다. 그렇지만 왜 필요한지, 어떻게 써야 하는지 잘 이해하고 적절히 사용했다고 생각한다.

우리 팀은 스프린트마다 번다운 차트가 우햐향으로 예쁘게 나왔기에 코치님도 우리 팀의 큰 장점으로 삼고 가면 좋다고 하셨다. 실제로 현업에서도 쓰이는 툴이라고 하니 이번에 경험해 본 게 아주 큰 도움이 될 것 같다.

 

 

공통 코드 & UUID 인공키

DB 설계는 프로젝트 때마다 항상 했었기에 어느 정도 익숙한 부분이라고 생각했다. 하지만 이번에 공통 코드를 도입하고 테이블마다 pk를 인공키로 사용하라는 조언은 처음 들어 보았다.

우리 프로젝트에서는 학생, 선생님 같은 신분이나 전체 공지, 조례, 종례 같은 공지 카테고리 등을 공통 코드로 관리했다. 백에서 response를 넘겨 줄 때도 코드로 주고, 프론트에서 request를 줄 때도 코드로 주는 식으로 이용했다. 우리 팀은 데이터의 변화가 그렇게 많지 않았지만 이러한 방식은 데이터 자체에 변화가 있다거나 데이터들의 분류가 필요할 때 유용하게 쓰일 수 있다. 처음에는 공통 코드를 짜는 것도 너무 어려웠고 개념도 잘 잡히지 않았지만 쓰다 보니 이용하는 이유를 이해했고 가면 갈수록 익숙해져서 좋은 시도였다고 생각한다.

그동안은 게시글마다 pk를 auto increment로 사용하고는 했는데, 사실 그렇게 하면 데이터의 접근이 쉬워지기 때문에 테이블마다 인공키로 pk를 사용하는 게 좋다는 조언을 들었다. 그래서 우리 프로젝트는 테이블마다 uuid로 pk값을 설정해 데이터의 보안에 신경 썼다.

또한 테이블 컬럼의 삭제가 일어날 때마다 진짜로 delete를 사용하는 일은 거의 없고, del_yn 같은 필드를 두어서 이 값의 변경을 통해 삭제 여부를 조회한다고 했던 팁도 추후에 유용하게 쓰일 수 있겠다.

 

---

 

4. 아쉬운 점

팀원들과 자기주도적으로 프로젝트를 진행하면 가장 큰 아쉬움이 지금 이렇게 하는 게 맞나 하는 의문이 든다는 점인 것 같다. 후에 나오는 아쉬운 점들은 이게 왜 안 된 건지 확신이 없어서 아쉬웠기 때문에...... 이렇게 적어 두면 나중에 알게 되는 날이 왔으면 좋겠다.

---

​Javascript, React 기본 지식

사실 어찌저찌 완성은 했지만 이 코드가 정말 잘 짠 코드인지 내가 가는 이 길이 맞는지...? 하는 고민이 계속 들었다. 개발은 실제로 구현해 보며 많이 배운다고 생각하긴 하지만 개념적인 부분이 많이 확립되지 않은 채 기능만 구현하고 있는 것 같다는 생각을 받아서 기본적인 자바스크립트 문법과 리액트 앱 생태계(?)를 다시금 잘 정리하고 다음 프로젝트에 들어가야 할 것 같다.

 

 

WebSocket 연결 불안정

채팅 기능을 구현하기 위해 webSocket을 사용했다. 이게 어느 정도까지는 전송이 매끄럽게 아주 잘되는데, 계속 여러 번 보내다 보면 혼자서 터지는 느낌으로 갑자기 연결이 끊기곤 했다. 그런 현상이 왜 나타나는지 파악하지 못해 아쉬운 부분이다.

 

 

수업 알림

수업 알림을 핵심 기능으로 잡고 꼭 구현해 보고 싶었으나 도저히 어떻게 구현해야 할지 막막한 기능 중 하나였다. 그래서 프로젝트 막바지까지 미루다가 제일 나중에 구현하게 된 기능이다. 실질적으로 알림 기능을 구현하려면 채팅처럼 webSocket을 연결하거나, push api를 사용하는 방법이 있었다. 전자는 이미 채팅과 화상 수업 기능으로 webSocket을 너무 많이 연결해 두어서 또 endpoint를 구축할 엄두가 나지 않았고, 후자 또한 새로운 개념을 학습하기에 너무 촉박한 시간이었다. 

결국 우리는 수업이 생성되었는지를 판단하는 api를 2초마다 요청하는 방법을 선택했다. 그 정도는 지금 서비스를 보여 주기에 서버에 무리가 그렇게 가지 않는다고 판단했다. 

일단 그렇게 알림을 띄우는 데에는 성공했지만 시간에 쫓겨 너무 억지스러운 방법으로 구현한 것 같아서 계속 아쉬움이 남았다. 다음에 이런 알림 기능을 또 구현해야 될 때는 애초부터 웹소켓 연결 기반을 쌓아두거나 push api를 공부해서 적용해 보고 싶다는 생각이 들었다.

 

 

webRTC

앞서 좋았던 점에서 말했던 배포 후의 재난이다. 쿠렌토 샘플 코드와 험난한 구글링을 통해 비디오 오디오 컨트롤과 화면 공유, 새로운 참가자 화면 배치까지 로컬에서 모든 테스트를 마치고 서버에 올렸을 때였다.

내 화면을 제외한 다른 참가자의 화면이 나오지 않았다...

다시 생각하니까 또 슬픈 것 같다. 로컬에서는 잘 되는데 서버에서만 안 되니 젠킨스로 자동 배포를 해 두었지만 올라가는 데 1분 30초에서 3분 정도 걸렸기 때문에 바로바로 오류를 잡을 수가 없었다. 또한 에러 메시지까지 전혀 나오지 않았다. 다른 유저의 참여와 퇴장이 실시간으로 잘 이루어지는 게 확인이 되는데도 미디어스트림 주고받는 게 안 되는 거였다.

결국 어쩔 수 없이 초기에 배포 테스트를 진행하며 다른 참가자의 화면이 잘 나왔을 때 (비디오 오디오 컨트롤과 화면 공유 구현은 안 되었을 때)의 소스코드로 돌려서 하나하나 다시 쌓으며 어디가 문제인지 찾는 과정을 거쳤다. 

초기의 소스코드 -> 완성된 소스코드 -> 초기의 소스코드로 하나하나 쌓고 하나하나 제거하는 왔다갔다 하는 과정을 두어 번 거친 것 같았다. 새벽 12시부터 시작했는데 새벽 5시에서나 다 끝낼 수 있었다.

아직도 정확히 오류가 발생되는 지점은 알지 못한다. 에러 메시지가 안 뜨기 때문에. 

일단 쿠렌토 미디어 서버 자체에서 테스트를 열몇 시간씩 하다 보면 혼자 터져 버리는 것 같은 현상이 있곤 했는데, 그게 첫 번째 문제였던 것 같다. 서버를 다시 껐다 켜니 안 되던 버전에서도 상대 참가자가 잘 보이곤 했다.

그 상태에서 계속 쌓다가 안 되는 걸 발견한 지점이 오디오 비디오 컨트롤을 현재 상태를 파악해서 할 수 있도록 변수를 뒀던 부분이었다. 그 코드가 어떤 문제가 있어서 안 되는지 정확히 알고 싶은 아쉬움도 있다.

 

---

5. 정리

새롭게 접하는 기술이 많았는데 나의 유일한 강점인 눈치로 이해해서 적용하기를 적절하게 사용해서 짧은 시간 안에 결과물을 낼 수 있었다. 하지만 이 강점의 단점인 개념적으로 완벽히 학습하기가 상대적으로 부족했기 때문에 다음 프로젝트를 진행하며 자바스크립트나 리액트의 기본 문법을 제대로 짚고 넘어가고 싶다. 또한 타입스크립트도 공부해 보고 싶다.

이렇게 볼륨이 큰 프로젝트는 처음이었고 그만큼 따라가기 벅차기도 했지만 돌이켜보니 정말 좋은 경험이었습니다. 또한 함께 한 팀원 분들 너무 감사드립니다. 덕분에 정말 좋은 경험할 수 있었습니다! 컨설턴트, 코치님 다 너무 감사합니다.

앞으로의 인생에 좋은 밑거름이 되길 🥰

 

 

 

 

다른 팀원들의 회고 포스트

창현님: https://velog.io/@palacer/SSAFY-6%EA%B8%B0-%EA%B3%B5%ED%86%B5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%B5%9C%EC%9A%B0%EC%88%98%EC%83%81-%ED%9A%8C%EA%B3%A0%EB%A1%9D

SSAFY 6기 공통 프로젝트 회고록

준범님: https://velog.io/@runkey/프로젝트-회고-SSAFY-2학기-공통-프로젝트-비대면-통합-교육-플랫폼-Drawing-Dream

[프로젝트 회고] SSAFY 2학기 공통 프로젝트 - 비대면 통합 교육 플랫폼 Drawing Dream

진명님: https://jingmong.tistory.com/63

DRAWING DREAM 프로젝트 회고

다예님: https://devdange.tistory.com/entry/%ED%9A%8C%EA%B3%A0-SSAFY-2%ED%95%99%EA%B8%B0-%EA%B3%B5%ED%86%B5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EB%A5%BC-%EB%A7%88%EC%B9%98%EB%A9%B0

[회고] SSAFY 2학기 공통 프로젝트를 마치며...