[7주차] Team 하니홈 신수진 & 원채영 미션 제출합니다.

[chaeyoungwon]

배포 링크

하니홈 투표 배포 링크 🔗

피그마 디자인 링크

하니홈 투표 UI 🔗

과제를 하며

주어진 필수 구현 사항을 바탕으로 전체 UI를 디자인한 후, 이를 기준으로 파트를 나누었는데요. 유사한 UI끼리 묶어서 한 명은 홈, 로그인, 회원가입 페이지를, 다른 한 명은 멤버 페이지, 투표 페이지, 공통 모달을 맡기로 한 후, 사다리타기를 통해 역할을 정했습니다.

• 신수진: 프로젝트 세팅, 투표 페이지, 멤버 페이지, 공통 모달

  채영이가 전반적인 디자인을 맡아서 하니홈 프로젝트 컨셉에 맞추어서 예쁘게 만들어주었습니다. 반응형으로 개발해야하다보니 디자인을 두 가지의 경우 모두 만들어주었는데, 너무 고생한거 같아서 박수 백 만 번 치고싶습니다. 👍🏻🔥👏🏻💓마지막 과제인 만큼 실력이 초반에 비해 조금 많이(?) 오른 것 같아 살짝은 뿌듯하지만, 아직 갈 길이 멀어보입니다…

  [7주차 작업 내용]

  • 백엔드와 프론트엔드 데이터를 각각 BE, FE 객체로 분리 저장하였고, 투표 페이지와 멤버 페이지에서 각 파트에 따라 URL 파라미터(params.part)를 사용하여 데이터를 동적으로 불러오는 구조로 구현하였습니다.
  • 공통 모달의 경우 onClose와 onConfirm두 개의 핸들러로 분리하여 역할 명확화하였습니다. 아니오(onClose)를 눌렀을 때 모달이 닫히고, 예(onConfirm)를 눌렀을 때 로직 실행 또는 페이지 이동 처리하였습니다. 재사용 가능한 컴포넌트로 설계하여 다른 투표 유형에서도 활용 가능하도록 구성하였습니다.
  • 반응형 레이아웃으로 구현하면서모바일 및 데스크탑에서 요소의 정렬, 크기, 간격 등이 자연스럽게 배치되도록 조정하였습니다.

  [8주차 작업 내용]

  • 파트장 및 데모데이 투표 결과 UI를 구현하고, 이에 투표 결과 조회 API를 연동하였습니다.
  • 동일한 스타일의 모달을 공통 컴포넌트로 분리한 뒤, 각 파일에서 import하여 사용하는 방식으로 리팩토링하였습니다.
  • 파트장 및 데모데이 투표 API를 연동하고, 같은 파트끼리만 투표가 가능하며, 같은 데모데이 팀에는 투표할 수 없도록 백엔드에서 제약을 걸어둔 로직에 맞춰, 해당 경우에는 백에서 전달되는 메시지를 기반으로 alert 처리를 추가하였습니다.
  • 사용자가 이미 투표한 파트장/팀 정보를 조회하는 API도 연동하여, 해당 항목에는 다른 스타일이 적용되도록 UI를 구현하였습니다.

• 원채영: UI 디자인, 공통 레이아웃, 홈, 로그인, 회원가입

  하니홈 서비스의 디자인 시스템을 기반으로 작업을 진행했는데, 디자인 없는 개발자의 설움을 이제야 깨닫습니다.. 이번 과제를 통해 백엔드와의 협업을 미리 경험해볼 수 있어서 의미 있었고, 본격적인 연동 전 개발 흐름을 사전에 준비해볼 수 있는 좋은 기회였습니다.

  [7주차 작업 내용]

  • 브레이크포인트를 768px로 설정하여 반응형으로 개발하였습니다. 모바일 환경에서는 헤더 메뉴가 햄버거 버튼을 클릭했을 때 나타나는 내비게이션 구조로 변경하였고, 홈 화면에 사용된 배경 도형들의 위치도 모바일에 맞게 조정하였습니다.
  • 회원가입 폼에는 Zod 라이브러리를 사용하여 유효성 검사를 적용하였습니다. 입력값에 따라 에러 메시지를 출력하고 버튼을 비활성화하는 로직을 구현하여, 사용자 입력에 대한 에러 문구 출력을 구현하였습니다.
  • 로그인 및 회원가입 인증 처리에서는 Zustand를 활용하여 accessToken을 전역 상태로 관리하였습니다.
  • Axios 인스턴스를 설정하고, 요청 및 응답 인터셉터를 구성하여 accessToken이 만료되었을 경우 자동으로 갱신할 수 있는 구조를 구현하였습니다.

  [8주차 작업 내용]

  • 7주차에 받은 코드 리뷰를 바탕으로 전반적으로 코드를 리팩토링하고 깨지는 UI들을 수정하였습니다.

  • 홈 화면에 총 투표 수를 함수로 받아오며, 실시간으로 숫자가 올라가는 애니메이션을 추가하여 훅으로 구현하였습니다.

  • zod와 react-hook-form을 함께 사용하여 회원가입 시 거치는 유효성 검사 코드, 추론 코드 등을 개발하였습니다.
    이메일 및 아이디 중복 검사 API를 연결하여 회원가입 시 모든 입력과 API 연결에 성공하였을 경우 회원가입 버튼이 활성화되도록 조건을 추가했습니다.

  • 토큰 관리 방식을 구체화하고, 실제 로그인 및 회원가입, 로그아웃 API를 연결하였습니다.

  • 현재 백엔드에서는 토큰 만료 시 자동으로 재발급해주는 로직이 구현되어 있습니다.
    하지만 프론트엔드에서 Zustand를 사용해 토큰을 저장할 경우, 페이지를 새로고침하면 토큰이 초기화되는 문제가 발생합니다. 이를 해결하기 위해, 백엔드에 API 개발을 요청하여 페이지가 새로고침될 때 토큰 재발급 API를 호출하는 로직을 추가하였습니다.
    단, 사용자가 직접 로그아웃을 실행한 경우에는 재발급이 이루어지지 않도록 하기 위해, 로컬스토리지에 특정 값을 저장해 해당 상황을 구분하도록 처리했습니다..

  • middleware.ts에서 일반적으로 사용자 접근 제어를 처리하지만, 토큰을 메모리에 저장하고 있어
    쿠키에 저장된 리프레시 토큰의 존재 여부를 기반으로 로그인 여부를 판단하고자 했습니다. 하지만 도메인 불일치 등의 이유로 쿠키가 undefined로 전달되는 문제가 발생한 것으로 보였고,, 클라이언트 측에서 별도의 인증 훅을 작성하여 로그인 여부를 판단하고, 필요한 경우 라우팅을 제한하는 방식으로 처리하였습니다 ㅠㅅㅠ

  • 투표 결과를 득표순으로 정렬되어 있는 API가 따로 존재하여 기존에 연결해둔 API를 제거하고 해당 API로 대체하였습니다. 또한 중복되는 API 연결 로직을 하나로 통일하고, fetch로 연결되어 있던 API들은 axiosInstance를 사용하는 형태로 전반적으로 수정하였습니다.

Key Question

Zod 스키마가 무엇인지, 어떻게 활용할 수 있는지 알아봅시다.

Zod는 런타임에서의 타입 검증과 스키마 기반 유효성 검사를 지원하는 TypeScript 친화적 라이브러리

import { z } from "zod";

• 사용 이유: TypeScript는 컴파일 타임에만 타입을 검사할 수 있다. 하지만 실제 코드가 동작하는 시점은 런타임이며, 이때 잘못된 값이 들어오더라도 TS는 관여할 수 없다.

  type User = { age: number }; // 컴파일 타임 제한만

  • age가 string이어도 실제 런타임에서는 에러 없이 통과할 수 있음

  • Zod를 쓰면 이런 상황에서 런타임 검증이 가능

    const schema = z.object({ age: z.number().int().min(0) });
    
    schema.parse({ age: 21 });
    schema.parse({ age: "21" }); // 런타임 에러

---

• 장점
  • 런타임에서도 안전한 타입 보장
  • 스키마에서 TypeScript 타입 자동 추론
  • 숫자 범위, 문자열 형식 등 세밀한 유효성 검사 가능
  • 별도 DTO 타입을 정의하지 않아도 되는 일관성 유지

---

• 활용 예시

  const signupSchema = z.object({
    id: z.string().min(6).max(20),
    email: z.string().email(),
    password: z.string().min(8).max(20),
  });
  
  try {
    signupSchema.parse(formData); // 성공 or 에러 throw
  } catch (e) {
    console.log(e.errors); // 유효성 에러 메시지 배열
  }

이번 프로젝트에서 토큰 관리를 어떻게 할 예정인지, 그리고 왜 그런 방법을 선택했는지에 대해 설명해 주세요.

이번 프로젝트에서는 Zustand 전역 상태 관리 라이브러리를 통해 access token을 관리하고, refresh token은 httpOnly 쿠키에 저장하여 자동 재발급 방식으로 인증 흐름을 구성할 예정입니다.

• access token은 상태로만 보관하여 컴포넌트 간 인증이 필요한 요청에 쉽게 활용할 수 있도록 합니다.
• refresh token은 보안성을 고려해 httpOnly 쿠키에 저장하여 클라이언트 측에서 직접 접근하지 않도록 합니다.
• access token이 만료되었을 때는, 서버에서 자동으로 refresh token을 활용해 access token을 응답 헤더에 담아 재발급해주는 구조입니다.

선택 이유

• 로컬스토리지에 access token을 저장하는 방식은 XSS 공격에 취약하다는 보안 우려가 있음
• 쿠키에만 저장하는 방식은 상태 기반 인증 흐름 관리가 불편할 수 있음
• 따라서 access token은 Zustand로 상태 관리하고, refresh token은 httpOnly 쿠키로 보호하며, 자동 재발급 구조를 통해 보안성과 사용 편의성 사이 균형을 맞추고자 함