인가 분리와 좋아요 Transaction 및 builder vs 생성자

2024.06.21.(금)

 

팀 프로젝트

• 진행 상황
  • 인가 분리 추가

[2024.06.22] feat/#38 auth >> 인가 분리 추가 by ysy56 · Pull Request #42 · GreedyPeople/GreedyPeople

 

• 변경사항
  • 중간 회의
    • 인텔리제이 자바 구글 스타일 가이드 적용
    • 유저 권한 필드 변경 및 상태(정상, 탈퇴) 필드 추가 : enum
    • 역할 분담 : 사용자 인증(+소셜로그인, -인가), 좋아요&팔로우(+차단 기능), 백오피스(+인가)
  • 저녁 회의
    • 좋아요의 트랜잭션에 관련된 의논
    • 빌드 & 생성자에 관련된 의논

 

---

질문

• 좋아요의 트랜잭션에 대해

[2024.06.20] feat/#8-like-menu >> 메뉴 좋아요 기능 추가 by sihyun615 · Pull Request #25 · GreedyPeople/GreedyPeople

해당 PR을 보면 좋아요 추가와 삭제의 Service에 모두 Transaction 어노테이션이 붙어있는 것을 확인했다.

현재 내가 아는 내용은 아래의 2개가 전부이다.

• Http 메서드가 PUT인 Service의 update에 Transaction 어노테이션 사용
• 트랜잭션이란 것은 하나의 기능을 묶어서 동작시키고 싶을 때 사용

그런데 여기서 왜 나는 PUT에 트랜잭션 어노테이션을 사용했던 건지 의문이 들기 시작했다.

그리고 트랜잭션이 하나의 기능을 묶어서 동작시키는 것이라면 좋아요 추가와 삭제는 하나의 동작으로 동작되어야 하기 때문에 트랜잭션을 사용하는 것이 맞는데 나는 왜 PUT일 때 트랜잭션 어노테이션을 사용하였는가? @Transaction을 어디에 붙여주어야 하는가? 이런 식으로 계속해서 의문점들이 꼬리를 물며 불어났다.

결론적으로 Transaction은 어떨 때 쓰는 것인지 스프링에서의 트랜잭션은 어떻게 되는 것인지 개념을 제대로 인지하지 못하여 튜터님께 질문하게 되었다.

 

트랜잭션은 restAPI가 여러 개가 동시에 실행되었을 때 트랜잭션이 있는 것이 먼저 선점한다.

예를 들어서 A가 1번 글을 수정하는 요청을 보냈고 B가 1번 글을 읽는 요청을 보냈을 때

글을 수정하는 것의 Service 단에 Transaction이 사용되었다면 수정 요청이 완료될 때까지 B는 1번 글을 읽을 수 없다.

그렇기 때문에 이런 경우에서는 B에게 Transaction readOnly를 해주어야 한다. 그러면 1번 글이 수정 중일 때도 B는 글을 읽어올 수 있다.

 

그리고 일반적으로 Repository에는 모두 Transaction 어노테이션이 붙어있다. 그런데 왜 Service 단에서 Transaction을 사용하나? 그 이유는 앞서 말했던 이유와 같다. 

 

마지막으로 정리하자면 속도를 위해서는 Transaction이 모두 Repository에 붙어있으니 Service에서는 빼도 상관없다는 주장과 안정성을 위해서 Transaction을 붙이자는 주장으로 나뉜다. 우리 팀은 속도보다는 안정성을 우선시하여 Transaction을 Service에서 붙여주는 것으로 하였으며, GET의 요청은 Transaction이 진행 중이더라도 읽을 수는 있어야 하기 때문에 Transaction readOnly를 사용해주는 것으로 결정하였다.

 

• 빌드 & 생성자에 대해

빌드와 생성자 중 어떤 것을 할 지 팀 프로젝트를 진행하기 전에 의논하지 않았기에 어떤 사람은 빌드를 어떤 사람은 생성자를 이용해서 코드를 작성하는 문제가 발생되었다.

 

나의 의견은 빌드의 경우는 문제가 발생한다면 어디에서 발생된 것인지 찾기 힘든 경우가 있기에 생성자를 지향한다고 알고 있어서 생성자를 사용하자는 의견이었다. 하지만, 생성자에서 값을 넣어주는 경우가 많을 경우에 빌드를 사용한다고도 한다. 이 점에서 우리는 User 이외에는 모두 생성자를 사용하도록 하였다. 하지만, 우리의 판단이 정확하지 않을 것이라는 판단하에 튜터님께 질문하게 되었다.

 

• 차단 기능에 대해

처음에는 차단 기능을 할 생각이 없었는데 내 담당 튜터님께서 역할 분담에 대한 조언으로 각자 역할 분담이 조금씩 바뀌게 되면서 차단 기능이 추가되었다. 해당 부분에 대해 당시 튜터님께 들었던 내용은 차단 기능은 블랙 리스트 테이블을 만들어서 차단 사용자를 관리한다는 걸 팀원들에게 얘기해주었다. 그 후 해당 부분을 맡은 담당 팀원이 블랙 리스트의 경우는 테이블을 어떤 컬럼을 가지고 있어야 되는지 물어보았고 이 부분에서 팀원들과 상의하다가 마침 담당 튜터님께서 계셔서 여쭤보기로 하였다.

 

정확하게 우리의 고민은 아래와 같았다.

• 블랙리스트 테이블을 만들 경우 유저의 아이디와 상태(차단, 정상)를 가지고 있다면 굳이 테이블을 만들지 않고 유저의 테이블에 상태(차단, 정상)만 추가하면 되지 않나?
• 블랙리스트 테이블을 만들 경우 유저의 아이디, 상태(차단, 정상)... 그리고 어떠한 것을 테이블의 컬럼으로 가지고 있어야 되는가?

 

튜터님께서 말씀해주신 방법은 3가지 정도가 있었다.

1. 유저의 테이블에 상태(차단, 정상)를 만들어서 차단 기능을 만드는 경우
2. 블랙리스트 테이블에 유저의 아이디 차단된 이유를 넣어서 테이블을 만들고 블랙리스트 테이블에 해당 아이디의 존재 여부로 차단 기능을 만드는 경우
3. 2번의 경우에 Redis를 조합해서 활용하는 경우 - 이 경우는 설명을 듣긴 했지만, 정확하게 이해하지 못했다.

 

결론적으로는 1+2의 방법으로 차단 기능을 구현하도록 정하였다.

유저의 테이블에 상태(차단, 정상)을 만들고 블랙리스트 테이블에 유저의 이유와 차단 이유를 넣어서 테이블을 만들고 차단 여부는 유저의 테이블에 상태가 차단인지 여부로 차단 기능을 구현하기로 하였다.

---

오늘의 회고

• 12시간 중 얼마나 몰입했는가?

하루 전체를 몰입해서 코드 구현하고 팀원들과 설계하고 튜터님께 질문하면서 보낸 것 같다.

팀 프로젝트는 나 혼자만하는 것이 아니기에 매번 프로젝트 시작 이후 최대한 몰입해서 진행하는 것 같다.

이번에도 예외없이 최대한 몰입해서 진행했다.

 

• 오늘의 생각

갑작스럽게 역할 분담을 조금 변경하게 되었는데도 동의해주고 기분 나빠하지 않았던 팀원들에게 너무 고맙다.

이번 팀 프로젝트를 열심히해서 다들 가져가는 게 많았으면 싶었던 내 개인적임 바램 때문에 역할 분담을 변경하게 되었는데도 내 의견을 수용하고 받아들여준 게 많이 고마웠다.

그리고 인가 부분을 내가 뺏어오게 되었는데 큰 불화가 생기지 않았던 점도 해당 부분을 맡았던 분께 다시 감사해하고 있다. 그렇지만.. 괜히 뺏어온 게 아닌가 싶었다. 욕심내서 뺏어왔는데 제대로 완성하지 못할까봐 걱정이 태산이었다.

 

• 내일 학습할 것은 무엇인지

주말동안 인증 인가 구현된 것으로 백오피스를 테스트 해볼 예정이다.