실무 경험이 없는 사람으로서 회사 생활에 대한 막연한 두려움과 기대가 있었다. 잘하고자 하는 마음과 완벽히 해내야 한다는 욕심이 범벅된 상태로 '그게 뭐든 무조건 많이 배우고 나오자' 되뇌며 홍대 입구역 1번 출구를 나왔다.
'애즈위메이크'
애즈위메이크는 동네 중대형 할인마트 반경 3km에 거주하는 소비자를 대상으로 주문 후 70분 이내 즉시 배달하는 식료품 장보기 앱 '큐마켓'을 운영 중인 회사다.
이들은 40-59세 주부들에게 ‘전단지’가 주는 역할이 지대함을 알았고, 오프라인 마트라면 어디나 진행하는 주기적 할인 프로모션인 '전단지'를 업로드 할 수 있는 어플 출시를 목표로 하고 있었다.
자유롭고 젊은 분위기 속에서 시작된 우리의 임무는 전단지를 이용한 서비스의 어플을 개발하는 것. 앞선 기수의 개발자 분들이 먼저 진행중이었고 우리가 더해져 주어진 한달 안에 배포까지 완료시키고자 했다.
1. 첫 주에는
디자인이 완성되지 않아 일의 진행 속도가 현저히 떨어졌다. 그러나 시간을 버릴 수 없었기에 이미 짜여진 코드를 해석하고 이해하기로 했다. (이 과정이 없었더라면 일에 착수하고 나서도 꽤 많이 헤매지 않았을까 싶다.)
코드의 흐름과 스타일을 어느 정도 익히고 나니 디자인도 끝이 보였고 할당된 일을 하나씩 해 나갈 수 있었다.
2. 맡은 바 충실히
사용하는 기술 스택이 이전의 프로젝트들과 다르지 않아 시작에는 어려움이 없었다. 하나 둘 일을 쳐내는 과정에 장애물이 없을 수는 없었고, 좌절과 극복의 반복은 여전했다. 차이가 있다면 이 프로젝트의 끝은 좌절이었다는 점 🥲
회원정보 수정
회원 정보 수정 페이지는 모두 모달창으로 띄웠다.
처음에는 end point를 다르게 주어 각기 다른 페이지로 구현할까 했는데, 그렇게 되면 end point와 토큰만 알면 개인 정보에 쉽게 접근할 수 있을거란 판단하에 모달을 선택하게 되었다.
회원 정보를 수정한 뒤 수정 창이 닫히면 마이페이지의 정보들이 수정된 정보로 바뀐다. 수정 창이 완전히 다른 페이지라면 상관 없겠지만 모달로 띄우고 있었으므로 바뀐 정보를 바로 적용시키기 위한 고민이 시작됐다.
처음에는 마이페이지로 이동했을 때 fetch문으로 다시 데이터를 불러오려 했다.(완전히 다른 페이지로 구성되어 있었다면 가능했을 것이다.) 그러나 플로우상 말이 안되는 조치였고, 수정 사항을 백엔드에 보냄과 동시에 해당 변화가 바로 화면에도 나타나도록 하는 방법이 필요했다.
▲ Props로 넘겨받은 userInfo state를 수정된 정보로 바꾸고 state 끌어올리기를 통해 마이페이지에 적용되도록 구상했다.
다행히 단번에 적용이 됐고, 큰 무리 없이 마무리 되는 것 같았다.
❗️자동 로그인
이번 프로젝트가 좌절로 끝을 맺었다고 얘기한 이유가 바로 여기 있다.
결론부터 말하자면, 실패다.
우리는 보안을 위해 access token(유효기간 30분)과 refresh token(유효기간 2주)을 같이 사용했다.
구글링 결과 거의 모든 플로우는 access token 만료시 프론트엔드에서 refresh token을 이용해 access token을 요청하고, 요청이 있을 때 백엔드에서 토큰을 재발급해주면 재발급된 토큰을 로컬스토리지에 저장하는 흐름이었다.
하지만 우리는 좀 달랐다.
access token이 만료되면 별도의 요청이 없어도 토큰이 새로 발급 되도록 백엔드에서 로직을 구현해놨다. 프론트에서는 계속해서 갱신되는 토큰을 로컬 스토리지에 업데이트 해야 하는데... 그게 죽어도 안되는거다. 그래 어쩐지 순항한다 싶었지
- 처음에는 유저가 로그인 하는 순간으로부터 access token이 만료되기 1분 전에 로그인이 연장 되도록 로직을 구현했다. (참고 자료)
그러나 아무리 수정을 거듭해도 원하는 결과가 나오지 않아 노선을 변경하는데 그마저도 어려워 새벽까지 온갖 자료를 다 열어봤던 기억이 난다.
- 마지막이라는 생각으로 axios interceptor를 적용하고자 아래와 같이 코드를 작성했다.
앞서 스포한 대로 이 마저 작동하지 않았고, 미련 뚝뚝 흘리며 프로젝트는 마무리 되었다. (이 때가 이미 프로젝트의 마지막 날이었기에 더 이상 손 써볼 시간이 없었다.)
아쉬움을 뒤로하고 이제는 실패의 원인을 찾아야 한다.
검색 해보니 위의 코드에서 instance로 지정해둔 URL을 계속 사용했어야 했다. 즉, 우리는 처음부터 모든 통신을 fetch로 작성했기 때문에 axios가 적용되지 않았던 것이다!
그렇지, 생각해보니 사용하지도 않을 instance를 선언해 둔 이유는 전혀 없겠구나. (추후에 fetch에도 interceptor를 적용할 수 있다는 글을 봤는데 차차 다뤄봐야지)
'애즈위메이크'의 일원이 되다(2) 에서 계속...
