일반적인 타입 설계는 보통 “타입을 미리 적어두는” 방식이야. 그런데 실무에선 이미 어딘가에 정의된 타입 구조에서 “일부분만 꺼내 쓰고” 싶을 때가 많다.

• 함수 시그니처에서 반환 타입만 가져오기
• 함수의 파라미터 리스트(튜플)만 뽑기
• Promise<...> 안의 결과 타입만 꺼내기
• 문자열/튜플/객체 타입을 패턴 매칭해서 특정 조각만 얻기

이걸 매번 수동으로 재정의하면 중복과 불일치 지옥이 온다. 함수가 바뀌면 파생 타입도 전부 고쳐야 하거든. infer는 이런 “기존 타입에서 특정 부분만 자동으로 추출”하는 도구다. 조건부 타입과 함께 쓰여서 패턴 매칭 + 타입 변수 추론을 가능하게 한다.

1) 기본 문법 — “조건부 타입 안에서만 쓴다”

형식은 딱 하나.

T extends SomePattern<infer U> ? U : Fallback

• T가 SomePattern<...> 모양과 매치되면, 그 안의 일부를 infer U로 추론해서 U를 반환.
• 매치 안 되면 Fallback (대개 never).

중요한 규칙

• infer는 조건부 타입의 참( ? ) 분기 내부에서만 선언할 수 있다.
• 한 번 추론된 U는 그 분기 안에서 이름을 가진 타입 변수처럼 자유롭게 쓸 수 있다.

2) 예제 1 — “함수 반환 타입 꺼내기” (ReturnType 원리)

type MyReturn<T> = T extends (...args: any[]) => infer R ? R : never;

function fn(x: number): string {
  return "hello";
}

type R = MyReturn<typeof fn>; // string

아주 자세한 뜯어보기

1. typeof fn → (x: number) => string 라는 값 → 타입 승격.

2. 조건부 타입에 대입:

// T 자리에 (x: number) => string 이 들어감
( (x: number) => string ) extends (...args: any[]) => infer R ? R : never

3. 좌변 함수 타입이 우변 패턴 (...args: any[]) => something 과** 형태가 같다 → 매칭 성공.**
4. 그 “something” 자리에 있는 타입을 infer R로 빼온다 → R = string.
5. 참 분기 결과 R → 최종 타입 string.

Tip infer는 *“형태가 맞으면 빼오는” *거다. 그래서 패턴 설계가 핵심이다.

3) 예제 2 — “파라미터 리스트(튜플) 꺼내기” (Parameters 원리)

type MyParams<T> = T extends (...args: infer P) => any ? P : never;

type P0 = MyParams<(a: number, b: string) => void>; // [number, string]

뜯어보기

• 이번엔 (...args: infer P)에 함수의 파라미터 리스트 전체가 들어간다.
• TS에서 파라미터 리스트는 튜플 타입으로 표현된다 → P = [number, string].
• 그래서 결과는 [number, string].

주의 “튜플”이라서 순서/개별 타입이 고정된다. 단순한 any[]가 아니다.

4) 예제 3 — “Promise 내부 타입 풀기” (Awaited 원리, 재귀 포함)

type MyAwaited<T> = T extends Promise<infer U> ? MyAwaited<U> : T;

type A = MyAwaited<Promise<string>>;            // string
type B = MyAwaited<Promise<Promise<number>>>;   // number
type C = MyAwaited<number>;                     // number

뜯어보기

1. Promise<string>이면 infer U = string → 다시 MyAwaited<string> 호출 → 더 이상 Promise 아님 → string.

2. Promise<Promise<number>>면

   • 1차: U = Promise<number>
   • 2차: U = number
   • 3차: number 반환.

3. number는 Promise<...> 패턴 불일치 → 그냥 T 그대로 반환.

Tip 재귀를 이용해 “여러 겹 Promise”도 풀어낼 수 있다.

5) 예제 4 — “튜플 구조 분해: 첫 원소 / 마지막 원소”

type First<T extends any[]> = T extends [infer F, ...any[]] ? F : never;
type Last<T extends any[]>  = T extends [...any[], infer L] ? L : never;

type F1 = First<["a", "b", "c"]>; // "a"
type L1 = Last<["a", "b", "c"]>;  // "c"
type F2 = First<[]>;              // never (매칭 불가)

뜯어보기

• [infer F, ...any[]]는 “첫 칸을 F로 받고 나머지는 아무거나”라는 패턴.
• ["a","b","c"]는 위 패턴과 매치 → F = "a".
• 빈 튜플은 매치 자체가 안 돼서 never.

이해 포인트 값에서 구조 분해 const [first, ...rest] = arr 과 아주 유사한 사고방식으로 보면 쉽다.

6) 예제 5 — “문자열 패턴 매칭” (템플릿 리터럴 + infer)

type Split2<S extends string> =
  S extends `${infer A}-${infer B}` ? [A, B] : [S];

type S1 = Split2<"ab-cd">; // ["ab","cd"]
type S2 = Split2<"hello">; // ["hello"]

뜯어보기

• 템플릿 리터럴 타입에서도 infer를 쓸 수 있다.
• "ab-cd"는 ${A}-${B} 패턴과 매칭 → A = "ab", B = "cd".
• "hello"는 -가 없어서 매칭 실패 → 기본값 [S].

확장 아이디어 재귀를 쓰면 Split<"a-b-c","-"> → ["a","b","c"] 같은 것도 가능하다.

7) 분배 조건부 타입과 infer — “유니온을 어떻게 처리하나”

조건부 타입은 좌변이 유니온이면 분배(distributive) 된다. 즉 각 원소에 독립적으로 조건을 적용하고 합친다.

type Element<T> = T extends (infer U)[] ? U : T;

type E1 = Element<string[]>;         // string
type E2 = Element<(number | boolean)[]>; // number | boolean
type E3 = Element<string | number[]>; // string | number
// 해석: Element<string> | Element<number[]>
//    -> string | number

뜯어보기

• [T = string | number[] → Element<string> | Element<number[]> → string | number.

주의 포인트 분배가 원치 않게 일어날 때가 있다. 그땐 T를 한 번 감싸 분배를 끊는다.

type NoDistrib<T> = [T] extends [infer U] ? U : never; // 분배 억제 트릭

8) infer의 제약/한계 — “여기선 안 된다”

1. 조건부 타입의 참 분기 내부에서만 선언 가능. 아래처럼 거짓 분기에서 선언은 문법적으로 불가.

// ❌ 잘못된 예
type Bad<T> = T extends any ? string : infer X;

2. 모호하면 추론 실패 → never로 빠지거나 원하는 결과가 안 나온다.
3. 여러 곳에서 상충되는 추론이 생기면 실패할 수 있다. (서로 다른 타입을 한 변수에 동시에 강제하면 안 됨)
4. 함수 파라미터(반공변 위치) 추론 난이도 함수 타입에서 입력 위치는 반공변이라 추론이 까다롭다. 가능한 한 출력 위치(공변)에서 추론하는 패턴이 안정적.

9) 자주 쓰는 패턴 정리

9-1. ReturnType / Parameters

type MyReturn<T>  = T extends (...a: any[]) => infer R ? R : never;
type MyParams<T>  = T extends (...a: infer P) => any ? P : never;

9-2. Awaited (중첩 Promise 풀기)

type MyAwaited<T> = T extends Promise<infer U> ? MyAwaited<U> : T;

9-3. 튜플 분해

type Head<T extends any[]> = T extends [infer H, ...any[]] ? H : never;
type Tail<T extends any[]> = T extends [any, ...infer R] ? R : [];
type Last<T extends any[]> = T extends [...any[], infer L] ? L : never;

9-4. 템플릿 리터럴 파싱

type TrimLeft<S extends string> =
  S extends ` ${infer R}` | `\n${infer R}` | `\t${infer R}` ? TrimLeft<R> : S;

10) 실전 미니 응용 — “API 응답 타입 자동 추출 + 느슨화”

const endpoints = {
  getUser:  { url: "/user",  response: { id: 1, name: "string" } },
  getPosts: { url: "/posts", response: [{ id: 1, title: "string" }] },
} as const;

type ApiResponse<T> = T extends { response: infer R } ? R : never;

function fetchApi<K extends keyof typeof endpoints>(
  key: K
): ApiResponse<(typeof endpoints)[K]> {
  return null as any;
}

const user = fetchApi("getUser");
// 타입: { readonly id: 1; readonly name: "string" }

const posts = fetchApi("getPosts");
// 타입: readonly [{ readonly id: 1; readonly title: "string" }]

// 리터럴/readonly를 일반 타입으로 느슨화
type Loose<T> =
  T extends string | number | boolean ? (T extends string ? string : T extends number ? number : boolean)
  : T extends readonly (infer U)[] ? Loose<U>[]
  : T extends object ? { [K in keyof T]: Loose<T[K]> }
  : T;

type User = Loose<typeof user>;   // { id: number; name: string }
type Posts = Loose<typeof posts>; // { id: number; title: string }[]

뜯어보기(핵심 포인트)

• typeof endpoints로 값→타입을 뽑고
• keyof로 가능한 키를 유니온으로 제한
• 인덱싱 (typeof endpoints)[K]로 특정 엔드포인트 타입 선택
• ApiResponse<...>에서 infer R로 response만 추출
• Loose<T>로 리터럴/readonly를 실사용-friendly 타입으로 변환

11) 디버깅 요령 — “왜 내가 원하는 대로 추론이 안 되지?”

• 분배가 개입했는지 확인: 좌변이 유니온이면 각 원소에 따로 조건이 적용된다. 원치 않으면 [T] extends [...] 트릭으로 분배를 끊어라.
• 패턴이 너무 빡빡한지 확인: 매치 실패하면 전부 never로 빠진다. 패턴을 느슨하게 바꿔보자.
• 반공변 위치(함수 파라미터)에서 추론하려고 집착하지 말고, 공변 위치(반환값/프로퍼티)로 옮겨서 추론을 유도하라.
• 추론된 타입 확인: IDE에서 마우스 오버하거나, 보조 타입으로 노출해서 확인해라.

type Debug<T> = T extends any ? { result: T } : never;
type D = Debug<MyReturn<typeof fn>>;

12) 최종 정리

• infer는 조건부 타입의 참 분기에서 패턴 매칭으로 타입을 꺼내는 도구다.
• 핵심은 “패턴을 어떻게 설계하느냐”: 함수/튜플/템플릿 리터럴/객체 어디든 응용 가능.
• 분배 조건부 타입을 이해해야 예측 가능한 결과를 얻는다.

관광데이터 공모전 준비를 하느라 2달동안 블로그를 못썼다..ㅠㅠ 이제 제출을 해서 다시 타입스크립트 공부를 시작했다! 다시 일주일에 하나씩 써보도록 해야겠다!!

☠ 공부만 하던 나날들

정보처리기사 실기 준비는 생각보다 버거웠고, ADsP는 처음에 '에이 이 정도는 쉬운 거 아냐?' 했다가 회귀분석, 나무모형, 지지도 향상도 이런거 보면서 진짜 현타가 왔다.. 괜히 만만하게 봤다가 후회를 많이 했다 :(

하루종일 앉아서 이론 보고, 기출 풀고, 또 보고... 나중엔 '이걸 대체 왜 하고 있는 거지?' 싶을 정도로 무기력해졌다.. ㅋㅋㅋㅋ 그러다 문득, 아 이거 자격증 하나 땄다고 세상이 바뀌지 않겠구나 싶더라

🫠 그런데도 괜찮았던 이유

그래도 참 신기한게, 하루하루 별거 안 한 것 같아도, 나중에 모아서 보면 분명 무언가 해낸 게 있긴 하더라!

어쨌든 시험은 이제 다 끝났고, 결과는..!! 기다리는 중이다! (붙을 거 같다 ㅎㅎㅎ)

🔄 다시 만들고 싶어졌다

시험 끝나고 나서 갑자기 좀 손이 근질근질~ '공부 말고 진짜 뭐 좀 만들고 싶다' 그래서 요즘은 친구랑 같이 사이드 프로젝트 하나 기획 중이다.

아직 초기 단계긴 한데, 사용자 문제 정의, 경쟁 서비스 분석도 해보고, 조금씩 화면 구성도 해보려고 한다!

아직은 막 구체화된 건 없지만, 그래도 "내가 만들고 싶은 걸 만드는" 그 느낌이 자격증 공부보다 천 배 ! 아니? 만 배는 재밌다

🌱 지금은 ‘전환점’ 같은 시기

딱힌 큰 계기나 목표가 있어서 그런 건 아닌데, 왠지 지금이 내 인생에서 좀 전환점 같은 시기라는 생각이 든다 ㅠㅠ.. 이대로는 안될 것 같고, 뭔가 더 나아가고 싶고.

그래서 자격증도 도전했고, 공부도 해보고, 이젠 다시 프로젝트도 하고, 나라는 사람의 바닥을 좀 더 단단히 다져보려고 하는 중이다.. ( 그래서 이번달 말에도 토익을 본다! ) => 이말은? 이번 달도 블로그를 못 쓸 수도 있다는..? 아마..?

💭 앞으로는

그래서 당분간은 너무 정리된 글 말고, 그냥 이렇게 일상적인 얘기를 좀 써보려고 한다.

꼭 무언가 알려주는 글이 아니어도 괜찮고, 코드가 없어도 괜찮고, 그냥 요새 나의 일상 정도만 적어도 충분한 것 같다.

빠른 시일 내로 또 적어봐야겠다!

Promsie 다루어보기

처음엔 단순히 비동기 함수를 만들 때 Promise<any> 같은 식으로 다 썼다. 그냥 값이 나중에 오니까 그거 받고 .then() 붙이거나 await 쓰면 되겠지 싶었다. 근데 프로젝트 규모가 커질수록 이런 애매한 타입들이 점점 문제를 일으키기 시작했다.

이 함수가 뭘 반환하는지를 명확히 알 수 없으니, await로 받아도 타입 추론이 안되고, 결국 또 타입을 단언하거나 따로 주석으로 적는 일이 많아졌다. 이건 타입스크립트를 쓰는 이유랑 거리가 멀어 보였다.

그래서 알게 된 것이 제네릭을 활용한 Promise 타입 지정이다.

왜 any 는 부족한가..?

예를 들어서 아래와 같은 API 호출 함수가 있다고 해보자.

function fetchData(url: string): Promise<any> {
    return fetch(url).then(res => res.join());
}

표면적으로는 문제가 없어 보인다. 하지만 실제로 await fetchData(...)를 한 그다음 줄 부터는 그 갑싱 어떤 구조인지 IDE도 모르고, 나도 확신할 수 없다. 타입스크립트를 쓰는 이유가 그 "확신"을 갖기 위함인데, 이 코드에는 그게 없다..!

제네릭으로 타입을 주입받게 만든다면?

그래서 아래처럼 바꿔본다.

function fetchData<T>(url: string): Promise<T> {
    return fetch(url).then(res => res.join());
}

이제 이 함수는 내가 직접 예상하는 타입을 명시적으로 지정할 수 있게 된다.

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

const getUser = async () => {
    const user = await fetchData<User>('/api/user/1');
      console.log(user.name); // <- 타입이 보장됨
}

진짜 중요한건 여기서 fetchData 함수가 User 타입을 반환한다는 약속을 함수 정의가 아니라 호출부에서 직접 명시했다는 점이다. 이건 엄청나게 큰 차이다. 호출하는 사람이 의도를 명확히 표현할 수 있고, 타입 추론까지 자연스럽게 따라오게 된다.

T를 활용한 응답 구조 커스터마이징

더 나아가면, 요즘 흔히 쓰는 API 구조처럼 응답이 다음과 같이 생겨 있을 수 있다.

{
    "success" : true,
      "data" : {
        "id" : 1,
          "name" : "Lee"
    }
}

이런 경우에 일반화를 하고 싶다면?

type ApiResponse<T> = {
    success: boolean;
      data: T;
};

function fetchApi<T>(url:string): Promise<ApiResponse<T>> {
    return fetch(url).then(res => res.json());
}

이렇게 하면 어떤 데이터든 data 안에 들어간다는 구조를 유지하면서도 T 를 통해 유연하게 타입을 바꿀 수 있다.

type Product = {
    id: number;
      price: number;
};

const getProduct = async () => {
    const response = await fetchApi<Product>('/api/product/1');
      if (response.success) {
        console.log(response.data.price); // <- 타입에 안전하게 접근 가능.
    }
}

이걸 써보면 느끼는게 있다. 제네릭은 단순히 타입을 뿌옇게 만드는 게 아니라, 타입을 더 정확하게 유지하면서도 확장성을 높여주는 방식이다.

제네릭 Promise는 타입을 연결하는 다리다!

정리하자면, 타입스크립트에서 Promise<T> 는 단순히 "나중에 올 거야"를 표현하는게 아니라, "이 값이 어떤 타입인지 정확하게 예측할 수 있어"라는 확신을 유지한 채 비동기 흐름을 다루는 도구가 된다.

그리고 이걸 제네릭으로 만들면, 다음과 같은 이점이 생긴다

• API 응답마다 구조가 달라도 T 하나로 통일된 패턴 유지 가능
• 호출하는 쪽에서 의도를 명확하게 드러낼 수 있다.
• 타입 추론이 자연스럽게 따라와서 실수를 줄인다.
• 리팩토링을 할 때도 타입이 따라오므로 유지보수가 수월하다.

결론

처음엔 Promise<T>처럼 생긴 문법이 복잡하고 과하다고 느껴질 수 있다. 하지만 프로젝트를 계속 진행을 하다 보면, "이 함수가 어떤 데이터를 반환하지?" 하는 질문이 계속 머릿속에 맴돈다..

그럴 때마다 나는 Promsie<any> 대신 Promise<T> 를 고민해본다. "이 데이터가 어떤 타입이어야 하고, 그게 함수 호출부에까지 드러나야 하지 않을까?" 라는 생각 말이다.

다음에는 타입 조작이나 조건부, 유틸리티 타입에 대해 알아보려고 한다 그러면 일주일동안 퇴근하고 공부를 해야겠지..ㅠㅠ 열심히 해보자!!

오늘은 타입스크립트의 제네릭에 대해서 알아보도록 할거다. 개발을 하다 보면 어떤 타입에 종속되지 않는 로직을 만들고 싶을 때가 많다. 예를 들어 배열의 첫 번째 값을 반환하는 함수 같은 경우가 대표적인데, 숫자 배열일 수도 있고, 문자열 배열일 수도 있고, 객체 배열일 수도 있다.

그렇다고 매번 any[]로 받을 수는 없다. 그렇게 하면 타입 추론이 사라지고 타입스크립트를 쓰는 의미가 없어진다. 그때 등장하는게 제네릭(Generic)이다.

왜 제네릭이 필요할까??

가장 먼저 했던 고민은 이거였다. "지금 이 함수는 number[]일 때도, string[]일 때도 돌아가는데... 그럼 타입을 뭘로 적어야 하지..?"

function getFirst(arr: any[]): any {
    return arr[0];
}

이렇게 any를 쓰면 모든 타입을 받을 수 있는 것 같긴 한데, 그 순간부터 타입스크립트의 타입 보호를 전혀 못 받게 된다. 예를 들어 아래 코드는 에러가 안 나지만, 런타임에 터질 가능성이 있다.

const name = getFirst(['Lee', 'Kim']);
name.toUpperCase(); // 문제 없음. 하지만 number 배열을 넣었다면??

그래서 등장하는게 바로 제네릭 함수다.

function getFirst<T>(arr: T[]): T {
    return arr[0];
}

여기서 <T>는 그냥 "아무 타입"이라는 의미가 아니라, 호출하는 시점에서 타입을 넘겨 줄 수 있도록 만드는 자리다. 함수 내부에서는 이 T라는 타입이 계속 이어지니까, 입력이 string[]이면 출력도 string이고, number[]이면 출력도 number가 된다.

const name = getFirst(['Lee', 'Kim']); // string
const age = getFirst([10,20,30]); // number

타입을 추론해주는 것도 좋지만, 필요하면 명시적으로도 적을 수 있다.

const result = getFirst<number>([1,2,3]);

제네릭은 단지 "타입을 나중에 정하자"는게 아니다!

단순히 "타입을 나중에 정한다"는 것보다 중요한 타입 간의 관계를 유지해준다는 거다. 이걸 깨닫고 나서 제네릭이 왜 그렇게 강력한지 체감됐다.

예를 들어, 다음과 같은 코드를 봐보자.

function wrap<T>(value: T): {value: T} {
    return { value };
}

이 함수는 어떤 타입을 받든 간에, 그 타입을 value 라는 키에 넣어 감싼 객체를 반환한다. 중요한 건, 반환 타입이 단순한 {value:any}가 아니라, 전달받은 T 그대로라는 점이다.

const wrapped = wrap('hello'); // {value: string}

이처럼 제네릭을 쓰면, 입력과 출력이 하나의 타입으로 연결되기 때문에 타입 안정성이 높아진다. 객체의 일부를 복사하는 유틸 함수나, API 응답을 처리하는 함수에서도 이 패턴이 유용하게 쓰인다.

제네릭을 여러 개 쓸 수도 있다!

실제로 유틸 함수들을 만들다 보면 두 개 이상의 타입 관계를 설정하고 싶을 때도 있다.

function merge<A,B>(a: A, b: B): A & B {
    return { ...a, ...b };
}

const merged = merge({ name: 'Lee' },{ age: 27});
// merged: { name: string; age: number }

여기서 A & B는 타입 병합을 사용한 건데, 두 객체를 합친 결과의 타입도 자동으로 보장된다. 이걸 직접 명시하면 상당히 귀찮고 헷갈리는데, 제네릭으로 자연스럽게 해결된다.

제네릭 제약 조건?

처음엔 제네릭을 쓰다 보면 너무 자유로워서 타입 에러가 잘 안나서 당황했다. 예를 들어

function printLength<T>(value: T) {
    return value.length; // 에러!
}

왜냐하면 T는 어떤 타입일지 모르기 때문에 length 프로퍼티가 있다는 걸 보장할 수 없다는 거다. 그럴 땐 제네릭에 제약을 줄 수 있다.

function printLength<T extends { length: number }>(value: T) {
    return vlaue.length; // 에러 X
}

이렇게 하면 length 가 있는 타입만 받을 수 있게 된다. 문자열, 배열, length가 있는 객체 등은 모두 통과가 된다.

마무리하며...

결국 제네릭은 타입을 유연하게 받되, 그 사이의 관계를 안전하게 유지할 수 있도록 도와주는 도구다. 단순히 어떤 타입이든 받아서 쓰는 게 아니라, 호출 시점에 타입이 주입되고 그 타입이 함수 전체를 관통하면서 연결된다는 점이 제네릭의 진짜 핵심이다.

처음엔 괜히 복잡하고 과한 문법처럼 보였지만, 프로젝트 규모가 커지고 타입 복잡도가 올라가면 갈수록 제네릭 없이는 만들 수 없는 함수나 구조들이 생겨난다.

그래서 지금은 그냥 외워서 쓰기보다는, "이 함수의 타입이 고정돼 있지 않고 외부에서 정해졌으면 좋겠다" 싶은 순간마다 제네릭을 떠올려본다.

그게 아마 타입스크립트를 좀 더 잘 쓰는 방향 중 하나일 거라고 믿는다.

1.React.memo

React.memo는 함수형 컴포넌트를 메모제이션하여, props가 변경되지 않으면 리렌더링을 방지하는 고차 컴포넌트(HOC)이다.

const MemoizedComponent = React.memo(MyComponent);

예를 들어, 부모 컴포넌트에서 매번 새로 렌더링될 때 자식 컴포넌트도 같이 렌더링된다면, React.memo를 사용해 props가 바뀌지 않았을 경우 리렌더링을 막을 수 있다.

하지만, 주의할 점은 React.memo는 props의 얕은 비교만 수행한다. 즉, 객체나 배열 같은 참조 타입이 매번 새로 생성되는 경우, props가 변경되는 것으로 인식하로 리렌더링된다.

그래서 이런 경우에는 useMemo, useCallback을 조합해서 써야 진짜 효과를 볼 수 있다 !

2. useMemo vs useCallback

useMemo

useMemo는 계산 비용이 높은 값을 메모제이션하는데 사용한다.

const memoizedValue = useMemo(() => computeExpensiveValue(a,b), [a,b]);

예를 들어 리스트를 정렬하거나 필터링하는 연산처럼 리렌더링마다 계속 반복하기에는 비싼 작업이 있다면, useMemo를 사용해서 의존성 값이 바뀔 때만 다시 계산되도록 할 수 있다.

useCallback

useCallback은 함수를 메모제이션하는데 사용된다. 주로 자식 컴포넌트에 콜백을 props로 넘길 때 유용하다.

const memoizedCallback = useCallback(() => doSomething(a,b), [a,b]);

이거 안 쓰면 함수는 매번 새로 정의되기 때문에, 참조가 변경되어 자식 컴포넌트가 불필요하게 리렌더링된느 문제가 생긴다.

그러면 모든 곳에 다 써야돼???

정답은 절대 ! 아니다 !

메모제이션은 "최적화"이지 "기본값"이 아니다.

이유를 말하자면

• useMemo, useCallback도 결국 비용이 든다.
  • 메모리에 값을 저장해야 하고,
  • 의존성 배열을 비교해야 하며,
  • 값이 바뀌엇는지도 판단해야 한다.

예를 들어 아래 코드처럼 엄청 단순한 함수는 굳이 useCallback을 쓸 필요가 없다.

const handleClick = () => {
    console.log("clicked");
}

근데 이런 함수에 쓰는건 미친거....

이걸 useCallback(() => {}, [])로 바꿔도, 실제로 성능이 더 좋아지지 않고, 오히려 복잡성을 추가할 뿐이다.

반대로, 렌더링마다 반복되는 무거운 연산이라면 useMemo가 유리하다.

3. React DevTools Profiler

말로만 "리렌더링이 많다"고 하지 말고, 실제로 확인하는게 가장 확실하다.

React DevTools의 Profiler 탭을 이용하면,

• 어떤 컴포넌트가
• 왜 리렌더링 됐는지
• 얼마나 시간이 걸리는지

이런걸 시각적으로 확인할 수 있다.

이를 통해 진짜 병목이 발생하는 부분을 찾아내고, 선별적으로 최적화하는 것이 가장 이상적인 접근이다.

정리하며...

1. React.memo로 컴포넌트 리렌더링 자체를 막을 수 있다.
2. useMemo, useCallback은 props나 연산 결과를 메모이제이션해서 불필요한 렌더링/재계산을 줄인다.
3. 하지만 무분별하게 쓰면 오히려 손해다. 메모이제이션도 비용이기 때문.
4. 최적화는 병목이 보일 때, 꼭 필요한 지점에만. Profiler로 확인하고 적용하자.

Promise란?

Promise는 비동기 작업의 완료나 실패를 처리하기 위한 객체다. 단순히 "성공했을 때 뭐 하고, 실패했을 땐 이거 하고"를 좀 더 체계적이고 읽기 좋은 방식으로 다루기 위한 개념이라고 보면 된다.

const promise = new Promise((resolve, reject) => {
  const success = true;

  if (success) {
    resolve("작업 성공!");
  } else {
    reject("작업 실패!");
  }
});

promise
  .then((result) => {
    console.log(result);
  })
  .catch((err) => {
    console.error(err);
  });

Promise의 상태 (State)

Promise는 세 가지 상태를 가진다:

• Pending : 초기 상태, 아직 성공도 실패도 하지 않은 상태
• Fulfilled : 작업이 성공적으로 완료된 상태 → resolve() 호출됨
• Rejected : 작업이 실패한 상태 → reject() 호출됨

한 번 Fulfilled나 Rejected 상태가 되면, 그 이후로는 절대 다른 상태로 바뀌지 않는다. 이게 Promise가 "결과를 약속한다"는 의미이기도 하다.

왜 Promise가 필요했을까?

예전 방식은 보통 이런 식이었다:

function fetchData(callback) {
  setTimeout(() => {
    callback("데이터 도착!");
  }, 1000);
}

fetchData((data) => {
  console.log(data);
});

하지만 이런 방식으로 비동기 작업이 중첩되면 아래처럼 된다:

doSomething((result) => {
  doAnotherThing(result, (next) => {
    doFinalThing(next, (final) => {
      console.log(final);
    });
  });
});

이게 바로 콜백 지옥이다. 들여쓰기도 계속 깊어지고, 오류 처리도 어렵고, 가독성도 최악이다. 그래서 나온 해결책이 바로 Promise다.

Promise를 사용하면 이렇게 바꿀 수 있다:

doSomething()
  .then(doAnotherThing)
  .then(doFinalThing)
  .then(console.log)
  .catch(console.error);

Promise의 단점은 없을까?

있다. 아무리 좋아 보여도 완벽한 해결책은 아니다. 크게 두 가지 문제를 정리해볼 수 있다.

1. 복잡한 에러 처리

단일 체인에서는 .catch() 하나로 커버가 되지만, 중첩된 비동기 흐름이 생기면 어디서 예외가 발생했는지 명확하게 처리하기가 어렵다. 예를 들어, 중간의 then() 안에서 발생한 오류와 마지막에서 발생한 오류를 구분하기 어렵다.

fetch("/data")
  .then((res) => res.json())
  .then((data) => {
    // 여기서 오류가 나면 catch에서 잡지만
    throw new Error("중간 오류");
  })
  .catch((err) => {
    // 어디서 발생한 오류인지 구체적으로 파악하기 어렵다
    console.error(err);
  });

2. then 체인의 한계 (콜백 지옥의 변형)

then() 체인을 너무 많이 쓰다 보면 결국 그 자체가 지저분해지기도 한다. 들여쓰기는 줄어들 수 있지만, 순차 로직이 많을수록 가독성은 여전히 떨어진다.

그래서 나온 게 바로 async/await. 이건 다음에 따로 정리하겠지만, 결론적으로 Promise를 쓰면서 생긴 한계를 좀 더 자연스럽게 풀어준다.

마무리

• Promise는 비동기 처리를 훨씬 깔끔하고 체계적으로 만들었다.
• resolve와 reject를 통해 성공과 실패를 다룬다.
• 세 가지 상태(Pending, Fulfilled, Rejected)로 나뉘며, 상태는 한 번 바뀌면 고정된다.
• 여러 비동기 작업을 연결하거나 병렬 처리할 때 매우 유용하다.
• 하지만 깊은 에러 처리나 과도한 then 체인에서는 여전히 한계가 있다.

그래서 진짜로 실무에선 보통 Promise를 기본 단위로 쓰되, 최종적으로는 async/await와 함께 쓰는 경우가 많다. 다음 글에선 그 얘기도 해보자!

1. 타입스크립트에서 클래스란?

자바스크립트의 클래스 문법을 확장한 형태다. 중요한 차이점은 클래스 필드에 타입을 명시적으로 지정할 수 있다는 것이다. 타입을 지정하지 않으면 매개변수와 마찬가지로 암시적으로 any로 추론되는데, strict 모드에선 에러가 발생할 수 있다.

class Employee {
  name: string = "";
  age: number = 0;
  position: string = "";

  work() {
    console.log("일함");
  }
}

생성자를 통한 필드 초기화

생성자에서 필드를 잘 초기화해주면 클래스 선언 시 초기값은 생략 가능하다.

class Employee {
  name: string;
  age: number;
  position: string;

  constructor(name: string, age: number, position: string) {
    this.name = name;
    this.age = age;
    this.position = position;
  }

  work() {
    console.log("일함");
  }
}

선택적 프로퍼티

class Employee {
  name: string;
  age: number;
  position?: string;

  constructor(name: string, age: number, position?: string) {
    this.name = name;
    this.age = age;
    this.position = position;
  }
}

2. 클래스는 타입이다!

타입스크립트에서는 클래스 자체가 타입으로도 사용된다.

const employee: Employee = {
  name: "",
  age: 0,
  position: "",
  work() {},
};

3. 상속과 super()

class ExecutiveOfficer extends Employee {
  officeNumber: number;

  constructor(name: string, age: number, position: string, officeNumber: number) {
    super(name, age, position);
    this.officeNumber = officeNumber;
  }
}

파생 클래스에서 생성자를 정의하면 반드시 super()를 호출해야 하며, 생성자의 최상단에서 호출해야 한다.

4. 접근 제어자 (Access Modifier)

타입스크립트는 다음과 같은 접근 제어자를 제공한다.

• public: 어디서든 접근 가능 (기본값)
• private: 클래스 내부에서만 접근 가능
• protected : 클래스 내부 + 파생 클래스에서만 접근 가능

예시:

class Employee {
  private name: string;
  protected age: number;
  public position: string;

  constructor(name: string, age: number, position: string) {
    this.name = name;
    this.age = age;
    this.position = position;
  }

  work() {
    console.log(`${this.name}이 일함`);
  }
}

class ExecutiveOfficer extends Employee {
  showAge() {
    console.log(this.age); // 가능
  }
}

const emp = new Employee("Lee", 30, "Developer");
emp.name; // ❌
emp.age;  // ❌
emp.position; // ✅

5. 생성자에서 필드 생략하기

생성자의 매개변수에 접근 제어자를 붙이면 필드 선언과 this 할당을 생략할 수 있다.

class Employee {
  constructor(
    private name: string,
    protected age: number,
    public position: string
  ) {}

  work() {
    console.log(`${this.name} 일함`);
  }
}

이게 훨씬 깔끔하다.

6. 인터페이스 구현

타입스크립트의 인터페이스는 클래스가 반드시 따라야 하는 설계도 역할을 한다.

interface CharacterInterface {
  name: string;
  moveSpeed: number;
  move(): void;
}

class Character implements CharacterInterface {
  constructor(
    public name: string,
    public moveSpeed: number,
    private extra: string
  ) {}

  move() {
    console.log(`${this.moveSpeed} 속도로 이동!`);
  }
}

인터페이스를 통해 클래스의 구조를 강제할 수 있어서 협업이나 코드 관리에 유용하다.

이런 구조 덕분에 타입스크립트의 클래스는 훨씬 더 견고하고 유지보수하기 좋은 구조로 코드를 작성할 수 있게 해준다. 다음엔 abstract class, readonly, static 키워드도 정리해봐야겠다.

그래서 이번엔, 남한테 설명하려고 하지 않고,
그냥 나 스스로 납득할 때까지 생각한 과정을 적어보려고 한다.

렌더링, 결국 시작점을 어디로 잡느냐의 문제

처음으로 떠오른 건 이거였다.
"웹페이지가 필요하다"라는 요구가 있을 때,
그 화면을 서버가 미리 만들어서 줄 거냐, 아니면 브라우저가 받아서 스스로 만들게 할 거냐
이 두 가지 방법밖에 없다는 거다.

그리고 이 선택 하나로, 모든게 달라진다.

서버가 미리 다 만들어서 주면, 브라우저는 그냥 받아서 보여주기만 하면 되니까 빠르겠지.
하지만 서버는 매번 열심히 페이지를 만들어야 한다.
그리고 브라우저는 받은 걸로는 상호작용을 잘 못할 거다.
자기가 직접 조립한 게 아니니까.

반대로 브라우저가 직접 화면을 만들게 하면, 서버는 간단해진다. 그냥 껍데기 HTML 주고, 스크립트 파일만 넘기면 된다.
근데 브라우저는 처음에 그걸 다 해석하고, 만들어야 하니까, 초기 로딩은 느릴 수밖에 없다.

SSR이 풀려고 했던 문제

생각해보면, 옛날 웹은 거의 다 서버 렌더링이었다.
그때는 CSR 같은 개념 자체가 없었다. HTML을 만들어서 보내는 게 당연했으니까.

근데 요즘은 사용자 경험이 너무 중요해졌다. 버튼 누르면 바로 반응해야 하고,
페이지 이동할 때 새로고침 같은 거 없이 부드럽게 넘어가야 하고.
그래서 SPA(Single Page Application)가 등장했다. CSR 중심으로.

그런데, CSR만 하니까 문제가 생겼다.

• 첫 화면이 너무 늦게 뜬다.
• 빈 화면을 오래 보여준다.
• 검색 엔진이 페이지 내용을 제대로 못 읽는다.

결국, "초기 화면은 빨라야 한다", "검색 엔진도 컨텐츠를 읽을 수 있어야 한다"
이걸 다시 해결해야 했다.

그래서 다시 서버에서 미리 화면을 만들어주는 방식을
다시 끌어온 거다. 그게 바로 SSR.

SSR을 쓰면 좋은 점이 뭔가

처음에 이걸 생각했을 때, 제일 먼저 떠오른 건
"빠른 첫 화면"이었다.

SSR은 브라우저가 별로 할 일이 없다.
그냥 서버가 준 완성된 HTML을 바로 띄우면 된다.
그러니까 사용자 입장에서는 클릭하자마자 바로 화면이 뿅 하고 나온다.

특히 모바일 네트워크 느린 환경에서는 이 차이가 진짜 크다.

또 하나,
"SEO".

서버가 준 HTML 안에는 이미 컨텐츠가 다 들어있다.
텍스트, 이미지, 메타데이터 다.
검색 엔진 로봇이 그걸 읽어가기 정말 쉽다.

만약 CSR이라면?
처음엔 아무것도 없는 빈 껍데기다.
크롤러가 JS를 실행해서 동적으로 만들어지는 화면을 기다려야 한다.
근데 모든 크롤러가 그걸 잘 지원하는 건 아니니까,
결국 노출에 손해를 볼 수 있다.

그렇다고 SSR이 무조건 좋은 건 아니다

생각할수록 느꼈다.
SSR도 만만한 게 아니다.

첫 번째로,
서버 부하 문제가 있다.

CSR은 요청이 오면 그냥 JS 파일 던져주면 끝이다.
근데 SSR은 요청 올 때마다, HTML을 새로 만들어야 한다.
어떤 유저가 들어왔는지, 그 사람 데이터에 따라 화면을 조합해야 하고,
그걸 전부 서버가 실시간으로 해야 한다.

이건 진짜 서버 리소스를 많이 잡아먹는다.
유저가 많아질수록 서버는 버거워진다.

두 번째,
상호작용 문제다.

서버가 HTML은 줄 수 있지만, 거기엔 아직 자바스크립트 기능이 없다.
클릭 이벤트 같은 건 동작하지 않는다.
결국 브라우저가 추가로 JS 파일을 다운받고,
HTML에 다시 기능을 붙이는 작업(hydration)을 해야 한다.

이게 느려지면 초기 화면은 떴는데
버튼 눌러도 아무 반응 없는 이상한 상황이 생길 수 있다.

(요즘엔 이걸 줄이려고 Partial Hydration 같은 것도 연구되고 있다.)

결국 내린 결론

SSR이든 CSR이든,
단순히 "이게 무조건 낫다"는 없다.

서비스 성격에 따라 다르다.

• 블로그, 커머스, 뉴스 사이트처럼
  빠른 초기 로딩, SEO가 중요한 경우 → SSR이 낫다.

• 대시보드, 복잡한 앱형 서비스처럼
  실시간 반응성과 부드러운 전환이 중요한 경우 → CSR이 낫다.

그리고 현대 웹은 둘 중 하나만 고집하지 않는다.

초기에는 SSR로 빠르게 보여주고,
그 이후엔 CSR처럼 부드럽게 조작하는 하이브리드 방식을 쓴다.

진짜로 느낀 것

처음엔 SSR, CSR이 그냥 "렌더링 방식"의 차이인 줄 알았다.
근데 진짜 고민하고 정리해보니까,
이건 단순 기술 싸움이 아니라
"사용자가 언제, 어떻게 화면을 만나야 하는가"에 대한
전략적인 선택이었다.

기술은 결국, 사용자 경험을 어떻게 설계할까를 결정하는 수단이라는 걸
이번에 진짜 몸으로 느꼈다.

"axios가 진짜로 뭘 해주는거지? fetch랑 뭐가 다르고, 내부에서 뭘 조작하고 있는 걸까?"

그래서 하나하나 천천히 파보기로 했다.

왜 axios를 쓰는 걸까?

fetch도 요청은 보낼 수 있다. 하지만 코드를 짜다 보면 이런 반복이 너무 많다.

fetch('/api/user', {
    method: "POST",
      headers: {
        'Content-Type': 'application/json'
    },
      body: JSON.stringify({name:'홍길동'})
})
.then((res) => {
    if (!res.ok) throw new Error("에러");
      return res.json();
})

• JSON.stringify
• res.ok 체크
• 응답 파싱

결국 axios는 이런 걸 대신 해주는 거다. 그런데 여기서 멈추면 진짜 아쉬운게, axios는 단순히 문법 편하게 만드는 도우미가 아니다. axios는 HTTP 요청을 구조적으로 추상화해서, 우리가 통신 흐름을 통제할 수 있게 해주는 도구다.

요청은 단순하지 않다

HTTP 요청은 단순히 URL + 데이터만 보내는 게 아니다. 요청을 보내기 위해선 반드시 본문(body)의 구조와 그 구조를 설명해줄 헤더(header)가 필요하다. 예를 들어 이런 상황을 상상해보자.

"서버야, 내가 데이터를 보낼 건데 JSON 형식이야! 그러니까 JSON으로 파싱해서 읽어줘!" 이걸 말해주는게 바로 Content-Type이다.

Content-Type: application/json

만약 이걸 잘못 보내면 서버는 본문을 제대로 해석하지 못한다. 즉, 우리가 아무리 body를 잘 만들어도, Content-Tytpe이 엉뚱하면 서버는 "이거 뭐지?"하고 에러를 낸다.

axios는 이걸 자동으로 해준다.

axios.post('/api/user', {name: '홍길동'});

위 코드는 다음과 같이 작동한다

• 내부에서 JSON.stringify() 처리
• 자동으로 Content-Type: application/json 붙임
• 응답 JSON 자동 파싱
• 에러 status code에 따라 catch로 보내줌

내가 신경 써야 할 건 오로지 데이터뿐이다. 그게 axios의 핵심 강점 중 하나다.

그런데 문제는... Content-Type은 상황에 따라 바뀐다.

예 1: x-www-form-urlencoded

HTML <form>에서 데이터를 보낼 때는 보통 이렇게 생긴다

name=홍길동&age=24

이런 방식은 application/x-www-form-urlencoded라는 형식인데, JSON이 아니다. 이때는 직접 Content-Type을 바꿔줘야 한다.

import qs from 'qs';

axios.post('/api/user', qs.stringify({name:"홍길동"}), {
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded'
    }
});

그리고 body는 JSON이 아니라 쿼리스트링처럼 만들어야 한다. (즉, stringify 방식도 바뀜)

예 2: 파일 업로드 - multipart/form-data

이미지나 파일을 업로드할 때는 완전히 다른 형식이 필요하다.

const formData = new FormData();
formData.append('file', file);

axios.post('/upload', formData);

여기서 주의할 점은, multipart/form-data는 boundary라는 복잡한 값이 필요해서 Content-Type을 직접 쓰면 안 된다.

headers: {
    'Content-Type': 'multipart/form-data' // X
}

axios 가 내부에서 알아서 설정하게 두는 게 안전하다.

axios는 "단순한 요청 도우미"를 넘어서

내가 axios를 다시 보게 된 결정적 포인트는 인터셉터였다.

axios.interceptors.request.use((config) => {
  config.headers.Authorization = `Bearer ${token}`;
  return config;
});

요청을 보내기 전에 가로채서 헤더를 추가할 수 있고, 응답을 받은 후에도 가로채서 메시지를 조작하거나 에러 핸들링도 할 수 있다. 이걸 보고 딱 느꼈다.

"axios"는 단순히 "요청 한 번 보내자"가 아니라 요청의 전 과정을 내가 가공하고 제어할 수 있는 구조를 제공해주는 도구구나."

자주 겪은 헷갈리는 포인트들

1. Content-Type이 json인데 body가 JSON이 아니면? -> 서버가 파싱 실패 (400 오류)
2. application/json 쓰면 브라우저가 OPTIONS 요청을 보내는 경우도 있다. -> 이건 CORS 사전 요청. 서버에서 OPTIONS 허용해야 함.
3. axios.post(url,string)을 썼는데 Content-Type을 안 바꾸면? -> axios는 기본적으로 application/json을 붙이니까, string body는 해석 오류 가능

정리하면..

• axios는 단순 요청 도구가 아니라, HTTP 통신 흐름 전체를 관리할 수 있게 해주는 인터페이스다.
• Content-Type은 본문의 구조를 서버에 알려주는 설명서고, 이게 맞지 않으면 서버는 말을 이해 못한다.
• 상황에 따라 본문 인코딩과 Content-Type이 같이 움직이며, axios는 대부분 자동으로 처리하지만 가끔은 우리가 직접 설정해야 한다.

결론

지금까지는 그냥 "axios 쓰면 편하네~" 하고 썼다면, 앞으로는 이게 어떤 흐름으로 작동하고, 서버와 어떤 형식으로 대화하게 만드는지를 좀 더 구조적으로 이해하고 다뤄보자.

이해한 만큼 에러는 줄어들고, 이해한 만큼 디버깅은 빨라지고, 이해한 만큼 확장성과 통제가 가능해진다.

그저 "하나는 비동기, 하나는 동기"라고 외워두기보다는,
이 둘이 왜 분리되었는지, 리액트의 렌더링 구조상 어떤 목적을 위한 것인지
그리고 우리가 언제 어떤 것을 선택해야 하는지를 구조적으로 이해해보자.

왜 둘로 나뉘었을까?

리액트는 기본적으로 렌더링 결과를 화면에 출력하는 일을 브라우저에게 위임한다.
즉, 컴포넌트 함수가 실행되면 가상 DOM이 만들어지고,
브라우저는 이걸 실제 DOM으로 패치하고, 화면을 그린다.

그런데 여기서 문제가 생긴다.

"렌더링 후 어떤 작업을 해야 할 때, 정확히 언제 해야 할까?"

예를 들어:

• 화면이 그려진 후 데이터를 가져오고 싶다 → 늦게 실행되어도 무방
• 화면이 그려지기 전에 요소 크기를 계산해 위치를 잡아야 한다 → 화면이 바뀌기 전이어야 함

이처럼 렌더링 이후의 타이밍은 두 종류로 나뉘는 작업의 본질을 반영한다.

그래서 React는 이 후처리 작업을 위해 두 개의 훅을 제공한다:

1. useEffect → 렌더링 후, 브라우저 페인트가 끝난 뒤 실행 (비동기)
2. useLayoutEffect → 렌더링 후, DOM이 완성되었지만 브라우저가 아직 그리기 전에 실행 (동기)

구조적으로 언제 실행되나?

즉,

• useLayoutEffect는 DOM을 변경할 수 있는 마지막 기회
• useEffect는 화면이 사용자에게 보인 후 처리하면 되는 일들

실무 기준: 어떤 작업을 어디에?

useEffect에 적합한 작업

• 비동기 API 호출
• 이벤트 리스너 등록/해제
• 로컬 스토리지 작업
• 외부 라이브러리 초기화 (시각적 영향 없는 경우)

useEffect(() => {
  fetchData().then(setData);
}, []);

useLayoutEffect에 적합한 작업

• DOM의 크기, 위치 측정
• 스크롤 조작
• CSS 클래스 조작 (렌더링 전 상태 반영)
• 레이아웃 플리커 방지

useLayoutEffect(() => {
    const height = ref.current.offsetHeight;
    setHeight(height); // setState -> 즉시 DOM 반영된다.
},[]);

왜 useLayoutEffect는 위험할 수 있나?

useLayoutEffect는 동기적으로 실행된다. 즉, 이 안에서 오래 걸리는 작업을 하면 렌더링이 차단되고, UI가 멈춘 듯한 느낌을 줄 수 있다.

useLayoutEffect(() => {
    whie (true) {} // 브라우저 멈춤
}, []);

그래서 일반적으로 항상 useEffect를 먼저 쓰고, "시각적으로 깜빡임이나 DOM 위치 오류"가 있을 때만 useLayoutEffect로 바꾸는 방식이 추천된다.

예시: 깜빡임이 생기는 경우

// 깜빡임 있는 경우
useEffect(() => {
    const h = ref.current.offsetHeight;
      setTop(h);
},[]);

• useEffect는 렌더링 후에 실행
• 이미 한번 그린 화면에서 위치를 바꾸게 됨 -> 깜빡임

// 깜빡임 없는 경우
useLayoutEffect(() => {
    const h = ref.current.offsetHeight;
      setTop(h);
},[]);

• useLayoutEffect는 DOM이 완성되었지만 아직 화면에 그려지기 전
• 위치 보정 후 브라우저가 그리므로 자연스러움

결론

useEffect와 useLayoutEffect의 차이는 단순히 "빠르냐 느리냐"가 아니라, 렌더링 이후 작업을 '어느 타이밍에서 통제할 것이냐'의 문제다.

렌더링 사이클을 정확히 이해하고, 우리가 통제하고자 하는 대상(DOM 구조인지, 시각 결과인지)을 기준으로 적절한 훅을 선택하는 것이 진짜 실력이다.

이 구조를 정확히 이해하는 것은
이벤트 위임, 동적 요소 처리, stopPropagation의 쓰임새를 이해하는 데 필수적이다.

이벤트 전파란?

이벤트 전파(Event Propagation)란,
브라우저가 특정 요소에서 이벤트가 발생했을 때,
그 이벤트가 DOM 트리를 따라 상위 또는 하위 요소로 이동하면서 전파되는 흐름을 말한다.

이벤트 전파는 총 3단계로 구성된다:

1. 캡처링(Capturing)
2. 타겟(Target)
3. 버블링(Bubbling)

1단계: 캡처링 (Capturing Phase)

이벤트가 DOM 최상위 요소(document)에서부터 시작해
이벤트가 실제 발생한 타겟 요소까지 내려오는 과정이다.

<body>
  <div id="outer">
    <button id="inner">Click</button>
  </div>
</body>

button을 클릭하면, 이벤트는 다음 순서로 "내려간다"

document -> html -> body -> div#outer -> button#inner

이때 각 단계에서 {capture: true} 옵션이 걸려 있는 리스너만 실행된다.

document.body.addEventListener(
    "click",
  () => console.log("캡쳐링: body"),
  {capture: true}
);

2단계: 타겟 (Target Phase)

이벤트가 실제로 발생한 요소(이벤트 타겟)에 도달한 시점이다. 즉, 사용자가 클릭한 그 요소에서 click,input,change 등 이벤트가 실제 트리거된다. 이 시점에서는 캡처링/버블링 여부와 상관없이 항상 실행된다.

document.getElementById("inner").addEventListener("click", () => {
    console.log("타깃 단계");
})

3단계: 버블링 (Bubbling Phase)

타겟 요소에서 이벤트가 끝나면, 이제는 반대로 DOM 트리를 상위 요소로 올라가면서 전파된다.

button#inner -> div#outer -> body -> html -> document

document.body.addEventListener("click", () => {
    console.log("버블링: body");
}); // capture: false 가 기본값

실습 예시: 캡처링 vs 버블링

<div id="outer">
  <button id="inner">Click me</button>
</div>

document.getElementById("outer").addEventListener(
  "click",
  () => console.log("캡처링 - outer"),
  { capture: true }
);

document.getElementById("outer").addEventListener("click", () =>
  console.log("버블링 - outer")
);

document.getElementById("inner").addEventListener("click", () =>
  console.log("타겟 - inner")
);

결과 순서

캡처링 - outer
타겟 - inner
버블링 - outer

전파를 막고 싶다면?

element.addEventListener("click", (e) => {
    e.stopPropagation();
})

• e.stopPropagation() -> 이벤트가 이후 단계로 전달되지 않게 함
• stopImediatePropagation() -> 현재 요소의 다른 리스너도 실행하지 않음

사용 예:

• 모달 내부 클릭은 유지하되, 바깥 영역 클릭 시 닫기
• 중첩된 이벤트 중 원하는 레벨까지만 실행하고 그 이상은 막기

이벤트 위임(Event Delegation)과의 연결

이벤트 전파를 이용하면, 하나의 부모 요소에 리스너를 걸고 자식 요소의 이벤트까지 처리하는 방식, 즉 이벤트 위임을 구현할 수 있다.

document.getElementById("list").addEventListener("click", (e) => {
    if (e.target.matches("li") {
        console.log(`클릭한 항목: ${e.target.textContent}`);   
    })
})

이벤트 위임은 동적 요소 처리, 성능 최적화, 메모리 절약 등에 매우 효과적이다.

마무리

• 브라우저는 이벤트 발생 시 DOM 트리를 따라 위에서 아래로(캡처링), 아래에서 위로(버블링) 흐름을 따라 이벤트를 전달한다.
• addEventListener의 세 번째 인자 { capture: true }를 통해 캡처링 리스너 등록이 가능하다.
• stopPropagation()을 통해 중간에서 이벤트 흐름을 끊을 수 있다.
• 이 구조는 이벤트 위임(Event Delegation) 같은 패턴을 가능하게 하고, 효율적인 DOM 제어를 가능하게 한다.

이 글에서는 자바스크립트 함수의 정체성과 구조를 차근히 풀어보고,
이 개념들이 어떻게 클로저, 고차 함수, this 바인딩 같은 기능을 만들어내는지를 깊게 살펴보자.

1. 함수는 일급 객체다

자바스크립트에서 함수는 값처럼 다룰 수 있는 존재, 즉 일급 객체다.

일급 객체(First-Class Citizen)라는 건

• 변수에 할당 가능하고,
• 함수의 인자로 넘길 수 있고,
• 함수의 반환값으로 사용할 수 있다는 뜻이다.

const sayHello = function () {
  return "Hello";
};

const callFn = function (fn) {
  return fn(); // 함수를 인자로 넘김
};

console.log(callFn(sayHello)); // 'Hello'

함수가 이렇게 자유롭게 이동하고 조합될 수 있기 때문에, 자바스크립트에서는 콜백 패턴, 고차 함수, 함수형 프로그래밍이 가능해진다.

2. 함수 표현식과 익명 함수

이러한 "함수는 값이다"라는 개념은 함수 표현식으로 이어진다. 함수 선언식과 달리 함수 표현식은 값으로 함수(=익명 함수)를 정의하고 변수에 할당한다.

const add = function(a,b) {
  return a + b;
}

익명 함수는 자체적으로 이름을 갖지 않기 때문에 디버깅 시 어려울 수 있지만, 콜백 함수나 즉시 실행 함수(IIFE)처럼 한 번 쓰고 버릴 함수에서 자주 사용된다.

setTimeout(function () {
    console.log("1초 뒤 실행");
}, 1000);

3. 호이스팅과 실행 타이밍

자바스크립트는 코드 실행 전에 변수와 함수 선언을 메모리에 올리는(호이스팅) 특성이 있다. 하지만 함수 선언식과 함수 표현식은 다르게 동작한다.

console.log(foo()); // 가능
function foo() {
    return "Declared";
}

console.log(bar()); // 에러
const bar = function() {
    return "Expressed";
}

• 함수 선언식은 전체 함수가 메모리에 올라가므로, 선언 전에 호출 가능
• 함수 표현식은 변수만 undefined로 호이스팅, 함수 자체는 런타임에 할당되므로 선언 전 호출 불가

이 차이는 var, let, const 의 스코프와 함께 이해하면 더 명확하다.

4. 클로저

함수가 일급 객체이기 때문에, 함수는 언제 어디서든 호출될 수 있다. 그런데 함수가 자신이 선언될 당시의 스코프를 기억한다면 어떤 일이 가능할까? 이게 바로 클로저(Closure)다.

function outer() {
    const outerVar = "I am from outer";

      return function inner() {
        return outerVar;
    }; 
}

const innerFunc = outer();
console.log(innerFunc()); // "I am from outer"

inner 함수는 이미 outer()가 끝났음에도, outerVar에 접근이 가능하다. 왜냐하면 함수는 자신이 선언될 때의 렉시컬 환경을 함께 기억하기 때문이다.

클로저는

• 정보 은닉(private 변수)
• 함수형 캐싱
• 부분 적용 함수 등 다양한 패턴을 구현할 수 있다.

5.고차 함수

클로저와 일급 객체가 결합되면, 우리는 함수를 조립하는 패턴을 만들 수 있다. 그게 바로 고차 함수다.

고차 함수란 함수를 인자로 받거나 반환하는 함수를 말한다.

function multiplyBy(factor) {
    return function (num) {
        return num * factor;
    };
}

const double = multiplyBy(2);
console.log(double(5)); // 10

여기서 multiplyBy(2)는 함수를 반환하는 함수다. 이런 식으로 코드를 동작의 흐름이 아닌 조합의 단위로 재사용할 수 있게 된다.

6. 화살표 함수와 this 바인딩

자바스크립트의 함수는 일반 함수와 화살표 함수 두 가지 문법을 제공한다. 여기서 중요한 차이는 this의 바인딩 방식이다.

const obj = {
    value: 42,
      method: function() {
        setTimeout(() => {
            console.log(this.value) // 42
        }, 1000);
    },
};

• 일반 함수는 호출 위치 기준으로 this를 바인딩
• 화살표 함수는 정의된 위치의 this를 기억(렉시컬 this)

이는 특히 비동기 콜백이나 클래스 내부 메서드에서 유용하다.

마무리

함수는 단순히 코드를 실행을 위한 구조가 아니다. 자바스크립트에서는 스코프를 품은 실행 컨텍스트이자, 동작을 값으로 전달하는 데이터 구조이기도 하다.

이 개념들을 이해하고 나면, 왜 자바스크립트가 콜백, 고차 함수, 클로저, 커링, 컴포지션 같은 함수형 개념을 쉽게 받아들일 수 있는지 알게된다!

배열은 사실 객체(Object)다

typeof [1, 2, 3]; // "object"

자바스크립트의 배열은 사실 객체다. 정확히 말하면, 숫자 형태의 문자열을 키로 가지는 특수한 객체이다.

즉,

const arr = [1,2,3];
arr[0] === arr["0"]; // true

배열의 인덱스는 내부적으로 문자열 키 "0", "1"처럼 처리 된다. 이러한 구조는 자바스크립트 배열이 연속된 메모리 공간에 값을 저장하는 C 스타일 배열과는 다르다는 것을 보여준다.

배열 인덱스는 사실 키

우리가 arr[2]라고 쓰는 것조차 사실은 아래와 같은 의미다

arr["2"]

자바스크립트는 배열이든 객체든 모든 프로퍼티를 문자열 키로 저장한다 배열이라고 해서 예외는 아니다. 다만, 배열은 이 키 중 정수형 문자열만 인덱스로 간주하고 특별하게 다룬다.

희소 배열(Sparse Array)

아래 예제를 보자

const a = [];
a[10] = "hello";
console.log(a); // [<10 empty items>, 'hello']

이 배열은 실제로 10개의 요소를 갖는 배열이 아니다. 중간의 값은 존재하지 않고, 메모리에도 존재하지 않는 "구멍(empty slot)"으로 남는다.

이런 배열을 희소 배열(Sparse Array)이라고 부른다. 희소 배열은 순회 시 조심해야 한다. forEach, map 등은 빈 슬롯을 건너뛰지만, for, for...in은 그렇지 않다.

a.forEach((v) => console.log(v)); // "hello"만 출력

length 의 의미

자바스크립트 배열의 length는 요소의 개수를 말하지 않는다. 정확히는 "가장 큰 인덱스 + 1"을 의미한다.

const b = [];
b[3] = "a";
console.log(b.length); // 4

length를 조작할 수도 있다.

const c = [1,2,3,4,5];
c.length = 2;
console.log(c); // [1,2]

length를 줄이면 요소가 제거되고, 늘리면 요소가 생기지 않고 빈 슬롯만 만들어진다.

c.length = 10;
console.log(c); // [1,2, <8 empty items>]

배열은 "진짜 배열"이 아니다

C나 Java의 배열은 연속된 메모리 공간에 값이 저장된다. 하지만 자바스크립트 배열은 그렇지 않다.

배열 요소들은 메모리상 연속적으로 존재하지 않아도 된다.

때문에 arr[1000000] = 1 같은 코드도 즉시 실행된다. 왜냐하면 단순히 "1000000"이라는 키를 객체에 추가하는 일이기 때문이다.

배열이 성능에 나쁜 영향을 줄 수도 있다

V8 엔진(Chrome)은 성능을 위해 배열을 3가지 모드로 최적화한다

1. Packed Element : 연속된 인덱스에 값이 차 있는 배열
2. Holey Element : 중간에 빈 슬롯이 있는 배열
3. Dictionary Element : 배열이 너무 희소하거나 인덱스가 매우 클 때

const x = [1,2,3] // Packed
x[100] = "hi" // Holey -> Dictionary로 퇴화 가능

자바스크립트의 배열은 단순한 리스트가 아니다. 진짜 배열을 흉내 내는 객체이며, 객체의 유연함과 배열의 편리함을 동시에 제공하는 자료구조이다. 하지만 내부 구조를 모르고 무작정 사용하면, 엔전 최적화를 깨뜨리고, 퍼포먼스를 망칠 수도 있다.

다음에는 배열과 객체의 메모리 관리 차이, 배열 메서드 실제 구현 방식 등도 정리를 해보자!

React에서의 렌더링 과정은 단순히 setState() → 재렌더링이 일어나는 것처럼 보이지만,
내부적으로는 두 가지 단계인 Render Phase와 Commit Phase를 거친다.

각 단계는 역할이 명확히 다르고, 특히 React 18의 Concurrent Mode에서는 이 구조가 더욱 중요해진다.

1. Render Phase (렌더 단계)

UI 변경 사항을 계산하는 단계

• 변경된 상태(state)나 props를 기반으로, 어떤 UI를 그려야 하는지를 계산
• 실제 DOM에는 아무런 변경이 발생하지 않음
• 가상 DOM(Virtual DOM)을 기반으로 변화 예측
• React의 Fiber Tree 구조에 따라 새로운 트리를 생성

특징

• 순수 계산 단계이므로 중단되거나 다시 시작 가능
• 비동기적으로 실행 가능 (→ Concurrent Mode에서 특히 유용)
• useEffect, ref, DOM 조작은 이 시점에 발생하지 않음

2. Commit Phase (커밋 단계)

실제 DOM에 변경 사항을 적용하는 단계

• Render Phase에서 결정된 변경 사항을 실제 DOM에 반영
• UI가 시각적으로 업데이트됨
• DOM 업데이트 이후, useEffect, useLayoutEffect 등의 사이드이펙트 실행

특징

• 이 단계는 중단되지 않고 반드시 완료되어야 함
• 빠르게 실행되어야 하며, UI에 직접 영향을 줌

요약: Render vs Commit

동기화될 때의 특징

1. 단계적 진행 (Prioritization)

• render phase가 끝났더라도 React는 즉시 커밋하지 않을 수 있음
• 우선순위가 높은 작업이 있다면 먼저 처리
• 이후 commit phase를 안전하게 실행 → 사용자 경험 최적화

2. 일관성 있는 병목 처리

• 변경된 내용을 모두 Fiber Tree에 먼저 준비한 후 commit 하므로,
• DOM의 일관성 유지가 가능하고, 불필요한 중간 렌더링이 없음

마무리

• Render Phase는 "계산", Commit Phase는 "실행"이다
• React의 렌더링은 실제 DOM에 바로 영향을 주지 않음 → 성능 최적화 가능
• React 18 이상에서는 이 구조가 더욱 중요해짐 (비동기 작업 관리 등)

다음에는 Concurrent Mode, Fiber Tree, Reconciliation, Effect Cleanup 등의 심화 주제도 정리해보자!

함수의 타입 정의 방법

자바스크립트와 유사하지만, 타입을 명시하는 것이 TypeScript의 핵심이다.

function func(a: number, b: number): number {
    return a+b;
}

// 함수의 반환값 타입은 자동으로 추론되기 때문에 생략가능.
function func(a: number, b: number) {
    return a+b;
}

화살표 함수 타입 정의

const add = (a: number, b: number): number => a + b;

// 화살표 함수도 마찬가지로 생략이 가능하다.
const add = (a: number, b: number) => a + b;

매개변수 기본값 설정하기

아래와 같이 함수의 매개변수에 기본값이 설정되어있으면 타입이 자동으로 추론된다. 이러한 경우에는 타입 정의를 생략해도 된다.

function introduce(name = "홍길동")  {
    console.log(`name : ${name}`);
}

// 기본값과 다른 매개변수의 타입을 정의하면 오류 발생
function introduce(name:number = "홍길동") {
    ...
}

// 기본값과 다른 타입의 값을 인수로 전달해도 오류 발생
introudce(1);

선택적 매개변수 설정하기

? 를 붙이면 해당 매개변수는 선택적으로 생략 가능하다.

function introduce(name = "홍길동", age?: number) {
    console.log(`name : ${name}`);
      console.log(`age : ${age}`);
}

introduce("홍길동",24);

introduce("홍길동");

선택적 매개변수의 타입은 number | undefined로 추론된다. 따라서 연산 등에 사용하려면 타입 좁히기가 필요하다:

function introducee(name = "홍길동", age?: number) {
    console.log(`name: ${name}`);
      if(typeof age === "number") {
        console.log(`age: ${age + 10}`);
    }
}

📌 선택 매개변수는 항상 마지막에 위치해야 한다!

나머지 매개변수

자바스크립트의 rest 파라미터(나머지 매개변수) 관련 내용이다.

다음과 같이 여러개의 숫자를 인수로 받는 함수가 있다고 가정해보자.

function getSum(...rest) {
    let sum = 0;
      rest.forEach((item) => (sum += item));
      return sum;
}

getSum 함수는 나머지 매개변수 rest로 배열 형태로 number 타입의 인수들을 담은 배열을 전달 받는다. 이때 rest 파라미터의 타입은 아래와 같이 정의하면 된다.

function getSum(...rest: number[]) {
    let sum = 0;
      rest.forEach((item) => (sum += item));
      return sum;
}

이때 만약 나머지 매개변수의 길이를 고정하고 싶다면 아래와 같이 튜플 타입을 이용해도 된다.

function getSum(...rest: [number, number, number]) {
    let sum = 0;
      rest.forEach((item) => (sum += item));
      return sum;
}

함수 타입 표현식

함수 타입을 타입 별칭으로 선언해서 재사용 가능!

type ADD = (a: number, b: number) => number;

const add: ADD = (a,b) => a + b;

이렇게 함수 타입 표현식을 이용하면 함수 선언 및 구현 코드와 타입 선언을 분리할 수 있어 유용하다.

함수 타입 표현식은 아래와 같이 여러개의 함수가 동일한 타입을 갖는 경우에 요긴하게 사용된다.

type Operation = (a: number, b: number) => number;

const ADD: Operation = (a, b) => a + b;
const SUB: Operation = (a, b) => a - b;
const MULTIPLY: Operation = (a, b) => a * b;
const DIVIDE: Operation = (a, b) => a / b;

호출 시그니쳐

함수 타입 표현식과 비슷하지만 객체 형태로 표현 가능

type Operation = {
    (a:number, b:number) : number;
}

const ADD: Operation = (a, b) => a + b;
const SUB: Operation = (a, b) => a - b;
const MULTIPLY: Operation = (a, b) => a * b;
const DIVIDE: Operation = (a, b) => a / b;

// 호출 시그니처 아래에 프로퍼티를 추가 정의하는 것도 가능
// => 하이브리드 타입

type Operation = {
    (a:number, b:number) : number;
      name: string;
}

const ADD: Operation = (a, b) => a + b;

정리

오늘은 함수 타입에 대해 간단히 알아봤다. 📌 다음엔 함수 타입의 호환성, 오버로딩, 사용자 정의 타입 가드도 이어서 정리해보자!

지금은 정보처리기사 실기 준비와 블로그 이전 때문에 바쁘지만... 꾸준히 기록은 계속하자 💪

이 과정을 단계별로 이해하면, 성능 최적화, 레이아웃 디버깅, 애니메이션 처리 등에 큰 도움이 된다.

전체 흐름

렌더링 파이프라인 6단계

1. DOM 생성

• HTML 문서를 브라우저가 바이트로 읽어들인 뒤 문자 → HTML 토큰으로 파싱
• 이를 기반으로 DOM Tree 생성
• DOM은 문서의 구조를 나타낸 트리 구조

<body>
  <div>Hello</div>
</body>

DOM Tree
└─ body
   └─ div

2. CSSOM 생성

• CSS 파일을 생성하여 CSSOM Tree 생성
• 각 노드는 선택자와 그에 대응하는 스타일 정보를 포함

div {
    color: red;
}

CSSOM Tree
└─ div
   └─ color: red

3. 렌더 트리 생성

• DOM + CSSOM을 결합하여 렌더 트리 생성
• display: none 요소는 제외됨
• 시각적으로 표현되는 요소만 포함됨

Render Tree
└─ div (color: red)

4. 레이아웃 -> aka.Reflow

• 각 요소의 위치와 크기 계산
• 뷰포트 크기 등을 고려
• 이 단계에서 Reflow 발생 가능 -> 성능 영향 큼

예시 : 창 크기 변경, 글자 수 변화, margin/padding 변경

5. 페인팅

• 각 요소에 대한 시각적 표현을 그림
• 텍스트, 색상, 테두리, 그림자 등
• 복잡한 페인팅은 성능에 영향 큼

예시 : box-shadow, border-radius, gradient 등

6. 컴포지팅

• 요소들을 레이어 단위로 나누고 GPU로 합성
• transform, opacity 등은 이 단계에서만 처리
• 레이아웃/페인트를 다시 하지 않기 때문에 애니메이션 ㅅ ㅓㅇ능이 좋음

성능 최적화를 위해 기억할 점

• display: none, visibility: hidden, transform, opacity 의 차이 이해
• Reflow / Repaint / Compositing 비용 구분
• 애니메이션은 가능하면 transform, opacity만 사용 -> GPU 처리

렌더링 파이프라인을 이해하면, 왜 특정 CSS가 느려지는지, 어떤 DOM 조작이 Reflow를 유발하는지 예측할 수 있다.
프론트엔드 성능 최적화의 핵심 지식! 꼭 익혀두자 💪

이럴 때 사용할 수 있는 주요 성능 최적화 기법들을 정리해보자!

1. React.memo – 컴포넌트 메모이제이션

props가 변경되지 않았다면 리렌더링을 막는 고차 컴포넌트(HOC)

import React from 'react';

const MyComponent = React.memo(function MyComponent({ text }) {
  console.log("렌더링!");
  return <div>{text}</div>;
});

memo를 사용하면 불필요한 렌더링을 막아주기 때문에 렌더링 비용이 큰 컴포넌트에서 특히 유용하다.

2. useCallback & useMemo - 함수와 값을 메모제이션

2-1. useCallback - 함수를 메모제이션

const handleClick = useCallback() => {
    console.log("클릭됨");
}, []);

• 의존성 배열이 변하지 않는 한, 같은 함수 인스턴스를 재사용
• 자식 컴포넌트에 함수를 props로 넘길 때 유용

2-2. useMemo - 계산된 값을 메모제이션

const result = useMemo(() =>{
    return heavyCalculation(a,b);
}, [a,b])

• 의존값이 변경되지 않는 한, 연산을 다시 수행하지 않는다.
• 비용이 큰 계산 작업에서 유용

예제: useCallback + memo 같이 사용

const Child = React.memo(({onClick}) => {
    console.log("Child 렌더링");
      return <button onClick={onClick}>클릭</button>
});

function Parent() {
    const [count, setCount] = useState(0);

      const handleClick = useCallback(() => {
        console.log("Clicked")!
    }, []);

    return (
        <>
            <Child onClick={handleClick} />
            <button onClick={() => setCount(count + 1)}>+1</button>
        </>
    )
}

3. 코드 스플리팅 (Code Splitting)

애플리케이션을 여러 개의 청크(조각)로 분할하여 필요한 시점에만 로딩 -> 초기 로딩 시간 단축!!

React에서 코드 스플리팅 도구

• React.lazy() - 동적으로 컴포넌트를 로드
• Suspense - 로딩 중 fallback UI 표시

예제

import React, {Suspense, lazy} from 'react';

const LazyComponent = lazy(() => import('./MyComponent'));

function App() {
    return (
        <Suspense fallback={<div>로딩 중...</div>}>
            <LazyComponent/>
        </Suspense>
    )
}

MyComponent는 실제로 화면에서 필요할 때 비동기적으로 로드된다. -> 초기 렌더링에서는 불필요한 코드가 제외되므로 성능 향상!

코드 스플리팅이 필요한 상황

1. 초기 로딩 시간이 길어지는 경우

• 앱이 크고 복잡할수록 초기 JS 번들 크기가 커짐
• 사용자가 처음 보는 화면만 빠르게 로드되도록 분할하면 UX 개선

2. 라우트별 분할이 필요한 경우

const Home = lazy(() => import('./pages/Home'));
const About = lazy(() => import('./pages/About'));

• SPA 구조에서는 각 페이지 컴포넌트를 나눠서 필요할 때만 로딩
• 라우터와 함께 코드 스플리팅하면 자연스럽고 효율적

마무리

React의 성능 최적화는 단순히 렌더링을 줄이는 것을 넘어서 전체 앱의 구조, 사용자 경험까지 고려한 설계가 필요하다.

다음에는 고급 성능 전략도 이어서 정리해보도록 하자!

React에서는 <input>, <textarea> 등의 폼 요소를 사용할 때
입력 값을 어떻게 관리하느냐에 따라 두 가지 방식으로 나뉜다:

• Controlled Component (제어 컴포넌트)
• Uncontrolled Component (비제어 컴포넌트)

1. Controlled Component (제어 컴포넌트)

React의 state를 통해 입력 값을 관리하는 방식

• 입력 요소의 value 속성을 상태값과 동기화
• 사용자가 입력할 때마다 onChange로 상태를 업데이트
• 모든 입력 데이터를 React가 완전히 제어함

장점

• 실시간 입력 값 검증
• 입력 값 초기화 및 제어 쉬움
• 여러 입력 간 상호작용 로직 구현 유리

코드 예시

import { useState } from 'react';

function ControlledInput() {
  const [text, setText] = useState('');

  const handleChange = (e) => setText(e.target.value);

  return (
    <div>
      <input type="text" value={text} onChange={handleChange} />
      <p>입력한 값: {text}</p>
    </div>
  );
}

2. Uncontrolled Component (비제어 컴포넌트)

입력 값이 DOM 자체에 저장되고, React가 직접 제어하지 않는 방식

• useRef를 통해 DOM에 접근
• React의 상태 업데이트가 필요 없음
• 값은 필요할 때 직접 DOM에서 읽음

장점

• 불필요한 렌더링이 없음
• 단순한 폼 처리에 적합
• 성능상 유리 (특히 대규모 폼에서)

코드 예시

import { useRef } from 'react';

function UncontrolledInput() {
  const inputRef = useRef(null);

  const handleSubmit = () => {
    alert(`입력한 값: ${inputRef.current.value}`);
  };

  return (
    <div>
      <input type="text" ref={inputRef} />
      <button onClick={handleSubmit}>제출</button>
    </div>
  );
}

상황에 따른 선택 기준

마무리

• 복잡한 폼 제어, 조건 렌더링, 유효성 검사 등의 경우 → Controlled
• 단순 입력 후 제출만 필요한 경우 → Uncontrolled

React에서 두 방식은 서로 대체 가능한 것이 아니라 용도에 맞게 선택하는 것이 중요하다! 두 방식을 모두 익혀두면 상황에 따라 적절한 구현이 가능하다. 💪

1. props란?

부모 컴포넌트가 자식 컴포넌트에게 전달하는 데이터
읽기 전용이며, 자식 컴포넌트는 이를 수정할 수 없다.

function ChildComponent(props) {
  // props.name = "New Name"; ❌ 오류 가능
  return <div>{props.name}</div>;
}

function ParentComponent() {
  return <ChildComponent name="Eunseop" />;
}

props는 외부에서 전달된 값으로, 컴포넌트 내부에서 변경 불가능한 값이다. 이를 통해 컴포넌트 간의 데이터 흐름을 예측 가능하고 안정적으로 유지할 수 있다.

2. state란?

컴포넌트 내부에서 관리되는 동적인 데이터 컴포넌트가 리렌더링되는 원인이 된다.

import { useState } from 'react'

function Counter() {
    const [count, setCount] = useState();

      const handleClick = () => setCount(prev => prev + 1);

      return (
        <div>
            <p>현재 카운트: {count}</p>
            <button onClick={handleClick}>+1</button>
        </div>
    )

}

state는 사용자 입력, 네트워크 응답 등 변화하는 데이터를 처리할 때 사용된다.

왜 props는 자식 컴포넌트에서 변하지 않을까?

React 의 단뱡향 데이터 흐름(One-way data flow) 원칙 때문!

• props는 읽기 전용
• 자식 컴포넌트는 props를 직접 변경할 수 없음
• 데이터 흐름이 예측 가능하고, 상태 관리가 쉬워짐
• 컴포넌트 재사용성과 독립성이 높아짐

props를 변경하고 싶다면?

자식 컴포넌트가 props를 변경할 수는 없지만, 부모 컴포넌트로부터 전달받은 함수를 호출해 상태를 변경할 수는 있다.

이런 방식은 상태 끌어올리기(Lifiting State Up)라고 한다.

예제

-> 부모 컴포넌트

import { useState } from "react"
import ChildComponent from "./ChildComponent"


function ParentComponent() {
    const [name, setName] = useState("Hong");

      const changeName = () => setName("Kim");


      return (
      <div>
        <h2>Parent: {name}</h2>
        <ChildComponent name={name} onChangeName={changeName} />
      </div>
    )
}

-> 자식 컴포넌트

function ChildComponent({name, onChangeName}) {
    return (
        <div>
            <p>Child: {name}</p>
            <button onClick={onChangeName}>이름 변경</button>
        </div>
    )
}

결과적으로

• 상태는 부모가 소유
• 자식은 상태를 변경할 수 있는 함수만 전달받음
• 데이터 흐름은 여전히 단방향 유지
• 코드의 예측 가능성, 유지보수성, 재사용성이 높아짐

마무리

• props: 외부(부모)에서 전달받는 읽기 전용 데이터
• state: 컴포넌트 내부에서 정의하고 관리하는 변경 가능한 데이터
• props를 바꾸고 싶을 땐 -> 부모 상태 변경 함수 전달 (상태 끌어올리기)

이 둘의 역할을 제대로 , 이해하면, 컴포넌트 구조 설계와 상태 관리가 훨씬 쉬워진다! 다음에는 Context API, useReducer 등 상태 관리 확장 도구도 정리해보도록 하자!

자바스크립트의 이벤트 루프(Event Loop) 는
싱글 스레드 언어인 JavaScript가 비동기 작업을 효율적으로 처리할 수 있게 하는 핵심 메커니즘이다.

왜 이벤트 루프가 필요할까?

자바스크립트는 기본적으로 한 번에 하나의 작업만 처리할 수 있는 싱글 스레드 언어이다.
그런데 어떻게 API 요청, setTimeout, UI 반응 등 다양한 작업을 동시에 처리할 수 있을까?

그 답이 바로 이벤트 루프에 있다!

이벤트 루프는
"콜 스택이 비어 있을 때, 대기 중인 비동기 콜백들을 하나씩 실행시켜주는 메커니즘"이다.

핵심 구조: 콜 스택 + 이벤트 루프 + 태스크 큐

JavaScript의 실행 구조는 다음처럼 구성되어 있다.

• Call Stack: 현재 실행 중인 함수가 쌓이는 곳 (동기 작업 처리)
• Web APIs: 타이머, AJAX, 이벤트 핸들러 등의 백그라운드 처리 영역
• Task Queues:
  • Macrotask Queue: setTimeout, setInterval 등
  • Microtask Queue: Promise.then, queueMicrotask 등
• Event Loop: 위 요소들을 관리하며 비동기 콜백을 콜 스택에 넣어줌

🔁 이벤트 루프 동작 예시

console.log('1');

setTimeout(() => {
  console.log('2');
}, 0);

Promise.resolve().then(() => {
  console.log('3');
});

console.log('4');

// 출력 결과

1
4
3
2

설명

1. '1' -> 동기 -> 즉시 실행
2. setTimeout() -> Web API -> MacroTask Queue에 등록
3. Promise.then() -> MicroTask Queue에 등록
4. '4' -> 동기 -> 즉시 실행
5. Call Stack 비자마자 -> MicroTask Queue 우선 실행 -> 3
6. 그 다음 -> MacroTask Queue 실행 -> 2

setTimeout(callback, 0) 의 오해

setTimeout(() => {
    console.log("Hello");
}, 0);

위 코드는 "0초 뒤에 실행" 되는 것이 아니라

• Web API에 타이머 등록
• 최소 0ms 후에 MacroTask Queue에 들어감
• 콜 스택이 비었을 때 실행됨

즉, 동기 코드가 모두 끝난 후에 실행이 된다!!

태스크 큐의 종류

이벤트 루프는 자바스크립트 비동기 처리의 핵심이자, 성능 최적화와 버그 해결에 있어서도 매우 중요한 개념이다.

다음에는 requestAnimationFrame, queueMicrotask 같은 심화 개념도 정리해보자! 🚀