12. 26. 40일차 TIL next 팀프로젝트

어떻게 보면 TIL이라기보다는 일기에 가까울 수도 있겠다.

정신이 없는 팀프로젝트가 시작되었고, 이전에 정리했던 내용을 토대로 next의 특징인 서버사이드, 클라이언트 사이드에서의 렌더링 방식을 고민하며 프로젝트에 참여하고 있다.

이번 팀프로젝트는 난이도가 너무 어렵다.

가장 큰 문제는 한 번 결정된 사항이 10분마다 바뀌어서 로직을 반복하여 수정하고 있다는 것이다.

전체적인 코드를 살펴보고 리펙토링하고, 로직을 수정하고를 반복하고 있어 정신이 너무 없다..

내가 담당한 페이지는 my-page 부분인데 일단 로그인 부분을 계속 해서 수정하고 있기 때문에 확인할 수가 없다.

지금은 로그인을 담당한 팀원과 함께 머리를 맞대고 개발 진행 중이며 기능이 Server side에서 잘 작동하길 바라고 있다.

현재 프로젝트에서는 tanstack쿼리를 사용하여 서버 상태를 관리하고, zustand를 사용하여 클라이언트 상태를 관리해야 한다. 이를 활용하여 로그인상태를 server와 client에서 각각 관리를하려고 한다.

---

1. 왜 로그인 상태를 두 가지 side에서 관리하려고 하는가?

1) 보안 강화

우리가 지금까지 진행했던 프로젝트에서는 로그인 시 생성되는 토큰을 로컬스토리지에 저장하고 이를 상태에 저장하여 로그인/로그아웃 기능을 구현하였다. 하지만 서버 사이드 인증을 통해 로그인 상태를 관리하게 되면 클아이언트에서 조작하기 어렵기때문에 민감한 데이터나 인증정보의 보안성을 향상시킬 수 있다고 생각하였다.

그렇기 때문에 클라이언트 측에서는 최소한의 상태를 관리하고, 서버에서는 민감한 데이터를 처리하여 공격면적을 줄이고자 한다.

 

2) 빠른 상태 업데이트 (UX향상)

클라이언트에서 로그인 상태를 즉시 확인하고 UI를 변경할 수 있어 사용자 경험이 좋아질 것이라 생각한다.

 

3) 서버 요청으로 인한 비용 감소

또한 클라이언트 사이드에서 관리를 동시에 함으로써 서버에 요청을 보내지 않고도 로그인 상태를 유지함으로써 서버 요청으로 인한 비용을 절감할 수 있을 것이라고 생각했다.

4) SSR / SSG 지원 (SEO 및 초기 로딩 속도 개선)

서버 사이드에서의 로그인 상태 관리를 통해 페이지를 미리 렌더링하고 로그인 여부에따라 콘텐츠는 맞춤화할 수 있을 것이며 이는 초기페이지 로드 시 사용자 맞춤형 콘텐츠를 제공해 줄 수 있다. 이를 통해 조건부 렌더링을 활용할 때보다 SEO 최적화에 유리해질 것이라고 생각한다.

---

2. 결과적으로 생각하는 로그인 상태 구조는?

1) 로그인 정보 저장 

• 서버 사이드 : 쿠키 또는 세션을 사용하여 민감한 인증 정보를 저장
• 클라이언트 사이드 : 사용자 ID, 닉네임과 같이 비민감한 데이터를 zustand로 관리

2) 로그인 상태 확인

• 서버에서 API 호출 시 인증 여부를 검증
• 클라이언트에서 상태를 빠르게확인 후 UI를 업데이트

3) 최적화된 상태 동기화

• 클라이언트에서 상태를 임시로 유지하되, 필요할 때 서버에 요청하여 상태를 검증하고 동기화.

---

3. 결론 - 서버와 클라이언트 로그인 상태를 함께 관리

장점

• 보안과 성능을 적절히 균형 맞출 수 있음.
• 사용자 경험 향상 및 SSR의 이점 제공.

단점

• 코드 복잡도 증가.
• 상태 동기화 및 유지보수에 추가적인 노력 필요.

---

근데.. 이게 일주일 동안 진행하는 미니 프로젝트에서 적용할 사항으로 적합한가 의문이 든다 ㅠㅠ
zustand를 사용할 로직을 생각하지 못해 이런 방식을 고민하였지만 과연 이런 방식이 효율적일까?