img, srcset, picture, lazy loading 이해하기

웹 페이지에서 이미지를 표시할 때 가장 먼저 떠오르는 태그는 img 태그다.

<img src="/product.jpg" alt="상품 이미지" />

이미지를 화면에 보여주는 것만 생각한다면 이것으로 충분해 보인다.

하지만 문득 이런 궁금증이 들었다.

화면에는 200px 크기로 보이는데, 브라우저는 정말 200px 크기의 이미지만 다운로드하고 있을까?

이 질문을 시작으로 img, srcset, picture, lazy loading이 왜 등장하게 되었는지 정리해보았다.

img 태그만 사용하면 어떤 일이 일어날까?

다음과 같은 이미지가 있다고 가정해보자.

• 실제 이미지 크기: 1200 × 1200
• 파일 용량: 500KB

그리고 화면에서는 아래처럼 렌더링된다.

<img src="/product.jpg" alt="상품 이미지" />

img {
  width: 200px;
  height: 200px;
}

사용자 눈에는 200px 크기로 보인다.

하지만 브라우저는 CSS가 적용된 최종 렌더링 크기를 기준으로 이미지를 다운로드하지 않는다.

src에 명시된 원본 이미지를 다운로드한 뒤, 렌더링 과정에서 200px 크기로 축소한다.

즉,

• 보여지는 크기: 200px
• 다운로드되는 크기: 1200px

일 수 있다.

이미지 한 장이라면 큰 문제가 아닐 수 있다.

하지만 상품 목록 페이지처럼 이미지가 수십 개 존재한다면 이야기가 달라진다.

500KB × 20장 = 10MB

사용자는 실제로 필요하지 않은 데이터를 다운로드하고 있을 수도 있다.

브라우저는 어떤 이미지를 내려받아야 하는지 모른다

사실 브라우저 입장에서는 당연한 행동이다.

<img src="/product.jpg" />

이 정보만 보고는

• 사용자의 화면 크기
• 디바이스 해상도
• 실제 렌더링 크기

를 정확히 판단할 수 없다.

브라우저는 단순히

"product.jpg를 요청하라고 했으니 product.jpg를 다운로드해야겠다."

라고 생각한다.

그래서 등장한 것이 srcset이다.

srcset은 어떤 문제를 해결할까?

srcset은 브라우저에게 여러 크기의 이미지 후보를 제공하는 기능이다.

<img
  src="product-400.jpg"
  srcset="
    product-400.jpg 400w,
    product-800.jpg 800w,
    product-1200.jpg 1200w
  "
  alt="상품 이미지"
/>

이제 브라우저는

• 현재 화면 크기
• 디바이스 픽셀 비율(DPR)

을 고려하여 적절한 이미지를 선택할 수 있다.

예를 들어

처럼 동작할 수 있다.

즉, 브라우저가 상황에 맞는 이미지를 스스로 선택할 수 있게 된다.

Retina 디스플레이에서는 어떻게 될까?

같은 200px 영역이라도 디바이스마다 필요한 이미지 크기가 다르다.

예를 들어 DPR(Device Pixel Ratio)이 2인 환경에서는

200px 영역
↓
실제로는 400px 이미지 필요

할 수 있다.

그래서 브라우저는 단순히 화면 크기만 보는 것이 아니라 디바이스 해상도까지 고려해서 이미지를 선택한다.

srcset이 없다면

• 너무 큰 이미지를 받거나
• 너무 작은 이미지를 받아 흐릿하게 보이는

문제가 발생할 수 있다.

picture 태그는 왜 등장했을까?

srcset은 같은 이미지의 크기만 바꾸는 데 적합하다.

하지만 경우에 따라서는 아예 다른 이미지를 제공해야 할 수도 있다.

예를 들어

• 모바일에서는 세로 이미지
• 데스크톱에서는 가로 이미지

를 보여주고 싶을 수 있다.

이때 사용하는 것이 picture 태그다.

<picture>
  <source
    media="(min-width: 768px)"
    srcset="/banner-desktop.jpg"
  />

  <source
    media="(max-width: 767px)"
    srcset="/banner-mobile.jpg"
  />

  <img src="/banner.jpg" alt="배너" />
</picture>

브라우저는 조건에 맞는 이미지를 선택하여 렌더링한다.

즉,

srcset은 "어떤 크기의 이미지를 사용할까?"를 해결하고,

picture는 "어떤 이미지를 사용할까?"를 해결한다.

이미지 포맷도 최적화 대상이다

이미지 최적화는 크기만의 문제가 아니다.

포맷 역시 중요하다.

일반적으로 다음과 같은 압축 효율을 가진다.

이를 활용하면 같은 이미지를 더 작은 용량으로 제공할 수 있다.

<picture>
  <source
    srcset="/product.avif"
    type="image/avif"
  />

  <source
    srcset="/product.webp"
    type="image/webp"
  />

  <img src="/product.jpg" alt="상품" />
</picture>

브라우저는 지원 가능한 가장 효율적인 포맷을 선택한다.

모든 이미지를 한 번에 다운로드해야 할까?

상품 목록 페이지를 생각해보자.

사용자가 처음 보는 영역은 화면 상단뿐이다.

그런데 아래쪽에 있는 이미지까지 모두 다운로드한다면 어떨까?

초기 로딩 시간이 길어질 수 있다.

이를 해결하기 위해 등장한 것이 Lazy Loading이다.

<img
  src={imageUrl}
  alt={name}
  loading="lazy"
/>

브라우저는 해당 이미지가 화면에 가까워졌을 때 다운로드를 시작한다.

결과적으로

• 초기 페이지 로딩 속도 개선
• 네트워크 사용량 감소

효과를 얻을 수 있다.

특히 무한 스크롤이나 상품 목록 페이지에서 유용하다.

CLS는 왜 발생할까?

이미지와 관련하여 자주 언급되는 성능 지표 중 하나가 CLS(Cumulative Layout Shift)다.

다음 코드를 보자.

<img src="/product.jpg" alt="상품" />

브라우저는 이미지 크기를 알 수 없기 때문에 처음에는 공간을 확보하지 못한다.

이후 이미지가 로딩되면 갑자기 공간이 생기면서 화면이 밀릴 수 있다.

사용자는

• 읽고 있던 위치가 바뀌고
• 버튼 위치가 움직이고
• 의도치 않은 클릭을 하게 될 수도 있다

이를 방지하려면 이미지 크기를 미리 알려주는 것이 좋다.

<img
  src="/product.jpg"
  alt="상품"
  width="300"
  height="300"
/>

또는 CSS의 aspect-ratio를 활용할 수도 있다.

정리

처음에는 단순히 이미지를 보여주는 태그라고 생각했던 img 태그가 생각보다 많은 고민을 담고 있다는 것을 알게 되었다.

이미지 최적화는 단순히 파일 용량을 줄이는 것이 아니다.

브라우저가

• 어떤 이미지를 다운로드해야 하는지
• 언제 다운로드해야 하는지
• 어떤 포맷을 사용해야 하는지

를 효율적으로 결정할 수 있도록 돕는 과정에 가깝다.

정리하면,

• srcset : 적절한 크기의 이미지를 선택하기 위해
• picture : 상황에 따라 다른 이미지를 제공하기 위해
• WebP / AVIF : 더 작은 용량으로 전달하기 위해
• loading="lazy" : 필요한 시점에 다운로드하기 위해
• width / height : CLS를 방지하기 위해

사용할 수 있다.

실제로 원본 이미지(1200px)와 srcset 적용 후 다운로드 크기를 비교한 실험 결과를 추가해볼 예정

이 글에서 다루는 것:

1. 제네릭 + 제약(extends)
2. 함수 오버로드 vs 유니온
3. unknown vs any — 그리고 API 응답/에러 타입 정의

1. 제네릭 + 제약(extends)

언제 쓰나: 여러 타입에 똑같이 동작하는 함수/타입을 만들되, 입력에 따라 반환 타입이 달라져야 할 때. 그리고 아무 타입이나 받으면 안 되고 일정 조건을 만족하는 타입만 받고 싶을 때 extends로 제약.

문제 상황: any로 받으면 타입 정보가 사라진다.

function first(arr: any[]): any {
  return arr[0]; // 반환이 any — 이후 타입 안전성 상실
}

패턴: 제네릭 T로 입력·출력 타입을 연결한다. 필요하면 extends로 제약.

function first<T>(arr: T[]): T | undefined {
  return arr[0]; // 입력 타입 그대로 반환
}
first([1, 2, 3]);  // number | undefined
first(["a", "b"]); // string | undefined

// 제약: id를 가진 타입만 허용
function getId<T extends { id: number }>(item: T): number {
  return item.id;
}
getId({ id: 1, name: "김" }); // ✅
getId({ name: "김" });        // ❌ id 없음

주의점: 제네릭을 남용해 실제로는 한 타입에만 쓰이는데 <T>를 붙이면 오히려 복잡해진다. "정말 여러 타입에 재사용되는가"를 기준으로 판단.

2. 함수 오버로드 vs 유니온

언제 쓰나: 하나의 함수가 입력에 따라 다른 반환 타입을 가질 때. 입력·출력의 조합이 정해져 있으면 오버로드, 단순히 여러 타입을 받기만 하면 유니온.

패턴 A — 유니온 (입출력 관계가 느슨할 때):

function format(value: string | number): string {
  return String(value);
}

패턴 B — 오버로드 (입력에 따라 반환이 달라질 때):

function parse(value: string): string;
function parse(value: number): number;
function parse(value: string | number): string | number {
  return typeof value === "string" ? value.trim() : value * 2;
}

const a = parse("hi"); // string으로 추론
const b = parse(42);   // number로 추론

주의점: 오버로드는 선언 시그니처(위 두 줄)와 구현 시그니처(세 번째)가 분리된다. 구현 시그니처는 호출자에게 보이지 않는다. 유니온으로 충분하면 오버로드는 과하다 — 반환 타입이 입력에 따라 갈릴 때만 쓴다.

3. unknown vs any — 그리고 API 에러 처리

언제 쓰나: 타입을 아직 모르는 값(API 응답, JSON.parse 결과, 외부 입력, catch의 error)을 다룰 때. 결론부터: any 대신 unknown을 써라.

3-1. any는 검사를 끄고, unknown은 검사를 강제한다

const data: any = JSON.parse(res);
data.user.name.toUpperCase(); // 런타임에 터져도 컴파일러 침묵 ❌

any는 타입 검사를 통째로 꺼버린다. 반면 unknown은 쓰기 전에 좁히기를 강제한다.

const data: unknown = JSON.parse(res);

// 바로 못 씀 — 검증을 강제당함
if (typeof data === "object" && data !== null && "user" in data) {
  // 여기서 타입 가드로 더 좁혀서 사용
}

핵심 차이: any는 "검사 끄기", unknown은 "검사하기 전엔 못 씀". 외부에서 들어오는 모든 값의 기본 타입은 unknown으로 두는 습관이 안전하다.

3-2. API 응답 타입 정의 — 성공과 실패를 함께

실무에서 API 응답은 성공만 있는 게 아니다. 성공/실패를 discriminated union(1편 참고)으로 정의하면, 응답을 다루는 쪽에서 안전하게 분기된다.

// 성공 시 데이터, 실패 시 에러 정보
type ApiResponse<T> =
  | { success: true; data: T }
  | { success: false; error: ApiError };

// 에러 자체의 타입도 명확히 정의
interface ApiError {
  code: string;      // 예: "UNAUTHORIZED", "NOT_FOUND"
  message: string;   // 사용자/개발자용 메시지
  status: number;    // HTTP 상태 코드
}

이제 응답을 쓰는 쪽:

function render(res: ApiResponse<User>) {
  if (res.success) {
    res.data.name;    // ✅ User
  } else {
    res.error.message; // ✅ ApiError
    res.error.status;  // ✅ number
  }
}

3-3. catch의 error는 unknown이다

TypeScript 4.4+에서 catch의 error는 기본이 unknown이다(그 전에는 any였다). error.message를 바로 못 쓴다 — 검증이 필요하다.

try {
  await fetchUser();
} catch (error) {
  // error는 unknown — 바로 .message 접근 불가
  console.log(error.message); // ❌ 컴파일 에러
}

패턴: 에러 형태를 좁히는 타입 가드를 만들어 둔다.

// Error 인스턴스인지 확인
function isError(value: unknown): value is Error {
  return value instanceof Error;
}

// 우리가 정의한 ApiError 형태인지 확인
function isApiError(value: unknown): value is ApiError {
  return (
    typeof value === "object" &&
    value !== null &&
    "code" in value &&
    "status" in value
  );
}

try {
  await fetchUser();
} catch (error) {
  if (isApiError(error)) {
    console.log(error.status, error.message); // ✅ ApiError로 좁혀짐
  } else if (isError(error)) {
    console.log(error.message);               // ✅ 표준 Error
  } else {
    console.log("알 수 없는 에러", error);     // 최후의 폴백
  }
}

3-4. 실전 조합: fetch 래퍼

위 조각들을 합치면, 던지지 않고 항상 ApiResponse를 반환하는 안전한 래퍼가 된다.

async function apiFetch<T>(url: string): Promise<ApiResponse<T>> {
  try {
    const res = await fetch(url);

    if (!res.ok) {
      return {
        success: false,
        error: { code: "HTTP_ERROR", message: res.statusText, status: res.status },
      };
    }

    const data = (await res.json()) as T; // 실무에선 zod 등으로 검증 권장
    return { success: true, data };
  } catch (error) {
    return {
      success: false,
      error: {
        code: "NETWORK_ERROR",
        message: isError(error) ? error.message : "요청 실패",
        status: 0,
      },
    };
  }
}

// 호출부 — 성공/실패가 타입으로 강제 분기됨
const res = await apiFetch<User>("/api/user/1");
if (res.success) {
  console.log(res.data.name);
} else {
  console.log(res.error.code, res.error.message);
}

주의점:

• as T로 응답을 단언한 부분은 여전히 "우기기"다. 신뢰할 수 없는 외부 데이터라면 zod 같은 스키마 검증 라이브러리로 런타임 검증까지 하는 게 안전하다. unknown의 가치는 좁히기를 강제하는 데 있는데, 결국 as로 우겨버리면 any와 다를 게 없어진다.
• 에러 타입(ApiError)을 프로젝트 전역에서 하나로 정의해두면, 에러 처리 코드가 일관되고 새 에러 코드를 추가하기도 쉽다.

정리

실무 기본기의 관통 원칙: 외부에서 들어오는 값은 믿지 말고, 타입 시스템 경계에서 검증하라. unknown으로 받아 좁혀 쓰는 습관 하나가 런타임 에러를 크게 줄인다.

이전 편: 타입 조작 — as const, keyof typeof, 유틸리티 타입

이 글에서 다루는 것:

1. as const
2. keyof typeof
3. 내장 유틸리티 타입
4. 템플릿 리터럴 타입

1. as const

언제 쓰나: 배열이나 객체 리터럴을 넓은 타입이 아니라 정확한 리터럴 타입으로 고정하고 싶을 때. 상수 목록에서 유니온 타입을 뽑는 출발점.

문제 상황: 그냥 선언하면 타입이 넓어진다.

const categories = ["food", "beverage", "goods"];
// 타입: string[]  ← "food" 같은 리터럴 정보 사라짐

패턴: as const로 읽기 전용 리터럴로 고정한다.

const categories = ["food", "beverage", "goods"] as const;
// 타입: readonly ["food", "beverage", "goods"]

type Category = typeof categories[number];
// "food" | "beverage" | "goods"

이렇게 하면 카테고리 목록이 categories 한 곳에서만 관리되고, 타입은 거기서 자동으로 파생된다. 새 카테고리를 추가할 때 배열만 고치면 타입이 따라온다.

주의점: as const가 붙은 값은 읽기 전용이 된다. push() 등 변경 메서드를 쓰려 하면 에러 — 상수니까 의도된 동작이다. 값을 좁은 타입으로 우기는 as Category와는 완전히 다른 용도이니 혼동하지 말 것. (as const는 "최대한 좁게 읽어달라"는 요청이고, as Category는 "검증 없이 이 타입이라 쳐"라는 우기기다.)

2. keyof typeof

언제 쓰나: 객체의 키들만 허용하는 타입이 필요할 때. 라벨 맵, 설정 객체, 상수 테이블에서 키 목록을 타입으로 재사용.

문제 상황: 객체 키를 문자열로 받으면 오타를 못 잡는다.

const LABELS = { food: "식품", beverage: "음료", goods: "잡화" };

function getLabel(key: string) {
  return LABELS[key]; // key가 뭐든 통과, 오타 못 잡음
}

패턴: typeof로 값의 타입을, keyof로 그 키들을 유니온으로 뽑는다.

const LABELS = { food: "식품", beverage: "음료", goods: "잡화" } as const;

type LabelKey = keyof typeof LABELS;
// "food" | "beverage" | "goods"

function getLabel(key: LabelKey) {
  return LABELS[key]; // ✅ 정의된 키만 허용
}

주의점: typeof(값 → 타입)와 keyof(타입 → 키 유니온)는 방향이 다른 별개 연산자다. keyof typeof X는 "X라는 값의 타입에서 키를 뽑아라"로 읽으면 된다. as const와 짝을 이룰 때 가장 강력하다.

3. 내장 유틸리티 타입

언제 쓰나: 이미 있는 타입을 조금 변형한 타입이 필요할 때. 매번 새로 정의하지 말고 조합한다.

type User = { id: number; name: string; email: string };

type UserUpdate = Partial<User>;              // 전부 옵셔널
type UserPreview = Pick<User, "id" | "name">; // { id, name }
type NewUser = Omit<User, "id">;              // id 제외
type Settings = Record<Category, boolean>;    // { food: boolean, ... }

function createUser() { return { id: 1, name: "김" }; }
type Created = ReturnType<typeof createUser>; // { id: number; name: string }

주의점: 유틸리티 타입은 조합할 때 강력하다. Partial<Omit<User, "id">>처럼 중첩 가능. 다만 과하게 중첩하면 가독성이 떨어지니, 자주 쓰는 조합은 별도 타입으로 이름을 붙이는 게 낫다.

4. 템플릿 리터럴 타입

언제 쓰나: 문자열의 형식/패턴 자체를 타입으로 강제하고 싶을 때. ID 접미사, 이벤트 이름, CSS 단위 등.

문제 상황: string으로 받으면 형식이 자유로워 실수가 난다.

function getById(id: string) {} // "user_1"이든 "asdf"든 통과

패턴: 백틱과 ${}로 문자열 패턴을 타입화한다.

type UserId = `user_${number}`;
type EventName = `on${Capitalize<string>}`; // onClick, onScroll...

const id: UserId = "user_1";   // ✅
const bad: UserId = "user_x";  // ❌ number 자리에 x

주의점: 유니온과 결합하면 조합이 폭발적으로 늘어난다. `${A|B}_${C|D}`는 4가지 조합을 만든다. 편리하지만 너무 큰 유니온은 컴파일러를 느리게 만들 수 있으니 적당히.

정리

타입 조작의 관통 원칙: 타입을 손으로 중복 정의하지 말고, 값이나 기존 타입에서 파생하라. 단일 출처가 유지되면 변경에 강해진다.

이전 편: 좁히기 — 타입 가드, discriminated union, satisfies 다음 편: 실무 기본기 — 제네릭, 오버로드, unknown과 API 에러 처리

useEffect의 cleanup function이란

effect가 반환하는 함수다. 이름 그대로 "정리(clean up)"를 담당한다. 구독 해제, 타이머 clear, 이벤트 리스너 제거, 진행 중인 요청 abort 같은 뒷정리가 여기 들어간다.

useEffect(() => {
  const timer = setInterval(tick, 1000);

  return () => {
    clearInterval(timer); // cleanup
  };
}, []);

cleanup은 언제 호출되나

두 가지 시점이다.

1. 컴포넌트가 언마운트될 때
2. effect가 재실행되기 직전 — 의존성 배열의 값이 바뀌면, 새 effect를 실행하기 전에 이전 effect의 cleanup을 먼저 돌린다.

의존성 배열이 []이면 재실행 자체가 없으므로, 이 경우엔 언마운트 때 딱 한 번만 cleanup이 호출된다.

실행 순서를 타임라인으로 보면 이렇다.

mount → effect
      ↓ (deps 변경)
      cleanup → effect (재실행)
      ↓ (deps 변경)
      cleanup → effect (재실행)
      ↓
unmount → cleanup (마지막 정리)

deps === []이면 가운데 재실행 구간이 통째로 사라지고 mount → effect ... unmount → cleanup만 남는다.

클로저 복습

본론 전에 클로저를 한 번 짚고 가자. 함수는 생성될 때 주변 스코프의 변수를 캡처한다.

function makeCounter() {
  let count = 0;
  return () => ++count; // count를 캡처
}
const counter = makeCounter();
counter(); // 1
counter(); // 2

반환된 함수는 makeCounter가 이미 끝났어도 count에 계속 접근한다. 이 "캡처" 동작이 다음 문제의 핵심이다.

stale closure — cleanup이 옛날 값을 보는 이유

cleanup 함수도 결국 클로저다. 생성된 시점의 값을 캡처한다. 그리고 deps === []이면 cleanup은 첫 렌더 때 딱 한 번 만들어진다.

문제 코드부터 보자.

function useProductList() {
  const [abortController, setAbortController] =
    useState<AbortController | null>(null);

  useEffect(() => {
    const controller = new AbortController();
    setAbortController(controller);
    fetchProducts({ signal: controller.signal });

    return () => {
      // 이 클로저는 첫 렌더 시점의 abortController를 캡처 → 계속 null
      abortController?.abort(); // 아무 일도 안 일어남
    };
  }, []);
}

cleanup 클로저가 만들어진 첫 렌더 시점에 abortController는 아직 null이다. 이후 setAbortController(controller)로 state를 갱신해도, 클로저가 붙잡은 건 그 순간의 null이다. state가 바뀌면 리렌더는 일어나지만, [] deps라 effect도 cleanup도 다시 만들어지지 않는다. 그래서 언마운트 시 실행되는 cleanup은 여전히 null.abort()를 시도하고, 실제 컨트롤러엔 닿지 못한다.

이렇게 클로저가 낡은 값을 붙잡고 있는 현상을 stale closure라고 부른다.

왜 ref가 이걸 해결하나

useState 대신 useRef로 바꾸면 해결된다.

function useProductList() {
  const abortControllerRef = useRef<AbortController | null>(null);

  useEffect(() => {
    const controller = new AbortController();
    abortControllerRef.current = controller;
    fetchProducts({ signal: controller.signal });

    return () => {
      // 클로저가 캡처하는 건 ref '객체'. .current는 실행 시점의 최신값
      abortControllerRef.current?.abort(); // 실제로 요청 취소됨
    };
  }, []);
}

핵심은 클로저가 캡처하는 대상이 바뀌었다는 것이다.

• state 버전: 클로저가 캡처한 건 null이라는 값. 첫 렌더의 스냅샷이 그대로 박제된다.
• ref 버전: 클로저가 캡처한 건 abortControllerRef라는 객체 참조. 이 객체는 리렌더 내내 동일하고, 내부의 .current만 갈아끼워진다.

cleanup이 실제로 실행되는 시점에 abortControllerRef.current를 읽으면, 그 순간의 최신 컨트롤러가 나온다. 그래서 abort()가 제대로 먹힌다.

state vs ref 비교 정리

마무리 — 판단 기준

정리하면 이렇다.

• 화면에 반영돼야 하는 값은 state. 값이 바뀌면 리렌더가 필요한 것들.
• 렌더링에는 반영할 필요 없지만, 콜백이나 cleanup 안에서 최신값을 읽어야 하는 값은 ref.

useEffect(() => {...}, []) 안에서 최신 state를 참조해야 하는 상황이 생기면, stale closure를 의심하고 ref를 떠올리면 된다. cleanup은 첫 렌더의 클로저를 그대로 물고 실행된다는 점만 기억하면, 왜 값이 안 바뀌는지 헷갈릴 일이 없다.

넓은 타입(string, unknown, 유니온)을 특정 타입으로 안전하게 좁히는 방법들. 공통 목표는 as로 우기지 않고, 런타임 검증을 타입에 연결하는 것.

그러려면 먼저 as가 정확히 뭘 하는지 알아야 한다.

이 글에서 다루는 것:

0. as(타입 단언) — 왜 좁히기가 필요한가
1. is 타입 가드
2. in 연산자 좁히기
3. Discriminated Union
4. Assertion Function (asserts)
5. satisfies

0. as — 타입 단언, 그리고 왜 좁히기가 필요한가

as는 타입 단언(type assertion)이다. 컴파일러에게 "이 값의 타입은 이거야, 내가 책임진다"라고 우기는 것.

const value: unknown = "hello";
const str = value as string; // "얘 string이야" 하고 단언

핵심: as는 런타임에 아무것도 하지 않는다

as는 검사를 하는 게 아니라 검사를 건너뛴다. 트랜스파일되면 흔적도 없이 사라진다. 그래서 단언이 틀려도 컴파일러는 잡아주지 못한다.

const value: unknown = 123;   // 실제로는 숫자
const str = value as string;  // 컴파일 통과 (거짓말인데도)
str.toUpperCase();            // 💥 런타임 에러 — 컴파일러는 침묵

이게 좁히기 패턴들이 존재하는 이유다. as는 타입 시스템의 비상구지 일상 도구가 아니다.

두 방향을 구분하라 — 이게 제일 중요하다

모든 as가 위험한 건 아니다. 방향이 위험을 가른다.

// ❌ 위험: 넓은 타입 → 좁은 타입으로 우기기 (검증을 건너뜀)
const cat = someString as Category;
// someString이 진짜 Category("food" 등)인지 아무도 확인 안 함

// ✅ 상대적으로 안전: 좁은 타입 → 넓은 타입으로 취급 (정보를 버릴 뿐)
const arr = categories as readonly string[];
// Category[]를 string[]로 취급 — 없는 값을 있다고 우기는 게 아님

• 넓은 걸 좁게 우기기: "이 string은 사실 Category야" → 틀릴 수 있고, 틀려도 안 잡힘. 위험.
• 좁은 걸 넓게 취급: "이 Category[]를 그냥 string[]로 봐줘" → 타입 정보를 버릴 뿐 거짓말은 아님. 대체로 안전.

앞으로 나올 includes() 예제에서 (CATEGORIES as readonly string[])가 자주 등장하는데, 이건 후자(안전한 방향)라서 남겨두는 것이다.

as를 정당하게 쓰는 경우

as가 항상 잘못은 아니다. 이럴 땐 정당하다:

1. 런타임 검증을 이미 마친 직후 — includes()나 타입 가드로 확인한 값을 좁힐 때 (이게 뒤에 나올 패턴들의 핵심)
2. 좁은 → 넓은 방향 — 위에서 본 안전한 방향
3. 개발자가 컴파일러보다 확실히 더 많이 아는 경우 — 예: DOM에서 document.getElementById("x") as HTMLInputElement처럼 마크업을 보고 타입을 아는 경우

반대로 검증 없이 넓은 걸 좁게 우기는 as는 피해야 하고, 그 자리엔 거의 항상 더 나은 패턴(is, in, discriminated union...)이 있다.

as에서 꼭 알아야 하는 것

• as는 런타임 검증이 아니다. 컴파일러를 설득할 뿐 실제 타입은 안 바뀐다.
• 넓은 타입 → 좁은 타입으로 우기는 게 위험하다(검증 생략). 반대 방향은 대체로 안전.
• as가 필요해지는 순간이 곧 "더 나은 패턴이 있다"는 신호다.
• 단, 검증 직후의 as나 안전한 방향의 as는 정당하다. "as = 무조건 악"이 아니라 "검증 없는 좁히기 as"가 악이다.

참고 — as의 사촌들

• as any: 검사를 통째로 끈다. 가장 위험. 웬만하면 쓰지 말 것.
• as unknown as T: "이중 단언". as로도 안 되는 억지 변환을 뚫을 때 쓰는데, 이게 필요하다는 건 대개 설계가 잘못됐다는 신호다.
• ! (non-null 단언): value!는 value as NonNullable<...>의 축약. "null 아님을 내가 보장"인데, 이것도 틀리면 런타임에 터진다.

1. is 타입 가드 (커스텀 가드)

언제 쓰나: 어떤 값이 특정 타입인지 런타임에 검사하고, 그 결과를 타입 시스템에도 반영하고 싶을 때. includes(), 속성 존재 확인 등 직접 검증 로직을 짜야 하는 경우.

문제 상황: string을 좁은 유니온으로 좁히려는데 as로 우기게 된다.

type Category = "food" | "beverage" | "goods";
const CATEGORIES: readonly Category[] = ["food", "beverage", "goods"];

function parse(value: string): Category {
  // includes가 Category만 받아서 어쩔 수 없이 as
  return CATEGORIES.includes(value as Category) ? (value as Category) : "food";
}

패턴: 반환 타입을 value is Category로 선언한 함수를 만든다. true면 컴파일러가 이후 value를 Category로 좁힌다.

function isCategory(value: string): value is Category {
  return (CATEGORIES as readonly string[]).includes(value);
}

function parse(value: string): Category {
  return isCategory(value) ? value : "food"; // as 불필요
}

주의점: 타입 가드 내부의 검증 로직이 실제로 맞는지는 개발자 책임이다. value is Category라고 선언해놓고 내부에서 엉뚱한 검사를 하면 컴파일러는 그대로 믿는다. 가드는 "우기기"를 한 곳에 격리하고 재사용 가능하게 만드는 것이지, 검증을 마법처럼 대신해주는 게 아니다.

2. in 연산자 좁히기

언제 쓰나: 유니온 타입에서 특정 속성의 유무로 분기하고 싶을 때. 판별 필드를 따로 두기 애매한 객체 유니온에 적합.

문제 상황: 두 객체 타입이 섞여 있는데, 있는 속성이 서로 다르다.

type Fish = { swim: () => void };
type Bird = { fly: () => void };

function move(animal: Fish | Bird) {
  animal.swim(); // ❌ Bird엔 swim이 없음
}

패턴: in으로 속성 존재를 확인하면 그 분기 안에서 타입이 좁혀진다.

function move(animal: Fish | Bird) {
  if ("swim" in animal) {
    animal.swim(); // ✅ Fish로 좁혀짐
  } else {
    animal.fly();  // ✅ Bird로 좁혀짐
  }
}

주의점: 속성 이름 오타를 잡아주지 못한다("swm" in animal은 그냥 false). 구조가 복잡해지면 다음의 discriminated union이 더 안전하다.

3. Discriminated Union (판별 유니온)

언제 쓰나: 여러 형태의 값을 다루는데, 각각을 명확히 구분하는 공통 리터럴 필드를 둘 수 있을 때. API 응답, 상태 관리, 이벤트 처리의 표준 패턴.

문제 상황: 성공/실패 응답을 하나의 타입으로 다루면서 안전하게 분기하고 싶다.

패턴: 공통 판별 필드(status, type, kind 등)를 리터럴로 두고 유니온을 만든다.

type ApiResult =
  | { status: "success"; data: string[] }
  | { status: "error"; message: string };

function handle(result: ApiResult) {
  if (result.status === "success") {
    result.data;    // ✅ data 접근 가능
  } else {
    result.message; // ✅ message 접근 가능
  }
}

주의점: 판별 필드는 반드시 리터럴 타입이어야 한다(status: string이면 좁혀지지 않음). never를 활용한 exhaustive check를 곁들이면 분기 누락도 컴파일 타임에 잡을 수 있다.

function handle(result: ApiResult) {
  switch (result.status) {
    case "success": return result.data;
    case "error":   return result.message;
    default:
      const _exhaustive: never = result; // 새 케이스 추가 시 여기서 에러
      return _exhaustive;
  }
}

4. Assertion Function (asserts value is T)

언제 쓰나: 조건이 안 맞으면 아예 진행을 멈춰야(throw) 할 때. 가드가 boolean을 리턴한다면, assertion function은 통과하지 못하면 예외를 던진다. 입력 검증, 불변식(invariant) 체크에 적합.

문제 상황: null일 수 있는 값을 매번 if (x === null) throw ...로 검사하는 게 반복된다.

패턴: 반환 타입을 asserts value is T로 선언한다. 이 함수를 통과하면 이후 코드에서 타입이 좁혀진다.

function assertDefined<T>(value: T): asserts value is NonNullable<T> {
  if (value === null || value === undefined) {
    throw new Error("값이 없습니다");
  }
}

function useUser(user: User | null) {
  assertDefined(user);
  user.name; // ✅ 여기서 user는 User (null 제거됨)
}

타입 가드와의 차이:

주의점: assertion function은 반환 타입 애노테이션이 없으면 동작하지 않는다. function assertDefined(value): asserts value is ...처럼 명시적으로 써야 한다. 화살표 함수에 타입 추론으로는 안 된다.

5. satisfies — as의 건강한 대안

언제 쓰나: 객체/값이 특정 타입을 만족하는지 검사하고 싶지만, 추론된 좁은 타입은 그대로 유지하고 싶을 때. as를 쓰고 싶어지는 상황의 대부분이 사실 이것.

문제 상황: as로 타입을 맞추면 구체적 정보가 뭉개진다.

type Category = "food" | "beverage" | "goods";

const labels = {
  food: "식품",
  beverage: "음료",
} as Record<Category, string>;

labels.food;    // string (리터럴 손실)
// goods 누락됐는데 as는 통과시킴 ❌

패턴: satisfies는 타입 만족 여부만 검사하고, 실제 타입은 좁게 유지한다.

const labels = {
  food: "식품",
  beverage: "음료",
  goods: "잡화",
} satisfies Record<Category, string>;

labels.food; // "식품" (리터럴 유지)
// goods 빠뜨리면 → 컴파일 에러 ✅

핵심 차이: as는 "이 타입이라고 쳐(검증 없이, 타입 넓힘)", satisfies는 "이 타입 맞는지 검사해줘(추론은 유지)".

주의점: satisfies는 TypeScript 4.9+에서만 쓸 수 있다.

정리

좁히기의 관통 원칙: 런타임 검증과 타입 시스템을 연결하라. as는 이 둘을 끊어버리기 때문에 최후의 수단이다.

다음 편: 타입 조작 — as const, keyof typeof, 유틸리티 타입, 템플릿 리터럴

코드 리뷰에서 이런 질문을 받았습니다.

"React에서 key는 어떤 역할일까요?"

면접에서도 자주 나오는 주제라 이참에 제대로 정리했습니다. key만 따로 떼어 보면 이해가 잘 안 되고, Virtual DOM과 Reconciliation이라는 배경까지 같이 봐야 "아, 그래서 key가 필요하구나"가 됩니다. 그래서 배경부터 짚고 갑니다.

흔한 오해부터

"반복문에서 key를 안 쓰면 에러가 난다"고 알고 있는 경우가 많은데, 정확히는 에러가 아니라 경고(warning)입니다.

Warning: Each child in a list should have a unique "key" prop.

경고가 떠도 화면은 일단 동작합니다. 하지만 key를 제대로 주지 않으면 성능 저하와 상태(state) 관련 버그가 따라옵니다. key는 "경고를 끄는 용도"가 아니라, React가 리스트의 각 요소를 식별하는 핵심 장치입니다.

배경지식 3가지

key를 이해하려면 이 세 개념이 먼저 필요합니다.

Virtual DOM은 실제 DOM을 흉내 낸 메모리 상의 가벼운 JS 객체 트리입니다. 화면에 직접 그려지지는 않습니다. 실제 DOM을 조작하는 건 웹에서 가장 느린 작업이기 때문에, 일단 메모리에서 먼저 계산해 보려는 것입니다.

Reconciliation(재조정)은 state나 props가 바뀌었을 때, React가 새 Virtual DOM 트리를 만들고 이전 트리와 비교해서, 실제 DOM에 적용할 최소한의 변경만 계산해 내는 과정입니다.

Diffing 알고리즘은 그 두 트리를 비교하는 방법입니다. 원래 트리를 통째로 비교하면 O(n³)이지만, React는 몇 가지 가정을 두고 이걸 O(n)까지 낮췄습니다.

1. 타입이 다르면 통째로 교체한다. (<div>가 <span>으로 바뀌면 옛 트리는 버리고 새로 만든다)
2. 같은 타입이면 속성만 업데이트하고 DOM 노드는 재사용한다.
3. 리스트에서는 key로 "어떤 요소가 그대로 유지되는지" 개발자가 힌트를 준다.

세 번째가 바로 key가 등장하는 지점입니다.

key의 진짜 역할

한 문장으로 정리하면 이렇습니다.

key는 "이전 렌더의 어떤 컴포넌트가 = 이번 렌더의 이 컴포넌트인가?"를 알려주는 식별자다.

리스트에서 같은 타입의 요소(<li> 여러 개)가 나열되면, React는 각각을 구분할 방법이 필요합니다. 그 역할을 key가 합니다. 이때 key는 형제 요소들 사이에서만 유일하면 되고, 전역에서 유일할 필요는 없습니다.

한 가지 중요한 점. key는 props가 아닙니다. 컴포넌트 안에서 props.key로 읽을 수 없고, 오직 React 내부의 재조정용으로만 쓰입니다.

비유 — 데스크탑 파일 (공식 문서)

파일에 이름이 없고 "순서"로만 부른다고 상상해 봅시다. "첫 번째 파일, 두 번째 파일..." 이렇게요. 쓸 수는 있지만, 파일 하나를 지우는 순간 순서가 전부 밀려서 헷갈립니다. 반면 파일에 이름(= 안정적인 고유 key)이 있으면, 순서가 바뀌어도 어떤 게 어떤 건지 정확히 식별할 수 있습니다.

왜 index를 key로 쓰면 안 되나

key={index}를 쓰면 린트 경고는 사라집니다. 하지만 리스트가 바뀌는 순간(추가·삭제·정렬) 문제가 터집니다.

성능 문제

[Alice, Bob, Charlie]에 index로 key를 준다고 해봅시다.

<li key="0">Alice</li>
<li key="1">Bob</li>
<li key="2">Charlie</li>

여기서 맨 앞 Alice를 삭제하면 [Bob, Charlie]가 됩니다. 그런데 key가 index 기준이라 React는 이렇게 해석합니다.

key="0": Alice → Bob 으로 바뀜    → 텍스트 업데이트
key="1": Bob → Charlie 로 바뀜    → 텍스트 업데이트
key="2": 사라짐                   → <li> 제거

실제로 필요한 작업은 "맨 앞 노드 1개 삭제"뿐인데, 업데이트 2번 + 삭제 1번을 하고 있습니다. 리스트가 크고 각 항목이 무거우면 이 낭비가 커집니다.

고유 id를 key로 쓰면 이렇게 됩니다.

<li key="a1">Alice</li>  ← 이 key가 사라짐 → Alice만 정확히 제거
<li key="b2">Bob</li>
<li key="c3">Charlie</li>

상태 버그 — 이쪽이 더 무섭다

각 항목이 자체 상태를 가진 컴포넌트일 때(펼침/접힘, 체크박스, 입력값 등) 진짜 문제가 생깁니다.

리스트를 뒤집거나 정렬하면 index는 그대로인데 그 자리에 들어오는 내용물이 바뀝니다. React는 key=1이면 같은 컴포넌트라고 판단해서 상태를 그대로 유지합니다. 그 결과 Alice에 입력한 값이 엉뚱하게 Bob 자리에 남는 버그가 생깁니다.

여기서 반드시 기억할 규칙이 있습니다.

같은 key = 같은 컴포넌트 인스턴스 = 상태 유지 다른 key = 새 인스턴스 = 상태 초기화

그래서 어떻게 해야 하나

// 권장: 안정적이고 고유한 값
{products.map((product) => (
  <ProductCard key={product.id} {...product} />
))}

좋은 key가 갖춰야 할 조건은 세 가지입니다.

1. 고유하다 — 형제 요소들 사이에서.
2. 안정적이다 — 매 렌더마다 바뀌지 않는다. key={Math.random()}은 절대 금지입니다. 매번 새 값이 나와서 모든 항목이 매 렌더마다 새로 만들어집니다.
3. 예측 가능하다 — 같은 데이터면 항상 같은 key가 나온다.

이 프로젝트에서의 적용

상품 리스트는 정렬·필터·무한스크롤로 항목이 계속 바뀌는 리스트입니다. 그래서 index를 key로 쓰면 정렬할 때 상태 버그가 날 위험이 있고, product.id를 key로 쓰는 게 정답입니다.

<ProductCard key={`product-card-${product.id}`} {...product} />

요약

• key의 역할: 리스트에서 "이전 렌더의 어떤 요소가 이번 요소와 같은지"를 React가 식별하는 값. Reconciliation에서 최소한의 DOM 변경을 계산하는 근거가 된다.
• index anti-pattern: 리스트가 바뀌면 index와 내용의 매칭이 어긋나서 ① 불필요한 DOM 연산(성능 저하) ② 상태가 엉뚱한 항목에 남는 버그가 생긴다.
• 정답: 데이터의 안정적이고 고유한 id를 key로 쓴다. (같은 key면 상태 유지, 다른 key면 상태 초기화)

React로 무한스크롤을 직접 구현하다가, 버그 하나를 고쳤더니 다음 버그가 드러나고 그걸 고쳤더니 또 다음 문제가 튀어나온 3연속 디버깅 기록.

들어가기 전 개념 정리

이 글에 자주 나오는 세 용어를 짧게 정리하고 시작한다.

race condition (경쟁 상태)

두 개 이상의 비동기 작업이 동시에 진행될 때, "누가 먼저 끝나느냐"에 따라 결과가 달라지는 상황이다. 실행 순서가 보장되지 않기 때문에, 먼저 보낸 요청이 나중에 도착하거나 그 반대가 되면 의도치 않은 결과가 나온다. 이 글에서는 이전 카테고리 요청의 늦은 응답이 새 카테고리 목록에 끼어든 게 바로 race condition이다.

StrictMode

React가 개발 모드에서만 켜는 검사 도구다. 컴포넌트를 일부러 mount → unmount → remount로 한 번 더 껐다 켜서, effect의 cleanup이 제대로 작성됐는지 미리 드러내 준다. 프로덕션 빌드에서는 동작하지 않는다. 즉 "cleanup을 안 짜두면 여기서 터진다"고 미리 경고해 주는 장치다.

rootMargin

IntersectionObserver의 옵션으로, 요소가 "화면에 보이는지"를 판단하는 경계선을 넓히거나 좁힌다. 예를 들어 "200px"을 주면 뷰포트 실제 경계보다 200px 바깥까지를 "보이는 영역"으로 친다. 무한스크롤에서는 바닥에 완전히 닿기 전에 미리 다음 페이지를 불러오는 용도로 쓴다.

시작: 상태를 store로 일원화했다

쇼핑몰 프로젝트에서 상품 목록 페이지를 만들고 있었다. 커서 기반 페이지네이션 + IntersectionObserver로 무한스크롤을 직접 구현했고, 상세 페이지에 갔다가 뒤로 돌아오면 목록과 스크롤 위치가 복원되는 UX도 넣었다.

처음 구조는 이랬다. 목록 데이터(items, cursor, hasNext, totalCount)는 훅의 로컬 useState에 살고, 언마운트될 때 zustand store에 "스냅샷"으로 저장했다가, 다시 마운트되면 그 스냅샷으로 초기값을 복원하는 방식.

그런데 이 구조엔 문제가 있었다. cleanup 함수는 클로저라서 언마운트 시점의 "최신" 값을 못 본다. 그래서 최신값을 저장하려고 미러 ref 4개 + 동기화 effect 4개를 두고 있었다. 같은 데이터가 로컬 state, 미러 ref, store 스냅샷 — 세 곳에 사는 삼중 구조였다. 리뷰에서도 "훅이 책임이 너무 많다"는 지적을 받았다.

그래서 리팩토링했다. 목록 데이터의 단일 출처를 store로. 로컬 state와 미러 ref를 전부 걷어내니 훅이 절반으로 줄었고, 뒤로가기 복원도 "store에 그냥 남아있으니까" 공짜로 됐다. 코드는 확실히 좋아졌다.

그리고 여기서부터 버그가 시작됐다.

사건 1. 다른 카테고리를 눌렀는데 이전 상품이 남아있다

재현 경로는 이랬다.

1. 식품 카테고리 + 높은가격순으로 스크롤을 쭉 내린다 (다음 페이지 요청이 날아가는 중)
2. 상품 상세로 들어갔다가 뒤로가기
3. 다른 카테고리 클릭
4. 이전 식품 상품 5개 정도가 새 카테고리 목록에 섞여서 남아있다

원인: abort는 인스턴스에, 쓰기는 전역에

원인을 추적해보니 한 문장으로 요약됐다.

요청을 취소하는 장치(AbortController)는 훅 인스턴스에 묶여 있는데, 응답을 쓰는 곳(store의 appendPage)은 전역이다.

타임라인을 펼치면 이렇다.

[식품 마지막 페이지 요청 발사] → 상세 이동(언마운트) → 뒤로가기(리마운트)
→ 카테고리 변경 → resetList() 로 목록 비움 → 새 카테고리 요청 발사
→ 그런데 아까 그 식품 요청이 이제야 도착 → appendPage(식품 5개)  ← 새치기
→ 새 카테고리 응답 도착 → appendPage(20개)  ← 식품 뒤에 붙음

흥미로운 건, 리팩토링 전에는 이 race가 존재했는데도 문제가 안 됐다는 점이다. 목록이 로컬 useState였을 때는 언마운트된 컴포넌트에 setState를 해봤자 React가 조용히 무시했다. 늦게 도착한 응답이 있어도 그냥 버려졌던 것이다.

그런데 쓰기 대상이 전역 store가 되자, 언마운트 후에도 쓰기가 실제로 반영된다. 늦은 응답을 React가 막아주던 암묵적 방어가 사라진 것이다. 게다가 뒤로가기로 리마운트되면 abortControllerRef는 새 인스턴스의 ref라서, 구 인스턴스에서 발사된 요청에는 손이 닿지 않는다. 그 요청은 클로저로 전역 store의 appendPage를 붙잡은 채 살아있다가, resolve되는 순간 목록에 끼어든다.

"왜 하필 5개만 남았나"도 설명이 된다. 커서 페이지네이션에서 마지막 꼬리 페이지는 limit(20)보다 작을 수 있다. 스크롤을 끝까지 내렸을 때 날아가던 요청이 바로 그 ~5개짜리 페이지였던 것이다.

해결: 낡은 응답은 버린다

fetch를 시작할 때 만든 AbortController를 지역 변수로 잡아두고, 응답을 store에 반영하기 직전에 확인한다.

const controller = new AbortController();
abortControllerRef.current = controller;

const response = await fetchProductList({ ..., signal: controller.signal });

// 응답이 도착한 사이에 abort된 요청이면 (필터 변경, 언마운트 등)
// 낡은 응답이므로 반영하지 않고 버린다
if (controller.signal.aborted) return;
appendPage(response.data);

요청마다 새로 만든 controller가 클로저에 잡혀 있으니, "이 응답이 아직 유효한 요청의 것인가"를 응답 시점에 판단할 수 있다. 시퀀스 토큰 같은 더 큰 장치도 고려했지만, 이 가드 하나로 충분했다.

여기서 얻은 교훈: 좋은 리팩토링이 새 버그를 만들 수 있다. 정확히는, 프레임워크가 암묵적으로 해주던 방어를 걷어내면 그 방어를 명시적으로 다시 세워야 한다.

사건 2. 새로고침하면 스켈레톤이 영원히 돈다

사건 1을 고치면서 "언마운트 시 진행 중 요청을 abort하는 cleanup"도 함께 넣었다. 방어를 한 겹 더 두자는 생각이었다. 그랬더니 새 문제가 생겼다.

새로고침하거나 주소를 직접 쳐서 들어가면 초기 요청이 취소되고, 스켈레톤이 영원히 멈춰 있다.

원인: StrictMode × 로딩 가드의 합작

React의 StrictMode는 개발 모드에서 컴포넌트를 일부러 mount → unmount → remount 시킨다. "cleanup이 제대로 작성됐는지" 검증하기 위한 의도된 동작이다. 문제는 여기에 우리의 로딩 가드(isLoadingRef)가 얽히면서 생겼다.

1. 마운트 #1: fetchPage(null) 실행 → isLoadingRef = true, 요청 시작
2. StrictMode 언마운트: cleanup이 abort()
   — 하지만 abort의 rejection 처리는 마이크로태스크라 아직 실행 안 됨
   → finally가 못 돌아서 isLoadingRef는 여전히 true
3. 재마운트: fetchPage(null) 재호출
   → if (isLoadingRef.current) return 에 걸려 즉시 리턴
   (React의 cleanup → 재실행은 동기 블록. 그 사이에 마이크로태스크가 낄 틈이 없다)
4. 그제야 요청 1의 finally가 isLoadingRef = false로 되돌리지만,
   이미 재요청해줄 주체가 없다

결과: 첫 fetch는 취소됐고, 재마운트의 fetch는 가드에 삼켜졌고, 아무도 다시 요청하지 않는다. 스켈레톤만 무한히 돈다.

처음엔 "StrictMode의 가짜 언마운트와 진짜 이탈을 구분하면 되지 않나?" 생각했는데, 이건 안티패턴이다. React가 권장하는 방향은 반대다 — cleanup에서 몇 번을 취소당해도 다시 시작할 수 있게 만드는 것.

해결: 요청의 소유권을 effect에 둔다

fetch를 시작한 effect가 자기 cleanup에서 abort와 가드 리셋까지 책임진다.

useEffect(() => {
  if (!isFetched) fetchPage(null);
  return () => {
    abortControllerRef.current?.abort();
    isLoadingRef.current = false; // abort와 가드 해제를 동기적으로 함께
  };
}, []);

이러면 mount → unmount → remount가 몇 번 반복돼도, 재마운트 시점의 가드는 항상 풀려 있어서 재요청이 성립한다.

하나 더. 가드를 cleanup에서 풀어버리면 반대 방향의 구멍이 생긴다 — 취소당한 옛 요청의 finally가 뒤늦게 돌면서 진행 중인 새 요청의 가드를 풀어버릴 수 있다. 그래서 finally에 소유권 체크를 넣었다.

finally {
  // 내가 아직 최신 요청일 때만 가드를 해제한다
  if (abortControllerRef.current === abortController) {
    isLoadingRef.current = false;
    setIsLoading(false);
  }
}

교훈: 과한 방어가 새 버그를 만든다. 그리고 비동기 가드를 다룰 때는 항상 "지금 이 상태의 소유자가 누구인가"를 물어야 한다.

사건 3. 스크롤이 한 페이지만 로드하고 멈춘다

같은 시기에 또 하나. 바닥까지 스크롤하면 다음 페이지가 한 번 로드되고 끝이다. 더 내려갈 곳도 없는데 다음 페이지가 안 온다. (위로 스크롤했다가 다시 내리면 로드된다 — 이게 결정적 힌트였다.)

원인: 버그인 줄 알았던 것이 기능이었다

이 이야기의 시작은 사실 더 전으로 거슬러 간다. 원래 코드에는 "중복 호출 버그"가 있었다.

loadMore의 deps: [cursor, hasNext, fetchPage]
→ cursor가 바뀔 때마다 loadMore가 새 참조로 재생성
→ 옵저버 effect(deps: [loadMore])가 disconnect → observe 반복
→ observe() 직후엔 항상 초기 콜백이 1회 발화
→ sentinel이 이미 화면에 보이면 즉시 실행 → 중복 fetch

그래서 ref 패턴으로 고쳤다. 콜백을 ref에 미러링하고 옵저버는 마운트 시 1회만 등록. 재등록이 사라지니 중복 호출도 사라졌다. 여기까진 좋았다.

그런데 IntersectionObserver는 교차 상태가 '변할 때'만 발화한다. 스켈레톤 20개가 실제 상품 20개로 교체되면 문서 높이가 거의 그대로라, 바닥에 있던 sentinel은 계속 보이는 상태 그대로다. 교차에 '변화'가 없으니 콜백은 두 번 다시 불리지 않는다.

그럼 예전엔 어떻게 연쇄 로딩이 됐을까? 그 "중복 호출 버그"가 트리거였다. 페이지가 로드되면 cursor가 바뀌고 → loadMore가 재생성되고 → 옵저버가 재등록되고 → 재등록 직후의 초기 콜백이 발화해서 → 다음 페이지를 불렀던 것이다. 우리가 버그라고 부르며 제거한 재등록이, 사실은 연쇄 로딩의 동력을 겸하고 있었다.

해결: rootMargin

재등록을 되살리거나 강제 재발화 트릭을 넣는 대신, 옵저버 옵션 하나로 풀었다.

new IntersectionObserver(callback, { rootMargin: "200px" });

감지 영역이 뷰포트 아래 200px까지 확장된다. 그러면 사이클이 자연스럽게 돌아간다 — 페이지가 append되면 sentinel이 한 페이지 높이만큼 아래로 밀려 감지 영역을 벗어나고(교차 변화 발생), 스크롤이 다시 접근하면 재발화한다. 덤으로 바닥에 닿기 200px 전에 미리 로드되니 UX도 좋아졌다.

교훈: 버그를 고치기 전에, 그 동작이 무엇에 기여하고 있었는지 물어야 한다. 그리고 옵저버는 "상태"가 아니라 "변화"에 반응한다는 걸 정확히 이해해야 무한스크롤을 제대로 만들 수 있다.

정리: 최종 방어 체계

세 사건을 지나고 나니, 무한스크롤 하나에 이런 방어선들이 서 있었다.

에필로그: 그리고 이 모든 것을 TanStack Query가 한다

위 표의 방어선 대부분을 TanStack Query의 useInfiniteQuery는 기본으로 제공한다.

• 중복 요청과 로딩 상태 → 내부에서 관리
• 낡은 응답(race) → queryKey(카테고리+정렬)가 다르면 자동 폐기
• StrictMode 대응 → 라이브러리가 처리
• isFetched / isLoading 구분 → 상태 플래그로 제공

"그럼 처음부터 라이브러리를 쓰지 그랬냐"고 할 수 있다. 하지만 직접 구현하며 각 방어선이 왜 필요한지를 몸으로 겪었기 때문에, 이제 RQ의 기능 하나하나가 무엇을 대신해주는지 정확히 안다. queryKey가 race를 막는다는 문장이 문서 속 한 줄이 아니라, 카테고리 잔상 버그의 기억으로 읽힌다.

다음 글은 이 코드를 TanStack Query로 마이그레이션하는 이야기가 될 것 같다.

ProductCard 컴포넌트를 리뷰받다가 이런 코멘트를 받았습니다.

"카드 안에서 useNavigate를 직접 쓰지 말고, onNavigate prop으로 부모에게 넘기는 게 어떨까요?"

처음엔 "그냥 카드 안에서 이동시키면 되는 거 아닌가?" 싶었는데, 이 안에는 관심사 분리 / props 네이밍 / 함수 분리라는 세 가지 개념이 다 들어 있었습니다. 이 글은 그 세 가지를 정리한 기록입니다.

1. 관심사 분리 (Separation of Concerns)

한 줄로 요약하면 이렇습니다. 컴포넌트는 자기 일에만 집중하고, 다른 관심사는 부모에게 넘긴다.

무엇이 문제였나

원래 ProductCard는 내부에서 useNavigate를 직접 호출하고 있었습니다.

// before — 카드가 "이동"까지 스스로 결정
export default function ProductCard({ id, ... }) {
  const navigate = useNavigate();
  const handleClick = (productId) => navigate(toProductDetail(productId));
  return <div onClick={() => handleClick(id)}>...</div>;
}

카드가 해야 할 일은 상품 정보를 보여주는 것입니다. 그런데 useNavigate가 들어오면서 "라우팅"이라는 전혀 다른 관심사까지 카드가 떠안게 됐습니다.

"react-router 환경에서만 동작한다"는 말의 의미

useNavigate는 평범한 함수가 아니라, react-router가 깔아놓은 판(Context) 위에서만 작동하는 훅입니다. <BrowserRouter> 안쪽에서만 살아있고, 그 밖에서 부르면 에러가 납니다.

즉 useNavigate를 카드 안에 넣는 순간, 카드는 "라우터가 있어야만 존재할 수 있는 컴포넌트"가 됩니다. 카드의 본질(이미지·이름·가격을 보여주는 것)은 라우터와 아무 상관이 없는데도 말이죠.

해결 — 이동 방식을 부모가 결정하게

// after — 카드는 "클릭됐다"만 알리고, 뭘 할지는 부모가 결정
type ProductCardProps = Pick<Product, 'id' | 'imageUrl' | ...> & {
  onNavigate: (id: string) => void;
};

export default function ProductCard({ id, ..., onNavigate }) {
  return <div onClick={() => onNavigate(id)}>...</div>;
}

// 부모 (ProductListPage)
<ProductCard {...product} onNavigate={(id) => navigate(toProductDetail(id))} />

카드는 이제 "이동 방식"을 모릅니다. 그냥 클릭됐다는 사실만 부모에게 알리고, 실제로 어디로 갈지는 부모가 정합니다.

왜 좋은가 — 구체적인 상황

같은 카드를 검색 결과 페이지에서도 쓴다고 해봅시다. 그런데 거기선 클릭했을 때 상세 페이지로 이동하는 게 아니라 미리보기 모달을 띄우고 싶습니다.

• useNavigate가 카드 안에 박혀 있으면 → 바꿀 수 없습니다. 카드가 이동 방식을 자기가 정해버렸으니까요.
• onNavigate를 밖에서 받으면 → 리스트 페이지는 navigate(상세)를, 검색 페이지는 모달 열기를 넘기면 됩니다. 같은 카드, 다른 동작.

비유로 이해하기

엘리베이터 버튼은 "눌렸다"는 신호만 보냅니다. 몇 층으로 갈지는 버튼이 정하지 않죠. 만약 버튼이 목적지 층까지 정해버리면, 그 버튼은 다른 건물에 갖다 쓸 수 없습니다.

카드 = 버튼, 이동 결정 = 엘리베이터 시스템(부모)

기타

사실 지금 프로젝트에선 카드가 항상 라우터 안에서만 쓰이고 테스트도 없어서, 당장 얻는 실익이 크지는 않을 수 있습니다. 지금은 원칙을 이해하는 게 목적이고, 나중에 테스트를 작성하거나 컴포넌트를 재사용하거나 Storybook으로 문서화할 때 이 차이를 체감하게 될 거라고 봅니다.

2. props 네이밍 — onClick vs onNavigate

핵심 원칙은 이렇습니다. prop 이름은 "무슨 일이 일어났나(이벤트)"가 아니라 "무엇을 원하나(의도)"로 짓는다.

부모 입장에서 비교하면 차이가 분명합니다.

// onClick — 이게 무슨 클릭인지 매번 확인해야 함
<ProductCard onClick={...} />

// onNavigate — 이름만 봐도 의도가 명확
<ProductCard onNavigate={(id) => navigate(...)} />

특히 카드 안에 클릭 지점이 여러 개일 때 이 차이가 커집니다. 카드에는 카드 전체(상세 이동), 담기 버튼, 수량 +/- 버튼처럼 클릭할 곳이 여럿 있습니다. 이걸 전부 onClick으로 받으면 어떤 클릭인지 구분할 수 없습니다. 그래서 의도별로 이름을 붙여야 합니다.

onNavigate, onAddToCart, onChangeQuantity ...

prop 이름이 곧 문서 역할을 합니다.

3. 함수 분리 — 언제 하고, 언제 안 하나

"함수는 웬만하면 분리하라"는 말을 많이 듣지만, 진짜 기준은 길이 · 재사용 · 명확성 세 가지입니다.

이번 케이스는 인라인이 맞다

<ProductCard onNavigate={(id) => navigate(toProductDetail(id))} />

• 한 줄 ✅
• 한 곳에서만 사용 ✅
• 뭘 하는지 뻔함 ✅

이럴 땐 인라인이 오히려 읽기 편합니다. 억지로 빼면 이렇게 됩니다.

const handleNavigate = (id: string) => navigate(toProductDetail(id));
// ...한참 아래...
<ProductCard onNavigate={handleNavigate} />

선언부와 사용부가 멀어져서 코드를 읽을 때 눈이 위아래로 왔다 갔다 하게 됩니다. 오히려 불편하죠.

정리

"무조건 분리"가 아니라 "분리가 가독성이나 재사용에 도움이 될 때 분리"입니다. 한 줄이고, 한 곳에서만 쓰고, 뭘 하는지 자명한 함수라면 인라인이 원칙에 더 맞습니다.

마무리

• 관심사 분리: UI 컴포넌트가 라우팅 같은 외부 시스템을 직접 알지 않게 하고, 동작은 부모가 주입한다. → 재사용성과 테스트 용이성 확보.
• props 네이밍: 이벤트명(onClick)이 아니라 의도명(onNavigate)으로. → 이름이 곧 문서가 된다.
• 함수 분리: 길이 · 재사용 · 명확성이 기준. 한 줄 · 단일 사용 · 자명한 함수는 인라인.

한 줄짜리 리뷰 코멘트였지만, 그 뒤에는 이만큼의 설계 원칙이 있었습니다. 앞으로 컴포넌트를 만들 때 "이 컴포넌트가 원래 알아야 하는 일인가?"를 먼저 물어보게 될 것 같습니다.

리액트의 state가 아닌, 브라우저 DOM 자체가 입력값을 들고 있다. 데이터의 주인은 브라우저(DOM)

• 동작: 사용자가 글자를 칠 때마다 리액트한테 알려주지 않음. 브라우저 DOM 자체( HTML < input > )이 조용히 자기 값을 업데이트함. 리액트는 ref를 통해 나중에 값을 가져옴

• 장점: 키 입력마다 컴포넌트가 다시 그려지지 않아서 성능이 매우 가볍다. (리렌더링 발생하지 않음)

• RHF의 방식: RHF는 기본적으로 이 Uncontrolled 방식을 사용. register가 이 입력창을 감시만 하다가, 나중에 제출할 때 한꺼번에 값을 가져옴.

반응형/제어 (Controlled)

입력값 하나하나가 리액트의 state와 동기화 데이터의 주인은 리액트(State)

• 동작: 사용자가 'A' 하나만 쳐도 onChange가 실행되고, state가 바뀌며, 그 결과로 컴포넌트 전체가 다시 그려짐. (리렌더링 발생)

• 장점: 입력값에 따라 실시간으로 화면을 바꿀 때(예: 글자 수 카운팅, 실시간 검색) 직관적이다.

• 단점: 입력할 때마다 리액트가 일을 해야 하므로, 폼이 복잡해지면 성능 부하가 생김.

mode
폼 제출 전 사용자의 액션에 따라 유효성 검사 타이밍을 결정.

reValidateMode
폼 제출 후 오류값 재검증 시 유효성 검사를 트리거할 사용자의 액션.

defaultValues
기본값(초기 렌더링 시 캐싱됨) 이후에 비동기로 데이터 조작시에는 values나 reset 함수 사용

values
Form 값을 업데이트하기 위한 반응형(Controlled) 값 외부 상태(예: API 데이터)가 변경될 때 폼 값을 자동으로 동기화하고 싶을 때 사용

errors
유효성 검사가 실패한 필드의 오류 정보(type, message 등)를 담고 있는 객체. 중요 : 오류 객체 참조 - stable를 유지하여 무한 재렌더링 방지

resetOptions
values나 defaultValues가 업데이트되어 폼 값이 새롭게 바뀔 때, 기존 폼 상태(에러, 방문 기록 등)의 유지 여부를 설정하는 옵션.

criteriaMode
모든 검증 오류를 표시하거나 한 번에 하나씩 표시

shouldFocusError
제출 시 에러가 난 첫 필드로 포커스 자동 이동 활성화하거나 비활성화

delayError
오류가 나타나는 시점을 밀리초(ms) 단위로 지연시킴. 사용자가 타이핑하는 동안 에러 메시지가 너무 빨리 깜빡이는 걸 방지.

validate
사용자 정의 유효성 검사 함수. (기본 제공되는 required, pattern 외에 직접 로직을 짜서 검증할 때 사용)

shouldUseNativeValidation
브라우저 내장 form constraint API 사용

shouldUnregister
컴포넌트가 화면에서 사라질(Unmount) 때 해당 필드 값도 폼 데이터에서 삭제할지 결정. 기본값 = false라 사라져도 값은 유지됨.

progressive
Form component를 사용할 때 기본 양식 제출 점진적인 향상(progressive enhancemen) 활성화.

disabled
전체 폼 필드를 한 번에 비활성화하며, 이때 해당 필드들은 유효성 검사에서 제외됨.

useForm 스키마 검증 Props

resolver
스키마 기반의 외부 검증 라이브러리(Zod, Yup, Joi 등)를 React Hook Form과 연결하는 함수

context
스키마 검증 시 외부 데이터를 참조할 수 있게 넘겨주는 객체. 폼 내부 데이터가 아닌, 외부의 동적인 상태(예: 전역 설정값, 현재 세션 정보 등)를 스키마 내부 로직에서 조건부로 활용하고 싶을 때 사용함.

mode/reValidateMode 비교

mode 역할

onChange | onBlur | onSubmit | onTouched | all (기본값 : onSubmit)

mode의 경우 폼 제출 전 사용자의 액션에 따라 유효성 검사 타이밍을 결정한다. 기본값은 onSubmit으로, 불필요한 리렌더링이 가장 적어 성능상 가장 유리하다.

reValidateMode의 역할

onChange | onBlur | onSubmit (기본값: 'onChange')

사용자가 form을 submit한 후 오류가 있는 입력이 재검증될 때(onSubmit, handleSubmit 실행 시) 검증 전략 결정. 기본값은 onChange로 입력값이 변경될 때 마다 재검증 트리된다. React Native의 경우 Custom register나 Controller 사용을 사용해야한다.

각 옵션에 따른 결과

onSubmit

첫 onSubmit이벤트에서 트리거됨. onSubmit 이후에는 각 필드에 onChange 이벤트 리스너가 활성화되어, 사용자가 값을 수정할 때마다 즉각적으로 재검증을 수행.

onBlur

사용자가 입력을 마치고 포커스를 옮길 때 검증하므로, onChange보다 성능 효율적이면서 적절한 피드백을 제공.

onChange

필드의 값이 변경될 때마다 이벤트 트리거. 모든 키 입력마다 유효성 검사 로직이 실행되고 상태가 업데이트되어 리렌더링이 발생함. 따라서 성능에 영향 많이 받게되므로 사용에 주의 필요

onTouched

첫 blur 이벤트에서 트리거. 이후 모든 onChange이벤트 발생할 때마다 트리거

• UI 라이브러리(MUI, AntD 등)의 커스텀 컴포넌트는 표준 HTML input과 이벤트 전달 방식이 다를 수 있어 Controller를 사용하게 되는데, ** Controller의 render 프롭에서 제공하는 field.onBlur를 수동으로 연결해 주어야 RHF가 해당 필드가 'Touched' 되었음을 정확히 인지**할 수 있음.

all

가장 엄격한 검증 방식으로 onBlur, onChange이벤트 발생 시 모두 트리거. 실시간 피드백을 극대화함

옵션에 따른 성능차이 : 왜 onChange를 주의해야 할까?

구독 기반 리렌더링 :

React Hook Form(RHF)은 기본적으로 비제어 방식(Uncontrolled)으로 불필요한 리렌더링을 방지하지만, mode: 'onChange'를 설정하면 키 입력마다 다음 사이클이 작동.

검증 함수 실행 -> 에러 객체 생성 -> 상태 업데이트

이때 RHF 내부의 상태가 업데이트될 때마다, 이 상태를 구독하고 있는 컴포넌트가 리액트의 리렌더링 사이클이 트리거되기 때문에 성능 부하가 발생한다. 입력값 자체는 비제어(Uncontrolled)지만 '검증 결과'는 반응형(Controlled)으로 관리되기 때문. 특히 복잡한 유효성 검사 로직이 포함되어 있거나 폼의 규모가 큰 경우, 메인 스레드를 점유하게 되어 사용자가 입력을 할 때 반응이 느려지는 타이핑 지연(Input Lag) 현상이 발생할 수 있다.

가비지 컬렉션(GC) 부하:

매 입력마다 새로운 errors 객체가 생성되고 참조가 변경되므로, 짧은 시간 내에 수많은 객체가 생성되고 파괴되는 과정은 브라우저의 가비지 컬렉터(GC)에 과부하를 주게 되며, 이는 특히 저사양 기기나 모바일 환경에서 성능 저하 및 버벅임의 직접적인 원인이 됨.

추천 이용 방식:

성능을 위해서는 기본값인 onSubmit이나 onBlur를 사용하는 것이 권장된다. 실시간 피드백이 반드시 필요하다면 처음부터 mode: 'onChange'를 쓰기보다 reValidateMode: 'onChange' 를 활용하여, 제출했을 때 에러 발생시에만 실시간으로 수정 여부를 검증하는 것도 효율적이다.

CORS는 기본적으로 SOP(Same-Origin Policy, 동일 출처 정책) 때문에 발생합니다. 웹 애플리케이션이 자신의 출처와 다른 곳으로 HTTP 요청을 보낼 때, 브라우저는 보안상의 이유로 이 요청이 안전한지 검사하고 허용되지 않은 경우 차단합니다.

CORS 발생 조건

1. 프로토콜(Protocol)이 다를 때: http와 https는 서로 다른 출처
2. 도메인(Domain/Host)이 다를 때: example.com과 api.example.com은 서로 다른 출처
3. 포트(Port)가 다를 때 위와 같은 경우 다른 출처로 인식합니다.

CORS 해결 방법

1. 서버가 브라우저에게 이 요청은 안전하다고 허락해 주는 것 서버 응답 헤더에 Access-Control-Allow-Origin을 추가합니다. 특정 도메인 허용: Access-Control-Allow-Origin: https://my-frontend.com 모든 도메인 허용: Access-Control-Allow-Origin: *

2. 프레임워크별 미들웨어 사용 직접 헤더를 넣기보다는 사용 중인 언어/프레임워크의 라이브러리를 쓰는 게 편합니다. Node.js (Express): cors 패키지 설치 후 app.use(cors()) 사용 Spring Boot: @CrossOrigin 어노테이션 사용 혹은 WebMvcConfigurer 설정

3. 개발 환경에서의 Proxy 설정 프론트엔드 개발 중에만 임시로 해결하고 싶다면, 클라이언트 쪽에서 프록시를 설정해 서버와 같은 출처인 것처럼 속일 수 있습니다.

React (package.json) "proxy": "http://localhost:8080" 추가 Webpack/Vite
설정 파일에서 server.proxy 옵션 사용

4. 백엔드 앞단에 Reverse Proxy 배치 (Nginx) 실제 운영 환경에서는 Nginx 같은 웹 서버를 앞에 두고, 프론트와 백엔드를 같은 도메인 아래 묶어서 CORS 상황 자체를 만들지 않기도 합니다.

자바스크립트 엔진은 코드를 실행하기 전 '컴파일 단계'를 거치며 변수 선언을 메모리에 미리 등록합니다. 실제 코드 위치와 상관없이 선언부만 최상단으로 끌어올려진 것처럼 보이는 현상을 말합니다.

변수별 호이스팅 동작 방식

호이스팅은 모든 변수(var, let, const)에 발생하지만, 그 결과는 확연히 다릅니다.

• 실행 전에 변수 이름을 먼저 environmentRecord에 등록.
• 변수/함수 선언이 실행 전에 스코프 상단으로 끌어올려진 것처럼 동작
• var: 선언 + 초기화(undefined)
• let, const: 선언만 호이스팅 (TDZ 존재) => 할당 전 reference error (TDZ : 실행 전으로 선언은 되었으나 초기화가 되지 않은 상태.)
  

일시적 사각지대 (Temporal Dead Zone, TDZ)

= 초기화 전 접근 금지 구간 = 스코프의 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간

var

console.log(a) // undefined
var a = 10
----- 동작과정 -----
var a
console.log(a) // undefined
a = 10

let, const

console.log(b) // ReferenceError(TDZ 발생)
let b = 10

let, const함수 선언문

sayHello() // 정상 실행

function sayHello() {
  console.log(""hello"")
}
//→ 함수 전체가 호이스팅됨.    

함수 표현식

sayHi() // TypeError

var sayHi = function () {
  console.log(""hi"")
}
//→ 변수는 undefined로 호이스팅
//→ 함수는 아직 할당 안 됨.

call by value, call by reference 란? 함수 호출 시 값을 전달하는 방식을 의미합니다.

Call by Value

Call by Value는 값의 복사본이 전달되므로, 함수 내부에서 값을 변경해도 원본에는 영향이 없습니다.

Call by Reference

Call by Reference는 변수의 참조값(메모리 위치)이 전달되어, 함수 내부에서 값을 변경하면 원본에도 영향이 발생합니다.

자바스크립트에서의 동작

자바스크립트는 이론적으로 Call by Value만 사용합니다. 함수에 전달되는 것은 항상 “값”이며, (참조타입)객체의 경우 객체를 가리키는 참조값이 값으로 복사됩니다.

따라서 함수 내에서 객체의 속성을 변경하면 원본이 함께 변경되기 때문에 겉보기에는 Call by Reference처럼 동작하는 것처럼 보일 수 있습니다.

예시

1) 원시 값일 때

function change(x) {
  x = 20
}

let a = 10

change(a)

console.log(a) //10

Call by Value

(해설) 여기서 복사되는 건 숫자 10 자체

a → 10 x → 다른 10 이 경우,완전 별개.

따라서 a 안 바뀜.

2) 객체 속성 바꿀 때

function change(obj) {
  obj.value = 20
}

let data = { value: 10 }

change(data)

console.log(data.value) // 20

Call by Reference

(해설) 여기서 복사되는 건 객체가 아니라 “객체를 가리키는 참조값” data ─┐____> 같은객체

obj ──┘

이 경우, 복사는 됐지만 같은 객체를 함께 본다. 따라서 값 바뀜.

3) 객체를 새로 재할당할 때

function change(obj) { 
    obj = { value: 20 } 
} 

let data = { value: 10 } 

change(data) 

console.log(data.value) //10

Call by Value

(해설) obj 화살표만 다른 객체로 갈아탐

data → 원래 객체 obj → 새 객체 이 경우, → 서로 완전 분리.

따라서 data 안 바뀜.

불변성이란 기존 데이터를 직접 변경하지 않고, 새로운 값을 생성하여 상태 변화를 표현하는 성질을 의미합니다.

자바스크립트에서 원시 타입은 한 번 생성된 값을 수정할 수 없기 때문에 자연스럽게 불변성을 가지며, 객체와 배열 같은 참조 타입은 내부 값을 변경할 수 있어 가변성을 가집니다.

불변성이 중요한 이유

• 변경 전/후 상태가 명확히 분리되어 디버깅과 로직 이해가 쉬워지기 때문에 상태변화 추적이 용이해집니다.
• 기존 데이터를 직접 수정하지 않기 때문에 예상치 못한 값 변경을 방지하여 사이드 이펙트를 줄일 수 있습니다.
• 이로 인해 안정적인 동작을 보장하고 협업과 유지보수에 유리한 구조를 만들 수 있습니다.

불변성을 지키는 방법

참조 타입 복사 시 재귀 기반 복사, 또는 Immer 같은 라이브러리등을 활용하여 데이터의 불변성을 유지하도록 합니다.

객체 : 기존 객체를 직접 수정하지 않고 새 객체를 생성하여 반환. 배열 : 동일한 새 배열을 생성.
코드 예시

// ---------- 객체
// 잘못된 예 (가변)
user.name = ""Kim""

// 올바른 예 (불변)
const newUser = { ...user, name: ""Kim"" }


// ---------- 배열
// 가변
arr.push(4)

// 불변
const newArr = [...arr, 4]

얕은 복사는 객체의 최상위 프로퍼티만 새로 복사하고(1단계 프로퍼티), 내부에 있는 중첩 객체나 배열은 기존 참조를 그대로 공유하는 복사 방식입니다. 따라서 복사본에서 중첩 데이터를 수정하면 원본에도 영향이 발생할 수 있습니다. 대표적으로 스프레드 연산자나 Object.assign이 얕은 복사를 수행합니다.

얕은복사 예시

const user1 = {
  name: "Lee",
  address: { city: "Seoul" }
}

const user2 = { ...user1 } // 얕은 복사 (1단계만 복사)

user2.address.city = "Busan"

console.log(user1.address.city) // "Busan" ← 원본도 함께 변경됨

깊은 복사

깊은 복사는 객체 내부의 중첩된 값까지 모두 새롭게 복사하여 완전히 독립적인 참조를 만드는 방식입니다. 그래서 복사본을 수정해도 원본에는 영향을 주지 않으며, 상태 불변성을 유지해야 하는 상황에서 중요하게 사용됩니다. 구현 방법으로는 structuredClone, 재귀 기반 복사, 또는 Immer 같은 라이브러리가 있습니다.
깊은복사 예시

const user1 = {
  name: "Lee",
  address: { city: "Seoul" }
}

const user2 = structuredClone(user1) // 깊은 복사 (모든 depth 복사)

user2.address.city = "Busan"

console.log(user1.address.city) // "Seoul" ← 원본 유지

리액트와 얕은복사/깊은복사 리액트에서는 상태 변경 여부를 참조 비교로 판단합니다. 그래서 기존 상태를 직접 수정하지 않고, 불변성을 유지하는 방식으로 상태를 관리하는 것이 중요합니다.

기본형/원시 타입(Primitive Type)

• Number
• BigInt
• String
• Boolean
• null
• undefined
• Symbol

원시 타입의 값은 변경 불가능한 값이며, 변수에 값을 할당하거나 복사할 때 값 자체가 복사되어 전달됩니다.

원시 값은 불변(immutable)이며 값 변경은 재할당으로만 이루어진다.

예시
let a = 10
let b = a  // 값 자체가 복사됨

console.log(a) //10
console.log(b) //10

b = 20  // b에 새로운 값이 재할당됨

console.log(a) //10
console.log(b) //20

참조형/참조 타입(Reference Type)

• Object
• Array
• Function
• Map
• Set

참조타입의 경우 메모리에 객체가 저장된 참조값(위치) 이 저장됩니다. 변수에 값을 할당할 때에도 객체가 저장된 참조값(reference)이 할당되며, 복사할 때에도 참조값이 복사됩니다.

따라서, 여러 변수가 같은 객체를 공유할 수 있으며,객체 내부 속성을 변경하면 원본에도 영향이 발생합니다.(얕은 복사에서 객체 내부의 참조는 변경되지 않아 발생)

예시
let obj1 = { x: 1 }
let obj2 = obj1 // 객체의 참조(주소)가 복사됨

obj2.x = 2  // 같은 객체를 수정

console.log(obj1.x) // 2
console.log(obj2.x) // 2