팀프로젝트 ‘퐁퐁핑퐁’ 회고

2023.12 ~ 2024.04

프로젝트를 시작하며

42Seoul의 마지막 과제로 핑퐁 게임과 채팅이 포함된 웹프로젝트를 진행하게 되었다. 과제의 요구사항은 프론트엔드는 Vanilla JS로 할 것, SPA를 구현할 것 등등이 있어 학습하기는 좋겠지만 난이도 있게 느껴졌다. 프로젝트 인원은 프론트엔드 3명과 백엔드 2명이였고, 42Seoul 기간이 끝나기 전에 프로젝트를 완료해야 했기 때문에 조금 촉박하게 진행해야 했었다.

 

기획

필요한 페이지와 기능이 많아서 기획 단계에서 시간과 애를 많이 먹었다.

팀원들과 여러 차례 회의하며 노션 페이지에 각 페이지 별 필요한 기능들과 디테일을 정리했다. (디자인 이후에 삭제되었는지 없어졌다..)

최종적으로 구현해야 하는 페이지와 기능은 크게 아래와 같다.

• 로그인 페이지 : 생동감 있는 애니메이션 적용, 42Seoul OAuth 연동
• 메인 페이지 : 프로필, 일반 게임 전적/토너먼트 게임 전적 조회, 친구 추가/차단, 게임 신청
• 프로필 편집 페이지 : 사진 변경, 닉네임 변경, 2차인증 등록/해제
• 토너먼트 게임 대기 페이지 : 토너먼트 참가자 대기
• 게임 페이지 : 게임 진행
• 게임 결과 페이지 : win/lose 결과 확인
• nav 바 : 사용자 검색, 게임하기
• 채팅 사이드바 : 검색, 채팅
• 친구 사이드바 : 친구 목록 확인, 차단 목록 확인, 검색

정말 잘잘하게 할게 많은 프로젝트였다.

특히 토너먼트 게임 부분의 기획이 어려웠는데, 방장의 유무/강제 퇴장/게임 수동으로 시작할건지/게임 중간에 나가버린다면,,, 등등 고려할 점이 너무 많았다. 게임을 좋아하는 팀원이 있어서, 롤 같은 다른 게임에서는 어떻게 처리하는지 레퍼런스 삼아 기획했다.

 

디자인

이전 프로젝트 이후 피그마를 좀 더 잘 다루게 되어서, 컴포넌트를 만들어 여기저기서 활용했는데 굉장히 편리했다. 이런 툴을 잘 다룰 수 있게 공부 해야겠다는 필요성을 느낀다. 디자인은 나와 프론트엔드 팀원 한명이 주로 작업했는데, 깔끔하게 잘 나온 것 같다. 개발할 때 고려/주의할 점이라던지 좀 더 고민해야할 점들은 피그마의 Mark 기능을 잘 사용했다.

 

개발

핑계지만, 이전 프로젝트 이후 바로 이 프로젝트를 진행한 터라 부족한 점을 알고 있음에도 불구하고 시간이 촉박하게 느껴져 공부보다는 코드 작성에 우선순위를 두었다🥲

기술 스택

Javascript

과제에서 Vanilla JS로 개발을 요구해서 사용했다. React의 편리한 기능들을 사용할 수 없어 불편하겠지만, JS를 기초부터 학습하고 이해할 수 있을 것이라고 기대했다.

CSS3

과제에서 CSS 프레임워크를 Bootstrap 만 허용을 해줬는데, Bootstrap에서는 가져다 쓸 컴포넌트가 마땅하지 않아 CSS3로 직접 스타일 적용했다.

 

맡은 역할

SPA(Single Page Application) 구현

로그인 페이지, 설정 페이지, 메인 페이지 구현

 

협업

Git 전략

main → develop → 작업할 브랜치

작업해야할 내용을 이슈에 등록한 뒤, 작업할 브랜치를 만들어 각자 작업하고, 한 기능이 완성되면 PR을 올려 develop 브랜치로 merge한다. 이후 최종본을 main으로 merge 했다.

회의

정기적으로 일주일에 세번씩 회의를 진행했다. 회의에서는 각자 목표한 분량을 달성했는지(개발 진행 상황 체크), 공유하거나 함께 고민할 이슈가 있는지, 다음 회의 때까지 개발할 목표 분량을 정했다. 회의 외에도 이슈나 문의할 내용이 있다면 대면이나 슬랙으로 바로바로 소통했다.

 

발생한 이슈

SPA 구현

이 프로젝트에서 코드 작성하기 가장 어려웠던 부분이 아닌가 싶다. 정보가 생각보다 많지 않고 대부분 클래스로 구현한 정보라 방법만 학습하고 우리 프로젝트에 맞게 컴포넌트 방식으로 변경하여 적용했다. 페이지 변경 시 URL, JS 파일, CSS 파일이 변경되도록 했고, 반대로 URL이 변경되어도 화면이 바뀌게 했으며, 뒤로가기도 구현했다. React를 쓸 때는 이런 동작방식을 모르고 그냥 썼는데, 직접 구현하며 경험할 수 있어 유익했다. 이 프로젝트를 하며 프레임워크가 개발자를 얼마나 편하게 해주는지 뼈저리게 느끼게 됐다!

정리한 블로그

OAuth 연동

42Seoul의 OAuth를 연동한 로그인 기능을 구현했다. OAuth 부분은 구현해본 적 없어서 구글링도 해보고, 구현해본 팀원에게 많이 물어봤다. 로그인 버튼을 클릭 → 42Seoul 로그인 URL로 이동시킴 → 로그인 성공 시 바뀌는 URL의 code를 추출하여 백엔드에 API 전송 → 백엔드에서 해당 code를 토대로 42Seoul에게서 Token 발급 → 백엔드에서 API로 Token 전달 → 로그인 성공 로직으로 구현했다.

Refresh Token

이 프로젝트에서는 Refresh Token을 도입했는데, Refresh Token 처리 로직을 구현하는데 약간 애를 먹었다. API 호출 후 응답이 Token 이 만료되었다던지, 유효하지 않다던지 하는 Token 에러일 경우에 쿠키에 저장된 Refresh Token를 통해 Access Token을 재발급 요청 API를 전송한다. Access Token이 재발급 되었을 경우 이전에 호출했던 API를 다시 호출하면 되고, Access Token 재발급이 실패하였을 경우 로그아웃 처리하는 로직으로 구현했다. 그런데 이 로직에서 바보이슈로 Access Token 재발급 후 이전에 호출했던 API를 다시 호출할 때, Token 재발급 받고 API 다시 호출하는 두 과정이 무한루프가 돌기도 했었다. 다행히 무한루프가 도는 원인을 금방 찾아 문제를 해결할 수 있었다.

웹폰트 최적화

로그인 페이지에 타이틀을 애니메이션을 적용하여 생동감 있게 구현했다. 그런데 로그인 페이지 로딩 시에 CSS와 폰트 적용 전 화면이 잠깐 뜨고, 이후 CSS와 폰트가 적용된 화면이 뜨는 현상이 있었다. 다른 팀원들은 거슬려하지 않았지만, 로그인 페이지를 만든 나는 너무너무 거슬렸다. 찾아보니 FIOT(Flash of Invisible Text), FOUT(Flash of Unstyled Text) 라는 웹폰트 문제가 있었고, 나의 경우에는 웹폰트가 로딩되는 동안에 기본 시스템 폰트로 텍스트가 표시되다가 웹폰트가 로딩되면 스타일이 변경되는 현상인 FOUT 였다. 웹폰트의 확장자를 용량이 작은 woff2로 변경하고, 타이틀에 표시되는 문자만 포함된 서브넷 폰트를 통해 60% 가량의 로딩시간을 단축했다. 그리고 페이지 로딩 이벤트를 통해 CSS 파일이 적용되기 전에는 아무 내용도 보이지 않게 하고, CSS 파일이 적용되면 내용을 보이게 적용했다.

정리한 블로그

 

느낀점

채팅 기능의 뷰는 내가 구현했지만 채팅 담당 백엔드 팀원이 소켓 연결은 처음이라 이것 저것 시도해보며 프론트엔드도 직접 같이 개발하는게 테스트 하기도 좋을 것 같다고 해서 넘겨주게 되었다. 채팅 기능까지 구현해보고 싶었는데 쪼끔 아쉬웠다. 다음 프로젝트에서 채팅 넣을 일이 있다면 꼭 해보고 싶다.

어떤 기능(or 데이터)를 받은 뒤 다른 기능으로 이어지는 경우가 많았다. 비동기 처리를 제대로 사용해본적이 없어 이론적으로만 알고 있던 상태였는데, 직접 구현하다 보니 사용 방법과 필요성을 익힐 수 있었다. 하지만 아직도 사용할 때마다 vscode에서 await이 적용되지 않는 구문이라는 안내를 보고서, 여기서는 왜 await이 안되는지 고민한다. JS 이론을 다시 공부해야할 필요를 느꼈다.

일단 코드를 작성하는 것을 우선으로 하다보니 효율적이지 않게 작성된 부분이 많은 것 같다. 이 프로젝트가 끝나고 나면 JS를 기초부터 학습하고 다룰 수 있을 거라고 기대했는데, 기대에 미치지는 못한다. 책이나 강의로 JS 이론을 더 공부해야겠다고 느꼈다.

 

결과물

https://github.com/42EASY/PongPongPingPong