Project Section - PreProject Review

Review 에서는 학습한 내용을 다시금 기록합니다.
Unit Review는 학습한 내용 중 기존에 알고 있었지만 정확하게 이해하지 못하던 정보와 새롭게 알게된 정보를 기록합니다. 추가적인 설명을 요하는 부분은 댓글로 남겨주세요.
Section Review는 전반적인 Section을 되돌아보고 학습했던 시간과 과정, 내용을 총괄하여 기록합니다.

 프로젝트 섹션의 두 가지 큰 미션 중 하나였던 프리 프로젝트가 끝났다. 컴퓨터공학을 이중전공하긴 했지만, 할 줄 아는게 없어 '협업'의 '협'자도 몰랐던 나로써는 처음으로 프론트엔드 사이드의 분들과 협업할 수 있는 시간이 되었고, 또한 처음으로 스프링을 활용한 웹 서비스를 만들어볼 수 있어 얻어간 것이 많은 프리 프로젝트였다.

 

 이번 회고에서는 기존의 섹션 리뷰에서 다루던 무엇을 잘했고 못했는지에 집중하기보다는, 프리 프로젝트 기간 동안 나는 무엇을 담당했으며, 어떤 어려움을 겪었고 이를 어떻게 해결했는지, 또한 메인 프로젝트에서 더 좋은 결과물을 만들기 위해선 보완해야할 점은 무엇인지에 집중해보고자 한다. 

 

 My Tasks

 

 아는 건 없지만 허섭하게나마 프로젝트를 해보았던 터라 백엔드 파트의 팀장을 맡게 되었다. 되도 않는 업무 분담을 진행해 팀원 분들에게 부탁드렸으며, 꼴에 팀장이라고 팀원 분들에게 부담을 지워드리고 싶지 않아 기능 개발의 대부분을 맡아 처리했다. 인증 / 인가 처리와 기본적인 CRUD를 제외한 대부분의 기능은 내가 맡아 처리했다. 대신, 기본적인 CRUD기능 및 배포 인프라 구축과 같은 DevOps파트는 다른 백엔드 팀원 분들에게 맡겼다. 그런데 지금 생각해보면, '이 방법이 과연 우리에게 옳은 방법이었을까?' 라는 생각이 든다. 해당 부분에 대해서는 잠시 뒤에 다루기로 하고 일단은 내가 맡았던 부분에 좀 더 집중해보겠다.

 

 가장 어려웠던 부분은 역시 인증 / 인가를 처리하는 부분이었다. 사실 로그인 코드는 이미 학습 자료로 배웠던 터라, 해당 코드들을 참고해 작성할 수 있어 코드 작성은 별로 어렵지 않았다. 문제는 로그 아웃을 구현하는 것과, 클라이언트와의 통신 과정에서 발생하는 여러 Access 제한 문제, 데이터들의 전달 문제 등에 있었다.

 

 먼저 로그 아웃은 redis를 통해 해결했다. Security Context 내부에서 직접적으로 Authentication을 찾아 제거하는 방법을 생각해보았으나, JWT를 이용한 로그인을 구현했기 때문에 애초부터 Context에 Authentication이 저장되지 않았다. 그래서 해당 방법이 아니라, 통신 과정에서 사용되는 토큰을 무력화 할 방법이 필요했다. 여러 선임 분들은 당연히 나와 비슷한 고민을 하셨을거고 그에 대한 답으로 redis를 내놓으셨다. 토큰의 지속 시간만큼만 redis에 해당 토큰을 '활성화'상태로 저장하고, 만일 로그아웃을 하면 '비활성화'상태로 상태를 변경시켜 더 이상 해당 토큰을 사용할 수 없게 만들면 Authentication에 대한 별도의 접근 없이도 로그인, 로그아웃을 구현할 수 있었다. 다만, Refresh Token을 통한 토큰 재발급의 기능까지는 아직 고려하지 않아 좀 더 알아볼 필요가 있다.

 

 다음으로 어려웠던 부분은 게시글에 대한 추천 수 계산이었다. 프리 프로젝트 미션이 stackoverflow의 클론 코딩이었기 때문에, 질문과 질문에 대한 추천 / 비추천 기능은 필수적으로 구현해야했다. 문제는 클라이언트 측에 어떻게 추천수를 넘겨줄까였다. 처음에는 질문 객체가 자신에게 해당하는 추천 / 비추천의 리스트를 가지고있고, 이를 순회하면서 추천 수를 계산하는 방식을 생각해보았다. 그러나 이 방법은 질문을 조회할 때마다 추천 수를 새롭게 계산해야 했으며, 특히 페이징 처리를 할 때는 한 번에 n 개의 질문에 대해 m 개의 추천 / 비추천을 돌아야하니 엄청난 비용적 손해가 발생했다. 그래서 일단은 추천수는 int 값으로 고정을 한 뒤, 이를 계산할 방법이 필요했다.

 

 추천의 구현이 어려웠던 이유는 중복을 방지하는 로직과 연관되어야 했기 때문이었다. 한 명의 사용자가 하나의 질문에 여러 번 추천 또는 비추천 할 수 있다면, 해당 기능 자체가 무가치해지기 때문에 이를 반드시 방지해야했다. 여러 방법이 있겠지만, 내가 선택한 방법은 사용자가 스스로 자신이 투표했는지 여부를 검증하는 방법이었다. 추천 엔티티와 사용자 간의 연관 관계를 만들면 사용자가 자신이 추천 / 비추천한 질문에 다시 한 번 추천 / 비추천을 할 때마다 자신이 가지고 잇는 추천 리스트에 해당 질문이 있는지, 그리고 만일 있다면 그것이 추천이었는지, 비추천이었는지를 알 수 있다. 즉, 추천이나 비추천 기능을 실행할 때만 n만큼의 질문을 순회하기 때문에 O(N*M)만큼 발생하던 비용을 O(N)만큼으로 줄일 수 있었다.

 

 다른 방법으로 생각했던 것은, 질문이 자신에게 추천 / 비추천한 사용자들의 id를 알고 있는 방법이 있었다. 이는 비용적으로 매우 훌륭했다. Hash자료구조에 사용자의 id를 담으면 상수시간만큼의 비용으로 추천 / 비추천 여부를 찾을 수 있었다. 그러나 내가 생각했을 때 이는 질문이 자신의 영역을 넘어선 일을 하고 있다고 판단되어 구현하지는 않았다. 질문 - 사용자의 관계는 N - 1의 관계다. 질문은 자신을 작성한 사용자에 대해서만 알아야지, 여러 사용자에 대한 정보를 알고 있는 것은 지나치다고 생각되었다. 물론 이 생각이 틀렸을 수도 있다. 다만 당시에는 이렇게 생각해서 상수 시간의 이점을 포기했다. 당장의 프리 프로젝트의 기능이 빠르게 작동하는 것보다, 좀 더 원칙적인 사상을 쌓는 과정이 더 중요하다고 생각했기 때문이다.

 

이 외에는 환경 변수 설정이나, 배포에서 겪는 에러들이 몇 가지 있었으나 몇 번의 검색으로 해결이 가능해 크게 어려움을 겪지 않았다. 구글은 최고의 선생님이다.(개인적으로 챗gpt를 이용한 문제 해결을 좋아하지 않는다. 정보의 최신화가 이루어지지 않아 부정확한 경우도 너무 많고, 내 task에 적용시키기 어려운 방법을 알려줄 때도 많았다.)

 

What's to improve

 

 입버릇처럼 '구현보다 분석과 설계가 중요하다.' 라고 주창했지만, 정작 짧은 시간 동안 프로젝트를 완성해야하는 상황에 부닥치니 구현에 더 시선이 쏠렸다. 설계 과정에서 빼먹은 점도 너무 많았고, api 명세서 등의 작성에도 집중하지 못 해 많은 수정이 필요했다. 구현에도 이렇게 작성해놓은 사항들을 반영하지 못 한 점이 너무 많았다.

 

 메인 프로젝트는 프리 프로젝트보다 더 큰 규모의 프로젝트를 하게 된다. 기능 분석과 유즈케이스 분석 등 프로젝트 분석에 더욱 힘써야 할 것이며, 이를 기반으로 프로젝트의 설계를 촘촘히 해나가야 할 것이다. 레시피가 아주 섬세하게 작성돼있는 요리는, 레시피를 무시하지 않는 이상 실패하기 어렵다. 

 

 또한, 이번 메인 프로젝트에서도 팀장 역할을 맡게 될 것 같은데... 역할 분담에 좀 더 세심해져야겠다. 팀원 모두가 함께 성장할 수 있는 프로젝트를 만드는 것이 무엇보다 중요할 것이다. 각자의 역량을 잘 파악해 섬세하게 역할 분담을 해보자.

 

 마지막으로 지난 프리 프로젝트를 함께 진행해주셨던 팀원 분들에게 감사의 말을 전하며, 앞으로 함께 하게 될 메인 프로젝트의 팀원분들에게도 잘 부탁드린다는 말씀을 전하고싶다. 즐거운 시간이 되었으면한다.