메가테라 23주차 주간회고 (프로젝트 7주차 회고)

23주 차 회고 (프로젝트 7주 차 회고)

---

메가 테라 23주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다.

7주 차 작업 목표

7주 차의 가장 큰 목표는 어드민 기능을 핵심적인 것부터 최대한 많이 구현하는 것이었다.
그래서 기존에 계획했던 게시판의 어드민 기능 중 가장 핵심적이고, 없으면 안 되는 기능 3가지를 뽑아 무조건 구현하도록 최우선 순위로 선정했다. 핵심적인 3가지 기능은 아래와 같다.

1. 전체 멤버 관리

• 전체 멤버 수를 확인할 수 있다.
• 멤버의 등급을 변경할 수 있다.
• 멤버를 강제 탈퇴시킬 수 있다.
• 회원 정보(아이디, 닉네임, 등급, 게시글 작성 수, 댓글 작성 수)를 확인할 수 있다.

2. 게시판 관리

• 하위 게시판 생성 (3 depth)
• 게시판 삭제

3. 등업 신청 관리

• 등업 신청 수락
• 등업 신청 거절

위의 어드민 기능들을 모두 구현했을 시 채팅 기능을 보완하는 작업까지 목표로 잡았다. (내가 작성한 채팅과 다른 사용자가 작성한 채팅 구분하는 작업)

7주 차 스토리 포인트 사용량은 아래와 같다.

우선 7주 차에 구현한 기능들에 대해 간단히 회고부터 해보자.

 

어드민을 기획하다

프로젝트 초기에 어드민을 기획할 때 나는 어드민을 사용자의 등급이 매니저이면 그 사용자가 어드민을 할 수 있도록 기획을 했었다.

왜냐하면 내가 접해본 어드민은 네이버 카페의 매니저가 전부였기 때문이다. 그래서 어드민 페이지도 기존에 진행하는 리액트 프로젝트에 같이 만드려고 계획을 세우고 있었다. 아무튼 이런 형태의 어드민도 어드민이라고 할 수 있지만 정확히는 어드민이 아니라는 것을 저번 주에 알게 되었다. 

어드민은 어드민만의 별도의 프로젝트(프론트엔드 로컬 주소 다르게 해서 어드민 프로젝트 생성, 백엔드는 서버를 같이 사용해도 괜찮음)가 생성되어야 하고 또 어드민 계정이 따로 존재해야 한다. 

그래서 어드민을 별도의 프로젝트를 새로 만들어서 진행하는 방향으로 정했고 그러다 보니 기존에 기획했던 어드민도 새롭게 기획을 했다.

위에서 말했듯이 시간이 일주일밖에 없었기 때문에 가장 핵심이 되는 3가지 (멤버 관리, 게시판 관리, 등업 신청 관리)와 시간이 있을 시 사용자에게 스탭 역할을 부여해 스탭 역할을 갖고 있는 사용자는 다른 사용자의 게시글을 삭제할 수 있는 권한을 부여하는 것 또는 통계 기능을 구현하는 것이었다.

결과는 핵심적인 3가지 기능은 완성했지만 나머지 부가적인 기능은 다른 기능을 리팩터링 하느라 시도조차 못한 상황이다.

아무튼 어드민에 대해 오해하고 있던 사실을 바로 잡고 새롭게 어드민을 기획하고 기능을 구현했다.

 

등업 신청 관리

우선 사용자가 신청한 등업 게시글을 관리하는 기능을 구현했는데 해당 기능을 구현하기 위해서는 먼저 해야 하는 작업이 있었는데 바로 사용자 객체에 등급 필드를 추가하는 것이다. 그래서 사용자의 등급을 값 객체로 만들어서 총 5개의 등급 (아마추어, 세미프로, 프로, 월드클래스, 스탭)이 존재하도록 생각했다. 계정이 생성이 될 시에는 아마추어 등급이 부여되고 더 높은 등급을 달성하기 위해서는 등업 신청을 해서 관리자가 해당 신청을 수락할 시에 등급 업이 되도록 기획했다. 그래서 관리자의 등업 신청 관리 페이지를 만들기 이전에 사용자 페이지에서 등업 신청 게시판을 먼저 만들어야 했다. 간단하게 등업 신청 시에는 신청 등급과 신청 사유를 적도록 했고 관리자 페이지에서는 해당 신청자의 정보(신청자가 작성한 게시글 수, 댓글 수)를 보고 수락할 것인지 거절할 것인지 결정하도록 했다.

이때 문제점이 하나가 있었는데 관리자가 등업 신청을 수락 또는 거절할 시에 사용자는 수락이 되었는지 거절이 되었는지 알 수 있는 방법이 전혀 없었다. 그래서 생각해낸 게 등업 신청 게시판에서는 자신이 등업 신청했던 이력을 볼 수 있도록 해서 등업 신청이 승인되었는지 거절되었는지 알 수 있도록 했다.

그리고 등급 시스템이 도입되다 보니 등급별로 접근할 수 있는 콘텐츠를 다르게 하는 기능도 있으면 좋겠다는 생각을 하게 되었는데 이 기능은 기존에 계획했던 핵심적인 기능을 모두 구현하면 도전하려고 했었지만 결국엔 시간이 없어서 작업이 미뤄지게 되었다.

 

등업 신청 관리 기능을 구현한 페이지이다.

전체 멤버 관리

전체 멤버 관리 기능은 어드민 기능 중 가장 핵심이라 생각했던 기능이다. 해당 기능을 구현하는 건 어렵지 않을 거라고 생각을 했었다. 그래서 예상 스토리 포인트를 3포인트로 잡았다. 왜냐하면 그냥 기존에 사용하던 userRepository에서 findAll 메서드를 이용해 모든 사용자를 어드민 프론트로 전달만 해주면 된다고 생각했기 때문이다. 실제로도 모든 사용자를 리스트 시키는 건 어렵지 않았다. 그런데 예상 스토리 포인트보다 2배나 더 쓴 이유는 맨 처음 구현하는 어드민 기능이다 보니까 REST API나 url, 어드민 컨트롤러 클래스의 위치(기존에 사용하던 패키지안의 컨트롤러에 넣을 것인지, 새로운 어드민 패키지를 만들고 컨트롤러 패키지를 만들어서 할 것인지) 등등 백엔드 서버를 같이 사용하다 보니 생각해야 할 것들이 많았기 때문에 예상 스토리 포인트보다 더 사용한 것 같다. 

 

전체 멤버 관리 기능을 구현한 페이지이다.

 

 

게시판 관리

마지막으로 구현한 기능은 게시판을 생성하고 삭제하는 기능이다. 구현 목표는 게시판을 하나 선택하면 해당 게시판의 하위 게시판으로 새로운 게시판을 3 depth 만큼 생성하게 하는 것이었다. 댓글로 비유하면 댓글의 대댓글의 대대댓글이 있는 형태이다.

처음에 게시판 엔티티를 설계할 때도 이를 생각하고 게시판 엔티티에 상위 게시판의 아이디를 참조할 수 있는 parentId 필드를 추가했었다.
만약에 해당 필드를 생성하지 않았었다면 이번에 만들고 게시판 모델 수정에 따른 엄청난 리팩터링이 필요했었을 것이다. 드디어 설계를 한 덕을 보는구나!라는 생각을 하게 되었다.

게시판 생성은 생각했던 것보다 쉽게 구현할 수 있었다. 생성 시 하위 게시판을 만들고 싶은 게시판을 선택해 선택한 게시판의 아이디값과 생성할 게시판의 이름을 백엔드로 전달해 create 해주면 끝이었다.

게시판 삭제하는 기능은 생성보다는 조금 더 복잡했는데 게시판을 삭제할 때 해당 게시판이 실제로 삭제(db에서 제거)가 되는 것이 아니라 삭제된 상태로 변경하는 soft delete방식을 활용해봤는데 이에 따른 다른 부분에서 고려할게 생겼었다. 예를 들어 실제 db에서 제거된 것이 아니기 때문에 모든 게시판 리스트를 화면에 보여줘야 할 때 게시판의 delete 상태가 지워지지 않은 상태인 게시판만 화면에 보이게 한다거나 게시판 생성 시 게시판 이름 중복 방지를 위해서 예외 처리를 할 때도 현재 존재하는 게시판(delete상태가 지워지지 않은 상태)만 모아서 검사를 하는 등 한번 더 생각해줘야 하는 부분들이 있었다. 그리고 게시판을 삭제하면 게시판 안에 존재하는 게시글이나 댓글 같은 것들은 지워지지 않고 존재하게 되는데 해당 게시판 안에 있는 모든 것들을 아예 지우거나 이것도 soft delete방식을 이용할 필요가 있었다.

이제는 뭐 하나 지우는 게 쉬운 일이 아닌 게 되었다. 객체 간의 관계가 서로를 참조하고 있다 보니 게시글 하나를 지우려면 게시글 안에 존재하는 댓글, 대댓글 모두를 지워야 게시글이 지워지기 때문이다. 

아무튼 게시판 생성 / 삭제 기능은 예상 스토리 포인트보다 더 빠르게 구현할 수 있었다. 덕분에 채팅 기능도 보완했다는 점!!

 

3 depth까지 게시판 생성 기능을 구현한 모습이다. (EPL -> 토트넘 -> 손흥민 각각 모두 게시판)

 

 

위의 기능을 모두 구현하고 보니 게시판의 모양새가 어느 정도 잡힌 것 같았다. 이 말은 프로젝트의 끝도 보인다는 이야기인데 이제는 정말 일주일밖에 남지 않았다. 디자인 입히고 지금 구현한 기능들을 한 번씩 사용해보면서 디테일을 잡다 보면 마지막 일주일도 금방 갈 것 같은데 최대한 알차게 사용해보자!