01. 첫 프로젝트를 회고하며.
프론트엔드 3명과 백엔드 3명이 랜덤으로 한 팀이 되어 약 2주간 프로젝트를 진행했다. 주제는 개발자들이 가장 많이 사용하는 커뮤니티 'Stackoverflow' 클론 코딩으로 사용할 때는 특별한 기능이 없어서 만만하게 생각했지만 생각보다 순탄하지 않았다..!
기획 단계
화면 기획
피그마를 사용하여 화면설계서를 작성했다. 내가 작성한 파트는 게시판 리스트, 마이페이지, 로그인 페이지였으며 실제 사이트에서 구현하지 않는 부분은 배제하여 리디자인하였다.
Git Flow
git branch 전략
- main: 실제 배포되는 브랜치
- dev: 다음 버전을 개발하는 브랜치
- feat: 기능을 개발하는 브랜치
만들고자 하는 사이트가 크지 않은 규모이기 때문에 위와 같이 축약하여 flow를 짰다. 이후에 사용하며 깨달은 점은 굳이 main과 dev를 나눌 필요가 있을까 하는 생각이었다. 명시적인 버전관리(v1,v2,v3..)가 필요한 어플리케이션과 다르게 웹사이트는 항상 최신의 단일 버전만을 사용하기 때문에 브랜치를 3개의 뎁스로 쪼개기 보다는 github의 action 기능을 통해 자동화 CI 빌드를 구축하는 것이 더욱 바람직하지 않았을까 싶은 아쉬움이 든다.
개발 단계
작업 할당 및 개발 시작
팀원의 노고로 완성된 플로우를 기반으로 PAGE 단위의 디렉토리와 파일 구조를 간략하게 그려보고 함께 작업할 분량을 정했다. 내가 맡게 된 부분은 공통 컴포넌트의 Button,Header, 그리고 게시판 관련 페이지였다.
버튼과 헤더 컴포넌트는 수월하게 진행되었지만 공통컴포넌트로 사용되기 때문에 다양한 요소들을 Props로 전달받아 구현되어야 하기 때문에 크기,텍스트,색상,타입,받아오는 데이터 등 다양한 부분을 고려하며 리펙토링되었다. 추후에 로그인 페이지를 담당하는 팀원에 의해 헤더는 모양만 갖춰진 컴포넌트에서 로그인 정보를 모든 페이지에 뿌리는 사이트의 진정한 HEAD로 거듭났다.
Page 단계에서는 이번에 사용하기로 미리 정했던 기술스택 중 Styled Components와 Axios가 많은 비중을 차지했고 Redux toolkit은 생각보다 활용이 익숙하지 않아 직접 구현하지 못하고 받아오는 역할만 수행했다.
실제로 API 명세서를 백앤드와 논의하며 요청하고 응답받는 과정을 진행해보니 서버가 전송하는 Body의 구조의 중요성, 연습만 했었던 Postman의 진정한 가치를 느끼며 데이터의 상관관계가 얼마나 중요한 것인지 깨달았고 오픈 API나 다양한 라이브러리를 사용하여 더 깊이있는 기능을 만들어보고 싶어졌다.
배포 단계
기다려왔던 배포의 시간
슬프게도 TDD는 구현하지 못한 채 프로젝트 마감 날 배포를 진행하게 되었다. 교육을 받을 때 배포
를 미리하면 CORS 에러를 예방할 수 있다는 현명한 조언을 들었던 기억이 얼핏 스쳐지나간다. AWS 배포 후 로컬에서는 프록시 우회를 통해 잘 받아와지던 데이터들이 사라지고 콘솔창이 붉게 물들었다.
webConfig 설정이나 해당 Api controller 에 @CrossOrigin 어노테이션을 사용하여 CORS 에러를 제어할 수 있다는 정보를 찾아 시도해보았지만 로그인 시도 시 토큰값을 POST하는 과정에서 CORS에러가 반복적으로 발생했다.
마지막 날 뼈 아픈 경험을 하며 그렇게 프로젝트는 막을 내렸다.
