멀티캠퍼스 프로젝트 회고록
팀명
왜 이게 되지
프로젝트명
Join Now(Joinow)
프로젝트 기간
10.4.2023 ~ 11.13.2023
프로젝트 아이디어
프로젝트 팀 매칭 웹 서비스
개발 도구
Front-end : HTML, CSS(+ Bootstrap), JS, Jquery
Back-end : Java 1.8, Spring Framework, Spring Boot, Spring Security, MyBatis, JPA
Database : MySQL(+ Workbench)
Design : Figma
이번에 진행한 프로젝트를 한마디로 말하자면
힘들었던 만큼, 날 성장시켜 준 프로젝트
멀티캠퍼스 백엔드 과정을 통해 새롭지 않았지만 처음과 같은 심정으로 임하게 됐던 자바부터 시작해서 Spring Framework, Spring boot, Mybatis 등 처음 배운 내용을 바탕으로 첫 웹 프로젝트를 진행했다.
이 프로젝트는 기획에서부터 어렵게 다가왔다. 하나의 아이디어를 정하고 그 아이디어에서 어떤 요소들을 파악해야 하는지부터 난관에 봉착했었다. 이 문제는 멘토링을 받으면서 멘토분들이 기능에 대한 내용이 필요하다고 조언해 주셔서 기능에 대한 회의를 논의했다.
기능에 대한 내용은 우선 메인기능과 서브기능으로 나뉜다. 메인 기능은 구현하고자 하는 웹 서비스에서 필요한 기능들을 의미하고 서브 기능은 메인 기능을 제외한 나머지 기능을 의미한다. 이 개념을 바탕으로 메인 기능과 서브 기능을 나눴고, 개발은 메인 기능을 우선적으로 하는 방향으로 정하고 개발을 시작했다.
역할 분담은 각 페이지를 랜덤으로 담당을 지정해서 진행하되, 작업이 우선적으로 끝난 팀원은 다른 페이지 작업을 보조해주는 방식으로 유동적으로 진행했다. 내가 맡았던 부분은 팀 페이지였다. 팀 페이지는 프로젝트 진행을 위해 프로젝트에 대한 정보, 팀원 간의 일정을 기록하고, 회의한 내용을 기록할 수 있는 회의록, 팀원 관리를 담은 페이지이다. 이 파트를 개발하면 정말 많은 부분에서 막막했던 것들을 나열하고자 한다.
1. 도통 뭐가 뭔지 알 수 없는 UI 작업
UI 작업을 위해 figma로 목업을 생성해두었고, 목업으로 설계된 내용 그대로 UI 개발을 진행하니 front-end 영역이었던 부분에서 초반에 많은 시간을 빼앗겼다. 사실 우리 팀은 bootstrap 템플릿을 사용하자는 의견과 함께 사용할 템플릿을 정하고 개발을 시작했다. 하지만 bootstrap 템플릿 적용이 생각보다 쉽지 않았다.
bootstrap은 클래스에 따라서 css 디자인이 설정되어 있어서 class만 입력해 주면 css와 js 모두 효과를 가져온다. css와 js를 디자인적으로 다루지 못하는 우리 팀에게 효율적으로 개발할 수 있을 것이라고 생각했는데 이 부분이 단점으로 작용했다.
class에 들어가는 값이 어떤 것이 있고, 그 값은 어떤 효과가 적용되어 있는지 모르면 적용이 어려웠다는 점이었다. 처음이어서 익숙하지 않던 우리 팀 모두 UI에서 개발이 지연된다고 판단 돼서 UI를 과감히 포기하고 백엔드 파트 기능 개발에 돌입하게 된다.(이리 정하고 나중에 프로젝트 발표 7주일부터 해서 모든 UI를 bootstrap 템플릿으로 변경 작업을 진행했다... 솔직히 다 완성 못할지도 모르겠다는 생각도 했는데 우리 팀은 깔끔한 시연영상까지 완벽히 해냈다.)
2. @PathVariable VS @RequestParam 누가 좋은 건데?
이 두 개 중에 좋은 건 없다. 어떤 상황에서 기능을 구현할지에 따라 구현 방식이 달라질 뿐이다. 이 내용은 따로 정리할 예정이지만 간략하게 이 두개를 설명하자면,
@PathVariable
URI에서 구분자를 통해 값을 전달 받는 방식. 아래 예시에 pageNo에 1의 값이 들어가게 된다.
ex) http:localhost:8080/app/main/1 | GetMapping("/main/{pageNo}")
@RequestParam
URL에서 파라미터의 값과 이름을 함께 전달하는 방식.
ex) http:localhost:8080/app/main?type=post. | GetMapping("/main")
아무것도 모르고 Rest API 방식처럼 구현해보고 싶다는 생각에 @PathVariable로 작업했고, 작업한 이후에 이 두 개의 사용 방식에 대해서 알게 되었다.
3. 데이터베이스 설계
데이터베이스 설계 단계에서 엔터티와 애트리뷰트, 관계를 정의하는 것에서 어떻게 정의를 내려야 할지 의문이었다. 기본적으로 필요했던 것은 회원에 대한 정보를 위해 유저 정보가 필요했고, 모집 공고를 생성을 위해 공고에 대한 정보가 필요했고, 팀에 대한 정보가 필요했다. 이렇게 나눴지만, 이렇게 정의를 해놓는 게 맞는 걸까. 테이블을 분리해야 하지 않을까 해서 정규화를 찾아보게 되었다. 정규화를 적용해 보고서 어느 정도 데이터베이스 설계의 윤곽이 잡히기 시작했고 개발 진행에 차질 없이 진행되었다.
이외에도 여러 어려운 일들이 있었지만, 팀원들과 소통해 나가면서 문제를 방치하지 않고 해결해 나가면서 프로젝트도 만족스러운 결과로 완성되었고, 발표도 잘 마무리하게 되었다.
이제는 취업준비하면서 개인 프로젝트를 진행하려고 한다. 우선 깃허브를 돌아보면서 흥미로운 주제를 선정하고 그에 대해 구현해나 가볼까 한다.