SSR

SSG + ISR

실무에서 사용한다면 ?

쇼핑몰 웹사이트를 만든다고 가정했을 때,

SSR

1. 로그인 후 메인/마이페이지: 유저별 맞춤 콘텐츠 필요하므로 서버에서 매 요청 처리
2. 메인 페이지 인기상품: 실시간 인기 상품 노출 필요
3. 검색 결과 페이지: 검색 결과도 SEO에 노출되게 하고싶으면 SSR 처리, 필요없으면 CSR 처리

SSG

1. 메인 페이지 상품 리스트: 쇼핑몰의 전체 상품 리스트는 실시간성으로 바뀌기보다 하루에 n번 갱신하는것이 낫다 생각
2. 제품 상세 페이지: 많이 보는 상품은 SSG + ISR로 캐싱, 실시간 재고 필요하면 SSR
3. 이벤트 및 프로모션: 고정 콘텐츠, 실시간성 필요 없지만 SEO 적합

• 운영체제로부터 자원을 할당받는 단위
• code, data, heap, stack 형식으로 할당

스레드

• 프로세스가 할당받은 자원을 이용하는 실행의 단위
• 메모리 영역 내에서 stack은 각자 값을 가지고 있음
• 나머지 code, data, heap, 형식으로 할당된 영역 공유

프로세스를 실행하다가 오류가 나서 강제종료되면 ? → 공유하고 있는 파일을 손상시키는 것이 아니면 영향 X

스레드 하나에서 오류가 발생하면 ? → 오류 난 스레드가 속한 프로세스가 종료 될 수 있다

싱글 스레드

• 하나의 프로세스에서 하나의 스레드가 실행
• 하나의 스택과 레지스터로 표현

장점) 자원 접근에 대한 동기화 신경을 쓰지 않아도 됨 단점) 여러개의 CPU를 활용하지 못함

멀티 스레드

• 각 프로세스 내에서 여러개의 스레드가 동시 작업 수행
• 자원을 공유하여 생성/관리 중복 최소화

장점) 자원을 공유하므로 가볍고 통신이 빠르다 단점) 동기화 이슈나 하나의 스레드 오류로 프로세스에 영향이 갈 수 있다

멀티 프로세스

• 하나의 프로그램이 여러개의 독립된 프로세스로 나누어 실행됨

장점) 각 프로세스가 메모리를 독립적으로 사용해 안전성이 높다 단점) 자원 소모가 크고, 프로세스 간 통신이 복잡하다

🤷‍♀️ 그러면 멀티 프로세스와 멀티 스레드는 어떻게 구분하여 언제 사용하는 것이 좋을까?

멀티 프로세스 : 작업간의 안전성이 중요할 때 사용 멀티 스레드 : 가볍고 빠른 통신이 중요할 때 사용

ex) 크롬 브라우저는 각 탭을 멀티 프로세스로 분리해서 한 탭이 멈춰도 다른 탭에는 영향이 없도록 설계되어 있다. 반면 서버나 게임에서는 멀티 스레드를 활용해 가볍고 빠름을 추구한다.

서버로부터 데이터 가져오기, 데이터 캐싱, 캐시 제어 등 데이터를 쉽고 효율적으로 관리할 수 있는 라이브러리

기능 정리

• 데이터 가져오기 및 캐싱
• 동일 요청의 중복 제거 (단일 요청으로 통합)
• 신선한 데이터 유지 및 빠른 데이터 업데이트
• 페이지네이션 및 데이터 지연로드 등의 성능 최적화
• 네트워크 재연결, 요청 실패 등의 자동 갱신

기본 설정

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 1000 * 10
    },
  },
});

function App() {
  return (
   <QueryClientProvider client={queryClient}>
      <div>기본 설정 세팅</div>
   </QueryClientProvider>;
  );
}

1. QueryClient를 사용하여 캐시와 상호 작용 할 수 있다.
2. QueryClientProvider를 최상단에서 감싸주고 QueryClient 인스턴스를 client props로 넣어 연결해야 함.
3. 해당 context는 비동기 요청을 알아서 처리하는 background 계층이 된다.

데이터 캐싱

const result = useQuery({
  queryKey: ["A"],
  queryFn,
  staleTime: 0, // (기본값 0초)
  gcTime: 1000 * 60 * 5, // (기본값 5분)
});

1. A라는 queryKey를 가진 쿼리 인스턴스가 mount
2. 네트워크 요청을 통해 데이터를 fetch(queryFn)하고, 데이터 A라는 queryKey로 캐싱
3. 기본값인 staleTime이 0이므로, 데이터를 가져오자마자 바로 stale(상함) 상태로 전환
4. 쿼리 인스턴스가 unmount 되면, Tanstack Query는 해당 캐시를 gcTime 동안 유지
5. 설정해놓은 5분 이내에 A 쿼리가 다시 mount 되면, 캐시된 데이터를 즉시 반환 
   (동시에 queryFn은 background에서 실행)
6. 5분 이내에 A 쿼리가 다시 mount 되지 않으면, 해당 캐시는 가비지 컬렉션에 의해 삭제

// gcTime: 해당 시간이 지나면 "데이터 캐시에서 제거" (메모리에서도 사라짐)
// staleTime: "데이터가 상하는데까지 걸리는 시간" 설정 옵션 (위 코드는 0으로 설정했기 때문에 바로상함)

useQuery 기본 문법

• useQuery는 v5부터 인자로 단 하나의 객체만 받는다. 그 중 첫번째 인자 queryKey, queryFn 가 필수 값이다.

const result = useQuery({
  queryKey, // 쿼리 식별자 (필수)
  queryFn, // 데이터 fetch하는 비동기 함수 (필수)
  // 옵션 예시) gcTime, staleTime, select 등
});

result.data; // queryFn 결과값 or 캐시된 데이터
result.isStale; // 값이 상했는지 여부 (staleTime 지나면 true)
result.refetch; // 재요청 함수 (queryFn을 다시 실행시키는 수동 트리거)
result.isLoading; // 로딩 상태 (queryFn 진행 상태 확인)

useQuery - queryFn

• 쿼리 함수는 데이터를 가져오는 비동기 함수로, 꼭 데이터를 반환하거나 오류를 던져야 함
• 던져진 오류는 반환되는 error 객체로 확인 가능
• error는 기본적으로 null

import { useQuery } from '@tanstack/react-query'

type ResponseValue = {
  message: string
  time: string
}

export default function DelayedData() {
  const { data, error } = useQuery<ResponseValue>({
    queryKey: ['delay'],
    queryFn: async () => {
      const res = await fetch('https://api.heropy.dev/v0/delay?t=1000')
      const data = await res.json()
      if (!data.time) {
        throw new Error('문제가 발생했습니다!')
      }
      return data
    },
    staleTime: 1000 * 10,
    retry: 1
  })
  return (
    <>
      {data && <div>{JSON.stringify(data)}</div>}
      {error && <div>{error.message}</div>}
    </>
  )
}

useQuery 주요 리턴 데이터

const {
  data,
  error,
  status,
  isPending,
  fetchStatus,
  isLoading,
  isFetching,
  isError,
  refetch,
  // ...
} = useQuery({
  queryKey: ["all-items"],
  queryFn: getAllItems,
});

• data: 쿼리 함수가 리턴한 Promise에서 resolved된 데이터

• error: 쿼리 함수에 오류가 발생한 경우, 쿼리에 대한 오류 객체
• status: data, 쿼리 결과값에 대한 상태를 표현하는 status는 문자열 형태로 3가지의 값이 존재한다.
  • pending: 쿼리 데이터가 없고, 쿼리 시도가 아직 완료되지 않은 상태 ㅤ- { enabled: false } 상태로 쿼리가 호출되면 이 상태로 시작된다
  • error: 에러 발생했을 때 상태
  • success: 쿼리 함수가 오류 없이 요청 성공하고 데이터를 표시할 준비가 된 상태
• isPending: 쿼리가 아직 수행되지 않았고, 캐싱된 데이터가 없을 때 true를 반환한다
  • status(pending)에 파생된 boolean 값이다
• fetchStatus: queryFn에 대한 정보를 나타냄
  • fetching: 쿼리가 현재 실행 중인 상태
  • paused: 쿼리를 요청했지만, 잠시 중단된 상태 (network mode와 연관)
  • idle: 쿼리가 현재 아무 작업도 수행하지 않는 상태
• isLoading: 캐싱 된 데이터가 없을 때 즉, 처음 실행된 쿼리일 때 로딩 여부에 따라 true/false로 반환된다.
  • 이는 캐싱 된 데이터가 있다면 로딩 여부에 상관없이 false를 반환한다.
  • status(pending)와 fetchStatus(fetching) 결합된 boolean이다. 즉, isFetching && isPending 와 동일하다.
• isFetching: 캐싱된 데이터가 있더라도 서버에 요청을 보내면 true를 반환한다
  • fetchStatus(fetching)에 파생된 boolean 값이다
• isSuccess: 쿼리 요청이 성공하면 true
• isError: 쿼리 요청 중에 에러가 발생한 경우 true
• refetch: 쿼리를 수동으로 다시 가져오는 함수 그 외 반환 데이터들을 자세히 알고 싶으면 useQuery 공식 문서 참고

솔직히 옵션이 너무 많아서 엄청 복잡해보인다. 하지만 평소 state 관리하던 loading이나 성공 결과들을 API 요청 시 한번에 처리 할 수 있다는것이 tanStack Query의 장점인 것 같다.
옵션을 하나씩 정리하기에는 너무 많은 양으로 아래 참조 링크를 보며 학습하도록 하자... 🙀

https://www.heropy.dev/p/HZaKIE https://github.com/ssi02014/react-query-tutorial?tab=readme-ov-file#%EA%B0%9C%EC%9A%94

0. 유틸리티 타입이란

1. Partial<T>
2. Required<T>
3. Readonly<T>
4. Pick<T, K>
5. Omit<T, K>
6. Record<K, V>
7. Exclude<T, K>
8. Extract<T, K>
9. ReturnType<T>

유틸리티 타입 ?

타입스크립트가 자체적으로 제공하는 특수한 타입

맵드 타입 기반: 목차 1~6번 (key를 기준으로 새로운 타입을 만든다. 키의 반복을 통해 속성 자체를 바꾸는 것에 초점)

조건부 타입 기반: 목차 7~9번 (타입이 어떤 조건에 따라 바뀌는 "삼항 연산자 스타일" 분기)

Partial<T>

특정 객체 타입의 모든 프로퍼티를 선택적 프로퍼티로 변환 👉 기존 객체 타입에 정의된 프로퍼티 중 일부분만 사용할 수 있도록 도와주는 타입

interface Post {
  title: string;
  tags: string[];
  content: string;
  thumbnailURL?: string;
}

const draft: Partial<Post> = {
  title: "제목",
  content: "내용",
};

Required<T>

특정 객체 타입의 모든 프로퍼티를 필수 프로퍼티로 변환 (partial 반대) 👉 사용 시 옵셔널 프로퍼티 생략 불가능 (생략 시 오류 발생)

interface Post {
  title: string;
  tags: string[];
  content: string;
  thumbnailURL?: string;
}

const withThumbnailPost: Required<Post> = {
  title: "제목",
  tags: ["ts"],
  content: "",
  // thumbnailURL: "",
};

Readonly<T>

특정 객체 타입의 모든 프로퍼티를 읽기 전용 프로퍼티로 변환 👉 사용 시 수정 불가능 (수정 시 오류 발생)

interface Post {
  title: string;
  tags: string[];
  content: string;
  thumbnailURL?: string;
}

const readonlyPost: Readonly<Post> = {
  title: "수정 불가",
  tags: [],
  content: "",
};

readonlyPost.content = '수정 시도';

Pick<T, K>

특정 객체 타입으로부터 특정 프로퍼티만 골라내는 타입

interface Post {
  title: string;
  tags: string[];
  content: string;
  thumbnailURL?: string;
}

const legacyPost: Pick<Post, "title" | "content"> = {
  title: "",
  content: "",
};
// 추출된 타입 : { title : string; content : string }

Omit<T, K>

특정 객체 타입으로부터 특정 프로퍼티만을 제거하는 타입

interface Post {
  title: string;
  tags: string[];
  content: string;
  thumbnailURL?: string;
}

const noTitlePost: Omit<Post, "title"> = {
  content: "",
  tags: [],
  thumbnailURL: "",
};

Record<K, V>

type 중복 프로퍼티 추가 시 이용하는 타입 👉 K에는 어떤 프로퍼티들이 있을지 String Literal Union 타입을 할당, V에는 프로퍼티의 값 타입을 할당

type Thumbnail = {
  large: {
    url: string;
  };
  medium: {
    url: string;
  };
  small: {
    url: string;
  };
};

// 위 코드를 아래처럼 사용 가능

type Thumbnail = Record<
  "large" | "medium" | "small",
  { url: string }
>;

아래는 조건부 타입 기반 타입 정리 !

Exclude<T, K>

Exclude 타입은 T로부터 U를 제거하는 타입 👉 여러 개가 합쳐진 유니언 타입에서 특정 케이스만 제거하고 싶을 때 사용

type Status = "loading" | "success" | "error" | "idle";

// Status 타입에서 "loading" 상태만 제외하고 싶어요.
type NonLoadingStatus = Exclude<Status, "loading">;
// 결과 타입 NonLoadingStatus는 "success" | "error" | "idle" 가 돼요!

let currentStatus: NonLoadingStatus = "success";
// currentStatus = "loading"; // 에러! NonLoadingStatus 타입에는 "loading"이 없어요.

Extract<T, K>

Extract 타입은 T로 부터 U를 추출하는 타입입니다 👉 유니언 타입 중에서 특정 타입들만 따로 뽑아내고 싶을 때 사용

type EventType = "click" | "mouseover" | "keydown" | "keyup";

// EventType 중에서 마우스 관련 이벤트("click", "mouseover")만 뽑아내고 싶어요.
type MouseEventType = Extract<EventType, "click" | "mouseover">;
// 결과 타입 MouseEventType는 "click" | "mouseover" 가 돼요!

let mouseEvent: MouseEventType = "click";
// mouseEvent = "keydown"; // 에러! MouseEventType 타입에는 "keydown"이 없어요.

ReturnType<T>

타입변수 T에 할당된 함수 타입의 반환값 타입을 추출하는 타입

type ReturnType<T extends (...args: any) => any> = T extends (
  ...agrs: any
) => infer R
  ? R
  : never;

function funcA() {
  return "hello";
}

function funcB() {
  return 10;
}

type ReturnA = ReturnType<typeof funcA>;
// string

type ReturnB = ReturnType<typeof funcB>;
// number

코드 예시 출처 한 입 크기로 잘라먹는 타입스크립트 https://velog.io/@outofearth/posts

서버가 미리 만든 HTML에 브라우저에서 React의 JS 기능을 붙이는 과정 이미 렌더링 된 HTML에 useState, useEffect, onClick 등의 기능을 살리는 것

💡 발생

• SSR이나 SSG처럼 HTML이 먼저 도착한 경우
• 브라우저는 해당 HTML과 React의 가상 DOM을 동기화함

🤸‍♀️ 예시

// 서버 렌더링된 HTML
<h1>타이틀</h1>
<button>버튼</button>

// 브라우저에서 JS 번들이 로드됨
→ React가 해당 HTML과 가상 DOM을 연결 (hydration)
→ onClick 이벤트, useState 등 기능이 활성화됨

Bundling

여러 JS 파일, 모듈들을 하나로 묶어서 단일 JS 파일로 만드는 작업 JS 파일을 최소화하여 최적화 Webpack, Vite, Turbopack 등으로 처리

💡 발생

• 앱 빌드 시 main.js 번들 파일 생성

🤸‍♀️ 예시

// src/components/A.tsx
// src/components/B.tsx

→ 번들링 후 여러 JS 파일(예: main.js, chunk.js 등)로 묶임

• 401 (Unauthorized): 인증이 필요하거나, 인증이 실패한 경우
• 403 (Forbidden): 인증은 되었지만 해당 리소스 권한 없음

쿠키와 세션 보안 측면

• 쿠키보다 세션이 안전

  • 인증 정보는 서버에만 저장됨
  • 클라이언트는 세션 ID만 전달
  • 서버에서 강제 로그아웃, 만료 처리 통제 가능

• JWT 사용 시 HTTP 헤더에 담아 전송

  • 서버는 토큰의 유효성과 서명만 검증

• JWT 사용 전략 ```

1. Access Token 헤더 전송
2. Access Token 만료 시 Refresh Token 발급
3. refresh 요청 시 이전 토큰 폐기 및 새로운 refresh token 발급

• Refresh Token은 HttpOnly + Secure + SameSite=Strict 쿠키에 저장

React에서의 DOM 컨트롤 방법

1️⃣ useRef() + .current: 특정 DOM 요소에 직접 접근 시 사용

import { useRef, useEffect } from 'react';

function MyComponent() {
  const inputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    if (inputRef.current) {
      inputRef.current.focus();
    }
  }, []);

  return <input ref={inputRef} />;
}

2️⃣ useEffect(): DOM이 렌더링 된 후 동작을 수행할 때 사용

useEffect(() => {
  console.log(document.getElementById('myDiv')?.innerText);
}, []);

3️⃣ className/style props: DOM 속성을 선언적으로 제어

<div className={isActive ? 'active' : ''} style={{ color: 'red' }}>
  Hello
</div>

4️⃣ dangerouslySetInnerHTML: HTML 문자열을 DOM 삽입 시 사용 (XSS 위험)

<div dangerouslySetInnerHTML={{ __html: '<b>Hello</b>' }} />

✏️ 직접 접근이 필요한 경우에만 ref로 제한적으로 사용하는 것이 베스트

XSS와 CSRF

XSS: 악성 스크립트를 웹사이트에 삽입해서 다른 사용자의 브라우저에서 실행되게 하는 공격

• 공격 대상: 사용자
• <input>, <textarea>, 댓글, 게시판 등 사용자가 입력을 표시하는 곳에서 발생
• 쿠키 탈취 및 세션 하이재킹, 사용자 입력 조작 등의 목적

CSRF: 사용자가 로그인된 상태에서, 공격자가 만든 요청을 사용자 의지와 무관하게 실행되게 하는 공격

• 공격대상: 서버
• 예시: <img src="http://bank.com/transfer?amount=10000&to=hacker">
• 로그인된 사용자의 권한으로 요청. 무단 송금, 비밀번호 변경 등 서버 상태 변경

🔒 해결방법

XSS : 출력 시 반드시 이스케이프 처리 및 입력값 필터링, 
      CSP(악성 스크립트 차단) 적용, 쿠키에 HttpOnly 속성 설정

CSRF : CSRF 토큰 사용 및 SameSite 쿠키 옵션 설정, 
       origin 헤더 검증, 로그아웃 시 세션 무효화, 세션 timeout 설정

그리고.. 실제 서비스에서의 Next.js의 단점/제약 정리 (App Router 기준)

😬 서버 컴포넌트 + 클라이언트 컴포넌트 분리의 복잡성

• 컴포넌트 내부에서 useState, useEffect, event listener 사용 시 use client 필요
• 이로 인해 모든 버튼 컴포넌트마다 use client를 붙이게 되거나, SSR 의도가 무너질때도 있다.. (경험담 ... ^^)

🐝 App Router 구조와 Page Router 구조의 충돌

• 기존 page router 기반 프로젝트에서 app router로 마이그레이션 시 혼합 사용 불가
• 구조/라이프사이클/라우팅 방식이 완전히 다름 ex) getServerSideProps → server component or fetch로 대체
• 그렇기 때문에 일부만 마이그레이션 불가. 기존 라이브러리와 호환 이슈 발생

👾 레이아웃 구조 복잡화

• 페이지마다 layout.tsx, loading.tsx, error.tsx 등 여러 파일 관리 필요
• 유지보수 시 새로 들어온 팀원이 구조파악 힘들때가 있다.. 🥲

❄️ 미들웨어 제약

• 리디렉션, 쿠키 읽기, 헤더 검사, JWT 토큰 단순검사 등 가벼운 조건 체크는 적합!
• 하지만 고급 인증/인가 처리는 API Route 또는 서버에서 따로 처리를 해야하는 이슈가 있다

Next의 장점은 충분히 알고 있지만, 단점에 대한 질문이 나오면 바로 답변이 나오지 않아서 정리해봤다 ㅎㅎ..

• 폼 제출이나 API 호출처럼 특정 이벤트 처리
• 함수로 구현되고, use server를 붙여서 서버에서 실행됨
  (클라이언트 컴포넌트에서 호출 가능)

API Route

• /app/api/에 정의된 엔드 포인트 (App Router 기준)
• 프록시 서버, Webhook, 외부 API 호출 처리 등 범용적으로 사용 가능

Server Component

• 서버에서 렌더링되는 컴포넌트 (서버에서만 실행)
• 클라이언트에는 HTML만 전송 (번들 사이즈 줄고 초기 로딩 속도 ↑)
• 인터랙티브는 클라이언트 컴포넌트로 내려줘야됨

🤔 그래서 Server Action과 API Route의 차이점은?

Server Action

1. 버튼 클릭 이벤트 같은 UI 액션을 서버에서 처리
2. FormData 파싱 및 CSRF 방어를 자동으로 처리
3. GET 요청에 직접 대응 불가능 (폼 action 방식이라 기본적으로 POST)

API Route

1. GET, POST, PUT, DELETE 등 다양한 HTTP 메서드 지원
2. fetch, axios 같은 클라이언트 코드에서 호출 필요
3. FormData 파싱 및 CSRF 방어 직접 구현

여기까지 읽었을 때 평소에 API 연동 시 GET 요청만 아니면 Server Action으로 처리해도 되지 않나? 싶었는데...

• CORS 프록시 서버 역할
• 외부 서비스에서 호출(Webhook, Slack 등)
• 헤더/쿠키 제어
• 실시간 데이터 처리(WebSocket)
• 여러 메서드 분기처리

위에 해당되는 케이스일 때 API Route를 사용하면 된다!

🙆‍♀️ 한줄정리

Server Component = UI Server Action = 컴포넌트 안에서 일어나는 액션 처리 API Route = HTTP 메서드와 API를 처리하는 곳

fallback 옵션 비교

fallback: false

• 정의된 path만 HTML로 사전 생성
• 정의되지 않은 path는 404 Not Found 반환
• 사용 예시: 고정된 블로그 글, 정책 페이지

fallback: blocking

• 정의되지 않은 path 접근 시, 빌드 타임 이후 서버에서 HTML을 실시간 생성
• 생성된 페이지는 캐시에 저장 → 이후부터 SSG처럼 동작
• 사용 예시: SEO가 중요한 상세 페이지 (뉴스, 상품)

fallback: true

• 정의되지 않은 path는 빈 페이지 반환 (레이아웃만 표시 / 로딩 UI 필요)
• 클라이언트는 props 없이 먼저 렌더링 → 이후 서버에서 데이터를 받아 채움
• 사용 예시: 페이지 수가 많은 곳 (커뮤니티, Q&A 게시판)

Next 초창기부터 제공되어 오던 구 버전의 라우터

장점

• 파일 시스템 기반의 간편한 페이지 라우팅 제공
• 다양한 방식의 사전 렌더링 제공 (SSR, SSG, ISR)

단점

• 페이지별 레이아웃 설정이 번거로움 (코드 중복 ↑)
• data fetching이 페이지 컴포넌트에 집중됨
• 불필요한 컴포넌트들도 JS Bundle에 포함됨

App Router

Next 13버전과 함께 처음으로 공개된 신규 라우터

장점

• 유연한 레이아웃 시스템 제공 (중첩 레이아웃, Parallel Routes)
• Server Component 지원 → JS Bundle 크기 절감 가능
• 서버 액션으로 API Route 대체 가능

단점

• 서버 / 클라이언트 각 컴포넌트 분리 필요
• Server Component에서는 브라우저 API 사용 불가 (window, document 등)
• hydration mismatch, suspense 오류 시 디버깅 복잡성 증가

코드를 실행하지 않고 문법 오류, 버그 가능성, 스타일 문제를 자동으로 찾아주는 도구

사용 이유 ?

• 버그 예방: 변수 선언을 하지 않았는데 사용하거나 오타 같은 실수를 잡아줌
• 코드 일관성 유지: 포맷을 통일해줌 (세미콜론이나 탭/스페이스 등)
• 리팩터링 용이: 이상한 코드 패턴을 미리 알려주기 때문에 유지보수에 도움이 됨
• 팀 협업 필수: 규칙 기반으로 자동 리뷰를 도와줌

ESLint가 잡아주는 구체적 예시

async function fetchData() {
  const res = fetch("https://api.com/data");
  const data = await res.json();
  return data;
}
// ESLint: Expected 'await' before calling 'fetch' because the function is async.

// .eslintrc
{
  "rules": {
    "require-await": "warn" // async 함수에서 await 없으면 경고
  }
}

• ESLint 플러그인에서 eslint-plugin-promise 사용
• 규칙 중 require-await, no-return-await, no-async-promise-executor, prefer-await-to-callbacks 같은 async 관련 규칙이 켜져 있을 때

const age = "30";

if (age == 30) {
  console.log("30살입니다");
}
// ESLint: Expected '===' and instead saw '=='

{
  "rules": {
    "eqeqeq": ["error", "always"]
  }
}

• 항상 ===과 !==만 쓰고, ==과 !=은 쓰지 말라는 설정
• == 는 타입이 다르더라도 자동 형변환 후 값이 같으면 true
• ===는 타입과 값이 모두 같아야 true, 타입이 다르면 false

설정 파일은 항상 프로젝트 루트에 존재하도록 한다.

자세한 활용방법: https://tech.kakao.com/posts/375

useState: 컴포넌트 레벨의 로컬 상태 관리 useReducer: 복잡한 상태 로직 관리 (Redux와 유사한 패턴으로 상태 업데이트) useContext: 전역 상태 공유 (prop drilling 해결)

🥐 라이브러리

Redux: Redux Toolkit으로 사용하는 대규모 상태 관리 라이브러리 Zustand: 심플하고 가벼운 전역 상태 관리, Provider 없이 사용 Jotai: Context보다 빠르고 직관적인 상태 관리 Recoil: 상태 간 의존성과 Selector로 유연한 상태 관리 Valtio: 객체처럼 다루며 간단하게 사용하는 상태 관리 Mobx: 객체지향적 상태 관리, 반응성 높은 UI

🥨 서버 상태관리

TanStack Query: 서버 상태 관리 특화, API 데이터 관리 시 사용 SWR: 간단한 데이터 페칭과 캐싱 필요 시 사용 Apollo Client: 로컬 상태와 원격 상태 통합 관리 (GraphQL 전용)

🍞 폼 상태관리

React Hook Form: 성능 최적화 폼 라이브러리, 최소 리렌더링 Formik: 폼 상태와 유효성 검사 필요시 사용

🤖 상태관리의 "아키텍처 패턴" 이나 "구현방식" 분류 개념

1️⃣ Atomic Store

개념:

• 상태를 작은 단위(원자, atom)로 나누어 관리
• 각 원자는 독립적이고 필요할 때만 구독/업데이트
• Bottom-up 방식 (작은 것부터 조합해서 큰 것을 만듦)

라이브러리:

• Jotai: atom()함수로 원자 생성
• Recoil: atom()과 selector() 사용

장점:

• 필요한 부분만 리렌더링
• 컴포넌트별 필요한 상태만 구독

2️⃣ Flux Pattern

개념:

• 단방향 데이터 플로우 아키텍처
• Action → Dispatcher → Store → View → Action 순환

  Action → Dispatcher → Store → View ↑ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ↓ ←←←←←←←←←←←←←←←←←

라이브러리:

• Redux: Flux의 단순화된 구현
• Zustand: Flux 패턴을 간소화

장점:

• 예측 가능한 상태변화
• 디버깅 용이 및 액션을 통한 상태 변경만 허용

3️⃣ Proxy Store

개념:

• 객체에 대한 접근과 수정을 가로채서 반응성 구현
• 불변성 관리 없이 직접 뮤테이션 가능

라이브러리:

• Valtio: 가장 대표적인 Proxy 기반 라이브러리
• MobX: Proxy + 데코레이터 패턴 (관찰 가능한 상태)

장점:

• 직관적인 상태 변경 (일반 객체처럼 사용)
• 자동 최적화

예시 (Valtio):

const state = proxy({ count: 0 })

// 직접 변경 가능
state.count += 1

🥹 그래서 언제 무엇을 선택하면 될까?

• Atomic Store (Jotai, Recoil)

  상태 간 복잡한 의존성 있을 때 세밀한 성능 최적화가 필요할 때 상태를 작은 단위로 나누어 관리하고 싶을 때

• Flux Pattern (Redux, zustand)

  예측 가능한 상태 변화가 중요할 때 팀 개발에서 일관성이 필요할 때 디버깅과 테스트가 중요할 때

• Proxy Store (Valtio, Mobx)

  빠른 프로토타이핑이 필요할 때 불변성 관리가 번거로울 때 직관적인 코드 작성을 원할 때

• Basic Type Int, Double, String, Bool 등

• Custom Type (사용자 정의 타입) Enum, Class, Struct

• Tuple 데이터들을 소괄호로 묶어서 간단하게 사용 할 수 있음.. (String, Int, String)

• Collection 아이템들이 들어가는 것 (Array, Dictionary, Set)

모든 데이터 타입은 옵셔널 처리가 가능하다

💡 메모리 구조 이해 (CS 관점 동작원리)

• 코드 영역: 함수 및 명령어 저장
• 데이터 영역: 전역 변수 저장
• 스택 영역: 함수 실행 시 생성되는 지역 변수, 파라미터
• 힙 영역: 클래스 인스턴스 등 동적 메모리 할당

Swift 기초 문법 흐름

• 변수/상수
• 기본연산자 (% 주의)
• 조건문(if/switch)
• 튜플
• 삼항/범위 연산자(...)
• 반복문(for/while)

함수

• 파라미터 → 스택에 저장
• 호출 시 → 스택 프레임에 쌓이며 실행

옵셔널

• 값이 있을 수도, 없을 수도 있는 타입
• 선언 예: var name: String?

처리 방법

• ! 강제 언래핑
• if let 바인딩
• guard let 바인딩
• ?? 닐 병합 (기본값 제공)

컬렉션

• Array, Dictionary, Set
• 각각 순서/키-값/중복제거 등의 목적

열거형

enum Weekday {
  case monday, tuesday, wednesday
}

한정된 사례를 통하여 개발자가 직접 만들 수 있는 Type

이후 학습 주제 정리

• func 키워드를 이용해 이름을 붙여주는 함수

클로저에는 두가지 종류가 있다.

1. Named Closure
2. Unnamed Closure

우리가 여태 써왔던 이름이 있는 함수는

func doSomething() {
        print("Named Closure")
}

이런 Named Closure이다. 하지만 이것을 클로저라고 부르지 않고 그냥 함수라고 불렀던 것이다.

그리고 이름을 붙이지 않고 사용하는 함수를

let closure = { print("Unnamed Closure") }

익명함수, 즉 Unnamed Closure 라고 부르는 것이다.

정리하자면

클로저는 Named Closure & Unnamed Closure 둘다 포함하지만,

보통 Unnamed Closure 를 말한다.

클로저 표현식

{ (Parameters) -> Return Type in
     실행 구문
}

이렇게 표현식을 사용하는데, 익명 함수인 만큼 func 이란 키워드를 사용하지 않는다.

그리고 클로저는 Closure Head와 Closure Body로 이루어져 있는데

{ (Parameters) -> Return Type in
     실행구문
}

// Closure Head : (Parameters) -> Return
// Closure Body : 실행구문

이 둘을 구분지어주는게 바로 in 이라는 키워드이다.

☝ Parameter와 Return Type이 둘 다 없는 클로저

클로저는 익명이긴 하지만 함수이다.

따라서 Swift에서 1급 객체이기 때문에 상수에 클로저를 대입할 수 있다.

특히 Parameter 와 Return Type이 둘 다 없는 경우는 다음과 같이 사용함

let closure = { () -> () in
        print("Closure")
}

Return Type 이 있어도, 없어도 생략 가능하고 Parameter 조차 생략 가능하다.

✌ Parameter와 Return Type이 있는 클로저

let driving = { (place: String) -> String in
    return "저는 차를타고 \(place)에 가고 있습니다."
}

Parameter와 Return Type이 있는 경우는 이렇게 표시한다.

함수 때 배운 대로 Parameter의 place는 단독으로 쓰였으니, Argument Label이자 Parameter Name이라고 생각할 수 있지만,

⭐ 클로저에선 Argument Label을 사용하지 않는다 ⭐

따라서, name은 Argument Label이 아니고, 오직 Parameter Name 이다.

클로저를 호출할 때는 Argument Label을 사용하지 않는다 !!

driving("회사") // 저는 차를 타고 회사에 가고 있습니다.
driving(place: "회사") // Error!

사용할 시 에러가 난다….!

1급 객체로서 클로저

1. 클로저를 변수나 상수에 대입할 수 있다.

   ⇒ 클로저를 변수나 상수에 대입할 수 있고, 대입된 변수나 상수를 실행 시키는 것이 가능하다.

let closure = { () -> () in
        print("Closure")
}

let closure2 = closure

2. 함수의 파라미터 타입으로 클로저를 전달할 수 있다.

func doSomething(closure: () -> ()) {
        closure()
}

이런 식으로 함수를 파라미터로 전달받는 doSomething 이라는 함수가 있는데

파라미터로 함수를 넘겨줘도 되지만

doSomething(closure: { () -> () in
        print("Hello!")
})

// 클로저로 작성된 부분 : { () -> () in print("Hello!") }

이렇게 클로저를 넘겨줘도 된다.

doSomething이란 함수에서 파라미터로 전달받은 함수를 실행시키면

작성한 클로저가 실행된다.

3. 함수의 반환 타입으로 클로저를 사용할 수 있다.

func doSomething() -> () -> () {

        return { () -> () in
                print("Hello JE!")
        }
}

선언부는 기존 함수와 똑같지만 return할 때 실제 값을 함수가 아닌 클로저를 리턴 할 수 있다.

let closure = doSomething()
closure() // Hello JE!

또한 호출하는 곳에서 클로저를 받아서 이렇게 실행시킬 수 있다.

클로저 실행

• 클로저가 대입된 변수나 상수로 호출

let closure = { () -> String in
        return "Hello JE!"
}

closure()  // Hello JE!

이런 식으로 클로저가 대입된 상수 closure를 호출 구문인 ()를 이용해서 실행시킬 수 있다.

• 클로저를 직접 실행하기

({ () -> () in
        print("Hello JE!")
})()  // Hello JE!

클로저를 변수나 상수에 대입하지 않고 실행시키고 싶다면, (완벽한 일회성)

그땐 클로저를 ( ) 소괄호로 감싸고, 마지막에 호출 구문인 ()를 추가해주면 된다.

📖 참고

https://babbab2.tistory.com/81

• nil을 사용할 수 있는 타입과 없는 타입을 구분하기 위함이며, nil을 사용할 수 있는 Type을 Optional Type이라 부른다.

쉽게 설명하자면

nil 이라는 값을 가질 수 있으면 Optional Type이고,

Optional Type을 선언할 때 타입 옆에 ? 를 붙인다.

let name: String? // String? = Optional Type
let age: Int? // Int? = Optional Type

nil이란?

• 변수에 객체가 할당되지 않은 상태 “값이 없음”을 뜻한다.
  

  ⇒ nil과 null은 다르다!

  Nil : 오류가 났지만, 앱 중단시키는 것 대신 nil을 돌려줄 테니 오류 난 것을 알려줄 때 사용 Null : 어떠한 값도 가지지 않고 있다는 뜻

let dictHuman = ["name": "je", "gender": "female"]

let name = dictHuman["name"] // "je"
let gender = dictHuman["je"] // nil

name이라는 key에 접근을 하면 je 이라는 value가 잘 뜨지만,

je이라는 key에 접근을 했을 때 dictHuman에는 je이라는 key가 존재하지 않기 때문에 nil이 뜸

Non-Optional Type과 Optional Type

• nil은 오류가 발생했을 때 오류 대신 뱉는 값이라고 하였다.

  어떤 자료형이든 nil을 반환하고 저장 할 수 있을까? → NO !! 절대 불가능하다

nil을 저장할 수 있는 건 오로지 Optional로 선언된 자료형 뿐이다.

Non-Optional Type은 선언과 동시에 초기화 해주던가 Type Annotation을 사용해야 된다.

⇒ 이 친구는 무조건 값을 가져야 한다 !! 값이 없으면 오류 발생 !!!!

Optional Type

1. Type Annotation 이용
2. Type Inference 이용 → 타입 추론, ⭐초기화 되는 값이 무조건 Optional 자료형⭐ 이여야 된다

// Type Annotation
var name: String?
name = nil // ?로 선언된 name에는 nil 저장 가능

// Type Inference
let a: Int? = nil
let b = a
print(b) // nil

아까 nil이란? 을 설명했을 때

let gender = dictHuman["je"] // nil

위 구문이 가능했던 이유는 dictHuman에서 value값을 가져오는 의 원형을 보면

@inlinable public subscript(key: Key) -> Value?

subScript 리턴 값이 옵셔널로 선언되어 있다.

따라서 dictHuman[”je”]의 리턴 값은 옵셔널 자료형인거고,

상수 gender는 타입 추론에 의해 옵셔널 자료형을 갖게 된 것이다.

Type

var today: String
var weather: String?

print(type(of: today))    // String
print(type(of: weather))  // Optional<String>

• Non-Optional Type과 Optional Type의 자료형 결과값은 다르다

  Non-Optional Type = String Type Optional Type = Optional Type

📖 참고

https://babbab2.tistory.com/15