4주차 회고(231210 ~ 231217)

4주차를 맞이한 팀 프로젝트 멘토링. 우리 팀은 계획대로라면 이번주까지가 1차 스프린트였는데, 일정이 살짝 밀리면서 추가 기능 도입은 멘토링 종료 이후로 넘기게 되었다. 아무튼 이번주 회고도 시작!

 

1. 무슨 일이 있었나요?

이번 주도 거의 기능 개발에 몰두했다. 자잘하게 디자인을 수정하는 등 다른 업무도 있었지만, 전반적으로 1차 스프린트를 무사히 완료하는 것에 중점을 두었다.

 

(1) 구글 로그인 구현

이번 주에는 소셜 로그인을 구현했다. 원래 카카오톡 로그인도 구현하려고 했는데, 소셜 로그인 구현이 처음이라 생각보다 많은 시간을 소요하는 바람에 구글 로그인만 구현했다.

 

 

 

(2) OpenFeign vs WebClient

소셜 로그인을 도입하면서 소셜 서비스에 요청을 보낼 일이 생겼다. API만 개발하던 나에게 다른 서버로 요청을 보내보는 일은 처음이라 많은 고민을 했다. 많은 예제 코드들이 RestTemplate으로 작성되어 있었지만, RestTemplate이 deprecated 될 뻔했다는 소식을 접할 수 있었다. 때문에 OpenFeign과 WebClient 둘 중 하나를 선택하기로 마음먹었고, 다음과 같은 이유로 OpenFeign을 선택했다.

• Spring Data JPA처럼 인터페이스만 선언하면 구현체는 알아서 생성되기 때문에, 쉽고 빠르게 작성할 수 있다. 
• 로그인 과정은 구글 서버로부터 사용자 정보를 받아야 다음 작업을 진행할 수 있으므로, 비동기식으로 동작할 필요가 없다.

실제로 써보니 정말 간단해서 Feign을 선택하길 잘했다고 느꼈다. 사용할 때도 메서드를 호출하면 끝이라, 코드의 가독성을 유지하며 외부 API를 호출할 수 있었다.

 

(3) 로그인 구현 방법 결정

사용자 정보도 성공적으로 받아왔으니 이제 끝이라고 생각했지만, 고민은 끝이 없었다🥲 세션 이용 / JWT 사용 / 리프레시 토큰까지 사용 등등.. 로그인을 구현하는 너무 많은 방법들이 존재했다.

결론적으로 JWT를 이용한 액세스 토큰을 이용하는 대신 유효기간을 짧게 가져가기로 했다. 일반적으로 많이 사용하는 방법이고, 그만큼 자료도 많았고, 액세스 토큰 탈취 시에도 유효기간이 짧아 큰 문제는 없을 것이라 생각했기 때문이다. 대신 사용자 경험 향상을 위해 유효기간이 긴 리프레시 토큰을 도입했다.

 

물론 이후에도 아래와 같은 고민들이 생겨났다.

• 리프레시 토큰 생성에 UUID를 이용할지, JWT를 이용할지
  결론적으로 UUID를 이용하기로 했다. JWT의 가장 큰 장점은 '페이로드에 정보를 담고 있기 때문에 DB를 조회할 필요가 없다'는 점인데, 리프레시 토큰은 DB에 저장할 예정이기 때문에 JWT를 사용하나 마나 의미가 없기 때문이었다. 
• 로그아웃 처리는 어떻게 할 것인지
  DB에 블랙리스트를 만들고, 로그아웃 시 액세스 토큰을 블랙리스트에 등록하는 방법이 있었다. 하지만 이 방식은 매 요청마다 DB를 조회해야 하기 때문에 비효율적이라고 생각했다. 애초에 유효기간을 짧게 설정한 것도 액세스 토큰이 탈취당했을 때 문제를 최소화하기 위해서였다고 생각했으므로... 액세스 토큰 삭제는 프론트 쪽으로 넘기고, 백에서는 리프레시 토큰만 삭제해주기로 했다 :)
• 리프레시 토큰을 레디스에 저장할 때, key를 memberId로 둘지, 아니면 토큰값으로 둘지
  처음에는 memberId로 뒀었는데, 그렇게 되니 로그아웃을 할 때도 액세스 토큰을 파싱해야 했다. 그래서 토큰값을 key로 지정했다.

 

(4) 레디스 사용

리프레시 토큰을 도입하면서 자연스럽게 레디스를 도입하게 되었다. 그냥 MySQL에 저장해도 괜찮지만..! 아래와 같은 이유로 레디스를 도입했다.

• TTL 설정 가능: 만료시간이 되면 자동으로 삭제 처리되어 토큰 관리가 편리하다.
• 빠른 액세스 속도: 사용자는 30분(=액세스 토큰의 유효기간)마다 액세스 토큰 갱신을 위해 DB 조회 요청을 보낸다. 리프레시 토큰의 유효기간은 2주이므로 호출 빈도는 높은 반면에, 삽입 및 삭제 빈도는 낮다.
• 데이터 손실 여파가 적음: 레디스는 MySQL에 비해 불안정하지만, 데이터가 다 날아가도 일어나는 일은 '모든 사용자가 재로그인을 하는 일'뿐이다. 회원 데이터가 날아가거나, 게시물이 날아가는 일에 비해 치명적인 문제는 아니다.

레디스 사용은 처음인데 생각보다 훨씬 간단해서 놀랐다. 물론 내가 겉핥기식으로 사용하고 있는 것도 있겠지만🤧

 

(5) 팀원과 함께 DB 조회 시 Exception이 발생하는 에러 해결

이번 주에는 프로젝트 배포를 진행했는데, 서버에서 배포 DB의 데이터가 조회되지 않는 문제가 발생했다. 로컬에서는 정상적으로 동작했기 때문에 비즈니스 로직에 문제가 있을 가능성은 크지 않았지만, 제대로 확인하기 위해 코드를 구석구석 살펴보았다. 예상했던 대로 코드에서는 문제가 있을만한 부분을 발견하지 못했다. 

 

환경설정의 문제인가 싶어 application.yml 파일을 확인했지만, DB 주소도 정상적으로 기입되어 있었다. 마지막으로 배포 서버의 로그를 확인해보았더니, 데이터베이스가 MySQL이 아니라 H2가 연결되어 있었다. 배포가 잘못되었다는 생각에  jar파일에 들어있는 파일들을 확인했는데, application.yml을 찾을 수가 없었다. 도커파일에서는 분명 application.yml을 생성했는데...🤔

 

설마 도커파일 문제일까? 싶어 터미널에서 도커파일을 그대로 따라쳐보니 application.yml이 resources 폴더 내부가 아니라 외부에 생성되고 있었다😂 cd resources 명령어를 추가해줌으로써 오류를 해결했지만, 겨우 명령어 한 줄 때문에 1시간 30분 가까이를 헤맨 건 조금 허탈했다. (나중에 여쭤보니 매니님은 훨씬 더 많은 시간을 태우셨다고..🥲)

 

그 외에도 다양한 문제들을 해결했고, 매니님과 함께 어떤 해결방법이 가장 좋을지 고민하는 시간을 가질 수 있었다. 부트캠프에서 프로젝트를 진행했을 때는 어떤 방법이 더 좋을지 고민할 시간조차 없었는데, 부트캠프에서는 신경쓰지 못했던 부분들까지 챙길 수 있어서 너무 좋았다!

 

(6) 앞으로의 계획 고민

프론트 측으로부터 기능 구현 완료에 시간이 더 걸릴것같다는 의견을 전달받았다🥲 그래서 멘토님께 프론트의 부담이 적고 백에서 해볼만한 추가 기능을 추천해달라고 부탁드렸다. 멘토님의 추천은 캐시!

 

캐시를 어떤 부분에 적용하면 좋은지는 CS 스터디를 통해 알아본 적 있었지만, 멘토님께서 '어디에 캐시를 둘 것인지', '왜 인기순 정렬에 캐시를 사용하면 좋은지'를 실제 프로젝트를 중심으로 설명해주시니 훨씬 와닿았다✨

• 매 조회마다 게시물 테이블과 좋아요 테이블의 JOIN 연산이 발생하고 있음
• 하지만 사용자마다 조회하는 내용이 동일함
• 최신순 정렬과 달리 결과값이 자주 바뀌지 않고, 좋아요 개수는 사용자에게 조금 덜 정확한 정보를 보여줘도 큰 문제가 없다.
  (최신순 정렬은 변경된 내용을 바로 반영해주지 않으면 사용자에게 오해를 불러일으킬 수 있다.)

---

2. 좋았던 점

• 이유 있는 선택을 했다. 기술을 도입할 때도 왜 그 기술인지를 고민했고, 에러를 해결할 때도 해결 방법이 여러가지라면 팀원과 함께 고민하는 시간을 가졌다.
• 에러가 발생하면 누가?를 묻기보다 왜?를 먼저 물었고, 팀 전반적으로 자신이 담당한 파트가 아니어도 팀원과 적극적으로 에러를 해결했다.

---

3. 아쉬웠던 점

• 지난 주 대비 참여율이 저조했다. 사실 코드를 안 짜는건 큰 문제가 되지 않는데, 팀원의 PR 요청을 제때제때 확인할 수 없는 건 협업 진행에 치명적이었다. (백엔드 인원이 2명이라 내가 확인해주지 않으면 셀프 머지를 해야한다ㅜㅜ)
• 다른 사람의 코드를 너무 많이 참고하는 것 같다. 어떻게 작성하지? 보다는 왜 이렇게 작성했을까!를 생각하는 시간이 좀 길었다.
• 프로젝트 일정이 조금 밀렸다. 근데 내가 팀장이다...😂

---

4. 그래서 어떻게 할 건가요?

• 당분간 개인 일정 자제하기. 5주차는 프로젝트에 온전히 집중하자🔥
• 다른 사람의 코드를 보고 의도를 고민하기보다는, 일단 내 코드를 작성하고 레퍼런스와 상충되는 부분에 대해서만 고민해보자.
• 팀원들의 업무 진행 상황을 면밀히 파악해보고, 일정이 밀리면 적절한 해결책을 찾아보자.