Watcher Habit: 습관 공유 플랫폼 🌱

💁‍♀️ 소개

Watcher Habit은 개인의 습관을 효과적으로 관리하고, 소규모 그룹과 습관을 공유하는 플랫폼입니다. 사용자들이 서로의 습관을 공유하며, 서로를 지켜보면서 동기부여를 얻을 수 있습니다. 이를 통해 습관의 지속성을 높이고, 그룹 내의 동료들과 함께 성장하는 경험을 할 수 있습니다.

📹 시연 영상: Watcher Habit 시연 영상 유튜브 링크

🛠️ 기술 스택

프론트엔드

백엔드

👀 목차

💡 프로젝트 동기

  1. 기술적 도전과 학습 동기

  2. 습관 기록을 통한 동기 부여

  3. 웹 애플리케이션 'Watcher Habit' 탄생

🚧 도전 및 문제 해결

  1. 실시간 알림

    1) 실시간 알림의 중요성과 필요성

    2) 알림 전송 방법의 선택과 SSE의 도입

    3) 실시간 알림 구현 상세

    4) 실시간 알림 기능 구현 결과

    5) SSE의 한계와 웹소켓을 사용하지 않아서 생긴 아쉬운 점

  2. 로그인 과정에서의 보안 고려사항

    1) 사용자의 데이터를 안전하게 저장

    2) 사용자의 데이터 관리를 위한 토큰 기반 선택

    3) 토큰 관리와 갱신 메커니즘

  4) 구현 결과

🔗 Repository 주소

💡 프로젝트 동기

1. 기술적 도전과 학습 동기

• 신기술 도입 경험: 새로운 기술과 라이브러리를 실전 프로젝트에 적용해보고, 이를 통해 기술적 역량을 확장하고자 했습니다. 안정적인 기술 스택을 활용하면서도, 프로젝트의 효율성을 높이는 방법을 탐구하는 데 중점을 두었습니다.

2. 습관 기록을 통한 동기 부여

• 아이디어 배경: 개인적으로 습관 형성을 기록하고 있었지만, 혼자서만 기록하다 보니 지속적인 동기 부여에 한계가 있음을 느꼈습니다. 이러한 문제를 해결하기 위해, 습관을 서로 공유하고 함께 확인할 수 있는 소규모 그룹을 형성하는 아이디어를 떠올리게 되었습니다. 이 아이디어는 리액트를 사용해 충분히 구현 가능하면서, 관리해야 할 상태가 많아 상태 관리 툴의 필요성도 예상되었습니다. 또한, 서버와 클라이언트를 분리하여 작업하는 등 기존 프로젝트와는 다른 기술적 도전을 포함하고 있었습니다.

3. 웹 애플리케이션 'Watcher Habit' 탄생

• 프로젝트 개요: 팀원들의 기술적 흥미와 습관 기록 아이디어가 결합되어, 서로의 습관을 모니터링하고 동기를 부여할 수 있는 웹 애플리케이션 'Watcher Habit'이 탄생했습니다. 이 애플리케이션은 사용자들이 서로의 습관을 지켜보며 격려하고 지원할 수 있는 기능을 제공하여, 더 효과적인 습관 형성을 돕습니다.

🚧 도전 및 문제 해결

3주 동안 개발을 진행하면서 겪었던 서버와 클라이언트에서 발생한 핵심적인 문제들을 정리해 보았습니다.

1. 실시간 알림

1) 실시간 알림의 중요성과 필요성

프로젝트의 핵심 기능 중 하나는 사용자가 어플리케이션 내에서 발생하는 다양한 이벤트들에 대해 실시간으로 알림을 받는 것이었습니다. 이를 통해 사용자는 새로운 그룹 초대, 습관 확인 요청, 알림 승인 요청 등의 이벤트를 즉각적으로 인지하고 반응할 수 있어야 했습니다.

2) 알림 전송 방법의 선택과 SSE의 도입

실시간 알림을 구현하기 위한 여러 방법 중, Server-Sent Events (SSE)를 선택한 이유는 다음과 같습니다:

• 간단한 구현: SSE는 웹 표준 기술로서 구현이 간단하며, 추가적인 라이브러리나 프레임워크 없이도 웹 서버와 브라우저에서 지원됩니다.
• 자동 재연결: 만약 네트워크 문제로 연결이 끊어졌을 때, SSE는 자동으로 재연결하는 기능을 내장하고 있어, 별도의 재연결 로직을 구현할 필요가 없었습니다.
• 단방향 통신으로 충분히 구현 가능하다고 판단: 프로젝트에서 필요한 알림은 받기만 하면 서버에서 다른 작업을 해주지 않아도 되는 것으로 기획했기 때문에, 단방향 전송 방법인 SSE로 충분히 구현이 가능했습니다.

3) 실시간 알림 구현 상세

프로젝트에서는 initEventSource 함수를 사용하여 SSE 연결을 초기화하였고, 연결이 성공적으로 이루어지면 서버에서 클라이언트로 알림 데이터를 전송합니다. 이를 수신한 클라이언트는 알림 메시지를 화면에 표시하며, 일정 시간 후에는 자동으로 알림을 화면에서 제거합니다.

4) 실시간 알림 기능 구현 결과

SSE를 도입함으로써 사용자는 어플리케이션에서 발생하는 중요한 이벤트들을 실시간으로 확인할 수 있게 되었습니다. 이를 통해 사용자는 필요한 정보나 요청을 즉시 확인하고 처리할 수 있게 되어 사용자 경험의 향상을 이룰 수 있었습니다.

또한, 서버에서 클라이언트로의 실시간 통신 구현으로 인해 프로젝트의 동적인 상호작용이 확대되었습니다.

5) SSE의 한계와 웹소켓을 사용하지 않아서 생긴 아쉬운 점

우리 프로젝트에서는 SSE를 사용하여 실시간 알림 기능을 구현하였습니다. SSE에는 다양한 장점이 있지만, 동시에 웹소켓에 비해 몇 가지 한계점이 있습니다.

SSE의 한계

• 단방향 통신: SSE는 서버에서 클라이언트로의 단방향 통신만 지원합니다. 이로 인해 클라이언트에서의 동작이 서버에 실시간으로 반영되기 어렵습니다. 예를 들면, 알림에서의 특정 액션을 서버에 즉각적으로 반영하는 것이 어렵습니다.

• 지속적 연결 유지: 많은 사용자가 동시에 SSE 연결을 유지할 경우 서버에 부하가 증가하게 됩니다. 현재 연결된 유저 id를 모두 connection으로 모아놓고 있는데 이 크기가 커지면 서버 내에서 메모리를 계속해서 많이 차지할 수 있기 때문에 부하가 증가하는 요인이 됩니다.

웹소켓의 장점 및 프로젝트에서의 아쉬움

• 양방향 통신: 웹소켓은 서버와 클라이언트 간의 양방향 통신을 지원합니다. 이로 인해 알림창의 실시간 갱신과 같은 기능을 더 효율적으로 구현할 수 있습니다.

• 알림창 실시간 갱신: 프로젝트에서는 리액트 쿼리를 사용하여 10초마다 알림을 조회하는 방식을 채택하였습니다. 웹소켓을 사용했다면, 서버에서 신규 알림 발생 시 클라이언트에 즉시 전송하여 알림창을 실시간으로 갱신하는 것이 가능했을 것입니다.

• 효율성 및 네트워크 최적화: 웹소켓은 데이터를 전송할 때 헤더가 불필요하여, 네트워크의 오버헤드가 적습니다. 따라서, 실제로 알림이 발생했을 때만 데이터를 전송하게 되어 네트워크 리소스를 보다 효율적으로 사용할 수 있습니다.

• 확장성: 웹소켓은 다양한 실시간 기능에 대한 확장성이 높습니다. 프로젝트의 발전에 따라 다양한 실시간 상호작용 기능을 추가할 때, 웹소켓의 양방향 통신 능력을 활용하면 보다 효과적으로 구현할 수 있었을 것입니다.

결론적으로, SSE는 현재 저희 프로젝트에서 필요한 기능을 빠르고 간편하게 구현하는 데에는 충분하였습니다. 하지만 미래의 프로젝트 확장성을 고려한다면, 웹소켓은 많은 기능을 보다 효과적으로 구현할 수 있는 강력한 도구로 작용할 것 같습니다. 따라서, 다음 단계의 개발에서는 웹소켓의 도입 및 활용을 고려해볼 필요가 있다고 생각됩니다. 이를 통해 사용자 경험을 더욱 향상시키고, 프로젝트의 기술적 한계를 넓힐 수 있을 것으로 기대됩니다.

2. 로그인 과정에서의 보안 고려사항

1) 사용자의 데이터를 안전하게 저장

왓처해빗 프로젝트에서는 사용자의 데이터를 안전하게 관리하기 위해 JWT 토큰 기반의 로그인 시스템을 구현했습니다. 사용자가 로그인을 통해 서버에 데이터를 저장할 수 있으며, 어느 기기에서나 언제든지 접근할 수 있도록 보장했습니다. 이 과정에서 가장 중요한 고려사항은 클라이언트 측에서 토큰을 안전하게 저장하고, 토큰의 갱신과 만료 처리를 효과적으로 관리하는 것이었습니다.

2) 사용자의 데이터 관리를 위한 토큰 기반 선택

• XSS 공격 방어: 사용자 토큰을 XSS(크로스 사이트 스크립팅) 공격으로부터 보호하기 위해, 토큰 저장 방법을 신중하게 선택했습니다. 특히, JavaScript 접근을 차단할 수 있는 HttpOnly 쿠키를 선택하여 토큰을 저장함으로써, 악성 스크립트가 토큰에 접근하는 위험을 최소화했습니다.

• 토큰 탈취 방지: 용자의 토큰이 탈취당하는 악용을 방지하기 위해, 액세스 토큰의 수명을 짧게 설정하고, 리프레시 토큰을 사용하여 만료된 액세스 토큰을 재발급하는 방식을 도입했습니다. 이로써, 토큰이 탈취되더라도 그 유효 기간이 짧아 악용될 가능성을 줄였습니다.

3) 토큰 관리와 갱신 메커니즘

• 안전한 토큰 저장 방법: JavaScript가 접근할 수 없는 HttpOnly 쿠키를 사용해 토큰을 저장함으로써, 클라이언트 측에서의 토큰 보안을 강화했습니다. 이 방법을 통해 XSS 공격으로부터 토큰을 보호할 수 있었습니다.

• 토큰 갱신 메커니즘: Axios Interceptors를 활용하여, API 호출 전에 토큰의 유효성을 검증하는 시스템을 구축했습니다. 만약 액세스 토큰이 만료된 경우, 리프레시 토큰을 통해 새로운 액세스 토큰을 받아오고, API 호출을 계속 수행할 수 있도록 구현했습니다.

• 리프레시 토큰 만료 처리: 리프레시 토큰이 만료된 경우, 사용자가 다시 로그인을 해야 하는 상황을 고려하여 로그인 페이지로 리다이렉트하도록 설정했습니다. 이를 통해 사용자 세션이 안전하게 관리되도록 했습니다.

• 쿠키를 이용한 토큰 전달 이슈 해결: 로컬 환경에서 쿠키를 통한 토큰 전달 문제를 해결하기 위해, CORS 설정을 적절히 수정하고 withCredentials 옵션을 활성화했습니다. 이를 통해 서버와 클라이언트 간의 보안 문제를 해결하고, 쿠키 기반의 토큰 전달 방식을 안정적으로 구현할 수 있었습니다.

4) 구현 결과

이 프로젝트를 통해 쿠키와 CORS 설정의 중요성을 인식하고, 이를 적절히 설정함으로써 클라이언트와 서버 간의 보안 문제를 효과적으로 해결했습니다. 이를 통해 사용자 데이터의 안전한 관리를 실현하고, 로그인의 신뢰성을 크게 향상시킬 수 있었습니다.

🔗 Repository Link

• Watcher-Habit 클라이언트 Repository
• Watcher-Habit 서버 Repository