코드스테이츠에서의 첫 프로젝트가 끝이났다...😭
내일부터 4주프로젝트가 시작되기때문에
시작되기전에 2주간 느낀 모든것들을 기록하고 싶어서 급하게 블로그를 켰다.
아... (회상)
개발을 배우고 나서 처음 진행한 프로젝트였고,
처음 함께한 팀프로젝트였기 때문에 모든것들이 새로웠고,
정말 많은 걸 배우고 많은 걸 느낀 프로젝트였다.
SR(Subject Research)
👨🏻💻 팀결성!
코드스테이츠과정을 시작하면서 3주쯤이었나?
그때 페어분의 권유로 한 알고리즘스터디에 함께하게되었다.
당시에는 '이렇게 따로 시간을 투자해도 괜찮을까? 지금 하는내용에 집중하는게 맞지 않을까?'라는 생각으로 스터디에 참여하는걸 고민했었던 기억이난다.
그때 '에라모르겠다 일단해보자'라는 생각으로 Google Meet에 들어가기 버튼을 누른 나를 매우매우 칭찬해주고싶다.
스터디원들 모두 너무너무 좋은 사람들이었고 너무너무 감사한 사람들이고
이미 나에게는 너무너무 소중한 인연이 되어버린것 같다.
그런 좋은 사람들과 이번 프로젝트를 함께했기에
정말 2주..도아닌 10일? 이라는 짧은 시간안에 많은 것들을 이뤄낼 수 있었다고 생각한다.
💾 Backend...!
나는 프론트엔드 희망자였지만
프로젝트를 들어가기 훨씬 전부터 2주프로젝트는 백엔드, 4주프로젝트는 프론트엔드로 참여하고 싶다는 생각을 갖고있었다.
백엔드를 꼭한번 경험해봐야 프론트엔드로 프로젝트에 들어갔을 때 훨씬 많은것을 배우고 많은것을 느낄 수 있을거라는 확고한 생각을 갖고있었기때문에 포지션을 결정할 때 큰 고민은 없었다.
팀이 결성되고 각자 희망포지션을 정해보니 프론트가 셋, 백이 한명이었다.
백이 한명... 나잖아?
당연히 있을 수 있는일인데 백엔드를 혼자맡게 된다는 생각은 전혀 해보지 않았다.
이때부터 혼자 백엔드를 맡게된다는 어떤 사명감 비슷한 걸 느꼈던 것 같다.
쌓여만 가는 백엔드 자료들..
⚒️ 기술스택
2주 프로젝트에 앞서 우리가 이 2주프로젝트에서 이루고싶은 목표를 설정했다.
그동안 배운 것들로 하나의 완성된 결과물을 만들고, 배포까지 완료했다는 성공경험
4주프로젝트를 위한 연습과정 - Github Issue들을 많이 만나보고, Jira와 같은 tool에 익숙해지기
이를 위해서 모두가 공통적으로 꼭 써보고 싶다고 생각한 TypeScript는 4주차로 미뤄두고
Frontend는 React hooks와 Redux를,
Backend는 서버는 express로 DB는 MongoDB를 중점적으로 사용해보기로 했다.
🖼 Idea & Wireframe
1차적으로 기본적인 CRUD 기능을 구현할 수 있는 커뮤니티페이지를 만들기로 정한 뒤,
팀원들 모두가 관심있는 반려동물이라는 주제 중 고양이를 택하여 고양이 전문 커뮤니티 사이트를 만들기로 의견이 모아졌다.
당시에는 각자가 페이지나 모달창을 디자인해보고 합치는 방향으로 진행했어서
'과연 이대로 잘 만들어 질까..?'라는 생각이 들었었는데
지금보니 오히려 더 잘만들어진 것 같아서 너무뿌듯하다.
🎞 DB Schema
이번프로젝트에서 우리팀에게 가장 도전적인 스택을 꼽으라면 MongoDB라고 말할 수 있을 것 같다.
코드스테이츠에서는 스프린트내내 SQL인 MySQL을 사용해왔고 MongoDB는 이론적으로만 훑고 넘어간 수준이라서
사실 걱정도 많이했었다.
그럼에도 MongoDB를 사용하기로 한 것은,
작은규모의 프로젝트인 만큼 DB를 선택하는데 있어서 자유로웠다는 점과
MERN 스택은 스택간의 궁합이 굉장히 좋다는 얘기를 계속 들어왔었기때문에
이 스택들간의 조합으로 프로젝트를 진행해보고 싶다는 욕심이 있었기 때문이었다.
처음 NoSQL의 Schema를 보고는 매우..음.. 어안이 벙벙했다는 표현이 맞을 것 같다.
SQL의 다대다관계가 복잡히 연결되어있는 Schema를 봐오다가
model, 그러니까 MongoDB의 collection안에 배열이 있고 객체가 있는 것을 보고
"이게 뭐지...?"라며 NoSQL의 Schema에 대해서 마구 찾아봤던 기억이난다.
처음에는 굉장히 낯설게 느껴졌지만 결국 객체형태의 데이터베이스이기때문에
익숙해지는데 그렇게 많은 시간이 들지는 않았던 것 같다.
다만 익숙해지는 것과 사용하는 것은 전혀 별개의 문제였음을 쿼리문을 한줄 치는 순간 알게되었다..
Review
백엔드를 맡아 프로젝트를 진행하면서 어려움을 느낀적이 3번 있었다.
첫번째 어려움은 익숙하지않은 MongoDB를 다루는 것이었고,
두번째는 이미지업로드 기능을 구현하는 것,
세번째는 HTTPS 배포를 진행하는 것이었다.
💪 나에게 MongoDB는 populate를 알기 전과 후로 나뉜다..
우리프로젝트의 가장 핵심기능은 북마크기능이라고 할 수 있다.
커뮤니티글이나 포토페이지글을 좋아요(하트)를 누르면 유저의 북마크에 추가되고,
북마크리스트의 중 하나를 클릭하면 해당글로 이동할 수 있는 기능이었다.
이를 서버에서 데이터로 전송하기 위해서는 DB의 Collection에 참조되어있는 값들을
여러번 이동하며 데이터를 쿼리해야했다.
이런 경우에 정말 유용하고 감사한 것이 Mongoose의 populate메서드였다.
populate를 사용하면 NoSQL인 MongoDB에서도 join과 같은 기능을 간편하게 수행할 수 있었고,
덕분에 이 populate 하나만으로 데이터를 쿼리할때 막혔던 부분들 중 대부분의 상황들을 수월히 해결할 수 있었다.
위의 북마크 API를 구현할때는 하나의 쿼리문에 populate를 3번연달아 쓰면서 나름 수월히(?) 데이터를 추출할 수 있었다.
정말 I LOVE POPULATE 다.
💪 이미지 업로드, multer? S3..?
우리 사이트는 유저의 프로필과 포토페이지 글에 이미지가 들어가야하기 때문에
이미지 업로드기능은 반드시! 구현해야했다.
이미지업로드가 어떻게 진행되는지 공부하면서 서버의 로컬스토리지에 저장하는 방법과 AWS의 S3 버킷에 저장하는 방법이 있다는 걸 알게되었고,
어차피 AWS로 배포할 거 S3에 저장하는 방법을 택하여 적용해보기로 했다.
multer S3라는 새로운 모듈을 배워야했지만 사용방법은 쉽게 찾을 수 있어서 어렵지않게 적용할 수 있었다.
다만 이미지를 폼데이터로 받아오는 것이 문제였다.
처음의 생각으로는 클라이언트에서 폼데이터와 함께 객체형태의 데이터를 함께 받은 다음, 이미지업로드 미들웨어를 하나 추가해서 하나의 API로 본래의 API기능과 이미지업로드 기능을 같이 수행하게 하고싶었다.
그러나 폼데이터는 스트링형식으로 들어오며, 찾아본 바로는 객체를 데이터로 함께 보내려면 객체형태를 하나하나 수정해줘야 했다.
결국 오히려 로직의 복잡도가 늘어난다고 판단했고, 이미지 업로드를 위한 API를 따로 구현하게되었다.
이미지 업로드 기능을 구현하기는 했지만, multer라는 모듈의 사용법만 익힌 느낌이고
폼데이터에 대해서는 아직 모르는 부분이 많다는 생각이 들어서 관련된 공부를 좀더 해볼 생각이다.
💪 HTTPS 배포
프로젝트에 앞서 배포는 정말..자신없는 종목이었다.
관계형데이터베이스를 RDS를 이용해 HTTP 배포를 하는것은 그냥 따라하면 되는 거라서 문제도 아니었지만
몽고DB를 데이터베이스로 두고 HTTPS 배포까지 하려니 AWS 로고만봐도 속이 답답해졌다.
그래도 뭐어쩌겠는가? 할수밖에없는걸...?😭
배포에 대한 이해가 부족했기에, 최대한 빠르게 서버쪽 기능구현을 마무리하고 배포테스트를 진행하고 싶었다.
잠을 좀더 줄이고 매달린 결과 원하는 날짜까지 마무리할 수 있었고 배포테스트를 진행할 수 있었다.
하나부터 열까지 검색해보면서 찾아가고, 배워가고 막히고 다시 검색하고.. 정말 순탄치않았다.
특히 EC2, LoadBalancer의 보안그룹 설정과 CloudFront, Route53 의 상세설정 부분에서 많이 헤맸던 것 같다. 그러나 이렇게 헤매면서 자꾸 찾다보니까 배포라는 과정이 어떠한 flow로 이루어지는지 더 잘 알수 있었던 것 같다.
또한 배포과정에 대한 이해가 부족하다보니, 배포를 끝내고 배포상태를 유지하는데 오히려 더 많은 어려움을 겪었다.
EC2 인스터스의 서버를 업데이트하기 위해, 서버를 껐다 켰을 때 IP주소가 변경된다는 것을 몰라서 이를 다시 연결하는데도 많은 시간을 썼으며,
S3버킷에 빌드한 파일을 업데이트 했는데 업데이트한 내용들이 도메인에 바로 적용되지 않아서 어디가 문제인지 계속 찾아봤고 결국, cloudFront의 Invalidations탭을 이용해 cloudFront의 캐시를 바로 최신화시킬 수 있다는 걸 알 수 있었다.
아래는 내가 배포를 진행하면서 정리한 링크다. 누군가에게 도움이 되었으면 좋겠다. 😁
AWS HTTPS 배포 FLOW
느낀점
나는 프로젝트 회고글들을 정말 많이 읽어봤다.
그들은 내가 겪을 시행착오들을 먼저 겪었을 확률이 높고, 이것들을 미리 안다면 내가 프로젝트를 진행할 때 많은 도움이 될거라는 생각때문이었다.
회고글들을 읽다보면 공통적으로 이야기하는 두가지가 있다.
첫째는 팀원들과의 소통,
두번째는 SR단계의 중요성이다.
정말 진부한 말이지만 나도 진부한 말을 할 수 밖에 없겠다.
🤝 소통
프로젝트에서 소통이라는 건 단순히 서로 이야기를 많이하자! 라는 의미는 아닌 것 같다.
내가 생각하고 느낀 프로젝트에서의 소통은 팀원간의 워크플로우가 면밀히 연결되어 있는 것이다.
가령 서버에서 API를 하나 만든다고 한다면
API를 만들기 전 해당 기능의 데이터흐름에 대해 클라이언트와 상의 -> 기능구현 -> API문서작성 -> 클라이언트에게 설명
위와 같은 작업의 워크플로우를 정하고 철저히 지키는 것이 굉장히 중요하다는 생각을 했다.
아무리 그때그때 소통을 열심히 한다해도 사람인 이상 실수하기 마련이기에,
하나의 루틴으로 내 워크플로우를 고정시키고 이런 팀원간의 워크플로우를 연결시켜 프로젝트를 진행하는 것이 프로젝트에서 소통을 원활하게 하는 방법이라는 생각을 했다.
🌈 SR의 중요성
이번 프로젝트 과정 중 발생했던 가장 큰 이슈는
클라이언트에서의 업무분담이었다.
SR단계에서 페이지별로 업무를 나눠 진행했었는데
프로젝트를 진행하다보니 페이지는 다르지만 겹치는 공통적인 기능들이 있었고
이때문에 페이지는 다르지만 같은기능을 각자 따로 구현하기도 하고
작업의 순서도 제각각이었으며, 누군가에게 업무가 편중되기도 하였다.
결국 이러한 문제를 객관적으로 바라봐준 팀원덕분에
각 페이지의 기능을 다시 살펴보고 업무를 재분배하여 방향성을 다시잡을 수 있었다.
이러한 것들을 SR단계에서 좀더 꼼꼼이 따져봤다면 프로젝트의 완성도를 좀 더 높일 수 있었다는 생각이 들었다.
⛳️ Final Project
대략 10일간 정말 일어나자마자 코드치고, 밥먹고 코드치고, 코드치다가 자고..
꿈에서도 코드가 나와서 이게 잔건지 뭔지 모르겠는 날들의 연속이었다.
많은 시행착오와 어려움들을 겪었지만 이들을 겪으면서 느낀건,
어려워보이는 것도 막상 가까이에서 부딪혀보면 역시 어렵다… 하지만 해볼만은 하다 라는거였다.
이렇게 부딪혀보는 경험들이, 누가 알려줘서 배우는게 아닌 개발자다운 자기주도적학습이라는 걸 제대로 해본 첫 경험이었던 것 같다.
조금은 더 어려웠지만 훨씬 더 짜릿한 성취감을 느낄 수 있는 경험이었다.
이뤄냈을때 너무 재밌었고 개발자라는 직업을 선택한 걸 잘했다고 느낄 수 있었던, 이번 프로젝트에서 얻어낸 정말 소중하고 값진 경험들이었다.
이제 남은건 코드스테이츠의 마지막 과정인 Final Project 뿐이다.
남은 4주간 다시 치열하게 달리겠지만
함께했던 팀원들과 다시 같이하게 될테니 한편으로는 힘이 난다.
이제 다시 프론트 공부하러 가야지...!
'프로젝트' 카테고리의 다른 글
| [프로젝트] DANGO 4주 프로젝트 회고 (2) | 2021.06.12 |
|---|