TypeScript on kastori

[TS #5] 타입 가드와 Discriminated Union — 런타임 타입 안전 처리

Wed, 24 Jun 2026 00:00:00 +0900

TypeScript는 컴파일 타임에 타입을 검사하지만, 실제 데이터는 런타임에 온다. 외부 API 응답, 이벤트 핸들러, 사용자 입력 — 이것들이 unknown이나 유니온 타입으로 들어올 때 TypeScript는 “이 값이 뭔지 확인하고 써라"고 강제한다. 그 확인하는 방법이 타입 가드다.

타입 가드 4가지

1. typeof — 원시 타입 분기

function process(value: string | number) {
 if (typeof value === 'string') {
 value.toUpperCase() // 여기서 value는 string
 } else {
 value.toFixed(2) // 여기서 value는 number
 }
}

typeof는 string, number, boolean, function, object 등 원시 타입에서만 쓴다.

2. instanceof — 클래스 인스턴스 분기

class NetworkError extends Error {
 statusCode: number
 constructor(message: string, statusCode: number) {
 super(message)
 this.statusCode = statusCode
 }
}

function handleError(err: Error) {
 if (err instanceof NetworkError) {
 console.log(err.statusCode) // NetworkError로 좁혀짐
 } else {
 console.log(err.message)
 }
}

3. in — 프로퍼티 존재 여부로 분기

interface Cat { meow(): void }
interface Dog { bark(): void }

function makeSound(animal: Cat | Dog) {
 if ('meow' in animal) {
 animal.meow() // Cat
 } else {
 animal.bark() // Dog
 }
}

4. 사용자 정의 타입 가드 — `is` 반환 타입

가장 강력하다. 직접 타입 가드 함수를 만들어서 unknown 데이터를 안전하게 처리한다.

function isUser(value: unknown): value is User {
 return (
 typeof value === 'object' &&
 value !== null &&
 'id' in value &&
 'name' in value
 )
}

// API 응답 검증
const data: unknown = await fetchJson('/api/user')
if (isUser(data)) {
 console.log(data.name) // 타입 안전하게 User로 사용
}

value is User가 반환 타입이다. 함수가 true를 반환하면 TypeScript가 그 블록 안에서 value를 User 타입으로 좁힌다.

Discriminated Union — 가장 강력한 상태 분기 패턴

공통 리터럴 필드(status, type 등)로 유니온을 구분하는 패턴이다. 상태 관리, API 응답 처리에서 자주 쓰인다.

결제 상태 처리

type PaymentState =
 | { status: 'idle' }
 | { status: 'pending' }
 | { status: 'success'; approvalNo: string; amount: number }
 | { status: 'fail'; errorCode: string; message: string }

function renderPayment(state: PaymentState) {
 switch (state.status) {
 case 'idle':
 return '결제 전'
 case 'pending':
 return '처리 중...'
 case 'success':
 return `승인번호: ${state.approvalNo}` // approvalNo 타입 보장
 case 'fail':
 return `오류: ${state.message}` // message 타입 보장
 }
}

status === 'success'인 브랜치에서는 approvalNo와 amount가 보장된다. status === 'fail'에서는 errorCode와 message가 보장된다. 각 상태마다 필요한 데이터를 타입 수준에서 강제한다.

API 응답 처리

type ApiResult<T> =
 | { success: true; data: T }
 | { success: false; error: string; code: number }

async function getUser(id: number): Promise<ApiResult<User>> {
 try {
 const user = await fetchUser(id)
 return { success: true, data: user }
 } catch {
 return { success: false, error: '조회 실패', code: 404 }
 }
}

const result = await getUser(1)
if (result.success) {
 console.log(result.data.name) // User 타입 보장
} else {
 console.log(result.error) // string 보장
}

result.success가 true면 data가 있고, false면 error와 code가 있다. try/catch 없이도 타입 수준에서 에러 케이스를 처리할 수 있다.

실무 패턴 — null 안전 처리

// 옵셔널 체이닝 (?.)
const city = user?.address?.city // user나 address가 null이면 undefined

// Nullish 병합 (??)
const name = user?.name ?? '이름 없음' // null/undefined이면 기본값

// null 단언 (!) — 확실할 때만
const name = user!.name // ⚠️ 실제로 null이면 런타임 오류

enum vs const 객체 vs 유니온

// enum — 런타임에 JS 객체로 남음 (번들에 포함)
enum Direction { UP = 'UP', DOWN = 'DOWN' }

// const 객체 — 값+타입 동시 활용, tree-shaking 가능
const Direction = { UP: 'UP', DOWN: 'DOWN' } as const
type Direction = typeof Direction[keyof typeof Direction] // 'UP' | 'DOWN'

// 유니온 — 가장 단순, 컴파일 후 사라짐
type Direction = 'UP' | 'DOWN'

단순한 상수값이면 유니온, 값을 변수처럼 참조해야 하면 const 객체를 쓴다. enum은 런타임에 JS 객체로 남아 번들에 포함되므로 신중하게 선택한다.

tsconfig strict 모드

타입 가드가 빛을 발하려면 strict: true가 필수다.

{
 "compilerOptions": {
 "strict": true, // null 체크, any 추론 금지 등 전체 활성화
 "noImplicitAny": true, // any로 추론되는 것 오류 처리
 "strictNullChecks": true, // null/undefined를 별도 타입으로 처리
 "noUnusedLocals": true // 안 쓰는 변수 오류
 }
}

strictNullChecks가 꺼져 있으면 null이 어디서든 들어갈 수 있어서 타입 가드의 효과가 절반으로 줄어든다.

마치며

타입 가드는 “컴파일러를 설득하는 방법"이다. TypeScript가 모르는 타입 정보를 런타임 조건으로 증명하면, 컴파일러가 그 블록 안에서 안전하게 타입을 좁혀준다.

이번 시리즈에서 TypeScript의 핵심을 Java와 비교하며 살펴봤다. 타입 시스템, interface/type, 제네릭, 유틸리티 타입, 타입 가드 — 이 다섯 가지를 이해하면 풀스택 프로젝트에서 Java와 TypeScript를 함께 다루는 데 충분한 기반이 된다.

[TS #4] 유틸리티 타입 — Partial, Pick, Omit, Record 실전 활용

Tue, 23 Jun 2026 00:00:00 +0900

REST API를 TypeScript로 타이핑하다 보면 비슷한 타입을 계속 만들게 된다. User는 있는데, 생성 요청에는 id가 없고, 수정 요청에는 일부 필드만 있고, 목록 조회에는 몇 개 필드만 필요하다. 이걸 매번 새 타입으로 만들면 User가 바뀔 때 다 같이 바꿔야 한다.

TypeScript는 이 문제를 유틸리티 타입으로 해결한다. 기존 타입을 변환해서 새 타입을 만드는 내장 헬퍼들이다.

Partial<T> — 모든 프로퍼티를 선택적으로

PATCH 요청처럼 일부 필드만 전송하는 경우에 쓴다.

interface User {
 id: number
 name: string
 email: string
 age: number
}

type UserUpdate = Partial<User>
// = { id?: number; name?: string; email?: string; age?: number }

async function updateUser(id: number, data: Partial<User>) {
 // data에는 바꾸려는 필드만 있으면 됨
}

updateUser(1, { name: '새 이름' }) // OK
updateUser(1, { name: '이름', age: 25 }) // OK

Required<T> — 모든 프로퍼티를 필수로

선택적 프로퍼티를 전부 필수로 바꿔야 할 때 쓴다.

interface Config {
 host?: string
 port?: number
 debug?: boolean
}

type StrictConfig = Required<Config>
// = { host: string; port: number; debug: boolean }

Readonly<T> — 읽기 전용으로 고정

불변 객체가 필요할 때 쓴다.

interface Cart {
 items: CartItem[]
 total: number
}

type FrozenCart = Readonly<Cart>

const cart: FrozenCart = { items: [], total: 0 }
cart.total = 100 // ❌ 컴파일 오류

Pick<T, K> — 필요한 프로퍼티만 선택

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

// 목록 조회 — id, name만 필요
type UserSummary = Pick<User, 'id' | 'name'>
// = { id: number; name: string }

// 프로필 카드 — id, name, email
type UserCard = Pick<User, 'id' | 'name' | 'email'>

Omit<T, K> — 불필요한 프로퍼티를 제외

// 생성 요청 — id, createdAt은 서버가 자동 생성
type CreateUserRequest = Omit<User, 'id' | 'createdAt'>
// = { name: string; email: string; password: string }

// 수정 요청 — id는 URL에 있고, 나머지는 선택적
type UpdateUserRequest = Partial<Omit<User, 'id' | 'createdAt'>>
// = { name?: string; email?: string; password?: string }

Pick vs Omit 선택 기준: 남길 필드가 적으면 Pick, 제거할 필드가 적으면 Omit. 필드가 10개인데 9개 필요하면 Omit이 훨씬 간결하다.

Record<K, V> — 키-값 맵

// string 키에 number 값
type ScoreBoard = Record<string, number>
const scores: ScoreBoard = { alice: 100, bob: 85 }

// 유니온 키 — 모든 키가 반드시 있어야 함
type OrderStatus = 'PENDING' | 'PAID' | 'SHIPPED' | 'DELIVERED' | 'CANCELLED'

type StatusLabel = Record<OrderStatus, string>
const labels: StatusLabel = {
 PENDING: '결제 대기',
 PAID: '결제 완료',
 SHIPPED: '배송 중',
 DELIVERED: '배송 완료',
 CANCELLED: '취소됨',
 // 하나라도 빠지면 컴파일 오류
}

유니온을 키로 쓰면 모든 케이스를 커버했는지 컴파일러가 확인해준다. 새 상태가 추가되면 labels도 함께 채워야 한다.

Exclude / Extract — 유니온 필터링

type AllRoles = 'admin' | 'user' | 'guest' | 'moderator'

// Exclude — 제거
type NonAdminRoles = Exclude<AllRoles, 'admin'>
// = 'user' | 'guest' | 'moderator'

// Extract — 추출
type StaffRoles = Extract<AllRoles, 'admin' | 'moderator'>
// = 'admin' | 'moderator'

// NonNullable — null, undefined 제거
type SafeString = NonNullable<string | null | undefined>
// = string

ReturnType / Parameters — 함수 타입 추출

함수 시그니처를 직접 타이핑하지 않고 타입을 추출할 수 있다.

function fetchUser(id: number): Promise<User> {
 return fetch(`/api/users/${id}`).then(r => r.json())
}

type FetchReturn = ReturnType<typeof fetchUser>
// = Promise<User>

type FetchParams = Parameters<typeof fetchUser>
// = [id: number]

// Awaited — Promise를 풀어서 내부 타입 추출
type UserType = Awaited<ReturnType<typeof fetchUser>>
// = User

라이브러리 함수의 반환 타입을 재활용할 때 유용하다. 함수 시그니처가 바뀌면 ReturnType도 자동으로 따라간다.

실무 조합 패턴

위 유틸리티 타입들을 조합하면 Article 하나에서 여러 용도의 타입을 파생시킬 수 있다.

interface Article {
 id: number
 title: string
 content: string
 authorId: number
 tags: string[]
 published: boolean
 createdAt: string
 updatedAt: string
}

// 목록 API 응답
type ArticleListItem = Pick<Article, 'id' | 'title' | 'authorId' | 'tags' | 'createdAt'>

// 생성 요청
type CreateArticleDto = Pick<Article, 'title' | 'content' | 'tags'>

// 수정 요청 — 제목, 내용, 태그만 수정 가능, 모두 선택적
type UpdateArticleDto = Partial<Pick<Article, 'title' | 'content' | 'tags'>>

// 임시 저장 — id, 타임스탬프 없는 상태
type ArticleDraft = Omit<Article, 'id' | 'createdAt' | 'updatedAt'>

Article 인터페이스만 수정하면 나머지는 자동으로 따라간다.

마치며

유틸리티 타입은 “기존 타입에서 파생"한다는 발상이다. 처음부터 모든 타입을 손으로 만들지 않아도 된다. Partial, Pick, Omit만 익혀도 API 타이핑의 80%는 해결된다.

다음 글에서는 유니온 타입을 런타임에 안전하게 처리하는 타입 가드와, 상태 관리에서 자주 쓰이는 Discriminated Union 패턴을 다룬다.

[TS #3] 제네릭 — Java 제네릭과 뭐가 다른가

Mon, 22 Jun 2026 00:00:00 +0900

Java의 List<T>, Optional<T>를 써봤다면 TypeScript 제네릭은 이미 절반은 아는 것이다. 개념은 동일하다 — 타입을 파라미터로 받아서 재사용 가능한 코드를 만든다. any를 쓰지 않고도 다양한 타입을 처리할 수 있다.

제네릭이 필요한 이유

any를 쓰면 일단 동작은 하지만 타입 정보가 사라진다.

// any — 타입 정보 소실
function identity(value: any): any {
 return value
}
const result = identity('hello') // 타입: any
result.toUpperCase() // OK인지 런타임 전엔 모름

// 제네릭 — 타입 유지
function identity<T>(value: T): T {
 return value
}
const result = identity('hello') // 타입: string (자동 추론)
const result = identity<number>(42) // 타입: number (명시)

<T>가 타입 파라미터다. Java의 <T>와 같다.

함수 제네릭

// 배열 첫 번째 요소 반환
function first<T>(arr: T[]): T | undefined {
 return arr[0]
}

first(['a', 'b', 'c']) // string | undefined
first([1, 2, 3]) // number | undefined

// 두 타입 파라미터
function swap<T, U>(a: T, b: U): [U, T] {
 return [b, a]
}

const [b, a] = swap('hello', 42) // [number, string]

인터페이스 제네릭 — API 응답 래퍼

실무에서 가장 자주 쓰이는 패턴이다. 모든 API 응답을 하나의 제네릭 인터페이스로 감싼다.

interface ApiResponse<T> {
 data: T
 message: string
 success: boolean
 timestamp: string
}

interface User { id: number; name: string }
interface Order { id: number; total: number }

const userResponse: ApiResponse<User> = {
 data: { id: 1, name: '홍길동' },
 message: '조회 성공',
 success: true,
 timestamp: '2026-06-20',
}

const ordersResponse: ApiResponse<Order[]> = {
 data: [{ id: 1, total: 15000 }],
 message: '주문 목록 조회 성공',
 success: true,
 timestamp: '2026-06-20',
}

페이지네이션, Repository 패턴도 같은 방식으로 표현한다.

interface Paginated<T> {
 items: T[]
 total: number
 page: number
 size: number
 hasNext: boolean
}

interface Repository<T, ID> {
 findById(id: ID): Promise<T | null>
 findAll(): Promise<T[]>
 save(entity: Omit<T, 'id'>): Promise<T>
 update(id: ID, entity: Partial<T>): Promise<T>
 delete(id: ID): Promise<void>
}

제약 조건 — extends로 타입 파라미터를 제한

타입 파라미터가 특정 구조를 가져야 할 때 extends로 제약을 건다.

// T는 반드시 id 프로퍼티를 가져야 함
function findById<T extends { id: number }>(items: T[], id: number): T | undefined {
 return items.find(item => item.id === id)
}

findById([{ id: 1, name: '홍' }], 1) // OK
findById(['a', 'b'], 1) // ❌ string에는 id가 없음

keyof 제약 — 실제 존재하는 키만 허용

keyof T는 객체 T의 키 타입을 추출한다. Java에는 없는 개념이다.

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

const user = { name: '홍길동', age: 30 }
getProperty(user, 'name') // string
getProperty(user, 'age') // number
getProperty(user, 'email') // ❌ 컴파일 오류 — email 키 없음

K extends keyof T는 “K는 T의 실제 키 중 하나"를 의미한다. 존재하지 않는 키로 접근하면 컴파일 오류가 난다.

기본값 타입

interface Container<T = string> { // T가 없으면 string
 value: T
}

const c1: Container = { value: '기본' } // Container<string>
const c2: Container<number> = { value: 42 } // Container<number>

실무 패턴 — API 호출 함수

async function fetchApi<T>(url: string): Promise<ApiResponse<T>> {
 const res = await fetch(url)
 const json = await res.json()
 return json as ApiResponse<T>
}

// 사용 — T만 바꾸면 모든 엔드포인트에 재사용
const userRes = await fetchApi<User>('/api/users/1') // ApiResponse<User>
const ordersRes = await fetchApi<Order[]>('/api/orders') // ApiResponse<Order[]>

타입 파라미터 하나로 모든 API 응답을 타입 안전하게 처리한다.

Java와의 차이점

Java 제네릭과 개념은 같지만 두 가지 차이가 있다.

1. 타입 소거(Type Erasure): Java는 런타임에 제네릭 타입 정보가 지워진다(List<String>이 런타임엔 그냥 List). TypeScript도 마찬가지다 — 컴파일 후 .js에는 타입 정보가 없다.

2. 구조적 타이핑: Java는 T extends Comparable<T> 처럼 명시적 인터페이스가 필요하지만, TypeScript는 구조만 맞으면 된다.

// Java라면 T extends HasId<T> 같은 선언 필요
// TypeScript는 그냥 구조로 제약
function findById<T extends { id: number }>(items: T[], id: number) {
 return items.find(item => item.id === id)
}

마치며

TypeScript 제네릭은 Java에서 이미 익숙한 개념이다. ApiResponse<T>, Paginated<T> 같은 공통 래퍼를 한 번 만들어두면 프로젝트 전체에서 타입 일관성이 생긴다.

다음 글에서는 TS가 기본 제공하는 유틸리티 타입들 — Partial, Pick, Omit, Record 등을 실무 API 패턴과 함께 살펴본다.

[TS #2] interface vs type — 언제 뭘 쓰는가

Sun, 21 Jun 2026 00:00:00 +0900

TypeScript를 처음 쓰면 금방 이 질문에 부딪힌다. “타입 정의할 때 interface 써야 해, type 써야 해?” 둘 다 되는 것 같고, 문서마다 다르게 쓰여 있다. 결론부터 말하면 객체 형태는 interface, 유니온·복잡한 조합은 type이 실무 기준이다.

interface — 객체의 계약을 정의한다

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

const user: User = {
 id: 1,
 name: '홍길동',
 email: 'hong@example.com',
}

Java의 interface와 비슷하다. 객체가 어떤 프로퍼티를 가져야 하는지 정의한다.

선택 프로퍼티와 읽기 전용

interface UserProfile {
 id: number
 name: string
 bio?: string // ? — 있어도 없어도 됨
 readonly createdAt: string // readonly — 수정 불가
}

const profile: UserProfile = { id: 1, name: '홍길동', createdAt: '2026-06-20' }
profile.createdAt = '2026-01-01' // ❌ 컴파일 오류

확장 — extends로 상속

interface Admin extends User {
 role: 'SUPER' | 'MANAGER'
 permissions: string[]
}

Java의 extends와 동일하다.

함수 타입 정의

interface Repository<T> {
 findById(id: number): Promise<T | null>
 save(entity: T): Promise<T>
 delete(id: number): Promise<void>
}

선언 합병 — interface만 가능한 기능

// 같은 이름을 두 번 선언하면 합쳐진다
interface Window {
 myCustomProp: string
}

// 이제 window.myCustomProp 사용 가능

외부 라이브러리 타입에 프로퍼티를 추가할 때 유용하다. type으로는 불가능하다.

type 별칭 — interface가 못하는 것을 한다

// 객체 타입 — interface와 동일
type Point = {
 x: number
 y: number
}

// 유니온 타입 — interface로 불가
type Status = 'pending' | 'approved' | 'rejected'
type ID = string | number

// 인터섹션 — 두 타입을 합침
type AdminUser = User & { role: string }

// 튜플
type Coordinate = [number, number]

// 함수 시그니처 별칭
type Handler = (event: Event) => void

type의 핵심은 유니온과 인터섹션이다. Status처럼 문자열 리터럴의 유니온으로 상태값을 표현하는 것은 TypeScript에서 매우 흔한 패턴인데, 이건 type으로만 할 수 있다.

확장 — &로 합성

type Animal = { name: string }
type Dog = Animal & { breed: string }

interface의 extends와 결과는 같지만 문법이 다르다.

언제 뭘 쓰는가 — 실무 기준

기능	interface	type
객체 타입 정의	✅	✅
확장	`extends`	`&`
유니온 타입	❌	✅
선언 합병	✅	❌
조건부·매핑 타입	❌	✅

interface를 쓸 때:
 - 객체 형태 정의 (DTO, Props, API 응답 구조)
 - 클래스가 구현할 계약
 - 외부 라이브러리 타입 확장 (선언 합병 필요 시)

type을 쓸 때:
 - 유니온 타입 (Status, Role, Direction 등 상태값)
 - 인터섹션으로 타입 합성
 - 조건부·매핑 타입 등 고급 패턴
 - 튜플, 함수 시그니처 별칭

실무 패턴 예시

실제 프로젝트에서 어떻게 나뉘는지 보면 기준이 명확해진다.

// API 응답 구조 — interface
interface ApiResponse<T> {
 data: T
 message: string
 status: number
}

// 상태값 — type (유니온)
type OrderStatus = 'PENDING' | 'PAID' | 'SHIPPED' | 'DELIVERED' | 'CANCELLED'

// React 컴포넌트 Props — interface
interface ButtonProps {
 label: string
 variant?: 'primary' | 'secondary' | 'danger'
 disabled?: boolean
 onClick: () => void
}

// 기존 타입에서 파생 — type
type CreateUserRequest = Omit<User, 'id' | 'createdAt'>
type UpdateUserRequest = Partial<Omit<User, 'id'>>

Omit, Partial 같은 유틸리티 타입을 쓰는 파생 타입은 type으로 만든다. 다음 글에서 이 유틸리티 타입들을 자세히 다룬다.

동적 키 — 인덱스 시그니처

키 이름을 미리 알 수 없는 경우에 쓴다.

interface StringMap {
 [key: string]: string
}

const map: StringMap = {
 name: '홍길동',
 city: '서울',
 // 어떤 string 키든 추가 가능
}

// Record<K, V>가 더 명확한 표현
type StringMap = Record<string, string>

마치며

둘 다 쓸 수 있는 상황에서는 interface를 기본으로 쓰고, 유니온이나 타입 조합이 필요할 때 type으로 전환하면 된다. 팀이 있다면 컨벤션을 하나로 통일하는 것이 중요하다.

다음 글에서는 interface와 type 모두에서 쓸 수 있는 제네릭 — 타입을 파라미터로 받는 방법을 다룬다.

[TS #1] TypeScript를 왜 쓰는가 — Java와 비교하며 이해하기

Sat, 20 Jun 2026 00:00:00 +0900

풀스택으로 일하다 보면 백엔드는 Java, 프론트엔드는 TypeScript를 같이 쓰게 된다. 두 언어 모두 정적 타입이라 개념은 익숙한데, 막상 코드를 쓰다 보면 미묘하게 다르게 동작해서 헷갈리는 순간이 생긴다. “Java도 타입 있는데 굳이 TS가 다른 건 뭐지?” — 비교해보면 빠르게 정리된다.

JavaScript의 문제, TypeScript의 해결

JavaScript로만 개발하면 이런 상황이 생긴다.

function greet(user) {
 return user.name.toUpperCase() // user가 null이면 런타임 에러
}

greet(null) // TypeError: Cannot read properties of null

배포 나가고 나서야 터진다. TypeScript를 쓰면 이 문제를 컴파일 타임에 잡는다.

function greet(user: { name: string } | null) {
 return user?.name.toUpperCase() // null 처리 강제 — 안 하면 컴파일 오류
}

TypeScript가 해결하는 세 가지:

컴파일 타임 오류 탐지 — 배포 전에 타입 오류를 잡는다
IDE 자동완성 — 객체 프로퍼티, 함수 시그니처까지 정확하게 제안
리팩터링 안전성 — 타입 변경 시 영향 범위를 컴파일러가 추적

TypeScript는 JS로 트랜스파일된다

TypeScript 파일(.ts)은 직접 실행되지 않는다.

.ts 파일
 ↓ tsc (TypeScript Compiler)
.js 파일 ← 브라우저/Node.js가 실행

타입 정보는 컴파일 시 모두 제거된다. 런타임에는 순수 JavaScript만 남는다. Java의 .java → .class 컴파일과 비슷한 흐름이지만, 결과물이 JS이기 때문에 JVM 없이 브라우저에서 바로 돈다.

기본 타입 — Java와 뭐가 다른가

Java에서 온 개발자가 헷갈리는 차이들이 있다.

// TS는 int/double/float 구분 없이 number 하나
const age: number = 30
const price: number = 9.99

// 배열 — 두 가지 문법이 동일
const names: string[] = ['김', '이', '박']
const names: Array<string> = ['김', '이', '박']

// 타입 추론 — 명시 안 해도 됨
const greeting = '안녕하세요' // TypeScript가 string으로 추론
const count = 0 // number로 추론

// 함수 파라미터는 항상 명시 (추론 불가)
function add(a: number, b: number): number {
 return a + b
}

Java처럼 엄격하게 타입을 명시해도 되고, 추론에 맡겨도 된다. 실무에서는 변수는 추론, 함수 파라미터/반환 타입은 명시하는 편이다.

Java에 없는 특수 타입들

any — 타입 검사를 포기한다

let value: any = '문자열'
value = 42 // OK
value.foo() // OK — 런타임에 터져도 컴파일 통과

// ❌ any는 TypeScript를 쓰는 의미를 없앤다

any는 TypeScript에게 “이 값은 신경 쓰지 마"라고 선언하는 것이다. 가능하면 쓰지 않는다.

unknown — 타입 안전한 any

let value: unknown = fetchSomething()

// ❌ 타입 확인 전 사용 불가
value.toUpperCase() // 컴파일 오류

// ✅ 타입 확인 후 사용 가능
if (typeof value === 'string') {
 value.toUpperCase() // OK
}

외부 API 응답이나 JSON.parse() 결과처럼 타입을 모를 때는 any 대신 unknown을 쓴다. 사용 전 반드시 타입을 확인해야 하므로 런타임 오류를 예방한다.

never — 절대 도달할 수 없는 타입

function throwError(msg: string): never {
 throw new Error(msg) // 절대 정상 반환 안 함
}

// Exhaustive check — 모든 케이스를 처리했는지 컴파일러가 확인
type Shape = 'circle' | 'square' | 'triangle'

function getArea(shape: Shape): number {
 switch (shape) {
 case 'circle': return Math.PI
 case 'square': return 1
 case 'triangle': return 0.5
 default:
 const _check: never = shape // Shape에 새 케이스 추가 시 여기서 컴파일 오류
 throw new Error(`Unknown shape: ${_check}`)
 }
}

never는 “여기까지 오면 안 된다"는 표식이다. 유니온 타입이 늘어날 때 switch 분기를 빠뜨리면 컴파일러가 잡아준다.

Java vs TypeScript: 타입 시스템의 근본적 차이

가장 중요한 차이는 명목적 타입(Java) vs 구조적 타입(TypeScript) 이다.

	Java (명목적)	TypeScript (구조적)
타입 판단 기준	클래스 이름	객체의 구조(프로퍼티 형태)
예시	`Dog`는 `extends Animal` 명시 필요	`{ name: string }`은 같은 구조면 같은 타입

interface Point { x: number; y: number }

function printPoint(p: Point) {
 console.log(p.x, p.y)
}

// Point를 implements하지 않아도 OK — 구조가 맞으면 됨
const myPoint = { x: 10, y: 20, z: 30 }
printPoint(myPoint) // OK — x, y가 있으니까

Java라면 myPoint가 Point를 implements해야 한다. TypeScript는 구조만 맞으면 통과다. 처음엔 어색하지만 익숙해지면 훨씬 유연하다.

마치며

TypeScript는 JavaScript에 Java식 타입 안전성을 더한 언어다. 개념은 이미 알고 있다 — 타입 시스템, 컴파일 타임 검사, 인터페이스. 차이는 구조적 타이핑과 트랜스파일 방식이다.

다음 글에서는 TypeScript에서 타입을 정의하는 두 가지 방법 — interface와 type 별칭 — 을 언제 어떻게 쓰는지 살펴본다.