1. 백엔드 파트로 참여하게 된 계기
프론트엔드 개발을 배우면서 나에게 백엔드란.. 언젠가 하겠지만 아직은 때가 아닌 존재였다. 하지만 문득 그 때는 언제일까? 라는 생각이 들었고 미루지말고 부딪혀보자는 생각에 백엔드를 경험해보게 되었다.
이번 프로젝트는 2주 동안 진행하는 프로젝트였는데, 규모가 작았기 때문에 백엔드를 도전해 볼 용기가 생겼던 것 같다. 이제와서 생각해보니 개발의 전체적인 흐름을 이해하는데 큰 도움이 되었고, 뜻깊은 경험이었다고 말할 수 있겠다.
2. 파트 분배 & 서비스 기획
우리 팀은 운이 좋게도 프론트엔드, 백엔드를 희망하고 있는 사람들이 반반씩 모여서 각자 하고 싶은 파트를 맡을 수 있게 되었다. 🍀
프로젝트를 시작하기 전에 서비스 기획을 진행했다. 프로젝트 기간이 짧다보니 최소한의 기능을 구현하고, 시간적 여유가 있으면 추가적으로 기능구현을 하는 것으로 하여 필수기능과 추가기능을 구분했다. 해당 내용을 바탕으로 와이어프레임을 작성한 후 프론트엔드는 피그마, 백엔드는 db 스키마를 각각 맡아서 작성했다.
우리팀은 와인을 판매하는 쇼핑몰을 만들기로 했는데, 평소에 와인을 즐기고 온라인으로 와인을 편하게 구매하고 싶은 사람들을 타겟으로 선정했다.
3. 역할 분배
팀 역할 : 매일 진행하는 스크럼은 팀원끼리 돌아가면서 회의록을 작성한 후 노션에 업로드하기로 했다.
파트별 역할 : 백엔드는 3명이기 때문에 크게 유저/상품/주문으로 나눴고 나는 유저쪽을 담당하게 됐다. 각자 맡은 부분의 Schema 및 Modeling, api 개발까지 하는 것으로 정했다.
4. 개발 내용
기억을 더듬어보니 아래 순서대로 작업을 했다.
- 각 파트에서 사용할 데이터 형식을 정의하는 Schema 파일을 작성했다.
- 작성한 Schema를 import하고, 모델링을 했다.
- user 관련 기능의 로직을 Service 파일에 작성했다.
- Route 파일은 Service에서 정의한 함수를 사용하여 서버에서 필요한 값을 가져오고, 수정하고, 저장하거나, 삭제한다.
- 잘못된 요청이 들어오면 서버에서 에러를 발생시켜야 하는데, 이를 위해 Middleware를 작성하여 에러를 핸들링했다.
- PostMan을 이용하여 CRUD 기능이 잘 동작하는 것을 확인할 수 있었다.
- API 명세서를 작성해서 프론트 분들께 전달했다.
5. 프론트-백 통신
마지막 날에 user 쪽 프론트엔드를 담당하시는 분과 연결하는 작업을 했는데, 너무나 당연하게도 ㅎ 에러가 발생했다. 그 중 제일 바보같았던 실수는 데이터를 조회하는 부분에서 userInfo.data 객체에 name, email 같은 속성들이 있는데, 여기서 userInfo 객체에 직접적으로 name과 같은 속성을 찾으려고 시도했다. Cannot read properties of null (reading 'data') 이라는 에러가 떴고, API명세서를 자세히 보니 data안에 해당 값들이 들어있어 있는 구조라서 그냥 name으로 찾으면 null값이 뜨고 data.name으로 입력했어야 정상적으로 조회할 수 있었다. 내가 쓴 API 명세서인데도 왜 헷갈렸지.. 통신하는 과정에서 API명세서의 중요성을 깨달았다. 프론트에 전달만 하고 끝이 아니라 나도 꼼꼼히 봐야하고, 잘못 작성된 게 있으면 바로 알아차려야 한다.
6. 후기
프로젝트 폴더 구조를 어떻게 만들어야 좋을지에 대한 고민을 오래했던것 같다. 프로젝트 기간 중 1/4 이상은 폴더 구조로 고민을 많이했던 것 같은데, 정답은 없고 개발자마다 스타일이 다르다는 것이 결론. 이렇게 저렇게 다양한 경험을 쌓으며 어떤 방법이 좋은지 알아보는게 앞으로의 숙제일 것 같다.
백엔드는 프론트엔드와 다르게 개발하는 동안 서비스 화면을 볼 수 없다. 그래서 잘 하고 있는게 맞는지 답답할 때도 있었지만 포스트맨이라는 구세주가 있어서 그래도 재미있게 개발할 수 있었던 것 같다. 또, crud 하는 것도 DB에서 직접 확인할 수 있어서 신기했다.
이번에 기술스택은 node.js와 mongoose, mongoDB를 사용했다. NoSQL이라 찐 백엔드를 경험했다고 하긴 어렵지만, 다음엔 SQL로 백엔드를 도전해 볼 것이다. 아자아자✨
