DOing
Spring ShoppingMall 팀프로젝트 회고 본문
약 4달간 진행해온 Spring 팀 프로젝트를 마치고 있습니다.
그에 대한 회고를 해보려고 합니다.
[ 계기 ]
웹 개발로 진로를 정하고 가장 먼저 했던 고민은 '그래서 무슨 언어를 선택하지?' 였습니다. 이에 대한 답은 대학시절 가장 많이 좋아했던 Java였습니다. 재학생 시절 c, c++, java, python, (약간의 js)를 모두 배우는 동안 가장 매력을 느꼈던것은 java를 앞으로 더 사용해보고 싶었습니다.
그 다음은 사용할 프레임워크를 선택하고자 하였습니다. 자바의 대표적인 프레임워크는 'Spring Framework'입니다. 요즘에는 스프링 부트도 많이 사용하는 추세이고, 초보자들은 스프링 부트로 시작하는 것이 편하다라는 말을 많이 듣고 스프링부트를 시작하였습니다. 하지만 처음 인프런의 스프링부트 강의를 듣다보니 이해가 되지 않는 부분이 너무 많았습니다. JPA, thymeleaf, gradle, 내장된 톰캣, 자동화된 설정은 스프링부트의 장점이라지만 어느 하나 이해가 되질않았습니다.
'내장화된 톰캣이 왜 좋다는 것인가?? 대체 무슨 설정을 자동화해준다는 것이지??'
우선 기초에 충실해야겠다는 생각이 들어 스프링부트 공부를 잠시 접어두고 스프링 공부를 하기로 결심하였습니다.
[ 학습 과정 ]
1. Spring 스터디
대학생 커뮤니티 '캠퍼스픽'에서 모집하고 있는 'Spring 스터디'에 들어가게 되었습니다. 혼자 공부하는 것이 아닌 스터디를 선택한 것에는 두가지 이유가 있었습니다. 첫번째는 적절한 동기부여, 두번째는 향후 팀프로젝트 가능성이였습니다.
매주 1회, '코드로 배우는 스프링 웹프로젝트'의 지정된 파트까지 공부해오고 이를 바탕으로 스터디를 진행하였습니다.
4명이서 2020.8 ~ 2020.11 약 4달간 진행하였습니다. 760쪽 가량의 두꺼운 책 분량과 다들 학기 수업과 병행했기 때문에 오래 걸렸던 것 같습니다. 이 기간동안 Maven이 무엇인지, MyBatis가 무엇인지, JSP가 무엇인지 실습을 통해 서서히 깨달아갔습니다.
Github : https://github.com/mangdo/SpringBoard
(리드미를 통해 자세한 설명&코드를 확인할 수 있습니다.)
2. 팀 프로젝트 계획
책의 실습이 모두 끝이 나고, 같이 스터디를 하던 팀원들과 프로젝트를 계획하기 시작하였습니다. 아이디어 구상시간보다는 실제 구현하는 것에 시간을 쓰고 싶었기 때문에 게시판에서 조금 더 발전한 쇼핑몰을 만들자는 의견으로 통일하였습니다.
그 다음에는 프로젝트의 환경을 정하였습니다. 저를 제외한 팀원들은 모두 MySQL을 사용해오고 있었습니다. 저는 Oracle을 사용하다가 MySQL로 DB를 바꾸는 것이 걱정되기도 했지만 이참에 다양한 DB를 이용해보자!라는 생각해 MySQL을 사용하는 것에 찬성하였습니다. 진행하던 스터디가 Spring 스터디였기 때문인지 팀원들은 모두 백엔드를 희망했습니다. 때문에 프론트에 시간을 쓰기보다는 백엔드에 집중을 하자는 판단에 프론트는 부트스트랩 템플릿을 수정하여 사용하기로 의견을 통일하였습니다.
[ 어려웠던 점 & 배운 점 ]
1. Git을 통한 협업
협업 과정은 git을 통해 이루어졌습니다.
저의 github계정에 Repository를 만들고 다른 팀원을 Collaborator로 초대하여 협업을 시작하였습니다. 주요 기능마다 브랜치를 만들어 작업하고 구현을 완료하면 push한다음, 팀원과 확인작업이 끝나면 main브랜치와 merge하였습니다.
최대한 충돌을 일어나지 않도록 역할을 분담했지만 그럼에도 한두개의 파일에서 충돌이 일어났습니다. git에서 대부분의 충돌은 자동으로 해결해주지만, 그렇지 않은 충돌의 경우에는 직접 파일을 확인하고 고쳐야했습니다. 이를 통해 이클립스에서 충돌을 해결하는 방법을 배웠습니다.
2. SQL의 중요성
프로젝트의 규모가 커지게 되면서 SQL도 복잡해져 갔습니다. 예를 들어 공지의 내용, 공지의 그림과 더불어 이전 공지나 다음 공지가 있다면 함께 조회해야하기도 했습니다. 때로는 여러 테이블을 함께 조회해야했습니다. 예를 들면 MyReviews에서는 리뷰 내용, 제품 정보, 제품 이미지 정보, 관리자의 답글이 있다면 답글의 내용까지도 가지고 왔어야했습니다. 또 리뷰를 너무 많이 들고오면 안되니 페이징까지 고려해야했습니다.
이를 통해 Java 언어뿐만 아니라 SQL 작성능력의 중요성을 깨달았습니다. 구글링을 통해 당장의 문제를 해결할 수도 있었지만, 기본 원리를 이해하고 사용하고자 했습니다. 이에 저는 전문가 가이드 서적을 구매하여 설계부터 다시 공부하였습니다. 적절한 동기부여를 위해 SQL 개발자(SQLD) 자격증에도 도전하였습니다. 그 결과로 92점이라는 높은 성적으로 SQLD 자격증을 취득할 수 있었으며 진행하던 프로젝트의 복잡한 SQL쿼리들도 모두 작성할 수 있었습니다.
3. UI/UX를 고려한 프론트엔드
백엔드에 집중하기위해 프론트는 부트스트랩 템플릿을 사용했습니다. 하지만, 템플릿에는 없는 페이지인 MyReviews, MyPurchase, Register, Login 등 다양한 페이지가 필요했습니다. 뿐만아니라 기존의 페이지들은 현 프로젝트에 맞춰서 변경해야 했습니다.
이를 위해 개발자 도구를 열고 기존 페이지의 html, css, js들을 분석하여 수정하였습니다. 새로 만든 페이지가 기존과 다른 디자인을 가지게 되면 UX가 나빠질 수 있다 생각하여 최대한 비슷한 디자인을 유지하려했습니다. 이를 위해서는 역시 기존 페이지의 html, css, js파일들을 이해하고 활용하는 과정이 필요했습니다.
MyReviews와 MyPurchase의 경우에는 리뷰를 중요하게 생각하는 사이트인 네이버쇼핑과 배달의 민족, 무신사의 리뷰페이지를 참고하며 디자인 하였습니다. 여러 사이트의 리뷰 관리를 조사하다보니 대부분의 사이트에서 리뷰에 (수정됨)을 표시하고 있는 것을 깨달았습니다. 실제로 리뷰의 수정 기능을 악용한 사례들이 있었기 때문에 추가된 기능이라는 것을 알게 되었고 이를 현 프로젝트 내에도 적용시켰습니다.
이러한 과정을 통해서 html, css, js, bootstrap에 대한 이해를 키웠으며 UI/UX를 고려한 웹 프론트엔드를 구현하였습니다.
4. Spring 이해
스터디에서 기존의 책을 읽고 따라 실습할때 보다 Spring에 대한 이해가 늘었습니다. 프로젝트 초반에는 책의 패턴 그대로 사용했다면 중반부터는 더 맞다고 생각하는 패턴으로 고쳐나갔습니다.
책에서는 "두개 이상의 의존성 주입을 할때는 생성자 주입이 아닌 Setter주입으로 바꿔라"라고 나와있었습니다. 때문에 프로젝트 초반에서는 Setter주입으로 사용하고 있었습니다. 하지만 의존성 주입에 대해 점점 공부를 해가며 이 구절에 의문이 가기 시작했고 저자분에게 질문을 올렸습니다. 저자분은 @RequiredArgsConstructor와 @AllArgsConstructor을 같이 사용할때 문제가 생기니 Setter주입으로 변경했다라는 답변을 주셨습니다.
여러 차례 생각해보았을 때 저는 차라리 @RequiredArgsConstructor와 @AllArgsConstructor을 같이 쓰지 않는 대신, 생성자 주입을 하는 것이 맞다고 판단이 들어 프로젝트의 의존성 주입 방식을 변경하였습니다. 이렇게 Spring의 동작방식에 대해 고민을 해가며 코드를 수정하였습니다. 이 과정에서 Spring 동작방식에 관한 이해가 늘었다고 생각합니다.
관련 포스팅 :
5. REST 적용
제품의 QuickView, 좋아요, 댓글, 답글 기능들은 한 사이트의 여러 페이지에서 사용합니다. 또한 한 페이지 내에서도 여러번 발생하는 요청들입니다. 예를 들어 제품의 QuickView는 사용자들이 빠르게 제품에 대해 정보를 습득할 수 있는 기능입니다. 만약 이때 페이지 이동을 하게 된다면, 사용자들은 불편을 겪을 것입니다. 그렇다고 해서 제품의 모든 정보(간략한 소개, 색상, 카카오톡 공유하기에 이용되어야할 정보들)을 모두 미리 가져올 수는 없습니다.
이때 제가 사용한 것이 REST방식입니다. JSON데이터만 주고 받기 때문에 페이지 이동없이 고속으로 화면 전환이 가능합니다. 서버에서는 주고받는 데이터 양을 줄일 수 있고 사용자들은 빠른 응답을 받을 수 있어 좋은 사용감을 받을 수 있을 것이라 생각하여 REST를 적용하였습니다. 이 과정을 통해 REST방식에 대한 이해와 JQuery의 Ajax통신에 대해 배울 수 있었습니다.
6. 배포 경험
AWS EC2(Amazon Linux 2), AWS RDS(MySQL), AWS S3를 사용하여 실제 배포까지 진행하였습니다.
기존 프로젝트에서는 이미지를 로컬 서버에 저장했지만 이를 AWS 파일서버인 S3에 저장하기 위해서는 기존 프로젝트 코드에 변경이 필요했으며, 배포를 위한 기본적인 네트워크에 대한 이해가 필요했습니다. 이는 배운점이 많았기 때문에 따로 포스팅을 만들었습니다.
2021.05.08 - [AWS] - [AWS] AWS 배포 회고
[AWS] AWS 배포 회고
최근에 AWS를 이용해서 총 두개의 프로젝트를 배포해보게 되었습니다. 그에 대한 회고를 해보려고 합니다. [ 계기 ] 꽤 오랫동안 진행해왔던 Spring 프로젝트를 마무리 지어가고 있었습니다. 워낙
doing7.tistory.com
[ 아쉬운 점 ]
1. 코드 리뷰
이전 Django 팀프로젝트에서는 팀계정을 만들어서 pull-request과정을 거치며 협업을 했지만, 이번 팀원들은 모두 생소하게 받아드렸었습니다. 그래서 팀계정과 pull-request과 무엇이고 그 장점이 뭐냐고 물어봤지만 저는 팀계정밖에 사용해보지 못했고 pull-request과정으로 밖에 merge를 시킨적이 없었기때문에 그에 대한 답을 하지 못했습니다.
때문에 이번 팀프로젝트 협업에서는 저의 github계정에 Repository를 만들고 다른 팀원을 Collaborator로 초대하여 협업을 시작하였습니다. 주요 기능마다 브랜치를 만들어 작업하고 구현을 완료하면 push한다음, 팀원과 확인작업이 끝나면 main브랜치와 merge하였습니다.
지금 제가 생각하기에 pull-request의 장점은 코드리뷰를 편하게 할 수 있다는 것이라고 생각합니다. 사실 이번 프로젝트에서는 코드 리뷰를 거의 하지못했었습니다. 코로나때문에 오프라인이 아닌 온라인으로만 진행하였었는데 오프라인으로 대화를 나누려다보니 더 조심스러워졌던 것 같습니다. 제 입장에서는 정말 코드를 왜 이런 방식으로 짰는지 궁금해서 물어보는 것인데 시비처럼 들리지 않을까, 또 나 역시도 Spring에 대해 잘 알지 못하는데 괜히 나서는 것이 아닐까, 지금 당장 문제가 생기는 것은 아니니 일단 그냥 둬야겠다, 라는 생각을 했습니다.
때문에 정말 기능 구현에 문제가 있을때만 서로 피드백을 주고 받았었습니다. 지금 생각해보면 오프라인 모임이 안됬었다면 줌을 통해서라도 서로 원활한 커뮤니케이션을 위해 노력했으면 좋았을 텐데라는 아쉬움이 남습니다. 활발하게 의견을 주고받는 분위기가 형성되었더라면 pull request를 도입하고, 코드리뷰를 통해 서로 더 많이 발전할 수 있지 않았을까라는 아쉬움이 남습니다.
2. 테스트의 중요성
사실 테스트를 왜 하는지 이해를 못했습니다. 중요하다고는 여러번 들었지만 이에 대해 공감하지 못했었습니다. 실제 코드를 작성하는 시간보다 테스트 코드를 짜는 시간이 오래걸렸기 때문에 비효율적이라는 생각이 들었기때문입니다.
테스트가 가끔 필요할때도 테스트를 만들어서 사용하고 기능이 잘 동작하면 테스트 코드를 빼고 push를 했습니다. 이제 기능이 다 잘 동작하니까 내가 만들때 사용한 테스트 코드는 다른 팀원이나 미래의 나에게 필요가 없을 것이라 생각에 테스트 코드를 push하지 않았습니다.
하지만 프로젝트가 규모가 커지면서 되던 기능이 안되는 현상이 일어났습니다. 그제서야 저는 테스트의 중요성을 깨달았습니다. 시간이 오래 걸리더라도 테스트를 작성하였다면 좋았을 텐데라는 아쉬움이 남습니다. 다음 프로젝트부터는 테스트를 작성하는 습관을 들이도록 노력하겠다는 생각을 하였습니다.
3. dto, domain의 이해
[ 마치며 ]
"팀플은 가까이서보면 손해같지만, 멀리보면 무조건 이득이다."
이것이 제가 여러 팀플을 겪으며 깨달았던 점이였습니다. 팀원과 나의 의견을 다를 수 밖에 없습니다. 나와 너무 다른 의견을 맞추려할때면 오히려 돌아가는 기분이 들때도 있습니다. 솔직하게 말해서 저 혼자 일을 다하는 것같은 기분이 들때도 있었습니다. 전공도 다르고, 실력도 다르고, 팀에 기여정도도 모두 다른 팀원들은 다양한 아이디어, 피드백을 던져주는 경우가 많습니다. 이를 흘려듣느냐, 이해하고 반영할 수 있느냐는 개인의 능력이라고 생각합니다. 팀프로젝트를 반복하며 가장 크게 배우는 것은 이러한 능력이라고 생각합니다.
이번 프로젝트에서도 저는 생각치도 못한 아이디어를 다른 팀원이 제안해주고, 같이 열심히 고민하는 팀원이 있었기때문에 4개월이라는 장기간동안 프로젝트를 포기하지않고 진행할 수 있었다고 생각합니다. 혼자 작업을 하며 지치고 의욕이 떨어질때마다 팀원의 피드백 덕분에 동기부여를 받을 수 있었고, 프로젝트를 진행동안 많은 것을 배울 수 있어 감사했습니다.
'Spring' 카테고리의 다른 글
| [Spring] Spring Framework의 정의와 목적 (0) | 2021.05.29 |
|---|---|
| Domain, Entity, Value(Object) (3) | 2021.05.27 |
| [Maven] Maven에 대해 알고 사용해보자 (0) | 2021.05.08 |
| [Spring Security] UserDetailsService를 이용한 인증 (0) | 2021.04.28 |
| [Spring Security] DB를 이용하여 로그인 (0) | 2021.04.28 |
