1. 사건의 발단
2. 문제 해결 과정과 학습 계기
3. 주요 개념
   • GitHub Permalink
   • Git Blame
   • Git Log와 GitHub History
4. 세 가지 개념 비교
5. [간단한 그림으로 전체 요약](#간단한 그림으로 전체 요약)
6. 결론

사건의 발단

회사에서 리팩토링을 진행하면서 수많은 커밋과 수차례의 merge가 진행되었었다. 리팩토링의 종점에 거의 도달했을때, 리팩토링 초창기에 있었던 코드가 필요하다는 것을 알게 되었다. 해당 코드의 line 의 위치는 기억하지만 이미 최신 브랜치에서는 해당라인이 다른 코드로 덮여 있는 이 상황...

문제 해결 과정과 학습 계기

옆자리 사수분 (shout out to ** calvin **) 께 내 상황을 공유하고 도움을 요청하니 Github permalink와 git blame 을 통해 타임머신으로 이동해서 쉽게 찾으셨습니다. 그때 들은 설명과 해당 키워드를 통해 내가 개인적으로 공부한 내용을 기록하려고 합니다.

주요 개념

• ** GitHub Permalink **
• ** Git Blame **
• ** Git log **

GitHub Permalink

1. 개념 Permalink 는 브랜치명 대신 특정 커밋 해시를 URL에 넣어, 그 커밋 시점의 파일(그리고 선택한 라인 범위)을 가리킨다. 브랜치가 앞으로 업데이트되더라도 Permalink는 과거 시점에 “고정”된다.

   • 브랜치 링크(시간에 따라 변함)

     https://github.com/org/repo/blob/main/src/utils/date.ts#L10-L20

   • Permalink(커밋 고정, 내용 불변)

     https://github.com/org/repo/blob/3c7e92b5a5/src/utils/date.ts#L10-L20

     여기서 3c7e92b5a5는 커밋 해시이며, #L10-L20은 라인 앵커다. 이 링크는 그 커밋의 트리 스냅샷 안에서 해당 경로와 라인을 표시한다.

2. 생성 방법

• GitHub 웹에서 파일을 열고 줄 번호를 클릭 → “Copy permalink” 또는 상단 메뉴의 “…” → Copy permalink” 를 사용한다.
• 이미 브랜치 링크를 보고 있다면, 키보드 단축키 Y 를 누르면 URL이 자동으로 커밋 해시 기반의 Permalink로 변환된다.
• 라인 범위는 #L10 또는 #L10-L20 형태로 지정한다.

3. 간단한 도식

   main:     A ---- B ---- C (HEAD)
              \
   Permalink →    B  ← 고정된 스냅샷

Git Blame

1. 개념 Blame은 파일의 각 라인이 현재 모습으로 자리 잡게 된 가장 최신 커밋을 표시한다. GitHub 파일 화면의 Blame 버튼으로 접근할 수 있고, CLI에서는 git blame을 쓴다.

• 본질: “이 줄은 누가 언제 어떤 커밋에서 마지막으로 손댔는가?”
• GitHub Blame에는 “View blame prior to this change” 기능이 있다. 이는 해당 줄을 바꾼 그 커밋의 직전 상태로 점프하여 라인의 족보를 거슬러 올라가게 한다.

2. “prior to”가 이동하는 기준

• git log 처럼 파일의 최신 커밋 순서로 이동하는 것이 아니라, 그 줄을 실제로 수정한 커밋 체인만 따라간다.
• 즉, 줄을 수정하지 않은 커밋은 건너뛰고, e -> c -> a 와 같이 라인을 바꾼 커밋들만 역순으로 밟는다.

도식

커밋 전체:  a ---- b ---- c ---- d ---- e (HEAD)
라인 수정:  *           *           *

blame prior-to 체인:  e  →  c  →  a
log(파일) 체인:        e  →  d  →  c  →  b  →  a

Git Log와 GitHub History

1. 개념 Log, History는 파일단위의 모든 커밋을 시간 역순으로 나열한다. github 파일 화면의 history 버튼이 이에 해당된다.

• 핵심: "이 파일은 어떤 커밋들을 거쳐 바뀌어 왔는가?"
• 라인을 건드리지 않은 변경(ex 파일 헤더 주석, import 정리, 포맷팅 등)도 모두 표에 잡힌다.

세 가지 개념 비교

간단한 그림으로 전체 요약

[브랜치 타임라인]
A ---- B ---- C ---- D ---- E (HEAD)

- Permalink: 특정 시점(B)의 스냅샷을 영구 지칭
- Blame: 특정 라인만 추적 → E → C → A
- Log/History: 파일 단위의 전체 흐름 → E, D, C, B, A

[브랜치/병합 개략]
        feature-x ---o
                     \
A --- B --- C --------M --- E
            \        /
             hotfix ----o

- History/PR: M에서 어떤 브랜치가 병합되었는지 맥락 확인
- Network: 분기/병합의 노선도 파악

결론

• Permalink 는 스냅샷의 정밀한 인용 도구다. 브랜치가 움직여도 링크는 움직이지 않는다.
• Blame 은 라인 단위의 족보다. prior -to 체인으로 "그 줄"의 진화를 거슬러 올라간다.
• Log, History는 파일의 연대기이다. 큰 변곡점과 흐름을 파악하는데 유리하다.

왜 dev 브랜치가서 코드 확인 안했냐는 나쁜 말은 ㄴㄴ

타입스크립트를 공부하다 보면 단순한 문법을 넘어서 트릭처럼 느껴지는 문법 패턴들을 만나게 됩니다.
이 글에서는 그중에서도 유니온 추출 / 매핑 후 값 유니온화 / 튜플 원소 타입 뽑기 같은 핵심 패턴을 정리합니다.

1. T[number] → 배열/튜플 원소 타입 유니온

개념

• 배열 타입 T에 [number]를 붙이면, 해당 배열의 모든 원소 타입을 유니온으로 추출합니다.

예시

type Roles = ["guest", "user", "admin"];
type Union = Roles[number];
// "guest" | "user" | "admin"

👉 튜플이든 배열이든, [number]는 “이 타입에서 나올 수 있는 모든 값들의 합집합”을 의미합니다.
즉, 런타임 반복이 아니라 타입 레벨 유니온 추출이에요.

2. Obj[keyof Obj] → 객체 value 타입 유니온

개념

• 객체 타입에서 keyof Obj는 키들의 유니온.
• 다시 Obj[keyof Obj]를 하면, 그 키들에 해당하는 모든 value 타입을 유니온으로 가져옵니다.

예시

type Obj = {
  a: number;
  b: string;
};

type Values = Obj[keyof Obj];
// number | string

👉 이 패턴은 “객체의 모든 value 타입을 유니온으로 만들고 싶을 때” 사용합니다.

3. { [P in keyof T]: ... }[keyof T] → 매핑 후 값 유니온 뽑기

개념

• 매핑 타입으로 키를 순회하면서 조건을 걸어 값을 생성.
• 마지막에 [keyof T]로 인덱싱하면, 생성된 객체의 value들을 유니온으로 모아 추출합니다.

예시

type Obj = { a: 1; b: 2; c: 3 };

type PickEven<T> = {
  [P in keyof T]: T[P] extends 2 ? P : never
}[keyof T];

type Result = PickEven<Obj>;
// "b"

👉 ...}[keyof T] 트릭은 매핑 타입 결과를 다시 유니온으로 만드는 핵심 패턴입니다.

4. 트릭 조합 실전: Problem 03 – auth-guards

이제 위의 트릭을 합쳐서, 특정 역할(Role)에 따라 접근 가능한 경로를 타입으로 구하는 문제를 풀어보겠습니다.

요구사항

• Role: "guest" | "user" | "admin"
• RouteMap: 각 path에 접근 가능한 role 리스트를 정의
• AccessibleRoutes: 역할 R이 접근 가능한 path들의 유니온

풀이

export type Role = "guest" | "user" | "admin";

export type RouteMap = {
  "/": { roles: ["guest", "user", "admin"] };
  "/login": { roles: ["guest"] };
  "/dashboard": { roles: ["user", "admin"] };
  "/settings": { roles: ["admin"] };
};

export type AccessibleRoutes<R extends Role> = never // 초기 상태

// AccessibleRoutes<R> 기대값
// ----------------------------
type G = AccessibleRoutes<"guest">;
type G_Expected = "/" | "/login";
type _g = Expect<Equal<G, G_Expected>>;

type U = AccessibleRoutes<"user">;
type U_Expected = "/" | "/dashboard";
type _u = Expect<Equal<U, U_Expected>>;

type A = AccessibleRoutes<"admin">;
type A_Expected = "/" | "/dashboard" | "/settings" | "/login";
type _a = Expect<Equal<A, A_Expected>>;


정답
// 1. 특정 path의 roles 유니온 추출
type RouteRoles<P extends keyof RouteMap> = RouteMap[P]["roles"][number];

// 2. 매핑 타입 + 조건부 타입 → 접근 가능한 path 필터링
export type AccessibleRoutes<R extends Role> = {
  [P in keyof RouteMap]: R extends RouteRoles<P> ? P : never
}[keyof RouteMap];

결과

• AccessibleRoutes<"guest"> → "/" | "/login"
• AccessibleRoutes<"user"> → "/" | "/dashboard"
• AccessibleRoutes<"admin"> → "/" | "/dashboard" | "/settings"

✅ 결론

• T[number]: 배열/튜플 원소 타입을 유니온으로 추출하는 패턴
• Obj[keyof Obj]: 객체의 value 타입들을 유니온으로 추출하는 패턴
• { [P in keyof T]: ... }[keyof T]: 매핑 타입 후 값을 다시 유니온으로 모으는 패턴

TypeScript에서 extends는 두 가지 문맥에서 사용됩니다.

1) 제네릭 제약(Constraint)
2) 조건부 타입(Conditional Type)
겉보기엔 똑같아 보여도, 의미와 쓰임새는 전혀 다릅니다. 이번 글에서는 이 둘을 확실히 구분해보고, 마지막에 실전 예제까지 살펴봅니다.

1. 제네릭 제약 (Constraint)

정의

제네릭 파라미터 T가 어떤 타입 U의 부분집합이어야 함을 선언하는 것.
형태: <T extends U>
→ “T는 반드시 U에 호환 가능한 타입이어야 한다.”

예시

function lengthOf<T extends { length: number }>(arg: T): number {
  return arg.length;
}

lengthOf("hello");        // string → length 있음 → OK
lengthOf([1, 2, 3]);      // number[] → length 있음 → OK
lengthOf({ length: 10 }); // 객체도 OK
// lengthOf(123);         // ❌ number에는 length 없음

👉 T extends { length: number } 제약이 걸렸기 때문에, length 속성이 없는 타입은 아예 함수 호출이 불가능합니다.

2. 조건부 타입 (Conditional Type)

정의

조건문처럼 타입을 분기합니다.
형태: T extends U ? X : Y
→ “T가 U에 할당 가능하면 X, 아니면 Y”

예시

type IsString<T> = T extends string ? "yes" : "no";

type A = IsString<string>; // "yes"
type B = IsString<number>; // "no"

제네릭과 함께

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

type A = ElementType<string[]>; // string
type B = ElementType<number>;   // number

👉 infer 키워드를 함께 써서, 조건이 맞으면 내부 타입을 변수처럼 추출해내는 것도 가능합니다.

3. 제약과 조건부를 함께 쓰는 경우

실무에서 자주 쓰는 패턴은 두 가지가 결합된 형태입니다.

function getProp<T extends object, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

• T extends object → T는 반드시 객체여야 함
• K extends keyof T → K는 반드시 T의 키 중 하나여야 함
• T[K] → K가 유효 키라는 것이 보장되므로 안전하게 값의 타입을 추출

4. 차이 정리

5. 실무 활용 패턴

• 제약으로 안전성 확보

    function pick<T, K extends keyof T>(obj: T, key: K): T[K] {
      return obj[key];
    }

  → K가 반드시 T의 키라는 제약이 있으므로 안전합니다.

• 조건부 타입으로 타입 변환

    type NonNullable<T> = T extends null | undefined ? never : T;
  
    type A = NonNullable<string | null>; // string
    type B = NonNullable<number | undefined>; // number

Q&A 정리

Q1. 제네릭 제약에서의 extends는 어떤 느낌인가요?

• “이 타입은 반드시 저 타입의 하위 집합이어야 한다”라는 규칙을 미리 거는 것.
• 런타임에서 if 체크를 하는 게 아니라, 애초에 호출/사용 자체가 금지됩니다.

Q2. 조건부 타입에서의 extends는 어떻게 다른가요?

• 타입 레벨의 삼항 연산자 같은 것.
• 타입 T를 실제로 넣으면 결과가 X 또는 Y로 “계산”됩니다.
• 즉, 타입을 실행해서 결과를 얻는 로직이라고 이해하면 편해요.

6. 실전 예시: RequestOf / ResponseOf

Day4 문제인 api-endpoints를 예로 들어보겠습니다.

export type ApiMap = {
  "/login": {
    req: { id: string; pw: string };
    res: { token: string };
  };
  "/me": {
    res: { id: string; name: string };
  };
  "/items": {
    req: { page: number };
    res: { items: Array<{ id: string; name: string }> };
  };
};

export type RequestOf<M, K extends keyof M> =
  "req" extends keyof M[K] ? M[K]["req"] : never;

export type ResponseOf<M, K extends keyof M> =
  M[K]["res"];

여기서 쓰이는 extends 두 가지 문맥:

1. 제약

   • <K extends keyof M>
   • K는 반드시 M 객체의 키 중 하나여야 한다.
   • 즉, "/login", "/me", "/items" 중 하나여야 함.

2. 조건부 타입

   • "req" extends keyof M[K] ? ... : ...
   • M[K]에 "req" 키가 존재하면 M[K]["req"],
     아니면 never.
   • 즉, 조건부 분기로 req가 없는 엔드포인트("/me")에서는 never 처리.

👉 이 조합 덕분에, "/login" 같은 엔드포인트에서는 요청 타입이 나오고, "/me" 같은 요청 없는 엔드포인트에서는 자동으로 never가 됩니다.

✅ 결론

• 제약(Constraint):제약 조건입니다. 규칙이라고 생각하세요. 제공하는 유형 K는 반드시 M의 키여야 한다. 이는 허용되는 유형을 제한하는 것입니다.
• 조건부 타입(Conditional Type): 타입 레벨에서 if/else 분기
• 실무에서는 두 가지가 함께 쓰이며, RequestOf 같은 유틸 타입에서 “키 제약 + 조건부 분기” 패턴이 핵심적으로 활용됩니다.

Problem 1 – FilterString

문제 요구

주어진 타입 T가 string이면 그대로 남기고, 그렇지 않으면 never가 되도록 타입을 정의하라.

문제 code

// 초기 상태  
export type FilterString<T> = never;  

type A = FilterString<string>;      // string  
type B = FilterString<number>;      // never  
type C = FilterString<"hello">;     // "hello"  
type D = FilterString<boolean>;     // never  
type E = FilterString<string | 1>;  // string  

test code

import type { Expect, Equal } from "../../tests/type-assert.ts";  
import type { FilterString } from "./01-filter-string.ts";  

type _cases = [  
  Expect<Equal<FilterString<string>, string>>,  
  Expect<Equal<FilterString<number>, never>>,  
  Expect<Equal<FilterString<"hello">, "hello">>,  
  Expect<Equal<FilterString<boolean>, never>>,  
  Expect<Equal<FilterString<string | 1>, string>>,  
];  

풀이 과정

조건부 타입을 떠올렸고, T extends string ? T : never 형태로 구현하면 정확히 요구사항을 만족했습니다.
유니언 타입 입력 시 분배 조건부 타입이 동작해 자동으로 필터링된 결과가 나왔습니다.

적용된 개념

• 조건부 타입 (T extends U ? X : Y)
• 분배 조건부 타입

최종 코드

export type FilterString<T> = T extends string ? T : never;  

Problem 2 – PublicUser

문제 요구

User 타입에서 password와 ssn만 제거한 PublicUser 타입을 만들어라.

문제 code

export type User = {  
  id: string;  
  email: string;  
  name: string;  
  phone?: string;  
  address?: string;  
  password: string;  
  ssn: string;  
};  

// 초기 상태  
export type PublicUser = never;  

test code

import type { Expect, Equal } from "../../tests/type-assert.ts";  
import type { PublicUser } from "./02-public-user.ts";  

type _cases = [  
  Expect<Equal<PublicUser,  
    { id: string; email: string; name: string; phone?: string; address?: string }  
  >>,  
];  

풀이 과정

민감 정보를 제거한다는 요구는 Omit 유틸리티 타입으로 쉽게 해결 가능했습니다.
Omit<User, "password" | "ssn">로 정의하면 의도대로 동작합니다.

적용된 개념

• Omit<T, K> = 특정 키 제거
• 내부적으로 Pick + Exclude 조합으로 동작

최종 코드

export type PublicUser = Omit<User, "password" | "ssn">;  

Problem 3 – StatusCounters

문제 요구

네트워크 요청 상태를 "idle" | "loading" | "success" | "error"로 정의하고,
각 상태별 카운터를 number 값으로 갖는 객체 타입을 정의하라.

문제 code

// 초기 상태  
export type Status = string;  
export type Counters = Record<string, number>;  

test code

import type { Expect, Equal } from "../../tests/type-assert.ts";  
import type { Status, Counters } from "./03-status-counters.ts";  

type _cases = [  
  Expect<Equal<Status, "idle" | "loading" | "success" | "error">>,  
  Expect<Equal<Counters, { idle: number; loading: number; success: number; error: number }>>,  
];  

풀이 과정

매핑 타입으로 유니언을 순회하며 모든 상태를 key로 정의했습니다.
Record<Status, number>로 간단히 해결할 수 있었습니다.

적용된 개념

• 매핑 타입 { [K in U]: ... }
• Record<K, V> = { [P in K]: V }

최종 코드

export type Status = "idle" | "loading" | "success" | "error";  
export type Counters = Record<Status, number>;  

Problem 4 – ApiValues

문제 요구

ApiMap 구조에서 각 엔드포인트의 data 타입만 추출하여 유니언으로 모으라.

문제 code

export type ApiMap = {  
  "/me": { data: { id: string; name: string } };  
  "/items": { data: Array<{ id: string; price: number }> };  
  "/health": { data: { ok: true } };  
};  

// 초기 상태  
export type ValueOf<T> = never;  
export type ApiValues<T> = never;  

test code

import type { Expect, Equal } from "../../tests/type-assert.ts";  
import type { ApiMap, ApiValues } from "./04-api-values.ts";  

type _cases = [  
  Expect<Equal<  
    ApiValues<ApiMap>,  
    { id: string; name: string }  
    | Array<{ id: string; price: number }>  
    | { ok: true }  
  >>,  
];  

풀이 과정

객체 value 타입 전체를 뽑는 T[keyof T]를 ValueOf로 정의했습니다.
그 후 ValueOf["data"]로 각 엔드포인트의 data 속성 타입만 추출했습니다.

적용된 개념

• 인덱스드 액세스 타입 T[K]
• T[keyof T] = 객체 value 전체 유니언
• ValueOf["data"]로 data 속성 추출

최종 코드

export type ValueOf<T> = T[keyof T];  
export type ApiValues<T> = ValueOf<T>["data"];  

Problem 5 – PartialBy

문제 요구

PartialBy<T, K>를 구현해, T에서 K 키만 optional로 만들고 나머지는 그대로 유지하라.

문제 code

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

// 초기 상태  
export type PartialBy<T, K extends keyof T> = never;  

test code

import type { Expect, Equal } from "../../tests/type-assert.ts";  
import type { PartialBy } from "./05-partial-by.ts";  

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

type _cases = [  
  Expect<Equal<  
    PartialBy<User, "email">,  
    { id: string; name: string; email?: string; age?: number }  
  >>,  
  Expect<Equal<  
    PartialBy<User, "name" | "age">,  
    { id: string; name?: string; email: string; age?: number }  
  >>,  
];  

풀이 과정

처음엔 조건부 타입으로 optional을 구현했지만 이는 단순히 undefined 허용으로만 처리되었습니다.
그래서 Omit + Pick + Partial을 교차(&)시켜 특정 키만 optional로 만들었습니다.

적용된 개념

• Omit<T, K>: 특정 키 제외
• Pick<T, K>: 특정 키만 선택
• Partial<Pick<T, K>>: 해당 키만 optional 처리
• & (교차 타입): 두 타입을 합쳐 최종 타입 생성

최종 코드

export type PartialBy<T, K extends keyof T> =  
  Omit<T, K> & Partial<Pick<T, K>>;  

🔎 Q&A 심화 정리

1. K in Status vs keyof Status

(1) K in Status

• in 키워드는 매핑 타입 문맥에서 사용된다.

• Status라는 유니언 타입의 원소들을 하나씩 순회하며, 그 값을 객체의 키로 만든다.

    type Status = "idle" | "loading" | "success";  
    type Counters = { [K in Status]: number };  
  
    // 결과  
    type Counters = {  
      idle: number;  
      loading: number;  
      success: number;  
    }  

👉 즉, K in Status는 유니언을 그대로 key 집합으로 사용하는 방법이다.

(2) keyof Status

• keyof는 객체 타입의 키를 뽑아내는 연산자다.
• 하지만 Status는 유니언 리터럴 타입이지 객체가 아니다.
• 따라서 keyof Status를 쓰면 문자열 리터럴의 내부 프로퍼티가 뽑혀서 전혀 다른 결과가 된다.

type Status = "idle" | "loading";  
type Wrong = keyof Status;  
// 결과: string | number | symbol  

👉 이유: 문자열 리터럴 타입은 사실상 string의 하위 타입이고, 자바스크립트에서 문자열의 키는 string | number | symbol이 될 수 있기 때문이다.

(3) 정리

• 유니언 타입을 그대로 키로 쓰고 싶을 때 → K in Status
• 객체의 키를 추출하고 싶을 때 → keyof User

2. keyof 객체 타입 결과는?

(1) 기본 객체

type User = { id: string; name: string; email?: string };  
type Keys = keyof User;  
// "id" | "name" | "email"  

👉 옵셔널 여부와 관계없이 키는 모두 포함된다.

(2) 인덱스 시그니처

type Dictionary = { [key: string]: number };  
type Keys = keyof Dictionary;  
// string | number  

👉 자바스크립트 객체 키는 사실상 string | number | symbol이 될 수 있다.

(3) 배열

type Arr = string[];  
type Keys = keyof Arr;  
// number | "length" | "push" | "pop" | ...  

👉 배열도 사실상 객체이므로, 숫자 인덱스와 배열 메서드들이 키로 잡힌다.

(4) 실무 응용

1. 안전한 프로퍼티 접근

    function getValue<T, K extends keyof T>(obj: T, key: K): T[K] {  
      return obj[key];  
    }  

2. 자동 필드 검사기

    type UserFields = keyof User;  
    // "id" | "name" | "email"  
   

3. & (교차 타입, Intersection Type)

(1) 기본 개념

• A & B는 A와 B를 모두 만족하는 타입이다.
• 객체 타입끼리 교차하면 속성이 병합된다.

    type A = { id: number };  
    type B = { name: string };  
    type AB = A & B;  
    // { id: number; name: string }  

  (2) 겹치는 키가 다르면?

  type A = { value: string };
  type B = { value: number };
  type AB = A & B;
  // { value: string & number } → never

👉 교차 타입에서 겹치는 키의 타입이 호환되지 않으면 never가 된다.

(3) 실무 응용

• 유틸리티 타입 합성

    type PartialBy<T, K extends keyof T> =  
      Omit<T, K> & Partial<Pick<T, K>>;  

• API 응답 타입 확장

    type Base = { id: string };  
    type WithTimestamp = { createdAt: Date };  
    type ApiResponse = Base & WithTimestamp;  
    // { id: string; createdAt: Date }  

4. 인덱스드 액세스 타입 vs 매핑 타입 문맥

(1) 인덱스드 액세스 타입

• 문법: T[K]
• 의미: 타입 T에서 키 K의 값 타입을 가져온다.

    type User = { id: number; name: string };  
    type IdType = User["id"]; // number  
    type Values = User[keyof User]; // number | string  

  👉 핵심: 값을 꺼내는 문법이다.

(2) 매핑 타입 문맥

• 문법: { [K in U]: ... }
• 의미: 유니언 U를 순회해서 새로운 객체 타입을 만든다.

    type Status = "idle" | "loading";  
    type Counters = { [K in Status]: number };  
    // { idle: number; loading: number }  

  👉 핵심: 키를 새로 만드는 문법이다.

(3) 키 리매핑(as)

• 매핑 타입 문맥에서만 사용할 수 있다.

    type Rename<T> = {  
      [K in keyof T as `new_${string & K}`]: T[K];  
    };  

  👉 인덱스드 액세스(T[keyof T])에서는 as를 쓸 수 없다.

(4) 정리

• T[K] → 값 꺼내기
• { [K in U]: ... } → 키 순회하여 객체 만들기
• as (키 리매핑) → 매핑 타입에서만 사용 가능

✨ Day 3 전체 정리

• 조건부 타입으로 타입 필터링
• Omit/Pick/Partial 조합으로 일부 키 optional 처리
• 매핑 타입과 Record로 상태 매핑
• Indexed Access + ValueOf로 API 응답 타입 추출
• 교차 타입(&)으로 유틸리티 합성
• K in vs keyof, 인덱스드 액세스 vs 매핑 타입 문맥, ?: vs | undefined 차이

👉 Day3 학습은 단순 문법을 넘어서, 실무 타입 설계 감각을 키우는 훈련이었다.

1. 콜백 함수란 무엇인가?
2. 콜백 기반 비동기 처리의 한계
3. Promise란 무엇인가?
4. Promise의 상태와 흐름
5. Promise의 생성 및 기본 사용법
6. Promise 체이닝: then, catch, finally
7. 주요 Promise 유틸 메서드들
8. async/await 문법
9. 콜백 기반 함수를 Promise로 변환하기
10. 실전 예제 및 정리

1. 콜백 함수란 무엇인가?

📌 개념 설명

콜백 함수(Callback Function)란 다른 함수의 인자로 전달되어 실행되는 함수를 말합니다. 자바스크립트에서는 일급 객체(First-class Object)로서 함수를 값처럼 전달할 수 있기 때문에, 콜백 패턴은 아주 일반적으로 사용됩니다.

✍️ 예시

function greet(name, callback) {
  console.log("안녕하세요, " + name);
  callback();
}

function sayBye() {
  console.log("안녕히 가세요!");
}

greet("동언", sayBye);

위 코드에서 sayBye 함수는 greet 함수의 콜백으로 전달되어 나중에 실행됩니다.

🔍 역할

• 로직의 흐름을 나중으로 미루고 싶을 때 (지연 실행)
• 이벤트 기반 프로그래밍에 필수적 (예: 클릭 이벤트 후 실행)
• 비동기 작업을 처리할 때 (파일 읽기, 서버 응답 처리 등)

🧠 주의할 점

• 콜백 지옥(Callback Hell)로 인해 코드 가독성이 떨어질 수 있음
• 에러 처리가 어렵고 중첩이 깊어짐

2. 콜백 기반 비동기 처리의 한계

📌 문제점 정리

콜백 함수는 간단한 비동기 흐름에서는 유용하지만, 여러 비동기 작업을 중첩해서 순차적으로 처리해야 할 경우 다음과 같은 문제들이 발생합니다.

😵 콜백 지옥 (Callback Hell)

readFile("user.json", (err, data) => {
  if (err) throw err;
  parseData(data, (err, result) => {
    if (err) throw err;
    fetchUser(result.id, (err, user) => {
      if (err) throw err;
      console.log(user);
    });
  });
});

• 중첩 구조로 인해 가독성↓ 유지보수↓
• 에러 처리 로직이 복잡하고 중복됨
• 흐름 제어(순차, 병렬 처리)가 어려움

💡 이러한 단점을 해결하기 위해 등장한 것이 바로 Promise입니다.

3. Promise란 무엇인가?

📌 개념 설명

Promise는 자바스크립트의 비동기 처리를 위한 객체입니다. 비동기 작업의 최종 성공 또는 실패를 나타내는 값을 미래 시점에 전달하겠다는 약속을 의미합니다.

✅ Promise 상태

• pending: 대기 중 (아직 결과가 없음)
• fulfilled: 작업 성공
• rejected: 작업 실패

const promise = new Promise((resolve, reject) => {
  // 비동기 로직
});

🤔 등장 배경

• 콜백 지옥 → 가독성 문제
• 순차적 흐름 처리 어려움
• 에러 처리 로직의 분산

🧪 예시 코드

function fetchData(): Promise<string> {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const success = true;
      if (success) {
        resolve("🎉 데이터 로드 성공");
      } else {
        reject(new Error("❌ 데이터 로드 실패"));
      }
    }, 2000);
  });
}

📈 실전 활용

• 서버 API 통신: fetch(), axios
• setTimeout/setInterval 대체
• Node.js 파일 처리 등

4. Promise의 상태와 흐름

🧱 세 가지 상태 & 설명

📈 상태 전이(transition)

• resolve(value) → fulfilled 상태로 전이
• reject(error) → rejected 상태로 전이
• 한 번 상태가 정해지면 절대 바뀌지 않음 (immutable)

const promise = new Promise((resolve, reject) => {
  resolve("성공");
  reject("실패"); // 무시됨
});

5. Promise의 생성 및 기본 사용법

const promise = new Promise((resolve, reject) => {
  // 비동기 작업
  setTimeout(() => {
    const ok = true;
    if (ok) resolve("작업 완료");
    else reject(new Error("에러 발생"));
  }, 1000);
});

• 📌 resolve(value) → 정상 결과 전달
• 📌 reject(error) → 에러 객체 전달

6. Promise 체이닝: then, catch, finally

Promise의 가장 큰 장점 중 하나는 체이닝(Chaining) 을 통해 여러 비동기 작업을 순차적으로 연결할 수 있다는 점입니다. then, catch then()메서드는 성공 결과를, catch()메서드는 실패 결과를 처리합니다. 이 메서드들은 새로운 Promise를 반환하므로 계속해서 연결할 수 있습니다.

fetchData()
  .then((data) => {
    console.log("성공", data);
  })
  .catch((err) => {
    console.error("실패", err.message);
  });

🛠 finally

finally()메서드는 Promise의 성공/실패 여부와 상관없이 무조건 한 번 실행됩니다. 주로 로딩 스피너 제거 등 마무리 작업에 사용됩니다.

fetchData()
  .finally(() => {
    console.log("작업 종료");
  });

7. 주요 Promise 유틸 메서드들

7.1 Promise.all

• 모든 Promise가 성공해야 결과 반환
• 하나라도 실패하면 전체가 reject

Promise.all([fetchA(), fetchB(), fetchC()])
  .then(([a, b, c]) => console.log(a, b, c))
  .catch(console.error);

7.2 Promise.race

• 가장 먼저 처리된 Promise의 결과 반환

Promise.race([fetchSlow(), fetchFast()])
  .then(console.log)
  .catch(console.error);

7.3 Promise.allSettled

• 성공/실패 상관없이 각 결과 개별 확인

Promise.allSettled([fetch1(), fetch2()])
  .then((results) =>
    results.forEach((res) =>
      res.status === "fulfilled"
        ? console.log("성공:", res.value)
        : console.error("실패:", res.reason)
    )
  );

7.4 Promise.any

• 가장 먼저 성공한 결과만 반환
• 전부 실패하면 AggregateError 반환

Promise.any([fail1(), fail2(), success()])
  .then(console.log)
  .catch((e) => console.error("모두 실패", e));

8. async/await

📌 개념 설명

async/await는 Promise를 동기 코드처럼 사용할 수 있게 해주는 문법입니다.

• async 함수는 항상 Promise를 반환합니다.
• await은 해당 Promise의 결과가 나올 때까지 기다립니다.

🧪 예시 코드

async function loadUserProfile() {
  try {
    const name = await fetchName(); // Promise<string>
    const age = await fetchAge();   // Promise<number>
    const job = await fetchJob();   // Promise<string>

    return { name, age, job };
  } catch (err) {
    console.error("에러:", err);
    throw err;
  }
}

✅ 장점

⚠️ 주의사항

• await는 반드시 async 함수 안에서 사용
• 병렬 호출 시에는 Promise.all() 사용이 더 효율적

9. 콜백 기반 함수를 Promise로 변환하기

기존 콜백 패턴을 Promise로 감싸는 예제:

function legacy(callback: (value: string) => void) {
  setTimeout(() => {
    callback("✅ 완료");
  }, 1000);
}

function wrapped(): Promise<string> {
  return new Promise((resolve) => {
    legacy((result) => {
      resolve(result);
    });
  });
}

🧠 util.promisify() (Node.js 내장 유틸)도 유사한 기능을 제공합니다.

10. 실전 예제 및 정리

async function getWeatherInfo() {
  try {
    const [temp, wind] = await Promise.all([
      fetchTemperature(),
      fetchWindSpeed(),
    ]);
    return { temp, wind };
  } catch (err) {
    console.error("날씨 정보를 불러오는데 실패했습니다.");
    throw err;
  }
}

정리

• 콜백 → Promise → async/await으로의 진화
• 각각의 방식은 상황에 따라 적절히 선택
• 병렬/순차 처리 유틸 메서드 적극 활용

keyof와 제네릭 제약

개념 설명

keyof T는 객체 타입 T의 모든 키를 유니언 타입으로 반환합니다. 예를 들어 keyof { name: string; age: number }는 "name" | "age"가 됩니다. 또한 제네릭을 사용할 때 T extends object처럼 타입의 범위를 제한해주면 타입 오류를 방지할 수 있습니다.

function getValue<T extends object, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

부가 설명

• keyof는 Record, Pick, Omit 등 다른 유틸리티 타입들과 자주 결합됩니다.
• 제네릭 제약을 통해 keyof의 사용 대상을 명확히 하여 예기치 않은 타입 추론을 방지할 수 있습니다.

Record<K, V>

개념 설명

Record<K, V>는 K를 키로, V를 값으로 갖는 객체 타입을 생성합니다.

type Role = "admin" | "user";
type RolePermissions = Record<Role, string[]>;

부가 설명

• 매핑 가능한 딕셔너리 형태를 만들 때 매우 유용합니다.
• 문자열 조합이 타입으로 제한되어야 할 때 활용하면 타입 안정성이 높아집니다.
• Tailwind 클래스, API 경로, 파일명 등에서 실무적으로 자주 쓰입니다.

Omit<T, K>

개념 설명

Omit<T, K>는 객체 타입 T에서 K에 해당하는 속성을 제거한 타입을 생성합니다.

type User = { id: number; password: string };
type PublicUser = Omit<User, "password">; // { id: number }

부가 설명

• 민감 정보를 제외한 타입 생성에 유용합니다.
• 내부적으로 Pick<T, Exclude<keyof T, K>>처럼 동작합니다.
• 따라서 T는 반드시 객체 타입이어야 하며, 유니언 타입에서는 동작하지 않습니다.

Exclude<T, U>

개념 설명

Exclude<T, U>는 유니언 타입 T에서 U에 해당하는 타입을 제외합니다.

type Role = "admin" | "user" | "guest";
type PublicRole = Exclude<Role, "admin">; // "user" | "guest"

부가 설명

• 유니언 타입 중 제외하고 싶은 타입이 있을 때 매우 유용합니다.
• 객체가 아닌 타입에서도 사용 가능하며, 유연하게 타입을 좁힐 수 있습니다.

Extract<T, U>

개념 설명

Extract<T, U>는 유니언 타입 T에서 U에 해당하는 타입만 추출합니다.

type Role = "admin" | "user" | "guest";
type Staff = Extract<Role, "admin" | "user">; // "admin" | "user"

부가 설명

• 유니언 타입에서 특정 값만 남기고 싶을 때 사용합니다.
• 조건 필터링에 가까운 역할을 하며, Exclude와 반대입니다.

조건부 타입과 infer

개념 설명

조건부 타입은 A extends B ? X : Y 형태로 타입 간 관계에 따라 결과를 분기시킵니다. infer 키워드를 사용하면 타입을 추론할 수 있습니다.

type ElementType<T> = T extends Array<infer U> ? U : T;

type A = ElementType<string[]>;  // string
type B = ElementType<boolean>;   // boolean

부가 설명

• infer는 ReturnType, Parameters 등 여러 내장 유틸리티 타입에서도 사용됩니다.
• 타입 연산 중간 결과를 임시로 추론해 다음 단계의 조건 분기 등에 활용할 수 있게 해줍니다.

템플릿 리터럴 타입

개념 설명

템플릿 리터럴 타입은 문자열 리터럴과 유니언 타입을 결합해 새로운 문자열 타입 조합을 생성할 수 있습니다.

type Size = "sm" | "md";
type Variant = "primary" | "secondary";
type ButtonClass = `btn-${Size}-${Variant}`;

부가 설명

• 허용된 문자열 조합만 가능하게 하여 런타임 오류를 줄입니다.
• 실무에서는 클래스명 제약, API 경로 제약, 자동 완성에 도움을 주는 패턴으로 자주 사용됩니다.

마무리

이번 학습을 통해 타입스크립트의 핵심 유틸리티 타입들과 그 동작 원리에 대해 이해하게 되었습니다. 단순히 문법을 외우는 것을 넘어, 타입 설계에 있어 어떤 유틸리티를 언제 사용해야 하는지에 대한 감각을 익힐 수 있었습니다.

특히 객체 타입과 유니언 타입을 다룰 때 사용하는 Pick, Omit, Extract, Exclude의 차이와 활용 방식, 조건부 타입과 infer를 통해 타입을 유연하게 조작하는 방법, 템플릿 리터럴 타입을 통한 문자열 패턴 제한은 앞으로 타입 안정성을 높이는 데 큰 역할을 할 것입니다.

타입은 문법이 아니라 설계입니다. 그리고 설계는 연습과 시행착오를 통해 단단해집니다.

📌 keyof와 typeof를 이용한 안전한 경로 추출

문제

const routes = {
  home: "/",
  users: "/users",
  settings: "/settings",
} as const;

type RouteName = keyof typeof routes;

function toPath(name: RouteName) {
  return routes[name];
}

// ✅ 통과
toPath("home");
toPath("users");

// ❌ 컴파일 에러 발생해야 함
toPath("login");
toPath("logout");

사용된 문법 설명

• typeof: 변수의 타입을 추론해 타입 시스템에서 사용 가능하게 만듦
• keyof: 객체 타입의 키를 유니온 타입으로 추출

📌 Record를 사용한 안전한 필드 매핑

문제

interface User {
  id: number;
  name: string;
  email: string;
  createdAt: string;
}

const userFieldLabels: Record<keyof User, string> = {
  id: 'User ID',
  name: 'Name',
  email: 'Email',
  createdAt: 'Created',
};

사용된 문법 설명

• Record<K, V>: K를 키로, V를 값으로 갖는 객체 타입 생성
• keyof T: 타입 T의 모든 키를 유니온 타입으로 추출

📌 Omit을 활용한 민감 정보 제거

문제

interface User {
  id: number;
  name: string;
  email: string;
  password: string;
  token: string;
}

type PublicUser = Omit<User, 'password' | 'token'>;

const safeUsers: PublicUser[] = [
  {
    id: 1,
    name: 'Alice',
    email: 'alice@email.com'
  },
  {
    id: 2,
    name: 'Bob',
    email: 'bob@email.com'
  },
];

사용된 문법 설명

• Omit<T, K>: 타입 T에서 속성 K를 제거한 타입 생성

📌 유니언 타입 분기와 never를 활용한 안전한 분기 처리

문제

type LinkProps = {
  variant: 'link';
  label: string;
  href: string;
  onClick?: never;
};

type ButtonProps = {
  variant: 'button';
  label: string;
  onClick: () => void;
  href?: never;
};

type Props = LinkProps | ButtonProps;

function Render(p: Props) {
  if (p.variant === 'link') {
    return `<a href="${p.href}">${p.label}</a>`;
  } else {
    return `<button>${p.label}</button>`;
  }
}

사용된 문법 설명

• 유니언 타입(Union Type): 여러 타입 중 하나의 타입을 가질 수 있음
• never: 절대 사용되어서는 안 되는 값 또는 타입을 나타냄
• 타입 좁히기(Narrowing): 조건문 등을 통해 유니언 타입을 구체적으로 좁히는 타입 보호 기법

📌 조건부 타입으로 API 응답 형태 제어하기

문제

interface ApiResponse<T> {
  data: T;
  meta: { total: number };
}

type FetchResult<T, Raw extends boolean> = Raw extends true ? ApiResponse<T> : T;

async function fetchData<T, Raw extends boolean>(
  url: string,
  opts: { raw: Raw }
): Promise<FetchResult<T, Raw>> {
  const response = {
    data: null as unknown as T,
    meta: { total: 0 },
  };

  return opts.raw ? response as FetchResult<T, Raw> : response.data as FetchResult<T, Raw>;
}

사용된 문법 설명

• 조건부 타입(Conditional Type): A extends B ? X : Y 형태로 타입 분기
• 제네릭 제약(Generic Constraint): Raw extends boolean 처럼 타입 조건을 제한

✅ 마무리

이번 학습에서는 단순히 문법을 외우는 것이 아니라, 문제를 풀고 타입 에러를 해결하는 과정을 통해 자연스럽게 고급 타입 문법에 익숙해질 수 있었습니다.

아직 배울 것이 많고 미숙한 점도 많지만, 조금씩 성장하고 있다는 감각을 놓지 않고 계속해서 기록을 이어가보려 합니다.

타입은 문법이 아니라 설계입니다.
그리고 설계는 연습과 시행착오를 통해 단단해집니다.

다음 학습 기록도 기대해주세요 🙌

저는 Myfit이라는 네이버 클라우드 해커톤 프로젝트를 진행하면서, 서버 없이 프론트엔드만 개발하는 환경이였습니다. 이 과정에서 네이버 클라우드의 클로바 AI API를 호출해야 했는데, CORS 에러가 발생했습니다.

2. CORS란 무엇인가

CORS 는 다른 출처에서 리소스를 공유할 때 발생하는 브라우저의 보안 메커니즘입니다. 여기서 출처는 아래의 세 가지 요소를 기준으로 정의됩니다.

• 프로토콜 (예: http, https)
• 도메인 (예: example.com)
• 포트 번호 (예: 3000)

동일 출처 정책(Same-Origin0Policy) 에 따라, 브라우저는 기본적으로 동일한 출처에서만 데이터를 요청할 수 있도록 제한합니다. 예를들어, http://localhost:3000에서 실행 중인데, API 요청을 https://api.example.com 으로 보낸다면, 이 요청은 다를 출처(Cross-Origin) 에 해당하므로 브라우저가 차단합니다.

CORS는 서버가 클라이언트 요청을 허용하도록 명시적으로 승인하는 방식으로 이 제한을 완화할 수 있도록 설계되었습니다. 이를 위해서 서버는 CORS 헤더를 추가하여 요청을 허용할 출처를 명시해야 합니다.

CORSD의 기본 동작 방식

CORS는 다음과 같은 방식으로 동작합니다.

1. 간단 요청: 요청 헤더가 단순한 경우, 서버는 Access-Control-Allow-Origin헤더를 통해 요청 출처를 허용할지 여부를 결정합니다.
2. Preflight 요청 : 특정 조건을 마족하는 요청은 서버와 미리 협상(Preflight) 과정을 거칩니다.

• 클라이언트는 OPTIONS 메서드로 서버에 요청을 보내 허용 가능한 메서드와 헤더를 확인합니다.
• 서버가 허용 응답을 반환하면 클라이언트가 실제 요청을 보냅니다.

3. CORS가 발생하는 이유

웹 브라우저는 사용자의 데이터를 보호하기 위해 동일 출처 정책을 적용합니다. 이 정책이 없다면 악의적인 사이트가 사용자의 세션 쿠키를 이용해 민감한 데이터를 탈취하거나, 권한이 없는 요청을 보낼 수 있습니다.

예를들어 현재 내가 실행하고 있는 React앱은 http://localhost:3000에서 실행중이지만 API는 https://api.example.com에서 호스팅되기 때문에 브라우저는 React 앱의 요청을 다른 출처로 간주하여 차단합니다.

4. Vercel Serverless Functions로 CORS 문제 해결하기

Vercel Serverless Functions는 클라이언트(React 앱)와 외부 API 서버 사이에서 프록시(proxy) 역할을 수행합니다. • 브라우저의 동일 출처 정책은 브라우저와 서버 간의 통신에만 적용됩니다. • 브라우저가 동일한 출처라고 판단하는 Vercel Serverless Functions에 요청을 보내면, 브라우저는 이를 차단하지 않습니다. • Serverless Function이 외부 API와 통신하고 결과를 React 앱으로 전달하는 방식으로 CORS 문제를 해결합니다.

프록시 서버의 흐름 예시

1.    React 앱은 https://my-app.vercel.app/api/data로 요청을 보냅니다.
2.    Vercel Serverless Function(/api/data)는 외부 API(https://api.example.com/data)로 요청을 보냅니다.
3.    외부 API에서 데이터를 받아온 후 Vercel Serverless Function이 이를 React 앱에 응답으로 전달합니다.

React 앱은 Vercel Serverless Functions를 동일 출처로 간주하므로, 브라우저는 CORS 문제 없이 요청과 응답을 처리할 수 있습니다.

추가로 Vercel Serverless Functions을 사용하면 같은 출처일텐데, 왜 Access-Control-Allow-Origin 설정을 하는지 gpt에게 물어봤는데

Vercel에 배포된 상태에서 같은 도메인에서 Serverless Function을 호출하면 CORS 설정이 필요 없지만 개발 서버에서 호출하는 경우 localhost:3000 에서 실행돼서 CORS 정책이 적용되기 때문이라고 한다.

myfit 프로젝트를 진행하며, 사용자 설문조사 화면을 제작했습니다. 예상보다 어려운 부분이 많았던 만큼, 그 과정을 기록으로 남기고자 이 글을 작성하게 되었습니다.

시작

가장 먼저 진행한 작업은 컴포넌트 분리였습니다. ProgressBar와 하나의 질문을 담는 Container를 각각 컴포넌트로 분리한 뒤, 질문 Container를 map 함수로 렌더링하고 ProgressBar와 함께 하나의 화면에 구성했습니다.

유의할 점

먼저 설문조사를 만들기 전에 고려해야 할 점들이 있었습니다. • 첫 번째 질문은 첫 질문과 그 다음 질문만 보여야 하고, 마지막 질문은 이전 질문과 마지막 질문만 보여야 합니다. (그 외의 질문들은 이전 질문과 현재 질문, 그리고 다음 질문이 보여야 함) • 각 질문 간의 이동은 별도의 버튼 없이, 질문 컨테이너를 클릭하여 이동하도록 해야 합니다. • 사용자의 점수를 totalScore 배열에 저장해야 합니다. • 현재 질문에서 점수를 체크하면 자동으로 다음 질문으로 넘어가야 합니다.

질문 Container 만들기

[1, 2, 3, 4, 5]로 구성된 배열을 map 함수로 렌더링하고, 각 숫자가 선택될 때 상위 컴포넌트로 선택된 값을 전달하도록 구현했습니다. 그리고 selectedValue라는 상태(state)를 생성하여, 각 숫자(value)가 선택되었을 때 해당 값이 selectedValue와 일치하면 UI에 파란색으로 표시되도록 구현했습니다.

질문 Container 렌더링

이 부분은 몇 가지 제약사항 때문에 다소 복잡했습니다. 우선, 사전에 정의된 유의사항에 따라 첫 번째 질문과 마지막 질문은 각각 두 개씩 표시해야 했습니다. 이를 해결하기 위해 visibleItems라는 변수를 만들어 현재 렌더링할 질문 Container를 제어하도록 했습니다. 또한, 현재 질문이 몇 번째인지 확인하기 위해 currentIndex라는 상태(state)를 생성하여 상태 관리를 했으며, visibleItems는 아래의 함수로 결정되도록 구현했습니다.

질문간 이동

현재 질문에서 점수를 체크한 후 다음 질문으로 넘어가는 함수와, 질문 Container를 클릭하여 이동하는 함수를 분리했습니다. 질문 Container 클릭 시 이동하는 함수는 다음과 같습니다.

이슈

하지만 여기서 또 다른 문제가 발생했습니다. 기존에는 질문 Container에서 선택된 value 값을 상위 컴포넌트로 전달하여 totalScore 배열의 currentIndex에 추가하는 방식으로 구현했습니다. 그러나 질문 Container의 selectedValue 상태(state)를 초기값으로 null로 설정한 탓에 문제가 발생했습니다. 선택 당시에는 문제가 없었지만, 다다음 질문으로 이동했다가 다시 이전 질문으로 돌아올 경우 상태가 초기화되어 null 값이 적용되었고, 이로 인해 UI 상에서 선택된 항목이 표시되지 않는 현상이 나타났습니다.

이를 해결하기 위해 totalScore 배열을 처음부터 null로 초기화된 배열로 설정했습니다. 이후 currentScore라는 prop을 통해 totalScore[index] 값을 질문 Container로 내려주고, 이를 selectedValue 상태의 초기값으로 설정하여 문제를 해결했습니다.

이슈

또 다른 이슈는 설문조사 화면에서 질문 간의 이동 방식이 버튼 없이, 다음 질문 또는 이전 질문을 클릭하면 이동하도록 구현된 점이었습니다. 그런데 이동 중에 currentIndex와 다른 질문 Container의 숫자를 클릭하면 해당 값이 변경되는 문제가 발생했습니다.

이 문제를 해결하기 위해 disabled 속성을 활용했습니다. currentIndex와 질문 Container의 index가 일치하지 않는 경우, 해당 질문 Container를 비활성화(disabled) 상태로 설정하여 잘못된 값 변경을 방지했습니다.

진행도 측정

ProgressBar에서 진행도를 측정할 때, totalScore 배열에서 null 값의 개수를 파악하여 진행도를 계산했습니다.

끝으로

설문조사 화면 구현 과정에서 겪었던 여러 가지 문제와 그 해결 방안을 다뤄보았습니다. 각 질문의 이동 방식과 점수 선택, 그리고 UI 상태 관리에서 발생한 여러 제약을 고려하여 기능을 구현하는 과정이었습니다.

특히, 질문 간 이동과 점수 체크의 흐름을 유연하게 처리하기 위해 여러 가지 조건을 추가하고, 상태 관리를 통해 일관성 있는 사용자 경험을 제공하려 노력했습니다.

앞으로도 더 나은 코드를 작성하기 위해 계속해서 고민하고 개선해 나가겠습니다.

읽어주셔서 감사합니다!

기존 달리기 응원의 경우 이모지 모달이 늦게 렌더링 되어 어색한 모습이였다.

해결 과정

해당 이슈의 원인은 이모지 모달 높이 값을 빨리 구하지 못해서 였다. 이모지 모달의 높이는 기기 높이 - 키보드 높이 - textinput의 높이로 이루어져있는데 이모지 모달의 높이를 구하는 과정에서 키보드 높이를 좀 더 빨리 구한다면 해결할 수 있다고 생각했다.

Keyboard.addListener(
      'keyboardWillShow',
      onKeyboardDidShow,
    );

기존 keyboardDidShow 이벤트에서 keyboardWillShow로 변경 하니 한층 애니메이션이 빨라졌다.

추가 문제

이모지 모달을 빨리 생성하는데에는 성공했지만, 모달의 검은 배경이 같이 올라가 보이는 게 상당히 어색해보였다. 해당 부분을 해결하기 위해 이모지와 모달 뒷 배경을 animation 으로 생성해서 어색함을 제거 하려고 했다.

useEffect(() => {
    Animated.timing(opacityAnim, { //모달 뒷 배경 애니메이션
      toValue: 0.4,
      duration: 600,
      useNativeDriver: true,
    }).start();

    Animated.timing(emojiScaleAnim, { //이모지 애니메이션
      toValue: 1,
      duration: 400,
      useNativeDriver: true,
    }).start();

    return () => {
      Animated.timing(opacityAnim, {
        toValue: 0,
        duration: 400,
        useNativeDriver: true,
      }).start();

      Animated.timing(emojiScaleAnim, {
        toValue: 1,
        duration: 500,
        useNativeDriver: true,
      }).start();
    };
  }, [opacityAnim, emojiScaleAnim]);

결과물

이전에 진행했던 프로젝트를 회고하면서, 발생했던 트러블슈팅을 뒤늦게나마 정리하는 글입니다.

이슈 배경

Input 컴포넌트에서 검색어를 입력하면 InputResult 컴포넌트에서 받아온 data를 자동완성 해서 보여줍니다. 이때 Input 컴포넌트에서 방향키를 통해 InputResult를 선택할 수 있습니다. 방향키를 통해 선택하는 과정에서 한국어를 입력하고 방향키를 누르면 이벤트가 2번 발생하는 에러가 발생합니다. "테"를 검색하면 [개발 필터링 테스트, 쇼핑 필터링 테스트, 코딩 필터링 테스트...]가 나옵니다. 이때 아래 방향키를 누르면 "코딩 필터링 테스트"가 선택되고 콘솔에는 ArrowDown이 2번 찍혔습니다.

이슈 원인 찾기

영어를 입력했을 때는 위와 같은 에러가 발생하지 않았고, 한국어를 입력했을 때만 발생하는 걸 발견하여 korean input keydown devent twice 검색 키워드를 통해 검색하였습니다. 저와 같은 에러가 발생하는 깃헙 이슈를 발견하였고, 해당 이슈를 해결하는 방법을 찾아 적용하였습니다. 요약하면 IME는 다양한 언어를 브라우저에서 지원하도록 변환시켜주는 어플리케이션인데, IME 과정에서 keydown 이벤트가 발생하면 OS와 브라우저 둘 다 keydown 이벤트를 처리하기 때문에 중복 이벤트가 발생하는 것이었습니다.

해결과정

첫 번째 시도

• 깃헙에 있는 예시 코드를 적용했습니다.
  • keyCode는 더 이상 사용되지 않기 때문에 isComposing만 사용했습니다.

const handleKeyDown = (e: React.KeyboardEvent<HTMLInputElement>) => {
    if (e.isComposing) {
      return;
    }
        /* ... */
};

• 하지만 React에는 iSComposing을 제공하지 않기 때문에 에러가 발생합니다.

두 번째 시도

• 현재 프로젝트에선 Next.js와 TypeScript를 사용하고 있기 때문에 저와 같은 환경인 블로그를 참고하여 코드를 수정했습니다.
• 하지만 KeyboardEvent를 import하는 과정에서 에러가 발생하여 레거시 코드인 keyCode를 사용하여 임시로 해결하였습니다.
  • composition 중일 때는 keyCode로 229를 반환합니다.

const handleKeyDown = (e: React.KeyboardEvent<HTMLInputElement>) => {
    if (e.keyCode === 229) {
      return;
    }
        /* ... */
};

• 참고
  • 깃헙 이슈: https://github.com/vuejs/vue/issues/10277
  • 블로그: https://velog.io/@dosomething/React-한글-입력시-keydown-이벤트-중복-발생-현상

Parallel Routes 와 Intercepting Routes 를 사용해 Modal 만들기

이전에 학습한 Parallel Routes 와 Intercepting Routes 를 사용해서 Modal을 만들수 있다고 문서에 작성돼있어서 직접 한번 만들어 보았다.

시작하기에 앞서, 간단히 요약하자면 Parallel Routes 는 한 화면에 두개의 페이지를 띄우는 것이고, Intercepting Routes 는 말 그대로 route를 인터셉트 하는 것 이다.

참고로 Intercepting Routes 는 클라이언트 컴포넌트에서만 적용이 된다

(설명의 편의를 위해 /authflow를 홈 화면이라 표현하겠습니다.)

1. /authflow에서 버튼 클릭을 통해 /authflow/login 으로 접속하면 /authflow/login/page.tsx 가 실행되지 않고 authflow/(.)login/page.tsx가 실행을 가로채 간다.

2. 그런데 실행을 가로챈 화면은 홈 화면에서 Parallel Routes가 구현되어 있으므로 layout의 children 이 아닌 modal에서 실행되며 그 결과 브라우저의 주소가 바뀌지만 홈 화면과 동시에 표시된다.

3. 가로채기 당한 authflow/login/page.tsx는 새로고침 하거나 주소 창에 authflow/login 을 직접 입력하여 접근하면 실행된다. 즉, 새로고침이나 주소를 타이핑하여 직접 접근 하는 경우에는 Intercepting Routes가 발생하지 않는다. 따라서

authflow/(.)login/page.tsx 와 동일하게 작업하면 된다.

실행본

더불어 이렇게 만든 모달은 Next.js에서는 다음과 같은 문제를 해결할 수 있다고 한다. • URL을 통해 모달 콘텐츠를 공유 가능하게 한다. • 페이지를 새로 고침해도 모달을 닫지 않고 컨텍스트를 유지한다. • 이전으로 이동 시 이전 라우트로 가지 않고 모달을 닫는다. • 앞으로 이동 시 모달을 다시 연다.

Next.js 공식문서를 번역하여 기록해둔 내용입니다.

Intercepting routes

Intercepting routes는 현재 레이아웃 내에서 애플리케이션의 다른 부분의 라우트를 로드할 수 있게 한다. 이러한 라우팅 패러다임은 사용자가 다른 컨텍스트로 전환하지 않고도 라우트의 내용을 표시하고자 할 때 유용하다.

예를 들어, 피드에서 사진을 클릭할 때, 사진을 모달로 표시하여 피드 위에 오버레이할 수 있다. 이 경우, Next.js는 /photo/123 라우트를 가로채서 URL을 마스킹하고 /feed 위에 오버레이한다.

그러나 공유 가능한 URL을 클릭하거나 페이지를 새로 고침하여 사진으로 이동할 때는 전체 사진 페이지가 렌더링되어야 한다. 이 경우에는 Intercepting routes가 발생하지 않는다.

-> 그래서 같은 경로의 페이지가 하나 더 있어야 한다.

Convention

Intercepting routes는 세그먼트를 위한 상대 경로 규칙과 비슷한 (..) 규칙으로 정의할 수 있다.

다음과 같이 사용할 수 있다.

•    (.)는 같은 레벨의 세그먼트를 매칭한다.
•    (..)는 한 레벨 위의 세그먼트를 매칭한다.
•    (..)(..)는 두 레벨 위의 세그먼트를 매칭한다.
•    (…)는 루트 앱 디렉토리에서 세그먼트를 매칭한다.

예를 들어, feed 세그먼트 내에서 photo 세그먼트를 가로채려면 (..)photo 디렉토리를 생성할 수 있다.

(..) 규칙은 파일 시스템이 아니라 라우트 세그먼트를 기반으로 한다는 점에 유의해야 한다.

-> 디렉토리 구조가 아닌 브라우저 주소창 ../../ 단위로(세그먼트) 레벨을 측정한다는 것을 유의

사용예제: 모달

Intercepting Routes는 Parallel Routes와 함께 사용하여 모달을 만들 수 있다. 이를 통해 모달을 구축할 때 흔히 발생하는 문제를 해결할 수 있다. 예를 들어:

•    URL을 통해 모달 콘텐츠를 공유 가능하게 한다.
•    페이지를 새로 고침해도 모달을 닫지 않고 컨텍스트를 유지한다.
•    이전으로 이동 시 이전 라우트로 가지 않고 모달을 닫는다.
•    앞으로 이동 시 모달을 다시 연다.

다음과 같은 UI 패턴을 고려할 수 있다. 사용자가 클라이언트 사이드 네비게이션을 통해 갤러리에서 사진 모달을 열거나, 공유 가능한 URL을 통해 직접 사진 페이지로 이동할 수 있다.

위 예시에서, @modal이 세그먼트가 아니라 슬롯이므로 photo 세그먼트로의 경로는 (..) 매처를 사용할 수 있다. 이는 파일 시스템 상으로는 두 레벨 위에 있더라도, photo 라우트는 한 세그먼트 레벨 위에만 있는 것을 의미한다.

사용하기 좋은 예제

• 상단 네비게이션 바에서 로그인 모달을 열면서 전용 /login 페이지도 가질때
• 측면 모달에서 쇼핑 카트를 여는 경우 등

출처: Next.js 공식문서

Next.js 공식문서를 번역하여 기록해둔 내용입니다.

Route Groups

앱 디렉토리에서는 중첩된 폴더가 일반적으로 URL 경로에 매핑된다. 하지만 폴더를 Route Group으로 표시하면 해당 폴더가 경로의 URL 경로에 포함되지 않도록 할 수 있다.

이를 통해 URL 경로 구조에 영향을 주지 않으면서 경로 세그먼트와 프로젝트 파일을 논리적으로 그룹화할 수 있다.

Route Groups는 다음과 같은 경우에 유용하다.

사이트 섹션, 의도, 팀별로 경로를 그룹화할 때

예시: 사이트의 마케팅 페이지와 쇼핑 페이지를 별도로 그룹화하기

app/
|-- (marketing)/
|   |-- layout.js
|   |-- home/
|   |   |-- page.js
|   |-- about/
|       |-- page.js
|-- (shop)/
    |-- layout.js
    |-- products/
    |   |-- page.js
    |-- cart/
        |-- page.js

(marketing) 그룹에는 마케팅 관련 페이지 (home, about)가 포함된다.
(shop) 그룹에는 쇼핑 관련 페이지 (products, cart)가 포함된다.
이렇게 그룹화하면 관련된 파일들을 논리적으로 그룹화하여 관리할 수 있다.

동일한 경로 세그먼트 레벨에서 중첩된 레이아웃을 활성화할 때

예시: 인증 관련 페이지와 애플리케이션 관련 페이지를 분리된 레이아웃으로 관리하기

app/
|-- (auth)/
|   |-- layout.js
|   |-- login/
|   |   |-- page.js
|   |-- register/
|       |-- page.js
|-- (app)/
    |-- layout.js
    |-- dashboard/
    |   |-- page.js
    |-- settings/
        |-- page.js

(auth) 그룹은 인증 관련 경로 (login, register)를 포함하며, 인증 레이아웃 (layout.js)을 사용한다.
(app) 그룹은 애플리케이션 관련 경로 (dashboard, settings)를 포함하며, 애플리케이션 레이아웃 (layout.js)을 사용한다.
동일한 경로 세그먼트 레벨에서 각기 다른 레이아웃을 사용하여, 서로 다른 사용자 경험을 제공할 수 있다.

동일한 세그먼트에서 여러 중첩된 레이아웃을 생성할 때, 여러 루트 레이아웃 포함

예시: 블로그와 쇼핑 섹션을 독립적으로 관리하기

app/
|-- (blog)/
|   |-- layout.js
|   |-- posts/
|   |   |-- page.js
|   |-- authors/
|       |-- page.js
|-- (shop)/
    |-- layout.js
    |-- products/
    |   |-- page.js
    |-- cart/
        |-- page.js

(blog) 그룹은 블로그 관련 경로 (posts, authors)를 포함하며, 블로그 레이아웃 (layout.js)을 사용한다.
(shop) 그룹은 쇼핑 관련 경로 (products, cart)를 포함하며, 쇼핑 레이아웃 (layout.js)을 사용한다.
각각의 루트 레이아웃이 독립적으로 존재하며, 각 섹션에 대해 완전히 다른 UI나 사용자 경험을 제공한다.

공통 세그먼트의 일부 경로에 레이아웃을 추가할 때

예시: 특정 경로에만 공통 레이아웃을 적용하기

app/
|-- (common)/
|   |-- layout.js
|   |-- account/
|   |   |-- page.js
|   |-- cart/
|       |-- page.js
|-- checkout/
    |-- page.js

(common) 그룹에는 공통 레이아웃을 사용하는 경로 (account, cart)가 포함된다.
checkout 경로는 공통 레이아웃을 사용하지 않으며, 별도의 레이아웃을 사용할 수 있다.
이를 통해 특정 경로에만 공통 레이아웃을 적용하고, 다른 경로는 독립적으로 관리할 수 있다.

Convention

폴더 이름을 괄호로 감싸서 Route Group을 생성할 수 있습니다: (folderName)

Examples

URL 경로에 영향을 주지 않고 경로를 조직화하기 URL에 영향을 주지 않고 경로를 조직화하려면 관련 경로를 함께 유지하기 위해 그룹을 만들수 있다. 괄호 안의 폴더는 URL에서 생략됩니다. (예(marketing))

(marketing) 및 (shop) 내부의 경로가 동일한 URL 계층 구조를 공유하더라도 해당 폴더에 layout.js 파일을 추가하여 각 그룹에 대해 다른 레이아웃을 만들 수 있다.

특정 세그먼트를 레이아웃에 선택하기

특정 경로를 레이아웃에 선택하려면 새 경로 그룹을 만들고 (예: (shop)) 동일한 레이아웃을 공유하는 경로를 그룹으로 이동하십시오 (예: account와 cart). 그룹 외부의 경로는 레이아웃을 공유하지 않는다 (예: checkout).

여러 루트 레이아웃 생성하기

여러 루트 레이아웃을 생성하려면 최상위 layout.js 파일을 제거하고 각 경로 그룹 내에 layout.js 파일을 추가해야한다. 완전히 다른 UI나 경험을 가진 섹션으로 애플리케이션을 분할할 때 유용하다. 각 루트 레이아웃에는 <html> 및 <body> 태그가 추가되어야 한다.

💡 알아두면 좋은 점

• 경로 그룹의 이름은 조직화를 위한 것 외에는 특별한 의미가 없다. URL 경로에 영향을 주지 않는다.
• 경로 그룹을 포함하는 경로는 다른 경로와 동일한 URL 경로로 해결되어서는 안된다. 예를 들어, 경로 그룹이 URL 구조에 영향을 주지 않기 때문에 (marketing)/about/page.js와 (shop)/about/page.js는 모두 /about으로 해석되어 오류를 발생시킬 수 있다.
• 최상위 layout.js 파일 없이 여러 루트 레이아웃을 사용하는 경우, 홈 page.js 파일은 라우트 그룹 중 하나에 정의되어야 한다. 예를 들어: app/(marketing)/page.js.
• 여러 루트 레이아웃 간의 탐색은 클라이언트 측 네비게이션과 달리 전체 페이지 로드를 발생시킨다. 예를 들어, app/(shop)/layout.js를 사용하는 /cart에서 app/(marketing)/layout.js를 사용하는 /blog로 이동하면 전체 페이지 로드가 발생한다. 이는 여러 루트 레이아웃에만 적용된다.

출처: Next.js 공식문서

Next.js 공식문서를 번역하여 기록해둔 내용입니다.

Parallel Routes

패러렐 라우트는 동시에 또는 조건부로 동일한 레이아웃 내에서 하나 이상의 페이지를 렌더링할 수 있게 한다. 이는 대시보드나 소셜 사이트의 피드와 같이 매우 동적인 앱 섹션에 유용하다.

Slots

패러렐 라우트는 이름이 지정된 슬롯(named slots)을 사용하여 생성된다. 슬롯은 @폴더 형식으로 정의된다. 예를 들어, 다음 파일 구조는 @analytics와 @team 두 개의 슬롯을 정의한다.

슬롯은 공유된 부모 레이아웃에 props로 전달된다. 위 예시에서는 app/layout.js 파일의 컴포넌트가 이제 @analytics와 @team 슬롯 props를 받아들이고, children props와 함께 병렬로 렌더링할 수 있다.

export default function Layout({
  children,
  team,
  analytics,
}: {
  children: React.ReactNode
  analytics: React.ReactNode
  team: React.ReactNode
}) {
  return (
    <>
      {children}
      {team}
      {analytics}
    </>
  )
}

그러나 슬롯은 라우트 세그먼트가 아니며 URL 구조에 영향을 미치지 않는다. 예를 들어, /@analytics/views 경로의 경우, URL은 /views가 됩니다. 왜냐하면 @analytics는 슬롯이기 때문이다.

💡 알아 두면 좋은 점.

• children prop은 명시적으로 슬롯이며 폴더에 매핑될 필요가 없다. 이는 app/page.js가 app/@children/page.js와 동등하다는 것을 의미한다.

default.js

기본적으로, 매칭되지 않은 슬롯에 대한 폴백을 렌더링하려면 default.js 파일을 정의할 수 있다. 이 경우 초기 로드 또는 전체 페이지 새로 고침 시 유용하다.

위와 같이 @team 슬롯에는 /settings 페이지가 있지만, @analytics 슬롯에는 없는 예시에서

/settings로 이동할 때, @team 슬롯은 /settings 페이지를 렌더링하며 @analytics 슬롯의 현재 활성 페이지를 유지한다.

새로 고침 시, Next.js는 @analytics에 대해 default.js를 렌더링한다. 만약 default.js가 존재하지 않으면 404 페이지가 대신 렌더링된다.

추가로, children은 암시적인 슬롯이기 때문에 Next.js가 부모 페이지의 활성 상태를 복구할 수 없을 때 children에 대한 폴백을 렌더링하기 위해 default.js 파일을 생성해야 한다.

정리하자면, 패러렐 라우트를 사용할 때, @폴더에서 기본적으로 보여줄 것이 없을 때 page.tsx 대신 사용한다. page.tsx를 사용해도 무방하지만, 특별히 보여줄 것이 없다면 default.tsx를 사용하여 null을 return한다.

useSelectedLayoutSement

useSelectedLayoutSegment와 useSelectedLayoutSegments는 모두 parallelRoutesKey 매개변수를 받아 슬롯 내에서 활성 라우트 세그먼트를 읽을 수 있게 한다.

'use client'

import { useSelectedLayoutSegment } from 'next/navigation'

export default function Layout({ auth }: { auth: React.ReactNode }) {
  const loginSegment = useSelectedLayoutSegment('auth')
  // ...
}

사용자가 app/@auth/login (또는 URL 바에서 /login)으로 이동할 때, loginSegment는 문자열 “login”과 같아진다.

출처: Next.js 공식문서

Next.js 공식문서를 번역하여 기록해둔 내용입니다.

Layout

레이아웃은 여러 경로 사이에서 공유되는 UI이다. 레이아웃은 내비게이션 시 상태를 보존하고 상호작용이 가능하며, 다시 렌더링되지 않는다. 또한, 레이아웃은 중첩될 수도 있다.

레이아웃을 정의하려면 layout.js 파일에서 React 컴포넌트를 기본으로 내보내면 된다. 이 컴포넌트는 렌더링 시 자식 레이아웃(존재하는 경우) 또는 페이지로 채워질 children prop을 받아야 한다.

예를 들어, 레이아웃은 /dashboard 및 /dashboard/settings 페이지와 공유된다.

app/
└── dashboard/
    ├── layout.js
    ├── page.js
    └── settings/
        └── page.js

이렇게 하면 /dashboard와 /dashboard/settings 페이지가 이 레이아웃을 공유하게 된다.

Root Layout

루트 레이아웃은 앱 디렉토리의 최상위 수준에서 정의되며 모든 경로에 적용된다. 이 레이아웃은 필수적이며, 서버에 반환되는 초기 HTML을 수정할 수 있도록 <html> 과 <body> 태그를 포함해야 한다.

Nested Layout

기본적으로 폴더 계층 구조 내의 레이아웃은 중첩된다. 이는 레이아웃이 자식 레이아웃을 자신의 children prop을 통해 감싸는 것을 의미한다. 특정 경로 세그먼트(폴더) 내에 layout.js 파일을 추가함으로써 레이아웃을 중첩할 수 있다.

app/
├── layout.js
└── dashboard/
    ├── layout.js
    └── page.js

세그먼트 란?

세그먼트(segment)란 URL 경로에서 경로를 구성하는 각 부분을 말한다. 일반적으로 경로는 여러 세그먼트로 나뉘어지며, 각 세그먼트는 슬래시(/)로 구분된다.

예를 들어, 다음 URL에서 세그먼트는 다음과 같다 https://example.com/products/electronics/laptops

•    첫 번째 세그먼트: /products
•    두 번째 세그먼트: /electronics
•    세 번째 세그먼트: /laptops

💡 알아두면 좋은 정보.

• 레이아웃으로는 .js, .jsx 또는 .tsx 파일 확장자를 사용할 수 있다.
• 루트 레이아웃에만 <html> 및 <body> 태그를 포함할 수 있다.
• 같은 폴더에 layout.js와 page.js 파일이 정의되어 있으면, 레이아웃은 페이지를 감싼다.
• 기본적으로 레이아웃은 서버 컴포넌트입니다만, 클라이언트 컴포넌트로 설정할 수도 있다.
• 부모 레이아웃과 자식 사이에서 데이터를 전달하는 것은 불가능하다. 그러나 같은 데이터를 경로에서 여러 번 가져오면 React가 자동으로 중복 요청을 제거하며 성능에 영향을 미치지 않는다.
• 레이아웃은 자신 아래의 경로 세그먼트에는 접근할 수 없다. 모든 경로 세그먼트에 접근하려면 클라이언트 컴포넌트 내에서 useSelectedLayoutSegment 또는 useSelectedLayoutSegments를 사용할 수 있다.
• Route Groups를 사용하여 특정 경로 세그먼트를 공유된 레이아웃에서 선택적으로 제외하거나 포함할 수 있다.

출처: Next.js 공식문서

curl 이란?

학습 배경

프로젝트를 진행하던 중 API가 정상적으로 작동하지 않는 문제를 발견했습니다. 이 상황을 백엔드 담당자에게 전달하자, 담당자는 재현 가능한 요청을 보내달라고 요청했습니다. 당시에는 '재현 가능한 요청'이 무엇을 의미하는지 몰랐기 때문에 단순히 실패하는 요청을 다시 보냈습니다.

백엔드 담당자는 curl 형식으로 재현 가능한 요청을 보내달라고 했고, 이때 처음으로 curl이라는 도구에 대해 알게 되었습니다.

이슈를 해결한 후, curl에 대해 더 깊이 학습해야겠다는 필요성을 느끼게 되었습니다.

그래서 curl이 뭔데?

curl 이란 client URL의 줄임말로 다양한 통신 프로토콜을 이용하여 데이터를 전송하기 위한 라이브러리와 명령 줄 도구를 제공하는 컴퓨터 소프트웨어 프로젝트이다. 주로 웹에서 데이터를 가져오거나 업로드할 때 사용됩니다.

curl은 다양한 프로토콜(HTTP, HTTPS, FTP, FTPS, SCP, SFTP, SMTP, POP3, IMAP)을 지원하며, 스크립트나 명령줄에서 HTTP 요청을 보내고 응답을 확인하는 데 매우 유용합니다.

기본 사용법

curl의 기본 구문은 다음과 같습니다.

curl [options] [URL]

주요 옵션들

• -X : HTTP 메서드를 지정합니다. 예: GET, POST, PUT, DELETE.
• -H : 요청 헤더를 설정합니다.
• -d : 요청 본문을 설정합니다. 주로 POST 요청에 사용됩니다.
• -i : 응답의 헤더를 포함합니다.
• -o : 응답을 파일로 저장합니다.
• -u : 사용자 인증을 설정합니다. 예: username:password.

HTTP,HTTPS 에서의 사용 예제

1. GET 요청

   curl https://api.example.com/data

2. POST 요청

   curl -X POST https://api.example.com/data -d '{"key":"value"}' -H "Content-Type: application/json"

3. 헤더 포함

   curl https://api.example.com/data -H "Authorization: Bearer your_token_here"

4. 파일 다운로드

   curl -o filename.zip https://example.com/file.zip

5. 응답 헤더 포함

   curl -i https://api.example.com/data

6. 사용자 인증

   curl -u username:password https://api.example.com/protected

예를 들어 로그인 요청을 재현하려면

curl -X POST https://api.example.com/login \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer exampletoken123" \
  -d '{"username":"user@example.com","password":"password123"}'

이 명령은 다음을 포함합니다

• HTTP 메서드: POST
• URL: https://api.example.com/login
• 헤더: Content-Type과 Authorization 헤더
• 본문 데이터: JSON 형식의 사용자명과 비밀번호

이슈 배경

달리기 앱에서 타이머를 구현하고 사용하던 중 장시간 타이머를 사용시 실제시간과 타이머 표시시간 사이에 오차가 발생하는 것을 알게 되었습니다.

이슈 원인 찾기

타이머 정확성 관련해서 구글링을 했고 javascript의 이벤트 루프와 taskqueue 그리고 promise와 같은 비동기 처리 과정에서 발생하는 지연 문제임을 파악했습니다.

🔍 이벤트 루프와 마이크로 태스크 큐, 매크로 태스크 큐 란?

이벤트 루프(Event Loop)

• 이벤트 루프는 자바스크립트의 비동기 처리 메커니즘의 핵심 개념입니다.
• 이벤트 루프는 콜 스택, 웹 API, 태스크 큐(microtask queue, macrotask queue)를 관리하며, 이들 간의 상호작용을 통해 자바스크립트 코드를 실행합니다.
• 이벤트 루프는 끊임없이 실행 중이며, 콜 스택이 비어있을 때마다 태스크 큐에서 다음 작업을 가져와 실행합니다.

microtask queue

• microtask queue는 Promise의 then/catch/finally 콜백, MutationObserver 등의 마이크로태스크를 관리하는 큐입니다.
• 마이크로태스크는 매우 빠르게 실행되며, 콜 스택이 비어있을 때마다 microtask queue에서 작업을 가져와 실행합니다.
• microtask queue의 작업은 macrotask queue보다 우선순위가 높습니다.

macrotask queue

• macrotask queue는 setTimeout, setInterval, I/O 작업, 이벤트 핸들러 등의 매크로태스크를 관리하는 큐입니다.
• 매크로태스크는 상대적으로 오래 실행되며, 콜 스택이 비어있고 microtask queue가 비어있을 때 macrotask queue에서 작업을 가져와 실행합니다.

작동 순서

1. 콜 스택에 함수가 쌓입니다.
2. 함수 내에서 비동기 작업(setTimeout, Promise 등)이 발생하면 해당 작업은 웹 API로 전달됩니다.
3. 웹 API에서 작업이 완료되면 해당 작업은 태스크 큐(microtask queue 또는 macrotask queue)로 전달됩니다.
4. 콜 스택이 비어있을 때, 이벤트 루프는 태스크 큐를 확인합니다.
5. 먼저 microtask queue에서 작업을 가져와 실행합니다.
6. microtask queue가 비어있으면 macrotask queue에서 작업을 가져와 실행합니다.
7. 이 과정을 반복하며 자바스크립트 코드를 실행합니다.

이슈 해결 과정

(before) (after)

문제 해결을 위해 setInterval의 각 호출 시 setTime을 통한 증가 방식에서 벗어나, 각 호출마다 시작 시간과 현재 시간을 비교하여 시간을 설정하는 방식으로 변경했고, 이를 통해 시간의 정확성을 향상 시켰습니다.

또한 더욱 정확한 시간 계산을 위해 호출 간격을 500ms로 줄였습니다. 하지만, 이 과정에서 useState 로 상태를 관리하게 되면 렌더링이 과도하게 발생하여 성능 저하의 우려가 있었습니다.

따라서 변수를 생성하여 실제 시간 값은 렌더링에 영향을 주지 않는 방식으로 하되, 1초이상 차이 날 경우에만 useState 를 통해 상태를 업데이트하고 화면에 반영하도록 하여 성능을 고려했습니다.

참고

• 이벤트 루프와 매크로,마이크로 태스크 큐

문제링크: https://www.acmicpc.net/problem/29792

문제해결 아이디어

• 각각의 캐릭터당 최대 보상으로 보스를 잡는 dp를 생성하고 최대 보상값을 res에 저장
• res를 내림차순으로 정렬해서 m번째 캐릭터까지 합하여 정답출력
• 각각의 캐릭터 별로 보스를 잡는 데 걸리는 시간을 구한다.
• dp는 보스 종류, 15분(900초)로 구성한다.

소스코드

import sys
input = sys.stdin.readline

n, m, k = map(int, input().split())
# 캐릭터 개수, 하루에 사용할 캐릭터 수, 보스 종류

damage = [] # 캐릭터 데미지

for _ in range(n):
    damage.append(int(input()))

boss = [] # 체력, 보상

res = []

for _ in range(k):
    boss.append(list(map(int, input().split())))

for i in range(n):
    time = [0]
    for hp, worth in boss:
        h = hp // damage[i]
        if hp % damage[i]:
            h += 1

        time.append(h)

    dp = [[0] * (901) for _ in range(k+1)]

    for a in range(1, k+1):
        for b in range(1, 901):
            if b >= time[a]:
                dp[a][b] = max(dp[a-1][b], boss[a-1][1] + dp[a-1][b-time[a]]) # 현재보스를 잡지 않을 경우, 현재 보스를 잡을 경우(현재 보스 보상 + 걸리는 시간을 뺀 이전 보상 최대값)
            else:
                dp[a][b] = dp[a-1][b]

    res.append(dp[k][-1])

res.sort(reverse=True)

print(sum(res[:m]))

문제상황

vscode로 파일명을 대소문자만 변경해서 push를 했는 데 왠걸 원격 브랜치의 파일명이 그대로 유지되는 일이 있었습니다. 해당 문제를 파악하지 못한채 pr을 올려버렸고 merge 된 main을 실행해보면 파일명과 import 한 파일의 대소문자가 달라 에러가 발생하는 이슈가 생겼습니다.

어떻게 해결했는가?

신속하게 구글링을 했고 해당 이슈는 여러 사람들도 많이 겪은 이슈라 어렵지 않게 해결할 수 있었습니다. 해결 방법은 크게 두가지가 있었는 데 git mv 명령어와 git config core.ingnorecase false 방법이 있었습니다.

git mv 명령어란

git mv 명령어는 git에서 파일을 이동하거나 이름을 변경하는 데 사용됩니다.

1. 파일 이름 변경

   git mv old_filename.txt new_filename.txt

• old_filename.txt -> new_filename.txt 으로 변경

2. 파일 이동

   git mv filename_txt new_directory/

• filename.txt 파일을 new_directory 디렉토리로 이동합니다.

3. 파일 이동 및 이름 변경

   git mv old_filename.txt new_directory/new_filename.txt

• old_filename.txt 파일을 new_directory 디렉토리로 이동하면서 이름을 new_filename.txt로 변경합니다.

git mv old_filename.txt OLD_FILENAME.txt

해당 방법을 통해 문제를 해결했습니다.

git config core.ingnorecase 명령어란

git config core.ignorecase는 git 설정에서 파일 이름의 대소문자 구분을 활성화하는 옵션입니다.

window나 macos의 경우 파일 시스템을 대소문자를 구별하지 않지만 Linux의 경우 대소문자를 구분하므로 크로스 플랫폼 개발시 유용한 설정입니다.

git config core.ignorecase설정을 true로 할 경우 git이 파일 이름의 대소문자를 무시합니다. 예를들어 README.md와 readme.md를 같은 파일로 인식합니다.

false로 설정 할 경우 git이 파일 이름의 대소문자를 구분합니다. README.md와 readme.md를 다른 파일로 인식합니다.

결론

저는 git mv 명령어를 이용하여 문제를 해결했습니다만. git config core.ignorecase 명령어는 어떤 건지 궁금해서 더 찾아보았고 각각의 해결방법을 정리해서 작성하게 되었습니다.