프로젝트 피드백 - 작성자: 이성국 튜터

[tjdrnr0557]

Overview

• 프로젝트 전반적으로 매우 훌륭합니다 디테일한 부분들만 조금 더 다듬고 다른 팀원 분들이 짠 로직까지 직접 구현해보고 이론적인 내용들까지 완벽히 숙지한다면 취업 준비하실 때 도움이 될 것 같습니다

• 전반적으로 문서화가 너무 잘되어있습니다 정말 열심히하신게 보이고 실력도 많이 성장하신 것 같아서 보기 너무 좋았습니다

• AWS S3 파일업로드, 레디스 사용, 카카오 로그인, 테스트코드등 추가적인 기능까지 구현해주셨는데 이러한 시도 정말 좋습니다. 이렇게 직접 구현하는 과정에서 실력도 많이 성장하셨을 것 같네요

• PR 에서 어떠한 작업을 했는지, 어떻게 테스트했는지 팀원분들끼리 코드리뷰 해주신 내용 정말 좋습니다 훌륭하네요

• restful api 에 대한 이해도가 많이늘어서 전반적으로 설계가 좋습니다. 아쉬운 점은 단수형보단 복수형으로 사용하는 것이 관례이기는 합니다 posts -> post, comments -> comment

• 하나 조회, 전체조회 때문에 단수형 복수형으로 나눠서 사용하신 것 같은데 포스트 전체 조회의 경우 GET /posts 포스트 하나 조회의 경우 GET /posts/{postId}로 사용하면 의미 전달이 충분히 될 수 있습니다

• {post_id} -> {postId} 카멜케이스로 보통 사용합니다

• ERD 같은 경우는 로그인하면 보이지 않네요. 선호에 따라 다르겠지만 저는 Readme에 바로 스크린샷형태로 보이는 것을 선호합니다. (한 뎁스 더 들어가야 하면 보지 않는 분도 계실 수 있을 것 같습니다)

• 어떠한 기능을 어떠한 기술을 사용해서 구현했는지 적어주셔서 좋습니다. 나중에 취업준비하실 때는 이 내용을 조금 더 상세히 기술해서 포트폴리오를 적는 것이 좋습니다. ex) 이 기능을 구현하는데 왜 레디스를 사용했고 다른 기술을 고려한 것은 무엇이있는지 성능상 어떠한 이점이 있어서 이것을 사용했는지 등등) 나중에 튜터실에 오시면 어떤식으로 쓰면 더 좋을지 자세히 말씀드릴게요

Code review

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/service/UserService.java#L37-L39

• 토큰 값은 코드에 적지 않습니다. 해킹될 위험이 있어서 vault 같은 곳에 보통 저장합니다. 지금은 적용하기 무리가 있으니 properties로 적용하는것도 방법이겠네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/service/UserService.java#L102-L116

• 파일업로드 기능 구현 좋습니다. 현재는 파일이름으로 저장하고 있지만 (파일을 서버에 저장하는 방식이라) 보통은 S3에 파일을 업로드하고 AWS 에서 파일에 대한 url을 주면 그 url을 보통 DB에 저장합니다.

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/service/FollowService.java#L14-L17

• @Transactional은 보통 메소드 단위로 사용하는게 좋습니다. 왜냐면 getFollowers 같은 메소드는 읽기만 있으므로 @Transactional(readOnly = true)로 적용해야하기 때문입니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/entity/Follow.java#L12-L27

• 팔로워 엔티티 설정 좋습니다 학습내용에 맞게 정석적으로 구현해주셨네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/service/FollowService.java#L21-L29

• 로직 구성 학습방향에 맞게 좋습니다
• 현업에서는 이렇게 사용하면 문제가 될 염려가 있습니다. 왜냐면 인스타그램 팔로워가 많은사람들은 몇천만명 이 넘는 유저들도 있기 때문에 이렇게 한번에 DB를 조회하면 그 내용이 엄청 많아져서 성능에 문제가 될 수 있습니다. 이를해결하려면 어떻게 해야할까요!? 여러방법이 있는데 한번 고민해보시고 검색해보면서 어떻게 처리하면 좋을지 고민해보면 좋을 것 같습니다.
• 또한 지금처럼 몇천만건의 데이터를 읽을때 Pagination이라는 것을 사용합니다. api를 호출할때 몇천만건을 한번에 불러오는 것은 성능에 문제가 생길 수 있어서 클라이언트에서 100개씩 여러번 호출하는 개념인데요 한번 검색해서 내용 숙지해보시면 좋을 것 같네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/entity/User.java#L47-L53

• 성능을 고려해서 반정규화 를 통해 팔로워, 팔로잉 수를 나타내주신 점 좋습니다.

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/user/controller/FollowController.java#L38-L47

• ~~ 성공 같은 문구는 나타내주지 않아도 api가 예외를 뱉지않고 성공해서 200 status를 내려준다면 클라이언트는 성공했다는 것을 알 수 있으므로 해당 문구 불필요합니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/redis/controller/RedisPostController.java#L18-L29

• 레디스를 이용한 캐싱을 사용하신 것은 좋으나 Redis만을 위한 Controller는 불필요합니다.
• 게시글을 조회할 때 레디스에 먼저 게시글이 있나 확인하고 없으면 DB를 조회해서 게시글을 가져와서 응답을 내려주고 이 게시글을 레디스에 저장하는 방식이 일반적인 캐싱 방식입니다
• https://souljit2.tistory.com/72 이런글 참조해보시면 좋겠네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/redis/service/RedisPostService.java#L23-L34

• 해당 방식으로 저장하는 것도 나쁘지 않으나 스프링에서 지원해주는 @Cacheable 같은 것을 사용하면 더 편리하게 캐싱할 수 있습니다
• 또한 이렇게 따로 저장하기 보단 어떠한 게시글을 조회했을 때 레디스에 있는지 확인하고 없으면 DB를 조회해서 이를 레디스에 저장하면 다음번 다시 조회할 때 레디스에 있는지 확인했을 때 있으면 캐시 히트가 되는 로직이 일반적입니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/redis/service/RedisPostService.java#L37-L44

• 이처럼 레디스를 조회하는 방식은 연산도 많이들고 캐시 히트가 될 확률도 적습니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/redis/entity/RedisPost.java#L8-L15

• 캐싱을 위해서 새로운 엔티티를 만들 필요는 없습니다
• 기존 엔티티를 이용해서 말씀드린 방식대로 캐싱을 적용해보면 좋겠네요

전반적으로 레디스를 이용한 시도 너무 좋았지만 좀 더 적절한 캐싱방법을 이용해보시면 더욱 좋을 것 같네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/kakao/service/KakaoService.java#L37-L39

• 주입방식 좋습니다
• 전반적으로 카카오 로그인 방식 구성이 괜찮은 것 같네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/kakao/service/KakaoService.java#L107-L111

• 현재는 프로젝트 사이즈가 작아서 User 엔티티에 kakaoId까지 저장하는 것도 괜찮지만 몇천만명이 사용하는 어플리케이션이라면 해당 테이블도 분리되는 것이 좋습니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/admin/controller/AdminNoticeController.java#L36-L45

• 페이지네이션을 적용해주셨네요 훌륭합니다. 페이지네이션 방식에는 사용해주신 방식과 커서 페이지네이션 방식이 있습니다. 실제로 현업에서는 커서 페이지네이션 방법을 훨씬 더 많이 사용합니다. 왜냐면 page, size를 이용하면 10번까지 조회한다음에 사용자들이 글을 계속 작성한다면 누락되서 조회하는 경우가 생길 수 있기 때문입니다. 커서 페이지네이션에 대해 검색해서 개념을 익혀보시면 더욱 좋을 것 같네요
• 로직 구성해주신 걸 보니 왜 페이지네이션을 사용해야하는지 알고 계실 것 같지만 이 부분에 대해서 좀 더 숙지해보면 좋을 것 같습니다 면접에서도 많이 나오는 내용입니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/admin/service/AdminPostService.java#L19-L22

• @Transactional은 보통 메소드 단위로 사용하는게 좋습니다. 왜냐면 getFollowers 같은 메소드는 읽기만 있으므로 @Transactional(readOnly = true)로 적용해야하기 때문입니다

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/admin/service/AdminUserService.java#L128-L134

• 토큰 삭제 좋습니다 레디스에 토큰 저장한 것도 적절합니다. 프로젝트 규모가 커지면 레디스가 아니라 DB에 토큰을 저장하는 경우도 있습니다. 구현하기 나름인데 이 부분도 고민해보면 좋을 것 같네요

https://github.com/JisooPyo/KP3C-backoffice-project/blob/46293acf6113e30da13e0b6e7e462f6d276ceb87/src/main/java/com/example/kp3coutsourcingproject/post/controller/PostController.java#L24-L48

• 전반적으로 페이지네이션 적용 필요합니다. 피드에 수천만개가 한번에 있을 수도 있는 로직이여서 실제 어플리케이션이라면 위험할 수 있습니다.
• 인스타그램을 예로들면 처음에 100개를 가져오고 우리가 피드를 내리다가 98번째쯤되면 그때 프론트에서 api를 요청해서 다음 100개를 가져오는 방식으로 설계가 되어있습니다. 이는 주로 커서 페이지네이션으로 구현되어있고 이 부분 참고해보시면 좋겠네요

전반적으로 동일한 부분에 대해서는 다시 지적하지는 않았으니 각자 작성한 부분에서 제가 리뷰 남긴 부분이 적용된다면 고쳐보시면 실력향상에 도움이 될 것 같습니다. 프로젝트하느라 고생많으셨습니다. 열심히 하고 계신게 눈에 보이네요. 다른 팀원분들이 작성하신 로직도 보면서 본인 것으로 만들면 더 좋을 것 같네요