[프로젝트 회고] 스팀 게임과 파티원 모집을 한 곳에서! 스팀 모아

7주간의 첫 번째 프로젝트가 끝난지도 벌써 3주나 지났다. KPT 방식으로 팀 차원의 회고를 진행했지만 더 자세한 개인 회고를 남겨본다.

생계 걱정 없이 마음껏 공부하며 내가 원하는 서비스를 만들 기회. 보통 기회는 아닌걸 알면서도 7주간 프로젝트를 진행하며 좋았던 점보다 힘든 점이 더 많았다. 원하는 기술 구현에 실패했을 때 느꼈던 좌절이라든가 팀장으로서 과한 책임감으로 팀원들에게 부담을 준 건 아닌지 고민했던 것, 추후 어떤 서비스를 개발하고 싶은지, 내가 웹개발을 하며 재미를 느끼는 지점은 어디인지 생각해 본 것까지. 여러 지점에서 돌이켜볼 게 많다.

 

회고를 통해 나쁜 습관은 버리고 좋았던 점은 강화해서 추후 프로젝트는 더 재미있게 진행할 수 있길! 앞으로의 프로젝트에서는 매 과정에서 내가 습득하고 파악한 것에 대해 자세히 기록해둬야겠다.

 

스팀모아 로고

 

1. 프로젝트 전반 회고

Keep

• 와이어 프레임이 깔끔하게 정리되어 있어 화면을 머리속에 그리기 좋았다.
• 원페이퍼 기획서를 똑바로 작성해서 프로젝트 진행과 발표에 큰 도움이 됐다. 
• 일일 스크럼 덕분에 팀 진행 상황을 모두가 파악할 수 있었다.

Problem

• 문서화(API 정의서, ERD, 와이어 프레임) 업데이트가 제대로 이루어지지 않아 소통에 문제가 됐다.
• 기획에 대한 모든 팀원의 이해도가 달라 같은 말을 반복해서 낭비되는 시간이 많았다.
• 일이 몇사람에게 몰리는 경우가 있었다.
• 프로젝트에 대한 각자의 목표가 다르다보니 헌신도가 달랐다.

Try

• 아침 스크럼과 저녁 스크럼을 가져서 공유하는 시간을 자주 가질 필요가 있다.
• 문서화는 시간이 오래 걸려도 가독성을 1순위로 두자. 보여주기식 문서화 절대 지양
• 기획 단계에서는 프론트나 백이나 모두 활발히 회의에 참여하자

---

모아존 페이지

 

2. 프론트엔드 회고

오픈 ID

• 새로운 개념을 이해하고 서치하는 과정이 어려웠다. 스팀모아는 스팀 로그인에 의존하고 있었기 때문에 오픈ID 구현에 실패하면 회원가입 자체에 대한 고민부터 다시 시작해야했다. 관련 자료도 없었고 프론트 팀원 셋이 맨땅에 헤딩하듯 구글링 하는 과정에서 많이 불안해했다. 
• 영어로 검색하는 것과 영어 자체보다는 코드를 하나하나 분해하며 이해하려고 연습하는 것이 중요하다는 것을 알았다.
• 자주 나오는 키워드로 계속 연결해서 검색하는 것이 중요하다. 구글링도 실력이다.

검색

• 초반에 짰던 (검색 - 필터링 - 리스트 - 페이지네이션의 묶음) 코드의 의존성이 높아 원하는 로직으로 동작하지 않았다. 
• 방법을 아예 변경하여 라우팅을 통해 문제를 해결했다.
• 의존성을 떨어트리는 모듈화, 아토믹 디자인의 중요성을 느꼈다.

CSS

• 스켈레톤을 처리하거나 정해진 규격 안에서 글씨를 움직임 처리하는 것, 웹-패드-모바일 반응형 처리, 이미지 비율을 처리하는 과정을 통해 CSS에 대해 많이 학습했다. 
• 공식 문서를 탐독하고 제대로 적용하는 것의 중요성도 다시금 알았다. (이미지 비율 관련 css : aspect-ratio https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-ratio)

모달

• 모달을 위한 state 설정
• 모달 위치를 위한 css
• 모달 디스플레이를 위한 css

예외 처리

• 로그인 여부에 대해 디테일하게 예외 처리를 해주어야 하는 경우가 있었다.
• 특정 페이지에서 뒤로가기를 눌렀을 때 로그인이 되어 있어야만 접근이 가능한 경우와 아닌 경우를 잘 나눠서 적절한 예외 처리를 해주어야 한다.
• 파티원을 모집할 때 로그인되어 있는 사람이 파티장인 경우, 파티장이 아닌 경우에 따라서 사용자 목록에 X 표시가 보일 수도 있고 안 보일 수도 있다. 파티원 삭제 기능을 구현할 때 삭제 권한을 부여하는 과정에서 여러 컴포넌트와 페이지를 거쳐 예외 처리를 구현해야했다.

렌더링

• 리액트 렌더링 흐름, 라이프 사이클에 대한 이해를 더욱 견고히 할 필요가 있다.
• useState, useEffect, useCallback, useParams 등 기본적인 훅에 대한 이해를 높여 나에게 맞는 코딩 스타일을 가져가고 싶다.

구조

• 라우팅 처리, api 요청 보내는 함수를 따로 관리해 의존도와 반복을 줄이자
• 컴포넌트, 페이지, api, 라우터 등 초기 설정 단계에서 큰그림을 그린 뒤 디렉토리 구조를 짜고 시작하자 (이번 프로젝트에서는 중간에 수정하느라 시간이 좀 걸렸다.)
• 컴포넌트의 구조를 짜임새있게 정석대로 하고 싶었으나 또 프로젝트를 수행하며 섞여버린 점이 아쉽다.

---

3. 웹 개발에 대한 개인 회고

- 사용자 친화적인 서비스를 개발하겠다는 다짐은 결국 일상에서 얼만큼 사람과 세상에 대해 고민하는지 그 고민의 깊이와 연관될 수밖에 없다고 생각한다. 현재 대부분의 소셜 미디어가 유저 팔로우 기능을 포함하고 있기 때문에 단순히 그 이유만으로 우리 서비스에도 해당 기능을 추가하겠다는 수동적인 태도보다는 사용자간의 상호작용을 통해 어떤 가치를 만들어내고 싶은지 능동적으로 고민할 필요가 있다. 해당 기능을 뺐을 때 사용자에게 어떤 불편함이 있을지에 대해서도 꼼꼼히 따져봐야 할 것이다. 예시를 유저 팔로우 기능으로 들었지만 게임 상태에 대한 태그 설정, 게임이 종료되는 시간 추가 여부, 방장에게만 추방 권한을 줄것인지 방장이 아닌 참여자에게도 탈퇴 권한을 부여할 것인지 등등등... 7주라는 짧은 시간 때문에 충분한 근거 없이 의사결정을 해버린 게 아쉬움으로 남는다. 실제 서비스를 만들게 된다면 보다 진지한 고민과 이를 바탕으로 합리적으로 의사결정해 좋은 서비스를 만들고싶다. 

 

- 스팀모아가 반 3등을 해서 우수 프로젝트에 뽑혔다. 배운 기술을 체화하고 프로젝트에 적용하기에도 바빠 상 욕심은 크게 없었는데 팀원과 으쌰으쌰 달려가다보니 보다 많은 사람에게 우리 서비스를 자랑하고 싶은 욕심은 생겼다. 기획의 정당성이 확보되고 정말로 현실적인 서비스를 만들어보고 싶다는 나의 개인적인 목표를 달성했기 때문에 상이 더욱 선물처럼 느껴진다. 

 

- 기획의 정당성이 확보되지 않거나, 기존에 있는 서비스를 답습하는 프로젝트는 하고싶지 않았다. 나만의 서비스 개발 의도가 분명해져야 마음이 동한다는 것을 스팀모아를 개발하며 알게됐다. 서비스 기획에 흥미를 느끼고, 중요하다고 생각하는 이유다. 사용자의 필요를 정확히 파악하고, 해당 서비스의 기대효과에 대해 분석하는 것이 나에게는 가장 중요한 부분 중 하나다. 탁상공론, 보여주기식, 현실과 동떨어져 있는 것.. 싫어 싫어...

 

- 나의 부족함을 인정하고 팀원에게 솔직히 공유하며 유능한 팀원의 도움을 기꺼이 받는 것도 성장의 지름길이라고 느낀다. 합이 좋은 프론트 팀원을 만나 성공적이고 기쁜 프로젝트를 진행할 수 있어 감사하다.