4주 Final Project 회고

코드스테이츠 1주일이 지난 지금 수료 마지막 기간에 했던 4주 Final Project에 대한 회고를 하려고 한다. 4주 동안 꽤 많은 일들이 있었고, 수료 후에는 이제 구직 활동을 할테지만 프로젝트에 대한 회고를 하며 뒤를 돌아보려 한다.

링크

노션 문서

깃헙

팀 배분

2주 프로젝트를 할 때와 같이, 32기는 13명의 수강생으로만 구성돼 있었으며, 이번에도 3명이 한 팀을 구성하게 됐다. 나와 백엔드를 하시는 팀원은 전에도 같이 하셨던 분이셨으며, 새로 프론트엔드를 해주실 한 분이 바뀌었다. 전에는 백엔드를 지망하셨으나 프론트엔드를 해보시고 있었던 분이셨는데 이번에는 프론트엔드를 지망하셨던 분이 같은 팀이 됐다. 나는 저번에는 팀장을 맡았지만, 이번 프로젝트에서는 팀원이 됐다. 이 때는 팀장을 맡았을 때보다 뭔가 부담감이 덜했던 것 같다.

개발

SR 작성

퍼스트 때와 마찬가지로 개발에 들어가기 앞서 SR 작성 단계를 걸쳤다. 아이디어 회의부터 서비스에 대한 전반적인 wiki 작성, DB Schema, Wireframe, API 문서 등을 작성했다. 퍼스트 때에 이미 경험을 해본지라 작성을 하는 데에 있어선 어려움이 없었지만 다시 새로운 아이디어와 서비스를 어떻게 제공할 것인지 회의를 하고 이 문서를 작성하는데 꽤 시간을 많이 사용했던 것 같다. 저번에도 느꼈었던 것이지만, 기획이 탄탄해야 개발을 함에 있어서도 도움이 되는 것 같으며, 진행에 있어서도 매우 중요한 부분인 것 같다. 파이널 프로젝트이긴 했지만 아직도 많이 부족했던 터라 API문서나 DB 스키마나 Wireframe 같은 문서들을 꽤 많이 수정하긴 했다 ^^;;

개발 단계

나는 퍼스트 때와 비슷하게 회원과 댓글, 카카오 API를 이용한 로그인, 결제에 대한 개발을 진행했다. CRUD에 대한 것과 OAuth 로그인은 나중에 서버쪽에서만 완료했지만, 전에 해봤던 것들이라 어렵지 않게 해낼 수 있었다. 그래서 이번에는 새로운 것들을 위주로 회고를 해보려고 한다.

카카오 페이 API를 이용한 결제 시스템 구현

우리 서비스에서는 해당 독립 영화에 대한 후원 기능을 제공한다. 그렇기 때문에 결제 시스템이 필요했다. 우린 주마다 피드백을 진행했는데 결제 시스템을 클라이언트 단이 아닌 서버 단에서 구현해보라는 피드백을 받았으며, 이러한 피드백을 받은 이유는 이와 같았다. 클라이언트 단에서 처리를 하고 검증의 과정을 거치겟지만, 만에 하나 그 정보가 탈취되어 서버에 전달이 된다면 잘못된 결제 요청을 가지고 결제 정보를 저장하는 것이기 때문에 서버에서 구현해보도록 하라고 하셨다. 그래서 PG 결제를 찾아보았으며, 이 경우 사업자 등록이나 협약을 통해 진행을 해야했기 때문에 보류가 됐고, 다른 외부 API에서는 보통 클라이언트 단에서 결제를 진행하는 것이 대부분이었기 때문에, OAuth 사용경험이 있는 본인은 카카오 페이를 이용하게 됐다.

• 결제 준비
  
  클라이언트에서는 토큰과 결제 정보를 전달하며 토큰으로 유저를 검증한다. 검증이 끝나면 위 URL에 ADMIN KEY, 필수파라미터들과 함께 결제 준비 요청을 한다.
  그러면 카카오에서는 TID라는 것과 redirect url을 서비스 서버로 전달하며, 서버에서는 TID와 함께 결제 요청 정보를 DB에 저장하게 된다. 그 후 서버는 클라이언트로 redirect url을 전달하게 된다.

• 결제 요청
  클라이언트에서는 전달 받은 redirect url로 접속 후 결제 요청을 진행하게 되며, 성공적으로 진행하게 된다면 Approval url에 pg_token을 파라미터로 붙여 리다이렉트 하게 한다.

• 결제 승인
  
  그 후 결제 승인을 위해서 클라이언트에서는 pg_token을 파싱하여 토큰과 함께 서버로 승인 요청을 하며 서버에서는 토큰을 통해 유저 검증을 한 후, DB에 저장한 결제 요청 정보를 찾아 카카오에 승인 요청을 보낼 준비를 한다.
  서버에서 이 정보와 ADMIN KEY를 카카오에 승인 요청을 하게 되며 카카오에서는 결제 상세 정보를 서버로 전달하게 된다. 그리고 서버에서는 결제 정보를 토대로 DB에 업데이트를 한다.

사실 더 쉽게 할 수도 있었지만, 클라이언트 단에서는 tid를 보존하고 싶다고 하지 않다고 해서, 다른 방법으로 이를 식별할 방법이 필요했다. 그래서 DB에 결제 요청 정보를 저장한 후 이와 함께 고유하게 식별할 수 있는 Redirect url을 같이 저장했으며, 클라이언트에서 이 url을 넘겨주면 url로 요청 정보를 찾아 tid를 찾도록 했다.

댓글의 페이지네이션

이번에는 댓글의 단순 CRUD가 아닌 페이지네이션을 구현했다. 여러 방법을 탐색하던 중 JPA Repository를 상속받아 페이징하는 방법을 사용하게 됐다. 해당 영화 id를 가진 댓글들을 가져와서 Pageable, PageRequest을 사용하여 find 메소드를 커스터마이징 할 수 있었으며, 이를 통해서 페이징을 구현할 수 있었다. 일단 최신순으로 정렬하는 것은 처음에는 date를 기준으로 했지만, 더미데이터의 경우 sql을 새로 실행했을 때 나오는 댓글들은 시간의 차이가 거의 없었기 때문에 정렬이 되지 않고 순서대로 뽑히게 됐다. 그래서 id를 기준으로 역순으로 정렬을 하도록 하니 최신순으로 정렬하는 것은 쉽게 해결이 됐다.

위와 같이 댓글의 페이징을 한 후 리가 필요한 데이터들만 보내줄 수 있도록 DTO를 새로 만들어서 데이터를 보내주도록 구현했다.
하지만 문제는 좋아요를 기준으로 한 정렬이 문제였는데 우리 서비스에서는 OneToMany 매핑이 된 ArrayList로 좋아요가 관리가 됐었기 때문에, PageRequest에서 객체를 통한 정렬 방법을 찾아봤지만, 결국 찾지 못하고 새로운 방법을 모색하게 됐으며, 생각을 해낸 것이 우리 댓글 엔티티에 좋아요라는 필드가 없었고, 이 필드를 추가 후에 좋아요를 관리하는 ArrayList객체의 사이즈가 좋아요 필드 값이 될 수 있도록 처리를 하니 좋아요에 대한 정렬도 처리를 할 수 있었다.

결과

gif를 올리고 싶지만, 용량이 너무 크다고 벨로그에서 거부를 한다 ㅠㅠ
결과 사진만 보면 꽤 괜찮게 나온 것 같다. 4주를 했지만 아쉬운 부분이 많다. 역시 프론트 2명, 백 2명 이렇게 구성이 됐었으면 하는 생각이 든다. 그리고 4주를 끝내고 나니 부족한 부분, 필요한 부분이 많이 보였다. 기능적인 측면에선 아직 클라이언트 쪽에서는 카카오 로그인을 구현하지 못했다. 프로젝트 거의 마지막에 서버 쪽에서 구현을 해서 클라이언트와 연동을 해서 또 카카오 로그인 했다는 것을 확인하고 서비스를 제공하려면 내가 한 부분 말고도 다른 분이 하신 부분도 건드려야 했기 때문에 서버 쪽에서만 완료를 해놓았다. 그리고 로그인 부분에서도 취약점이 많은데 인증을 거치지 않아 아무런 아이디를 입력하고 회원가입을 시도하면 중복체크만 넘어가면 완료가 된다. 그래서 이메일 인증을 추후에 개발하면 어떨까라는 생각이 든다. 또한 전체적인 부분을 건드리지 않기 위해 카카오 로그인을 했을 때 우리 서비스 자체의 토큰 인증서비스를 한번 더 이용해서 서비스 자체의 액세스 토큰과 리프레쉬 토큰을 넘겨주면 어떨까라는 생각이 든다. 리팩토링을 해야할 부분도 많이 존재한다. 기능과 서비스의 분리, 컨트롤러, 서비스, 레포지토리의 기능을 잘 생각하며 리팩토링을 진행하면 좋을 것 같다. 4주라는 시간이 짧을 수도, 길 수도 있는 시간이었다. 하지만 이렇게 끝났다고 해서 이 프로젝트를 방치하기에는 너무 아까운 것 같다. 위와 같이 리팩토링과 부족한 부분을 보완해가면서 더 완성도 있는 서비스를 만들고 싶다.