[Pre Project] Stack Over Flow Clone

soohyunee·2023년 3월 6일

프로젝트

[Pre Project] Stack Over Flow Clone

목록 보기

9/9

1. 프로젝트 개요

프로젝트 기간

2023.02.15 - 2023.03.02

팀 구성

Frontend 3명 -> 2명, Backend 3명

기술 스택

Frontend : React, Styled-Components, Axios

주요 기능

Question

Create: 유저만 질문 작성 가능
Read: 질문 상세 페이지 조회
Update: 작성자만 질문 수정 가능
Delete: 작성자만 질문 삭제 가능

Answer

Create: 유저만 답변 작성 가능
Read: 답변을 작성한 질문 상세 페이지에서 조회 가능
Update: 작성자만 답변 수정 가능
Delete: 작성자만 답변 삭제 가능

Signup & Login

회원가입
로그인, 로그아웃

결과물

메인

로그인 / 회원가입

상세 페이지

2. 회고

1. 리덕스 공부하자
이번 프로젝트에서 제일 아쉬웠던 점은 리덕스를 사용하지 못한 것이었다. 초중반에 프론트엔드 팀원분 한 분이 중도하차를 하면서 각자 맡아야 할 부분도 늘어났고, 그에 따라 포기해야할 부분도 생겼었다.
원래는 기능 구현이 다 되면 리빌딩하는 식으로 리덕스를 적용해보려고 했었는데, 생각보다 시간이 촉박했고 백엔드와 연결하는 부분에서 시간이 많이 소요가 되어서 차마 리빌딩 시간을 갖지 못하고 후반부에는 여유가 없는 채로 프로젝트를 마무리하게 되었다.
이제 또 바로 시작하는 메인 프로젝트 때는 리덕스에 도전을 하면서 공부를 하더라도 리덕스를 사용해야겠다는 생각이 들었다. 사실 axios도 제대로 사용한 건 이번에 거의 처음인 것 같다. 그래서 처음에는 안그래도 약한 비동기 파트에 axios까지 괜찮을까? 라고 생각이 들었는데 지금은 이제 두렵지가 않다!
그래서 공부를 충분히 하고 적용을 하면 더 좋겠지만, 오히려 에러를 두려워하지 않고 하면서 배우는 것도 실력 향상에 도움이 많이 된다고 생각이 들었다.

2. 팀원들과 소통하기
다른 팀은 어땠을 지 모르겠지만 우리 팀은 소통에 있어서 순탄하지만은 않았다고 생각한다. 프로젝트 초중반 쯤 프론트 팀원 한 분이 개인 사정으로 인하여 하차하실 때 하차 당일 알게 되어서 조금 당황스럽기도 했지만 소통의 중요성을 그 때 더 깨닫게 되었다. 만일 그런 상황을 일찍 알게 되었다면 대비를 할 수 있었을 테니 말이다. 그래도 팀원 분이 하차를 하게 된 이후로 더 많이 소통을 시작했고, 서로 어려운 점이 있거나 부득이하게 불참할 경우 등의 일정 공유도 잘 되었다.

3. 기획, 설계 단계와 문서화의 중요성
우리 팀은 다들 협업 경험이 없었고, 개발 프로젝트 경험 또한 없었기에 초반에는 기획과 설계 단계를 짧게 갖고 개발 시간을 길게 갖는 방향으로 진행했었다. 아무래도 다들 개발하는데 오래 걸릴 것이라고 생각한 것도 있을테고 기획, 설계의 중요도가 개발보다 낮다고 생각해서 그런 것도 같다.
하지만 개발에 들어가서 각자 서로 생각했던 큰 그림은 같으나 작은 부분은 생각하는게 다르구나라는 것을 알게 되었다. 그래서 회의 때 주로 그런 것에 대해 논의를 하곤 했었고, 간단한 유저플로우라도 그릴 걸 이라는 생각도 많이 들곤 했었다.
그리고 화면명세서와 api명세서처럼 문서화를 하는 것은 정말 중요한 것이구나 라고 느끼게 되었다. 이번 프로젝트에선 화면명세서라기보단 와이어프레임에 가깝게 피그마로 화면 디자인 정도만 그려봤는데 이렇게 하니 백엔드분들이 보기에는 기능별로 나열하지않아 어떤 버튼을 누르면 어떤 일이 발생하는 지와 같이 잘 연상이 안됐던 것 같다. 프론트도 api 명세서를 프로젝트 마지막 쯤에 받아서 테스트 api로 테스트를 할 때 사용했던 변수명같은 것을 api 명세서에 적힌 것으로 바꾸는 작업을 하기도 하고, 연결을 하니 막상 생각했던 응답과 다른 응답을 받은 적도 있어서 조금 비효율적이라고 느꼈었다.

4. 하면 된다! 포기하지말고 구글링하자
이번 프로젝트에서 axios, 텍스트 에디터, json server, json server auth 등 처음 다뤄보는 것들이 참 많았다. 각 종 다양한 라이브러리도 많았고 git도 정말 어려웠었다. 하지만 모르고 낯설어도 구글링을 열심히 하다보니 정말 어느 순간 해결이 되고 있었다. 안되면 될 때까지 영어도 번역해가면서 열심히 구글링을 했던 것 같다.
구글링도 실력이라는 말이 공감이 이제야 되는데 확실히 구글링을 많이 해보니 이제 어떤 키워드를 검색하면 나오겠구나 혹은 이걸 보면 되겠다 이걸 적용하면 되겠다 라는 감이 조금씩 생기는 것 같다. 구글링하는 동안은 참 괴롭긴 하지만 막상 해결이 되면 너무 뿌듯했다.

5. TIL은 나의 오답 노트
예전에는 에러가 나오면 사실 조금 두려웠다. 에러가 나면 그냥 막연하게 뭐가 잘못된거지? 라고만 생가했었다. 하지만 TIL을 쓰다보니 낯이 익은 에러도 많이 보였고, 에러가 났다는 상황에 집중하기보다는 에러가 무엇을 얘기하고 있는지 에러 메시지를 뜯어보고 에러 발생 지점으로 돌아가서 코드를 뜯어보는 습관이 생겼다.
TIL을 쓰려면 에러에 대해 알아야할 것 같아서 에러 메시지가 무엇인지 구글링을 하고, 구글링한 방법으로 시도를 해보고, 해결을 하면서 블로그에 최종적으로 다시 정리하는 느낌으로 글로써 정리를 하니 에러 핸들링을 하면서 정말 많은 학습이 됐었던 것 같다. 그리고 비슷한 에러가 나면 내 블로그를 다시 보곤 한다. 이번 프로젝트 때 map관련 에러가 많이 났었는데 TIL을 적은 이후에도 몇 번 났어서 내가 적었던 TIL을 또 보고, 해결했었던 기억이 있다.
다음 메인 프로젝트 때는 아무래도 조금 더 도전적이고, 난이도 자체도 높을 것이라고 생각이 든다. 메인 프로젝트때도 열심히 에러를 극복하고 TIL을 적으면서 더 많이 성장하고 싶다.

6. 배포를 실패하다
제출 마감일 3~4일 전부터 배포를 시도를 하였지만, 결국 실패하였다. 그래서 프로젝트의 배포 링크는 존재하지 않는게 너무 아쉽다. 우선 처음엔 백엔드 측에서 aws로 배포를 하려다가 실패하였고, aws로 배포한 서버를 연결하는 것보다 우선 통신이 잘되고 있는지 확인하는게 급하다고 판단하였다. 그래서 tomcat으로 배포한 서버와 클라이언트를 연결한 후 통신이 잘되고 있는지 확인을 했다. 그런데 생각보다 cors에러 등.. 발목 잡히는 시간이 길었고, 에러가 다 잡힌 후에는 하루라는 시간 밖에 남지 않게 되었다. 다시 백엔드 측에서 aws로 서버를 배포하려고 하였으나 실패하였고, 결국 그렇게 프로젝트는 종료하게 되었다.
너무 아쉬웠지만, 다음 메인 프로젝트에서는 매주 배포를 해서 백엔드와 잘 통신이 되고 있는지를 체크하는 것이 필요하겠다고 생각했다. 추후에 메인 프로젝트가 끝나면, 리덕스로 리빌딩 + 최적화 + 파이어베이스 스토리지를 사용하여 전체적인 코드 리팩토링을 진행할 예정이다.