☄️ 배경

2022년 42gg프로젝트를 마무리하고, 2기를 뽑아서 넘겨주게 되었다.

나는 얼마 남지 않은 블랙홀을 밀기 위해...
프로젝트에서 과제로 스위칭 하는 시간이 필요했고, 1월 동안은 42서울의 C++ Module 과제를 밀었다.

C++을 처음 하는 거라 문법도 잘 모르고, 해서 미리 시작하고 있었던 동현님과 지요, 그리고 이미 과제를 끝냈던 대킴님과 오전 ~ 오후에 함께 클러스터에서 공부했다. C++ 과제로 지쳐있었을 때, 잠깐의 티타임☕️ 시간에 "우리 C++로 오목 게임을 만들어 보는 건 어때?" 라는 말이 불씨🔥가 되어...

오크모크 프로젝트가 시작되었다!!

나는 42gg 프로젝트를 하면서,

• 42서울의 선배님들과 만남의 자리를 가지고,
• 크래프톤도 다녀오고,
• 기존 코드를 코엑스 소프트웨이브용 이벤트용으로 수정하고,
• 포트폴리오를 쓰기 위해 프로젝트 복기도 좀 해보고,

하면서 리팩토링에 대한 열망☄️과 새로운 프로젝트를 통해 이것저것 새롭게 써보고 싶은 열망☄️이 똘똘 뭉쳐있었기 때문에 거절할 이유가 없었다.
(이것저것: 반응형, custom hook, grapQL, ... 문제인식과 해결과정 기록 등등)
(또, 클래스를 겨우 만들고 있는데 이 C++로 게임을 만든다고?? 재밌겠는데?? 라는 마음...😆)

첫날 우선 대킴🐷, 동현🐵, 지요🐉 그리고 나🐭 이렇게 네 명의 팀원들이 모여 근무수칙과 기술스택, mvp 기능을 정했다. 그리고 각자 기술스택에 대해서 공부를 했다.

🛫 MVP 기능 설계

mvp는 오목 게임에서 필요한 기본적인 페이지와 기능들을 쭉 나열한 뒤, 각 페이지별로 필요한 기능들을 묶고, 우선순위에 밀린 기능들은 추후 구현할 것으로 미뤄두었다. 아래와 같이 간단하게!

✨ 오크모크 MVP

로그인

- 게스트, 간편 로그인(구글 - 개인정보 동의 체크 모달 추가)
- 닉네임은 랜덤하게 부여. 구글 로그인은 닉네임 변경 가능하도록 (닉네임 중복 불가)

메인페이지

- 방만들기
	+ 기본 둘이서(두대 디바이스)
	+ 시간 조정
	+ 삼삼은 허용(추후 허용 유무 체크 구현)
	+ 관전 유무 기능
- 방리스트

게임페이지

- 오목판
- 경기 유저 정보
- 준비, 시작, 강퇴, 초대, 음소거, 나가기
- 착수, 기권
- 시간표시
- 방 설정
* DB 기보 저장 필수

etc ...

🛠 기술 스택

42 과제에 파묻혀 하고 싶은 것들이 넘쳐났다. 나는 GraphQL을 꼭 써보고 싶었기에 장단점을 찾아보게 되었다.

왜 GraphQL ?

RESTful API의 문제점

• over fetching: 데이터를 선택적으로 쓰고 싶지만, 원하는 양보다 많은 데이터를 받아오는 것
• under fetching: over fetching과 반대로 덜 받아오는 것

RESTful API의 경우 필요한 리소스에 따라 특정한 엔드포인트로 요청 해야하고, 필요한 데이터들이 부분적으로 나눠서 개발되어 있다. 따라서 그만큼 요청 횟수가 늘어나게 된다.

42gg 프로젝트를 하면서 REST API의 under fetching의 불편한 점에 대해서 많이 느낄 수 있었다.

42gg페이지에 유저가 처음 진입했을 때, 레이아웃에서 유저정보(/user), 시즌정보(/seanlist), 공지정보(/announce), 유저 현재 경기 정보(/live)를 각각의 다른 api를 통해 받왔다. 데이터 요청을 4번이나 하는 것! 😱

또, 경기 예약 페이지에 새로고침 버튼을 만들면서 각 컴포넌트에 분리되어 있는 데이터를 다시 패칭받아 관리하기 위해 recoil을 여기! 저기! 심어주게 되었다.😖 (그때는 최선이라고 생각했지만, 지금 useAxios나 다른 형태로도 구현이 가능할지도 모른다. 새로고침버튼이 나중에 추가된 기능이라 아쉬운 부분)

프로젝트를 하며 취업한 선배를 만나 이야기할 수 있는 자리가 있었는데, 그분이 GraphQL을 이야기 하셨다. 그리고 찾아보았는데, 정말 멋진 녀석같았다.

그래서 GraphQL은 ?

• Get many resources in a single request
  일반적인 REST API는 여러 URL에서 로드해야 하지만 GraphQL API는 단일 요청으로 앱에 필요한 모든 데이터를 가져올 수 있다.
• HTTP 요청 횟수를 줄일 수 있다.
• 응답 사이즈도 줄일 수 있다.

RESTful API 보다 유연하게 데이터를 요청하고 받을 수 있다. 기존 API 요청 형식과 너무 다른게 흥미로웠다. 특히, 서버비 지원을 따로 받지 않는 우리같은 가난한💸 학생들에게는 HTTP 요청 횟수를 줄일 수 있는 것이 매력적으로 느껴졌다.

🖼 화면설계

2일차부터는 빠르게 화면설계에 들어갔다.

모바일의 작은 화면에서 어떻게 보여지는 지가 가장 중요하기 때문에, 모바일 화면을 먼저 설계했다. 데스크탑은 모바일에서 구현한 컴포넌트를 기반으로 레이아웃이나 크기만 조정하면 되므로...!! 이건 화면을 여러번 설계하면서 깨닫게 된 건데, 반응형 디자인을 서치하다 보니 화면 설계법에 모바일 우선(Mobile First) 화면 설계법 이라는 것이 있었다. 🤭

3일차에는 피그마의 페이지별 화면설계를 보면서 다같이 세부적인 기능을 정의하고, 확인하는 시간을 가졌다. (화면은 아직까진 비밀이다!🤪)

고민해야할 부분은 추후에 확인하기 쉽도록 이모티콘과 빨간색으로 표시하고, 확정된 부분은 세부적으로 설명을 적어주었다. 이렇게 해야 여러 팀원들이 보아도 같은 결과물을 상상하며 코드를 그려나갈 수 있다.

이번에는 반응형 구현에 욕심을 내어서 데스크탑 화면 레이아웃과 모바일 레이아웃을 다르게 구성했다. 이전 프로젝트처럼 단순히 rem으로 크기만 조정하는 게 아니라 레이아웃 자체를 약간 다르게 설계했다. 두근두근 피그마를 만들면서 어떻게 컴포넌트를 분리하고, 구조화해서 코드를 짜야할 지 그려졌다. 기대된다! 😍

🔬 데이터 추출 및 정의

페이지별 화면설계를 보면서 필요한 데이터를 뽑아내는 작업을 했다. DB 설계를 위한 과정이라고 한다. 이 데이터를 바탕으로 DB를 설계한다.

예를 들면,

rank 페이지 ➡️ 랭크, 유저이름, 상태메시지, 승 횟수, 패 횟수, 현재 페이지, 총 페이지

이런 식으로 모든 페이지와 모달 등에 필요한 데이터를 뽑아내고 정리했다.

이전에 프로젝트에서 백과 프론트를 나눠 진행했을 때에는 이 과정까지는 참여하지 않았었는데, 데이터를 뽑아내는 과정이 생각보다 만만치 않았다. 그래도 중복되는 데이터가 보여서 어떻게 묶어야 할 지(유저 데이터는 어디까지 유저가 가지고 있고, 어디서부터 랭크, 프로필로 나눌지)가 보였다.

🏗 스키마 설계(API 설계)

팀원들이 모두 모여 전날 정리한 데이터를 보면서 확인하는 시간을 가졌다. 또 GraphQL 문법에 맞게 request, response를 정의하며 세부적으로 데이터 변수명도 정했다.

이밖에도, 아래 사항들처럼 세부적인 것까지 논의했다.

• 유저를 식별하는 값을 어떻게 관리할 지(닉네임 or 유저 인덱스)
  • 닉네임은 수정이 가능한가?
  • 신고 대상이 닉네임을 수정한다면?
  • 채팅을 받은 대상이 닉네임을 수정한다면?
• 유저의 상태값을 하나의 enum으로 관리할 지, 분리할 지
• 유저가 강퇴한 방 재입장시 프론트에서 처리? 백에서 처리?
• 방 넘버와 id를 따로 관리한다면, 강퇴리스트는 어떻게 관리하는가?
• etc...

이렇게 세부적인 것까지 논의하면서 점점 추상적이던 프로젝트의 흐름이 구체적으로 그려지고 있다는 게 느껴졌다.

😆 1주차 마무리

이렇게 한 주가 끝이 났다. 정말 설계를 탄탄히 하고 들어가고 있다. 꼼꼼하게 함께 확인하고 들어가니 시간이 조금 걸렸지만, 나중에 발생하는 오류들을 줄여줄 수 있을 것이라고 믿고 있다...!!! 뭐 하나 익숙한 거 없이 새로운 기술들을 쓰느라 찾아보고, 논의하느라 정말 말을 많이 했다. 새로운 프로젝트에 들어가서 두근두근하다. 앞으로의 오크모크가 기대된다.💕