[우테코] 스프린트4 회고

Sally·2022년 8월 30일
0
post-thumbnail

레벨 3의 마지막

스프린트4는 우테코에서의 레벨 3에서의 마지막 스프린트 기간이였다. 다음 레벨에서는 주어지는 미션을 수행해야 하기 때문에 이번 스프린트가 온전히 우리의 팀 프로젝트에만 집중할 수 있는 마지막 기간이였다.
그래서 우리 팀의 스프린트 4의 목표는 최대한 기능을 구현 해 놓기 였다.

목표했던 기능은

  • 리프레시 토큰으로 로그인 유지 하기
  • 이미지 URL 길이 줄이기
  • 해시태그로 게시글 검색할 수 있도록 하기
  • 마이페이지 수정하기
  • 게시물 추천하기
  • 유저별로 작성한 글을 볼 수 있는 검색
  • 버그 수정들
  • 자잘한 UI 수정

이였다.

개수는 많아도 금방 끝낼 수 있을 줄 알았는데 예상치 못한 복병을 만나버렸다.
수도권 일대에 물난리가 난 그날,
나 역시도 잠실쪽에 있었고 물난리로 집에 겨우겨우 들어갔다.
그리고 그 다음날 온라인으로 재택을 진행하였고 그 다음날 난 코로나에 확진됐다.
코로나 아플지는 알았는데 이렇게 까지 아플지는 몰랐다
몸의 컨디션이 하루종일 왔다갔다 했기 때문에 코딩에 제대로 집중하기 힘들었다. 게다가 격리 기간동안 나머지 프론트 크루 한 명이 테코톡 준비를 한다고 며칠간 팀 기능 개발에 시간을 많이 투자하지 못하여서 나머지 일들도 다 내 몫이 되었다. 팀원이 야속하기도 했지만, 뭐 어쩌겠나 할 건 해야지 약으로 어떻게 연명하면서 결국은 기능들을 완성시킬 수 있었다.
내 몸의 한계를 시험해보면서도 나의 건강과 팀의 성취 사이에서 어떻게 밸런스를 유지해야하는지 고민이 되는 주간이였다.😢
그런데 이렇게 한 번 각성되고 나니 이젠 두려운게 없어...

왜 이 기능들을 구현하였을까?

이번 스프린트 동안 개발한 기능들에 대해서 몇 가지를 소개해보고자 한다.

리프레시 토큰으로 로그인 유지하기

리프레시 토큰을 도입하게 된 이유는 간단하다. 유저의 사용성을 위해서이다.
기존의 accessToken의 유효시간이 고작 30분이였기 때문에 사용할 수 있는 시간이 짧았다. 그리고 새로운 accessToken을 발급받기 위해서는 새롭게 로그인 요청을 보내야 했기 때문에 브라우저를 열어놓고 계속해서 사용하는 유저들에게는 여간 불편한 일이 아닐 수 없다.

그래서 우리가 도입한 리프레시 토큰의 프로세스는 이러하다

최초 로그인을 하였을 경우 accessToken과 refreshToken을 같이 발급해준다 ->
요청마다 accessToken이 담겨져 보내지게 되는데 해당 accessToken이 유효하지 않으면 1005번 에러를 던지게 된다 ->
1005번 에러가 발생할 경우 쿠키에 저장된 refreshToken을 가지고 새로운 accessToken발급 요청을 보낸다. ->
해당 refreshToken이 유효한 경우, 새로운 accessToken이 발급되게 된다.

사실 프론트엔드에서는 리프레시토큰을 브라우저의 쿠키에 저장하는 것에 큰 힘을 들일 필요가 없었다.
백엔드와 프론트엔드에서 같은 도메인을 공유하고 있기 때문에 백엔드에서 쿠키에 리프레시 토큰을 담아 보내면 유저의 브라우저에 해당 쿠키가 저장이 된다.
*다만 , 리프레시 토큰 관련된 권한들 몇개를 허가 해주어야 한다.

이미지 URL 길이 줄이기

이 기능이 필요하게 된 이유는 우리 팀에서 TOAST Editor를 사용하기 때문이다.
우리 팀의 서비스의 가장 큰 줄기는 모르는 것을 질문하는 것이다.
그 중에서도 프로그래밍과 관련된 질문을 하는 것을 주 타겟으로 잡았기 때문에 코드와 이미지 등에 대한 작성이 쉬워야 했다.

이를 위해선 마크업 문서가 작성이 가능해야 했는데 주어진 시간 동안 문서 에디터까지는 개발하기 힘들었기 때문에 외부 라이브러리인 TOAST Editor을 사용하게 되었다.

그런데, 해당 TOAST Editor에는 큰 단점이 있었으니 바로 이미지를 올렸을 때의 url 길이이다.
TOAST Editor는 유저가 이미지를 올리게 되면 url로 변환하여 관리하게 되는데 해당 url의 길이가 약 10만줄 정도는 된다. 거짓말이 아니다 직접세봤다
이미지를 올린 순간 부터 이미 문서를 작성하는 곳이 이미지 url로 가득 차버리게 된다. 그 혼돈 속에서 유저가 글을 작성하는 것이 매우 불편해진다.
그래서 우리 팀에서는 해당 이미지 url길이를 줄이는 것이 필수적이였다.

url이미지 길이를 줄이기 위해서,
이미지 전용 EC2 인스턴스를 하나 만들었다. 그 후 프론트에서는 TOAST Editor에서 이미지가 올라갔을 때 이를 감지하여 폼 데이터에 파일을 넣어서 백엔드에게 보내게 되고 백엔드에서는 해당 blob을 서버에 저장하고 새로운 url을 보내주었다.
이 과정을 통해서 이미지 url을 한 줄로 줄일 수 있었다.

해시태그로 검색하기

인스타그램과 트위터로 인해서 해시태그로 게시물을 검색하는 것은 대중에게 매우 익숙해졌다. 작성자의 경우 자신이 작성한 글에 대해서 키워드를 정하여 글에 대한 주제를 독자들에게 소개하고 글에 대한 유입을 키울 수 있다. 독자의 경우 자신에게 필요한 글을 해시태그를 통해서 필터링 하여 빠르게 찾을 수 있다.

이러한 장점들을 가진 해시태그가 우리 팀의 목표인 유저가 궁금증 해소를 빠르고 쉽게 할 수 있도록 하자 라는 것을 달성하는데 도움이 될 것 같아서 도입하게 되었다.

0개의 댓글