23.06.25 ~ 23.07.02

업무 공유

1. 채팅방 내 보호자 접근 시, 소셜 로그인 및 서비스 회원가입

현재 앱 내 보호자와 미용사가 메시지를 주고받을 수 있는, 채팅 기능이 존재한다.

이 중 보호자는 미용사가 전송한 카카오 메시지를 통해 채팅방에 접근할 수 있는데,

이때 해당 페이지에 접근 시 카카오 소셜 로그인 → 정보 저장(회원가입) → 채팅방 열람 의 flow가 추가되었다.

 

채팅 기능은 웹을 통해 기존 앱에서도, 카카오 템플릿에서도 접근이 가능하도록 되어 있는데...

기존 앱에서는 앱 내 local storage에 토큰을 저장한 후, api 요청 시 header에 토큰을 실어 보내고 있었다.

물론 웹에서도 local storage에 토큰을 저장할 수는 있었지만,

이 경우 server side에서 해당 토큰을 조회할 방법이 사라지므로 해당 페이지는 서버 측에서 실행할 수 없었다.

 

팀원들과 논의한 결과, 해당 이유로 SSR의 강점을 포기하기보다는,

cookie를 통해 서버 측에서 토큰을 조회하는 방식으로 권한/인가 를 구현하기로 했다.

 

즉 채팅 페이지 내 접근 시

1) cookie에 token이 존재하지 않을 경우 로그인 페이지로 강제 redirect했고,

2) 로그인 페이지에서 카카오 소셜 로그인을 통해 사용자의 정보(전화번호, 성별 등)를 조회한 후

3) 해당 데이터를 통해 회원가입 요청을 보내는 형태

로 회원가입 flow를 작성했고

 

4) cookie에 token이 존재할 경우 해당 토큰으로 로그인 요청

5) 로그인 정보(카카오 소셜 로그인 전화번호)와 채팅방 정보(접속한 채팅방에 해당하는 보호자의 전화번호)를 비교해

6) 유효한 사용자가 아닐 경우 invalid 페이지로 강제 redirect

7) 유효한 사용자일 경우 채팅 서비스 사용

과 같은 흐름으로 login을 구현했다.

 

2. 미용샵 랜딩 페이지 static site generation 으로 변경

팀의 스프린트 목표는 상담지 생성 건 수를 늘리는 것이었다.

이를 위해 포스터를 제작하고 베타테스터 샵들에게 뿌렸는데...

포스터 속 QR 코드를 찍으면 나오는 랜딩 페이지를 SSG로 변경했다.

 

그 이유는

1) 미용샵 정보를 보여주는 페이지 → build 시점에서 데이터를 불러와 미리 HTML 그릴 수 있음

2) 잦은 변경 X → 매 요청바다 server에서 해당 HTML을 그릴 필요(SSR)가 없음

사실 처음 해당 페이지를 설계했을 때부터 SSG의 이점이 훨씬 컸다.

 

현 베타테스터 중 상담지가 10건 이상 생성된 샵들만 동적 경로(static path)를 지정해 주었으며,

지난 스프린트에서 미용샵의 추가 정보(이미지, 운영 시간 등)가 추가되고 이를 수정할 수 있게 되면서

revalidate 옵션을 통해 가장 마지막 생성으로부터 일정 시간이 흐른 후, 새로 해당 HTML을 그려줄 수 있게 하였다.

 

회고

1. 결국 해봐야 안다.

개발을 시작하고부터 지금까지, 매 순간 느끼는 점. 결국 해봐야 아는구나.

 

처음 cookie를 도입하기로 했을 땐, 아무런 걱정이 없었다.

왜? 무엇인지, 어떻게 사용해야 하는지 다 알고 있다 생각했었으니까!

 

하지만 결국 개념을 실제로 구현했을 때 확실하게 이해되는 법이고,

그러니 두려움 없이 최대한 빨리 실패를 경험하는 것이 중요함을 다시 한번 느낄 수 있었다.

함께 끙끙거린 팀원들에게도 감사!

• httpOnly
• sameSite
• domain

등의 cookie 옵션을 명확히 이해했던 한 주!

 

2. 출퇴근 시간을 활용하자.

정보처리기사 실기 시험을 접수했다.

필기를 준비할 때는 한 달 전부터 출근길마다 요약 영상을 틀어두곤 했는데,

실기는 한 달도 안 남았는데도... 영 집중이 안 되는 느낌.

 

기본 코딩, SQL만 알면 무난히 합격한다는 후기를 봐서 그런가, 마음이 느슨해진 듯하다.

퇴근 후 클라이밍이나 다른 FE 세미나를 보기 위해서라도 미리미리 + 틈틈이 해둬야 하니...

다음 주부터는 출근길에 C, JAVA 기본 개념 및 문제를 풀어볼 예정!