### 1. 가독성 및 디버깅
기존 함수 및 디버깅: 기존 함수 선언에는 기본적으로 이름이 지정되어 React DevTools와 같은 도구에서 가시성이 향상됩니다. 이름이 지정된 함수는 실행 흐름을 추적하거나 문제를 디버깅할 때 더 쉽게 식별할 수 있습니다. 대규모 구성 요소나 빈번한 디버깅이 필요한 구성 요소의 경우 이름이 지정된 기능을 사용하면 특히 여러 기능이 관련된 경우 시간을 절약하고 혼란을 줄일 수 있습니다. 익명 화살표 함수를 사용할 때 스택 추적에 '익명'으로 표시되는 경우가 많아 오류의 정확한 원인을 찾아내기가 더 어렵습니다.

디버깅의 화살표 함수: 화살표 함수는 변수에 명시적으로 할당되지 않는 한 이름이 지정되지 않는 경우가 많기 때문에 디버깅 도구에서 추적하기가 더 어려울 수 있습니다. 이는 여러 익명 함수를 구별하는 것이 까다로울 수 있으므로 깊은 구성 요소 계층 구조가 존재하는 응용 프로그램과 특히 관련이 있습니다.

### 2. 성능 고려 사항
화살표 함수로 다시 렌더링: React에서는 특히 PureComponent와 같은 최적화된 구성 요소나 shouldComponentUpdate를 활용하는 구성 요소를 처리할 때 화살표 함수가 의도하지 않은 성능 결과를 초래할 수 있습니다. 화살표 함수가 컴포넌트의 렌더 메소드 내에서 생성되거나 prop으로 직접 전달되면 렌더링할 때마다 다시 생성되므로 React는 매번 이를 새로운 함수 인스턴스로 처리하게 됩니다. 이는 렌더링 간의 동일성 검사가 실패하기 때문에 구성 요소가 불필요하게 다시 렌더링될 수 있음을 의미합니다(즉, 화살표 기능이 매번 새로운 값으로 표시됨).

하위 구성 요소에 미치는 영향: 화살표 함수가 하위 구성 요소에 props로 전달될 때 해당 하위 항목이 PureComponent 또는 React.memo에 의존하는 경우 불필요하게 다시 렌더링될 수도 있습니다. 이는 특히 대규모 애플리케이션에서 성능에 계단식 영향을 미칠 수 있습니다.

최적화 팁: 일반적인 방법은 렌더링 메서드 외부에서 함수를 정의하거나 'useCallback'을 사용하여 화살표 함수를 메모하여 렌더링할 때마다 함수가 다시 생성되는 것을 방지하는 것입니다. 그러나 이로 인해 복잡성이 추가되고 기존 함수 선언을 사용하면 이 문제를 완전히 피할 수 있습니다.

### 3. 일관성과 this 바인딩
화살표 함수 및 자동 this 바인딩: 화살표 함수의 주요 이점 중 하나는 주변 컨텍스트에 this를 자동으로 바인딩하는 것입니다. 이는 개발자가 클래스 구성 요소에서 메서드를 명시적으로 바인딩해야 하는 일반적인 문제를 방지하는 데 도움이 됩니다. (this.method.bind(this)). 이는 메서드 호출 방법에 따라 this 값이 변경될 수 있는 클래스 기반 구성 요소에 특히 유용합니다.

기능적 구성 요소: 기능적 구성 요소에서는 '이것'이 더 이상 문제가 되지 않으므로 이 바인딩은 크게 관련이 없습니다. '이것'에 대해 전혀 걱정할 필요 없이 상태와 소품에 직접 액세스할 수 있습니다. 이러한 맥락에서 화살표 함수의 자동 바인딩 동작은 이점이 아니며 특히 클래스 기반 구성 요소와 기능 구성 요소 간에 전환하는 개발자의 경우 기존 함수 선언이 더 일관되고 간단할 수 있습니다.

### 4. 코드 스타일 및 팀 선호도
팀 일관성: 일부 팀은 명확성과 일관된 구문을 위해 기존 함수 선언을 사용하는 것을 선호합니다. 함수 선언은 더 명확한 구조를 제공하며 암시적 반환(화살표 함수가 가질 수 있음)이 없기 때문에 코드를 더 쉽게 따라갈 수 있습니다. 화살표 함수는 암시적 반환을 허용하므로, 특히 개발자가 함수가 값이 아닌데 값을 반환한다고 잘못 가정할 때 미묘한 버그가 발생할 수 있습니다.

코드 가독성: 기존 함수 선언은 더 장황한 경우가 많지만, 특히 여러 기여자가 있는 대규모 팀이나 코드베이스에서 구성 요소의 구조를 보다 명확하게 이해할 수 있습니다. 가독성이 우선시된다면 팀의 코드 스타일 선호도는 기존 기능에 기울어질 수 있습니다.

### 5. 범위 지정 및 종결
화살표 함수 및 어휘 범위 지정: 화살표 함수에는 어휘 'this' 바인딩이 있습니다. 즉, 주변 컨텍스트에서 'this' 값을 유지합니다. 이는 특정 상황에서 매우 도움이 될 수 있지만 개발자가 화살표 기능을 언제 어디서 사용할지 결정할 때 신중해야 함을 의미하기도 합니다. 주의 깊게 고려하지 않으면 의도치 않게 잘못된 'this' 컨텍스트를 캡처할 수 있기 때문입니다.

기존 함수 및 유연성: 기존 함수 선언에는 어휘적 this 바인딩이 없으므로 개발자가 this 컨텍스트를 명시적으로 제어해야 하는 시나리오에 더 많은 유연성을 제공합니다. 어떤 경우에는 이러한 유연성이 유리할 수 있으며, 특히 더 복잡하거나 동적인 코드베이스에서는 더욱 그렇습니다.

> 
화살표 함수는 특히 클래스 구성 요소에서 편리함을 제공하지만 특정 시나리오에서는 기존 함수 선언이 분명한 이점을 제공합니다. 이는 많은 경우에 더 예측 가능하고 성능이 뛰어납니다. 특히 자동 'this' 바인딩이 관련이 없는 기능적 구성 요소에서는 더욱 그렇습니다. 또한 기존 기능을 사용하면 특히 대규모 팀이나 애플리케이션에서 코드 디버깅 및 유지 관리가 더 쉬워집니다. 궁극적으로 결정은 프로젝트의 특정 요구 사항, 팀 선호도 및 코드 스타일의 일관성 필요성에 따라 내려질 수 있습니다.

React 화살표 함수 vs function 함수

gwanhun1

## 결합도(Coupling)와 응집도(Cohesion)
소프트웨어 설계에서 **결합도(Coupling)**와 **응집도(Cohesion)**는 시스템의 모듈 간 관계를 설명하는 두 가지 중요한 개념입니다. 높은 응집도는 유지하되 결합도를 낮추는 것이 좋은 설계의 핵심입니다. 아래는 React, TypeScript, JavaScript를 활용한 예시입니다.

### 1. **결합도(Coupling)**
결합도는 모듈 간의 의존성을 나타냅니다. 결합도가 높으면 모듈들이 강하게 연결되어 있어 변경하기 어렵고, 결합도가 낮으면 모듈 간의 독립성이 높아져 변경과 재사용이 용이합니다.

* 결합도가 높은 예시 (Bad Example)

```js // UserProfile 컴포넌트가 UserService에 직접적으로 의존함
import UserService from './services/UserService';

const UserProfile = () => {
  const user = UserService.getUser(); // UserService에 강하게 결합

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
};

export default UserProfile;
```

위 예시에서 UserProfile 컴포넌트는 UserService에 직접적으로 의존하고 있기 때문에 결합도가 높습니다. 만약 UserService의 구현이 변경되면 UserProfile도 변경해야 합니다.

* 결합도를 낮춘 예시 (Good Example)
```js
// UserProfile이 UserService를 props로 받도록 개선
interface User {
  name: string;
  email: string;
}

interface UserProfileProps {
  user: User;
}

const UserProfile = ({ user }: UserProfileProps) => (
  <div>
    <h1>{user.name}</h1>
    <p>{user.email}</p>
  </div>
);

export default UserProfile;

// UserService에서 데이터를 가져오는 로직을 분리

import UserProfile from './UserProfile';
import UserService from './services/UserService';

const App = () => {
  const user = UserService.getUser(); // 여기서만 UserService에 의존

  return <UserProfile user={user} />;
};

export default App;

```
이 방식으로 UserProfile은 UserService에 의존하지 않고, props로 user 데이터를 받기 때문에 결합도가 낮아졌습니다. 이제 UserProfile은 다양한 사용자 데이터를 받을 수 있어 재사용성이 높아집니다.

---

### 2. **응집도(Cohesion)**
응집도는 모듈 내에서 기능들이 얼마나 밀접하게 관련되어 있는지를 나타냅니다. 응집도가 높으면 모듈 내의 기능들이 하나의 목적을 위해 함께 동작하며, 유지보수성이 높아집니다.

- 응집도가 낮은 예시 (Bad Example)

```js
// 한 컴포넌트에서 여러 책임을 다루는 경우 (응집도가 낮음)
const UserProfile = ({ user, isLoggedIn }: { user: any; isLoggedIn: boolean }) => {
  const handleLogout = () => {
    // 로그아웃 처리 로직
    console.log('Logged out');
  };

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
      {isLoggedIn && <button onClick={handleLogout}>Logout</button>}
    </div>
  );
};

export default UserProfile;

```

위 예시는 UserProfile 컴포넌트가 사용자 정보를 표시하는 책임 외에 로그아웃 로직까지 처리하고 있어, 응집도가 낮습니다.

- 응집도가 높은 예시 (Good Example)

```js // 책임을 분리하여 응집도 향상
const UserProfile = ({ user }: { user: any }) => (
  <div>
    <h1>{user.name}</h1>
    <p>{user.email}</p>
  </div>
);

const LogoutButton = ({ onLogout }: { onLogout: () => void }) => (
  <button onClick={onLogout}>Logout</button>
);

const App = () => {
  const user = { name: 'John', email: 'john@example.com' };
  const handleLogout = () => {
    console.log('Logged out');
  };

  return (
    <div>
      <UserProfile user={user} />
      <LogoutButton onLogout={handleLogout} />
    </div>
  );
};

export default App;
```
위 예시에서는 UserProfile과 LogoutButton의 책임을 분리하여 각 컴포넌트가 하나의 명확한 역할만 수행하게 하였습니다. 이를 통해 응집도가 높아졌으며, 유지보수와 테스트가 용이해졌습니다.

> 결론
결합도(Coupling): 모듈 간의 의존성을 줄여 변경에 유연하게 대처할 수 있게 하는 것이 중요합니다.
응집도(Cohesion): 모듈 내에서 관련된 기능들이 밀접하게 연관되어 있을수록 유지보수성과 가독성이 높아집니다.

결합도 응집도

React 프로젝트에서 **`@` 같은 alias(별칭)**를 사용하지 않으면, 파일을 불러올 때 **상대 경로**를 사용해야 합니다.

## 1. Alias 없이 상대 경로 사용

```js
import MyComponent from '../components/MyComponent';
```
* 디렉토리가 깊어질수록 경로가 복잡해짐.
* 파일 위치를 변경할 경우, 경로를 일일이 수정해야 함.

## 2. Alias 사용 시 절대 경로 사용
Alias를 설정하면 절대 경로를 사용할 수 있습니다:

```js

import MyComponent from '@/components/MyComponent';
````

* 경로가 단순해지고 코드 관리가 편리해짐.
* 디렉토리 구조가 바뀌어도 수정할 부분이 적음.

## 3. Alias 설정 방법
 ### 1. Webpack에서 Alias 설정
* Webpack을 사용한다면 webpack.config.js 파일에서 resolve.alias 옵션을 사용하여 설정할 수 있습니다.

설정 방법:
프로젝트 루트에 있는 webpack.config.js 파일을 엽니다.다음 코드를 추가합니다:
```js
const path = require('path');

module.exports = {
  // 기존 설정들
  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'src'), // '@'를 'src' 디렉토리에 매핑
    },
  },
};
```
설명:
path.resolve(__dirname, 'src')는 프로젝트의 루트 경로에서 src 디렉토리를 절대 경로로 설정하는 역할을 합니다.
이제 @/components/MyComponent 같은 형태로 src 디렉토리 내의 파일을 가져올 수 있습니다.

### 2. Create React App (CRA)에서 Alias 설정
* CRA에서는 기본적으로 Webpack 설정을 직접 수정할 수 없습니다. 대신, jsconfig.json 또는 tsconfig.json 파일에서 경로 설정을 할 수 있습니다.

설정 방법 (JavaScript 프로젝트):
프로젝트 루트에 jsconfig.json 파일을 추가하거나 수정합니다.
다음 내용을 추가합니다:
```json
{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@/*": ["*"]
    }
  }
}
```
설정 방법 (TypeScript 프로젝트):
프로젝트 루트에 tsconfig.json 파일을 열거나 수정합니다.
다음 내용을 추가합니다:
```json
{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@/*": ["*"]
    }
  }
}
```
설명:
baseUrl은 기본적으로 src 폴더를 기준으로 경로를 설정합니다.
paths는 @/*를 src/*로 매핑하는 역할을 합니다.
이제 @/components/MyComponent와 같은 방식으로 src 폴더 내 파일을 가져올 수 있습니다.

### 3. Vite에서 Alias 설정
* Vite는 프로젝트의 빌드 도구로, 설정 파일인 vite.config.js에서 Alias를 설정할 수 있습니다.

설정 방법:
프로젝트 루트에 있는 vite.config.js 파일을 엽니다.
다음 코드를 추가합니다:
```js
import { defineConfig } from 'vite';
import path from 'path';

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'), // '@'를 'src' 디렉토리에 매핑
    },
  },
});
```
설명:
path.resolve(__dirname, './src')는 src 폴더를 절대 경로로 설정합니다.
이제 @/components/MyComponent와 같이 절대 경로를 사용할 수 있습니다.


## 결론
Alias 사용 시: 경로가 간단해지고 관리가 편리해짐.
Alias 미사용 시: 상대 경로 사용으로 경로 관리가 복잡해질 수 있음.

![65828947-ì§ë-ê²½ë¡-ë°©í¥-ê²½ë¡-íì-ìì-íë©´-ì§ëìì-ë¤ë¥¸-ìì´ì½-ì¬ì´ì-ê²½ë¡ë¥¼-ê·¸ë ¸ìµëë¤-ì»¬ë¬.jpg](https://res.cloudinary.com/dcfqahfbr/image/upload/v1742390488/cvlog/posts/kus7pltaccjcdrdukanq.jpg)

React 프로젝트에서 경로 관리

> 문제 발생 상황 : 카운팅 애니메이션을 settimeout으로 구현 중 훅 순서에 맞지 않는 리액트 애러 발생

### 기존로직:
```javascript
import { useEffect, useState } from "react";

type UseCountUpType = { end: number | string };

export const useCountUp = ({ end }: UseCountUpType) => {
  const [currentCount, setCurrentCount] = useState<number>(0);

  const parseEndValue = (value: number | string): number | null => {
    if (typeof value === "number") return value;
    if (typeof value === "string") {
      const cleanedValue = value.replace(/,/g, ""); // 쉼표 제거
      const parsedValue = Number(cleanedValue);
      return isNaN(parsedValue) ? null : parsedValue;
    }
    return null;
  };

  useEffect(() => {
    const targetValue = parseEndValue(end);

    if (targetValue === null) return;

    // 목표 값에 도달하기 위해 증가할 간격 계산 (1초를 목표로 설정)
    const increment = Math.ceil(targetValue / 60); // 목표 값에 도달할 수 있는 적절한 증가값
    let current = 0;

    const updateCount = () => {
      current += increment;
      if (current >= targetValue) {
        setCurrentCount(targetValue); // 목표 값 도달
      } else {
        setCurrentCount(current);
        setTimeout(updateCount, 1000 / 60); // 1초 내에 완료하도록 조정
      }
    };

    updateCount(); // 첫 호출로 카운트 시작
  }, [end]);

  const formattedCount = new Intl.NumberFormat().format(currentCount);

  return formattedCount;
};
```
---

> React에서 useEffect와 같은 **훅(Hooks)**을 사용할 때, 호출 순서와 상태 관리가 중요한 이유는 React가 컴포넌트 렌더링 시 훅을 정해진 순서대로 호출하기 때문입니다. 이 순서가 깨지면 React가 상태를 올바르게 추적하지 못하고 오류가 발생할 수 있습니다.

### 1. React 훅의 호출 순서
React 컴포넌트가 렌더링될 때, 모든 훅은 매번 동일한 순서로 호출되어야 합니다. 즉, 첫 번째 렌더링에서 호출된 훅은 항상 두 번째 렌더링에서도 첫 번째로 호출되어야 합니다. 만약 훅의 호출 순서가 달라지면, React는 어떤 훅이 이전 렌더링에서 어떤 값을 가졌는지 알 수 없게 됩니다.

예를 들어, 다음과 같은 코드에서 훅을 사용할 때 순서가 깨지면 오류가 발생할 수 있습니다:
```javascript
useState('A'); // 첫 번째 훅
useEffect(() => { console.log('Effect!') }); // 두 번째 훅
```
React는 첫 번째 훅이 useState였는지 useEffect였는지 기억해야 하는데, 만약 useEffect를 호출하기 전에 useState를 호출하지 않으면 오류가 발생합니다.
### 2. setInterval 또는 setTimeout과 React 훅
setInterval이나 setTimeout은 JavaScript에서 시간을 기반으로 특정 작업을 일정 간격으로 실행하게 합니다. 이들은 비동기 방식으로 동작하므로, React에서는 상태를 업데이트하는 방법을 주의 깊게 다뤄야 합니다.

이 문제는 setInterval 또는 setTimeout이 동적으로 훅을 호출하게 만들기 때문에 발생합니다. 예를 들어, 아래 코드처럼 setInterval이 호출될 때마다 setState를 사용해 상태를 변경하는 경우, React는 상태 업데이트가 여러 번 이루어지는지, 그리고 상태가 변경될 때마다 해당 훅을 어떻게 처리해야 하는지에 혼란을 겪을 수 있습니다.
```javascript
useEffect(() => {
  const interval = setInterval(() => {
    setCurrentCount(prev => prev + 1); // 상태를 계속 업데이트
  }, 1000);
  
  return () => clearInterval(interval); // 컴포넌트가 사라질 때 타이머 정리
}, []);

```
### 3. 왜 "훅 호출 순서"가 중요한가?
React는 렌더링이 완료될 때마다 훅을 실행해서 컴포넌트의 상태를 관리합니다. 만약 어떤 훅이 "동적"으로 호출되는 구조라면, 그 훅이 매번 다른 순서로 호출될 수 있습니다. 이런 경우 React는 해당 훅이 이전 상태나 값에 대한 정보를 잘못 추적하게 되어, 예상치 못한 동작이나 경고 메시지가 발생합니다.

### 4. 실제 경고 메시지
React에서 발생하는 경고 메시지:
```javascript
Warning: React has detected a change in the order of Hooks called by <ComponentName>.
This will lead to bugs and errors if not fixed. For more information, read the Rules of Hooks.
```
이 메시지는 훅 호출 순서가 변경되었음을 알려줍니다. 위에서 설명한 대로, setInterval 또는 setTimeout을 재귀적으로 사용하는 방식에서 상태 업데이트가 동적으로 이루어지면, React는 훅들이 어떻게 실행되었는지 추적할 수 없게 되어, 이 경고를 표시합니다.

### 5. 어떻게 해결할 수 있을까?
이 문제를 해결하려면 setInterval 또는 setTimeout을 컴포넌트 외부에서 관리하지 말고, React의 상태 관리 훅(useState 등)을 잘 활용해야 합니다. 예를 들어, useRef를 사용하여 상태가 변경될 때마다 훅이 계속 호출되지 않도록 상태를 추적할 수 있습니다.

> 해결 방법
setInterval을 useRef와 함께 사용하여, React의 상태와 훅 호출 순서를 안정적으로 유지할 수 있습니다.

```javascript
import { useEffect, useState, useRef } from "react";

type UseCountUpType = { end: number | string };

export const useCountUp = ({ end }: UseCountUpType) => {
  const [currentCount, setCurrentCount] = useState<number>(0);
  const targetRef = useRef<number | null>(null); // `useRef`를 사용하여 상태를 저장

  const parseEndValue = (value: number | string): number | null => {
    if (typeof value === "number") return value;
    if (typeof value === "string") {
      const cleanedValue = value.replace(/,/g, "");
      const parsedValue = Number(cleanedValue);
      return isNaN(parsedValue) ? null : parsedValue;
    }
    return null;
  };

  useEffect(() => {
    targetRef.current = parseEndValue(end); // `useRef`로 `end` 값을 저장

    if (targetRef.current === null) return;

    const increment = Math.ceil(targetRef.current / 60);
    let current = 0;

    const interval = setInterval(() => {
      current += increment;
      if (current >= targetRef.current) {
        setCurrentCount(targetRef.current); // 목표 값에 도달하면 설정
        clearInterval(interval);
      } else {
        setCurrentCount(current);
      }
    }, 1000 / 60);

    return () => clearInterval(interval);
  }, [end]);

  const formattedCount = new Intl.NumberFormat().format(currentCount);

  return formattedCount;
};
```


### 최종로직(애니메이션 개선)
```javascript
import { useEffect, useRef, useState } from "react";

export const useCountUp = (endValue: number | string) => {
  const [displayValue, setDisplayValue] = useState("");
  const animationRef = useRef<number>();
  const digitsRef = useRef<string[]>([]);
  const decimalsRef = useRef<string[]>([]);

  // 한 번만 계산하는 초기 파싱 함수
  const parseEndValue = (value: number | string): [string[], string[]] => {
    const stringValue =
      typeof value === "string" ? value.replace(/,/g, "") : value.toString();
    const [integer, decimal] = stringValue.split(".");
    return [integer.split(""), decimal ? decimal.split("") : []];
  };

  useEffect(() => {
    if (animationRef.current) {
      cancelAnimationFrame(animationRef.current);
    }

    // 유효성 검사
    if (
      endValue === undefined ||
      endValue === null ||
      (typeof endValue === "string" && !endValue.trim())
    ) {
      setDisplayValue("");
      return;
    }

    const targetNum =
      typeof endValue === "string"
        ? parseFloat(endValue.replace(/,/g, ""))
        : endValue;

    if (isNaN(targetNum)) {
      setDisplayValue("");
      return;
    }

    // 시작 전에 미리 자릿수 배열 계산
    const [integerDigits, decimalDigits] = parseEndValue(endValue);
    digitsRef.current = integerDigits;
    decimalsRef.current = decimalDigits;

    const duration = 1000; // 더 짧은 애니메이션 시간
    const startTime = performance.now();

    const animate = (currentTime: number) => {
      const elapsed = currentTime - startTime;
      const progress = Math.min(elapsed / duration, 1);

      // 단순화된 이징
      const easeProgress =
        progress < 0.5
          ? 2 * progress * progress
          : 1 - Math.pow(-2 * progress + 2, 2) / 2;

      // 정수부 계산 - 메모이제이션된 자릿수 사용
      const newIntegerDigits = digitsRef.current.map((targetDigit, index) => {
        const digitProgress = Math.min(easeProgress * (1 + index * 0.05), 1);
        return Math.round(parseInt(targetDigit) * digitProgress).toString();
      });

      // 소수부 계산 - 필요한 경우만
      let finalValue = new Intl.NumberFormat().format(
        parseInt(newIntegerDigits.join("")),
      );

      if (decimalsRef.current.length > 0) {
        const newDecimalDigits = decimalsRef.current.map(
          (targetDigit, index) => {
            const digitProgress = Math.min(
              easeProgress * (1 + (index + digitsRef.current.length) * 0.05),
              1,
            );
            return Math.round(parseInt(targetDigit) * digitProgress).toString();
          },
        );
        finalValue += `.${newDecimalDigits.join("")}`;
      }

      setDisplayValue(finalValue);

      if (progress < 1) {
        animationRef.current = requestAnimationFrame(animate);
      }
    };

    // 첫 프레임 즉시 시작
    animationRef.current = requestAnimationFrame(animate);

    return () => {
      if (animationRef.current) {
        cancelAnimationFrame(animationRef.current);
      }
    };
  }, [endValue]);

  return displayValue;
};

```
## 요약:
React는 훅을 호출하는 순서가 매 렌더링마다 일정해야만 제대로 동작합니다.
setInterval 또는 setTimeout처럼 비동기적인 함수가 상태를 업데이트할 때, 훅 호출 순서가 변경되면 오류가 발생할 수 있습니다.
이를 해결하려면 useRef와 같은 React의 상태 추적 메커니즘을 사용하여 훅 호출 순서를 안정적으로 유지해야 합니다.



React 훅 안에서 setInterval() setTimeout()

# 토큰 저장 방식: 로컬 저장소 vs 쿠키

---

### 액세스 토큰 (Access Token)
액세스 토큰은 사용자가 인증을 받은 후, 서버에서 제공되는 짧은 수명의 토큰입니다. 클라이언트는 이 토큰을 이용하여 서버에 인증된 요청을 보냅니다.

- **장점**:
  - 짧은 유효 기간으로 보안성이 높음
  - 인증이 필요한 요청에 자동으로 포함됨
- **단점**:
  - 짧은 유효 기간으로 인해 자주 갱신이 필요
  - 유출되면 보안 위험이 존재

### 리프레시 토큰 (Refresh Token)
리프레시 토큰은 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용됩니다. 리프레시 토큰은 더 긴 수명을 가집니다.

- **장점**:
  - 액세스 토큰이 만료되어도, 리프레시 토큰으로 자동 갱신 가능
  - 서버에서 직접 관리하여 보안성이 높음
- **단점**:
  - 유출 시, 악용될 위험이 있음
  - 관리가 더 복잡함


--- 
## 저장 위치 및 보안

### LocalStorage

- **장점**:
  - 클라이언트 측에서 쉽게 저장하고 관리 가능
  - 브라우저에서 제공하는 API로 액세스하기 쉬움
  - 서버 사이드 설정 없이 클라이언트만 관리 가능
- **단점**:
  - **XSS 공격**에 취약: 악성 스크립트가 삽입되면 쉽게 접근될 수 있음
  - 만료된 액세스 토큰을 관리하기 어려움
  - 쿠키와 달리 자동으로 서버 요청에 포함되지 않음

### Cookies

- **장점**:
  - `httpOnly` 속성을 통해 JavaScript에서 접근할 수 없어서 XSS 공격에 더 안전
  - `secure` 플래그와 `sameSite` 옵션을 활용하여 HTTPS와 CSRF 공격을 방지할 수 있음
  - 서버 측에서 쉽게 관리 가능
- **단점**:
  - **CSRF 공격**에 취약할 수 있음, 하지만 `sameSite` 옵션을 통해 예방 가능
  - 크기 제한이 있어 대용량 데이터를 저장할 수 없음 (4KB 제한)
  - 요청 시 자동으로 포함되므로, 서버 측에서 더 많은 설정이 필요

---
## 보안 이슈: XSS 및 CSRF 공격

### XSS (Cross-Site Scripting)
- **LocalStorage**: JavaScript로 쉽게 접근 가능하여 악성 스크립트가 토큰을 탈취할 수 있음
- **Cookies**: `httpOnly` 쿠키로 JavaScript에서 접근 불가하므로 XSS 공격에 더 안전

### CSRF (Cross-Site Request Forgery)
- **Cookies**: 쿠키는 브라우저가 자동으로 전송하기 때문에 CSRF 공격에 취약할 수 있음. 이를 방지하기 위해 `sameSite` 플래그와 **anti-CSRF tokens**를 활용할 수 있음
- **LocalStorage**: XSS 공격에 더 취약하지만 CSRF 공격에는 영향 없음

---
## 저장 방식 전략

### 방법 1: LocalStorage 사용
- 액세스 토큰을 `localStorage`에 저장하고, 리프레시 토큰은 `localStorage`나 쿠키에 저장
  - **장점**: 설정이 간단하고 서버 측 관리가 필요 없음
  - **단점**: XSS 공격에 취약하며, 토큰 탈취 시 보안 리스크가 있음

### 방법 2: Cookies 사용
- 액세스 토큰과 리프레시 토큰을 모두 `httpOnly` 쿠키에 저장
  - **장점**: XSS 공격으로부터 보호되며, 자동으로 요청에 포함됨
  - **단점**: CSRF 공격에 취약할 수 있지만, `sameSite`와 **anti-CSRF tokens**로 예방 가능

### 방법 3: 메모리 저장 (액세스 토큰) + 쿠키 저장 (리프레시 토큰)
- 액세스 토큰은 메모리에 저장하고, 리프레시 토큰만 `httpOnly` 쿠키에 저장
  - **장점**: 액세스 토큰이 노출되지 않아 XSS 공격에 안전함. 리프레시 토큰을 통해 새로운 액세스 토큰을 발급받을 수 있음
  - **단점**: 페이지 리프레시 시 액세스 토큰이 사라지며, 리프레시 토큰을 사용해 갱신해야 함

---
## 👍 권장 저장 방식

- **액세스 토큰**은 `localStorage` 또는 메모리에 저장하고, **리프레시 토큰**은 `httpOnly` 쿠키에 저장합니다.
- **CSRF**와 **XSS** 공격을 방지하려면, 쿠키에 `sameSite` 플래그와 **anti-CSRF tokens**를 사용합니다.
- **세션 관리** 및 **토큰 갱신**을 서버 측에서 안전하게 관리하도록 합니다.

![img (1).jpg](https://res.cloudinary.com/dcfqahfbr/image/upload/v1739924662/cvlog/posts/ikl8nurim3phyabrsoiu.jpg)

React 화살표 함수 vs function 함수

결합도 응집도

React 프로젝트에서 경로 관리

React 훅 안에서 setInterval() setTimeout()

(TOKEN) localstorage VS cookie