23년 4월 21일

배운 것과 알게 된 점

이날은 마지막으로 수정할 부분 수정해주었고, 크게 우리가 뭔가 한 거는 많이 없었다.
다만 몇가지 테스트 중에 피드 api 부분에서 잘못된 부분이 있어서 수정되었다. 그리고 마이페이지에서도 shopId가 필요하다고 하셔서 추가하는 단순한 작업만 진행하였다.
은 모두 다 마무리 되어서, 이제 남는것은 프론트 분들이 배포 하는 것만 남아 있는 상태이다.
그리고 저녁먹고 와보니 내일 발표 하고 나서 각 팀마다 예상 질문이 3가지가 나와 있었고 우리팀의 질문은 다음과 같았다.

Q1. jsonwebtoken을 사용하는 것과 세션을 사용해 관리하는 방식은 어떤 차이가 있을까요?
Q2. redux 등과 같은 라이브러리는 어떤 때에 활용하는 것이 좋을까요?
Q3. 프론트엔드에서 화면을 렌더링하는 과정에서 메모이제이션을 사용하면서 얻을 수 있는 이점이 있을까요? 또, 단점에 대해서도 설명해 주세요.

여기서 우리 백앤드에서는 Q1만 해당되고, Q2와 Q3은 프론트 질문이라 우리는 Q1 질문에 답변을 미리 한번 작성해보는 시간을 가졌다. 그래서 우리 백앤드에서는 간단하게 이렇게 작성을 하였다.

A : 저희 백앤드에서는 소셜 로그인 기능을 구현할 때, jsonwebtoken을 사용하여 인증 처리를 하였습니다.
이는 JWT 토큰을 이용한 인증 방식이 세션 기반 인증보다 서버 부하가 적고, 확장성이 높기 때문입니다.
JWT 토큰은 클라이언트 측에서 발급받으며, 서버에서는 검증만 하면 되므로, 서버 부하가 감소하고,
클라이언트 측에서도 토큰을 보관하고 있기 때문에 상태를 관리하는 세션과 달리 서버에서 클라이언트의 상태를 관리하지 않아도 되는 장점이 있습니다.
또한, JWT 토큰은 토큰의 만료 기간을 설정하여 보안성을 높일 수 있습니다. 따라서, 저희 백앤드에서는 JWT 토큰을 이용해서 소셜 로그인을 구현하게 되었습니다.

뭔가 조금 어설프긴 하지만 그래도 최대한 요약해서 말한 것이고, 아마 이 기본 3가지 질문 외에도 추가 예상 질문들이 온다면 이정도인데 추가적으로 질문에 대한 답변을 한다면 다음과 같았다.

Q4. 다른 사진 업로드 라이브러리 중 multer를 사용한 이유
A : multer는 가장 많이 사용되는 파일 업로드 미들웨어 중 하나이고,
Express와 함께 사용하기 쉬우며, 다양한 옵션을 제공하여 파일 업로드 구현에 용이하다는 장점이 있습니다.
또한, 우리 팀은 단순히 사진 한 장이나 여러 장을 업로드하는 기능만을 구현해야 했기 때문에,
더 복잡한 기능을 제공하는 다른 라이브러리보다 더 간편하고 빠르게 구현할 수 있는 multer를 선택했습니다.
따라서 우리 프로젝트의 요구사항에 가장 적합한 라이브러리인 multer를 사용하게 되었습니다.

Q5. NOSQL과 RDBMS중 왜 RDBMS를 사용했고 그 중 왜 MySQL, Sequelize를 사용한 이유
A : 저희가 RDBMS를 사용한 이유는 우선 저희 프로젝트에서
어떠한 데이터를 삭제할때 참조하는 데이터도 연쇄적으로 쉽게 삭제하기 위해서 관리 하기 위해서 사용 하였고,
각 테이블마다 데이터의 일관성과 무결성을 보장하고, 유연한 데이터 구조를 유지 할 수 있으면서, 쿼리의 성능을 최적화하기 좋아서 사용했습니다.
또한 Sequelize ORM의 사용으로 데이터베이스 조작을 더욱 편리하게 할 수 있고,
무엇보다도 소셜 로그인과 어드민 로그인 통해서 유저들을 관리를 하고
3천개가 넘는 카페들을 관리해서 그걸 통해서 피드나 스크랩, 메뉴 등 연관관계가 대해서 관계 설정에 유용하기 때문에 저희 백앤드에서는 MYSQL를 사용하게 되었습니다.

Q6. 3계층 분리 장단점
A : 첫째, 코드의 가독성과 유지보수성이 좋아집니다. 라우터에 API를 모두 적는다면 코드가 길어지고 복잡해지기 때문에, 코드를 이해하고 유지보수하기 어렵습니다.
반면에 3계층 분리를 하면 각 계층별로 책임이 명확하게 분리되므로 코드를 이해하기 쉬워집니다.
둘째, 코드 재사용성이 좋아집니다. 컨트롤러, 서비스, 레파지토리 계층으로 분리하여 코드를 작성하면, 비즈니스 로직과 데이터베이스 로직을 분리할 수 있습니다.
이렇게 분리하면, 비즈니스 로직이 변경되더라도 데이터베이스 로직을 수정하지 않아도 되므로 코드 재사용성이 좋아집니다.
셋째, 유닛 테스트가 용이해집니다. 각 계층이 명확하게 분리되어 있기 때문에, 각 계층별로 유닛 테스트를 수행할 수 있습니다.
이렇게 하면, 각 계층의 동작이 예상대로 동작하는지 확인할 수 있으므로 코드의 신뢰성을 높일 수 있습니다.
반대로 단점이면 첫째로, 기존보다 코드량이 증가한다는 점입니다.
컨트롤러, 서비스, 레파지토리 세 개의 계층으로 코드를 분리하다 보면 각 계층마다 파일이 추가되고 코드의 중복도 증가할 수 있습니다.
둘째로, 프로젝트의 규모가 작고 단순할 경우에는 3계층 구조를 구현하는 것이 비효율적일 수 있습니다. 이 경우에는 오히려 코드의 가독성이 떨어질 수 있습니다.
셋째로, 계층 간의 의존성이 높아지게 되는데, 이는 수정이나 유지보수를 어렵게 만들 수 있습니다. 한 계층의 수정이 다른 계층에 영향을 미칠 가능성이 높아지기 때문입니다.

이 외에도 추가적인 질문들이 있겠지만 내일 발표는 프론트 팀장님이 진행하기로 결정하였다. 이제 남는 시간은 프론트분들이 배포하는 것을 기다리는것으로 오늘 일정은 의외로 빨리 마무리 하였다.
아마 밤늦게까지 프론트쪽에서도 테스트 하고 배포 준비 중이신것 같기에 오늘 배포 마무리 되면 배포된 홈페이지에서도 잘 작동하는지 테스트 할 계획이다.

앞으로 할 일

내일은 대망의 중간 발표 하는 날이다. 중간 발표에서 시니어 멘토님의 조언이나 앞으로 계획 방안을 알려주는데 내가 백앤드에서 서기를 맡았기에 백앤드에서 말한 것들을 기록하는 것을 가지고 앞으로 어떻게 진행할지 의논 할 것 같다.