[해커톤] 프로젝트 회고(1)

2022년 08월 15일

해커톤이란?

해킹(hacking) + 마라톤(marathon)의 합성어로 제한된 시간 동안 아이디어를 도출하고 결과물을 만들어내는 이벤트이다.

멋쟁이 사자처럼 백엔드 스쿨 1기에서는 아이디어톤과 해커톤을 나눠서 진행했다.
아이디어톤에 제출한 나의 아이디어로 팀이 꾸려졌고, 팀장을 맡게 되었다.

프로젝트를 진행하면서 발생한 문제점

아래는 현재 프로젝트 초반에 발생한 문제들이다.

회원 인증 관련 이슈
- Thymeleaf에서 인증된 회원 사용
- Controller에서 인증된 회원 사용
협업 방식 관련 이슈
- git branch 전략 미사용

1. 회원 인증 관련 이슈

Thymeleaf의 애매한 사용

팀장을 맡았지만 막상 개발을 할 생각에 막연했던 나는 이전에 졸업 작품으로 진행한 프로젝트 방식을 채택해 사용하기로 했다. 하지만 해당 프로젝트에는 큰 문제점이 있었는데, 바로 thymeleaf의 fragment를 애매하게 사용했다는 점이다.

졸업 작품을 개발할 당시 Spring Boot와 Thymeleaf에 대한 이해도가 적어 공부를 해볼 생각으로 막연하게 졸업작품 프로젝트로 진행을 했다.

fragments-img

또한, Spring Security를 이용해서 회원 인증 처리는 했지만 인증된 회원 객체를 불러오기 위해 th:sec을 사용하는 것이 아닌 @CurrentUser라는 Security를 이용한 커스텀 어노테이션을 생성해 Controller단에서 Account를 보내주는 방식을 채택한 것이다.

controller-img

header-img

즉, 이 프로젝트의 문제점은 Controller에 있는 모든 Method마다 Account를 Model에 담아 보내줘야하며, 모든 페이지마다 Account를 필수로 보내줘야하는 것이다. 코드의 중복뿐만 아니라, fragment도 가독성도 떨어지고, 여러 Domain에서 1개의 fragment에만 의존해 관심사가 한 fragment에 집중되어 있었다.

어떻게 해결해야할까?

블로그를 찾아보며 Thymeleaf에서 제공하는 layout을 새로 알게되어 이를 이용해 리팩터링을 진행하였다.

1. Fragment를 독립된 파일로 만들기

하나의 파일로 이루어져있던 fragment를 용도에 맞는 파일로 나눠주었다.

layout-fragment-img

2. Thymeleaf Security의 활용

기존에 Controller에서 Model에 담아서 보내주는 것이 아닌 principal을 이용해 현재 인증된 유저의 username을 불러왔다.

<span class="item-title" sec:authentication="principal.username">닉네임</span>

3. 회원 정보가 필요 시 VO 활용

보통 회원 정보가 필요할 경우 해당 Entity를 Model에 담아 View에 보내주었다. 하지만 Entity 자체를 View에 보낼경우 필요하지 않은 정보도 볼 수 있기 때문에 VO를 사용하여 최소한의 필요한 정보만 담아 View에 보내주는 것으로 리팩터링하였다.

@GetMapping("/profile/setting")
public String showProfilePage(Principal principal, Model model) {
    log.info("principal.getName()={}", principal.getName());

    MemberVo member = memberService.getReadOnlyMember(principal.getName());
    model.addAttribute(member);

    return "profile/profile-setting";
}

2. 협업 방식 관련 이슈

앞서 말했던 졸업작품을 개발할 당시에 git branch 전략을 사용하지 않고, 각자 이름으로 된 브랜치를 만들어 기능 개발을 완성하면 master에 PullRequest를 올리는 방식으로 진행했다. 이 때의 문제점은 그래프가 지저분해지며, git log를 분석하기도 어려웠다. 그리고 가장 큰 단점은 이 협업 방식의 흐름이다.

개발 -> commit -> push -> 내 브랜치 to master Pull Request -> Code Review -> Approbe -> Merge Pull Request -> branch-up-to-date Pull Reqeust-> 개발

github-branch

이를 해결하기 위해 git-flow 전략을 채택하였고, 이를 도입하기 위해 테스트 Repository를 만들어 팀원과 테스트를 진행해보았다.
우선 develop 브랜치를 생성해 5개의 파일을 만들었다. 그 다음 모든 팀원이 develop에서 개발을 진행을 해보니 서로 겹치지 않는 이상 문제가 없을 것 같아 이 방법을 채택했다.
이 방식을 통해 프로젝트 최신화를 기다리지 않아도 되고, 작업한 내용을 바로바로 받아 사용할 수 있게 되었다.

개발 -> commit -> push -> fetch -> pull -> 개발

참고 블로그

Jwhy