본문으로 건너뛰기
AIDevOps
  • Learn
  • Learning Paths
  • Practice
  • Open Source
  • Books
  • Engineering

    AI DevOpsAI 서비스 개발·운영 전체 지도LLMOpsLLM 배포·평가·관측실전 프로젝트AI Agent 프로젝트 실습

    Knowledge

    Docs기술 문서 모음Blog엔지니어링 아티클Plogger개발 기록 피드

    Validate

    Certification3단계 역량 인증 · 준비 중
AI Models
LlamaMistralGemmaDeepSeekQwen
🎨 Frontend
Frontend 입문 & 로드맵JavaScriptTypeScript|ReactNext.js|VueNuxt
🤖 AI 실전 개발
AI 실전 입문 & 로드맵Hugging FaceLangChainLlamaIndexLLMOps|LangGraphMCPMulti-AgentAgent Evaluation
🧠 AI Core
AI 입문 & 로드맵ML FundamentalsLLM Fundamentals|Python AIC++|PyTorchTensorFlowJAX
🧠 AI Agent 개발
금융 AI AgentLLM API 서버주식 투자 AgentAIOps AI Agent교육 AI Agent코딩 AI Agent
🌱 Spring Cloud
Spring 입문 & 로드맵Spring Cloud GatewaySpring BootJava|Spring AISpring SecuritySpring BatchSpring JPA
🐳 DevOps
DevOps 입문 & 로드맵LinuxDockerCI/CD|Kubernetes 기본K8s 심화/실무PrometheusGrafana
🧱 인프라
인프라 입문 & 로드맵NginxRedis
☁️ 클라우드
클라우드 입문 & 로드맵AWSGCPAzureNCPCloudflare
📱 Mobile
Mobile 입문 & 로드맵KotlinAndroidFlutter
⚙️ Backend
Backend 입문 & 로드맵Python 기본FastAPIDjangoFlask|CGoGinNode.js
💾 Database
DB 입문 & 로드맵공통 SQLOracleMySQLPostgreSQL|MongoDB벡터 DB
🧪 검증
k6JMeternGrinder
AIDevOps

Engineering AI. From Code to Production.
AI와 AI Agent를 개발하고 운영하기 위한 엔지니어링 학습 플랫폼

Learn

  • 전체 가이드
  • Learning Paths
  • Practice
  • Books

Resources

  • AI DevOps
  • LLMOps
  • 실전 프로젝트
  • Docs
  • Blog
  • Plogger
  • Open Source
  • Certification (준비 중)

Start Here

  • AI Core 로드맵
  • AI 실전 개발 로드맵
  • Spring Cloud 로드맵
  • DevOps 로드맵
  • 인프라 로드맵

 

  • 클라우드 로드맵
  • Frontend 로드맵
  • Mobile 로드맵
  • Backend 로드맵
  • Database 로드맵
© 2026 AI DevOps Korea. All rights reserved.
이용약관개인정보처리방침Sitemaptestforge.kr
  1. Home
  2. Learn
  3. Frontend
  4. TypeScript
타입 안전 JavaScript 완전 가이드

🔷 TypeScript 완전 가이드

Visitors

TypeScript로 타입 안전한 JavaScript를 작성하세요. 타입 시스템, 타입 좁히기, 제네릭, 유틸리티 타입, 실무 패턴까지 완전 가이드.

  • Beginner · 입문
  • 업데이트 2026.09.18
  • 약 5분 읽기
  • 8개 섹션
  • 예제 코드 4개
  • 웹 IDE 실습 제공
🔷

TypeScript 웹 IDE

설치 없이 브라우저에서 코드를 실행하고 단계별 예제로 익혀보세요.

웹 IDE 열기 →
대규모 프론트엔드Node.js 서버라이브러리 개발React/Vue/Angular

관련 프레임워크 & 개발환경

⚛️React→▲Next.js→🟢Node.js→

목차

0 / 10
  1. 가이드 사용법
  2. 구조 다이어그램
  3. 프로젝트 설정
  4. 타입 시스템
  5. 타입 좁히기 (Narrowing)
  6. 제네릭
  7. 유틸리티 타입
  8. TypeScript 설계
  9. 운영 기준
  10. 검증 전략
목차 10개 섹션
  1. 가이드 사용법
  2. 구조 다이어그램
  3. 프로젝트 설정
  4. 타입 시스템
  5. 타입 좁히기 (Narrowing)
  6. 제네릭
  7. 유틸리티 타입
  8. TypeScript 설계
  9. 운영 기준
  10. 검증 전략

가이드 사용법

읽는 방향

TypeScript를 실무 흐름으로 이해하기

TypeScript로 타입 안전한 JavaScript를 작성하세요. 타입 시스템, 타입 좁히기, 제네릭, 유틸리티 타입, 실무 패턴까지 완전 가이드. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.

핵심 관점

프론트엔드 / 앱 개발

화면을 그리는 법에서 멈추지 않고, 상태, 데이터 요청, 라우팅, 접근성, 배포 단위까지 함께 봅니다.

대규모 프론트엔드Node.js 서버라이브러리 개발React/Vue/Angular

구조 다이어그램

글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 TypeScript를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.

학습 흐름

다이어그램 렌더링 중…

아키텍처 관점

다이어그램 렌더링 중…

프로젝트 설정

TypeScript를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.

tsc --init으로 생성되는 tsconfig.json에서 실제로 자주 손보게 되는 값은 몇 개 안 됩니다. strict는 반드시 켜두는 것이 좋고, moduleResolution은 Vite/esbuild 같은 최신 번들러를 쓴다면 bundler로 설정합니다.
BASH
npm install -D typescript ts-node
npx tsc --init

# tsconfig.json 핵심 설정
# "strict": true
# "target": "ES2022"
# "moduleResolution": "bundler"

Tip

strict: true를 처음부터 켜두면 나중에 마이그레이션할 때보다 타입 오류를 훨씬 적게 만나게 됩니다 — 새 프로젝트는 항상 strict 모드로 시작하세요.

타입 시스템

여기서는 타입 시스템을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.

Discriminated Union(식별 가능한 유니온)은 각 타입에 공통된 리터럴 필드(여기서는 ok)를 두어, 그 값만 확인하면 TypeScript가 나머지 필드의 타입까지 자동으로 좁혀주는 패턴입니다. 이 패턴을 쓰면 "성공했는데 error 필드에 접근"하는 실수를 컴파일 타임에 막을 수 있습니다.
TYPESCRIPT
// Discriminated Union (추천 패턴)
type Result<T> =
  | { ok: true;  value: T }
  | { ok: false; error: string };

function parse(input: string): Result<number> {
  const n = Number(input);
  return isNaN(n)
    ? { ok: false, error: `"${input}" is not a number` }
    : { ok: true, value: n };
}

const result = parse("42");
if (result.ok) console.log(result.value); // TypeScript가 타입을 좁힘

타입 좁히기 (Narrowing)

여기서는 타입 좁히기 (Narrowing)을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.

유니온 타입(A | B)으로 선언된 값은 그 자체로는 A인지 B인지 알 수 없습니다. typeof, instanceof, in, 또는 직접 만든 타입 가드 함수로 조건을 검사하면, 그 조건 분기 안에서 TypeScript가 실제 타입을 좁혀 안전하게 해당 타입의 멤버에 접근할 수 있게 해줍니다.
narrowing.tsTYPESCRIPT
type Circle = { kind: 'circle'; radius: number };
type Square = { kind: 'square'; side: number };
type Shape = Circle | Square;

function area(shape: Shape): number {
  // 'kind' 필드로 분기하면 각 블록 안에서 타입이 자동으로 좁혀짐
  if (shape.kind === 'circle') {
    return Math.PI * shape.radius ** 2;   // 여기서는 shape가 Circle로 좁혀짐
  }
  return shape.side ** 2;                  // 여기서는 Square로 좁혀짐
}

// 커스텀 타입 가드 — is 키워드로 타입을 확정
function isCircle(shape: Shape): shape is Circle {
  return shape.kind === 'circle';
}

Tip

as Circle처럼 타입 단언(assertion)으로 강제로 타입을 바꾸는 것은 컴파일러를 속이는 것과 같습니다 — 런타임에는 아무 검증도 하지 않으므로, 가능하면 타입 가드로 실제 값을 확인한 뒤 좁히는 방식을 우선하세요.

제네릭

여기서는 제네릭을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.

제네릭은 "지금은 타입을 정하지 않고, 함수나 클래스를 사용하는 시점에 타입이 채워지는" 자리표시자입니다. ``처럼 제약을 걸면, 완전히 자유로운 타입이 아니라 "T의 실제 키 중 하나"처럼 의미 있는 범위로 좁힐 수 있습니다.
TYPESCRIPT
function pick<T, K extends keyof T>(obj: T, keys: K[]): Pick<T, K> {
  return Object.fromEntries(keys.map(k => [k, obj[k]])) as Pick<T, K>;
}

// 조건부 타입
type NonNullable<T> = T extends null | undefined ? never : T;
type ReturnType<T extends (...args: unknown[]) => unknown> = T extends (...args: unknown[]) => infer R ? R : never;

// 빌더 패턴
class QueryBuilder<T> {
  private filters: Partial<T> = {};
  where<K extends keyof T>(key: K, value: T[K]): this {
    this.filters[key] = value;
    return this;
  }
  build(): Partial<T> { return this.filters; }
}

유틸리티 타입

유틸리티 타입은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

TypeScript 내장 유틸리티 타입들은 이미 정의한 타입을 매번 손으로 다시 쓰지 않고 변형해서 재사용하게 해줍니다. 예를 들어 생성 시 필요한 모든 필드를 가진 User 타입이 있다면, 수정 폼에서는 Partial로 "일부만 보내도 되는" 버전을 따로 정의할 필요 없이 바로 만들 수 있습니다.
타입설명예시
Partial모든 프로퍼티를 optional로Partial
Required모든 프로퍼티를 required로Required
Pick특정 프로퍼티만 선택Pick
Omit특정 프로퍼티 제외Omit
Record키-값 맵 타입Record

TypeScript 실무 설계

TypeScript 실무 설계은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

TypeScript는 타입을 많이 쓰는 것보다 경계 타입을 정확히 잡는 것이 중요합니다. unknown 입력을 schema로 좁히고 domain type과 DTO를 분리해야 합니다.
결정 지점확인 질문실무 기준
경계TypeScript 코드에서 바뀌기 쉬운 부분은 어디인가?입출력, 설정, 외부 연동, 핵심 규칙을 분리합니다.
상태상태가 어디서 생성되고 어디서 사라지는가?상태 소유자와 수명 주기를 코드로 드러냅니다.
장애실패했을 때 호출자는 무엇을 받는가?timeout, fallback, error contract를 먼저 정합니다.

TypeScript 운영 기준

이 섹션은 TypeScript 운영 기준을 실무 관점에서 정리합니다. 개념을 외우기보다, 어떤 상황에서 이 기준을 꺼내 쓸지에 초점을 맞춰보세요.

tsconfig strictness, build artifact, type-only import, package boundary가 장기 유지보수에 영향을 줍니다.

Tip

  • strict mode
  • DTO/domain split
  • runtime schema
  • type regression

TypeScript 검증 전략

TypeScript 검증 전략은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

type test, runtime validation, API type regression을 함께 사용해야 합니다.
품질 축검증 방법완료 기준
정확성정상/실패 케이스를 자동화합니다.핵심 시나리오가 재현 가능하게 통과합니다.
회귀 방지버그 수정 시 동일 케이스를 테스트로 남깁니다.같은 장애가 다시 배포되지 않습니다.
운영성로그, 메트릭, 알림을 확인합니다.문제가 생겼을 때 원인 추적 경로가 있습니다.
← 이전 가이드JavaScript다음 가이드 →React