사전 프로젝트 회고

지난 목요일 2주 반 정도 시간을 쏟아부은 사전 프로젝트를 마감했다. 4개월의 학습 기간을 마치고 처음 해보는 프로젝트였다. 사전 프로젝트 목표는 Stack Overflow를 클론하는 거였다. 즉, 기본적인 질문, 답변 게시판 CRUD 및 회원가입/로그인이 주요 과제였다.
 
부트캠프에서 OT 때 안내하기로는 사전 프로젝트는 이 다음 메인 프로젝트를 위해 기능 구현에 힘을 쏟고, 자동 배포 등은 후순위로 두는 게 좋다고 얘기했지만, 나는 반대로 CRUD 기능 구현을 후순위에 두고 깃헙 등 여러 명이 함께 하는 프로젝트 툴 사용에 익숙해지는 것과 자동 배포, https 통신 프로토콜 같이 혼자서는 해볼 수 없는 것들을 프로젝트 때 경험해 보고 싶었다. 게시판 CRUD 기능은 혼자서도 얼마든지 구현해 볼 수 있는 거니까 팀 프로젝트가 아니면 할 수 없는 것들을 하고 싶었다. 
 
그래서 맨 처음부터 스택오버플로우 코드 구현이 아닌, 프론트와 백에서 각각 to do 앱 과제를 구현했던 걸 서버와 클라이언트의 통신으로 이어보는 걸 시도했다. 그리고 장렬히 실패했다 ㅋㅋㅋㅋㅋ 하루 반나절 정도 시간을 쓰다가 포기하고, 방향을 선회해 클라이언트와 서버에서 최종 배포 환경을 먼저 구성해두고, 코드가 무거워지기 전에 아주 간단한 api 테스트를 해보기로 했다. 그래도 결코 무용한 시간은 아니었다. cors 에러를 처음부터 맞았고, http 통신 환경과 https 통신 환경이 다르다는 걸 확실히 알 수 있었다. 사실 https 프로토콜을 사용하는 건 클라이언트 쪽에서는 크게 어렵지 않지만 서버가 할 일이 많다. 백엔드에서는 4개월 동안 http만 배웠지 https는 가보지 않은 땅이었다. 하지만 실제 바깥 세상은 다 https지 http를 쓰는 곳은 이제 거의 없다. 언제고 넘어야 할 산이면 일찍 넘는 게 좋지 않겠냐고 백엔드 팀원 분들을 설득했고, 다행히 팀원들이 도전적인 과제를 흔쾌히(라고 믿고 있다😇) 받아들여줬다. 
 
맨 처음에는 서버에서 보내주는 간단한 문자열을브라우저에 띄워보는 것으로 시작했다. 
 

cors 에러

하지만 이내 성공했다! 
 

FE-BE server connected. Hello!

 
 
초반에 백엔드 개발 속도가 프론트보다 훨씬 빨라서 DB 구축이 어느 정도 되어 있었다. 그래서 이 다음은 클라이언트에서 보내는 데이터를 서버가 받아서 그대로 응답 데이터로 돌려주면 그걸 화면에 띄워보기로 했다. 
 

Hello Loopi

 
이때가 사전 프로젝트를 하면서 가장 기쁜 순간이었다. 최종 과제 제출을 하는 순간보다 더 기뻤다. 이 날이 프로젝트 시작 7일차였는데, 사실상 이 때 이미 하고 싶은 걸 다 이룬 셈이었다. 이 다음부터는 그냥 코드를 짜기만 하면 됐다.
 
 
api 테스트 준비를 하면서 동시에 초기 세팅을 해야 했다. 나 포함 사전 프로젝트 팀원 여섯 명이 전원 프로젝트 경험이 없는 사람들이라 초기 세팅을 하면서 config 등을 어떻게 해야 하는건지 하나도 몰랐다. 프론트 쪽은 나 혼자 초기 세팅을 담당해야 했는데 이게 맞는지 뭐가 뭔지 몰라서 시간을 많이 썼다. 지금도 뭐가 뭔지 잘 모르지만 그래도 한 번 해봤다고 메인 프로젝트 때는 조금 더 수월하게 할 수 있었다. 물론 다 뜻대로 되지 않는다. 늘 그렇듯이😇 프로젝트를 하면서 안 되는 게 당연하고, 되는 게 이상하고 알 수 없는 거라는 걸 많이 배웠다. 
 
초기 세팅과 api 테스트를 마치고, 코드 작성을 해나가다보니 자동 배포 환경이 일찌감치 구성되어 있었기에 배포 링크에서 빨간 딱지를 맞는 대참사도 겪었다. 클라이언트가 https인데 서버가 http로 통신하는 경우, 보안의 위험성 차원에서 브라우저에서 경고하는 거라고 알려준 분도 있었는데, 우리 팀은 클라이언트와 서버 모두 https 통신이었기 때문에 사이트 타이틀, 파비콘, 마크업, 스타일링 등이 똑같아서 브라우저에서 위험 사이트로 경고하는 것으로 생각하고 있다. 클론 성공의 증표로 삼기로 정신 승리..ㅋㅋㅋ 
 
 
게시판 crud 기능 중에서 스택오버플로우라는 사이트의 특징을 생각했을 때 단순 텍스트를 작성하는 게시글이 아니라 코드를 작성할 수 있고, 코드 블록을 보여주는 게 중요하다고 생각했다. 그래서 에디터 라이브러리를 사용해서 사용자가 텍스트 뿐만 아니라 코드도 작성할 수 있게 구현했다. 
 

질문 작성 화면

최종 배포 후 찍어둔 화면이 없어서 아쉽다... 그나마 코드 블럭 나온 화면

 
 
프로젝트를 하면서 코드 작성 관련해서 얻은 가장 큰 수확은 react custom hook 사용의 필요성을 제대로 느끼고 몇 가지 hook을 작성했다는 점이다. 그리고 이제까지 브라우저의 개발자도구로 주로 요소 검사와 콘솔 창을 주로 봤는데 네트워크 탭을 신명나게 들여다보게 되었다. 맨처음 request header와 response header를 배울 때는 당최 뭐가 뭔지 알 수 없었는데, 네트워크에 대한 이해도를 절로 높이게 되었다. 또한 vercel이라는 서비스를 사용해 배포와 배포 자동화를 경험해 볼 수 있었다. 
 
 
api 테스트에서 모든 걸 다 이루었다고 했지만 당연히 아쉬운 점들도 많다. 상태 유지에 대해 깊이 학습할 절대적인 시간이 부족했다. 사실 스택오버플로우 정도의 게시판을 구현하는 수준에서 상태 관리 라이브러리의 필요성을 크게 느끼지 못했다. 보일러 플레이트 코드가 더 많아질 게 분명해서 props drilling 1~2회와 useContext로 상태를 여기저기서 끌어다 쓰는 방식으로 선방할 수 있었다. 그래도 시간이 조금 더 있었다면 굳이 필요가 없더라도 경험 차원에서 상태 관리 툴을 써봤으면 좋았을 텐데 못 써 본 아쉬움이 있다. 
 
구글 소셜 로그인 oauth를 어설프게나마 구현해보았다. refresh token까지는 사용을 못 해서 반쪽짜리이긴 했지만 말이다. 그리고 결과적으로 빨간 딱지 때문에 최종 배포 환경에서는 구글 소셜 로그인 기능이 막혔다. 최종 과제 제출일 당일이었나 하루 전인가 로컬에서 구글 로그인이 성공해 기념으로 스크린샷을 찍은 걸로 만족해야 했다. 
 

 
이외에도 전체 목록 페이지에서 상세 보기 페이지에 진입하거나 뒤로 가기 등으로 나올 때 스크롤이 제일 상단으로 가지 않는 문제, 불필요한 리렌더링 방어 등 디테일한 부분의 구현을 미처 다 잡지 못했다. 사전 프로젝트 마감 다음날부터 바로 메인 프로젝트에 진입해서 정신없는 일주일을 보낸지라 아직 이에 대한 부분들을 찾아보지도 못했다. 아마 같은 문제를 메인 프로젝트 때 또 만날 것만 같다...😇
 
 
사전 프로젝트를 하면서 제한된 시간 안에 주어진 리소스를 가지고 가능한 것과 가능하지 않은 것을 판단해 업무의 우선순위를 정해 실행해 나가는 경험이 귀중한 자산이 되었다. 사전 프로젝트의 경험을 바탕으로 직접 서비스 기획과 설계부터 시작해서 구현과 배포까지 하는 메인 프로젝트는 더욱 재미가 있다...! 이에 대한 이야기는 또 언제 쓸 수 있을런지, 사전 프로젝트 때 차곡차곡 모아둔 에러 보따리도 조금씩 풀어볼 수 있기를 희망한다.