코테이토 홈페이지 프로젝트 V1 회고록

2월 23일 코테이토 데모데이가 끝나고 공식적으로는 프로젝트 V1이 끝났다.

2023년 10월부터 2024년 2월까지 5개월동안 진행한 프로젝트에 대한 후기를 남겨보도록 하겠다.

 

왜 2월에 끝났는데 지금 작성하냐...

공식적으로는 2월 마감으로 마감까지는 완료했지만 V1으로 남겨두기에는 스스로 너무 부족한 부분이 많이 보였다.

리펙토링할 것도 눈에 보이는 것만 산더미였고 미완으로 남겨둘 수가 없어서 추가로 리펙토링을 4월까지 진행했다.

 

코테이토 프로젝트란?

코테이토는 내가 2023년 3월부터 활동했던 동아리다. 일년동안 동아리 활동을 하면서 다양한 사람들을 만나면서 많이 배우고 생각하는 방식도 알게 됐다. 그렇다 보니 지금까지 배운 지식과 경험을 바탕으로 운영을 할 수 있는 프로젝트를 만들고 싶었다.

그렇게 뜻이 맞는 인원들(모이고 보니까 대부분은 운영진이더라... 나 빼고)끼리 프로젝트를 진행했다.

 

CS 문제풀이 웹

코테이토 활동에는 'CS 문제풀이' 가 있다. 교육팀에서 매주 CS 주제를 선정해 발표하고 문제를 풀게 된다.

문제는 ppt로 보여주고 카톡방에 답을 적어 선착순으로 가장 먼저 맞춘 사람이 득점을 하는 방식이다. 이런 방식으로 10문제를 푼 이후 가장 많은 득점자를 선정하는 방식이다.

 

- 카톡방에서 답을 작성하다 보니까 자신의 정답이 모두에게 공개된다. 따라서 참여자들이 답이 확실하지 않은 경우에는 답을 올리지 않는 문제다.

- 또한 초반에 한 사람이 몰아서 득점을 할 경우 다른 인원들은 참여 의지가 떨어져 후반부로 갈수록 참여율이 떨어진다.

 

따라서 우리는 답안이 공개되지 않으면서 문제풀이가 모두 끝나고 우승자만 나오게 웹 페이지를 만들자고 하면서 프로젝트가 시작됐다.

 

이를 더불어서 CS 문제풀이 기능 등 많은 기능이 추가된 코테이토 만의 홈페이지를 만들게 되는 방향으로 흘러갔다.

처음 동아리에 들어갔을 때 홈페이지가 존재하지 않고 대학생 커뮤니티인 에브리타임에만 동아리에 대한 정보를 확인 할 수 있었다. 따라서 어떤 동아리인지 알기 어려웠다. 이런 문제점을 해결하고자 동아리 홍보 홈페이지로 발전됐다. 

 

프로젝트 인원 구성

V1 때는 기획자 1명, 디자이너 2명, 개발자 6명(BE 3명, FE 3명)으로 진행하였다. 위에 말했다시피 많은 인원들이 운영진이나 이에 준하는 활동을 하는 멤버들이 많았기 때문에 다들 애정을 가지고 프로젝트에 참여하였다. 매주 대면으로 회의를 진행하였는데 다들 많은 의견을 교환하고 커뮤니케이션이 잘 된 거 같아 만족스러운 프로젝트였다.

 

기술 스택

Spring boot(java)

보안: spring security, jwt

배포 : aws ec2, aws rds, S3

선착순:  redis

DB: MYSQL

 

redis

문제 풀이에는 선착순이 필수이기 때문에 어떤 방식으로 진행할 지 고민이었다. Spring 자체는 멀티 쓰레드이기 때문에 먼저 서버에 들어왔다고 먼저 DB에 저장된다는 보장이 없기 때문이다.

이 때문에 싱글 쓰레드인 redis를 사용해 서버에 들어오자 마자 티켓 번호를 받는 방식으로 진행하였다.

 

 

아키텍처, 기능

이 게시물에 적으려 했으나 다 적으면 이 글을 읽는데 시간이 너무 길어 질것 같아 따로 게시물로 작성하겠슴다..

 

 

잘한 점(발전한 점)

1. 관리 용이한 깃

 

- 브랜치 관리

기존에는 도메인에 따라 브랜치를 나누고 main에 합치고 기존 브랜치를 재사용했다.

브랜치에서 pull main을 통해 재사용하니 한 브랜치에 commit이 너무 많이 코드를 추적하기 어려웠다.

 

따라서 개발이 시작된지 얼마 지나지 않아 도메인이 아닌 기능을 브랜치 명으로 사용하고 PR을 진행한 후 해당 브랜치는 폐기하는 방식을 적용했다.

 

- PR 메세지의 중요성

지금까지 진행한 프로젝트는 깃으로 협업을 하면서 하긴 했지만 작업 분배가 결국 도메인 별로 나눠서 작업을 진행했기 때문에 한 코드를 여러명이 작업할 가능성이 거의 없었다. 따라서 커밋, PR 메세지도 나만 알아보면 되지.. 하면서 대충 적었던 것 같다...

이게 말이 되냐.. 1년 전 나 자신...

 

하지만 이번 프로젝트는 볼륨이 크기도 하고 수정 사항이나 개발을 도메인 별로 나누는게 아닌 스프린트 형식으로 진행하다 보니까 어떤 기능이 추가되고 어떤 기능이 아직인지 확인하기 위해 PR 메세지를 봐야하는 경우가 많았다.

 

따라서 한눈에 기능을 유추할 수 있는 PR 메세지, commit 메세지를 작성하려고 노력했다. 처음에는 어떤식으로 적어야 할지 고민을 하느라 메세지 적을 때도 많은 시간이 걸렸는데.. 지금도 비슷하다... 아니 조금 줄었다...

 

지금 작성하는거에 비하면 이것도 마음에 안드는데 일단 V1의 마지막 PR이니.. 넣겠다

 

 

사실 V2에 사용하는 방식은 좀더 발전한 방식이긴 하나 V1 회고니까... 이만 적겠다.

 

2. 협업 과정

우리 프로젝트는 개발 시 비대면으로 소통을 하면서 작업하는 거 외에 일주일에 한번씩 대면으로 파트별로 최소 절반 이상 참여해하는 회의를 2시간 진행했다.  길다면 긴 시간인 5개월동안 시험기간 2번을 제외한 모든 주차에 대면으로 회의를 진행했다. 그리고 이 회의 정책은 V2가 진행되는 현재도 이어지고 있다.

 

매주 9명 중 많아도 3명을 제외한 모든 인원들이 회의 참여했고 덕분에 프로젝트 진행이 정체되지 않은 것 같다.

보통 프로젝트를 진행하다 보면 자주 소통을 하지 않으면 프로젝트 초반의 텐션을 유지하기 어렵다. 하지만 매주 대면으로 회의를 진행하고 금주 진행 상황을 발표하고 다음주 진행 계획에 대해 회의를 진행하다 보면 해야 할 일이 명확히 보이게 된다. 

 

3. 새로운 개발 방법 습득

프로젝트를 진행하다 보면 peer review를 통해 얻게 되는 지식이 상당히 많다는 것을 느끼게 된다. 프로젝트를 진행하면서 팀원들의 개발 방법을 보고 내 코드에 적용하는 방식이 참 많았다. 

 

몇가지 예시...

- DTO를 맞출 때 class -> record로 교체

- Builder 패턴 -> static factory Method 패턴로 교체

 

해당 내용은 개발하면서 따로 알게 된게 아닌 팀원들이 "이건 이렇게 해보는 게 어때?" 라는 말로 시작됐다.

공부를 하면서 문제점을 발견해 더 좋은 방법을 찾는 것은 당연하지만 개발하는데 큰 하자가 없으면 새로운 방식을 찾지 않을 수 밖에 없다. 하지만 주변의 리뷰나 방식을 통해 생각치도 못한 방식을 얻을 수 있다.. 최고..

 

아쉬운 점

1. 회의 문서화 부족

회의를 매주 2시간을 진행하면서 회의록을 작성했다.

하지만 회의록으로만은 과거에 결정난 사항을 복기하기 어려웠다.

과거의 한 이야기를 언제 했는지 몰랐기 때문에 각 기능별로 어떻게 결정났는지 알기 어려웠다.

 

어,,, 이야기 했었나요,, 언제요?.. 확인 해볼게요..

 

 

이 점은 V2에 들어가며 일정을 관리하고 기능별로 회의 내용을 정리하는 과정이 추가되며 해결됐다..

개인 정보가 있어서.. 일부만..

 

 

2. 웹소켓에 대한 기술 부채

내가 개발한 CS 문제풀이 서비스를 구현하기 위해 WebSocket을 사용했다. 실시간성을 유지하기 위해 사용했으나 websocket에 대해 공부가 부족한 상태에서 코드를 짜기에 급했다. 

최초에는 websocket stomp를 사용해서 구현하다 막혀 기본 웹소켓으로 구현하기, 코드를 생각해서 짜기 보다는 기존의 레퍼런스를 가져와 프로젝트에 맞춰 개조하는 방식, websocket 방식을 사용은 했지만 웹소켓의 특징인 양방향성을 사용하지는 않은 마감시간에 쫒겨 문제가 발생했을 때
"그래서 더 나은 방법을 찾아서 마감할 수 있어?"라고 혼자 자기합리화하며 이것 저것 붙여가며 돌아만 가는 코드를 짰다.

V1 웹소켓 구현을 그림으로 표현할 때

 

결국에는 2월에 종료됐어야 하는 프로젝트가 5월까지 리펙토링을 했던 이유 중 가장 큰 이유라고 내 개인적으로는 생각한다.

 

돌아가기만 하는 코드를 짜서 결국은 나중에 공부를 하고 코드를 뜯어 고쳤다. 개인적으로 내 스스로 실망한 기간이었다.

 

3. 유지보수 할 수 없는 코드

프로젝트 V1은 2월 말 데모데이로 끝났지만 우리는 V2로 바로 넘어갈 수 없었다. 더러운 코드, 쿼리 최적화, 생명주기에 따른 연관관계 제거, 만족하지 못하는 로직을 다 뜯어 고치면서 2개월을 보냈다.

과거에 내가 작성한 코드를 보면서 생각했다.

"이게 뭔 소리야..?" 팀원이 이 코드가 뭐냐고 물어봤을 때 나도 내 코드를 보고 한참은 봐야지 이해하는 코드.. 대충 지은 메소드 명 등 그야 말로 개판 그 자체였다. 리팩토링 기간에 좋은 코드, 책임과 역할이 잘 분리된 코드, 잘 짠 쿼리를 제대로 생각하면서 다시 갈아엎었다..

 

해야할게 산더미였다... 과거의 코드를 짠 내 잘못이지..

 

결국은 언제가는 이 프로젝트는 종료되고 다른 동아리원이.. 이 코드를 보면서 기능을 추가할 것이다... 그 때 내 코드를 보고 이해할 수 있을까 생각하니 아찔했다. 코드를 이해할 수 없어 프로젝트를 이어나가는게 무슨 말도 안되는 이유인가..

 

V2에서는 뼈저리게 느낀 이 경험을 통해 코드 리뷰도 많은 시간을 투자하고 더 고민하면서 코드를 짜고 있다. 물론 미래의 내가 다시 코드를 보면 "아직도 부족해" 생각하겠지만 적어도 V1 때보다는 발전했네 생각이 들게 하는게 목표이다.

 

V2 목표

자연스럽게 v2 목표가 나왔는데 V2 기간동안 나의 목표를 적어보겠다.

 

1. 기술 부채를 최대한 줄이겠다.

 - 새로 공부를 할 때 CS라는 기초 벽돌이 없으면 기술 부채를 해결할 수 없다.

2. 3,4학년에 배운 CS 공부를 복기하면서 더 나은 코드를 짤 것이다. 

3. 내가 프로젝트에서 나갈 때 이 사이트는 유지될 수 있게 클린 코드를 작성할 것이다.

4. 개발과 CS 지식은 이론과 실기가 아니라 "개발이 CS의 연장선이다"을 명심하고 CS 지식을 바로바로 적용할 수 있게 미리미리 탄탄하게 적용시켜 놓자..

 

깃허브 링크: https://github.com/IT-Cotato/CS-Quiz-BE

GitHub - IT-Cotato/CS-Quiz-BE: IT연합동아리 Cotato CS퀴즈 서버 레포지토리입니다.

사이트 링크: https://www.cotato.kr/